1. Home
  2. Field-Programmable Gate Arrays
  3. Running DDR below the min frequency

Running DDR below the min frequency

This post might not be directly on topic here but I'm hoping that someone else out in FPGA-land might have come across a similar problem.

The problem: I'm using an FPGA to do emulation of RTL that would normally be build into an ASIC.As such, therefore, the RTL is not very `FPGA friendly' and I can only get a speed of 33-40MHz, maybe 50 at a push. The trouble is that the system incorporates a DDR DRAM controller and DDR DRAMs have a min. frequency spec - 66MHz in the case of the ones I'm using - related to the internal DLL. I *think* that this is why I'm getting no response from the RAMs during read cycles & the data bus seems to be floating.

I've tried running with both DLL enabled and disabled to no avail. [Maybe some manufacturers work in this mode and others don't].

Any ideas ?

Reply to
rick
Loading thread data ...

The spec minimum for DDR is 83.33MHz. I have managed to make some run at 66MHz, but I don't think you'll get them to run lower.

You are correct that this is related to the internal DLLs in the DDR.

If you can't bump the speed, I can't see that you'll be able to make it work

Cheers

PeteS

Reply to
PeteS

There are solutions to my problem but, trouble is, I don't really like any of them much:

o Run the controller part of the system on a 2x clock. The downside is that this would give overly optimistic performance results.

o Run the DRAM clock at 2x and do some sort of conversion between the controller's output and the DRAM control/datapath signals ... Ugly, esp the write path!

o Similar to the previous but use ordinary SDR RAMs at 2x to emulate DDR at 1x.

Rick

Reply to
rick

It seems pretty on-topic to me!

I can't answer your question directly, but I can think of two things you can do:

  1. Add a second (third, 99th, whatever) FPGA to implement a DDR DRAM emulator. If you don't want mere test patterns out of it you'll probably have to back it up with static RAM or something. You'll have the drawback that you're not giving the FPGA the 'real thing', but you'll at least be able to check for gross logic errors and even some glitches.

  1. Modify the RTL to be more FPGA friendly, but in a way that allows you to verify top-level equivalence. This is even more remote from the first choice, but it gives you the satisfaction of seeing your stuff actually run DDR DRAM at full speed.

I assume that "Get a faster FPGA" has already been explored to it's fullest extent...

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
Reply to
Tim Wescott

Is 2 as bad as you think ? - you are only trying to keep the DLLs happy, so a simple scheme that reads-twice, and writes-twice, would get the clock into the DRAM realm, but the data-rate matches the larger system ?

-jg

Reply to
Jim Granville

Pete,

With a little bit of advice & messing around with s/w I've managed to get DDR working in DLL-disabled mode @33MHz at least as far as getting the PROM monitor up running.

The basic advice was that with the DLL off the DDR DRAMs (may) ignore the CAS latency value programmed into the mode register and just kind of choose their own value. The detailed advice that in this case CL always = 2 was not right since for the Samsung based DIMMs I'm using we seem to have CL = 1.

Rick

Reply to
rick

Well, if you are willing to play in DLL-Disabled mode, you can expect to get interesting results. Certainly I have done so for test and eval purposes (well, that's what I told the boss about all that time in the lab ;)

My original point was that in normal operating mode (DLLs on, some CAs as supported iaw datasheet), you probably won't get DDR to operate below 66MHz

Cheers

PeteS

Reply to
PeteS

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.