What are DRVs (max transition, capacitance, fanout), and why are they fixed before timing?

Short Answer

DRVs are design rule violations: a net whose transition time, load capacitance or fanout exceeds the limit set by the library or the constraints. They are fixed before timing because DRV fixing changes cells and buffers, which changes timing, and because timing on a violating net comes from outside the library characterized range. In PrimeTime, DRC fixing has the highest priority and can degrade setup or hold, so it runs first.

Technical Explanation

• Max transition limits how slow a signal edge can be. Library timing tables are characterized over a range of input transition and output load, and beyond that range the tool extrapolates, so delay numbers on the violating net are less trustworthy.
• Max capacitance limits the total load a driver can see. Too much load means slow edges, higher dynamic power and more current through the driver and its output wire.
• Max fanout limits how many pins a net drives. PrimeTime reports it with report_constraint -max_fanout (PT). ICC2 does not honor max fanout as a design rule constraint. You can set opt.common.max_fanout (ICC2) as a soft optimization target for data path cells instead.
• The PrimeTime UG states that setup or hold fixing does not degrade DRC, but DRC fixing can degrade setup or hold because it has the highest priority. Fixing timing first and DRC second throws away timing work.
• Fixing a DRV usually means upsizing the driver, inserting a buffer or splitting the load. Each changes delay on the net and input capacitance on the previous stage, so timing has to be rechecked afterwards anyway.
• The names are a trap. In PrimeTime the report is report_constraint (PT), singular. In ICC2 the documented command is report_constraints (ICC2), plural. Keep each script on the name its tool documents, so reviewers are never unsure which report they are reading.

What To Check

• Count of max transition and max capacitance violations per scenario, and the worst value against its limit.
• Whether violations are on data nets, clock nets or high fanout nets such as resets and scan enables.
• The ICC2 opt.common.max_fanout (ICC2) setting, since the ICC2 DRC report will not show fanout.
• That no violating net is also on a critical timing path whose slack you are trusting.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Zero max transition and max capacitance violations in every scenario at signoff.
• Suspicious (illustrative): A few violations over the limit by under 10%, all on non-timing-critical nets such as a scan enable.
• Hard stop: Transition violations on clock nets or on setup-critical paths. The delay numbers on those nets are extrapolated, so fix them before any timing ECO.

What The Interviewer Is Testing

• Knowing the order DRC then setup then hold, and the reason for it.
• Is the candidate aware that ICC2 does not honor max fanout as a DRC?
• Keeping report_constraint (PT) and report_constraints (ICC2) apart.

Follow-up Question & Model Response

"Why is timing on a net with a max transition violation not trustworthy?"

Candidate Model Response: Cell delay and output transition come from library tables indexed by input transition and output load. The tables only cover the characterized range. When the input transition is above that range, the tool extrapolates from the edge of the table, and the result can be off in either direction. The slack on that path might look fine and still be wrong. Fixing the transition puts the path back inside the characterized data.