Reconstruct the AOCV incremental derating: cell u1/u252 has late derate 1.082, early 0.924; you apply -increment -late 0.03 and -increment -early -0.03.
From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide
Short Answer
An increment adds to the existing derate factor rather than replacing it, so the final late derate is 1.082 + 0.03 = 1.112 and the final early derate is 0.924 + (-0.03) = 0.894. If a sum landed below 0.0, the tool would clamp it to 0.0.
Technical Explanation
The key word in the command is -increment — it does not replace the derate factor already in effect on the cell, and it does not multiply it. It adds arithmetically to whatever factor AOCV (advanced on-chip variation, table-based derating by depth and distance) already assigned.
- The late-side math: u1/u252 already carries a late derate of 1.082, so applying
-increment -late 0.03gives a final late factor of 1.082 + 0.03 = 1.112, making the late (worst-case, slow) delay bigger. - The early-side math: the cell's existing early derate is 0.924, and
-increment -early -0.03is a negative increment, giving 0.924 + (-0.03) = 0.894, making the early (best-case, fast) delay smaller. - Why the early increment is negative: the two increments push the setup/hold guardband window open in both directions by the same 0.03 — late gets slower, early gets faster — which is the whole point of an incremental margin.
- The clamp guard: if a sum came out below 0.0, the tool clamps the resulting factor to 0.0 rather than letting an increment produce a negative delay, which would be physically meaningless.
- Why this matters: incremental derating lets a designer layer a small extra guardband on top of a table- or library-driven derate without regenerating the underlying characterization data — the reported, final factor is always the sum, never just the increment typed into the command.
Common Mistake
The Trap: reading the -increment value in the command as the final derate factor itself.
- Someone sees
-increment -late 0.03and reports "the derate is 0.03" instead of computing 1.082 + 0.03 = 1.112. - That misreading understates the actual margin being applied on the path by more than a factor of thirty, making a signoff review look far more conservative than it really is.
Follow-up Question & Model Response
What tells you whether a cell's reported derate came from the base AOCV table alone or from a table value plus an increment?
Candidate Model Response: Run report_timing_derate (PT) on the cell twice: once plain, which reports the current, already-combined derate factor in effect, and once with -increment, which reports only the incremental piece on top of it. Subtracting the two tells you the base table value, and confirms whether an increment is in effect at all. Relying on memory of which increments were scripted months earlier is unreliable, especially once several derate adjustments have accumulated from different SDC files across a project.
Practical Example
Cell u1/u252 in a 28nm design has an AOCV base table entry of late 1.082 at its logic depth. A late-stage margin review adds set_timing_derate -increment -late 0.03 [get_cells u1/u252] (SDC) and the mirrored early command to compensate for a newly discovered voltage-drop hotspot near that cell. report_timing_derate [get_cells u1/u252] (PT) afterward shows the combined 1.112 now in effect, and report_timing_derate -increment [get_cells u1/u252] (PT) confirms the 0.03 increment on top of the 1.082 base, the same combined value report_timing (PT) uses when it walks a path through that cell.
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.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.
Continue practising