07-10-2017 04:44 PM
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.
07-10-2017 06:51 PM
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", 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".
07-10-2017 07:04 PM
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).
07-11-2017 12:35 PM
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.
07-11-2017 12:40 PM
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).