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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hello,

I have a DDR2 Controller ASIC rtl, which i need to put on FPGA and
validate it. The problem is, i am not able to get this controller run
on more than 50-60 Mhz on Virtex4 FPGA. Now, as everyone says minimum
clock frequency for DDR2 devices is 100Mhz, i am simply not able to
get DDR2 interface working on FPGA.

I want to know if the DDR2 Devices can work on the clock frequencies
which are much lower than 100Mhz. Has anyone tried it and got any
success?

please put your insights.

Regards,
Amit


Re: How low DDR2 Clock Frequency can be? To make it work on FPGA.
Quoted text here. Click to load it

Try faster FPGA?

Antti




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

Quoted text here. Click to load it

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 (>20%0MHz) DDR2 parts.

Is there a memory expert in the house? :-)
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
We've slightly trimmed the long signature. Click to see the full one.
Re: How low DDR2 Clock Frequency can be? To make it work on FPGA.
Quoted text here. Click to load it
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
(http://www.micron.com/support/designsupport/faq/ddr2 ):

"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...

Re: How low DDR2 Clock Frequency can be? To make it work on FPGA.
On Tue, 15 May 2007 15:49:20 +0200, Sean

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: How low DDR2 Clock Frequency can be? To make it work on FPGA.
Quoted text here. Click to load it
...

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

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

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


Re: How low DDR2 Clock Frequency can be? To make it work on FPGA.
Quoted text here. Click to load it
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...

Re: How low DDR2 Clock Frequency can be? To make it work on FPGA.
Quoted text here. Click to load it

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

Re: How low DDR2 Clock Frequency can be? To make it work on FPGA.
Quoted text here. Click to load it


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


Re: How low DDR2 Clock Frequency can be? To make it work on FPGA.
Quoted text here. Click to load it

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







Re: How low DDR2 Clock Frequency can be? To make it work on FPGA.
Quoted text here. Click to load it
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...

Re: How low DDR2 Clock Frequency can be? To make it work on FPGA.
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


Re: How low DDR2 Clock Frequency can be? To make it work on FPGA.
Quoted text here. Click to load it

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


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

Quoted text here. Click to load it

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


Site Timeline