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

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Path
  • STA Glossary
  • STA Metrics Reference
  • STA Mastery Cheatsheet
  • Timing Paths and Checks16
  • Constraints & SDC Fundamentals20
    • Clock Definition & Uncertainty
    • Generated Clocks & Dividers
    • I/O Timing & Boundary Contracts
      • Input and Output Delay
      • Interface Budgets
      • Virtual Clocks
      • I/O Constraint Audit
    • Exceptions & Audit Policy
    • Environment and Design Rules
  • Delay Graph & Path Analysis16
  • Beyond Setup and Hold16
  • Multi-Corner Multi-Mode Signoff16
  • OCV, AOCV, POCV and Variation16
  • Crosstalk and Noise16
  • ECO and Closure16
  • STA Debug Playbook16
  • STA Interview Prep26
  • Capstone Timing Signoff Lab4
Loading lesson

‹I/O Timing & Boundary Contracts
  1. Topics
  2. Static Timing Analysis
  3. Constraints & SDC Fundamentals
  4. I/O Timing & Boundary Contracts
  5. Virtual Clocks

Part 2 · Constraints and SDC · All levels

Virtual Clocks

A virtual clock has no source in the design; it stands for an external clock used as the reference for input and output delays.

On this page

    Why it matters

    External logic is launched or captured by some clock that is not a pin of the design: a board clock or a clock on another chip. A virtual clock models it: it gives the external launcher its own period, waveform and latency, and keeps I/O delays independent of the internal clock's waveform, gating and tree.

    Definition and use

    Diagram
    # not-run: SDC is not executable here
    create_clock -name vclk -period 10                          ;# no source object: a virtual clock
    set_clock_latency 0.8 [get_clocks vclk]                     ;# models the external clock's own latency
    set_input_delay  -clock vclk -max 4.0 [get_ports din]
    set_output_delay -clock vclk -max 3.0 [get_ports dout]

    Real clock as reference

    Virtual clock as reference

    Latency of the reference

    The clock edge at the definition point plus the clock's source latency (network latency only if the clock is ideal and set_clock_latency is given); the internal tree latency appears only on the capturing flop's side

    Set explicitly to what the external clock really has

    Use

    Interface clock is the same net as the internal clock

    Interface clock is external, or you want to control its period, waveform and latency independently

    Risk

    Port timing follows the internal clock's waveform, gating and tree

    Wrong latency value gives wrong port timing

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    # Setup on an input: arrival = reference source latency + input delay + internal path; required = T + capture latency - setup
    T, setup = 10.0, 0.1
    def slack(ref_latency, capture_latency, input_delay, path):
        arrival = ref_latency + input_delay + path
        required = T + capture_latency - setup
        return required - arrival
    # capture flop clock latency 1.2 ns; required = 10 + 1.2 - 0.1 = 11.1
    s_virtual = slack(0.8, 1.2, 4.0, 3.5)     # virtual clock carrying the external clock's own latency 0.8
    s_real_ref = slack(0.0, 1.2, 4.0, 3.5)    # real clock as reference with zero source latency: launch at the definition-point edge
    assert abs(s_virtual - 2.8) < 1e-9 and abs(s_real_ref - 3.6) < 1e-9
    print("PASS: virtual reference slack", round(s_virtual, 2), "vs real reference", round(s_real_ref, 2))

    The external clock's real latency is 0.8 ns. Using the internal clock as the reference with no source latency assumes the outside launches at the definition-point edge, 0.8 ns earlier than it really does, giving 3.6 ns of slack instead of 2.8 ns: optimistic on setup (and wrong in the other direction on hold). A virtual clock lets you put the real latency, period and waveform in, independent of the internal tree.

    What the review looks for

    • A virtual clock exists for each external clock that is not a pin of the design, with a stated period and latency.

    • Input and output delays reference the right clock; no port is tied to an internal clock by accident.

    • Virtual clock latency values come from the board or system plan.

    Common pitfall

    Forgetting that a virtual clock has no network: setting uncertainty or latency on it is the only way its edge times move. A virtual clock with no latency or uncertainty modelled is an ideal external clock, which may be too optimistic.

    Interview

    Explain why you would use a virtual clock: the interface is timed to an external clock whose latency differs from the on-chip tree.

    Check yourself When is a real clock a better reference than a virtual one?

    When the external logic is launched from the same clock source, so the same period and waveform apply; set the clock's source latency to model the external path. The reference is still the edge at the clock's definition point, not the internal tree.

    Related topics

    • Interface Budgets

    • Next: I/O Constraint Audit

    Previous

    32 / 183

    Next: I/O Constraint Audit

    Up next

    Up nextI/O Constraint Audit

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Input and Output Delay