merge 2 kinds of resistors after extraction (netlist.simplify)

edited March 22 in KLayout Support

Hi,

In my layouts, I have several types of resistors : poly, poly_without_salicide, nwell, metal1, metal2, ...
For the LVS, I use :

    same_device_classes("HIPOLY_RES", "RES")
    same_device_classes("NWELL_RES", "RES")
    same_device_classes("RMetal1", "RES")
    same_device_classes("RMetal2", "RES")

But the resistors in parrallel, or in series are not merged and the LVS fails.
Any tricks to solve that LSV issue ?

Thank you, BRgds,
Laurent

Comments

  • This would be an improper use of "merge devices".
    They are -not- the same device. They all have different
    tolerances, as-shot values, tempcos.

    You should represent them as they are laid out, in the
    schematic. "Merging" is just a little cleanup of too-busy
    schematic representation. It isn't supposed to be a mind
    reader or "make stuff up".

    Now your series / parallel is maybe another question.
    Those rules are not the _classes definition you show.
    There is a "netlist.combine_devices" and fellow travelers.
    Look at the "LVS Netlist Tweaks" stuff in the LVS manual?
    But combining may (?) still fail if device segments are not
    matched in type or geometry params?

  • You are right : the best is to specify the type of device in the netlist.
    The syntax is obvious for active devices, but what is the correct syntax for a resistor ?
    Thank you,
    Laurent

  • Hi Laurent,

    good question :)

    I am trying to follow the ngspice conventions. If I got the ngspice doc right, here are the variants:

    Rname n1 n2 value
    Rname n1 n2 value model [params]
    Rname n1 n2 model [params]
    

    The third variant is used, if "value" obviously isn't a value (like "1.5k") or indicates a formula (starting with a "("). But in this case, no value is provided, so it's hardly usable.

    BTW, the same applies to "C".

    Best regards and stay healthy,

    Matthias

  • edited March 25

    Thank you Mathias, but I tried it and it does not work.

    The test case is fairly simple : connect 2 or 3 metals (M1, M2 ,M3) in series with proper vias and use a resistor marker :
    RM1 = M1 & ResMkr
    RM2 = M2 & ResMkr
    RM3 = M3 & ResMkr

    Then make the LVS with 3 resistors in series in the netlist :
    R1 1 2 0.01 RM1
    R2 2 3 0.01 RM2
    R3 3 4 0.01 RM3

    You can adjust the values after netlist comparison and may be change the netlist order ...

    BRgds,
    Laurent

  • edited March 25

    Hi, Laurent!

    Are RM1, RM2 and RM3 models? If so, you should have related .MODEL statements in your netlist. Otherwise they should be comments ($layer=RM1, etc) as extractor tools does for layout-related parameters.

    You could also Google for HSpice User's Manual. SPICE netlist syntax is described very well there.

  • Hi Laurent,

    A first attempt to verify this actually leaves me with a working case :(

    Here is my Spice nelist:

    .subckt TOP
    R1 1 2 100 M1
    R2 2 3 200 M2
    R3 3 4 50 M3
    .ends
    

    The LVS script is this:

    deep
    verbose
    
    source("layout.gds")
    
    target_netlist("extracted.cir")
    schematic("reference.cir")
    report_lvs("compare.lvsdb")
    
    m1 = input(1, 0)
    v1 = input(2, 0)
    m2 = input(3, 0)
    v2 = input(4, 0)
    m3 = input(5, 0)
    rm1 = input(10, 0)
    rm2 = input(11, 0)
    rm3 = input(12, 0)
    
    m1_res = m1 & rm1
    m2_res = m2 & rm2
    m3_res = m3 & rm3
    
    m1_wire = m1 - rm1
    m2_wire = m2 - rm2
    m3_wire = m3 - rm3
    
    extract_devices(resistor("M1", 50.0), { "R" => m1_res, "C" => m1_wire })
    extract_devices(resistor("M2", 100.0), { "R" => m2_res, "C" => m2_wire })
    extract_devices(resistor("M3", 25.0), { "R" => m3_res, "C" => m3_wire })
    
    connect(m1_wire, v1)
    connect(v1, m2_wire)
    connect(m2_wire, v2)
    connect(v2, m3_wire)
    
    netlist
    if compare
      puts "SUCCESS: netlists match!"
    else
      raise("ERROR: netlists don't match!")
    end
    

    I have attached the testcase.

    What is different in your case?

    Matthias

  • edited April 2

    Thank you Matthias,

    I found out my mistake, I tried to solved it having general resistors (and sometimes I have them) :

        same_device_classes("M1", "RES")
        same_device_classes("M2", "RES")
        same_device_classes("M3", "RES")
    

    ... but it does not work :/.
    I solved it by the solution you suggested me for transistors where I had the same kind of issue :

        same_device_classes("M1", "RES")
        same_device_classes("M1", "M1")
        same_device_classes("M2", "RES")
        same_device_classes("M2", "M2")
        same_device_classes("M3", "RES")
        same_device_classes("M3", "M3")
    

    ... and it works B).
    Now, M1 (resp. M2, M3) can be match to unknown type resistor or to M1 type (resp M2, M3).
    But if 2 types are in series, the type must be specified.

    BRgds,
    Laurent

  • Hi Laurent,

    That's already halfway good :)

    Device combination happens within a single device class currently, so the equivalence isn't seen. Maybe it's possible to generalize this. I just don't know if it's possible to predict the class which will be the outcome of such a combination. So M1 + RES might become M1 or RES unpredictably.

    Best regards,

    Matthias

Sign In or Register to comment.