Hello! I am trying to resubmit my mpw-7 project bu...
# lvs
l
Hello! I am trying to resubmit my mpw-7 project but I am stuck on a LVS mismatch. I made sure to start over with the latest tag mpw-7h, but still no luck. This is the repository: https://github.com/mole99/caravel_wfg_sky130 The relevant log files are attached. Any help is appreciated, thanks!
t
Copy code
-------------------------------------------|-------------------------------------------
wfg_top (1)                                |wfg_top (1)
merge_memory (1)                           |merge_memory (1)
wb_mux (1)                                 |wb_mux (1)
sky130_sram_2kbyte_1rw1r_32x512_8 (2)      |sky130_sram_2kbyte_1rw1r_32x512_8 (2)
wb_memory (1)                              |wb_memory (1)
Number of devices: 6                       |Number of devices: 6
Number of nets: 655 **Mismatch**           |Number of nets: 657 **Mismatch**
---------------------------------------------------------------------------------------
NET mismatches: Class fragments follow (with fanout counts):
Circuit 1: user_project_wrapper            |Circuit 2: user_project_wrapper

---------------------------------------------------------------------------------------
Net: vssa2                                 |Net: vccd1
  wfg_top/vccd1 = 1                        |  wfg_top/vccd1 = 1
  wb_mux/vccd1 = 1                         |
                                           |
Net: vdda1                                 |Net: dummy_648
  merge_memory/vccd1 = 1                   |  merge_memory/proxyvccd1 = 1
  wb_memory/vccd1 = 1                      |
                                           |
(no matching net)                          |Net: dummy_650
                                           |  wb_mux/proxyvccd1 = 1
                                           |
(no matching net)                          |Net: dummy_656
                                           |  wb_memory/proxyvccd1 = 1
---------------------------------------------------------------------------------------
The output above indicates that the 2nd netlist does not have power supply pins for
wb_mux
,
wb_memory
, or
merge_memory
(although it does, for
wfg_top
). The "proxy" prefix means that netgen didn't find the pin in the pin list and so inserted one as a placeholder. I note that the files in
verilog/gl/
have power pins specified, so I can only assume that the netlists in the signoff directory that are indicated in the log files as the netlists that are being read into netgen for the LVS do not have power pins (?).
l
Thanks for your reply, @Tim Edwards. So that is what is meant by "proxy". What I also do not understand is why are wfg_top/vccd1 and wb_mux/vccd1 listed under Net: vssa2 on the left side? Shouldn't they be listed under Net: vccd1? The log file states that these two files are read in: Reading netlist file /home/leo/Dokumente/workspace-sky-mpw-7-redesign/caravel_wfg_sky130/openlane/user_project_wrapper/runs/22_11_23_17_52/results/signoff/user_project_wrapper.spice Reading netlist file /home/leo/Dokumente/workspace-sky-mpw-7-redesign/caravel_wfg_sky130/openlane/user_project_wrapper/runs/22_11_23_17_52/tmp/signoff/25-user_project_wrapper.pnl.v And whereas in "user_project_wrapper.spice" all subckts are connected to vccd1, in "25-user_project_wrapper.pnl.v" only wfg_top is connected to vccd1. Exactly as you described it! This begs the question as to why. Isn't user_project_wrapper.spice the netlist generated from the layout? So the actual layout is correct? But the netlist it is compared to is wrong? I compiled all the macros (merge_memory, wb_memory, wb_mux, wfg_top) separately and included them in the user_project_wrapper as blackboxes all in the same way. Notably, wfg_top is always at the top of FP_PDN_MACRO_HOOKS, VERILOG_FILES_BLACKBOX, EXTRA_LEFS and EXTRA_GDS_FILES. So maybe that's where I should continue looking.
t
I would assume this question is best put to the openlane developers, since whatever is happening to strip off the power supplies from the macros (or never insert them), and to do this to some macros but not others, must be happening within the synthesis flow.
m
How about setting
FP_PDN_CHECK_NODES
?
Copy code
./configuration/README.md:| `FP_PDN_CHECK_NODES` | Enables checking for unconnected nodes in the power grid. 0=Disable 1=Enable. <br> (Default: `1`) |
Currently,
openlane/user_project_wrapper/config.json
has
Copy code
{
    "DESIGN_NAME": "user_project_wrapper",
...
    "FP_PDN_CHECK_NODES": 0,
Looking at
verilog/gl/user_project_wrapper.v
you can see that only
wfg_top
has power connections. Your
user_project_wrapper.v
also has a tie cell
Copy code
sky130_fd_sc_hd__conb_1 TIE_ONE_one_ (.VGND(vssd1),
    .VNB(vssd1),
    .VPB(vccd1),
    .VPWR(vccd1),
    .HI(one_));
However, I don’t think that you’re doing standard cell placement at the top level, so this may cause a problem. It looks like you’re trying to eliminate the
user_proj_example
level. I’ve seen problems when tying top level macro pins to power or ground, because the tie cells can’t be placed. This is just a guess, but maybe check the
config.json
conversion. There should be a
config.tcl
file under the
runs
directory for
user_project_wrapper
. See if the
FP_PDN_MACRO_HOOKS
are as expected.
l
Thanks to both of you for your help! The problem was in the way I specified FP_PDN_MACRO_HOOKS. Previously in the tcl configuration I used:
Copy code
set ::env(FP_PDN_MACRO_HOOKS) "\
	wfg_top_inst                            vccd1 vssd1 vccd1 vssd1, \
	merge_memory_inst                       vccd1 vssd1 vccd1 vssd1, \
	wb_mux_inst                             vccd1 vssd1 vccd1 vssd1, \
	wb_memory_inst                          vccd1 vssd1 vccd1 vssd1, \
	sky130_sram_2kbyte_1rw1r_32x512_8_inst0 vccd1 vssd1 vccd1 vssd1, \
	sky130_sram_2kbyte_1rw1r_32x512_8_inst1 vccd1 vssd1 vccd1 vssd1"
Now that OpenLane is moving to json configurations, I tried setting FP_PDN_MACRO_HOOKS in a similar way, which was wrong. The correct way is to also use a comma at the end of the string:
Copy code
"FP_PDN_MACRO_HOOKS": [
    "wfg_top_inst                            vccd1 vssd1 vccd1 vssd1,",
    "merge_memory_inst                       vccd1 vssd1 vccd1 vssd1,",
    "wb_mux_inst                             vccd1 vssd1 vccd1 vssd1,",
    "wb_memory_inst                          vccd1 vssd1 vccd1 vssd1,",
    "sky130_sram_2kbyte_1rw1r_32x512_8_inst0 vccd1 vssd1 vccd1 vssd1,",
    "sky130_sram_2kbyte_1rw1r_32x512_8_inst1 vccd1 vssd1 vccd1 vssd1"
],
This looks a bit strange. I will open an issue to ask if this is intentional. The local precheck is now passing. Thanks again!
👍 1