UVM-based chip verification method, device, equipment and storage medium

Abstract

The application is suitable for the field of electronic design automation, and provides a chip verification method, device and equipment based on UVM and a storage medium, wherein the method comprises the following steps: encapsulating hardware interface layer code related to low-level design under test in a test platform in a low-level verification environment into a packaging module; encapsulating entire UVM environment components used for verifying the low-level design under test into a UVM package, and setting environment starting code associated with the UVM package in the packaging module; in a high-level verification environment, binding the packaging module to a design under test instance corresponding to the low-level design under test in a high-level design under test; and instantiating the packaging module in a test platform under the high-level verification environment, accessing the UVM package by the environment starting code to construct a low-level UVM environment, and verifying the design under test instance. The scheme improves the reuse and ease of use of the verification environment, and reduces the additional coding and integration cost.

Description

Technical Field

[0001] This application belongs to the field of electronic design automation, and in particular relates to a chip verification method, apparatus, device and storage medium based on UVM. Background Technology

[0002] In existing UVM (Universal Verification Methodology) verification environments, high-level chip verification cannot directly reuse components from low-level verification environments, resulting in additional coding and integration costs. Summary of the Invention

[0003] This application provides a UVM-based chip verification method, apparatus, device, and storage medium to address the problem that high-level chip verification cannot directly reuse components from low-level verification environments, resulting in additional coding and integration costs.

[0004] The first aspect of this application provides a UVM-based chip verification method, including:

[0005] The hardware interface layer code related to the low-level design under test in the test platform under the low-level verification environment is encapsulated into a wrapper module; the wrapper module is used by the test platform under the high-level verification environment.

[0006] The entire UVM environment components used to verify the low-level design under test are encapsulated in a UVM package, and environment startup code associated with the UVM package is set in the package module;

[0007] In a high-level verification environment, the packaging module is bound to a design-under-test instance in the high-level design-under-test that corresponds to the low-level design-under-test.

[0008] The packaging module is instantiated on the test platform in the high-level verification environment. The environment startup code accesses the UVM package to build a low-level UVM environment to verify the design under test instance.

[0009] A second aspect of this application provides a UVM-based chip verification apparatus, comprising:

[0010] The first encapsulation module is used to encapsulate the hardware interface layer code related to the low-level design under test in the test platform under the low-level verification environment into a wrapper module; the wrapper module is used to be instantiated and used by the test platform under the high-level verification environment.

[0011] The second packaging module is used to encapsulate the entire UVM environment components used to verify the low-level design under test in a UVM package, and to set environment startup code associated with the UVM package in the packaging module;

[0012] The binding module is used to bind the packaging module to the design-under-test instance in the high-level design-under-test that corresponds to the low-level design-under-test in a high-level verification environment.

[0013] A building module is used to instantiate the packaging module on the test platform in the high-level verification environment. The environment startup code accesses the UVM package to build a low-level UVM environment to verify the design under test instance.

[0014] A third aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described in the first aspect.

[0015] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.

[0016] The fifth aspect of this application provides a computer program product including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in an electronic device, a processor in the electronic device performs the steps of the method described in the first aspect above.

[0017] In this embodiment of the application, the above-described solution encapsulates the hardware interface layer code related to the low-level design under test (DUT) in the test platform under the low-level verification environment into an independent packaging module. The entire UVM environment component used to verify the low-level DUT is encapsulated in a UVM package. Environment startup code associated with the UVM package is set in the packaging module. In the system-level verification environment, the packaging module is bound to the corresponding DUT instance. During verification simulation, the bound packaging module automatically creates its corresponding low-level UVM environment, effectively realizing the reuse of components in the low-level environment for simulation verification, improving the reusability and usability of the verification environment, and reducing additional coding and integration costs. Attached Figure Description

[0018] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiments below. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0019] Figure 1 This is a schematic diagram of the structure of a chip verification platform according to some embodiments of this application. Figure 1 ;

[0020] Figure 2 This is a schematic diagram of the structure of a chip verification platform according to some embodiments of this application. Figure 2 ;

[0021] Figure 3 This is a schematic diagram of the structure of a chip verification platform according to some embodiments of this application. Figure 3 ;

[0022] Figure 4 This is a schematic diagram of the structure of a chip verification platform according to some embodiments of this application. Figure 4 ;

[0023] Figure 5 This is a schematic diagram of the structure of a chip verification platform according to some embodiments of this application. Figure 5 ;

[0024] Figure 6 This is a flowchart of a UVM-based chip verification method according to some embodiments of this application;

[0025] Figure 7 This is a schematic diagram of the structure of a chip verification platform according to some embodiments of this application. Figure 6 ;

[0026] Figure 8 This is a schematic diagram of the structure of a chip verification platform according to some embodiments of this application. Figure 7 ;

[0027] Figure 9 These are structural diagrams of a UVM-based chip verification apparatus according to some embodiments of this application;

[0028] Figure 10 This is a structural diagram of the computer device provided in the embodiments of this application. Detailed Implementation

[0029] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0030] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0031] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0032] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0033] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0034] Before describing the solutions in this application, the terms used in the embodiments will be explained.

[0035] UVM is a standard, reusable verification methodology framework based on SystemVerilog, and it is the cornerstone of modern digital chip verification.

[0036] A DUT (Design Under Test) is a hardware design object that is being verified. It can be a module, a subsystem, or a complete chip.

[0037] TB (Testbench) is a complete simulation environment built to verify the DUT, including components such as stimulus generation and result checking.

[0038] SoC (System on Chip) integrates an entire electronic system onto a single chip, including a processor, memory, peripheral controllers, etc.

[0039] VIP (Verification Intellectual Property) is a pre-built, reusable verification component or environment, typically used to verify standard interfaces (such as USB, PCIe, AXI, etc.).

[0040] Unit-level testing (UT) is testing the most basic and smallest functional unit in a design, typically a submodule or a tightly coupled logic group (such as a state machine, an arithmetic logic unit, or a FIFO).

[0041] BT (block level test) is a test for a large functional module (composed of multiple units) and is a step in the verification process.

[0042] ST (System level test) is a test performed at the level of multiple modules, the entire chip, or a subsystem, designed to verify whether the integrated modules can work together.

[0043] CRG (Clock Reset Generator) is a component in the test platform used to generate and control clock and reset signals, and is the foundation for the normal operation of the simulation environment.

[0044] DDR (Double Data Rate Synchronous Dynamic Random Access Memory).

[0045] PCIe (Peripheral Component Interconnect Express).

[0046] UVM is the mainstream method for chip functional verification. Combined with... Figure 1 As shown, in the UVM-based verification framework, TB includes functions such as DUT instantiation and integration, CRG, VIP instantiation, and signal connection and driving.

[0047] In some implementations, TB starts the UVM environment through the system-level test function `run_test`, combined with... Figure 2 As shown, this UVM environment includes components such as uvm_test_top, uvm_env, uvm_agent, uvm_scoreboard, uvm_driver, uvm_monitor, and uvm_sequencer, forming a hierarchical structure to realize functions such as stimulus sending, scheduling, data collection and comparison.

[0048] Among them, uvm_test_top is the top-level component of UVM testing and also the starting point of testing. When run_test is called in TB, UVM will automatically create an instance of the corresponding type named uvm_test_top to configure the entire test environment, build the component topology, and specify the test scenario.

[0049] uvm_env is the environment component for UVM testing. As a container component, it is used to organize multiple related components in the verification platform together to form a reusable subsystem.

[0050] uvm_agent is the proxy component for UVM testing, which encapsulates the three components that interact with the DUT's specific interface: Driver, Monitor, and Sequencer.

[0051] uvm_scoreboard is the scoreboard component for UVM testing, used to check the correctness of the DUT behavior.

[0052] uvm_driver is the driver component for UVM testing. It is a component that interacts directly with the DUT. It is responsible for converting transaction-level stimuli into signal-level waveforms and driving them to the DUT's interface.

[0053] uvm_monitor is the monitor component for UVM testing, responsible for monitoring signal activity on the DUT interface.

[0054] uvm_sequencer is the sequencer component for UVM testing. As a scheduling component, it is used to manage the generation and transmission of test sequences.

[0055] Combination Figure 3 As shown, TB transmits signals to one or more components in the UVM environment via an interface to drive and monitor the signals. Optionally, the signal transmission method is implemented using uvm_config_db:set.

[0056] From a verification hierarchy perspective, it can be divided into unit-level testing (UT), module-level testing (BT), and system-level testing (ST). There is often reuse of environment components between different verification levels, including UVM environment components, stimuli, and configuration processes.

[0057] Optionally, high-level tests require a high-level verification environment, and low-level tests require a low-level verification environment. For example, system-level tests use a system-level verification environment, module-level tests use a module-level verification environment, and unit-level tests use a unit-level verification environment. When the high-level verification environment is a system-level verification environment, the low-level verification environment can be a module-level or unit-level verification environment; when the high-level verification environment is a module-level verification environment, the low-level verification environment can be a unit-level verification environment.

[0058] In some UVM verifications, there is a "tight coupling" between high-level and low-level verification environments. For example, the module-level verification environment and the system-level verification environment are "tightly coupled," and the module-level verification environment and the unit-level verification environment are "tightly coupled."

[0059] In one example, combined Figure 4 As shown, high-level verification environments typically reuse the uvm_agent or uvm_env components from low-level verification environments. Such integration and reuse require modifying the uvm_test_top or uvm_env of the high-level verification environment, adding new components, and reconfiguring the environment connections.

[0060] Therefore, if a high-level verification environment wants to reuse a verification component (such as uvm_agent) in a low-level verification environment, it must manually modify its own environment structure (such as modifying uvm_env), "insert" the new component, and reconnect.

[0061] Furthermore, different levels of verification environments correspond to corresponding levels of test platforms (TB), combined with Figure 5 As shown, the design-under-test (DUT) objects contained in high-level verification environments (TBs) differ from those in low-level verification environments (TBs). For example, when a high-level verification environment TB is a system-level TB, it typically contains multiple modules or the entire system as verification objects. When a low-level verification environment TB is a module-level TB, it typically targets a large functional module. When a low-level verification environment TB is a unit-level TB, it typically targets a sub-module or a tightly coupled logic group. Due to these differences in DUTs, signal connections related to verification intellectual property (VIP) cannot be directly reused and must be reconnected in the system-level environment.

[0062] Taking a module-level Data Interface (TB) as an example, the signal interfaces and driver logic defined in a module-level TB are for a single module's Device Underlying Unit (DUT). In a system-level TB, the DUT is an integration of multiple modules. The connections corresponding to the signal interfaces and driver logic in the module-level TB cannot be directly used in the system-level TB and need to be rewritten.

[0063] When the system-level TB passes an interface to the corresponding UVM environment, the component hierarchy in the UVM environment changes due to the change in the environment structure. The path for passing the interface through uvm_config_db also needs to be changed, which triggers corresponding adjustments to the passing path, increases the integration workload, and further increases the reuse complexity.

[0064] This results in the need for structural analysis and modification of the original environment when reusing components in the module-level UVM environment in the system-level UVM environment, increasing the workload of developing adaptable components; the interface definitions, signal connections and driving logic in the module-level TB cannot be directly used in the system-level environment and need to be rewritten; the interface transmission path needs to be adjusted due to changes in component hierarchy and cannot be directly reused, resulting in additional coding and integration costs.

[0065] In other words, when high-level verification processes reuse low-level environment components, they need to perform structural analysis, modify the original environment, rewrite interface definitions and signal connections, and adjust interface transmission paths, resulting in additional coding and integration costs.

[0066] In this regard, in one embodiment of this application, taking the high-level verification environment as the system-level verification environment, the high-level verification environment TB as the system-level TB, and the high-level test as the system-level test, and the low-level verification environment as the module-level verification environment, the low-level verification environment TB as the module-level TB, and the low-level test as the module-level test as an example, some processing methods are proposed:

[0067] Encapsulate all reusable logic directly related to the DUT within the module-level TB. This mainly includes:

[0068] 1. Instantiation of VIPs (e.g., a DDR memory controller VIP, a PCIe VIP).

[0069] Specifically, the volatile hardware signal connection parts that are bound to specific DUTs are separated from the pure software environment of UVM and standardized and packaged (wrapper).

[0070] 2. Package the software components of the entire module-level UVM environment. Examples include uvm_test_top, uvm_env, uvm_agent, and uvm_scoreboard. Predefine interfaces for interacting with this environment, such as "how to start a test," "how to send stimuli," and "how to obtain comparison results." The module-level UVM environment is packaged as an independent, plug-and-play unit, eliminating the need for splitting and manual integration into the system-level uvm_env. Through a unified API, the system-level environment can call and control various module-level environments in a standard manner, achieving component reuse.

[0071] This application proposes a software improvement scheme to achieve distributed reuse of the verification environment through encapsulation and interface standardization. This solves the problem in the existing UVM verification environment that high-level verification cannot directly reuse low-level environment components and TB content, thereby reducing additional coding and integration costs.

[0072] To illustrate the technical solution described in this application, specific embodiments are provided below.

[0073] Combination Figure 6 As shown, in some embodiments, a UVM-based chip verification method is proposed, including:

[0074] Step 601: Encapsulate the hardware interface layer code related to the low-level design under test in the test platform of the low-level verification environment into a wrapper module.

[0075] The wrapper module is used by the test platform in a high-level verification environment. The wrapper module is the same as the wrapper module.

[0076] Hardware interface layer code can refer to the code written in a hardware description language (HDL, such as Verilog / SystemVerilog) specifically used to implement the physical signal connections and electrical interactions between the test platform (TB) and the design under test (DUT).

[0077] Optionally, the hardware interface layer code includes at least one of the following: intellectual property verification instantiation code, physical signal connection code, and clock reset generation logic code.

[0078] During implementation, combined with Figure 7As shown, there can be multiple Test Modules (TBs) in a low-level verification environment. The hardware-related logic code related to the Device Under Test (DUT) that needs to be reused in each low-level verification environment TB, such as VIP instantiation, signal connection and driving logic, is encapsulated into independent wrapper modules for reuse (shown in the figure as reused wrapper modules). The DUT in the high-level verification environment TB contains the DUTs from the aforementioned low-level verification environment TBs, and the encapsulated wrapper modules can be directly instantiated and used by the high-level verification environment TB.

[0079] Step 602: Encapsulate the entire UVM environment components used to verify the low-level design under test in a UVM package, and set the environment startup code associated with the UVM package in the package module.

[0080] During implementation, combined with Figure 8 As shown, the entire UVM environment components of the low-level verification environment are encapsulated into a package, namely the UVM package, and associated with the corresponding wrapper module. This encapsulated UVM package can be directly instantiated and used by the high-level verification environment TB.

[0081] Optionally, the UVM environment components include at least one of uvm_test_top, uvm_env, uvm_agent, uvm_scoreboard, uvm_driver, uvm_monitor, and uvm_sequencer.

[0082] Optionally, setting the environment startup code associated with the UVM package in the packaging module includes:

[0083] An initialization block is set up in the packaging module; the environment startup code is written in this initialization block.

[0084] The initialization block is used to create a top-level test component of the low-level UVM environment based on the environment startup code, in order to build the low-level UVM environment.

[0085] In some implementations, specifically, an initial block is added to the wrapper module so that when the low-level UVM environment is instantiated later, the create_component_by_name method of uvm_factory is used to create wrap_test_top as the top-level test component of the instantiated low-level UVM environment.

[0086] An initialization block is a syntax structure in Verilog used to perform a one-time initialization operation at the start of a simulation. It is mainly used to set the initial state or generate test stimulus signals.

[0087] Optionally, the UVM package further encapsulates application interfaces related to the UVM environment components; the application interfaces include at least one of a component acquisition interface, an incentive sending interface, and a data comparison interface.

[0088] Optionally, the UVM package and the wrapper module are located in separate file sets, and layered compilation and independent version release are supported.

[0089] The low-level UVM environment is encapsulated at the uvm_test_top level and reused in a distributed structure for the high-level environment. It also provides standardized interfaces based on the package (UVM package) to improve ease of use.

[0090] During implementation, low-level UVM environment components (such as uvm_test_top, uvm_env, uvm_agent, etc.) and related application interfaces (such as component acquisition, incentive sending, and data comparison) are encapsulated into a package.

[0091] Step 603: In the high-level verification environment, bind the packaging module to the design-under-test instance in the high-level design-under-test that corresponds to the low-level design-under-test.

[0092] The binding operation can be implemented using the bind statement.

[0093] Specifically, the bind statement is used to bind the wrapper module to at least one DUT instance without modifying the DUT source code, enabling the wrapper module and the DUT to achieve distributed reuse and plug-and-play functionality.

[0094] This effectively solves the problem in hierarchical chip verification where the higher-level verification environment cannot reuse the lower-level verification environment in a lossless, plug-and-play manner, leading to the need for repeated development, adaptation, and integration.

[0095] Optionally, in a high-level verification environment, binding the packaging module to a design-under-test instance in the high-level design-under-test that corresponds to the low-level design-under-test includes:

[0096] In the case where there are multiple instances of the same type of design under test corresponding to the same packaging module in the low-level design under test, the same packaging module is bound to each instance of the same type of design under test respectively.

[0097] Without modifying the DUT source code, by binding the wrapper module to at least one DUT instance, the wrapper module and the DUT can achieve distributed reuse and plug-and-play functionality.

[0098] The same wrapper module is bound to each DUT instance of the same type, so that in subsequent simulations, each DUT instance corresponds to an independent wrapper instance and an independent uvm_test_top instance, enabling parallel verification of multiple instances. The same wrapper module is bound to at least one DUT instance, achieving distributed reuse and plug-and-play functionality.

[0099] During implementation, the high-level verification environment adds the wrapper module to the compilation list and uses the bind statement in the TB to bind it to the corresponding design under test instance. The same wrapper can be bound to multiple design under test instances of the same type, establishing simulation relationships later.

[0100] The wrapper module also includes a configuration database call interface, which is used to pass the interface handle to the corresponding component in the wrapper module via uvm_config_db#set() before the UVM verification environment starts.

[0101] The wrapper module is directly connected to the port signals of the DUT through the SystemVerilog interface, and completes the signal connection and driver initialization before the initialization block is executed.

[0102] The wrapper module encapsulates the reuse logic related to the design under test, supports direct instantiation and reuse via bind, and initiates the instantiation and creation of the UVM environment within the wrapper module.

[0103] Step 604: In the test platform of the high-level verification environment, the packaging module is instantiated, and the environment startup code accesses the UVM package to build a low-level UVM environment to verify the design under test instance.

[0104] The environment startup code executes automatically when the simulation begins.

[0105] The aforementioned processing has encapsulated the entire UVM environment components of the low-level verification environment into a package and associated it with the corresponding wrapper module, combined with... Figure 8 As shown, during the simulation reuse process, after the wrapper module is instantiated in the high-level verification environment TB, the low-level UVM environment is automatically instantiated and created, decoupled from the original high-level verification environment in TB. Multiple low-level verification environments are independent of the original high-level verification environment shown in the middle, and the final high-level verification environment is a distributed environment structure in which low-level UVM environments are inserted.

[0106] Optionally, the test platform in the high-level verification environment instantiates the packaging module, and the environment startup code accesses the UVM package to build a low-level UVM environment for verifying the design under test instance, including:

[0107] The packaging module is instantiated in the test platform of the high-level verification environment. The environment startup code is triggered to construct the low-level UVM environment through the UVM factory mechanism according to the registered name of the top-level test component, so as to verify the design instance under test.

[0108] The initialization block calls uvm_factory::create_component_by_name() to dynamically generate uvm_test_top and loads the wrapper module into simulation memory.

[0109] The `create_component_by_name` method of `uvm_factory` is used to create the top-level test in the wrapper module. Figure 8 The diagram shows the creation of wrap_test_top as an instantiated top-level test component of a low-level UVM environment. wrap_test_top is the instantiation name of a top-level test component that has the same functionality as uvm_test_top.

[0110] In some implementation processes of this application, at a low level, the code used to instantiate verification IP and connection signals is encapsulated into an independent packaging module. The low-level UVM environment components are encapsulated in a UVM package. In the packaging module, code is set up to call the UVM factory and create the test components defined in the UVM package. In the high-level verification environment, the packaging module is bound to the corresponding design under test instance through the bind statement. During verification simulation, the bound packaging module automatically creates its corresponding low-level UVM environment, which together with the high-level verification environment constitutes a distributed verification platform for simulation verification.

[0111] The wrapper module contains initialization logic for initiating the creation of the UVM environment, enabling the UVM environment to be automatically created in the high-level verification environment and decoupled from the original high-level verification environment.

[0112] The high-level verification environment automatically creates a UVM environment by instantiating wrapper modules, thus decoupling it from the high-level environment. The high-level verification environment is configured to support the simultaneous binding and execution of multiple wrapper modules from different low-level verification environments, forming a distributed verification structure. The high-level verification environment forms a distributed verification platform structure by instantiating one or more wrapper modules from different low-level verification environments.

[0113] Through the above solution, the wrapper module can be directly reused in the high-level environment via bind without modification. The low-level UVM environment is reused as a whole in package form, running as an independent process with no code dependency on the high-level environment. By decoupling from the high-level environment, distributed deployment and distributed verification are supported. The standardized interface improves the ease of reuse and avoids repeatedly building verification components for low-level units in the high-level environment, saving a lot of development time. Moreover, during simulation, the low-level design under test can still run its full set of native tests, ensuring the internal correctness after integration and significantly reducing integration and maintenance costs.

[0114] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0115] Based on the same inventive concept, this application also provides a UVM-based chip verification device. The UVM-based chip verification device provided in this application can implement all the processes of the embodiments of the above-described UVM-based chip verification method and achieve the same technical effects. Therefore, the specific limitations of one or more UVM-based chip verification device embodiments provided below can be found in the limitations of the UVM-based chip verification method above, and will not be repeated here to avoid repetition.

[0116] This embodiment can divide the computing side into functional modules according to the above method. For example, it can be divided into functional modules corresponding to each function, or two or more functions can be integrated into one processing module.

[0117] See Figure 9 , Figure 9 This is a structural diagram of a UVM-based chip verification device provided in an embodiment of this application. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0118] The UVM-based chip verification device 900 includes:

[0119] The first encapsulation module 901 is used to encapsulate the hardware interface layer code related to the low-level design under test in the test platform under the low-level verification environment into a packaging module; the packaging module is used to be instantiated and used by the test platform under the high-level verification environment.

[0120] The second packaging module 902 is used to encapsulate the entire UVM environment components used to verify the low-level design under test in a UVM package, and to set environment startup code associated with the UVM package in the packaging module;

[0121] Binding module 903 is used to bind the packaging module to the design-under-test instance in the high-level design-under-test that corresponds to the low-level design-under-test in a high-level verification environment.

[0122] Module 904 is used to instantiate the packaging module on the test platform in the high-level verification environment, and the environment startup code accesses the UVM package to build a low-level UVM environment to verify the design under test instance.

[0123] Optionally, module 903 is bound, specifically for:

[0124] In the case where there are multiple instances of the same type of design under test corresponding to the same packaging module in the low-level design under test, the same packaging module is bound to each instance of the same type of design under test respectively.

[0125] Optionally, the second encapsulation module 902 is specifically used for:

[0126] An initialization block is set in the packaging module; the environment startup code is written in the initialization block;

[0127] The initialization block is used to create a top-level test component of the low-level UVM environment based on the environment startup code, in order to build the low-level UVM environment.

[0128] Optionally, module 904 is constructed, specifically for:

[0129] The packaging module is instantiated on the test platform in the high-level verification environment. The environment startup code is triggered to construct the low-level UVM environment based on the registered name of the top-level test component through the UVM factory mechanism, so as to verify the design instance under test.

[0130] Optionally, the hardware interface layer code includes at least one of the following: intellectual property verification instantiation code, physical signal connection code, and clock reset generation logic code.

[0131] Optionally, the UVM package further encapsulates application interfaces related to the UVM environment components; the application interfaces include at least one of a component acquisition interface, an incentive sending interface, and a data comparison interface.

[0132] Optionally, the UVM environment components include at least one of uvm_test_top, uvm_env, uvm_agent, uvm_scoreboard, uvm_driver, uvm_monitor, and uvm_sequencer.

[0133] The integrated modules described above can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and represents only one logical functional division; in actual implementation, other division methods may be used.

[0134] It should be noted that the relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0135] In one embodiment, such as Figure 10 As shown, a computer device is provided. The computer device 10 of this embodiment includes: at least one processor 1000 (… Figure 10 (Only one is shown in the diagram), memory 1001, and computer program 1002 stored in said memory 1001 and executable on said at least one processor 1000, wherein the processor 1000 executes said computer program 1002 to implement the steps in any of the above method embodiments.

[0136] The computer device 10 may be a desktop computer, laptop, handheld computer, or other computing device. The computer device 10 may include, but is not limited to, a processor 1000 and a memory 1001. Those skilled in the art will understand that... Figure 10 This is merely an example of computer device 10 and does not constitute a limitation on computer device 10. It may include more or fewer components than shown, or combine certain components, or different components. For example, the computer device may also include input / output devices, network access devices, buses, etc.

[0137] The processor 1000 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0138] The memory 1001 can be an internal storage unit of the computer device 10, such as a hard disk or memory of the computer device 10. The memory 1001 can also be an external storage device of the computer device 10, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the computer device 10. Furthermore, the memory 1001 can include both internal and external storage units of the computer device 10. The memory 1001 is used to store the computer program and other programs and data required by the computer device. The memory 1001 can also be used to temporarily store data that has been output or will be output.

[0139] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0140] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0141] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0142] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0143] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0144] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0145] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0146] The methods described in this application can be implemented in whole or in part by a computer program product. When the computer program product is run on a computer device, the computer device executes the steps in the various method embodiments described above.

[0147] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A UVM-based chip verification method, characterized in that, The method comprises the following steps: encapsulating hardware interface layer code related to a low-level design under test in a test platform in a low-level verification environment into a packaging module; the packaging module is used to be instantiated by a test platform in a high-level verification environment; encapsulating entire UVM environment components for verifying the low-level design under test into a UVM package, and setting an initialization block in the packaging module; environment starting code is written in the initialization block; the initialization block is used to create a top-level test component of a low-level UVM environment based on the environment starting code, so as to build the low-level UVM environment; in a high-level verification environment, binding the packaging module to a design under test corresponding to the low-level design under test in a high-level design under test; instantiating the packaging module by a test platform in the high-level verification environment, accessing the UVM package by the environment starting code to build a low-level UVM environment, and verifying the design under test; the step of binding the packaging module to the design under test corresponding to the low-level design under test in the high-level design under test in the high-level verification environment comprises: in the case that there are multiple same-type design under test corresponding to the same packaging module in the low-level design under test, binding the same packaging module to each of the same-type design under test respectively.

2. The method of claim 1, wherein, the step of instantiating the packaging module by the test platform in the high-level verification environment, accessing the UVM package by the environment starting code to build a low-level UVM environment, and verifying the design under test comprises: instantiating the packaging module by the test platform in the high-level verification environment, triggering the environment starting code to build the low-level UVM environment according to the registered name of the top-level test component through a UVM factory mechanism, and verifying the design under test.

3. The method of claim 1, wherein, The hardware interface layer code comprises at least one of verification intellectual property instantiation code, physical signal connection code and clock reset generation logic code.

4. The method of claim 1, wherein, The UVM package further encapsulates an application interface related to the UVM environment components; the application interface comprises at least one of a component acquisition interface, an excitation sending interface and a data comparison interface.

5. The method of claim 1, wherein, The UVM environment components comprise at least one of uvm_test_top, uvm_env, uvm_agent, uvm_scoreboard, uvm_driver, uvm_monitor and uvm_sequencer.

6. A UVM-based chip verification apparatus, characterized by comprising: The method comprises the following steps: a first encapsulation module is configured to encapsulate hardware interface layer code related to a low-level design under test in a test platform in a low-level verification environment into a packaging module; the packaging module is used to be instantiated by a test platform in a high-level verification environment; a second encapsulation module is configured to encapsulate entire UVM environment components for verifying the low-level design under test into a UVM package, and set an initialization block in the packaging module; environment starting code is written in the initialization block; The initialization block is configured to create a top test component of a low-level UVM environment based on the environment starting code to build the low-level UVM environment; a binding module configured to bind the packaging module to a design-under-test instance corresponding to the low-level design-under-test in a high-level design-under-test in the high-level verification environment; a building module configured to instantiate the packaging module on a test platform in the high-level verification environment, access the UVM package by the environment starting code to build the low-level UVM environment, and verify the design-under-test instance; The binding module is specifically configured to bind the same packaging module to each of the same type of design-under-test instances respectively in the case that there are multiple same type of design-under-test instances corresponding to the same packaging module in the low-level design-under-test.

7. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 7. The computer program is executed by the processor to implement the steps of the method according to any one of claims 1 to 5.

Images