A verification method, device, electronic device and storage medium

Abstract

An embodiment of the present invention provides a verification method, device, electronic device, and storage medium. Based on the module timing requirements corresponding to each module in the code file to be verified, the code file to be verified is divided into a first code file and a second code file; the module timing requirement of the first module included in the first code file is lower than the module timing requirement of the second module included in the second code file; the first code file is compiled into an executable file, and based on the executable file, software simulation verification is performed in a software simulation environment; the target bit file corresponding to the second code file is deployed to a specified chip, and based on the specified chip, hardware simulation verification is performed in a hardware simulation environment; the software simulation environment and the hardware simulation environment perform bidirectional data synchronization based on a target communication interface. By adopting a combined software and hardware verification method, while improving the verification effect, the verification advantages of the two verification methods are taken into account, and it has the advantages of convenient debugging and high verification accuracy.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of computer technologies, and in particular, to a verification method, apparatus, electronic device, and storage medium. Background Art

[0002] With the increase in the scale and functional complexity of chips, simulating and verifying chip code is an essential step.

[0003] In related technologies, there are mainly two simulation verification methods for chip code: One verification method is logic verification, that is, compiling the chip code into an executable file and executing the executable file to perform the simulation of the hardware circuit. Another verification method is prototype verification, that is, compiling the chip code and synthesizing it into an actual field-programmable gate array (FPGA) hardware for verification. However, the verification process of the first verification method has a low verification accuracy for timing issues and cannot accurately detect potential timing problems; the verification cycle of the second verification method is long, and the debugging performance is poor. Therefore, there is an urgent need for a verification method that is convenient for debugging and has a high verification accuracy for timing issues. Summary of the Invention

[0004] Embodiments of the present invention provide a verification method, apparatus, electronic device, and storage medium.

[0005] To solve the above problems, embodiments of the present invention disclose a verification method, the method including:

[0006] Dividing a to-be-verified code file into a first code file and a second code file based on the module timing requirements corresponding to each module in the to-be-verified code file; the module timing requirement of a first module included in the first code file is lower than the module timing requirement of a second module included in the second code file;

[0007] Compiling the first code file into an executable file, and performing software simulation verification in a software simulation environment based on the executable file;

[0008] Deploying a target bit file corresponding to the second code file to a specified chip, and performing hardware simulation verification in a hardware simulation environment based on the specified chip; the software simulation environment and the hardware simulation environment perform bidirectional data synchronization based on a target communication interface.

[0009] On the other hand, embodiments of the present invention disclose a verification apparatus, the apparatus including:

[0010] A first partitioning module, configured to partition the to-be-verified code file into a first code file and a second code file based on the module timing requirements corresponding to each module in the to-be-verified code file; the module timing requirement of the first module included in the first code file is lower than the module timing requirement of the second module included in the second code file;

[0011] A first verification module, configured to compile the first code file into an executable file and perform software simulation verification in a software simulation environment based on the executable file;

[0012] A second verification module, configured to deploy the target bit file corresponding to the second code file to a specified chip and perform hardware simulation verification in a hardware simulation environment based on the specified chip; the software simulation environment and the hardware simulation environment perform bidirectional data synchronization based on a target communication interface.

[0013] In another aspect, an embodiment of the present invention discloses an electronic device, including: a processor, a memory, a communication interface, and a communication bus, where the processor, the memory, and the communication interface complete communication with each other through the communication bus; the memory is used to store executable instructions, and the executable instructions cause the processor to execute the foregoing method.

[0014] An embodiment of the present invention also discloses a readable storage medium, on which executable instructions are stored, and when executed by one or more processors, the executable instructions cause the processors to execute the method as described above.

[0015] The embodiments of the present invention have the following advantages: In the verification method provided in the embodiments of the present invention, based on the module timing requirements corresponding to each module in the code file to be verified, the code file to be verified is divided into a first code file and a second code file; the module timing requirement of the first module included in the first code file is lower than that of the second module included in the second code file; the first code file is compiled into an executable file, and based on the executable file, software simulation verification is performed in a software simulation environment; the target bit file corresponding to the second code file is deployed to a specified chip, and based on the specified chip, hardware simulation verification is performed in a hardware simulation environment; the software simulation environment and the hardware simulation environment perform bidirectional data synchronization based on a target communication interface. In this way, by splitting the code file to be verified into a first code file for software simulation verification and a second code file for hardware simulation verification, the first code file with lower module timing requirements can be verified based on the software simulation verification method, giving play to the advantages of high flexibility and convenient debugging in this verification method, and, enabling the second code file with higher module timing requirements to be verified based on the hardware simulation verification method, giving play to the advantage of higher verification accuracy for timing problems in this verification method, and at the same time avoiding the limitations of the two verification methods. By adopting the method of combined software and hardware verification, while improving the verification effect, the verification advantages of the two verification methods are taken into account, and it has the advantages of convenient debugging and high verification accuracy for timing problems. Further, the software simulation environment and the hardware simulation environment can perform bidirectional data synchronization based on the target communication interface, which can ensure the data consistency between the software simulation environment and the hardware simulation environment to a certain extent, while maintaining the original code logic of the code file to be verified unchanged, ensuring the accuracy and reliability of the simulation verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present invention, and those of ordinary skill in the art can obtain other drawings without creative efforts based on these drawings.

[0017] Figure 1 is a flowchart of the steps of a verification method provided by an embodiment of the present invention;

[0018] Figure 2 is a block diagram of a verification device provided by an embodiment of the present invention;

[0019] Figure 3 is a schematic structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0020] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0021] Referring to Figure 1 , a step flowchart of a verification method provided by an embodiment of the present invention is shown, which is applied to a verification platform. The verification platform can be used to perform operations such as calling a compiler to compile code (including compiling a first code file into an executable file and compiling a second code file into a target bit file), calling a simulation tool to perform software simulation verification, and implementing hardware simulation verification based on a target chip.

[0022] As Figure 1 shown, the method may specifically include the following steps:

[0023] Step 101: Divide the to-be-verified code file into a first code file and a second code file based on the module timing requirements corresponding to each module in the to-be-verified code file; the module timing requirement of the first module included in the first code file is lower than the module timing requirement of the second module included in the second code file.

[0024] In the embodiments of the present invention, the code file to be verified may be the code file of the target chip, such as Verilog code. The target chip refers to a specific chip or circuit design that needs to be verified. In the embodiments of the present invention, the target chip refers to the chip that needs to perform software and hardware co-verification. The code file to be verified may include multiple modules. A module refers to an IP (Intellectual Property) in the target chip, that is, an integrated circuit module with intellectual property rights, and can also be called an IP core. It is a mature design of a circuit module with independent functions in the target chip. Modules may include, but are not limited to: core modules, peripheral modules, and storage modules, etc. The core module may include a processor core, etc.; the peripheral module may include a Universal Asynchronous Receiver / Transmitter (UART), an Inter-Integrated Circuit (I2C), a Serial Peripheral Interface (SPI), etc.; the storage module may include a Static Random Access Memory (SRAM), a Dynamic Random Access Memory (DRAM), a Read-Only Memory (ROM), etc. Different modules have different functions. According to the timing requirements of each module, different modules may correspond to different module timing requirements. The module timing characteristics corresponding to the module can be determined according to the function of the module, the timing requirements of the input and output, and the timing constraints of the entire system. For example, it can be determined by analyzing whether the logic in the module is closely related to the clock signal, whether there is data transfer across clock domains, and whether specific timing parameters (such as setup time, hold time, etc.) are met, etc., to determine the module timing requirements.

[0025] The code file to be verified is modularly decomposed. According to the module timing requirements corresponding to each module, the modules can be divided into a first module that does not require (or requires relatively less) strict timing control and a second module that requires strict timing control according to the strictness of the timing control requirements. The second module that requires strict timing control usually involves operations such as clock signal synchronization, data sampling and transmission, etc., and has strict requirements for timing parameters, such as peripheral modules, ADC (Analog-to-Digital Converter) and DAC (Digital-to-Analog Converter), etc. The first module that does not require (or requires relatively less) strict timing control usually pays more attention to function correctness and data processing efficiency, and has relatively lower requirements for timing, such as core modules, storage modules, and algorithm acceleration modules, etc. It can be understood that the second module that requires strict timing control and the first module that does not require strict timing control are relatively divided according to the module timing requirements. Although the first module that does not require strict timing control has relatively lower requirements for timing in specific situations, during the entire verification process, it is still necessary to ensure that each module in the target chip can work together and meet the overall timing requirements.

[0026] After dividing the modules according to the module timing requirements corresponding to each module to obtain a second module that requires strict timing control and a first module that does not require (or requires relatively less) strict timing control, code integration can be performed based on the first module that does not require (or requires relatively less) strict timing control to obtain a first code file, and code integration can be performed based on the second module that requires strict timing control to obtain a second code file. The first code file and the second code file can be Verilog code. The module timing requirements of the first module included in the first code file are lower than the module timing requirements of the second module included in the second code file. During the integration process, the first module and the second module can be copied or moved to the first code file and the second code file respectively. Without destroying the original function implementation and data flow, ensure that the logical associations between the modules within the code file are correct, and at the same time maintain the consistency of the interfaces, including signal names, bit widths, directions, and timing requirements, etc. After dividing the code file to be verified into the first code file and the second code file, the first code file and the second code file can be respectively simulated and verified through a simulation tool to ensure that the functions and timing characteristics of each module meet the design requirements. This includes verifying whether the interface connections between the modules are correct, whether the data flow is unobstructed, and whether the timing constraints are met, etc.

[0027] Step 102: Compile the first code file into an executable file, and based on the executable file, perform software simulation verification in a software simulation environment.

[0028] In the embodiments of the present invention, for the first module that does not require (or relatively requires less) strict timing control, a software simulation verification method can be used to verify these modules. Software simulation is to simulate and verify the functions and characteristics of a digital circuit design based on a hardware description language. The first code file is compiled into an executable file by a compiler, and based on a simulation tool, the executable file is executed to perform software simulation verification in a software simulation environment. The process of compiling the first code file into an executable file may include: using a code conversion tool, such as a v2c tool or a Verilator tool, etc., to convert the first code file from Verilog code to C language code or C++ code. Using a compiler, such as gcc, to compile the C language code or C++ code into an executable file. Invoking a simulation tool to execute the executable file on a host computer, configuring simulation parameters and input stimuli, comparing the output results with the expected results, analyzing the correctness of the design, and obtaining the software simulation verification results to perform software simulation verification in a software simulation environment. The software simulation verification environment is a domain specifically used for simulating and verifying the first module in the first code file. Exemplarily, the software simulation verification environment may include a compiler, a test bench, such as a verification platform, the first code file, and related simulation tools and libraries. In this environment, the functions, performance, stability, etc. of the first module in the first code file can be comprehensively tested and verified by simulating the operating environment and various input conditions of each module in the first code file.

[0029] Step 103: Deploy the target bit file corresponding to the second code file to a specified chip, and based on the specified chip, perform hardware simulation verification in a hardware simulation environment; the software simulation environment and the hardware simulation environment perform bidirectional data synchronization based on a target communication interface.

[0030] In the embodiments of the present invention, for the second module that requires strict timing control, a hardware simulation verification method can be adopted to verify these modules. The hardware simulation verification method refers to compiling the code through a compiler and synthesizing it into a real hardware circuit, and performing simulation verification through the real hardware circuit. Deploy the target bit file corresponding to the second code file to the specified chip, and based on the specified chip, perform hardware simulation verification in the hardware simulation environment. The process of deploying the target bit file corresponding to the second code file to the specified chip may include: inputting the second code file into the synthesis tool. The synthesis tool converts the second code file into a gate-level netlist (Netlist) and generates configuration information. The gate-level netlist is a circuit description composed of basic logic gates (such as AND gates, OR gates, NOT gates, etc.). Input the configuration information generated by the synthesis tool into the placement and routing tool. The placement and routing tool is used to determine the specific positions of each logic element on the specified chip and generate wiring information connecting these elements. Convert the placement and routing information file into a target bit file, and the target bit file can be a bit file. The target bit file can be configuration data that can be directly loaded by the specified chip. The target bit file contains configuration information of the chip, such as a complete description of all logic elements and connection relationships inside the chip, and is used to guide the implementation of the logic function inside the FPGA. Deploy the target bit file to the specified chip, specifically, the target bit file can be burned into the specified chip. The specified chip can be an FPGA chip. The FPGA chip represents a Field-Programmable Gate Array, which is a programmable logic device and can achieve different circuit connections and functions through programming. The FPGA chip has the advantages of fast operating speed and can be docked with real peripherals. Through writing test programs, using debugging tools or building a test platform, perform hardware simulation verification in the hardware simulation environment based on the specified chip. The hardware simulation environment usually includes the specified chip, peripheral circuits, verification platform, debugging tools, and related hardware and software interfaces. Specifically, after deploying the target bit file to the specified chip, connect the peripheral circuit and the test device, configure the debugging tool and set breakpoints or watchpoints, run the simulation and observe the hardware behavior. Stimulate the hardware design on the specified chip and capture its response. Based on the response, compare it with the expected result to obtain the hardware simulation verification result.

[0031] Since the code to be verified is divided into a first code file and a second code file, and software verification and hardware verification are respectively used for simulation verification, the data that needs to be interacted between the software verification environment and the hardware verification environment needs to be synchronized to ensure data consistency and accuracy. The bidirectional data synchronization between the software simulation environment and the hardware simulation environment can be achieved by calling the target communication interface through the interface call function in the automation script of the verification platform. Specifically, the host computer can be connected to the board of the specified chip. For example, the host computer and the board of the specified chip can be connected through a Universal Serial Bus (USB) data cable, and at the same time, the bidirectional data synchronization between the software simulation environment and the hardware simulation environment can be achieved through the Universal Serial Bus (USB) interface, so as to realize the data interaction and collaborative work between different simulation environments. In this way, cross-domain access to registers between the software simulation environment and the hardware simulation environment can be achieved based on the target communication interface.

[0032] In the embodiment of the present invention, based on the module timing requirements corresponding to each module in the code file to be verified, the code file to be verified is divided into a first code file and a second code file; the module timing requirement of the first module included in the first code file is lower than that of the second module included in the second code file; the first code file is compiled into an executable file, and based on the executable file, software simulation verification is carried out in the software simulation environment; the target bit file corresponding to the second code file is deployed to the specified chip, and based on the specified chip, hardware simulation verification is carried out in the hardware simulation environment; the software simulation environment and the hardware simulation environment perform bidirectional data synchronization based on the target communication interface. In this way, by splitting the code file to be verified into a first code file for software simulation verification and a second code file for hardware simulation verification, the first code file with lower module timing requirements can be verified based on the software simulation verification method, giving play to the advantages of high flexibility of this verification method and convenient debugging during the verification process, and, the second code file with higher module timing requirements can be verified based on the hardware simulation verification method, giving play to the advantage of higher verification accuracy of this verification method for timing problems, and at the same time avoiding the limitations of the two verification methods. By adopting the method of combined software and hardware verification, while improving the verification effect, the verification advantages of the two verification methods are taken into account, and it has the advantages of convenient debugging and high verification accuracy for timing problems. Further, the software simulation environment and the hardware simulation environment can perform bidirectional data synchronization based on the target communication interface, which can ensure the data consistency between the software simulation environment and the hardware simulation environment to a certain extent, and at the same time maintain the original code logic of the code file to be verified unchanged, ensuring the accuracy and reliability of the simulation verification.

[0033] Optionally, the embodiment of the present invention may further include the following steps:

[0034] Step 201: When the same target register with the same name is included in the first code file and the second code file, for the target register, create a first backup register corresponding to the target register in the first code file, and redirect the memory access operation for the target register in the first code file to the first backup register.

[0035] Step 202: For the target register, create a second backup register corresponding to the target register in the second code file, and redirect the memory access operation for the target register in the second code file to the second backup register.

[0036] In the embodiments of the present invention, when the same target register with the same name is included in the first code file and the second code file, it indicates that both the first code file and the second code file involve memory access operations for the same target register. Since the first code file and the second code file are respectively in two different simulation environments, in order to improve the independence of verification and ensure data consistency for the same target register in the software simulation environment and the hardware simulation environment, backup registers corresponding to the target register can be added respectively in the first code file and the second code file, and the original memory access operations for the target register in the first code file and the second code file are redirected to the backup registers. The interfaces of the backup registers and the target registers (such as signal names, bit widths, directions, etc.), definitions, register names, and usage methods are kept consistent. Specifically, a first backup register corresponding to the target register can be created in the first code file, and the memory access operation for the target register in the first code file is redirected to the first backup register. At the same time, a second backup register corresponding to the target register is created in the second code file, and the memory access operation for the target register in the second code file is redirected to the second backup register. The values in the first backup register and the second backup register should be kept consistent. In this way, during the simulation verification process, if a memory access operation needs to be performed on the target register, the memory access operation can be directly performed on the local backup register.

[0037] The process of redirecting the original memory access operation for the target register to the backup register may include: identifying the read and write operations for the target register in the first code file and the second code file, which may include operations such as reading the value of the register and writing a new value to the register. For these read and write operations, replace the register address and register name corresponding to the target register with the register address and register name corresponding to the backup register.

[0038] It can be understood that if there are multiple target registers with the same name in the first code file and the second code file, backup registers corresponding to each target register can be created in the first code file and the second code file, and the memory access operations for the target registers can be redirected to their respective corresponding backup registers.

[0039] In the embodiments of the present invention, when there are the same target registers with the same name in the first code file and the second code file, by creating backup registers and redirecting the memory access operations for the target registers to the backup registers, the independence of software and hardware verification can be improved, while ensuring that the code logic is not affected and maintaining the code stability.

[0040] Optionally, the embodiments of the present invention may further include the following steps:

[0041] Step 301, when the second backup register is executed with a first write operation in the hardware simulation environment, synchronize the first write value corresponding to the first write operation to the first backup register in the software simulation environment based on the target communication interface.

[0042] In the embodiments of the present invention, in the hardware simulation environment, if the second backup register is executed with a first write operation, in order to maintain data consistency, the first write value corresponding to the first write operation can be synchronized to the first backup register in the software simulation environment based on the target communication interface. Specifically, when detecting a change in the value in the second backup register, an interface call function can be called to transfer the first write value to the software simulation environment based on the target communication interface, and replace the original value in the second backup server with the first write value to ensure data consistency between the first backup register and the second backup register.

[0043] Step 302, when the first backup register is executed with a second write operation in the software simulation environment, synchronize the second write value corresponding to the second write operation to the second backup register in the hardware simulation environment based on the target communication interface.

[0044] In the embodiments of the present invention, in the software simulation environment, if the first backup register is executed with a second write operation, the second write value corresponding to the second write operation can be synchronized to the second backup register in the hardware simulation environment based on the target communication interface. Specifically, when detecting a change in the value in the first backup register, an interface call function can be called to transfer the second write value to the hardware simulation environment based on the target communication interface, and replace the original value in the first backup server with the second write value to ensure data consistency between the first backup register and the second backup register.

[0045] In the embodiment of the present invention, when a write operation is performed on the backup register, the written value can be synchronously updated to the backup register with the same name in the other simulation environment through the target communication interface. In this way, it can be ensured that the values in the first backup register and the second backup register are always consistent, and the consistency and correctness of the data are ensured based on the synchronization mechanism.

[0046] Optionally, the embodiment of the present invention may further include the following steps:

[0047] Step 401: When the second code file does not contain the write logic for the second backup register, if a first read operation is performed on the second backup register in the hardware simulation environment, the current value of the first backup register in the software simulation environment is obtained based on the target communication interface as the read result corresponding to the first read operation.

[0048] In the embodiment of the present invention, when the second code file does not contain the write logic for the second backup register, that is, during the hardware simulation verification in the hardware simulation environment, no write operation will be performed on the second backup register, and only read operations will be performed on the second backup register. Correspondingly, during the software simulation verification in the software simulation environment, read and write operations may be performed on the first backup register with the same name as the second backup register. At this time, the value in the first backup register may change due to the write operation, that is, the value in the first backup register can be used as the latest value. In this case, it is not necessary to synchronize the value to the second backup register every time a write operation is performed on the first backup register. Instead, when a read operation needs to be performed on the second backup register in the hardware simulation environment, the value in the first backup register in the software simulation environment can be directly read.

[0049] If a first read operation is performed on the second backup register in the hardware simulation environment, the current value of the first backup register in the software simulation environment can be obtained based on the target communication interface as the read result corresponding to the first read operation. Exemplarily, when a first read operation on the second backup register is detected in the hardware simulation environment, the compiler will call the interface call function, determine the first backup register with the same name as the second backup register in the software simulation environment based on the target communication interface, obtain the current value in the first backup register, return the current value to the hardware simulation environment, and output it as the read result corresponding to the first read operation.

[0050] Step 402: When the write logic for the first backup register is not included in the first code file, if a second read operation is performed on the first backup register in the software simulation environment, obtain the current value of the second backup register in the hardware simulation environment based on the target communication interface, and use it as the read result corresponding to the second read operation.

[0051] In the embodiment of the present invention, the write logic for the first backup register is not included in the first code file, that is, during the software simulation verification in the software simulation environment, the first backup register will not be written, and only the first backup register will be written. Correspondingly, during the hardware simulation verification in the hardware simulation environment, read and write operations may be performed on the second backup register with the same name as the first backup register. At this time, the value in the second backup register may change due to the write operation, that is, the value in the second backup register can be used as the latest value. In this case, it is not necessary to synchronize the value to the first backup register every time the second backup register is written. Instead, when a read operation needs to be performed on the first backup register in the software simulation environment, the value in the second backup register in the hardware simulation environment can be directly read.

[0052] If a second read operation is performed on the first backup register in the software simulation environment, the current value of the second backup register in the hardware simulation environment can be obtained based on the target communication interface and used as the read result corresponding to the second read operation. Exemplarily, when a second read operation on the first backup register is detected in the software simulation environment, the compiler will call the interface call function, determine the second backup register with the same name as the first backup register in the hardware simulation environment based on the target communication interface, obtain the current value in the second backup register, return the current value to the software simulation environment, and output it as the read result corresponding to the second read operation.

[0053] In the embodiment of the present invention, when no write operation is performed on the local backup register in its own simulation environment, if a read operation is performed on the local backup register in its own simulation environment, the current value of the backup register with the same name in the other simulation environment can be obtained through the target communication interface as the read result of the read operation. Without the need to synchronize the register values in real time, it alleviates the bandwidth occupancy to a certain extent while ensuring data consistency and accuracy.

[0054] Optionally, step 101 may include the following steps:

[0055] Step 501: Determine the first code file according to the first code marker inserted in the code file to be verified in advance; the first code marker is used to indicate the first module whose module timing requirement is lower than the preset requirement.

[0056] In an embodiment of the present invention, according to the module functions and module timing requirements of each module in the code file to be verified, a first code marker is inserted into the code file to be verified in advance. The first code marker is used to indicate a first module whose module timing requirement is lower than a preset requirement. The first module may include a core module, a storage module, an algorithm acceleration module, etc. The preset requirement can be determined according to actual verification requirements, and the embodiment of the present invention does not limit this. The first module with a module timing requirement lower than the preset requirement may be a module with a lower strictness degree of the module timing requirement. The first code marker may be a predefined code field, and the embodiment of the present invention does not limit this.

[0057] Traverse the code file to be verified to determine the first module indicated by the first code marker, and based on the first module, integrate to obtain a first code file.

[0058] Step 502: Determine the second code file according to the second code marker inserted into the code file to be verified in advance; the second code marker is used to indicate a second module whose module timing requirement is higher than the preset requirement.

[0059] In an embodiment of the present invention, according to the module functions and module timing requirements of each module in the code file to be verified, a second code marker is inserted into the code file to be verified in advance. The second code marker is used to indicate a second module whose module timing requirement is higher than the preset requirement. Among them, the second module with a module timing requirement higher than the preset requirement may be a module with a higher strictness degree of the module timing requirement. The second module may include a peripheral module, an ADC (analog-to-digital converter), a DAC (digital-to-analog converter), etc. The second code marker may be a predefined code field, and the embodiment of the present invention does not limit this.

[0060] Traverse the code file to be verified to determine the second module indicated by the second code marker, and based on the second module, integrate to obtain a second code file.

[0061] It can be understood that in the process of dividing the code file to be verified into a first code file and a second code file, for the unmarked modules in the code file to be verified, a default type of the unmarked modules can be set in advance. For example, the unmarked modules can be default determined as the first module.

[0062] In an embodiment of the present invention, by inserting a first code marker and a second code marker into the code file to be verified, the code file to be verified is divided to obtain a first code file and a second code file, which can accurately split the code file according to the module timing requirements and provide accurately classified code files for software and hardware simulation verification respectively.

[0063] Optionally, step 101 may further include the following steps:

[0064] Step 601: Obtain a pre-set target configuration file; the target configuration file includes a first configuration sub-file, a second configuration sub-file, and the code file to be verified.

[0065] In an embodiment of the present invention, the compiler obtains a pre-set target configuration file. The target configuration file can be obtained by the compiler receiving an external input. The target configuration file may include a first configuration sub-file, a second configuration sub-file, and a code file to be verified. The first configuration sub-file may define a first module name, and the first module name is the module name corresponding to a module with a low module timing requirement defined in advance. For example, the module names corresponding to a peripheral module, an ADC (analog-to-digital converter), and a DAC (digital-to-analog converter), etc. The second configuration sub-file may include a defined second module name, and the second module name is the module name corresponding to a module with a high module timing requirement defined in advance. For example, the module names corresponding to a core module, a storage module, and an algorithm acceleration module, etc. The code file to be verified may include one code file. In the case where the target chip structure is complex, the code file to be verified may also include multiple module code files, and each module code file is used to represent a functional module, and each module code file may be named after the module name of the functional module.

[0066] Step 602: Based on the first module name in the first configuration sub-file, determine a first module in the code file to be verified whose module timing requirement is lower than the preset requirement, and generate the first code file based on the first module.

[0067] In an embodiment of the present invention, the compiler parses the target configuration file to obtain the first configuration sub-file, the second configuration sub-file, and the code file to be verified. Based on the first module name in the first configuration sub-file, a module matching the first module name is determined in the code to be verified as the first module. Code integration is performed based on the first module to generate the first code file. Correspondingly, in the case where the code file to be verified includes multiple module code files, a module code file matching the first module name can be determined in the multiple module code files, and the module code files are integrated to generate the first code file.

[0068] Step 603: Based on the second module name in the second configuration sub-file, determine a second module in the code file to be verified whose module timing requirement is higher than the preset requirement, and generate the second code file based on the second module.

[0069] In an embodiment of the present invention, based on the second module name in the second configuration sub-file, a module matching the second module name is determined in the code to be verified as the second module. Code integration is performed based on the second module to generate a second code file. Correspondingly, when the code file to be verified contains multiple module code files, a module code file matching the second module name can be determined in the multiple module code files, and the module code files are integrated to generate a second code file.

[0070] It can be understood that for the code content in the code file to be verified that is not determined as the first module or the second module, a default type of the module that is not determined as the first module or the second module can be preset. For example, a module that is not determined as the first module or the second module can be default determined as the first module.

[0071] In an embodiment of the present invention, based on the target configuration file, in a non-intrusive manner, that is, without modifying the code file to be verified, the division of the code file to be verified can be automatically completed, improving the efficiency of code division.

[0072] In an embodiment of the present invention, through a verification platform, the code file to be verified can be divided into a first code file and a second code file, and a compiler is called to compile the first code file into an executable file, a simulation tool is called for software simulation verification, and a compiler is called to compile the second code file into a target bit file, and a synthesis tool is called to deploy the target bit file on a specified chip for hardware simulation verification. At the same time, the target communication interface generated by the automated script of the verification platform can realize two-way data synchronization between the software verification environment and the hardware verification environment, and further realize the backup of the target register and the synchronization logic of cross-domain register access to maintain data consistency.

[0073] Refer to Figure 2 , which shows a block diagram of a verification device provided by an embodiment of the present invention. As Figure 2 shown, the device may specifically include:

[0074] A first division module 701, configured to divide the code file to be verified into a first code file and a second code file based on the module timing requirements corresponding to each module in the code file to be verified; the module timing requirement of the first module included in the first code file is lower than the module timing requirement of the second module included in the second code file;

[0075] A first verification module 702, configured to compile the first code file into an executable file and perform software simulation verification in a software simulation environment based on the executable file;

[0076] The second verification module 703 is configured to deploy the target bit file corresponding to the second code file to a specified chip, and perform hardware simulation verification in a hardware simulation environment based on the specified chip; the software simulation environment and the hardware simulation environment perform bidirectional data synchronization based on a target communication interface.

[0077] Optionally, the apparatus further includes:

[0078] The first creation module is configured to, when the first code file and the second code file include the same target register with the same name, create a first backup register corresponding to the target register in the first code file for the target register, and redirect the memory access operation for the target register in the first code file to the first backup register;

[0079] The second creation module is configured to create a second backup register corresponding to the target register in the second code file for the target register, and redirect the memory access operation for the target register in the second code file to the second backup register.

[0080] Optionally, the apparatus further includes:

[0081] The first synchronization module is configured to, when a first write operation is performed on the second backup register in the hardware simulation environment, synchronize a first write value corresponding to the first write operation to the first backup register in the software simulation environment based on the target communication interface;

[0082] The second synchronization module is configured to, when a second write operation is performed on the first backup register in the software simulation environment, synchronize a second write value corresponding to the second write operation to the second backup register in the hardware simulation environment based on the target communication interface.

[0083] Optionally, the apparatus further includes:

[0084] The first acquisition module is configured to, when the second code file does not include write logic for the second backup register, if a first read operation is performed on the second backup register in the hardware simulation environment, acquire the current value of the first backup register in the software simulation environment as a read result corresponding to the first read operation based on the target communication interface;

[0085] A second acquisition module, configured to, when the first code file does not include write logic for the first backup register, if a second read operation is performed on the first backup register in the software simulation environment, obtain, based on the target communication interface, the current value of the second backup register in the hardware simulation environment as the read result corresponding to the second read operation.

[0086] Optionally, the first partitioning module 701 includes:

[0087] A first determination module, configured to determine the first code file according to a first code marker inserted in the code file to be verified in advance; the first code marker is used to indicate a first module whose module timing requirement is lower than a preset requirement;

[0088] A second determination module, configured to determine the second code file according to a second code marker inserted in the code file to be verified in advance; the second code marker is used to indicate a second module whose module timing requirement is higher than the preset requirement.

[0089] Optionally, the first partitioning module 701 includes:

[0090] A first acquisition module, configured to acquire a preset target configuration file; the target configuration file includes a first configuration sub-file, a second configuration sub-file, and the code file to be verified;

[0091] A first generation module, configured to determine, based on the first module name in the first configuration sub-file, a first module in the code file to be verified whose module timing requirement is lower than the preset requirement, and generate the first code file based on the first module;

[0092] A second generation module, configured to determine, based on the second module name in the second configuration sub-file, a second module in the code file to be verified whose module timing requirement is higher than the preset requirement, and generate the second code file based on the second module.

[0093] Refer to Figure 3 , which is a schematic structural diagram of an electronic device provided in an embodiment of the present invention. As Figure 3 shown, the electronic device includes: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface complete communication with each other through the communication bus; the memory is used to store executable instructions, and the executable instructions cause the processor to execute the verification method in the foregoing embodiment. The executable instructions may form a program.

[0094] An embodiment of the present invention provides a readable storage medium, on which executable instructions are stored. When executed by one or more processors, the processors are caused to execute the verification method of the foregoing embodiment.

[0095] Each embodiment in this specification is described in a progressive manner. The key point of each embodiment is the difference from other embodiments. For the same or similar parts among the embodiments, reference can be made to each other.

[0096] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, a device, or a computer program product. Therefore, the embodiments of the present invention can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the embodiments of the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. It should be noted that all actions of obtaining signals, information, or data in this application are carried out on the premise of complying with the corresponding data protection regulations and policies of the country where it is located and obtaining authorization from the owner of the corresponding device. The embodiments of the present invention are described with reference to the flowcharts and / or block diagrams of methods, terminal devices (systems), and computer program products according to the embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram can be implemented by computer program instructions, and the combination of the processes and / or blocks in the flowchart and / or block diagram can also be implemented by computer program instructions. These computer program instructions can be provided to the processors of general-purpose computers, special-purpose computers, embedded processors, or other programmable data processing terminal devices to generate a machine, so that the instructions executed by the processors of the computer or other programmable data processing terminal devices generate a device for implementing the functions specified in Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0097] These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing terminal device to work in a predictive manner, so that the instructions stored in the computer-readable memory generate a manufactured product including an instruction device, and the instruction device implements the functions specified in Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0098] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device, so that a series of operation steps are executed on the computer or other programmable terminal device to generate a computer-implemented process. Therefore, the instructions executed on the computer or other programmable terminal device provide for implementing in the processFigure 1 one process or multiple processes and / or blocks Figure 1 steps of functions specified in one block or multiple blocks.

[0099] Although the preferred embodiments of the embodiments of the present invention have been described, those skilled in the art can make additional changes and modifications to these embodiments once they know the basic creative concepts. Therefore, the appended claims are intended to be construed as including the preferred embodiments and all changes and modifications falling within the scope of the embodiments of the present invention.

[0100] Finally, it should also be noted that in this text, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or terminal device comprising a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or terminal device. Without further limitation, an element defined by the statement "comprising one..." does not exclude the existence of additional identical elements in the process, method, article or terminal device comprising the said element.

[0101] The above has introduced in detail a method for generating an instruction stream file, an apparatus for generating an instruction stream file, an electronic device and a readable storage medium provided by the present invention. Specific examples are used in this text to elaborate on the principle and implementation manner of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention; at the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation manner and application scope. In summary, the content of this specification should not be construed as a limitation to the present invention.

Claims

1. A verification method, characterized in that: The method comprises: Based on the module timing requirements corresponding to each module in the code file to be verified, the code file to be verified is divided into a first code file and a second code file; the module timing requirement of the first module included in the first code file is lower than the module timing requirement of the second module included in the second code file; Compiling the first code file into an executable file, and calling a simulation tool to execute the executable file on a host computer to perform software simulation verification in a software simulation environment; The target bit file corresponding to the second code file is deployed to a designated chip, and hardware simulation verification is performed in a hardware simulation environment based on the designated chip; the software simulation environment and the hardware simulation environment perform bidirectional data synchronization based on a target communication interface.

2. The method according to claim 1, characterized in that The method further comprises: In a case where the first code file and the second code file contain the same target register with the same name, for the target register, creating a first backup register corresponding to the target register in the first code file, and redirecting a memory access operation for the target register in the first code file to the first backup register; For the target register, a second backup register corresponding to the target register is created in the second code file, and a memory access operation for the target register in the second code file is redirected to the second backup register.

3. The method according to claim 2, characterized in that The method further comprises: In a case where a first write operation is performed on the second backup register in the hardware emulation environment, synchronizing a first write value corresponding to the first write operation to the first backup register in the software emulation environment based on the target communication interface; In a case where a second write operation is performed on the first backup register in the software emulation environment, a second write value corresponding to the second write operation is synchronized to the second backup register in the hardware emulation environment based on the target communication interface.

4. The method according to claim 2, characterized in that: The method further comprises: In a case where the second code file does not include write logic for the second backup register, if a first read operation is performed on the second backup register in the hardware simulation environment, a current value of the first backup register in the software simulation environment is obtained based on the target communication interface as a read result corresponding to the first read operation; In the case where the first code file does not contain the write logic for the first backup register, if a second read operation is performed on the first backup register in the software simulation environment, the current value of the second backup register in the hardware simulation environment is obtained based on the target communication interface as the read result corresponding to the second read operation.

5. The method according to claim 1, characterized in that The method of dividing the code file to be verified into a first code file and a second code file based on the module timing requirements corresponding to each module in the code file to be verified comprises: Determine the first code file according to a first code mark pre-inserted into the code file to be verified; the first code mark is used to indicate a first module whose module timing requirement is lower than a preset requirement; The second code file is determined according to a second code mark pre-inserted into the code file to be verified; the second code mark is used to indicate a second module whose module timing requirement is higher than the preset requirement.

6. The method according to claim 1, characterized in that The method of dividing the code file to be verified into a first code file and a second code file based on the module timing requirements corresponding to each module in the code file to be verified comprises: Obtaining a preset target configuration file; the target configuration file includes a first configuration sub-file, a second configuration sub-file and the code file to be verified; Based on the first module name in the first configuration subfile, determining in the code file to be verified a first module whose module timing requirement is lower than a preset requirement, and generating the first code file based on the first module; Based on the second module name in the second configuration subfile, a second module having a module timing requirement higher than the preset requirement is determined in the code file to be verified, and the second code file is generated based on the second module.

7. A verification device, characterized in that: The device comprises: A first division module is used to divide the code file to be verified into a first code file and a second code file based on the module timing requirements corresponding to each module in the code file to be verified; the module timing requirement of the first module included in the first code file is lower than the module timing requirement of the second module included in the second code file; A first verification module, used for compiling the first code file into an executable file, calling a simulation tool to execute the executable file on a host computer, and performing software simulation verification in a software simulation environment; The second verification module is used to deploy the target bit file corresponding to the second code file to a specified chip, and perform hardware simulation verification in a hardware simulation environment based on the specified chip; the software simulation environment and the hardware simulation environment perform two-way data synchronization based on a target communication interface.

8. The device according to claim 7, characterized in that The device also includes: a first creation module, configured to, when the first code file and the second code file contain the same target register with the same name, create a first backup register corresponding to the target register in the first code file for the target register, and redirect a memory access operation for the target register in the first code file to the first backup register; The second creation module is used to create a second backup register corresponding to the target register in the second code file, and redirect the memory access operation of the target register in the second code file to the second backup register.

9. An electronic device, characterized in that: include: A processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other via the communication bus; The memory is used to store executable instructions, and the executable instructions enable the processor to execute the verification method according to any one of claims 1 to 6.

10. A readable storage medium, characterized in that: Executable instructions are stored thereon, and when executed by one or more processors, the processors are caused to perform the verification method according to any one of claims 1 to 6.

Images