Forum Discussion
Occasional ContributorAbout loading constraints
The constraints you used will remove the Unconstrained path being reported out because the -to node (RLO_CLK_node) that is false path is the same.
At the end, designers need to know their design requirement and know where & when to use set_false_path. These constraints tell Timing Analyzer not to analyze specific paths or clock transfers. Once a path has been cut by either of these commands, there is no way to un-cut it, i.e. these constraints have the highest priority.
Regards,
Richard Tan
Super ContributorI try some iterations and the constraints below will works:
set_false_path -from [get_ports {RLO_CLK}] -to [get_pins {s_rlo_clk_det[0]|data*}]
Same with :
set_false_path -from [get_ports {RLO_CLK}] -to [get_pins {s_rlo_clk_det[0]|*}]
My guess is the pin datac might be changeable during compilation/design optimization, causing it not recognizable by the tool. Adding the asterisk (*) wildcard will help to ensure the constraints is applied to objects that match that pattern. In the above sdc example, any path -to the reg or the reg's data pin will be false path.
In future, if you see similar behavior, try to use the asterisk (*) wildcard instead. You can verify whether the false path constraint is applied in the timing analyzer (Report False Path).
Regards,
Richard Tan
Yamada1Thank you for answering.
I understand that this can be avoided by using wildcards.
Also, I just noticed that line 17 of the sdc file doesn't seem to be applied either.
No particular message appears, but when you look at "Unconstrained Paths", RLO_CLK_NODE remains unconstrained.
It would be helpful if you could provide us with information regarding this.
We apologize for the inconvenience and appreciate your understanding.
