Timequest SDRAM input: unconstrained and working vs closed and broken

[Altera_Forum]

https://alteraforum.com/forum/attachment.php?attachmentid=14800&stc=1 Hi folks, 

 I have an interesting problem that I'm failing to make headway with. I'm working on a Cyclone V design (DE0-CV platform, but also reproducible on Cyclone IV) using single data rate, edge aligned SDRAM and get corrupted data back sometimes leading me to believe that I'm not meeting timing. This also seems to be very sensitive to different place and route - changing the design slightly or the PLL phase shift can get things working again, but I really want something that works reliably.  The basic setup is: 

• 50 MHz input clock 
• ALTPLL in normal mode (also tried source synchronous), first output 50MHz, -2.7ns phase shift to SDRAM, second output 50MHz 0ns phase shift to the rest of the logic 
• Fast input/output registers for all SDRAM signals, no warnings about any of those being ignored except the signals that are static 0/1. 

  Simplified constraints are:  set_time_format -unit ns -decimal_places 3 create_clock -period 20.000 -name clk clk derive_pll_clocks set sdram_pll "SysPLL|altera_pll_i|general.gpll~PLL_OUTPUT_COUNTER|divclk" set sys_clk "SysPLL|altera_pll_i|general.gpll~PLL_OUTPUT_COUNTER|divclk" derive_clock_uncertainty set sdram_input_delay_min 2.7 set sdram_input_delay_max 6.5 set sdram_output_delay_min -0.8 set sdram_output_delay_max 1.5 create_generated_clock -name sdram_clk -source $sdram_pll set sdram_outputs s_addr s_cs_n s_data s_banksel }] set_output_delay -clock sdram_clk -min $sdram_output_delay_min $sdram_outputs set_output_delay -clock sdram_clk -max $sdram_output_delay_max $sdram_outputs set sdram_inputs }] set_input_delay -clock sdram_clk -min $sdram_input_delay_min $sdram_inputs set_input_delay -clock sdram_clk -max $sdram_input_delay_max $sdram_inputs set_multicycle_path -setup -end -from sdram_clk -to 2 set_multicycle_path -hold -end -from sdram_clk -to 1  When the design works it seems robust, when it fails it's reproducible but not for every read. Things that have made the problem go away include: 

• Removing the multicycle paths: this results in a setup violation of 7-9ns depending on phase shift, but sensitive to PAR 
• Disabling OPTIMIZE_HOLD_TIMING: the design still meets timing and works reliably, but at a lower Fmax 

  The hold timing optimization makes me wonder if it's hold related but as the design still meets timing I don't have a lot to go on. I've attached a setup report for the SDC above which looks right to me - the data is launched and then latched a full period later, and then another build with the multicycle removed showing the timing failure. But the one that meets timing gets corrupted data, the one that fails timing works reliably. I've been through lots of old posts about this sort of thing and many of the Altera app notes, but can't seem to make any progress, so hopefully it's something fairly fundamental.  Any pointers most gratefully received!  Jamie

[Altera_Forum]

Hi,  

 I don't understand why you use a multicyle path. Both clocks have the same frequency... The way I see your problem is that your constraints may be too strong, or maybe have a small calculation mistake (maybe not, it's just an hypothesis). Then, although the timing report gives you a setup violation, the PAR have made all it could to meet the timing and your system works fine because of the strong requirement. While giving a multicycle path requirement, the PAR do not try to optimise the data alignement between sys_cllk and sdram_clk (you give it 2 periods to meet setup). The timing report is fine but you got timing failure at runtime.  Can you post your input and output delay calculation, also with your SDRAM datasheet data for these delays ?  hope it helps.

[Altera_Forum]

Hi Mazel, 

 My understanding of the need for the multicycle is that it's to capture the data on the following edge as the PLL shift on its own is not enough to have the input data ready at the register so it should be held for the next edge. Most of the SDR examples I've found on this forum include a multicycle like this and I've tried both with and without :)  The memory is a ISSI IS42S16160B (http://www.issiusa.com/pdf/42s83200b-16160b.pdf), and for the delay calculations, I've followed AN 433 using system-centric approach:   - output max delay: tsu = 2ns (input data setup time tDS)  - output min delay: tH = 1ns (input data hold time tDH)  - input max delay: 6.4ns (Access Time From CLK tAC2) which corresponds to a UI of 20ns - tSU  - input min delay: 2.7ns (Output Data Hold Time tOH2)  I haven't included trace delays in those, but I think they're going to be sub 0.1ns for this board. The -2.7ns phase shift was selected based on http://www.pldworld.com/_altera/html/_excalibur/nios-sdram-tuning/sdram_pll_tuning.pdf and ~-3ns seems to be fairly typical for SDR SDRAM controllers at 50MHz.  Thanks,  Jamie

[Altera_Forum]

I managed to figure this out in the end and the SDRAM timing was rather misleading. It was actually due to the use of an combinationally derived asynchronous reset derived on the prefetch FIFO and different placements could either cause that glitch to be present or hidden, so I'm happy now :)