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: 
Highlighted
Contributor
Contributor
2,085 Views
Registered: ‎03-03-2017

Interfacing a parallel ADC at 250 Msps

The reason for this post is to know the weaknesses (that I must be skipping) on the assumptions and procedures followed to implement the firmware of a FPGA connected to two parallel ADCs as described below. After reading many posts and documentation, I’m not sure if my understanding is correct (which probably not).

 

I'm using the Xilinx Zynq UltraScale+ XCZU3EG-1SFVC784E to capture the data of two external ADCs running at 250 Msps (ADS42LB69, 16 bits each and DDR). The ADC provides its own clock center aligned with the data. The 250-MHz clock is generated externally to the FPGA and all signals outside the FPGA are LVDS.

 

Due to space issues in the PCB, the length of each differential trace between the ADC and the FPGA is slightly different to each other, and thus, we use idelays for path mismatch compensation. The input clock coming from the ADCs have to be delayed as well, but, according to UG571, "clocks should not be delayed using an IDELAYE3, because the IDELAY cannot directly route to the global clock buffers. When clocks must be delayed, use an MMCM or PLL for clock generation, and delay the clocks using the fine-phase shift capabilities." Therefore, considering the specifications described above, the design has been implemented as seen in the image below:

xilinx post.png

I would like to know your concrete opinion on the two following issues:

 

  1. The first question is regarding the FPGA implementation as seen in the previous image. I would like to know if this design is suitable or should be improved in any way. Right now, I don’t have lack-of-resources problems. Some additional considerations: The maximum difference between the ADC traces is below 2 cm, which equals 100 ps, achievable with the edelays. The FIFO depth is 16 words (minimum possible), and I wait to fill it with at least 4 words before enabling the output to avoid reading problems due to jitter.
  2. The second question is regarding the time constraints, since I’m not sure my understanding is the correct one. My first try is described below:

First, the reference and ADC clocks are created:

 

# Reference clock (CLK_DOMAIN 2 in the figure)
create_clock -period 4.000 -name ref_clk [get_ports clk_250MHz_p]

# ADC clock (CLK_DOMAIN 1 in the figure)
create_clock -period 4.000 -name ADC_clk -waveform {2.080 4.000} [get_ports clk_AD0_p]

 

Then, a virtual clock is created defining the ideal launch clock for the data coming out of the ADC. Since the ADC is a centre-aligned interface, the launch clock needs to be advanced by 90° in order to obtain the correct initial setup and hold times:

# Virtual clock equal to ADC clock 90 degree shifted
create_clock -period 4.000 -name launch_ADC_clk -waveform {3.000 5.000}

 

 

Assuming that the edelays and the MMCM_1 suitably compensate the data and clock traces mismatch on the board (that is to say, assuming all signals are equally delayed), the input delays only depend on the ADC and default setup and hold times, obtaining:

# Set input constraint using setup and hold wrt virtual clock: Tsu = 0.62; Th = 0.54
set_input_delay -clock virtual_clk_AD0_p -max 0.38 [get_ports clk_AD0_p]
set_input_delay -clock virtual_clk_AD0_p -min -0.46 [get_ports clk_AD0_p]

# Since we use IDDR, these are for the falling edge
set_input_delay -clock virtual_clk_AD0_p -clock_fall -max -add_delay 0.38 [get_ports clk_AD0_p]
set_input_delay -clock virtual_clk_AD0_p -clock_fall -min -add_delay -0.46 [get_ports clk_AD0_p]

 

Finally, both clock domains are considered asynchronous:

 

# Set asynchronous clocks
set_clock_groups -name async_clk0_clk1 -asynchronous -group [get_clocks -include_generated_clocks clk_250MHz_p] -group [get_clocks -include_generated_clocks clk_AD0_p]

Are these constraints suitable for this design? Is there a better methodology to add them? Vivado is not showing timing problems when implementing the design, but I’m not sure if the constraints have been suitably added. In this regard, should data be constrained as well?

0 Kudos
3 Replies
Scholar drjohnsmith
Scholar
2,054 Views
Registered: ‎07-09-2009

Re: Interfacing a parallel ADC at 250 Msps

Could be the diagram,  but my initial thought is it looks like there are two clocks out of the adc, one for each data stream

   you show only one clock,  and there is no guarantee on the data sheet I can see as to how aligned the two clocks out are.

 

Pitty you did not set the delays on the PCB, must be a real real tight board.

 

 

You can effectively move the data and / or the clocks ( assuming the clock out of the ADC is continuous )

 

I'd look at setting the delay on the clocks, with the in delays set at mid point, so that 'nominally' the clock is in the centre of the data ,

    then you can move the data around using the in delays to align in reality.

 

Good luck, I've done similar, and unless you can auto calibrate on the system, its fun finding something that works across all voltage / temperature / process variations .

 

This is the sort of thing I ended up doing

 

https://www.xilinx.com/support/documentation/application_notes/xapp523-lvds-4x-asynchronous-oversampling.pdf

 

0 Kudos
Contributor
Contributor
2,037 Views
Registered: ‎03-03-2017

Re: Interfacing a parallel ADC at 250 Msps

Thanks for your answer. To clarify, the ADC has only one output clock for the two sets of data, so what you can see in the diagram is the real configuration.

0 Kudos
Contributor
Contributor
2,001 Views
Registered: ‎03-03-2017

Re: Interfacing a parallel ADC at 250 Msps

@avrumw, I've read many of your posts which are clear and very didactic. If you could review this case, it would be very helpful. 

0 Kudos