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 1When 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:
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.
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
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 :)