LVS with empty cells

acsacs
edited January 18 in KLayout Support

Hi everybody,
I'm new to this forum and I've, lets say, some experience with EDA tools
but not with klayout, which turns me again into a complete novice. Hope you've still some patience left ..

I tried for a while now, but attached LVS still makes problems.
Both of Klayout 0.26.9 (compiled form source) and Klayout 0.26.2 (from the Debian repos) are showing the same
behavior -- they are running forever when it comes to the "compare" line.

A.) It would be nice, if someone with a deeper insight could have a closer look. Thanks ..

3 additional short questions
B.) I wonder if the LVS-script could also be done in python?
C.) is it possible to stop a long (or forever) running script in klayout without killing the main process?
D.) Is there a feature in klayout (or maybe it is already planned), which could adapt the extracted netlist in a way, so that "netgen" can be used as an second check (2 pair of eyes ..)

thanks in advance

Comments

  • Hi,

    thanks for the test case. I'll take a look.

    Regarding your questions:

    B. I don't want to maintain two ecosystems. One is already enough effort. And Ruby is better suited for a DSL, so no Python from my side. But the core API is available in Python too.
    C. Not currently. That would be a separate process. But you can run KLayout in batch mode and send it into some batch queue, like you do with any other EDA tool.
    D. You can export SPICE, but I have no experience with netgen, so I can't say what the requirements are.

    In general, there is some advance on the LVS code. You might want to compile the master from GitHub to try the recent code. Reports are better and some bugs are fixed. I hope I can release that version soon.

    Kind regards,

    Matthias

  • edited January 24

    @acs Thanks for your nice testcase ... it was pretty simple to debug the issue.

    It's actually a stupid bug. The compare algorithm sometimes enters an infinite loop when it encounters a case of two topologically equivalent (i.e. entirely parallel) subcircuits. None of my tests covered this case so far.

    It will be easy to fix. May I include your testcase in the test suite or do you claim copyright?

    Thanks,

    Matthias

  • @Matthias: no problem .. no copyright ;)

    ad D) when I'll get some experience, too, I will try to elaborate. But for now the simplest case: netgen assumes a top-netlist, means, the top subcircuit/cell needs to be called.

    X1 <nets> <if> <any> topcell
    

    Sometimes a spice netlist ends with ".end". Not sure if this is standard or not.

  • OK, so I must ask (in lieu of reading deeply for my
    own edification): does LVS include a "permute
    parallel" ability, with rules by device-type, and is
    it only stymied by the "parallel elements" being
    under hierarchy? If yes, does that mean a flat
    netlist might play better? And would trying that
    out (presuming you can get a flat netlist) be a
    debug angle?

  • Hi Jim,

    I had to look up "stymied" in a dictionary first (I'm not a native speaker), but I hope I understand your question now :)

    First of all, I need to say that the LVS compare algorithm made some progress in the 0.27 which I am currently preparing. So in the current 0.26.x, some of what I say may not fully apply.

    But the idea in general is this: The netlist compare algorithm is agnostic. This means it tries to work only with equivalences which a strictly established. When there is parallelism or symmetry, the parallel elements care considered to be equivalent and the netlist compare algorithm tries to work through the possible combinations to find a solution.

    For example, if a subcircuit consists of parallel identical blocks (e.g. a bank of level shifters) the corresponding pins should become swappable indicating that the blocks are equivalent. This analysis is based on topological equivalence and I think this works decently for small circuits.

    So to answer your question: flattening of a netlist should not significantly improve the quality of the compare, because the parallelism should be considered even in a hierarchy by means of swappable pins. And the compare algorithm is basically a backtracking algorithm. In case of parallelism this algorithm tries the possible combinations but limits the search depth to avoid combinational explosion. With a lot of parallelism, the algorithm may stop trying too early and the compare may not yield. This is more likely in a flat netlist, so I'd try to preserve the hierarchy if possible.

    There are cases when parallelism is present logically, but not physically. A CMOS NAND gate for example logically has two equivalent inputs while topologically they are different because the serial transistors are not equivalent (only one is attached to supply). In this case, you can declare the inputs pins as swappable in the LVS deck.

    Sometimes you may want to tie parallel instances to certain nets to give the compare algorithm some hint. In this case, labels can help to establish a fixed assignment and the compare algorithm does not have to try a lot of combinations.

    I hope this explains that a little. There are some more details here: https://www.klayout.de/doc-qt5/manual/lvs_compare.html

    Best regards,

    Matthias

  • I was thinking more of a common CMOS case where
    "a" FET is made up of multiple gate stripes, and in some
    PDKs each gate-stripe is extracted as its own device,
    while schematic shows only one; the layout might have
    (say) four stripes. "permute parallel" (this is how I saw
    it called, in "Brand C") asserts equivalence between
    (4) totally-parallel single-gate-stripe extracted FETs,
    and (1) 4-finger FET in the schematic netlist.

    Similarly there is "permute serial" which would call
    (say) a layout resistor made of (10) 1K segments in
    series, and a single 10K schematic resistor instance.

    I have seen this controlled specifically per library
    device, along with whether terminals can swap (like
    a low voltage non-extended MOSFET can swap S, D
    schematic terminals, but an extended-drain or LDMOS
    cannot (breakdown asymmetry, source resistance, etc.).

    There must be some sort of intermediate "netlist
    reduction" pass, I imagine, whether observable or hidden.
    Else the core algorithm would have a lot more balls to
    juggle, all the way through the comparison?

  • edited February 5

    I see .. anyway, I hope the previous answer wasn't wasted :)

    Yes, there is such a netlist reduction step. It's called "device combination". It's described here: https://www.klayout.de/doc-qt5/manual/lvs_tweaks.html.

    I introduced the "DMOS" device to described asymmetric MOS devices. Sorry for the name, but I picked it because that asymmetry to my knowledge is common in all kind of power devices and DMOS sounded representative ("PMOS" would be much more misleading and "AMOS" sounded ugly).

    From the schematic point of view, "DMOS" is simply the same as MOS. From the extraction point of view, source and drain can be represented by different regions and the device's S and D terminals will not swap.

    Best regards,

    Matthias

Sign In or Register to comment.