Hi @Tim Edwards, I saw during gds2spice, if we include the following lines, there will be fill and tap cells in the extracted spice file, causing mismatches with the source spice file.

lef read inputs/adk/rtk-tech.lef
lef read inputs/adk/stdcells.lef
gds noduplicates true
gds order true

1. Do we need the above lines for proper spice extraction? 2. If so, is it okay to filter all fill and tap cell mismatches?

I believe the openroad netlist output in

verilog/gl

includes the fill and tap cells so LVS should match that netlist if you're extracting lef. If you're extracting gds, the fill and tap cells will be ignored if you

export MAGIC_EXT_USE_GDS=1

in the shell or

set ::env(MAGIC_EXT_USE_GDS) 1

in the

config.tcl

file.

@Jake Ke: The problem with the tap cells is that the verilog description always has VDD and VSS and applies these to all the VNB and VPB ports of the standard cells. However, those connections are made only within the tap cell. If you take the tap cell as a black box, then each row (or rather pair of rows) of standard cells has its own individual VPB tied to the nwell but separate from all the others. The gate-level verilog does not divide up the VPB connections by row, and so will always mismatch. The solution I use requires (1) you don't read the LEF of the standard cells, but you pick up the standard cell views from the magic database versions in the PDK, so you have transistor-level views of the standard cells. Then, when you extract, magic flattens the tap cells and forms all the connections between VPWR and VPB. (2) As Mitch said above, you set the environment variable MAGIC_EXT_USE_GDS to 1 to tell netgen to ignore the tap and fill cells, which exist in the verilog-derived netlist but have been optimized out of the layout netlist. That's the only way to get a proper LVS for a standard cell layout, given the way the standard cells are designed and the way that the gate-level verilog is generated.

Thank you @Tim Edwards and @Mitch Bailey . Those are very helpful!