Interfacing Controller for SDR SDRAM Memory with FPGA Centric Approach

[Altera_Forum]

Sorry i'm not native english speaker. I'm a begginer in I/Os constraints on Quartus but i've done my best by reading the TimeQuest Timing Analyzer Handbook, other threads , TimeQuest Timing Analyzer User Guide on alterawiki, free online courses... but i still have some difficulties to resolve my problem. 

 I want to interface my controller with an SDR SDRAM with FPGA centric approach. I'm currently trying to use center aligned data for input and output as described in the " Source Synchronous Interfaces and the TimeQuest Timing analyzer" free online course.  My input clock is for the design and is connected to a pll. The output of the pll is connected to the clock of the external device.  So according to the course I performed some report_timing for both slow and fast corners to get the slack values for setup and hold times.   report_timing -from input_clock -to output clock -setup -npaths 1  I found : Slow Corner : su slack: 12,132 hold slack: 4,168 Fast Corner :  su slack: 13,214 hold slack: 1,87  According to this values, the equation the phase shift to apply to balance hold and setup times, in order to be center aligned, would be (4,168-13,214)/2 ie -81°.  But it doesn't work, I can't read anything from my memory.  Something strange, I tried some shift delays ( with or without any constraints) and with +50° I meet the timings and I can read something but not the exact expected value.  I'm on this problem for weeks, i'm very desperate. If someone have any clue or advice please don't hesitate. Thanks a lot   *************************DATASHEET********************************  My FPGA is a EP1S10F780C6. External device datasheet ( MT48LC4M32B2 speedgrade 7) : Data-in, Address, CS#, RAS#, CAS#, WE#, CKE, DQM setup time : 2ns Data-in, Address, CS#, RAS#, CAS#, WE#, CKE, DQM setup time : 1ns Data-out hold time : 2,5 ns (min)   ************************* SDC FILE********************************** set period 20.000 create_clock -name input_clock -period $period [get_ports {H}] create_clock -name virtual_clock -period $period  create_generated_clock -name pll_clock -source  {inst_sdram_pll|altpll_component|pll|inclk[0]}  {inst_sdram_pll|altpll_component|pll|extclk[0]}  create_generated_clock -name output_clock -source  {inst_sdram_pll|altpll_component|pll|extclk[0]} -phase -81 [get_ports H_sdram]  # init : reset , start : always equals to '1'  set_false_path -from [get_ports {init start}] set_false_path -to [get_ports {H_sdram}] set_false_path -to [get_ports {led[*]}]   set_output_delay -add_delay -clock output_clock -max 2 [get_ports {Data_in_out[*] Address[*] CS CKE CAS BA[*] DQM[*] RAS We}] set_output_delay -add_delay -clock output_clock -min 1 [get_ports {Data_in_out[*] Address[*] CS CKE CAS BA[*] DQM[*] RAS We}]  # I'm not sure about input delays, i tried some different values, so i put#  set_input_delay -add_delay -clock virtual_clock -max# [get_ports {Data_in_out[*]}] set_input_delay -add_delay -clock virtual_clock -min# [get_ports {Data_in_out[*]}]  *******************************************************************

[Altera_Forum]

When you change the phase-shift of the PLL, you can change the setup and hold requirements, and the place-and-route will change to try and meet timing. So when changing the phase-shift, don't assume the place-and-route of everything else will be the same. 

- When you do an 81 degree phase-shift, the -phase should be applied to the pll_clock, since that's where it is actually changing. You should be getting a PLL mismatch warning, stating that you're PLL timing constraints are different than the actual PLL is configured in hardware. This is bad. I recommend using derive_pll_clocks, since this will modify the PLL timing constraints whenever you change the PLL megafunction, so the constraints always match the hardware. If you're modifying the PLL output to a phase-shift of 81 degrees, this affects both the data and clock going off-chip, and the shift basically cancels out, i.e. it's not buying you anything. - I assume this is not DDR, just SDR(single-data rate). If so, you want to do a 180 degree phase-shift on the clock so that it is in the middle of the data window. This can be done in two ways: 1) Add another tap to the PLL that is 180 degrees phase-shifted and have that drive out H_sdram. 2) Just invert the clock going out H_sdram, and on that generated clock add -invert. In the end, you will have a setup relationship of 10ns and hold relationship of -10ns, and it should easily meet your timing requirements. (Should the -min value be -1 on your set_output_delay? If the Th requirement of the external device is 1ns, that becomes a -1ns for the -min value). - On the input side, are the clock and data coming in edge aligned(i.e. they change at the same time) or center-aligned? I'm not sure from the description.

[Altera_Forum]

Thanks for you quick response ! 

I'm not currently at work. i'll perform the changes tomorrow.  It's not DDR but SDR. Th requirement of the external device is 1ns so I will change to -1 in set_input_delay, it's my mistake. On the input side I guess that it's center-aligned because the input clock is inverted with the SDRAM clock and the data from the memory is edge aligned with the SDRAM clock. I don't know if i am clear.

[Altera_Forum]

Basically somebody needs to do the 180 degree shift or inversion. If the upstream device is doing it, then: 

create_clock -name virtual_clock -period $period -waveform {10 20} That says there is a 180 degree shift on the virtual clock, which basically means the clock is already aligned in the middle of the data eye at the FPGA pins, and all the FPGA should do is try to match the clock and data delays to the register to maintain that relationship. The way you have it now, you're saying the clock and data coming from the external device change at the same time(are edge-aligned), which is the worst possible relationship between a clock and data. If this relationship was maintained to the input registers, it would cause a violation. The FPGA will try to add delay to the data path to fix this, but it's not ideal. The way to fix that is: 1) Invert the clock as it feeds the input registers. This centers the clock into the middle of the data eye. 2) Have the PLL port do a 180 degree shift, and make sure the generated clock on the output of the PLL describes it that way(either manually, or with derive_pll_clocks)

[Altera_Forum]

I think I was not clear.  

The pll performs the 180 degree shift, so the clock and data coming to the memory are center-aligned. But for the input side, the input clock doesn't come from the memory but from the oscillator ( input H ) which is not shifted. If I perform a read command to the SDRAM, we can say that the data changes on the edge of H_sdram. So is it possible that the data and the main clock are "automatically" center-aligned or must I perform an inversion for the virtual clock and write : create_clock -name virtual_clock -period $period -waveform {10 20}  And have any idea about the values to constrain in input? Does it depend on the tsu and th of the FPGA?  Thanks again

[Altera_Forum]

Sorry it's a redundant question. Thank you very much I understand now