Channels
#openlane
Title
a
Ahmed Ghazy
07/27/2020, 2:08 PM@User: I will quote @User on that:
This is a known issue. . . It has found symmetries and is trying to resolve them with some very badly written method. For all practical purposes, it is done, and the circuit is LVS clean.
📝 2
u
20Mhz
07/27/2020, 2:09 PMwonder if there is a recommended way to break out and continue from next step.
a
Ahmed Ghazy
07/27/2020, 3:59 PMProbably can catch SIGINT and just return instead of exiting, but there are situations where it is desireable to kill the whole thing. I will look into that.
u
20Mhz
07/27/2020, 4:14 PMsounds good, although there may be useful to add functionally to start from specific step, alternatively, I need to continue interactively after this. thanks
Finished after 4.5 hrs, not that bad
Copy code
LVS Done.
LVS reports:
net count difference = 0
device count difference = 0
unmatched nets = 0
unmatched devices = 0
unmatched pins = 2
property failures = 0
Total errors = 2 Copy code
(no matching pin) |VPWR
(no matching pin) |VGNDa
Ahmed Ghazy
07/27/2020, 6:28 PMYea, if you wait long enough, it will finish... Not that it doesn't need to be optimized in netgen...
👍 1
The above unmatched pins are expected (got fixed/worked-around in https://github.com/RTimothyEdwards/open_pdks/blob/6d85172cb41bb9fcb5f113847de6ddeacc405fd9/sky130/openlane/common_pdn.tcl#L2), so should get merged soon to the original repo.
It's because the power pins are named differently (VDD, GND vs. VPWR, VGND). However, @Tim Edwards mentioned somewhen that netgen should be able to match differently named pins, so it's potentially a bug?
u
20Mhz
07/27/2020, 6:32 PMgot it, thanks!
t
Tim Edwards
07/27/2020, 6:43 PM@Ahmed Ghazy: If the pins are named differently, then netgen should match them. If it has not matched them, it likely means that they are on the wrong layer in the layout, such as might happen if the pins are overlapping a via and have not been set with the "sticky" flag to force them to remain on a specific layer.
@Ahmed Ghazy: Still, it raises the question: If your tool is generating both the netlists being compared, then why would you not set the names of the power pins to be the same in both?
@20Mhz: The issue with netgen taking so long on the symmetry breaking is clearly a bug and just needs to be tracked down and fixed. I have given it low priority because once I've hit that point, I know the LVS is done and correct.
@20Mhz: Also, "4.5 hrs, not that bad" is a strange sentiment. I was expecting something more along the lines of "4.5 hrs, when are you going to fix this horribly broken thing?".
🤣 3
u
20Mhz
07/27/2020, 6:53 PMI still don’t get a notion of how this scale, we’ll see
t
Tim Edwards
07/27/2020, 7:34 PM@20Mhz: Netgen itself scales quite well. It's just that one part at the end with symmetry breaking that for a reason that I have not yet investigated appears to be exponential with design size.
t
tnt
07/27/2020, 8:00 PM@Tim Edwards I guess I'm also used to long Xilinx synthesis and PnR runs ... or 24h modelsim simulations ...
a
Ahmed Ghazy
07/27/2020, 9:39 PM@Tim Edwards: This was fixed in the recent open_pdks PRs. Power net names are now derived from the power pin names of cells.
On a related note, recently, we got pdngen to export the stripes as pins, so the verilog module (written right before routing) now already includes the power pins, is there a way to get
vlog2Verilog