https://open-source-silicon.dev
Join Slack
<@U017E7L119N>: I will quote <@U016EM8L91B> on that: &gt; This is a known issue. . . It has found sy...
# openlane
a
@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
wonder if there is a recommended way to break out and continue from next step.
a
Probably 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
sounds 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)                          |VGND
a
Yea, 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
got it, thanks!
t
@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
I still don’t get a notion of how this scale, we’ll see
t
@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
@Tim Edwards I guess I'm also used to long Xilinx synthesis and PnR runs ... or 24h modelsim simulations ...
a
@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
to skip the module ports in order to evade having a duplicate of the power ports?
Open in Slack
PreviousNext
Powered by

What is Linen?

Linen is a search-engine friendly community platform. We offer integrations with existing Slack/Discord communities and make those conversations Google-searchable.

Powered by