Forum Discussion

ESkul1's avatar
ESkul1
Icon for New Contributor rankNew Contributor
6 years ago

MAX10 set_false_path failure

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.

9 Replies

  • KennyT_altera's avatar
    KennyT_altera
    Icon for Super Contributor rankSuper Contributor
    6 years ago

    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.

  • ESkul1's avatar
    ESkul1
    Icon for New Contributor rankNew Contributor
    6 years ago

    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.

  • KennyT_altera's avatar
    KennyT_altera
    Icon for Super Contributor rankSuper Contributor
    6 years ago

    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's avatar
    ESkul1
    Icon for New Contributor rankNew Contributor
    6 years ago

    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.