A Brief History

The Advanced Microcontroller Bus Architecture, commonly known as AMBA, was introduced by ARM (Advanced RISC Machine) in the 1960s to create an open standard for designing the various functional blocks of a System-on-a-Chip (SoC) for high-performance communications. Despite being initially designed for microcontrollers, hence the name AMBA, the extent went far beyond, all the way to the latest gen smartphones and processors.

At its first inception in 1966, the two buses introduced by ARM were the Advanced System Bus (ASB) and the Advanced Peripheral Bus (APB). The APB was designed for low bandwidth peripherals that do not meet the requirement for high-performance designs, similar to some other industry standard protocols. To integrate easily into other design flows, the APB protocol was made to transition to the rising clock edge, requiring two clock cycles for data transfer to take place. On the other hand, the Advanced eXtensible Interface (AXI), also developed by ARM, is an on-chip communication bus protocol similar to APB but a much faster and high-performing protocol. Compared with the former, it maintains a higher frequency operation without using complex bridges. It has the necessary flexibility to be implemented in interconnect architectures and has backward compatibility with the AHB and APB interfaces. Some key features that separate it from the other protocols are that it has separate address/control and data phases and has burst-based transactions with only the start address issued.

The Bus Bridge

Now, the readers might ask, if better-performing high-speed AXI protocols are out there, why are the other protocols such as APB still present in the field? The simple answer is power consumption. Being a high-frequency protocol, the AXI requires much more power than the rest. It has a higher latency, and the bus standard is not shared. These constraints make it unsuitable for the wide range of applications that are contemporary today.

A link or a bridge between the two protocols is thus necessary to maintain communication between them. Moreover, as these have different clock frequencies, implementing a Clock Domain Crossing (CDC) becomes imperative. The principle of the CDC can be described as the following: a car goes to the gas station to fill up on gas. There might be a queue depending on the time of the day. The queue might be empty or have 10-15 cars up front. The first car in the queue gets priority and fills up its tank. When the first car is done, the second car moves up the queue to become the first car and repeats the same process. Eventually, all the cars are processed, and the station waits again for the cars to arrive. This basic idea is called a FIFO, or first in first out. The same principle applies to the CDC which processes the high-speed data from the AXI and slows down the process according to the lower clock speed of the APB. Other blocks such as the Address Decoder, Write Data Aligner and Read Data Aligner are also required. AXI and APB Transfer Controllers are also required - to establish a control sequence between the two interfaces. The descriptions of each of the blocks may be too elaborative for this blog. But readers can get ample information over the internet.

The Structure

The Hardware Team at DSi aimed to create an APB to AXI bridge that would enable this communication between the two protocols. The team completed both the design and thorough verification of the bridge communication. The design was made in SystemVerilog, arguably the most popular Hardware Description Language nowadays. However, to achieve a completely flawless design, it is imperative to set design goals while possessing a proper understanding of the micro-architecture of the protocols. The team maintained a concrete design plan along with continuous documentation that enabled them to work in a structured way.

But it is not sufficient to just design an APB to AXI bridge and call it a day. A proper verification methodology is required to ensure that all the goals were achieved, find corner cases, and improve the design for better use. A standardized methodology for verifying integrated circuit designs is the Universal Verification Methodology (UVM). UVM was primarily derived from the OVM (Open Verification Methodology), based on Verisity Design's eRM (e Reuse Methodology) for the e Verification Language in 2001. Unlike previous methodologies developed independently by simulator vendors, the UVM class library brings much automation to the SystemVerilog language, such as sequences and data automation features (packing, copy, compare), and is an Accellera standard with support from multiple vendors: Aldec, Cadence, Mentor Graphics, Synopsys, and Xilinx Simulator (XSIM).

The figure shows all the components used in the UVM verification strategy. The standard makefile was used for developing a presentable way of running the simulations. The preplanned test cases were defined within the makefile. The user now simply needs to add the name of the specific test to run in the command line as an argument in the Linux Terminal only, all else is automated. The log files containing the report of success and failures are then generated accordingly. The source codes are split into src, verif, and run directories. The src directory contains the design source files. All other verification files are within the verif directory with top, test, and env subdirectories. The top directory contains the top-level testbench and interface file, the test contains the test library and sequence item, and the env contains the scoreboard, coverage, and two agent subdirectories with the driver, monitor, and sequencer for each agent.

Run all the simulations

Run the specific simulation

Timing diagrams were monitored to get a visual representation of the waveforms, which enabled a better understanding of the outputs. Consecutive writes and reads were tested as well as with other different criteria. Corner cases and error cases were tested and resolved accordingly. The scoreboard kept track of the write and read data and used it to match them. We also generated a coverage report based on the number of functionalities tested and covered.

Even ignoring the successful implementation of the APB to AXI bridge, the experience gained from this project remains invaluable to the team. It enabled us to develop a strong base on SystemVerilog design and helped us to gain a greater understanding of the Universal Verification Methodology.