Edge-aligned center aligned DDR Timing constrains

[Altera_Forum]

Hello: 

 I have a source synchronous interface sending DDR data/clk/ctrl to a FPGA TTL levels (input only to FPGA ). The spec of the source gives a picture defining tValid from rising edge to data valid of 3.5ns, from the same edge tHold of 0 ns. I am assuming the same numbers are true from the falling edge.  If the freq of the clock is 50Mhz:  tSU= tcy/2 - 3.5= 6.5ns tH= 0ns  I am trying to understand is this interface is considered edge-aligned for the purpose of applying timing constrains? Is it correct that center-aligned DDR will specified the tSUP and tH the same values? Do I need to feed clk input to a PLL and shift by 90 deg ?  I instantiated an ALTDDIO_IN without a PLL so far and I am trying to write the timing constrains.  thank you

[Altera_Forum]

.sdc I assume? What you have is not really edge-aligned or center-aligned(although probably closest to edge-aligned). It not symmetric around either edge though.  

create_clock -name ext_ssync_clk -period 20.0  set_input_delay -max 3.5 -clock ext_ssync_clk [get_ports {din[*]}] set_input_delay -min 3.5 -clock ext_ssync_clk [get_ports {din[*]}] set_input_delay -max 3.5 -clock ext_ssync_clk [get_ports {din[*]}] -clock_fall -add_delay set_input_delay -min 3.5 -clock ext_ssync_clk [get_ports {din[*]}] -clcok_fall -add_delay I'm ignoring any board skew, but this describes what is going on outside the device. Now let's say you have a clock coming into the FPGA: create_clock -period 20.0 -name fpga_clk [get_ports fpga_clk]  The setup relationship will be 10ns for opposite edge transfers and hold will be 0ns for same edge, which will be the most restrictive. TimeQuest will basically evaluate that your data delay can't be 10-3.5=6.5ns longer than your clock path or you'll have a setup violation, and it can't be 0ns or less(more negative) than your clock path inside the FPGA or you will have a hold violation. The problem is that your data path will be short since it directly feeds the pin while the clock path is long, so you'll probably fail hold. (The fitter could crank up the input delay chain and possibly get it to work)  Now let's say you add a PLL in source-synchronous compensation mode. You will get identical analysis except your clock path will be shorter since it will be compensated for by the PLL. The fitter might still turn up the IO delay chain if there is one, but this might work.  Now let's say you phase-shift the PLL output 90 degrees. This results in a 5ns setup relationship and -5ns hold relationship. Your data path can't be more than 5-3.5=1.5ns longer than the clock path inside the FPGA, and can't be less than -5ns shorter than the clock path. In other words, your data can be +1.5 to -5ns delay compared the clock path. (This makes since since the data period is 10ns. This allows for 6.5ns of it to be chewed up inside the FPGA, as 3.5ns of it was chewed up outside the FPGA.) This is probably the best layout since having the clock and data pretty closely match will meet timing. You could tweak the PLL phase-shift a bit but not sure it will help).  (Been a while since I've analyzed these and typing from memory, but I think that's correct...)  The following might help but is often overkill: http://www.alterawiki.com/wiki/source_synchronous_analysis_with_timequest

[Altera_Forum]

--- Quote Start ---  .sdc I assume? What you have is not really edge-aligned or center-aligned(although probably closest to edge-aligned). It not symmetric around either edge though.    Now let's say you phase-shift the PLL output 90 degrees. This results in a 5ns setup relationship and -5ns hold relationship. Your data path can't be more than 5-3.5=1.5ns longer than the clock path inside the FPGA, and can't be less than -5ns shorter than the clock path. In other words, your data can be +1.5 to -5ns delay compared the clock path. (This makes since since the data period is 10ns. This allows for 6.5ns of it to be chewed up inside the FPGA, as 3.5ns of it was chewed up outside the FPGA.) This is probably the best layout since having the clock and data pretty closely match will meet timing. You could tweak the PLL phase-shift a bit but not sure it will help).  (Been a while since I've analyzed these and typing from memory, but I think that's correct...)  The following might help but is often overkill: http://www.alterawiki.com/wiki/source_synchronous_analysis_with_timequest  --- Quote End ---    Thanks for the feedback ..       I followed the example from your documentation based on the ADS4149 example   System centric design including cable (DDR input only)  target_out----->>microcoax cable--->>> PCB Receiver--- PPL Shift 90 on DDR_clk_in  These are the constrains  derive_clock_uncertainty derive_pll_clocks  # DDR _clk-in period (80Mhz) ;# I incremented the freq to see how fast I can run the interface set T_Period [expr 12.5] #  create_clock -name target_DDRClkin -period $T_Period [get_ports {DDR_clk_in}] create_clock -name ssync_clk_ext -period $T_Period #  set_clock_groups -asynchronous -group [get_clocks {target_DDRClkin}] #    set tSU 3.5 set tH 0.0   set board_data2clk_skew_max 1.0 set board_data2clk_skew_min 1.0  set relationship [expr $T_Period/4 ];# if shifted by 90deg  set skew_max [expr $relationship - $tSU]  set skew_min [expr -$relationship - (-$tH)]    set Inp_DDR_max [expr $skew_max + $board_data2clk_skew_max] set Inp_DDR_min [expr $skew_min + $board_data2clk_skew_min]   set_input_delay -clock ssync_clk_ext -max $Inp_DDR_max [get_ports {DDR_Data [*] DDR_Cntrl [*]}]  set_input_delay -clock ssync_clk_ext -min $Inp_DDR_min [get_ports {DDR_Data [*] DDR_Cntrl [*]}]  set_input_delay -clock ssync_clk_ext -max $Inp_DDR_max [get_ports {DDR_Data [*] DDR_Cntrl [*]}] -clock_fall -add_delay set_input_delay -clock ssync_clk_ext -min $Inp_DDR_min [get_ports {DDR_Data [*] DDR_Cntrl [*]}] -clock_fall -add_delay     --Comments /issues/questions TQ reports  Seupt : slack of 1.7x --- 1.8x for data  Hold : slack of -0.6x ---- -0.65 for data (failed)  I get the same numbers even when I compiled with the PPL set to 50 Mhz, Did I do something wrong? I see in the equation that the skew is accounted for but no cable or board delay. This make sense to me as the important factor is the skew between clock and data not delay (for inputs).  Is it recommended to increase the shift in the PLL to push the timing to the center?  thank you   UPDATE  There is a typo, the setup time is calculated like this set tSU [expr $T_Period/2 - 3.5 ]  thanks