Smart Traffic Commander: Three Decision Rules of DDRI Arbiter in ARM Cortex

Notes on “Xilinx Zynq-7000 Embedded System Design and Implementation” 91 Situations where DDRI can perform arbitration

Imagine this: when ten cars rush towards a toll booth at the same time, how does the toll collector decide who goes first? Should the car that has been waiting the longest go first? Or should the ambulance be prioritized? Or should a convoy heading to the same destination be allowed to pass together?The DDRI arbiter of ARM Cortex acts as this “smart toll collector”, determining which memory requests can enter the DDR controller first. This article will analyze its three major decision rules using real cases:Wait Time, Urgency, Page Hit.

⚖️ What is an Arbiter? Why do we need it?

In ARM systems, multiple master devices (CPU cores, GPU, DMA controllers, etc.) simultaneously issue memory requests to the DDR controller.The DDRI arbiter is responsible for selecting the highest priority request from these conflicting requests and sending it to the DDRC scheduler for processing. Without an arbitration mechanism:

Low-priority devices may experience “starvation” (e.g., DMA transfers being continuously preempted by the CPU)
Frequent memory row switching can lead to a performance drop (each switch adds a delay of 30~50ns)

Rule One: Wait Time – Give the “Longest Waiting” Request a Green Light

Principle: Each request starts timing when it enters the queue, and if it is not processed for a long time, its priority is automatically increased.

📌 Real Case: GPU Memory Access on Raspberry Pi 4

Scenario The VideoCore GPU of Raspberry Pi 4 continuously reads from video memory (located in LPDDR4), while the CPU cores perform AI inference calculations.
Conflict The CPU issues a burst of weight read requests, blocking the GPU’s frame data requests.
Arbitration Decision

// Pseudocode: Wait Time Weight Calculation 
if(request.wait_time > THRESHOLD){
 priority += WAIT_BOOST;// Increase priority for timed-out requests 
}

Result When the GPU request waits for more than 200ns, the arbiter forces it to be executed before the CPU request to avoid video stuttering.

💡 Key Value: In Cortex-A72, the timeout threshold is typically150~300ns (about 50~100 clock cycles).

Rule Two: Urgency – Open the VIP Lane for “Life-Saving Tasks”

Principle: The urgency of requests is identified through the QoS (Quality of Service) signal on the AXI bus (e.g., 0=lowest, 3=highest).

📌 Real Case: Brake Signal Processing in Automotive ESP Systems

Scenario In the Bosch ESP controller based on Cortex-R5:

High Priority Brake sensor data writing (QoS=3, real-time requirement <10μs)
Low Priority Fault log writing to SD card cache (QoS=0)

Burst Conflict When ABS is triggered, sensor data floods in.
Arbitration Decision

// Pseudocode: Urgency Priority Logic 
if(request_A.qos > request_B.qos){
 select request_A;// Select the request with higher QoS 
}

Result Even if the log request arrives first, the arbiter still prioritizes the brake data to ensure real-time response.

⚠️ Note: Misuse of high QoS can lead to system imbalance (e.g., Linux kernel default QoS=0).

Rule Three: Page Hit – Allow “Readers of the Same Book” to Avoid Changing Shelves

Principle: DDR memory consists of multipleBanks (shelves) andRows (shelf layers). If a new request has the sameRow Address as the currently open one, there is no need to switch rows (avoiding tRCD delay).

📌 Real Case: Frame Buffer Optimization in Hisilicon Hi3519 Video Encoder

Scenario When processing 1080P video, the ISP module reads image data row by row

Address Sequence:Row1_Col1→Row1_Col2→...→Row1_Col1920

Conflict At the same time, the audio module needs to write voiceprint data (addresses scattered across different Banks).

Arbitration Decision

// Pseudocode: Page Hit Detection 
if(current_bank == new_bank && current_row == new_row){
 priority += PAGE_HIT_BONUS;// Page hit bonus points 
}

Result The arbiter arranges consecutive Row1 accesses together, reducing row switching frequency and improving bandwidth utilization by 20%.

🔍 Data Comparison:

Request Pattern Average Latency Bandwidth Utilization

Random Access 45ns 65%

After Page Hit Optimization 32ns 85%

Request Pattern	Average Latency	Bandwidth Utilization
Random Access	45ns	65%
After Page Hit Optimization	32ns	85%

How do the Three Rules Work Together?

The actual arbitration uses a weighted scoring system:

Overall Priority = Wait Time Weight × 0.4 + QoS Level × 0.5 + Page Hit Bonus × 0.1

📌 Collaborative Case: Multi-Task Competition in Drone Flight Control Systems

Devices

Gyroscope DMA (QoS=2, waiting 100ns, page hit)
Camera Capture (QoS=3, waiting 50ns, page miss)
WiFi Data Transmission (QoS=1, waiting 200ns, page hit)

Arbitration Calculation

Gyroscope Score = 100×0.4 + 2×0.5 + 1×0.1 = 41.1
Camera Score = 50×0.4 + 3×0.5 + 0×0.1 = 21.5
WiFi Score = 200×0.4 + 1×0.5 + 1×0.1 = 80.6

Decision Select WiFi Request (even though the gyroscope with a page hit has been waiting longer, the WiFi’s timeout weight is higher)

How Can Developers Configure Arbitration Strategies?

In ARM chips, parameters can be adjusted through registers (taking NXP i.MX8 as an example):

// Set wait time threshold (priority increases beyond this value)  MMDC_ArbiterCtrl0.THOLD =0x80;// 128 clock cycles  // Configure QoS weight (0-7, higher values indicate greater weight)  MMDC_QoS_WEIGHT.w_qos_weight =0x3;// Set QoS weight to medium  // Enable page hit optimization  MMDC_ArbiterCtrl0.PAGE_POLICY =1;// 1= prioritize page hit requests

Three Practical Tips for Beginners

Real-time tasks must set QoS

// Set QoS level when initiating requests on AXI 
AXI_Request.qos =3;// Highest urgency

Avoid “Long Wait Chains”:

Incorrect: Allow low-priority tasks to continuously issue a large number of requests
Correct: Use burst transfers to merge small requests (reducing arbitration frequency)

Optimize Memory Layout for Page Hit Rate:

Place related data (e.g., image rows) in the same Bank but different Rows
Separate data (e.g., audio/video) into different Banks

Conclusion: The Art of Balance

The DDRI arbiter is like a wise traffic commander:

Wait Time Rule embodies fairness – “No vehicle should be left stranded forever”
Urgency Rule ensures critical tasks – “Ambulances always have priority”
Page Hit Rule enhances efficiency – “Let passengers going to the same floor share the elevator”

Understanding these three rules will help you tame the DDR bandwidth bottleneck in embedded development, allowing ARM systems to run faster and more stably.