embedded - DDR2 CAS Latency - is it fixed to clock-cycles or time?

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.

Answer

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.