Turning off the DLL to run DDR2 at very low frequency

Hi,

There's been a few discussions about this the last couple years, but it seems nothing ended with firm conclusions. What I would like to do is to run DDR2 at 25MHz (DDR50). I understand that to do this I have to turn off the DLL (which can't work at below 125MHz) and that this should work but is not supported. My question is, what happens then?

Ie: How do the DQS signals behave during read? Do they turn off, become random, are synchronized with the clock? Is it safe to just read the data a quarter cycle after the clock edge, or is it more complicated than that? I haven't designed an sdram core before, but I'm going to have to do this for this project and have many other, more general questions. If someone knows some good reading material, please let me know.

Aleksandr Dubinsky

Reply to
adubinsky457
Loading thread data ...

You won't find any firm conclusions. As you've probably found out, the datasheets make no statements one way or another about usage when the DLL is disabled. I did some experiments with this for a project that was later aborted. As I recall, I ran DDR (type 1, I think) at 75MHz or so, disabling the DLL. As I recall it worked fine. The main difference just seems to be that you don't have a guaranteed difference between the clock and DQS. If your design doesn't depend on this, then it should work. I think most designs rely on a narrow window where they expect DQS to show up, because the clock speed and copper lengths are fixed. But if you have a design that is flexible enough to allow for any sort of delay, it should work OK. This type of flexibility is difficult, though. There is ambiguity in the DQS edge, because you might not know which edge it is. My design required writing data to the DRAM and then reading it back to determine which DQS edge I was seeing. As you know, though, disabling the DLL carries no guarantees and performance may differ between brands.

You could always have a design which runs the IOBs at high speeds (125MHz) but then connects to a memory controller running at a lower rate. I.e., the effective speed would be about the same as a slower single-clock design because you would have gaps between the bursts. But you'd need asynchronous FIFOs. -Kevin

Reply to
Kevin Neilson

ce

"The main difference just seems to be that you don't have a guaranteed difference between the clock and DQS."

It sounds like you're saying that I still have to track and synchronize to the DQS and that it acts a bit unpredictably, at least at 75MHz.

"My design required writing data to the DRAM and then reading it back to determine which DQS edge I was seeing."

You mean your controller was constantly re-calibrating?

"You could always have a design which runs the IOBs at high speeds (125MHz) but then connects to a memory controller running at a lower rate."

My reasons for running at 25MHz is signal quality on the bus.

- Alex

Reply to
adubinsky457

You might just want to build a prototype and scope it out. I'm also interested in running without the DLL, so I intend to build a test board in the next few months.

Reply to
mng

If you get an answer I would be interested to know as I have some un- released modules than would suit the low-tech market if the technique works. A lot projects use SDRAM because it is simple especially if the frequency drops down to 25-50 makes easy timing. Do the same with DDR and then the barrier to use of DDR for these projects is gone.

John Adair Enterpo> Hi,

Reply to
John Adair

Take care that you have all the on-die termination settings (such as the RTT register) correct--this might help the bus quality.

What I was trying to say is that with the DLL on, the range of the DQS edge is fairly narrow. I think most designs are meant to work with a single clock rate and the assumption that the copper delays are within a narrow range (that vary slightly only because of temperature/voltage) and then the controller can be simplified because it knows basically where the edge will be and there is no cycle ambiguity. Without this DLL this window becomes large. I'm not saying that it necessarily drifts rapidly with time--just that you can't say before reset where the edge will be. My controller didn't recalibrate continuously--just at reset, which seemed to work fine. The good thing is that with low speeds the controller becomes easier in that you don't have to worry about finding the exact middle of the DQS pulse--the pulse is fat enough that you can simply find the edge and then delay a certain fixed amount of time before latching. -Kevin

Reply to
Kevin Neilson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.