A UVM-based convolutional neural network verification system
The UVM-based convolutional neural network verification system solves the problem of low verification efficiency in existing technologies, realizes the reuse and efficient verification of hardware accelerator verification platforms with different structural layers, shortens the verification cycle, and improves verification efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-05-18
- Publication Date
- 2026-03-10
AI Technical Summary
The lack of a dedicated verification solution for convolutional neural network functions in existing technologies leads to low chip verification efficiency and the inability to reuse traditional targeted testing platforms, which increases chip development time and costs.
A UVM-based convolutional neural network verification system is adopted, which includes the design under test, interface module, test case module and verification environment. By quantifying the verification progress, the completeness of verification of each functional module is ensured, and the hardware accelerator verification platform for convolutional neural network models with different structural layers is reused.
It shortens the verification cycle, improves verification efficiency, reduces redundant development work, supports convolutional neural network models with multiple configurations, adapts to mainstream convolutional neural network models, and enhances the flexibility and coverage of the verification system.
Smart Images
Figure CN114912358B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of integrated circuit design, and particularly relates to a convolutional neural network verification system based on UVM. BACKGROUND
[0002] With the continuous development of integrated circuits, the design scale of system on chip (SOC) is continuously expanding, and the number of IP (Intellectual Property) modules integrated in the SOC chip is also increasing, so the requirement for chip verification in the chip development link is higher and higher, and the building of the verification platform is more complex. In most integrated circuit design companies today, the manpower and time required for chip verification accounts for as high as 70% of the entire chip development process. The traditional directional test platform is based on the verilog language, which cannot cover all the functions to be tested and cannot be reused between different projects, which greatly reduces the verification efficiency and increases the time and cost of chip development.
[0003] Convolutional neural network is a kind of feedforward neural network containing convolution calculation and having a deep structure, and is one of the representative algorithms of deep learning, which has achieved the best effect in the field of computer vision, classification, etc. In modern artificial intelligence systems, convolutional neural network has been widely used, which brings challenges to data throughput and energy efficiency of underlying hardware. Through reconfigurable convolutional neural network architecture, in-chip and out-of-chip data flow processing and optimization, the whole system can effectively improve the efficiency. In the current mainstream convolutional neural network hardware design method, ASIC (Application Specific Integrated Circuit) has attracted more and more attention. ASIC is a chip customized for specific requirements, which has advantages in size, power consumption and reliability, and has strong versatility and can be used in more Internet of Things terminal devices, but there is no verification solution specifically for convolutional neural network function in the prior art, which greatly affects the verification efficiency. SUMMARY
[0004] The purpose of the present application is to provide a convolutional neural network verification system based on UVM, which quantifies the verification progress according to the mechanism in UVM (Universal Verification Methodology), and ensures the completeness of the verification of each function module. Only a small amount of modification is needed to reuse the hardware accelerator verification platform of convolutional neural network models with different structure layers, thereby shortening the verification period and improving the verification efficiency.
[0005] The purpose of the present application is realized by the following technical solutions:
[0006] A convolutional neural network verification system based on UVM, the system comprises a design under test (DUT), an interface module for the design under test, a test case module base_test, a verification environment, wherein:
[0007] The design under test (DUT) uses a hardware accelerator based on a convolutional neural network under test;
[0008] The interface module for the design under test specifically comprises a host interface, a slave interface, a control interface, a convolution kernel interface and a register interface, the interface module contains definitions of all interface signals required by the design under test, and is used for data communication between the design under test and other modules;
[0009] The test case module base_test is used for creating different verification environments and generating different test excitations;
[0010] Each test case instantiated in the test case module inherits from base_test class According to different configurations of the verification environment, different sequences sequence are configured to generate transactions transaction conforming to the protocol specification, so as to form different test cases;
[0011] The verification environment is built according to the verification requirements of the convolutional neural network hardware accelerator under test, and is used for verifying the data flow control functions of the convolution, activation, pooling, fully connected functional layer, base address and data offset in the design under test.
[0012] As can be seen from the above technical solutions of the present application, the system according to the mechanism in UVM quantifies the verification progress and ensures the verification completeness of each functional module, and only a small amount of modification is needed to reuse the hardware accelerator verification platform of the convolutional neural network model with different structural layers, thereby shortening the verification period and improving the verification efficiency. BRIEF DESCRIPTION OF DRAWINGS
[0013] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.
[0014] Figure 1 The structure diagram of the convolutional neural network verification system based on UVM provided by the embodiments of the present application;
[0015] Figure 2This is a schematic diagram of the register model in an embodiment of the present invention. Detailed Implementation
[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments, and do not constitute a limitation of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of the present invention.
[0017] like Figure 1 The diagram shown is a schematic representation of the structure of a UVM-based convolutional neural network verification system provided in an embodiment of the present invention. The system includes a design under test (DUT), an interface module for the DUT, a test case module (base_test), and a verification environment, wherein:
[0018] The Design Under Test (DUT) uses a hardware accelerator based on the convolutional neural network under test;
[0019] The interface modules for the design under test (DUT) specifically include a host interface, a slave interface, a control interface, a convolution kernel interface, and a register interface. Each interface module contains the definitions of all required DUT interface signals for data communication between the DUT and other modules. In the implementation, each interface can be directly used when the DUT is instantiated in `top_tb`, passed to components at various levels via the `config_db` mechanism, and its contents are encapsulated in the driver using a virtual interface.
[0020] The test case module base_test is used to create different verification environments and generate different test stimuli.
[0021] Each test case instantiated in the test case module inherits from [the module name]. base_test class Based on the different functional points being tested, configure the corresponding verification environment (environment, env) and configure different sequences to generate transactions that conform to the protocol specifications, thereby forming different test cases;
[0022] The verification environment is built according to the verification requirements of the convolutional neural network hardware accelerator under test, and is used to verify the data flow control functions of the convolution, activation, pooling, fully connected functional layers, base address and data offset in the design under test.
[0023] In the specific implementation, the verification environment includes a host agent, a slave agent, a control agent, a convolution kernel agent, a register agent, a reference model, and a scoreboard component; where, when there are multiple layers, it is necessary to instantiate the corresponding data input / output and the number of channels of the convolution kernel;
[0024] The host agent is used to send random signed data and simulate image data to the design under test (DUT). Specifically, the host driver in the host agent sends an instantiated transaction according to the uvm_send macro in the sequence, obtains the register configuration information using seq_item_port.get_next_item to generate a corresponding amount of data, and transmits the data to the DUT through the virtual interface. At the same time, the host monitor transmits the detected transaction to the reference model through uvm_analysis_port. Before the DUT receives the data, it needs to ensure that the protocol handshake is successful. In order to speed up the simulation and optimize the function of the verification component, after the data request signal and response signal handshake is successful, a random number is generated and sent directly to the virtual interface.
[0025] The slave agent is used to receive the calculation result data of the design under test and transmit the calculation result data to the scoring board component for address and data comparison.
[0026] The control agent is used to verify the hardware-triggered convolution method. It sets the signal that triggers convolution in the design under test to be valid through a virtual interface, thereby verifying the functional points in the design.
[0027] The convolution kernel proxy is used to configure the weight information of the convolution kernel, with the purpose of generating random weight data for the calculation of the convolutional layer;
[0028] The register proxy is used to configure the register. When the register proxy is connected to the register, it uses a front-door access method. Most of the test cases studied in this embodiment are triggered by configuring the values of the register model to trigger convolution.
[0029] Each agent contains a driver, a monitor, and a sequence generator, among which:
[0030] The driver is used to request a test transaction object from the sequence generator and drive the requested test transaction object to the port of the design under test. In specific implementation, after completing the conversion from transaction level to port level information that the design under test can accept, the design under test is driven through the interface according to the bus interface protocol of the design under test (APB in this embodiment, but other AMBA series protocols can also be supported).
[0031] The monitor is used to collect data from the port of the design under test and convert the collected data into transactions to be transmitted to the subsequent reference model and scoreboard components for processing;
[0032] The sequence generator is used to initiate a sequence and then send the test transaction object to the driver. Specifically, the sequence generator is derived from `uvm_sequencer`, registered in the factory using the `uvm_component_utils` macro, and specifies the type of transaction to be generated during definition. The test transaction object is a class defined in the UVM verification platform. All transactions are derived from `uvm_sequence_item`. The transaction class packages all the data to be used for testing. In this embodiment, the transaction includes information such as the input frame width (pixel size), input frame length (pixel size), output frame size (pixel size), convolution kernel size, number of convolution kernels per column of the slider, stride, operation address, and operation type. Furthermore, this data supports the AXI4 protocol.
[0033] In practice, although the sequence generator is not a basic component of the verification system, the stimuli required for verification consist of transactions and are generated by sequences.
[0034] In addition, the execution of each test case instantiated in the test case module is initiated by a request signal from the design under test, followed by an acknowledgment signal from the host driver. Different random numbers are generated by instantiating the read_channel_transaction of each layer and passed to the design under test and the reference model respectively through the read data channel interface.
[0035] The corresponding channel data is obtained using uvm_blocking_get_port in Transaction Level Modeling (TLM) communication, triggering the signal to start data convolution, activation, and pooling functions, and outputting it to the scoring board component for comparison.
[0036] The scoring board component compares data from two sources: the reference model and the monitor in the slave agent. If the data comparison is successful, it prints "PASS"; if the comparison fails, it reports "FAIL".
[0037] The scoring board component stores the results of each data comparison between the design under test and the reference model, which is used to debug the functionality of the module under test.
[0038] In the specific implementation, the data to be compared by the scoreboard component is obtained through uvm_blocking_get_port; in the main_phase, two processes are created by fork. One process processes the data from the reference model and puts the data into expect_queue when it is received; the other process processes the data from the monitor in the slave agent, which is the output data of the design under test and is temporarily stored in actual_queue.
[0039] Data from the two queues is stored in the corresponding log files according to the number of channels. At the same time, the data stored in actual_queue and expected_queue are compared. If the data is consistent, they will be removed from the queue until the simulation verification is completed.
[0040] Next, check if the queue is empty and print the corresponding simulation report.
[0041] The aforementioned reference model performs the same functions as the design under test, including writing convolutional kernels and channel data (8 / 16-bit random per pixel), starting convolution calculation based on the number of kernel columns, base address and offset address, non-linear activation, max-min and mean pooling, fully connected layers, and bank switching. Each individual functional layer is written as a virtual task, separating parameter passing and retrieval for easier encapsulation and reuse. Each processed data entry is transmitted to the scoring board component according to the bus width. In the specific implementation, the number of convolutional kernels and output layers remains consistent. Data is retrieved from the driver and stored in a two-dimensional array using nested for loops. Based on the register values, the convolutional kernel size and data type are determined, and corresponding multiplication and addition operations are performed. The calculated data results are truncated to the bit width and then subjected to non-linear mapping and pooling mode selection. Image compression is performed to extract features. When calculating multiple consecutive images, a ping-pong buffer register is configured to save read / write time.
[0042] In the specific implementation, the above register proxy establishes three uvm_reg_blocks, namely data channels bank0, bank1, and convolution kernel and non-ping-pong configuration register, during the configuration of the registers. It generates test transactions in the manner of front door and accesses the design under test with the help of the proxy, which consumes simulation time.
[0043] Simultaneously, multiple sequences are generated, storing operation addresses and operation types in variables. After being converted by a converter, these variables are transmitted to the sequence generator, and finally, the driver completes the front door access operation using the Advanced Peripheral Bus (APB) interface timing.
[0044] In this example, both sending read commands and retrieving read operation return values can be accomplished using the register model. Here, the register model is a set of high-level abstract classes used to model the address-mapped registers and memories in the Design Under Test (DUT). It reflects various characteristics of the registers in the DUT, generates stimuli to the DUT, and performs register function checks. Furthermore, the register model can be used to read register values using either front-door or back-door access in any time-consuming phase, and also in some time-efficient phases using back-door access. This embodiment redefines the register interface between the verification system and the DUT, enabling verification personnel to better organize and configure registers, simplifying the process and reducing workload.
[0045] In a register model, front-door access, whether a read or write operation, generates a variable `uvm_reg_bus_op` from the sequence. This variable stores the operation type and address. For write operations, the written data and other information are converted by a converter before being passed to the bus sequence generator, and finally to the design under test. Figure 2 This is a schematic diagram of the register model according to an embodiment of the present invention, illustrating the write operation mode flow of the register model's front-door access. In addition to completing the read and write operations of the front-door access, it also updates the mirror value and expected value of the register through automatic prediction, tracking real-time changes in register values in the design under test. Figure 2 Includes:
[0046] uvm_reg_item is derived from uvm_sequence_item and is a built-in transaction in UVM. It corresponds to the object of the write operation and is used to update register values, image values, and expected values.
[0047] The uvm_reg_map stores the address of the register, translates it into an accessible physical address, initiates a write sequence, and returns the result of the write.
[0048] The `uvm_reg_adapter` implements type casting functionality. Through the `bus2reg` and `reg2bus` methods of the adapter, it can convert between `uvm_reg_item` and the target transaction. `reg2bus` converts the `uvm_reg_bus_op` type variable emitted by the register model via a sequence into a form that the bus sequence generator can receive. `bus2reg`, when an operation is detected on the bus, converts the collected transaction into a `uvm_reg_bus_op` type variable, allowing the register model to update the corresponding register values promptly.
[0049] The uvm_driver drives bus transactions to the design under test;
[0050] uvm_monitor monitors bus transactions;
[0051] The uvm_reg_predictor instructs the uvm_reg_adapter to convert bus transactions into corresponding register operations. The register model can also initiate read operations and then return the value. Due to the special nature of the bus, when the bus driver initiates a read request, it can simultaneously obtain the value to be read. If it stores this value in the bus transaction obtained by the bus sequence generator, then the value to be read already exists in the bus transaction. This value is passed through the bus2reg function in the converter, and finally, the register model obtains this value.
[0052] In addition, during the functional verification process using the aforementioned verification environment, if the coverage reaches 100%, it is determined that the requirements are met; if the coverage does not reach 100%, it is determined that the requirements are not met.
[0053] If the coverage does not meet the requirements, modify the parameter settings and verify again.
[0054] It is worth noting that the contents not described in detail in the embodiments of the present invention belong to the prior art known to those skilled in the art.
[0055] In summary, the system described in the embodiments of the present invention has the following advantages:
[0056] 1. This system uses the most mainstream UVM verification methodology to build the verification environment, which can be reused reasonably. This ensures the correctness of the code and avoids the repeated development of verification components. Only a few code modifications are needed to deploy it in other verification processes.
[0057] 2. This system is highly scalable, supports convolutional neural networks with various configurations, supports up to 64-bit input / output channels, and the maximum side length R of the input feature map image is 256 pixels. It supports convolutional kernel sizes of 1*1 / 2*2 / 3*3 / 5*5 / 7*7 / 11*11, stride S = 1 / 2 / 3 / 4 / 5, and int4 / int8 / int16 data types for calculation. It is compatible with current mainstream convolutional neural network models.
[0058] 3. This system has a built-in register proxy, supports configurable registers, supports front-door and back-door access, and the interface supports AMBA series protocols (AXI / AHB / APB) and different bus widths;
[0059] 4. This system can flexibly construct various required test cases, add constrained random stimuli, accelerate coverage convergence, and has high test case verification efficiency, which greatly shortens the IC design development cycle.
[0060] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims. The information disclosed in the background section is intended only to enhance the understanding of the overall background technology of the present invention and should not be construed as an admission or implication in any way that such information constitutes prior art known to those skilled in the art.
Claims
1. A UVM-based convolutional neural network verification system, characterized in that, The system comprises a design under test (DUT), an interface module for the design under test, a test case module base_test, and a verification environment, wherein: The design under test (DUT) uses a hardware accelerator based on a convolutional neural network under test; The interface module for the design under test specifically comprises a host interface, a slave interface, a control interface, a convolution kernel interface, and a register interface, and the interface module contains definitions of all interface signals needed by the design under test, for data communication between the design under test and other modules; The test case module base_test is used to create different verification environments and generate different test stimuli; Each test case instantiated in the test case module inherits from the base_test class, configures a corresponding verification environment according to different function points, and configures different sequences to generate transactions conforming to protocol specifications, thereby forming different test cases; The verification environment is built according to the verification requirements of the convolutional neural network hardware accelerator under test, and is used to verify the data flow control functions of the convolution, activation, pooling, fully connected functional layers, base addresses, and data offsets in the design under test; The verification environment comprises a host agent, a slave agent, a control agent, a convolution kernel agent, a register agent, a reference model, and a scoreboard component; when there are multiple image layers, the corresponding data input and output and the number of convolution kernel channels need to be instantiated; The host agent is used to send random signed number data to simulate image data transmission to the design under test; The slave agent is used to receive the operation result data of the design under test and transmit the operation result data to the scoreboard component for address and data comparison; The control agent is used to verify the way of hardware triggered convolution, and sets the signal of the design under test triggering convolution to be valid through a virtual interface, so as to verify the function points in the design; The convolution kernel agent is used to configure the weight information of the convolution kernel, and the purpose is to generate random weight data for convolution layer calculation; The register agent is used to configure the register, and the register agent uses the front door access method to connect with the register when connected, wherein the test case is triggered by configuring the value of the register; Each agent contains a driver, a monitor, and a sequence generator, wherein: The driver is used to apply a test transaction object to the sequence generator and drive the applied test transaction object to the port of the design under test; The monitor is used to collect data on the port of the design under test and convert the collected data into transactions to be transmitted to the subsequent reference model and scoreboard component for processing; The sequence generator is used to start a sequence and then send a test transaction object to the driver; The data to be compared by the scoreboard component is derived from the reference model and the monitor in the slave agent, both of which are obtained through uvm_blocking_get_port. Two processes are established by fork in main_phase, one process handles data from the reference model, and puts the data into expect_queue when receiving the data; the other process handles data from the monitor in the slave agent, which is the output data of the design under test, and temporarily stores in actual_queue; The data in the two queues are stored in the corresponding log file according to the number of channels, and the data stored in actual_queue and expect_queue are compared, if the data is consistent, they are cleared from the queue until the simulation verification is completed; Then judge whether the queue is empty, and print the corresponding simulation report.
2. The UVM-based convolutional neural network verification system according to claim 1, wherein the running of each test case instantiated in the test case module is requested by the design under test, and a confirmation signal is then sent from the host driver, and a read_channel_transaction of each layer is instantiated to generate different random numbers, which are respectively transmitted to the design under test and the reference model by the read data channel interface; The uvm_blocking_get_port in transaction-level modeling (TLM) communication is used to obtain the data of the corresponding channel, trigger signals to start data convolution, activation, and pooling functions, and output to the scoreboard component for comparison; The data to be compared in the scoreboard component are from the reference model and the monitor in the slave agent, and if the data comparison is successful, PASS is printed; if the comparison fails, FAIL is reported; The results of comparing each piece of data of the design under test and the reference model in the scoreboard component are saved, which are used to debug the function of the test module.
3. The UVM-based convolutional neural network verification system according to claim 1, wherein the reference model is used to complete the same function as the design under test, including implementing convolution kernel and channel data writing, starting convolution calculation according to the number of convolution kernel columns, base address and offset address, nonlinear activation, maximum and minimum pooling, full connection, and bank switching functions, and writing each individual function layer as a virtual task, separating the transmission and acquisition of parameters to facilitate encapsulation and reuse, and each piece of processed data is transmitted to the scoreboard component according to the bus bit width.
4. The UVM-based convolutional neural network verification system according to claim 1, wherein the register agent establishes three uvm_reg_block, namely data channel bank0, bank1, and convolution kernel and non-ping-pong configuration registers, in the process of configuring the registers, generates test transactions according to the front door mode and accesses the design under test by means of the agent, and consumes simulation time; Meanwhile, multiple sequences are started to generate variables storing operation addresses and operation types, which are converted by a converter and then transmitted to the sequence generator, and finally the front door access operation is completed by the driver with advanced peripheral bus (APB) interface timing. 5.The UVM-based CNN verification system according to claim 1, wherein, in the functional verification process using the verification environment, if the coverage rate reaches 100%, it is determined that the requirement is met; if the coverage rate does not reach 100%, it is determined that the requirement is not met; and if the coverage rate does not meet the requirement, the parameter setting is modified and the verification is performed again.