ExpertQuestion 69 of 69Source: Synopsys PrimeTime User Guide: Hold Timing Closure and ECO Triage

You inherited a design with 3,000 hold violations two days before tapeout — what is your triage order?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

With that little time, the priority is grouping violations by root cause before fixing anything, because 3,000 individual violations are rarely 3,000 independent problems; most trace back to a handful of systematic causes like one under-sized clock buffer stage or one derate setting. Fix the highest-leverage systematic cause first, re-run incrementally to see how many violations that single fix clears, then triage what remains, rather than working the list top to bottom.

A 3,000-violation list grouped into clusters: 1,150 tracing to one under-sized clock buffer branch, cleared by three inserted hold buffers, followed by three smaller clusters of a few hundred each closed individually. — Technical Reference DiagramYou inherited a design with 3,000 hold violations two days before tapeout — what is your triage order?

Technical Explanation

The first step is grouping, not fixing: sort the 3,000 violations by shared clock domain, shared physical region, and shared root net or buffer stage, since a systematic cause, like one under-sized clock tree stage, can produce hundreds of near-identical violations.
A quick way to find systematic causes is checking whether violations cluster on one clock's launch or capture side, or on paths sharing a specific clock buffer, using report_clock_timing (PT) or a scripted pull of failing paths' shared attributes.
Fixing the biggest systematic cause first, for example adding hold buffers on one clock tree branch that touches 1,200 of the 3,000 violations, clears far more violations per engineering hour than fixing isolated single-path issues.
After each fix, an incremental timing update followed by a targeted re-check of the affected paths, rather than a full from-scratch signoff run, keeps the loop fast enough to try several fixes in two days.
The remaining isolated violations, after systematic causes are cleared, are triaged individually, typically by risk: a hold violation with a large negative slack or one on a critical control signal gets priority over a 5ps violation on a low-risk data path.
Because hold fixes generally use buffer insertion, adding delay, rather than resizing, as setup fixes often do, and because delay added for hold on one path must not create a new setup violation elsewhere, every fix needs a check that it did not open a new problem before moving to the next.

Common Mistake

The Trap: starting at the top of a 3,000-item violation list and fixing paths one at a time in slack order, without first checking whether most of them share one root cause.

Fixing violations one path at a time when 1,200 of them share one clock buffer wastes almost all of the available time on redundant work.
Running a full signoff re-analysis after every single fix, instead of an incremental, targeted check, can burn most of the two days on runtime rather than triage.

Follow-up Question & Model Response

If the root-cause grouping shows the 1,200-violation cluster traces back to a clock tree issue that would normally need re-synthesis, but there's no time for that, what do you do?

Candidate Model Response: In a two-day window, re-synthesizing the clock tree is off the table, so the fix has to be a targeted ECO instead: adding hold buffers directly on the affected branch through PrimeTime's ECO commands, verified with an incremental timing update rather than redoing clock tree synthesis. This trades a cleaner long-term fix for one that closes timing now, and the team should flag the clock tree issue for a proper fix in the next design cycle rather than treating the ECO buffer insertion as the permanent answer. The immediate goal is a design that meets timing for tapeout; the systematic root cause still needs to be addressed properly afterward.

Practical Example

Of 3,000 hold violations, sorting by clock domain and physical region shows 1,150 cluster on the clk_core domain's east-side branch, all with similar 15-25ps negative slack. Tracing that branch's clock tree shows one buffer stage was sized for a lighter fanout than the block ended up with after a late RTL change. Inserting three additional hold buffers on that branch with PrimeTime's ECO flow, then running an incremental update, clears 1,090 of those 1,150 violations in one pass. The remaining 1,850 violations are then triaged in three smaller clusters of a few hundred each, tracing to two more localized buffer-sizing issues and one derate-margin edge case, closing the design with about six hours to spare before the tapeout deadline.

Complete STA Handbook