Chip verification code escaping method and device, electronic equipment and program product

Abstract

This application discloses a chip verification code escaping method, apparatus, electronic device, and program product, relating to the field of integrated circuit verification technology. The method includes: acquiring hardware verification code for a chip; acquiring code escaping rule configuration information, including syntax matching rules and syntax filtering rules; parsing and converting the hardware verification code based on the code escaping rule configuration information; and generating software driver code corresponding to the hardware verification code, which is used to drive the chip. The technical solution of this application achieves code reuse from the hardware verification environment to the software driver environment by converting hardware verification code into software driver code, avoiding repetitive input and human error caused by manually writing driver code. Furthermore, it improves the overall efficiency of chip verification and ensures the consistency of the verification environment by generating smoke test cases for simulation verification.

Description

Technical Field

[0001] This application relates to the field of integrated circuit verification technology, and in particular to a chip verification code escaping method, apparatus, electronic device and program product. Background Technology

[0002] In the field of integrated circuit design verification, hardware logic verification and software driver development are widely used to ensure the correctness of chip functionality. Design verification utilizes hardware description languages ​​to build the verification environment, while software verification uses programming languages ​​to write driver code. In existing technical solutions, hardware verification code and software driver code are often developed and maintained independently, with the mapping relationship relying on manual conversion or fixed scripts. However, this separation approach cannot adapt to scenarios with rapid chip iteration and high demands for hardware-software co-verification. Furthermore, fixed scripts cannot accommodate the differences in chip verification across various fields, potentially leading to problems such as redundant manpower investment, inconsistent verification environments, or low overall verification efficiency.

[0003] Therefore, there is an urgent need for a chip verification code escaping method that can convert hardware verification code into software driver code and enable the reuse of verification and driver environments. Summary of the Invention

[0004] This application provides a chip verification code escaping method, apparatus, electronic device, and program product.

[0005] Firstly, this application provides a method for escaping chip verification codes, including:

[0006] Obtain the hardware verification code for the chip; Retrieve code escaping rule configuration information, which includes syntax matching rules and syntax filtering rules; Based on the code escaping rule configuration information, the hardware verification code is parsed and converted; Generate software driver code corresponding to the hardware verification code. The software driver code is used to drive the chip.

[0007] In some embodiments, the hardware verification code is based on the SystemVerilog language, and the software driver code is based on the C language.

[0008] In some embodiments, hardware verification code is parsed and transformed based on code escaping rule configuration information, including: Hardware verification code is matched based on syntax matching rules to generate software driver code.

[0009] In some embodiments, it also includes: Based on syntax filtering rules, the syntax formats that are not supported by the programming language corresponding to the software driver code are filtered and deleted.

[0010] In some embodiments, generating software driver code corresponding to the hardware verification code includes: Generate header and source files; The underlying software library is built based on header and source files, and the chip driver environment is built by calling the underlying software library.

[0011] In some embodiments, it also includes: Generate smoke test cases based on the generated header and source files; Simulation verification was performed based on smoke test cases.

[0012] Secondly, this application provides a chip verification code escaping device, comprising: The code acquisition module is configured to acquire the hardware verification code of the chip; The rule acquisition module is configured to acquire code escaping rule configuration information, which includes syntax matching rules and syntax filtering rules. The conversion processing module is configured to parse and convert hardware verification code based on code escaping rule configuration information; The code generation module is configured to generate software driver code corresponding to the hardware verification code. The software driver code is used to drive the chip.

[0013] In some embodiments, the conversion processing module includes: The syntax matching submodule is configured to match hardware verification code based on syntax matching rules to generate software driver code; The syntax filtering submodule is configured to filter and delete syntax formats that are not supported by the programming language corresponding to the software driver code based on syntax filtering rules.

[0014] Thirdly, this application provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to implement any of the chip verification code escaping methods.

[0015] Fourthly, this application provides a computer program product, including a computer-readable storage medium on which a computer program is stored, wherein the computer program, when executed by a processor, implements a chip verification code escaping method for any one of the following.

[0016] The at least one technical solution adopted in this application can achieve the following beneficial effects: by parsing and converting the hardware verification code in the chip verification stage based on code escaping rule configuration information including syntax matching rules and syntax filtering rules, corresponding software driver code is generated, realizing code reuse from the hardware verification environment to the software driver environment, avoiding repetitive investment and human error caused by software driver personnel manually writing driver code; by generating header files and source files and building underlying software libraries, basic components that can be directly called are provided for building the chip driver environment, improving the development efficiency and reusability of driver code; by generating smoke test cases and performing simulation verification, the correctness of the converted software driver code is checked. The technical solution of this application effectively improves the overall efficiency of chip verification and ensures the consistency of the verification environment.

[0017] It should be understood that both the foregoing general description and the following detailed description are exemplary and intended to provide further illustration of the claimed technology. Attached Figure Description

[0018] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The accompanying drawings are used to provide a further understanding of the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the accompanying drawings, the same reference numerals generally represent the same components or steps.

[0019] Figure 1 This illustration schematically shows an overall flowchart of a chip verification code escaping method according to an embodiment of this application; Figure 2 This illustration schematically shows a syntax matching process of a chip verification code escaping method according to an embodiment of this application; Figure 3 This illustration schematically shows a syntax filtering process of a chip verification code escaping method according to an embodiment of this application; Figure 4 This illustration schematically shows a software driver code generation process for a chip verification code escaping method according to an embodiment of this application; Figure 5 This illustration schematically shows a smoke test case generation process for a chip verification code escaping method according to an embodiment of this application; Figure 6 This illustration schematically shows a smoke test case verification flow diagram of a chip verification code escaping method according to an embodiment of this application; Figure 7 This illustration schematically shows an overall structural diagram of a chip verification code escaping device according to an embodiment of this application; Figure 8 This illustration schematically shows a conversion processing module structure of a chip verification code escaping device according to an embodiment of this application; Figure 9 An exemplary block diagram of a computer program product of a chip verification code escaping method according to an embodiment of this application is shown schematically.

[0020] In the diagram: 701, Code Acquisition Module; 702, Rule Acquisition Module; 703, Conversion Processing Module; 704, Code Generation Module; 705, Syntax Matching Submodule; 706, Syntax Filtering Submodule; 901, Computer Program. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application more apparent, exemplary embodiments according to this application will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0022] Figure 1 The illustration shows an overall flowchart of a chip verification code escaping method according to an embodiment of this application.

[0023] like Figure 1 As shown, the steps are as follows: S101, Obtain the chip's hardware verification code. Specifically, the hardware verification code is register-transfer level code written in SystemVerilog, used to describe the chip's verification environment and logic functions. This code is usually generated by design verification personnel and verified through simulation to ensure the correctness of the chip's logic.

[0024] S102, Obtain code escaping rule configuration information. This configuration information includes syntax matching rules and syntax filtering rules. Specifically, load the pre-configured code escaping rule configuration information, where syntax matching rules define the mapping relationship between hardware verification code and software driver code, and syntax filtering rules define the syntax formats that need to be filtered and deleted.

[0025] For example, code escaping rule configuration information is stored in a table file, which includes a rule matching page and a text filtering page. The rule matching page stores syntax matching rules, and the text filtering page stores syntax filtering rules. Adaptation can be achieved by adjusting the configuration parameters in the table file for different chip verification scenarios.

[0026] S103, based on the code escaping rule configuration information, parses and converts the hardware verification code. Specifically, it uses syntax matching rules to match the hardware verification code and uses syntax filtering rules to filter and delete syntax formats in the hardware verification code that are not supported by the corresponding programming language, thereby achieving code language escaping.

[0027] S104 generates software driver code corresponding to the hardware verification code. Specifically, it outputs the escaped software driver code, which is used to drive the chip, enabling the converted code to run in the software verification platform to drive and verify the chip logic.

[0028] Figure 2 The illustration shows a syntax matching process diagram of a chip verification code escaping method according to an embodiment of this application.

[0029] like Figure 2 As shown, the steps are as follows: S201, Obtain syntax matching rules from code escaping rule configuration information. Specifically, read the code escaping rule configuration information and extract syntax matching rules from it. Syntax matching rules may include predefined syntax pattern templates or mapping tables, used to indicate how specific syntax structures in hardware verification code correspond to syntax structures in software driver code.

[0030] S202, based on syntax matching rules, matches the hardware verification code. Specifically, it identifies target code segments within the hardware verification code that conform to the syntax matching rules. Specifically, it traverses the code lines or syntax tree nodes of the hardware verification code, comparing the code content with the syntax pattern templates in the syntax matching rules. When a code segment in the hardware verification code is found to match a pattern in the syntax matching rules, that code segment is identified as the target code segment.

[0031] For example, register definitions or task function definitions in the SystemVerilog language are identified as target code snippets. For instance, the logic[31:0] type in SystemVerilog is matched with the uint32_t type in C, or the task definition is matched with the void function declaration in C, thereby establishing a mapping relationship between hardware data structures and software data structures.

[0032] S203, Generate software driver code based on the matching results. Specifically, based on the target code snippet and the mapping relationship defined in the syntax matching rules, generate the corresponding software driver code. For example, the variable definitions or logical operations in the identified hardware verification code are converted into corresponding variable declarations or function calls in the C language, thereby completing the initial generation from hardware verification code to software driver code.

[0033] Figure 3 The illustration shows a syntax filtering flow diagram of a chip verification code escaping method according to an embodiment of this application.

[0034] like Figure 3 As shown, the steps are as follows: S301, Obtain syntax filtering rules from the code escaping rule configuration information. Specifically, parse the syntax filtering rules from the code escaping rule configuration information. Syntax filtering rules can contain predefined filter lists or regular expression patterns used to identify syntax formats not supported by the programming language corresponding to the software driver code. For example, they can be defined for specific keywords or structures of the hardware description language that are not supported by the C language.

[0035] S302, based on syntax filtering rules, identifies syntax formats in the software driver code that are not supported by the corresponding programming language. Specifically, the initially generated software driver code is scanned or parsed, and the code content is compared with the filter list or pattern in the syntax filtering rules. When a syntax structure matching the syntax filtering rules is detected in the software driver code, that part of the syntax format is identified as an unsupported syntax format. For example, incompatible formats left over from concurrent execution statements or timing control statements specific to hardware verification code after conversion to software driver code are identified, such as the fork...join concurrent block, #10 delay control statement, or always@(posedge clk) timing logic block in SystemVerilog. These syntaxes cannot be directly compiled and run in C language and need to be identified as unsupported syntax formats.

[0036] S303 filters and removes identified unsupported syntax formats to generate filtered software driver code. Specifically, the identified unsupported syntax formats are removed from the software driver code or replaced with equivalent syntax structures supported by the programming language. After filtering and removal, the filtered software driver code is obtained, ensuring that it conforms to the syntax specifications of the target programming language, can be correctly compiled by the compiler, and can run on the software verification platform. For complex syntax structures that cannot be directly removed or replaced, for example, comment markers or placeholders can be inserted into the software driver code to prompt developers to manually handle special code segments; or complex sequential logic structures can be simplified into equivalent sequential execution code to ensure that the generated software driver code can be compiled and run on the software verification platform.

[0037] Figure 4 The illustration shows a schematic diagram of the software driver code generation process of a chip verification code escaping method according to an embodiment of this application.

[0038] like Figure 4As shown, the steps are as follows: S401 generates header and source files based on the filtered software driver code. Specifically, the filtered software driver code undergoes structured processing, saving interface declarations, macro definitions, and data type definitions as header files, and function implementations and specific logic operations as source files. The generated header and source files conform to the specifications of the target programming language; for example, they conform to the file organization format of the C language, to facilitate subsequent compilation and version management.

[0039] S402 builds a low-level software library based on header and source files. Specifically, the header and source files are compiled and linked to generate a reusable low-level software library. This low-level software library encapsulates the basic functionalities required by the chip driver and provides a unified calling interface. By building this low-level software library, modular storage of the driver code is achieved, facilitating its calling and reuse in different chip verification scenarios and reducing the workload of repetitive development.

[0040] S403 constructs the chip driver environment by calling underlying software libraries. Specifically, the underlying software libraries are loaded in the software verification platform, and the interface functions in the underlying software libraries are called to initialize hardware interfaces, configure registers, and send test stimuli, thereby constructing the chip driver environment.

[0041] For example, memory address mapping, interrupt configuration, and register read / write operations are performed by calling library functions, simulating software access to hardware. The chip driver environment is used to simulate chip operations at the software level, enabling the converted software driver code to drive chip logic, complete hardware-software co-verification or independent verification of the software platform, and ensure the consistency of the verification environment.

[0042] Figure 5 The illustration shows a smoke test case generation process of a chip verification code escaping method according to an embodiment of this application.

[0043] like Figure 5 As shown, the steps are as follows: S501: Obtain the generated header and source files. These files contain the interface definitions and logic implementations required by the chip driver, serving as the basic input data for generating smoke test cases. Ensure that the file versions used are consistent with the converted software driver code to guarantee the accuracy of subsequent verification.

[0044] S502 generates smoke test cases based on the generated header and source files. Specifically, it parses the interface declarations in the header files and the function implementations in the source files, automatically generating test scripts or test code that call these interfaces and functions, which serve as smoke test cases. These smoke test cases are used to perform basic functional testing on the converted software driver code, verifying the availability of key interfaces and the correctness of basic logic. The generated smoke test cases can be directly applied to the software verification platform without the need for manually writing test scripts, thus improving verification efficiency.

[0045] Figure 6 The illustration shows a smoke test case verification flow diagram of a chip verification code escaping method according to an embodiment of this application.

[0046] like Figure 6 As shown, the steps are as follows: S601, Obtain the generated smoke test cases. Smoke test cases contain test scripts or test code used to test the software driver code, serving as input data for simulation verification. Ensure that the version of the smoke test cases used is consistent with the generated software driver code to guarantee the validity and accuracy of the verification results.

[0047] S602, simulates and verifies the software driver code based on smoke test cases. Specifically, smoke test cases and software driver code are loaded into the software verification platform, and the smoke test cases are run to perform functional tests on the software driver code. By comparing the simulation output results with the expected results, the logical correctness and interface usability of the converted software driver code are verified. For example, the smoke test cases are executed in an EDA simulation platform or software verification environment to obtain the simulation verification results. If the verification passes, it indicates that the software driver code can correctly drive the chip logic; if the verification fails, the process returns to check the code escaping rule configuration information or hardware verification code for correction and re-conversion.

[0048] After successful verification, the software driver code is integrated into the chip driver verification platform for reuse, allowing the design verification environment and the chip driver verification environment to share the same code logic. Through this reuse mechanism, the verification logic completed by the design verification personnel using the SystemVerilog language can be directly converted into C language driver code usable by the chip driver personnel. Both environments operate based on the same code logic, ensuring the consistency and reliability of the verification results and significantly reducing the difficulty of chip driver development and debugging.

[0049] Figure 7 The illustration shows an overall structural diagram of a chip verification code escaping device according to an embodiment of this application.

[0050] like Figure 7As shown, the device includes a code acquisition module 701, a rule acquisition module 702, a conversion processing module 703, and a code generation module 704.

[0051] The code acquisition module 701 is configured to acquire the chip's hardware verification code. The hardware verification code is register-transfer level code written in SystemVerilog, used to describe the chip's verification environment and logic functions. This code is typically generated by design verification personnel and verified through simulation to ensure the correctness of the chip's logic.

[0052] The rule acquisition module 702 is configured to acquire code escaping rule configuration information. This configuration information includes syntax matching rules and syntax filtering rules. The syntax matching rules define the mapping relationship between hardware verification code and software driver code, while the syntax filtering rules define the syntax formats that need to be filtered and deleted. For example, the code escaping rule configuration information is stored in a table file, which includes a rule matching page and a text filtering page. The rule matching page stores syntax matching rules, and the text filtering page stores syntax filtering rules. Adaptation can be achieved by adjusting the configuration parameters in the table file for different chip verification scenarios.

[0053] The conversion processing module 703 is configured to parse and convert hardware verification code based on code escaping rule configuration information. Specifically, the conversion processing module 703 uses syntax matching rules to match the hardware verification code, identifies target code fragments that can be converted into software driver code, and initially generates the corresponding software driver code; at the same time, it uses syntax filtering rules to filter and delete syntax formats that are not supported by the corresponding programming language in the initially generated software driver code, ensuring that the generated code conforms to the syntax specifications of the target programming language.

[0054] The code generation module 704 is configured to generate software driver code corresponding to the hardware verification code, which is used to drive the chip. Specifically, the code generation module 704 generates header files and source files based on the filtered software driver code output by the conversion processing module 703; it constructs a low-level software library based on the header files and source files; and it builds a chip driver environment by calling the low-level software library. The software driver code can run in the software verification platform to drive and verify the chip logic. In addition, the code generation module 704 can also generate smoke test cases based on the generated header files and source files for subsequent simulation verification to ensure that the escaped code is correct and usable.

[0055] Figure 8 The illustration shows a schematic diagram of the conversion processing module structure of a chip verification code escaping device according to an embodiment of the present application.

[0056] like Figure 8As shown, the conversion processing module 703 includes a syntax matching submodule 705 and a syntax filtering submodule 706.

[0057] The syntax matching submodule 705 is configured to match hardware verification code based on syntax matching rules to generate software driver code. Specifically, the syntax matching submodule 705 obtains syntax matching rules from the rule acquisition module 702, traverses the code lines or syntax tree nodes of the hardware verification code, and compares the code content with the syntax pattern templates in the syntax matching rules. When a code segment in the hardware verification code is found to match a pattern in the syntax matching rules, that code segment is identified as the target code fragment.

[0058] For example, register definitions or task function definitions in the SystemVerilog language are identified as target code snippets. For instance, the `logic[31:0]` type in SystemVerilog is matched with the `uint32_t` type in C, or the `task` definition is matched with a `void` function declaration in C, thereby establishing a mapping relationship between hardware data structures and software data structures. Based on the target code snippets and the mapping relationship defined in the syntax matching rules, the corresponding software driver code is generated, completing the initial generation from hardware verification code to software driver code.

[0059] The syntax filtering submodule 706 is configured to filter and delete syntax formats that are not supported by the programming language corresponding to the software driver code based on syntax filtering rules. Specifically, the syntax filtering submodule 706 obtains syntax filtering rules from the rule acquisition module 702, scans or parses the software driver code initially generated by the syntax matching submodule 705, and compares the code content with the filter list or pattern in the syntax filtering rules. When a syntax structure matching the syntax filtering rules is detected in the software driver code, that part of the syntax format is identified as an unsupported syntax format.

[0060] For example, incompatible formats of concurrent execution statements or timing control statements specific to hardware verification code are identified after conversion to software driver code. Examples include SystemVerilog's fork...join concurrent blocks, #10 delay control statements, or always@(posedge clk) timing logic blocks. These syntaxes cannot be directly compiled and run in C and need to be identified as unsupported syntax. The identified unsupported syntax is then removed from the software driver code or replaced with equivalent syntax structures supported by the programming language.

[0061] For complex syntactic structures that cannot be directly removed or replaced, for example, comment markers or placeholders can be inserted into the software driver code to prompt developers to manually handle special code segments; or complex sequential logic structures can be simplified into equivalent sequential execution code to ensure that the generated software driver code can be compiled and run on the software verification platform. After filtering and deletion, the filtered software driver code is obtained, ensuring that the software driver code conforms to the syntax specifications of the target programming language, can be correctly compiled by the compiler, and can run on the software verification platform.

[0062] Figure 9 An exemplary block diagram of a computer program product of a chip verification code escaping method according to an embodiment of this application is shown schematically.

[0063] like Figure 9 As shown, the computer program product stores a computer program 901, which, when executed by a processor, implements the method provided in any embodiment of this application.

[0064] The basic principles of this application have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this application are merely examples and not limitations, and should not be considered as essential features of each embodiment of this application. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the application to the necessity of employing the aforementioned specific details for implementation.

[0065] The block diagrams of devices, apparatuses, devices, and systems involved in this application are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” and “having” are open-ended terms meaning “including but not limited to” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to” and is used interchangeably with it.

[0066] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0067] It should also be noted that in the system and method of this application, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions of this application.

[0068] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this application is not limited to the specific aspects of the processes, machines, manufacturing, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufacturing, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described above can be utilized. Therefore, the appended claims include such processes, machines, manufacturing, events, means, methods, or actions within their scope.

[0069] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this application. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of this application. Therefore, this application is not intended to be limited to the aspects shown herein, but rather to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0070] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this application to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A chip verification code escaping method, characterized in that, include: Obtain the hardware verification code for the chip; Obtain code escaping rule configuration information, which includes syntax matching rules and syntax filtering rules; Based on the code escaping rule configuration information, the hardware verification code is parsed and converted; Generate software driver code corresponding to the hardware verification code, which is used to drive the chip.

2. The chip verification code escaping method according to claim 1, characterized in that, The hardware verification code is based on the SystemVerilog language, and the software driver code is based on the C language.

3. The chip verification code escaping method according to claim 1, characterized in that, Based on the code escaping rule configuration information, the hardware verification code is parsed and converted, including: The hardware verification code is matched based on the syntax matching rules to generate the software driver code.

4. The chip verification code escaping method according to claim 3, characterized in that, Also includes: Based on the syntax filtering rules, the syntax formats that are not supported by the programming language corresponding to the software driver code are filtered and deleted.

5. The chip verification code escaping method according to claim 1, characterized in that, Generate software driver code corresponding to the hardware verification code, including: Generate header and source files; A low-level software library is built based on the header file and the source file, and a chip driver environment is built by calling the low-level software library.

6. The chip verification code escaping method according to claim 5, characterized in that, Also includes: Generate smoke test cases based on the generated header file and source file; Simulation verification was performed based on the smoke test case.

7. A chip verification code escaping device, characterized in that, include: The code acquisition module is configured to acquire the hardware verification code of the chip; The rule acquisition module is configured to acquire code escaping rule configuration information, which includes syntax matching rules and syntax filtering rules. The conversion processing module is configured to parse and convert the hardware verification code based on the code escaping rule configuration information; The code generation module is configured to generate software driver code corresponding to the hardware verification code, and the software driver code is used to drive the chip.

8. The chip verification code escaping device according to claim 7, characterized in that, The conversion processing module includes: The syntax matching submodule is configured to match the hardware verification code based on the syntax matching rules to generate the software driver code; The syntax filtering submodule is configured to filter and delete syntax formats that are not supported by the programming language corresponding to the software driver code based on the syntax filtering rules.

9. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the chip verification code escaping method according to any one of claims 1 to 6.

10. A computer program product comprising a computer-readable storage medium on which a computer program is stored, characterized in that, When the computer program is executed by the processor, it implements the chip verification code escaping method as described in any one of claims 1 to 6.

Images