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: 
260 Views
Registered: ‎02-23-2019

Same-Edge capture edge-aligned DDR input fails timing?

Jump to solution

Using Vivado 2019.1 and a xcku060-ffva1517-2-e device. It has a edge-aligned DDR interface to an ADC implemented as follows:

DDRschematic.JPG

Following the recommendations by @avrumw in How to constraint Same-Edge capture edge-aligned DDR input properly? (cheater method), I implemented the following constaints:

create_clock -period 4.568 -name RF0_ADC0_DCO_P -waveform {0.000 2.284} [get_ports RF0_ADC0_DCO_P]

# Input Delay Constraint: RF ADC Inputs
# Edge-Aligned Double Data Rate Source Synchronous Inputs
set input_adcclk_period 4.568; # Period of input clock (full-period)
set skew_bre 0.300; # Data invalid before the rising clock edge
set skew_are 0.300; # Data invalid after the rising clock edge
set skew_bfe 0.300; # Data invalid before the falling clock edge
set skew_afe 0.300; # Data invalid after the falling clock edge

set_input_delay -clock RF0_ADC0_DCO_P -max [expr $input_adcclk_period/2 + $skew_afe] [get_ports {RF0_ADC0_D_P[*]}];
set_input_delay -clock RF0_ADC0_DCO_P -min [expr $input_adcclk_period/2 - $skew_bfe] [get_ports {RF0_ADC0_D_P[*]}];
set_input_delay -clock RF0_ADC0_DCO_P -max [expr $input_adcclk_period/2 + $skew_are] [get_ports {RF0_ADC0_D_P[*]}] -clock_fall -add_delay;
set_input_delay -clock RF0_ADC0_DCO_P -min [expr $input_adcclk_period/2 - $skew_bre] [get_ports {RF0_ADC0_D_P[*]}] -clock_fall -add_delay;

The delay in the IDELAYE3 is set to 1/4 the clock period.  This fails static timing analysis for both setup and hold:

FailSummary.JPG

Have I improperly constrained the design (i.e. cheated on the cheater method)?  Is there a better implementation that would be more likely to meet timing? 

0 Kudos
1 Solution

Accepted Solutions
130 Views
Registered: ‎02-23-2019

Re: Same-Edge capture edge-aligned DDR input fails timing?

Jump to solution

Thanks for thorough response!  We will be pursuing dynamic capture, so if you have any resources or references that our particularly good on the topic, please point me to them.  Thanks again!

0 Kudos
6 Replies
Historian
Historian
239 Views
Registered: ‎01-23-2009

Re: Same-Edge capture edge-aligned DDR input fails timing?

Jump to solution

Show us the entire timing report for both the setup check and the hold check.

Avrum

0 Kudos
228 Views
Registered: ‎02-23-2019

Re: Same-Edge capture edge-aligned DDR input fails timing?

Jump to solution

I believe this is what wanted to see?

TimeReport.JPG

0 Kudos
221 Views
Registered: ‎02-23-2019

Re: Same-Edge capture edge-aligned DDR input fails timing?

Jump to solution

That was Setup... this is the Hold report...

TimeReport_Hold.JPG

0 Kudos
Xilinx Employee
Xilinx Employee
186 Views
Registered: ‎03-29-2013

Re: Same-Edge capture edge-aligned DDR input fails timing?

Jump to solution

Did you use the constraints templates to come up with the delay constraints? You can also use the Timing Constraints Wizard in Vivado IDE to do the same.

0 Kudos
Historian
Historian
148 Views
Registered: ‎01-23-2009

Re: Same-Edge capture edge-aligned DDR input fails timing?

Jump to solution

I see nothing obviously wrong with either the constraints or the design...

You are trying to do a 4.568ns period DDR interface - this means 2.284ns for each data period. The clock/data skew is +/-300ps, which leaves a data window of 1.684ns. This is pretty small...

I am not as familiar with the smallest period that UltraScale can do, but with the 7 series, this is at or just below the smallest window that can be captured statically - around 1.7ns of data window is where it becomes doable with "ChipSync" clocking. In UltraScale, due to the "flexible" clocking structure, the BUFGCE is a bit of a mixture of the BUFG and the BUFIO/BUFR in the 7 series - from these results, it appears to be a bit worse in terms of timing.

The delay in the IDELAYE3 is set to 1/4 the clock period.

There is nothing that says this is the correct amount; the setup/hold window of the ISERDES when clocked by the BUFG should not be assumed to be (and is not) symmetrical around the clock - to find the "best" setting for the IDELAY, you should look at the static timing results and adjust.

That being said, all changing the IDELAY can do is trade setup margin for hold margin - and you have neither - you are failing both. This is a clear indication from the tools saying "This interface with this timing characteristic captured with this clocking structure does not work".

I don't think there is a faster clocking structure - the datasheet in the UltraScale family only specifies the timing with the MMCM or PLL and a BUFG (tPSMMCM*/tPHMMCM*) - and the minimum window described there is 1.75ns (a bit better than what you are seeing here), it doesn't specify anything for direct capture (the equivalent of ChipSync) - you can take a look at this post on clocking structures (although it is for the 7 series).

So you can experiment with other clocking structures, and maybe take a look at/play with the CLOCK_ROOT of this global clock (although I am not sure it matters for input interfaces - at least if the clock and data are in the same I/O bank, which they really should be).

But, ultimately, it may be the case that this interface cannot be captured statically by this device, and you will have to investigate some kind of dynamic capture/training...

Avrum

0 Kudos
131 Views
Registered: ‎02-23-2019

Re: Same-Edge capture edge-aligned DDR input fails timing?

Jump to solution

Thanks for thorough response!  We will be pursuing dynamic capture, so if you have any resources or references that our particularly good on the topic, please point me to them.  Thanks again!

0 Kudos