UVM-based bus conversion bridge verification method, device, equipment and storage medium

Abstract

The present invention relates to the field of integrated circuit design technology, and in particular to a UVM-based bus conversion bridge verification method, device, equipment, and storage medium. The method obtains input parameters of a module to be tested, and based on the bus conversion bridge AMBA protocol interface specification, determines the verification requirements and verification strategy corresponding to the input parameters; based on the verification requirements and the verification strategy, determines a target interface, and based on the UVM base class library, establishes a constraint incentive corresponding to the target interface; based on a verification model and the constraint incentive, verifies the module to be tested, and outputs a verification result. By analyzing the input parameters, the corresponding verification requirements and verification strategy are determined, thereby determining the verification model to be used, and performing a verification test on the module to be tested. The UVM-based bus conversion bridge verification method can improve the reusability of the system and the degree of automation of the verification platform construction, thereby improving the work efficiency of verification.

Description

Technical Field

[0001] The present invention relates to the technical field of integrated circuit design, and in particular to a UVM-based bus conversion bridge verification method, device, equipment and storage medium. Background Art

[0002] With the rapid development of modern society, the upgrade of various advanced electronic products, both in the civilian and military sectors, is inseparable from the advancement of chips. According to research and analysis, the majority of SoC (System on Chip) functional chips fail in the first tape-out due to functional defects. Because SoC functional verification is complex and requires thorough verification from RTL (Register Transfer Level) to chip production, improving verification efficiency, reducing verification time, and enhancing verification completeness are urgent priorities.

[0003] With the development of system-on-chip, the AMBA (Advanced Microcontroller Bus Architecture) bus protocol has been continuously improved to meet people's requirements for high system performance. In complex SOCs, if only a single bus is used, its timing convergence will be affected because too many IP (Intellectual Property) cores are mounted on the single bus. Therefore, multiple buses must be built, and the information exchange between the buses must be through bus conversion bridges. The extensive use of bus conversion bridges will obviously make the verification of bus conversion bridges more difficult.

[0004] As the scale of system-on-chip (SoC) designs continues to expand, the number of IP modules integrated within SoCs is also increasing. Consequently, the requirements for chip verification during chip development are becoming increasingly stringent, and the construction of verification platforms is becoming more complex. Therefore, improving the efficiency of verification platforms has become a pressing technical challenge. Summary of the Invention

[0005] The main purpose of the present invention is to provide a bus conversion bridge verification method, device, equipment and storage medium based on UVM, aiming to solve the technical problem of low working efficiency of existing verification platforms.

[0006] To achieve the above object, the present invention provides a bus conversion bridge verification method based on UVM, and the bus conversion bridge verification method based on UVM includes:

[0007] Obtain input parameters of the module to be tested, and determine the verification requirements and verification strategies corresponding to the input parameters based on the bus conversion bridge AMBA protocol interface specification;

[0008] Based on the verification requirements and the verification strategy, determine the target interface, and based on the UVM base class library, establish the constraint incentive corresponding to the target interface;

[0009] Based on the verification model and the constraint incentive, the module to be tested is verified and a verification result is output.

[0010] Furthermore, the constraint incentive corresponding to the target interface is established based on the UVM base class library, including:

[0011] Based on the sequence class in the UVM base class library, create sequence items corresponding to each target interface;

[0012] The constrained incentive is generated based on the sequence items.

[0013] Furthermore, the verifying the module to be tested based on the verification model and the constraint incentive and outputting the verification result includes:

[0014] Inputting the constraint incentive into the verification model, and determining the functions to be verified and the verification order of each function to be verified based on the sequence item in the constraint incentive;

[0015] Based on the sequence items and the verification order, each function to be verified is verified in turn, and the verification result is output to complete the verification of the module to be tested.

[0016] Furthermore, the determining the target interface based on the verification requirement and the verification strategy includes:

[0017] Determining a function to be verified based on the verification requirement and the verification strategy;

[0018] Determining a verification model to be used based on the function to be verified;

[0019] Based on the standby verification model, a bus interface between the standby verification model and the module to be tested is determined as the target interface.

[0020] Furthermore, the verifying the module to be tested based on the verification model and the constraint incentive and outputting the verification result further includes:

[0021] Creating a monitoring interface, and connecting a monitor and the verification model based on the monitoring interface;

[0022] Based on the monitor, sampling verification data of the module to be tested by the verification model;

[0023] The verification data is sent to a scoreboard, and a comparison result between the verification data in the scoreboard and the standard data in the reference model is obtained as the verification result.

[0024] Furthermore, sampling verification data of the module to be tested by the verification model based on the monitor includes:

[0025] Based on the monitor, collecting code coverage and functional coverage of each constraint stimulus in the verification model;

[0026] Determining a target coverage rate based on the code coverage rate and the function coverage rate;

[0027] When the target coverage reaches a preset coverage, the current sampling data is used as the verification data.

[0028] Furthermore, after determining the target coverage based on the code coverage and the function coverage, the method further includes:

[0029] When the target coverage does not reach the preset coverage, modifying the constraint incentive to determine a test blind area;

[0030] Based on the test blind area, an iterative constraint stimulus is created, and based on the iterative constraint stimulus, the module to be tested is verified to obtain the current sampling data and the target coverage until the target coverage reaches the preset coverage, and the current sampling data is used as the verification data.

[0031] In addition, to achieve the above-mentioned purpose, the present invention also provides a bus conversion bridge verification device based on UVM, which includes: a verification requirement determination module, which is used to obtain input parameters of a module to be tested, and determine the verification requirements and verification strategies corresponding to the input parameters based on the bus conversion bridge AMBA protocol interface specification; a constraint incentive establishment module, which is used to determine a target interface based on the verification requirements and the verification strategy, and establish a constraint incentive corresponding to the target interface based on a UVM base class library; and a verification result output module, which is used to verify the module to be tested based on a verification model and the constraint incentive, and output a verification result.

[0032] In addition, to achieve the above-mentioned purpose, the present invention also provides a UVM-based bus conversion bridge verification device, which includes a processor, a memory, and a UVM-based bus conversion bridge verification program stored in the memory and executable by the processor, wherein when the UVM-based bus conversion bridge verification program is executed by the processor, the steps of the above-mentioned UVM-based bus conversion bridge verification method are implemented.

[0033] In addition, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which a UVM-based bus conversion bridge verification program is stored, wherein when the UVM-based bus conversion bridge verification program is executed by a processor, the steps of the UVM-based bus conversion bridge verification method as described above are implemented.

[0034] The present invention provides a bus conversion bridge verification method based on UVM. The method obtains input parameters of a module to be tested, determines verification requirements and verification strategies corresponding to the input parameters based on the bus conversion bridge AMBA protocol interface specification; determines a target interface based on the verification requirements and verification strategies, and establishes constraint incentives corresponding to the target interface based on a UVM base class library; verifies the module to be tested based on a verification model and the constraint incentives, and outputs a verification result. Through the above-mentioned method, the present invention determines the corresponding verification requirements and verification strategies by analyzing the input parameters, thereby determining the verification model to be used, connects the corresponding verification model through the target interface, generates the corresponding constraint incentives, performs verification testing on the module to be tested, and obtains a verification result. Through the bus conversion bridge verification method based on UVM, the reusability of the system and the automation level of the verification platform construction can be improved, the working efficiency of the verification is improved, and the technical problem of the low working efficiency of the current verification platform is solved. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 Schematic diagram of the hardware structure of the UVM-based bus conversion bridge verification device involved in the embodiment of the present invention;

[0036] Figure 2 A schematic flow chart of a first embodiment of a bus conversion bridge verification method based on UVM according to the present invention;

[0037] Figure 3 It is a standardized Agent template proposed in this embodiment;

[0038] Figure 4 A schematic flow chart of a second embodiment of a bus conversion bridge verification method based on UVM according to the present invention;

[0039] Figure 5 A schematic diagram of the structure of a reusable verification platform provided by the present invention;

[0040] Figure 6 A schematic flow chart of a third embodiment of a bus conversion bridge verification method based on UVM according to the present invention;

[0041] Figure 7 The present invention is a schematic diagram of the application process of the bus conversion bridge verification platform based on UVM;

[0042] Figure 8This is a functional module diagram of the first embodiment of the UVM-based bus conversion bridge verification device of the present invention.

[0043] The purpose, features and advantages of the present invention will be further described with reference to the accompanying drawings and in conjunction with the embodiments. DETAILED DESCRIPTION

[0044] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0045] The UVM-based bus conversion bridge verification method involved in the embodiment of the present invention is mainly applied to a UVM-based bus conversion bridge verification device, which can be a device with display and processing functions such as a PC, a portable computer, or a mobile terminal.

[0046] Reference Figure 1 , Figure 1 The hardware structure diagram of the UVM-based bus conversion bridge verification device involved in the embodiment of the present invention is shown in FIG. In the embodiment of the present invention, the UVM-based bus conversion bridge verification device may include a processor 1001 (e.g., a CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to realize the connection and communication between these components; the user interface 1003 may include a display screen (Display) and an input unit such as a keyboard (Keyboard); the network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface); the memory 1005 may be a high-speed RAM memory or a stable memory (non-volatile memory), such as a disk memory. The memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0047] Those skilled in the art will understand that Figure 1 The hardware structure shown in the figure does not constitute a limitation on the UVM-based bus conversion bridge verification device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0048] Continue to refer to Figure 1 , Figure 1 The memory 1005 as a computer-readable storage medium may include an operating system, a network communication module, and a UVM-based bus conversion bridge verification program.

[0049] exist Figure 1In the embodiment, the network communication module is mainly used to connect to the server and perform data communication with the server; and the processor 1001 can call the UVM-based bus conversion bridge verification program stored in the memory 1005 and execute the UVM-based bus conversion bridge verification method provided in the embodiment of the present invention.

[0050] An embodiment of the present invention provides a bus conversion bridge verification method based on UVM.

[0051] Reference Figure 2 , Figure 2 The figure is a flow chart of the first embodiment of the bus conversion bridge verification method based on UVM of the present invention.

[0052] In this embodiment, the bus conversion bridge verification method based on UVM includes the following steps:

[0053] Step S10, obtaining input parameters of the module to be tested, and determining verification requirements and verification strategies corresponding to the input parameters based on the bus conversion bridge AMBA protocol interface specification;

[0054] In this embodiment, by studying the mechanism of AMBA series bus conversion bridge to reduce bus bandwidth occupation, bus conversion bridge design principles and AMBA port protocol interface specifications, the goals of UVM verification as well as the overall verification requirements and verification strategy are given.

[0055] Specifically, the AMBA bus protocol is a set of interconnect specifications provided by ARM that standardizes chip communication mechanisms between various IPs. These designs typically have one or more microprocessors and integrate other components such as internal memory or external memory bridges, DSPs, DMA, accelerators, and various other peripherals such as USB, UART, PCIe, and I2C. The main purpose of the AMBA protocol is to provide a standard and efficient way to reuse these IPs across multiple designs.

[0056] Step S20, based on the verification requirement and the verification strategy, determining the target interface, and establishing a constraint incentive corresponding to the target interface based on the UVM base class library;

[0057] In this embodiment, by adjusting the timing of the bus interface signals on both sides of the bus bridge to conform to the timing specifications of the corresponding bus standards, data exchange and communication between different buses can be carried out more smoothly. The entire verification platform operation process is designed into different stages, ensuring that each stage performs specific tasks at specific times, thereby improving efficiency. Through the design of sequences, the generation of stimulus information is completely independent from other components, increasing the flexibility of data flow generation.

[0058] In this embodiment, in order to improve the reusability of the UVM platform, a UVM verification platform based on a hierarchical structure is developed, including a factory mechanism, a callback mechanism and a sequence mechanism.

[0059] The factoy mechanism allows for the creation of internal components and object overloading by registering extension classes with a factory. The factory mechanism primarily targets uvm_component and its subclasses, which form the verification environment hierarchy, and uvm_object and its subclasses, which constitute the environment's configuration properties and data transmission.

[0060] The callback mechanism improves code reusability and is also used to build exception test cases. If you use callback functions to handle the differences between two projects, and write the similarities into a complete environment, then when reusing, you only need to change the relevant callback function environment to fully reuse them.

[0061] The sequence mechanism is used to control and generate a series of stimuli and send them to the driver through the sequencer. Sequence is the process of generating and sending data.

[0062] Specifically, the UVM universal class library is used to write components that simulate the behavior of the host and slave ends on the AMBA series bus verification platform. The verification platform environment is dynamically configured to meet different verification requirements, constrained random excitations are generated, and interfaces are reserved to facilitate the expansion of the verification platform's functionality. The sequence class in the UVM base class library is used to generate excitation transactions. Sequence items are created for the corresponding interfaces, and constrained random excitations are added to the sequence class, such as write address and control information, burst type, burst length, protection type, etc. This allows for a more comprehensive verification of the design under test (DUT) for functional defects, addresses special cases that verifiers have not considered, and achieves comprehensive verification more quickly.

[0063] A sequence item is the smallest granularity of content in each interaction between the driver and the DUT. It can only encapsulate data and does not have automatically executed functions. The sequence object itself generates a target number of sequence item objects. Thanks to the randomization of the SV and the support of sequence items for randomization, the data content in each generated sequence item object is unique. The generated sequence items flow through the sequencer and then to the driver. The driver obtains each sequence item, parses the data, and then writes the data to the interface according to the physical interface protocol with the DUT, effectively stimulating the DUT.

[0064] like Figure 3 As shown, Figure 3 It is a standardized Agent template proposed in this embodiment.

[0065] In this embodiment, the standardized Agent template is a Cag (common agent) template, which covers all Agent components and automatically adjusts the calls and connections of internal components based on the different work_mode configurations. It includes:

[0066] (1) Cag_driver.sv and cag_driver_cfg.sv

[0067] The module that generates timing stimulus in Master mode obtains the interface passed in by the external verification environment during the build phase and implements the function of obtaining transactions from the sequencer and driving them to the interface during the main phase. It reserves callback function interfaces, dynamic reset functions, random IDLE state functions, and task templates for read and write operations.

[0068] The cag_driver_cfg.sv file is the driver control file. It can be used to specify some driver-related configuration values, such as random mode, random weight, back pressure mode, and whether to retain read data when read is invalid.

[0069] Note: The value of Cfg should be obtained recursively from the upper cfg file, that is, driver_cfg should come from agent_cfg, and agent_cfg should come from env_cfg.

[0070] (2) Cag_slave_driver.sv and Cag_slave_driver.sv

[0071] In slave mode, this module is used to generate responses to input stimuli. Its internal functions are similar to those of cag_driver.sv.

[0072] The main_task in the slave_driver can be triggered in two ways: 1. Utilize the sequence mechanism to generate transactions, assign values ​​to these transactions under specific conditions, and drive them to the interface; 2. Start a resident loop in the run_phase that drives directly to the interface whenever specific conditions are met. If method 2 is used, the slave_sequence can be started in two ways: 1. Automatically start the slave_sequence in the run_phase of cag_interface_agent.sv by default; 2. Manually start the slave_sequence in the appropriate location within the user's sequence_lib / testcase / environment.

[0073] (3) Cag_monitor.sv, cag_monitor_cfg.sv and cag_monitor_cov.sv

[0074] A pure monitoring sampling module, which is enabled in all working modes, samples data from the interface and encapsulates it into transactions, and then sends it out through the out_port. (The out_port is usually connected to the RM or CHECKER in the environment)

[0075] cag_monitor_cov.sv is the complete set of interface function coverage models involved in the AGENT, which is used to assist users in measuring incentive completeness.

[0076] (4)Cag_interface.sv

[0077] This represents the agent's complete input and output interfaces, including three clocking blocks and three modports. These correspond to the master (including reg_master), slave, and monitor operating modes. Note: The direction of the same signal varies across the three clocking blocks. For example, for the Paddr of the APB interface, the direction of the signal in drv_cb should be output, the direction of the signal in slv_cb should be input, and the direction of all signals in mon_cb should be input.

[0078] (5)Cag_xaction.sv

[0079] It is a specific uvm_sequence_item in the agent. It should be noted that there is no absolute one-to-one correspondence between the members in cag_xaction and the members in cag_interface.

[0080] (6)Cag_sequence_lib.sv and cag_sequencer

[0081] Cag_sequence_lib.sv should provide the base_sequence base class of the agent, as well as sequence branches in various modes (such as master_seq / slave_seq, etc.). At the same time, it should provide task encapsulation shortcut operations for user convenience (for example, apb-agent should provide apb_write and apb_read functions).

[0082] (7) Cag_agent.sv and cag_agent_cfg.sv

[0083] The top level of Cag_agent declares, instantiates, and connects the aforementioned components according to the function switches. To use the agent, users only need to instantiate it. Cfg is its corresponding configuration file.

[0084] (8)Cag_agent_dec.sv

[0085] The declare file of the agent, which is used to define the parameters, defines, typedefs, structs, etc. involved in the agent.

[0086] (9)Cag_reg_adapter.sv

[0087] Only enabled in reg_master mode, used to connect reg_model and agent, converting uvm_reg_bus_op in reg_model to trasaction in agent.

[0088] (10)Cag.f

[0089] A list of files that users need to add to their own env.f.

[0090] Step S30: verifying the module to be tested based on the verification model and the constraint stimulus, and outputting a verification result.

[0091] In this embodiment, the stimulus added in the Sequence is called in the UVM Sequencer as a whole. The UVMSequencer sends it to the UVM driver in the form of transaction communication according to the needs of the Driver. The Driver converts the abstract stimulus transaction into a signal-level stimulus that can be recognized by the DUT interface, thereby driving the DUT. At the same time, a monitor is created in each DUT to collect coverage data, and converts it into an abstract transaction and sends it back to the user.

[0092] This embodiment provides a bus conversion bridge verification method based on UVM, the method obtains the input parameters of the module to be tested, and based on the bus conversion bridge AMBA protocol interface specification, determines the verification requirements and verification strategies corresponding to the input parameters; based on the verification requirements and the verification strategies, determines the target interface, and based on the UVM base class library, establishes the constraint incentive corresponding to the target interface; based on the verification model and the constraint incentive, verifies the module to be tested and outputs the verification result. Through the above-mentioned manner, the present invention determines the corresponding verification requirements and verification strategies by analyzing the input parameters, thereby determining the verification model to be used, connects the corresponding verification model through the target interface, generates the corresponding constraint incentive, performs verification testing on the module to be tested, and obtains the verification result. Through the bus conversion bridge verification method based on UVM, the reusability of the system and the degree of automation of the verification platform construction can be improved, the working efficiency of the verification is improved, and the technical problem of the low working efficiency of the current verification platform is solved.

[0093] Reference Figure 4 , Figure 4 1 is a flow chart of a second embodiment of a bus conversion bridge verification method based on UVM according to the present invention.

[0094] Based on the above Figure 2 In the embodiment shown, in this embodiment, step S20 specifically includes:

[0095] Step S21, based on the sequence class in the UVM base class library, creating sequence items corresponding to each target interface;

[0096] Step S22: generating the constraint incentive based on the sequence item.

[0097] In the present embodiment, in AMBA protocol conversion bridge design, there are three interfaces in total, and wherein AHB, AXI interfaces are host interfaces, therefore need to add randomized incentive affairs to these two interfaces and carry out the transmission of emulated data stream.The generation of incentive affairs is realized by the sequence class in UVM SystemVerilog base class library, creates sequence item to corresponding interface respectively, adds constraint randomization incentive in sequence class, such as write address and control information, burst type, burst length, protection type etc. can all be randomized, whether the function of verification DUT more comprehensively can be defective like this, make up the special case that verification personnel can't consider, reach comprehensive verification degree faster.

[0098] Furthermore, based on the above Figure 2 In the embodiment shown, in this embodiment, step S30 specifically includes:

[0099] Inputting the constraint incentive into the verification model, and determining the functions to be verified and the verification order of each function to be verified based on the sequence item in the constraint incentive;

[0100] Based on the sequence items and the verification order, each function to be verified is verified in turn, and the verification result is output to complete the verification of the module to be tested.

[0101] In the present embodiment, UVM divides the operation process of the entire verification platform into different stages, and purpose is exactly to ensure that specific things are done at specific times, thereby improving efficiency. The design concept of Sequence also follows this principle in full. It completely separates the generation of data stream (stimulus information) from other parts, thereby mentioning the reusability of other parts and increasing the flexibility of data stream generation. After the data stream is generated, it is necessary to send it to the driver and then to the DUT, so a sequencer is needed to provide an interface, convert the upper layer stimulus configuration scenario into required transaction incentive, and send it to the driver, which is connected to the driver by the TLM port to realize communication.

[0102] Furthermore, based on the above Figure 2 In the embodiment shown, in this embodiment, step S20 specifically includes:

[0103] Determining a function to be verified based on the verification requirement and the verification strategy;

[0104] Determining a verification model to be used based on the function to be verified;

[0105] Based on the standby verification model, a bus interface between the standby verification model and the module to be tested is determined as the target interface.

[0106] In the present embodiment, the whole verification platform of UVM is based on the stimulus simulation of abstract transactions, so the signals are classified, divided into directions, and pointed to the signal interface of the corresponding DUT. These are all realized by the systemverilog grammar, which also reflects the efficiency and reusability of building the UVM verification platform. The packaging of signals is realized by the interface keyword in systemverilog. The binding of signals is realized by the bind keyword.

[0107] Interfaces are divided into two categories: one is the actual data structure that packages signals for manipulation, and the other is the virtual interface, which primarily connects SystemVerilog code to Verilog code and enables communication between them. Because stimuli are added to tasks in SystemVerilog, correct connections are essential. The UVM-based AMBA protocol conversion bridge verification implementation only requires instantiation of the interface. To target different DUT submodules, instantiate them within each DUT submodule. This is very convenient, saves a lot of work, and demonstrates the reusability of the UVM verification platform.

[0108] Reference Figure 5 , Figure 5 A schematic structural diagram of a reusable verification platform provided by the present invention.

[0109] In this embodiment, the reusable verification platform may include UVM verification component-level reuse, module-level reuse, function-level reuse, and transaction-level reuse.

[0110] Among them, the verification component level includes a complete test stimulus library, which is generated in real time according to the established constraints of the environmental configuration or transmission sequence; the focus of module-level reuse is to be separated from the protocol content and placed on the reuse of basic functions. Function-level reuse mainly includes conversion between various protocols or the sending and receiving of data and protocols, including address mapping conversion functions and task functions that drive address transmission, common functions, and task function libraries; transaction-level reuse defines basic content such as data packet types and data transmission formats for common protocol content. For designs with similar protocols, the parent class definition and functional functions are reused by inheriting and modifying the common library content.

[0111] Reference Figure 6 and Figure 7 , Figure 6 A schematic flow chart of a third embodiment of a bus conversion bridge verification method based on UVM according to the present invention; Figure 7 The present invention is a schematic diagram of the application process of the bus conversion bridge verification platform based on UVM.

[0112] Based on the above Figure 2In the embodiment shown, in this embodiment, the step S30 specifically further includes:

[0113] Step S31, creating a monitoring interface, and connecting a monitor and the verification model based on the monitoring interface;

[0114] Step S32: sampling verification data of the module to be tested by the verification model based on the monitor;

[0115] Step S33: Send the verification data to the scoreboard, and obtain a comparison result between the verification data in the scoreboard and the standard data in the reference model as the verification result.

[0116] In this embodiment, the UVM method supports an automated monitoring module, which primarily implements a reference model module and a scoreboard to coordinate verification and ensure the correctness of verification. The verification platform is further optimized by combining the System Verilog high-level verification language, improving the error-checking mechanism, and enabling verification of the reuse of AMBA series buses and bus conversion bridges in SOC designs. The bus functional model is used to generate the desired incentives for verifiers.

[0117] In a specific implementation, based on verification requirements, constrained randomization test cases were written in SystemVerilog to generate a large number of randomized stimuli for the AHB, AXI, and APB interfaces. A CoverageGroup was then written to collect coverage data for function points on the three interfaces. For function points that were not covered, direct test cases were used to cover the boundary conditions to improve coverage.

[0118] In a specific embodiment, stimulus transactions from the sequencer are fed into the DUT via the driver on the one hand, and also fed into the reference model via the driver on the other. The reference model is the key and core of the entire UVM verification platform because its work is consistent with the DUT. The scoreboard compares its output with the DUT. If the reference model has errors, its output is also unreliable, and thus the scoreboard is also unreliable. The scoreboard is primarily used to compare the data output by the reference model with the DUT to ensure consistency and provide the comparison results.

[0119] Based on the above Figure 6 In the embodiment shown, in this embodiment, step S32 specifically includes:

[0120] Based on the monitor, collecting code coverage and functional coverage of each constraint stimulus in the verification model;

[0121] Determining a target coverage rate based on the code coverage rate and the function coverage rate;

[0122] When the target coverage reaches a preset coverage, the current sampling data is used as the verification data.

[0123] Furthermore, after determining the target coverage based on the code coverage and the function coverage, the method further includes:

[0124] When the target coverage does not reach the preset coverage, modifying the constraint incentive to determine a test blind area;

[0125] Based on the test blind area, an iterative constraint stimulus is created, and based on the iterative constraint stimulus, the module to be tested is verified to obtain the current sampling data and the target coverage until the target coverage reaches the preset coverage, and the current sampling data is used as the verification data.

[0126] In this embodiment, coverage technology is an important indicator for measuring verification progress and completion of verification work. Coverage-driven verification technology is studied, including code coverage and functional coverage.

[0127] Code coverage includes line coverage, state machine coverage, branch coverage, condition coverage, and path coverage. Simulation tools automatically extract code coverage from design code.

[0128] Functional coverage can be divided into two types: data-oriented coverage, which checks the data combination that has been performed and is obtained by writing cover groups, cover points and cross coverage. Control-oriented coverage, which checks whether the behavior sequence has occurred.

[0129] "Coverage" is a general term used to measure the degree of design verification completeness. As tests gradually cover various reasonable combinations, the simulation process gradually paints a picture of the design. Coverage tools collect information from simulation projects, process it, and generate coverage reports. This coverage report identifies coverage gaps, allowing users to modify existing test stimuli or create new tests to address these gaps. This process continues iteratively until coverage reaches the preset standard.

[0130] In addition, an embodiment of the present invention also provides a bus conversion bridge verification device based on UVM.

[0131] Reference Figure 8 , Figure 8 This is a functional module diagram of the first embodiment of the UVM-based bus conversion bridge verification device of the present invention.

[0132] In this embodiment, the UVM-based bus conversion bridge verification device includes:

[0133] Verification requirement determination module 10, used to obtain input parameters of the module to be tested, and determine the verification requirements and verification strategies corresponding to the input parameters based on the bus conversion bridge AMBA protocol interface specification;

[0134] A constraint incentive establishment module 20 is used to determine a target interface based on the verification requirement and the verification strategy, and to establish a constraint incentive corresponding to the target interface based on a UVM base class library;

[0135] The verification result output module 30 is used to verify the module to be tested based on the verification model and the constraint stimulus, and output the verification result.

[0136] Furthermore, the constraint incentive establishment module 20 specifically includes:

[0137] A sequence item creation unit is used to create sequence items corresponding to each target interface based on the sequence class in the UVM base class library;

[0138] A constraint incentive generating unit is used to generate the constraint incentive based on the sequence item.

[0139] Furthermore, the verification result output module 30 specifically includes:

[0140] a first unit for determining functions to be verified, configured to input the constraint stimulus into the verification model, and determine the functions to be verified and a verification order of the functions to be verified based on the sequence item in the constraint stimulus;

[0141] The verification result output unit is used to verify the functions to be verified in sequence based on the sequence items and the verification order, and output the verification result to complete the verification of the module to be tested.

[0142] Furthermore, the constraint incentive establishment module 20 specifically includes:

[0143] A second unit for determining a function to be verified, configured to determine a function to be verified based on the verification requirement and the verification strategy;

[0144] a verification model to be used determining unit, configured to determine a verification model to be used based on the function to be verified;

[0145] The target interface determining unit is configured to determine, based on the standby verification model, a bus interface between the standby verification model and the module to be tested as the target interface.

[0146] Furthermore, the verification result output module 30 specifically includes:

[0147] A monitoring interface creation unit, configured to create a monitoring interface and connect a monitor and the verification model based on the monitoring interface;

[0148] A verification data acquisition unit, configured to sample verification data of the module to be tested by the verification model based on the monitor;

[0149] The verification result obtaining unit is used to send the verification data to the scoreboard, and obtain a comparison result between the verification data in the scoreboard and the standard data in the reference model as the verification result.

[0150] Furthermore, the verification data collection unit specifically includes:

[0151] A coverage collection subunit, configured to collect, based on the monitor, the code coverage and functional coverage of each constraint stimulus in the verification model;

[0152] a target coverage determination subunit, configured to determine a target coverage based on the code coverage and the function coverage;

[0153] The verification data determination subunit is configured to use the current sampling data as the verification data when the target coverage reaches a preset coverage.

[0154] Furthermore, the verification result output module 30 further includes a coverage iteration unit, which specifically includes:

[0155] a test blind area determination subunit, configured to modify the constraint incentive and determine a test blind area when the target coverage does not reach the preset coverage;

[0156] The coverage iteration subunit is used to create an iterative constraint stimulus based on the test blind area, and verify the module to be tested based on the iterative constraint stimulus, obtain the current sampling data and the target coverage, until the target coverage reaches the preset coverage, and use the current sampling data as the verification data.

[0157] Among them, each module in the above-mentioned UVM-based bus conversion bridge verification device corresponds to each step in the above-mentioned UVM-based bus conversion bridge verification method embodiment, and their functions and implementation processes are no longer described here one by one.

[0158] In addition, an embodiment of the present invention also provides a computer-readable storage medium.

[0159] The computer-readable storage medium of the present invention stores a UVM-based bus conversion bridge verification program, wherein when the UVM-based bus conversion bridge verification program is executed by a processor, the steps of the UVM-based bus conversion bridge verification method described above are implemented.

[0160] Among them, the method implemented when the UVM-based bus conversion bridge verification program is executed can refer to the various embodiments of the UVM-based bus conversion bridge verification method of the present invention, and will not be repeated here.

[0161] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or system comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or system. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or system comprising the element.

[0162] The serial numbers of the above embodiments of the present invention are for description only and do not represent the advantages or disadvantages of the embodiments.

[0163] The present application can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and the like. The present application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. The present application can also be practiced in distributed computing environments in which tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media, including storage devices.

[0164] Through the description of the above embodiments, those skilled in the art can clearly understand that the above embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better embodiment. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in each embodiment of the present invention.

[0165] The above are only preferred embodiments of the present invention and are not intended to limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made using the contents of the present invention description and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A bus conversion bridge verification method based on UVM, characterized in that, The bus conversion bridge verification method based on UVM comprises the following steps: Obtain input parameters of the module to be tested, and determine the verification requirements and verification strategies corresponding to the input parameters based on the bus conversion bridge AMBA protocol interface specification; Determine the target interface based on the verification requirements and the verification strategy: Determining a function to be verified based on the verification requirement and the verification strategy; Determining a verification model to be used based on the function to be verified; Based on the standby verification model, determining a bus interface between the standby verification model and the module to be tested as the target interface; Based on the UVM base class library, a constraint incentive corresponding to the target interface is established: based on the sequence class in the UVM base class library, a sequence item corresponding to each target interface is created; generating the constraint incentive based on the sequence item; Based on the verification model and the constraint incentive, the module to be tested is verified and the verification result is output: Inputting the constraint incentive into the verification model, and determining the functions to be verified and the verification order of each function to be verified based on the sequence item in the constraint incentive; Based on the sequence items and the verification order, each function to be verified is verified in turn, and the verification result is output to complete the verification of the module to be tested.

2. the bus conversion bridge verification method based on UVM as claimed in claim 1, is characterized in that, The verifying the module to be tested based on the verification model and the constraint incentive and outputting the verification result further includes: Creating a monitoring interface, and connecting a monitor and the verification model based on the monitoring interface; Based on the monitor, sampling verification data of the module to be tested by the verification model; The verification data is sent to a scoreboard, and a comparison result between the verification data in the scoreboard and the standard data in the reference model is obtained as the verification result.

3. the bus conversion bridge verification method based on UVM as claimed in claim 2, is characterized in that, The step of sampling verification data of the module to be tested by the verification model based on the monitor includes: Based on the monitor, collecting code coverage and functional coverage of each constraint stimulus in the verification model; Determining a target coverage rate based on the code coverage rate and the function coverage rate; When the target coverage reaches a preset coverage, the current sampling data is used as the verification data.

4. the bus conversion bridge verification method based on UVM as claimed in claim 3, is characterized in that, After determining the target coverage based on the code coverage and the function coverage, the method further includes: When the target coverage does not reach the preset coverage, modifying the constraint incentive to determine a test blind area; Based on the test blind area, an iterative constraint stimulus is created, and based on the iterative constraint stimulus, the module to be tested is verified to obtain the current sampling data and the target coverage until the target coverage reaches the preset coverage, and the current sampling data is used as the verification data.

5. A bus conversion bridge verification device based on UVM, characterized in that, Used to run the UVM-based bus conversion bridge verification method according to any one of claims 1 to 4, the UVM-based bus conversion bridge verification device comprises: A verification requirement determination module is used to obtain input parameters of the module to be tested and determine the verification requirements and verification strategies corresponding to the input parameters based on the bus conversion bridge AMBA protocol interface specification; A constraint incentive establishment module is used to determine a target interface based on the verification requirement and the verification strategy, and to establish a constraint incentive corresponding to the target interface based on a UVM base class library; The verification result output module is used to verify the module to be tested based on the verification model and the constraint stimulus, and output the verification result.

6. A bus conversion bridge verification device based on UVM, characterized in that, The UVM-based bus conversion bridge verification device includes a processor, a memory, and a UVM-based bus conversion bridge verification program stored in the memory and executable by the processor, wherein when the UVM-based bus conversion bridge verification program is executed by the processor, the steps of the UVM-based bus conversion bridge verification method according to any one of claims 1 to 4 are implemented.

7. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a UVM-based bus conversion bridge verification program, wherein when the UVM-based bus conversion bridge verification program is executed by a processor, the steps of the UVM-based bus conversion bridge verification method according to any one of claims 1 to 4 are implemented.

Images