FPGA Central

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

[email protected] 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

On Apr 21, 4:36*pm, Kevin Neilson
<kevin_neil...@removethiscomcast.net> wrote:
> adubinsky...@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

On Apr 21, 12:15 pm, adubinsky...@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 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.

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
Enterpoint Ltd.

On Apr 21, 8:15*pm, adubinsky...@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

[email protected] wrote:
> On Apr 21, 4:36 pm, Kevin Neilson
> <kevin_neil...@removethiscomcast.net> wrote:
>> adubinsky...@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