- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Attempted to add CDC module (VHDL) with the following attributes applied (taken from Intel/Altera example):
ATTRIBUTE altera_attribute : string;
ATTRIBUTE altera_attribute OF ff1 : signal is "-name SYNCHRONIZER_IDENTIFICATION ""FORCED IF ASYNCHRONOUS""";
ATTRIBUTE altera_attribute OF CDC_Behav : architecture is "-name SDC_STATEMENT ""set_false_path -to *|CDC_DATA:*|ff1 """;
Note that ff1 is the input FF that receives the incoming (from slower clock domain) signal to be sync'd to system clock (faster clock domain).
CDC_Behav is the architecture name of this module.
CDC_DATA is the entity name for this module.
This fails completely - Ignored Constraints report shows this constraint was, uhmm, ignored:
Does the MAX10 not support this constraint? If not, how to handle this?
If it does support, can any one tell me what is wrong with the above constraint?
Thank you.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you try to put this constrain in the sdc files?
go to File -> new -> other files -> Synonopsis Design File
Right click on it and insert the command that you want.
Compile the design to see if it still got ignored.
If no, use this way instead of using an Attribute.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Any update?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, apologies for late reply - sidetracked on another project. I tried your suggestion to add a false_path constraint into the sdc file: set_false_path -from [get_clocks *] -to [get_registers {CDC_2FF:inst14|ff1}]
The -to ... ff1, is the first register in the CDC (clock domain crossing) module. The sdc false_path wizard created the -from [get_clocks *] even tho I had selected the clock signal name for the source clock, that originates from the pll. (the destination clock also originates from the same pll, at a higher frequency than source).
There were no warnings/errors re. failed constraint during compile. However, the false_path didn't have any effect; same timing error. Timing Analyzer - report false_path returned "nothing to report" which seems to indicate the above constraint didn't capture the path correctly? I am not understanding what it takes to get a false path to work with this part family. Maybe you can point me to a specific real-world example of how to apply a false path constraint to a CDC module?
Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In the timing analyzer, there is a report mention about ignored constraint. You can double click it to see your constraint take effect there.
Looking into your constrain set_false_path -from [get_clocks *] -to [get_registers {CDC_2FF:inst14|ff1}]
This will be incorrect because you cannot set the * there to get clocks. I
My suggestion is to get the register that you want to false path.
set_false_path -from [get_registers <register name>] -to [get_registers {CDC_2FF:inst14|ff1}]
We do not use false path from clock to register.
either way, you can use set_clock_groups, this will false path the clock in two directions
Here is the link for reference:
https://www.intel.com/content/www/us/en/programmable/quartushelp/13.0/mergedProjects/tafs/tafs/tcl_pkg_sdc_ver_1.5_cmd_set_false_path.htm
https://www.intel.com/content/www/us/en/programmable/quartushelp/13.0/mergedProjects/tafs/tafs/tcl_pkg_sdc_ver_1.5_cmd_set_clock_groups.htm
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Thank you for the helpful reply.
You pointed out a subtle but significant detail that wasn't apparent from the descriptions of set_false_path usage. Whereas the description states the '-from' must be a clock pin, it does not distinguish that pin must be at a register or node as you pointed out. Per your suggestion, I took a look at the set_clock_groups constraint.
I also found the following page to be really helpful as far as all timing constraint usage : https://www.intel.com/content/www/us/en/programmable/documentation/ony1529966370740.html?wapkw=difference%20create_clock%20create_generated_clock#mwh1410383723620
Following the examples at the above link, it appears that set_clock_groups constraint works; timing was met, with no warnings issued in regards that constraint, and Timing Analyzer - Ignored Constraints was empty.
I have one other CDC issue involving the incoming (from the board) RESET signal. The difference here (from the previous CDC case) is the signal originates from an input pin with no associated clock, and it's de-assert is completely random. Similar to the previous CDC, the following attributes were used in the vhd file and rejected (warning issued) by the tools :
ATTRIBUTE altera_attribute OF ff1_80 : signal is "-name SYNCHRONIZER_IDENTIFICATION ""FORCED IF ASYNCHRONOUS""";
ATTRIBUTE altera_attribute OF CDC_Behav : architecture is "-name SDC_STATEMENT ""set_false_path -to *|RESET_SYNC:*|ff1_80 """;
Based on your previous post, I chose to replace this with a set_false_path constraint from the "RESET~input|i pin" input (-from), to the first register of the CDC module (ff1). Again the Timing Analyzer shows no ignored constraints so I assume this constraint is correct:
set_false_path -from [get_pins {RESET_N~input|i}] -to [get_registers {RESET_SYNC:inst6|ff1_UC}]
Is this the best approach for handling an incoming asynchronous reset in the MAX10 part? (the goal in this case is to make sure the de-assert of the incoming reset is glitch-free into the receiving clock domain).
Thank you again for your time and help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Our advise is always use synchronous reset, if you have asynchronous reset, you can synchronize it with the below method:
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/qts/qts_qii51006.pdf
page 12-8
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Any further question?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
HI KTan, re this issue, your advice got this resolved.
I have another issue open, re. a AVSPI core I generated in QuartusII, that fails to compile -- error on attributes inside one of the core files.
Someone picked this up but have not heard back for over a week.
If you are able to take a look, it is here:
https://forums.intel.com/s/question/0D50P00004Ye0HJSAZ/avspi-core-attributes-failure
Thank you for your time and help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Seems like it had been updated just now for your forum thread above.

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