It looks like you're new here. If you want to get involved, click one of these buttons!
Hi!
I try to add an automated LVS check into the librecell
standard-cell layout generator. Netlist extraction works fine but I don't manage to compare the reference netlist and extracted netlist the way I want.
For now I use this function to make the comparison. It is obviously not yet what I want.
def compare_netlist(extracted: db.Netlist, reference: db.Netlist) -> bool:
"""
Check if two netlists are equal.
:param extracted:
:param reference:
:return: Returns True iff the two netlists are equivalent.
"""
cmp = db.NetlistComparer()
cmp.same_device_classes(db.DeviceClassMOS3Transistor(), db.DeviceClassMOS4Transistor())
compare_result = cmp.compare(extracted, reference)
logger.info("Netlist comparision result: {}".format(compare_result))
if not compare_result:
logger.warning("Netlists don't match.")
print('extracted netlist:')
print(extracted)
print('reference netlist:')
print(reference)
return compare_result
Now I get this output:
2020-02-20 11:40:42 lvs INFO: Netlist comparision result: False
2020-02-20 11:40:42 lvs WARNING: Netlists don't match.
extracted netlist:
circuit INVX1 (A=A,gnd=gnd,Y=Y,vdd=vdd);
device PMOS $1 (S=Y,G=A,D=vdd) (L=0.05,W=0.5,AS=0.1125,AD=0.115,PS=1.45,PD=1.5);
device NMOS $2 (S=gnd,G=A,D=Y) (L=0.05,W=0.25,AS=0.05875,AD=0.05875,PS=1,PD=1);
end;
reference netlist:
circuit INVX1 (A=A,Y=Y,VDD=VDD,GND=GND);
device PMOS '0' (S=Y,G=A,D=VDD,B=VDD) (L=0.05,W=0.5,AS=0,AD=0,PS=0,PD=0);
device NMOS '1' (S=Y,G=A,D=GND,B=GND) (L=0.05,W=0.25,AS=0,AD=0,PS=0,PD=0);
end;
The two netlists have the same topology of transistors but are not exactly the same. The reference is made up of 4-terminal MOS transistors whereas the layout actually only has 3-terminal transistors. The forth terminal comes from the well-tap cells and is therefore not visible in the layout.
So in the above case the comparison says "not the same netlist" but I want it to treat this netlists as equivalent.
My question: Can I tell the netlist comparer to just ignore the fourth terminal?
Thanks a lot in advance!
Comments
Hi Thomas,
unfortunately not directly as MOS3 and MOS4 are different devices and basically the forth terminal is part of the functional description. Imagine it's tied to the wrong potential - in this case the transistor would not work.
The "same device classes" feature is to map different incarnations of MOS3 or MOS4 between schematic and layout, but cannot map MOS3 to MOS4 as these are different fundamental types.
But it's possible to tell the Spice reader to read M devices as MOS3. The key concept is the "Spice reader delegate". It's explained here: https://www.klayout.de/doc-qt5/manual/lvs_io.html
This is the code in your case:
Best regards,
Matthias
Thank you so much Matthias! Worked out of the box.
In case somebody also needs it for Python:
Thanks! But I still love Ruby
Just one remark regarding this solution: the code above does not take the "M" parameter into account. For a fully compatible Spice reader, the code should read "M" as well and multiply W with M. Not a big change, but sometimes this may be important.
Internally, KLayout does not use "M". Instead, only the total width of the transistor is used.
Best regards,
Matthias
For analog circuits where matching is an interest, it would be better to check explicitly all three params (W, L, M) because edge effects make W=2 M=1 different than W=1 M=2 depending on lithography. There are also capacitance concerns for the RF folks (Cdb varies by factor of 2 or so). While gross function / connectivity may be satisfied, LVS has additional roles (like enforcing schematic intent beyond just the hookup).
Hi Jim,
true ... I just don't know how to tell apart digital from analog designers in my code (popup: "are you a digital guy?", answers: "yes", "no" and "don't care")
I just introduced "tolerances". Maybe it's possible to extract "M" and give it a 100% tolerance by default. So by default it's not checked. And if you want, you could set the tolerance.
BTW: KLayout also extracts AD,SD,PD and PS, but I can't imagine it makes sense to check this too. The idea was originally that having these values would allow a simulator to pick a somewhat better model, but before this happens, I think parasitics need to be included in the extraction.
Best regards,
Matthias