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.