What is a timing derate, and where do you see it in a report?

Short Answer

A timing derate is a multiplier applied to calculated delays to cover on-chip variation: late delays are scaled up and early delays scaled down. In a PrimeTime report you only see it if you ask: report_timing -derate (PT) adds a Derate column next to each incremental delay. Reading that column tells you which factor was applied to which cell or net, and whether it is the one you meant.

Technical Explanation

• set_timing_derate -late 1.05 -cell_delay (SDC) multiplies late cell delays by 1.05. For a positive delay the new delay is the old delay times the factor, so a 100 ps cell becomes 105 ps.
• Setting a derate also switches PT into on-chip variation mode. For a setup check PT applies late derates to the launch clock path and the data path and early derates to the capture clock path; for hold it does the opposite.
• Derates can be scoped to clock or data paths, to cell or net delays, to rise or fall, and to specific cells, nets or library cells. A narrower scope wins over a wider one, so a per-cell derate overrides a design-wide value.
• Cell timing checks, meaning setup and hold times of the flop, are not derated by default; -cell_check applies a factor to them.
• report_timing -derate (PT) shows the factor on each row. A 1.200 next to one cell and 1.100 next to another tells you two different derates reached those cells, and you can trace which command set each.
• report_timing_derate (PT) lists the derate settings themselves, split by clock and data, rise and fall, early and late. Use it to prove the settings match the signoff specification before reading any slack.
• Common signs of a derate problem are a column full of 1.000 on the data path of a setup report, which means no late derate reached it, or a factor that differs between PT and ICC2 for the same scenario.

What To Check

• The derate settings in report_timing_derate (PT) against the signoff specification for each scenario.
• The Derate column on data and clock rows of the worst setup and hold paths.
• Rows showing 1.000 where a factor was expected, or a factor that is too large on a single cell.
• The same scenario in ICC2 and PT, since a derate mismatch is a common correlation gap.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Every data row on a setup path shows the specified late factor, for example 1.050, and every capture clock row shows the early factor.
• Suspicious (illustrative): One cell shows 1.200 while its neighbours show 1.050, pointing at a per-cell or per-library-cell derate someone added and forgot.
• Hard stop: Data rows show 1.000 in a signoff run that is supposed to be derated. The slack is optimistic; stop and fix the setup.

What The Interviewer Is Testing

• Knowing which parts of a setup path get late derates and which get early derates.
• Can you find the factor actually applied to a given cell in the report?
• Precedence rules: does the candidate know a narrower scope overrides a wider one?

Follow-up Question & Model Response

"Why is the capture clock path derated early for a setup check?"

Candidate Model Response: A setup check fails when data arrives late and the capture clock arrives early. To bound the worst case, PT makes the launch clock and data late and the capture clock early at the same time. That creates pessimism on the clock segment both paths share, because one physical buffer cannot be early and late at once. CRPR removes that shared-segment pessimism afterwards.