Subscribe to DesignWare Technical Bulletin
Improving Quality of Service with DesignWare IP for AMBA Interconnect
By Phani Emani, Suresh Venkatachalam, Sriram Balasubramanian, Sreenath Panganamala, Synopsys
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 masters and slaves to meet the market demands. In any SoC-based subsystem, masters are broadly classified as latency-sensitive masters (e.g., CPUs), bandwidth-sensitive masters (e.g., GPUs) and best-effort masters (e.g., SATA and USB interfaces). These masters communicate with a shared memory controller (DDR) slave device.
In a SoC-based on-chip communication systems, the masters communicate with different slaves through the interconnect fabric. The interconnect plays a vital role in routing traffic between the masters and slaves. The access time to the bus (i.e., the time until the bus is granted) for latency-sensitive masters (CPU) and bandwidth requirements for bandwidth-sensitive masters (GPU) are key factors in determining the overall performance in a SoC, while accessing a shared memory controller slave.
AMBA® AXI™ is a high-performance SoC bus protocol. Synopsys’ 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 masters and slaves. These arbitration schemes are used to distribute the bandwidth and control the latency requirements of the masters. However, these arbitration schemes are not enough to meet requirements of the masters.
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 masters can be met by distributing the slave’s bandwidth amongst the masters in a fair mechanism to improve the SoC’s performance. The QoS feature also helps designs meet the average latency requirements of latency-sensitive masters.
Bandwidth Challenges Between Masters and Slaves
Consider the subsystem in Figure 1, consisting of different types of masters (latency-sensitive master, bandwidth-sensitive master, and best-effort master) and a shared-memory slave. The DW_axi interconnect connects the masters and slave.
Figure 1: Subsystem without QoS
Interconnect needs to meet the requirements of all types of masters, including the bandwidth requirements of the GPU, latency requirements of the CPU, and the requirements of the USB master.
The slave’s bandwidth is fixed. For example, if the slave 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 masters access the slave’s shared memory, then there is no guarantee that the average required bandwidth can be met for bandwidth-sensitive masters. For example: Consider a subsystem in which slave supports a maximum of 800 Mbps. The GPU, a master, needs a sustained bandwidth of 400 Mbps. There are other best-effort master(s) like SATA and USB 3.0 in the system accessing the same slave. In this case, there is no guarantee that GPU gets a sustained bandwidth if all the masters are accessing the slave. The GPU might take the maximum share of the bandwidth and other masters will not get a chance to access their share. This may result in reduced performance.
- If bandwidth-sensitive and best-effort masters try to access the slave most of the time, then the latency requirements of CPU master 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 masters.
Considering the conditions described previously, adding QoS to the interconnect improves performance:
- If all the masters access the slave’s shared memory, then the bandwidth requirement of each master is met by regulating (or limiting) the traffic on master ports. For example: Consider a sub-system in which slave 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 masters in the system.
- If all the masters try to access the slave, 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 masters in a sub-system. Synopsys’ QoS solution is illustrated Figure 2.
Figure 2: QoS in DesignWare IP for AMBA Interconnect
The QoS controller in DW_axi is comprised of a QoS bandwidth regulator and a QoS arbiter.
The QoS regulator regulates the rate of the incoming traffic on the address channel of a master port. The QoS regulator can be configured on each of the master 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.
The QoS arbiter prioritizes the requests based on the priority value. The QoS arbiter can be configured on each of the slave 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 masters.
The memory controller (DDR) bandwidth is fixed for a given frequency of operation and data bus width. The QoS regulator on the master port will regulate the incoming traffic at a master port, which lends predictability to the sharing of the slave’s bandwidth by different masters. The QoS regulator can be programmed on each master port, per address channel separately, according to the bandwidth requirements of the master. The requests from the master, 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 masters.
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 master port, per address channel.
- QoS arbiter on each slave port, per address channel.
The DesignWare IP for AMBA Interconnect is packaged as a .run file. Designers use the Synopsys 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.
Subscribe to DesignWare Technical Bulletin