Verification method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a verification method and device, electronic equipment and a storage medium, and the method comprises the steps: dividing a to-be-verified code file into a first code file and a second code file based on a module time sequence requirement corresponding to each module in the to-be-verified code file; the module time sequence requirement of the first module contained in the first code file is lower than the module time sequence requirement of the second module contained in the second code file; compiling the first code file into an executable file, and performing software simulation verification in a software simulation environment based on the executable file; 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; and the software simulation environment and the hardware simulation environment perform bidirectional data synchronization based on the target communication interface. A software and hardware combined verification mode is adopted, the verification effect is improved, the verification advantages of the two verification modes are considered at the same time, and the method has the advantages of being convenient to debug and high in verification precision.

Description

Technical Field

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

[0002] As chip size and functional complexity increase, simulation and verification of chip code is an essential step.

[0003] In the related art, there are mainly two simulation verification methods for chip codes: one verification method is logic verification, which is to compile the chip code into an executable file and execute the executable file to simulate the hardware circuit. The other verification method is prototype verification, which is to compile the chip code and integrate it into the actual field programmable gate array (FPGA) hardware for verification. However, the verification process of the first verification method has low verification accuracy for timing problems and cannot accurately detect potential timing problems; the second verification method has a long verification cycle and poor debugging performance. Therefore, there is an urgent need for a verification method that is convenient for debugging and has high verification accuracy for timing problems. Summary of the invention

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

[0005] In order to solve the above problem, an embodiment of the present invention discloses a verification method, which includes: 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 performing software simulation verification in a software simulation environment based on the executable file; 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.

[0006] On the other hand, an embodiment of the present invention discloses a verification device, the device comprising: 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, and performing software simulation verification in a software simulation environment based on the executable file; 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.

[0007] On the other hand, an embodiment of the present invention discloses an electronic device, comprising: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store executable instructions, and the executable instructions enable the processor to execute the aforementioned method.

[0008] The embodiment of the present invention further discloses a readable storage medium on which executable instructions are stored. When executed by one or more processors, the processors execute the method as described above.

[0009] The embodiments of the present invention include 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 requirements of the first module contained in the first code file are lower than the module timing requirements of the second module contained 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 full play to the advantages of the 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 full play to the advantages of the high verification accuracy of this verification method for timing problems, and at the same time avoiding the limitations of the two verification methods, adopting the software and hardware joint verification method, while improving the verification effect, taking into account the verification advantages of the two verification methods, with the advantages of convenient debugging and high verification accuracy for timing problems. Furthermore, the software simulation environment and the hardware simulation environment can perform two-way data synchronization based on the target communication interface, which can ensure the data consistency of 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

[0010] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative labor.

[0011] Figure 1 is a flowchart of a verification method provided by an embodiment of the present invention; Figure 2 is a block diagram of a verification device provided by an embodiment of the present invention; Figure 3 It is a structural schematic diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0012] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0013] Reference Figure 1 , shows a flow chart of the steps of a verification method provided by an embodiment of the present invention, which is applied to a verification platform. The verification platform can be used to call 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), call a simulation tool to perform software simulation verification, and implement hardware simulation verification based on a target chip.

[0014] like Figure 1 As shown, the method may specifically include the following steps: Step 101: based on the module timing requirements corresponding to each module in the code file to be verified, divide the code file to be verified 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.

[0015] In the embodiment of the present invention, the code file to be verified may be a code file of a target chip, such as a Verilog code. The target chip refers to a specific chip or circuit design that needs to be verified. In the embodiment of the present invention, the target chip refers to a chip that needs to be verified by software and hardware linkage. The code file to be verified may include multiple modules. The module refers to the IP (Intellectual Property) in the target chip, that is, an integrated circuit module with intellectual property rights, which may also be called an IP core (IP Core), which is a mature design of a circuit module with independent functions in the target chip. The modules may include, but are not limited to: core modules, peripheral modules, and storage modules. The core module may include a processor core, etc.; the peripheral module may include a universal asynchronous receiver and transmitter (UART), an integrated circuit bus (Inter-Integrated Circuit, I2C), a serial peripheral interface (SPI), etc.; the storage module may include a static random access memory (Static Random Access Memory, SRAM), a dynamic random access memory (Dynamic Random Access Memory, DRAM), a read-only memory (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 based on the module's function, the input and output timing requirements, and the timing constraints of the entire system. For example, the module timing requirements 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.

[0016] The code files to be verified are modularly decomposed. According to the module timing requirements corresponding to each module and the strictness of the timing control requirements, each module can be divided into a first module that does not require (or relatively requires less) strict timing control and a second module that requires strict timing control. The second module that requires strict timing control usually involves operations such as clock signal synchronization, data sampling and transmission, and has strict requirements on timing parameters, such as peripheral modules, ADC (analog-to-digital converter) and DAC (digital-to-analog converter). The second module that does not require (or relatively requires less) strict timing control usually pays more attention to functional correctness and data processing efficiency, and has relatively low requirements on timing, such as core modules, storage modules and algorithm acceleration modules. 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 lower timing requirements in certain circumstances, it is still necessary to ensure that all modules in the target chip can work together and meet the overall timing requirements during the entire verification process.

[0017] After the modules are divided according to the module timing requirements corresponding to each module to obtain the second module that requires strict timing control and the first module that does not need (or relatively less needs) strict timing control, code integration can be performed based on the first module that does not need (or relatively less needs) 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 codes. The module timing requirements of the first module contained in the first code file are lower than the module timing requirements of the second module contained 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, ensuring that the logical association between the modules in the code file is correct, while maintaining the consistency of the interface, including signal name, bit width, direction and timing requirements. After the code file to be verified is divided into the first code file and the second code file, the first code file and the second code file can be simulated and verified by the simulation tool to ensure that the function and timing characteristics of each module meet the design requirements. This includes verifying whether the interface connections between modules are correct, whether the data flow is smooth, whether the timing constraints are met, etc.

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

[0019] In an embodiment of the present invention, for the first module that does not require (or relatively requires less) strict timing control, software simulation verification can be used to implement verification of these modules. Software simulation is the simulation and verification of the functions and characteristics of digital circuit design based on hardware description language. The first code file is compiled into an executable file by a compiler, and the executable file is executed based on a simulation tool 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. Use a compiler, such as gcc, to compile the C language code or C++ code into an executable file. Call the simulation tool to execute the executable file on the host computer, configure the simulation parameters and input stimulus, compare the output result with the expected result, analyze the correctness of the design, and obtain the software simulation verification result to perform software simulation verification in the software simulation environment. The software simulation verification environment is a domain specifically used to simulate and verify the first module in the first code file. Exemplarily, the software simulation verification environment may include a compiler, a test platform (Testbench), such as a verification platform, a first code file, and related simulation tools and libraries. In this environment, the function, performance, stability, etc. of the first module of 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.

[0020] Step 103: deploy the target bit file corresponding to the second code file to a designated chip, and perform hardware simulation verification 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.

[0021] In an embodiment of the present invention, for the second module that requires strict timing control, a hardware simulation verification method can be used to implement verification of these modules. The hardware simulation verification method refers to compiling the code through a compiler, synthesizing it into a real hardware circuit, and performing simulation verification through the real hardware circuit. 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 performed in a 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 a 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.). The configuration information generated by the synthesis tool is input into a layout and routing tool. The layout and routing tool is used to determine the specific location of each logic element on the specified chip and generate routing information connecting these elements. The layout and routing information file is converted 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 the configuration information of the chip, such as a complete description of all logic elements and connection relationships inside the chip, which is used to guide the implementation of logic functions inside the FPGA. The target bit file is deployed to the specified chip, and the target bit file can be burned to the specified chip. The specified chip can be an FPGA chip. The FPGA chip stands for Field-Programmable Gate Array, which is a programmable logic device that can realize different circuit connections and functions through programming. The FPGA chip has the advantages of fast running speed and can be connected to real peripherals. By writing a test program, using a debugging tool or building a test platform, hardware simulation verification in a hardware simulation environment is performed based on the specified chip. The hardware simulation environment usually includes a specified chip, a peripheral circuit, a verification platform, a debugging tool, and related hardware and software interfaces. Specifically, after deploying the target bit file to the specified chip, the peripheral circuit and the test equipment can be connected, the debugging tool can be configured and breakpoints or observation points can be set, and the simulation can be run and the hardware behavior can be observed. By stimulating the hardware design on the specified chip and capturing its response. Based on the response, it is compared with the expected result to obtain the hardware simulation verification result.

[0022] Since the code to be verified is divided into a first code file and a second code file, and simulation verification is performed in software verification mode and hardware verification mode respectively, 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 interface call function in the automation script of the verification platform can be used to call the target communication interface to achieve two-way data synchronization between the software simulation environment and the hardware simulation environment. The specific implementation is that the host computer and the board of the specified chip can be connected, for example, the host computer and the board of the specified chip can be connected through a universal serial bus (USB) data cable, and the two-way data synchronization between the software simulation environment and the hardware simulation environment can be performed through the universal serial bus (USB) interface to achieve 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.

[0023] In an 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 contained in the first code file is lower than the module timing requirement of the second module contained 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 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 full play to the advantages of the 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 full play to the advantages of the high verification accuracy of this verification method for timing problems, and at the same time avoiding the limitations of the two verification methods, adopting the software and hardware joint verification method, while improving the verification effect, taking into account the verification advantages of the two verification methods, with the advantages of convenient debugging and high verification accuracy for timing problems. Furthermore, the software simulation environment and the hardware simulation environment can perform two-way data synchronization based on the target communication interface, which can ensure the data consistency of 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.

[0024] Optionally, the embodiment of the present invention may further include the following steps: Step 201: When the first code file and the second code file contain the same target register with the same name, 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.

[0025] 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.

[0026] In an embodiment of the present invention, when the first code file and the second code file contain the same target register with the same name, it is characterized 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 the data consistency of the same target register in the software simulation environment and the hardware simulation environment, a backup register corresponding to the target register can be added to the first code file and the second code file respectively, 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 register. The interface (such as signal name, bit width, direction, etc.), definition, register name and usage of the backup register and the target register are 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 can be 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 consistent. In this way, during the simulation verification process, if a memory access operation is required for the target register, the memory access operation can be directly performed on the local backup register.

[0027] 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, the register address and register name corresponding to the target register are replaced with the register address and register name corresponding to the backup register.

[0028] It can be understood that if the first code file and the second code file contain multiple target registers with the same name, a corresponding backup register can be created for each target register in the first code file and the second code file, and the memory access operation for the target register can be redirected to the corresponding backup register.

[0029] In an embodiment of the present invention, when the first code file and the second code file contain the same target register with the same name, by creating a backup register and redirecting the memory access operation for the target register to the backup register, the independence of software and hardware verification can be improved, while ensuring that the code logic is not affected and maintaining code stability.

[0030] Optionally, the embodiment of the present invention may further include the following steps: Step 301: When a first write operation is performed on the second backup register in the hardware simulation environment, a first write value corresponding to the first write operation is synchronized to the first backup register in the software simulation environment based on the target communication interface.

[0031] In an embodiment of the present invention, in a hardware simulation environment, if a first write operation is performed on a second backup register, then 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 a change in the value in the second backup register is detected, an interface call function can be called, the first write value can be transferred to the software simulation environment based on the target communication interface, and the original value in the second backup server can be replaced based on the first write value to ensure data consistency between the first backup register and the second backup register.

[0032] Step 302: 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.

[0033] In an embodiment of the present invention, in a software simulation environment, if a second write operation is performed on the first backup register, 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 a change in the value in the first backup register is detected, the interface call function can be called, the second write value can be transferred to the hardware simulation environment based on the target communication interface, and the original value in the first backup server can be replaced based on the second write value to ensure data consistency between the first backup register and the second backup register.

[0034] In the embodiment of the present invention, when a write operation is performed on a backup register, the written value can be synchronously updated to the backup register with the same name in the other party's 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.

[0035] Optionally, the embodiment of the present invention may further include the following steps: Step 401: When the second code file does not contain the write logic for the second backup register, if the 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.

[0036] In an embodiment of the present invention, the second code file does not contain the write logic for the second backup register, that is, in the process of hardware simulation verification in the hardware simulation environment, the second backup register will not be written, and only the second backup register will be written. Correspondingly, when software simulation verification is performed in the software simulation environment, the first backup register with the same name as the second backup register may be read and written. 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 after each write operation to the first backup register, but when it is necessary to read the second backup register in the hardware simulation environment, the value in the first backup register in the software simulation environment is directly read.

[0037] If a first read operation is performed on the second backup register in the hardware emulation environment, the current value of the first backup register in the software emulation 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 emulation 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 emulation environment based on the target communication interface, and obtain the current value in the first backup register, return the current value to the hardware emulation environment and output it as the read result corresponding to the first read operation.

[0038] Step 402: When 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, based on the target communication interface, the current value of the second backup register in the hardware simulation environment is obtained as the read result corresponding to the second read operation.

[0039] In an embodiment of the present invention, the first code file does not contain the write logic for the first backup register, that is, in the process of performing 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, when performing hardware simulation verification in the hardware simulation environment, the second backup register with the same name as the first backup register may be read and written. 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 after each write operation to the second backup register, but when it is necessary to read the first backup register in the software simulation environment, the value in the second backup register in the hardware simulation environment is directly read.

[0040] 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 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, and 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.

[0041] In an embodiment of the present invention, if a read operation is performed on a local backup register in its own simulation environment, and no write 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 party's simulation environment can be obtained through the target communication interface as the read result of the read operation. This ensures data consistency and accuracy while alleviating bandwidth occupancy to a certain extent without the need to synchronize the register value in real time.

[0042] Optionally, step 101 may include the following steps: Step 501: Determine the first code file according to a first code marker pre-inserted into the code file to be verified; the first code marker is used to indicate a first module whose module timing requirement is lower than a preset requirement.

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

[0044] The code file to be verified is traversed to determine the first module indicated by the first code mark, and based on the first module, a first code file is integrated to obtain the first code file.

[0045] Step 502: Determine the second code file according to a second code marker pre-inserted into the code file to be verified; the second code marker is used to indicate a second module having a module timing requirement higher than the preset requirement.

[0046] In an embodiment of the present invention, according to the module functions of each module in the code file to be verified and the module timing requirements, a second code mark is pre-inserted into the code file to be verified, and the second code mark is used to indicate a second module whose module timing requirements are higher than the preset requirements. Among them, the second module whose module timing requirements are higher than the preset requirements can be a module with a higher degree of strictness in module timing requirements. The second module may include a peripheral module, an ADC (analog-to-digital converter) and a DAC (digital-to-analog converter), etc. The second code mark can be a pre-defined code field, which is not limited in the embodiment of the present invention.

[0047] The code file to be verified is traversed to determine the second module indicated by the second code mark, and based on the second module, a second code file is integrated to obtain.

[0048] It is understandable that, in the process of dividing the code file to be verified into the first code file and the second code file, for the unmarked modules in the code file to be verified, the default type of the unmarked modules can be preset, for example, the unmarked modules can be determined as the first module by default.

[0049] In an embodiment of the present invention, by inserting a first code tag and a second code tag 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. The code file can be accurately split according to the module timing requirements, providing accurately classified code files for separate software and hardware simulation verification.

[0050] Optionally, step 101 may further include the following steps: Step 601: Obtain 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.

[0051] In an embodiment of the present invention, the compiler obtains a preset target configuration file. The target configuration file may be obtained by the compiler receiving 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, which is a module name corresponding to a predefined module with low module timing requirements, such as a module name corresponding to a peripheral module, an ADC (analog-to-digital converter), and a DAC (digital-to-analog converter). The second configuration sub-file may include a second module name defined, which is a module name corresponding to a predefined module with high module timing requirements, such as a module name corresponding to a core module, a storage module, and an algorithm acceleration module. The code file to be verified may include one code file. In the case of a complex target chip structure, the code file to be verified may also include multiple module code files, 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.

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

[0053] In an embodiment of the present invention, the compiler parses the target configuration file to obtain a first configuration sub-file, a second configuration sub-file, and a 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 a first code file. Accordingly, in the case where the code file to be verified contains 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 a first code file.

[0054] Step 603: Based on the second module name in the second configuration subfile, determine in the code file to be verified a second module having a module timing requirement higher than the preset requirement, and generate the second code file based on the second module.

[0055] In an embodiment of the present invention, based on the second module name in the second configuration subfile, 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. Accordingly, in the case where the code file to be verified includes 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.

[0056] 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 pre-set. For example, the module that is not determined as the first module or the second module can be determined as the first module by default.

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

[0058] In the embodiment of the present invention, through the verification platform, the code file to be verified can be divided into a first code file and a second code file, and the compiler is called to compile the first code file into an executable file, the simulation tool is called to perform software simulation verification, and the compiler is called to compile the second code file into a target bit file, and the 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 bidirectional data synchronization between the software verification environment and the hardware verification environment, thereby realizing the backup of the target register and the synchronization logic of cross-domain register access, and maintaining data consistency.

[0059] Reference Figure 2 , shows a block diagram of a verification device provided by an embodiment of the present invention, such as Figure 2 As shown, the device may specifically include: A first division module 701 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 702, used 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; The second verification module 703 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 bidirectional data synchronization based on a target communication interface.

[0060] Optionally, the device further comprises: 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.

[0061] Optionally, the device further comprises: A first synchronization module, configured to synchronize, based on the target communication interface, a first write value corresponding to the first write operation to the first backup register in the software simulation environment when a first write operation is performed on the second backup register in the hardware simulation environment; A second synchronization module is used to 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 when a second write operation is performed on the first backup register in the software simulation environment.

[0062] Optionally, the device further comprises: a first acquisition module, configured to acquire, based on the target communication interface, a current value of the first backup register in the software simulation environment as a read result corresponding to the first read operation, if a first read operation is performed on the second backup register in the hardware simulation environment when the second code file does not contain a write logic for the second backup register; A second acquisition module is used to obtain, based on the target communication interface, a current value of the second backup register in the hardware simulation environment as a read result corresponding to the second read operation, if the second read operation is performed on the first backup register in the software simulation environment, when the first code file does not contain the write logic for the first backup register.

[0063] Optionally, the first division module 701 includes: A first determination module is used to 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; A second determination module is used to determine the second code file 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.

[0064] Optionally, the first division module 701 includes: A first acquisition module is used 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; A first generating module, configured to determine, in the code file to be verified, a first module whose module timing requirement is lower than a preset requirement based on a first module name in the first configuration subfile, and generate the first code file based on the first module; The second generating module is used to determine, in the code file to be verified, a second module having a module timing requirement higher than the preset requirement based on the second module name in the second configuration subfile, and generate the second code file based on the second module.

[0065] Reference Figure 3 , is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. Figure 3 As shown, the electronic device includes: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store executable instructions, and the executable instructions enable the processor to execute the verification method of the above embodiment. The executable instructions can constitute a program.

[0066] An embodiment of the present invention provides a readable storage medium having executable instructions stored thereon, which, when executed by one or more processors, enables the processors to execute the verification method of the aforementioned embodiment. The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0067] It should be understood by those skilled in the art that the embodiments of the present invention can be provided as methods, devices, or computer program products. 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. 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 codes. It should be noted that all actions of acquiring signals, information or data in this application are carried out under the premise of complying with the corresponding data protection laws and policies of the country of residence and with the authorization given by the owner of the corresponding device. The embodiments of the present invention are described with reference to the flowcharts and / or block diagrams of the 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 box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the process Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0068] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing terminal device to operate in a predictable manner, so that the instructions stored in the computer readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0069] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0070] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0071] Finally, it should be noted that, in this article, relational terms such as first and second, etc. 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 terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.

[0072] The above is a detailed introduction to an instruction stream file generation method, an instruction stream file generation device, an electronic device and a readable storage medium provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea; at the same time, for a person skilled in the art, according to the idea of ​​the present invention, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on 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 performing software simulation verification in a software simulation environment based on the executable file; 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, and performing software simulation verification in a software simulation environment based on the executable file; 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