cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
quark21
Visitor
Visitor
259 Views
Registered: ‎02-23-2021

LVDS DDR ADC Interface at 437.5 MHz

Hello all,

I will preface my post by clearly stating that I'm a timing constraint novice in the truest sense. I'm attempting to interface an LVDS DDR ADC with a 7 series FPGA (Z-7030 with speed grade -1). The interface is currently operating without issue with a bit clock frequency of 280 MHz in 2-wire mode (see page 45 of the ADC datasheet linked above). I have inherited this project and have been tasked with attempting to operate the ADC at the maximum sampling rate of 125 MHz. This equates to a bit clock of 437.5 MHz. However, the interface fails at this frequency and no longer produces any valid data. I have realized that I need to apply new timing constraints to stand any hope of achieving the higher throughput. I have introduced the following constraints:

create_clock -period 2.285 -name adc_clk [get_ports adc_phy_dclk_p]

set_input_delay -clock adc_clk -max 1.865 [get_ports adc_phy_data*]

set_input_delay -clock adc_clk -clock_fall -max -add_delay 1.865 [get_ports adc_phy_data*]

set_input_delay -clock adc_clk -min 0.47 [get_ports adc_phy_data*]

set_input_delay -clock adc_clk -clock_fall -min -add_delay 0.47 [get_ports adc_phy_data*]

 

set_input_delay -clock adc_clk -max 1.865 [get_ports adc_phy_fclk*]

set_input_delay -clock adc_clk -clock_fall -max -add_delay 1.865 [get_ports adc_phy_fclk*]

set_input_delay -clock adc_clk -min 0.47 [get_ports adc_phy_fclk*]

set_input_delay -clock adc_clk -clock_fall -min -add_delay 0.47 [get_ports adc_phy_fclk*]

I have based my max and min times upon the setup and hold times given on page 18 of the ADC datasheet. The trace lengths of the clock and data lines on the PCB are length matched, so no additional skew should be introduced here. 

max was calculated as : bitclock_period/2 - setup time (0.42 ns)

min was calculated as: hold time (0.47 ns)

The fclk signal is edge aligned with the data, so it gets the same constraints. 

I'm not entirely certain if these constraints are correct, so I'd greatly appreciate if someone far more knowledgeable than I can set me on the right track. Also, I should mention that the current interface takes a static-capture approach, simply clocking the data into IDDR primitives with no dynamic clock alignment using IDELAYE2 (I should probably consider a dynamic capture approach such as the architecture shown in XAPP524). 

I have attached a partial schematic of the ADC capture/deserialization block. The delay blocks are all currently set to a delay value of 0, presumably because the traces on the board are correctly length matched. 

Anyway, I do apologize for my ignorance, and any help to get this thing up to speed would be truly appreciated!

Kind Regards

 

 

adc_io_1.png
1 Reply
227 Views
Registered: ‎01-22-2015

@quark21 

Welcome to the Community Forum!

I'm a timing constraint novice in the truest sense...
Not from what I see.  In fact, I think you have pretty much answered your own question.

So, the 437.5MHz DDR interface clock has a half-period of 1.14ns.  You correctly calculate the min/max values of clock-to-out time for the ADC as tco_min=thd_min=0.36 and tco_max=1.14-tsu_min=1.14-0.36=0.78.  So, tco of the ADC varies by 0.42ns (=0.78-0.36).  Putting all this together gives you a data-eye with width of 0.72ns (=1.14-0.42).

As described by Avrum in <this> post, the best static-capture architectures need a data-eye width over 1ns.  So, static capture methods will fail timing analysis when applied to your 437.5MHz DDR source synchronous interface.  -and, as you said, the dynamic capture method shown in XAPP524 should be used.

So, good job answering your own question!  -and good luck with this difficult project.

Cheers,
Mark

Tags (1)