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

Abstract

The present disclosure relates to a verification system, a verification method, an electronic device, and a storage medium. The verification system includes a simulation verification device, a first part, and a second part. The first part includes a first master module and a second slave module. The second slave module includes a storage unit connected to a memory access interface around a test module. The second part includes a first direct programming interface, a second direct programming interface, a function library module, and a test case module for providing test cases. The first direct programming interface communicates with the first master module and is configured to call a first function of the function library module in response to executing the test case to realize front-door access to a register of the test module. The second direct programming interface communicates with the storage unit and is configured to call a second function of the function library module in response to executing the test case to realize back-door access to the storage unit. The verification system achieves synchronization between the software side and the hardware side, facilitates functional verification of the test module, reduces simulation time, and realizes reusable verification of chips.

Description

[Technical Field]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] This application claims priority to Chinese patent application no. 202211062729.2, filed on August 31, 2022, the entire contents of which are incorporated herein by reference.

[0002] [Technical field] SUMMARY OF THE INVENTION An embodiment of the present disclosure relates to a verification system, a verification method, an electronic device, and a storage medium. [Background technology]

[0003] Currently, with the rapid development of the electronics and information industry, the scale of systems on chips (SoCs) is becoming larger and larger, and chip verification work, which accounts for an average of nearly 70% of the total chip development workload, is becoming increasingly complex, resulting in higher requirements for chip risk management.

[0004] Integrated circuit hardware models associated with Very Large Scale Integration (VLSI) integrated circuit chips have become highly complex, and the corresponding design and verification computational complexity has also increased significantly. Therefore, for highly complex functional test scenarios, the speed, capacity, and efficiency of electronic design automation (EDA) simulation cannot meet the needs of SoC verification, leading to the emergence of hardware-accelerated verification techniques.

[0005] Hardware-accelerated verification technology verifies a chip design through a hardware simulator, maps the design under test (DUT) to a processor array or a field programmable gate array (FPGA), and verifies the mapped equivalent system.

[0006] The speed of hardware acceleration verification methods has been qualitatively improved compared to software simulation. While the average rate of software simulation is, for example, 1 [KHz], the hardware acceleration simulation verification method can reach, for example, an average of 2 [MHz], significantly improving verification efficiency. Summary of the Invention

[0007] At least one embodiment of the present disclosure provides a verification system including a simulation verification device and a first part and a second part respectively created in the simulation verification device, wherein the first part includes a first master module and at least one second slave module each connected to a test object, the test object includes a test module and a plurality of object interfaces connected to the periphery of the test module, the plurality of object interfaces including a memory access interface, the second slave module includes a storage unit, the storage unit is connected to the memory access interface, and 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 the first direct programming interface is configured to call at least one first function in the function library module in response to executing the test case to realize front-door access of a register of the test module; and the second direct programming interface communicates with the storage unit of the first portion, and the second direct programming interface is configured to call at least one second function in the function library module in response to executing the test case to realize back-door access of the storage unit.

[0008] At least one embodiment of the present disclosure further provides a verification method based on the above verification system, including: performing compilation of register transfer level code based on the test module; performing comprehensive compilation based on the first portion, the test target, the test module, the first master module, and the second slave module to obtain the compiled first portion; selecting a usage mode of the simulation verification device, adding the compiled first portion to at least one compilation option according to the usage mode, calling a first assembler tool to decompose the verification system, generating a hardware information library for the simulation verification device, and realizing accelerator compilation; compiling code in a behavioral modeling language of the second portion; and executing the compiled first and second portions to obtain verification results.

[0009] At least one embodiment of the present disclosure provides an electronic device including a processing module and a memory, wherein a computer program is stored in the memory, and when the computer program is executed by the processing module, the verification method described in any one of the above embodiments is realized.

[0010] At least one embodiment of the present disclosure provides a computer-readable storage medium having a computer program stored thereon, the computer program, when executed by a processing module, realizing the verification method described in any of the above embodiments. [Brief explanation of the drawings]

[0011] In order to more clearly describe the embodiments of the present disclosure, the drawings necessary for use in the embodiments are briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present disclosure, and those skilled in the art can obtain other drawings based on these drawings without creative efforts.

[0012] [Figure 1] FIG. 1 is a schematic block diagram of a verification system provided by some embodiments of the present disclosure. [Figure 2] FIG. 2 is a schematic block diagram of the software side of the verification system provided by one embodiment of the present disclosure. [Figure 3] FIG. 3 is a schematic block diagram of a first master module of a verification system provided by some embodiments of the present disclosure. [Figure 4] FIG. 4 is a schematic diagram of address spaces of a first master module and a second slave module provided by some embodiments of the present disclosure. [Figure 5] FIG. 5 is a flowchart of a verification method provided by some embodiments of the present disclosure. [Figure 6] FIG. 6 is a flowchart of the execution process of step S5 of the verification method of FIG. [Figure 7] FIG. 7 is a flowchart of a verification method provided by some other embodiments of the present disclosure. [Figure 8] FIG. 8 is a block diagram of an electronic device provided according to some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0013] The technical solutions in the embodiments of the present disclosure are clearly and completely described below with reference to the accompanying drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, but not all of the embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without creative efforts fall within the scope of protection of the present disclosure.

[0014] Unless otherwise specified, all terms (including technical and scientific terms) used in the examples of the present disclosure have the same meaning as commonly understood by those skilled in the art to which the present disclosure belongs. It should also be understood that terms defined in common dictionaries should be interpreted to have a meaning consistent with the meaning in the context of the relevant technology, and should not be interpreted in an idealized or highly formalized sense unless explicitly stated as such in the examples of the present disclosure.

[0015] The words "first," "second," and similar words used in the embodiments of the present disclosure do not denote any order, quantity, or importance, but are only used to distinguish between different components. Similar words such as "one," "an," or "the" do not denote a quantitative limitation, but rather indicate the presence of at least one. Similarly, similar words such as "comprise" or "containing" mean that the element or thing appearing before the word includes the elements or things listed after the word and equivalents thereof, without excluding other elements or things. Similar words such as "connected" or "coupled" are not limited to physical or mechanical connections, but can include direct or indirect electrical connections, and also include communication connections.

[0016] In the embodiments of the present disclosure, flowcharts are used to illustrate steps of methods according to the embodiments of the present disclosure. It should be understood that previous or subsequent steps do not necessarily have to be performed in order. Instead, various steps can be processed in reverse order or simultaneously. At the same time, other operations may be added to these processes, or one or more steps may be deleted from these processes.

[0017] As can be seen from the research in this disclosure, hardware simulation acceleration verification platforms include FPGA-based verification platforms, such as HAPS or ZEBU. However, FPGA-based verification platforms have limitations such as limited capacity, time-consuming synthesis, difficult debugging, the need to manually partition large systems, and the need to modify clock trees, making FPGA-based verification platforms unsuitable for accelerating functional simulation to replace EDA simulation.

[0018] The research in this disclosure also reveals that some current simulation acceleration solutions have the following drawbacks:

[0019] First, simulation acceleration based on Universal Verification Methodology (UVM) can reuse the original UVM environment and test cases when performing simulation acceleration, but the shells of UVM-related methodologies are more complex to analyze and have lower acceleration performance, and migrating UVM to a synthesisable verification platform for simulation acceleration requires a lot of time-consuming and labor-intensive optimization work.

[0020] Second, although simulation acceleration based on embedded interfaces is fast, the test platform needs to be created in a synthesizable format and integrated into the simulation accelerator, which results in very low reusability. When combining various test platforms with the simulation accelerator, they need to be rewritten, analyzed, and debugged, which is a heavy workload.

[0021] At least one embodiment of the present disclosure provides a verification system including a simulation verification device and a first part and a second part respectively created in the simulation verification device, wherein the first part includes a first master module and at least one second slave module each connected to a test object, the test object includes a test module and a plurality of object interfaces connected to the periphery of the test module, the plurality of object interfaces including an access interface, and the second slave module includes a storage unit connected to the access interface, and 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 the first direct programming interface is configured to call at least one first function in the function library module in response to executing the test case to realize front-door access of a register of the test module, and the second direct programming interface communicates with the storage unit of the first portion, and the second direct programming interface is configured to call at least one second function in the function library module in response to executing the test case to realize back-door access of the storage unit.

[0022] The verification system of the above-described embodiments of the present disclosure provides a first direct programming interface and a second direct programming interface, thereby realizing synchronization between the software and hardware sides of the verification system. During functional verification of a test module, operations such as reading and writing registers and accessing and storing memory units can be easily performed. This reduces simulation time, improves chip verification efficiency, and realizes reusable verification of chips at the system level and / or module level, which is expected to have a wide range of applications.

[0023] Figure 1 is a schematic block diagram of a verification system provided by some embodiments of the present disclosure. Figure 2 is a schematic block diagram of the software side of the verification system provided by some embodiments of the present disclosure.

[0024] 1, the verification system 1000 includes a simulation verification device 100 and a first portion 200 and a second portion 300, which are respectively created in the simulation verification device 100. For example, the first portion 200 is a hardware side configured to be created based on a hardware description language (HDL). The second portion 300 is a software side configured to be created based on a behavioral modeling language. For example, the hardware description language includes Verilog, SystemVerilog, etc., and the behavioral modeling language includes C language or CPP language (also known as C++ language), etc.

[0025] 1, the first part 200 includes a first master module 210 and at least one second slave module 220, each connected to a test object 230. The test object 230 includes a test module 231 and a plurality of object interfaces connected to the periphery of the test module 231. The plurality of object interfaces includes at least one memory access interface 232. The second slave module 220 includes a storage unit 221 connected to the memory access interface 232.

[0026] For example, test module 231 is a Design Under Test (DUT), where the DUT is implemented, for example, by RTL (Register Transfer Level) design code.

[0027] 1, second portion 300 includes first direct programming interface 310, second direct programming interface 320, function library module 330, and test case module 340. Test case module 340 is configured to provide at least one test case.

[0028] For example, the first direct programming interface 310 and / or the second direct programming interface 320 are both direct programming language interfaces, which are interfaces for making calls between a hardware description language (e.g., SystemVerilog, etc.) and a software programming language (e.g., C / C++, etc.).

[0029] For example, the function library module 330 is configured to create a function library based on a plurality of functions for provision to other programs, for example, the function library module 330 can select a static library, the function library module 330 includes at least one first function and at least one second function therein, and can realize register configuration when the first function is called and used, and can realize memory unit access and storage when the second function is called and used.

[0030] 1 , the first direct programming interface 310 communicates with the first master module 210, and the first direct programming interface 310 is configured to, in response to execution of a test case from the test case module 340, call at least one first function in the function library module 330 to realize a front door access of a register of the test module 231. For example, the front door access includes a front door data read operation and / or a front door data write operation, and accordingly, the first function includes a function to be read by and / or a function to be written by the register.

[0031] 1 , the second direct programming interface 320 communicates with the storage unit 221 of the first portion 200, and the second direct programming interface 320 is configured to, in response to execution of a test case from the test case, call at least one second function in the function library module 330 to realize a backdoor access of the storage unit 221. For example, the backdoor access includes a backdoor data load operation and / or a backdoor data export operation, and accordingly, the second function includes a function loaded by and / or a function exported by the storage unit.

[0032] In some examples, a "front door access" in an embodiment of the present disclosure simulates a CPU (Central Processing Unit) via a register configuration bus (e.g., AMBA protocol) to issue read and write commands via the bus and read / write actual values ​​of registers in the DUT according to bus timing. Because actual RTL transfers are performed during a front door access and the front door access transfers according to the bus timing protocol, the front door access takes a simulation time. For example, the front door access cannot read / write per domain.

[0033] In some examples, the term "backdoor access" in the embodiments of the present disclosure refers to an access method that directly reads a two-dimensional array of storage units. Backdoor access does not require simulation time. For example, backdoor access can read and write on a per-domain basis.

[0034] The verification system of the above embodiment of the present disclosure provides a first direct programming interface and a second direct programming interface, thereby realizing synchronization between the software and hardware sides of the verification system and easily realizing register read / write and memory unit access during functional verification of a test module, thereby reducing simulation time, improving the efficiency of chip function verification, and realizing reusable verification of chips at the system level and module level, which is expected to have a wide range of applications.

[0035] In some examples, the test object 230 of the first section 200 is the top layer of the hardware side of the verification system 100. For example, the test module 231 of the test object 230 includes an intellectual property (IP) module of an SoC chip. For example, the test module 231 may be an independent IP in an SOC verified by the verification system 100. For example, the SOC may be based on an instruction set microarchitecture such as X86, ARM, or RISC-V, although the embodiments of the present disclosure are not limited thereto. The test module 231 is versatile and suitable for major IPs in a chip. For example, the test module 231 may include, but is not limited to, a general-purpose graphics processor (GPGPU). The embodiments of the present disclosure are not limited thereto and will not be described again. The verification system of the above embodiments of the present disclosure is applicable to simulation verification acceleration of IP-level modules in an SoC and software bare metal development, significantly reducing the time required for simulation verification.

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

[0037] It should be noted that the first master module and the second slave module in the embodiments of the present disclosure are referred to as the master module and the slave module, respectively, relative to the test object, and these are merely naming methods for making the explanation of the present disclosure clear and concise, and the embodiments of the present disclosure are not limited to these, and the scope of protection of the embodiments of the present disclosure is not limited by these.

[0038] In some examples, the simulation verification equipment 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 to the first processor.

[0039] For example, simulation verification equipment includes Cadence's Palladium equipment, whose underlying architecture is a CPU processor and an application-specific integrated circuit. The processor in a Palladium equipment is composed of multiple processors connected in parallel, allowing for acceleration of simulation verification through parallel channels.

[0040] The embodiments of the present disclosure perform accelerated verification of hardware simulation based on simulation verification equipment such as Palladium equipment, and can maintain chip RTL compatibility with fewer changes, have excellent debug performance and high signal visibility, have high platform compatibility, and can support SystemVerilog, System C, or System CPP. Furthermore, there is no need to manually divide the SoC design, and no additional human investment is required, so the verification time requirements and chip delivery quality of chip projects can be fully met.

[0041] Note that the simulation verification equipment used in the verification system of the embodiments of the present disclosure is not limited to Palladium equipment, but may be other simulation verification equipment built based on a processor, and the embodiments of the present disclosure are not limited to this and will not be described repeatedly.

[0042] In some examples, the second part 300 is configured to be created based on the C language or the CPP language, for example, the second part 300 is a software side that runs on Cadence's compilation software Xcelium. In this way, the verification system according to the embodiment of the present disclosure can easily realize the execution of related instructions after compiling the C language or the CPP language code, and is widely used, facilitating the development work of research and development personnel.

[0043] In some examples, the first master module 210 is used to generate read and / or write instructions, configure registers of the test module 231, and issue resets such as a global reset. For example, as shown in Figures 1 and 2, the second portion 200 further includes a driving module 350 for driving the first master module 210 of the first portion 200, such that the first master module 210 configures registers of the test module 231 and performs a global reset.

[0044] In some examples, the first master module 210 and the second slave module 220 are Accelerated Verification IP (AVIP) designed for the simulation verification equipment 100 based on a Verification Unit Component (VIP).

[0045] 2, the first master module 210 includes an Advanced Microprocessor Bus Architecture master module that may be referred to as an AMBA MASTER, i.e., the first master module 210 supports the AMBA standard bus protocol. Similarly, the driver module 350 may be referred to as an AMBA MASTER Driver. For example, the second slave module 220 also includes an Advanced Microprocessor Bus Architecture slave module that may be referred to as an AMBA SLAVE, i.e., the second slave module 220 supports the AMBA standard bus protocol.

[0046] The verification system of the above embodiment of the present disclosure enables broader bus protocol verification at the module level and subsystem level by using an AVIP that can support multiple standard bus protocols.

[0047] 1, the first section 200 further includes a clock excitation source module 240. The clock excitation source module 240 is used to provide a system clock signal to the hardware side, which is used by the DUT or the like. For example, the clock frequency of the clock signal may be 1 GHz. This is merely an example and does not limit the present disclosure.

[0048] For example, as shown in FIG. 1, the plurality of target interfaces of test target 230 includes at least one of a first interface 233a, a second interface 233b, a third interface 233c, and a fourth interface 233d.

[0049] 1, the first interface 233a is connected to the clock excitation source module 240 to receive a clock signal. The verification system of the present disclosure may be driven by a global clock to promote the functionality, performance, and stability of the synchronous digital system.

[0050] 1, the second interface 233b is configured to receive an interrupt request signal, for example, the interrupt request signal causes the corresponding hardware to stop its current operating state, switch to an operation task corresponding to the interrupt request signal, and switch back after the processing of the operation task is completed, thereby avoiding signal contention.

[0051] 1, the first master module 210 is connected to the third interface 233c to configure the registers of the test module 231. For example, as shown in FIG. 1, the first master module 210 is connected to the fourth interface 233d to reset the first part 200.

[0052] 1, there are two memory access interfaces 232, two second slave modules 220, and each second slave module 220 includes a storage unit 221. In this way, there is a one-to-one correspondence between the storage units 221 and the memory access interfaces 232, and in this way, a data transmission path can be formed between each storage unit 221 and the test module 231, thereby realizing backdoor access to the storage unit. This is merely an example and does not limit the present disclosure.

[0053] 1, the memory unit 221 of the second slave module 220 is used to store register data, that is, the main role of the second slave module 220 in the verification system 100 is to function as the memory of the verification system. For example, to realize a front door write operation, the embodiment of the present disclosure can store data written by the front door write operation in the memory unit 221 through the memory access interface 232.

[0054] 1 , if necessary, the first portion 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 embodiment of the present disclosure converts and processes the read and write speeds through the rate matching bridge 250, thereby avoiding problems such as metastable states and clock signal mismatches when transmitting data across clock domains between the test module 231 and the memory unit 221.

[0055] In some examples, the data source in the storage unit 221 of the second slave module 220 includes two types: the first is to write data to a register of the test module 231 through a front-door write operation and transmit it to the storage unit 221 of the second slave module 220 across clock domains via the rate matching bridge 250; the second is to introduce data into the storage unit 221 through a back-door data load operation.

[0056] In some examples, the storage unit 221 of the second slave module 220 has a virtual storage space. For example, the present disclosure may allocate a portion of the storage space to the storage unit 221 via a Palladium device. This is merely an example and is not intended to limit the scope of the present disclosure.

[0057] 2, the first direct programming interface 310 includes a direct programming interface (C / C++ DPI) based on C or CPP language, and the second direct programming interface 320 includes a one-time access direct programming interface (MARG DPI) based on C or CPP language. For example, the MARG DPI is a type of interface that is relatively suitable for one-time storage and reading.

[0058] The embodiment of the present disclosure connects the software side and the hardware side of the verification system through a DPI interface, thereby enabling the first master module 210 to complete, for example, backdoor access (e.g., frontdoor read / write operations) of the AMBA bus registers through the CPP interface functions of the DPI. Furthermore, based on the set MARG DPI, the storage unit 221 of the second slave module 220 can directly realize backdoor access of the storage unit 221 by calling the CPP interface functions corresponding to the MARG DPI, thereby realizing data loading and data export of the storage unit.

[0059] For example, the first function may include a function related to reading and / or writing a register, and the second function may include a function loaded and / or exported by a storage unit. The CPP interface functions used in the embodiments of the present disclosure are written and packaged in the CPP language, which allows for easy calling, more complex functions, and test cases with functions more suited to chip requirements. Furthermore, the CPP interface functions can synchronize the software and hardware sides, greatly improving the efficiency of simulation acceleration.

[0060] FIG. 3 is a schematic block diagram of a first master module of a verification system provided by some embodiments of the present disclosure.

[0061] 3, the first master module 210 includes a main core 211 and a third slave module 212. For example, the third slave module 212 is embedded in the first master module 210, and the third slave module 212 is an embedded Advanced Peripheral Bus slave module, i.e., an embedded APB module.

[0062] Note that the third slave module 212 in the embodiments of the present disclosure is called a slave module relative to the main core 211, but this is merely a naming method, and the embodiments of the present disclosure are not limited to these, and the scope of protection of the embodiments of the present disclosure is not limited by these.

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

[0064] For example, as shown in FIG. 3, the main core 211 is respectively connected to the first direct programming interface 310 and the third interface 233c, and obtains a register access instruction (i.e., an instruction for performing a read operation or a write operation on a register of the test module 231) corresponding to the first function of the test case to configure the register of the test module 231.

[0065] For example, when a user executes a test case and calls a first function, the main core 211 of the first master module 210 receives a register access instruction to configure a register of the test module 231 .

[0066] In some examples, the main core 211 may further obtain control data related to the register access instruction, including basic data required when performing a read or write operation on a register, such as a base address of the memory, a basic width of the memory, etc. This is merely an example and is not intended to limit the present disclosure.

[0067] 3, the third slave module 212 of the first master module 210 is connected to the main core 211 and the fourth interface 233d, respectively, and transmits a reset signal generated by the main core 211 to the fourth interface 233d to reset the first part 200. For example, in each test case, before executing a simulation, it is necessary to reset the states of all cores and all memories inside the hardware side to their initial states.

[0068] In some examples, if the second slave module 220 is an AMBA module, it may be instantiated into multiple AMBA modules of different types, such as an APB module, or an AXI module, or an ACE module, etc. This is merely an example and is not intended to limit the present disclosure.

[0069] In some examples, when instantiating the second slave module 220, the AMBA parameters that need to be declared include at least one of the size of the memory, the base address of the memory, and the depth of outstanding operations that can be supported, which are merely examples and are not intended to limit the present disclosure.

[0070] In some examples, independent storage spaces are allocated to the first master module 210, the second slave module 220, and the third slave module 212. For example, after completing the initial configuration of the verification system 1000, it is necessary to allocate storage space to each module, such as the first master module 210, the second slave module 220, and the third slave module 212.

[0071] FIG. 4 is a schematic diagram of address spaces of a first master module and a second slave module provided by some embodiments of the present disclosure.

[0072] 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 (1 Mbyte). For example, as shown in FIG. 4, the address range of the first master module 210 includes 0x0000_0000 to 0x000F_FFFF, which has a size of 1 MB, and 0x0010_0000 to 0x001F_FFFF, which has a size of 1 MB. For example, as shown in FIG. 4, the address range of one of the two second slave modules 220 is 0x4000_0000 to 0x7FFF_FFFF, which has a size of 1 GB, and the address range of the other second slave module 220 is 0x8000_0000 to 0xFFFF_FFFF, which has a size of 2 GB. This is merely an example and does not limit the present disclosure.

[0073] In some examples, the second portion 300 further includes a profile, and the test case is configured to execute a case configuration based on at least one first function of the profile for front door access or to execute a case configuration based on at least one second function of the profile for back door access.

[0074] In some examples, the function library module 330 includes a static library that is compiled and generated through a behavioral modeling language based on test cases and profiles.

[0075] For example, in the example of FIG. 2, the test cases provided by the test case module 340 include test0 to test3, and different test cases call different functions to verify functionality that meets requirements. For example, as shown in FIG. 2, in the case of the test case module 340, a profile can be called using test_entry() to provide the associated test case. test_entry() is the entry point for the user to edit the test case to be tested, and test_entry() calls the profile (e.g., a .cfg file) to complete the configuration of the associated test case. The verification system 1000 can provide the user with an API for configuring backdoor access and backdoor access to registers. For example, the profile is compiled using C / CPP to generate a static library (user lib), which is further analyzed by the API interface to complete, for example, register reads and writes.

[0076] The simulation acceleration verification of the above-described embodiments of the present disclosure uses test cases constructed based on C / CPP code, which results in a relatively simple environment, no complicated methodology, the simulation environment can be quickly set up, and the execution speed is very fast.

[0077] In some examples, the first function includes at least one of a register read function reg_read, a register write function reg_write, a register read check function reg_read_check, a register write read and check function reg_write_check, and a register polling wakeup read function poll_reg_equal.

[0078] 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 at a specific register address.

[0079] For example, the function reg_read_check is used to check whether the data written to a particular address register is as expected, e.g., the data written to a particular address register may be the data written via the function reg_write.

[0080] For example, the function reg_read_check first reads data from a specific address register, then compares the read data with expected data, and if the comparison results are the same, the check passes; if the comparison results are different, the current operation is stopped and an error is reported. The embodiment of the present disclosure can write data to a register at a specific address through the function reg_read_check and automatically compare the expected result with the read result, which allows for more advanced automation and improves the work efficiency of the verifier.

[0081] The operation and method of the function reg_write_check may be referred to the function reg_read_check, the difference being that the function reg_write_check further includes writing data to a specific address register, which will not be repeated here.

[0082] For example, the function poll_reg_equal polls a specific address register several times in succession until the value read from the specific address register is equal to the expected value. If the value is not equal, it continues to read. If the number of reads exceeds the maximum number of polls set by the user (e.g., 10,000), it reports an error and terminates polling. If the value read from the same address register multiple times is not equal to the expected value, it reports an error and terminates the read cycle.

[0083] For example, if the second function needs to poll and wake up some registers before performing backdoor access to the storage unit of the second slave module, the function poll_reg_equal can poll and wake up the relevant registers and check the read / write results of the register data in order.

[0084] In some examples, the second function includes at least one of a polling wakeup read function of the storage unit, poll_mem_equal, an initialization function of the storage unit, mem_init, a data load function of the storage unit, mem_load, and a data export function of the storage unit.

[0085] In some examples, the data export function of the storage unit includes a multi-byte read function of the storage unit or a data capture function of the storage unit mem_dump, and the lengths of the data segments read from the function mem_dump and the multi-byte read function of the storage unit are different, and the length of the data segment read from the function mem_dump is longer than the length of the data segment read from the multi-byte read function of the storage unit.

[0086] For example, the multi-byte read function of a storage unit includes a function mem_read32 or a function mem_read64. The function mem_read32 is used to directly read 32-bit data from a specific storage unit address, and the function mem_read64 is used to directly read 64-bit data from a specific storage unit address.

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

[0088] For example, the function mem_load can load a readable file into the verification system in hexadecimal format. This hexadecimal file is a two-dimensional array with addresses at the front and data at the back, and the function mem_load loads each piece of data into the corresponding memory space based on its address.

[0089] For example, the function poll_mem_equal polls a register at a specified address several times in succession until the value read from the storage unit at a particular address is equal to the expected value; if it is not equal, it continues reading; if the number of reads exceeds the maximum number of polls set by the user (e.g., 10,000), it reports an error and terminates polling; if multiple reads from the storage unit at the same address do not equal the expected value, it reports an error and terminates the read cycle.

[0090] For example, the function mem_init is used to initialize the storage units in the address range to be used, preventing data remaining in the storage units after the previous test case execution from affecting the execution and result comparison of the next test case. The function mem_init initializes the storage units in the set address range, and has the following five main modes: Mode 0: All values ​​in the storage unit are initialized to 0x0000_0000. Mode 1: All values ​​in the storage unit are initialized to 0xFFFF_FFFF. Mode 2: The values ​​of the storage units are initialized to the value of the address of each storage unit. Mode 3: The value of the storage unit is initialized to a value that starts at 0x0 and increases by 0x4 each time. Mode 4: The value of the storage unit is initialized to a value that starts at 0 and increases by 1 each time.

[0091] The above modes and corresponding functions are merely examples and are not intended to limit the embodiments of the present disclosure.

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

[0093] For example, the function file_cmp can compare two hex files and obtain the comparison result. In the test case of the embodiment of the present disclosure, the user can self-specify the names of the two hex files that need to be compared in the file_cmp function definition.

[0094] For example, the function glb_rst may reset the first portion 200 and reset the state of the modules in the first portion 200 .

[0095] In some examples, the multiple test cases provided by the test case module 340 may not be completely identical, and each test case may correspond to one or more functions, for example, each test case may be any one or a combination of multiple functions described above. The embodiments of the present disclosure are not limited thereto and can be freely adjusted according to actual verification needs, and will not be described again here.

[0096] It should be noted that the functions included in the function library module 330 of the embodiments of the present disclosure are not limited to the above examples, and may be other corresponding functions used to meet verification requirements, which are not exhaustive and will not be repeated here.

[0097] At least one embodiment of the present disclosure further provides a verification method that can be realized based on the verification system described in any of the above embodiments. For specific embodiments and technical effects of the verification method based on the verification system, reference can be made to the verification system provided by the above embodiments of the present disclosure.

[0098] FIG. 5 is a flowchart of a verification method provided by some embodiments of the present disclosure.

[0099] For example, as shown in FIG. 5, a verification method provided by at least one embodiment of the present disclosure includes steps S1 to S5. Step S1: Compile the RTL code based on the test module 231. Step S2: perform comprehensive compilation based on the first part 200, the test object 230, the test module 231, the first master module 210 and the second slave module 220 to obtain the compiled first part 200. Step S3: select a usage mode of the simulation verification equipment 100, add the first part 200 being compiled to at least one compilation option according to the usage mode, call a first assembler tool to disassemble the verification system 1000, generate a hardware information library for the simulation verification equipment 100, and realize the compilation of the accelerator. Step S4: Compiling the behavioral modeling language code of the second part 300. Step S5: Execute the compiled first part 200 and second part 300 to obtain a verification result.

[0100] In some examples, the verification method of the present disclosure further includes a process or step of debugging according to the verification result so that the verification passes.

[0101] In some examples, the verification method of the present disclosure further includes a process or step of configuring the simulation verification equipment 100 to visualize the verification results. Visualization methods include, but are not limited to, charts, text, waveform charts, etc. This allows the verification results to be reflected in a timely, convenient, and accurate manner, thereby facilitating the management and execution of verification work.

[0102] For example, in step S1, the step of performing RTL code compilation based on the test module 231 further includes the following process or steps: using a second compilation tool to compile the RTL file list of the test module 231 and the corresponding RTL files, and generate a DUT netlist in a predetermined format including the test module 230, such as generating a DUT netlist in a vg format including the test module 230. The generated DUT netlist is configured to be executed by the simulation verification equipment 100. Note that the setting format of the DUT netlist in the embodiments of the present disclosure is not limited to the vg format and may be other formats such as the edif format, and the embodiments of the present disclosure are not limited thereto.

[0103] For example, in step S1, the second compilation tool includes Cadence's compilation tool vavlog or compilation tool vaelab. Of course, this is merely an example and does not limit the present disclosure.

[0104] For example, in step S2, performing comprehensive compilation based on the first portion 200, the test object 230, the test module 231, the first master module 210, and the second slave module 220 to obtain the compiled first portion 200 includes the following steps or processes: based on a third compilation tool of the simulation verification equipment 100, performing comprehensive compilation on the first portion 200, the test object 230, the test module 231, the first master module 210, and the second slave module 220 (such as the two second slave modules 220 shown in FIG. 1 ) and the clock excitation source module 240 to obtain the compiled hardware side.

[0105] For example, the third compilation tool may include Cadence's Palladium-based VLAN tool. Of course, this is merely an example and is not intended to limit the present disclosure.

[0106] For example, in step S2, the target of comprehensive compilation in the embodiment of the present disclosure not only includes the first part 200, the test object 230, the test module 231, the first master module 210, and the second slave module, but also includes, for example, Cadence AVIP files and other necessary peripheral test resources required for comprehensive compilation, which are not the focus of the description of the embodiment of the present disclosure and will not be comprehensively repeated here. Therefore, the comprehensive compilation in this step can generate the compiled hardware side.

[0107] For example, in step S3, selecting a usage mode of the simulation verification equipment 100, adding the first portion 200 being compiled to at least one compile option according to the usage mode to compile the accelerator, invoking a first assembler tool to disassemble the verification system, and generating a hardware information library for the simulation verification equipment may include the following process or steps: selecting an IXCOM mode of the Palladium equipment, adding the first portion 200 being compiled according to the IXCOM mode to at least one compile option, invoking a first assembler tool to disassemble the verification system 1000, and generating a hardware information library (hardware lib). For example, the hardware information library may include lib libraries of information such as RTL, a simulation environment, and a compilation environment. This is merely an example and does not limit the present disclosure.

[0108] Embodiments of the present disclosure use Palladium's IXCOM mode to increase compatibility with non-synthesizable portions of a design, and apply portions of a design to simulation verification equipment to be compatible with other modes, reducing verification workload, reducing costs, and improving verification efficiency.

[0109] For example, in step S3, the compiled first portion 200 generated by the comprehensive compilation may be compiled using a Cadence-based IXCOM compilation tool with additional compilation options such as -z1, -ua+1xua, -dpi, and -timescale, and a first assembler tool such as Cadence's VXE may be invoked to perform processing such as decomposition (e.g., assembling natural language programming into machine code) on the entire verification system 1000, and to generate a hardware information library that can be directly used by the simulation verification device 100, thereby completing the compilation of the accelerator. This is merely an example and does not limit the present disclosure.

[0110] For example, in step S4, the behavior modeling language may be a CPP language, ie step S4 is used to compile the CPP code of the second portion 300.

[0111] For example, in step S4, the CPP code of the test case set by the user is compiled, mainly including, for example, settings of the type of the first and / or second functions to be specifically called, the combination method of the first and / or second functions to be called, specific settings of the first and / or second functions (e.g., register read / write addresses, specific written data), and a first reference file for comparison (see below for details), etc. Therefore, the verification system calls the static library file generated in step S4 during final execution, so that the test case set by the user can be enabled during the simulation acceleration verification process and complete the test function.

[0112] In some examples, the verification method of the present disclosure further includes a process or step of checking whether the above registers constituting the test module meet the target requirements of the test module 231.

[0113] For example, the test cases provided by the test case module 340 of the embodiment of the present disclosure for different test modules 231 are all different, and the same test module 231 can develop multiple different test cases based on multiple different test cases, and different data is written to the registers of the AMBA bus because the different test cases correspond to different function settings, register settings, expected data results, etc.

[0114] In some examples, the first portion 200 and the second portion 300 created in the simulation verification device 100 according to the embodiments of the present disclosure represent a verification environment built based on the simulation verification device 100, where the verification environment is divided into a hardware side and a software side that can interact with each other. For example, the first portion 200 may be installed in the simulation verification device 100, such as a Palladium device, and the hardware side and the first portion 200 may be connected and placed on another device, such as a server, that can communicate with each other. Of course, the first portion 200 and the second portion 300 may be executed together by, for example, a Palladium device, and the embodiments of the present disclosure are not limited thereto.

[0115] Fig. 6 is a flowchart of the execution process of step S5 of the verification method of Fig. 5. For example, as shown in Fig. 6, an example of step S5 includes at least steps S51 to S53. Step S51: In response to the test module 231 being the first module, read the first data in the storage unit 221 through backdoor access to obtain the first reference file. Step S52: In response to the test module 231 being the second module, read the second data in the storage unit 222 by backdoor access to obtain the second file. Step S53: Compare the second file with the first reference file to obtain a verification result.

[0116] For example, in step S51, reading the first data in the storage unit 221 via backdoor access to obtain the first reference file includes the following process or steps: in response to the completion of the execution of the test case (e.g., after the test case is executed for the first time), read the first data in the storage unit 221 via backdoor access to obtain a self-named first target hexadecimal format file, and generate a standard version of a second target hexadecimal format file based on the first target hexadecimal format file to obtain the first reference file.

[0117] For example, the first target hexadecimal format file is the first hex file and the second target hexadecimal format file is the golden version of the second hex file. This is merely an example and is not intended to limit the present disclosure.

[0118] For example, in step S52, the second module is configured as a module that is updated based on the first module. The second module is a test module that is continuously and iteratively updated based on the first module during chip development. Therefore, each time the RTL code is changed and iteratively updated in the test module 231, the test cases need to be re-run to test whether the RTL functionality has changed and calibrate the RTL using the first reference file.

[0119] For example, in step S52, the step of reading the second data in the storage unit 221 through backdoor access to obtain the second file includes the following process or steps: re-execute the test case, and read the second data in the storage unit 221 through backdoor access to obtain the second file. For example, the test case in step S52 is theoretically expected to be the same as the test case executed for the first time in the above step S51, so it can be determined whether the verification has passed.

[0120] For example, in step S53, comparing the first reference file with the second file and obtaining the verification result includes the following process or steps: if the comparison result between the first reference file and the second file is the same, the verification is passed, and a character or pattern such as "testcase pass" is printed on the graphical interface, and the process ends; if the comparison result between the second file and the first reference file is different, the verification is failed, and a character or pattern such as "testcase fail" can be printed on the graphical interface, and the test case can be debugged and the RTL code of the test module 231 can also be checked. Therefore, after modification and debugging, it can be run again and the comparison process can be repeated. If the comparison result is the same, the verification is passed and the process ends.

[0121] Therefore, if the verification fails, the step of reading the second data in the storage unit 221 through backdoor access to obtain the second file in step S52 further includes the following process or steps: debug the test case, execute the debugged test case, read the second data in the storage unit 221 through backdoor access, and obtain the second file. For example, the test case after debugging in step S52 is the same as the test case executed for the first time in step S51. This makes it possible to avoid the problem of verification failure due to an error in the test case in the actual process, and allows the simulation verification process to proceed smoothly.

[0122] In some examples, step S52 may also allow the test case to be debugged before running the test case again, although embodiments of the present disclosure are not limited thereto.

[0123] In some examples, when the compiled first portion 200 and second portion 300 are executed, the packaged instruction Make emu_run in the Makefile is executed to directly start the graphical interface of the Palladium instrument, thus printing the test case execution results and corresponding required log information in the graphical interface, which allows the user to further debug or record the results.

[0124] The verification file and basic verification process of the embodiments of the present disclosure are general-purpose, which helps reduce the verification workload. As verification work becomes more sophisticated, the number of verification cases increases and the complexity of the verification cases also increases. By continuously iterating the design and automating regression testing work, the quality of the project can be ensured and the workload of tedious tasks can be reduced.

[0125] FIG. 7 is a flowchart of a verification method provided by some other embodiments of the present disclosure.

[0126] For example, as shown in FIG. 7, a verification method provided by some embodiments of the present disclosure includes steps T1 to T8. Step T1, execute the test case for the first time. Step T2: read the first data in the storage unit through backdoor access to obtain the first reference file; Step T3, run the test case again. Step T4: read the second data in the storage unit through backdoor access to obtain the second file. In step T5, the data in the first reference file is compared with the data in the second file. In step T6, it is determined whether the data in the second file is the same as the data in the first reference file. If they are the same, proceed to step T8. If they are different, the verification fails, and in step T7, debugging of the test case and RTL check of the test module are performed. Steps T3 to T6 are repeated until the determination results are the same, and then proceed to step T8. Step T8: The verification is passed, and the verification process is terminated.

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

[0128] For example, the test case in step T3 may be a test case after being debugged if the verification fails, or may be a test case obtained by debugging a test case before starting step T3, but the embodiments of the present disclosure are not limited thereto.

[0129] Based on the above-mentioned test case verification process, the embodiments of the present disclosure can realize an automated process with a certain degree of versatility, thereby realizing a simple, efficient, and highly reusable hardware acceleration test method and process, which greatly saves time in chip verification projects and greatly improves chip verification efficiency.

[0130] 8 is a schematic structural diagram of an electronic device provided in accordance with 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 that, when executed by the processing module 410, implements a verification method in accordance with at least some embodiments of the present disclosure.

[0131] The electronic devices in the embodiments of the present disclosure include, but are not limited to, mobile terminals such as laptop computers, tablet computers, etc., and fixed terminals such as desktop computers, traditional servers, cloud servers, etc. The electronic devices shown in Figure 8 are merely examples and do not limit the functionality and scope of use of the embodiments of the present disclosure.

[0132] For example, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts may be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product including a computer program embodied in a non-transitory computer-readable medium, the computer program including program code for performing the method illustrated in the flowchart. When the computer program is executed by the processing module 801, it performs the verification method of an embodiment of the present disclosure.

[0133] It should be noted that the computer-readable medium referred to in this disclosure may be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. The computer-readable storage medium may be, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media include, but are not limited to, an electrical connection with one or more wires, a portable computer disk, a hard drive, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this disclosure, a computer-readable medium may be any tangible medium that contains or stores a program, and the program may be used by or in combination with an instruction execution system, apparatus, or device. In the embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with computer-readable program code embodied therein. Such propagated data signals can take many forms, including, but not limited to, electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transmit a program used by or in connection with an instruction execution system, apparatus, or device. Program code contained on a computer-readable medium may be transmitted over any suitable medium, including, but not limited to, wire, optical cable, RF (radio frequency), etc., or any suitable combination thereof.

[0134] The computer-readable medium may be included in the electronic device, or may exist independently of the electronic device.

[0135] It should be noted that, in the embodiment of the present disclosure, the specific functions and technical effects of the electronic device 400 may refer to the above description of the verification method, but will not be described again here.

[0136] The following points need to be explained: (1) The drawings of the embodiments of the present disclosure only include structures related to the embodiments of the present disclosure, and common designs may be referenced for other structures. (2) The embodiments and features of the embodiments of the present disclosure may be combined with each other to obtain new embodiments, provided that there is no contradiction.

[0137] The above are merely specific embodiments of the present disclosure, but the scope of protection of the present disclosure is not limited thereto, and should be subject to the scope of protection of the claims.

Claims

1. 1. A verification system, comprising: a simulation verification device; and a first part and a second part, each of which is created in the simulation verification device; the first part includes a first master module and at least one second slave module, each of which is connected to a test object; the test target includes a test module and a plurality of target interfaces connected to the periphery of the test module, the plurality of target interfaces including a memory access interface, the second slave module includes a storage unit, the storage unit is connected to the memory access interface, the second portion 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 executing the test case, call at least one first function in the function library module to provide front-door access to registers of the test module; the second direct programming interface communicates with the storage unit of the first portion, and the second direct programming interface is configured to, in response to executing the test case, call at least one second function in the function library module to achieve backdoor access of the storage unit; Verification system.

2. the first part is a hardware part configured to be created based on a hardware description language; The verification system of claim 1 , wherein the second part is a software part configured to be created based on a behavioral modeling language.

3. 2. The verification system of claim 1, wherein the simulation verification device includes a first processor and a plurality of second processors connected in parallel to the first processor.

4. 4. The verification system of claim 3, wherein 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 first portion further includes a clock excitation source module for providing a clock signal, and the plurality of target interfaces further includes at least one of a first interface, a second interface, a third 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 an interrupt request signal; the first master module is connected to the third interface to configure a register of the test module; The verification system of claim 1 , wherein the first master module is connected to the fourth interface to reset the first portion.

6. the first master module comprises an Advanced Microprocessor Bus Architecture master module, and the second slave module comprises an Advanced Microprocessor Bus Architecture slave module; The first master module includes a main core and a third slave module, and the main core is respectively connected to the first direct programming interface and the third interface, whereby the main core obtains a register access instruction corresponding to the first function of the test case to configure a register of the test module; 6. The verification system of claim 5, wherein the third slave module is connected to the main core and the fourth interface, respectively, and transmits a reset signal generated by the main core to the fourth interface to reset the first part.

7. The verification system of claim 1 , wherein the first portion further includes a rate matching bridge, the rate matching bridge configured to be coupled to the second slave module and the memory access interface, respectively.

8. the second portion further includes a profile; The test case is configured to execute a case configuration based on the at least one first function of the profile for the front door access, or to execute a case configuration based on the at least one second function of the profile for the back door access; The verification system of claim 2 , wherein the function library module includes a static library generated by compiling through the behavioral modeling language based on the test cases and the profiles.

9. the at least one first function includes at least one of a register read function, a register write function, a register read check function, a register write read and check function, and a register polling wakeup read function; The verification system of claim 1 , wherein the at least one second function includes at least one of a storage unit polling wakeup read function, a storage unit initialization function, a storage unit data load function, and a storage unit data export function.

10. 7. The verification system according to claim 6, wherein the first master module, the second slave module, and the third slave module each have an independent storage space.

11. 1. A method for verification, the method comprising: performing a compilation of register transfer level code based on the test module; performing a comprehensive compilation based on the first portion, the test object, the test module, the first master module, and the second slave module to obtain the first portion being compiled; selecting a usage mode of the simulation verification device, adding the first part being compiled to at least one compilation option according to the usage mode, invoking a first assembler tool to decompose the verification system, generating a hardware information library for the simulation verification device, and realizing compilation of an accelerator; compiling the second portion of behavioral modeling language code; Executing the compiled first and second parts to obtain a verification result.

12. the simulation verification equipment includes a Palladium equipment; The method of claim 11 , wherein the first part is a hardware side configured to be created based on a hardware description language, and the second part is a software side configured to be created based on a behavioral modeling language.

13. performing compilation of register transfer level code based on the test module, 12. The method of claim 11, further comprising: using a second compilation tool to compile the register transfer level file list of the test module and the corresponding register transfer level file, and generating a test module netlist of a predetermined format including the test object, wherein the generated test module netlist is configured to be executed by the simulation verification equipment.

14. The step of performing a comprehensive compilation based on the first portion, the test object, the test module, the first master module, and the second slave module to obtain the compiled first portion is in response to the first portion further including a clock excitation source module for providing a clock signal, 13. The method of claim 12, further comprising: performing a comprehensive compilation on the first part, the test target, the test module, the first master module, the second slave module, and the clock excitation source module based on a third compilation tool of the simulation verification equipment to obtain the compiled hardware side.

15. selecting a usage mode of the simulation verification device, adding the first part being compiled to at least one compilation option according to the usage mode, invoking a first assembler tool to decompose the verification system, and generating a hardware information library for the simulation verification device; 13. The method of claim 12, further comprising: selecting an IXCOM mode for the Palladium device; adding the first portion being compiled according to the IXCOM mode to at least one compilation option; and invoking the first assembler tool to decompose the verification system and generate the hardware information library.

16. The step of executing the compiled first and second parts to obtain a verification result includes: In response to the test module being a first module, reading first data in the storage unit through the backdoor access to obtain a first reference file; In response to the test module being a second module, reading second data in the storage unit through the backdoor access to obtain a second file, the second module being configured to be updated based on the first module; The method of claim 11 , further comprising comparing the second file with the first reference file to obtain the verification result.

17. The step of reading the first data in the storage unit by the backdoor access and obtaining the first reference file includes: reading the first data in the storage unit through the backdoor access in response to completion of execution of the test case 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.

18. The step of reading the second data of the storage unit and obtaining the second file by the backdoor access includes:

17. The method of claim 16, further comprising: debugging the test case; and executing the test case being debugged to read the second data in the storage unit through the backdoor access to obtain the second file.

19. An electronic device, the electronic device comprising: a processing module and a memory, The memory stores a computer program that, when executed by the processing module, implements the method of claim 11. electronic equipment.

20. A computer-readable storage medium having stored thereon a computer program, the computer program implementing the method of claim 11 when executed by a processing module.

Images