Chipress

We will cover DDR memory controller design in this post. Note, there are many ways to implement DDR memory controllers, and we show one possible implementation as a case study.

As shown below, on one side, a DDR memory controller takes read and write requests from system fabric. The source of these requests can be CPUs, SOC agents, or IO devices. In our case study, we assume the system fabric follows AXI protocols.

On the other side, the DDR memory controller interacts with DDR devices through DDR-PHY (Dual Data Rate Physical Layer). Functionally, DDR-PHY converts parallel single-rate data from memory controller into serial dual-rate data streams for transmission over the DDR memory interface and vice versa. It is also in charge of DDR device calibration and initialization.

The diagram shows the DDR memory controller top level architecture.

The controller will first chop the incoming AXI write and read requests into DDR burst aligned packets, and decode the AXI address into the DRAM address (Channel, Rank, Chip, Bank Group, Bank, etc.). The address decoding logic should properly interleave the AXI traffic, such that DDR bank conflict is minimized and the DDR device can achieve a throughput that is close to its theoretical maximum.

DDR write packets are stored in the DDR Write Command Pool as long as there is Write Command Pool space available, and the associated write data is stored in the Write Data Buffer. Once the write packets are pushed into the DDR Write Command Pool, the controller will return AXI Write Responses. This significantly improves the write latency.

Once a DDR write packet / command is sent to DDR, the associated write data shall be popped from the Write Data Buffer. The Write Data Path Control shall unpack the write data and count write latency.

Certain DDR devices do not support partial write, thus a Read-Modify-Write (RMW) operation is required. RMW will first issue a DDR read command to the same address, and DDR read data will then be sent back to the Write Data Buffer for merging. Finally, a full DDR write command is issued.

DDR read packets, on the other hand, are pushed to the DDR Read Command Pool, if both the DDR Read Command Pool and the Read Data Reorder Buffer have space available. If either one has no space left, the Read Request Packetizer shall backpressure the AXI Read Channel.

After a DDR read packet / command is sent to DDR, the Read Data Path Control is responsible for collecting read data from DDR and packing data into the Read Data Reorder Buffer.

Generally speaking, the DDR memory controller provides out-of-order read data responses, as allowed by AXI protocols. The controller still requires the Read Data Reorder Buffer since:

1. The Read Data Reorder Buffer makes sure the read data responses are in order, for AXI read requests with the same AXI ID, as required by AXI protocols
2. One AXI read request may be chopped to multiple DDR burst aligned packets, and DDR packets may be scheduled out-of-order. The Read Data Reorder Buffer should “assemble” the read data from DDR, and provide the data response for the original AXI read request

In this post, we covered the basic read and write operations / data flows of the DDR memory controller. We will cover more subtle details in later posts, such as data hazards handling, scheduling and QoS, as well as RAS and power saving.

Reference:

1. https://www.quora.com/What-is-DDR-PHY-in-VLSI