Verification method and device, computer equipment and computer readable storage medium
By loading and executing new hex files during the VCS simulation process and saving and calling the simulation site, the problem of frequent compilation and simulation time is solved, and the simulation speed and flexibility are improved.
Patent Information
- Application Number
- CN202411780648.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-05
- Publication Date
- 2025-04-11
AI Technical Summary
During the VCS simulation process, users need to frequently adjust their use cases, resulting in wasted time for compilation and simulation. In the prior art, the public parts of basic testing implementation platform simulation need to be highly consistent, reducing the flexibility and efficiency of simulation.
By loading new hex files when executing a derived new use case, executing a new hex file, saving the simulation site, and calling the saved simulation site if needed, reducing the simulation time of the common part and improving simulation speed.
This method can effectively reduce compilation and simulation time, improve simulation speed, and improve simulation flexibility, avoiding the need to re-execute static packages.
Smart Images
Figure CN119806996A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer technology, and in particular to a verification method, apparatus, computer device and computer-readable storage medium. Background Art
[0002] When verifying a design project, you can use VCS simulation and VCS separate compilation.
[0003] Among them, VCS simulation can be divided into two-step method and three-step method.
[0004] Two-step method: first use VCS to compile and generate a sim file, and then execute this sim file for simulation.
[0005] Three-step method: separate the compilation vlogan and elaboration into two steps. Elaboration is to obtain the instantiation module from the library file, instantiate and link it, and then generate the simv file. Simulation requires loading different hex files and starting the simulation from time 0.
[0006] However, for VCS simulation, during the simulation debugging phase, users need to constantly adjust use cases. Regardless of whether it is the two-step method or the three-step method of VCS, users need to spend a lot of time recompiling and executing from time 0, which is a waste of time.
[0007] When the design is relatively large, VCS can be used for separate compilation. The unchanged content (common part) during the compilation and simulation process can be packaged in a package, called a static package (base_pkg). The basic test (base_test) based on the static package can be used to implement the common part of the platform simulation. At the location where the common part is executed, a snapshot point (save point) is set. When the simulation is executed to the snapshot point, the current simulation state is saved (savedesign); each new derived test case derived from the basic test case is packaged into a dynamic package (test_pkg). The dynamic package can include all test cases based on the basic test, so that these extended test cases can be compiled together when compiling the dynamic package. During simulation, the previously saved simulation state is restored first, and then multiple simulations are performed.
[0008] For VCS separate compilation, when the use case needs to be adjusted, only the dynamic package needs to be compiled, which can effectively reduce the time required for two-step and three-step compilation, and directly restore the previously saved simulation state during simulation, which can reduce the simulation time of the common part.
[0009] However, for the same version of DUT, the common parts of the basic test platform simulation need to be highly consistent, which greatly reduces the flexibility of the simulation. In addition, when the basic test needs to load the hex file generated by software compilation, the basic test file itself has not changed, but when the software changes, the static package needs to be re-executed, which greatly reduces the simulation efficiency. Summary of the invention
[0010] The embodiments of the present application provide a verification method, apparatus, computer device, computer-readable storage medium, and computer program product, which can solve at least one technical problem in the background technology.
[0011] In view of this, in a first aspect, an embodiment of the present application provides a verification method based on VCS separate compilation verification, the verification method comprising:
[0012] The following steps are performed when deriving a new use case:
[0013] Loading a new hex file and executing the new hex file;
[0014] After the execution of the new hex file is completed, saving the first simulation scene;
[0015] Calling the saved first simulation scene;
[0016] After the calling of the saved first simulation scene is completed, another derived new use case is executed.
[0017] In one embodiment, the loading of the new hex file and the execution of the new hex file include:
[0018] The CPU core is powered off;
[0019] After the CPU core is powered off, the new hex file is loaded into the boot read-only memory to overwrite the common hex file in the boot read-only memory;
[0020] CPU core is powered on;
[0021] After the CPU core is powered on, the new hex file is executed to complete the user configuration.
[0022] In one embodiment, the loading of the new hex file and the execution of the new hex file include:
[0023] Loading the new hex file to an address outside the startup read-only memory, wherein the startup read-only memory is loaded with the common part hex file;
[0024] Execute the new hex file.
[0025] In one implementation, the common part hex file specifies the loading address of the new hex file; after the common part hex file is executed, it points to the loading address of the new hex file.
[0026] In one embodiment, before the execution of deriving a new use case, the process includes:
[0027] Package the unchanged contents during the compilation and simulation process as a common part to generate a static package;
[0028] Writing a top-level module of the verification platform and importing the static package at the beginning of the top-level module;
[0029] Compile the static package;
[0030] Perform basic tests where the common portion hex file is loaded into the boot ROM;
[0031] After the execution of the basic test is completed, saving the second simulation scene;
[0032] Generate a dynamic package, wherein the dynamic package includes each new derived test case derived from the basic test case;
[0033] Compiling the dynamic package;
[0034] The saved second simulation scene is called.
[0035] In a second aspect, the embodiment of the present application further provides a verification device, based on VCS separation compilation verification, comprising:
[0036] Multiple modules for performing functional operations when deriving new use cases are executed, and the modules include:
[0037] A loading and executing module, used for loading a new hex file and executing the new hex file;
[0038] A saving module, used for saving the first simulation scene after the execution of the new hex file is completed;
[0039] A calling module is used to call the saved first simulation scene.
[0040] In one embodiment, the loading of the new hex file and the execution of the new hex file include:
[0041] The CPU core is powered off;
[0042] After the CPU core is powered off, the new hex file is loaded into the boot read-only memory to overwrite the common hex file in the boot read-only memory;
[0043] CPU core is powered on;
[0044] After the CPU core is powered on, the new hex file is executed to complete the user configuration.
[0045] In one embodiment, the loading of the new hex file and the execution of the new hex file include:
[0046] Loading the new hex file to an address outside the startup read-only memory, wherein the startup read-only memory is loaded with the common part hex file;
[0047] Execute the new hex file.
[0048] In a third aspect, an embodiment of the present application further provides a computer device, including a memory and a processor;
[0049] The memory is connected to the processor, the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the verification method described in any one of the first aspects.
[0050] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and the computer program is suitable for being loaded by a processor and executing any one of the verification methods in the first aspect.
[0051] In a fifth aspect, an embodiment of the present application further provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of any one of the verification methods described in the first aspect.
[0052] The above verification method, apparatus, computer device, computer-readable storage medium and computer program product, when executing a derived new use case, first load a new hex file and execute the new hex file, after the execution of the new hex file is completed, save the first simulation scene, then call the saved first simulation scene, after the call of the saved first simulation scene is completed, execute another derived new use case. This application can save the simulation time of the common part and effectively improve the simulation speed. BRIEF DESCRIPTION OF THE DRAWINGS
[0053] Figure 1 The figure is a flow chart of the verification method in the prior art.
[0054] Figure 2 This is a partial flow chart of the verification method of the embodiment of the present application.
[0055] Figure 3 The figure is a flow chart of the verification method according to the embodiment of the present application.
[0056] Figure 4 This is a partial flow chart of a verification method according to another embodiment of the present application.
[0057] Figure 5 This is a flowchart of a verification method according to another embodiment of the present application.
[0058] Figure 6 It is a schematic diagram of a verification device according to an embodiment of the present application.
[0059] Figure 7 It is a schematic diagram of a computer device according to an embodiment of the present application. DETAILED DESCRIPTION
[0060] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0061] See also Figure 1 The existing verification method based on VCS separate compilation includes the following steps:
[0062] S11, packaging the unchanged contents during the compilation simulation process as a common part to generate a static package base_pkg.
[0063] Specifically, the unchanged contents during the compilation simulation process include DUT, VIP, etc.
[0064] The pkg files imported into the static package base_pkg usually come from the vip pkg files and uvm pkg files imported into the top-level module (top.sv).
[0065] The following is an example of a code snippet for generating a static package base_pkg:
[0066] package base_pkg;
[0067] `include "uvm_macros.svh"
[0068] import uvm_pkg::*;
[0069] import svt_uvm_pkg::*;
[0070] import env_pkg::*;
[0071] `include "base_test.sv"
[0072] endpackage:base_pkg
[0073] import base_pkg::*;
[0074] S12, write the top-level module top.sv of the verification platform and import the static package base_pkg at the beginning of the top-level module top.sv.
[0075] The following is an example code snippet for writing the top-level module top.sv of the testbench:
[0076] import uvm_pkg::*;
[0077] import env_pkg::*;
[0078] import base_pkg::*;
[0079] S13, compile the static package base_pkg.
[0080] The following is an example code snippet for compiling a static package base_pkg:
[0081] PT_CMP_OPTS+=-partcomp$(tb_top)base_pkg-dir=$(CMP_PATH) / partcomp-enable_dynamic_tb-pcmakeprof
[0082] S14, execute basic test base_test.
[0083] When executing the basic test base_test, the common part hex file is loaded into the boot read-only memory bootrom. The common part hex file is loaded into the boot read-only memory bootrom and can be used as a boot loader (bootloader), which mainly completes the system power-on process and initializes the system clock.
[0084] S15, after the basic test base_test is executed, the simulation scene saveddesign is saved (that is, the scene from 0ns in the simulation process to the completion of the basic test base_test is saved).
[0085] It is necessary to add snapshot points during the basic test base_test simulation process. When the simulation runs to the snapshot point, the simulation scene saveddesign is saved.
[0086] Specifically, you can specify to save the scene from 0ns to the set time during the simulation. As shown in the following code snippet, you can save the simulation scene saveddesign from 0ns to 5ns.
[0087] Stop-relative 5ns-once-continue-command{run 0; save.. / saveddesign; puts "SAVE RESTORE simulation state SAVED at time=$now"; run}
[0088] You can also specify a fixed position in the basic test base_test as a snapshot point. As shown in the following code snippet, for_dtl_save1 in the basic test base_test can be used as a snapshot point.
[0089] task base_test::for_dtl_save1();
[0090] `uvm_info(get_type_name(),"dtl save point 1...", UVM_MEDIUM);
[0091] #10ns;
[0092] Endtask
[0093] As shown in the following code snippet, you can save the simulation scene saveddesign from 0 to execution to for_dtl_save1.
[0094] stop-in base_test::for_dtl_save1-once-continue-command{run0; save.. / saveddesign; puts "SAVE RESTORE simulation state SAVED at time=$now"; run}
[0095] S16, generating a dynamic package test_pkg, wherein the dynamic package test_pkg includes each new test case derived from the basic test case.
[0096] Specifically, the dynamic package test_pkg mainly packages each new test case derived from the basic test case, and also includes the pkg file imported in the top-level module top.sv, as well as the modified files and new test cases used in the new test case. The dynamic package test_pkg can include all test cases based on the basic test base_test, so that when compiling the dynamic package test_pkg, these extended test cases can be compiled together and then simulated multiple times.
[0097] The following is an example of a code snippet that generates a dynamic package test_pkg:
[0098] package test_pkg;
[0099] `include "uvm_macros.svh"
[0100] import uvm_pkg::*;
[0101] import svt_uvm_pkg::*;
[0102] import env_pkg::*;
[0103] import base_pkg::*;
[0104] `include "tc_test1_sanity.sv"
[0105] `include "tc_test2_sanity.sv"
[0106] `include "tc_test3_sanity.sv"
[0107] endpackage:test_pkg
[0108] S17, compile the dynamic package test_pkg.
[0109] The following is an example code snippet for compiling a dynamic package test_pkg:
[0110] PT_CMP_OPTS+=-sharedlib=$(CMP_PATH) / partcomp-partcomp test_pkg-dir=$(CMP_PATH) / dynamic_test_base-dynamic_tb-pcmakeprof
[0111] S18, call the saved simulation scene saveddesign.
[0112] Derive a new use case simulation by restoring saveddesign, you can directly call the simulation scene saved at the snapshot point.
[0113] The following is an example of a code snippet that calls a saved simulation scene:
[0114] restore.. / saveddesign
[0115] echo "Restore simulation and current simulation time=$now\n"
[0116] call\$dtl_load
[0117] call tb.refresh
[0118] Run
[0119] S19, execute the derived new use case.
[0120] After calling the saved simulation scene, you can execute the derived new use case.
[0121] The above verification method based on VCS separate compilation has the following technical problems:
[0122] For the same version of DUT, the common parts of the basic test implementation platform simulation need to remain highly consistent, which greatly reduces the flexibility of the simulation.
[0123] In addition, when the hex file generated by software compilation needs to be loaded in the basic test, the basic test file itself does not change much, but when the software changes, the static package needs to be re-executed, which greatly reduces the simulation efficiency.
[0124] Based on the above situation, an embodiment of the present application proposes a verification method, which aims to solve at least part of the above-mentioned technical problems.
[0125] Please combine Figure 2 The verification method of this application is based on VCS separate compilation verification. The verification method includes:
[0126] The following steps are performed when deriving a new use case:
[0127] S201, loading a new hex file and executing the new hex file.
[0128] The new hex file can be a new hex file generated by rewriting the software according to one's own needs. The new hex file can be loaded into the boot read-only memory to overwrite the public part hex file in the boot read-only memory boot rom. The new hex file can also be loaded to an address outside the boot read-only memory boot rom. At this time, the new hex file can be a user part hex file different from the public part hex file. In the execution of the derived new use case, the user part hex file can be loaded into the user rom, and the user rom can specify the address to jump to after the execution of the public part hex file is completed.
[0129] S202, after the execution of the new hex file is completed, save the simulation scene saveddesign1 (ie, the first simulation scene named in claim 1).
[0130] In order to save the simulation scene saveddesign1, you can set a snapshot point. When the simulation runs to the snapshot point, the simulation scene saveddesign1 will be saved.
[0131] S203, calling the saved simulation scene saveddesign1.
[0132] Before executing another derived new use case, you can directly call the simulation scene saveddesign1 saved at the snapshot point by restoring saveddesign1.
[0133] S204, after calling the saved simulation scene saveddesign1, execute another derived new use case.
[0134] In this application, when executing a derived new use case, first load a new hex file and execute the new hex file. After the execution of the new hex file is completed, save the simulation scene saveddesign1, and then call the saved simulation scene saveddesign1. After the call of the saved simulation scene saveddesign1 is completed, execute another derived new use case. This application can save the simulation time of the common part and effectively improve the simulation speed.
[0135] In order to facilitate the understanding of the present application, based on the different properties of the new hex file, the verification method of the present application is specifically described in Example 1 and Example 2 respectively.
[0136] Embodiment 1
[0137] See also Figure 2 , the verification method of this embodiment includes:
[0138] The following steps are performed when deriving a new use case:
[0139] S291, CPU core powered off.
[0140] The CPU core must complete the power-off process according to the process to execute the next loading step.
[0141] S292, after the CPU core is powered off, a new hex file is loaded into the boot read-only memory boot rom to overwrite the common part hex file in the boot read-only memory boot rom.
[0142] Users can rewrite the software according to their needs and generate a new hex file. After the CPU core is powered off, the new hex file is loaded into the boot ROM, so that the original public part hex file in the boot ROM will be overwritten and replaced by the new hex file.
[0143] S293, the CPU core is powered on.
[0144] The CPU core must complete the power-on process according to the process to execute the new hex file.
[0145] S294, after the CPU core is powered on, execute the new hex file to complete the user configuration.
[0146] S295, after executing the new hex file, save the simulation scene saveddesign1.
[0147] S296, call the saved simulation scene saveddesign1.
[0148] After this step is completed, just focus on deriving new use cases.
[0149] S297, after calling the saved simulation scene saveddesign1, execute another derived new use case.
[0150] For some users, the hex file configuration process included in the basic test base_test does not meet the current needs, but the sv configuration process included in the basic test base_test still meets the current needs. In this regard, the user can rewrite the software, generate a new hex file, and execute the derived new use case to complete the configuration based on user needs. Based on this embodiment, the user can retain the sv configuration process in the basic test bast_test and cover the configuration process brought by the public part hex file, which saves the sv configuration process simulation time and greatly improves the simulation speed.
[0151] In order to better understand this embodiment, Figure 3 The verification method of this embodiment is described in more detail. The verification method of this embodiment includes:
[0152] S21, packaging the unchanged contents during the compilation simulation process as a common part to generate a static package base_pkg.
[0153] Specifically, the unchanged contents during the compilation simulation process include DUT, VIP, etc.
[0154] The pkg files imported into the static package base_pkg usually come from the vip pkg files and uvm pkg files imported into the top-level module (top.sv).
[0155] The following is an example of a code snippet for generating a static package base_pkg:
[0156] package base_pkg;
[0157] `include "uvm_macros.svh"
[0158] import uvm_pkg::*;
[0159] import svt_uvm_pkg::*;
[0160] import env_pkg::*;
[0161] `include "base_test.sv"
[0162] endpackage:base_pkg
[0163] import base_pkg::*;
[0164] S22, write the top-level module top.sv of the verification platform and import the static package base_pkg at the beginning of the top-level module top.sv.
[0165] The following is an example code snippet for writing the top-level module top.sv of the testbench:
[0166] import uvm_pkg::*;
[0167] import env_pkg::*;
[0168] import base_pkg::*;
[0169] S23, compile the static package base_pkg.
[0170] The following is an example code snippet for compiling a static package base_pkg:
[0171] PT_CMP_OPTS+=-partcomp$(tb_top)base_pkg-dir=$(CMP_PATH) / partcomp-enable_dynamic_tb-pcmakeprof
[0172] S24, execute basic test base_test.
[0173] When executing the basic test base_test, the common part hex file is loaded into the boot read-only memory bootrom. The common part hex file is loaded into the boot read-only memory bootrom and can be used as a boot loader (bootloader), which mainly completes the system power-on process and initializes the system clock.
[0174] S25, after the basic test base_test is completed, the simulation scene saveddesign is saved (that is, the scene from 0ns in the simulation process to the completion of the basic test base_test is saved).
[0175] It is necessary to add snapshot points during the basic test base_test simulation process. When the simulation runs to the snapshot point, the simulation scene saveddesign is saved.
[0176] Specifically, you can specify to save the scene from 0ns to the set time during the simulation. As shown in the following code snippet, you can save the simulation scene saveddesign from 0ns to 5ns.
[0177] Stop-relative 5ns-once-continue-command{run 0; save.. / saveddesign; puts "SAVE RESTORE simulation state SAVED at time=$now"; run}
[0178] You can also specify a fixed position in the basic test base_test as a snapshot point. As shown in the following code snippet, for_dtl_save1 in the basic test base_test can be used as a snapshot point.
[0179] task base_test::for_dtl_save1();
[0180] `uvm_info(get_type_name(),"dtl save point 1...", UVM_MEDIUM);
[0181] #10ns;
[0182] Endtask
[0183] As shown in the following code snippet, you can save the simulation scene saveddesign from 0 to execution to for_dtl_save1.
[0184] stop-in base_test::for_dtl_save1-once-continue-command{run0; save.. / saveddesign; puts "SAVE RESTORE simulation state SAVED at time=$now"; run}
[0185] S26, generating a dynamic package test_pkg, wherein the dynamic package test_pkg includes each new test case derived from the basic test case.
[0186] Specifically, the dynamic package test_pkg mainly packages each new test case derived from the basic test case, and also includes the pkg file imported in the top-level module top.sv, as well as the modified files and new test cases used in the new test case. The dynamic package test_pkg can include all test cases based on the basic test base_test, so that when compiling the dynamic package test_pkg, these extended test cases can be compiled together and then simulated multiple times.
[0187] The following is an example of a code snippet that generates a dynamic package test_pkg:
[0188] package test_pkg;
[0189] `include "uvm-macros.svh"
[0190] import uvm_pkg::*;
[0191] import svt_uvm_pkg::*;
[0192] import env_pkg::*;
[0193] import base_pkg::*;
[0194] `include "tc_test1_sanity.sv"
[0195] `include "tc_test2_sanity.sv"
[0196] `include "tc_test3_sanity.sv"
[0197] endpackage:test_pkg
[0198] S27, compile the dynamic package test_pkg.
[0199] The following is an example code snippet for compiling a dynamic package test_pkg:
[0200] PT_CMP_OPTS+=-sharedlib=$(CMP_PATH) / partcomp-partcomp test_pkg-dir=$(CMP_PATH) / dynamic_test_base-dynamic_tb-pcmakeprof
[0201] S28, call the saved simulation scene saveddesign.
[0202] Derive a new use case simulation by restoring saveddesign, you can directly call the simulation scene saved at the snapshot point.
[0203] The following is an example of a code snippet that calls a saved simulation scene:
[0204] restore.. / saveddesign
[0205] echo "Restore simulation and current simulation time=$now\n"
[0206] call\$dtl_load
[0207] call tb.refresh
[0208] Run
[0209] S29, execute the derived new use case 1.
[0210] After calling the saved simulation scene, the derived new use case 1 can be executed.
[0211] When executing the new use case 1, complete the following steps:
[0212] S291, CPU core powered off.
[0213] S292, after the CPU core is powered off, a new hex file is loaded into the boot read-only memory boot rom to overwrite the common part hex file in the boot read-only memory boot rom.
[0214] S293, the CPU core is powered on.
[0215] S294, after the CPU core is powered on, execute the new hex file to complete the user configuration.
[0216] S295, after executing the new hex file, save the simulation scene saveddesign1.
[0217] S296, call the saved simulation scene saveddesign1.
[0218] S297, after calling the saved simulation scene saveddesign1, execute the derived new use case 2.
[0219] In this embodiment, the user can retain the SV configuration process in the basic test bast_test and cover the configuration process brought by the public part hex file, which saves the simulation time of the SV configuration process and greatly improves the simulation speed.
[0220] Embodiment 2
[0221] See also Figure 4 , the verification method of this embodiment includes:
[0222] The following steps are performed when deriving a new use case:
[0223] S391, loading a new hex file to an address outside the boot read-only memory boot rom, where the boot read-only memory boot rom is loaded with the common part hex file.
[0224] Users can write software according to their own needs to generate a new hex file. In this embodiment, the new hex file is not used to replace or overwrite the public part hex file, and can be regarded as a user part hex file. Therefore, in this derived new use case, the user part hex file needs to be loaded to an address outside the boot read-only memory, which can be defined as userrom. After the public part hex file is executed, it will jump to this address.
[0225] Specifically, the public part hex file specifies a loading address of the new hex file; after the public part hex file is executed, it points to the loading address of the new hex file.
[0226] S392, execute the new hex file.
[0227] After the new hex file is executed, user initialization is completed.
[0228] S393, after executing the new hex file, save the simulation scene saveddesign1.
[0229] S394, calls the saved simulation scene saveddesign1.
[0230] After this step is completed, just focus on deriving new use cases.
[0231] S395, after calling the saved simulation scene saveddesign1, execute another derived new use case.
[0232] For some users, the hex file configuration process included in the basic test base_test does not fully meet the current needs. The user not only needs to keep the configuration process of the public part hex file, but also needs to add other configuration processes in the user part hex file. In this case, the user needs to keep the configuration process in the public part hex file, so the user part hex file cannot be loaded to the boot rom address, and the user part hex file needs to be executed in the derived new use case. For this embodiment, the user keeps all the configuration processes in the basic test bast_test and adds a new configuration process, which not only improves the simulation flexibility, but also omits the simulation time of all public parts, greatly improving the simulation speed.
[0233] In order to better understand this embodiment, Figure 5 The verification method of this embodiment is described in more detail. The verification method of this embodiment includes:
[0234] S31, packaging the unchanged contents during the compilation simulation process as a common part to generate a static package base_pkg.
[0235] Specifically, the unchanged contents during the compilation simulation process include DUT, VIP, etc.
[0236] The pkg files imported into the static package base_pkg usually come from the vip pkg files and uvm pkg files imported into the top-level module (top.sv).
[0237] The following is an example of a code snippet for generating a static package base_pkg:
[0238] package base_pkg;
[0239] `include "uvm_macros.svh"
[0240] import uvm_pkg::*;
[0241] import svt_uvm_pkg::*;
[0242] import env_pkg::*;
[0243] `include "base_test.sv"
[0244] endpackage:base_pkg
[0245] import base_pkg::*;
[0246] S32, write the top-level module top.sv of the verification platform and import the static package base_pkg at the beginning of the top-level module top.sv.
[0247] The following is an example code snippet for writing the top-level module top.sv of the testbench:
[0248] import uvm_pkg::*;
[0249] import env_pkg::*;
[0250] import base_pkg::*;
[0251] S33, compile the static package base_pkg.
[0252] The following is an example code snippet for compiling a static package base_pkg:
[0253] PT_CMP_OPTS+=-partcomp$(tb_top)base_pkg-dir=$(CMP_PATH) / partcomp-enable_dynamic_tb-pcmakeprof
[0254] S34, execute basic test base_test.
[0255] When executing the basic test base_test, the common part hex file is loaded into the boot read-only memory bootrom. The common part hex file is loaded into the boot read-only memory bootrom and can be used as a boot loader (bootloader), which mainly completes the system power-on process and initializes the system clock.
[0256] S35, after the basic test base_test is completed, the simulation scene saveddesign is saved (that is, the scene from 0ns in the simulation process to the completion of the basic test base_test is saved).
[0257] It is necessary to add snapshot points during the basic test base_test simulation process. When the simulation runs to the snapshot point, the simulation scene saveddesign is saved.
[0258] Specifically, you can specify to save the scene from 0ns to the set time during the simulation. As shown in the following code snippet, you can save the simulation scene saveddesign from 0ns to 5ns.
[0259] Stop-relative 5ns-once-continue-command{run 0; save.. / saveddesign; puts "SAVE RESTORE simulation state SAVED at time=$now"; run}
[0260] You can also specify a fixed position in the basic test base_test as a snapshot point. As shown in the following code snippet, for_dtl_save1 in the basic test base_test can be used as a snapshot point.
[0261] task base_test::for_dtl_save1();
[0262] `uvm_info(get_type_name(),"dtl save point 1...", UVM_MEDIUM);
[0263] #10ns;
[0264] Endtask
[0265] As shown in the following code snippet, you can save the simulation scene saveddesign from 0 to execution to for_dtl_save1.
[0266] stop-in base_test::for_dtl_save1-once-continue-command{run0; save.. / saveddesign; puts "SAVE RESTORE simulation state SAVED at time=$now"; run}
[0267] S36, generating a dynamic package test_pkg, wherein the dynamic package test_pkg includes each new test case derived from the basic test case.
[0268] Specifically, the dynamic package test_pkg mainly packages each new test case derived from the basic test case, and also includes the pkg file imported in the top-level module top.sv, as well as the modified files and new test cases used in the new test case. The dynamic package test_pkg can include all test cases based on the basic test base_test, so that when compiling the dynamic package test_pkg, these extended test cases can be compiled together and then simulated multiple times.
[0269] The following is an example of a code snippet that generates a dynamic package test_pkg:
[0270] package test_pkg;
[0271] `include "uvm_macros.svh"
[0272] import uvm_pkg::*;
[0273] import svt_uvm_pkg::*;
[0274] import env_pkg::*;
[0275] import base_pkg::*;
[0276] `include "tc_test1_sanity.sv"
[0277] `include "tc_test2_sanity.sv"
[0278] `include "tc_test3_sanity.sv"
[0279] endpackage:test_pkg
[0280] S37, compile dynamic package test_pkg.
[0281] The following is an example code snippet for compiling a dynamic package test_pkg:
[0282] PT_CMP_OPTS+=-sharedlib=$(CMP_PATH) / partcomp-partcomp test_pkg-dir=$(CMP_PATH) / dynamic_test_base-dynamic_tb-pcmakeprof
[0283] S38, call the saved simulation scene saveddesign.
[0284] Derive a new use case simulation by restoring saveddesign, you can directly call the simulation scene saved at the snapshot point.
[0285] The following is an example of a code snippet that calls a saved simulation scene:
[0286] restore.. / saveddesign
[0287] echo "Restore simulation and current simulation time=$now\n"
[0288] call\$dtl_load
[0289] call tb.refresh
[0290] Run
[0291] S39, execute the derived new use case 1.
[0292] After calling the saved simulation scene, the derived new use case 1 can be executed.
[0293] When executing the new use case 1, complete the following steps:
[0294] S391, loading a new hex file to an address outside the boot read-only memory boot rom, where the boot read-only memory boot rom is loaded with the common part hex file.
[0295] S392, execute the new hex file.
[0296] S393, after executing the new hex file, save the simulation scene saveddesign1.
[0297] S394, calls the saved simulation scene saveddesign1.
[0298] S395, after calling the saved simulation scene saveddesign1, execute the derived new use case 2.
[0299] In this embodiment, the user retains all configuration processes in the basic test bast_test and adds new configuration processes, which not only improves the simulation flexibility but also omits the simulation time of all common parts, greatly improving the simulation speed.
[0300] In this application, users can write software according to their own needs and generate new hex files, which can be used as bootloader according to Example 1, or as user software to supplement the bootloader according to Example 2, thereby improving the flexibility of simulation.
[0301] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.
[0302] Based on the same inventive concept, the embodiment of the present application also provides a verification device for implementing the verification method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations / descriptions in the verification device embodiment provided below can refer to the limitations / descriptions of the interrupt handling method above, and will not be repeated here.
[0303] See also Figure 6 The verification device of the embodiment of the present application is based on VCS separation compilation verification. The verification device includes:
[0304] Multiple modules for performing functional operations when deriving new use cases are executed, and the modules include:
[0305] A loading and executing module 501 is used to load a new hex file and execute the new hex file;
[0306] A saving module 502, configured to save the first simulation scene after the execution of the new hex file is completed;
[0307] The calling module 503 is used to call the saved first simulation scene.
[0308] This application can save simulation time of the common part and effectively improve the simulation speed.
[0309] In some embodiments, the loading of the new hex file and the execution of the new hex file include:
[0310] The CPU core is powered off;
[0311] After the CPU core is powered off, the new hex file is loaded into the boot read-only memory to overwrite the common hex file in the boot read-only memory;
[0312] CPU core is powered on;
[0313] After the CPU core is powered on, the new hex file is executed to complete the user configuration.
[0314] For some users, the hex file configuration process included in the basic test base_test does not meet the current needs, but the sv configuration process included in the basic test base_test still meets the current needs. In this regard, the user can rewrite the software, generate a new hex file, and execute the derived new use case to complete the configuration based on user needs. Based on this embodiment, the user can retain the sv configuration process in the basic test bast_test and cover the configuration process brought by the public part hex file, which saves the sv configuration process simulation time and greatly improves the simulation speed.
[0315] In some other embodiments, the loading of the new hex file and the execution of the new hex file include:
[0316] Loading the new hex file to an address outside the startup read-only memory, wherein the startup read-only memory is loaded with the common part hex file;
[0317] Execute the new hex file.
[0318] For another part of users, the hex file configuration process included in the basic test base_test does not fully meet the current needs. The user not only needs to keep the configuration process of the public part hex file, but also needs to add other configuration processes in the user part hex file. In this case, the user needs to keep the configuration process in the public part hex file, so the user part hex file cannot be loaded to the boot rom address, and the user part hex file needs to be executed in the derived new use case. For this embodiment, the user keeps all the configuration processes in the basic test bast_test and adds a new configuration process, which not only improves the simulation flexibility, but also omits the simulation time of all public parts, greatly improving the simulation speed.
[0319] In the embodiments of the present application, the term "module" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.
[0320] Figure 7 Schematic diagram of the structure of a computer device provided in an embodiment of the present application. Figure 7 As shown, the computer device may include: a processor 601 and a memory 602. The memory 602 is connected to the processor 601, and the memory 602 is used to store a computer program. The processor 301 is used to call the computer program so that the computer device executes the verification method described in the above embodiment. In addition, the above-mentioned computer device may also include: at least one communication bus 603. Among them, the communication bus 603 is used to realize the connection communication between components. The memory 602 can be a high-speed RAM memory, or a non-volatile memory, such as at least one disk memory.
[0321] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. The computer program is suitable for being loaded by a processor and executing the verification method described in the above embodiment.
[0322] The embodiment of the present application also provides a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. The processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the electronic device performs the verification method described in the above embodiment.
[0323] It should be understood that in the embodiments of the present application, the processor referred to may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.
[0324] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by hardware related to computer program instructions, and the program can be stored in a computer-readable storage medium, and when the program is executed, it can include the processes of the embodiments of the above-mentioned methods. The storage medium can be a disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM), etc.
[0325] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.
[0326] The above disclosure is only a preferred example of the present application and cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are all within the scope covered by the present application.
Claims
1. A verification method based on VCS separation compilation verification, characterized in that: The verification method comprises: The following steps are completed when deriving a new use case: Loading a new hex file and executing the new hex file; After the execution of the new hex file is completed, saving the first simulation scene; Calling the saved first simulation scene; After the calling of the saved first simulation scene is completed, another derived new use case is executed.
2. The verification method according to claim 1, characterized in that: The loading of the new hex file and the execution of the new hex file include: The CPU core is powered off; After the CPU core is powered off, the new hex file is loaded into the boot read-only memory to overwrite the common hex file in the boot read-only memory; CPU core is powered on; After the CPU core is powered on, the new hex file is executed to complete the user configuration.
3. The verification method according to claim 1, characterized in that: The loading of the new hex file and the execution of the new hex file include: Loading the new hex file to an address outside the startup read-only memory, wherein the startup read-only memory is loaded with the common part hex file; Execute the new hex file.
4. The verification method according to claim 3, characterized in that: The public part hex file specifies the loading address of the new hex file; After the public part hex file is executed, it points to the loading address of the new hex file.
5. The verification method according to claim 1, characterized in that: Before the execution of deriving a new use case, the following steps are included: Package the unchanged contents during the compilation and simulation process as a common part to generate a static package; Writing a top-level module of the verification platform and importing the static package at the beginning of the top-level module; Compile the static package; Perform basic tests where the common portion hex file is loaded into the boot ROM; After the execution of the basic test is completed, saving the second simulation scene; Generate a dynamic package, wherein the dynamic package includes each new derived test case derived from the basic test case; Compiling the dynamic package; The saved second simulation scene is called.
6. A verification device, based on VCS separation compilation verification, characterized in that: include: Multiple modules for performing functional operations when deriving new use cases are executed, and the modules include: A loading and execution module, used for loading a new hex file and executing the new hex file; A saving module, used for saving the first simulation scene after the execution of the new hex file is completed; The calling module is used to call the saved first simulation scene.
7. The authenticator device according to claim 6, characterized in that: The loading of the new hex file and the execution of the new hex file include: The CPU core is powered off; After the CPU core is powered off, the new hex file is loaded into the boot read-only memory to overwrite the common hex file in the boot read-only memory; CPU core is powered on; After the CPU core is powered on, the new hex file is executed to complete the user configuration.
8. The verification device according to claim 6, characterized in that: The loading of the new hex file and the execution of the new hex file include: Loading the new hex file to an address outside the startup read-only memory, wherein the startup read-only memory is loaded with the common part hex file; Execute the new hex file.
9. A computer device, characterized in that: including memory and processor; The memory is connected to the processor, the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the verification method according to any one of claims 1 to 5.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and the computer program is suitable for being loaded by a processor and executing the verification method according to any one of claims 1 to 5.