When the board clock traverses a clock modifying block which transforms the waveform in addition to compensating the overall insertion delay, it is recommended to use a virtual clock as a reference clock for the input and output delay instead of the board clock. 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 has a positive shifted waveform compared to the board clock: the virtual clock is defined like the board clock, and 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 has a negative shifted waveform compared to the board clock: the virtual clock is defined like the board clock and 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 example, consider the sysClk board clock that runs at 100
MHz and gets multiplied by an MMCM to generate clk266 that runs at 266 MHz. An output
that is generated by clk266 should use clk266 as the
reference clock. If you try to use sysClk as the reference clock (for
the set_output_delay specification), it will appear as
asynchronous clocks, and the path can no longer be timed as a single cycle.