APB bus and APB bus slave device verification method and device
By encapsulating the design under test in APB bus verification and using the UVM verification platform for signal conversion and comparison verification, the problems of incomplete functional point coverage and high VIP cost in commercial verification are solved, thereby improving verification efficiency and code reusability.
Patent Information
- Application Number
- CN202511665201.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-13
- Publication Date
- 2026-02-24
AI Technical Summary
Existing technologies suffer from incomplete coverage of APB bus verification functions and high costs associated with commercial verification VIPs.
By identifying the design under test and encapsulating it in a pre-defined top-level design file, APB bus input signals are collected and converted into transaction data, which are then sent to the reference model to output the expected result data. The target module is identified from multiple slave device modules, and its output signals are collected for comparison and verification. The UVM verification platform is used to manage functional coverage and code coverage.
It achieves more comprehensive coverage of APB bus verification functions, reduces the cost of commercial verification VIPs, and improves the efficiency of chip verification and the reusability of developed code.
Smart Images
Figure CN121560656A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of chip verification technology, and in particular to an APB bus and an APB bus slave device verification method and apparatus. Background Technology
[0002] Universal Verification Methodology (UVM) is widely used as a mainstream verification method in chip verification. UVM provides library functions developed using the SystemVerilog language, which features object-oriented characteristics such as encapsulation, inheritance, and polymorphism. Chip verification engineers can use these UVM library functions to build verification platforms. Advanced Peripheral Bus (APB) is a widely used high-level peripheral bus; the APB interface is used to access low-speed peripheral devices, and verification of APB and its peripheral devices is essential in the verification field. UVM has many VIPs (Verification IPs), which can be connected to the corresponding IP module interfaces for rapid verification of the IP modules. The use of VIPs greatly improves the efficiency of setting up the verification environment and significantly saves chip verification time.
[0003] However, each digital chip design IP module requires a separate verification environment. In the top-level test_top.v, the verification platform is connected to the chip design module through signal instantiation, and then a script file is provided to execute simulation commands. Currently, there are dedicated apb VIPs for simulating APB in related technologies, but considering cost and practicality, it is not easy to flexibly reuse its own verification environment. Furthermore, it is difficult to cover all functional points by writing test stimuli in Verilog, which urgently needs to be solved. Summary of the Invention
[0004] This application provides a verification method and apparatus for an APB bus and an APB bus slave device to solve the problems of incomplete functional point coverage and high cost of commercial verification VIP in APB bus verification.
[0005] The first aspect of this application provides a method for verifying an APB bus and an APB bus slave device, including the following steps: Identify the design to be tested and encapsulate it in a preset top-level design file; The APB bus input signal of the design under test is acquired, the APB bus input signal is converted into first transaction data, and the first transaction data is sent to a preset reference model. The expected result data is then output through the preset reference model. The target slave device module is determined from the multiple slave device modules of the design under test, and the output signal of the target slave device module is collected. The output signal is converted into second transaction data, and the expected result data and the second transaction data are compared and verified to obtain the verification result of the target slave device module.
[0006] Optionally, determining the target slave device module from the plurality of slave device modules of the design under test includes: The preset top-level design file and the top-level verification environment are linked by instantiation; The target slave device module is determined from the APB bus and the slave device IP modules of the APB bus based on the configuration file; A UVM verification platform is built from the device module according to the stated objectives.
[0007] Optionally, the UVM verification platform includes: environmental components and a top-level verification environment, wherein, The environment component integrates the input agent, the output agent, the preset reference model, and the scoreboard; The environment component is instantiated and encapsulated in the top layer of the verification environment.
[0008] Optionally, before acquiring the APB bus input signal of the design under test, the method further includes: The sequencer generates stimulus data, which is then sent to the design under test and a preset reference model via a driver.
[0009] Optionally, when comparing and verifying the expected result data and the second transaction data to obtain the verification result of the target slave device module, the method further includes: Collect functional coverage and code coverage during the verification process. When the functional coverage and code coverage reach the preset requirements, it is determined that the verification of the target device module is completed.
[0010] Optionally, after collecting functional coverage and code coverage during the verification process, the following steps are also included: If the functional coverage and code coverage do not meet the preset requirements, random stimuli and / or targeted stimuli are added, and the step of sending the stimulus data to the design under test and the preset reference model via the driver is re-executed until the code coverage and functional coverage meet the preset requirements.
[0011] A second aspect of this application provides an APB bus and an APB bus slave device verification apparatus, comprising: A determination module is used to determine the design under test and encapsulate the design under test in a preset top-level design file; The output module is used to acquire the APB bus input signal of the design under test, convert the APB bus input signal into first transaction data, send the first transaction data to a preset reference model, and output the expected result data through the preset reference model. The verification module is used to determine the target slave device module from multiple slave device modules of the design under test, collect the output signal of the target slave device module, convert the output signal into second transaction data, and compare and verify the expected result data and the second transaction data to obtain the verification result of the target slave device module.
[0012] Optionally, the verification module is specifically used for: The preset top-level design file and the top-level verification environment are linked by instantiation; The target slave device module is determined from the APB bus and the slave device IP modules of the APB bus based on the configuration file; A UVM verification platform is built from the device module according to the stated objectives.
[0013] Optionally, the UVM verification platform includes: environmental components and a top-level verification environment, wherein, The environment component integrates the input agent, the output agent, the preset reference model, and the scoreboard; The environment component is instantiated and encapsulated in the top layer of the verification environment.
[0014] Optionally, before acquiring the APB bus input signal of the design under test, the output module is further configured to: The sequencer generates stimulus data, which is then sent to the design under test and a preset reference model via a driver.
[0015] Optionally, when comparing and verifying the expected result data and the second transaction data to obtain the verification result of the target slave device module, the verification module is further configured to: Collect functional coverage and code coverage during the verification process. When the functional coverage and code coverage reach the preset requirements, it is determined that the verification of the target device module is completed.
[0016] Optionally, after collecting functional coverage and code coverage during the verification process, the verification module is further configured to: If the functional coverage and code coverage do not meet the preset requirements, random stimuli and / or targeted stimuli are added, and the step of sending the stimulus data to the design under test and the preset reference model via the driver is re-executed until the code coverage and functional coverage meet the preset requirements.
[0017] A third aspect of this application provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being configured to perform the APB bus and APB bus slave device verification method as described in the above embodiments.
[0018] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the verification method for the APB bus and the APB bus slave device as described in the above embodiments.
[0019] A fifth aspect of this application provides a computer program product storing a computer program that, when executed by a processor, implements the verification method for the APB bus and APB bus slave device as described in the above embodiments.
[0020] Therefore, this application embodiment identifies the design under test (DUT) and encapsulates it in a preset top-level design file; it acquires the APB bus input signals of the DUT, converts them into first transaction data, and sends the first transaction data to a preset reference model, outputting expected result data through the preset reference model; it identifies a target slave module from multiple slave modules of the DUT, acquires the output signals of the target slave module, converts the output signals into second transaction data, and compares and verifies the expected result data and the second transaction data to obtain the verification result of the target slave module. This solves the problems of incomplete functional point coverage and high VIP costs in commercial verification of APB bus.
[0021] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description
[0022] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart illustrating an APB bus and an APB bus slave device verification method according to an embodiment of this application. Figure 2 This is a schematic diagram of a UVM-based verification platform for an APB bus and its slave device, according to an embodiment of this application, which provides a verification method for an APB bus and an APB bus slave device. Figure 3This is a schematic diagram of an APB bus and an APB bus slave device verification apparatus provided according to an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Detailed Implementation
[0023] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.
[0024] Before introducing the APB bus and the verification method of the APB bus slave device according to the embodiments of this application, let me briefly introduce the technical problem solved by the embodiments of this application.
[0025] Specifically, Verilog test stimuli are difficult to cover all functionalities, and the related verification IP structures are complex, requiring study of relevant documentation before using the VIP. The UVM-based APB bus and its slave devices refer to various functional modules under the bus interface protocol implemented within the chip. In complex chip designs, it is necessary to first verify each small functional module successfully, and then integrate the functional sub-modules into a larger module through signal instantiation for verification as a whole, gradually verifying the entire module. Compared to simpler Verilog verification, this method allows selection of APB bus and its slave device IP modules for verification via configuration files, supports optional APB bus and slave device IP module verification, and allows for the addition of more customized APB bus and slave device modules for verification. This increases the reusability of the code and verification platform, and provides more complete verification functions and test cases. This UVM-based APB bus and its slave device verification platform construction method saves costs and shortens verification development time.
[0026] The APB (Advanced Peripheral Bus) of this invention is an advanced peripheral bus, belonging to the AMBA (Advanced Microcontroller Bus Architecture) bus. APB is a low-cost interface protocol. The APB protocol does not support pipelined design; each transmission requires at least two clock cycles. The APB bus can typically connect to external slave devices, such as UART, SPI, and I2C. UART refers to Universal Asymmetric Receiver Transmitter, a universal serial bus with two data lines, enabling full-duplex transmission and reception. SPI (Serial Peripheral Interface) is a high-speed, full-duplex, synchronous communication bus. I2C (Inter-Integrated Circuit) is a widely used serial bus interface, requiring only two lines: a serial data line (SDA) and a serial clock line (SCL) for data transmission.
[0027] The following describes, with reference to the accompanying drawings, a verification method and apparatus for the APB bus and APB bus slave devices according to embodiments of this application. Addressing the issues of incomplete function point coverage and high commercial verification VIP costs in APB bus verification mentioned in the background art, this application provides a verification method for the APB bus and APB bus slave devices. In this method, embodiments of this application determine the design under test (DUT) and encapsulate it in a preset top-level design file; acquire the APB bus input signals of the DUT, convert the APB bus input signals into first transaction data, and send the first transaction data to a preset reference model, outputting expected result data through the preset reference model; determine a target slave device module from multiple slave device modules of the DUT, acquire the output signals of the target slave device module, convert the output signals into second transaction data, and compare and verify the expected result data and the second transaction data to obtain the verification result of the target slave device module. This solves the problems of incomplete function point coverage and high commercial verification VIP costs in APB bus verification.
[0028] Specifically, Figure 1 This is a flowchart illustrating an APB bus and an APB bus slave device verification method provided in an embodiment of this application.
[0029] like Figure 1 As shown, the verification method for the APB bus and its slave devices includes the following steps: In step S101, the design to be tested is determined and encapsulated in a preset top-level design file. Among them, the preset top-level design file is the highest-level encapsulation of the design under test, serving as the benchmark object for the verification environment connection and ensuring the consistency between the verification target and the design implementation.
[0030] Specifically, the DUT is the design under test. The purpose of this application embodiment is to verify whether the function of the design under test meets the target requirements. The entire DUT of the APB bus and its slave devices is encapsulated into the dut_top file (the preset top-level design file).
[0031] In step S102, the APB bus input signal of the design under test is acquired, the APB bus input signal is converted into first transaction data, and the first transaction data is sent to the preset reference model. The expected result data is output through the preset reference model.
[0032] The first transaction data is transaction-level abstract data obtained by collecting and encapsulating the APB bus input signals through the monitor of the input agent in the verification platform. This data contains complete transmission information of the APB protocol layer (such as address, read / write type, data, control signals, etc.) and is used to generate the expected results in the preset reference model.
[0033] Specifically, for different interface signal timings, an `in_agent` component (input agent) is defined. `in_agent` contains a `driver` component and a `monitor` component (first monitor). The first monitor within the input agent continuously monitors changes in physical signals on the APB bus interface of the design under test, including key information such as address, read / write control, and data. The monitor parses and encapsulates the captured signal-level timing behavior according to the APB protocol specification, converting it into transaction-level data objects with clear semantics, i.e., first transaction data. The first transaction data is sent to the preset reference model through the transaction-level communication interface. After receiving this transaction data, the preset reference model performs calculations and simulations based on the described bus operation type and parameters, using internally pre-built functional algorithms or behavioral models, ultimately generating the expected result data corresponding to the operation, which is then output to the next-level verification component for comparison and analysis.
[0034] Optionally, in some embodiments, before acquiring the APB bus input signal of the design under test, the method further includes: generating stimulus data based on a sequencer, and sending the stimulus data to the design under test and a preset reference model via a driver.
[0035] The stimulus data is a set of input data used to test the correctness of the design under test. The preset reference model (reference_mode) is a reference model component in UVM, used to generate reference data and send it to the scoreboard.
[0036] Understandably, the UVM verification platform sends the generated stimulus data to the DUT and reference_mode through the sequencer and driver, so that the reference_mode and the design under test receive the same input stimulus synchronously. This establishes a consistency benchmark for the comparison of subsequent output results and ensures that the reference model and the design under test run in the same stimulus environment during the verification process, laying the foundation for the accuracy of functional verification.
[0037] In step S103, the target slave device module is determined from the multiple slave device modules of the design under test, and the output signal of the target slave device module is collected. The output signal is converted into second transaction data, and the expected result data and the second transaction data are compared and verified to obtain the verification result of the target slave device module.
[0038] Optionally, in some embodiments, determining the target slave device module from multiple slave device modules of the design under test includes: instantiating a preset top-level design file and a top-level verification environment; determining the target slave device module from the APB bus and the slave device IP modules of the APB bus based on a configuration file; and building a UVM verification platform based on the target slave device module.
[0039] Specifically, `dut_top` is instantiated and connected to the verification environment. `test_top` is the top layer of the verification environment. The configuration file then selects the APB bus to be verified and its slave device's IP module (target slave device module), such as the `apb_uart` module. The UVM platform is then built based on the selected target slave device module. For different interface signal timings, an `out_agent` component (output agent) is defined. `out_agent` generally only needs to contain a `monitor` component (second monitor). This `out_agent` component does not need to transmit data to the DUT but only needs to monitor the DUT's output. The second monitor in the output agent collects the functional output signals of the target slave device module in real time, parses and encapsulates them according to the device-specific protocol specification into standardized transaction objects, i.e., second transaction data. This transaction data and the expected result data are synchronously transmitted to the scoreboard. The actual data is compared with the reference data to obtain the verification result. The RTL code of the tested object then outputs data signals to the scoreboard, which compares the two sets of data streams to determine if they are correct. By using time alignment and content comparison mechanisms, each of the two sets of data items is verified, and finally a verification result is generated to determine the functional correctness of the target slave device module.
[0040] Optionally, in some embodiments, the UVM verification platform includes: an environment component and a verification environment top layer, wherein the environment component integrates an input agent, an output agent, a preset reference model, and a scoreboard; the environment component is instantiated and encapsulated in the verification environment top layer.
[0041] Understandably, the in_agent, out_agent, reference model, and scoreboard components are integrated into the env environment (environment component), and then env is encapsulated in test_top (the top-level verification environment). When the SystemVerilog language verifies the DUT, it communicates data via mailbox, while the information exchange between UVM (Universal VerificationMethodology) components is conducted through TLM (Transaction Level Modeling).
[0042] Optionally, in some embodiments, when comparing and verifying the expected result data and the second transaction data to obtain the verification result of the target slave device module, the method further includes: collecting the functional coverage and code coverage during the verification process, and determining that the verification of the target slave device module is completed when the functional coverage and code coverage reach the preset requirements.
[0043] Optionally, in some embodiments, after collecting the functional coverage and code coverage during the verification process, the method further includes: if the functional coverage and code coverage do not meet the preset requirements, adding random stimuli and / or targeted stimuli, and re-executing the step of sending the stimuli data to the design under test and the preset reference model via the driver, until the code coverage and functional coverage meet the preset requirements.
[0044] Understandably, the functional and code coverage results of test cases are collected through methods such as comparing scoreboard data and uvm_info print information, and it is determined whether the coverage meets the preset requirements. Generally, code coverage is close to the target value, but functional coverage requires that the verification functions are complete, ensuring that all necessary functions are verified, and the functional coverage must reach 100%. For example, code coverage requires line coverage and state machine coverage to reach 100%, ensuring that all state transitions of the UART controller from idle, start, data transmission to stop are tested; functional coverage requires full coverage, that is, full address space register read and write (0x00-0xFF), boundary data testing (32'h00000000 / FFFFFFFF), transmit and receive tests under specific scenarios with baud rates of 115200 / 9600, and FIFO overflow exception triggering. If the functional coverage does not meet the requirements, add random or targeted stimuli and resend them to the reference_model and DUT. Then compare the data in the scoreboard component and collect coverage again until the code coverage and functional coverage meet the verification requirements.
[0045] It should be noted that, in order to avoid the influence of absolute paths when inputting data to the DUT, an interface was added to this UVM verification environment, and then the "send" and "receive" operations of the config_db mechanism were used to connect the interface in test_top with the interface in driver.
[0046] Therefore, compared to verifying the design by writing targeted test stimuli in Verilog, the verification platform of this application includes random and targeted testing. The verification process is more comprehensive and specific, covering some typical abnormal scenarios and boundary conditions. Its verification function is more complete, covering more functional points, and the verification is more complete. This application embodiment can support the verification of multiple peripheral devices under APB through parameter configuration, including common slave device verification such as apb_i2C, apb_uart, and apb_spi. Furthermore, it can add verification of more APB buses and their slave devices, increasing the reusability of development code and the verification platform. At the same time, it saves costs compared to VIP, simplifies verification difficulty, and increases chip development efficiency.
[0047] To facilitate those skilled in the art to further understand the APB bus and the verification method of the APB bus slave device in the embodiments of this application, the following is combined with Figure 2 The embodiments shown will be described in detail.
[0048] Specifically, such as Figure 2 As shown, Figure 2This is a schematic diagram of a UVM-based verification platform for an APB bus and its slave devices, representing an embodiment of this application. The present invention proposes a method for constructing a UVM-based verification platform for an APB bus and its slave devices, primarily used for verifying the APB bus and its slave devices. The entire UVM environment of the UVM-based verification platform for the APB bus and its slave devices consists of components such as a driver, a monitor, a sequencer, a reference model, and a scoreboard.
[0049] Furthermore, the module interfaces for the APB bus and its slave devices are first defined in the file, and the entire DUT is encapsulated in the `dut_top` file. Then, `dut_top` is instantiated and connected to the verification environment. The configuration file then selects the IP modules of the APB bus and its slave devices to be verified, such as the `apb_spi` IP module. The interface information of the various UVM components communicates with each other using virtual interfaces, avoiding the problems of absolute paths and improving code portability. During the simulation phase, the test case names are entered, and this verification platform can automatically generate and configure the verification environment. Verification personnel only need to write test case files on the template without needing to worry about setting up the verification environment. In this UVM verification platform, the sequence is derived from `uvm_sequence`, and the transaction sent by the sequencer is derived from `uvm_sequence_item`, used to send data stimuli. The agent in_gent is derived from uvm_agent and is used to encapsulate the sequencer, driver, and monitor together. The sequencer is derived from uvm_sequencer and is used to check the transmission sequence. The driver is derived from uvm_driver and the monitor is derived from uvm_monitor. This verification platform based on the uvm-based APB bus and its slave devices uses the sequencer to generate transactions, and the driver is responsible for receiving and driving transactions.
[0050] After selecting the APB bus and its slave device IP modules to be verified through the configuration file, different test cases are selected based on the specific functional test points to verify the DUT, as modules with the same protocol may not implement the same specific functions. The test platform verification test cases in this embodiment are relatively complete; however, the required test case files need to be activated according to specific needs. Ultimately, all test requirements are determined by the functional points to be verified. Test cases use different sequences to generate stimuli. The sequencer then transmits the APB data stimuli to the driver, which in turn sends the data stimuli to the DUT. For write operations, the sequencer generates write data stimuli and sends the write data to the APB interface signal via the driver. The APB interface signal is then sent to the next-level slave device signal. This process involves data protocol conversion, specifically from the APB protocol to the slave device's related protocol, for example, from the APB protocol to the SPI protocol. Subsequently, the monitor collects the output results, converts the interface signal into transaction data packets, and sends them to the scoreboard. Simultaneously, it compares the data with the data output by reference_mode to determine whether the data write operation was successful.
[0051] Additionally, this IP module incorporates a FIFO (First-In, First-Out) storage queue to store the first written stimuli. Test stimuli are sent to the reference_model and DUT via the driver and sequencer. The scoreboard receives the data and stores it in a FIFO buffer, which follows a first-in, first-out (FIFO) principle. The data in the reference_model is then compared with the DUT output data, one by one, to obtain the data verification result. If the data comparison is successful, the stimulus passes; otherwise, it fails. The uvm_info statement outputs the results. If any data mismatch occurs, the corresponding test case is located, and the cause of the bug can be investigated. Bug finding can be done by using Verdi to open waveform graphs to capture signals one by one or by inspecting the design code.
[0052] Furthermore, the verification platform based on the UVM-based APB bus and its slave devices includes write operations, read operations, and support for APB-side delayed transmission. To ensure complete verification of all functional points of the design under test (DUT), this verification platform also includes collecting verification functional coverage results. Verification coverage generally includes functional coverage and code coverage. Code coverage is generally easier to achieve, while functional coverage is specified by the tester based on the functional requirements of the DUT. After the functional points are specified, corresponding test cases are written. The verification progress is monitored by checking the pass / fail status of the test cases. Once all test cases pass, the verification functional point target is achieved. When a test case fails, the above method is used to find the cause. If it is a problem with the DUT, the DUT code is modified and the test is repeated until it passes. This process is an iterative process. The simulation platform file contains complete test cases. During simulation, this invention can automatically complete the simulation of test cases based on the input test case name. This UVM-based APB bus and its slave device verification platform features detailed test cases, including random and abnormal stimuli, as well as boundary conditions, to improve verification completeness. Code coverage and functional coverage are required to meet the target, generally 100%.
[0053] It should be noted that, in addition to verifying the input and output interface signal functions of the IP module, the internal interface signals of the IP module also need to be verified during the verification process. Verification methods include using Verdi to capture waveforms.
[0054] This UVM-based APB bus and its slave device verification platform allows users to select different APB buses and their slave devices for verification via configuration files. The platform integrates verification of three peripheral devices supported by APB: apb_spi, apb_i2c, and apb_uart IP modules. Furthermore, it allows for the addition of verification content for other peripheral devices supported by the APB protocol. This allows for the retention of the APB code while only adding the corresponding slave device content, increasing code reusability. During testing, test cases are run via a Makefile, initializing the various components of the verification platform and automatically building the verification environment. This separates test case creation from verification environment setup, reducing the workload for verification developers.
[0055] Therefore, in this invention, a large number of test cases on the UVM verification platform enable comprehensive coverage of the functional points of the design under test, resulting in accurate and reliable verification results. Furthermore, different APB buses and their slave devices can be selected for verification through configuration files, and new APB slave devices can be added to the framework of the verification platform for verification. This achieves the characteristic of strong reusability of the verification platform, effectively utilizes the advantages of the UVM verification method, improves the efficiency of chip verification, shortens the chip development cycle, and saves development costs.
[0056] According to the verification method for the APB bus and APB bus slave devices proposed in this application, the embodiments of this application determine the design under test (DUT) and encapsulate it in a preset top-level design file; acquire the APB bus input signals of the DUT, convert the APB bus input signals into first transaction data, and send the first transaction data to a preset reference model, outputting expected result data through the preset reference model; determine the target slave device module from multiple slave device modules of the DUT, acquire the output signals of the target slave device module, convert the output signals into second transaction data, and compare and verify the expected result data and the second transaction data to obtain the verification result of the target slave device module. This solves the problems of incomplete functional point coverage and high commercial verification VIP costs in APB bus verification.
[0057] Next, referring to the accompanying drawings, a verification apparatus for the APB bus and the APB bus slave device according to an embodiment of this application is described.
[0058] Figure 3 This is a block diagram of the verification device for the APB bus and the APB bus slave device according to an embodiment of this application.
[0059] like Figure 3 As shown, the verification device 10 for the APB bus and APB bus slave device includes: a determination module 100, an output module 200, and a verification module 300.
[0060] Among them, the determination module 100 is used to determine the design to be tested and encapsulate the design to be tested in a preset top-level design file; The output module 200 is used to acquire the APB bus input signal of the design under test, convert the APB bus input signal into first transaction data, send the first transaction data to the preset reference model, and output the expected result data through the preset reference model. The verification module 300 is used to determine the target slave device module from multiple slave device modules of the design under test, collect the output signal of the target slave device module, convert the output signal into second transaction data, and compare and verify the expected result data and the second transaction data to obtain the verification result of the target slave device module.
[0061] Optionally, the verification module 300 is specifically used for: connecting the preset top-level design file and the top-level verification environment through instantiation; determining the target slave device module from the APB bus and the slave device IP modules of the APB bus based on the configuration file; and building a UVM verification platform based on the target slave device module.
[0062] Optionally, the UVM validation platform includes: an environment component and a top-level validation environment, wherein the environment component integrates an input agent, an output agent, a preset reference model, and a scoreboard; the environment component is instantiated and encapsulated in the top-level validation environment.
[0063] Optionally, before acquiring the APB bus input signal of the design under test, the output module 200 is also used to: generate stimulus data based on the sequencer, and send the stimulus data to the design under test and the preset reference model through the driver.
[0064] Optionally, when comparing and verifying the expected result data and the second transaction data to obtain the verification result of the target slave device module, the verification module 300 is also used to: collect the functional coverage and code coverage during the verification process, and determine that the verification of the target slave device module is completed when the functional coverage and code coverage reach the preset requirements.
[0065] Optionally, after collecting the functional coverage and code coverage during the verification process, the verification module 300 is further configured to: if the functional coverage and code coverage do not meet the preset requirements, add random stimuli and / or targeted stimuli, and re-execute the step of sending the stimuli data to the design under test and the preset reference model through the driver, until the code coverage and functional coverage meet the preset requirements.
[0066] It should be noted that the foregoing explanation of the verification method embodiment for the APB bus and APB bus slave device also applies to the verification device for the APB bus and APB bus slave device in this embodiment, and will not be repeated here.
[0067] According to the verification apparatus for the APB bus and APB bus slave device proposed in the embodiments of this application, the embodiments of this application determine the design under test (DUT) and encapsulate the DUT in a preset top-level design file; acquire the APB bus input signals of the DUT, convert the APB bus input signals into first transaction data, and send the first transaction data to a preset reference model, outputting expected result data through the preset reference model; determine the target slave device module from multiple slave device modules of the DUT, acquire the output signals of the target slave device module, convert the output signals into second transaction data, and compare and verify the expected result data and the second transaction data to obtain the verification result of the target slave device module. This solves the problems of incomplete functional point coverage and high commercial verification VIP costs in APB bus verification.
[0068] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include: The memory 401, the processor 402, and the computer program stored on the memory 401 and capable of running on the processor 402.
[0069] When the processor 402 executes the program, it implements the verification method for the APB bus and the APB bus slave device provided in the above embodiments.
[0070] Furthermore, electronic devices also include: Communication interface 403 is used for communication between memory 401 and processor 402.
[0071] The memory 401 is used to store computer programs that can run on the processor 402.
[0072] Memory 401 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.
[0073] If the memory 401, processor 402, and communication interface 403 are implemented independently, then the communication interface 403, memory 401, and processor 402 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0074] Optionally, in a specific implementation, if the memory 401, processor 402, and communication interface 403 are integrated on a single chip, then the memory 401, processor 402, and communication interface 403 can communicate with each other through an internal interface.
[0075] Processor 402 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.
[0076] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described APB bus and APB bus slave device verification method.
[0077] This application also provides a computer program product that stores a computer program that, when executed by a processor, implements the above-described APB bus and APB bus slave device verification method.
[0078] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.
[0079] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.
[0080] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.
[0081] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.
[0082] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it includes one or a combination of the steps of the method embodiments.
Claims
1. An APB bus and a method for verifying APB bus slave devices, characterized in that, Includes the following steps: Identify the design to be tested and encapsulate it in a preset top-level design file; The APB bus input signal of the design under test is acquired, the APB bus input signal is converted into first transaction data, and the first transaction data is sent to a preset reference model. The expected result data is then output through the preset reference model. The target slave device module is determined from the multiple slave device modules of the design under test, and the output signal of the target slave device module is collected. The output signal is converted into second transaction data, and the expected result data and the second transaction data are compared and verified to obtain the verification result of the target slave device module.
2. The method according to claim 1, characterized in that, The step of determining the target slave device module from the plurality of slave device modules of the design under test includes: The preset top-level design file and the top-level verification environment are linked by instantiation; The target slave device module is determined from the APB bus and the slave device IP modules of the APB bus based on the configuration file; A UVM verification platform is built from the device module according to the stated objectives.
3. The method according to claim 2, characterized in that, The UVM verification platform includes: environmental components and a top-level verification environment, wherein, The environment component integrates the input agent, the output agent, the preset reference model, and the scoreboard; The environment component is instantiated and encapsulated in the top layer of the verification environment.
4. The method according to claim 1, characterized in that, Before acquiring the APB bus input signal of the design under test, the method further includes: The sequencer generates stimulus data, which is then sent to the design under test and a preset reference model via a driver.
5. The method according to claim 1, characterized in that, When comparing and verifying the expected result data and the second transaction data to obtain the verification result of the target slave device module, the method further includes: Collect functional coverage and code coverage during the verification process. When the functional coverage and code coverage reach the preset requirements, it is determined that the verification of the target device module is completed.
6. The method according to claim 5, characterized in that, Following the functional coverage and code coverage in the aforementioned collection and verification process, the following is also included: If the functional coverage and code coverage do not meet the preset requirements, random stimuli and / or targeted stimuli are added, and the step of sending the stimulus data to the design under test and the preset reference model via the driver is re-executed until the code coverage and functional coverage meet the preset requirements.
7. A verification device for an APB bus and an APB bus slave device, characterized in that, include: A determination module is used to determine the design under test and encapsulate the design under test in a preset top-level design file; The output module is used to acquire the APB bus input signal of the design under test, convert the APB bus input signal into first transaction data, send the first transaction data to a preset reference model, and output the expected result data through the preset reference model. The verification module is used to determine the target slave device module from multiple slave device modules of the design under test, collect the output signal of the target slave device module, convert the output signal into second transaction data, and compare and verify the expected result data and the second transaction data to obtain the verification result of the target slave device module.
8. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the APB bus and APB bus slave device verification method as described in any one of claims 1-6.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the verification method for the APB bus and APB bus slave device as described in any one of claims 1-6.
10. A computer program product, said computer program product storing a computer program, characterized in that, When executed by the processor, the program implements the APB bus and the verification method for the APB bus slave device as described in any one of claims 1-6.