MAX10 set_false_path failure

[ESkul1]

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.

[Kenny_Tan]

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.

[Kenny_Tan]

Any update?

[ESkul1]

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.

[Kenny_Tan]

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

[ESkul1]

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.

[Kenny_Tan]

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

[Kenny_Tan]

Any further question?

[ESkul1]

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.

[Kenny_Tan]

Seems like it had been updated just now for your forum thread above.