https://open-source-silicon.dev logo
Join Slack
Powered by
Is there a simple example of running Xyce with Sky...
# xyce
c
Is there a simple example of running Xyce with Sky130 models. I saw some issues with including models (issue with relative paths from the invocation directory). I think I am not on the latest version yet, I am on a version older than 7.2 I believe. If needed I can provide my runfiles. Thanks in advance.
m
You need 7.4 for most fixes. The most recent version in git fixes all issues and should just work.
c
Thanks for the Prompt reply Prof. Guthaus. Let me build 7.4.
Running with 7.4 I get error
Copy code
*****
***** Welcome to the Xyce(TM) Parallel Electronic Simulator
*****
***** This is version Xyce Release 7.4-opensource
***** Date: Wed Nov 24 00:32:11 PST 2021


***** Executing netlist gmId.netlist

***** Reading and parsing netlist...
Netlist warning in file
 /home/chandru/Tools/open_pdks/sky130/sky130A/libs.tech/ngspice/all.spice at
 or near line 2
 Unrecognized dot line will be ignored
Netlist error in file
 /home/chandru/Tools/open_pdks/sky130/sky130A/libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_01v8__tt.pm3.spice
 at or near line 31
 Model is required for device MSKY130_FD_PR__NFET_01V8 and no valid model card
 found.
Simulation aborted due to error.  There are 0 MSG_FATAL errors and 1 MSG_ERROR
 errors
*** Xyce Abort ***
Copy code
Netlist
.options nonlin continuation=gmin
.options timeint method=trap
.options device temp=25
.options output initial_interval=1e-8
*.options parser model_binning=true

* Model Includes and Std Cell Includes

.param mc_mm_switch=0
.param mc_pr_switch=0
.lib ../../../Tools/open_pdks/sky130/sky130A/libs.tech/ngspice/sky130.lib.spice tt


.options nonlin continuation=gmin
.options timeint method=trap
.options device temp=25
.options output initial_interval=1e-8
.param kw = 1
.param pvdd = 1.8

* --- Voltage Sources ---
vdd   supply  0 dc 'pvdd'
vsig  vi  0 dc 'pvdd'

** Change W to tfin need to verify
* --- Inverter Subcircuit ---
XM1 supply vi 0 0 sky130_fd_pr__nfet_01v8 L=0.15 W=1

*MM0 supply vi 0 0  nmos_slvt tfin=6.5n l=7n nfin='kw'
*Idd supply drn0 dc 1m
*Rg vi drn0 1m
*Xinv1  vi 1 supply 0 mg_inv
*Xinv2  1 2 supply 0 mg_inv
*Xinv3  2 3 supply 0 mg_inv
*Xinv4  3 4 supply 0 mg_inv
*Xinv5  4 vo supply 0 mg_inv

* --- Transient Analysis ---
*.tran 10n 5u
*.DC vsig 0 1 0.1
.DC kw 1 20 1
*.DC Idd 0 100e-3 0.05e-3
*.print dc v(drn0)
.op
.print dc {N(XM1:GDS)*N(XM1:GM)}
.print dc N(XM1:VTH)
.print dc N(XM1:IDS)
.print dc N(XM1:VDSSAT)
.print dc N(XM1:VGS)
.print dc N(XM1:VDS)
.print dc N(XM1:GDS)
.print dc kw
.print dc N(XM1:CGG)
*.print tran {v(vi)+1} {v(vo)+1}
*comp {v(vi)+1} reltol=1e-2
*comp {v(vo)+1} reltol=1e-2  abstol=1e-5 zerotol=1e-8
.end
m
This needs the version in GitHub just beyond 7.4. there is one more fix that is needed. The line .options scale=x was not supported in 7.4 but added shortly after.
The Xyce way was: .options parser scale=x
But they added support for the other way later
c
Copy code
*****
***** Welcome to the Xyce(TM) Parallel Electronic Simulator
*****
***** This is version Xyce DEVELOPMENT-202111241005-(Public_Release-7.3.0-373-g82a079af)-opensource
***** Date: Wed Nov 24 10:08:34 PST 2021


***** Executing netlist gmId.netlist

***** Reading and parsing netlist...
Netlist error: Cannot convert 'x' to double for expression SCALE
Netlist error in file gmId.netlist at or near line 28
 Model is required for device M1 and no valid model card found.
Simulation aborted due to error.  There are 0 MSG_FATAL errors and 2 MSG_ERROR
 errors
*** Xyce Abort ***
This was with the build from github master
I did both .options parser scale=x and .options scale=x
Ok I think I get it to work without the scale options and the gitbuh binary. Some other commands like print dc N(XM1:VTH) are erroring out now. Confusing.
m
I see. Both may work when one isn't recognized... But you need the scale or the models will be wrong. It isn't easily removable.
Xyce likely uses a different syntax for printing.. what is N()?
c
Professor, Can you clarify the scale comment ? The .print command need the full name of the instance XM1:<NAME OF MOS>:VTH
N is the printing of the parameters of a device I believe, not node V or I
so .print dc N(XM1&lt;NAME&gt;<PARAM_NAME>) seems to be working .options parser scale=x doesnt work at all.
This is the definition for the scale in the release notes. So this is for scaling of dependent parameter
so then x has to be a numeric value right ? What is that value for sky130 ? Any ideas?
I verified that with a scale of 1 the sims work.
m
Work, but probably not correct. The scale is baked into all of the models and cannot easily be changed. I've not printed spice parameters in Xyce, just voltage and current, so I'm not sure what the correct way is...
c
Understood, I will see if there is documentation of mos characteristics to compare this to.
e
Hi @User sorry I didn’t reply when this was first posted. I’ll try to add a few comments here.
@User is correct that if a PDK is using “scale” then you can’t ignore it. It has to be included to be correct. Xyce’s original syntax was 
.options parser scale
but the most recent versions have been adapted to also support the more standard 
.option scale
. Note that for this more standard syntax the word 
option
is not plural.
Regarding the use of “x” on the .option scale line. This can probably be fixed, up to a point. By default, .options statements in Xyce do not support parameter inputs. But, there are cases in which it is allowed. One just has to code exceptions into the parser. The main reason that it isn’t allowed by default is that once .options statements have been processed in Xyce (during parsing) they aren’t ever re-parsed. And, people often want to use parameters to treat something as a variable. So, for example, if you had:
Copy code
.param foo=1.0e-6 
.option scale=foo
.step foo list 1.0e-6 2.0e-6 3.0e-6
then Xyce would run the circuit 3 times, with a different value of 
foo
each time. But, since (currently) the value for scale is only applied during parsing, it would not properly update the value on the 2nd and 3rd 
.STEP
iterations.
The quickest change to allow parameters on the .option scale line would not address the 
.STEP
problem I just mentioned. But outside of that issue, it would not be hard to make that change in the parser.
Regarding the 
N()
output, that has been our 
.PRINT
line syntax for outputting internal device variables including (sometimes) device parameters. Currently, it doesn’t support as many internal device variables as we’d like it to. So, depending on what you are trying to output you might run into limitations. But it looks like it is working for you. It can be tricky to use for devices that are deep inside of subcircuit hierarchies, as you have to fully resolve the name.
14 Views
Open in Slack
PreviousNext
Powered by