This article is intended to be a guide for tuning the default configuration to shape the traffic of the HP ports to help meet your system throughput requirements.

Table of Contents

Introduction

Performance through the HP ports is very dependent on the traffic patterns generated by the PL masters as well as non-deterministic traffic patterns driven by software running on the processors. Both sets of masters will be competing for DDR access. The non-deterministic nature of software running on the processors makes it difficult to accurately model for optimal DDR efficiency. However, you may be able to iteratively tune the default configurations to help meet your system performance requirements. This is not an exhaustive list of the available controls, but the most effective knobs to help shape the HP traffic. The data path from the HP ports in the PL to the DDR memory controller is shown below.

Open

This article does not address:

1. HPC, HPM, ACE, ACP or LPD ports

2. CCI/QVN enablement

3. SMMU enablement

PS-PL Interface

The PS-PL interface is comprised of an AXI FIFO interface (AFI) per port to bridge the PS and PL domains. The main controls here are the QoS and the issuing capability per port. The QoS specifies the priority of the transaction which is also used to map the channel into traffic classes in the DDR memory controller. The QoS may be static or dynamic depending on your system requirements. The issuing capability defines how many HP outstanding transactions may be in-flight at a given time.

Registers

Example #1: AFIFM QoS: HP0-3 R/W set to Best Effort (0x0) (default)

Open

Example #2: AFIFM QoS: HP0 R/W set to Video (0x7), HP1-3 R/W set to Best Effort (0x0)

Open

FPD Interconnect Switches

The interconnect switches are comprised of the NIC-400 with QoS-400 ARM IP which provides two traffic regulation mechanisms.

1. Transaction rate regulation

2. Outstanding transaction regulation

Registers

The FPD General Programmer's View (GPV) Module contains the QoS-400 registers for regulating the AXI traffic through the NIC-400 switches. The table below maps the “top” NIC-400 switches. The “bottom” NIC-400 switches also have their own resister set for regulating traffic as secondary level of control. Regulating the “bottom” switches is not investigated here.

FPD GPV module base address: 0xFD700000

Transaction Rate Regulation

When regulating the traffic with the QoS-400, you must specify one of these sets.

1. Peak rate, burstiness and average rate

2. Peak rate only

3. Burstiness and average rate

Example #3: Transaction rate regulation

Regulate HP0 port to an average rate of 10% of the interconnect max data rate, but allow up to 4 catch-up transactions capped at 15% of the max data rate.

BL = 16

MAX = 533 MTps (8528 MBps)

Tps_avg = 0.1 * 533M = 53.3 MTps (852.8 MBps)

Tps_max = 0.15 * 533M = 79.95 MTps (1279.2 MBps)

Rate_avg = floor (256 / (100 * BL / %BW_avg)) = floor (4096 / (100 * 16 / 10)) = 25 (0x19)

Rate_peak = floor (4096 / (100 * BL / %BW_peak)) = floor (256 / (100 * 16 / 15)) = 2 (0x2)

Burstiness = 4 (0x4)

Due to quantization effects the actual rate will be lower than the target rate.

Rate (avg) = 25 * 100 * 16 / 4096 = 9.76% of MAX => 8528 * 0.0976 = 832.8 MBps

Rate (peak) = 2 * 100 * 16 / 256 = 12.5% of MAX => 8528 * 0.125 = 1066 MBps

Open

Outstanding transaction regulation

In the QoS-400 you may specify the maximum number of outstanding transactions allowed with fractional transaction resolution. The actual number of transactions will modulate between the lower and upper bound.

Example

Regulate HP0 port to 2.5 outstanding transactions.

oti = 2 (0x2)

otf = 256 * 0.5 = 128 (0x80)

DDR QoS Controller

The DDR QoS controller can throttle low latency and best effort traffic based on the Content Addressable Memory (CAM) levels to prioritize video traffic. It also provides software the ability to trigger urgent AXI transactions on a per port basis to dynamically elevate lower priority traffic.

DDR QoS Control Module base address: 0xFD090000

Open

QoS Throttle Control

The QoS DDR controller is designed to ensure that there is always space available in the CAMs for video traffic. By monitoring the individual CAM levels, the QoS DDR controller can throttle low latency and best effort traffic in favor of video traffic. The DBGCAM register can be used to monitor CAM levels to see if any are saturating.

Urgent Transactions

Urgent transactions are enabled by default in FSBL which sets in the [rd|wr]_port_urgent_en bits in the PCFG[R|W]_n registers. Urgent transactions may be issued either through expiring aging counters in the DDRC or through software by writing to the DDRC_URGENT register in the DDR QoS Controller.

DDR Memory Controller

The DDR memory controller is based on the Synopsys uMCTL2 DDR Memory Controller IP. The four HP ports from the PL funnel down to three AXI Port Interfaces (XPI) through the interconnect switch network (NIC/QoS). Since this is a multi-port memory controller, arbitration occurs based on the priority and direction of each request in an effort to optimize the DDR bandwidth. The commands in the XPI are serviced by the Port Arbiter (PA) based on a set of arbitration rules. The selected command is then forwarded to the DDR Controller (DDRC) for scheduling. Inside the DDRC the commands from the PA are queued in either the read or write Content Addressable Memory (CAM). Once a command is selected from either CAM, it is forwarded to the PHY and issued to the DDR memory.

DDRC Module base address: 0xFD070000

Open

Port Control

The Port Control registers allow software to enable and disable the DDRC ports. This can be helpful for debugging or dynamically managing ports with software.

Traffic Classes

The QoS values on each port are mapped into traffic classes. Variable priority reads and writes (VPR/VPW) have a timer associated with each command. When the timer reaches zero, the command is considered expired and gets elevated to the highest priority whether the command is in an XPI or a CAM. Video traffic class is mapped to VPR/VPW.

Variable Priority Timeouts

Variable priority timeouts can be modified to trade-off latency for throughput.

Port Aging

Port aging provides a mechanism to elevate an XPI port's priority when it has an outstanding request, but has not been serviced after a set time. When the aging timer counts down to zero, the port is elevated to the highest priority, which is equivalent to an expired variable priority command.

PA Arbitration

• Read/write arbitration

  • Reads

    • Stay on reads as long as there is a timed-out read port or an expired VPR with available credit

    • Switch to writes if there is a timed-out write port or expired VPW with available credit

    • Switch to writes when there is no read credit left and there is a pending write with available credit

    • Reads are prioritized over writes when everything else is equal

  • Writes

    • Stay on the writes as long as there is a timed-out write port or expired VPW with available credit

    • Switch to reads if there is a timed-out read port or expired VPR with available credit

    • Switch to reads if there is an HPR read port with available credit

    • Switch to reads when there is no write credit left and there is a pending read with available credit

• 2-priority level arbitration based on port aging and expired VPR/VPW commands

• 2-priority level arbitration for read requests based on DDRC read priorities

• 16-priority level arbitration based external AXI QoS inputs

• Round-robin arbitration when everything else is equal

Content Addressable Memory (CAM)

The read CAM has 64 command entries which is split into HPR and LPR/VPR sections. This ratio can be changed in the SCHED register if either of these queues are getting saturated. The write CAM is fixed at 64 command entries.

PERFHPR1, PERFLPR1 and PERFWR1 registers allow you to specify the maximum starve cycles per queue. This value specifies the number of clocks before the queue goes critical. This timeout may be tweaked depending on your traffic patterns and latency requirement. A larger value may increase video or bulk throughput by reducing queue switching, whereas a smaller value may reduce latency by switching to another queue more quickly at the expense of DDR efficiency.

PERFVPR1 and PERFVPW1 registers allow you to specify a timeout range. This will group commands that are temporally located with an expired VPR/VPW command making them all expired in an attempt to improve DDR utilization.

Address Mapper

The address mapper allow you to map the rank, bank group (DDR4-only), bank, column and row address lines to optimize your memory accesses based on your traffic patterns. The ADDRMAP{0:11} registers map individual address lines to the HIF address which is the word address generated by the XPI.

The ZCU102 has 4 GB DDR4 x64 DIMM with a burst length of 8. The table below shows the default address mapping generated by Vivado.

Debug/Status Registers

These registers are for debugging and polling the status of the DDRC ports. DBGCAM monitors the CAM levels. PSTAT monitors the XPI outstanding commands.

Writing Quasi Dynamic Group 3 Registers

Please see the ZU+ TRM UG1085 (1), Ch. 17 DDR Memory Controller, “Group 3: Registers that can be written when controller is empty” for the pseudo code.

APU

You may need to adjust the APU QoS if the HP ports are significantly impacting the APU DDR accesses. Very high HP bandwidth may result in APU software that freezes or runs very slowly.

APU Module base address: 0xFD5C0000

Registers

Test Bench

• Vitis 2020.1

• Petalinux/Yocto 2020.1

• ZCU102

Firmware

PL

The IPI block design for the test bench has a traffic generator (TG) connected to each HP port. Each TG is configured with a 128-bit data bus at 250MHz and operates as a greedy master flooding the FPD interconnect and DDR with equal read and write traffic. The theoretical data rate of each TG is 4 GBps per channel. The only TG flow control is the AXI back pressure.

Open

Software

Linux

Linux is running on the APU. The buffer memory (0x7000_0000) for the TGs is reserved from Linux through the device tree node below. This prevents Linux from virtually mapping this segment into system memory.

APM Monitor

Running an APM monitor on the RPU in OCM allows us to measure the DDR traffic while running a high level OS like Linux on the APU. Since there is no dependency on the DDR memory, the monitor software will not get blocked from executing no matter how heavy the HP traffic. This approach does not require JTAG to read the APM registers which can be affected by very high HP traffic and also requires physical access to the JTAG connector on the board.

Related Links

1. Zynq UltraScale+ Devices Register Reference (UG1087)

2. Zynq UltraScale+ Device Technical Reference Manual (UG1085)

3. ARM® CoreLink™ NIC-400 Network Interconnect

4. ARM® CoreLink™ QoS-400 Network Interconnect Advanced Quality of Service

5. Quality of Service (QoS) in ARM Systems: An Overview, Ashley Stevens, July 2014