²ÝÁñÉçÇø

Introduction

Modern systems-on-chips (SoC) are becoming more complex with a larger number of CPUs and advanced GPUs to support a wide range of applications with additional peripheral managers and subordinates to meet the market demands. In any SoC-based subsystem, managers are broadly classified as latency-sensitive managers (e.g., CPUs), bandwidth-sensitive managers (e.g., GPUs) and best-effort managers (e.g., SATA and USB interfaces). These managers communicate with a shared memory controller (DDR) subordinate device.

In a SoC-based on-chip communication systems, the managers communicate with different subordinates through the interconnect fabric. The interconnect plays a vital role in routing traffic between the managers and subordinates. The access time to the bus (i.e., the time until the bus is granted) for latency-sensitive managers (CPU) and bandwidth requirements for bandwidth-sensitive managers (GPU) are key factors in determining the overall performance in a SoC, while accessing a shared memory controller subordinate.

AMBA? AXI? is a high-performance SoC bus protocol. ²ÝÁñÉçÇø¡¯ DesignWare? IP for AMBA Interconnect (DW_axi) is an interconnect fabric implementation of AMBA 3 AXI/AMBA 4 AXI protocol. The DW_axi supports different arbitration schemes while routing the traffic between managers and subordinates. These arbitration schemes are used to distribute the bandwidth and control the latency requirements of the managers. However, these arbitration schemes are not enough to meet requirements of the managers.

The AMBA 4 AXI protocol brings in quality of service (QoS) signaling on the AXI bus to address the challenges imposed by bandwidth and latency requirements of various IP in a SoC.

By using the QoS feature, the average bandwidth requirements of different managers can be met by distributing the subordinate¡¯s bandwidth amongst the managers in a fair mechanism to improve the SoC¡¯s performance. The QoS feature also helps designs meet the average latency requirements of latency-sensitive managers.

Bandwidth Challenges Between Managers and Subordinates

Consider the subsystem in Figure 1, consisting of different types of managers (latency-sensitive manager, bandwidth-sensitive manager, and best-effort manager) and a shared-memory subordinate. The DW_axi interconnect connects the managers and subordinate.

Interconnect needs to meet the requirements of all types of managers, including the bandwidth requirements of the GPU, latency requirements of the CPU, and the requirements of the USB manager.

The subordinate¡¯s bandwidth is fixed. For example, if the subordinate is a DDR memory, it can only support limited bandwidth based on the data width and frequency of operation.

Consider the following situations:

• If all the managers access the subordinate¡¯s shared memory, then there is no guarantee that the average required bandwidth can be met for bandwidth-sensitive managers. For example: Consider a subsystem in which subordinate supports a maximum of 800 Mbps. The GPU, a manager, needs a sustained bandwidth of 400 Mbps. There are other best-effort manager(s) like SATA and USB 3.0 in the system accessing the same subordinate. In this case, there is no guarantee that GPU gets a sustained bandwidth if all the managers are accessing the subordinate. The GPU might take the maximum share of the bandwidth and other managers will not get a chance to access their share. This may result in reduced performance.
• If bandwidth-sensitive and best-effort managers try to access the subordinate most of the time, then the latency requirements of CPU manager may not be met, which also reduces performance.

Implementing QoS will address these issues.

Addressing Performance Issues with QoS

The purpose of QoS in the interconnect is to regulate and prioritize the incoming traffic so that the latency and bandwidth requirements are met for all types of managers.

Considering the conditions described previously, adding QoS to the interconnect improves performance:

• If all the managers access the subordinate¡¯s shared memory, then the bandwidth requirement of each manager is met by regulating (or limiting) the traffic on manager ports. For example: Consider a sub-system in which subordinate supports a maximum of 800 Mbps. The GPU requires a sustained bandwidth of 400 Mbps. QoS will regulate the GPU at 400 Mbps so that the GPU does not over-consume the bandwidth or starve for bandwidth. This will ensure that remaining bandwidth can be shared by other managers in the system.
• If all the managers try to access the subordinate, then QoS will prioritize the CPU requests to meet latency requirements.

QoS Implementation in DesignWare IP for AMBA Interconnect

The QoS in DW_axi is designed to meet the requirements of all types of managers in a sub-system. ²ÝÁñÉçÇø¡¯ QoS solution is illustrated Figure 2.

The QoS controller in DW_axi is comprised of a QoS bandwidth regulator and a QoS arbiter.

QoS Regulator

The QoS regulator regulates the rate of the incoming traffic on the address channel of a manager port. The QoS regulator can be configured on each of the manager ports per address channel, i.e., each write and/or read address channel. If the incoming traffic is more than the desired rate, the QoS regulator will limit the traffic.

QoS Arbiter

The QoS arbiter prioritizes the requests based on the priority value. The QoS arbiter can be configured on each of the subordinate ports per address channel, i.e., each write and/or read address channel. The QoS arbiter ensures that high-priority requests are serviced first to meet the requirements of latency-sensitive managers.

The memory controller (DDR) bandwidth is fixed for a given frequency of operation and data bus width. The QoS regulator on the manager port will regulate the incoming traffic at a manager port, which lends predictability to the sharing of the subordinate¡¯s bandwidth by different managers. The QoS regulator can be programmed on each manager port, per address channel separately, according to the bandwidth requirements of the manager. The requests from the manager, on each address channel, will be regulated based on the programmed rate. The QoS Arbiter will prioritize the high priority requests, thereby meeting the latency requirements of latency-sensitive managers.

Configurable Features in DesignWare IP for AMBA Interconnect

The following DW_axi features are fully configurable and can be selected when configuring the core in coreConsultant or coreAssembler.

• Enabling or disabling QoS feature through configuration parameters in AMBA 3 AXI / AMBA 4 AXI protocol modes of operation.
• External source (pin level) or internal source (registers) of the QoS value in AMBA 3 AXI protocol mode of operation.
• QoS regulator on each manager port, per address channel.
• QoS arbiter on each subordinate port, per address channel.

The DesignWare IP for AMBA Interconnect is packaged as a .run file. Designers use the ²ÝÁñÉçÇø coreConsultant tool to configure, synthesize, simulate, and verify the IP configuration. The image also includes:

• Configured Verilog RTL source code
• Verilog test suite that integrates the device-under-test (DUT) models
• Leda checker rules used for linting and example report
• Support for creating gate-level DUT models using a GTECH library

For more information, visit www.synopsys.com/AMBA.