Browse > Home / 信息中心 / SNUG / 2007-2008 年论文集 / AMBA Bus Performance Test Based on PowerBench & SYNOPSYS’ VIP

AMBA Bus Performance Test Based on PowerBench & SYNOPSYS’ VIP


Lai Desheng, Ling Minghui, Cheng Zhihui, Wang Wancai, Yi Min
Shenzhen HiSilicon Technologies Co., Ltd


Abstract

The AMBA bus is used in today’s System on Chip (SoC) broadly. More and more modules are developed with an AMBA interface.

Some multi-function modules have more than one AMBA interfaces indeed. Most of the Verification engineers do much work on the verification of the interface spec. The spec is so complex to be comprehended fully depending on much experience. Usually it can not be covered by the testbench entirely. The performance, for example the bus traffic, is verified rarely, while it is very importance. Fortunately, many EDA vendors, such as SYNOPSYS, provide the Verification IPs (VIPs) for the AMBA, which can test the consistency of the AMBA interfaces to the spec. When errors exist in the interface, the VIP can capture them and give the corresponding error messages. So the user needs to care the performance test more. This paper gives an example to test the traffic performance of the AMBA bus. The testbench is based on the AMBA VIP owned by SYNOPSYS and PowerBench owned by HiSilicon.

Keywords: VIP, AMBA, SoC, PowerBench

1 Introduction

SoC is composed of one or more central cores, IPs for the service and the bus interconnection module usually. The central core determines the bus type and the architecture. ARM core series share the most of embedded CPU market because of their high performance & low power and ARM7TDMI is used by many designs due to its low price. AMBA (Advanced Microprocessors Bus Architecture) designed by ARM company is so high performance with the popular ARM core that it becomes the main bus architecture used in SoC.

Besides the core, many IPs such as AMBA master or slave devices developed by the user or provided by the vendor for the service are integrated in the SoC. The master devices often need to access the slave devices on the bus as the core does. Some device such as LCD controller occupies so large bandwidth to disturb the whole SoC running. So the bus performance plays an important role in the SoC design. In the past, the function and AMBA interface spec verification are the primary and difficult work for the verification engineers. The main reason is the interface spec is very complex and not to be covered fully by the testbench and the verification engineer spends much time on the verifying to find more bugs through various methods. Lack of performance test tools and test environment restricts the bus performance test to be performed.

Today, some vendors such as SNOPSYS can provide the VIPs for AMBA interface test. The VIPs support the key feature of the AMBA. The verification engineer needs not to develop the AMBA BFM (Bus Function Model), which may be not full-right, and focuses on the performance test. PowerBench developed by HiSilicon is a verification tool used with the simulator together, which supports the stimulus data generation, bandwidth control and so on. During simulation, PowerBench resides in the simulator to help the user to build a powerful testbench.

This paper introduces a testbench based on SYNOPSYS’ VIP as AMBA master, slave device and PowerBench to test the AMBA performance. The VIPs perform bus transactions to exchanger service data or control data each other through the bus interconnection module and PowerBench generates the service & control data, controls bandwidth and analyzes QoS real-time.

2 SYNOPSYS’ DesignWare AMBA VIP

SYNOPSYS’ DesignWare VIPs are the verification models for the ARM AMBA 3 AXI Interface including a Master, Slave, Interconnect model and so on. Each model supports key features of the ARM AMBA 3.0 AXI interface, e.g. separate address/control and data phases, unaligned data transfer support, burst-based transactions, separate read and write channels, and out-of-order transaction completion. The VIP is proven on many projects and reliable. They may bring the following benefits.

  • Saves testbench development time. VIPs are easy to be integrated into your current methodology and provides coverage reports and protocol checks.
  • Reduces project risk. VIP enables verification of full breadth of each protocol and supports for constrained random verification, tests for corner cases behavior.
  • Highest quality. Design is proven on hundreds of customer designs and extensive regression environments

2.1 VIPm

VIPm is the AMBA master model. It supports configurable transactions, unaligned data transfers, locked access, and transaction messaging. It can generate the master ARM AMBA 3 AXI transactions as defined by the AMBA® AXI Protocol v1.0 specification. The purpose of VIPm is to generate all types of read & write cycles on AMBA 3 AXI bus. While all AMBA 3 AXI transactions are initiated by the Master verification model, there may be more than one Master in a system. The Master can be used to verify the AMBA 3 AXI interconnect or a slave device. Figure 2-1 shows a simple AMBA 3 AXI testbench which uses the Synopsys model to test either a slave or AMBA 3 AXI interconnect. Reading and writing transactions are accomplished using five independent bus channels, each with its own handshake signals. The address, data and response transfers can happen on independent cycles which allow maximum use of the buses, especially if they are shared. The VIPm under control of axi_vip_bfm writes or reads the service data & control data from PowerBench to the slave device. The basic flow in using the VIPm is the following.

  • Configure the model. Before starting any transaction, you configure the Master’s overall behavior using the set_config_param . Create and set values in the XACT transaction buffer. The XACT transaction buffer contains all the information and data (including expected results) defining an AMBA 3 AXI interface transaction.
  • Issue the transaction. The VIPm has only one command to issue transactions: send_xact. The command reads the attributes of the XACT transaction buffer and then issues the appropriate transfer on the bus.
  • Get the results. When the results of the requested transaction are ready, the model makes available a XACT results buffer. You obtain the contents of the result buffer through the get_result command or through the use of a model initiated notification called AXI_MSGID_MASTER_SEND_XACT_COMPLETE. From this notification event you can extract the results buffer to read its content
Figure2-1 VIPm Model

2.2 VIPs

VIPs is the AMBA slave model as Figure 2-2. It supports model supports configurable transactions, unaligned data transfers, variable slave response behavior, and FIFO memory. The VIPs is a bus functional model that can respond to ARM AMBA 3 AXI interface transactions. It can be used to verify an AMBA 3 AXI interconnect or master. Reading and writing transactions are accomplished using five independent bus channels each with its own handshake signals. The address, data and response transfers can happen on independent cycles which allow maximum use of the buses especially if they are shared. The slave supports multiple address, multiple data buses. This includes multiple write response buses.

Transactions are always in data bursts of one to sixteen transfers or “beats”. The data buses can be configured to support transfers up to 128 bytes wide. The Buffer Response channel returns write status results and consists of a single summary transfer for each write burst. Read status is returned with each read data transfer. The VIPs provides user configurable memory space with RAM blocks and FIFO’s that have variable data and variable response behavior. The Slave responds to Read and Write transaction requests from a Master by using the configured memory space data and attributes. Under control of the Monitor, VIPs used in this testbench respond to the bus transactions initialized by VIPm. Following is the basic flow in using VIPs.

  • Configure the model as a whole. In this first step you setup general characteristics of the model. For example, in this step you would setup such attributes as data and address widths. You use the set_config_param command for setting model wide behaviors. Configure how the Slave will react to specific transactions. You do this by creating a series of “Response buffers (RESP)” which define in detail how the Slave will react to any possible transaction on the AMBA 3 AXI bus. You can create RESP buffers for specific types of transactions such as read, write, locked, cached or instruction.
  • Once you have defined any needed RESP buffers, you place them in a “match list”. When a transaction arrives on Slave’s port, it will scan a “match list” to find the buffer that defines how the Slave should react to that particular request.
  • Start the simulation once you have fully configured the Slave. The slave runs as a daemon that needs to be started after initial configuration is done. The command star is used to start the model.
Figure2-2 VIPs

2.3 VIPi

VIPi is the DesignWare Interconnect Verification IP called AXI Bus Matrix generally. It is a bus functional model that provides a means of easily interconnecting AMBA 3 AXI interface Masters and Slaves as part of verification platform for designs using the AMBA® AXI Protocol (v1.0). The number of master and slave is up to 32 respectively. The AMBA performance focuses on this model which is the DUV tested by this testbench. The VIPi contains the following components.

  • Separate Arbiters for each channel (read address, read data, write address, write data, write response).
  • Separate Decoders for each address channel.
  • Multiple data buses.
  • A built-in default Slave.

Figure2-3 shows the internal architecture of the VIPi. A DUT can replace any of the Master or Slave models shown. The VIPi model, by default, implements the Interconnect as a shared address bus, shared data buses, and shared write response buses. You can switch between the predefined architectures SASD and SAMD. The Interconnect does not insert registers on any channel. Every bus has its own arbiter associated with it, and can be operated with specific configuration settings. The arbiter controls proper bus-to-pass data. The address bus and write data channels use a three-tier arbitration scheme; the write response and the read data channels use a round-robin scheme. The Interconnect model maintains a global routing order table, with which the Interconnect maintains the order of transactions (A[W|R]ID) on the write or read channels from the same Master based on recording “being-routed transactions”. The decoder only resides on the address channel and decodes the selected master’s address. The Interconnect supports the interleave feature on write and read channels.

Figure2-3 VIPi

3 Testbench

Figure 3-1 shows the testbench structure for the AMBA performance test. It is made up of SYNOPSYS’ IP & VIP, ARM core and other components from PowerBench. The AXI Bus Matrix is DUV. The IP & VIP are connected through DUV. Among the testbench, axi_vip_bfm combined with SYNOPSYS’ VIPm are the master devices and Monitor combined with VIPs is the slave devices. The master device directed by the service configuration accesses the slave device through DUV. That several master and slave devices exchange service data according to the SoC data-flow imitates the SoC running environment.

Figure3-4 Structure of the testbench for AMBA performance test

3.1 ARM Core

In this testbench, the processor is ARM1176JZF-S, which is the core of SoC. This core can configure the IP or VIP and run the specific software. The purpose of this testbench is test the bandwidth of the VIPi and the service model is implemented by axi_vip_bfm & Monitor. The service software needn’t run, so the main task of the ARM core is to configure the IP and VIPs.

3.2 L2 Cache and AXI DMAC

L2 Cache and AXI DMAC are developed by HiSilicon. These two IPs communicate with the other VIPs through VIPi. The function of L2 Cache is to increase the data speed between ARM core and peripherals. The DMAC is used as the master device to exchange the mass data among the peripherals without the ARM core participation.

3.3 Data Generator

Data Generator is an important component in the testbench. This component can generate the service & control data based on the specific constrain. The scheduler of PowerBench controls Data Generator to let out the stimulus data provided that the actual bandwidth is less than the configured one. In this testbench, the configured bandwidth is larger than the performance of the VIPi and the bottleneck of bandwidth is not the PowerBench, so the test result is the real bandwidth of the VIPi.

3.4 axi_vip_bfm

This module is a BFM. It interacts with PowerBench to get the service & control data, then configures the VIPm using the control data and controls the VIPm to send the service data to VIPs. The key features are the following.

  • Support write transaction. The data is from PowerBench and the bandwidth is controlled by PowerBench.
  • Support read transaction. During read, axi_vip_bfm also requires the data from PowerBench, but discard the data. The purpose is to realize the read data flow control. Before each burst read, the number of byte to be read is known. So the remained bytes can be calculated after each burst read. If the remained bytes are less than the bytes to be read, axi_vip_bfm needs request data from PowerBench. The read data is sent to PowerBench for check.
  • Support control signal interleaving. The control signal is aid, arddr, awaddr, aburst, assize, alen, alock and so on. These signals compose a data section which can be requested from PowerBench. Interleaving can be implemented in the testcase, for example:

keep AXICtrl.asize –exact 30:0×3 30:0×2 20:0×1 20:0×0
In the testcase obove, the burst time is 10 and the time of asize = 3, 2, 1 ,0 is 3, 3, 2 ,2 respectively.

  • Support INCR, unaligned transfer, aligned on 4kb boundary processing, random value of alen & asize and the combination.
  • Support wrap transaction, random value of alen & asize and the combination.
  • Support the switch between INCR and wrap.

The VIPm used in the BFM ensures that the BFM can communicate with the DUV correctly and it collects the function coverage of the AMBA master interface, too. The other code in this BFM is in the transaction level and the function of the BFM is easy to work out.

3.5 Checker

Checker is used to compare the result from DUV and the one from the RM. In this testbench, Checker can analyze the data received by each VIPs is correct or not and the data from VIPm is written into the corresponding VIPs rightly or not. If it is correct, the function of the VIPm & VIPs is right and no error exists in the VIPi.

3.6 Monitor

Monitor is data acquisition module. It interacts with VIPs to receive the service data and then sends it to RM for analysis (merging or unmerging). RM parses the data and get the payload slice. At last the slice is stored by Checker for check. The VIPs in the monitor handles the cycles of the AMBA interface and collects the function coverage of the AMBA slave interface. It is the reliable channel used by the monitor to received data from the DUV

3.7 RM

RM is the reference model for the DUV, which is coded by C/C++ language usually. It can analyze the control data requested from PowerBench by axi_vip_bfm and obtain some main information such as VIPs No.. The analysis result is stored in the Scoreboard and ready for Checker.

3.8 Scoreboard

Scoreboard is the memory to store the analysis result from RM. When the testbench receive the VIPs No. and service data actually, the Checker searches the corresponding result from RM and compares with the actual result. The comparison result is recorded in the Scoreboard for GUI display.

3.9 Tests

Tests are series of tcl script to control the simulation. In this testbench, all operations such as testcase, directed by the user are implemented in tcl scripts composed of many tcl commands from the simulator VCS. The write & read real-time bandwidth of each VIPm can be displayed on the Qos GUI of PowerBench.

4 Simulation

A Tx port for each VIPm and a Rx port for each VIPs are created through the corresponding tcl command. axi_vip_bfm can request service & control data through the Tx port from Tx port. The data complies with the service model and data flow on the AMBA. After the data is obtained, axi_vip_bfm configures each VIPm according to the control data and stores the service data into the VIPm. Finishing the preparation, axi_vip_bfm send a start command to the VIPm and the VIPm performs sorts of bus transactions on the bus with the simulation time gong on. The write bandwidth is calculated by PowerBench simultaneous. If the data has been sent and the actual bandwidth is less than the configured one, axi_bfm_bfm can get the service & control data again. Or the VIPm is in the ready state and the actual bandwidth decreases. Before test the DUV, the configured bandwidth is so large that the bottleneck of bandwidth exists in the DUV. As the result, the bandwidth is the real one of the DUV. The read bandwidth test is the same as the write test. During the bandwidth test, the Monitor and VIPm’s read transaction are used to ensure the validity of the transaction too. When error occurs, the simulation is stopped. Figure4-1 is the simulation flowchart.

Figure4-5 Simulation flow

5 Test Result

The testbench can be used to test the performance of SoC architecture at the conception phase. At this time, the AMBA master and slave devices are the SYNOPSYS’ VIP. The testbench can also be used to test the performance at the system test phase. At this time, the AMBA master and slave devices are the IP developed by user or provided by vendors. Because VIPi can interconnect up to 32 master devices with up to 32 slave devices and each device can be enabled or disabled, the verification engineer can build a testbench for a specific SoC project. The author enables only one VIPm and one VIPs in the testbench and uses the default parameter to configure the DUV. After simulation, the real-time bandwidth is shown as Figure5-1 and Figure5-2.

Figure5-1 shows the real-time bandwidth on the condition of a very large configured bandwidth. The bottleneck is performance of VIPi itself. The bandwidth is steady gradually with the simulation time gong-on. The average of read and write bandwidth is 1691.02mbps and 2646.34mbps respectively.

Figure5-6 Bandwidth QoS(1)

Figure5-2 shows the real-time bandwidth on the condition that the configured read bandwidth is 1400mbps and the write one is 1800mbps. The VIPi’s performance is better than the one of the VIPm, so the bottleneck is the VIPm and the bandwidth is not the real one of the VIPi. At the begin of simulation, the simulation time is equal to zero and a packet of the service & control data can be returned to axi_vip_bfm, as Figure5-2 shows, a peak value appears. After a time, the bandwidth is steady and near to the configured one.

Figure5-7 Bandwidth QoS(2)

The service model may be optimized before the behavior of VIP is more like the device. As the optimization goes on, the test result can be more and more reasonable. This is the direction that the testbench is improved.

6 Conclusion

SoC is very popular today. The bus architecture is the most important factor to be considered and the bus bandwidth is demanded to meet the requirement of the service and economical. SYNOPSYS can provide many powerful VIPs which can cover the verification on cycle level and the verification engineer maybe focus on the performance test. This paper shows an example for the AMBA performance test. The author hops that all SoC verification engineers are able to realize this conception and face the SoC verification challenge confidently.

7 Reference

[1] Using the DesignWare Verification Models for the AMBA 3 AXI Protocol, SNOPSYS, Version 3.50a, November 2005.
[2] PowerBench User Manual(V3.1), HiSilicon, January 2007.