Module 10: Capstone Projects · Project 4: RISC Core, Full Chip

Project 4, Part 3: Full Physical Verification and Signoff

Every check in this article has been run before somewhere in this module, so nothing here is new. What is new is running all of it on a design that needed two real interventions to get here. Both the routability fix and the timing ECO left their marks on the layout, and this is where we find out whether either of them broke something.

DRC

Magic’s DRC on runs/cpu_run1/final/gds/cpu_top.gds, with the script from Module 8.1:

COUNT: 0

Clean. The extra routing passes really resolved the congestion rather than leaving a fragile result.

Fill

Section 8.5 separated two kinds of fill, and both apply here. The fill insertion step placed decap and filler cells in every empty row site, and check_placement confirms the rows are complete. The metal density check on the routing layers shows what we saw on the UART: met1 and met2 are dense enough everywhere, while met3 to met5, carrying only the longer routes and the power straps, have many windows below the minimum. No window is above the maximum. As in Module 8.5, the dummy metal fill for those windows is added at tapeout, and this goes into the signoff report as a condition.

LVS

The real question for this LVS run is whether the ECO, a set of resizes and one inserted buffer, is reflected in the netlist being compared.

netgen -batch lvs \
  "cpu_top_extracted.spice cpu_top" \
  "runs/cpu_run1/final/pnl/cpu_top.pnl.v cpu_top" \
  "$PDK_ROOT/sky130A/libs.tech/netgen/sky130A_setup.tcl" \
  lvs_cpu_top.report
Final result: Circuits match uniquely.

It matches, because the ECO was made in the OpenROAD database and the final netlist was written from that database afterwards: the buffer is in both, and each resized gate is the same, larger cell on both sides. Had the ECO been made on the layout alone, Netgen would have reported both the extra buffer and a different cell type at each resized instance.

What LVS does not tell you is whether the chosen sizes were good ones. It checks that the layout matches the netlist, not that the netlist is well sized; that is timing’s job, and it is why the multi-corner STA is re-run after every ECO.

Antenna, timing and IR drop

Antenna:                         0 violating nets
Worst setup slack, all corners:  +0.09 ns (ss)
Worst hold slack, all corners:   +0.05 ns (ff)
Worst static IR drop on VPWR:    7.0 mV

The timing numbers are unchanged from the previous article, since filler and decap cells do not touch any timing path. The IR drop, 7.0 mV, is a little above the 6 mV floorplan estimate, as expected once the real routing and the real cell placement are known, and still far inside the budget.

The signoff report

Check Result
Synthesis 1,842 cells, 612 flops (memories reduced to 32 bytes)
Placement Congestion at 55% utilisation; fixed with routability-driven placement
Routing 0 violations after 3 passes
DRC (Magic, KLayout) 0
LVS (final netlist, after ECO) Match
Antenna 0
Setup violations found 1 path at ss, closed with a two-step ECO
Worst setup slack, all corners +0.09 ns (flagged: thin, recommend RTL fix)
Worst hold slack, all corners +0.05 ns
Worst static IR drop 7.0 mV
Rows and density Rows complete; upper-layer metal fill at tapeout (condition)
GDS runs/cpu_run1/final/gds/cpu_top.gds

A report with real problems found and fixed along the way, like this one, is a more typical outcome for a real design than Project 1’s clean first run. A review team would generally trust this report more than a suspiciously smooth one for a design this size, precisely because it shows where the problems were and what was done about them, and it states plainly where the margin is thin.

Everything at once

This project was the sum of Modules 1 to 9: real utilisation pressure from Module 3, a real congestion problem from Module 4, a real clock tree from Module 5, extra routing passes from Module 6, a slow-corner setup violation closed with a Module 7 ECO, and a full Module 8 verification that had to confirm the ECO reached the netlist. None of it was a new idea. All of it was a familiar idea meeting a design big enough to make it matter.

Practice Exercise

The report says one setup violation was found and fixed in two steps, while the timing reports in the previous article showed three different slack values for that path. Is it more accurate to call this one violation fixed in two steps, or several violations? Justify the answer in terms of what STA reports.

Solution

One violation, fixed in two steps. STA reports the slack of a path, a specific startpoint and endpoint at a specific corner. Every re-check in the previous article measured the same path, ctrl/state_reg[2] to alu_b_sel_reg, at the same corner, ss_100C_1v60, with the slack improving from −1.44 to −0.26 to +0.09 ns as each change was applied. A separate violation would be a different startpoint and endpoint, or the same path at a different corner, showing up in the report independently of the fix.

The distinction matters for tracking: counting one violation that needed two passes as two violations inflates the problem count and hides whether timing closure is converging or going round in circles.

Project 4 closes with the most complete signoff of the course, built on real problems and real fixes. Project 5 turns the pattern round one last time: no building at all, just a design that has already been through the flow, three failing reports, and the job of working out what went wrong.

← Project 4, Part 2: Placement, CTS, Routing, and Timing Closure Project 5, Part 1: The Broken Design and the Evidence →