Dynamic loading simulation verification method and system thereof

Abstract

This application provides a dynamically loaded simulation verification method and system. The method includes: saving a field data task; modifying the configuration file of the test cases executed in the field data task and saving it in a test case configuration module; restoring the field data task, and loading the configuration file in the test case configuration module, and loading test cases according to the configuration file or reloading test cases different from those executed in the field data task; and executing the loaded test cases. This application can reduce costs and improve the efficiency of integrated circuit verification simulation.

Description

Technical Field

[0001] This application relates to the field of integrated circuit simulation and testing technology, and more particularly to a dynamic loading simulation verification method and system thereof. Background Technology

[0002] Existing circuit simulation testing technologies are based on the UVM (Universal Verification Methodology) framework, which can solve the problems of standardizing and modularizing circuit simulation testing environments. The test process data all come from UVM sequences, which generally refer to the sequential combination of simulation stimulus data and are compiled as part of the test environment throughout the entire test environment.

[0003] During development, developers spend a significant amount of time and effort creating their own test cases and test sequences, compiling and running them to complete simulation testing. However, even the slightest modification to a test case requires recompilation and rerunning. Furthermore, some modules being verified need to be initialized before test case execution, and this initialization phase can consume substantial simulation time, potentially exceeding the test case's runtime, thus drastically reducing simulation efficiency.

[0004] Mainstream EDA (Electronic Design Automation) tools support save and restore or checkpoint functionality, allowing the context data of the circuit simulation at a specific point in time to be saved and directly loaded into that point in the next run. This feature can solve the problem of excessively long initialization time mentioned above. However, EDA tools can only shorten initialization time when the test cases and simulation environment remain unchanged. They are ineffective in situations most commonly encountered in circuit simulation work where the simulation environment remains the same but the test cases need to be changed.

[0005] Another mainstream simulation acceleration technique typically employs a hardware-software co-processing approach, using a hardware-software interface to execute time-consuming simulations on dedicated hardware. This technique is often used in the later stages of circuit verification and requires additional hardware support, resulting in higher costs. Summary of the Invention

[0006] The purpose of this application is to provide a dynamic loading simulation verification method and system, which can reduce costs and improve the efficiency of integrated circuit verification simulation.

[0007] This application discloses a simulation verification method with dynamic loading, including:

[0008] Task: Save on-site data;

[0009] Modify the configuration file of the test cases executed in the field data task and save it in the test case configuration module;

[0010] The system resumes the field data task, loads the configuration file in the test case configuration module, and loads test cases according to the configuration file or reloads test cases different from those executed in the field data task; and

[0011] Execute the loaded test cases.

[0012] In a preferred embodiment, prior to saving the field data task, the following is also included:

[0013] Compile the test environment and / or test cases; and

[0014] Initialize the test environment and the test cases.

[0015] In a preferred embodiment, after restoring the field data task, the method further includes: determining whether to run from the initial time; if not, running the test environment from the saved time.

[0016] In a preferred embodiment, the method further includes: determining whether to continue to the next test case; if so, loading and executing the test case.

[0017] In a preferred embodiment, the test cases are written in a scripting language or a custom language, or by dynamically loading symbol tables in software.

[0018] In a preferred embodiment, the field data task includes storing the circuit state and test environment context data at the point in time.

[0019] In a preferred embodiment, the configuration file includes the name of the test case, execution flow, task scheduling, circuit behavior control, and parameters.

[0020] This application also discloses a dynamic loading simulation verification system, comprising:

[0021] The task save and restore module is used to save or restore on-site data tasks;

[0022] The test case configuration module is used to save the configuration files of the test cases executed in the field data task and parse the configuration files;

[0023] The test case management module is used to load the configuration file in the test case configuration module after the task of restoring the field data is completed.

[0024] The test case module is used to store test case files; and

[0025] A test case loading and execution module is used to load and execute test cases from the test case module.

[0026] In a preferred embodiment, the test case loading and execution module interacts with the test environment through a verification / direct programming interface library.

[0027] Compared with traditional technical solutions, the implementation method of this application can reduce costs and improve the efficiency of integrated circuit verification and simulation. Attached Figure Description

[0028] Figure 1 This is a flowchart of a simulation verification method for dynamic loading according to an embodiment of this application.

[0029] Figure 2 This is a system block diagram for implementing simulation verification of dynamic loading according to an embodiment of this application.

[0030] Figure 3 This is a simulation verification process diagram for implementing dynamic loading according to an embodiment of this application. Detailed Implementation

[0031] In the following description, many technical details are presented to help the reader better understand this application. However, those skilled in the art will understand that the technical solutions claimed in this application can be implemented even without these technical details and various variations and modifications based on the following embodiments.

[0032] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0033] One embodiment of this application provides a simulation verification method for dynamic loading. Figure 1 A flowchart of a simulation verification method for dynamic loading according to an embodiment of this application is shown. The method includes the following steps:

[0034] Step 101: Save the field data task of the circuit simulation. In one embodiment, the field data task includes context data of the circuit state and test environment corresponding to the point in time of saving.

[0035] In one embodiment, before saving the field data task, the method further includes the steps of: compiling a test environment and / or test cases, and initializing the test environment and the test cases.

[0036] It should be noted that when the hardware circuit design or simulation environment changes, the test environment or test cases need to be recompiled. When the hardware circuit and the corresponding simulation environment remain unchanged, initialization can proceed directly without recompilation. Those skilled in the art will understand that in some cases, the hardware circuit design and simulation environment remain unchanged for a period of time; in such cases, recompilation of the test environment and test cases is unnecessary, and the compilation phase can be skipped to directly enter the runtime initialization phase. However, when it is necessary to switch the parameters and configurations of the hardware circuit or simulation environment, the compilation of the test environment and test cases must be recompiled.

[0037] When the hardware circuit design and simulation environment remain unchanged for a period of time, and the parameters and configurations of the hardware circuit or simulation environment do not change, the initialization phase can be skipped. That is, the test cases can be run directly without recompiling and rerunning the initialization phase. It should be understood that after the hardware circuit design and simulation environment stabilize, simulation tests under certain parameters and configurations will be repeatedly executed for a period of time. In this case, since the parameters and configurations of the hardware circuit or simulation environment remain unchanged, the initialization phase can be skipped.

[0038] In this embodiment, it is not necessary to rerun the compilation and initialization phases, modify the test case configuration file, and run the test directly.

[0039] Step 102: Modify the configuration file of the test cases executed in the field data task and save it in the test case configuration module. In one embodiment, the configuration file includes the name of the test case, execution flow, task scheduling, circuit behavior control, and parameters, etc.

[0040] Step 103: Restore the field data task, load the configuration file in the test case configuration module, and load test cases according to the configuration file or reload test cases that are different from the test cases executed in the field data task.

[0041] See Figure 2 The simulation verification system provided in one embodiment of this application includes a test case management module, a test case loading and execution module, a UVM / DPIC library, a test case configuration module, and a test case module.

[0042] The test case management module can load test case configuration information from the test case configuration module after restoring the saved time-point field data. The test case configuration information mainly includes relevant configuration files, such as the test case name, execution flow, task scheduling, circuit behavior control, and parameters. In this embodiment, the test case configuration module can configure or modify the test case configuration files to run different test cases without modifying the test environment.

[0043] The test case loading and execution module can load and execute test cases from the test case module after restoring the saved time-point data. The test case module stores test case files, and the language used in these files must be recognizable by the test case loading and execution module. The language used to write the test case files can be, for example, a mainstream scripting language, a custom language, or a method that dynamically loads symbol tables; this application does not impose any restrictions on this.

[0044] In some embodiments, the test case loading and execution module can be understood as a test case interpretation and execution module, capable of recognizing the language of the test cases and executing them; in some embodiments, the test case loading and execution module can also be implemented by an existing scripting language interpreter; this application does not impose any limitations on this. Embodiments of this application can modify or update test case files through the test case module, and directly load and execute the modified or updated test case files through the test case loading and execution module, thereby achieving online modification and execution of test cases. The test case loading and execution module can interact with the test environment through the DPIC interface.

[0045] The UVM / DPIC library standardizes and encapsulates the UVM framework and DPIC software modules. Relevant functionalities can be obtained from the UVM / DPIC library during test case execution. The DPIC software modules provide services to other modules via APIs.

[0046] In one embodiment, before restoring the field data task, the method further includes: determining whether to run from the initial time; if not, running the test environment from the saved time point. In one embodiment, the initial time is time point 0.

[0047] This application embodiment allows for the selective saving of field data at one or more time points. In this way, during the next run, if it is not necessary to start from the initial time (such as time point 0), a time point can be selected from the saved one or more time points as the starting point for operation, and the field data at that time point can be directly loaded based on the saved field data at that time point, thereby improving operating efficiency.

[0048] Step 104: Execute the loaded test cases.

[0049] As described above, in this embodiment of the application, the test case loading and execution module can load and execute relevant test cases from the test case module.

[0050] In one embodiment, the method further includes: determining whether to continue with the next test case; if so, loading and executing the test case. At this point, the test case loading and execution module loads the next test case from the test case module and executes it.

[0051] In summary, this application introduces a dynamic loading method, implementing dynamic loading through software to skip the recompilation and runtime initialization phases, directly entering the test case testing phase. This application significantly improves the efficiency of circuit simulation verification without increasing hardware costs, saving considerable time and reducing costs.

[0052] The following will combine Figure 3 The implementation process of the simulation verification method of this application is fully described, such as... Figure 3 As shown, this implementation process can be divided into the following steps: Figure 3 The three stages shown are: compilation stage, preparation stage, and verification stage, as detailed below:

[0053] Step 01: Simulation verification begins.

[0054] Step 02: Determine if it is necessary to compile the simulation environment or test cases. If so, proceed to Step 03; otherwise, proceed to Step 04, skipping the first stage (compilation stage) and proceeding to the second stage (preparation stage).

[0055] As mentioned above, if the hardware circuit design or simulation environment changes, it is necessary to recompile the test environment or test cases. If the hardware circuit remains unchanged, and the corresponding simulation environment also remains unchanged, the recompilation step can be skipped.

[0056] Step 03: Compile the simulation environment and test cases.

[0057] Step 04: Start running the simulation environment.

[0058] Step 05: Determine whether to start running from time point 0. If it is necessary to start running from time point 0, proceed to step 06 for initialization. If not, proceed to step 08, skipping steps 06 and 07 in the second stage and proceeding to the third stage (i.e., the verification stage).

[0059] As mentioned above, when the hardware circuit design and simulation environment remain unchanged for a period of time, and the parameters and configurations of the hardware circuit or simulation environment are unchanged, the initialization phase can be skipped.

[0060] Step 06: Perform necessary initialization of the test environment and hardware circuit initialization before test execution. In some embodiments, hardware circuit initialization includes the initialization of circuit parameters.

[0061] Step 07: Test preparation complete, save the field data of circuit simulation.

[0062] Step 08: Load the test case configuration information. As mentioned above, after restoring the saved site data, the test case management module can load the test case configuration information from the test case configuration module. This configuration information mainly consists of the test case configuration files, such as the test case name, execution flow, task scheduling, circuit behavior control, and parameters, etc.

[0063] Step 09: Execute the loaded test cases. The test case loading and execution module can load and execute test cases from the test case module.

[0064] Step 10: Determine whether to continue testing the next test case. If so, return to step 09, where the test case loading and execution module loads the next test case from the test case module and executes it. If not, proceed to step 11.

[0065] Step 11, End the test. It's clear from the above implementation process that, with only test cases modified, the test environment and test case compilation and initialization stages can be skipped, and the relevant test cases can be loaded and executed directly.

[0066] Taking the DDR subsystem as an example, this application's embodiments demonstrate the efficiency of simulation testing in several common scenarios. The compilation time for the DDR subsystem simulation environment is approximately 10 minutes; the initialization phase of the simulation environment (excluding the training and adjustment of electrical parameters such as signal levels and clock phases required before the DDR system operates normally to achieve optimal electrical characteristics and ensure signal integrity) takes approximately 40 minutes; and the test case execution takes approximately 20 minutes.

[0067] 1. The test environment and test cases remain unchanged; switch test cases. (Reference) Figure 3 In this scenario, the recompilation and initialization stages can be skipped directly, and the process can proceed directly to the third stage. After restoring the saved data at the time point, the relevant test cases can be loaded and executed directly, at which point the execution efficiency of the test cases is 100%.

[0068] 2. The test environment remained unchanged; the test cases were modified. (Reference) Figure 3This scenario is similar to the first scenario above. We can skip the recompilation and initialization stages and go directly to the third stage. The execution efficiency of the test cases is 100%.

[0069] 3. Modification of the DPIC (Direct Programming Interface C) software portion of the test environment. In this scenario, only the DPIC software portion needs to be recompiled; the entire test environment does not need to be recompiled. Compiling the DPIC software portion only takes about 2 minutes, followed by approximately 40 minutes of initialization and about 20 minutes of test case execution. In this case, the test case execution efficiency is 32%.

[0070] 4. Modifications to the SystemVerilog portion of the test environment. In this scenario, the entire test environment needs to be recompiled, taking approximately 10 minutes for compilation, 40 minutes for initialization, and 20 minutes for test case execution. At this point, the test case execution efficiency is 28%.

[0071] The probability of occurrence for the above four scenarios is approximately 20%, 50%, 20%, and 10% respectively (this will vary depending on the development stage), with an actual overall utilization rate of approximately 79%.

[0072] Existing simulation testing solutions, corresponding to the first scenario mentioned above, can skip the recompilation and initialization stages and directly enter the third stage by utilizing EDA's Save and Restore or checkpoint functions, achieving 100% test case execution efficiency. However, for the second, third, and fourth scenarios mentioned above, i.e., scenarios where the test environment or test cases have been modified, recompilation and initialization are all required, resulting in a test case execution efficiency of only 28%, and the actual overall utilization rate is far lower than that of this application.

[0073] One embodiment of this application also provides a simulation verification system, including: a task saving and restoring module, a test case management module, a test case loading and execution module, a test case configuration module, and a test case module.

[0074] The task save and restore module is used to save on-site data tasks.

[0075] The test case configuration module is used to save the configuration files of the test cases executed in the field data task and parse the configuration files.

[0076] The test case module is used to store test case files. The language used in these test case files must be recognizable by the test case loading and execution module. The language used to write the test case files can be, for example, a mainstream scripting language, a custom language, or a method that dynamically loads symbol tables; this application does not impose any restrictions on this.

[0077] Both the test case configuration module and the test case module are dynamically configurable or modifiable. The test case configuration module can be used to configure or modify the test case configuration file to run different test cases without changing the test environment. The test case module can be used to modify or update the test case file to modify or switch test cases, thereby achieving dynamic loading of test cases and their configuration information.

[0078] The test case management module is used to load the configuration file in the test case configuration module after the task of restoring the field data is completed.

[0079] The test case loading and execution module is used to load and execute the test cases from the test case module. In one embodiment, the test case loading and execution module can interact with the test environment through a verification / direct programming interface library. In some embodiments, the test case loading and execution module can be understood as a test case interpretation and execution module, which can recognize the language of the test case and execute the test case; in some embodiments, the test case loading and execution module can also be implemented by an existing scripting language interpreter; in some embodiments, the test case loading and execution module can also be implemented by dynamically loading a symbol table; this application does not limit this.

[0080] The simulation verification system also includes the UVM / DPIC library, which standardizes and encapsulates the UVM framework and DPIC software modules. Relevant functionalities can be obtained from the UVM / DPIC library during test case execution. The DPIC software modules provide services to other modules via APIs.

[0081] Based on whether the content stored within the module can be reconfigured after restoring the simulation site data, the test case management module, test case loading and execution module, and UVM / DPIC library can be classified as the static part of the verification system, while the test case configuration module and test case module can be classified as the dynamic part of the verification system.

[0082] It should be noted that in this patent application, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. In this patent application, if it refers to performing an action according to an element, it means performing the action at least according to that element, including two cases: performing the action only according to that element, and performing the action according to that element and other elements. Expressions such as "multiple," "repeatedly," and "various" include two, two times, two kinds, and more than two, more than two times, and more than two kinds.

[0083] This specification includes combinations of various embodiments described herein. Individual references to embodiments (e.g., “one embodiment”, “some embodiments”, or “preferred embodiments”) do not necessarily refer to the same embodiment; however, these embodiments are not mutually exclusive unless indicated to be mutually exclusive or are readily apparent to those skilled in the art. It should be noted that the word “or” is used in a non-exclusive sense throughout this specification unless the context explicitly indicates or requires it.

[0084] All references to this specification are considered to be incorporated integrally into the disclosure herein so that they can serve as a basis for modifications where necessary. Furthermore, it should be understood that the above descriptions are merely preferred embodiments of this specification and are not intended to limit the scope of protection of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the scope of protection of one or more embodiments of this specification.

Claims

1. A method of dynamic loading of simulation verification, characterized in that, comprising: a save session task including context data of a circuit state and a test environment corresponding to a save time point; modifying and saving a configuration file of a test case executed in the save session task in a test case configuration module, wherein the configuration file includes a name, an execution flow, a task schedule, a circuit behavior control and parameters of the test case; running the test environment from the save time point, restoring the save session task, and loading the modified configuration file in the test case configuration module, and loading the test case according to the configuration file; and executing the loaded test case.

2. The dynamically loaded simulation verification method of claim 1, wherein, Before saving the save session task, further comprising: compiling the test environment and / or the test case; and initializing the test environment and the test case.

3. The dynamically loaded simulation verification method of claim 1, wherein, Before restoring the save session task, further comprising: judging whether to run from an initial time, and if not, running the test environment from the save time.

4. The dynamically loaded simulation verification method of claim 1, wherein, Further comprising: judging whether to continue a next test case, and if so, loading and executing the test case.

5. The dynamically loaded simulation verification method of claim 1, wherein, The test case is written in a script language or a custom language, or is loaded in a software dynamic loading symbol table.

6. A dynamically loaded simulation verification system, comprising: comprising: a task save and restore module for saving or restoring a save session task including context data of a circuit state and a test environment corresponding to a save time point, and for running the test environment from the save time point and restoring the save session task; a test case configuration module for modifying and saving a configuration file of a test case executed in the save session task in a test case configuration module, wherein the configuration file includes a name, an execution flow, a task schedule, a circuit behavior control and parameters of the test case; a test case management module for loading the modified configuration file in the test case configuration module after restoring the save session task; a test case module for storing a test case file; and a test case loading and executing module for loading and executing a test case from the test case module.

7. The dynamically loaded simulation verification system of claim 6, wherein, The test case loading and executing module interacts with the test environment through a verification / direct programming interface library.

Images