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: 
Observer jsduran4xilinx
Observer
3,235 Views
Registered: ‎11-07-2016

reset recover check being carried out against wrong edge

Hello.

 

I am in Vivado 2016.2 on a Ubuntu 14 box.

 

My system is failing reset recovery timing check but according to the timing report the check is being carried out against the rising edge of the CLR signal.  A reset recovery check is supposed to check that there is sufficient time between the *release* of the reset and the next rising clock edge.  So here the CLR edge to check should be the falling edge, not the rising edge.  Please refer to the attached screenshot.

 

What am I missing?

 

Many thanks in advance.

recovery_check.png
0 Kudos
5 Replies
Scholar watari
Scholar
3,219 Views
Registered: ‎06-16-2013

Re: reset recover check being carried out against wrong edge

Hi @jsduran4xilinx

 

Because of your design uses synchronous reset at "design_2_i/CHCAX_0/inst/chca_i0/chca_hqm_i0/chca_hqm_txmsg_i0/ctx_txmsg_data_r_reg[149]", you don't find reset recovery check on this STA report.

 

If your design want asynchronous reset, you should change the description at "design_2_i/CHCAX_0/inst/chca_i0/chca_hqm_i0/chca_hqm_txmsg_i0/ctx_txmsg_data_r_reg[149]".

 

Thank you.

Best regards,

0 Kudos
Highlighted
Historian
Historian
3,203 Views
Registered: ‎01-23-2009

Re: reset recover check being carried out against wrong edge

So, first of all, it isn't possible to tell from this report whether the CLR is active high or active low. The FDCE has a parameter IS_CLR_INVERTED which determines the polarity of CLR.

 

However, I don't think any of this matters. Since the FPGAs are programmable logic, most (all?) of the cells are symmetrical - equal on the 0-1 and 1-0 transitions. For this reason, I don't think Xilinx pays much attention to the polarity of the asynchronous preset/clear signals for static timing purposes - it simply times both edges of the signal.

 

While (assuming IS_CLR_INVERTED Is not set) your assertion would be true (the rising edge of CLR would be a false path), the tools probably just don't do this.

 

You can, of course, set this as a false path yourself using

 

set_false_path -rise_to [get_pins <...>/CLR]

 

I suspect that this won't matter - it will just end up showing you the (real) failing falling path timing check.

 

You haven't told us the actual clock periods, but these two clocks have a very odd timing relationship to eachother. If it is timing 9.999ns to 11.110ns, this path is basically impossible to meet - this is a 1.111ns requirement (which is probably too fast).

 

Avrum

Tags (1)
0 Kudos
Observer jsduran4xilinx
Observer
3,166 Views
Registered: ‎11-07-2016

Re: reset recover check being carried out against wrong edge

Thanks Watari.

 

Now why do you say my design uses synchronous reset at the destination register?  I checked and it is coded (RTL) as asynchronous.  Also, the CLR input to the FDCE looks like an asynchronous input to me.

0 Kudos
Observer jsduran4xilinx
Observer
3,164 Views
Registered: ‎11-07-2016

Re: reset recover check being carried out against wrong edge

Thanks Avrum,

 

Each of your points is worth pursuing.  I'll update with how it goes.

 

The timing weirdness is due to the MCMM.  There is another thread around the time of this one, which I started, which deals with this question.  There is a link there to yet another thread and the exchange there is useful -- things make sense in the end (after a couple of notebook pages worth of diagrams).

0 Kudos
Observer jsduran4xilinx
Observer
3,162 Views
Registered: ‎11-07-2016

Re: reset recover check being carried out against wrong edge

I meant the MMCM, sorry.

0 Kudos