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: 
Scholar embedded
Scholar
2,063 Views
Registered: ‎06-09-2011

ODDR Clock to reset Timing Failure

Hi all,

 

I am using xc7a15t-3FGG484 in a design. I am going to write to external SRAM memory. My SRAM clock is 250 MHz!. I am going to feed it through an IO pin of FPGA. I receive below timing error as an indication of timing failure!. 

Summary				
Name	Path 21			
Slack	-0.206ns			
Source	FastReset_INST/oSyncRst_reg/C   (rising edge-triggered cell FDPE clocked by oSysClk250_SysClk  {rise@0.000ns fall@2.000ns period=4.000ns})			
Destination	ExtMemClkODDR_INST/R   (falling edge-triggered cell ODDR clocked by oSysClk250_SysClk  {rise@0.000ns fall@2.000ns period=4.000ns})			
Path Group	oSysClk250_SysClk			
Path Type	Setup (Max at Slow Process Corner)			
Requirement	2.000ns (oSysClk250_SysClk fall@2.000ns - oSysClk250_SysClk rise@0.000ns)			
Data Path Delay	1.651ns (logic 0.341ns (20.657%)  route 1.310ns (79.343%))			
Logic Levels	0  			
Clock Path Skew	-0.138ns			
Clock Uncertainty	0.054ns			

This is ralted to the path from Reset Synchronizer to the reset pin of my ODDR which below picture draws it:

Untitled.jpg

I am wondering why I should receive error for such a relatively low frequency in Artix-7 architecture!. 

I am also wondering if ignoring this error would affect my system work and reliability?

I would appreciate any help,

Hossein

0 Kudos
2 Replies
Voyager
Voyager
2,038 Views
Registered: ‎06-24-2013

Re: ODDR Clock to reset Timing Failure

I am wondering why I should receive error for such a relatively low frequency in Artix-7 architecture

The requirement in your case is 2ns and you are missing it by 206ps in the worst case so not that much.

Most of the path delay is due to routing, so it looks like the reset logic was placed further away from the ODDR than necessary.

 

I am also wondering if ignoring this error would affect my system work and reliability?

That really depends on the conditions, i.e. how often this path is used, how much the environment changes, etc.

In general a timing error means that something is wrong and reliability or functionality is reduced.

 

I would appreciate any help,

My suggestion is to try to optimize the design and/or revisit placement/routing to meet the requirement.

 

Hope that helps,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
Historian
Historian
2,022 Views
Registered: ‎01-23-2009

Re: ODDR Clock to reset Timing Failure

The "problem" with this path (and the same for your other path in https://forums.xilinx.com/t5/Timing-Analysis/Clock-to-Reset-timing-failed/td-p/783451), is that the ODDR and IDDR work on both edges of the clock. Thus, the R input has setup checks to both the rising and falling edges of the clock. This makes these paths 1/2 clock cycle timing paths; here that becomes a 2ns path, but in the other post it is a 1ns path. A 2ns path is hard, a 1ns path is pretty much impossible.

 

The "best" solution in these cases (if you can) is simply to not use the R input - tie it inactive. For the ODDR, this means that during the first clock after reset is asserted, the output will be unknown (really 0, since this is what the INIT value of the flip-flop is). On the second clock of reset, it will clock out the values provided on the inputs - if the flip-flops that generate this are reset, then the ODDR will be in a known state after the 2nd clock of reset.

 

For the IDDR you have a similar thing. If you tie off the R input, then the output of the IDDR will always follow the input. If the rest of your design is in reset, this is not a problem. On the deasserting edge of reset, your system will start responding to the value of the input one clock sooner, since the outputs of the IDDR won't have been in reset during the previous clock (or ever).

 

This also goes towards a larger question - whether you need resets at all. The Xilinx recommendation is to remove user resets where possible. The argument is that all flip-flops come up in a known state after configuration. In many cases, this recommendation is a good one - it has lots of advantages in terms of reducing routing complexity and improving overall timing. However, sometimes Xilinx gets a little over aggressive in pursuing this "recommendation" - in most circuits there are at least some parts of the design that still need an explicit reset, and cannot simply rely on the INIT value of the flip-flop (as maintained by the Global Set Reset - GSR) - see this post on the use of resets and the GSR.

 

Avrum

Tags (2)
0 Kudos