https://open-source-silicon.dev logo
Join Slack
Powered by
Has anyone gotten decap mismatches? Why would this...
# openlane
m
Has anyone gotten decap mismatches? Why would this be?
Copy code
Subcircuit summary:
Circuit 1: user_project_wrapper            |Circuit 2: user_project_wrapper
-------------------------------------------|-------------------------------------------
sky130_fd_sc_hd__tapvpwrvgnd_1 (1)         |sky130_fd_sc_hd__tapvpwrvgnd_1 (1)
sky130_fd_sc_hd__and2_1 (333)              |sky130_fd_sc_hd__and2_1 (333)
sky130_fd_sc_hd__and2_2 (38)               |sky130_fd_sc_hd__and2_2 (38)
sky130_fd_sc_hd__decap_3 (2917)            |sky130_fd_sc_hd__decap_3 (1) **Mismatch**
sky130_fd_sc_hd__clkbuf_2 (227)            |sky130_fd_sc_hd__clkbuf_2 (227)
@User This seems like a netgen issue. There are definitely more than 1 of these decap cells in the Verilog (right) netlist. The setup.tcl from sky130A seems to have some options for these to be "parallelized". Do you know what this might be?
It looks like the setup.tcl used to have them ignored, but that is commented out:
Copy code
#        if {[regexp {sky130_fd_sc_[^_]+__decap_[[:digit:]]+} $cell match]} {
#            ignore class "-circuit2 $cell"
#        }
@User It looks like a commit from you commented them out:
Copy code
44b715a8 sky130/netgen/sky130_setup.tcl (Mitch Bailey 2020-12-19 21:48:18 +0900 307) #        if {[regexp {sky130_fd_sc_[^_]+__decap_[[:digit:]]+} $cell match]} {
44b715a8 sky130/netgen/sky130_setup.tcl (Mitch Bailey 2020-12-19 21:48:18 +0900 308) #            ignore class "-circuit1 $cell"
44b715a8 sky130/netgen/sky130_setup.tcl (Mitch Bailey 2020-12-19 21:48:18 +0900 309) #        }
but the commit was supposed to IGNORE fill and tap cells
Copy code
commit 44b715a8cb733069b55d892ebe4786a79b9d5893 (tag: 1.0.91)
Author: Mitch Bailey <d-m-bailey@users.noreply.github.com>
Date:   Sat Dec 19 21:48:18 2020 +0900

    Ignore fill and tap cells in device level LVS
m
@User Right, fill and tap cells contain no extracted devices. LVS was extracting them as undefined subcircuits and ignoring them solved the problem. On the other hand, decap cells contain devices and ignoring them could result in mismatches. netgen's setup file has parallel reduction for decap devices, but recently I've noticed that it hasn't been working in all cases. I can see from your list that there are 
sky130_fd_sc_hd__tapvpwrvgnd_1
cells also being considered during LVS. The sky130A netgen setup file should ignore these too. Can you post your netgen command?
m
Differences in decap shouldn't really be a mismatch as that could be safe to ignore. Correctness isn't dependent on exact decap. This is using the setup.tcl from open_pdks in the openlane flow.
Copy code
Reading netlist file /project/openlane/user_project_wrapper/runs/user_project_wrapper/results/magic/user_project_wrapper.spice
Reading netlist file /project/openlane/user_project_wrapper/runs/user_project_wrapper/results/lvs/user_project_wrapper.lvs.powered.v
...
Reading setup file /software/PDKs/sky130A/libs.tech/netgen/sky130A_setup.tcl
Comparison output logged to file /project/openlane/user_project_wrapper/runs/user_project_wrapper/results/lvs/user_project_wrapper.lvs.lef.log
Logging to file "/project/openlane/user_project_wrapper/runs/user_project_wrapper/results/lvs/user_project_wrapper.lvs.lef.log" enabled
sky130A_setup.tcl
The version of open_pdks is the one installed from openlane with make pdk.
Copy code
commit 14db32aa8ba330e88632ff3ad2ff52f4f4dae1ad (HEAD, tag: 1.0.234)
Author: Tim Edwards <tim@opencircuitdesign.com>
Date:   Mon Oct 25 13:18:42 2021 -0400

    Updated version to go along with the merge of pull request #169
    from Manar Abdelatty.
In my MPW2 submission that passed LVS, it had 1 instance of each decap type in both netlists when it matched.
m
Ok, so this is a result of 
flow.tcl -design user_project_wrapper
?
m
Yeah
Using the mpw-3 tagged stuff
m
mpw-3
or 
mpw-3a
?
Can you check the LVS results for the 
decap
cells in the 
user_project_wrapper
LVS log? I'm thinking that it's trying to do a black box compare because I doubt that the spice library is being added to the verilog.
t
@User: Ignoring cells is always dangerous, because you could have, for example, a cell inserted upside down or something like that and ignoring it would mean you never see the issue. The main thing is that the decap cells in the layout have not been combined in parallel; you should end up basically with one decap cell of each type on each side. Since decaps connect only to power and ground, you need to figure out what's going on with the power and ground in your layout netlist.
m
@User I've recently (within the last 3? months) noticed non-parallelization of 
decap
cells (I think). Has there been a change to netgen not to parallelize non-empty cells?
t
No. They should all be parallel.
m
Correct me if I'm wrong, but parallel reduction only occurs if there's a mismatch, right?
t
No, parallel reduction happens automatically, although if there are parameters like with parallel reduction of devices, then the parameters are chained together in a record. But the devices are still considered parallel.
t
@User I had the same issue within the last days. Also filler mismatches. I was working hard to rebuild the testcase but wasn't able to, sorry. All I can do is to confirm it. I use the resizer-fixed docker to match the latest Openlane\pdks release and I don't have decap\filler LVS issues these days. https://github.com/The-OpenROAD-Project/OpenLane/issues/693
m
@User I see, thanks for the parallel explanation. I got through this and there was a PDN DRC error that is probably related. If the supplies are messed up, it won't do the reduction right. https://skywater-pdk.slack.com/archives/C016H8WJMBR/p1636739206261400
@User ^^ Did you check your supplies?
t
@User Good to know, but didn't check it back then. Layout hiccups don't have highest priority right now. I still have time as I'm targeting MPW4, where the flow will just work like a charm.🪄
m
@User What version of netgen? May be related to a recent change.
m
I used the version with tag mpw-3a. Not sure what that is. The error was due to a bad power stripe that shorted some power rails
m
Ok. FWIW, 
netgen -batch
will give you the version.
m
I'm trying to not use custom versions in this tape out. Approved versions only.
👍 1
2 Views
Open in Slack
PreviousNext
Powered by