https://open-source-silicon.dev logo
Join Slack
Powered by
<@U01H2JMLFLL> : Also you should be extracting bo...
# magic
t
@User : Also you should be extracting both layout and schematic as subcircuits, with a pin list. Make sure you are defining ports on your top level layout. Do not flatten the layout.
t
Does flattening break the LVS process?
t
These comments are less critical. I took your two netlists, ran them through netgen, and got a match. Use a script like the one below ("run_lvs.sh" when unzipped):
run_lvs.zip
No, flattening does not break the LVS process, it just makes it harder to understand what went wrong if the circuits don't match.
Based on your posted magicrc file, change 
/usr/share/pdk/
in the example batch script to 
/home/tom/pdks/
and it should work for you.
Okay, never mind that, I was not paying attention but I am seeing the same output with the strange dump of parameters with a property mismatch error. I will take a look at what's going on.
t
Ah - ok! Thanks, Tim
t
Actually I am very suspicious about a change I made to netgen. If you could, please, try rolling back netgen to revision, say, 175, and see if it works. It seems like netgen lost track of the ordering of parameters, which is exactly what my recent code change was messing with (except it was supposed to fix something, not break it. . . ).
t
Trying it now, Tim
That's interesting, the results are different: Originally I was using
Copy code
Netgen 1.5.177 compiled on Thu 20 May 2021 10:18:32 PM PDT
When I try 
Netgen 1.5.175 compiled on Thu 17 Jun 2021 02:53:20 PM PDT
I get the attached. It's still broken in what looks like the same place but the report is a little different:
Copy code
Flattening unmatched subcell ldo_amp in circuit user_analog_project_wrapper_lvssch.spice (1)(1 instance)
Equate elements:  no current cell.
Equate elements:  no current cell.
Class user_analog_project_wrapper_lvsmag.spice:  Merged 49 devices.
Class user_analog_project_wrapper_lvssch.spice:  Merged 2 devices.

Subcircuit summary:
Circuit 1: user_analog_project_wrapper_lvs |Circuit 2: user_analog_project_wrapper_lvs 
-------------------------------------------|-------------------------------------------
sky130_fd_pr__pfet_g5v0d10v5 (3)           |sky130_fd_pr__pfet_g5v0d10v5 (3)           
sky130_fd_pr__nfet_g5v0d10v5 (4)           |sky130_fd_pr__nfet_g5v0d10v5 (4)           
Number of devices: 7                       |Number of devices: 7                       
Number of nets: 5                          |Number of nets: 5                          
---------------------------------------------------------------------------------------
Circuits match uniquely.
Property errors were found.
Netlists match uniquely.
There were property errors.
sky130_fd_pr__nfet_g5v0d10v54 vs. ldo_ampI2/sky130_fd_pr__nfet_g5v0d10v5M9:
 w circuit1: 108   circuit2: 24   (delta=127%, cutoff=1%)
Cells have no pins;  pin matching not needed.
Device classes user_analog_project_wrapper_lvsmag.spice and user_analog_project_wrapper_lvssch.spice are equivalent.
Circuits match uniquely.
Property errors were found.
The following cells had property errors: user_analog_project_wrapper_lvsmag.spice
user_analog_project_wrapper_lvssch.spicelvs_report.loguser_analog_project_wrapper_lvsmag.spice
Did that info. Help at all, @Tim Edwards?
@Tim Edwards going back to what you were saying about flattening - I've run into numerous issues with magic getting confused with references to cells which aren't in the same folder as the parent layout. I probably should have just put everything in the same folder for simplicity but I didn't like that approach much. As such, I have a separate folder for each sub design in which there are 
sch
and 
lay
folders. I've found that when I instantiate layouts from one block in another the tool gets confused occasionally, and so what I'm now doing is hardening each sub design into a flattened 
.mag
file once it's LVS and DRC clean, so I can copy them into the wrapper folder. This seems to get around those issues but it does of course mean that for LVS at the top level it's unable to resolve into the hierarchy of the sub designs I tried instantiating the non flattened 
ldo_amp
in the wrapper but then I get 
File /home/tom/repos/mpw2-columbus-a0/columbus/ip/top/lay/../../ldo/lay/ldo_amp_b.mag couldn't be read
even after saving (the cell is just called 
ldo_amp
, I don't know why it needs to append the 
_b
). Manually editing the mag file to remove the 
_b
from the name at least enables it to find the file but the report is not much more helpful from what I can tell. It's attached. Also - If I instantiate my flattened 
ldo_amp
in the wrapper it passes LVS but faild pin matching. Is there a way to supress labels but preserve port names when flattening?
user_analog_project_wrapper_lvsmag.spicelvs_report.loguser_analog_project_wrapper_lvssch.spice
t
Well, what I've determined from the original output is that it looks like a false positive error for property matching. The output is kind of messy, but what it boils down to is that netgen says it has a device with W = 108, L = 1, M =1 on one side, and on the other side one device with W = 12, L = 1, M =1 in parallel with another device W = 96, L = 1, M =1. Clearly all lengths are the same, so it should combine simply by adding Ws, and 96 + 12 = 108, so your circuit is fine and I need to dig down and figure out why it is that netgen failed to add the Ws together.
t
Ok thanks, Tim that's a big relief. Do you suggest I continue using 
Netgen 1.5.175
for now?
user_analog_project_wrapper_lvsmag.spice,user_analog_project_wrapper_lvssch.spice,lvs_report.log
lvs_report.loguser_analog_project_wrapper_lvssch.spiceuser_analog_project_wrapper_lvsmag.spice
user_analog_project_wrapper_lvsmag.spice,user_analog_project_wrapper_lvssch.spice,lvs_report.log
lvs_report.loguser_analog_project_wrapper_lvssch.spiceuser_analog_project_wrapper_lvsmag.spice
t
(1) For the problem above: The proper way to run LVS is to make sure that both circuits declare a top level subcircuit. Your layout-extract netlist now does that. You should probably just remove the comments from the subcircuit line at the top of the schematic captured netlist. When you have a subcircuit wrapper around the top level, though, you need to pass each netlist to netgen as a pair "<filename> <cellname>" so that it knows not only what file to read, but what subcircuit is the topmost subcircuit to compare. (2) I am still working on the original problem with the property mismatch. It appears to be a fairly simple problem in the property matching algorithm. I think I should have it fixed tomorrow.
t
Thank you, Tim. I'm going to try to get my LVS flow setup in the way you suggest with subckt wrappers and passing the file cell name pairs. Does netgen care about the pin ordering on the subckt declarations?
t
No, netgen will figure out how the ordering of pins in one netlist matches the other, and keep track of it.
t
👍
@Tim Edwards, thank you for your pointers on how I should be running LVS the correct way. I've made all the changes you suggested and am now running netgen like this 
netgen -batch lvs "${CELL_NAME}_lvsmag.spice $CELL_NAME" "${CELL_NAME}_lvssch.spice $CELL_NAME" $PDK_ROOT/libs.tech/netgen/sky130A_setup.tcl lvs_report.log
on NON flattened designs and everything is looking good (not tried the top yet) except the previously passing BGR. netgen is now core dumping only on the BGR sub design which is LVS clean according to previous runs.
Copy code
/home/tom/repos/mpw2-columbus-a0/columbus/lvs.sh: line 97: 2118548 Segmentation fault      (core dumped) netgen -batch lvs "${CELL_NAME}_lvsmag.spice $CELL_NAME" "${CELL_NAME}_lvssch.spice $CELL_NAME" $PDK_ROOT/libs.tech/netgen/sky130A_setup.tcl lvs_report.log
I'm using netgen commit# 
6a555ad6edd1e57421b533bffb38ffa7db5fc0ea
(TOT). Line 97 of lvs.sh is the netgen call. I've attached the netlists causing the crash, and the terminal output 
log
. Please let me know if I can provide any additional info. The BGR is the largest sub design but I've not had netgen coredump on me before now. The cell name for both the layout and schematic are bgr_top
bgr_top_lvsmag.spicelogbgr_top_lvssch.spicelvs.sh
t
@Tom: netgen 
commit c4f03eabaf86e8eb341154ba4bc11c1d79eaacdd
on opencircuitdesign.com fixes the crash condition.
t
Great! Trying it now. Thanks
Alarmingly this version of netgen is failing one of my sub designs which was passing with the older versions
specifically the bgr - the one causing the core dump
@Tim Edwards, did you get round to fixing the magic extraction routine that was causing my BGR LVS to fail?
t
I fixed the crash condition, but the cell does not extract correctly due to labels being a combination of lines (no area to the label), on the edge of the cell, and not attached to any layer inside the cell where they exist. The problem can be resolved by using the (undocumented!) command option 
extract do labelcheck
. I still have the window up where I was working on this, and before I got sucked into other emergencies, I was considering whether the 
do labelcheck
option ought to be a default option, or not an option at all. But at least using it resolves the issue with your circuit.
t
Ok thank you @Tim Edwards. Are there any circumstances where you wouldn't want to 
do labelcheck
?
7 Views
Open in Slack
PreviousNext
Powered by