Resolving .lib control statements in SPICE netlists


Is there a way to load SPICE netlists which include transistor models via .lib statements?

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

sky130.lib.spice contains .include statements in the following form:

* Typical corner (tt)
.lib tt
.include "../a.spice"
.include "../b.spice"

* Slow-Fast corner (sf)
.lib sf


I see that NetlistSpiceReaderDelegate has a method 'control_statement'. However, I don't understand yet how it could be used to load .lib-style includes.

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

    Pg 395

    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 (, but as there is a workaround, I won't give it high priority to be honest.

    Kind regards,


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

    Best regards,


  • 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
    and "blessed").

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

Sign In or Register to comment.