https://open-source-silicon.dev
Join Slack
Hello, I'm trying to simulate a simple inverter using the most recent openpdk, skywater pdk, and Xyc...
# xyce
j
Hello, I'm trying to simulate a simple inverter using the most recent openpdk, skywater pdk, and Xyce version DEVELOPMENT-202108231700-g-9e0db523-opensource. I am using the openpdk Xyce patches from https://github.com/RTimothyEdwards/open_pdks/issues/124 and Xyce parses the netlist and simulates, but produces an incorrect result as shown below. Does anyone have any experience with this or have gotten primitive device simulation working? Thanks
xyce_test.tar.xz
e
@Jesse Cirimelli-Low I can take a look at this.
m
It's related to the scaling again. I tried removing the AGAUSS stuff but I can't replicate what I had back in June even with an older version of Xyce so I'm not sure what happened
e
@Matthew Guthaus thanks, that makes sense. I’m in the midst of various meetings today so I may not have an answer before tomorrow.
There have been changes to the source code since June, of course, but not many that I can think of that would have impacted scaling. So, this is a bit mysterious, but we should be able to track it down.
m
I'm also not sure which version of Xyce I was using from June
e
This may be a good candidate issue for me to use git-bisect.
m
I do like that, but it is a little bit of a pain in a compile loop. I'll see if I can identify further here too
I was trying to use an older version from June ( 31a37766a0a9962fa4823ea1b17f35a6194e826b) and it actually gives me an error trying to print the Z node. It's like it doesn't exist, perhaps due to pruning the transistors out for some reason?
Copy code
***** Reading and parsing netlist...
Netlist error: There was 1 undefined symbol in .PRINT command: node Z
Simulation aborted due to error.  There are 0 MSG_FATAL errors and 1 MSG_ERROR
 errors
*** Xyce Abort ***
Simulation aborted due to error.  There are 0 MSG_FATAL errors and 1 MSG_ERROR
 errors
But then I use the same version on another machine and it runs, but gives me the invalid output as well as the warnings:
Copy code
***** Setting up topology...

Netlist warning in file
 /home/mrg/test/share/pdk/sky130A/libs.tech/ngspice/../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_01v8__tt.pm3.spice
 at or near line 31
 Device instance X2:MSKY130_FD_PR__NFET_01V8: Source conductance reset to
 1.0e3 mho
Netlist warning in file
 /home/mrg/test/share/pdk/sky130A/libs.tech/ngspice/../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_01v8__tt.pm3.spice
 at or near line 31
 Device instance X2:MSKY130_FD_PR__NFET_01V8: Drain conductance reset to 1.0e3
 mho
Netlist warning in file
 /home/mrg/test/share/pdk/sky130A/libs.tech/ngspice/../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__pfet_01v8__tt.pm3.spice
 at or near line 33
 Device instance X1:MSKY130_FD_PR__PFET_01V8: Source conductance reset to
 1.0e3 mho
Netlist warning in file
 /home/mrg/test/share/pdk/sky130A/libs.tech/ngspice/../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__pfet_01v8__tt.pm3.spice
 at or near line 33
 Device instance X1:MSKY130_FD_PR__PFET_01V8: Drain conductance reset to 1.0e3
 mho
Is the version supposed to include the build time and the commit ID? because the other version has the wrong commit ID: DEVELOPMENT-202109021201-g-af5539f1-opensource It is. I didn't do a reconfigure/make clean so it had an old version, I think.
e
The .PRINT error is weird. Xyce shouldn’t have a problem with that, normally. Possibly you need to do a clean rebuild?
But, the warnings seem like a red flag, possibly related to scaling.
m
Yeah, they were the same ones as before, but I have removed the AGAUSS stuff which made it go away before because there weren't multiple levels of scaling
e
Got it. I thought they sounded familiar.
m
This old version has the print statements for the l/w parameters and they are the correct values: BSIM4:Instance:processParams l = 1.5e-07 BSIM4:Instance:processParams w = 1.26e-06
e
@Matthew Guthaus I just built a copy of Xyce from June 23. It does produce the print statements you mention, but the incorrect inverter result is the same as I get with today’s copy of Xyce.
m
I cleanly rebuilt on my two machines and one still fails with that node Z error
Both with version 31a37766
e
Huh. I don’t get that. I haven’t had much chance to really work on this today, but I’ll try to dig into this tomorrow.
m
Ok, Jesse got the Verilog-A plugins working for some ReRAM modeling but then this cropped up
I figured out the Z error. It was a debug thing I added to the library models (or actually somethign I commented out)
e
Cool. If I add nrd=1 nrs=1 to the subcircuit call lines, then the warnings about source conductance, etc., go away. They are being set to zero inside the subcircuit. But, this doesn’t change the inverter result.
Also, I quickly tried running this in ngspice and it got the same result as Xyce.
m
That's interesting... Did you fix the scaling for ngspice?
.options parser scale=1u vs .option scale=1u
e
Yes, I did change the scale command to be consistent with ngspice. I didn’t change anything else however. I wasn’t sure if anything else present in the files would matter or not. But anyway, with the ngspice version of scale, it produced the same (wrong looking) result as Xyce.
t
@Jesse Cirimelli-Low: All the discussion is good, but the source of the issue appears to be that you have not set the voltage for Vdd.
😂 1
🙌 1
m
facepalm
@Tim Edwards It looks like all the changes for Xyce are in open_pdks then except for the incompatible .options parser one. Does it make sense to have a separate xyce directory instead of ngspice with that version?
t
I thought that according to Eric, Xyce now handles the 
.option scale
line properly. . . see Eric's comment above. My understanding is that the ngspice and xyce model contents should be equivalent.
m
It does not as of the current master branch: ***** Reading and parsing netlist... Netlist warning in file /home/mrg/test/share/pdk/sky130A/libs.tech/ngspice/all.spice at or near line 2 Unrecognized dot line will be ignored
I think that was referring to the fact that he changed the scale back to be compatible with ngspice
t
@Eric Keiter will have to comment on that. My understanding (from spending a lot of time looking into it) is that the scale cannot simply be changed. The model equations have lots of coefficients with the scalefactor multiplied in, so it's actually a huge and complicated effort to figure out how to rewrite all the model equations to be compatible with SI units.
m
This is just a syntax change, not actually changing the scale.
".option scale=1u" to ".options parser scale=1u"
t
Oh, I get it.
m
We would still get those warnings unless we change the nrd and nrs, but that appears to be harmless.
t
I wonder if there are any other clever ways around the .option scale issue. It's annoying to have to have a separate directory and copy and link lots of files just because one of them requires a one-line change.
m
I agree
e
@Matthew Guthaus & @Tim Edwards yes, currently in Xyce, scale is set via 
.options parser scale=1u
. I have thought about attempting to change Xyce’s syntax to just be 
.option scale=1u
, like ngspice and other codes such as Hspice. That is possible to do, but it sort of breaks the standard way that we handle other types of options in Xyce. So it is a bit of a philosophical shift.
But, if the ONLY difference between the ngspice files and the Xyce files is this issue, it might be worth doing.
It looks like (at least in this version of the files) that .options parser scale=# only appears in the 
xyce_test/pdk/sky130A/libs.tech/ngspice/all.spice
file. Is that the case? if so it is really just a single file that would require 2 versions.
t
Is it really a philosophical stretch to consider that 
.option
is a compatibility level support for known other versions of SPICE? After all 
.options
and 
.option
are two different cards.
It's more than a single file because 
all.spice
is called from at least 
sky130.lib.spice
and possibly others, which would need to be changed as well.
It is also a matter of figuring out how to support xyce vs. ngspice when running a simulation from, say, xschem.
m
It's included in at least 26 files
e
Ah. Ok then.
Regarding the philosophical angle, it is probably not a big deal. Possibly I’m just being pedantic.
m
You can't take it back if you add it though, so it's worth debating 🙂
t
My take on it is that 
.option
is a legal card in Berkeley spice3, so not supporting it is a serious compatibility issue.
m
What are the other things taht can be used with .option?
e
Mainly in the very early days of the project, when I looked at what other tools did, it felt too limiting to have a single 
.option
command for all manner of code options. For example, I wanted to be able to independently set different tolerances in different parts of the code (like the iterative solver vs. the nonlinear solver vs. the time integrator). But most SPICE codes apply the same tolerances to everything. So, to have more flexibility, we decided to go with the 
.options <package_name> param=#
format. So, we’ve stuck with that pattern ever since. But, we were less concerned with being precisely compatible with other codes back in those days, and we are much more concerned with it now.
m
Oh, all the tolerance things...
🙂 1
e
I did actually add an issue to our internal bug tracker last month, to support the 
.option scale=#
format. So, I’m not totally opposed to the idea, but I hadn’t quite made peace with it yet.
2 Views
Open in Slack
PreviousNext
Powered by

What is Linen?

Linen is a search-engine friendly community platform. We offer integrations with existing Slack/Discord communities and make those conversations Google-searchable.

Powered by