Achieving Timing Closure on Source Synchronous DDR Input

[Altera_Forum]

Hi I am looking for some help achieving timing closure in a design.  

 I am using a TI ADS4149 EVM Board and connecting it to a Terasic C5 SoC Dev Board.  The ADC outputs Source Synchronous DDR LVDS Centre Aligned data. I am capturing data from the ADC using a DDIO register in the FPGA. I take the clock output from the ADC and using a pll in source synchronous mode connect it to clock the ddio register. The sampling frequency for the ADC is currently at 160MHz but I am looking to push this up to as near to 250MHz as I can.   I have constrained my design using:   # create virtual clock latching data @ source create_clock -name vir_clk_adc -period 6.250 # create clock that is received @ pin (90 degree shift) create_clock -name clk_adc -period 6.250 -waveform {1.563 4.688} # create generated clock output from pll create_generated_clock -name clk_adc_pll -source .gpll~PLL_REFCLK_SELECT|clkin }] .gpll~PLL_OUTPUT_COUNTER|divclk}] derive_clock_uncertainty # set input constraint using setup and hold wrt virtual clock# max = Tperiod/4 - Tsu# min = Th - Tperiod/4 set_input_delay -clock vir_clk_adc -max 0.463 *}] set_input_delay -clock vir_clk_adc -min -1.163 *}] set_input_delay -clock vir_clk_adc -max 0.463 *}] -clock_fall -add_delay set_input_delay -clock vir_clk_adc -min -1.163 *}] -clock_fall -add_delay # false path double data rate edges set_false_path -setup -rise_from {vir_clk_adc} -fall_to {clk_adc_pll} set_false_path -setup -fall_from {vir_clk_adc} -rise_to {clk_adc_pll} set_false_path -hold -rise_from {vir_clk_adc} -rise_to {clk_adc_pll} set_false_path -hold -fall_from {vir_clk_adc} -fall_to {clk_adc_pll}    When I perform timing analysis I am getting setup and hold violations on paths from the RX Pins to the DDIO register. (please see attached jpegs)   I am looking to close timing and am stuck as to what to do next.  Analysing the waveforms they look to have the correct relationship. There are no large interconnect delays, the DDIO has a large cell delay but I dont believe I can change this?   Analysing the data arrival path for the setup of the top failing path, the data is received at the pin, goes through an IO buffer into the DDIO cell, I cant affect this path as far as i am aware. looking at the data required path the clock is received at the pin, goes to the PLL onto a global clock and then to the DDIO pins. Looking at the hold path (it is for a different pin but they are all essentially the same) the data arrival and data required paths are the same as the setup.   I dont know what I can do to achieve timing closure. Assuming my constraints are valid (please let me know if not) and as far as I can tell my design is about as simple as it can get, what would be the next step? The only option that I have is to remove the PLL which I am going to test next.   Help would be appreciated  Thanks  James

[Altera_Forum]

your sdc looks ok to me though I don't understand why tSU and tH are commented for calculation of delays. I expected a small skew range instead. 

You have PLL phase to play with to get timing closure. Have you tried that?

[Altera_Forum]

Hi Kaz, 

 I used tSU and tH as they were specified for the adc in the datasheet and I couldnt find a skew value. AN433 in section FPGA Centric Input Delay Constraints says you can use Unit interval (period/2 for DDR) and setup and hold values for the input delays : UI/2-tSU and tH-UI/2 for source sync inputs.   I hadnt played with the pll phase yet due to having both setup and hold delays, I understand that if I had positive setup slack then I could move it to get less negative hold slack and vice versa but with both already being negative i dont see how I can get them both to be positive!!  regards  James

[Altera_Forum]

ADC data is input to FPGAs and its tSU/tH must be related to its own inputs unrelated to FPGA. 

Your DDR is centre aligned and so best to use small skew range.  also try both ways of edge transfers(same edge and opposite edge). You may remove PLL for a start.

[Altera_Forum]

how do I choose a skew value? should it be on the adc datasheet as I cant see one defined.  

 Can you elaborate on both ways of edge transfer? I dont understand what you mean.  My only reservation with removing the pll was that the clock input is lvds, can I clock internal logic straight from this? My design registers the ddio output and puts it into a DCFIFO. This means I would have to clock some of the internal logic using the ADC input clock so it was in the correct clock domain. I guess I could drive the DDIO straight from the ADC clock input and also apply this to the pll in source synchronous mode the output of which could drive the internal logic reading the ddio output.   Regards  James

[Altera_Forum]

skew value is up to the vendor to tell you. When they say it is centre aligned DDR then they should indicate their skew. Board itself will also have some skew effect. 

If you don't know these figures you can try small value then go up till failure to see your IF tolerance.  PLL is not essential if your adc clock is routed through clock pin. It wouldn't harm anyway so keep it if you wish.  for centre aligned DDR (as well as for edge aligned DDR) there are two patterns of transfer: same edge or opposite edge. This is decided by setting the edge false paths. In your case you are targeting same edge transfer as you are setting false path on rise to fall for setup. If you swap those for hold to those for setup and vice versa then you are targeting opposite edge transfer. In this case your fpga logic should take care of data acquisition order. I believe there are some examples in timequest resource centre.

[Altera_Forum]

Hi Kaz, 

 After scouring the data sheet there is nothing like skew defined so I will try the iterative method to get a better idea. I have read somewhere that output skew and setup/hold requirements are related, and that the equation I used in the sdc's is actually the equivalent of skew i.e.  tSKEW(setup) = period/4 - tSU  tSKEW(hold) = period/4 - tH  I removed the pll from the input and re-evaluated the timing and it all seemed a bit counter intuitive. (Note I am running it faster now too hence value changes)  I modified the SDC's to remove the create generate clock which isn't required with no pll and modified the other constraints to use the input adc clock rather than what had been the generated clock:    # create virtual clock latching data @ source create_clock -name vir_clk_adc -period 4 # create clock that is received @ pin (90 degree shift) create_clock -name clk_adc -period 4 -waveform {1 3} derive_clock_uncertainty # set input constraint using setup and hold wrt virtual clock # max = Tperiod/4 - Tsu # min = Th - Tperiod/4 set_input_delay -clock vir_clk_adc -max -0.100 *}] set_input_delay -clock vir_clk_adc -min -0.400 *}] set_input_delay -clock vir_clk_adc -max -0.100 *}] -clock_fall -add_delay set_input_delay -clock vir_clk_adc -min -0.400 *}] -clock_fall -add_delay # false path double data rate edges set_false_path -setup -rise_from {vir_clk_adc} -fall_to {clk_adc} set_false_path -setup -fall_from {vir_clk_adc} -rise_to {clk_adc} set_false_path -hold -rise_from {vir_clk_adc} -rise_to {clk_adc} set_false_path -hold -fall_from {vir_clk_adc} -fall_to {clk_adc}   I then looked at the timequest reports (see attached setup2 and hold2)  For the setup the data arrival paths are unaffected, the data required path is actually longer than using the pll and this pushes the slack to be positive. The hold path is the same with the data arrival path unaffected and the data required path longer without the pll. Its not completely fixed it but its a lot better, and it works on my board too. Its almost as if the pll was over compensating.   I had another read through the AN433 and interestingly     --- Quote Start ---  Altera does not recommend using a PLL on the input clock for the following inputs: ■ Center-aligned SDR or DDR inputs ■ Low-speed inputs  --- Quote End ---    to be honest the whole section reads a bit confusingly saying use a pll and dont use a pll. It does seem to have improved the interface at least!  Regards  James

[Altera_Forum]

I will try first the easiest options: 

  # create virtual clock latching data @ source create_clock -name vir_clk_adc -period 4 # create clock that is received @ pin (90 degree shift) create_clock -name clk_adc -period 4 -waveform {1 3} derive_clock_uncertainty # set input constraint using setup and hold wrt virtual clock# max = Tperiod/4 - Tsu# min = Th - Tperiod/4 set_input_delay -clock vir_clk_adc -max 0.250 *}] set_input_delay -clock vir_clk_adc -min -0.250 *}] set_input_delay -clock vir_clk_adc -max 0.250 *}] -clock_fall -add_delay set_input_delay -clock vir_clk_adc -min -0.250 *}] -clock_fall -add_delay # false path double data rate edges set_false_path -setup -rise_from {vir_clk_adc} -fall_to {clk_adc} set_false_path -setup -fall_from {vir_clk_adc} -rise_to {clk_adc} set_false_path -hold -rise_from {vir_clk_adc} -rise_to {clk_adc} set_false_path -hold -fall_from {vir_clk_adc} -fall_to {clk_adc}   if it fails timing try opposite edge transfer (fpga should deinterleave data accordingly)   # create virtual clock latching data @ source create_clock -name vir_clk_adc -period 4 # create clock that is received @ pin (90 degree shift) create_clock -name clk_adc -period 4 -waveform {1 3} derive_clock_uncertainty # set input constraint using setup and hold wrt virtual clock# max = Tperiod/4 - Tsu# min = Th - Tperiod/4 set_input_delay -clock vir_clk_adc -max 0.250 *}] set_input_delay -clock vir_clk_adc -min -0.250 *}] set_input_delay -clock vir_clk_adc -max 0.250 *}] -clock_fall -add_delay set_input_delay -clock vir_clk_adc -min -0.250 *}] -clock_fall -add_delay # false path double data rate edges set_false_path -setup -rise_from {vir_clk_adc} -rise_to {clk_adc} set_false_path -setup -fall_from {vir_clk_adc} -fall_to {clk_adc} set_false_path -hold -rise_from {vir_clk_adc} -fall_to {clk_adc} set_false_path -hold -fall_from {vir_clk_adc} -rise_to {clk_adc}

[Altera_Forum]

Hi Kaz, 

 I tried the first option, still had some timing failures, then tried the second option and it passed timing. (see attached setup3 and hold3)  It worked on my board but by changing the false paths it looks like it isnt correctly describing the waveform.   If I describe how I understand it, the virtual clock is the launch clock, which is latching the adc data at the adc. the latch clock is the clock received at the pin which is 90 degree shifted to make it center aligned. The relationship that I am describing in the sdcs should be from the rising edge of the launch to the rising edge of the latch as the data is output at the adc on that rising edge and should be valid to be latched by the rising edge received at the pin. vice versa with the falling edge. Changing the false paths means that I am saying the data is launched on the rising edge and should be valid at the faling edge of the received clock but that doesnt describe how the adc is outputting data and what I have in the design. (see 3rd image)  Does that make sense?  Regards  James

[Altera_Forum]

--- Quote Start ---  Hi Kaz,  If I describe how I understand it, the virtual clock is the launch clock, which is latching the adc data at the adc. the latch clock is the clock received at the pin which is 90 degree shifted to make it center aligned. The relationship that I am describing in the sdcs should be from the rising edge of the launch to the rising edge of the latch as the data is output at the adc on that rising edge and should be valid to be latched by the rising edge received at the pin. vice versa with the falling edge. Changing the false paths means that I am saying the data is launched on the rising edge and should be valid at the faling edge of the received clock but that doesnt describe how the adc is outputting data and what I have in the design. (see 3rd image)  Does that make sense?  Regards  James  --- Quote End ---    virtual clock is the adc launch clock fpga clock at the pin is shifted 90 degrees to indicate centre aligned data (instead of conventional delay figures) Then we have two options to tell timequest: same edge transfer or opposite edge transfer. Both are correct as long as fpga is aware of it. In the first case (your sdc) you are going for same edge then you found out that opposite edge is better which I expected and doesn't need pll as falling edge is centred on data eye launched by rising edge and rising edge is centre aligned on data eye launched by falling edge.  Now for the second case you need to tell fpga how to de-interlave ddr data as Hdata/Ldata are now reversed.