Verification system, verification method, electronic device, and storage medium

Abstract

The present disclosure provides a verification system, a verification method, an electronic device and a storage medium. The verification system comprises a simulation verification device, a first part and a second part. The first part comprises a first master module and a second slave module. The second slave module comprises a storage unit connected with a memory access interface of a peripheral of a to-be-tested module. The second part comprises a first and a second direct programming interface, a function library module and a test case module for providing a test case. The first direct programming interface communicates with the first master module and is configured to, in response to running the test case, call a first function of the function library module to realize front door access of a register of the to-be-tested module. The second direct programming interface communicates with the storage unit and is configured to, in response to running the test case, call a second function of the function library module to realize back door access of the storage unit. The verification system realizes synchronization between the software side and the hardware side, facilitates function verification of the to-be-tested module, consumes less simulation time and realizes reusable verification of a chip.

Description

Technical Field

[0001] Embodiments of this disclosure relate to a verification system, verification method, electronic device, and storage medium. Background Technology

[0002] Currently, with the rapid development of the electronic information industry, the scale of System On Chip (SoC) is getting larger and larger, and the chip verification work, which accounts for nearly 70% of the total chip development workload on average, is becoming more and more complex, and the requirements for chip risk control are also getting higher and higher.

[0003] The hardware models accompanying Very Large Scale Integration (VLSI) integrated circuit chips become extremely complex, significantly increasing the computational load for design and verification. Therefore, for highly complex functional testing scenarios, the speed, capacity, and efficiency of Electronic Design Automation (EDA) simulations are often insufficient to meet the needs of SoC verification, leading to the development of hardware-accelerated verification technologies.

[0004] Hardware-accelerated verification technology verifies chip designs using hardware simulators. It maps the Design Under Test (DUT) onto a processor array or Field Programmable Gate Array (FPGA) and then verifies the mapped equivalent system.

[0005] Hardware-accelerated verification methods offer a significant speed improvement over software simulation. Software simulation typically operates at a rate of, for example, 1kHz, while hardware-accelerated verification methods can achieve an average speed of, for example, 2MHz, greatly enhancing verification efficiency. Summary of the Invention

[0006] At least one embodiment of this disclosure provides a verification system, including a simulation verification device and a first part and a second part respectively created on the simulation verification device. The first part includes a first master module and at least one second slave module respectively connected to a device under test (DUT). The DUT includes a module under test and multiple object interfaces connected to the periphery of the module under test, the multiple object interfaces including memory access interfaces. The second slave module includes a storage unit connected to the memory access interfaces. The second part includes a first direct programming interface, a second direct programming interface, a function library module, and a test case module. The test case module is configured to provide at least one test case. The first direct programming interface communicates with the first master module and is configured to: in response to running the test case, call at least one first function in the function library module to achieve front-door access to the registers of the module under test. The second direct programming interface communicates with the storage unit of the first part and is configured to: in response to running the test case, call at least one second function in the function library module to achieve back-door access to the storage unit.

[0007] At least one embodiment of this disclosure also provides a verification method based on the verification system described above, comprising: compiling register transfer level code based on the module under test; performing comprehensive compilation based on the first part, the object under test, the module under test, the first master module, and the second slave module to obtain the compiled first part; selecting the usage mode of the simulation verification device, adding at least one compilation option to the compiled first part according to the usage mode, and calling a first assembler to deconstruct the verification system to generate a hardware information library for the simulation verification device to achieve accelerator compilation; compiling code for the second part using a behavioral modeling language; running the compiled first part and the second part to obtain verification results.

[0008] At least one embodiment of this disclosure provides an electronic device, including: a processing module and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processing module, it implements the verification method as described in any of the above embodiments.

[0009] At least one embodiment of this disclosure provides a computer-readable storage medium, wherein the storage medium stores a computer program, which, when executed by a processing module, implements the verification method as described in any of the above examples. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A block diagram of a verification system provided in some embodiments of this disclosure;

[0012] Figure 2 A block diagram of the software side of a verification system provided in some embodiments of this disclosure;

[0013] Figure 3 A block diagram of the first main module of the verification system provided in some embodiments of this disclosure;

[0014] Figure 4 A schematic diagram of the address spaces of a first master module and a second slave module provided for some embodiments of this disclosure;

[0015] Figure 5 A flowchart illustrating a verification method provided for some embodiments of this disclosure;

[0016] Figure 6 yes Figure 5 A flowchart of the execution process of step S5 in the verification method;

[0017] Figure 7 A flowchart of a verification method provided for other embodiments of this disclosure; and

[0018] Figure 8 This is a block diagram of an electronic device provided for some embodiments of this disclosure. Detailed Implementation

[0019] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0020] Unless otherwise defined, all terms (including technical and scientific terms) used in the embodiments of this disclosure shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It should also be understood that terms such as those defined in a common dictionary shall be interpreted as having a meaning consistent with their meaning in the context of the relevant art, and shall not be interpreted in an idealized or highly formalized sense, unless expressly defined in the embodiments of this disclosure.

[0021] The terms "first," "second," and similar terms used in this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, terms such as "an," "a," or "the" do not indicate a quantity limitation, but rather indicate the presence of at least one. Likewise, terms such as "including" or "comprising" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect, and also include communication connections.

[0022] Flowcharts are used in this disclosure to illustrate the steps of a method according to embodiments of this disclosure. It should be understood that the preceding or following steps are not necessarily performed in exact order. Instead, the steps can be processed in reverse order or simultaneously. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0023] This research reveals that hardware simulation acceleration verification platforms, including FPGA-based verification platforms such as HAPS or ZEBU, are suitable for functional simulation acceleration as an alternative to EDA simulation due to limitations such as capacity constraints, long synthesis time, difficult debugging, the need for manual partitioning of large systems, and the need to modify clock trees.

[0024] This published research also found that some current simulation acceleration schemes have the following drawbacks:

[0025] First, simulation acceleration based on Universal Verification Methodology (UVM) can reuse the original UVM environment and test cases when accelerating simulation. However, the shell of UVM-related methodologies is relatively complex to analyze, resulting in low acceleration performance. Moreover, migrating UVM to a synthesizable simulation acceleration verification platform requires a lot of optimization work, which is time-consuming and labor-intensive.

[0026] Second, although simulation acceleration based on embedded interfaces is faster, it requires the test platform to be written in a synthesizable form and synthesized into the simulation accelerator, resulting in low reusability. Different test platforms need to be rewritten, parsed, and debugged when combined with simulation accelerators, which involves a large workload.

[0027] At least one embodiment of this disclosure provides a verification system, including a simulation verification device and a first part and a second part respectively created on the simulation verification device; the first part includes a first master module and at least one second slave module respectively connected to an object under test; the object under test includes the module under test and multiple object interfaces connected to the periphery of the module under test, the multiple object interfaces including memory access interfaces, the second slave module includes a storage unit connected to the memory access interface; the second part includes a first direct programming interface, a second direct programming interface, a function library module and a test case module, the test case module being configured to provide at least one test case; the first direct programming interface communicates with the first master module, and the first direct programming interface is configured to: in response to running a test case, call at least one first function in the function library module to achieve front-door access to the registers of the module under test; the second direct programming interface communicates with the storage unit of the first part, and the second direct programming interface is configured to: in response to running a test case, call at least one second function in the function library module to achieve back-door access to the storage unit.

[0028] The verification system of the above embodiments of this disclosure provides a first direct programming interface and a second direct programming interface, which can realize the synchronization of the software side and the hardware side of the verification system. This facilitates the implementation of operations such as register reading and writing and memory access in the functional verification of the module under test. The simulation time is reduced, the chip verification efficiency is improved, and the system-level and / or module-level reusable verification of the chip can be realized. It has a wide range of application prospects.

[0029] Figure 1 This is a block diagram of a verification system provided in some embodiments of the present disclosure. Figure 2 This is a block diagram of the software side of a verification system provided in some embodiments of this disclosure.

[0030] For example, such as Figure 1 As shown, the verification system 1000 includes a simulation verification device 100 and a first part 200 and a second part 300 respectively created on the simulation verification device 100. For example, the first part 200 is the hardware side, which is configured to be created based on a hardware description (HDL) language. The second part 300 is the software side, which is configured to be created based on a behavioral modeling language. For example, hardware description languages ​​include Verilog, SystemVerilog, etc., and behavioral modeling languages ​​include C language or C++ language, etc.

[0031] For example, such as Figure 1 As shown, the first part 200 includes a first master module 210 and at least one second slave module 220, both connected to the object under test 230. The object under test 230 includes a module under test 231 and multiple object interfaces connected to the periphery of the module under test 231. The multiple object interfaces include at least one memory access interface 232. The second slave module 220 includes a storage unit 221 connected to the memory access interface 232.

[0032] For example, the module under test 231 is the design under test (DUT), which is implemented using RTL (Register Transfer Level) design code.

[0033] For example, such as Figure 1 As shown, the second part 300 includes a first direct programming interface 310, a second direct programming interface 320, a function library module 330, and a test case module 340. The test case module 340 is configured to provide at least one test case.

[0034] For example, the first direct programming interface 310 and / or the second direct programming interface 320 are both Direct Programming Interfaces (DPIs), which are interfaces for inter-calling between hardware description languages ​​(e.g., SystemVerilog) and programming languages ​​for software (e.g., C / C++).

[0035] For example, function library module 330 is configured as a function library based on multiple functions for use by other programs. For example, function library module 330 can be a static library. Function library module 330 internally includes at least one first function and at least one second function, wherein the first function can configure registers when called, and the second function can access memory units when called.

[0036] For example, such as Figure 1 As shown, the first direct programming interface 310 communicates with the first main module 210, and the first direct programming interface 310 is configured to: in response to running a test case originating from the test case module 340, call at least one first function in the function library module 330 to implement front-door access to the registers of the module under test 231. For example, front-door access includes front-door read data operation and / or front-door write data operation, and correspondingly, the first function includes functions related to register read and / or write.

[0037] For example, such as Figure 1As shown, the second direct programming interface 320 communicates with the storage unit 221 of the first part 200, and the second direct programming interface 320 is configured to: in response to running a test case originating from the test case module 340, call at least one second function in the function library module 330 to implement backdoor access to the storage unit 221. For example, the backdoor access includes a backdoor data loading operation and / or a backdoor data export operation, and correspondingly, the second function includes storage unit loading and / or export functions.

[0038] In some examples, "front-door access" in embodiments of this disclosure refers to simulating a CPU (Central Processing Unit) issuing read / write instructions on a bus via a register configuration bus (e.g., the AMBA protocol) to read / write the actual values ​​of the DUT's registers according to bus timing. Front-door access involves real RTL transfers and relies on bus timing protocols for transmission; therefore, it consumes simulation time. For example, front-door access cannot be performed on a domain-by-domain basis.

[0039] In some examples, "backdoor access" in embodiments of this disclosure refers to an access method that directly reads a two-dimensional array of memory cells. Backdoor access does not consume simulation time. For example, backdoor access can be performed by reading and writing on a domain basis.

[0040] The verification system of the above embodiments of this disclosure can realize the synchronization of the software and hardware sides of the verification system by providing a first direct programming interface and a second direct programming interface. This facilitates register reading and writing, memory unit access, etc. in the functional verification of the module under test. The simulation time is reduced, the verification efficiency of chip function is improved, and reusable verification of the chip at the system level and module level can be realized. It has a wide range of application prospects.

[0041] In some examples, the object under test 230 of the first part 200 is the top-level hardware component of the verification system 100. For example, the module under test 231 of the object under test 230 includes an IP (Intellectual Property) module of a SoC chip. For example, the module under test 231 can be an independent IP in the SoC to be verified by the verification system 100. For example, the SoC can be based on a microarchitecture of instruction sets such as x86, ARM, or RISC-V, and the embodiments of this disclosure do not limit this. The module under test 231 is universal and applicable to key IPs in a chip. For example, the module under test 231 includes, but is not limited to, a GPGPU (General Purpose Graphics Processing Unit), and the embodiments of this disclosure do not limit or elaborate on this. The verification system of the above embodiments of this disclosure can be applied to the simulation verification acceleration of IP-level modules in SoCs and the bare metal software development, greatly reducing the time required for simulation verification.

[0042] It should also be noted that the module under test 231 in the embodiments of this disclosure may belong to the IP module level in some scenarios and to the subsystem level in other scenarios. The embodiments of this disclosure do not limit this, and this does not affect the protection scope of this disclosure.

[0043] It should be noted that the first main module and the second slave module in the embodiments of this disclosure are referred to as the main module or the slave module relative to the object under test, respectively. This is merely a naming convention to facilitate the clarity and conciseness of the description of this disclosure. The embodiments of this disclosure are not limited thereto, nor is the scope of protection of the embodiments of this disclosure limited thereto.

[0044] In some examples, the simulation verification device 100 includes a first processor and the first processor includes a plurality of second processors connected in parallel, that is, the second processors are sub-processors relative to the first processor.

[0045] For example, simulation verification equipment includes Cadence's Palladium device, whose underlying architecture consists of a CPU processor and application-specific integrated circuits (ASICs). The Palladium device's processors are a large number of processors connected in parallel, thereby accelerating simulation verification through parallel pathways.

[0046] The embodiments of this disclosure are based on hardware simulation acceleration verification using simulation verification equipment such as Palladium devices, which can keep the chip RTL compatible with minimal modifications; provide excellent debugging performance and high signal visibility; have high platform compatibility and support SystemVerilog, System C, or System CPP; and eliminate the need for manual SoC design partitioning and require less additional manpower, thereby well meeting the chip project's requirements for verification time and chip delivery quality.

[0047] It should be noted that the simulation verification equipment used in the verification system of the embodiments of this disclosure is not limited to the Palladium device, but can also be other simulation verification equipment built based on processors. The embodiments of this disclosure do not limit or elaborate on these devices.

[0048] In some examples, the second part 300 is configured to be created based on the C or C++ language. For example, the second part 300 is a software side running on Cadence's Xcelium compiler software. Thus, the verification system of this disclosure can easily execute relevant instructions after compiling C or C++ code, making it widely applicable and convenient for R&D personnel.

[0049] In some examples, the first master module 210 is used to generate read and / or write instructions, configure the registers of the module under test 231, and generate a reset, such as a global reset. For example, as Figure 1 and Figure 2 As shown, the second part 200 also includes a driver module 350, which drives the first main module 210 of the first part 200, so that the first main module 210 configures the registers of the module under test 231 and performs a global reset.

[0050] In some examples, the first master module 210 and the second slave module 220 are AVIP (Accelerated Verification IP) designed for the simulation verification device 100, based on the Verification IP (VIP) component.

[0051] For example, such as Figure 2 As shown, the first master module 210 includes a master module with an Advanced Microprocessor Bus (AMBA) architecture, also known as an AMBAMASTER, meaning that the first master module 210 supports the AMBA standard bus protocol. Correspondingly, the driver module 350 can also be called an AMBAMASTER Driver. For example, the second slave module 220 includes a slave module with an AMBA bus architecture, also known as an AMBA SLAVE, meaning that the second slave module 220 supports the AMBA standard bus protocol.

[0052] The verification system of the above embodiments of this disclosure enables broader bus protocol verification at both the module and subsystem levels by employing AVIP, which supports multiple standard bus protocols.

[0053] For example, such as Figure 1 As shown, the first part 200 also includes a clock excitation source module 240, which provides a system clock signal on the hardware side for use by the DUT, etc. For example, the clock frequency of the clock signal can be 1 GHz. This is merely exemplary and is not a limitation of this disclosure.

[0054] For example, such as Figure 1 As shown, the multiple object interfaces of the object under test 230 also include at least one of the first interface 233a, the second interface 233b, the third interface 233c, and the fourth interface 233d.

[0055] For example, such as Figure 1 As shown, the first interface 233a is connected to the clock excitation source module 240 to receive clock signals. The verification system of this disclosure can be driven by a global clock, which is beneficial to the functionality, performance and stability of the synchronous digital system.

[0056] For example, such as Figure 1As shown, the second interface 233b is configured to receive interrupt request signals. For example, an interrupt request signal is used to stop the current working state of the relevant hardware and switch to the operation task corresponding to the interrupt request signal, and then switch back after the operation task is completed, thereby avoiding signal conflicts.

[0057] For example, such as Figure 1 As shown, the first main module 210 is connected to the third interface 233c for configuring the registers of the module under test 231. For example, as... Figure 1 As shown, the first main module 210 is connected to the fourth interface 233d for resetting the first part 200.

[0058] For example, in Figure 1 In the example, there are two memory access interfaces 232 and two second slave modules 220, each of which includes a memory unit 221. Thus, each memory unit 221 corresponds one-to-one with a memory access interface 232, forming a data transmission path between each memory unit 221 and the module under test 231, thereby enabling register front-door access. This is merely exemplary and not a limitation of this disclosure.

[0059] For example, such as Figure 1 As shown, the storage unit 221 of the second slave module 220 is used to store register data, that is, the main function of the second slave module 220 in the verification system 100 is as the memory of the verification system. For example, to implement the front door write operation, the embodiments of this disclosure can realize the storage of data written through the front door write operation into the storage unit 221 through the memory access interface 232.

[0060] For example, such as Figure 1 As shown, if necessary, the first part 200 may further include a rate matching bridge 250, which is configured to be connected to the second slave module 220 and the memory access interface 232 respectively. The embodiments of this disclosure utilize the rate matching bridge 250 to perform read / write rate conversion and processing, thereby avoiding metastability and clock signal mismatch issues in cross-clock domain data transmission between the module under test 231 and the memory unit 221.

[0061] In some examples, the data in the memory cell 221 of the second slave module 220 comes from two sources. The first is that data is written into the register of the module under test 231 through a front-door write operation and then transferred across the clock domain to the memory cell 221 of the second slave module 220 via the rate matching bridge 250. The second is that data is loaded into the memory cell 221 through a back-door data load operation.

[0062] In some examples, the storage unit 221 of the second slave module 220 has virtual storage space. For example, this disclosure may allocate a portion of the storage space to storage unit 221 using a Palladium device. This is merely exemplary and is not intended to limit the embodiments of this disclosure.

[0063] For example, such as Figure 2 As shown, the first direct programming interface 310 includes a direct programming interface (C / C++ DPI) based on C or C++ language, and the second direct programming interface 320 includes a one-time access direct programming interface (MARG DPI) based on C or C++ language. For example, MARG DPI is a type of interface that is more suitable for one-time storage and retrieval.

[0064] The embodiments of this disclosure connect the software and hardware sides of the verification system through the DPI interface. This not only enables the first master module 210 to perform front-door access (e.g., front-door read / write operation) of registers on the AMBA bus through the CPP interface function of the DPI, but also enables the storage unit 221 of the second slave module 220 to directly achieve back-door access to the storage unit 221 by calling the CPP interface function corresponding to the MARG DPI based on the set MARG DPI, thereby realizing data loading and data export of the storage unit.

[0065] The CPP interface functions used in the embodiments of this disclosure (such as the first function or the second function mentioned above; for example, the first function may include functions related to register reading and / or writing, and the second function may include functions for loading and / or exporting memory cells, etc.) are written and packaged in CPP language, making them easy to call. This allows for the implementation of more complex functions and test cases that better meet the chip's requirements. Furthermore, it achieves synchronization between the software and hardware sides, greatly improving the efficiency of simulation acceleration.

[0066] Figure 3 This disclosure provides a block diagram of the first main module of a verification system according to some embodiments.

[0067] For example, such as Figure 3 As shown, the first master module 210 includes a master core 211 and a third slave module 212. For example, the third slave module 212 is embedded in the first master module 210. The third slave module 212 is an embedded advanced peripheral bus slave module, i.e., an embedded APB module. It should be noted that the third slave module 212 in the embodiments of this disclosure is referred to as a slave module relative to the master core 211. This is merely a naming convention, and the embodiments of this disclosure are not limited thereto, nor is the scope of protection of the embodiments of this disclosure limited thereto.

[0068] In some examples, the main core 211 of the first main module 210 is an AVIP core, and the main core 211 of the first main module 210 includes synthesizable RTL code.

[0069] For example, such as Figure 3 As shown, the main core 211 is connected to the first direct programming interface 310 and the third interface 233c respectively, so that the main core 211 can obtain the register access instruction corresponding to the first function of the test case (i.e., the instruction used to read or write the register of the module under test 231) for configuring the register of the module under test 231.

[0070] For example, when a user runs a test case and calls the first function, the main core 211 of the first main module 210 will obtain a register access instruction to configure the registers of the module under test 231.

[0071] In some examples, the main core 211 also acquires control data related to register access instructions. This control data includes basic data required for reading or writing registers, such as the base address and base width of the memory. This is merely illustrative and not intended to limit the scope of this disclosure.

[0072] For example, such as Figure 3 As shown, the third slave module 212 of the first master module 210 is connected to the master core 211 and the fourth interface 233d respectively. This allows the reset signal generated by the master core 211 to be transmitted to the fourth interface 233d for resetting the first part 200. For example, a reset is required before each test case starts running for simulation, so that the state of all cores and all memory on the hardware side is in its initial state.

[0073] In some examples, when the second submodule 220 is an AMBA module, it can be instantiated into multiple different types of AMBA modules, such as an APB module, an AXI module, or an ACE module. This is merely exemplary and is not a limitation of this disclosure.

[0074] In some examples, when instantiating the second slave module 220, the AMBA parameters that need to be declared include at least one of the following: memory size, memory base address, and depth of currently ongoing (Outstanding) operations that can be supported. This is merely exemplary and is not intended to limit this disclosure.

[0075] In some examples, the first master module 210, the second slave module 220, and the third slave module 212 are each configured with independent storage space. For example, after the verification system 1000 has completed its initial setup, storage space needs to be allocated to each module, such as the first master module 210, the second slave module 220, and the third slave module 212.

[0076] Figure 4 This is a schematic diagram of the address spaces of a first master module and a second slave module provided for some embodiments of this disclosure.

[0077] In some examples, the address offset of the first master module 210 is 0x0000_0000, and the address offset of the third slave module 212 is 0x0010_0000 (1M Byte). For example, as Figure 4 As shown, the address range of the first main module 210 includes 0x0000_0000 to 0x000F_FFFF with a size of 1MB and 0x0010_0000 to 0x001F_FFFF with a size of 1MB. For example, as Figure 4 As shown, one of the two second slave modules 220 has an address range of 0x4000_0000 to 0x7FFF_FFFF and a size of 1GB, while the other second slave module 220 has an address range of 0x8000_0000 to 0xFFFF_FFFF and a size of 2GB. This is merely an example and is not intended to limit the scope of this disclosure.

[0078] In some examples, the second part 300 also includes a configuration file. The test cases are configured to perform test case configuration based on at least one first function of the configuration file for front-door access, or the test cases are configured to perform test case configuration based on at least one second function of the configuration file for back-door access.

[0079] In some examples, function library module 330 includes static libraries compiled from test cases and configuration files using a behavioral modeling language.

[0080] For example, in Figure 2 In the example, the test case module 340 provides test cases ranging from test0 to test3. Different test cases will call different functions to verify that the functionality meets the requirements. For example, as Figure 2 As shown, for test case module 340, it can use `test_entry()` to call the configuration file to provide relevant test cases. `test_entry()` is the entry point for users to edit the test cases to be tested. `test_entry()` calls the configuration file (e.g., a .cfg file) to complete the configuration of the relevant test cases. Verification system 1000 can provide users with an API to configure front-door and back-door memory access to registers. For example, the configuration file is compiled from C / C++ to generate a static library `userlib`, which is further parsed by the API interface to complete, for example, reading and writing to registers.

[0081] The simulation acceleration verification of the above embodiments of this disclosure uses test cases built based on C / CPP code, which makes the environment relatively simple, without complex methodologies, and allows the simulation environment to be set up quickly and run very fast.

[0082] In some examples, the first function includes at least one of the following: register read function reg_read, register write function reg_write, register read check function reg_read_check, register write read and check function reg_write_check, and register poll wake-up read function poll_reg_equal.

[0083] For example, the function reg_write is used to directly write 32-bit data to a specific register address, and the function reg_read is used to directly read 32-bit data from a specific register address.

[0084] For example, the function reg_read_check is used to check whether the data written to a specific address register is the same as expected. For example, the data written to a specific address register may be the data written by the function reg_write.

[0085] For example, the function `reg_read_check` first reads data from a specific address register, then compares the read data with the expected data. If the comparison result is the same, the check passes; if the comparison result is different, the current operation stops and an error is reported. The embodiments of this disclosure use the function `reg_read_check` to write data to a specific address register and automatically compare the reading result with the expected result. This provides a high degree of automation and improves the efficiency of verification personnel.

[0086] The function reg_write_check can be used in the same way as reg_read_check, except that reg_write_check also includes writing data to a specific address register, which will not be elaborated here.

[0087] For example, the function poll_reg_equal is used to continuously poll and read values ​​from a specific address register multiple times until the value read from the specific address register is equal to the expected value; if they are not equal, it continues to read until the number of reads exceeds the maximum number of polling times set by the user (e.g., 10000), at which point an error is reported and the polling ends; if multiple values ​​are read from the same address register but are still not equal to the expected value, an error is reported and the reading loop ends.

[0088] For example, the function poll_reg_equal can poll and wake up the relevant registers and check the read and write results of the register data in turn when some registers need to be polled to wake up the registers before the second function performs backdoor access to the storage unit of the second slave module.

[0089] In some examples, the second function includes at least one of the following: a memory cell polling wake-up read function poll_mem_equal, a memory cell initialization function mem_init, a memory cell data loading function mem_load, and a memory cell data export function.

[0090] In some examples, the storage cell data export function includes a storage cell multi-byte read function or a storage cell data grabbing function mem_dump, wherein the data segment lengths read by the mem_dump function and the storage cell multi-byte read function are different, with the data segment length read by the mem_dump function being greater than the data segment length read by the storage cell multi-byte read function.

[0091] For example, functions for reading multiple bytes from a memory cell include the functions mem_read32 and mem_read64. The function mem_read32 is used to directly read 32 bits of data from a specific memory cell address, while the function mem_read64 is used to directly read 64 bits of data from a specific memory cell address.

[0092] For example, the function mem_dump can extract data from a storage unit and extract the data in hexadecimal format into a self-named hexadecimal format file (hex file).

[0093] For example, the function `mem_load` loads a readable file in hexadecimal format into the verification system. This hexadecimal file is a two-dimensional array, with addresses preceding data and data following. The `mem_load` function loads each data item into its corresponding memory space based on its address.

[0094] For example, the function poll_mem_equal is used to continuously poll and read values ​​from a memory location at a specified address multiple times until the value read from the memory location at the specified address is equal to the expected value. If the comparison result is not equal, the reading continues until the number of reads exceeds the maximum number of polling times set by the user (e.g., 10000), at which point an error is reported and the polling ends. If multiple values ​​are read from the memory location at the same address but are still not equal to the expected value, an error is reported and the reading loop ends.

[0095] For example, the function `mem_init` initializes memory units within the used address range to prevent residual data in memory units from affecting the execution and result comparison of subsequent test cases after the previous test case run. The function `mem_init` initializes memory units within a predefined address range in five main modes:

[0096] Mode 0: All values ​​in the memory cells are initialized to 0x0000_0000;

[0097] Mode 1: All values ​​in the storage unit are initialized to 0xFFFF_FFFF;

[0098] Mode 2: The value of each memory cell is initialized to the value at the address of each memory cell;

[0099] Mode 3: The value of the storage unit is initialized to a value that starts from 0x0 and increments by 0x4 each time;

[0100] Mode 4: The value of the storage unit is initialized to a value that starts from 0 and increments by 1 each time.

[0101] The above-described patterns and corresponding functions are merely exemplary and are not intended to limit the embodiments of this disclosure.

[0102] In some examples, library module 330 may also include the file comparison function file_cmp and / or the reset function glb_rst.

[0103] For example, the function `file_cmp` can compare two hex files to obtain the comparison result. In the test cases of the embodiments of this disclosure, the user can specify the names of the two hex files to be compared in the definition of the `file_cmp` function.

[0104] For example, the function glb_rst can reset the first part 200, resetting the module state in the first part 200.

[0105] In some examples, each test case in the multiple test cases provided by the test case module 340 may not be exactly the same, and the function corresponding to each test case may be one or more. For example, each test case may be any function or any combination of functions described above. The embodiments of this disclosure do not limit this, and it can be freely adjusted according to actual verification needs, which will not be elaborated here.

[0106] It should be noted that the functions included in the function library module 330 of the embodiments of this disclosure are not limited to the above examples, but may also be other corresponding functions used to meet verification requirements, which will not be listed or described in detail here.

[0107] At least one embodiment of this disclosure also provides a verification method, which can be implemented based on the verification system described in any of the above embodiments. For specific implementation methods and technical effects of the verification method based on the verification system, please refer to the verification system provided in the above embodiments of this disclosure.

[0108] Figure 5 This is a flowchart illustrating a verification method provided for some embodiments of this disclosure.

[0109] For example, such as Figure 5 As shown, at least one embodiment of this disclosure provides a verification method including steps S1 to S5.

[0110] Step S1: Compile RTL code based on the module under test 231.

[0111] Step S2: Perform comprehensive compilation based on the first part 200, the object under test 230, the module under test 231, the first main module 210, and the second slave module 220 to obtain the compiled first part 200.

[0112] Step S3: Select the usage mode of the simulation verification device 100, add at least one compilation option to the already compiled first part 200 according to the usage mode, and call the first assembler to deconstruct the verification system 1000 to generate a hardware information library for the simulation verification device 100, so as to realize the accelerator compilation.

[0113] Step S4: Compile the code of the behavior modeling language for Part 2, 300.

[0114] Step S5: Run the compiled first part 200 and second part 300 to obtain the verification results.

[0115] In some examples, the verification method disclosed herein also includes the following process or step: debugging based on the verification results to ensure that the verification passes.

[0116] In some examples, the verification method disclosed herein further includes the following process or step: configuring the verification results to be visualized on the simulation verification device 100, wherein the visualization methods include, but are not limited to, charts, text, waveforms, etc. This can reflect the verification results in a timely, convenient, and accurate manner, which is beneficial to the management and execution of verification work.

[0117] For example, in step S1, RTL code compilation based on the module under test 231 includes the following process or steps: compiling the RTL file list and corresponding RTL files of the module under test 231 using a second compilation tool, generating a DUT netlist containing the object under test 230 in a specified format, such as generating a DUT netlist in vg format containing the object under test 230. The generated DUT netlist is configured to run on the simulation verification device 100. It should be noted that the specified format of the DUT netlist in the embodiments of this disclosure is not limited to vg format, but can also be other types of formats, such as edif format, etc., and the embodiments of this disclosure do not limit this.

[0118] For example, in step S1, the second compilation tool includes Cadence's compilation tool vavlog or the compilation tool vaelab. Of course, this is merely exemplary and is not intended to limit this disclosure.

[0119] For example, in step S2, a comprehensive compilation is performed based on the first part 200, the object under test 230, the module under test 231, the first main module 210, and the second slave module 220 to obtain the compiled first part 200. This includes the following process or steps: the first part 200, the object under test 230, the module under test 231, the first main module 210, and the second slave module 220 (e.g., based on the third compilation tool of the simulation verification device 100) are used to compile the first part 200, the object under test 230, the module under test 231, the first main module 210, and the second slave module 220 (e.g., based on the third compilation tool of the simulation verification device 100). Figure 1 The two second slave modules 220 and the clock excitation source module 240 are synthesized and compiled to obtain the compiled hardware side.

[0120] For example, third-party compilation tools include Cadence's Palladium-based VLAN tool. Of course, this is merely illustrative and not a limitation of this disclosure.

[0121] For example, in step S2, the objects of the synthesis compilation in the embodiments of this disclosure include not only the first part 200, the object under test 230, the module under test 231, the first main module 210, and the second slave module 220, but also, for example, the Cadence AVIP file necessary for compilation and other required peripheral test resources. Since this is not the focus of the embodiments of this disclosure, it will not be exhaustively described here. Therefore, the compiled hardware side can be generated through this synthesis compilation step.

[0122] For example, in step S3, the usage mode of the simulation verification device 100 is selected. Based on the usage mode, at least one compilation option is added to the already compiled first part 200 for accelerator compilation. Then, the first assembler tool is called to deconstruct the verification system, generating a hardware information library for the simulation verification device. This includes the following processes or steps: selecting the IXCOM mode of the Palladium device; based on the IXCOM mode, at least one compilation option is added to the already compiled first part 200; and the first assembler tool is called to deconstruct the verification system 1000, generating a hardware information library (hardware lib). For example, the hardware information library contains lib libraries containing information such as RTL, simulation environment, and compilation environment. This is merely exemplary and not a limitation of this disclosure.

[0123] The embodiments disclosed herein use Palladium's IXCOM mode, which makes it more compatible with non-synthesizable parts of the design, supports placing parts of the design in the simulation verification device, and is compatible with other modes, which can reduce the workload of verification, reduce costs, and improve verification efficiency.

[0124] For example, in step S3, using the Cadence-based IXCOM compilation tool, the pre-compiled first part 200 generated by synthesis is compiled with options such as -z1, -ua+1xua, -dpi, and -timescale. Furthermore, Cadence's VXE and other first-level assembly tools can be invoked to deconstruct the verification system 1000 as a whole (e.g., assembling natural language programming into machine language), generating a hardware information library that can be directly used for simulation verification device 100, thereby completing the accelerator compilation. This is merely an example and is not a limitation of this disclosure.

[0125] For example, in step S4, the behavior modeling language can be CPP language, that is, step S4 is used to compile CPP code for the second part 300.

[0126] For example, step S4 mainly compiles the CPP code for the user-defined test cases. This may include setting the types of the first and / or second functions to be called, how the first and / or second functions are combined, the specific settings of the first and / or second functions (e.g., register read / write addresses and the specific data written), and the first reference file for comparison (details below). Thus, the verification system calls the static library file generated in step S4 during final runtime, enabling the user-defined test cases to take effect and complete the test functions during the simulation-accelerated verification process.

[0127] In some examples, the verification method of this disclosure further includes the following process or steps: verifying whether the above-described configuration of the registers of the module under test meets the target requirements of the module under test 231.

[0128] For example, the test cases provided by the test case module 340 of the embodiments of this disclosure are different for different modules under test 231, and multiple different test cases can be developed for the same module under test 231 based on multiple different verification requirements. Different test cases will correspond to different function settings, register settings, expected data results, etc., which will result in different data writing to the registers of the AMBA bus.

[0129] In some examples, the first part 200 and the second part 300 created on the simulation verification device 100 in the embodiments of this disclosure represent a verification environment built based on the simulation verification device 100. The verification environment is divided into a hardware side and a software side, and the hardware side and the software side can interact with each other. For example, the first part 200 may be ported to the simulation verification device 100, such as the Palladium device, and the first part may be located on another device, such as a server, that can achieve communication with the hardware side. Of course, the first part 200 and the second part 300 may also run together on, for example, the Palladium device, and the embodiments of this disclosure do not limit this.

[0130] Figure 6 yes Figure 5 The flowchart illustrates the execution process of step S5 in the verification method. For example, as shown... Figure 6 As shown, an example of step S5 includes at least steps S51 to S53.

[0131] Step S51: In response to the fact that the module under test 231 is the first module, the first data of the storage unit 221 is accessed through the backdoor to obtain the first reference file.

[0132] Step S52: In response to the fact that the module under test 231 is the second module, the second data of the storage unit 222 is accessed through the backdoor to obtain the second file.

[0133] Step S53: Compare the second file with the first reference file to obtain the verification results.

[0134] For example, in step S51, accessing and reading the first data of storage unit 221 through a backdoor to obtain a first reference file includes the following process or steps: in response to the end of test case execution (e.g., after the initial execution of the test case), accessing and reading the first data of storage unit 221 through a backdoor to obtain a self-named first target hexadecimal format file; and generating a standard version of a second target hexadecimal format file based on the first target hexadecimal format file to obtain the first reference file.

[0135] For example, the first target hexadecimal format file is the first hex file, and the second target hexadecimal format file is the second hex file of the Golden version. This is merely illustrative and is not intended to limit this disclosure.

[0136] For example, in step S52, the second module is configured to be updated based on the first module. The second module is the module under test that is continuously iteratively updated based on the first module during chip development. Therefore, each time the RTL code of the module under test 231 changes and is iteratively updated, the test cases need to be rerun to test whether the RTL function has changed and to calibrate the RTL using the first reference file.

[0137] For example, in step S52, accessing and reading the second data from storage unit 221 through a backdoor to obtain the second file includes the following process or steps: running the test case again, accessing and reading the second data from storage unit 221 through the backdoor, and obtaining the second file. For example, theoretically, the test case in step S52 is expected to be the same as the test case run for the first time in step S51, so that it can be determined whether the verification passes.

[0138] For example, in step S53, comparing the second file with the first reference file to obtain the verification result includes the following process or steps: If the comparison result of the second file and the first reference file is the same, the verification passes, and the character or pattern "testcase pass" can be printed to the graphical interface, and the process ends; if the comparison result of the second file and the first reference file is different, the verification fails, and the character or pattern "testcase fail" can be printed to the graphical interface, and the test case can be debugged. The RTL code of the module under test 231 can also be checked. Thus, after modification and debugging, the process is repeated until the comparison result is the same, then the verification passes, and the process ends.

[0139] Therefore, in the event that the verification fails, step S52, which involves accessing and reading the second data from storage unit 221 through a backdoor to obtain the second file, also includes the following process or steps: debugging the test cases, running the debugged test cases, and accessing and reading the second data from storage unit 221 through the backdoor to obtain the second file. For example, the debugged test cases in step S52 are test cases with the same configuration as the test cases initially run in step S51. This avoids verification failures due to errors in the test cases during actual operation, thus ensuring the smooth progress of the simulation verification process.

[0140] In some examples, for step S52, the test case can also be debugged before running the test case again, and the embodiments of this disclosure do not limit this.

[0141] In some examples, when running the compiled Part 200 and Part 300, the graphical interface of the Palladium device can be launched directly by executing the Make emu_run command, which is already packaged in the Makefile. In this way, the test case execution results and the corresponding necessary log information will be printed on the graphical interface for users to further debug and record the results.

[0142] The verification documents and basic verification process of the embodiments disclosed herein are universal, which helps to reduce the workload of verification. As the verification work progresses, the number of verification test cases increases, the complexity of the verification test cases also increases, and the design is constantly iterated. Automated regression testing helps to ensure project quality and reduce the workload of tedious tasks.

[0143] Figure 7 A flowchart of a verification method provided for other embodiments of this disclosure.

[0144] For example, such as Figure 7 As shown, the verification method provided in some embodiments of this disclosure includes steps T1 to T8.

[0145] Step T1: Initial run of the test cases.

[0146] Step T2: Access the first data in the storage unit through the backdoor to obtain the first reference file.

[0147] Step T3: Run the test cases again.

[0148] Step T4: Access the second data in the storage unit through the backdoor to obtain the second file.

[0149] Step T5: Compare the data in the second file with the data in the first reference file.

[0150] Step T6: Determine whether the data in the second file is the same as the data in the first reference file. If yes, proceed to step T8. If no, the verification fails, and the debugging of the test cases and the RTL verification of the module under test in step T7 are executed. Repeat steps T3 to T6 until the judgment result is the same, then proceed to step T8.

[0151] Step T8: Verification passed, verification process ends.

[0152] For example, the first reference file in step T2 is the second hex file of the golden version.

[0153] For example, the test cases in step T3 can be test cases that have been debugged after verification failed, or test cases obtained by debugging the test cases before starting step T3. The embodiments of this disclosure do not limit this.

[0154] Based on the test case verification process described above, the embodiments of this disclosure can realize an automated process with certain universality, thereby achieving a simple, efficient, and highly reusable hardware acceleration testing method and process, which greatly saves the time of chip verification engineering and significantly improves chip verification efficiency.

[0155] Figure 8 This is a schematic diagram of the structure of an electronic device provided in at least one embodiment of the present disclosure. The electronic device 400 includes a processing module 410 and a memory 420. The memory 420 stores a computer program. When the computer program is executed by the processing module 410, it implements the verification method of at least some embodiments of the present disclosure.

[0156] The electronic devices in this disclosure may include, but are not limited to, mobile terminals such as laptops and tablets, and fixed terminals such as desktop computers, conventional servers, and cloud servers. Figure 8 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0157] For example, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For instance, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. When the computer program is executed by a processing module, the verification method of embodiments of this disclosure is performed.

[0158] It should be noted that the computer-readable medium described above in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In embodiments of this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In embodiments of this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0159] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0160] It should be noted that, in the embodiments of this disclosure, the specific functions and technical effects of the electronic device 400 can be referred to the description of the verification method above, and will not be repeated here.

[0161] The following points need to be explained:

[0162] (1) The accompanying drawings of the embodiments of this disclosure only involve the structures involved in the embodiments of this disclosure. Other structures can be referred to the general design.

[0163] (2) Where there is no conflict, the embodiments of this disclosure and the features in the embodiments can be combined with each other to obtain new embodiments.

[0164] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. The scope of protection of this disclosure should be determined by the scope of protection of the claims.

Claims

1. A verification system, comprising a simulation verification device and a first part and a second part respectively created on the simulation verification device, wherein the first part is a hardware side and the second part is a software side, wherein... The first part includes a first master module and at least one second slave module, which are respectively connected to the object under test; The object under test includes a module under test and multiple object interfaces connected to the periphery of the module under test. The multiple object interfaces include memory access interfaces. The second slave module includes a storage unit, and the storage unit is connected to the memory access interface. The second part includes a first direct programming interface, a second direct programming interface, a function library module, and a test case module, wherein the test case module is configured to provide at least one test case; The first direct programming interface communicates with the first main module, and the first direct programming interface is configured to: in response to running the test case, call at least one first function in the function library module to realize front door access to the registers of the module under test; The second direct programming interface communicates with the storage unit of the first part, and the second direct programming interface is configured to: in response to running the test case, call at least one second function in the function library module to achieve backdoor access to the storage unit; The first main module includes a main core and a third slave module. The main core is connected to the first direct programming interface and the third interface among the plurality of object interfaces, respectively, so that the main core obtains the register access instruction of the first function corresponding to the test case, for configuring the registers of the module under test. The second part also includes a driver module for driving the first main module of the first part, so that the first main module configures the registers of the module under test and performs a global reset.

2. The verification system as described in claim 1, wherein, The hardware side configuration is created based on a hardware description language; the software side configuration is created based on a behavioral modeling language.

3. The verification system as described in claim 1, wherein, The simulation verification device includes a first processor, which includes multiple second processors connected in parallel.

4. The verification system as described in claim 3, wherein, The simulation verification device includes a Palladium device, the first direct programming interface includes a direct programming interface based on C language or CPP language, and the second direct programming interface includes a one-time access direct programming interface based on C language or CPP language.

5. The verification system as described in claim 1, wherein, The first part also includes a clock excitation source module for providing clock signals, and the plurality of object interfaces further include a first interface, a second interface and a fourth interface; The first interface is connected to the clock excitation source module to receive the clock signal; The second interface is configured to receive interrupt request signals; The first main module is connected to the fourth interface for resetting the first part.

6. The verification system as described in claim 5, wherein, The first master module includes a master module with an advanced microprocessor bus architecture, and the second slave module includes a slave module with an advanced microprocessor bus architecture. The third slave module is connected to the main core and the fourth interface respectively, and transmits the reset signal generated by the main core to the fourth interface for resetting the first part.

7. The verification system as described in claim 1, wherein, The first part also includes a rate matching bridge, which is connected to the second slave module and the memory access interface respectively.

8. The verification system as described in claim 2, wherein, The second part also includes configuration files, The test cases are configured to perform the front door access based on at least one first function in the configuration file, or the test cases are configured to perform the back door access based on at least one second function in the configuration file. The function library module includes a static library compiled based on the test cases and the configuration file and using the behavioral modeling language.

9. The verification system as described in claim 1 or 8, wherein, The at least one first function includes at least one of the following: a register read function, a register write function, a register read-after-check function, a register write-after-read and check function, and a register polling wake-up read function; The at least one second function includes at least one of the following: a storage unit polling wake-up read function, a storage unit initialization function, a storage unit data loading function, and a storage unit data export function.

10. The verification system as described in claim 6, wherein, The first master module, the second slave module, and the third slave module are each configured with independent storage space.

11. A verification method based on the verification system according to any one of claims 1 to 10, comprising: Compile register-transfer level code based on the module under test; Based on the first part, the object under test, the module under test, the first main module, and the second slave module, a comprehensive compilation is performed to obtain the compiled first part; Select the usage mode of the simulation verification device, add at least one compilation option to the compiled first part according to the usage mode, and call the first assembly tool to deconstruct the verification system to generate a hardware information library for the simulation verification device, so as to realize accelerator compilation. The code for the second part is compiled using a behavior modeling language; Run the compiled first and second parts to obtain the verification results.

12. The verification method as described in claim 11, wherein, The simulation verification equipment includes the Palladium device; The hardware side configuration is created based on a hardware description language, and the software side configuration is created based on a behavioral modeling language.

13. The verification method as described in claim 11, wherein, Compiling register-transfer level code based on the module under test includes: The register transfer level file list and corresponding register transfer level file of the module under test are compiled using the second compilation tool to generate a netlist of the module under test containing the object under test in a set format. The generated netlist of the module under test is configured to run on the simulation verification device.

14. The verification method as described in claim 12, wherein, In response to the first part further including a clock excitation source module for providing a clock signal, the first part, the object under test, the module under test, the first master module, and the second slave module are synthesized and compiled to obtain the compiled first part, including: The third compilation tool based on the simulation verification device performs comprehensive compilation on the first part, the object under test, the module under test, the first master module, the second slave module and the clock excitation source module to obtain the compiled hardware side.

15. The verification method as described in claim 12, wherein, Select the usage mode of the simulation verification device, add at least one compilation option to the already compiled first part according to the usage mode, and call the first assembler to deconstruct the verification system to generate a hardware information library for the simulation verification device, including: Select the IXCOM mode of the Palladium device, add at least one compilation option to the already compiled first part according to the IXCOM mode, and call the first assembler to deconstruct the verification system to generate the hardware information library.

16. The verification method as described in claim 11, wherein, Run the compiled first and second parts to obtain the verification results, including: In response to the fact that the module under test is the first module, the first data of the storage unit is accessed and read through the backdoor to obtain the first reference file; In response to the fact that the module under test is the second module, the second data of the storage unit is accessed and read through the backdoor to obtain the second file, wherein the second module is configured to be updated based on the first module; The second file is compared with the first reference file to obtain the verification result.

17. The verification method as described in claim 16, wherein, Accessing and reading the first data of the storage unit through the backdoor to obtain the first reference file includes: In response to the end of the test case execution, the first data in the storage unit is read through the backdoor to obtain a self-named first target hexadecimal format file; Generate a standard version of the second target hexadecimal format file based on the first target hexadecimal format file, and obtain the first reference file.

18. The verification method as described in claim 16, wherein, Accessing and reading second data from the storage unit through the backdoor to obtain a second file includes: The test cases are debugged, and the debugged test cases are run. The second data in the read storage unit is accessed through the backdoor to obtain the second file.

19. An electronic device comprising: Processing module and memory, The memory stores a computer program, which, when executed by the processing module, implements the verification method according to any one of claims 11 to 18.

20. A computer-readable storage medium, wherein, The storage medium stores a computer program, which, when executed by the processing module, implements the verification method according to any one of claims 11 to 18.

Images