Root cause

The low-voltage setup scenarios were built from the hot-only rule: lowv_ss_cold_cworst ran, but its result was not expected, because the matrix treated hot as the slowest setup condition. At the low voltage of the new mode the cold condition is slower, so the result that matters for setup came from the scenario nobody watched. The violations are real: they would have appeared in silicon at cold, low voltage. Nothing is wrong with the constraints or the tools.

Fix plan

1
2
3
4
5
6
7
8
9
10
11
12
13

segments = {"seg1": 900, "seg2": 600, "seg3": 350, "seg4": 200, "seg5": 150, "others": 200}       # failing endpoints per shared segment
total = sum(segments.values())
assert total == 2400
order = sorted(segments, key=lambda s: -segments[s])
covered = 0
rows = []
for s in order:
    covered += segments[s]
    rows.append((s, round(covered / total, 3)))
assert rows[:3] == [("seg1", 0.375), ("seg2", 0.625), ("seg3", 0.771)]
remaining_after_three = total - sum(segments[s] for s in order[:3])
assert remaining_after_three == 550
print("PASS: fixing the three biggest shared segments covers", rows[2][1], "of the failing endpoints; remaining", remaining_after_three)

Three shared segments account for 77% of the 2,400 endpoints; after fixing them 550 remain, which is a much smaller job and probably needs a few targeted fixes. That is the arithmetic for the nine-day plan: days 1 to 3 fix the shared segments and re-run, days 4 to 6 deal with the remaining 550, days 7 to 8 run the full matrix and review hold, day 9 is buffer. What not to do: waive the violations, loosen the derate for the scenario, or drop the scenario. All three hide a real failure.

Related topics

• Investigation

• Next: How to Narrate It

• Fixing Setup