cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
6,767 Views
Registered: ‎01-22-2015

reset-bridge clarification

Jump to solution

The importance of using a reset-bridge to bring a global asynchronous reset into each clock-domain as a synchronous reset was explained by Avrum at <this link> .  The VHDL version of the reset-bridge shown below is from Cummings at <this link>

 

signal asyncrst_n, rst_n, rff1 : std_logic;
...
process (clk, asyncrst_n)
begin
  if (asyncrst_n = '0') then
    rff1 <= '0';
    rst_n <= '0';
  elsif (clk'event and clk = '1') then
    rff1 <= '1';
    rst_n <= rff1;
  end if;
end process;

 

This VHDL reset-bridge looks very much like a 2-flop synchronizer that brings asyncrst_n into the "clk" clock-domain as rst_n, or am I missing some subtle difference?

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
10,814 Views
Registered: ‎01-23-2009

The reset bridge is very similar to the two stage synchronizer. It works on the same principle; that the first flip-flop can go metastable after the asynchronous event, but the probability of the 2nd flip-flop also going metastable is significantly reduced.

 

The difference is that the asynchronous reset input asyncrst_n is used as the asynchronous clear of the two synchronization flip-flops. The deassertion of reset (in this case the 1, since this is an active low reset bridge generating an active low reset) is done by the fact that the D input of the first flip-flop is tied to 1.

 

Here is a diagram of an active high reset bridge.

 

ResetBridge.jpg

 

The advantage of this over a conventional 2 stage synchronizer with the rst_in coming in through the D input is that the bridge asserts rst_out combinatorially when rst_in is asserted - even if there is no clock. So the reset bridge generates a reset (rst_out) that is asynchronously asserted, but synchronously de-asserted.

 

Avrum

View solution in original post

Tags (1)
0 Kudos
6 Replies
Highlighted
Guide
Guide
10,815 Views
Registered: ‎01-23-2009

The reset bridge is very similar to the two stage synchronizer. It works on the same principle; that the first flip-flop can go metastable after the asynchronous event, but the probability of the 2nd flip-flop also going metastable is significantly reduced.

 

The difference is that the asynchronous reset input asyncrst_n is used as the asynchronous clear of the two synchronization flip-flops. The deassertion of reset (in this case the 1, since this is an active low reset bridge generating an active low reset) is done by the fact that the D input of the first flip-flop is tied to 1.

 

Here is a diagram of an active high reset bridge.

 

ResetBridge.jpg

 

The advantage of this over a conventional 2 stage synchronizer with the rst_in coming in through the D input is that the bridge asserts rst_out combinatorially when rst_in is asserted - even if there is no clock. So the reset bridge generates a reset (rst_out) that is asynchronously asserted, but synchronously de-asserted.

 

Avrum

View solution in original post

Tags (1)
0 Kudos
Highlighted
6,713 Views
Registered: ‎01-22-2015

...the reset bridge generates a reset (rst_out) that is asynchronously asserted, but synchronously de-asserted.

 

Got it! - Thanks

 

We should set ASYNC_REG=TRUE for both registers used in the reset bridge?  

 

Must I write any timing exceptions for the reset bridge?

 

0 Kudos
Highlighted
Guide
Guide
6,695 Views
Registered: ‎01-23-2009

We should set ASYNC_REG=TRUE for both registers used in the reset bridge?  

 

Yes.

 

Must I write any timing exceptions for the reset bridge?

 

Yes. Depending on where the rst_in comes from, it normally needs an exception. This is one of the few cases that I would consider using a set_false_path

 

set_false_path -to [get_cells signal_meta_reg]

 

But you could also use a set_max_delay -datapath_only.

 

In some methodologies (generally before Xilinx implemented the ASYNC_REG property), I would also have considered an exception between the two synchronizer flops:

 

set_max_delay -from [get_cells signal_meta_reg] -to [get_cells rst_out_reg] 2

 

to constrain the routing between the two flip-flops to be significantly less than one clock period, but with the ASYNC_REG, this probably isn't necessary anymore...

 

Avrum

0 Kudos
Highlighted
Observer
Observer
1,452 Views
Registered: ‎11-16-2015

Hello avrumw, 

First of all thank you very much for all the information you share in this forum.

A quick question that I didn't find an answer to in this and other similar posts. Is it necessary to set the path from `rst_in` to `rst_out_reg` (second FF of the bridge) also as a false path?

I understand that the asynchronous reset feeds the asynchronous clear/preset of both flip flops on a reset bridge. Even so, is the recommended approach to set the false path only up to the first FF? 

From another answer that you posted, another alternative for constraint is:

set_false_path -from [get_ports rst_in]

in case `rst_in` was a top-level port. I assume this approach would lead to both paths (to `signal_meta_reg` and `rst_out_reg`) being set as false for timing.

In my particular case, my top level VHDL entity has three instances: the reset bridge, block 1 that operates on clock domain 1 and block 2 that operates on clock domain 2. The original reset is ready for block 1, but goes through the bridge prior to being connected to block 2. So I assume the latter approach of setting false path "from rst_in port" would not be applicable given block 1 uses the reset signal as is and I assume timing should not be ignored in this case.

What would you recommend? Do I need something more specific like the following:

set_false_path -from [get_ports rst_in] -to [get_cells signal_meta_reg]
set_false_path -from [get_ports rst_in] -to [get_cells rst_out_reg]

Thanks

0 Kudos
Highlighted
1,415 Views
Registered: ‎01-22-2015

@igorauad 

Since Jan2017 when I started this thread, I have learned much from Avrum.  I hope you (and he) won’t mind if I try to answer your questions.

The Vivado schematic below will help us talk about your questions, where RSTI is an asynchronous reset input to the FPGA.
reset_bridge2.jpg

The only constraints needed to make the Reset Bridge work are the following since they tell Vivado to place the two registers of the Reset Bridge physically close to each other (ie. in the same slice of the FPGA):

set_property ASYNC_REG TRUE [get_cells {RSTB/meta_rst_reg}]
set_property ASYNC_REG TRUE [get_cells {RSTB/rst_out_reg}]

All other constraints that we write for the Reset Bridge are only nice-to-have (ie. not necessary) because they free-up timing analysis to do more important things (than analyzing paths that need not undergo timing analysis).

The path (meta_rst_reg/C to rst_out_reg/D) between the Reset Bridge registers MUST pass timing analysis if the Reset Bridge is to combat metastability and output a clean reset signal.  However, since the ASYNC_REG=TRUE constraints are holding the registers physically close, then the path between the registers WILL pass timing analysis.  So, no worries here and no new nice-to-have constraints are needed.

All paths (-from rst_out_reg/C) coming out of the Reset Bridge MUST pass timing analysis.

As Avrum suggests, it is nice-to-have constraints that false-path the paths ending at the PRE pin inputs to the Reset Bridge registers.

set_false_path -to [get_pins {RSTB/meta_rst_reg/PRE}]
set_false_path -to [get_cells {RSTB/rst_out_reg/PRE}]  

Alternatively, you can sometime use Avrum’s other suggested constraint:

set_false_path -from [get_ports RSTI]

However, unless port RSTI is feeding only Reset Bridges then this alternate constraint may reach circuits that it shouldn’t reach.  For example, in the circuit above, RSTI directly drives dat1_reg in the clk_out1 clock-domain.  So, the above constraint will reach dat1_reg/R, which is probably a bad thing.  That is, we almost always want resets to come-off synchronously with the clock in the clock-domain (which is just what the Reset Bridge does for us).  So, in this case, it is recommend that RSTI feed a second Reset Bridge whose output feeds dat1_reg/R and the clk_out1 clock-domain.

Finally, if the above set_false_path constraints receive warnings from Vivado, it may be because RSTI cannot be a legal starting point for a timing path until you write the following dummy set_input_delay constraint:

set_input_delay -clock CLK_IN 1.0 [get_ports RSTI ]

Mark

 

Highlighted
Observer
Observer
1,407 Views
Registered: ‎11-16-2015

markg@prosensing.com 

Thank you very much for the thorough explanation. It is absolutely clear to me know.

The constraints to both RSTB/meta_rst_reg/PRE and RSTB/rst_out_reg/PRE are primarily what I wanted to understand. In my first attempt, I added a false path only to the first FF (RSTB/meta_rst_reg/PRE) and there was a timing violation in the timing report with respect to the second FF. So it is clear to me now that both constraints (or alternative approaches that we discussed) are needed.

Best regards,

Igor

0 Kudos