UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor vascom
Visitor
9,294 Views
Registered: ‎09-17-2015

How to add reset_path constraint?

Jump to solution

I need to apply set_false_path to many nets. And then I am want exclude some nets from this constraint. But Vivado not allow use reset_path constraint.

 

What should I do to override set_false_path for some paths?

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Historian
Historian
15,620 Views
Registered: ‎01-23-2009

Re: How to add reset_path constraint?

Jump to solution

So, Vivado does not support the "reset_path" command. Furthermore, once a set_false_path command has been applied to a path, there is nothing that can override/remove it (short of doing a reset_timing which removes all timing constraints).

 

So, you will have to find a way to construct your set_false_path more carefully so that it does not apply to the paths you want to exclude.

 

However, I want to point out that the set_false_path command you are using is EXTREMELY DANGEROUS. You are disabling timing on all the asynchronous preset and clear inputs in all flip-flops in your design. In general, this is not a correct thing to do. It is essential to understand that the deasserting edge of the preset/clear pins must be synchronous and timed in order to ensure your design will come out of reset properly.

 

Unless you are doing something "special" in your design (like stopping the clocks around the deasserting edge of reset or clearly separating and constraining those FFs that need synchronous reset), this is almost certainly a design killer.

 

The deassertion of reset must be done synchronously. For many flip-flops, failure to do so will not yield a failure; if a flip-flop maintains the same state (under all conditions) during reset and on the first few clocks after reset is deasserted, then it will not exhibit a failure.

 

If, however, under any condition a flip-flop can make a state change on the first clock edge after reset is deasserted, then the system can fail - both due to metastability and due to coherency. For example, if a flip-flop is reset to the value 0 during reset (by an asynchronous CLR) and on the first clock that CLR is deasserted the flip-flop takes the value 1, then you have a potential metastability condition. If the CLR deasserts enough after the rising edge of clock the FF will remain in reset and retain the value 0. If the CLR deasserts enough before the rising edge of clock then the FF will clock in the value 1 on the rising edge. If the two events come too close together (violating the reset recovery check), then the flip-flop can go metastable and crash your system.

 

Furthermore if you have a state machine that is asynchronously cleared to the value 000 and on the clock after the deassertion of CLR it transitions to the state 111, then you have a coherency issue if the reset is not timed. If the CLR is not timed, then the propagation delay of the CLR to each of the 3 flops is unconstrained, and can be any length. On a given clock edge, you therefore have the possibility where some but not all of the FFs remain in CLR on a particular clock edge near the deassertion of CLR, but others do not. In this case your state machine can take literally any state - and your system has crashed.

 

So, for certain FFs, proper timing of the asynchronous PRE/CLR is essential.

 

If your plan was to disable all the paths and then re-enable them for the ones that matter (the ones that can transition after reset), then, as I said above, you can't do this since there is no reset_path command. Furthermore, this isn't generally useful in an FPGA.

 

In an FPGA, all flip-flops are initialized to the INIT value during the bitstream configuration stage. In hardware, they are held in the INIT state through an internal signal called GSR (Global Set Reset). This GSR effectively acts as an asynchronous preset/clear to all flip-flops in the design. The deassertion of GSR, though, is slow and not synchronous to any clock; therefore it suffers from the same problem I described above for your asynchronous PRE/CLR with timing disabled; potential metsatability and coherency problems in any flip-flop that can change state right after the deassertion of GSR.

 

So given that the GSR is no better/worse than your PRE/CLR with timing disabled, then you can accomplish the same thing (again, assuming you realize that some FFs need to be timed correctly coming out of reset) by physically removing the connections to the PRE/CLR pins that don't need to be timed and let the GSR take care of them, and then use a properly timed reset to those FFs that need them (with no timing exceptions). This has the significant advantage of removing all the logic and routing associated with the (useless) nets controlling the PRE/CLR pins of FFs that don't matter.

 

Avrum

6 Replies
Xilinx Employee
Xilinx Employee
9,282 Views
Registered: ‎08-01-2008

Re: How to add reset_path constraint?

Jump to solution
Example
From: set_false_path -from [get_cells -hierarchical -filter {NAME =~ *gsckt_wrst.gic_rst.garst_sync_ic[3]…..
To: set_false_path -from [get_cells -hierarchical -filter {NAME =~ *gsckt_wrst.gic_rst.garst_sync_ic[<=: $rst_sync_stages :>]…..

Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
Moderator
Moderator
9,279 Views
Registered: ‎01-16-2013

Re: How to add reset_path constraint?

Jump to solution
Hi,

Can you post how generic you are defining the constraints? and using -reset_path in command.

Thanks,
Yash

P.S. Exception constraint should be use as specific as possible to avoid constraint masking.
0 Kudos
Visitor vascom
Visitor
9,276 Views
Registered: ‎09-17-2015

Re: How to add reset_path constraint?

Jump to solution
I can't list all nets because it is more then 100000.
0 Kudos
Visitor vascom
Visitor
9,275 Views
Registered: ‎09-17-2015

Re: How to add reset_path constraint?

Jump to solution
I am want some like this:
set_false_path -from [get_pins module_rst_reg/C] -to [get_pins .*/(CLR|PRE) -regexp -hierarchical]
reset_path -to [get_pins -regexp -hierarchical -filter { NAME =~ ".*my_module_0.*/(CLR|PRE) " }]
0 Kudos
Highlighted
Historian
Historian
15,621 Views
Registered: ‎01-23-2009

Re: How to add reset_path constraint?

Jump to solution

So, Vivado does not support the "reset_path" command. Furthermore, once a set_false_path command has been applied to a path, there is nothing that can override/remove it (short of doing a reset_timing which removes all timing constraints).

 

So, you will have to find a way to construct your set_false_path more carefully so that it does not apply to the paths you want to exclude.

 

However, I want to point out that the set_false_path command you are using is EXTREMELY DANGEROUS. You are disabling timing on all the asynchronous preset and clear inputs in all flip-flops in your design. In general, this is not a correct thing to do. It is essential to understand that the deasserting edge of the preset/clear pins must be synchronous and timed in order to ensure your design will come out of reset properly.

 

Unless you are doing something "special" in your design (like stopping the clocks around the deasserting edge of reset or clearly separating and constraining those FFs that need synchronous reset), this is almost certainly a design killer.

 

The deassertion of reset must be done synchronously. For many flip-flops, failure to do so will not yield a failure; if a flip-flop maintains the same state (under all conditions) during reset and on the first few clocks after reset is deasserted, then it will not exhibit a failure.

 

If, however, under any condition a flip-flop can make a state change on the first clock edge after reset is deasserted, then the system can fail - both due to metastability and due to coherency. For example, if a flip-flop is reset to the value 0 during reset (by an asynchronous CLR) and on the first clock that CLR is deasserted the flip-flop takes the value 1, then you have a potential metastability condition. If the CLR deasserts enough after the rising edge of clock the FF will remain in reset and retain the value 0. If the CLR deasserts enough before the rising edge of clock then the FF will clock in the value 1 on the rising edge. If the two events come too close together (violating the reset recovery check), then the flip-flop can go metastable and crash your system.

 

Furthermore if you have a state machine that is asynchronously cleared to the value 000 and on the clock after the deassertion of CLR it transitions to the state 111, then you have a coherency issue if the reset is not timed. If the CLR is not timed, then the propagation delay of the CLR to each of the 3 flops is unconstrained, and can be any length. On a given clock edge, you therefore have the possibility where some but not all of the FFs remain in CLR on a particular clock edge near the deassertion of CLR, but others do not. In this case your state machine can take literally any state - and your system has crashed.

 

So, for certain FFs, proper timing of the asynchronous PRE/CLR is essential.

 

If your plan was to disable all the paths and then re-enable them for the ones that matter (the ones that can transition after reset), then, as I said above, you can't do this since there is no reset_path command. Furthermore, this isn't generally useful in an FPGA.

 

In an FPGA, all flip-flops are initialized to the INIT value during the bitstream configuration stage. In hardware, they are held in the INIT state through an internal signal called GSR (Global Set Reset). This GSR effectively acts as an asynchronous preset/clear to all flip-flops in the design. The deassertion of GSR, though, is slow and not synchronous to any clock; therefore it suffers from the same problem I described above for your asynchronous PRE/CLR with timing disabled; potential metsatability and coherency problems in any flip-flop that can change state right after the deassertion of GSR.

 

So given that the GSR is no better/worse than your PRE/CLR with timing disabled, then you can accomplish the same thing (again, assuming you realize that some FFs need to be timed correctly coming out of reset) by physically removing the connections to the PRE/CLR pins that don't need to be timed and let the GSR take care of them, and then use a properly timed reset to those FFs that need them (with no timing exceptions). This has the significant advantage of removing all the logic and routing associated with the (useless) nets controlling the PRE/CLR pins of FFs that don't matter.

 

Avrum

Explorer
Explorer
8,920 Views
Registered: ‎02-13-2012

Re: How to add reset_path constraint?

Jump to solution

First, completely agree with Avrum about the dangers of using set_false_path too indiscriminately.

 

Nonetheless, to specifically address the "here is what I want"....

set_false_path -from [get_pins module_rst_reg/C] -to [get_pins .*/(CLR|PRE) -regexp -hierarchical]
reset_path -to [get_pins -regexp -hierarchical -filter { NAME =~ ".*my_module_0.*/(CLR|PRE) " }]

 

From that, my interpretation is that you want a false path from "module_rst_reg" to all CLR and PRE pins except excluding the CLR and PRE pins in "my_module_0".  You can do that with boolean and inverse matching in the filter (note the highlighted characters):

set_false_path -from [get_pins module_rst_reg/C] -to [get_pins -regexp -hierarchical -filter {NAME =~  ".*/CLR"  && NAME !~  ".*my_module_0.*/CLR" }]

 

(do the same for PRE in a second line)