Early design stage oriented AMBA configurable uvm verification environment automatic generation and evaluation system
By automatically generating a UVM verification environment with an AMBA bus architecture, the problem of time-consuming and labor-intensive traditional verification methods in SoC chip design is solved. It enables early functional and performance collaborative verification, reduces iteration costs, and improves verification efficiency and quality.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HEFEI UNIV OF TECH
- Filing Date
- 2026-03-08
- Publication Date
- 2026-06-09
AI Technical Summary
In large-scale SoC chip design, traditional verification methods are time-consuming and labor-intensive, difficult to cover all use cases, and require repeated iterations for performance verification, increasing design cycle and risk.
This paper presents an automated generation and evaluation system for UVM verification environments based on the AMBA bus architecture. It automatically generates UVM verification environments through management scripts, integrates a performance analysis module, and performs functional and performance verification at an early stage.
It enables early functional and performance co-verification of SoC design, reducing iteration costs, shortening the R&D cycle, and improving verification efficiency and quality.
Smart Images
Figure CN122174758A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of chip development, and in particular to an automated generation and evaluation system for an AMBA configurable UVM verification environment in the early stages of design. Background Technology
[0002] In the field of IC (integrated circuit) design, traditional mainstream verification methods include waveform-based testing and manually compiled test cases. These methods require engineers to have a high degree of familiarity with the design. They involve manually building test scenarios to simulate various potential risks based on a thorough understanding of the design. However, this approach has significant limitations in large-scale designs such as SoC (System on Chip) chip design. On the one hand, as the design scale increases, manually building test scenarios and analysis models becomes extremely tedious and time-consuming, and it's difficult to cover all usage scenarios. On the other hand, traditional verification methods are greatly limited in scalability and reusability. Each new project or design often requires rewriting a large number of test cases, which is not only time-consuming but also carries significant risks. To address this issue, the Universal Verification Methodology (UVM) has emerged. With its high reliability, excellent portability, and random stimulation of non-directional testing, it has quickly become the focus of the chip verification field.
[0003] In the field of IC (Integrated Circuit) design, mainstream chip designs increasingly favor System-on-a-Chip (SoC) designs that utilize reusable IP (or IP cores, which are specific functional modules within a chip). With the development of SoC-level chips, the number and complexity of reusable IP within a chip increase. In this context, communication between modules within the SoC becomes a core component of complex SoC chips. The Advanced Microcontroller Bus Architecture (AMBA), a bus standard proposed and widely adopted by ARM, is primarily used for efficient data transfer between high-performance microprocessors and peripheral devices. Due to its superior flexibility and scalability, the AMBA bus has gained widespread application in both industry and academia. The AMBA bus specification mainly includes the AHB (Advanced High Performance Bus) system bus, the APB (Advanced Peripheral Bus) peripheral bus, and the AXI (Advanced Extensible Interface) scalable bus.
[0004] In addition, in traditional verification, performance verification is often performed after the functional verification of the IP in the SoC chip is completed. If the performance does not meet the requirements, the design needs to be modified, and then functional and performance verifications are performed again. On the one hand, repeated iterations and verifications increase the chip design cycle. On the other hand, the unknown performance status in the early stages of design increases the risk of the system.
[0005] In summary, how to use the UVM environment for functional verification in the early stages of design and simultaneously output analytical performance parameters to improve the verification efficiency and quality of on-chip systems is a pressing technical problem that needs to be solved. Summary of the Invention
[0006] The purpose of this invention is to provide an automatically generated UVM verification system for AMBA bus architecture chips. It also provides a generalized AMBA random transfer packet to simulate IP bus behavior, so that the IP function can be evaluated in the early stage of design. The verification system will provide a performance verification report to facilitate designers to evaluate chip performance, reduce iteration risk, and shorten the chip development cycle.
[0007] This invention discloses an automated generation and evaluation system for an AMBA configurable UVM verification environment for early design stages. The system includes a SoC under test, management scripts, and a UVM verification platform.
[0008] The SoC under test uses the AMBA bus as the on-chip communication bus architecture, as well as IP modules connected to the AMBA bus.
[0009] The management script includes a configuration file that provides the configuration parameters required for the generated UVM verification environment, including the AMBA version, bus width, and the number of masters and slaves.
[0010] The UVM verification platform includes design wiring documents, interface verification environment, and related verification test cases.
[0011] Furthermore, the management script includes the following steps to generate the UVM verification environment:
[0012] Step 1: According to actual needs, input the number of AHB / APB / AXI host and slave interfaces contained in the IP module, the corresponding version of the interface, and the corresponding configuration of the interface into the configuration file;
[0013] Step 2: Copy the UVM environment template to the working directory and convert the configuration parameters into script variables;
[0014] Step 3: Assign the script variables to the parameterized variables in the UVM environment;
[0015] Step 4: Replace the class name and file name with the configured IP module name, and delete redundant environment components according to interface requirements;
[0016] Step 5: Delete redundant verification test case files to complete the simplification and customization of the final environment.
[0017] Furthermore, in step 1, the interface configuration includes:
[0018] Configure the address bit width and data bit width for the AHB bus and APB bus sections;
[0019] For the AXI bus part, in addition to configuring the address bit width and data bit width, it is also necessary to configure the ID bit width and the outstanding depth for reading and writing respectively, so as to check whether the IP can reach the configured outstanding depth for reading and writing in the performance analysis section later.
[0020] Furthermore, in step 2, the script variables include the number of master and slave devices, the AMBA bus version, the verification mode parameters, and the configured address and data bit widths.
[0021] The script determines whether the environment needs a corresponding master or slave based on whether the number of master and slave machines is 0. That is, when the number of master machines is configured to be 0, the variable in the script will mark that the verification environment does not need the slave machine part.
[0022] The AMBA bus version is converted into a variable in the script, which is used to delete unnecessary versions in the subsequent environment while retaining the environment with the corresponding version;
[0023] The verification modes are divided into IP verification mode and VIP verification mode, and the environment generation depends on different configurations.
[0024] The configured address width and data width, etc., are used to modify variables in the verification environment.
[0025] Furthermore, in step 2, the ID bit width and read / write outstanding depth in the AXI bus section are also included for the AXI bus.
[0026] Furthermore, in step 4, the keyword "__NAME__" is used to globally replace the IP module name through a system function;
[0027] Nested identification is performed using protocol and version tags, and unnecessary protocol code blocks are automatically deleted based on whether the bus requires a master or slave in the configuration file.
[0028] Furthermore, in step 5, when the IP module contains a slave device of the bus protocol and the UVM environment contains a corresponding host, the read and write test verification cases sent by the host will be retained.
[0029] When an IP contains both a host and a slave device of a bus protocol, the UVM environment will also contain the corresponding host and slave device of that protocol. The UVM environment will retain all the verification test cases corresponding to that protocol.
[0030] Furthermore, in step 5, the verification test cases are configured for different protocols as follows:
[0031] The AHB bus includes basic Burst and Single read / write, back-to-back read / write, fully random scenarios, slave insertion latency and error recovery tests;
[0032] The APB bus includes basic read / write, slave insertion latency, and error recovery tests;
[0033] The AXI bus includes 4K boundary, atomic access, lockout test, out-of-order transfer, unaligned transfer, slave response delay, and anomaly test.
[0034] Furthermore, the automated generation and evaluation system for the early-stage AMBA configurable UVM verification environment includes a performance analysis module;
[0035] The performance analysis module analyzes the current read / write, transmission size, and transmission length based on the data recorded by the bus monitor; calculates the total transmission time using the start and end times; and calculates the bandwidth and transmission channel utilization based on the clock frequency and the amount of data transmitted.
[0036] For the AXI bus, each channel is also analyzed in addition to dynamically analyzing the outstanding depth detected on the current bus.
[0037] The beneficial effects achieved by this invention are:
[0038] Early design intervention: By generating configurable UVM verification environments through automated scripts, designers can conduct functional and performance verification in the early stages of IP or SoC design, changing the situation of lagging verification processes in the past.
[0039] Reduce iteration costs: Early problem detection means that modifications can be made at the stage with the lowest design costs, avoiding large-scale iterations later on, significantly shortening the chip development cycle and reducing project risks.
[0040] Highly automated and configurable: The management script can automatically generate a complete verification environment containing the correct bus version, quantity, and test cases based on a simple configuration file, which greatly reduces the repetitive work of setting up the verification environment and improves the reusability of the verification platform.
[0041] Functional and performance co-verification: While running functional test cases, the verification environment integrates a performance monitoring and analysis module, which can simultaneously output key performance indicators such as bandwidth, channel utilization, and outstanding depth, thus achieving co-verification of functional correctness and performance compliance.
[0042] Comprehensive test case coverage: The built-in test case set covers most of the standard and complex scenarios of the AMBA bus protocol, providing more reliable verification assurance for the design. Attached Figure Description
[0043] Figure 1 This is a schematic diagram of the verification system provided in an embodiment of the present invention.
[0044] Figure 2 This is a schematic diagram of the UVM structure of the present invention.
[0045] Figure 3 This describes the process of controlling the script to generate the UVM verification environment.
[0046] Figure 4 To verify the environmental performance analysis module. Detailed Implementation
[0047] The present invention will be further described below with reference to specific embodiments, and the advantages and features of the present invention will become clearer as a result. However, these embodiments are merely exemplary and do not constitute any limitation on the scope of the present invention. Those skilled in the art should understand that modifications or substitutions can be made to the details and form of the technical solutions of the present invention without departing from the spirit and scope of the present invention, but all such modifications and substitutions fall within the protection scope of the present invention.
[0048] like Figure 1 As shown, this invention provides a functional and performance verification system for AMBA bus architecture chips. The system includes the SoC under test, management scripts, and a UVM verification platform.
[0049] The SoC under test is an AMBA bus-based SoC. The AMBA bus type can include AHB (Advanced Highperformance Bus) system bus, APB (Advanced Peripheral Bus) peripheral bus and AXI (Advanced Extensible interface) scalable bus. All modules in the SoC are logic modules on the SoC.
[0050] like Figure 2 As shown in this embodiment, for the IP modules mounted on the AMBA AXI bus, AMBA AHB bus, and AMBA APB bus, the UVM verification environment can generate corresponding AMBA AXI bus drivers and bus responses, AMBA AHB bus drivers and bus responses, and AMBA APB bus drivers and bus responses.
[0051] like Figure 3 As shown, the management script generates the verification environment based on the configuration file. The management script includes the configuration file, a script file that generates the UVM verification environment based on the constraint file, and a simulation execution script. The configuration file includes the AMBA protocol version to be generated, the bus width, and the number of buses, and also generates files that connect to the VIPs and IPs within the aforementioned SOC.
[0052] Specifically, the working principle of the management script includes the following steps:
[0053] Step 1: Determine if the configuration file has been generated correctly. After successful generation, the user needs to configure the configuration file. The configurable content includes the number n of AHB / APB / AXI host and slave interfaces in the IP module, as well as the corresponding version of the interface (both AXI and APB AMBA3 and AMBA4 versions are supported).
[0054] For the AHB and APB bus sections, the address bit width and data bit width also need to be configured. For the AXI bus section, in addition to the above, the ID bit width and the outstanding depth for reading and writing also need to be configured. This is used to check whether the IP can reach the configured outstanding depth for reading and writing in the performance analysis section later.
[0055] Step 2: First, the entire UVM verification environment will be copied to the current working directory. Then, the script will read the configuration file and convert the configuration in the configuration file into script variables, including the number of master and slave machines, AMBA bus version, verification mode parameters, configured address width and data width, as well as the ID width and read / write outstanding depth in the AXI bus part.
[0056] The script determines whether a host or slave is needed in the environment based on whether the number of host or slave is 0. That is, when the number of host is configured to be 0, the variable in the script will mark that the environment does not need slave.
[0057] The AMBA bus version is converted into a variable in the script, which is used to delete unnecessary versions in the subsequent environment while retaining the environment with the corresponding version.
[0058] The authentication modes are divided into IP authentication mode and VIP authentication mode. Different configurations will affect the subsequent environment generation.
[0059] The configured address width and data width, etc., will be modified as variables in the verification environment in the next step.
[0060] Step 3: Based on the conversion script variables, modify the parameterized variables in the UVM environment, including address bit width, data bit width, ID bit width in the AXI bus, and outstanding depth parameter, to make them equal to the user-defined values. These values will be the parameterized variables in the entire verification environment. In the subsequently generated environment, these parameters will all be the parameters in the configuration file.
[0061] Step 4: If the configuration file is set to IP module verification mode, the IP module name in the configuration file will be replaced with the class name and verification file name in the UVM verification environment, making the verification environment more intuitive.
[0062] Next, depending on whether a certain bus in the configuration file needs a master or slave, delete the unnecessary parts of the common files in the environment components. For example, if the AHB master count is configured to be 2 and the slave count to be 0, then the environment needs to include content for 2 slaves, so delete the content for the master.
[0063] Step 5: Delete redundant verification test case files. When the IP module contains a host of a certain bus protocol and there are slave devices in the environment, the verification test cases for slave insertion delay and error response corresponding to that protocol will be retained, and the rest of the verification test cases will be deleted.
[0064] When an IP address contains slave devices of a certain bus protocol and the environment contains a master device, read and write tests under various conditions sent by the master device will be retained.
[0065] When an IP address contains both a host and a slave device for a certain bus protocol, the environment will also contain both hosts and slave devices for that protocol. In this case, all verification test cases for that protocol will be retained in the environment.
[0066] For the AHB bus, tests include basic Burst and Single read / write, back-to-back read / write, fully random scenarios, slave insertion latency, and error recovery.
[0067] For the APB bus, tests include basic read / write, slave insertion latency, and error response.
[0068] For the AXI bus, tests include 4K boundary, atomic access, lockout, out-of-order transfer, unaligned transfer, slave response delay, and anomaly testing.
[0069] The above environments can run in parallel for different protocols without affecting each other. These five steps complete the final simplification and customization of the environment.
[0070] The UVM verification platform is generated by management scripts and includes an AMBA bus verification environment and its test case set corresponding to the configuration parameters. The test case set is configured to generate random read and write transmission packets and send them to the IP module under test via the main VIP to simulate bus behavior. The bus monitor module monitors and records the transmission data on the AMBA bus, performs functional and performance analysis on the IP module based on the recorded data, and outputs an analysis report.
[0071] The AMBA UVM verification environment includes the MASTER VIP and SLAVE VIP of AHB3, the MASTER VIP and SLAVE VIP of APB3 and APB4, and the MASTER VIP and SALVE VIP of AXI3 and AXI4. The number of these verification component VIPs can be n, where n is an integer greater than or equal to 0.
[0072] like Figure 4 As shown, the UVM verification platform also includes a performance analysis module. This module monitors transmissions on the AMBA bus based on the AMBA bus monitor module, performing dynamic monitoring synchronously in each use case. During the monitoring process, each transmission packet is analyzed, and a performance analysis report is printed after each transmission packet is completed. The report provides information on the transmission packet's transmission status, including the read / write type, transmission type, slave response type, transmission time, bandwidth, and channel utilization.
[0073] Different AMBA buses and master / slave configurations will generate different analysis files and output different analysis results. For example, regarding the outstanding depth, the verification environment will record each transmission and dynamically analyze the current outstanding depth.
[0074] In addition, the environment contains a large number of test cases. These test cases generate specific random transmission packets, which are sent to the corresponding AMBA bus master verification component VIP. The verification component VIP then sends the packets to the DUT, thereby verifying the specific performance of the same AMBA bus under different transmission conditions and shortening the SoC verification time.
[0075] The following describes the working principle of the management script in conjunction with specific embodiments of the present invention.
[0076] A certain intelligent audio processing IP, named AUDIO03, is used in a smart speaker SoC. Its interface configuration is relatively complex, including one AXI4 master interface, one AXI4 slave interface, and two APB3 slave interfaces. All interfaces have a 32-bit bus width, an ID width of 4, and an expected Outstanding depth of 8. If the UVM verification environment is manually built using traditional methods, verification engineers would need to spend a significant amount of time constructing the environment and preparing test cases. Furthermore, the large number of combined interfaces in this IP makes manual setup prone to errors.
[0077] The specific work process is as follows:
[0078] First, run the script. A configuration file is provided. According to the actual needs, fill in the APB version as APB3, the quantity as 3 slaves, the AXI interface as AXI4, one master and one slave, and fill in 0 for the remaining bus quantity. Modify the bus width to 32 bits, the ID width to 4, and the Outstanding depth to 8.
[0079] Next, the script continues running. It reads the configuration file, converts the configuration into internal variables, and then completely copies the pre-configured UVM verification environment template to the current working directory. The template contains all the master and slave VIPs for all AMBA bus versions, the corresponding verification environment components, all test cases, and the top-level configuration file. Afterward, it modifies the parameters set in the environment through parameterized variables using the configuration file, specifically replacing the bus width with 32 bits, the ID width with 4, and the Outstanding depth with 8. After the replacement, the script performs precise cropping by recognizing special tags in the file: retaining...<START_AXI4_MASTER> and<END_AXI4_MASTER> The code between,<START_AXI4_SLAVE> and<END_AXI4_SLAVE> The code between,<START_APB3_SLAVE> and<END_APB3_SLAVE> Delete the code between them.<START_AHB3_MASTER> and<END_AHB3_MASTER> Between and<START_AHB3_SLAVE> and<END_AHB3_SLAVE> The code between,<START_AXI3_MASTER> and<END_AXI3_MASTER> The code between,<START_AXI3_SLAVE> and<END_AXI3_SLAVE> Remove the code between these sections and delete the corresponding tag lines. Then, replace the `__NAME__` entries in the environment based on the IP name, including the filename and class name. For example, `__NAME___test_base.sv` is renamed to `AUDIO03_test_base.sv`, and `class __NAME___test_base extends uvm_test;` is changed to `class AUDIO03_test_baseextends uvm_test;`. Finally, delete redundant test case files, keeping only those related to AXI4 and APB3.
[0080] Once the environment is generated, designers only need to start the corresponding test cases according to the test cases to quickly perform simulation.
[0081] The above are merely preferred embodiments of the present invention and do not constitute any limitation on the scope of protection of the present invention; all technical solutions formed by equivalent transformations or equivalent substitutions fall within the scope of protection of the present invention; the parts of the present invention not described in detail are well-known technologies to those skilled in the art.
Claims
1. An automated generation and evaluation system for a configurable UVM verification environment in the early stages of design using AMBA, characterized in that, The automated generation and evaluation system for the early-stage AMBA configurable UVM verification environment includes the SoC under test, management scripts, and a UVM verification platform. The SoC under test uses the AMBA bus as the on-chip communication bus architecture, as well as IP modules connected to the AMBA bus. The management script includes a configuration file that provides the configuration parameters required for the generated UVM verification environment, including the AMBA version, bus width, and the number of masters and slaves. The UVM verification platform includes design wiring documents, interface verification environment, and related verification test cases.
2. The automated generation and evaluation system for a configurable UVM verification environment for early-stage design using AMBA as described in claim 1, characterized in that, The management script includes the following steps to generate the UVM verification environment: Step 1: According to actual needs, input the number of AHB / APB / AXI host and slave interfaces contained in the IP module, the corresponding version of the interface, and the corresponding configuration of the interface into the configuration file; Step 2: Copy the UVM environment template to the working directory and convert the configuration parameters into script variables; Step 3: Assign the script variables to the parameterized variables in the UVM environment; Step 4: Replace the class name and file name with the configured IP module name, and delete redundant environment components according to interface requirements; Step 5: Delete redundant verification test case files to complete the simplification and customization of the final environment.
3. The automated generation and evaluation system for a configurable UVM verification environment for early-stage design using AMBA as described in claim 2, characterized in that, In step 1, the interface configuration includes: Configure the address bit width and data bit width for the AHB bus and APB bus sections; For the AXI bus part, in addition to configuring the address bit width and data bit width, it is also necessary to configure the ID bit width and the outstanding depth for reading and writing respectively, so as to check whether the IP can reach the configured outstanding depth for reading and writing in the performance analysis section later.
4. The automated generation and evaluation system for a configurable UVM verification environment for early-stage design using AMBA as described in claim 2, characterized in that, In step 2, the script variables include the number of master and slave devices, the AMBA bus version, the authentication mode parameters, and the configured address and data bit widths. The script determines whether the environment needs a corresponding master or slave based on whether the number of master and slave machines is 0. That is, when the number of master machines is configured to be 0, the variable in the script will mark that the verification environment does not need the slave machine part. The AMBA bus version is converted into a variable in the script, which is used to delete unnecessary versions in the subsequent environment while retaining the environment with the corresponding version; The verification modes are divided into IP verification mode and VIP verification mode, and the environment generation depends on different configurations. The configured address width and data width, etc., are used to modify variables in the verification environment.
5. The automated generation and evaluation system for a configurable UVM verification environment for early-stage design using AMBA as described in claim 4, characterized in that, In step 2, the AXI bus also includes the ID bit width and read / write outstanding depth in the AXI bus section.
6. The automated generation and evaluation system for a configurable UVM verification environment for early-stage design using AMBA as described in claim 2, characterized in that, In step 4, the keyword "__NAME__" is used to globally replace the IP module name through a system function; Nested identification is performed using protocol and version tags, and unnecessary protocol code blocks are automatically deleted based on whether the bus requires a master or slave in the configuration file.
7. The automated generation and evaluation system for a configurable UVM verification environment for early-stage design using AMBA as described in claim 2, characterized in that, In step 5, when the IP module contains a slave device of the bus protocol and the UVM environment contains a corresponding host, the read and write test verification cases sent by the host will be retained. When an IP contains both a host and a slave device of a bus protocol, the UVM environment will also contain the corresponding host and slave device of that protocol. The UVM environment will retain all the verification test cases corresponding to that protocol.
8. The automated generation and evaluation system for a configurable UVM verification environment for early-stage design using AMBA as described in claim 2, characterized in that, In step 5, the verification test cases are configured for different protocols as follows: The AHB bus includes basic Burst and Single read / write, back-to-back read / write, fully random scenarios, slave insertion latency and error recovery tests; The APB bus includes basic read / write, slave insertion latency, and error recovery tests; The AXI bus includes 4K boundary, atomic access, lockout test, out-of-order transfer, unaligned transfer, slave response delay, and anomaly test.
9. The automated generation and evaluation system for a configurable UVM verification environment for early-stage design using AMBA as described in claim 1, characterized in that, The automated generation and evaluation system for early-stage design-oriented AMBA configurable UVM verification environment includes a performance analysis module. The performance analysis module analyzes the current read / write, transmission size, and transmission length based on the data recorded by the bus monitor; calculates the total transmission time using the start and end times; and calculates the bandwidth and transmission channel utilization based on the clock frequency and the amount of data transmitted. For the AXI bus, each channel is also analyzed in addition to dynamically analyzing the outstanding depth detected on the current bus.