Assembling Every Check From Modules 7 and 8
Across Modules 7 and 8 we ran a series of separate checks, each in its own tool, each with its own report format and its own idea of pass and fail. Until now nothing has made us look at them side by side. That is exactly the moment before a real tapeout decision, and in this section we build it up: the checklist in this article, the decision rule in the next, and a written signoff report in the third.
The checklist
| # | Check | Tool | Source | What it verifies |
|---|---|---|---|---|
| 1 | Setup timing, all corners, with derating | OpenSTA | 7.5 | Every path meets the clock at ss, tt and ff |
| 2 | Hold timing, all corners | OpenSTA | 7.3, 7.5 | No path changes too soon, above all at ff |
| 3 | Design rule check | Magic | 8.1 | The geometry meets the SKY130 rules |
| 4 | Layout vs. schematic | Magic + Netgen | 8.2 | The layout implements the final netlist |
| 5 | Antenna check | OpenROAD | 8.3 | No gate at risk during fabrication |
| 6 | IR drop and electromigration | OpenROAD PDNSim | 8.4 | Supply drop within budget, grid currents within limits |
| 7 | Rows filled, metal density | OpenLane, KLayout | 8.5 | Rows complete; density windows understood, fill planned |
| 8 | Independent DRC | KLayout | 9.2 | A second, independently written geometry check |
| 9 | GDS sanity | Magic/KLayout XOR, viewer | 9.1, 9.2 | Right top cell, complete cells, both streamouts identical |
That is the complete set this course produced for uart_top. Real tapeouts often add more, such as formal equivalence between RTL and the final netlist, signal integrity (crosstalk) analysis, or checks required by a specific shuttle’s harness. Each of those is the same kind of move: another independent check, another row in this table.
Collecting the real status lines
For your own run, pull the actual result of each check out of its report file. Do not rely on remembering that it passed a while ago. Where the files are depends on the OpenLane version, but OpenLane 2 also collects the key numbers into a metrics file for the whole run, which is the quickest place to start:
RUN=runs/uart_full
grep -iE "setup__ws|hold__ws|drc_error__count|lvs_error__count|antenna__violating|ir__drop" \
$RUN/final/metrics.csv
Then open each underlying report, the STA summary for each corner, the DRC report, the Netgen report, the antenna report, the IR drop summary, and copy the one line that states the result into a notes file, one line per checklist row. You are starting the signoff report of the third article right now, from real report files.
Figure 1 shows the point of doing it this way.
A flow that finishes without errors is not the same as a flow whose reports all say pass. A run can complete perfectly at the scripting level while one report inside it states a failure nobody opened. “The run completed” and “signoff passed” are different claims, and Module 7’s whole violation-fixing section exists because the first does not imply the second.
Practice Exercise
Here are six one-line results pulled from six report files for a run that completed without a single error. Which one, if any, blocks tapeout, and why does the clean run not save it?
STA: setup WNS = +0.03 ns, TNS = 0.00 ns (all corners)
DRC: 0 violations
LVS: Circuits match uniquely
ANTENNA: 0 violating nets
IR DROP: worst = 61 mV (budget: 50 mV)
DENSITY: no window above maximum; upper-layer fill planned at tapeout
Solution
The IR drop line blocks tapeout: 61 mV against a 50 mV budget is a measured, out-of-budget result. Everything else being clean, and the run completing without errors, changes nothing about what that report says. This is the situation the paragraph above warns about: the number has to be read and compared with its budget by a person, not inferred from the run’s apparent success.
In the next article we look at what a real go/no-go decision against a checklist like this looks like, including what to do when an item fails.