Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • RTL Foundations36
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
  • Timing & Clocking39
    • STA Foundations
    • Setup, Hold and Slack
    • Skew and Variation
      • Skew and Jitter in Practical STA
      • Uncertainty Modeling
      • Clock Tree and Skew Sources
      • Reading Timing Reports with Skew Context
      • OCV and AOCV Concepts
    • Timing Exceptions
    • Clock Gating
    • RTL for Timing
    • Clock Architecture
  • Reset & CDC34
  • Memory & Buses57
  • Advanced RTL28
  • Senior & Interview76
  • Glossary and Notation
Loading lesson

←Skew and Variation
  1. Topics
  2. RTL Design
  3. Timing & Clocking
  4. Skew and Variation
  5. OCV and AOCV Concepts
On this page

    Part 5 of 9, lesson 16 of 39Part 5 of 9/Timing & Clocking/Lesson 16 of 39Intermediate

    OCV and AOCV Concepts

    Derating, pessimism removal, and depth-dependent AOCV on one example path.

    With a late derate of 1.08 and an early derate of 0.92, the path with +0.11 ns of slack drops to -0.148 ns. Even after removing the shared-trunk pessimism it still fails at -0.068 ns.

    After this lesson you can: apply late and early derates to a setup or hold check, compute the common-path pessimism removal, and explain why AOCV is less pessimistic for deep paths.

    Same chip, different speeds

    Two transistors millimetres apart do not switch at the same speed. On-chip variation (OCV) models this with derating factors.

    For a setup check, the launch clock and data paths are made slower (late derate, for example ×1.08) and the capture clock path faster (early derate, for example ×0.92). Hold reverses the early/late assignments.

    The same path, now derated

    Quantity

    Nominal

    Derated (setup)

    Launch clock + clk→Q + logic

    2.42 ns

    × 1.08 = 2.614 ns (late)

    Capture clock latency

    0.80 ns

    × 0.92 = 0.736 ns (early)

    Required time

    2.00 + 0.80 − 0.12 − 0.15 = 2.53

    2.00 + 0.736 − 0.12 − 0.15 = 2.466 ns

    Slack

    +0.11 ns

    2.466 − 2.614 = −0.148 ns

    The derate turns a passing path into a failing one. Before common-path correction, independent early/late assignments also introduce pessimism on the shared clock segment. The constructed tree below gives a 0.08 ns correction for this pessimism.

    For static common-path variation, the shared physical clock buffers and wires cannot be both slow for launch and fast for capture in the same analysis. This does not imply identical delay on successive clock edges: temporal jitter and other time-dependent effects need separate treatment.

    Common-path pessimism removal (CRPR / CPPR)

    Constructed flat-OCV setup example. Launch latency 0.62=0.50+0.12 ns and capture latency 0.80=0.50+0.30 ns share the same physical 0.50 ns trunk.

    Follow the tree from the source to the split. Both checks contain the same physical trunk, but the independent worst-case setup calculation counts it late on launch and early on capture. For this simple static flat-derate model, that creates 0.08 ns of artificial relative-clock penalty. The two branches after the split are different physical paths, so their early/late difference is not canceled.

    CRPR=common clock path delay×(late derate−early derate)
    Diagram
    Common clock path delay (shared trunk):   0.50 ns
    CRPR = 0.50 x (1.08 - 0.92) = 0.08 ns
    Slack after pessimism removal = -0.148 + 0.08 = -0.068 ns

    The result is still negative. A design that looks fine without derates can fail with them, and the gap is real margin the chip needs.

    Rebuild the setup slack from the branches

    Quantity

    Calculation (ns)

    Launch clock, late

    0.50 x 1.08 + 0.12 x 1.08 = 0.6696

    Data clk-to-Q + logic, late

    (0.35+1.45) x 1.08 = 1.9440

    Data arrival

    0.6696+1.9440 = 2.6136

    Capture clock, early

    0.50 x 0.92 + 0.30 x 0.92 = 0.7360

    Setup required

    2.00+0.7360-0.12-0.15 = 2.4660

    Raw slack

    2.4660-2.6136 = -0.1476

    Shared-trunk correction

    0.50 x (1.08-0.92) = +0.0800

    Corrected slack

    -0.1476+0.0800 = -0.0676 (still fails)

    This reproduces the rounded -0.068 ns result above. Setup time and uncertainty were held fixed for this teaching example; a signoff flow uses the library checks and variation settings appropriate to its analysis view.

    Hold reverses early and late, not the benefit of removal

    For a constructed flat-OCV hold example using the same clock tree and derates, take nominal clk-to-Q=0.30 ns and minimum logic=0.10 ns, with hold=0.06 ns and hold uncertainty=0.05 ns held fixed. Hold uses an early launch/data path and a late capture path. It still adds the removable shared-clock pessimism to slack.

    Hold quantity

    Calculation (ns)

    Earliest data arrival

    (0.50+0.12+0.30+0.10) x 0.92 = 0.9384

    Latest hold requirement

    (0.50+0.30) x 1.08+0.06+0.05 = 0.9740

    Raw hold slack

    0.9384-0.9740 = -0.0356

    Corrected hold slack

    -0.0356+0.0800 = +0.0444

    CRPR removes duplicated pessimism, not actual skew, data-path delay or specified jitter. The simple trunk-times-derate formula here is a teaching model, not a replacement for tool analysis of edge polarity, rise/fall arcs, AOCV/POCV correlation or temporal variation. Use the reported correction from the approved signoff flow.

    Check yourself If the clock paths share only 0.25 ns instead of 0.50 ns, what flat-derate correction remains?

    0.25 x (1.08-0.92)=0.04 ns. Only the actual common segment qualifies; separate branches cannot be added to it just because they happen to have equal nominal delays.

    Check yourself Why does CRPR only apply to the clock path and not to the data path?

    Because the pessimism comes from treating the same physical clock buffers and wires as late for launch and early for capture. The data path exists only on the launch side; there is no shared segment to cancel.

    Depth-dependent and statistical derating

    A flat derate punishes deep paths most. Depth-aware and statistical methods remove some of that pessimism.

    Method

    Idea

    Effect

    OCV (flat derate)

    One factor for all paths

    Simple, pessimistic for long paths

    AOCV (advanced)

    Derate depends on logic depth and distance: deeper paths average out variation

    Less pessimism for deep paths, more for shallow ones

    POCV / LVF

    Per-cell statistical sigma

    Most accurate; needs library support

    An illustrative AOCV late-derate table (the numbers are made up to show the shape):

    Logic depth

    Late derate

    1

    1.15

    5

    1.09

    20

    1.05

    AOCV makes deep paths look better and shallow paths worse than a flat derate. A path with one or two cells is where variation really matters, because there is nothing to average it out.

    Common mistakes

    Derating is for the implementation team to apply; an RTL designer should not hand-add margin to compensate for it. If a path is failing only with derates, the right response is still structural: less logic, less fanout, balanced clocks.

    • Setup derates launch and data late and the capture clock early. Hold reverses them.

    • CRPR removes pessimism only on the shared physical clock segment: 0.50 x (1.08 - 0.92) = 0.08 ns here.

    • AOCV derates by logic depth. Deep paths get less derate, one- or two-cell paths get more.

    Rule of thumb: if a path fails only with derates, fix the structure, not the margin.

    How this was checked

    The 0.08 ns trunk correction uses a constructed flat-OCV tree. The AOCV derate table is made up to show its shape. Use the correction reported by the approved signoff flow.

    • Interview: run a mock interview on this topic

    Related topics

    • Timing exceptions

    Previous

    131 / 350

    Next: Timing Exceptions

    Up next

    Up nextTiming Exceptions

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Skew and Jitter in Practical STA
    • Uncertainty Modeling
    • Clock Tree and Skew Sources