Hello I m trying to simulate a simple inverter using the mos open-source-silicon.dev #xyce

Hello, I'm trying to simulate a simple inverter us...

Jesse Cirimelli-Low

09/02/2021, 10:32 AM

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

Eric Keiter

09/02/2021, 3:44 PM

@Jesse Cirimelli-Low I can take a look at this.

Matthew Guthaus

09/02/2021, 3:48 PM

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

Eric Keiter

09/02/2021, 3:55 PM

@Matthew Guthaus thanks, that makes sense. I’m in the midst of various meetings today so I may not have an answer before tomorrow.

Eric Keiter

09/02/2021, 4:01 PM

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.

Matthew Guthaus

09/02/2021, 5:17 PM

I'm also not sure which version of Xyce I was using from June

Eric Keiter

09/02/2021, 5:18 PM

This may be a good candidate issue for me to use git-bisect.

Matthew Guthaus

09/02/2021, 5:20 PM

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

Matthew Guthaus

09/02/2021, 9:16 PM

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

Matthew Guthaus

09/02/2021, 9:17 PM

~~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.

Eric Keiter

09/02/2021, 9:26 PM

The .PRINT error is weird. Xyce shouldn’t have a problem with that, normally. Possibly you need to do a clean rebuild?

Eric Keiter

09/02/2021, 9:27 PM

But, the warnings seem like a red flag, possibly related to scaling.

Matthew Guthaus

09/02/2021, 9:28 PM

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

Eric Keiter

09/02/2021, 9:28 PM

Got it. I thought they sounded familiar.

Matthew Guthaus

09/02/2021, 9:33 PM

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

Eric Keiter

09/02/2021, 11:05 PM

@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.

Matthew Guthaus

09/02/2021, 11:06 PM

I cleanly rebuilt on my two machines and one still fails with that node Z error

Matthew Guthaus

09/02/2021, 11:06 PM

Both with version 31a37766

Eric Keiter

09/02/2021, 11:07 PM

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.

Matthew Guthaus

09/02/2021, 11:08 PM

Ok, Jesse got the Verilog-A plugins working for some ReRAM modeling but then this cropped up

Matthew Guthaus

09/02/2021, 11:36 PM

I figured out the Z error. It was a debug thing I added to the library models (or actually somethign I commented out)

Eric Keiter

09/03/2021, 12:21 AM

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.

Eric Keiter

09/03/2021, 12:21 AM

Also, I quickly tried running this in ngspice and it got the same result as Xyce.

Matthew Guthaus

09/03/2021, 2:36 AM

That's interesting... Did you fix the scaling for ngspice?

Matthew Guthaus

09/03/2021, 2:39 AM

.options parser scale=1u vs .option scale=1u

Eric Keiter

09/03/2021, 3:00 PM

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.

Tim Edwards

09/03/2021, 4:59 PM

@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

Matthew Guthaus

09/03/2021, 5:00 PM

facepalm

Matthew Guthaus

09/03/2021, 5:03 PM

@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?

Tim Edwards

09/03/2021, 5:12 PM

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.

Matthew Guthaus

09/03/2021, 5:14 PM

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

Matthew Guthaus

09/03/2021, 5:15 PM

I think that was referring to the fact that he changed the scale back to be compatible with ngspice

Tim Edwards

09/03/2021, 5:18 PM

@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.

Matthew Guthaus

09/03/2021, 5:18 PM

This is just a syntax change, not actually changing the scale.

Matthew Guthaus

09/03/2021, 5:19 PM

".option scale=1u" to ".options parser scale=1u"

Tim Edwards

09/03/2021, 5:19 PM

Oh, I get it.

Matthew Guthaus

09/03/2021, 5:20 PM

We would still get those warnings unless we change the nrd and nrs, but that appears to be harmless.

Tim Edwards

09/03/2021, 5:21 PM

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.

Matthew Guthaus

09/03/2021, 5:22 PM

I agree

Eric Keiter

09/03/2021, 6:02 PM

@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.

Eric Keiter

09/03/2021, 6:03 PM

But, if the ONLY difference between the ngspice files and the Xyce files is this issue, it might be worth doing.

Eric Keiter

09/03/2021, 6:04 PM

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.

Tim Edwards

09/03/2021, 6:05 PM

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.

Tim Edwards

09/03/2021, 6:06 PM

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.

Tim Edwards

09/03/2021, 6:07 PM

It is also a matter of figuring out how to support xyce vs. ngspice when running a simulation from, say, xschem.

Matthew Guthaus

09/03/2021, 6:07 PM

It's included in at least 26 files

Eric Keiter

09/03/2021, 6:07 PM

Ah. Ok then.

Eric Keiter

09/03/2021, 6:07 PM

Regarding the philosophical angle, it is probably not a big deal. Possibly I’m just being pedantic.

Matthew Guthaus

09/03/2021, 6:08 PM

You can't take it back if you add it though, so it's worth debating 🙂

Tim Edwards

09/03/2021, 6:10 PM

My take on it is that

.option

is a legal card in Berkeley spice3, so not supporting it is a serious compatibility issue.

Matthew Guthaus

09/03/2021, 6:10 PM

What are the other things taht can be used with .option?

Eric Keiter

09/03/2021, 6:10 PM

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.

Matthew Guthaus

09/03/2021, 6:11 PM

Oh, all the tolerance things...

🙂 1

Eric Keiter

09/03/2021, 6:12 PM

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.

3 Views

Open in Slack

Previous Next