1
\$\begingroup\$

We have a (new, prototype) board that is, at best, temperamental. It's using a Micron MT47H64M16HR-25:H DDR RAM, the design reference board uses a Micron MT47H64M16HR-25E:H. Only one letter different, what could possibly go wrong? The extra letter means our board's DDR has a Cas Latency (CL) of 6, while the reference one has a CL of 5.

So - what could possibly go wrong is that our board does not run! Or, if we drop the clock frequency, it will partly boot but then hang. Of course, there's lots of other things that could cause this so I'm working through the possibilities - this being one of them.

A wrinkle is that the CPU (TI DM368) can't be configured for CAS greater than 5. Another wrinkle is that the DDR is not being run at full speed - it gets run at 340(680)MHz or 270(540)MHz, which are below the 400(800)MHz spec of the part. There's a table in the Micron data sheet that suggests the CL may drop when running slower, but no explanation to confirm or deny.

This post suggests CL is a time-based value, I.E. it will always take Xns to access the part, regardless of the clock frequency.

To my mind, SDRAM being a clock-driven device, the CL would be related to ticks of the clock rather than a fixed period, but I'm quite aware that there's all sorts of trickery going on in DDR to push the limits.

So, the question is: is CL fixed to clock cycles or time?

Bonus question: How can I test the DDR without being able to boot to Linux? The U-Boot ram tests are very basic read/write and never throw an error. Anyone got any good tricks? I can recompile U-Boot with a new routine in if needed.

\$\endgroup\$
1
\$\begingroup\$

CL minimum value is time based, but it is counted in clock cycles. So using it at a lower frequency you can presumably reduce CL - but if so, you must specify the actual CL value in the DRAM's mode register on initialisation; if the data sheet gives a mode reg bit pattern representing CL=5, then you are probably OK.

Also check that your reduced clock frequency is still within the permitted range for the part's internal DLL (there will be a minimum freq specified) but I think 270 MHz will be OK.

These details are from memory, but I did reliably operate DDR2 from a Virtex-5 FPGA at just under 200MHz so there is some leeway.

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ Aah, mixed units of measurement, great! The slower we run it, the more reliable it gets - clocking down to 172(345)MHz the board runs fine but then doesn't have the MIPS for the task at hand. The data sheet gives command/config registers for setting the DDR but the code that sets it is a bit buried in the SDK we're using so I was hoping to avoid it. \$\endgroup\$ – John U Sep 18 '13 at 10:07
  • \$\begingroup\$ heh, I rolled my own mode register setting in VHDL, but you may have to dig deeper. At least check that what your SDK is writing to DRAM modereg makes sense... \$\endgroup\$ – Brian Drummond Sep 18 '13 at 10:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.