How do cell delay and net delay derates differ when you apply set_timing_derate?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Short Answer
By default, set_timing_derate -early/-late (SDC) scales both the cell delays and the net delays on a path by the same factor. Adding -cell_delay or -net_delay restricts the derate to just one of the two, which matters because cell delay and net delay come from different physical sources of variation and do not need the same margin.
Technical Explanation
A path's total delay is the sum of cell delays through gates and net delays through wires, and manufacturing variation does not affect the two equally.
- The default scope covers both.
set_timing_derate -early 0.9(SDC), written without a scope option, applies the 0.9 factor to every cell delay and every net delay affected by the command. -cell_delaynarrows it to gates only.set_timing_derate -cell_delay -early 0.90(SDC) derates only the delay through standard cells, leaving net delays at their nominal calculated value.-net_delaynarrows it to wires only.set_timing_derate -net_delay -early 0.96(SDC) derates only the interconnect delay, leaving cell delays untouched.- Why the two need different treatment: cell delay variation comes mostly from transistor-level process variation — threshold voltage, channel length — while net delay variation comes mostly from metal width, spacing, and via resistance variation, which behaves differently across a process.
- A
-cell_checkscope exists too, for setup and hold library checks specifically, separate from delay through the cell, letting a derate target the constraint checks a library defines rather than propagation delay. - Combining separate cell and net derates is common in signoff. A team might apply a larger derate to cell delay than to net delay, or the reverse, if characterization data shows one source of variation is larger for their process than the other.
Common Mistake
The Trap: applying one blanket derate factor to an entire design and assuming it correctly represents both cell and interconnect variation equally.
- A designer copies a derate value from a previous project's constraint file without checking whether that project's process had a similar balance of cell-delay versus net-delay variation.
- If the new process has, say, much larger interconnect variation than the old one, a single shared factor either over-margins the cells or under-margins the wires, and neither error shows up unless someone splits the derate and re-checks.
Follow-up Question & Model Response
Your foundry's characterization data shows interconnect delay varies more than cell delay on your process node. How would that change your set_timing_derate commands?
Candidate Model Response: I would split the single blanket derate into two separate commands, one scoped with -cell_delay and one scoped with -net_delay (SDC), rather than applying one factor to both. Given interconnect varies more on this process, I would use a larger late-side factor and a smaller early-side factor for -net_delay than for -cell_delay, reflecting the wider spread the foundry data shows for wires. I would confirm the split with report_timing_derate (PT) to check both scopes are active as intended, since a missing scope option silently falls back to derating everything together.
Practical Example
A 16nm design's foundry data shows net delay variation of about 15% versus cell delay variation of about 6%. The team applies set_timing_derate -cell_delay -late 1.06 and set_timing_derate -net_delay -late 1.15 (SDC) instead of one shared factor. report_timing -derate (PT) on a wire-dominated path across a large block shows a noticeably larger margin applied to its net delays than to its cell delays, matching the underlying variation data instead of over- or under-margining either source.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
Continue practising