CN115543797A

CN115543797A - Bus conversion bridge verification method, device, equipment and storage medium based on UVM

Info

Publication number: CN115543797A
Application number: CN202211193654.1A
Authority: CN
Inventors: 隋金雪; 相光超; 张霞; 王海洋
Original assignee: Yantai Branch Institute Of Computing Technology Chinese Academy Of Science; Shandong Technology and Business University
Current assignee: Yantai Branch Institute Of Computing Technology Chinese Academy Of Science; Shandong Technology and Business University
Priority date: 2022-09-28
Filing date: 2022-09-28
Publication date: 2022-12-30

Abstract

The invention relates to the technical field of integrated circuit design, in particular to a bus conversion bridge verification method, a device, equipment and a storage medium based on UVM, wherein the method obtains input parameters of a module to be tested, and determines verification requirements and verification strategies corresponding to the input parameters based on AMBA protocol interface specifications of the bus conversion bridge; determining a target interface based on the verification requirement and the verification strategy, and establishing constraint excitation corresponding to the target interface based on a UVM base class library; and verifying the module to be tested based on a verification model and the constraint excitation, and outputting a verification result. And determining corresponding verification requirements and verification strategies through analyzing the input parameters, thereby determining verification models required to be used and performing verification tests on the module to be tested. Through the bus conversion bridge verification method based on the UVM, the reusability of the system and the automation degree of the establishment of the verification platform can be improved, and the work efficiency of verification is improved.

Description

Bus conversion bridge verification method, device, equipment and storage medium based on UVM

Technical Field

The invention relates to the technical field of integrated circuit design, in particular to a bus conversion bridge verification method, a bus conversion bridge verification device, bus conversion bridge verification equipment and a storage medium based on UVM.

Background

With the rapid development of modern society, the chip progress cannot be kept in the civilian field or the military field due to the updating and upgrading of various advanced electronic products. According to investigation and analysis, the reason that most SOC (System on Chip) functional chips fail in the first time of Chip flow is functional defects. Since the function verification of the SOC is complicated, sufficient verification work is performed from RTL (Register Transfer Level) to chip commissioning, so that it is urgent to improve the verification work efficiency, reduce the verification time, and improve the verification completeness.

With the development of system on chip, the Bus protocol of the Advanced Microcontroller Bus Architecture (AMBA) is also perfected to meet the requirement of people on high performance of the system, and in a complex SOC, if only a single Bus is used, timing convergence of the single Bus is affected due to too many IP (intelligent performance) cores mounted on the single Bus, so that multiple buses must be built, information communication among the buses must pass through a Bus conversion bridge, and the great use of the Bus conversion bridge obviously leads to the difficulty in verification of the Bus conversion bridge to be increased continuously.

At present, the design scale of a system-level chip is continuously enlarged, the number of IP modules integrated in an SOC chip is also continuously increased, so that the requirement on chip verification in chip development is higher and higher, and the establishment of a verification platform is more complicated. Therefore, how to improve the working efficiency of the verification platform becomes a technical problem to be solved urgently at present.

Disclosure of Invention

The invention mainly aims to provide a bus conversion bridge verification method, a bus conversion bridge verification device, bus conversion bridge verification equipment and a storage medium based on UVM, and aims to solve the technical problem that the existing verification platform is low in working efficiency.

In order to achieve the above object, the present invention provides a bus conversion bridge verification method based on UVM, where the bus conversion bridge verification method based on UVM includes:

acquiring input parameters of a module to be tested, and determining verification requirements and verification strategies corresponding to the input parameters based on bus conversion bridge AMBA protocol interface specifications;

determining a target interface based on the verification requirement and the verification strategy, and establishing constraint excitation corresponding to the target interface based on a UVM base class library;

and verifying the module to be tested based on a verification model and the constraint excitation, and outputting a verification result.

Further, the establishing of the constraint excitation corresponding to the target interface based on the UVM base class library includes:

based on the sequence classes in the UVM base class library, creating sequence items corresponding to all target interfaces;

generating the constrained excitation based on the sequence items.

Further, the verifying the module to be tested based on the verification model and the constraint excitation, and outputting a verification result, including:

inputting the constraint excitation into the verification model, and determining functions to be verified and verification sequences of the functions to be verified based on the sequence items in the constraint excitation;

and sequentially verifying the functions to be verified based on the sequence items and the verification sequence, and outputting the verification result to complete the verification of the module to be verified.

Further, the determining a target interface based on the verification requirement and the verification policy includes:

determining a function to be verified based on the verification requirement and the verification strategy;

determining a to-be-verified model based on the to-be-verified function;

and determining a bus interface between the standby verification model and the module to be tested as the target interface based on the standby verification model.

Further, the verifying the module to be tested based on the verification model and the constraint excitation, and outputting a 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 verification model to the module to be tested;

and sending the verification data to a scoring board, and obtaining a comparison result between the verification data of the scoring board and standard data in a reference model as the verification result.

Further, the sampling, based on the monitor, the verification data of the verification model to the module under test includes:

collecting code coverage and function coverage of constraint excitations in the verification model based on the monitor;

determining a target coverage rate based on the code coverage rate and the function coverage rate;

and when the target coverage rate reaches a preset coverage rate, taking the current sampling data as the verification data.

Further, after determining the target coverage based on the code coverage and the function coverage, the method further includes:

when the target coverage rate does not reach the preset coverage rate, modifying the constraint excitation to determine a test blind area;

and establishing iteration constraint excitation based on the test blind area, verifying the model to be tested based on the iteration constraint excitation, obtaining the current sampling data and the target coverage rate until the target coverage rate reaches the preset coverage rate, and taking the current sampling data as the verification data.

In addition, to achieve the above object, the present invention further provides a UVM-based bus conversion bridge verification apparatus, including: the verification requirement determining module is used for acquiring input parameters of the module to be tested and determining verification requirements and verification strategies corresponding to the input parameters based on bus conversion bridge AMBA protocol interface specifications; the constraint excitation establishing module is used for determining a target interface based on the verification requirement and the verification strategy and establishing constraint excitation corresponding to the target interface based on a UVM base class library; and the verification result output module is used for verifying the module to be tested based on a verification model and the constraint excitation and outputting a verification result.

In addition, to achieve the above object, the present invention further provides a UVM-based bus conversion bridge verification apparatus, which includes a processor, a memory, and a UVM-based bus conversion bridge verification program stored on the memory and executable by the processor, wherein the UVM-based bus conversion bridge verification program, when executed by the processor, implements the steps of the UVM-based bus conversion bridge verification method as described above.

In addition, to achieve the above object, the present invention further provides a computer readable storage medium having a UVM-based bus conversion bridge verification program stored thereon, wherein the UVM-based bus conversion bridge verification program, when executed by a processor, implements the steps of the UVM-based bus conversion bridge verification method as described above.

The invention provides a bus conversion bridge verification method based on UVM, which comprises the steps of obtaining input parameters of a module to be tested, and determining verification requirements and verification strategies corresponding to the input parameters based on AMBA protocol interface specifications of a bus conversion bridge; determining a target interface based on the verification requirement and the verification strategy, and establishing constraint excitation corresponding to the target interface based on a UVM base class library; and verifying the module to be tested based on a verification model and the constraint excitation, and outputting a verification result. Through the mode, the corresponding verification requirements and the verification strategies are determined through analysis of the input parameters, so that the verification models needed to be used are determined, the corresponding verification models are connected through the target interfaces, the corresponding constraint excitation is generated, the module to be tested is subjected to verification test, and the verification result is obtained. Through the bus conversion bridge verification method based on the UVM, the reusability of the system and the automation degree of the establishment of the verification platform can be improved, the work efficiency of verification is improved, and the technical problem that the work efficiency of the existing verification platform is low is solved.

Drawings

Fig. 1 is a schematic hardware structure diagram of a UVM-based bus conversion bridge verification device according to an embodiment of the present invention;

FIG. 2 is a flowchart illustrating a first embodiment of a UVM-based bus transfer bridge verification method according to the present invention;

FIG. 3 is a standardized Agent template proposed in the present embodiment;

FIG. 4 is a flowchart illustrating a UVM-based bus transfer bridge verification method according to a second embodiment of the present invention;

FIG. 5 is a schematic structural diagram of a reusable verification platform according to the present invention;

FIG. 6 is a flowchart illustrating a UVM-based bus transfer bridge verification method according to a third embodiment of the present invention;

FIG. 7 is a schematic diagram illustrating an application flow of a UVM-based bus transfer bridge verification platform according to the present invention;

fig. 8 is a functional block diagram of a UVM-based bus conversion bridge verification apparatus according to a first embodiment of the present invention.

The implementation, functional features and advantages of the objects of the present invention will be further explained with reference to the accompanying drawings.

Detailed Description

It should be understood that the specific embodiments described herein are merely illustrative of the invention and do not limit the invention.

The bus conversion bridge verification method based on the UVM is mainly applied to bus conversion bridge verification equipment based on the UVM, and the bus conversion bridge verification equipment based on the UVM can be equipment with display and processing functions, such as a PC (personal computer), a portable computer, a mobile terminal and the like.

Referring to fig. 1, fig. 1 is a schematic diagram of a hardware structure of a UVM-based bus conversion bridge verification apparatus according to an embodiment of the present invention. In an embodiment of the present invention, the UVM-based bus conversion bridge authentication apparatus 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 for implementing connection communication among the components; the user interface 1003 may include a Display screen (Display), an input unit such as a Keyboard (Keyboard); the network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface); the memory 1005 may be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as a disk memory, and the memory 1005 may optionally be a storage device separate from the processor 1001.

Those skilled in the art will appreciate that the hardware configuration shown in fig. 1 does not constitute a limitation of the UVM-based bus conversion bridge validation apparatus, and may include more or fewer components than those shown, or some components in combination, or a different arrangement of components.

With continued reference to fig. 1, the memory 1005 of fig. 1, which is a type of computer-readable storage medium, may include an operating system, a network communication module, and a UVM-based bus conversion bridge authentication program.

In fig. 1, the network communication module is mainly used for connecting to a server and performing data communication with the server; the processor 1001 may call a UVM-based bus conversion bridge verification program stored in the memory 1005, and execute the UVM-based bus conversion bridge verification method according to the embodiment of the present invention.

The embodiment of the invention provides a bus conversion bridge verification method based on UVM.

Referring to fig. 2, fig. 2 is a flowchart illustrating a bus translation bridge verification method based on UVM according to a first embodiment of the present invention.

In this embodiment, the UVM-based bus conversion bridge verification method includes the following steps:

step S10, acquiring input parameters of a module to be tested, and determining verification requirements and verification strategies corresponding to the input parameters based on bus conversion bridge AMBA protocol interface specifications;

in this embodiment, a UVM verification-based target, an overall verification requirement, and a verification policy are provided by studying a mechanism of reducing the bus bandwidth occupied by an AMBA-series bus conversion bridge, a bus conversion bridge design principle, and an AMBA port protocol interface specification.

Specifically, the AMBA bus protocol is a set of interconnect specifications provided by ARM that standardizes the chip communication mechanism between various IPs. These designs typically have one or more microprocessors and integrate other components-internal or external memory bridges, DSPs, DMAs, accelerators and various other peripherals like USB, UART, PCIE, I2C, etc. The primary purpose of the AMBA agreement is to reuse these IPs across multiple designs in a standard and efficient way.

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

in this embodiment, the timing sequence of the bus interface signals on both sides of the bus bridge is adjusted to meet the timing sequence specification of the corresponding bus standard, so that data exchange and mutual communication between different buses can be performed more smoothly. The operation process of the whole verification platform is designed into different stages, and each stage is guaranteed to do specific things at specific time, so that the efficiency is improved. Through the design of Sequence, the generation of the incentive information is completely separated from other parts, and the flexibility of data stream generation is increased.

In the embodiment, in order to improve reusability of the UVM platform, a UVM verification platform based on a hierarchical structure is developed, which includes a factor mechanism, a callback mechanism, and a sequence mechanism.

The factor mechanism is used for registering the extension class in a factory, so that the creation of an environment internal component and the overloading of an object can be realized. The factory mechanism is primarily directed to the uvm _ component and its subclasses that make up the verification environment hierarchy, and the uvm _ object and its subclasses that make up the environment configuration attributes and data transfers.

The Callback mechanism improves code reusability and is also used for constructing abnormal test cases. If two items are made using callback functions at different places, and the same place is written as a complete env, the relevant callback function env can be completely reused by changing the same.

The Sequence mechanism is a mechanism for controlling and generating a series of stimuli, and sending the stimuli to the driver through the Sequence. Sequence is a process of generating and transmitting data.

Specifically, the universal class library of the UVM is utilized to write components to simulate the behaviors of a host terminal and a slave terminal on an AMBA series bus verification platform, the environment of the verification platform is dynamically configured to meet different verification requirements, constrained random excitation is generated, and an interface is reserved to facilitate the expansion of the functions of the verification platform. The method comprises the steps of generating excitation transactions through sequence classes in a UVM base class library, respectively creating sequence items for corresponding interfaces, adding constraint randomized excitation in the sequence classes, such as write address and control information, burst type, burst length, protection type and the like, so that whether functions of a DUT (Design Under Test) to be tested are defective or not can be comprehensively verified, special conditions that verification personnel cannot consider are made up, and comprehensive verification is achieved quickly.

The sequence item is the minimum granularity content of each driver interacting with the DUT, and can only encapsulate data without an automatically executed function. The sequence object itself generates a target number of sequence item objects. By means of the randomization of the SV and the support of the randomization by the sequence item, the data content in each generated sequence item object is different. The generated sequence item will go through the sequence and flow to the driver. And the driver obtains each sequence item, and writes the data into the interface according to a physical interface protocol of the DUT after data analysis so as to form effective excitation on the DUT.

As shown in fig. 3, fig. 3 is a standardized Agent template according to the embodiment.

In this embodiment, the standardized Agent template is a Cag (common Agent) template, covers all the components of the Agent, and automatically adjusts the call and connection of internal components according to different work _ mode configurations. The method comprises the following steps:

(1) Cg _ driver.sv and Cag _ driver _ cfg.sv

A module for generating time sequence excitation in a Master mode, and acquiring an interface transmitted by an external verification environment in the built _ phase; the function of acquiring the traffic from the sequence and driving to the interface is realized in main _ phase. Reserving a callback function interface, a dynamic reset function, an IDLE state random function and a read-write operation task template.

Sv file is a control file corresponding to a driver, and can be used to specify some configuration values related to the driver, for example: random pattern, random weight, backpressure pattern, whether read data is held when read is invalid, etc.

Note: the value of Cfg should be recursively taken from the upper Cfg file, i.e. driver _ Cfg should be from agent _ Cfg, and agent _ Cfg should be from env _ Cfg.

(2) Cag _ slave _ driver.sv and Cag _ slave _ driver.sv

And the module for generating response to the input excitation in the Slave mode has similar internal functions as the cag _ driver.

The main _ task in the Slave _ driver has two triggering modes: 1. generating a trasaction by using a sequence mechanism, assigning a value to the trasaction under a specific condition and driving the value to an interface;2. a resident loop process is started in run _ phase, and is directly driven to interface whenever a specific condition is met. If the method 2 is adopted, there are two starting methods for the slave _ sequence: (1) sv automatically starts the slave sequence by default in run _ phase of cag _ interface _ agent. (2) Manually initiated by the user at the appropriate location of his sequence _ lib/testcase/environent.

(3) Cg _ monitor.sv, cag _ monitor _ cfg.sv and Cag _ monitor _ cov.sv

The pure monitor sampling module is enabled in each working mode, samples from the interface, packages into a trace, and sends out from the out _ port. (out _ port is typically connected to RM or CHECKER in the environment)

Sv is the complete set of all interface class function coverage models involved in the AGENT, and is used for assisting the user to measure the excitation completeness.

(4)Cag_interface.sv

The agent includes three clockking blocks and three modports for all input/output interfaces of the agent. The method respectively corresponds to a master (including reg _ master), a slave and a monitor. Note that: the same signal has different directions in three clockking blocks, taking Paddr of the APB interface as an example, output should be in drv _ cb, input should be in slv _ cb, and all signals in mon _ cb should be input.

(5)Cag_xaction.sv

Is the specific uvm sequence item in the agent. Note that there is no absolute one-to-one correspondence between members in the cag _ dictionary and members in the cag _ interface.

(6) Cg _ sequence _ lib.sv and Cag _ sequence

Sv is provided with base _ sequence base class of the agent, and sequence branch under various types of modes (e.g. master _ sequence/slave _ sequence, etc.). At the same time, should provide quick operation of task encapsulation for user's convenience (e.g. the apb-agent should provide apb _ write and apb _ read functions)

(7) Sg _ agent.sv and Cag _ agent _ cfg.sv

The top level of the Cag _ agent, where the aforementioned components are declared, instantiated, connected according to the function switch. When the user uses the agent, the user only needs to instantiate the agent. Cfg is its corresponding configuration file.

(8)Cag_agent_dec.sv

The delete file of the agent, wherein the name, define, typedef, struct, etc. related to the agent are defined.

(9)Cag_reg_adapter.sv

And the bus switching unit is only enabled in the reg _ master mode and is used for connecting the reg _ model and the agent and converting uvm _ reg _ bus _ op in the reg _ model and trace in the agent into each other.

(10)Cag.f

File list, which the user needs to add to his env.f.

And S30, verifying the module to be tested based on a verification model and the constraint excitation, and outputting a verification result.

In this embodiment, the stimuli added in Sequence are called in the UVM Sequence as a whole, the UVM Sequence is sent to the UVM Driver in a transaction communication manner according to the requirement of the Driver, the Driver converts the abstract stimulus transaction into a stimulus at a signal level that can be recognized by the DUT interface, so as to drive the DUT, and at the same time, a Monitor is created at each DUT to collect coverage rate data and convert the coverage rate data into an abstract transaction to be sent back to the user.

The embodiment provides a bus conversion bridge verification method based on UVM, which comprises the steps of obtaining input parameters of a module to be tested, and determining verification requirements and verification strategies corresponding to the input parameters based on AMBA protocol interface specifications of a bus conversion bridge; determining a target interface based on the verification requirement and the verification strategy, and establishing constraint excitation corresponding to the target interface based on a UVM base class library; and verifying the module to be tested based on a verification model and the constraint excitation, and outputting a verification result. Through the mode, the corresponding verification requirements and the verification strategies are determined through analysis of the input parameters, so that the verification models needed to be used are determined, the corresponding verification models are connected through the target interface, the corresponding constraint excitation is generated, the module to be tested is subjected to verification test, and the verification result is obtained. Through the bus conversion bridge verification method based on the UVM, the reusability of the system and the automation degree of the verification platform building can be improved, the work efficiency of verification is improved, and the technical problem that the work efficiency of the existing verification platform is low is solved.

Referring to fig. 4, fig. 4 is a flowchart illustrating a bus translation bridge verification method based on UVM according to a second embodiment of the present invention.

Based on the foregoing embodiment shown in fig. 2, in this embodiment, the step S20 specifically includes:

step S21, based on the sequence class in the UVM base class library, creating a sequence item corresponding to each target interface;

and S22, generating the constraint excitation based on the sequence items.

In this embodiment, there are three interfaces in total in the AMBA protocol conversion bridge design, where the AHB and AXI interfaces are host interfaces, and therefore, a randomized excitation transaction needs to be added to the two interfaces to simulate the transmission of a data stream. The generation of the excitation transaction is realized through sequence classes in a UVM SystemVerilog base class library, sequence items are respectively created for corresponding interfaces, constraint randomized excitation is added in the sequence classes, such as write address and control information, burst type, burst length, protection type and the like can be randomized, so that whether the function of the DUT is defective or not can be comprehensively verified, special conditions which cannot be considered by a verifier are made up, and the comprehensive verification degree can be quickly achieved.

Further, based on the embodiment shown in fig. 2, in this embodiment, the step S30 specifically includes:

and sequentially verifying each function to be verified based on the sequence item and the verification sequence, and outputting the verification result to complete the verification of the module to be tested.

In this embodiment, the UVM divides the operation process of the entire verification platform into different stages, so as to ensure that a specific event is done at a specific time, thereby improving efficiency. The concept of Sequence also fully follows this principle. It completely separates the generation of data stream (excitation information) from other parts, thereby improving the reusability of other parts and increasing the flexibility of data stream generation. After the data stream is generated, it needs to be sent to the driver and then to the DUT, so the sequencer needs to provide an interface to convert the upper layer stimulus configuration scenario into the required transaction stimulus and send it to the driver, communicating through the TLM port connection driver.

Further, based on the embodiment shown in fig. 2, in this embodiment, the step S20 specifically includes:

determining a function to be verified based on the verification requirement and the verification policy;

determining a to-be-verified model based on the to-be-verified function;

In this embodiment, the UVM is based on the simulation of the abstract transaction in the entire verification platform, so that the signal is classified, divided, and directed to the signal interface of the corresponding DUT. These are all realized through the systemverilog syntax, thus also reflecting the high efficiency and reusability of building the UVM verification platform. The packing of the signal is realized by the interface key in the systemverilog. The binding of the signals is achieved through the bind key.

The interfaces are divided into two types, wherein one type is a data structure for packing signals to operate actually, the other type is a virtual interface, and the system mveriolog code and verilog code are mainly connected and communicated with each other, because excitation is added in the task in the system mveriolog, and correct connection is realized. The verification of the AMBA protocol conversion bridge based on the UVM only needs to instantiate an interface, and if the interface is pointed to different DUT sub-modules, the interface is instantiated into the different DUT sub-modules, so that the operation is very convenient, a large amount of work is saved, and the reusability of the building of the UVM verification platform is well reflected.

Referring to fig. 5, fig. 5 is a schematic structural diagram of a reusable verification platform according to the present invention.

In this embodiment, the reusable verification platform may include UVM verification component level reuse, module level reuse, functional level reuse, and transaction level reuse.

The verification component level comprises a perfect test excitation library and is generated in real time according to the environment configuration or the established constraint of the transmission sequence; the module level reuse is mainly put on the reuse of basic functions apart from the protocol content, and the function level reuse mainly comprises the conversion among various protocols or the sending and receiving of data and protocols, including an address mapping conversion function and a task function for driving address transmission, a common function and a task function library; transaction-level reuse uses the basic contents such as packet types, data transmission formats and the like to be defined by the contents of a general protocol, and uses the definitions of parent classes and function functions to be repeated by inheriting and modifying the contents in a common library for similar design of the protocol.

Referring to fig. 6 and 7, fig. 6 is a flowchart illustrating a UVM-based bus conversion bridge verification method according to a third embodiment of the present invention; fig. 7 is a schematic application flow diagram of the UVM-based bus conversion bridge verification platform according to the present invention.

Based on the embodiment shown in fig. 2, in this embodiment, the step S30 specifically further includes:

step S31, establishing a monitoring interface, and connecting a monitor and the verification model based on the monitoring interface;

step S32, based on the monitor, sampling the verification data of the verification model to the module to be tested;

and S33, sending the verification data to a scoring board, and obtaining a comparison result between the verification data of the scoring board and standard data in a reference model as the verification result.

In this embodiment, the UVM method supports an automatic monitoring module, and the automatic monitoring module mainly implements the reference model module and the scoreboard to cooperate to implement the comparison verification, thereby ensuring the correctness of the verification. And further optimizing the verification platform by combining a System verilog high-level verification language, perfecting a debugging mechanism, realizing the verification of the multiplexing of the AMBA series bus and the bus conversion bridge in the SOC design, and generating the excitation which a verifier wants to obtain by adopting a bus function model.

In the specific embodiment, according to verification requirements, a SystemVerilog writing constraint randomized test case is adopted to generate a large number of randomized stimuli to three interfaces of AHB, AXI and APB, a CoverageGroup is written to collect coverage rate data, and coverage rate information of functional points on the three interfaces is collected. And finally, adopting a direct test case to cover the boundary condition for the functional points which cannot be covered so as to improve the coverage rate.

In a specific embodiment, the stimulus transaction from sequence is driven to the DUT input via Driver on the one hand and also to the reference model via Driver on the other hand. The reference model is the key and core of the entire UVM verification platform because it does work in line with the DUT, and the Scoreboard will compare its output with the DUT, and if the reference model is faulty, its output is also untrusted, and thus Scoreboard is also untrusted. And the Scoreboard is mainly used for comparing whether the data output by the reference model is consistent with the DUT or not and giving a comparison result.

Based on the foregoing embodiment shown in fig. 6, in this embodiment, the step S32 specifically includes:

and creating iteration constraint excitation based on the test blind area, verifying the model to be tested based on the iteration constraint excitation, obtaining the current sampling data and the target coverage rate until the target coverage rate reaches the preset coverage rate, and taking the current sampling data as the verification data.

In this embodiment, the coverage rate technology is an important index for measuring the verification progress and the verification work completion degree, and the research coverage rate-driven verification technology includes two types, namely code coverage rate and function coverage rate.

Wherein the code coverage rate comprises a row coverage rate, a state machine coverage rate, a branch coverage rate, a condition coverage rate and a path coverage rate. The simulation tool will automatically extract code coverage from the design code.

Functional coverage is divided into two categories: and the coverage rate facing the data is obtained by writing a coverage group, a coverage point and cross coverage on the processed data combination check. Control oriented coverage, check if a sequence of actions has occurred.

"coverage" is a general term to measure how well a design verification is completed. As the test gradually covers various reasonable combinations, the simulation process slowly delineates the situation of the design. The coverage rate tool will collect information in the simulation engineering, then carry on the subsequent processing and get the coverage rate report, find out the blind area on the coverage through this coverage rate report, then further modify the existing test excitation, or create new test to fill up these blind areas. This process is iterated until the coverage reaches a preset criterion.

In addition, the embodiment of the invention also provides a bus conversion bridge verification device based on the UVM.

Referring to fig. 8, fig. 8 is a schematic functional block diagram of a UVM-based bus conversion bridge verification apparatus according to a first embodiment of the present invention.

In this embodiment, the UVM-based bus conversion bridge verification apparatus includes:

the verification requirement determining module 10 is configured to obtain an input parameter of a module to be tested, and determine a verification requirement and a verification policy corresponding to the input parameter based on a bus conversion bridge AMBA protocol interface specification;

a constraint incentive establishing module 20, configured to determine a target interface based on the verification requirement and the verification policy, and establish a constraint incentive corresponding to the target interface based on a UVM base class library;

and the verification result output module 30 is used for verifying the module to be tested based on the verification model and the constraint excitation and outputting a verification result.

Further, the constraint excitation establishing module 20 specifically includes:

the sequence item creating unit is used for creating sequence items corresponding to all target interfaces based on the sequence classes in the UVM base class library;

and the constraint excitation generating unit is used for generating the constraint excitation based on the sequence items.

Further, the verification result output module 30 specifically includes:

a to-be-verified function determination first unit, configured to input the constraint excitation into the verification model, and determine, based on the sequence items in the constraint excitation, a to-be-verified function and a verification order of each to-be-verified function;

and the verification result output unit is used for sequentially verifying the functions to be verified based on the sequence items and the verification sequence and outputting the verification result so as to complete the verification of the module to be verified.

Further, the constraint excitation establishing module 20 specifically further includes:

a second unit for determining a function to be verified, configured to determine the function to be verified based on the verification requirement and the verification policy;

the standby verification model determining unit is used for determining a standby verification model based on the function to be verified;

and the target interface determining unit is used for determining a bus interface between the standby verification model and the module to be tested as the target interface based on the standby verification model.

Further, the verification result output module 30 specifically further includes:

the monitoring interface creating unit is used for creating a monitoring interface and connecting a monitor and the verification model based on the monitoring interface;

the verification data acquisition unit is used for sampling the verification data of the verification model to the module to be tested based on the monitor;

and the verification result obtaining unit is used for sending the verification data to a scoring board and obtaining a comparison result between the verification data of the scoring board and standard data in a reference model as the verification result.

Further, the verification data acquisition unit specifically includes:

a coverage rate collecting subunit, configured to collect, based on the monitor, code coverage rates and function coverage rates of constraint excitations in the verification model;

a target coverage determination subunit configured to determine a target coverage based on the code coverage and the function coverage;

and the verification data determining subunit is used for taking the current sampling data as the verification data when the target coverage rate reaches a preset coverage rate.

Further, the verification result output module 30 further includes a coverage iteration unit, which specifically includes:

a test blind area determining subunit, configured to modify the constraint excitation to determine a test blind area when the target coverage does not reach the preset coverage;

and the coverage rate iteration subunit is used for creating iteration constraint excitation based on the test blind area, verifying the model to be tested based on the iteration constraint excitation, obtaining the current sampling data and the target coverage rate until the target coverage rate reaches the preset coverage rate, and taking the current sampling data as the verification data.

Each module in the UVM-based bus conversion bridge verification apparatus corresponds to each step in the UVM-based bus conversion bridge verification method embodiment, and functions and implementation processes thereof are not described in detail herein.

In addition, the embodiment of the invention also provides a computer readable storage medium.

The computer readable storage medium of the present invention stores a UVM-based bus conversion bridge verification program, wherein the UVM-based bus conversion bridge verification program, when executed by a processor, implements the steps of the UVM-based bus conversion bridge verification method as described above.

The method implemented when the UVM-based bus conversion bridge verification program is executed may refer to various embodiments of the UVM-based bus conversion bridge verification method of the present invention, and details thereof are not repeated herein.

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or system. Without further limitation, an element defined by the phrases "comprising one of 8230; \8230;" 8230; "does not exclude the presence of additional like elements in a process, method, article, or system that comprises the element.

The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.

The application is operational with numerous general purpose or special purpose computing system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet-type devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. The application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) as described above and includes instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, an air conditioner, or a network device) to execute the method according to the embodiments of the present invention.

The above description is only a preferred embodiment of the present invention, and not intended to limit the scope of the present invention, and all modifications of equivalent structures and equivalent processes, which are made by using the contents of the present specification and the accompanying drawings, or directly or indirectly applied to other related technical fields, are included in the scope of the present invention.

Claims

1. A UVM-based bus conversion bridge verification method is characterized by comprising the following steps:

2. The UVM-based bus conversion bridge verification method of claim 1, wherein establishing constraint incentives corresponding to the target interface based on the UVM base class library comprises:

generating the constrained excitation based on the sequence items.

3. The UVM-based bus conversion bridge verification method of claim 2, wherein the verifying the module under test based on the verification model and the constraint excitation and outputting a verification result comprises:

4. The UVM-based bus conversion bridge validation method of claim 1, wherein the determining a target interface based on the validation requirement and the validation policy comprises:

determining a to-be-verified model based on the to-be-verified function;

5. The UVM-based bus conversion bridge verification method of claim 1, wherein the module under test is verified based on the verification model and the constraint excitation, and a verification result is output, and further comprising:

6. The UVM-based bus conversion bridge verification method of claim 5, wherein the sampling verification data of the verification model for the module under test based on the monitor comprises:

7. The UVM-based bus conversion bridge validation method of claim 6, wherein after determining a target coverage based on the code coverage and the functional coverage, further comprising:

8. A UVM-based bus conversion bridge validation apparatus, comprising:

the verification requirement determining module is used for acquiring input parameters of the module to be tested and determining verification requirements and verification strategies corresponding to the input parameters based on bus conversion bridge AMBA protocol interface specifications;

the constraint excitation establishing module is used for determining a target interface based on the verification requirement and the verification strategy and establishing constraint excitation corresponding to the target interface based on a UVM base class library;

and the verification result output module is used for verifying the module to be tested based on a verification model and the constraint excitation and outputting a verification result.

9. A UVM-based bus translation bridge verification device, comprising a processor, a memory, and a UVM-based bus translation bridge verification program stored on the memory and executable by the processor, wherein the UVM-based bus translation bridge verification program, when executed by the processor, implements the steps of the UVM-based bus translation bridge verification method of any of claims 1 to 7.

10. A computer readable storage medium having a UVM based bus conversion bridge verification program stored thereon, wherein the UVM based bus conversion bridge verification program, when executed by a processor, performs the steps of the UVM based bus conversion bridge verification method of any one of claims 1 to 7.