Forum Discussion
Occasional ContributorSetup slack violations?
Hi,
I have a design implemented in a Cyclone 10LP device, but I am struggling a bit with the Timing Analyzer. I am using Quartus Prime Lite edition 24.1.
The setup-slack is violated for a number of paths, but I need some help interpreting the waveform shown in the attachment.
And, looking at the path in Technology Map viewer I also struggle on how to improve the timing. How can I attack the issue?
A pointer to relevant documentation is highly appreciated
8 Replies
ShengN_alteraSuper Contributor
Seems like both the launch and latch clocks are asynchronous which causes the cdc with high clock skew. Please refer this link https://www.intel.com/content/www/us/en/docs/programmable/683243/22-4/constraining-cdc-paths.html for constraining cdc path.
cjakThanks for the quick response.... I have a follow question though...
If I have understood how to constrain I/O's, the launch clock is an internal PLL-output and the latch-clock is a virtual clock to emulate the external device. Is it required to insert CDC-constraints for all virtual clocks emulating latch-clock in external devices?
What about I/O that is not latched in external devices? How do I constrain them?
- ShengN_altera
May I confirm that the latch-clock is a virtual clock to emulate the external device means?
Means 1: External device latches using its OWN internal clock. If yes, this is asynchronous.
Means 2: FPGA sends a forwarded clock to the external device (external device clock derived from FPGA PLL/CLOCK). If yes, this is source synchronous.
What about I/O that is not latched in external devices? How do I constrain them? Simply mark as false path because there is no capture edge on the external side, so STA cannot define a setup or hold window. Any timing analysis from FPGA internal clock to that I/O is meaningless.
- cjak
Hi,
In this case it is asynchronous. The MCU latches the signal with its own internal clock.
I also have an ADC in my system which receives its clock from the FPGA (PLL-output/2). What are the considerations I need to make when constraining this? It is routed to PLL1_clkoutp-pin, but currently it is just a PLL-output divided by 2 (by inverting/toggling a signal based on the PLL-output frequency).
I will insert false-paths for the IOs. Thanks!
- cjak
Also, the from-node and to-node are the same net internal in the FPGA, so I do not see why it should be defined as false-path... maybe I have not understood if correctly?
