Verilog bus map to spice subcircuits in reversed order

[d-m-bailey]

Verilog bus indices in instances are being mapped in the wrong order to spice subckt definitions.

Extract the tarball into a new directory

netgen -batch source storage.netgen.ng
netgen -batch source storage.netgen.ok

The output is in

storage.lvs.lef.ng.log
storage.lvs.lef.ok.log

Both will end with Result: Circuits match uniquely. However, storage.lvs.lef.ng.log contains mismatches (ports are reversed).

I don't know that there is a viable solution to this problem. The bus index mapping depends on how the busses are defined in the missing verilog module definition which may be in either order. It might be better to not allow bus mapping from verilog to spice and instead require that bus connections are expanded in the gate level verilog.

netgen-verilog-bus.tar.gz

[RTimothyEdwards]

@d-m-bailey : That is not a valid setup for the LVS. If you want to read multiple files, then you must read all files before running the "lvs" command and then pass the file number to "lvs". If you pass a file name to "lvs" it will get a unique file number unassociated with anything that comes before. In effect, you are causing the SRAM SPICE netlist to be ignored. The proper setup would be:

    # read layout-extracted netlist
    set file1 [readnet spice storage.lef.spice]

    # read sram def into verilog-derived netlist
    set file2 [readnet spice sram_1rw1r_32_256_8_sky130.blackbox.sp]
    # read verilog top
    readnet storage.test.ok.v $file2
    # read library spice into verilog-derived netlist
    readnet spice sky130_fd_sc_hd.spice $file2
    lvs "$file1 storage" "$file2 storage" sky130A_setup.tcl storage.lvs.lef.ng.log -json

[RTimothyEdwards]

@d-m-bailey : I have confirmed that the script above produces a correct LVS result with pins in order. HOWEVER, the way I would have done it is this:

    # read layout-extracted netlist
    set file1 [readnet spice storage.lef.spice]
    # read verilog top
    set file2 [readnet  storage.test.ok.v]
    # read sram def into verilog-derived netlist
    readnet spice sram_1rw1r_32_256_8_sky130.blackbox.sp $file2
    # read library spice into verilog-derived netlist
    readnet spice sky130_fd_sc_hd.spice $file2
    lvs "$file1 storage" "$file2 storage" sky130A_setup.tcl storage.lvs.lef.ng.log -json

which in theory should be exactly the same; it's just that I read the verilog first and follow that by the SPICE netlists. But when I do that, the pin assignments are completely wrong---not just in reverse order, but assigned in arbitrary order regardless of the pin name. I would like it to be the case that netgen would produce the same result no matter what order you read in the files. For now, I will probably just let it be with a warning in the documentation about the order of reading files when mixing verilog and SPICE in the same netlist, but it needs to be fixed.

[d-m-bailey]

@RTimothyEdwards Thanks for the clarification. I'll need to fix the openlane/scripts/tcl_commands/lvs.tcl because my invalid (but working) script is taken from there. Maybe it "works" because it reads into file "1" without defining file "0" first. Then in the lvs macro, the layout is read into "0" and the subsequent net is read into "1" (which already has the subcells loaded). Probably not the intended operation, but seems to work.

[RTimothyEdwards]

@d-m-bailey :
storage.netgen.ng.tgz I think this issue can be closed. It was most likely complicated by issues that have been resolved in the netgen code recently. But as mentioned at the top, the use of file numbers in the script was incorrect. The corrected "storage.netgen.ng" (which is no longer "ng") is attached. It is the exact equivalent of the original script but with the file number handling corrected, and it passes LVS.

[RTimothyEdwards]

More specifically, the recent commit d69fbc23bbabf87e62e09840d0c4d69b04b87339 (Feb 3 2024) fixes the problem that I mentioned in the post above (March 4 2021), because that script reads the verilog before the SPICE, which was the problem recently found and fixed. Now, either script above produces correct LVS.