CN118052196A

CN118052196A - Chip verification test method and device based on UVM and electronic equipment

Info

Publication number: CN118052196A
Application number: CN202410209159.8A
Authority: CN
Inventors: 倪园慧; 刘光宇; 马盼; 林子明
Original assignee: CRSC Research and Design Institute Group Co Ltd
Current assignee: CRSC Research and Design Institute Group Co Ltd
Priority date: 2024-02-26
Filing date: 2024-02-26
Publication date: 2024-05-17

Abstract

The invention discloses a chip verification test method and device based on UVM and electronic equipment, and relates to the technical field of chip verification, comprising the following steps: calling and configuring an excitation component, a monitoring component, a reference model component and a score board component in UVM to construct a module-level verification model; performing module-level verification on the chip by using a module-level verification model; determining a target sub-component requiring vertical multiplexing from candidate sub-components included in a monitoring component, a reference model component and a scoreboard component of the module-level verification model; constructing a system level verification model by adopting a target sub-component; and carrying out system level verification on the chip by using a system level verification model. According to the scheme, the system-level verification model can be built by multiplexing the target sub-components which can be vertically multiplexed in the module-level verification model, so that configuration operations on the monitoring component, the reference model component and the score board component when the system-level verification model is built can be reduced, and the construction efficiency of the system-level verification model is improved.

Description

Chip verification test method and device based on UVM and electronic equipment

Technical Field

The present invention relates to the field of chip verification technologies, and in particular, to a chip verification test method and apparatus based on UVM, and an electronic device.

Background

The universal verification methodology (universal verification methodology, UVM) is a System Verilog language-based verification platform development framework with which reusable components can build a functional verification environment with standardized hierarchies and interfaces. UVM is a library in which classes (classes) are used to implement.

In the related art, a system-level verification model is constructed by calling and configuring an excitation component, a monitoring component, a reference model component and a score board component in UVM, so that the system-level verification model can be utilized to perform system-level verification on the chip.

The efficiency of constructing the system level verification model in the above manner is yet to be further improved.

Disclosure of Invention

The invention provides a chip verification test method and device based on UVM and electronic equipment, which are used for solving the problem that the efficiency of constructing a system-level verification model in the related technology needs to be further improved.

According to an aspect of the present invention, there is provided a UVM-based chip authentication test method, including:

Calling and configuring an excitation component, a monitoring component, a reference model component and a score board component in UVM to construct a module-level verification model; performing module-level verification on the chip by using the module-level verification model;

Determining a target sub-component requiring vertical multiplexing from candidate sub-components included in a monitoring component, a reference model component and a scoreboard component of the module-level verification model;

constructing a system level verification model by adopting the target sub-component;

And carrying out system-level verification on the chip by using the system-level verification model.

According to another aspect of the present invention, there is provided a UVM-based chip authentication test apparatus comprising:

The model building unit is used for calling and configuring an excitation component, a monitoring component, a reference model component and a score board component in the UVM to build a module level verification model;

the verification unit is used for carrying out module-level verification on the chip by utilizing the module-level verification model;

The model building unit is further used for determining a target sub-assembly needing to be vertically multiplexed from candidate sub-assemblies included in a monitoring assembly, a reference model assembly and a score board assembly of the module level verification model;

the model construction unit is further used for constructing a system-level verification model by adopting the target sub-component;

the verification unit is further used for performing system-level verification on the chip by using the system-level verification model.

According to another aspect of the present invention, there is provided an electronic apparatus including:

at least one processor; and

A memory communicatively coupled to the at least one processor; wherein,

The memory stores a computer program executable by the at least one processor to enable the at least one processor to perform the UVM based chip verification test method of any of the embodiments of the invention.

According to another aspect of the present invention, there is provided a computer readable storage medium storing computer instructions for causing a processor to implement the UVM based chip verification test method of any of the embodiments of the present invention when executed.

According to the technical scheme, the system-level verification model can be built through multiplexing the target sub-components which can be vertically multiplexed in the module-level verification model, so that configuration operations on the monitoring component, the reference model component and the score board component when the system-level verification model is built can be reduced, and the construction efficiency of the system-level verification model is improved.

It should be understood that the description in this section is not intended to identify key or critical features of the embodiments of the invention or to delineate the scope of the invention. Other features of the present invention will become apparent from the description that follows.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for the description of the embodiments will be briefly described below, and it is apparent that the drawings in the following description are only some embodiments of the present invention, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a flowchart of a chip verification test method based on UVM according to a first embodiment of the present invention;

Fig. 2 is a schematic diagram of a chip verification test method based on UVM according to a first embodiment of the present invention;

fig. 3 is a flowchart of a chip verification test method based on UVM according to a second embodiment of the present invention;

fig. 4 is a schematic structural diagram of a chip verification test device based on UVM according to a third embodiment of the present invention;

fig. 5 is a schematic structural diagram of an electronic device implementing a UVM-based chip verification test method according to an embodiment of the present invention.

Detailed Description

In order that those skilled in the art will better understand the present invention, a technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in which it is apparent that the described embodiments are only some embodiments of the present invention, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present invention without making any inventive effort, shall fall within the scope of the present invention.

It should be noted that the terms "target," "original," and the like in the description and claims of the present invention and the above-described drawings are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the invention described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

Example 1

Fig. 1 is a flowchart of a UVM-based chip verification test method according to a first embodiment of the present invention, which is applicable to a UVM-based chip verification scenario, and the method may be performed by an electronic device. As shown in fig. 1, the method includes:

Step 101, calling and configuring an excitation component, a monitoring component, a reference model component and a score board component in UVM to construct a module level verification model; and carrying out module-level verification on the chip by using a module-level verification model.

Specifically, referring to fig. 2, the authentication component in uvm includes: stimulus (incentive) components, monitor components, reference model (REFERENCE MODEL) components, score board (scoreboard) components, connect these components to a design under test (Device Under Test, DUT). These components communicate with the DUT at the pin (pin) level by driving and sampling DUT signals, and with the rest of the components in the UVM by passing transaction (transaction) objects. Wherein the stimulus component includes a driver component and a Sequencer component. The driver component retrieves the transfer transaction from the sequencer class and then converts it to apply various types of stimuli, such as normal stimuli, errant stimuli, etc., to the DUT at the interface (interface). The monitoring component is used for monitoring the interface data and the behavior of the DUT, and then whether the behavior of the DUT is correct or not can be judged according to the signal changes after the input and output signals of the DUT change. The stimulus component is responsible for translating data at the delivery transaction level into the interface (interface) level of the DUT and driving it to the DUT. The monitoring component is operative to observe the interface of the DUT and collect bus information and convert it into a transfer transaction for processing by subsequent components such as a reference model component, scoreboard component, etc. The reference model component is used to perform the same function as the DUT, corresponding to simulating the behavior of the DUT, with the expected result, its output being received by the sequencer component for comparison with the DUT output result, the complexity of which is determined by the DUT. The sequencer component is used for judging whether the behavior of the DUT accords with the expected behavior, comparing and reporting two paths of data, wherein one path of data is from the monitoring component, the other path of data is from the reference model component, and whether the results are consistent is checked. While for each interface, the UVM provides a agent component, which is a container class, for packaging the drive, monitor and sequencer components together, and other design-specific components in an environment (env) component, instantiated and configured by the top-level test component.

The flow before silicon is generally from chip definition to chip design stage to back end part, and the designer adopts the hierarchical division direction of the chip, and the hierarchical division can be generally divided into chip system level design, subsystem level design and module level design. The verification of the chip refers to the chip design, and the verification work is performed in a layering manner, and from the perspective of the chip design, the design team can be pushed to perform the layering design by decomposing the complex chip into modularized components. For the verification stage, when a verification person performs chip verification, it is clear which function points perform verification at a module level, which function points perform verification at a subsystem level, and which function points perform verification at a system level. Whether repeated verification is needed at different levels or not, and whether the completeness of verification can be ensured at each level or not. Corresponding to the design level, the verification level can also be divided into three types: chip system level verification, chip subsystem level verification, and module level verification. The chip subsystem level verification and the chip system level verification may be combined into a system level verification, so that the verification level may be divided into two types, a system level verification and a module level verification.

In particular, for module level verification, a module with independent functions should be built, and each module needs an independent development system, where the module may not only include a module of RTL level original code, but may be divided and combined according to a complete functional module, and may include multiple modules. The whole system or subsystem is composed of a plurality of module units with independent functions, such as a processor (CPU) mainly composed of units such as direct access memory (Direct Memory Access, DMA), cache (Cache), arithmetic Logic Unit (ALU), floating Point Unit (FPU) and Core0/Core1, etc., which have their own independent functions, in terms of technical details, the units (blocks or units) have their own independent clocks, timings, interfaces, specifications and back-end physical or constraint, etc., and these characteristics, all developers including design engineers, verification engineers and even back-end engineers need to follow, so the interfaces and functions at the module level are more stable than at the designer level, so the verification engineers can formulate the verification flow of the module for them, use randomized test stimulus and independent checking mechanisms, so that their functions can be verified more quickly, simply and more advanced to reduce the future error correction (debugs) work at a higher level. The module-level verification generally belongs to white box verification, and whether an interface or a specific function is changed along with the thought of the design, so that the verification requirement needs to be considered in cooperation with the division of hierarchical design, and the design work of a large-scale system is assisted jointly. The decision factors depending on which verified functional point is verified by the module level are as follows:

Verification of internal functions such as state machines; storage verification of internal data; a data packing function, a coding and decoding function; execution of the instruction; configuration of registers.

At the same time, it should be considered that the following functions cannot be verified at the module level, and require higher level subsystem level or system level verification:

interaction signals with other adjacent modules; interaction signals with other subsystems; interaction signals with the outside of the chip; and (5) verifying the power switch.

Once the module level verification is complete, after determining that the basic function of the module is correct, the verification engineer may continue with a higher level of verification that must confirm whether the connection to and from the module and the interface protocol are correct, i.e., whether the connection is properly implemented by the neighboring units included at the higher level. The completeness of the module level verification provides good debugging guarantee for higher level verification.

Step 102, determining a target sub-component requiring vertical reuse from candidate sub-components included in the monitoring component, the reference model component, and the scoreboard component of the module level verification model.

From the point of view of the design to be tested, the excitation and driving of the simple module is often the sub-module of the design to be tested from the upper and lower layers, without manual input. Thus, while multiplexing the verification model, neither the components related to test stimulus nor drive can be multiplexed, such as sequencer components, test cases (test cases), etc. In addition, when the design to be tested is changed from a simple Module to a complex Module or subsystem, both the Module name and interface signals of the RTL Module have changed, so the sim_top file of the Module-level verification model is not reusable. The remaining components and configuration of business functions (configuration), monitoring components, reference model components, score board components, and functional discover (functional discover), associated with the system level verification model, may all be reused. Thus, a target sub-component requiring vertical reuse may be determined from the candidate sub-components included in the monitoring component, reference model component, and scoreboard component of the module level verification model.

And 103, constructing a system level verification model by adopting the target sub-component.

Specifically, the incentive component, the monitoring component, the reference model component and the score board component in the UVM can be invoked and configured, and the target sub-components involved therein can be directly multiplexed to construct a system level verification model.

Optionally, if the system-level verification includes chip subsystem-level verification and chip system-level verification. Similarly, the incentive component, monitoring component, reference model component and scoreboard component in the UVM can be invoked and configured, and the target sub-components involved therein (which can be candidate sub-components determined to need to be vertically multiplexed from among the monitoring component, reference model component and scoreboard component of the module level verification model) can be directly multiplexed, thereby constructing the chip subsystem level verification model. The incentive component, monitoring component, reference model component and scoreboard component in the UVM can be invoked and configured, and the target sub-components involved therein (which can be either determined to be vertically multiplexed from the candidate sub-components comprised by the monitoring component, reference model component and scoreboard component of the module level verification model, or which can be determined to be vertically multiplexed from the candidate sub-components comprised by the monitoring component, reference model component and scoreboard component of the chip subsystem level verification model) can be directly multiplexed, thereby constructing the chip system level verification model.

Step 104, performing system-level verification on the chip by using the system-level verification model.

For chip subsystem level verification, a mature subsystem has complete functions to perform special tasks, and has a stable enough interface for integration at a higher layer. Compared with module level verification, the chip subsystem level has independent functions and interface time sequences, even protocols, such as the Cache module mentioned in the module level, and the Cache module can be further divided into an access storage unit module, a memory unit, a bus interception unit and the like, if the direct division of the functions of the Cache into the module level verification may be too complex, the Cache subsystem can be divided into the chip subsystem for verification at the moment, and the corresponding lower-level sub-module can be divided into the module verification. The subsystem layers are more closed and more stable than the modules, which facilitates the integration and relatively closed features so that we can get different subsystems from inside or outside the company, and qualified subsystems should include: design package, verification package, regression test table, coverage collection script and data, and complete documentation (design, verification, integration, backend).

The well-defined delivery and well-defined handling process may enhance self-confidence of the top-level integration while reducing some of the interface understanding ramifications and parameterization configuration issues that occur during the integration process. Reusable subsystem verification cycles mainly include regression test sets, document-clear specifications (including functional specifications and interface specifications), coverage entries (explicitly verified parts), and possible verification cases (those cases corresponding to the regression test sets). The clear specification of the document enables an integrated end verification engineer to know the level of the chip subsystem, and the verification condition also shows the range and depth of the chip subsystem level verification. The regression test set is used when the designer modifies the chip subsystem, in which case the verification team runs the test program in the regression test set, ensuring that such modifications and improvements to the chip subsystem layer do not cause any other problems to the chip subsystem. For verification alone, in addition to requiring adequate verification of functions within the verification, if parameters or compilation pre-processing (compiler directive) are required for the external interfaces of the chip subsystem, the verifier gives complete verification by analyzing these parameters and the different options of compilation pre-processing (thus possibly yielding unused hardware architecture functions). From the standpoint of the closeness and reusability of the chip subsystems, they can be used in multiple chip projects, which is a good thing for design reuse, and verification also requires parameterizing the verification environment to accommodate the parameterized configuration of hardware. Only if the parameterization of the chip subsystem is verified sufficiently, the expected functions can be realized in different chip projects, the verification of the chip subsystem can be an ideal unit capable of being segmented for verification management, a plurality of modules below the layer can interact a lot, the layer tends to be closed, and the interface between the layer and the periphery is limited, so that the chip subsystem is convenient to set to a special verification group at the layer of the subsystem.

Wherein, for system-on-chip verification, the chip is composed of a plurality of modules and subsystems, and as a whole input document for verification, a chip specification document description has defined explicit interfaces and functions. The purpose of this level of verification is to ensure that the individual modules and subsystems that make up the system are properly connected, and that the design conforms to all interface protocols. In addition, some modules or sub-systems cannot verify at this level, for example, the reset operation (reset) of the chip needs to verify at the system level, and since the interface definition description of the chip itself is already fixed in the specification document and the function, the verification environment at the chip level is relatively stable and can provide a stable verification input for a verifier. In particular, the chip system level will not re-verify all corner functions once, while focusing on functions that cannot be verified by the module or subsystem, and the main functions, while ensuring that the module level verification is sufficient. The chip system level verification focuses on signal interaction among different subsystems and realizes use cases closer to actual scenes. The actual scenario use case herein does not necessarily refer to the software level of the system, but after the system software level is further divided into a plurality of modules to perform the interaction scenario, the separate test is performed. Because the system-on-chip scale is large, running a pass of verification takes a long time, the regression test time will be long, and because the path to be traced is multiplied, the system-on-chip verification must be based on the module level. In verification at the system-on-chip level, the reusability of the test is generally considered to be relatively high, mainly because: peripheral verification components need not be as numerous as module level or chip subsystem level and need to be updated frequently, they are mainly focused on verifying the input and output of the chip. Interaction and collaboration checking between subsystems inside the chip is mainly handed to the level of a processor and the subsystems of the chip, and starting from register checking and data checking, the use case of directional testing (DIRECTED TEST) is realized.

Multiplexing can enable verification personnel to utilize verification components and design modules of one or more chips in the system, the verification components are designed once and used for many times, and a built model is used for doing more important things, so that the verification team reduces the cost of repeated development, and more resources and efforts are used for realizing verification scenes and inspection. With the increase of the complexity of the chip, a complex device with hundreds of features is verified, and if the verification personnel overturns all the previous module level or chip subsystem level verification work and does not reuse the verification work, the waste of the existing resources is caused, so that the improvement of the verification efficiency is not facilitated. The easily reusable verification platform can reduce a large amount of repetitive work while supplementing the time for the verifier to build and check the test scene.

Multiplexing of the authentication platforms is divided into horizontal multiplexing, which refers to multiplexing between authentication components of the same hierarchy, and vertical multiplexing, which refers to multiplexing between cross hierarchies. The present invention is primarily directed to vertical multiplexing. Referring to the upper half of fig. 2, the chip is composed of a module a, a module B and a module C, and in the process of performing module-level verification, a verification platform needs to be built for the module a, the module B and the module C respectively, and 3 sets of verification platforms are correspondingly built. For example, the module a has a driver (a) which is specific to the module a and capable of generating stimulus, and can determine whether the behavior of the module a meets the expected scoreboard component scoreboard (a) according to the output of the module a, and transmit the collected output of the module a to the monitor component monitor (a) of the scoreboard component, where the model to be given by the verification platform is the reference model REFERENCE MODEL (a). There are also self-corresponding authentication components and platforms for modules B and C. Referring to the lower part of fig. 2, the system-level verification platform for the chip integrates the module a, the module B and the module C into a chip, and performs corresponding configuration for external input pins of the whole chip, so that signals inside the module a, the module B and the module C do not need to be focused, and many signals between the module a, the module B and the module C inside the chip are interconnected and embedded into internal signals, and when the whole chip-level verification is performed, the signals do not need to be configured like the module-level verification platform, and many of the signals are external signals of the module for the module-level verification platform, so that excitation needs to be considered. Corresponding verification components are provided for the chip, and the verification components can perform incomplete vertical multiplexing on the verification components from the module A, the module B or the module C of the lower-level module level, wherein the incomplete multiplexing refers to the existence of a reusable part and an unsuitable reusable part. A great difficulty in performing vertical multiplexing operations is that the requirements of the pumping elements at the module level are not consistent with those of the pumping elements at the top level, especially some of the pumping elements that require an initialisation transaction (as opposed to a reactor). Typically, a module-level verification environment would be more desirable to have a randomized stimulus component and a small control unit to achieve higher functional coverage. However, in higher level verification, the chip subsystem level and the chip system level, the verification engineer is more likely to be able to achieve randomization at a higher level. This means that within a module-level test platform, the stimulus component is more focused on randomization of individual transactions and randomly generates these transactions between the external interfaces of the modules under test. In the next layer, the excitation means need more control in generating the special sequence. This level of randomization extends through different transactions than the transactions themselves, in other words, it is desirable to build a randomized sequence that contains multiple stimulus component types, and thus it is desirable to be able to coordinate the capabilities of different stimulus components so that higher level sequences can be created, requiring a verification engineer to develop one stimulus component that can control any of the randomizations.

According to the technical scheme provided by the embodiment of the invention, the system-level verification model can be built by multiplexing the target sub-components which can be vertically multiplexed in the module-level verification model, so that configuration operations on the monitoring component, the reference model component and the score board component can be reduced when the system-level verification model is built, and the construction efficiency of the system-level verification model is improved.

Example two

Fig. 3 is a flowchart of a chip verification test method based on UVM according to a second embodiment of the present invention, in which steps 102 and 103 in the first embodiment are refined, common parameters for system level verification are obtained from a module level verification model, and features of the system level verification model are built according to the common parameters. As shown in fig. 3, the method includes:

Step 301, calling and configuring an excitation component, a monitoring component, a reference model component and a score board component in UVM to construct a module level verification model; and carrying out module-level verification on the chip by using a module-level verification model.

Step 301 is similar to the principle and implementation of step 101, and will not be described again.

Step 301 may be followed by step 302, step 303, step 304, step 305, step 306, or step 308.

Step 302, selecting a target function and an original assertion verification sub-component of the target function required by the system level verification model from original assertion verification sub-components of candidate functions included in a monitoring component, a reference model component and a scoreboard component of the module level verification model; the original assertion verification subcomponent of the target function is determined to be the target subcomponent.

Step 307 may be performed after step 302.

Wherein the assertion is good at presetting for a particular logic or timing, and a check report is given once the actual behavior of the design does not conform to the description of the assertion. Assertions are mainly used to examine the contents of a design, improve the visibility and debugging capabilities of the design, and examine whether design features are covered in the verification. The advantages of using assertions are mainly: the position of the assertion is closer to the position of the source code of the different functional points, so that the position of the error source can be positioned faster and more clearly when the corresponding checked functional point generates errors. For the assertion itself, the assertion can express a longer timing, which allows the assertion to describe the behavior of the design at a higher level of abstraction, while the assertion also has coverage, through which quantized data can be built to measure the progress of verification. On the other hand, an assertion can be put directly into a design, which allows the assertion to be multiplexed on different designs so that it has a stronger lifecycle and verification extension. From the perspective of reusability, assertions may enable vertical multiplexing from module-level verification to subsystem-level verification on chip to system-level verification on chip. This is because assertions express the property of logic that can be done wherever used, which is valid for a verification engineer, whether instantiated at the module level, the subsystem-on-chip level, or the system-on-chip level. While if multiple modules have assertions that are combined at the chip level, all assertions from all modules remain true. When using assertions in the module level, if a verification engineer can concatenate all modules through the assertions (vertical multiplex assertions), then the corresponding benefits from the protection measures of the assertions can also be obtained, as well as assisting in the debugging of test failures. For example, the assertions "data in and out" and "state machine" inserted from module a at module level verification may remain in a monitor check state under both the subsystem-on-chip and system-on-chip environments. This is due to the fact that assertions can be implanted into the system as non-comprehensive modules. In the chip subsystem, the integration of the subsystem of the new assertion section can in turn check the integration relationship between slave a and slave B to check that it can be preserved in the chip system.

Specifically, if the module-level verification model and the system-level verification model need to verify the same function, the original assertion verification sub-component corresponding to the function in the module-level verification model can be determined to be the target sub-component.

Step 303, if the candidate sub-components included in the monitoring component, the reference model component and the scoreboard component of the module level verification model include an original component closing switch; and the system level verification model requires the component to close the switch, the original component close switch is determined to be the target sub-component.

Step 307 may be performed after step 303.

Specifically, the component close switch is used for component close. Component shutdown here refers to: the monitoring component stops taking the number, the reference model component stops calculating, and the score board component stops comparing. When the switch is turned off at the original component of the system level verification multiplex module level verification model, the module level verification environment can be turned off by the switch. Because the end-to-end comparison is mainly done at the later stage of the simulation, or during the netlist simulation period, the comparison of the individual signals can be turned off.

Step 304, selecting target functions and macros of target functions required by the system level verification model from macros of candidate functions included in the monitoring component, the reference model component and the scoreboard component of the module level verification model; the macro of the target function is determined as a target sub-component.

Step 307 may be performed after step 304.

Macro (Marco) refers to the replacement of one or several lines of text code, i.e. a code segment created using defined compiler instructions. Once a macro has been defined, it can be used anywhere within the scope of the coding unit if desired. For software development, macros can reduce repetitive coding work, are easy to read, and are more beneficial to vertical multiplexing. The numerous macros provided by the UVM platform can hide many details, and the more integrated functions bring convenience to multiplexing work. Macros essentially consist of three parts, namely a name, some text and optional parameters. It may be invoked by the () character followed by the macro name. A macro may use parameter definitions. Parameters are useful for customizing macros that are to be widely used, such as a function/task. Such macro parameters may be defined using default values such that if the design verification engineer does not pass any particular values, the macro will be replaced with default values. In addition to the directly defined parameters mentioned above, the parameterized design can also be performed by means of macro definition.

Several notes about macro parameters: the parameters may have default values. The parameter may be skipped by leaving the position empty even though the position has no default value. If the parameter is a string, the decision whether the parameter needs to be bracketed in the double quotation marks depends on the substitution position of the parameter in the macro text. For example, in debug1 MODNAME is within the quotation marks in the macro text, so program-block does not include strings in quotation marks when invoking macros. Whereas the parameter passed by debug2 is "program-block" because MODNAME appears outside the quotation marks in the macro-text.

Specifically, if the module-level verification model and the system-level verification model need to verify the same function, a macro corresponding to the function in the module-level verification model may be determined as the target sub-component.

Step 305, obtaining original registers included in a monitoring component, a reference model component and a scoreboard component of the module level verification model; acquiring the value of the offset address parameter of the original register and the value of the back gate access path parameter; constructing a target register by adopting the value of the offset address parameter of the original register and the value of the back gate access path parameter; and determining the target register as a target subcomponent.

Step 307 may be performed after step 305.

The window of mutual conversation between the modules is a register, on one hand, the current condition of the design to be tested can be obtained by reading the state of the register, and on the other hand, the register can be made to work in a certain mode by configuring the register. In the process of constructing the verification model, verification of the register is always arranged in the front of a verification list, because each module is provided with a register configuration bus, and when the modules are integrated into one chip, each chip is provided with a configuration bus, and the configuration buses are respectively connected into each module after arbitration, so that the communication of semantic consistency among hardware can be ensured only if the correctness of the functions of the register is ensured. For register multiplexing, it is first necessary to move a portion of the bus agent (bus agent) from the environment into the base_test, and note that the bus agent here corresponds to an wrapper, and mainly includes a driver component, a sequencer component, and a monitor component. Corresponding to the bus agent is a register, each module having its own register in performing the module level verification. However, if context level multiplexing is implemented, it is not possible to instantiate registers in the context, because the offset addresses are different from each other for each register. If the registers are instantiated at the context level, the offset address cannot be specified in this case. Thus, in module level verification, registers need to be instantiated in the base case. A pointer to a register is set within the environment and needs to be assigned in the basic case. To be able to use the register in system level verification, a new register needs to be re-established, where the new register needs to be added to the registers of the different modules and set the offset address and the path of the back gate access.

Specifically, the value of the offset address parameter and the value of the back gate access path parameter of the original register in the module level verification model can be transmitted into the original register to obtain the target register.

The target subcomponent includes a config db mechanism for interface instantiation delivery, step 306.

Uvm tree-structured nodes often require high-level components to issue environmental parameters or to make changes to environmental patterns through configuration. For example, interface, which is often instantiated in the top, inputs different clock and reset signals, both driver and monitor in the environment require interface and DUT connections. After the interface is instantiated, the transfer is needed, and the transfer method is a config_db mechanism. The process of delivery is important in two ways: path and name. For paths, the parameters of config db are easier to vertically multiplex than directly de-assign in the form of an absolute path of uvm _test_top. The config db mechanism is divided into a set function and a get function, with four parameters in total. In the set function: ① The first two parameters together form the target path, which must be guaranteed to be correct. The first parameter is a pointer to the component instance and the second parameter is a path relative to the instance. ② The third parameter represents the name of the transfer process, which must be consistent with the get function. ③ The last parameter represents the variable that needs set. In the get function: ① The first two parameters together form the target path, which must be guaranteed to be correct. The first parameter is a pointer to the component instance and the second parameter is a path relative to the instance. If the first parameter is this, the second parameter is null. ② The third parameter, which represents the name of the transfer procedure, must be identical to that in the set function. ③ The last parameter represents the variable that requires get. When the set function and the get function perform vertical multiplexing operation, it is guaranteed that when config_db_set and config_db_get are called, the class where the target parameter is located is already over-coded by new (), and the target parameter can be accessed. Typically, config_db_set and config_db_get are performed at the UVM's configure_phase.

In step 307, a system level verification model is built using the target subcomponent.

Step 309 may be performed after step 307.

Step 307 is described in the above embodiments, and will not be described in detail.

Step 308, obtaining the public parameters of the system level verification from the module level verification model, and constructing the system level verification model according to the public parameters.

For introducing parameters in the verification environment, the structure and the data type can be adjusted more conveniently through parameter adjustment without modifying the definition inside the object, so that a plurality of parameters can be directly used by changing the data in the vertical multiplexing process. The tool finally forms a top-level module according to the design integration relationship, namely vertically integrates the modules into a chip top-level architecture, and the process comprises the instantiation of each module (module), the instantiation of an interface (interface), the instantiation of a program (program), the integration of layers, the calculation of parameters, the solution of layer signal reference, the establishment of module connection and the like. In the modeling phase, the parameter modification command options provided by the tool are modified. For example, in designing an interface, an interface with parameters is used herein. These parameters include, data bit width: data_width, addr_width, input_skuw, output_skuw, slider_num. In constructing the verification model, parameters used include: address bit width, data bit width, etc., to accommodate different systems. And the parameters common to a plurality of related components are placed in the same package (package) for convenient management.

For example, the specific definition is as follows:

Interface apb_if#(parameter DATA_WIDTH＝32,parameter ADDR_WIDTH＝32,

parameter INPUT_SKEW＝0,parameter OUTPUT_SKEW＝0,parameter SLAVER_NUM＝8)()；

These parameters are then used to declare variables. In this way it is ensured that the code is still available when the system data bus and the address bus change. The following applies:

The parameters data_width and addr_width are used because of the uncertainty of the DATA bit WIDTH and address bit WIDTH in the system. Whereas the INPUT_SKEW and OUTPUT_SKEW exist for post-simulation, simulations of setup time and hold time can be supported. SLVAER _NUM is mainly because the slave devices mounted on the master device are not fixed, depending on the system.

Specifically, if the module-level verification model and the system-level verification model use the same parameter, that is, the common parameter can be obtained from the module-level verification model and verified by the system-level verification model, and the common parameter is multiplexed when the system-level verification model is purchased.

Step 309, performing system level verification on the chip using the system level verification model.

Further, the vertical multiplexing granularity and the vertical multiplexing efficiency are in normal distribution, namely gaussian distribution, and the whole normal distribution curve is in a bell shape, and has low two ends and high middle. Wherein, the vertical multiplexing granularity refers to the division granularity of the code and the structure of the verification component. That is, the code and structure of the split verification component of the particular coarse granularity and the particular fine granularity may lead to a reduction in vertical multiplexing efficiency, and the scale selection of the optimal granularity should be the intermediate position. For the coarsest granularity, a large number of components that can be multiplexed are ignored, resulting in a reduction in the degree of vertical multiplexing, due to insufficient refinement. For fine granularity partitioning components, the scheduling overhead may also decrease the vertical multiplexing efficiency due to too fine granularity.

Example III

Fig. 4 is a schematic structural diagram of a chip verification test device based on UVM according to a third embodiment of the present invention. As shown in fig. 4, the apparatus 400 includes:

a model building unit 410 for invoking and configuring an incentive component, a monitoring component, a reference model component and a scoreboard component in the UVM to build a module level verification model;

A verification unit 420, configured to perform module level verification on the chip using a module level verification model;

the model building unit 410 is further configured to determine a target sub-component that needs to be vertically multiplexed from candidate sub-components included in the monitoring component, the reference model component, and the scoreboard component of the module level verification model;

a model construction unit 410 further configured to construct a system level verification model using the target subcomponent;

The verification unit 420 is further configured to perform system level verification on the chip using the system level verification model.

A model building unit 410, specifically configured to select a target function and an original assertion verification sub-component of the target function required by the system level verification model from original assertion verification sub-components of candidate functions included in a monitoring component, a reference model component, and a scoreboard component of the module level verification model;

the original assertion verification subcomponent of the target function is determined to be the target subcomponent.

The model building unit 410 is specifically configured to close the switch if the candidate sub-components included in the monitoring component, the reference model component, and the scoreboard component of the module level verification model include an original component; and the system level verification model requires the component to close the switch, the original component close switch is determined to be the target sub-component.

A model construction unit 410, specifically configured to select a target function and a macro of the target function required by the system level verification model from macros of candidate functions included in the monitoring component, the reference model component, and the scoreboard component of the module level verification model;

The macro of the target function is determined as a target sub-component.

The model building unit 410 is specifically configured to obtain original registers included in the monitoring component, the reference model component, and the scoreboard component of the module level verification model; acquiring the value of the offset address parameter of the original register and the value of the back gate access path parameter;

constructing a target register by adopting the value of the offset address parameter of the original register and the value of the back gate access path parameter; and determining the target register as a target subcomponent.

The model construction unit 410 is further configured to obtain common parameters with the system level verification from the module level verification model, and construct the system level verification model according to the common parameters.

In one implementation, the target subcomponent includes a config_db mechanism for interface instantiation delivery.

The chip verification test device based on the UVM provided by the embodiment of the invention can execute the chip verification test method based on the UVM provided by any embodiment of the invention, and has the corresponding functional modules and beneficial effects of executing the chip verification test method based on the UVM.

Example IV

Fig. 5 shows a schematic diagram of the structure of an electronic device 10 that may be used to implement an embodiment of the invention. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. Electronic equipment may also represent various forms of mobile devices, such as personal digital processing, cellular telephones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the inventions described and/or claimed herein.

As shown in fig. 5, the electronic device 10 includes at least one processor 11, and a memory, such as a Read Only Memory (ROM) 12, a Random Access Memory (RAM) 13, etc., communicatively connected to the at least one processor 11, in which the memory stores a computer program executable by the at least one processor, and the processor 11 may perform various appropriate actions and processes according to the computer program stored in the Read Only Memory (ROM) 12 or the computer program loaded from the storage unit 18 into the Random Access Memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 may also be stored. The processor 11, the ROM 12 and the RAM 13 are connected to each other via a bus 14. An input/output (I/O) interface 15 is also connected to bus 14.

Various components in the electronic device 10 are connected to the I/O interface 15, including: an input unit 16 such as a keyboard, a mouse, etc.; an output unit 17 such as various types of displays, speakers, and the like; a storage unit 18 such as a magnetic disk, an optical disk, or the like; and a communication unit 19 such as a network card, modem, wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information/data with other devices via a computer network, such as the internet, and/or various telecommunication networks.

The processor 11 may be a variety of general and/or special purpose processing components having processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various specialized Artificial Intelligence (AI) computing chips, various processors running machine learning model algorithms, digital Signal Processors (DSPs), and any suitable processor, controller, microcontroller, etc. The processor 11 performs the various methods and processes described above, such as the UVM-based chip authentication test method.

In some embodiments, any of the UVM based chip verification test methods described above may be implemented as a computer program tangibly embodied on a computer readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and/or installed onto the electronic device 10 via the ROM 12 and/or the communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of any of the UVM based chip verification test methods described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform any of the UVM-based chip verification test methods described above in any other suitable manner (e.g., by means of firmware).

Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuit systems, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), systems On Chip (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs, the one or more computer programs may be executed and/or interpreted on a programmable system including at least one programmable processor, which may be a special purpose or general-purpose programmable processor, that may receive data and instructions from, and transmit data and instructions to, a storage system, at least one input device, and at least one output device.

A computer program for carrying out methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the computer programs, when executed by the processor, cause the functions/acts specified in the flowchart and/or block diagram block or blocks to be implemented. The computer program may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of the present invention, a computer-readable storage medium may be a tangible medium that can contain, or store a computer program for use by or in connection with an instruction execution system, apparatus, or device. The computer readable storage medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. Alternatively, the computer readable storage medium may be a machine readable signal medium. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

To provide for interaction with a user, the systems and techniques described here can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) through which a user can provide input to the electronic device. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic input, speech input, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a background component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such background, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), blockchain networks, and the internet.

The computing system may include clients and servers. The client and server are typically remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, also called a cloud computing server or a cloud host, and is a host product in a cloud computing service system, so that the defects of high management difficulty and weak service expansibility in the traditional physical hosts and VPS service are overcome.

It should be appreciated that various forms of the flows shown above may be used to reorder, add, or delete steps. For example, the steps described in the present invention may be performed in parallel, sequentially, or in a different order, so long as the desired results of the technical solution of the present invention are achieved, and the present invention is not limited herein.

The above embodiments do not limit the scope of the present invention. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives are possible, depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of the present invention.

Claims

1. The chip verification test method based on UVM is characterized by comprising the following steps of:

2. The method of claim 1, wherein determining a target sub-component requiring vertical multiplexing from candidate sub-components included in a monitoring component, a reference model component, and a scoreboard component of a module level verification model comprises:

Selecting a target function and an original assertion verification sub-component of the target function required by the system level verification model from original assertion verification sub-components of candidate functions included in the monitoring component, the reference model component and the scoreboard component of the module level verification model;

3. The method of claim 1, wherein determining a target sub-component requiring vertical multiplexing from candidate sub-components included in a monitoring component, a reference model component, and a scoreboard component of a module level verification model comprises:

If the candidate sub-components included in the monitoring component, the reference model component and the score board component of the module level verification model comprise an original component closing switch; and the system level verification model requires the component to close the switch, the original component close switch is determined to be the target sub-component.

4. The method of claim 1, wherein determining a target sub-component requiring vertical multiplexing from candidate sub-components included in a monitoring component, a reference model component, and a scoreboard component of a module level verification model comprises:

Selecting a target function and a macro of the target function required by the system level verification model from macros of candidate functions included in the monitoring component, the reference model component and the scoreboard component of the module level verification model;

The macro of the target function is determined as a target sub-component.

5. The method of claim 1, wherein determining a target sub-component requiring vertical multiplexing from candidate sub-components included in a monitoring component, a reference model component, and a scoreboard component of a module level verification model comprises:

Acquiring original registers included in a monitoring component, a reference model component and a score board component of a module level verification model; acquiring the value of the offset address parameter of the original register and the value of the back gate access path parameter;

6. The method of claim 1, wherein the target subcomponent comprises a config db mechanism for interface instantiation delivery.

7. The method as recited in claim 1, further comprising:

and obtaining common parameters of the module-level verification model and the system-level verification, and constructing the system-level verification model according to the common parameters.

8. A UVM-based chip verification test device, comprising:

9. An electronic device, the electronic device comprising:

at least one processor; and

A memory communicatively coupled to the at least one processor; wherein,

The memory stores a computer program executable by the at least one processor to enable the at least one processor to perform the UVM based chip verification test method of any of claims 1-7.

10. A computer readable storage medium storing computer instructions for causing a processor to implement the UVM based chip verification test method of any of claims 1-7 when executed.