<hell__>
> DLL reset allows the ability to lock to a new target clock frequency.
<hell__>
though this document is for another type of DDR
<hell__>
to initialise DDR3 after a JEDEC reset, one first programs MR2, then programs MR3, then programs MR1, and finally programs MR0 with the DLL reset bit set
<hell__>
then one does ZQ calibration and waits until tDLLK (time for the DRAM's DLL to lock) has elapsed
<promach3>
hell__: what does it exactly mean by "new target clock frequency" ?
<hell__>
if you change the clock speed to the DRAM
<promach3>
what ?
<promach3>
@hell__ I suppose each DDR3 RAM clock speed is already fixed by manufacturer ?
<promach3>
hell__:
<hell__>
need to go, be right back
<hell__>
promach3: RAM manufacturers rate RAM chips to work *up to* a maximum clock speed
<hell__>
it's usually possible to use a lower clock speed
<promach3>
alright
<hell__>
when initialising the RAM for the first time, the memory controller's clock outputs are usually disabled, so the RAM is "running" at 0 Hz (it's not running)
<hell__>
after enabling the clock outputs, the DLL in the RAM needs to "lock" to the clock signal. A DLL reset "unlocks" the DLL, so that it can lock again to the current clock speed
<promach3>
ok, so it is a **MUST** to enable "DLL Reset" ?
<promach3>
hell__:
<hell__>
oh, looks like I missed one detail
<hell__>
the "DLL reset" bit is self-clearing. This means, when you set "DLL reset" to 1, it will return back to 0 automatically
<promach3>
I mean enable "DLL Reset" inside MR0 ?
<hell__>
yes, you have to set "DLL reset" to 1 in MR0
<promach3>
ok
<hell__>
if you enable "DLL reset" in MR0, then you must wait for tDLLK before using any functions that require the DLL (read commands or ODT synchronous operations)
<promach3>
what about WRITE commands ?
<promach3>
hell__:
<hell__>
as long as you don't use ODT with WRITE commands, it should be fine
<promach3>
but why READ commands require DLL , but WRITE commands do not require ?
<hell__>
the DLL is used to generate DQS
<hell__>
for read commands, the DRAM drives DQ and DQS pins, and uses the DLL to maintain a quarter phase shift between DQ and DQS
<promach3>
90 degree phase shift ?
<hell__>
yes
<hell__>
the idea of DQS is to tell the receiving end when exactly to sample DQ
<hell__>
for write commands, the memory controller drives DQ and DQS pins, so the DRAM doesn't need to use the DLL
<promach3>
I am using clock divider to do the work of DLL in the case of memory controller
<promach3>
is this appropriate ?
<promach3>
sorry should be line 111
<promach3>
instead of line 112
<hell__>
it should work
<hell__>
on the memory controller of Intel Haswell processors, the DQ and DQS phase shift can be controlled by software during memory initialisation
<promach3>
hell__: I suppose the DQ and DQS phase shift is fixed at 90 degrees ?
<hell__>
the phase shift isn't fixed, but there's no reason to use anything other than 90 degrees on DDR3
<promach3>
but 90 degrees is the nominal case to avoid "ISI"
<hell__>
yes
<promach3>
so, why use other phase shift other than 90 degrees ?
<hell__>
the hardware *can* use phase shifts other than 90 degrees, but software always uses 90 degree phase shifts
<promach3>
software ???
<promach3>
I am confused
<promach3>
hell__:
<hell__>
I'm talking about the memory controller on Intel Haswell processors (which is what I'm most familiar with)
<promach3>
software as in verilog or C language ?
<hell__>
the memory is initialised by the BIOS (or equivalent), which is software
<promach3>
use other phase shift other than 90 degrees --> due to Write Levelling procedure ?
<hell__>
the BIOS pokes control registers on the memory controller to send commands to the DRAM and adjust timing/voltage parameters
<hell__>
it's just that the memory controller is very complex and flexible. I mean, it can also support LPDDR3 and even contains specific hardware to run memory tests
<promach3>
hell__: use other phase shift other than 90 degrees --> due to Write Levelling procedure ?
* hell__
is checking
<hell__>
during JEDEC write leveling, I only move DQS
<promach3>
what do you exactly mean by "only move DQS" ? hell__
<hell__>
the memory controller I use has adjustable DQ and DQS phase shifts
<promach3>
you wrote your own memory controller verilog coding ?
<hell__>
no, I wrote software to use the memory controller on Intel Haswell processors
<promach3>
ok
<hell__>
during JEDEC write leveling, I sweep the DQS phase shift in small steps over a full clock cycle, and sample the logic level on the DQ pins
<hell__>
the final value for DQS phase shift is where DQ transitions from low to high. Then, I program DQ phase shift to (DQS phase shift + 90 degrees)
<hell__>
now the phase of DQ and DQS is correctly aligned, but the values could be wrong by some amount of full clock cycles
<hell__>
to check and correct that, I write a simple test pattern to the DRAM and read it back to see if it matches. I move DQ and DQS back and forth in full-clock-cycle steps until I find a setting that passes
<hell__>
it has 4 DDR3 DIMM slots. On the picture, only 2 slots are populated
<hell__>
The mainboard supports 2 memory channels, and each channel is connected to 2 DIMM slots
<hell__>
DDR3 DIMMs can have 1 or 2 ranks, so each channel can have up to 4 ranks
<hell__>
when I made that log, all 4 DIMM slots were populated with single-rank DIMMs. Rank 0 is the first rank on the first slot, and rank 2 is the first rank on the second slot
<hell__>
I have to train each rank separately, but I can test one rank on both channels at the same time. I print the plots in the same order
<hell__>
I really like these plots because you can see the fly-by skew
<promach3>
I am confused with what you meant by fly-by skew ?
<checkpoint>
anybody knows how to use ecpbram to subst random binary ? it's not clear how to provide target binary (-t), ecpbram does not recognize ihex format :(