Showing results for 
Show  only  | Search instead for 
Did you mean: 
Not applicable

set false path

I am designing with Zynq Device on Vivado.

I have an asynchronous reset , which is de-asserted synchronously by a clock.

Do I need to give false path to the synchronized reset(de-asserted only) to that clock domain(which used to synchronize it).

What is the recommended method. Anybody please help.


0 Kudos
5 Replies
Registered: ‎05-25-2015

If your reset is de-asserted synchronously why do you think that it is an asyncronous reset ?


0 Kudos
Xilinx Employee
Xilinx Employee
Registered: ‎05-07-2015

By asynchrnous assert and synchronous deassert , i assume you intend to  implement the equivalent topology as shown below and you will probably add a BUFG at the end to distribute the reset_out signal to  the FPGA resources.


Now, do you mean to ask
1) whether you need apply false_path constraint from Q1 to D2?  (NO you need not obviously) or 
2) Do you mean to ask a false path from Q2 to rest of the FPGA?
As reset_out will not be going to D input of any  other Flipflop  and only goes to their SET/CLR control inputs. I am positively sure that you need not apply any  false path constraints.
Update me if I'm missing anything here.

Kindly note- Please mark the Answer as "Accept as solution" if information provided solves your query.
Give Kudos (star provided in left) to a post which you think is helpful and reply oriented.

Please mark the Answer as "Accept as solution" if information provided addresses your query/concern.
Give Kudos to a post which you think is helpful.
Registered: ‎01-23-2009

@nagabhar - thanks for the picture.

This is a classic reset synchronizer (or "reset bridge"). There are a number of constraints necessary on them. I will assume the first FF is called "rst_meta_reg" and the second one "rst_dst_reg".

First, you need to set the ASYNC_REG property on both the FFs

set_property ASYNC_REG TRUE [get_cells {rst_meta_reg rst_dst_reg}]

Next (and this is somewhat up for debate), you should put a constraint between the two FFs. As designed, the tools will allow for one full clock period of propagation between the FFs, whereas you want to reserve some for metastability resolution, so you can put

set_max_delay -from [get_cells rst_meta_reg] -to [get_cells rst_dst_reg] 2

I use 2ns because the tools can just meet that (you can try 1.5), so the rest of the clock period is reserved for metastability resolution.

But (and this is, I think, the original question), you also need an exception on the RESET_in - this is a true false path. This can be done with

set_false_path -from [get_ports RESET_in_pin]; # assuming RESET_in_pin is the top level port of the design


set_false_path -to [get_cells rst_meta_reg]

But, as others have observed, that is the only false path - the RESET_out to the actual FFs is not false. Yes, the asserting edge technically is, but since the timing in Xilinx is symmetrical (rising and falling edges have the same propagation) you don't get any advantage from declaring it false. However, just for fun, here is how you would do it...

set_false_path -fall_from [get_cells rst_dst_reg]; # since this is an active low reset, the falling edge is the asserting edge

One note, though, it is encouraged to use active high resets - in this diagram, both the RESET_in and RESET_out are active low (and should probably be named RESET_in_N and RESET_out_N). To use active high resets, use the PRE port of the FF without inversion, and tie the D input to a 0.


Tags (2)
Registered: ‎01-15-2013

@avrumw : 


Just out of curiosity, is there any particular reason why you mentioned " One note, though, it is encouraged to use active high resets". 



0 Kudos
Registered: ‎01-23-2009

Just out of curiosity, is there any particular reason why you mentioned " One note, though, it is encouraged to use active high resets". 

So lets start with the first possible answer - why not?

For all other logic (other than resets, read/write enables and chip selects) we use active high signals. People in general are more comfortable with active high signals - that's how we think. Using active low signals creates a (small) opportunity for us to make silly mistakes, especially when we are combining the reset condition with some other condition - we don't do Boolean reduction with active low signals well in our heads...

So why do we use active low resets? The reason for this traces back into the mists of the prehistoric digital era...

In ancient times (while we were carving out schematics on rocks using chisels), we used Resistor-Transistor Logic (RTL - not to be confused with register transfer language), Diode-Transistor Logic (DTL), and Transistor-Transistor Logic (TTL). In these technologies, a signal that was at the "low" condition drew power, whereas a signal that was at the "high" condition did not. Therefore, to minimize power dissipation in these devices, whenever it was possible, if you could identify a signal that spent the majority of the in one logic state, it made sense to map that state to the "high" condition.

This was clearly true of resets - resets are active for only a small amount of time, and then remain inactive for the rest of the time that the circuit is running. Therefore, it made sense to map the inactive state to the lower power state, which is "high" - thus making the reset active low (RSTn).

The same is true for read enables and write enables - we never assert both at the same time, and there are definitely times when we are doing neither reads nor writes, so these signals spend more time inactive than active. So we used active low signals for these too (RDn and WRn).

Similarly for chip selects. Often chip selects are used to select "which one out of N devices/blocks is this operation targeted to". In an address mapped system, this is never more than one out of the N (and there are also times when we aren't accessing any device), and hence all N or at least N-1 of these signals are inactive at any given time. So, again, we mapped the more common condition to the low power state ("high"), hence active low chip selects (CSn).

In CMOS, neither the "high" state nor the "low" state draw more static power - power is drawn through leakage (which is independent of the logic value) and during transitions (dynamic power). So there is no power advantage to using active low signals.

These old technologies (RTL/DTL/TTL) have not been in common use for 3 or 4 DECADES! And yet we hang on to this archaic use of active low signals because of them - it is time to let them go!

Now on to the more practical. In all technologies up to the 7 series, the reset input (at the slice boundary) to Xilinx CLBs had an optional inverter. The flip-flops themselves always used active high resets (synchronous or asynchronous), but the devices accommodated active low resets through the use of this inverter.

In the 7 series, Xilinx decided that what I described above was absolutely ridiculous, and they removed the inverter from the slice boundary - this reduced the slice size (ever so slightly). Thus to accommodate an active low reset, a LUT needed to be used to invert the reset prior to entering the slice. This could result in as few as one extra LUT used in the design, or, depending on how the hierarchy was structured, a fair number of LUTs. 

Unfortunately, this dogged determination to stick with active low resets remained (including in lots of Xilinx IP that still uses active low resets), so in the UltraScale and UltraScale+ architectures, Xilinx relented, and put the inverters back. 

So, from an architectural point of view, it only now matters in 7 series - active high resets are faster (no LUT in the critical path) and make smaller designs (no LUTs used for inverting the reset). In other architectures it makes no difference. However, in all architectures, you should never mix them - use either all active high (I still prefer this) or all active low; Xilinx slices cannot mix both in the same slice - these are different "control sets"...

But the first point remains - active low signals are counter-intuitive, and (ever so slightly) more error prone - why do we still use them?


Tags (2)