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

Abstract

The application discloses a chip testing method, device, equipment, storage medium and program product. The method comprises the following steps: obtaining structured description data based on a standard test description file of a first chip, wherein the standard test description file is used for describing the test requirement of the first chip; injecting the structured description data into an environment template to obtain a verification environment, wherein the verification environment is a program used for carrying chip test logic, and the environment template is a preset test logic program framework; and driving the first chip to test based on the verification environment, so as to obtain a chip test result. The test requirement of different chips can be adapted only by parameter injection of the structured description data, a full-automatic chip test flow can be realized, and the chip test efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a chip testing method, apparatus, device, storage medium, and program product. Background Technology

[0002] In the chip design and mass production process, chip testing is a crucial step in ensuring functional correctness and performance stability. By applying specific test vectors and monitoring the output response, it is possible to verify whether the chip conforms to design specifications and prevent defective chips from entering the market and causing losses.

[0003] In related technologies, chip testing often relies on manually writing test platform code or on a specific vendor's closed toolchain: first, the Automatic Test Pattern Generation (ATPG) tool generates a Standard Test Interface Language (STIL) file, then engineers manually convert the test vectors and timing parameters in the file into a hardware description language test environment, or use a toolchain to simultaneously generate test files and verification models, and finally execute the test on a hardware simulation platform.

[0004] However, the verification models generated by closed toolchains have poor adaptability, cannot be flexibly integrated into different hardware simulation platforms, and have high testing costs and low testing efficiency. Summary of the Invention

[0005] This application provides a chip testing method, apparatus, device, storage medium, and program product. The technical solution is as follows.

[0006] On the one hand, a chip testing method is provided, the method comprising:

[0007] Structured description data is obtained based on the standard test description file of the first chip, wherein the standard test description file is used to describe the test requirements of the first chip;

[0008] The structured description data is injected into the environment template to obtain the verification environment, which is a program used to carry the chip test logic, and the environment template is a preset test logic program framework.

[0009] The first chip is tested based on the verification environment, and the chip test results are obtained.

[0010] On the other hand, a chip testing apparatus is provided, the apparatus comprising:

[0011] The processing module is used to obtain structured description data based on the standard test description file of the first chip, wherein the standard test description file is used to describe the test requirements of the first chip;

[0012] The processing module is further configured to inject the structured description data into the environment template to obtain a verification environment, wherein the verification environment is a program used to carry chip test logic, and the environment template is a preset test logic program framework.

[0013] The testing module is used to drive the testing of the first chip based on the verification environment and obtain the chip test results.

[0014] In some embodiments, the processing module is further configured to:

[0015] Obtain the standard test description file;

[0016] The test vector, timing parameters, and signal parameters are extracted from the standard test description file. The test vector is used to drive the test of the first chip, the timing parameters are used to constrain the signal interaction timing when testing the first chip, and the signal parameters are used to indicate the test signal attributes.

[0017] The structured description data is generated based on the test vector, the timing parameters, and the signal parameters.

[0018] In some embodiments, the structured description data includes a set of test vectors, a set of timing constraints, and a set of signal attributes;

[0019] The test vector set includes at least two test vectors, each test vector corresponding to an expected result. The expected result is used to provide a reference for the test result output by the first chip based on the test vector.

[0020] The timing constraint set is used to indicate the timing parameters when testing the first chip, and the timing parameters include at least one of clock cycle, signal setup time, and signal hold time.

[0021] The signal attribute set is used to indicate the signal parameters when testing the first chip, and the signal parameters include at least one of signal name, signal type, and signal direction.

[0022] In some embodiments, the environment template includes a test stimulus generation template and a test result comparison template;

[0023] The processing module is further configured to:

[0024] The structured description data is injected into the test stimulus generation template and the test result comparison template to generate test stimulus code and test comparison code;

[0025] The verification environment is obtained by assembling the test stimulus code and the test comparison code. The test stimulus code is used to drive the test of the first chip based on the test driving logic, and the test comparison code is used to generate the chip test results based on the test result comparison logic.

[0026] In some embodiments, the testing module is further configured to:

[0027] Integrate the verification environment and the first chip to generate a hardware execution file, which is used to express the chip test logic in a hardware description language;

[0028] Run the hardware executable file to generate the chip test results.

[0029] In some embodiments, the test module is further configured to connect the verification environment to the test interface of the first chip and compile the hardware executable file.

[0030] In some embodiments, the hardware executable file includes test logic code and test data;

[0031] The test logic code is used to instruct the chip test logic;

[0032] The test data includes test vectors and expected results;

[0033] The test module is also used for:

[0034] Load the hardware executable file;

[0035] The test driver logic, as indicated by the hardware execution file, drives the test of the first chip.

[0036] Based on the test result comparison logic indicated by the hardware execution file, the test result obtained by the first chip based on the test vector is compared with the expected result to obtain the comparison result.

[0037] The chip test results are generated based on the comparison results.

[0038] In some embodiments, the testing module is further configured to:

[0039] If the test result meets the verification conditions and the expected result, a first comparison result is obtained. The first comparison result is used to indicate that the first chip passes the test based on the test vector.

[0040] If the test result does not meet the verification conditions as expected, a second comparison result is obtained, which is used to indicate that the first chip has failed the test based on the test vector.

[0041] In some embodiments, the testing module is further configured to:

[0042] Test statistics are generated based on the comparison results. The test statistics include at least one of test coverage, error records, and pass rate. The test coverage is used to indicate the degree to which the test vector covers the function of the first chip. The error records are used to indicate the test information of the first chip that failed the test based on the test vector. The pass rate is used to indicate the proportion of the first chip that passed the test based on the test vector.

[0043] The chip test results are generated based on the test statistics.

[0044] On the other hand, a computer device is provided, the computer device including a processor and a memory, the memory storing at least one instruction, at least one program, code set or instruction set, the at least one instruction, the at least one program, the code set or instruction set being loaded and executed by the processor to implement the chip testing method as described in any of the embodiments of this application above.

[0045] On the other hand, a computer-readable storage medium is provided, wherein at least one instruction, at least one program, code set, or instruction set is stored therein, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the chip testing method as described in any of the embodiments of this application above.

[0046] On the other hand, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform any of the chip testing methods described in the above embodiments.

[0047] The beneficial effects of the technical solutions provided in this application include at least the following:

[0048] By injecting structured description data obtained from parsing standard test description files into an environment template, a verification environment is automatically generated. This approach not only generates hardware-platform-independent structured description data by parsing standard test description files, thus eliminating the format dependency of the original test files on specific toolchains, but also adapts to the testing requirements of different chips simply by injecting parameters of the structured description data, based on an environment template that encapsulates general test logic. Furthermore, the generated verification environment conforms to the general specifications of hardware description languages, can be recognized and compiled by various hardware simulation platforms, and is not limited by specific toolchains or hardware platforms. This improves the flexibility of cross-platform integration, enables a fully automated chip testing process, eliminates the need for manual adjustments to the verification environment to adapt to hardware simulation platforms, reduces testing costs, and improves chip testing efficiency. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1 This is a schematic diagram of a test system provided in an exemplary embodiment of this application;

[0051] Figure 2 This is a flowchart of a chip testing method provided in an exemplary embodiment of this application;

[0052] Figure 3 This is a chip testing architecture diagram provided in an exemplary embodiment of this application;

[0053] Figure 4 This is a flowchart illustrating the standard test description file parsing process provided in an exemplary embodiment of this application;

[0054] Figure 5 This is a flowchart illustrating a file parsing process provided in an exemplary embodiment of this application;

[0055] Figure 6 This is a flowchart of an automatic generation method for a verification environment provided in an exemplary embodiment of this application;

[0056] Figure 7 This is a flowchart illustrating the verification environment generation process provided in an exemplary embodiment of this application;

[0057] Figure 8 This is a flowchart of a chip testing method based on a hardware executable file provided in an exemplary embodiment of this application;

[0058] Figure 9This is a schematic diagram of the top-level design for chip testing provided in an exemplary embodiment of this application;

[0059] Figure 10 This is a schematic diagram of a chip testing framework provided in an exemplary embodiment of this application;

[0060] Figure 11 This is an accelerated testing flowchart provided by an exemplary embodiment of this application;

[0061] Figure 12 This is a structural block diagram of a chip testing apparatus provided in an exemplary embodiment of this application;

[0062] Figure 13 This is a structural block diagram of a terminal provided in an exemplary embodiment of this application. Detailed Implementation

[0063] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0064] It should be understood that although the terms first, second, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, a first parameter may also be referred to as a second parameter without departing from the scope of this disclosure, and similarly, a second parameter may also be referred to as a first parameter. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0065] In the chip design and mass production process, chip testing is a crucial step in ensuring functional correctness and performance stability. By applying specific test vectors and monitoring output responses, it is possible to verify whether the chip conforms to design specifications, preventing defective chips from entering the market and causing losses. In related technologies, chip testing often relies on manually written test platform code or closed toolchains from specific vendors: first, STIL files are generated using the ATPG tool, then engineers manually convert the test vectors and timing parameters in the file into a hardware description language test environment, or the toolchain is used to simultaneously generate test files and verification models, and finally, the tests are executed on a hardware simulation platform. However, verification models generated by closed toolchains have poor adaptability, cannot be flexibly integrated into different hardware simulation platforms, and result in high testing costs and low testing efficiency.

[0066] The chip testing method provided in this application automatically generates a verification environment by injecting structured description data obtained from parsing standard test description files into an environment template. This method not only generates hardware platform-independent structured description data by parsing standard test description files, eliminating the original test files' format dependency on specific toolchains, but also adapts to the testing needs of different chips based on an environment template encapsulating general test logic, simply by injecting parameters from the structured description data. Furthermore, the generated verification environment conforms to the general specifications of hardware description languages, can be recognized and compiled by various hardware simulation platforms, and is not limited by specific toolchains or hardware platforms. This improves the flexibility of cross-platform integration, enables a fully automated chip testing process, eliminates the need for manual adjustments to the verification environment to adapt to hardware simulation platforms, reduces testing costs, and improves chip testing efficiency.

[0067] First, the testing system for this application will be introduced. Please refer to... Figure 1 The illustration shows a schematic diagram of a test system provided in an exemplary embodiment of this application, which includes a computer device 10 and a first chip 20.

[0068] Computer device 10 is the test execution entity, used to execute the chip testing method provided in the embodiments of this application. The first chip 20 is the object to be tested, and there is a connection between computer device 10 and the first chip 20. Through this connection, computer device 10 can drive the test of the first chip 20.

[0069] In some embodiments, the computer device 10 is a hardware simulation device, which is a physical execution carrier for the test logic of the first chip 20, and is used to execute the hardware executable logic of the first chip 20.

[0070] Schematic, computer device 10 parses the standard test description file of the first chip 20 to obtain structured description data. The standard test description file is used to express the test requirements of the first chip 20 in a standard test interface language, and the structured description data is used to express the test requirements of the first chip 20 in structured data. Computer device 10 injects the structured description data into an environment template to automatically generate a verification environment. This verification environment is a program used to carry the chip test logic, and the environment template is a preset test logic framework. Computer device 10 drives the test of the first chip 20 based on the verification environment to obtain chip test results. These chip test results are used to indicate the chip performance of the first chip 20.

[0071] Optionally, the computer device 10 mentioned above may be a hardware simulation device such as a dedicated chip test accelerator or a field-programmable gate array (FPGA) simulator, or a terminal or server capable of driving the test chip. This application embodiment does not limit this.

[0072] The aforementioned terminal is optional and can be a desktop computer, laptop computer, mobile phone, tablet computer, e-book reader, Moving Picture Experts Group Audio Layer III (MP3) player, Moving Picture Experts Group Audio Layer IV (MP4) player, smart TV, smart vehicle, and other types of terminal devices. This application embodiment does not limit the specific terminal device to these types.

[0073] It is worth noting that the aforementioned servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers that provide basic cloud computing services such as cloud services, cloud security, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0074] Cloud technology refers to a managed technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to achieve data computing, storage, processing, and sharing.

[0075] In some embodiments, the server described above can also be implemented as a node in a blockchain system.

[0076] It should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant regions. For example, the operational data and account information involved in this application were obtained with full authorization.

[0077] To further clarify, this application may display a prompt interface, pop-up window, or output voice prompts before and during the collection of user-related data (e.g., account information, historical operation data, and real-time operation data involved in this application). These prompt interfaces, pop-ups, or voice prompts are used to inform the user that their relevant data is being collected. This ensures that the application only begins the steps for collecting user-related data after receiving confirmation from the user regarding the prompt interface or pop-up window; otherwise (i.e., without receiving confirmation from the user), the steps for collecting user-related data end, meaning no user-related data is collected. In other words, all user data collected in this application is collected with the user's consent and authorization, and the collection, use, and processing of relevant user data must comply with the relevant laws, regulations, and standards of the relevant regions.

[0078] This is illustrative; please refer to it. Figure 2 This document illustrates a flowchart of a chip testing method provided in an exemplary embodiment of this application. This method can be executed by a terminal, a server, or both simultaneously. This embodiment uses the execution of the method by a terminal as an example for illustration. Figure 2 As shown, the method includes the following steps:

[0079] Step 210: Obtain structured description data based on the standard test description file of the first chip.

[0080] The standard test description file is used to describe the test requirements of the first chip, and the structured description data is used to express the test requirements of the first chip in structured data.

[0081] Optionally, the standard test description file is a text file written in a standardized test interface language to fully record the test requirements of the first chip.

[0082] Test requirements include, but are not limited to, the test objectives, test scope, test rules, and judgment criteria for the first chip. Essentially, test requirements transform the chip's design requirements, such as functional correctness, performance stability, and timing compliance, into quantifiable and executable test task descriptions. Standard test description files are description files that describe test tasks using standard test interface languages.

[0083] As an example, the standard test description file can be a STIL file automatically generated based on ATPG.

[0084] Structured description data is an intermediate data set generated after parsing a standard test description file. It adopts a hierarchical data structure, such as tables, dictionaries, graph structures, sets, etc.

[0085] In some embodiments, structured description data can be obtained by parsing a standard test description file, or the structured description data corresponding to the first chip can be obtained directly, or the parsed structured description data can be reused for the first chip. This application does not limit this.

[0086] Parsing standard test description files refers to the process of recognizing text content, verifying syntax rules, extracting semantic information, and reconstructing data formats from standard test description files. Its core objective is to transform unstructured text test requirements into structured data that machines can directly process, providing a unified and standardized input basis for the automatic generation of subsequent verification environments.

[0087] In some embodiments, the parsing process includes obtaining a standard test description file for the first chip, extracting test vectors, timing parameters, and signal parameters from the standard test description file through syntax parsing, and generating structured description data based on the test vectors, timing parameters, and signal parameters.

[0088] The test vector is used to drive the test of the first chip, the timing parameters are used to constrain the signal interaction timing when testing the first chip, and the signal parameters are used to indicate the test signal attributes.

[0089] For test vector extraction, the text description of "input signal = value → output signal = expected value" can be converted into a structured input-output mapping pair, namely test vector-expected result pair, by identifying the content corresponding to the keyword "TEST_VECTOR" in the standard test description file. Here, the test vector is a vector used to test the specified function of the chip, and the expected result is the expected result of the chip running the test vector.

[0090] For timing parameter extraction, timing constraint parameters such as clock cycle, signal setup time, and signal hold time can be extracted by identifying the content corresponding to the keyword "TIMING_CONSTRAINT".

[0091] For signal parameter extraction, attribute parameters such as signal name, signal type, signal direction, and signal bit width can be extracted by identifying the content corresponding to the keyword "SIGNAL_DEFINITION".

[0092] Optionally, the structured description data includes a set of test vectors, a set of timing constraints, and a set of signal attributes.

[0093] The test vector set includes at least two test vectors used to drive the first chip; the timing constraint set is used to indicate the timing parameters when testing the first chip, and the timing parameters include at least one of clock cycle, signal setup time, and signal hold time; the signal attribute set is used to indicate the signal parameters when testing the first chip, and the signal parameters include at least one of signal name, signal type, and signal direction.

[0094] The test vector is the signal value input to the first chip. The test vector corresponds to the expected result, and the prediction result is the output value generated by the chip under the drive of the test vector.

[0095] In some embodiments, test vectors may correspond to test scenario labels, which indicate the test type corresponding to the test vector, such as functional testing, boundary condition testing, etc., and can be used for scenario matching of the subsequent verification environment.

[0096] The timing constraint set is a data set that defines the timing rules for signal interactions during the testing process, and is used to ensure the validity of the test vector.

[0097] The signal attribute set is a data set that describes all the signal characteristics involved in the test process, and is used to ensure the compatibility of signal drivers and chip interfaces.

[0098] Step 220: Inject the structured description data into the environment template to obtain the verification environment.

[0099] The verification environment is a program used to carry the chip test logic, and the environment template is a preset test logic program framework.

[0100] The verification environment is an executable program written in a hardware description language, used to carry all the test logic of the first chip; the environment template is a predefined test logic program framework, which adopts a modular structure design in a hardware description language, used to carry general test logic and reserve parameter injection interfaces.

[0101] Injecting structured description data into an environment template to obtain a verification environment means filling the parameters in the structured description data into the corresponding positions in the environment template according to preset rules, and combining the structured description data and the environment template into an executable test program.

[0102] In some embodiments, the process of generating the verification environment includes: obtaining an environment template including a test stimulus generation template and a test result comparison template, wherein the test stimulus generation module is a program framework for carrying test-driven logic and the test result comparison template is a program framework for carrying test result comparison logic; injecting structured description data into the test stimulus generation template and the test result comparison template to automatically generate the verification environment.

[0103] An environment template is a predefined, standardized test logic program framework stored in a template library of computer devices. Its design goal is to achieve rapid instantiation of the test environment through "general logic encapsulation + parameter interface reservation".

[0104] When acquiring an environment template, the system can automatically match the corresponding environment template based on the type of the first chip (such as a digital chip or a mixed-signal chip) or the test scenario (such as functional testing or timing testing), such as "general test template for digital chips" or "specific test template for high-speed interfaces".

[0105] The core components of the environment template include a test stimulus generation template and a test result comparison template. The test stimulus generation template is the logic framework used to drive the test of the first chip, and the test result comparison template is the logic framework used to verify the first chip.

[0106] In some embodiments, structured description data is injected into a test stimulus generation template and a test result comparison template to generate test stimulus code and test comparison code; the test stimulus code and test comparison code are assembled to obtain a verification environment, wherein the test stimulus code is used to drive the test of the first chip based on test driving logic, and the test comparison code is used to generate chip test results based on test result comparison logic.

[0107] The injection of structured description data combines the specific parameters of the test requirements with the general logic of the environment template, and the program automatically completes parameter matching and code generation.

[0108] Injecting structured description data into the test stimulus generation template can transform the general logic of the test driver into a specific signal driver program for the first chip, i.e., test stimulus code, which can accurately output input signals that meet the test requirements.

[0109] By injecting structured description data into the test result comparison template, the general logic for verifying test results can be transformed into a specific result verification program for the first chip, i.e., test comparison code, which can automatically complete the acquisition and comparison of output signals.

[0110] Step 230: Drive the test of the first chip based on the verification environment and obtain the chip test results.

[0111] Optionally, the chip test results are used to indicate at least one test result of the first chip, such as chip performance, compatibility, or compliance.

[0112] The first chip test driven by the verification environment refers to the process of executing the test logic defined in the verification environment through a hardware carrier, applying preset test vectors to the first chip, collecting output signals, and verifying the results. Its core objective is to verify whether the first chip meets the design requirements through an automated process.

[0113] Chip test results can be used to reflect the performance indicators of the first chip, such as functional correctness, timing compliance, and signal stability.

[0114] In some embodiments, the testing process includes: integrating a verification environment and a first chip; generating a hardware execution file, which is used to express the chip test logic in a hardware description language; and running the hardware execution file to generate chip test results.

[0115] Integration refers to building a test system that can work together with the verification environment (i.e., test logic program) and the first chip (i.e. test object) through physical connection and logical adaptation. Its core objective is to ensure that test signals can be transmitted stably between the two.

[0116] The process of generating the hardware executable file includes connecting the verification environment to the test interface of the first chip and compiling it to obtain the hardware executable file.

[0117] In some embodiments, it is necessary to logically bind the signal ports of the verification environment, such as the excitation output terminal and the result acquisition terminal, to the test interfaces of the first chip, such as the input pins and the output pins, so as to drive the test of the first chip based on the verification environment.

[0118] The hardware executable file is a binary file that integrates the test logic of the verification environment with the interface characteristics of the first chip and is compiled into a file that can be run directly on the hardware simulation platform. It is the carrier that transforms the test logic from software description into hardware executable operation. Its essence is a composite of "test logic code + test data". It can be recognized and executed by the hardware simulation platform and can accurately adapt to the interface timing and signal characteristics of the first chip to realize automated driving and result verification of the chip.

[0119] The hardware execution file includes test logic code and test data. The test logic code is used to instruct the chip test logic, and the test data includes test vectors and expected results.

[0120] Test logic code is a set of binary instructions that can be directly executed by the hardware. It encapsulates the test logic in the verification environment and is used to control the timing, signal interaction and result judgment of the test process. For example, it includes stimulus driving logic, result acquisition and comparison logic, timing control logic, exception handling logic, etc.

[0121] Test data is a static data block in the hardware execution file, which stores the specific parameters (i.e., test vectors) required for the test and the expected standards (i.e., expected results).

[0122] Hardware executable files are the key link between software logic and hardware execution. Through compilation and transformation, abstract verification environment code is converted into hardware-executable instructions, solving the problem that software descriptions cannot directly drive physical chips.

[0123] In some embodiments, the chip test results are obtained by comparing the test results of the first chip obtained by testing it with the expected results based on structured description data.

[0124] The testing process includes loading the hardware executable file, testing the first chip based on the test-driven logic indicated by the hardware executable file, comparing the test results obtained by the first chip based on the test vector with the expected results based on the test result comparison logic indicated by the hardware executable file, and generating chip test results based on the comparison results.

[0125] If the test results meet the verification conditions, a first comparison result is obtained, which indicates that the first chip passes the test based on the test vector; if the test results do not meet the verification conditions, a second comparison result is obtained, which indicates that the first chip fails the test based on the test vector.

[0126] In some embodiments, test statistics are generated based on the comparison results, and chip test results are generated based on the test statistics.

[0127] Optionally, the test statistics include at least one of test coverage, error records, and pass rate. Test coverage is used to indicate the degree to which the test vector covers the functionality of the first chip. Error records are used to indicate test information of the first chip that failed the test based on the test vector. Pass rate is used to indicate the proportion of the first chip that passed the test based on the test vector.

[0128] This is illustrative; please refer to it. Figure 3 , Figure 3 This is a chip testing architecture diagram provided in an exemplary embodiment of this application, such as... Figure 3 As shown, the chip testing system may include an input layer 310, a parsing layer 320, a processing layer 330, an acceleration layer 340, and an output layer 350.

[0129] The input layer 310 is used to input STIL files.

[0130] The parsing layer 320 is used to parse STIL files through the STIL parsing engine to obtain structured description data, which may include processing flows such as Joint Test Action Group (JTAG) signal timing parsing and top-level interface state extraction.

[0131] The processing layer 330 is used to perform test data transformation and verification environment generation. For test data transformation, it can include processing flows such as timing constraint generation based on structured description data and top-level signal mapping. For verification environment generation, it can execute processing flows such as JTAG timing template driving and top-level interface adaptation through the verification environment (Testbench) generator.

[0132] Acceleration layer 340 can be integrated through a hardware simulation platform (such as Palladium) to perform incremental compilation, time-sensitive test vector loading and other processing procedures.

[0133] The output layer 350 is used for test execution and result analysis. For test execution, it includes processing procedures such as JTAG signal timing monitoring and top-level state anomaly detection. For result analysis, it includes processing procedures such as timing violation location and state anomaly tracing.

[0134] In summary, the method provided in this application automatically generates a verification environment by injecting structured description data obtained from standard test description files into an environment template. This method not only generates hardware-platform-independent structured description data by parsing standard test description files, eliminating the original test files' format dependency on specific toolchains, but also adapts to the testing needs of different chips based on an environment template encapsulating general test logic, simply by injecting parameters from the structured description data. Furthermore, the generated verification environment conforms to the general specifications of hardware description languages, can be recognized and compiled by various hardware simulation platforms, and is not limited by specific toolchains or hardware platforms. This improves the flexibility of cross-platform integration, enables a fully automated chip testing process, eliminates the need for manual adjustments to the verification environment to adapt to hardware simulation platforms, reduces testing costs, and improves chip testing efficiency.

[0135] In some embodiments, the parsing process of the test description file describes the transformation of the test requirements of the first chip from text description into machine-processable structured data, providing standardized input for the automatic generation of the subsequent verification environment. Please refer to [reference needed]. Figure 4 , Figure 4 This is a flowchart illustrating the standard test description file parsing process provided in an exemplary embodiment of this application. This method can be executed by a terminal, a server, or both simultaneously. This embodiment uses terminal execution as an example for illustration. Figure 4 As shown, step 210 above includes the following steps:

[0136] Step 211: Obtain the standard test description file.

[0137] Standard test description files are text files written using standard test interface languages, and their core characteristics include standardization, completeness, and readability.

[0138] Standardization refers to adhering to unified grammatical rules, such as fixed keywords and parameter formats, to ensure compatibility between different testing tools and systems.

[0139] Completeness refers to the inclusion of all the required information for the first chip test, covering scenarios such as functional testing, timing testing, and signal characteristic testing.

[0140] Readability refers to its ability to support human reading through text formatting and automatic machine parsing through grammatical rules.

[0141] Step 212: Extract test vectors, timing parameters, and signal parameters from the standard test description file.

[0142] In some embodiments, the standard test description file can be parsed to obtain test vectors, timing parameters, and signal parameters.

[0143] Syntax parsing refers to the automated process of using parsing tools to perform text recognition, rule verification, and information extraction on standard test description files. Its core is based on the syntax rules of the standard test interface language, such as keyword definitions and parameter nesting formats, to transform unstructured text in the file into recognizable structured data, and finally extract core test parameters, including test vectors, timing parameters, and signal parameters.

[0144] In some embodiments, the specific logic of the parsing process includes file format verification, keyword recognition, and parameter extraction.

[0145] File format validation is used to check whether a file conforms to standard syntax rules, such as correct keyword spelling and matching parameter brackets. If a format error is found, an error message is returned.

[0146] Keyword recognition is used to locate text paragraphs in a file that record core parameters using a pre-defined keyword library.

[0147] Parameter extraction is used to strip redundant text, such as annotations and formatting marks, from the located paragraphs and extract specific parameter values.

[0148] The test vector is the input signal value used to drive the input port of the first chip, and it is the most critical execution basis in the test requirements.

[0149] Timing parameters are quantitative indicators that define the time relationship between signal interactions during testing, ensuring that the chip is driven and verified under preset time constraints. Their core function is to simulate the actual working timing environment of the chip.

[0150] The timing parameters specifically include at least one of the following parameters: clock mid-term, signal setup time, and signal hold time.

[0151] The clock period is used to indicate the period length of the test clock signal and defines the time base for signal transmission; the signal setup time is used to indicate the minimum time that the input signal must remain stable before the clock edge to ensure that the signal is correctly sampled by the chip; the signal hold time is used to indicate the minimum time that the input signal must remain stable after the clock edge to avoid sampling errors caused by signal transitions.

[0152] Signal parameters are a set of parameters that describe the physical and logical properties of all signals involved in the test process, and are used to ensure that the test signals are compatible with the interface characteristics of the first chip.

[0153] The signal parameters specifically include at least one of the following: signal name, signal type, signal direction, signal bit width, and level standard.

[0154] The signal name is a unique identifier for the signal, used to distinguish signals with different functions; the signal type indicates the electrical or logic type of the signal, such as "digital signal," "analog signal," "differential signal," "single-ended signal," etc.; the signal direction indicates the direction of signal transmission between the test system and the chip, such as "input," "output," "bidirectional," where the input signal is sent from the test system to the chip, and the output signal is sent from the chip to the test system; the signal bit width is the number of binary bits in the digital signal; the level standard indicates the voltage range of the signal, ensuring that the electrical characteristics of the test signal are compatible with the chip interface.

[0155] Step 213: Generate structured description data based on test vectors, timing parameters, and signal parameters.

[0156] Optionally, the structured description data includes a set of test vectors, a set of timing constraints, and a set of signal attributes.

[0157] The test vector set includes at least two test vectors. The test vectors are used to drive the first chip. The test vectors correspond to expected results. The prediction results are used to provide a reference for the test results obtained by the first chip based on the test vectors.

[0158] The timing constraint set is used to indicate the timing parameters when testing the first chip. The timing parameters include at least one of clock cycle, signal setup time, and signal hold time.

[0159] The signal attribute set is used to indicate the signal parameters when testing the first chip. The signal parameters include at least one of the following: signal name, signal type, and signal direction.

[0160] This is illustrative; please refer to it. Figure 5 , Figure 5 This is a flowchart illustrating a file parsing process provided in an exemplary embodiment of this application, such as... Figure 5As shown, the parsing process for the standard test description file includes: Step 501, input STIL file; Step 502, syntax analysis; Step 503, determine compliance, if compliant, proceed to Step 504, otherwise proceed to Step 505; Step 504, data extraction; Step 505, generate error report; Step 506, data caching; Step 507, output test data.

[0161] The method provided in this application clearly divides the structured description data into test vector sets, timing constraint sets, and signal attribute sets, and refines the core parameters of the sets, realizing the classification, storage, and association binding of test requirements. Based on this structured division, the test data is clear and organized, which not only facilitates the accurate extraction of required parameters from the environment template, but also ensures the consistency between the test logic and the original requirements, avoiding confusion or omissions.

[0162] In summary, the method provided in this application, by parsing standard test description files, generates structured description data that is independent of the hardware platform, thereby removing the original test file's format dependency on a specific toolchain, which can improve data parsing efficiency and chip testing efficiency.

[0163] In some embodiments, after parsing the structured description data, a verification environment can be automatically generated to drive the testing of the first chip. The environment template includes a test stimulus generation template and a test result comparison template. Please refer to... Figure 6 , Figure 6 This is a flowchart illustrating an automatic generation method for a verification environment provided in an exemplary embodiment of this application. This method can be executed by a terminal, a server, or both simultaneously. This embodiment uses terminal execution as an example for illustration. Figure 6 As shown, step 220 above includes the following steps:

[0164] Step 221: Inject structured description data into the test stimulus generation template and test result comparison template to generate test stimulus code and test comparison code.

[0165] The test stimulus code is used to drive the test of the first chip based on the test-driven logic, and the test comparison code is used to generate chip test results based on the test result comparison logic.

[0166] In some implementations, it is necessary to first obtain an environment template that includes a test stimulus generation template and a test result comparison template.

[0167] An environment template is a predefined, standardized test logic program framework stored in a template library of computer devices. Its design goal is to achieve rapid instantiation of the test environment through "general logic encapsulation + parameter interface reservation".

[0168] When acquiring an environment template, the system can automatically match the corresponding environment template based on the type of the first chip (such as a digital chip or a mixed-signal chip) or the test scenario (such as functional testing or timing testing), such as "general test template for digital chips" or "specific test template for high-speed interfaces".

[0169] The core components of the environment template include the test stimulus generation template and the test result comparison template.

[0170] The test stimulus generation template is a program framework used to carry test-driven logic. Its core function is to define the general process of how to send test signals to the first chip. After injecting parameters, it can generate specific signal-driven code (i.e., test stimulus code).

[0171] In some embodiments, the test stimulus generation template encapsulates the basic process of signal transmission, such as signal initialization, vector sequence loading, timing control, and signal output, to ensure the standardization of stimulus transmission.

[0172] For test stimulus generation templates, parameter injection can be achieved by reserving input slots corresponding to structured description data. For example, the test vector interface is used to receive the input vector sequence in the test vector set, the timing parameter interface is used to receive parameters such as clock period, signal setup time, and signal hold time in the timing constraint set, and the signal attribute interface is used to receive parameters such as signal name, direction, and bit width in the signal attribute set.

[0173] The test result comparison template is a program framework used to carry the test result comparison logic. Its core function is to define the general process of how to collect and verify the output signal of the first chip. After parameter injection, it can generate specific result verification code (i.e. test comparison code).

[0174] In some embodiments, the basic process of test result comparison template encapsulation result verification, such as expected result storage, real-time signal acquisition, comparison rule execution, and result recording, ensures the consistency of the verification logic.

[0175] For the test result comparison template, parameters can be injected by reserving input slots corresponding to the structured description data. For example, the expected result interface is used to receive the expected output vector (i.e., the expected result) in the test vector set, the acquisition configuration interface is used to receive parameters such as the output signal name, bit width, and sampling timing in the signal attribute set, and the comparison rule interface is used to receive the judgment criteria in the structured description data, such as "complete match passed" and "analog signal allows ±5% error".

[0176] It is worth noting that the above-mentioned environment template types and corresponding parameter injection methods are merely illustrative examples, and the embodiments of this application do not limit them.

[0177] For the parameter injection process of the test stimulus module (test stimulus code), the input signal parameters in the signal attribute set of the structured description data can be injected into the signal attribute interface of the test stimulus generation template to generate specific signal definition code; the clock period, setup time, hold time and other parameters of the timing constraint set in the structured description data can be injected into the timing parameter interface of the test stimulus generation template to generate timing control code; and the input vectors of the test vector set in the structured description data can be injected sequentially into the test vector interface of the test stimulus generation template to generate stimulus sending code.

[0178] For the parameter injection process of the test comparison module (test comparison code), the output signal parameters of the signal attribute set in the structured description data can be injected into the acquisition configuration interface of the test result comparison module to generate signal acquisition code; the expected output vector of the test vector set in the structured description data can be injected into the expected result interface of the test result comparison template to generate expected result storage code; and the judgment criteria in the structured description data can be injected into the comparison rule interface of the test result comparison module to generate result verification code.

[0179] Step 222: Assemble the test stimulus code and test comparison code to obtain the verification environment.

[0180] In some embodiments, after the test stimulus module and the test comparison module complete parameter injection, a mapping between the output of the test stimulus module and the input interface of the first chip, and a mapping between the output interface of the first chip and the test comparison module can be established to realize signal link connection, ensure the integrity of signal transmission path, and generate a verification environment including the test stimulus module and the test comparison module.

[0181] This is illustrative; please refer to it. Figure 7 , Figure 7 This is a flowchart illustrating the verification environment generation process provided in an exemplary embodiment of this application, such as... Figure 7 As shown, the verification environment generation process includes: Step 701, the parsing engine sends JTAG timing data to the Testbench generator; Step 702, the Testbench generator requests a JTAG timing template from the JTAG timing template library; Step 703, the JTAG timing template library returns the timing template to the Testbench generator; Step 704, the Testbench generator injects timing parameters, such as the test clock (TCK) period and the test mode select (TMS) edge; Step 705, the Testbench generator generates the top-level interface monitoring code; Step 706, the Testbench generator outputs the JTAG Testbench, resulting in the generated Testbench, i.e., the verification environment.

[0182] The method provided in this application breaks down the generation of the verification environment into two steps: modular code generation and standardized assembly. This allows the test stimulus code to focus on the chip driver logic and the test comparison code to focus on the result verification logic. The two are combined to form a complete test logic, which not only ensures the independence of the functions of each module, but also achieves seamless collaboration through standardized interfaces. The final generated verification environment is both targeted (matching the requirements of the first chip) and complete (covering the entire process of driver and comparison).

[0183] In summary, the method provided in this application, based on parameter injection, can automatically generate a verification environment without the need for manual test code writing. It achieves automatic template instantiation driven by structured data, improving the efficiency of verification environment generation. Furthermore, the test logic is entirely generated based on structured description data, avoiding requirement deviations caused by manual coding. The environment template can be applied to different chip tests, and a new verification environment can be generated simply by replacing the structured data, reducing maintenance costs and improving the chip testing efficiency of automatically generating verification environments based on parameter injection.

[0184] In some embodiments, it is necessary to integrate the verification environment and the first chip to obtain a hardware executable file for running on a hardware emulation platform. Please refer to [reference needed]. Figure 8 , Figure 8 This is a flowchart of a chip testing method based on a hardware executable file provided in an exemplary embodiment of this application. This method can be executed by a terminal, a server, or both simultaneously. This embodiment illustrates the method executed by a terminal as an example. Figure 8 As shown, step 230 above includes:

[0185] Step 231: Integrate the verification environment and the first chip to generate the hardware executable file.

[0186] Hardware execution files are used to express chip test logic in a hardware description language.

[0187] Integration refers to building a test system that can work together with the verification environment (i.e., test logic program) and the first chip (i.e. test object) through physical connection and logical adaptation. Its core objective is to ensure that test signals can be transmitted stably between the two.

[0188] The process of generating the hardware executable file includes connecting the verification environment to the test interface of the first chip and compiling it to obtain the hardware executable file.

[0189] In some embodiments, it is necessary to logically bind the signal ports of the verification environment, such as the excitation output terminal and the result acquisition terminal, to the test interfaces of the first chip, such as the input pins and the output pins, so as to drive the test of the first chip based on the verification environment.

[0190] The hardware executable file is a binary file that integrates the test logic of the verification environment with the interface characteristics of the first chip and is compiled into a file that can be run directly on the hardware simulation platform. It is the carrier that transforms the test logic from software description into hardware executable operation. Its essence is a composite of "test logic code + test data". It can be recognized and executed by the hardware simulation platform and can accurately adapt to the interface timing and signal characteristics of the first chip to realize automated driving and result verification of the chip.

[0191] The hardware execution file includes test logic code and test data. The test logic code is used to instruct the chip test logic, and the test data includes test vectors and expected results.

[0192] Test logic code is a set of binary instructions that can be directly executed by the hardware. It encapsulates the test logic in the verification environment and is used to control the timing, signal interaction and result judgment of the test process. For example, it includes stimulus driving logic, result acquisition and comparison logic, timing control logic, exception handling logic, etc.

[0193] Test data is a static data block in the hardware execution file, which stores the specific parameters (i.e., test vectors) required for the test and the expected standards (i.e., expected results).

[0194] Hardware executable files are the key link between software logic and hardware execution. Through compilation and transformation, abstract verification environment code is converted into hardware-executable instructions, solving the problem that software descriptions cannot directly drive physical chips.

[0195] In this embodiment of the application, the chip testing method provided in this embodiment is executed by a hardware simulation device, which integrates the verification environment and the first chip into the hardware simulation platform and compiles and generates a hardware executable file. The hardware executable file is a code file that can be directly executed in the hardware simulation platform.

[0196] Step 232: Run the hardware executable file to generate chip test results.

[0197] In this embodiment of the application, the chip testing method provided in this embodiment is executed by a hardware simulation device. After integrating the verification environment and the first chip into the hardware simulation platform to obtain the hardware executable file, the hardware executable file is run directly in the hardware simulation platform to generate the chip test results of the first chip.

[0198] In some embodiments, the chip test results are obtained by comparing the test results of the first chip obtained by testing it with the expected results based on structured description data.

[0199] The testing process includes loading the hardware executable file, testing the first chip based on the test-driven logic indicated by the hardware executable file, comparing the test results obtained by the first chip based on the test vector with the expected results based on the test result comparison logic indicated by the hardware executable file, and generating chip test results based on the comparison results.

[0200] This is illustrative; please refer to it. Figure 9 , Figure 9 This is a schematic diagram of the top-level design for chip testing provided in an exemplary embodiment of this application, such as... Figure 9 As shown, the test stimulus module 910 drives the test of the first chip, and the test comparison module 920 compares the test results of the first chip with the expected results to generate chip test results.

[0201] During environment integration, the Testbench and the first chip's top-level DUT are instantiated in `hw_top`. The `atpg_dft_top` interface is connected to the DUT's instantiated interface of the same name. Because `atpg_dft_top` is generated based on the module-matched *.stil file, all signals in `atpg_dft_top` have matching signals in the module. During compilation and loading, the Device Under Test (DUT) and Testbench interface are integrated and compiled to generate a Database. After the Database is compiled, it is loaded onto the Emulator via the `palladium xeDebug` command. During accelerated simulation and monitoring, the Testdata is loaded into the Testbench's vector memory via the `Memory -load` command, then released and reset, and the simulation is started. The Testbench driver drives the test vectors to the DUT's top-level interface. The Testbench checker compares the Testdata (golden data) with the output response transmitted from the DUT to the Testbench. If the comparison values ​​are the same, the test vector passes; if the comparison values ​​are different, the test vector is abnormal, and an exception is printed, which is output to the `xeDebug` interface.

[0202] The method provided in this application ensures accurate mapping between the signals of the verification environment and the physical pins of the chip through interface connection. By compiling, the interface adaptation logic and test logic are integrated into a hardware executable form, thus eliminating the interface barrier between the verification environment and the chip and ensuring stable transmission of test signals. At the same time, the test execution efficiency is improved through compilation optimization, avoiding test errors caused by signal delay or conflict.

[0203] The method provided in this application clearly divides the hardware executable file into test logic code and test data, so that the test logic code can be reused to adapt to different chips, while the test data can be updated independently. This reduces the complexity of file generation and facilitates the expansion of subsequent test scenarios.

[0204] If the test results meet the verification conditions, a first comparison result is obtained, which indicates that the first chip passes the test based on the test vector; if the test results do not meet the verification conditions, a second comparison result is obtained, which indicates that the first chip fails the test based on the test vector.

[0205] Verification conditions are pre-set criteria for determining whether a test passes or fails. They are the core of the comparison logic and essentially define the range within which the actual test results and the predicted results match.

[0206] Optionally, the verification conditions can be dynamically determined based on the chip type, test scenario, etc., and this application embodiment does not limit this.

[0207] The method provided in this application ensures the correct deployment of test logic by loading hardware execution files, drives the test to achieve precise stimulation of the chip, realizes automated verification of comparison results, and finally generates results to complete the transformation from raw data to conclusions, thereby achieving full automation of test execution and improving test efficiency.

[0208] The method provided in this application embodiment intuitively reflects the correctness of the chip function through the first comparison result, and accurately records the details of mismatch through the second comparison result. Both of them not only clarify the conclusion of the single-vector test, but also provide raw data for subsequent statistical analysis.

[0209] In some embodiments, test statistics are generated based on the comparison results, and chip test results are generated based on the test statistics.

[0210] Optionally, the test statistics include at least one of test coverage, error records, and pass rate. Test coverage is used to indicate the degree to which the test vector covers the functionality of the first chip. Error records are used to indicate test information of the first chip that failed the test based on the test vector. Pass rate is used to indicate the proportion of the first chip that passed the test based on the test vector.

[0211] The method provided in this application, by generating test statistics such as test coverage, error records, and pass rates, and then generating chip test results based on these data, achieves a leap from a single comparison result to a comprehensive performance evaluation. Test coverage reflects the comprehensiveness of the test, error records pinpoint specific problems, and the pass rate quantifies the overall performance. These data together constitute a multi-dimensional evaluation of the first chip's performance, which can improve the efficiency of test evaluation.

[0212] In summary, the method provided in this application, through the process of integrating the verification environment with the first chip, generating a hardware executable file, and generating results from the running file, transforms the abstract verification environment into test logic (hardware executable file) that can be directly executed on the hardware platform. The integration process ensures that the verification environment and the chip interface are in place, and the generation of the hardware executable file enables the test logic to be implemented as physical electrical signals, thereby improving the authenticity and reliability of the test results.

[0213] In this embodiment, a self-developed Python script parsing tool is used to load the STIL file, parse it to generate Verilog, and then integrate the Testbench (extracting test vectors, timing information, and test cycle data from the STIL file description) and Testdata (test data). The generated Testbench is then integrated with the design into the Palladium accelerator for compilation and database processing. Tests are then loaded and executed, test results are collected, and the correctness or failure of the tests is determined based on the test results.

[0214] The chip testing method provided in this application mainly includes a STIL file processing module, a Testbench automatic generation module, and a Palladium accelerated verification module.

[0215] The STIL file processing module uses a Python parsing tool to read STIL format test vector files, extract key information such as test vector data, timing parameters, and test cycle count, and generate structured intermediate data. It supports the Institute of Electrical and Electronics Engineers (IEEE) 1450 standard and can recognize Pattern blocks (test vectors), Timing blocks (timing constraints), and Signals blocks (signals and signal input / output (IO) attributes), extracting vector data from the Pattern blocks to generate Testdata.

[0216] The Testbench auto-generation module generates synthesizable Verilog Testbench based on parsed Pattern blocks (test vectors), Timing blocks (timing constraints), Signals blocks (signals and signal I / O attributes), and integrates clock-driven, vector loading, and response capture functions.

[0217] The Python parsing tool injects parameters parsed in STIL into the template using Python string replacement to automatically generate a Testbench. Specifically, it can include a clock module and a vector-driven module, where the clock module generates clock signals based on timing blocks, and the vector-driven module generates vector-driven logic.

[0218] The Palladium accelerated verification module is used to perform chip testing. It integrates the Testbench and the Design Under Test (DUT) into the Palladium hardware emulator, enabling hardware acceleration and real-time monitoring of test vectors. The top-level design is as shown above. Figure 9 As shown.

[0219] 1. Environment integration.

[0220] (a) Instantiate atpg_dft_top and the top-level DUT of the chip to be verified in hw_top.

[0221] (b) Connect the atpg_dft_top interface to the DUT instantiated interface of the same name. Since atpg_dft_top is generated based on the *.stil file matched by the module, the signals of atpg_dft_top have matching signals in the module.

[0222] 2. Compilation and loading.

[0223] (a) After integrating the DUT and Testbench interface, compile to generate the Database.

[0224] (b) The results of the Database compilation are loaded onto the Emulator via the palladium xeDebug command.

[0225] 3. Accelerate simulation and monitoring.

[0226] (a) Load Testdata into the vector memory in Testbench using the Memory-load instruction, release and reset, start simulation, and Testbench driver drives the test vector to the top-level interface of DUT.

[0227] (b) The Testbench checker compares the Testdata golden data with the output response transmitted by the DUT to the Testbench. If the comparison values ​​are the same, the test vector passes; if the comparison values ​​are different, the test vector is abnormal, and an exception is triggered and printed to the xeDebug interface.

[0228] This is illustrative; please refer to it. Figure 10 , Figure 10This is a schematic diagram of a chip testing framework provided in an exemplary embodiment of this application, such as... Figure 10 As shown, the chip testing method provided in this application includes the following steps: Step 1001, obtaining the STIL file; Step 1002, parsing the STIL file, i.e., obtaining structured description data by parsing the STIL file through the STIL parsing engine; Step 1003, extracting test data; Step 1004, obtaining the environment template, i.e., using a Testbench generator; Step 1005, generating the verification environment, i.e., obtaining the AXI / APB Testbench code; Step 1006, obtaining the design netlist; Step 1007, integrating the verification environment and the first chip, for example, using the Palladium integration module; Step 1008, generating the hardware execution file, i.e., using an accelerated simulation environment; Step 1009, running the hardware execution file, i.e., test execution and monitoring; Step 1010, obtaining test results; Step 1011, error analysis and defect location.

[0229] The tools and environment configurations used in the embodiments of this application are illustrated below:

[0230] Parsing tool: Python parsing tool;

[0231] Input file: STIL format ATPG test vector file (compliant with IEEE 1450 standard);

[0232] Output files: Verilog can synthesize Testbench and binary test data Testdata.

[0233] For details on the internal processes of the STIL parsing engine, please refer to... Figure 5 In STIL syntax parsing, information such as test vectors, timing constraints, and signal mappings in the STIL file are analyzed to construct internal data structures. For example, test vector data is extracted through the Pattern block, and the state changes of the WaveformTable block in different periods are parsed through the Timing block, along with the waveform definitions in the Period and Waveforms blocks within the same period. Test vectors, timing information, and test period data are extracted from the parsing results and converted into a format loadable by the Palladium accelerator.

[0234] In some embodiments, the Testbench generation process can be referenced. Figure 7 The driving generation logic can include state machine generation logic, vector data driving module generation logic, signal verification generation logic, and test result report generation logic.

[0235] To accelerate simulation and monitoring, the generated testbench and design are integrated into the Palladium accelerator to optimize compilation and execution efficiency. Please refer to [link / reference needed]. Figure 11 , Figure 11 This is an accelerated testing flowchart provided by an exemplary embodiment of this application, such as... Figure 11 As shown, Step 1101: Obtain Testbench code; Step 1102: Obtain design netlist; Step 1103: Compile Palladium; Step 1104: Simulation image; Step 1105: Test execution; Step 1106: Real-time monitoring; Step 1107: Test log; Step 1108: Error analysis; Step 1109: Defect localization.

[0236] The tools and environment configuration are as follows:

[0237] Simulation platform: Palladium hardware emulator (including ICE Flow toolchain);

[0238] Input files: chip netlist, Verilog synthesizable testbench, testdata binary file;

[0239] Output: Simulation log (xeDebug.log), test pass / fail flags.

[0240] Regarding the compilation and loading process, the database is first compiled using Palladium ICE Flow to compile the chip netlist and Testbench; to accelerate simulation execution, Palladium simulation is started, the compiled database is loaded, and the vector memory test data Testdata in Testbench is placed; the test execution process is controlled, the test results are collected and analyzed, and specific test pass or fail can be output, such as the number of test vectors that passed or failed.

[0241] The method provided in this application supports multiple versions of the STIL standard through an STIL parsing engine; it implements an efficient method for extracting and converting test vectors and timing information. It also includes a template-based hardware-accelerated test platform generation method; employing adaptive interface adaptation technology, it achieves automatic testbench generation. Through Palladium accelerator optimization integration, it implements an efficient method for partitioning and parallel execution of test vectors on the hardware accelerator; it enables incremental compilation and caching mechanisms to improve iteration efficiency. Finally, it provides a test execution and monitoring system, implementing real-time anomaly detection and test progress tracking methods.

[0242] In summary, the method provided in this application reduces manual intervention, shortens the test preparation cycle, and improves test efficiency through automated parsing and testbench generation; it also enhances test execution speed by efficiently utilizing the Palladium accelerator. It eliminates dependence on third-party STIL parsing tools, saving on tool licensing fees; it reduces manual coding workload and lowers labor costs. It supports custom test sequences and special protocols, adapting to diverse testing needs; it is easily extended with new STIL syntax features and accelerator functionality, enhancing flexibility and scalability. The automatically generated testbench exhibits high consistency, reducing human error; comprehensive coverage analysis and anomaly detection improve defect detection rates and enhance test quality.

[0243] Figure 12 This is a structural block diagram of a chip testing apparatus provided in an exemplary embodiment of this application, as shown below. Figure 12 As shown, the device includes the following parts:

[0244] Processing module 1210 is used to obtain structured description data based on the standard test description file of the first chip, wherein the standard test description file is used to describe the test requirements of the first chip;

[0245] The processing module 1210 is further configured to inject the structured description data into an environment template to obtain a verification environment, wherein the verification environment is a program for carrying chip test logic, and the environment template is a preset test logic program framework.

[0246] The test module 1220 is used to drive the test of the first chip based on the verification environment and obtain the chip test results.

[0247] In some embodiments, the processing module 1210 is further configured to:

[0248] Obtain the standard test description file;

[0249] The test vector, timing parameters, and signal parameters are extracted from the standard test description file. The test vector is used to drive the test of the first chip, the timing parameters are used to constrain the signal interaction timing when testing the first chip, and the signal parameters are used to indicate the test signal attributes.

[0250] The structured description data is generated based on the test vector, the timing parameters, and the signal parameters.

[0251] In some embodiments, the structured description data includes a set of test vectors, a set of timing constraints, and a set of signal attributes;

[0252] The test vector set includes at least two test vectors, each test vector corresponding to an expected result. The expected result is used to provide a reference for the test result output by the first chip based on the test vector.

[0253] The timing constraint set is used to indicate the timing parameters when testing the first chip, and the timing parameters include at least one of clock cycle, signal setup time, and signal hold time.

[0254] The signal attribute set is used to indicate the signal parameters when testing the first chip, and the signal parameters include at least one of signal name, signal type, and signal direction.

[0255] In some embodiments, the environment template includes a test stimulus generation template and a test result comparison template;

[0256] The processing module 1210 is further configured to:

[0257] The structured description data is injected into the test stimulus generation template and the test result comparison template to generate test stimulus code and test comparison code;

[0258] The verification environment is obtained by assembling the test stimulus code and the test comparison code. The test stimulus code is used to drive the test of the first chip based on the test driving logic, and the test comparison code is used to generate the chip test results based on the test result comparison logic.

[0259] In some embodiments, the test module 1220 is further configured to:

[0260] Integrate the verification environment and the first chip to generate a hardware execution file, which is used to express the chip test logic in a hardware description language;

[0261] Run the hardware executable file to generate the chip test results.

[0262] In some embodiments, the test module 1220 is further configured to connect the verification environment to the test interface of the first chip and compile the hardware executable file.

[0263] In some embodiments, the hardware executable file includes test logic code and test data;

[0264] The test logic code is used to instruct the chip test logic;

[0265] The test data includes test vectors and expected results;

[0266] The test module 1220 is also used for:

[0267] Load the hardware executable file;

[0268] The test driver logic, as indicated by the hardware execution file, drives the test of the first chip.

[0269] Based on the test result comparison logic indicated by the hardware execution file, the test result obtained by the first chip based on the test vector is compared with the expected result to obtain the comparison result.

[0270] The chip test results are generated based on the comparison results.

[0271] In some embodiments, the test module 1220 is further configured to:

[0272] If the test result meets the verification conditions and the expected result, a first comparison result is obtained. The first comparison result is used to indicate that the first chip passes the test based on the test vector.

[0273] If the test result does not meet the verification conditions as expected, a second comparison result is obtained, which is used to indicate that the first chip has failed the test based on the test vector.

[0274] In some embodiments, the test module 1220 is further configured to:

[0275] Test statistics are generated based on the comparison results. The test statistics include at least one of test coverage, error records, and pass rate. The test coverage is used to indicate the degree to which the test vector covers the function of the first chip. The error records are used to indicate the test information of the first chip that failed the test based on the test vector. The pass rate is used to indicate the proportion of the first chip that passed the test based on the test vector.

[0276] The chip test results are generated based on the test statistics.

[0277] In summary, the apparatus provided in this application automatically generates a verification environment by injecting structured description data obtained from parsing standard test description files into an environment template. This not only generates hardware-platform-independent structured description data by parsing standard test description files, eliminating the original test files' format dependency on specific toolchains, but also adapts to the testing needs of different chips based solely on the parameter injection of structured description data, using an environment template encapsulated with general test logic. Furthermore, the generated verification environment conforms to the general specifications of hardware description languages, can be recognized and compiled by various hardware simulation platforms, and is not limited by specific toolchains or hardware platforms. This improves the flexibility of cross-platform integration, enables a fully automated chip testing process, eliminates the need for manual adjustments to the verification environment to adapt to hardware simulation platforms, reduces testing costs, and improves chip testing efficiency.

[0278] It should be noted that the chip testing device provided in the above embodiments is only an example of the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0279] Figure 13 This illustration shows a structural block diagram of a terminal 1300 provided in an exemplary embodiment of this application. The terminal 1300 may be a smartphone, tablet computer, MP3 player, MP4 player, laptop computer, or desktop computer. The terminal 1300 may also be referred to as user equipment, portable terminal, laptop terminal, desktop terminal, or other names.

[0280] Typically, terminal 1300 includes a processor 1301 and a memory 1302.

[0281] Processor 1301 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 1301 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). Processor 1301 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1301 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 1301 may also include an Artificial Intelligence (AI) processor, which is used to handle computational operations related to machine learning.

[0282] The memory 1302 may include one or more computer-readable storage media, which may be non-transitory. The memory 1302 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1302 are used to store at least one instruction, which is executed by the processor 1301 to implement the chip testing method provided in the method embodiments of this application.

[0283] In some embodiments, the terminal 1300 also includes other components 1303, as those skilled in the art will understand. Figure 13 The structure shown does not constitute a limitation on terminal 1300 and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0284] Embodiments of this application also provide a computer device that can be implemented as follows: Figure 1 The computer device shown is such as a terminal or server. This computer device includes a processor and a memory, the memory storing at least one instruction, at least one program, code set, or instruction set. The processor loads and executes the at least one instruction, at least one program, code set, or instruction set to implement the chip testing methods provided in the above-described method embodiments.

[0285] Embodiments of this application also provide a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by a processor to implement the chip testing method provided in the above-described method embodiments.

[0286] Embodiments of this application also provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the chip testing methods provided in the above-described method embodiments.

[0287] Optionally, the computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), solid-state drives (SSDs), or optical discs, etc. The random access memory may include resistive random access memory (ReRAM) and dynamic random access memory (DRAM). The sequence numbers of the embodiments in this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0288] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0289] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A chip testing method, characterized in that, The method includes: Structured description data is obtained based on the standard test description file of the first chip. The standard test description file is used to describe the test requirements of the first chip, and the structured description data is used to express the test requirements of the first chip in structured data. The structured description data is injected into the environment template to obtain a verification environment. The verification environment is a program used to carry chip test logic. The environment template is a preset test logic program framework. The parameters in the structured description data are filled into the corresponding positions of the environment template according to preset rules. The structured description data and the environment template are combined to form an executable test program. The first chip is tested based on the verification environment, and the chip test results are obtained.

2. The method according to claim 1, characterized in that, The standard test description file based on the first chip yields structured description data, including: Obtain the standard test description file; The test vector, timing parameters, and signal parameters are extracted from the standard test description file. The test vector is used to drive the test of the first chip, the timing parameters are used to constrain the signal interaction timing when testing the first chip, and the signal parameters are used to indicate the test signal attributes. The structured description data is generated based on the test vector, the timing parameters, and the signal parameters.

3. The method according to claim 2, characterized in that, The structured description data includes a set of test vectors, a set of timing constraints, and a set of signal attributes; The test vector set includes at least two test vectors, each test vector corresponding to an expected result. The expected result is used to provide a reference for the test result output by the first chip based on the test vector. The timing constraint set is used to indicate the timing parameters when testing the first chip, and the timing parameters include at least one of clock cycle, signal setup time, and signal hold time. The signal attribute set is used to indicate the signal parameters when testing the first chip, and the signal parameters include at least one of signal name, signal type, and signal direction.

4. The method according to any one of claims 1 to 3, characterized in that, The environment template includes a test stimulus generation template and a test result comparison template; The step of injecting the structured description data into the environment template to obtain the verification environment includes: The structured description data is injected into the test stimulus generation template and the test result comparison template to generate test stimulus code and test comparison code; The verification environment is obtained by assembling the test stimulus code and the test comparison code. The test stimulus code is used to drive the test of the first chip based on the test driving logic, and the test comparison code is used to generate the chip test results based on the test result comparison logic.

5. The method according to any one of claims 1 to 3, characterized in that, The process of driving the test of the first chip based on the verification environment to obtain chip test results includes: Integrate the verification environment and the first chip to generate a hardware execution file, which is used to express the chip test logic in a hardware description language; Run the hardware executable file to generate the chip test results.

6. The method according to claim 5, characterized in that, The process of integrating the verification environment and the first chip to generate a hardware execution file includes: The verification environment is connected to the test interface of the first chip, and the hardware executable file is compiled.

7. The method according to claim 5, characterized in that, The hardware execution file includes test logic code and test data; the test logic code is used to instruct the chip test logic; the test data includes test vectors and expected results. The process of running the hardware executable file and generating the chip test results includes: Load the hardware executable file; The test driver logic, as indicated by the hardware execution file, drives the test of the first chip. Based on the test result comparison logic indicated by the hardware execution file, the test result obtained by the first chip based on the test vector is compared with the expected result to obtain the comparison result. The chip test results are generated based on the comparison results.

8. The method according to claim 7, characterized in that, The test result comparison logic based on the hardware execution file instruction compares the test result obtained by the first chip based on the test vector with the expected result to obtain the comparison result, including: If the test result meets the verification conditions and the expected result, a first comparison result is obtained. The first comparison result is used to indicate that the first chip passes the test based on the test vector. If the test result does not meet the verification conditions as expected, a second comparison result is obtained, which is used to indicate that the first chip has failed the test based on the test vector.

9. The method according to claim 7, characterized in that, The process of generating the chip test results based on the comparison results includes: Test statistics are generated based on the comparison results. The test statistics include at least one of test coverage, error records, and pass rate. The test coverage is used to indicate the degree to which the test vector covers the function of the first chip. The error records are used to indicate the test information of the first chip that failed the test based on the test vector. The pass rate is used to indicate the proportion of the first chip that passed the test based on the test vector. The chip test results are generated based on the test statistics.

10. A chip testing device, characterized in that, The device includes: The processing module is used to obtain structured description data based on the standard test description file of the first chip. The standard test description file is used to describe the test requirements of the first chip, and the structured description data is used to express the test requirements of the first chip in structured data. The processing module is further configured to inject the structured description data into an environment template to obtain a verification environment. The verification environment is a program used to carry chip test logic. The environment template is a preset test logic program framework. The parameters in the structured description data are filled into the corresponding positions of the environment template according to preset rules. The structured description data and the environment template are combined to form an executable test program. The testing module is used to drive the testing of the first chip based on the verification environment and obtain the chip test results.

11. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing at least one computer program, which is loaded and executed by the processor to implement the chip testing method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The storage medium stores at least one computer program, which is loaded and executed by a processor to implement the chip testing method as described in any one of claims 1 to 9.

13. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the chip testing method as described in any one of claims 1 to 9.

Images