Chip verification method and device, equipment, storage medium and program product

Abstract

The invention discloses a chip verification method and device, equipment, a storage medium and a program product. The method comprises the steps that a first executable file of a C model is obtained, the first executable file comprises an original code and a target code which are designed based on a verified function in a chip, and the verified function comprises a plurality of algorithm steps; running the first executable file based on the input signal to obtain running data of each algorithm step; extracting simulation data of each algorithm step from the simulation waveform file with the verified function; and respectively comparing the operation data and the simulation data of each algorithm step to determine an abnormal algorithm step in which the operation data and the simulation data are inconsistent. Therefore, by automatically comparing the operation data and the simulation data of each algorithm step, the abnormal algorithm step with the problem can be quickly determined, and the manual inspection and analysis time is shortened.

Description

Technical Field

[0001] The present application belongs to the field of chip research and development technology, and in particular relates to a chip verification method, device, equipment, storage medium and program product. Background Art

[0002] Chip verification is a crucial step in the chip development process, ensuring the correctness and reliability of chip designs. Traditional chip verification methods are primarily based on the UVM (Universal Verification Methodology) platform. However, UVM verification suffers from slow simulation speeds and long debugging cycles. This is especially true in scenarios involving extensive computations, as each time a specific scenario is debugged, the simulation must be rerun, consuming a significant amount of time.

[0003] To improve verification efficiency, related technologies often combine a C model with a UVM verification platform. The C model is connected to the UVM platform as a reference model, and the correctness of the simulation results is determined by comparing the reference output of the C model with the chip's simulation results. While this approach improves verification efficiency, incorrect simulation results require manual inspection and analysis of the source of the problem, making it difficult to quickly locate the problem. Summary of the Invention

[0004] The embodiments of the present application provide a chip verification method, apparatus, device, storage medium, and program product, which can quickly locate problems in a chip during the chip verification process.

[0005] In a first aspect, an embodiment of the present application provides a chip verification method, comprising:

[0006] Obtaining a first executable file of the C model, the first executable file including original code and target code designed based on a verified function in the chip, the verified function including multiple algorithm steps, the original code being used to implement the multiple algorithm steps, and the target code being used to instruct the C model to output operating data of each algorithm step;

[0007] Running the first executable file based on the input signal to obtain running data of each algorithm step;

[0008] Extracting simulation data for each algorithm step from a simulation waveform file of the function to be verified, where the simulation waveform file is obtained by simulating the function to be verified based on an input signal;

[0009] The running data and simulation data of each algorithm step are compared respectively to identify abnormal algorithm steps where the running data and simulation data are inconsistent.

[0010] In a second aspect, an embodiment of the present application provides a chip verification device, comprising:

[0011] an acquisition module, configured to acquire a first executable file of the C model, the first executable file including original code and target code designed based on a verified function in the chip, the verified function including a plurality of algorithm steps, the original code being used to implement the plurality of algorithm steps, and the target code being used to instruct the C model to output operating data of each algorithm step;

[0012] An operation module, configured to execute the first executable file based on an input signal to obtain operation data of each algorithm step;

[0013] An extraction module is used to extract simulation data of each algorithm step from a simulation waveform file of the function to be verified, where the simulation waveform file is obtained by simulating the function to be verified based on an input signal;

[0014] The comparison module is used to compare the running data and simulation data of each algorithm step respectively to determine the abnormal algorithm steps where the running data and simulation data are inconsistent.

[0015] In a third aspect, an embodiment of the present application provides an electronic device comprising a processor and a memory, wherein the memory stores programs or instructions that can be run on the processor, and when the programs or instructions are executed by the processor, the steps of the method described in the first aspect are implemented.

[0016] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the method described in the first aspect are implemented.

[0017] In a fifth aspect, an embodiment of the present application provides a computer program product, which is stored in a storage medium and is executed by at least one processor to implement the method described in the first aspect.

[0018] The chip verification method, apparatus, device, storage medium, and program product of the embodiments of the present application obtain a first executable file of a C model; run the first executable file based on an input signal to obtain the operating data of each algorithm step in the verified function in the chip; extract the simulation data of each algorithm step from the simulation waveform file of the verified function; and compare the operating data and simulation data of each algorithm step respectively to identify abnormal algorithm steps whose operating data and simulation data are inconsistent. In this way, by automatically comparing the operating data and simulation data of each algorithm step, it is possible to quickly identify abnormal algorithm steps with problems, reducing the time for manual inspection and analysis. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0020] Figure 1 This is a flowchart of a chip verification method provided by an embodiment of the present application;

[0021] Figure 2 is a schematic structural diagram of a chip verification device provided by another embodiment of the present application;

[0022] Figure 3 This is a structural diagram of an electronic device provided in yet another embodiment of the present application. DETAILED DESCRIPTION

[0023] The features and exemplary embodiments of various aspects of the present application will be described in detail below. In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, rather than to limit the present application. For those skilled in the art, the present application can be implemented without the need for some of these specific details. The following description of the embodiments is merely to provide a better understanding of the present application by illustrating the examples of the present application.

[0024] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, the elements defined by the phrase "comprising..." do not exclude the presence of other identical elements in the process, method, article, or device comprising the elements.

[0025] Before the embodiment of the present invention is described in further detail, the chip verification method in the related art is introduced, as mentioned above, in order to promote chip verification efficiency, the verification method that adopts UVM to be combined with C model is carried out chip verification in the related art. At present, the verification method that UVM is combined with C model, mainly is by direct programming interface (Distributed Program Interface, be called for short DPI) C model is embedded in UVM as the reference model of UVM, by UVM the stimulus signal that test case is generated is also input signal respectively input in chip and C model, then the actual result of verifying chip output based on the final result of the output of C model is correct, when the final result of the output of C model is inconsistent with the actual result of chip output, determine that chip has problems. Although this mode has improved verification efficiency compared to traditional verification method based on UVM, but because it is just compared with the final result of C model and chip output, lack the comprehensive comparison mechanism with UVM simulation result, make when chip has problems, need to carry out problem location by artificial debugging, and each debugging all needs UVM to run test case, make in the process of problem location, need UVM to run test case repeatedly, cause consuming time long, can't locate the source of problem quickly. In addition, this approach relies on the C model of random testing and dynamic DPI interface interaction, and has problems such as high resource consumption and poor cross-platform reusability.

[0026] In view of the above problems, the embodiments of the present application provide a chip verification method, apparatus, device, storage medium and program product. The chip verification method provided by the embodiments of the present application is first introduced below.

[0027] The chip verification method provided in the embodiment of the present application can be applied to chip development scenarios to perform functional verification on the chip. It should be noted that the chip verification method provided in the embodiment of the present application can be executed by a chip verification device based on the C model and UVM. In the embodiment of the present application, the chip verification method provided in the embodiment of the present application is illustrated by taking the chip verification device executing the chip verification method as an example.

[0028] See also Figure 1 , is a flow chart of a chip verification method provided in some embodiments of the present application. Figure 1 As shown, the method includes the following steps S110-S140, which are described in detail below.

[0029] S110. Obtain a first executable file of the C model, the first executable file including original code and target code designed based on a verified function in the chip, the verified function including multiple algorithm steps, the original code is used to implement the multiple algorithm steps, and the target code is used to instruct the C model to output the running data of each algorithm step.

[0030] In some embodiments of the present application, a chip refers to a chip that requires verification. The chip may include one or more functions. The verified function refers to the function to be verified in the chip. For example, if the chip has an AES (Advanced Encryption Standard) encryption function, when verifying the AES encryption function in the chip, the AES encryption function is the verified function.

[0031] In some embodiments of the present application, a C model is a model corresponding to the function being verified. A C model is a behavioral model developed in the C language and used to implement the function being verified. For example, if the function being verified is an AES encryption function, the C model is a C language model that can implement the corresponding AES encryption algorithm.

[0032] In order to solve the problem in related technologies that problems in chips cannot be quickly located, this embodiment provides a comprehensive comparison mechanism, which decomposes the verified function into multiple algorithm steps executed in a specific order. Different algorithm steps have different functions, data processing methods, etc. During verification, the algorithm step with problems is determined by comparing the relevant result data of each algorithm step in the verified function, so as to achieve rapid location of the problem.

[0033] In view of this, to analyze each algorithmic step separately, in this embodiment, the C model includes source code and target code. The source code implements the multiple algorithmic steps of the function being verified. The target code instructs the C model to output the operational data for each algorithmic step in the function being verified. Thus, by running the C model, relevant operational data for each algorithmic step can be obtained. Based on this operational data, it is then possible to determine whether each algorithmic step has problems, thereby quickly locating the problematic algorithmic step.

[0034] In some embodiments of the present application, the original code can be designed based on the description of each step of the verified function in the functional specification of the chip. For example, the verified function is an AES encryption function, which includes byte replacement, row shift, column mixing, round key and multiple algorithm steps. Based on this, when developing the original code of the C model, byte replacement, row shift, column mixing, round key and their corresponding code segments can be designed based on the description of the verified function in the functional specification of the chip, and then multiple code segments corresponding to the multiple algorithm steps are composed according to the execution order of the multiple algorithm steps, thereby forming an original code that can implement multiple algorithm steps in sequence according to the execution order of the multiple algorithm steps. In this way, for each algorithm step, the function of the algorithm step can be realized by running the code segment corresponding to the algorithm step in the original code.

[0035] In some embodiments of the present application, for each algorithm step, the running data of the algorithm step includes the data obtained after the code segment corresponding to the algorithm step is executed, that is, the intermediate result of the algorithm step. The intermediate result refers to the temporary data or intermediate state generated between each algorithm step during the execution of the algorithm. These intermediate results are usually not directly used as the final output of the algorithm, but are used for calculation or processing in subsequent algorithm steps to help the algorithm gradually achieve its final goal. For example, taking the AES encryption algorithm as an example, the intermediate result of the byte replacement algorithm step is the data after byte replacement. In the byte replacement algorithm step of AES encryption, each byte of the input data is replaced by searching the S box, and the replaced data is the intermediate result of the byte replacement algorithm step. This result will serve as the input of the row shift algorithm step. The intermediate result of the row shift algorithm step is the data after row shift. The data after byte replacement undergoes a row shift operation, and each row is circularly shifted according to different offsets. The new data state obtained is also the intermediate result of the row shift algorithm step and will be used in the subsequent column mixing algorithm step. The intermediate result of the column mixing algorithm step is the column-mixed data. The row-shifted data is multiplied by a fixed matrix to complete the column mixing operation. The resulting result is the intermediate result of the column mixing algorithm step and the input of the round key addition algorithm step. The intermediate result of the round key addition algorithm step is the result after the round key addition. In each round, the column-mixed data is XORed with the round key for that round. The result obtained is the intermediate result of the round key addition algorithm step for that round. If there is a next round, this intermediate result will serve as the input for the next round. After multiple rounds of such intermediate result transmission and processing, the final output of the AES encryption algorithm is obtained, which is the final result.

[0036] In some embodiments of the present application, a C-model executable file refers to a file that can run independently in an operating system environment and implement the C-model functionality. The presentation of executable programs varies in different operating system environments. For example, in a Windows operating system, an executable program can be a .exe file, a .sys file, a .com file, or other file types.

[0037] In some embodiments of the present application, the C model includes a first executable file, and the first executable file includes the above-mentioned original code and target code. In the above-mentioned step S110, the first executable file is obtained.

[0038] S120. Run the first executable file based on the input signal to obtain operation data of each algorithm step.

[0039] Here, the input signal is a signal input into the C model and chip to check whether the verified function meets expectations.

[0040] In some embodiments of the present application, the input signal can be generated by running a test case corresponding to the function to be verified through UVM, wherein the test case is set according to information such as the scenario to be verified.

[0041] In some embodiments of the present application, independent operation of the C model is achieved by running a first executable file. Independent operation of the C model means that the C model runs as an independent process, isolated from the UVM environment, without the need for real-time interaction with UVM, which can reduce synchronization overhead. Running the first executable file based on an input signal means that when the C model runs independently based on the first executable file, the input signal is input as input data into the C model, so that the C model processes the input signal, thereby obtaining a log file of the C model. As described above, the first executable file includes source code and target code. Based on this, when processing the input signal, the C model processes the input signal according to the processing order and processing method of multiple algorithm steps based on the source code. During the processing, the target code outputs the operation data of each algorithm step. In this way, a log file containing the operation data of each algorithm step can be obtained. Since the log file contains not only the operation data of each algorithm step but also some other data, in order to obtain the operation data of each algorithm step, after obtaining the log file of the C model, the log file is parsed to extract the operation data of each algorithm step from the log file.

[0042] In some embodiments of the present application, log files are parsed using a Python tool to extract the running data of each algorithm step.

[0043] In some embodiments of the present application, the intermediate results of the algorithm steps include data names and data values. For each algorithm step, structured data containing data names and data values ​​is generated based on the intermediate results of the algorithm step, and the structured data is used as the running data of the algorithm step.

[0044] In some embodiments of the present application, the operation data of multiple algorithm steps are stored in a first file for subsequent use. The first file may be a file in CSV (Comma-Separated Values) format.

[0045] S130. Extract simulation data of each algorithm step from the simulation waveform file of the verified function, where the simulation waveform file is obtained by simulating the verified function based on the input signal.

[0046] In some embodiments of the present application, prior to step S130, the verified function in the chip is simulated based on an input signal consistent with the input signal in step S120 to obtain a simulation waveform file of the verified function. A simulation waveform file is a data file that records the signal changes in the chip during the simulation process. The simulation waveform file stores the state changes of the chip signals in a time series format.

[0047] In some embodiments of the present application, before the above-mentioned step S130, the verified function in the chip can be simulated based on the input signal through the universal verification method platform UVM, and during the simulation process, the signal changes of the chip are recorded, thereby generating a simulation waveform file of the verified function based on the signal changes. When the verified function in the chip is simulated based on the input signal through UVM, the test case corresponding to the verified function can be run through UVM to obtain the input signal; the input signal is input into the chip so that the chip runs the verified function based on the input signal, thereby realizing the simulation of the verified function. Among them, the test case is set according to the actual verification requirements.

[0048] In some embodiments of the present application, in the above-mentioned step S130, simulation data of each algorithm step is extracted from the simulation waveform file of the verified function, so as to compare the simulation data of each algorithm step with the corresponding operation data, thereby determining the algorithm step with problems.

[0049] In some embodiments of the present application, when extracting the simulation data of each algorithm step from the simulation waveform file of the verified function, the key signal of each algorithm step can be determined respectively; the key signal and the signal value of the key signal corresponding to each algorithm step can be extracted respectively from the simulation waveform file; based on the key signal and the signal value of the key signal of each algorithm step, the simulation data of each algorithm step is generated, wherein the simulation data also includes the data name and data value of the algorithm step. Among them, the key signal of the algorithm step refers to the signal corresponding to the data name in the running data of the algorithm step, one key signal corresponds to one data name, and accordingly, the signal value of the key signal corresponds to the data value of the data name. For example, the verified function is an AES encryption function, wherein the algorithm step includes byte replacement, and the running data of the byte replacement includes the data after the byte replacement, then the key signal of the byte replacement includes the signal corresponding to the data after the byte replacement.

[0050] In some embodiments of the present application, the fsdbreport tool provided by Verdi is used to extract key signals and signal values ​​from the simulation waveform file.

[0051] In some embodiments of the present application, for each algorithm step, the extracted key signal of the algorithm step is converted into a corresponding data name, the signal value of the key signal is converted into a corresponding data value, and then structured data containing the data name and data value is generated, and the structured data is used as simulation data for the algorithm step.

[0052] In some embodiments of the present application, simulation data of multiple algorithm steps are stored in a second file for subsequent use, wherein the second file may be a file in CSV (Comma-Separated Values) format.

[0053] S140. Compare the running data and simulation data of each algorithm step respectively to determine the abnormal algorithm steps where the running data and simulation data are inconsistent.

[0054] In some embodiments of the present application, for each algorithm step in the verified function, if there is no problem with the algorithm step, the operating data of the algorithm step is consistent with the simulation data. If the simulation data corresponding to the operating data domain is inconsistent, it indicates that there is a problem with the algorithm step. Based on this, the operating data and simulation data of each algorithm step can be compared separately by an automated comparison engine, so as to determine the abnormal algorithm steps in which the operating data and simulation data are inconsistent among multiple algorithm steps based on the comparison results. In this way, by automatically comparing the operating data and simulation data of the algorithm steps, the algorithm steps with problems can be quickly located, thereby achieving rapid location of the problem.

[0055] In some embodiments of the present application, the operation data of multiple algorithm steps are stored in a first file, and the simulation data of multiple algorithm steps are stored in a second file. Based on this, the automated comparison engine can automatically compare the first file and the second file to identify abnormal algorithm steps.

[0056] In some embodiments of the present application, the automated comparison engine includes a data alignment module and a numerical comparator. When the automated comparison engine performs an automated comparison on a first file and a second file, the data alignment module aligns the data of the first file and the second file using methods such as label mapping to associate data values ​​corresponding to the same algorithm steps and data names in the first file and the second file. The numerical comparator then compares the associated data to determine abnormal algorithm steps where the run data and the simulation data differ.

[0057] In some embodiments of the present application, the verified function may need to be implemented through multiple rounds of calculation. For example, taking the AES encryption function as an example, multiple rounds of calculation are required to obtain the final ciphertext, and each round of calculation requires the execution of byte replacement, row shift, column mixing and round key plus multiple algorithm steps. In this case, for each algorithm step, multiple groups of operating data and multiple groups of simulation data of the algorithm step in multiple rounds of calculation can be obtained through the above steps S120 and S130. In view of this, in this case, in order to ensure the accuracy of the comparison result, the data of the first file and the second file are aligned by the data alignment module, and the first file and the second file are aligned in time sequence to establish an association between the data values ​​corresponding to the same algorithm step, the same calculation round and the same data name in the first file and the second file. In this way, the operating data and simulation data under the same algorithm step, the same calculation round and the same data name can be compared in the numerical comparator, thereby improving the accuracy of the comparison result.

[0058] In some embodiments of the present application, after an abnormal algorithm step is identified, a difference report can be generated based on the abnormal algorithm step and output. The generated difference report is used to indicate the abnormal algorithm step with a problem in the verified function. In this way, the verification personnel can intuitively understand the problem with the verified function based on the difference report.

[0059] The chip verification method provided in the embodiment of the present application obtains a first executable file of a C model; runs the first executable file based on an input signal to obtain the running data of each algorithm step in the verified function in the chip; extracts the simulation data of each algorithm step from the simulation waveform file of the verified function; and compares the running data and simulation data of each algorithm step respectively to identify abnormal algorithm steps whose running data and simulation data are inconsistent. In this way, by automatically comparing the running data and simulation data of each algorithm step, it is possible to quickly identify abnormal algorithm steps with problems, reducing the time of manual inspection and analysis.

[0060] In some embodiments, before step S110, it is possible to first verify whether there is a problem with the function being verified. If it is determined that there is a problem with the function being verified, step S110 is then performed. This can reduce the waste of resources caused by performing the above steps when there is no problem with the function being verified.

[0061] In some embodiments, before the above step S110 , the following steps S210 - S230 may be performed to verify whether there is a problem with the function being verified.

[0062] S210. Simulate the verified function in the chip based on the input signal through UVM to obtain the actual result of the chip output.

[0063] The input signal here is consistent with the input signal in the above steps S120 and S130.

[0064] In some embodiments of the present application, before step S210 , a test case corresponding to the function to be verified may be run through UVM to generate an input signal.

[0065] In some embodiments of the present application, the actual result output by the chip is the final result obtained by the chip executing the verified function based on the input signal. For example, if the verified function is an AES encryption function, the actual result output by the chip is the ciphertext obtained by the chip encrypting the input signal using the verified function.

[0066] In some embodiments of the present application, in the process of simulating the verified function in the chip based on the input signal through UVM, a simulation waveform file of the verified function can be generated. In this way, in step S130, the simulation data of each algorithm step can be directly extracted from the simulation waveform file of the verified function generated here, without the need for UVM to run the simulation again, thereby reducing the number of simulations of UVM and improving verification efficiency.

[0067] S220. Run the second executable file of the C model based on the input signal to obtain the running result of the C model, where the second executable file includes the original code.

[0068] The input signal here is consistent with the input signal in the above steps S120 and S130.

[0069] In some embodiments of the present application, a test case corresponding to the function to be verified may be run through UVM to generate an input signal, and the input signal may be saved in a file. In step S220, the input signal may be obtained from the file.

[0070] In some embodiments of the present application, the second executable file contains original code, so that by running the second executable file, the C model can implement multiple algorithm steps of the verified function, and then process the input signal based on the multiple algorithm steps to obtain the final result after processing, and use the final result after processing as the running result of the C model.

[0071] S230. Compare the running result with the actual result to obtain the verification result of the verified function.

[0072] In some embodiments of the present application, the verification result of the verified function is used to indicate whether the running result and the actual result are consistent. If the running result and the actual result are inconsistent, it means that there is a problem with the verified function, and the above step S110 is executed. If the running result and the actual result are consistent, it means that there is no problem with the verified function, the verification is passed, and there is no need to execute the above step S110.

[0073] In some embodiments of the present application, before step S110, when it is verified through the above steps S210-S230 whether there is a problem with the verified function, in the above step S120, the input signal can be obtained through playback technology.

[0074] Replay technology, also known as replay technology, refers to recording key data during the verification process and re-injecting or replaying this data when needed to reproduce specific scenarios or errors. Based on this, during the above steps S210-S230, the input signal can be recorded. In this way, when executing the above step S120, the recorded input signal can be directly re-injected into the C model, without having to re-run the test case through UVM to generate the input signal. This can speed up the verification process and reduce the need for UVM to re-run the simulation.

[0075] Through experiments, it was determined that the processing time spent on independently running the C model based on playback technology is 0.329 seconds, while the processing time spent on the traditional method of running the test case through UVM to generate the input signal and then inputting the input signal into the C model for processing is 62.572 seconds. It can be seen that the processing method based on playback technology takes less time and is more efficient. In some embodiments, after determining the abnormal algorithm step, a chip modification and debugging phase can be carried out. In the modification and debugging phase, the abnormal algorithm step of the verified function in the chip is modified and debugged to eliminate the problem of the verified function. After each modification and debugging, the verified function after modification and debugging is verified again to determine whether the abnormality of the verified function has been eliminated. Given that the modification and debugging are performed on the abnormal algorithm step, and the other algorithm steps remain unchanged, when the verified function after modification and debugging is verified again, only the abnormal algorithm step can be verified based on playback technology. In this way, the time for full verification can be reduced.

[0076] Based on the chip verification method provided in the above embodiment, the present application also provides a specific implementation of a chip verification device. Please refer to the following embodiments.

[0077] See also Figure 2 Schematic diagram of a chip verification device provided in some embodiments of the present application, such as Figure 2 As shown, the device 200 includes the following modules:

[0078] An acquisition module 201 is configured to acquire a first executable file of a C model, the first executable file including source code and target code designed based on a verified function in a chip, the verified function including a plurality of algorithm steps, the source code being used to implement the plurality of algorithm steps, and the target code being used to instruct the C model to output operating data for each algorithm step;

[0079] An operation module 202 is configured to execute the first executable file based on the input signal to obtain operation data of each algorithm step;

[0080] An extraction module 203 is configured to extract simulation data of each algorithm step from a simulation waveform file of the function to be verified, where the simulation waveform file is obtained by simulating the function to be verified based on an input signal;

[0081] The comparison module 204 is used to compare the operation data and simulation data of each algorithm step respectively to determine abnormal algorithm steps where the operation data and simulation data are inconsistent.

[0082] In some embodiments, the apparatus 200 further includes an initial verification module configured to:

[0083] Before obtaining the first executable file of the C model, the verified function in the chip is simulated based on the input signal through UVM to obtain the actual result output by the chip;

[0084] Running a second executable file of the C model based on the input signal to obtain an operation result of the C model, wherein the second executable file includes the original code;

[0085] Compare the running results with the actual results to obtain the verification results of the verified functions;

[0086] Accordingly, the acquisition module 201 is used to:

[0087] When the verification result indicates that the running result is inconsistent with the actual result, a first executable file of the C model is obtained.

[0088] In some embodiments, the execution module 202 is configured to:

[0089] Running the first executable file based on the input signal to obtain a log file of the C model;

[0090] The running data of each algorithm step is extracted from the log file. The running data includes the data name and data value of the algorithm step.

[0091] In some embodiments, the apparatus 200 further includes a simulation module for:

[0092] Before extracting simulation data for each algorithm step from the simulation waveform file of the verified function, the verified function in the chip is simulated based on the input signal using a universal verification method platform;

[0093] During the simulation process, obtain the signal changes of the chip;

[0094] Generates simulation waveform files of the verified functions based on signal changes.

[0095] In some embodiments, the extraction module 203 is configured to:

[0096] Identify the key signals for each algorithm step separately;

[0097] Extract the key signals and signal values ​​of each algorithm step from the simulation waveform file;

[0098] Based on the key signal of each algorithm step and the signal value of the key signal, simulation data of each algorithm step is generated, and the simulation data includes a data name and a data value of the algorithm step.

[0099] In some embodiments, the apparatus 200 further includes a reporting module configured to:

[0100] Comparing the running data and simulation data of each algorithm step respectively to identify abnormal algorithm steps where the running data and simulation data are inconsistent, and generating a difference report based on the abnormal algorithm steps;

[0101] Output a difference report.

[0102] The chip verification device provided in the embodiment of the present application can implement each process implemented in the above method embodiment. To avoid repetition, it will not be described here.

[0103] Figure 3 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application is shown.

[0104] The electronic device 300 may include a processor 301 and a memory 302 storing computer program instructions.

[0105] Specifically, the processor 301 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0106] The memory 302 may include a large-capacity memory for data or instructions. By way of example and not limitation, the memory 302 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 302 may include removable or non-removable (or fixed) media. Where appropriate, the memory 302 may be inside or outside the integrated gateway disaster recovery device. In a specific embodiment, the memory 302 is a non-volatile solid-state memory. The memory 302 may include a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage medium device, an optical storage medium device, a flash memory device, an electrical, optical, or other physical / tangible memory storage device. Therefore, typically, the memory 302 includes one or more tangible (non-transitory) computer-readable storage media (e.g., a memory device) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it may perform the operations described in any one of the chip verification methods in the above-mentioned embodiments.

[0107] The processor 301 implements any one of the chip verification methods in the above embodiments by reading and executing computer program instructions stored in the memory 302 .

[0108] In one example, the electronic device 300 may further include a communication interface 303 and a bus 310. Figure 3 As shown, the processor 301 , the memory 302 , and the communication interface 303 are connected via a bus 310 and communicate with each other.

[0109] The communication interface 303 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present application.

[0110] Bus 310 includes hardware, software or both, and the components of online data flow metering equipment are coupled to each other. For example, but not limitation, bus can include accelerated graphics port (AGP) or other graphics bus, enhanced industry standard architecture (EISA) bus, front side bus (FSB), hypertransport (HT) interconnection, industry standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations. In appropriate cases, bus 310 can include one or more buses. Although the present application embodiment describes and shows specific bus, the application considers any suitable bus or interconnection.

[0111] Processor 301 may include one or more processing units. Optionally, processor 301 integrates an application processor and a modem processor. The application processor primarily handles operations related to the operating system, user interface, and application programs, while the modem processor primarily processes wireless communication signals, such as a baseband processor. It is understood that the modem processor may not be integrated into processor 301.

[0112] The memory 302 can be used to store software programs and various data. The memory 302 may mainly include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store an operating system, applications or instructions required for at least one function (such as a sound playback function, an image playback function, etc.). In addition, the memory 302 may include volatile memory or non-volatile memory, or the memory 302 may include both volatile and non-volatile memory. The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct RAM bus random access memory (DRRAM). The memory 302 in the embodiment of the present application includes but is not limited to these and any other suitable types of memory.

[0113] In addition, in conjunction with the chip verification method in the above embodiments, the present application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when the computer program instructions are executed by a processor, any one of the chip verification methods in the above embodiments is implemented.

[0114] The processor is the processor in the electronic device described in the above embodiment. The readable storage medium includes a computer-readable storage medium, such as a computer read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk.

[0115] An embodiment of the present application also provides a computer program product, including a computer program, which implements any one of the chip verification methods in the above embodiments when the computer program is processed and executed.

[0116] It should be understood that the present application is not limited to the specific configurations and processes described above and illustrated in the figures. For the sake of brevity, a detailed description of known methods is omitted here. In the above embodiments, several specific steps are described and illustrated as examples. However, the method process of the present application is not limited to the specific steps described and illustrated. Those skilled in the art can make various changes, modifications, and additions, or change the order of the steps after understanding the spirit of the present application.

[0117] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of the present application are programs or code segments that are used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link by a data signal carried in a carrier wave. "Machine-readable medium" can include any medium that can store or transmit information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROMs, flash memories, erasable ROMs (EROMs), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. The code segment can be downloaded via a computer network such as the Internet, an intranet, etc.

[0118] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps. In other words, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0119] Aspects of the present disclosure have been described above with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of each box 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 or other programmable data processing device to produce a machine so that these instructions executed by the processor of the computer or other programmable data processing device enable the implementation of the function / action specified in one or more boxes of the flowchart and / or block diagram. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor or a field programmable logic circuit. It is also understood that each box in the block diagram and / or flowchart and the combination of the boxes in the block diagram and / or flowchart can also be implemented by dedicated hardware that performs the specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0120] The above description is only a specific embodiment of the present application. Those skilled in the art will clearly understand that for the convenience and brevity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the scope of protection of the present application is not limited thereto. Any person skilled in the art can easily think of various equivalent modifications or replacements within the technical scope disclosed in the present application, and these modifications or replacements should be included in the scope of protection of the present application.

Claims

1. A chip verification method, characterized in that: include: Obtaining a first executable file of a C model, the first executable file including original code and target code designed based on a verified function in a chip, the verified function including a plurality of algorithm steps, the original code being used to implement the plurality of algorithm steps, and the target code being used to instruct the C model to output operating data of each of the algorithm steps; Running the first executable file based on an input signal to obtain operation data of each algorithm step; Extracting simulation data for each algorithm step from a simulation waveform file of the verified function, wherein the simulation waveform file is obtained by simulating the verified function based on the input signal; The operating data and simulation data of each algorithm step are compared respectively to determine abnormal algorithm steps where the operating data and simulation data are inconsistent.

2. The method according to claim 1, characterized in that Before obtaining the first executable file of the C model, the method further includes: Simulating the verified function in the chip based on the input signal using a universal verification method platform to obtain an actual result output by the chip; running a second executable file of the C model based on the input signal to obtain an operation result of the C model, wherein the second executable file includes the original code; Comparing the running result with the actual result to obtain a verification result of the verified function; The obtaining of the first executable file of the C model includes: When the verification result indicates that the running result is inconsistent with the actual result, the first executable file of the C model is obtained.

3. The method according to claim 1, characterized in that The step of running the first executable file based on the input signal to obtain the operation data of each algorithm step includes: Running the first executable file based on the input signal to obtain a log file of the C model; The operation data of each algorithm step is extracted from the log file, where the operation data includes a data name and a data value of the algorithm step.

4. The method according to claim 1, wherein Before extracting the simulation data of each algorithm step from the simulation waveform file of the verified function, the method further comprises: Simulating the verified function in the chip based on the input signal using a universal verification method platform; During the simulation process, recording signal changes of the chip; A simulation waveform file of the verified function is generated based on the signal change.

5. The method according to claim 1, wherein Extracting simulation data of each algorithm step from the simulation waveform file of the verified function includes: Determining the key signals for each of the algorithm steps respectively; Extract the key signal and the signal value of the key signal of each algorithm step from the simulation waveform file respectively; Based on the key signal and the signal value of the key signal of each algorithm step, simulation data of each algorithm step is generated, and the simulation data includes a data name and a data value of the algorithm step.

6. The method according to claim 1, characterized in that After comparing the operation data and simulation data of each algorithm step to determine an abnormal algorithm step in which the operation data and simulation data are inconsistent, the method further includes: generating a discrepancy report based on the anomaly algorithm steps; The difference report is output.

7. A chip verification device, characterized in that: include: an acquisition module, configured to acquire a first executable file of a C model, wherein the first executable file includes original code and target code designed based on a verified function in a chip, wherein the verified function includes a plurality of algorithm steps, the original code is used to implement the plurality of algorithm steps, and the target code is used to instruct the C model to output operating data of each of the algorithm steps; An operation module, configured to execute the first executable file based on an input signal to obtain operation data of each step of the algorithm; an extraction module, configured to extract simulation data of each algorithm step from a simulation waveform file of the verified function, wherein the simulation waveform file is obtained by simulating the verified function based on the input signal; The comparison module is used to compare the operation data and simulation data of each algorithm step respectively to determine the abnormal algorithm step where the operation data and simulation data are inconsistent.

8. An electronic device, characterized in that: The electronic device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the chip verification method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by a processor, the chip verification method according to any one of claims 1 to 6 is implemented.

10. A computer program product, characterized in that When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device executes the chip verification method according to any one of claims 1 to 6.

Images