How low DDR2 Clock Frequency can be? To make it work on FPGA.

Try faster FPGA?

Antti

This probably isn't very helpful, as I guess Amit is using the FPGA for ASIC prototyping and therefore his RTL will be targeted at the ASIC and will be poorly optimised for FPGA.

The maximum clock frequency for DDR2 SDRAMs is quite aggressively specified, as Amit says. I have to say that my own knee-jerk reaction would be simply to try it; I'd be amazed if the DDR2's internal clock generators could not cope with a clock that's slower than nominal by a factor of 4. But they have hideously complicated internal clock re-timing circuits, so maybe it would indeed all go horribly wrong. Does anyone know for sure? Micron's data sheet and Verilog model both enforce an 8ns maximum clock period on all their current (>=200MHz) DDR2 parts.

Is there a memory expert in the house? :-)

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

125MHz is the lowest specified clock rate for DDR2 SDRAM, not 100MHz.

The problem is that inside the DRAM chip there is a DLL, that makes sure the data is output edge aligned with the data strobe. This DLL only works for a specific frequency range, usually down to 125MHz. In the JEDEC spec it is specified that the DLL must work down to 125MHz, but does not need to work for frequencies below that.

So basically this means that maybe it works, maybe it doesn't. You could be lucky and have DRAM chips that support it, but you can't count on it. It might work with one shipment of chips, but might not with another. It may vary from manufacturer to manufacturer, and from die revision to die revision. So even though technically slower clock speeds should be possible, this is just something that is out of spec, and even if it happens to work the functionality might go away at any time.

So in your case if you try it and it doesn't work, you can never be sure if the problem is with the IP core or the DRAM chip...

--
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...

Not exactly an expert, but I'm trying to figure out the same thing at the moment.

This is what Micron is saying on the subject on their website

"Q: Will the device run at a slow clock (well under the slowest data sheet speed)? A: For a READ operation, the DRAM edge-aligns the strobe(s) with the data. Most controllers sense the strobe to determine where the data window is positioned. This fine strobe/data alignment requires that each DRAM have an internal DLL. The DLL is tuned to operate for a finite frequency range, which is identified in each DRAM data sheet. Running the DRAM outside these specified limits may cause the DLL to become unpredictable.

The DRAM is tested to operate within the data sheet limits. Micron does not suggest or guarantee DRAM operation outside these predefined limits."

So the problem is the DLL inside the DRAM chips. It depends on how they implemented their DLL. If you have slow clock speeds, you might not care about the phase relationship, so you could just turn off the DLL. That's covered in the FAQ as well:

"Q: Should the DLL be disabled? A: Although in some cases the DRAM may work with the DLL off, this mode of operation is not documented nor supported by JEDEC. Therefore, each DRAM design may behave differently when configured to run with the DLL disabled. Micron does not support or guarantee operation with the DLL disabled. Running the DRAM with the DLL disabled may cause the device to malfunction and/or violate some DRAM output timing specifications."

So: It might work, or it might not...

I've had *VERY* bad expiriences with using DRAM chips out of spec. Samsung is especially annoying about this. You might run the chips a tiny little bit out of spec for some reason, and everything works just fine for years. Then suddenly a new die revision appears, and from one shipment to another your designs stops working. And you can't even blame them, because it was never specified for what you were doing.

Or they just change the spec a little bit. Last year I had to fix a

6-year old design because Samsung decided to drop support for full page burst reads from their SDR SDRAM chips in the latest die revision. So the latest shipment of the product simply didn't work anymore. Took me awhile to find a copy of ISE4 to even get that old design to synthesize...

So if you're designing a product that might be around for awhile, I strongly suggest to stick *very* closely to all the DRAM specs. Or test with *one* type of chip and buy a whole bunch of those to support the product's entire lifetime.

--
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...

There are readers of c.a.f who have designed a DLL; I'm not one of them.

But if the problem is the limited length of the DLL delay chain, could one run the memory flat out for a while until it is hot and everything slows down?

-- Tim

I haven't looked at DDR2 in a while, but I seem to recall there is a way to turn off the DLL if you are willing to run a much lower frequency than would normally be used. I don't know if I've ever seen what "much lower" actually is, but the

50MHz might be in that range.

John Providenza

if you turn the DLL off then you cant really validate the DDR2 IP-core functionality under normal conditions. (DLL OFF is not normal operating mode) those for the asic core validation, the validation FPGA test FPGA must run at DDR2 supported clock.

Antti

Yes, you can turn it off, it's just a bit in the mode register. But, as I said in another message in this thread, this mode is not officially supported by any of the DRAM vendors. So maybe it works, maybe it doesn't.

In any case it means running the DRAM out of spec, and that's not really a good way to validate a DRAM controller core, as Antti said.

--
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...

Look for a thread here a few months ago about DDR or DDR2 "DLL frequency"; there was some discussion; apparently there is a DLL (for tracking strobe timings) in the DDR[2] memory which runs out of adjustment range at low frequencies.

It is apparently possible (by changing the mode register initialisation parameters) to turn the DLL OFF, and run the memory without it.

In which case you presumably have to take more care of the strobe timings yourself, (e.g. provide phase shift adjustment in the DCM) but if you can live with this, it may let you work outside the normal frequency range.

And no, I haven't actually tried it...

- Brian

Theoretically you can change a bit in the mode register to turn off the DLL.

But who does guarantee that the mode register accesses will be successful when running the DDR2 memory at lower speeds than 125 MHz ?

Did you find out what is holding your Fmax down in your FPGA ?

Rgds Andre

Sounds like it might be possible to run the DDR2 controller at (let's say) 50MHz, then put a rather thin wrapper around it clocked at (let's say) 200MHz that could oversample the read data and therefore guarantee to capture read data at a time when it's known to be stable. After all, there's no point in trying to test *timing* of the DDR2 controller in the FPGA prototype; it's only *functionality* that's being validated. So an oversampled wrapper that made the timing irrelevant might be useful.

Note that I'm NOT proposing that the SDRAM itself be clocked faster than the FPGA. Obviously you want the SDRAM clock to be the same as the main clock for the DDR2 controller logic, to ensure that all the pipelining and so forth works the same way as in the real thing. I'm just talking about using an oversampled clock to interpolate timings around the SDRAM pins, so that the rest of the controller is immune to data skew weirdnesses introduced by the out-of-spec slow clock.

This might turn out to be a bad idea - someone needs to work all the consequences through.

Tricky problem.

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Hmmm.. If the fMin of these devices is getting faster, quicker than FPGAs are increasing in speed, then FPGA's might be outflanked in the memory interface stakes ? Could mandate custom silicon blocks ?

Or, SDRAM suppliers might consider a special test flow, or silicon variant, just for FPGAs, but that does not sound cheap ?.

Back to the specific issue: The RAM is tested only over the range the data sheet states, and it has a PLL for alignment. That makes the limits fairly important. So one FPGA workaround, would be to try a double-frequency BUS - ie you design for 2 clocks at the pins, for every one inside the controller. Yes, it will be wasteful in current consumption, but it might get you into the validated space, which is what matters.

-jg

...

Recently I was tasked with getting a DRAM controller working on a slow part, and my plan was to disable the DLL and run the DRAM at a low frequency (like 50MHz). It seemed to me that the minimum clock speed was just a spec for the DLL. Since most FPGA-based DRAM controllers used some sort of dynamic alignment to synchronize the read data with the internal clock, the use of the DRAM's DLL shouldn't be necessary. Unfortunately I never got to finish this and have no results, but I would think that you could turn off the DLL and operate at low rates as long as you are dynamically adjusting for the read path delay. But the manufacturers won't even print any specs in the datasheet for usage with the DLL switched off.

-Kevin

Thank you all for giving your expert insights.

I am a bit confident now that, atleast i can try out some of the options like Disabling DLLs, Developing a small wrapper on DDR2 interface (if at all logically possible) and others. Previously, I have put a DDR controller/Interface on FPGA with Micron device running at 40Mhz. 40Mhz is again out of spec but somehow it worked.

Regards, Amit