Design of a Bus Communication Architecture using AXI Protocol based SoC Systems

Abstract

Introduction

I. INTRODUCTION

These days, a lot of SOCs use the advanced extensible interface, or axi, protocol. The Advanced Microcontroller Bus Architecture (AMBA) specification includes Axi. This AMBA AXI protocol is intended for high-performance, high-frequency system designs and has a number of characteristics that make it suitable for high-speed submicron connections.

Experts in the field created the excellent methodology known as VIP to cut down on time spent in test bench settings. Vip is a built-in architecture that is incorporated in SoCs and is used for on-chip transaction verification. This work builds a test bench for the purpose of verifying axi memory transactions and data transfer between locations throughout the read and write phases in both the same and separate addresses.

Here, the primary goal of the verification environment—which was created using the Verilog system—is to confirm the aforementioned memory transfers. The generator, mailbox, monitor, interface, coverage, bus functional model (BFM), and monitor are the primary VIP components. Each module in this case is made in accordance with its intended use [1].

The main objective of the generator is to generate different test cases for different applications. One kind of conduit for communication that allows for message exchange is a mailbox. Here is where the bfm and generator exchange information. Transactions are received from the generator and sent to the axi interface by Bfm, which is an essential part of the verification environment. The axi interface’s functions include connecting the slave and master and assisting with handshaking during dialogue. We can only retrieve the outputs, which contain all of the transaction signals, by using the Axis interface. To ensure that transactions are authentic, Axi Monitor is employed in compliance with the handshaking protocol. Here, the monitor is meant to be used for transactions using memory. Only when all of the different modules are instantiated in the top module and appropriate synchronization is maintained between them will we obtain precise handshaking. The memory transactions in this study are

A. Test Case 1:Write and Read from the Same Location

Test case 1: In this instance,  the primary focus was on write and read transactions that took place at the same address.  Axia protocol, on the other hand, divides write data operations into numerous phases and write address operations into a single phase [2]. The write address signal, or AWADDR, is a 32-bit signal that designates the specific address where numerous pieces of data need to be written. Similarly, read data operations happen in numerous phases, and read address operations happen in a single step. ARADDR stands for read address signal, a 32-bit signal. The signals in this test case must have the same for both ARADDR and AWADDR, which also happen at the same place.

B. Test case 2:write and read from the different location

Test case 2: Testcase 2 differs greatly from Testcase 1. In this instance, read and write take place at distinct places. The fact that the AWADDR and ARADDR signals in this test instance originate from different addresses suggests that the write and read signals ought to originate from separate addresses. In this work, we are practically testing the aforesaid test scenarios with the aid of collected waveforms.

II. RELATED WORK

Research and development is now underway in the domain of bus monitor design for performance analysis of AXI protocol- based System-on-Chip (SoC) devices. AXI-based interconnects in SoC designs have been the subject of several related publications that have investigated related ideas and approaches with the goal of improving the effectiveness and precision of such analyses.

The following are some significant findings from previous studies:

1. Bus Functional Models (BFMs): To simulate AXI transactions and confirm system behaviour, Bus Functional Models (BFMs) have been used in numerous prior research. BFMs are transaction-level models that can produce AXI traffic for testing and validation. They are commonly implemented in Verilog or System Verilog. These models play a key role in confirming functional accuracy and conformance with the AXI protocol.
2. Performance Profiling Tools: A number of tools have been created to profile AXI-based SoC systems’ performance. These tools provide insights into latency, throughput, and other important parameters while capturing AXI transactions during runtime. Instruments for performance profiling assist in locating bottlenecks and improving system setups [3]
3. FPGA-based Monitoring Solutions: AXI protocol analysis-specific FPGA-based monitoring solutions have been the focus of some research. In order to record and analyse AXI transactions in real-time and offer comprehensive insight into system-level interactions, these solutions frequently include the creation of bespoke hardware designs
4. Integration with System-Level Simulation Environments: System C or System Verilog are two examples of system-level simulation environments that may be integrated with AXI bus monitors to provide a comprehensive analysis of SoC performance. Co-simulation of hardware and software components is made possible by this integration, allowing for a thorough examination of AXI-based communication.
5. Open-Source Initiatives: To meet the requirement for AXI performance analysis and monitoring, several open-source initiatives have been developed. These projects frequently include reusable parts, like software libraries or Verilog modules, to make it easier to create unique monitoring systems for AXI-based SoCs design.

By leveraging insights from these related works, the design of a bus monitor for performance analysis of AXI protocol-based SoC systems can benefit from established methodologies and techniques. The goal is to contribute to the advancement of tools and methodologies for optimizing the performance and efficiency of complex SoC architectures utilizing the AXI protocol.Top of Form

An open standard protocol called Advanced Microcontroller Bus Architecture (AMBA) is used for on-chip interconnects, which are specifications for connecting and managing functional blocks within a system-on-chip (SoC). Small-scale SoCs can readily use the AMBA bus. Because of its efficiency, the AMBA bus has thus served as the SOC market’s representative. The AMBA specification defines three different buses: Advanced Peripheral Bus (APB) Advanced High performance Bus (AHB) Advanced extensible Interface Bus (AXI)

The AMBA standard details all of the signals, transfer methods, structural layout, and other bus protocol details for the APB, AHB, and AXI buses. The AMBA APB is secondhand to communicate with any peripheral that has little bandwidth and doesn’t require the high performance of a pipelined bus interface.

APB peripheral device that meet the specifications listed below can be easily incorporated into any design process:

a. Devices with low-speed peripheral buses • A non-multiplexed, synchronous bus 8, 16, 32-bit data bus, 32-bit address bus, single master (bridge)

b. Non-pipelined with the following specifications, AMBA AHB is a new bus level that operates above APB and incorporates the capabilities needed for high-performance, high clock frequency systems.

c. Split transactions; burst transfers • Greater data bus configurations (64/128 bits);

d. Single clock edge operation;

e. Single cycle bus master handover; AXI enhances the functionality of the AHB bus and supports the next generation of high act SoC architectures. The areas of the AXI bus protocol are backward compatibility with AMBA AHB and APB inter- faces, litheness in summit the boundary and act requirements of a wide range of components, and support for high frequency operation without the need for complex bridges. The features of the AXI protocol are as follows: • Support for non-aligned addresses, Distinct control, and data phases and the capacity to issue several pending addresses.

III. BUS MONITOR

Creating a specialised module that watches and records AXI transactions taking place within the SoC is necessary when  designing a bus monitor for performance monitoring of AXI protocol-based System-on-Chip (SoC) systems. This bus monitor is essential for examining the AXI interconnect’s efficiency, throughput, and latency since it offers insightful data that can be used to optimise the system and improve performance. The following are important factors and parts that are usually included in the bus monitor design for AXI protocol analysis [4]:

1. Transaction Observation: AXI transactions that take place on the connection must be seen by the bus monitor. This entails recording data, address, response status, data, transaction type (read or write), and other pertinent information.
2. Interface: The AXI interconnect in the SoC is directly interfaced with by the bus monitor. Depending on the design needs, it may connect to the interconnect via AXI protocol interfaces (AXI4, AXI4-Lite, etc.).
3. Transaction Decoding and Analysis: The bus monitor decodes and examines AXI transactions to derive important performance indicators. This include figuring out any bottlenecks as well as latency, or the amount of time it takes for a transaction to finish [5].
4. Data Storage and Logging: The bus monitor logs transaction data to an external storage medium or keeps it in memory to enable thorough performance analysis. For the purpose of post-analysis and system behaviour visualisation, this data logging is essential.
5. Integration with Monitoring Tools: To offer real-time insights into system behaviour, the bus monitor may integrate with analysis frameworks or performance monitoring tools. The performance of the AXI interconnect may be continuously observed and assessed thanks to this integration.
6. Hardware Implementation: The bus monitor can be implemented using either software (running on the SoC or included in firmware) or hardware (FPGA-based), depending on the needs and application. For precise monitoring, hardware implementations provide direct access to AXI signals.
7. Validation and Verification: To guarantee correct transaction capture and analysis, the bus monitor is put through validation and verification procedures prior to deployment. Simulation environments and test benches are used to verify the functionality in different scenarios [6].
8. Customisation and Adaptability: A well-thought-out bus monitor has to be both flexible and able to accommodate various system architectures and AXI configurations. Its adaptability makes it possible for it to be easily included into a variety of SoC architectures.

D. Test Case

Test Example :

The list of test cases is included in the „Test case". Every test case is linked to "sequences" that are written for various scenarios, such as

single_write_operation [12]. write-followed-read-operation, multiple write,

single read, multiple reads

To confirm the design for a specific scenario, any test case is linked to the Verification Environment [6].

Transaction Generator (AXI) The "sequence item" is another name for the transaction generator. A class called Se- quence_item has all port signals as one of its properties. The "rand" keyword is used to declare each of these signals, allowing this class to allot the random rate to each signal after using the randomize method. The DUV is later assigned these generated input values [13].

XV. AXI MASTER TRANSACTION

It consists of the signals that the master drives. There is an instance of the AXI_transaction_generator in this class. The values produced by the AXI_transaction_generator may be overridden by the master transaction. The values produced by the AXI transaction generator are sent to the DUV assuming that no signals have been overridden.

???????XVI. AXI_SLAVE_TRANSACTION

AXI_Master_Transaction-like functionality is included, with the exception that signals driven from the slave are also in- cluded.

???????XVII. AXI_SCOREBOARD

The AXI_scoreboard additionally stores the standards produced in the AXI_Master_Transaction and AXI_Slave_Transaction.

These signals can subsequently be used to compare the expected and actual outputs.

Useful CoverageThis class contains a collection of several coverage scenarios that are used to determine the extent to which this design is protected through verification. The classes AXI Master Transaction and AXI Slave Transaction will raise this reporting.

???????XVIII. AXI_MASTER

Its the important wedge of master part, including two subblocks like, Write/read/get data &AXI master BFM. Read/write/get data:

The sequencer, driver, and monitor objects belong to the classes represented in this sub-block. The sequencer selects and inserts the desired sequence into the driver. In compliance with the protocol, it drives these signals. Monitor checks whether or not signals are changing in accordance with procedure [14].

???????XIX.  AXI MASTER BFM

It is the class that contains the bus-related functions. Bus Function Modules is an acronym for BFM. Ultimately, the DUV receives the signals that the driver is driving.The functionality of AXI_Slave and AXI_Master is comparable.

???????XX. AXI_ASSERTIONS

The list of assertions written in accordance with the signal description is included. Assert statements are used to write these.

Prior to being applied to the DUV, these claims are applied to the driver’s driving signals [15].

???????XXI. SYSTEM VERILOG

Its known as Hardware Verification Language (HVL). The main purpose is verification. The test bench (TB) is first written in the Verilog language using household tasks and purposes [11]. However, the procedure remained extremely drawn out. It circumvents this laborious process. Concepts like the notion of OOPs, randomization, and constrained randomization are all included in System Verilog, an updated version of Verilog. These tools enable us to rapidly generate any potential set of inputs, which lets us validate the design step-by-step [16].

A. RTL Design

////////write address channel (aw)

logic awvalid; /// master sends new address

???????

References

[1] Schmoldt, H. F. Benthe, and G. Haberland, “Digitoxin metabolism by rat liver microsomes,” Biochem. Pharmacol, vol. 24, no. 17, pp. 1639–1641, 1975. [2] J. K. Glenn and J. Goldman, “Task delegation to physician extenders–some comparisons,” Am. J. Public Health, vol. 66, no. 1, pp. 64–66, 1976. [3] R. P. Patil and P. V. Sangamkar, “A Review of System-On-Chip Bus Protocols,” Int. J. Adv. Res. Electr. Electron. Instrum. Eng, vol. 04, no. 01, pp. 271–281, 2015. [4] H. G. Verification, Amba, Bus, Implementing, Wrap, Using, and Verilog, Int. J. Res. Eng. Technol, vol. 05, no. 03, pp. 201–206, 2016. [5] V. I. Gavrilov, Acta Virol, vol. 19, no. 6, pp. 510–510, 1975. [6] H. G. Verification, Amba, Bus, Implementing, Wrap, Using, and Verilog, Int. J. Res. Eng. Technol, vol. 05, no. 03, pp. 201–206, 2016. [7] A. R. Babu, P. Anand, Y. Kim, and S. Jadhav, “System Verilog versus UVM-based Verification of AXI4-Lite Arbitration,” in SoutheastCon 2023. IEEE, 2023, pp. 350–357. [8] D. C. K. Kho and K. Munusamy, “Transaction-based SoC design techniques for AMBA AXI4 bus interconnects using VHDL,” in 2014 11th International Conference on Electrical Engineering/Electronics, Computer, Telecommunications and Information Technology (ECTI-CON). IEEE, 2014, pp. 1–6. [9] R. H. H. S. S. Prasad and C. S. Rani, “Development of VIP for AMBA AXI-4.0 Protocol,” Indian J. Sci. Technol, vol. 9, no. 48, 2016. [10] Y. W. Chow, R. Pietranico, and A. Mukerji, “Studies of oxygen binding energy to hemoglobin molecule,” Biochem. Biophys. Res. Commun, vol. 66, no. 4, pp. 1424–1431, 1975. [11] W. Silen, T. E. Machen, and J. G. Forte, “Acid-base balance in amphibian gastric mucosa,” Am. J. Physiol, vol. 229, no. 3, pp. 721–730, 1975. [12] B. I. Korelitz and S. C. Sommers, “Responses to drug therapy in ulcerative colitis. Evaluation by rectal biopsy and histopathological changes,” Am. J. Gastroenterol, vol. 64, no. 5, pp. 365–370, 1975. [13] E. A. Suvorova, “The approach to design of dynamically reconfigurable arbitration units in embedded systems,” Radio Ind. Russ, vol. 29, no. 3, pp. 55–67, 2019. [14] W. H. Parry, F. Martorano, and E. K. Cotton, “Management of life-threatening asthma with intravenous isoproterenol infusions,” Am. J. Dis. Child, vol. 130, no. 1, pp. 39–42, 1960. [15] R. F. Wachter, G. P. Briggs, and C. E. Pedersen, “Precipitation of phase I antigen of Coxiella burnetii by sodium sulfite,” Acta Virol, vol. 19, no. 6, pp. 500–500, 1975. [16] W. Silen, T. E. Machen, and J. G. Forte, “Acid-base balance in amphibian gastric mucosa,” Am. J. Physiol, vol. 229, no. 3, pp. 721–730, 1975.

Copyright

Copyright © 2024 Bandan Kumar Bhoi, Aditya Kumar Hota. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.