A verification method and system of a UVM-based verification use case

Abstract

The application relates to the technical field of UVM use case verification, and relates to a verification method and system for a UVM verification use case, which comprises the following steps: receiving user input information, identifying a target top-level file based on the user input information, performing compilation by using the target top-level file, assigning the name of a class in the user input information to a test class specified parameter, replacing the default value of a UVM core function run_test() with the assigned test class specified parameter, obtaining a target UVM core function run_test(), when running to the target UVM core function run_test(), executing test class instance creation, obtaining a test instance, performing a construction stage operation and a component connection operation according to the test instance, obtaining a target simulation verification platform, and performing core simulation based on the target simulation verification platform. The application can improve the starting efficiency of the verification process of the UVM verification use case and improve the automation degree of the verification process of the verification use case.

Description

Technical Field

[0001] This invention relates to the field of UVM use case verification technology, and in particular to a UVM-based verification method and system for verification use cases. Background Technology

[0002] As chip design scale and functional complexity increase, the UVM verification methodology, with its standardized hierarchical architecture, reusable component library, and unified factory mechanism, has become an irreplaceable core technology for ensuring the functional correctness, protocol consistency, and performance compliance of billion-gate SoC designs before tape-out.

[0003] Traditional technologies typically employ template inheritance and manual coding, requiring developers to write test classes and sequence classes for each case and complete registration and configuration. While this can build complete test cases, it suffers from drawbacks such as a huge amount of repetitive code and the ease of maintenance oversights when the platform is renamed. Therefore, the level of automation needs to be improved. Summary of the Invention

[0004] This invention provides a UVM-based verification method and system for verification test cases, the main purpose of which is to improve the startup efficiency of the UVM verification test case verification process and enhance the automation level of the verification test case verification process.

[0005] To achieve the above objectives, this invention provides a UVM-based verification method for verification test cases, comprising:

[0006] Receive user input information and identify the target top-level file based on the user input information. The user input information includes the class name, and the class name in the target top-level file is the same as the class name in the user input information.

[0007] The compilation is performed using the target top-level file. Once the compilation step is completed, the simulation phase begins.

[0008] During the simulation phase, the class name in the user input information is assigned to the test class specified parameter. The assigned test class specified parameter replaces the default value of the UVM core function run_test() to obtain the target UVM core function run_test(). The target UVM core function run_test() refers to the UVM core function run_test() after the default value is overridden. The test class specified parameter is used to specify the name of the test class and test cases to be run.

[0009] When the execution reaches the target UVM core function run_test(), the test class instance is created, and the test instance is obtained.

[0010] Based on the test instance, perform the build phase operations to obtain connection component information, hierarchy information, and configuration information;

[0011] Based on the connection component information, hierarchical structure information, and configuration information, component connection operations are performed to obtain the original simulation verification platform;

[0012] The original simulation verification platform is sequentially checked and initialized to obtain the target simulation verification platform;

[0013] The core simulation is performed based on the target simulation verification platform. After the core simulation steps are completed, the verification operation is performed to complete the verification of the UVM-based verification test cases.

[0014] Optionally, the process of performing compilation using the target top-level file includes:

[0015] Identify the registration macros and constructors in the target top-level file, where the registration macros are either object registration macros or component registration macros;

[0016] The UVM factory registration and class initialization are performed based on the registration macro and constructor respectively, and the compilation is completed.

[0017] Optionally, the step of performing the construction phase operation based on the test instance to obtain connection component information, hierarchy information, and configuration information includes:

[0018] The construction phase is identified. In the construction phase, sub-components are instantiated based on test instances to obtain connection component information and hierarchical structure information, and configuration information is obtained based on a preset parameter retrieval method.

[0019] Optionally, the step of performing the construction phase operation based on the test instance to obtain connection component information, hierarchical structure information, and configuration information further includes:

[0020] If the construction phase is the construction phase of a preset test class, then identify the virtual sequence class in the target top-level file;

[0021] Determine the default sequence for the main_phase in the pre-built virtual sequencer;

[0022] During the construction phase of the test class, the virtual sequence class is set as the default sequence of the main_phase based on preset configuration database instructions.

[0023] Optionally, the step of performing component connection operations based on connection component information, hierarchical structure information, and configuration information to obtain the original simulation verification platform includes:

[0024] Several components to be connected were identified, including the TLM port;

[0025] Based on the connection component information, hierarchical structure information, and configuration information, multiple TLM ports of multiple components to be connected are connected to obtain a communication channel, wherein the communication channel includes multiple connected components.

[0026] The original simulation verification platform was constructed based on the communication channel and multiple connected components.

[0027] Optionally, the core simulation based on the target simulation verification platform includes:

[0028] The virtual sequence class in the target top-level file and multiple sequencers in the target simulation verification platform were identified respectively. The virtual sequence class includes the body code segment.

[0029] The sequence class is instantiated based on the body code segment to obtain a sequence object. The mapping sequencer is identified among the multiple sequencers based on the sequence object. The correspondence between the sequence object and the mapping sequencer is defined by a preset macro in the body code segment.

[0030] The core simulation of the sequence object is completed based on the mapping sequencer.

[0031] Optionally, the core simulation of the sequence object based on the mapping sequencer includes:

[0032] Multiple transactions are generated based on the sequence object, and transactions are extracted sequentially from the multiple transactions;

[0033] The transaction is sent to the pre-built driver using the mapping sequencer, and then sent to the preset design module under test using the driver after sending, to obtain the target design module;

[0034] The simulation is performed based on the target design module to complete the simulation of the transaction;

[0035] The core simulation of the sequence object is completed when each of the multiple transactions has completed its simulation.

[0036] Optionally, the core simulation based on the target simulation verification platform further includes:

[0037] The current number of incentives is detected based on a preset objection mechanism, which includes raise_objection and drop_objection.

[0038] If the current number of incentives is not a preset zero value, then return to the step of detecting the current number of incentives based on the preset Objection mechanism until the current number of incentives is zero.

[0039] If the current number of excitations is zero, then the core simulation step is stopped.

[0040] Optionally, the verification operation includes at least one of the following operations: extracting simulation result data, performing a final verification check, generating a test report, and releasing resources.

[0041] To achieve the above objectives, the present invention also provides a verification system for verification test cases based on UVM, comprising:

[0042] The top-level file compilation module is used to receive user input information, identify the target top-level file based on the user input information, where the user input information includes the class name, the class name in the target top-level file is the same as the class name in the user input information, and perform compilation using the target top-level file;

[0043] The test instance creation module is used to assign the class name from the user input information to the specified parameter of the test class, and replace the default value of the UVM core function run_test() with the assigned specified parameter of the test class to obtain the target UVM core function run_test(). The target UVM core function run_test() refers to the UVM core function run_test() after the default value is overridden. The specified parameter of the test class is used to specify the name of the test class and test cases to be run. When the target UVM core function run_test() is run, the test class instance is created.

[0044] The verification platform construction module is used to perform construction phase operations based on test instances, obtain connection component information, hierarchical structure information and configuration information, and perform component connection operations based on the connection component information, hierarchical structure information and configuration information to obtain the original simulation verification platform;

[0045] The core simulation execution module is used to sequentially perform platform checks and initialization on the original simulation verification platform to obtain the target simulation verification platform, perform core simulation based on the target simulation verification platform, and perform verification operations after the core simulation steps are completed.

[0046] To address the above problems, the present invention also provides an electronic device, the electronic device comprising:

[0047] Memory, storing at least one instruction;

[0048] The processor executes the instructions stored in the memory to implement the verification method for the UVM-based verification use case described above.

[0049] To address the aforementioned issues, the present invention also provides a computer-readable storage medium storing at least one instruction, which is executed by a processor in an electronic device to implement the verification method for the UVM-based verification use case described above.

[0050] To address the problems described in the background section, this invention first receives user input information and identifies the target top-level file based on this input. This step, by receiving user input and automatically identifying the corresponding target top-level file, achieves accurate matching between user-specified test cases and pre-defined templates, avoiding the inefficient operation of manually searching and matching files, and improving the startup efficiency and accuracy of the verification process. Next, the class name from the user input is assigned to a specified parameter of the test class. The assigned specified parameter of the test class replaces the default value of the UVM core function `run_test()`, resulting in the target UVM core function `run_test()`. The specified parameter of the test class is used to specify the test case to be run. The step of specifying the test class and test case names involves assigning the user-inputted class name to a specified parameter of the test class and replacing the default value of `run_test()`. This achieves dynamic specification and injection of test cases, avoiding the tedious operation of modifying platform code and significantly improving the flexibility and efficiency of test case switching. Furthermore, this invention sets the virtual sequence as the default sequence of the virtual sequencer in the test class using `uvm_config_db`, enabling automatic execution of the sequence at a specified stage. Finally, this invention sets the virtual sequence class as the default sequence of the virtual sequencer through database configuration commands. This step replaces the traditional manual sequence startup method, making the sequence startup process fully automated. Therefore, this invention can improve the startup efficiency of the UVM verification test case verification process and enhance the automation level of the verification test case process. Attached Figure Description

[0051] Figure 1 A flowchart illustrating a verification method for a UVM-based verification test case provided in an embodiment of the present invention;

[0052] Figure 2 A functional block diagram of a UVM-based verification test case verification system provided in an embodiment of the present invention;

[0053] Figure 3 This is a schematic diagram of the structure of an electronic device that implements the verification method for the UVM-based verification test cases, according to an embodiment of the present invention.

[0054] Explanation of reference numerals in the attached figures:

[0055] 10. Electronic device; 11. Processor; 12. Memory; 13. Bus.

[0056] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0057] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0058] This application provides a verification method for UVM-based verification test cases. The execution entity of the UVM-based verification test case verification method includes, but is not limited to, at least one of the following electronic devices that can be configured to execute the method provided in this application embodiment: a server, a terminal, etc. In other words, the UVM-based verification test case verification method can be executed by software or hardware installed on a terminal device or a server device, and the software can be a blockchain platform. The server includes, but is not limited to, a single server, a server cluster, a cloud server, or a cloud server cluster.

[0059] Reference Figure 1 The diagram shown is a flowchart illustrating a UVM-based verification method for verification cases according to an embodiment of the present invention. In this embodiment, the UVM-based verification method for verification cases includes:

[0060] S1. Receive user input information and identify the target top-level file based on the user input information. The user input information includes the class name, and the class name in the target top-level file is the same as the class name in the user input information.

[0061] As is clear, the user input information refers to the information entered by the user, which includes the specific use case name for subsequent simulation execution, i.e., the class name. The target top-level file refers to the top-level file with the same class name as the user input information. When the target top-level file is pre-built, the placeholders in the template file are replaced by specific use case names, and the replaced template file is the target top-level file.

[0062] S2. Compile using the target top-level file. Once the compilation step is complete, the simulation phase begins.

[0063] Specifically, the process of performing compilation using the target top-level file includes:

[0064] Identify the registration macros and constructors in the target top-level file, where the registration macros are either object registration macros or component registration macros;

[0065] The UVM factory registration and class initialization are performed based on the registration macro and constructor respectively, and the compilation is completed.

[0066] It should be explained that the target top-level file contains registration macros and constructors. Registration macros are macro instructions used to register classes with the UVM factory, such as `uvm_object_utils` or `uvm_component_utils`. Different target top-level files have different types of registration macros; these macros can be object registration macros (i.e., `uvm_object_utils` macros) or component registration macros (i.e., `uvm_component_utils` macros). The function of these registration macros is to complete the factory registration of UVM classes (i.e., create objects of the class). The constructor refers to the `new` function of the class, which is used to initialize the class.

[0067] S3. In the simulation phase, the class name in the user input information is assigned to the test class specified parameter. The assigned test class specified parameter replaces the default value of the UVM core function run_test() to obtain the target UVM core function run_test(). The target UVM core function run_test() refers to the UVM core function run_test() after the default value is overridden. The test class specified parameter is used to specify the name of the test class and test cases to be run.

[0068] Understandably, the test class specified parameter refers to the command-line argument used to specify the name of the test class to be run, i.e., +UVM_TESTNAME. The default value of the UVM core function run_test() refers to the default test class name used when no test class is specified, such as "default_test". Here, the UVM core function run_test() refers to the entry function when the UVM environment starts simulation, which is used to create and start the specified test class instance.

[0069] For example, the default value of a certain UVM core function run_test() is default_test, that is, the UVM core function run_test() is run_test(“default_test”) at this time. The parameter specified by the assigned test class is PATTERN_NAME. After the parameter specified by the assigned test class is replaced, run_test(“default_test”) becomes run_test(“PATTERN_NAME”).

[0070] S4. When the target UVM core function run_test() is executed, the test class instance is created, and the test instance is obtained.

[0071] It is clear that the test instance refers to the test class object created by the run_test() function. This test instance is used to start and control the operation process of the UVM verification platform, ensuring that the UVM verification platform starts the subsequent UVM_Phase mechanisms.

[0072] Furthermore, the aforementioned UVM_Phase mechanisms include: build_phase, connect_phase, end_of_elaboration_phase, start_of_simulation_phase, run_phase, extract_phase, check_phase, report_phase, and final_phase. The detailed execution flow and function of each of these UVM_Phase mechanisms are existing technologies and will not be elaborated upon here.

[0073] S5. Perform the build phase operations based on the test instance to obtain connection component information, hierarchical structure information, and configuration information.

[0074] It should be explained that the "build phase" refers to the "build_phase" in each of the aforementioned UVM_Phase mechanisms. The "connection component information" refers to the communication connection relationship established between components, the "hierarchical structure information" refers to the parent-child relationship and organizational structure of components in the verification environment, and the "configuration information" refers to the running parameters or environment settings transmitted through a configuration database (such as uvm_config_db).

[0075] Specifically, the step of performing the build phase operation based on the test instance to obtain connection component information, hierarchy information, and configuration information includes:

[0076] The construction phase is identified. In the construction phase, sub-components are instantiated based on test instances to obtain connection component information and hierarchical structure information, and configuration information is obtained based on a preset parameter retrieval method.

[0077] It is clear that instantiating a child component refers to creating an object of its child component within the parent component's `build_phase`. The parameter retrieval method refers to a method for obtaining parameter values ​​from the UVM configuration database; optionally, this parameter retrieval method is the `uvm_config_db::get` method.

[0078] In detail, the step of performing the build phase operation based on the test instance to obtain connection component information, hierarchy information, and configuration information also includes:

[0079] If the construction phase is the construction phase of a preset test class, then identify the virtual sequence class in the target top-level file;

[0080] Determine the default sequence for the main_phase in the pre-built virtual sequencer;

[0081] During the construction phase of the test class, the virtual sequence class is set as the default sequence of the main_phase based on preset configuration database instructions.

[0082] It should be explained that the "build phase" of the test class refers to the environment build operation performed by the test class in the `build_phase`. The "default sequence in the main_phase" of the virtual sequencer refers to the sequence object executed by default in the main_phase of the virtual sequencer. The "configuration database command" refers to the command for parameter configuration using methods such as `uvm_config_db::set` or `uvm_config_db::get`.

[0083] Furthermore, when the test build phase is reached, the virtual sequence class is set as the default sequence for the main_phase by configuring database instructions. Then, when the main_phase in the virtual sequencer is reached subsequently, this default sequence will be automatically started without manually calling the start() method. This approach uses an instantiated test class to automatically start the pre-configured default sequence (i.e., the default sequence for the main_phase in the virtual sequencer set by the virtual sequence class) and trigger the entire verification process, thus replacing the traditional manual sequence startup method (i.e., the seq.start() method), making the sequence startup process fully automated.

[0084] S6. Perform component connection operations based on connection component information, hierarchical structure information, and configuration information to obtain the original simulation verification platform.

[0085] It is clear that the original simulation verification platform refers to the UVM verification environment in which component instantiation and connection have been completed but platform checks and initialization have not yet been performed. The component connection operation based on connection component information, hierarchical structure information and configuration information refers to binding the TLM ports of each component according to the predefined connection relationship in connect_phase to establish a communication path.

[0086] In detail, the step of performing component connection operations based on connection component information, hierarchical structure information, and configuration information to obtain the original simulation verification platform includes:

[0087] Several components to be connected were identified, including the TLM port;

[0088] Based on the connection component information, hierarchical structure information, and configuration information, multiple TLM ports of multiple components to be connected are connected to obtain a communication channel, wherein the communication channel includes multiple connected components.

[0089] The original simulation verification platform was constructed based on the communication channel and multiple connected components.

[0090] Understandably, the "component to be connected" refers to UVM component instances that require establishing a communication connection, such as sequencer, driver, monitor, etc. The "communication channel" refers to the data transmission path between components formed through a TLM port connection. The "multiple connected components" refers to multiple components that have already been connected and are yet to be connected.

[0091] S7. Perform platform checks and initialization sequentially on the original simulation verification platform to obtain the target simulation verification platform.

[0092] It should be explained that the target simulation verification platform refers to the original simulation verification platform after platform checking and initialization, where platform checking and initialization refer to the end_of_elaboration_phase and start_of_simulation_phase in each of the above-mentioned UVM_Phase mechanisms.

[0093] S8. Perform core simulation based on the target simulation verification platform. After the core simulation steps are completed, perform verification operations to complete the verification of the UVM-based verification test cases.

[0094] It is clear that the core simulation refers to the run_phase in each of the aforementioned UVM_Phase mechanisms.

[0095] In detail, the core simulation based on the target simulation verification platform includes:

[0096] The virtual sequence class in the target top-level file and multiple sequencers in the target simulation verification platform were identified respectively. The virtual sequence class includes the body code segment.

[0097] The sequence class is instantiated based on the body code segment to obtain a sequence object. The mapping sequencer is identified among the multiple sequencers based on the sequence object. The correspondence between the sequence object and the mapping sequencer is defined by a preset macro in the body code segment.

[0098] The core simulation of the sequence object is completed based on the mapping sequencer.

[0099] It is clear that the multiple sequencers refer to multiple UVM components used for managing and scheduling sequences, such as tx_seqr, rx_seqr, etc. The body code segment refers to the code written by the user to implement the specific logic. The sequence object refers to the object instantiated from the sequence class used to generate transactions. The definition of the mapping relationship between the sequence object and the multiple sequencers based on preset macros means: using macros such as uvm_do_on to bind the sequence object to a specified sequencer. The mapped sequencer refers to the specific sequencer instance bound to the sequence object.

[0100] In detail, the core simulation of the sequence object based on the mapping sequencer includes:

[0101] Multiple transactions are generated based on the sequence object, and transactions are extracted sequentially from the multiple transactions;

[0102] The transaction is sent to the pre-built driver using the mapping sequencer, and then sent to the preset design module under test using the driver after sending, to obtain the target design module;

[0103] The simulation is performed based on the target design module to complete the simulation of the transaction;

[0104] The core simulation of the sequence object is completed when each of the multiple transactions has completed its simulation.

[0105] Understandably, the design under test (DUT) refers to the design module that needs to be functionally verified. The target design module refers to the DUT that has received the transaction.

[0106] Furthermore, the name of the sequencer mentioned above (such as seqr_tx) is strongly bound to the architecture of the UVM verification platform. If the UVM verification platform changes (such as renaming the sequencer), only the corresponding field in the template needs to be modified, and all test cases will automatically inherit the modification results without needing to be adjusted one by one. Here, the template refers to the template file for building the target top-level file.

[0107] In detail, the core simulation based on the target simulation verification platform also includes:

[0108] The current number of incentives is detected based on a preset objection mechanism, which includes raise_objection and drop_objection.

[0109] If the current number of incentives is not a preset zero value, then return to the step of detecting the current number of incentives based on the preset Objection mechanism until the current number of incentives is zero.

[0110] If the current number of excitations is zero, then the core simulation step is stopped.

[0111] As is clear, the Objection mechanism refers to the mechanism in UVM used to control simulation runtime. This Objection mechanism declares that there are still stimuli that have not been completed through `raise_objection` and declares that the current stimuli have been completed through `drop_objection`, thereby obtaining the current number of stimuli. The current number of stimuli refers to the number of stimuli transactions that have not yet been completed. If the current number of stimuli is not zero, it means that there are still stimuli being processed or waiting to be processed, that is, it is necessary to continue to monitor the current number of stimuli. If the current number of stimuli is zero, it means that all stimuli have been processed, and at this time, the core simulation steps can be stopped.

[0112] In detail, the verification operation includes at least one of the following operations: extracting simulation result data, performing a final verification check, generating a test report, and releasing resources.

[0113] It is clear that the extraction of simulation result data, final verification check, generation of test report and release of resources refer to the extract_phase, check_phase, report_phase and final_phase of the above-mentioned UVM_Phase mechanisms, respectively.

[0114] To address the problems described in the background section, this invention first receives user input information and identifies the target top-level file based on this input. This step, by receiving user input and automatically identifying the corresponding target top-level file, achieves accurate matching between user-specified test cases and pre-defined templates, avoiding the inefficient operation of manually searching and matching files, and improving the startup efficiency and accuracy of the verification process. Next, the class name from the user input is assigned to a specified parameter of the test class. The assigned specified parameter of the test class replaces the default value of the UVM core function `run_test()`, resulting in the target UVM core function `run_test()`. The specified parameter of the test class is used to specify the test case to be run. The step of specifying the test class and test case names involves assigning the user-inputted class name to a specified parameter of the test class and replacing the default value of `run_test()`. This achieves dynamic specification and injection of test cases, avoiding the tedious operation of modifying platform code and significantly improving the flexibility and efficiency of test case switching. Furthermore, this invention sets the virtual sequence as the default sequence of the virtual sequencer in the test class using `uvm_config_db`, enabling automatic execution of the sequence at a specified stage. Finally, this invention sets the virtual sequence class as the default sequence of the virtual sequencer through database configuration commands. This step replaces the traditional manual sequence startup method, making the sequence startup process fully automated. Therefore, this invention can improve the startup efficiency of the UVM verification test case verification process and enhance the automation level of the verification test case process.

[0115] like Figure 2 The diagram shown is a functional block diagram of a UVM-based verification test case verification system provided in an embodiment of the present invention.

[0116] The UVM-based verification test case verification system 100 of this invention can be installed in an electronic device. Depending on the functions implemented, the UVM-based verification test case verification system 100 may include a top-level file compilation module 101, a test instance creation module 102, a verification platform construction module 103, and a core simulation execution module 104. The module described in this invention can also be called a unit, which refers to a series of computer program segments that can be executed by the processor of an electronic device and can perform a fixed function, and which are stored in the memory of the electronic device.

[0117] The top-level file compilation module 101 is used to receive user input information, identify the target top-level file based on the user input information, wherein the user input information includes the name of the class, the name of the class in the target top-level file is the same as the name of the class in the user input information, and perform compilation using the target top-level file;

[0118] The test instance creation module 102 is used to assign the class name in the user input information to the test class specified parameter, and replace the default value of the UVM core function run_test() with the assigned test class specified parameter to obtain the target UVM core function run_test(). The target UVM core function run_test() refers to the UVM core function run_test() after the default value is overridden. The test class specified parameter is used to specify the name of the test class and test cases to be run. When the target UVM core function run_test() is run, the test class instance is created.

[0119] The verification platform construction module 103 is used to perform construction phase operations based on test instances to obtain connection component information, hierarchical structure information and configuration information, and to perform component connection operations based on the connection component information, hierarchical structure information and configuration information to obtain the original simulation verification platform.

[0120] The core simulation execution module 104 is used to sequentially perform platform checks and initialization on the original simulation verification platform to obtain the target simulation verification platform, perform core simulation based on the target simulation verification platform, and perform verification operation after the core simulation steps are completed.

[0121] In detail, the modules in the UVM-based verification test case verification system 100 described in this embodiment of the invention employ the same methods as described above. Figure 1 The verification methods used in this paper are the same as those used in the UVM-based verification test cases, and can produce the same technical effects, so they will not be repeated here.

[0122] like Figure 3 The diagram shown is a structural schematic of an electronic device that implements a verification method for UVM-based verification test cases according to an embodiment of the present invention.

[0123] The electronic device 1 may include a processor 10, a memory 11 and a bus 12, and may also include a computer program stored in the memory 11 and executable on the processor 10, such as a verification method program for a UVM-based verification use case.

[0124] The memory 11 includes at least one type of readable storage medium, such as flash memory, portable hard drive, multimedia card, card-type memory (e.g., SD or DX memory), magnetic memory, disk, optical disk, etc. In some embodiments, the memory 11 can be an internal storage unit of the electronic device 1, such as a portable hard drive. In other embodiments, the memory 11 can be an external storage device of the electronic device 1, such as a plug-in portable hard drive, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on the electronic device 1. Furthermore, the memory 11 includes both internal storage units and external storage devices of the electronic device 1. The memory 11 can be used not only to store application software and various types of data installed on the electronic device 1, such as the code of verification methods for UVM-based verification test cases, but also to temporarily store data that has been output or will be output.

[0125] In some embodiments, the processor 10 may be composed of integrated circuits, such as a single packaged integrated circuit or multiple integrated circuits with the same or different functions, including combinations of one or more central processing units (CPUs), microprocessors, digital processing chips, graphics processors, and various control chips. The processor 10 is the control unit of the electronic device, connecting various components of the entire electronic device via various interfaces and lines. It executes programs or modules stored in the memory 11 (e.g., verification method programs for UVM-based verification test cases) and calls data stored in the memory 11 to perform various functions of the electronic device 1 and process data.

[0126] The bus 12 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus 12 can be divided into an address bus, a data bus, a control bus, etc. The bus 12 is configured to realize the connection and communication between the memory 11 and at least one processor 10, etc.

[0127] Figure 3 Only electronic devices with components are shown; it will be understood by those skilled in the art that... Figure 3The structure shown does not constitute a limitation on the electronic device 1, and may include fewer or more components than shown, or combine certain components, or have different component arrangements.

[0128] For example, although not shown, the electronic device 1 may also include a power supply (such as a battery) to power the various components. Preferably, the power supply can be logically connected to the at least one processor 10 through a power management system, thereby enabling functions such as charging management, discharging management, and power consumption management through the power management system. The power supply may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components. The electronic device 1 may also include various sensors, Bluetooth modules, Wi-Fi modules, etc., which will not be described in detail here.

[0129] Furthermore, the electronic device 1 may also include a network interface. Optionally, the network interface may include a wired interface and / or a wireless interface (such as a Wi-Fi interface, a Bluetooth interface, etc.), which is typically used to establish communication connections between the electronic device 1 and other electronic devices.

[0130] Optionally, the electronic device 1 may further include a user interface, which may be a display, an input unit (such as a keyboard), and optionally, a standard wired interface or a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen, etc. The display may also be appropriately referred to as a screen or display unit, used to display information processed in the electronic device 1 and to display a visual user interface.

[0131] The verification method program for UVM-based verification test cases stored in the memory 11 of the electronic device 1 is a combination of multiple instructions, which, when run in the processor 10, can achieve the following:

[0132] Receive user input information and identify the target top-level file based on the user input information. The user input information includes the class name, and the class name in the target top-level file is the same as the class name in the user input information.

[0133] The compilation is performed using the target top-level file. Once the compilation step is completed, the simulation phase begins.

[0134] During the simulation phase, the class name in the user input information is assigned to the test class specified parameter. The assigned test class specified parameter replaces the default value of the UVM core function run_test() to obtain the target UVM core function run_test(). The target UVM core function run_test() refers to the UVM core function run_test() after the default value is overridden. The test class specified parameter is used to specify the name of the test class and test cases to be run.

[0135] When the execution reaches the target UVM core function run_test(), the test class instance is created, and the test instance is obtained.

[0136] Based on the test instance, perform the build phase operations to obtain connection component information, hierarchy information, and configuration information;

[0137] Based on the connection component information, hierarchical structure information, and configuration information, component connection operations are performed to obtain the original simulation verification platform;

[0138] The original simulation verification platform is sequentially checked and initialized to obtain the target simulation verification platform;

[0139] The core simulation is performed based on the target simulation verification platform. After the core simulation steps are completed, the verification operation is performed to complete the verification of the UVM-based verification test cases.

[0140] Specifically, the processor 10's implementation method for the above instructions can be found in [reference needed]. Figures 1 to 3 The descriptions of the relevant steps in the corresponding embodiments are not repeated here.

[0141] Furthermore, if the modules / units integrated in the electronic device 1 are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. The computer-readable storage medium can be volatile or non-volatile. For example, the computer-readable medium may include: any entity or system capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, or a read-only memory (ROM).

[0142] The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor of an electronic device, can perform the following:

[0143] Receive user input information and identify the target top-level file based on the user input information. The user input information includes the class name, and the class name in the target top-level file is the same as the class name in the user input information.

[0144] The compilation is performed using the target top-level file. Once the compilation step is completed, the simulation phase begins.

[0145] During the simulation phase, the class name in the user input information is assigned to the test class specified parameter. The assigned test class specified parameter replaces the default value of the UVM core function run_test() to obtain the target UVM core function run_test(). The target UVM core function run_test() refers to the UVM core function run_test() after the default value is overridden. The test class specified parameter is used to specify the name of the test class and test cases to be run.

[0146] When the execution reaches the target UVM core function run_test(), the test class instance is created, and the test instance is obtained.

[0147] Based on the test instance, perform the build phase operations to obtain connection component information, hierarchy information, and configuration information;

[0148] Based on the connection component information, hierarchical structure information, and configuration information, component connection operations are performed to obtain the original simulation verification platform;

[0149] The original simulation verification platform is sequentially checked and initialized to obtain the target simulation verification platform;

[0150] The core simulation is performed based on the target simulation verification platform. After the core simulation steps are completed, the verification operation is performed to complete the verification of the UVM-based verification test cases.

[0151] In the embodiments provided by this invention, it should be understood that the disclosed devices, systems, and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative, and actual implementations may have other classification methods.

[0152] The modules described as separate components may or may not be physically separate. The components shown as modules 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 modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0153] Furthermore, the functional modules in the various embodiments of the present invention 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 in the form of hardware plus software functional modules.

[0154] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0155] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A verification method for verification test cases based on UVM, characterized in that, The method includes: Receive user input information and identify the target top-level file based on the user input information. The user input information includes the class name, and the class name in the target top-level file is the same as the class name in the user input information. The compilation is performed using the target top-level file. Once compilation is complete, the simulation phase begins. Compilation is performed using the target top-level file, including: Identify the registration macros and constructors in the target top-level file, where the registration macros are either object registration macros or component registration macros; The UVM factory registration and class initialization are performed based on the registration macro and constructor respectively, and the compilation is completed. During the simulation phase, the class name in the user input information is assigned to the test class specified parameter. The assigned test class specified parameter replaces the default value of the UVM core function run_test() to obtain the target UVM core function run_test(). The target UVM core function run_test() refers to the UVM core function run_test() after the default value is overridden. The test class specified parameter is used to specify the name of the test class and test cases to be run. When the execution reaches the target UVM core function run_test(), the test class instance is created, and the test instance is obtained. Based on the test instance, perform the build phase operations to obtain connection component information, hierarchy information, and configuration information; Based on the connection component information, hierarchical structure information, and configuration information, component connection operations are performed to obtain the original simulation verification platform; The original simulation verification platform is sequentially checked and initialized to obtain the target simulation verification platform; The core simulation is performed based on the target simulation verification platform. After the core simulation is completed, the verification operation is performed to complete the verification of the UVM-based verification test cases.

2. The verification method for UVM-based verification test cases as described in claim 1, characterized in that, The construction phase operation based on the test instance yields connection component information, hierarchical structure information, and configuration information, including: The construction phase is identified. In the construction phase, sub-components are instantiated based on test instances to obtain connection component information and hierarchical structure information, and configuration information is obtained based on a preset parameter retrieval method.

3. The verification method for UVM-based verification test cases as described in claim 2, characterized in that, The step of performing the construction phase operation based on the test instance to obtain connection component information, hierarchical structure information, and configuration information also includes: If the construction phase is the construction phase of a preset test class, then identify the virtual sequence class in the target top-level file; Determine the default sequence for the main_phase in the pre-built virtual sequencer; During the construction phase of the test class, the virtual sequence class is set as the default sequence of the main_phase based on preset configuration database instructions.

4. The verification method for UVM-based verification test cases as described in claim 3, characterized in that, The component connection operation is performed based on connection component information, hierarchical structure information, and configuration information to obtain the original simulation verification platform, including: Several components to be connected were identified, including the TLM port; Based on the connection component information, hierarchical structure information, and configuration information, multiple TLM ports of multiple components to be connected are connected to obtain a communication channel, wherein the communication channel includes multiple connected components. The original simulation verification platform was constructed based on the communication channel and multiple connected components.

5. The verification method for UVM-based verification test cases as described in claim 4, characterized in that, The core simulation based on the target simulation verification platform includes: The virtual sequence class in the target top-level file and multiple sequencers in the target simulation verification platform were identified respectively. The virtual sequence class includes the body code segment. The sequence class is instantiated based on the body code segment to obtain a sequence object. The mapping sequencer is identified among the multiple sequencers based on the sequence object. The correspondence between the sequence object and the mapping sequencer is defined by a preset macro in the body code segment. The core simulation of the sequence object is completed based on the mapping sequencer.

6. The verification method for UVM-based verification test cases as described in claim 5, characterized in that, The core simulation of the sequence object based on the mapping sequencer includes: Multiple transactions are generated based on the sequence object, and transactions are extracted sequentially from the multiple transactions; The transaction is sent to the pre-built driver using the mapping sequencer, and then sent to the preset design module under test using the driver after sending, to obtain the target design module; The simulation is performed based on the target design module to complete the simulation of the transaction; The core simulation of the sequence object is completed when each of the multiple transactions has completed its simulation.

7. The verification method for UVM-based verification test cases as described in claim 6, characterized in that, The core simulation based on the target simulation verification platform also includes: The current number of incentives is detected based on a preset objection mechanism, which includes raise_objection and drop_objection. If the current number of incentives is not the preset zero value, return to the step of detecting the current number of incentives based on the preset Objection mechanism until the current number of incentives is zero. If the current stimulus quantity is zero, then stop the core simulation.

8. The verification method for UVM-based verification test cases as described in claim 7, characterized in that, The verification operation includes at least one of the following operations: extracting simulation result data, final verification check, generating test report, and releasing resources.

9. A verification system for verification test cases based on UVM, characterized in that, The system includes: The top-level file compilation module is used to receive user input information, identify the target top-level file based on the user input information, where the user input information includes the class name, the class name in the target top-level file is the same as the class name in the user input information, and perform compilation using the target top-level file. The compilation using the target top-level file includes: identifying the registration macros and constructors in the target top-level file, where the registration macros are object registration macros or component registration macros, and performing UVM factory registration and class initialization based on the registration macros and constructors respectively to complete the compilation. The test instance creation module is used to assign the class name from the user input information to the specified parameter of the test class, and replace the default value of the UVM core function run_test() with the assigned specified parameter of the test class to obtain the target UVM core function run_test(). The target UVM core function run_test() refers to the UVM core function run_test() after the default value is overridden. The specified parameter of the test class is used to specify the name of the test class and test cases to be run. When the target UVM core function run_test() is run, the test class instance is created. The verification platform construction module is used to perform construction phase operations based on test instances, obtain connection component information, hierarchical structure information and configuration information, and perform component connection operations based on the connection component information, hierarchical structure information and configuration information to obtain the original simulation verification platform; The core simulation execution module is used to sequentially perform platform checks and initialization on the original simulation verification platform to obtain the target simulation verification platform. Core simulation is then performed based on the target simulation verification platform. After the core simulation is completed, the verification operation is executed.

Images