Project 3, Part 3: Signoff and Retrospective

In the previous article we routed the design around the macro. DRC will tell us whether the geometry is legal, but LVS across a macro boundary raises a question we have not met before. Everywhere else in this module, LVS compared a layout made entirely of standard cells with a netlist of the same cells. Here one instance is a macro whose inside was never part of our flow. So what exactly does LVS compare at that boundary? In this article we answer that, check the macro’s power connections, and sign the design off.

LVS across the macro

netgen -batch lvs \
  "sram_ctrl_extracted.spice sram_ctrl" \
  "runs/sram_run1/final/pnl/sram_ctrl.pnl.v sram_ctrl" \
  "$PDK_ROOT/sky130A/libs.tech/netgen/sky130A_setup.tcl" \
  lvs_sram_ctrl.report

The part of the report that is new, trimmed:

Circuit sky130_sram_2kbyte_1rw1r_32x512_8 contains no devices;
  treating it as a black box.
...
Final result: Circuits match uniquely.

Netgen does not compare the macro’s thousands of internal transistors. In the extracted layout the macro appears as a cell with pins, and the netlist has only its port list, so Netgen treats it as a black box: it checks that the instance is there on both sides and that each of its pins is connected to the same net in the layout and in the netlist, and nothing more. That is the right behaviour, not a weakness. The macro’s internal correctness is the responsibility of whoever generated and verified it. Your LVS verifies that you connected it correctly.

This is the main thing that changes when a macro is involved: the trust boundary moves. For the macro, you verify the integration, not the internals. In Projects 1 and 2 every cell traced back to a library the flow understood completely; here part of the chip is a block you trust because someone else verified it.

Power connections to the macro

The SRAM brings its own power pins and ring, and they must be connected to the design’s supply nets, not left floating. The flow’s LVS already checks the connectivity of vccd1 and vssd1 as pins of the macro, and OpenROAD’s power grid checker confirms that every power pin is reached by the grid:

% check_power_grid -net VPWR
% check_power_grid -net VGND

Both report no unconnected nodes. Running the IR drop analysis from Module 8.4 on this design shows a worst drop of 18.4 mV at the macro’s supply pins, the largest of any project so far, because the SRAM draws its current through a limited number of connections on one side of a large block. It is still well inside a 90 mV budget.

This is a check Projects 1 and 2 never needed in this form: not just that the grid is continuous, but that a large block with its own ring is connected to it at enough points, and that its far side is not starved.

DRC and antenna

DRC (Magic):  COUNT: 0
Antenna:      0 violating nets

Both clean, which confirms that the extra routing pass in the previous article really cleared the congestion rather than moving it somewhere else.

Signoff report

The last row is worth a moment. The final GDS combines two sources: our own routed design, and the macro’s GDS supplied separately, merged at streamout. Projects 1 and 2 each produced a GDS entirely from one flow run. This one is assembled from parts that never went through the same flow together, which is why checking the finished GDS (DRC, LVS, the streamout XOR) matters just as much here.

What changes with a black-box macro

Three concrete differences run through this whole project:

• Floorplanning becomes about geometry you do not control. Orientation, halo and power hookup exist because the macro’s pins and outline are fixed facts you design around, not parameters you tune.
• Congestion concentrates at fixed points. Every macro pin edge is a bottleneck by construction. In Projects 1 and 2 congestion could, in principle, be spread out almost anywhere; here it could only be relieved in one channel, because that is where the pins are.
• LVS becomes a question of the trust boundary. Verifying that a black box is wired correctly is a different job from verifying that every transistor matches, and teams integrating other people’s memories and IP blocks work inside this distinction all the time.

Almost every real chip, from a small microcontroller to a large processor, mixes synthesised logic with hard macros: SRAMs, ROMs, PLLs, high-speed I/O. Floorplanning, routing and verifying around blocks you did not build is not a niche skill. For most working physical designers it is most of the job.

Practice Exercise

Suppose the macro’s supplier later sends a revised Liberty file for this same SRAM with a slightly longer access time, while the LEF and GDS stay the same. Which signoff results would need to be redone, and which would not?

The macro is integrated, verified at its boundary and signed off, with a clear view of what verification means once part of the design is a block you trust rather than one you built. Project 4 raises the stakes again: the RISC processor core, the largest design in the course, where every discipline from Modules 1 to 9 is needed at once.