MAX1000 SDRAM Controller - 100 MHz and Initialization Refresh Cycles

[hemanthmab]

According to the W9864G6JT document:

An additional eight Auto Refresh cycles (CBR) are also required before or after
programming the Mode Register to ensure proper subsequent operation.

I have been using the DRAM controller with the below settings, modifying your example:

at 100 MHz Clock, for both NIOS II and SDRAM (with the SDRAM CLK having a phase shift of-3ns). Both generated by the PLL. I haven't tested it too much other than writing the whole memory area reading the values back (after calling the alt_dcache_flush_all() function). Did you experience any issues running the DRAM Controller at 100 MHz or was it because other external peripherals don't support it?

Thanks for the qsys file too, helped me understand the controller config a little bit better.

[jefflieu]

When you compiled the bit stream, did you have any error in the timing report?
I had "pulse width" violation when I use 100MHz clock.

[hemanthmab]

No, but I am not using your project file, don't have any flash controller included and some other differences so that might have something to do with it. With which clock network did you get the pulse width error? Maybe my timing constraints aren't as fine tuned as yours.

I am testing with a NIOS II/f core too, so its right at the edge of the fMax report (104 MHz). Though I did notice this:

alt_ddr sdram_clk_io(
    .outclock	        (sdram_clk), 
    .din                      (2'b01),
    .pad_out		(sdram_0_clk)
);

which really didn't make any sense to me. Why not directly link sdram_clk and sdram_0_clk?

[jefflieu]

Without the DDR flop, there's routing delay between the PLL output and the Pin.
And the relationship between the output clock and other signals will change from compilation to compilation depending on how the clock signal is routed.
The DDR flop eliminates that routing delay.