- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It would be helpful if you could teach us the following points about virtual clocks.
1) The timing analyzer user guide states that it is used to limit the data output from the FPGA to the external device, but is that understanding correct?
2) If you search on the web, you will find an article stating that a virtual clock is specified when restricting I/O regardless of input/output. Should I use a virtual clock for I/O constraints even if the design receives data on that clock?
Sorry for the elementary question, but it would be helpful if you could teach me.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for answering.
Thank you for your detailed explanation.
The part "limit the data output from the FPGA to the external clock." I intended to describe the configuration of Figure 45 in the Timming Analyzer User's Guide.
It seems to be a problem with the original text here, but it seems that the machine translation made the sentence incomprehensible. very sorry.
It was very helpful to know that a virtual clock is required for synchronous I/O timing analysis.
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?
Sorry for the inconvenience, but thank you in advance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
"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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for answering.
As you pointed out, the physical clock is the base clock.
Thank you for your detailed explanation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, please login to https://supporttickets.intel.com , view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.
p/s: If any answer from community or Intel support are helpful, please feel free to mark as solution, give Kudos and rate 4/5 survey
Regards,
Nurina

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page