Deep Verification Base: SPICE output

I'm playing around with the new DVB. Sofar I could extract a netlist of a small hand-drawn design and now I would like to verify my design by simulation with ngspice.
@Matthias Is there already some script around for converting the netlist into SPICE format?
Otherwise I will start working on it :wink:

Comments

  • Hi Tok,

    Is this something that you plan to share with the larger community? I would be interested in learning more.

    Thanks,

    VikasG

  • Yes I can share it. But don't expect too much. In the first step I will just care about three-terminal transistors and dump them to SPICE.
    I will post it here when I have something that works more or less.

  • I put it in the package repo as a python library. It's called 'spicex'. Note: currently you will need to build KLayout from the 'dvb' branch.

  • Documentation and code is here: https://codeberg.org/tok/spicex

  • Hi tok,

    Thanks for providing this package. I'm excited to see you're already aboard. On the other hand I'm a bit worried as there are many bugs yet to discover ...

    I have just pushed a commit that adds a SPICE writer in C++. It's configurable through a delegate, although the Python netlist writer still makes sense as it will be more flexible. So thanks for the package and please keep it.

    Regards,

    Matthias

  • Don't worry about the bugs. I'm aware that this is work in progress.
    I just used DVB to extract the netlist of a small hand-drawn design for SPICE simulation and verification. DVB helped me to find bugs in my own design ;)

    What about netlist comparison? I think it could be done in Python. There are some libraries around for graph isomorphism problems which could be used. However, I don't know what algorithms are usually used for LVS.
    The thing I'm not sure about yet is how to handle differences in the netlists.
    Does the DVB API allow to retrieve locations of devices and nets from the netlist? This would be helpful in order to highlight mismatches.

  • Hi Thomas,

    yes, the idea of the "LayoutToNetlist" API is to deliver geometry information along with the nets. The methods provided currently are "shapes_of_net" for flat output and "build_net"/"build_all_nets" for hierarchical output into a new layout. This was the first I could come up with.

    The LayoutToNetlist can be persisted into the internal format using read/write, but that's is not quite efficient and not standardized. Others use annotated GDS/SPICE combination and there probably are more options.

    I think that netlist vs. netlist compare usually is implemented with a bracktracking algorithm starting with known identities (labelled nets or explicitly specified identity). There is an important degree of freedom that breaks true isomorphy: the inputs of most gates (like NAND, NOR, AND ...) can be swapped even though that is not truely isomorphic (the serial transistors are actually ordered). This freedom is something a netlist vs. netlist algorithm has to provide.

    The Netlist class already provides device combination: a fingered transistor will be extracted as multiple transistors. As a device in the schematic it's just one. The corresponding method is Netlist#combine_devices.

    Best regards,

    Matthias

Sign In or Register to comment.