Chipress

We discussed how a DDR memory controller deals with data hazards in previous posts. Let us look at how the DDR memory controller handles DDR command arbitration, scheduling and QoS.

There are many ways to implement DDR command arbitration and scheduling, and we show one possible solution below.

Before any DDR command can be issued, the DDR memory controller shall make sure the DDR command meets the timing requirements, or DDR timing parameters. There are quite a few DDR timing parameters, and this post summarizes DDR4 timing parameters. DDR Timing Control block will implement the timing counters.

There are 2 levels of arbitration / scheduling in our case study:

1. First level: DDR arbitration among all reads, and DDR arbitration among all writes
2. Second level: DDR command scheduler from DDR read (including RMW), DDR write, and DDR maintenance commands

First Level Arbitration

If no prior activate command is issued to the bank, we call it “closed page”. For “closed page”, the DDR memory controller shall first issue an activate command to open the bank, and then issue the read / write command.

If a DDR read / write command will access the same open row in the bank, or “open page”, the command may be issued directly.

If a DDR read / write command will access a different row from the “open page”, we call it “cross page”. For “cross page”, the DDR memory controller shall first issue a precharge command to close the bank, then issue an activate command to open the different row, and then issue the read / write command.

It is easy to see that, in terms of access latency, “open page” < “closed page” < “cross page”. To improve the overall DDR data bus utilization, we should consider DRAM page status, and make “open page” higher priority, while making “cross page” lower priority.

In addition to DRAM page status, the DDR memory controller can also take the AXI request priority into account. The user will typically specify the request priority using “AxQoS” signaling. For example, we can define “LOW”, “MED”, “HIGH”, “CRITICAL”, 4 levels of QoS. “CRITICAL” is guaranteed to be served in an ASAP manner, while all other priorities are served when there are no requests with higher priority.

It is also worthwhile to implement a starvation prevention mechanism in the DDR Read Command Pool. If a certain DDR read packet is sitting in the DDR Read Command Pool for a long period of time, the DDR memory controller can uplift its priority. Otherwise, that long outstanding DDR read packet will incur a long read latency from user’s perspective, and will introduce a system performance bottleneck.

Second Level Arbitration

The DDR Maintenance Command Queue issues commands such as refresh, self-refresh, power-down, etc. These commands, like refresh, must be issued in time, to make sure DDR devices do not lose data and work properly. Therefore, DDR commands from the DDR Maintenance Command Queue shall have the highest priority than regular DDR read / write commands.

Certain DDR devices offer per-bank refresh capability, instead of all-bank refresh. The DDR memory controller shall take advantage of this capability, and still be able to issue regular DDR read / write commands to non-refreshed banks.

Between DDR read and write commands, the DDR memory controller should minimize read / write switch, since each read / write switch decreases the DDR data bus utilization. In particular, when serving RMW, it will be more efficient to finish all reads before starting any writes.