The DRAM interface and the PHY (why a DDR3+ interface must be tuned at boot)

The DRAM interface and the PHY {#dram-interface} This chapter explains what happens on the wires between the FPGA and the DRAM, and why a DRAM interface must be tuned at boot. It covers the signals, the strobes, the board topology, the leveling procedures, the termination and the reference voltages, then the clocks of the FPGA and the DFI interface between the controller and the PHY. Each section ends with the part of LiteDRAM that implements the mechanism. The previous chapter, DRAM in a nutshell , explained the commands and the timings; Initialization and calibration gives the exact steps the BIOS runs. The signals {#iface-signals} A DRAM interface has two halves. The command and address half goes one way, from the controller to the DRAM, and is shared by every chip of a rank. The data half is bidirectional and split into byte lanes , each with its own strobe. The figure below shows the signals. Signal Direction Role CK, CK# To the DRAM Differential clock; commands are sampled on its rising edge CS#, RAS#, CAS#, WE# To the DRAM Command encoding; ACT_n added on DDR4 A, BA, BG To the DRAM Row or column address, bank, bank group (DDR4) CKE To the DRAM Clock enable; low for power down and self refresh ODT To the DRAM Turns on the termination of the DRAM's data pins RESET# To the DRAM Reset (DDR3 and later) DQ Both Data, 4, 8 or 16 per chip DQS, DQS# Both Data strobe, one differential pair per byte lane (per nibble on x4 chips) DM To the DRAM Data mask, one per byte lane: masks bytes during a write A byte lane is 8 DQ, their DQS pair and their DM. Each lane is routed on its own, so each one can arrive at a slightly different time, and each one is tuned on its own. In LiteDRAM, the pads of the DRAM are a record from the platform file, with fields named after these signals ( dq , dqs_p , a , ba , cs_n ). The PHY counts the lanes from it. Two helpers of litedram/common.py reshape the pads: PHYPadsReducer keeps some lanes only, and PHYPadsCombiner merges chips with separate command buses into one controller. Double data rate and the strobe {#iface-dqs} SDR memory transfers one word per clock, sampled on the rising edge of the clock that the controller sends. DDR memories transfer two words per clock, one on each edge, and at these rates the clock from the controller cannot be trusted to sample the data: the delays of the board and of the chips are too large. The data therefore travel with their own clock, the strobe DQS: the side that sends the data also sends DQS, and the receiver samples DQ with it. This is a source-synchronous interface. Both travel the same path, so their delays cancel. The figure below shows how DQS is aligned with DQ. On writes the controller sends DQS centre aligned , its edges in the middle of each bit. On reads the DRAM sends DQS edge aligned , on the bit transitions, and the receiver delays it by a quarter of a clock. Before the burst, DQS is driven for a preamble , and after it for a postamble , without carrying data. In LiteDRAM, the DDR PHYs shift the write DQS by a quarter of a clock from DQ, with the means of its FPGA: The Artix-7 PHY clocks its DQS serializers from a clock shifted by 90 degrees, sys4x_dqs , which the target builds ( bench/arty.py ). The PHYs with output delays (Kintex-7 and Virtex-7 HP banks, UltraScale) delay DQS by a quarter of a clock. The Lattice and Gowin PHYs take the shifted write clock of the DQS block of their FPGA. On reads, the PHYs differ: The Xilinx PHYs do not use DQS. They sample DQ with their own fast clock, through an input delay that read leveling tunes per lane. The Lattice and Gowin PHYs use the DQS blocks of their FPGA, which delay DQS by 90 degrees, capture DQ with it and report when they saw a burst ( burst detect ). Fly-by topology and write leveling {#iface-flyby} DDR3 and DDR4 route the clock, command and address pins as one bus that passes by every chip in turn and ends on a termination: the fly-by topology. It keeps these heavily loaded signals clean at high rates, but each chip receives the clock a little later than the previous one. The figure below shows it. The data lanes are point to point, so their delays do not follow the clock. A chip needs DQS to arrive close to its own CK edge (tDQSS). With fly-by routing the skew between the first and the last chip can exceed a clock period, so each lane needs its own DQS delay. Write leveling measures that delay. The controller sets the DRAM into write leveling mode with a mode register bit (MR1 bit A7 on DDR3 and DDR4), then sends DQS pulses. The DRAM samples its CK with each DQS rising edge and returns the sampled value on DQ. The controller delays DQS step by step until DQ goes from 0 to 1: DQS is then aligned with CK at that chip. In LiteDRAM, the PHYs expose write leveling through registers: wlevel_en enables the mode, wlevel_strobe sends one DQS pulse, and per-lane output delays move DQS and DQ. The BIOS runs the scan ( sdram_write_leveling in liblitedram ). Write leveling needs output delays: the Kintex-7 and Virtex-7 PHYs in HP banks and the UltraScale PHYs have them. The Artix-7 has none: with one static DQS phase, only some lanes of a fly-by memory meet tDQSS. Its optional CK phase shift mode ( with_ck_phase_shift , DDR3 at 1:4) moves CK against all the lanes instead ( CK phase shift ). Write latency and DQ-DQS training {#iface-write-latency} Write leveling aligns DQS with CK within one clock period, but a lane can be one whole clock early or late: the DRAM then writes the burst shifted by a few words. Write latency calibration writes a known pattern, reads it back, and moves each lane by whole clocks until the pattern is right. DQ-DQS training then centres DQ against DQS on writes. It sweeps the output delay of the DQ pins of each lane, writes and reads back a pattern at each step, and keeps the middle of the passing range. It relies on a working read side, which read leveling then refines. In LiteDRAM, the write latency is moved by write bitslips ( wdly_dq_bitslip ) and DQ by output delays ( wdly_dq ). Each PHY declares which calibrations it supports in its settings ( write_leveling , write_latency_calibration , write_dq_dqs_training , read_leveling ); the BIOS runs only those. Read leveling {#iface-read-leveling} On reads, the controller does not know when the data arrive. The DRAM answers CL clocks after RD, but the board and the I/Os add a delay that differs per lane. Two settings must be found for each lane: a coarse one, which fast clock cycle holds the first word, and a fine one, where in the bit to sample. The coarse setting is a bitslip : the deserializer output is shifted by whole bits until the words line up. The fine setting is an input delay, from a few picoseconds to about a hundred per step depending on the FPGA (78 ps on 7-Series with a 200 MHz reference). Read leveling writes a pattern, then for each bitslip sweeps the delay and reads the pattern back. The figure below shows such a scan. The window is the data eye seen through the delay line. A wide window means a robust interface; a narrow one points to a signal integrity or clocking problem. DDR3 and DDR4 can also return a fixed pattern from their MPR (multi-purpose register), so the read side can be tuned before anything has been written. The PHYs that capture with DQS have one more problem: DQS is not driven between bursts, so the receiver must listen to it only during a read. The FPGA's DQS block opens this gate and reports a burst detect, which read leveling uses to confirm that the read window is right. In LiteDRAM, each PHY declares its number of delay taps and bitslips in its settings ( delays , bitslips ), and exposes them through registers ( rdly_dq_inc , rdly_dq_bitslip , and burstdet_seen on the Lattice and Gowin PHYs). The BIOS runs the sca