A functional bug is fixed with a small change touching two logic cones: a gate level is removed from one cone, while the bug fix adds a gate level of new logic on a different, deeper cone. After the change the signoff run reports 214 hold violations in the fast corners (worst -0.040 ns), from the cone that lost a gate level, and 31 setup violations in the slow corners (worst -0.025 ns), from the deeper cone whose maximum paths the added logic lengthened. Tape-out is in 60 hours. A manager proposes waiving the hold violations because 'the block is low risk and slack is only tens of picoseconds'.
Item | Value |
|---|---|
Change | Two logic cones in one block: a gate level removed from one, a gate level of new logic added on a deeper cone |
Hold violations (fast corners) | 214, worst -0.040 ns |
Setup violations (slow corners) | 31, worst -0.025 ns |
Time left | 60 hours |
Cost of a full verification run | 18 hours |
Cost of a fast loop (top scenarios, timing only) | 5 hours |
What kind of change was it? A logic change sits high on the ECO risk ladder: it needs the full verification set, including equivalence.
Do the hold violations share a cause (the removed gate level shortened paths into a group of flops)?
Do the setup violations share a cause (the added gate level lengthened maximum paths in the deeper cone)?
How many endpoints can be fixed by delay insertion and how many cannot?
How many full runs and fast loops fit in 60 hours?
left, full, fast = 60, 18, 5
max_full = left // full
assert max_full == 3
plan = 3 * fast + 2 * full # three batches each followed by a fast loop, then two full runs
assert plan == 51 and left - plan == 9
risky = 1 * fast + 1 * full # one big batch, one full run
assert risky == 23
print("PASS: at most", max_full, "full runs fit; careful plan uses", plan, "h (", left - plan, "h spare ); risky plan uses", risky, "h")Sixty hours allow at most three full runs. A careful plan with three batches (each checked by a fast loop) and two full runs takes 51 hours with 9 spare. A single big batch with one full run takes only 23 hours but leaves no room to recover if the batch breaks something: it is the plan that looks fastest and is the riskiest.
Nothing checks the batch until the one full run at the end, so any breakage is found late; the three-batch plan finds problems after each step, while there is still time to repair them.