I noticed that the flow.tcl script only does DRC and LVS on the maglef routing cells. Is this intentional? Is the full GDS DRC and LVS done elsewhere?

@User: This is intentional, yes. For LVS, the schematic you have is a verilog standard-cell-level netlist, so if you use the GDS (or the "mag" view) for the layout, which contains also lower-level devices down to transistors, you will be comparing the schematic to a netlist with many more devices. The line of thought here is that if every block/cell is LVS clean by itself (which should always be the case, otherwise, why would one be using it?), the "internal" netlist details can be abstracted away and LVS can run with only knowledge of how the block connects externally. For DRC, while using the GDS/"mag" view works for simple standard-cell-only layouts, checking other complex layouts (e.g., IO cells, SRAM blocks) doesn't usually go very well. A similar argument (with some caveats) to the above can also be applied, and running DRC with the maglef view captures all relevant violations that result from routing. If you'd like to experiment with it, simply play with the

MAGTYPE

variable (

mag

vs.

maglef

) set in

scripts/tcl_commands/magic.tcl

.

@Ahmed Ghazy Thanks for the quick response. I can understand abstracted LVS/DRC with hard macros where lower layer interaction between blocks is limited. However, even with individually LVS/DRC clean standard cells, I'd be awful wary of taping out a design without full DRC/LVS because of placement issues I've seen. Thanks for the suggestion on changing maglef to mag in magic.tcl. I'd just found that yesterday and attempted an LVS run with the lower level devices. As you noted, the verilog netlist does not contain these lower level devices. Is there any way to combine the verilog with the lower level spice/cdl cell definitions to do a full LVS run? Currently the verilog and spice/cdl number of pins and order does not match. eg. veilog conversion .subckt sky130_fd_sc_hd__and2_4 A B X VGND VPWR cdl .SUBCKT sky130_fd_sc_hd__and2_8 A B VGND VNB VPB VPWR X PS. The current CDL cells are missing mosfet source connections. eg. open_pdks/sky130/sky130A/libs.ref/sky130_fd_sc_hd/cdl/sky130_fd_sc_hd.cdl .SUBCKT sky130_fd_sc_hd__and2_8 A B VGND VNB VPB VPWR X MMP0 Y A VPB phighvt ... MMP1 Y B VPB phighvt ... MMIP0 X y VPB phighvt ... MMN0 y A VNB nshort ... MMN1 sndA B VNB nshort ... MMIN0 X y VNB nshort ... .ENDS sky130_fd_sc_hd__and2_4

+1 to Mitch's concerns. It's way too easy for the router to drop a via in the wrong place which interacts with the internals of a stdcell and cause a DRC and/or LVS violation - I've seen it many times on other tools

@Mitch Bailey: Thanks for your observations. I do agree that one should be careful with what the LVS and DRC reports actually mean; the default is meant to be as general as possible to work in most cases. The results are as good as the abstraction is; the scenario @yrrapt described wouldn't happen, for example, because the abstracted maglef view includes conservative via obstructions to prevent such scenario. However, placement issues or DRC issues that occur on lower layers (e.g., non-continuous nwell, etc.) wouldn't be checked without running the mag/GDS-level DRC. That said, for our tapeouts, we did perform a full DRC and an "almost full" LVS in the extents allowed by the tools. I will look into making mag/GDS-DRC the default; if you open an issue on our repo, it will help us track it. @Tim Edwards: Is it feasible in the netgen setup to read in all CDLs of the standard cells to complement the schematic (verilog netlist) side as mentioned above in @Mitch Bailey's comment in order to run a full (GDS-level) LVS?

@Ahmed Ghazy Thanks again for responding. Running LVS against the maglef views gives you a top level spice netlist that matches the verilog. I tired to add the cdl subcircuits from the pdk to that top level spice netlist and then compare that with the full netlist extracted from the mag views. It turns out that while some subcircuits are easy to adjust (I just used a wrapper circuit to connect to VNB and VPB and reorder the power and output), some subcircuits have abstract views with pins in a totally different order.

That's the same list but reordered, except for vpb/vnb