Module 9: GDSII Generation and Tapeout ยท 9.3 Signoff Checklist

What a Real Signoff Decision Looks Like

In the previous article we collected every check into one list. At some point someone says “we are taping out”, and money is committed to a shuttle slot or a mask set. In this article I want to look at what that moment should be: a decision, made by a named person, against a written list. “It’s probably fine” is a feeling, not that decision.

The decision rule

Every item on the checklist gets one of three statuses: PASS, FAIL, or WAIVED, with a written justification. The rule is a plain AND across every row, with one narrow exception, as Figure 1 shows: the design goes only if every item passes, or every failing item has a documented waiver.

The go/no-go decision rule
Figure 1: Go only when every item passes, or every failing item carries a written, signed waiver

A waiver is a real engineering document, not a shrug. Sometimes a check fails in a way that is judged acceptable. For example: “the IR drop report shows 53 mV against a 50 mV budget in one corner of the die, and a timing run at the correspondingly reduced voltage for the cells in that region still passes with 0.3 ns of slack”. A proper waiver states the check, the measured value against its limit, the technical reasoning for accepting it, and the name of the engineer who takes responsibility. It is never a silent skip.

Some checks are not waivable in practice. A foundry or shuttle will reject a submission that fails its own DRC or antenna precheck, whatever your waiver says. Waivers apply to your own design margins, not to the manufacturer’s rules.

Drafting one yourself

Take the IR drop case from the previous article, 61 mV against a 50 mV budget, and write a one-paragraph waiver in your own words before reading on. It must state the check and the measured value against the budget, the physical or electrical reasoning for why it is acceptable, what extra evidence supports that reasoning, and a named owner. Write it so that someone else could read it cold and reach the same conclusion.

You may find you cannot honestly write it. 61 mV is more than 20% over the budget, and unless you can show that the affected cells still meet timing at the lower supply they actually see, the right answer is to fix the grid, not to waive it. Finding that out is part of the exercise.

In commercial tapeouts this review happens with names attached to every waiver. No name on a waiver means nobody is accountable if that net fails in silicon, and the practice exists to stop “everyone assumed someone else had checked it”.

A mistake that needs the same treatment as an outright failure is quietly re-running a check with relaxed settings until it says PASS, then calling it fixed. That is moving the goalposts. A report that now prints PASS under different assumptions is not the original check passing, and it needs the same written justification as a waiver.

Practice Exercise

Your antenna check reports two violations on two different nets. One is on a short net that connects straight to its gate on the same layer, with a partial ratio just over the limit. The other is on a long met3 run crossing half the die, three times over the limit. Do they deserve the same treatment in a go/no-go decision? What would you do with each?

Solution

They are different risk classes, but neither should go to the fab as a waiver. Shuttle and foundry prechecks include antenna rules, so both would be rejected, and both are cheap to fix.

The long met3 net is the real risk: a lot of exposed metal on one gate, far over the limit. Fix it properly with a diode next to the gate or a jumper, as in Module 8.3.

The short net barely over the limit is odd. A short, same-layer connection should not collect much charge, so check first whether the report is right: the gate might be a very small one, the net might have extra metal you did not expect, or the rule might be applied to a layer you did not think of. Then fix it, which is usually a single diode. Understanding why it failed matters more than the fix, because an unexpected violation often points at a setup problem that affects other nets.

In the next article we put every status line and every waiver into one signoff report for uart_top, ending with an explicit verdict.

โ† Assembling Every Check From Modules 7 and 8 Building Your Own Signoff Report for the UART โ†’