The board clock traverses a clock modifying block that transforms the waveform and compensates for the overall insertion delay. Use a virtual clock as a reference clock for the input and output delay. Do not use the board clock for the input and output delay. There are three main cases for using a virtual clock:
- The internal clock and the board clock have different period: The virtual clock must be defined with the same period and waveform as the internal clock. This results in a regular single-cycle path requirement on the I/O paths.
- For input paths, the internal clock uses a positive shifted waveform compared to the board clock. Define the virtual clock like the board clock. A multicycle path constraint of two cycles for setup is defined from the virtual clock to the internal clock. These constraints force the setup timing analysis to be performed with a requirement of one clock cycle + amount of phase shift.
- For output paths, the internal clock uses a negative shifted waveform compared to the board clock. Define the virtual clock like the board clock. A multicycle path constraint of two cycles for setup is defined from the internal clock to the virtual clock. These constraints force the setup timing analysis to be performed with a requirement of one clock cycle + amount of phase shift.
To summarize, the use of a virtual clock adjusts the default timing analysis to avoid treating I/O paths as clock domain crossing paths with a tight and unrealistic requirement.
For more information, refer to this link in the Vivado Design Suite User Guide: Design Analysis and Closure Techniques (UG906).
For example, consider the sysClk board clock
that runs at 100 MHz. An MMCM multiplies it to generate clk266 that runs at 266 MHz. An output that is generated by clk266 must use clk266 as
the reference clock. When you use sysClk as the
reference clock for the set_output_delay specification,
it appears as asynchronous clocks. Consequently, you can no longer time the path as a
single cycle.