Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎06-09-2011

clock rise to fall timing error


I am designing a board which contains a fast ADC with DDR output bus of 500 MHz clock!. I have decided to choose xc7a15t-3fgg484 to read ADC data!. I use a FIFO and write these data in the input with 500 MHz clock and read it with half clock speed but double width in order to prevent working in speed boundaries of Artix-7. Clocks have constraints and design - up to this stage - is placed & routed without any error. However, when I look at the clock interaction report I see this relatively fast 500 MHz input clock - which is fed to PLL and I am using its shifted output for reading DDR bus - has failure with itself!. Below picture:


Should I consider it as a design failure or not?! If yes, why I don't see any error messages.


Thanks in advance,





0 Kudos
1 Reply
Registered: ‎01-23-2009

Yes, this is a design failure.


It should also show up in a report_timing or report_timing_summary.


Presumably this is the path from the Q2 output of the IDDR to the fabric flop on the rising edge of the clock - at 500MHz, this is a 1ns path, which is basically impossible to meet.


You should look at the "SAME_EDGE" mode of the IDDR. In this mode, the IDDR does the transfer from the falling edge to the rising edge inside the IDDR, so it can probably work at this speed. However, this introduces an extra pipeline delay on the Q2 path of the IDDR. You may need a similar pipeline delay on the Q1, which can be done in the fabric, or can be done using the SAME_EDGE_PIPELINED mode of the IDDR.


Alternatively, you should be doing all of this in an ISERDES - this cell is specifically designed to allow for high speed capture without bringing the high speed clock domain into the fabric of the FPGA (which is causing you all kinds of problems).


At any point in your (multiple) threads on this design have you considered the input timing to this IDDR (or ISERDES - it would be the same). You say you are running at 500MHz DDR, which is a 1ns bit period. Do you have proper input constraints on these signals (set_input_delay commands which properly describe the timing characteristics of the interface based on the sending device and the board propagation)? It is virtually inconceivable that these paths will pass in an Artix-7 - even in the -3 speedgrade. Static capture of a synchronous bus starts failing well below this rate. I believe you said this is coming from an ADC (and hence truly is digital and synchronous) - there is no way that this is going to work without dynamic calibration...



0 Kudos