https://open-source-silicon.dev logo
Join Slack
Powered by
Hi, I'm trying to use case to get a sweep in tempe...
# chipalooza
a
Hi, I'm trying to use case to get a sweep in temperatures but it fails in drawing the graph. The cace table is generated but clicking the 
temperature
button to see the graph just cleans the window. I think this problem could be related with the use of a 
measure
field with a python script. This is the repo, the simulations take a while. After each simulation it writes an error.
Copy code
CACE Simulation error:  format is missing entries
simline is:  2.99171835e-05  1.86475860e+00 
formatvars are: result
That's because I miss something in the 
format
entry? Should I define the 
variables
dictionary?
t
You shouldn't need 
variables
set. Is the repository in a state where I can try to reproduce this result?
a
Yes, I've uploaded changes right now. Please read the README.md because you have to upload a submodule to use the Makefile system.
Sorry for the late reply, I was on a meeting
t
I have the repository but I don't see a "Temperature Sweep" parameter.
a
I'm watching the github site and its on line 229 from the 
SDC.txt
file, in 
electrical_parameters
dictionary.
Copy code
name:		temperature_sweep
status:		skip
description:	Mean voltage in a range of temperatures
display:	Temperate sweep
unit:		V
spec {
	typical:	any
}
simulate {
	tool:		ngspice
	template:	transient.spice
	format:		ascii .data result
}
measure {
	tool: python
	filename: analyze_temps.py
}
conditions {
	name:		temperature
	minimum:	-40
	maximum:	130
	step: 		linear
	stepsize:	30

	+
	name:		corner
	typical:	tt
}
t
@aquiles viza: Oh, I see it. I had copied the text file into a different directory when I was figuring out how to accommodate your multiple schematic directories, and I was looking at that file, which was outdated.
The first problem is that 
wrdata
always plots an extra variable in front, which for transient simulations like this one is always time. You need something like 
format:  ascii .data null result
or 
format:  ascii .data time result
(but then you need to declare 
time
as in a 
variables
block). This solves some of the error messages that appear in the output, but it doesn't get rid of the main problem, which is that you cannot go from the result table view to a plot. I suspect this has something to do with the way that the 
analyze_temps.py
script passes data back to the program, although I'm not sure what your 
analyze_temps.py
script is doing.
Okay, I get what you're doing now; your 
measure
script takes in the 
time  value
result from the 
.data
file and generates a single result output. That's fine; the 
format:
line still needs to be 
format:  ascii .data null result
because it still indicates the format of the output file (which CACE is trying to do something with, even if you are ignoring it and just reading the .data file from your script). But I think all that does is just generate some error messages in the terminal. I don't think that impacts the actual error at all.
Everything seems to be working correctly except for generating the plot from the table values. I will need to debug this. It does not appear to affect the simulation results in any way, just the ability to create the plot over temperature. When it reshapes the result vector into (value, temperature) pairs, only the first result is handled. The rest of the results don't get the temperature added.
@aquiles viza: Okay, I just patched CACE to fix this error, and I can now get a plot of the result vs. temperature for the temperature sweep (the problem was, as I thought, only in the preparation of the plot, and not in the data itself).
a
I've tested the code and it worked fine, the only problem I'm facing is that the plot should start from -40 followed by -10, but those values are missing. I'm not sure but maybe is related to the 
-
on the name.
t
Are the negative temperatures in the list format? Or might the simulation have failed at those points?
a
Are in the linear format, with stepsize=30, The simulation files and results exists but cace is not reading them
t
Sounds like a pretty clear bug to me but I will need to track it down.
a
I run the code with the "simulate single-threaded" setting and now it shows the complete range. I think this problem could be related with the number of concurrent simulations, because running everything at once don't works as expected either
t
That is a weird issue. Whenever I run it, multithreaded or not, all seven simulations get run. The simulations are ordered with the negative temperatures first; and while I have no idea how the multithreading scheduling works, I know they are passed to the scheduler in order. I have Leo Moser reworking the code to try to simplify the multithreading, so I hope that will make these problems go away. That work probably won't be finished until next week, though.
16 Views
Open in Slack
PreviousNext
Powered by