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!

Reply

ISE Timing Constraint issue interfacing a AD9252 with a Spartan 6 Device

Highlighted
Visitor
Posts: 1
Registered: ‎04-20-2017

ISE Timing Constraint issue interfacing a AD9252 with a Spartan 6 Device

1 Block Diagram

In our current design we have a XC6SLX100T-2 FFG484I. The FPGA has to capture data (8 Data Channels parallel, each channel 14 bit serial) from ADC (AD9252) through differential DDR interface running at 350 MHz.

 

1.emf

 

2 AD9252 Serial high speed data interface to FPGA using IDELAY/ISERDES

The bit clock (DCO_P/N; 350 MHZ) provided by the ADC is 90° out-of-phase with respect to the data and frame signals (DIN_P/N and FCLK_P/N). This alignment is maintained all the way to the FPGA using good PCB layout. The bit clock is used to capture the data and frame signals and it is important that the capture clock and input data delays (inside the FPGA grid) are closely matched. To achieve this, the clock and input data are routed through an input delay (IDELAY) cell. With this method, the insertion delay in the clock and data paths are equal (if necessary delays can be varied to ensure data capture occurs in the middle of the data eye).

 

In order to distribute the bit clock to the whole edge of the device (ADC pins are located not only in one half edge) a PLL must be used to generate the capture clocks (see Figure 1 below). The PLL derives two in phase clocks (700 MHz = bit clock and 100 MHz). When using the PLL for data reception, PLL deskew is required. Therefore the in-phase capture clock is routed back to the PLL using a BUFIO2FB primitive. This mechanism forces the capture clock to be in the same phase as the original received clock (c.p. XAPP 1064).

 

Figure 1: Block diagram of RCV_AD9252_CLK

 

The first thing that must be accomplished is getting the serial ADC data (DIN_P/N) latched into the FPGA using the DDR bit clock (DCO_P/N). The receiver clock (DCO_P/N) is multiplied to 700 MHz in a PLL. A ISERDES master / slave combination shifts the data on the rising edge of the 700 MHz clock into an internal shift register.

 

Figure 2: Block diagram of RCV_AD9252_DATA_CHx

 

3 Timing Constraints

 

NET “ADC_DCO_P” TNM_NET = TN_ADC_BIT_CLOCK;

TIMESPEC TS_ADC_BIT_CLOCK = PERIOD “TN_ADC_BIT_CLOCK” 350 MHZ HIGH 50%;

 

NET “DIN*_P” TNM = TN_ADC_DATA;

TIMEGRP “TN_ADC_DATA” OFFSET IN 400  ps VAILD 800 ps BEFORE “ADC_DCO_P” RISING;

TIMEGRP “TN_ADC_DATA” OFFSET IN 400  ps VAILD 800 ps BEFORE “ADC_DCO_P” FALLING;

 

 

“Map”, “Place & Route” and “Timing Messages”- Warnings:

 

Timing: 3224 – The clock ADC_DCO_P associated with TIMEGRP “TN_ADC_DATA” OFFSET IN 0.4 ns VAILD 0.8 ns BEFORE COMP “ADC_DCO_P” “FALLING” does not clock any registered input components.

 

Timing: 3225 – Timing constraint TIMEGRP “TN_ADC_DATA” OFFSET IN 0.4 ns VAILD 0.8 ns BEFORE “ADC_DCO_P” “FALLING” ignored during timing analysis

  

 

4 Questions

 Obviously our timing constrains are not correct for the DDR interface in our design.

 -  How to write proper constrains for our case?