Achieving Timing Closure on Source Synchronous DDR Input

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