On Sat, 3 Nov 2018 at 21:03, Michael Mrozek EvilDragon@openpandora.org wrote:
Ah, okay. Does that mean that self-refresh also doesn't lower the clock rate?
The memory clock is gated in self-refresh.
I think we can rule out the power supply, as the memory runs fine whatever you do when DLL is off, and even when DLL is on as long as you run a memtester and keep the memory busy.
The same argument can be made for the memory clock. It is possible however that DLL locking is more sensitive to sub-optimal power supply stability and/or memory clock irregularities. Anyway, it's just a guess, but the best one I have given the info available to me.
Unless you mean that the power supply has issues keeping the power constant when the memory usage changes but that would be the PALMAS and that handles it automatically.
Palmas is more for long-term stability. Keeping the power supply stable during short-term fluctuations of power consumption is dependent on decoupling caps and pcb layout.
Also, 2GB RAM doesn't have the issue, and the power consumption is nearly the same.
That doesn't really say anything since the average power consumption is not the suspect in the first place.
As far as I understood from the JEDEC documents, DLL doesn't have anything to do with the timing settings - we've already set up the custom timings according to the datasheet.
The datasheet contains nothing but standard JEDEC timings. It could just as easily have mentioned which clock speeds are supported and the range of CAS values for each and referred to JEDEC for the rest.
If I understood correctly, DLL is being used to automatically compensate timing issues caused by longer traces
No, the memory controller's DLLs are used for that. The RAM's DLL is not programmable and cannot be used to compensate for trace length. The RAM needs the DLL to make its data outputs and ODT toggle at the right time (as specified by JEDEC) relative to the memory clock. In DLL-off mode the timing for data read from the ram becomes JEDEC-unspecified ("tDQSCK(DLL_off) values are vendor specific"), and ODT is officially not supported at all in DLL-off mode.
(higher resistance values).
Trace length directly affects timings because of the time it takes for signals to travel along the trace. Resistance values have nothing to do with it.
A Dual-Die RAM could otherwise receive or transfer the requested value from the wrong chip.
Ehh, no.
However, if it works fine without DLL, then it seems our traces / resistances are good enough for the timings..?
Trace lengths are not relevant for this. It means that 1. the RAM seems to be okay with DLL-off operation at the frequency and CAS value where we use it (which jedec doesn't spec at all). 2. with our current settings EMIF seems to be okay with whatever (JEDEC-unspecified) timing the RAM outputs data during reads in DLL-off mode. 3. we either don't use/need ODT, or it behaves well enough in DLL-off mode (even though JEDEC does not consider ODT to be supported in DLL-off mode)
Okay. BTW: Where did you find thoese 125MHz limit?
4.5 DLL-off Mode The maximum clock frequency for DLL-off Mode is specified by the parameter tCK(DLL_OFF).
13.1 Timing Parameters for DDR3-800, DDR3-1067, DDR3-1333, and DDR3-1600 Table 68: tCK(DLL_OFF): min 8 ns