Clock uncertainty is the total possible time variation between any pair of
clock edges. It includes computed jitter, phase error, and any user-defined uncertainty
from set_clock_uncertainty.
For primary clocks, define jitter using
set_input_jitter and set_system_jitter.
For clock generators such as MMCMs and PLLs, the tool calculates jitter from the source
clock jitter and clock modifying block (CMB) configuration. For generated clocks, such
as flop-based dividers, jitter matches the source clock. Important: The AMD Vivado™ Design Suite supports clock-based uncertainty, not pin-based.
If a clock propagates through multiple CMBs, like parallel
BUFGCEs, while retaining the same clock name, its jitter remains
constant, and is unaffected by resources in the clock's path and unaffected by the
clock's fanout.The tool adds the user-specified uncertainty to its internal computation. For generated clocks (such as from MMCM, PLL, and flop-based clock dividers), the user-specified clock uncertainty does not propagate through the clock generator.
For more information on jitter and phase error definitions, see the Vivado Design Suite User Guide: Using Constraints (UG903).
The clock uncertainty has two purposes:
- Reserving some margin during slack calculations to account for clock noise that can affect hardware behavior. Because the delay and jitter values are already conservative, AMD does not recommend adding extra uncertainty to guarantee hardware functionality.
- Over-constraining selected paths: You can use clock uncertainty to make paths related to specific clocks or clock pairs more restrictive during one or more implementation steps. This helps improve quality of results (QoR) and timing closure. When you apply clock uncertainty, the tool does not alter the clock waveforms or their relationships, so the rest of your timing constraints remain valid.