Forum Discussion
Occasional ContributorAbout Virtual Clocks in Constraints
Virtual clocks represent the clocks that drive external devices, those that drive into the FPGA on inputs (upstream) and those that drive devices fed by the FPGA on outputs (downstream). I'm not sure what you mean by "limit the data output from the FPGA to the external clock." On outputs, the virtual clock is used as the latch clock and the setup and hold timing requirements at the downstream device are based off of it. On inputs, the virtual clock acts as the launch clock and the tco of the upstream device is based off of it.
For synchronous I/O timing analysis, the virtual clock is always the clock that is referenced when creating your set_input_delay and set_output_delay constraints so even if the same physical clock drives both the external device and the FPGA, you should always create a separate virtual clock with create_clock. Virtual clocks are created with create_clock by not specifying a target (but including a name), something like:
create_clock -name virt_clock -period 10
Regular ContributorHello,
"For example, is it correct to assume that correct analysis results cannot be obtained if the physical clock used to latch the target signal is specified instead of the virtual clock when creating the set_input_delay constraint?"
If by physical clock you mean a base clock on Quartus, then yes. Because using virtual clock to describe an external clock most accurately represent the clocking topology of the design and they also help in specifying clock uncertainty.
Please see the following documentations:
Regards,
Nurina
Occasional ContributorThank you for answering.
As you pointed out, the physical clock is the base clock.
Thank you for your detailed explanation.
