Turning off the DLL to run DDR2 at very low frequency
in [FPGA]
|
Prev: opb_intc + PowerPC
Next: Newbie: Testbench question
From: Kevin Neilson on 24 Apr 2008 14:23 adubinsky457(a)gmail.com wrote: > On Apr 21, 4:36 pm, Kevin Neilson > <kevin_neil...(a)removethiscomcast.net> wrote: >> adubinsky...(a)gmail.com wrote: >>> 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 >> 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 > > > "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 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 |