On 13 September 2017 at 01:43, Michael Mrozek EvilDragon@openpandora.org wrote:
So, DLL is the internal clock of the memory
Not quite... a DLL (Delay Locked Loop) is a way to create fine-grained timing from a reference clock signal. The DLL inside the memory locks onto the bus clock (ck-nck) provided by the memory controller and is used to make its outputs line up right to the bus clock. Specifically, this affects the alignment (relative to bus clock) of: 1. memory's dq (data) and dqs outputs (data clock) during reads; 2. changes to its termination resistors in response to the ODT signal (synchronous ODT) and/or during writes (dynamic ODT).
When the memory DLL is on, the alignment of these relative to the bus clock is tightly specified by jedec. When the DLL is off, they no longer are.
For some reason JEDEC also forbids use of ODT whatsoever in DLL-off mode. I have no idea why. I would have expected that ODT in DLL-off mode simply follows the "asynchronous ODT" rules which also apply when the memory is in self-refresh (at which time the DLL is implicitly disabled).
Note btw that although JEDEC specifies various aspects of DLL-off mode, is entirely optional for memory to support DLL-off mode in the first place.
What frequency is tCKDLL_OFF in our setup?
JEDEC specifies tCK(DLL_OFF)(min) to be 8ns, i.e. the max clock frequency specified for DLL-off mode is 125 MHz.
And what is it when it's switched on?
We're running the memory bus at 532 MHz, i.e. tCK = 1.88 ns.
Running with DLL off at that frequency is therefore waay outside JEDEC-specified territory.
The DLL-off mode is only required to support setting of CL=CWL=6.
Note that normally these values are strongly dependent on the clock frequency. Since DLL-off mode is only specified at very low frequencies, jedec simply picked a fixed value for each that the ram is required to support.
--> So CL and CWL are the same and different to the setup in DLL on?
Tony only toggled the DLL-off bit, he didn't change any timings.
Since the memory is still being run at high frequency, using the normal CL and CWL values is the right thing to do.
- DLL-off mode will affect the Read data Clock to Data Strobe
relationship (tDQSCK), but not the Data Strobe to Data relationship (tDQSQ, tQH). Special attention is needed to line up Read data to controller time domain.
This is already taken care of by hardware leveling, since it needs to compensate for the round-trip delay anyway. Moreover, this parameter (dqs gate) is quite tolerant since it merely affects the window during which the memory controller has the receivers enabled and is ready to capture data. The actual data capture happens on data strobe (dqs) transitions, and as your quote says the dqs-to-dq timing is not affected by disabling the DLL.
- DLL off also disables ODT.
There's nothing saying it disables ODT. Rather, JEDEC says you're supposed to refrain from using ODT in DLL-off mode. Using it anyway would be undefined behaviour, but my suspicion would be that it behaves like asynchronous ODT in practice.
Juliano's analysis seems to imply that data signal integrity should be fine with or without ODT, and Tony has reported success with ODT disabled.
- One thing that still puzzles me: According to the information I
found, the timings need to be setup SPECIFICALLY for the memory chips you use. Even the JEDEC standard mentions sometimes that the specific timings need to be taken from the datasheet of the manufacturer.
Where exactly? I'm pretty sure this isn't true, and it would completely defeat the purpose of standardized speed bins.
(DLL-off mode *does* have some manufacturer-dependent timings, such as tDQSCK, but it's an obscure and optional feature anyway.)
Are we sure there's NOTHING that simply powers a part of the Pyra for 10 seconds after it has been switched off?
Pretty sure yes.
According to the OMAP5 document, hardware levelling must be triggered by the software, so what happens if we never trigger hardware levelling?
It would use the reset default values and fail spectacularly.
Using software-provided leveling values should be possible though. Here's what I said about this on irc a few days ago:
<@zmatt> notaz/tmlind: btw, in case you want to try manual leveling... I think the procedure is: <@zmatt> 1. set the appropriate values in ext phy control 2-13 ( https://goo.gl/bDV8js ) instead of the seed values being written currently. you should be able to use the values obtained from a successful hw leveling. <@zmatt> 2. skip the hw leveling procedure (obviously) <@zmatt> and the step 3 that I was missing when I tried this a while back: <@zmatt> 3. reset the phy to latch the config registers into the phy. This is done by setting bit 10 of the "iodft_tlgc" register at offset 0x60. You can find it in the dra7 trm, it's omitted from the omap5 trm.
Matthijs