Project 1, Part 3: Signoff and Retrospective
In the previous article the ALU routed with zero violations. “The router did not complain” and “this layout is signoff clean” are different claims, though, and treating them as the same is exactly the shortcut that gets a tapeout rejected. In this article we run the checks from Module 8 on the ALU and write up the result.
DRC
OpenLane runs Magic’s DRC and KLayout’s DRC as part of the flow, but it is worth running Magic by hand once and reading the result. Use the batch script from Module 8.1 on the final GDS, runs/alu8_run1/final/gds/alu8.gds, with the cell name alu8. The report ends:
COUNT: 0
Clean, as routing suggested. On a design this sparse, a DRC violation here would almost always point at a tool or PDK setup problem rather than at spacing pressure, because there is too much room in the layout for the rules to be under strain.
LVS
Extract the layout with Magic and compare it with the final powered netlist that OpenLane wrote, exactly as in Module 8.2:
netgen -batch lvs \
"alu8_extracted.spice alu8" \
"runs/alu8_run1/final/pnl/alu8.pnl.v alu8" \
"$PDK_ROOT/sky130A/libs.tech/netgen/sky130A_setup.tcl" \
lvs_alu8.report
Final result: Circuits match uniquely.
The final netlist is not the 163-cell synthesis netlist. It also contains the tap cells, the decap and filler cells, and any buffers the resizer added on the inputs and outputs, because OpenLane writes it after all of those have been placed. LVS checks the layout against that final netlist, which is what we want. Since nobody edited the layout by hand, a clean match is the expected, unremarkable result. LVS mismatches nearly always trace back to some change made outside the flow, and this project made none.
Antenna and timing
From the flow’s antenna check and its multi-corner STA against the virtual clock:
Antenna: 0 violating nets
Worst setup slack: +1.84 ns (ss corner)
Worst hold slack: +0.31 ns (ff corner)
Positive slack in both directions against the virtual clock, at every corner, and no antenna violations, which is unsurprising on a small block with no long single-layer routes.
The signoff report
| Check | Result |
|---|---|
| Synthesis | 163 cells, 0 flops or latches (expected) |
| Routing | 0 violations after 2 passes |
| DRC (Magic, KLayout) | 0 |
| LVS (Netgen, final netlist) | Match |
| Antenna | 0 |
| Worst setup slack, all corners | +1.84 ns |
| Worst hold slack, all corners | +0.31 ns |
| CTS | Not applicable: no clock |
| GDS | runs/alu8_run1/final/gds/alu8.gds |
This is the checklist of Module 9.3 in miniature, and on this design every row came back clean at the first attempt. Note the CTS row: it says “not applicable”, not “0”, which matters and is the subject of the exercise in Project 2’s last article.
Real ASIC teams do have blocks exactly like this one, small pieces of combinational logic dropped into a larger chip, and they really are this easy. That is a fair reflection of how much of the flow’s difficulty comes from clocks and macros rather than from physical design as such.
What this project did not face
It is worth being honest about what a clean first run on this design does not prove. The ALU never had to deal with:
- Clock tree synthesis and skew. No flops, no tree, and none of Module 5’s hold-fixing work. Project 2 starts there.
- Real timing pressure across corners. One virtual clock and plenty of slack everywhere. Nothing made us look hard at the slow corner, where a marginal design fails.
- Macros. Every cell came from the same library and was placed by the same tool. Project 3 is about what changes when part of the design is a block you did not synthesise.
- Congestion. At 35% utilisation, placement and routing had plenty of room. Project 4 shows what happens when that room runs out.
None of this is a criticism of the project. An uneventful first full run is the correct outcome for a design this simple, and it is the right place to start. But it would be a mistake to leave Project 1 thinking the flow is always this calm.
Practice Exercise
If this same ALU were re-run with FP_CORE_UTIL raised from 35 to 85, everything else unchanged, which row of the signoff report would you expect to go wrong first, and why?
Solution
Routing is the most likely first casualty. At 85% utilisation the core shrinks to about 2,300 µm², a square under 48 µm on a side, and the rows are almost full. Placement would probably still legalise, since cells can be packed tighter at the cost of more displacement, but the router would have far fewer free tracks between and over the cells. Detailed routing is where congestion first shows up as violations, or as a route that does not converge, well before timing or LVS show any symptom. This is the situation the congestion analysis of Module 4 and the routability work of Module 6 exist to catch before it reaches this point.
Project 1 is complete: the full flow, first time, a clean signoff, and an honest list of what it did not have to prove. Project 2 takes the UART controller, a real sequential design, and brings us to the first real timing problem of this module.