It looks like you're new here. If you want to get involved, click one of these buttons!
Is there a way to load SPICE netlists which include transistor models via
The characterization tool lctime (Python) uses KLayout for parsing and analyzing spice netlists. That worked quite well for simple netlists. However, things seem to be more complicated as soon as
.lib control statements are used to include transistor models. KLayout ignores control statements.
In the following example the
.lib statement is skipped and therefore the transistor models will not be found.
.lib "/XYZ/sky130/skywater-pdk-libs-sky130_fd_pr/models/sky130.lib.spice" tt .subckt thesis_inv A Y VPWR VGND X0 Y.t1 A.t0 VPWR.t1 VPWR.t0 sky130_fd_pr__pfet_01v8 ad=1.25045 pd=6.51 as=1.2364 ps=6.5 w=2.81 l=0.15 X1 Y.t0 A.t1 VGND.t0 VGND sky130_fd_pr__nfet_01v8 ad=0.3916 pd=2.65 as=0.3872 ps=2.64 w=0.88 l=0.15 .ends
.include statements in the following form:
* Typical corner (tt) .lib tt .include "../a.spice" .include "../b.spice" .endl * Slow-Fast corner (sf) .lib sf *... .endl *...
I see that NetlistSpiceReaderDelegate has a method 'control_statement'. However, I don't understand yet how it could be used to load
I'd appreciate any hints!
Thanks & best regards
I don't know about netlist import here, but if you use
ngspice there are args to the 'listing' command which
can put you out a fully expanded netlist, even as far
as turning any variables into numerical values (like in
case you left a FET's W as a SPICE variable by some
the listing r command will save the expanded netlist
(all parameters evaluated, subcircuits flattened, .control sections removed) into a file
within the same directory.
So you could use ngspice as a "preprocessor" if you like.
Depending on how the include-chain and model hierarchies
are assembled, you might like to maintain a stripped down
model tree for LVS (esp. if subcircuits contain more than
just the MOSFET they represent - your extract might not,
for example, pick up an explicit well-sub diode or D-B
diode meant to emulate breakdown or the added parasitic
inductances of a RF CMOS model, etc.
But you won't see that until the first layer gets peeled.
Thank you, using ngspice as a pre-processor is a useful alternative!
@dick_freebird Thank you for this hint. I did know this either.
It may be possible to use a SpiceReaderDelegate to implement this feature, but in general I'd like to support SPICE natively if possible. Although I fixed a number of issues recently (like supporting parametric circuits), still a lot of details are not entirely clear to me.
I understand the .lib feature to be some kind of conditional include, right?
I have created a ticket for this feature (https://github.com/KLayout/klayout/issues/new), but as there is a workaround, I won't give it high priority to be honest.
In my opinion a "parametric" circuit is not verifiable because
it's not "done" - it's subject to change until all variables have
become fixed. I don't know that this is something worth
trying to support. Maybe just as far as connectivity with any
variables left to fall out the "parameter mismatch" chute.
The ngspice "preprocessed" listing which spits out a fully flat,
fully floating point (no text variables) netlist would be verifiable
because it's fixed and frozen (hopefully the same, and same
values, apply to the layout).
I don't much use .lib myself but see it used often in PDKs
I get from other people.
It's kind of a ".include bundle, with logic" in that you can
assert some gangwise (process) model collections by a
passed-in argument, from among multiple options in one
big (.lib) file. The sections each replace some gang of
include and control statements, times N "conditions".
Seems that sort of organization appeals to folks who have to
maintain a large models & params pile.
@dick_freebird Thanks for these insights.
I found some cases, where parametrized circuits are used to wrap devices - passing down the parameters to the actual "M" elements for example after manipulation. These parametric cells are never top level ones of course, but when they are embedded in a circuit, KLayout needs to understand how to read them. That's why this topic came into play.
Yes, I often see subcircuits "wrapping" a MOSFET core
element - RF CMOS, see Rg, Ls, Ld added external to
the intrinsic FET; ESD GGNMOS clamps work a lot more
realistically when you add a breakdown element that
BSIM lacks (trivial D model w/ BV, RS and IBV).
But you should not, and should not be expected to
"verify" elements which are either nonphysical or
behavioral enhancements without added physical
feature. Why and how would you verify that a diode
buried in such a subcircuit "wrapper" is present
(it's omnipresent) or hooked up (it's always hooked up)?
This is where the "Fuggedaboudit, just keep two sets
of books" is your leverage. There's the one set of models
you may get from the foundry, with all that hierarchy.
But you don't get to use the "side reps" that a Big Iron
CAD system employs, to steer netlist evaluation. So
take the foundry models stack, and remove from every
model subcircuit every element besides what corresponds
to the schematic element (Mxxx) and fix any connectivity
broken by deleting "not to verify" devices (might recommend
doing this by commenting, so your trail can be inspected
Now despite being buried in subcircuits there should be a
1:1 matchup with no pruning.
A foundry I work with, is set up this way (they use Tanner
which is halfway between Big Iron and loose point tools).
It works. It is relatively maintainable, an orderly editing
process of N files at most. But you have to sell anything
you create yourself, to the foundry if you are looking to
grease the tape-in. So simple is good. And you can't get
much simpler than "deleting any problems".