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

Abstract

The invention discloses a chip testing method and device, equipment, a storage medium and a program product. The method comprises the steps of 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 a test requirement of the first chip; the structured description data is injected into an environment template to obtain a verification environment, the verification environment is a program used for bearing chip test logic, and the environment template is a preset test logic program framework; the first chip is driven and tested based on the verification environment, the chip test result is obtained, the test requirements of different chips can be met only through parameter injection of the structured description data, the full-automatic chip test process can be achieved, and the chip test efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, and particularly relates to a chip testing method and device, equipment, a storage medium and a program product. BACKGROUND

[0002] In the chip design and mass production process, chip testing is a key link to ensure the correctness of its functions and the stability of its performance. By applying specific test vectors and monitoring output responses, it can be verified whether the chip meets the design specifications and avoid the loss caused by defective chips flowing into the market.

[0003] In the related art, chip testing is mostly dependent on manual writing of test platform code or on specific vendor closed tool chains: first, an Automatic Test Pattern Generation (ATPG) tool is used to generate a Standard Test Interface Language (STIL) file, and then an engineer manually converts the test vectors and timing parameters in the file into a hardware description language test environment, or uses a tool chain to synchronously generate a test file and a verification model, and finally executes the test on a hardware simulation platform.

[0004] However, the verification model generated by the closed tool chain has poor adaptability and cannot be flexibly integrated into different hardware simulation platforms, resulting in high testing cost and low testing efficiency. SUMMARY

[0005] Embodiments of the present application provide a chip testing method, device, equipment, storage medium and program product. The technical solution is as follows.

[0006] In one aspect, a chip testing method is provided, and the method comprises: obtaining structured description data based on a standard test description file of a first chip, the standard test description file being used to describe test requirements of the first chip; injecting the structured description data into an environment template to obtain a verification environment, the verification environment being a program used to carry chip testing logic, and the environment template being a preset test logic program framework; driving the first chip for testing based on the verification environment, to obtain a chip testing result.

[0007] In another aspect, a chip testing device is provided, and the device comprises: a processing module configured to obtain structured description data based on a standard test description file of a first chip, the standard test description file being used to describe test requirements of the first chip; The processing module is further configured to inject the structured description data into an environment template to obtain a verification environment, the verification environment being a program for carrying chip test logic, and the environment template being a preset test logic program framework. The test module is configured to drive a test of the first chip based on the verification environment to obtain a chip test result.

[0008] In some embodiments, the processing module is further configured to: obtain the standard test description file; extract a test vector, a timing parameter, and a signal parameter from the standard test description file, the test vector being used to drive a test of the first chip, the timing parameter being used to constrain a timing of signal interaction when testing the first chip, and the signal parameter being used to indicate a test signal attribute; generate the structured description data based on the test vector, the timing parameter, and the signal parameter.

[0009] In some embodiments, the structured description data includes a test vector set, a timing constraint set, and a signal attribute set; the test vector set includes at least two test vectors, and the test vectors correspond to expected results used to provide a reference for a test result output by the first chip based on the test vectors; the timing constraint set is used to indicate a timing parameter when testing the first chip, and the timing parameter includes at least one of a clock period, a signal setup time, and a signal hold time; the signal attribute set is used to indicate a signal parameter when testing the first chip, and the signal parameter includes at least one of a signal name, a signal type, and a signal direction.

[0010] In some embodiments, the environment template includes a test stimulus generation template and a test result comparison template; The processing module is further configured to: inject the structured description data into the test stimulus generation template and the test result comparison template to generate test stimulus code and test comparison code; assemble the test stimulus code and the test comparison code to obtain the verification environment, the test stimulus code being used to drive a test of the first chip based on test driving logic, and the test comparison code being used to generate the chip test result based on test result comparison logic.

[0011] In some embodiments, the test module is further configured to: integrate the verification environment and the first chip to generate a hardware execution file, the hardware execution file being used to express the chip test logic in a hardware description language. running the hardware execution file to generate the chip test result.

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

[0013] In some embodiments, the hardware execution file comprises test logic code and test data. The test logic code is configured to instruct the chip test logic. The test data comprises test vectors and expected results. The test module is further configured to: load the hardware execution file; drive the first chip based on test driving logic instructed by the hardware execution file; compare a test result of the first chip based on the test vectors with expected results based on test result comparison logic instructed by the hardware execution file to obtain a comparison result; generate the chip test result based on the comparison result.

[0014] In some embodiments, the test module is further configured to: obtain a first comparison result in a case where the test result meets a verification condition of the expected result, the first comparison result being configured to indicate that the first chip passes the test based on the test vectors; obtain a second comparison result in a case where the test result does not meet the verification condition of the expected result, the second comparison result being configured to indicate that the first chip fails the test based on the test vectors.

[0015] In some embodiments, the test module is further configured to: generate test statistical data based on the comparison result, the test statistical data comprising at least one of test coverage, error record, and pass rate, the test coverage being configured to indicate a coverage degree of the test vectors on the functions of the first chip, the error record being configured to indicate test information of the first chip failing the test based on the test vectors, and the pass rate being configured to indicate a proportion of the first chip passing the test based on the test vectors; generate the chip test result based on the test statistical data.

[0016] In another aspect, a computer device is provided, which includes a processor and a memory having stored therein at least one instruction, at least one program, a code set or an instruction set, which is loaded and executed by the processor to implement the chip testing method according to any one of the above-described embodiments of the present application.

[0017] In another aspect, a computer readable storage medium is provided, which has stored therein at least one instruction, at least one program, a code set or an instruction set, which is loaded and executed by a processor to implement the chip testing method according to any one of the above-described embodiments of the present application.

[0018] In another aspect, 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 the processor executes the computer instructions to cause the computer device to perform the chip testing method according to any one of the above-described embodiments.

[0019] The technical solutions provided by the embodiments of the present application have at least the following beneficial effects: By injecting the structured description data obtained based on the standard test description file into the environment template, the verification environment is automatically generated. The structured description data independent of the hardware platform can be generated by parsing the standard test description file, which eliminates the format dependence of the original test file on the specific tool chain. The verification environment can be adapted to the test requirements of different chips based on the environment template encapsulating the general test logic only by parameter injection of the structured description data. The generated verification environment complies with the general specification of the hardware description language and can be recognized and compiled by various hardware simulation platforms, which is not limited to specific tool chains or hardware platforms. The flexibility of cross-platform integration can be improved, and the chip testing process can be fully automated without manual adjustment of the verification environment to adapt to the hardware simulation platform, which reduces the testing cost and improves the chip testing efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort.

[0021] Figure 1 is a schematic diagram of a test system provided by an exemplary embodiment of the present application; Figure 2is a flow chart of a chip testing method provided by an example embodiment of the present application; Figure 3 is a chip testing architecture diagram provided by an example embodiment of the present application; Figure 4 is a standard test description file parsing flow chart provided by an example embodiment of the present application; Figure 5 is a file parsing flow chart provided by an example embodiment of the present application; Figure 6 is a flow chart of a verification environment automatic generation method provided by an example embodiment of the present application; Figure 7 is a verification environment generation flow chart provided by an example embodiment of the present application; Figure 8 is a flow chart of a chip testing method based on hardware execution files provided by an example embodiment of the present application; Figure 9 is a chip testing top-level design schematic diagram provided by an example embodiment of the present application; Figure 10 is a chip testing framework flow chart schematic diagram provided by an example embodiment of the present application; Figure 11 is an accelerated testing flow chart provided by an example embodiment of the present application; Figure 12 is a structural block diagram of a chip testing device provided by an example embodiment of the present application; Figure 13 is a structural block diagram of a terminal provided by an example embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to make the purpose, technical scheme and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the drawings.

[0023] It should be understood that although the terms first, second, etc. can be adopted to describe various information in the present disclosure, these information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of the present disclosure, the first parameter can also be referred to as the second parameter, and similarly, the second parameter can also be referred to as the first parameter. Depending on the context, the word "if" as used herein can be interpreted as "when" or "upon" or "in response to determining".

[0024] In the chip design and mass production process, chip testing is a key link to ensure the correctness of its functions and the stability of its performance. By applying specific test vectors and monitoring output responses, it can be verified whether the chip meets the design specifications and avoid the loss caused by defective chips flowing into the market. In related technologies, chip testing relies on manual writing of test platform code or on specific vendor closed tool chains: first, generate a STIL file through an ATPG tool, then manually convert the test vectors and timing parameters in the file into a hardware description language test environment, or use a tool chain to synchronously generate a test file and a verification model, and finally execute the test on a hardware simulation platform. However, the verification model generated by the closed tool chain has poor adaptability and cannot be flexibly integrated into different hardware simulation platforms, resulting in high testing cost and low testing efficiency.

[0025] The chip testing method provided in the embodiments of the present application can automatically generate a verification environment by injecting structured description data obtained by parsing a standard test description file into an environment template. The structured description data generated by parsing the standard test description file is independent of the hardware platform and is free of format dependence on specific tool chains. The environment template encapsulates general test logic, and the structured description data can adapt to the testing requirements of different chips by only parameter injection, and the generated verification environment complies with the general specification of the hardware description language and can be recognized and compiled by various hardware simulation platforms, which is not limited to specific tool chains or hardware platforms, can improve the flexibility of cross-platform integration, can realize a fully automatic chip testing process, does not require manual adjustment of the verification environment to adapt to the hardware simulation platform, reduces the testing cost, and improves the chip testing efficiency.

[0026] First, the test system of the present application is introduced. Please refer to Figure 1 which shows a schematic diagram of a test system provided by an exemplary embodiment of the present application, which includes a computer device 10 and a first chip 20.

[0027] The computer device 10 is a test execution subject for executing the chip testing method provided by the embodiments of the present application. The first chip 20 is the object to be tested, and there is a connection relationship between the computer device 10 and the first chip 20, through which the computer device 10 can drive the test of the first chip 20.

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

[0029] Illustratively, the computer device 10 parses a standard test description file of the first chip 20 to obtain structured description data, the standard test description file being used to express test requirements of the first chip 20 in a standard test interface language, and the structured description data being used to express the test requirements of the first chip 20 in structured data; the computer device 10 injects the structured description data into an environment template to automatically generate a verification environment, the verification environment being a program used to carry chip test logic, and the environment template being a preset test logic framework; and the computer device 10 drives the first chip 20 based on the verification environment to obtain a chip test result, the chip test result being used to indicate a chip performance of the first chip 20.

[0030] Optionally, the computer device 10 described above can be a dedicated chip test accelerator, a Field-Programmable Gate Array (FPGA) emulator, or the like hardware emulation device, or can be a terminal or a server capable of driving a test chip, and the present embodiment is not limited thereto.

[0031] The terminal described above is optional, and the terminal can be a desktop computer, a laptop computer, a mobile phone, a tablet computer, an electronic book reader, a Moving Picture Experts Group Audio Layer III (MP3) player, a Moving Picture Experts Group Audio Layer IV (MP4) player, a smart television, a smart vehicle, or the like terminal device, and the present embodiment is not limited thereto.

[0032] It is worth noting that the server described above can be a standalone physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud security, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0033] The cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and networks in a wide area network or a local area network to realize data calculation, storage, processing, and sharing.

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

[0035] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data for analysis, stored data, displayed data, etc.) and signals involved in the present application are authorized by the user or fully authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards in the relevant region. For example, the operation data and account information involved in the present application are obtained under full authorization.

[0036] Further explanation, before collecting the relevant data of the user (for example: the account information, historical operation data and real-time operation data involved in the present application, etc.) and in the process of collecting the relevant data of the user, a prompt interface, a pop-up window or an output voice prompt information can be displayed, which is used to prompt the user that the relevant data of the user is being collected at present, so that the present application only starts to perform the related steps of obtaining the relevant data of the user after obtaining the confirmation operation of the user to the prompt interface or the pop-up window, otherwise (i.e. without obtaining the confirmation operation of the user to the prompt interface or the pop-up window), ending the related steps of obtaining the relevant data of the user, that is, not obtaining the relevant data of the user. In other words, all the user data collected by the present application is collected under the condition that the user agrees and authorizes, and the collection, use and processing of the relevant user data need to comply with the relevant laws, regulations and standards in the relevant region.

[0037] Illustratively, please refer to Figure 2 which shows a flowchart of a chip testing method provided by an example embodiment of the present application. The method can be executed by a terminal, can be executed by a server, or can be executed by both the terminal and the server. The example embodiment of the present application takes the method executed by the terminal as an example for illustration, as shown in Figure 2 The method includes the following steps: Step 210, obtaining structured description data based on a standard test description file of the first chip.

[0038] 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 a structured data.

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

[0040] The test requirements include but are not limited to the test target, test range, test rule and judgment standard of the first chip, and the test requirements are essentially the design requirements of the chip, such as function correctness, performance stability and timing compliance, which are converted into quantifiable and executable test task descriptions. The standard test description file is a description file that describes the test task in a standard test interface language.

[0041] Illustratively, the standard test description file can be an STIL file automatically generated based on ATPG.

[0042] The structured description data is an intermediate data set generated after parsing the standard test description file, and adopts a hierarchical data structure such as a table, a dictionary, a graph structure, a set, and the like.

[0043] In some embodiments, the structured description data can be obtained by parsing the standard test description file, or can be directly obtained for the first chip, or can be reused for the first chip after being parsed, and the embodiments of the present application do not limit this.

[0044] Parsing the standard test description file refers to a process of text content recognition, syntax rule checking, semantic information extraction, and data format reconstruction on the standard test description file, and a core target thereof is to convert unstructured text test requirements into structured data that can be directly processed by a machine, to provide a unified and standardized input basis for subsequent automatic generation of a verification environment.

[0045] In some embodiments, the parsing process includes obtaining a standard test description file of the first chip, extracting a test vector, a timing parameter, and a signal parameter from the standard test description file through syntax parsing, and generating structured description data based on the test vector, the timing parameter, and the signal parameter.

[0046] The test vector is used to drive the test of the first chip, the timing parameter is used to constrain the signal interaction timing when the first chip is tested, and the signal parameter is used to indicate the signal attribute.

[0047] For the test vector extraction, the content corresponding to the “TEST_VECTOR” keyword in the standard test description file can be identified, and a text description of “input signal = value → output signal = expected value” can be converted into a structured input-output mapping pair, that is, a test vector-expected result pair, wherein 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.

[0048] For the timing parameter extraction, the content corresponding to the “TIMING_CONSTRAINT” keyword can be identified, and timing constraint parameters such as a clock period, a signal setup time, and a signal hold time can be extracted.

[0049] For the signal parameter extraction, the content corresponding to the “SIGNAL_DEFINITION” keyword can be identified, and attribute parameters such as a signal name, a signal type, a signal direction, and a signal bit width can be extracted.

[0050] Optionally, the structured description data comprises a test vector set, a timing constraint set and a signal attribute set.

[0051] The test vector set comprises at least two test vectors for driving the first chip; the timing constraint set is used to indicate timing parameters during testing the first chip, the timing parameters comprising at least one of a clock period, a signal setup time and a signal hold time; and the signal attribute set is used to indicate signal parameters during testing the first chip, the signal parameters comprising at least one of a signal name, a signal type and a signal direction.

[0052] The test vector is a signal value input to the first chip, and the test vector corresponds to an expected result, which is an output value generated by the chip under the driving of the test vector.

[0053] In some embodiments, the test vector can correspond to a test scenario label, which is used to indicate a test type corresponding to the test vector, such as a functional test or a boundary condition test, and can be used for subsequent scenario matching of a verification environment.

[0054] The timing constraint set is a data group defining timing rules for signal interaction during testing, and is used to ensure validity of the test vector.

[0055] The signal attribute set is a data group describing all signal characteristics involved in the testing, and is used to ensure compatibility of signal driving with a chip interface.

[0056] Step 220: injecting the structured description data into an environment template to obtain a verification environment.

[0057] The verification environment is a program for carrying chip test logic, and the environment template is a pre-set test logic program framework.

[0058] The verification environment is an executable program written in a hardware description language, and is used to carry all test logic of the first chip; the environment template is a pre-defined test logic program framework, and is designed in a modular structure of a hardware description language, and is used to carry general test logic and reserve a parameter injection interface.

[0059] Injecting the structured description data into the environment template to obtain the verification environment means that parameters in the structured description data are filled into corresponding positions of the environment template according to a pre-set rule, and the structured description data and the environment template are combined into an executable test program.

[0060] In some embodiments, the generation process of the verification environment comprises: obtaining an environment template including a test stimulus generation template and a test result comparison template, the test stimulus generation template being a program framework for carrying test driving logic, and the test result comparison template being a program framework for carrying test result comparison logic; and injecting structured description data into the test stimulus generation template and the test result comparison template to automatically generate the verification environment.

[0061] The environment template is a pre-defined standardized test logic program framework stored in a template library of a computer device, and the design goal thereof is to realize rapid instantiation of a test environment through "general logic encapsulation + parameter interface reservation".

[0062] When the environment template is obtained, the system can automatically match a corresponding environment template according to the type (such as a digital chip or a mixed-signal chip) or the test scenario (such as a function test or a timing test) of the first chip, such as a "digital chip general test template" or a "high-speed interface special test template".

[0063] The core components of the environment template include a test stimulus generation template and a test result comparison template, the test stimulus generation template being a logic framework for driving the test first chip, and the test result comparison template being a logic framework for verifying the first chip.

[0064] In some embodiments, 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; and the test stimulus code and the test comparison code are assembled to obtain the verification environment, the test stimulus code being used to drive the test first chip based on the test driving logic, and the test comparison code being used to generate the chip test result based on the test result comparison logic.

[0065] The injection of the structured description data is to combine specific parameters of a test requirement with general logic of the environment template, and to automatically complete parameter matching and code generation through a program.

[0066] The injection of the structured description data into the test stimulus generation template can convert general logic of test driving into a specific signal driving program for the first chip, i.e., test stimulus code, which can accurately output input signals meeting test requirements.

[0067] The injection of the structured description data into the test result comparison template can convert general logic of test result verification into a specific result verification program for the first chip, i.e., test comparison code, which can automatically complete collection and comparison of output signals.

[0068] In step 230, the test first chip is driven based on the verification environment to obtain a chip test result.

[0069] Optionally, the chip test result is used to indicate at least one of a chip performance, compatibility, compliance, and the like of the first chip.

[0070] The driving test of the first chip based on the verification environment refers to a process of landing test logic defined in the verification environment through a hardware carrier, applying a preset test vector to the first chip, collecting an output signal, and completing result verification. The core goal is to verify whether the first chip meets design requirements through an automated process.

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

[0072] In some embodiments, the test process includes integrating the verification environment and the first chip, generating a hardware execution file, and using the hardware execution file to express chip test logic in a hardware description language; running the hardware execution file to generate a chip test result.

[0073] Integration refers to constructing a testable system by physically connecting and logically adapting the verification environment (i.e., test logic program) and the first chip (i.e., test object) to work together, and the core goal is to ensure stable transmission of test signals between the two.

[0074] The generation process of the hardware execution file includes connecting the test interface of the verification environment and the first chip, and compiling to obtain the hardware execution file.

[0075] In some embodiments, the signal ports of the verification environment, such as excitation output ports, result collection ports, and the like, need to be logically bound with the test interfaces of the first chip, such as input pins, output pins, and the like, so as to be able to drive the test of the first chip based on the verification environment.

[0076] The hardware execution file is a binary file that can be directly run on a hardware simulation platform after integrating the test logic of the verification environment and the interface characteristics of the first chip, and is a carrier for converting test logic from software description to hardware executable operation. Its essence is a "test logic code + test data" complex that can be recognized and executed by a hardware simulation platform, and can accurately adapt to the interface timing and signal characteristics of the first chip to achieve automatic driving and result verification of the chip.

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

[0078] The test logic code is a set of binary instructions executable directly by hardware, encapsulating the test logic in the verification environment, for controlling the timing, signal interaction and result judgment of the test flow, for example, including excitation driving logic, result collection and comparison logic, timing control logic, exception handling logic, etc.

[0079] The test data is a static data block in the hardware execution file, storing specific parameters (i.e., test vectors) and expected standards (i.e., expected results) required for testing.

[0080] The hardware execution file is a key link for software logic to land on hardware execution, converting abstract verification environment code into hardware executable instructions through compilation and conversion, solving the problem that software description cannot directly drive physical chips.

[0081] In some embodiments, the chip test result is obtained by comparing the test result of the first chip based on the structured description data with the expected result.

[0082] The test process includes loading the hardware execution file, testing the first chip based on the test driving logic indicated by the hardware execution file, comparing the test result of the first chip based on the test vector with the expected result based on the test result comparison logic indicated by the hardware execution file, obtaining the comparison result; and generating the chip test result based on the comparison result.

[0083] In the case where the test result and the expected result meet the verification condition, the first comparison result is obtained, and the first comparison result is used to indicate that the first chip passes the test based on the test vector; in the case where the test result and the expected result do not meet the verification condition, the second comparison result is obtained, and the second comparison result is used to indicate that the first chip fails the test based on the test vector.

[0084] In some embodiments, the test statistical data is generated based on the comparison result, and the chip test result is generated based on the test statistical data.

[0085] Optionally, the test statistical data includes at least one of test coverage, error record and pass rate, the test coverage is used to indicate the functional coverage degree of the test vector on the first chip, the error record is used to indicate the test information of the first chip failing the test based on the test vector, and the pass rate is used to indicate the proportion of the first chip passing the test based on the test vector.

[0086] For illustration, please refer to Figure 3 , Figure 3 is a chip test architecture diagram provided by an exemplary embodiment of the present application, as shown in Figure 3 The chip test system can include an input layer 310, an analysis layer 320, a processing layer 330, an acceleration layer 340 and an output layer 350.

[0087] The input layer 310 is configured to input the STIL file.

[0088] The parsing layer 320 is configured to parse the STIL file by a STIL parsing engine to obtain structured description data, which can include a Joint Test Action Group (JTAG) signal timing parsing and top-level interface state extraction process.

[0089] The processing layer 330 is configured to perform test data conversion and verification environment generation. For test data conversion, it can include a timing constraint generation based on the structured description data and a top-level signal mapping process. For verification environment generation, it can perform a JTAG timing template driving and a top-level interface adaptation process by a testbench generator.

[0090] The acceleration layer 340 can be integrated with a hardware simulation platform (such as Palladium) to perform incremental compilation, timing-sensitive test vector loading, and other processes.

[0091] The output layer 350 is configured to perform testing and result analysis. For testing, it includes a JTAG signal timing monitoring and a top-level state abnormality detection process. For result analysis, it includes a timing violation bit and a state abnormality tracing process.

[0092] In summary, the method provided by the embodiments of the present application can automatically generate a verification environment by injecting structured description data based on a standard test description file into an environment template. The method can parse a standard test description file to generate structured description data independent of a hardware platform, thereby eliminating the format dependency of the original test file on a specific tool chain. The method can also adapt the test requirements of different chips by only injecting parameters of the structured description data based on an environment template encapsulating general test logic. The generated verification environment complies with the general specification of a hardware description language and can be recognized and compiled by various hardware simulation platforms, thereby improving the flexibility of cross-platform integration, realizing a fully automatic chip testing process, reducing the testing cost, and improving the chip testing efficiency.

[0093] In some embodiments, the parsing process of the test description file is to convert the test requirements of the first chip from a text description into machine-processable structured data, which provides a standardized input for the subsequent automatic generation of a verification environment. Please refer to Figure 4 , Figure 4is a standard test description file parsing flowchart provided by an exemplary embodiment of the present application, which can be executed by a terminal, a server, or both the terminal and the server. The present embodiment takes the terminal as an example for illustration, as shown in Figure 4 The step 210 includes the following steps. Step 211: Obtain a standard test description file.

[0094] The standard test description file is a text file written in a standard test interface language, and its core features include standardization, completeness, and readability.

[0095] Standardization refers to compliance with uniform syntax rules, such as fixed keywords and parameter formats, to ensure compatibility between different test tools and systems.

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

[0097] Readability refers to the support for manual review through text format and automatic parsing by machines through syntax rules.

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

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

[0100] Syntax parsing refers to an automated process of text recognition, rule checking, and information extraction on the standard test description file using parsing tools. Its core is based on the syntax rules of the standard test interface language, such as keyword definition and parameter nesting format, to convert unstructured text in the file into identifiable structured data, and ultimately extract core test parameters, including test vectors, timing parameters, and signal parameters.

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

[0102] File format checking is used to check whether the file conforms to the standard syntax specifications, such as correct keyword spelling and parameter bracket matching. If there is a format error, an error prompt is returned.

[0103] Keyword recognition is used to locate text passages that record core parameters in the file through a pre-set keyword library.

[0104] Parameter extraction is used to strip redundant text, such as comments and format symbols, from the located passages to extract specific parameter values.

[0105] The test vector is an input signal value used to drive the input port of the first chip, and is the most core execution basis in the test requirement.

[0106] The timing parameter is a quantitative index for defining the time relationship of signal interaction in the test process, and ensures that the chip is driven and verified under the preset time constraint. The core role is to simulate the actual working timing environment of the chip.

[0107] The timing parameter specifically includes at least one of clock period, signal setup time, signal hold time and the like.

[0108] The clock period is used to indicate the period length of the test clock signal, and defines the time reference of signal transmission; the signal setup time is used to indicate the minimum time that the input signal needs to be 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 needs to be stable after the clock edge, to avoid sampling errors caused by signal transition.

[0109] The signal parameter is a parameter set for describing the physical and logical properties of all signals involved in the test process, to ensure that the test signal is compatible with the interface characteristics of the first chip.

[0110] The signal parameter specifically includes at least one of signal name, signal type, signal direction, signal bit width, and level standard.

[0111] The signal name is the unique identification of the signal, used to distinguish signals with different functions; the signal type is used to indicate the electrical or logical type of the signal, such as "digital signal", "analog signal", "differential signal", "single-ended signal", etc.; the signal direction is used to indicate the transmission direction of the signal between the test system and the chip, such as "input", "output", "bidirectional", 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 of the digital signal; the level standard is used to indicate the voltage range of the signal, to ensure that the electrical characteristics of the test signal are compatible with the chip interface.

[0112] In step 213, the structured description data is generated based on the test vector, the timing parameter and the signal parameter.

[0113] Optionally, the structured description data includes a test vector set, a timing constraint set and a signal attribute set.

[0114] The test vector set includes at least two test vectors, the test vector is used to drive the first chip, and the test vector corresponds to an expected result, which is used to provide a reference for the test result of the first chip based on the test vector.

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

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

[0117] For illustration, refer to Figure 5 , Figure 5 is a file parsing flowchart provided by an exemplary embodiment of the present application, as shown in Figure 5 the parsing process of the standard test description file includes: step 501, inputting an STIL file; step 502, syntax analysis; step 503, determining whether it is compliant, if compliant, executing step 504, otherwise executing step 505; step 504, data extraction; step 505, generating an error report; step 506, data caching; and step 507, outputting test data.

[0118] The method provided by the embodiment of the present application explicitly divides the structured description data into a test vector set, a timing constraint set, and a signal attribute set, and refines the core parameters of the sets, realizes the classified storage and associated binding of test requirements, and based on the structured division, makes the test data clear and orderly, which is convenient for accurately extracting the required parameters by the environment template, and ensures the consistency of the test logic and the original requirements, avoiding confusion or omission.

[0119] In summary, the method provided by the embodiment of the present application can generate structured description data independent of the hardware platform by parsing the standard test description file, and can improve the data parsing efficiency and the chip test efficiency by stripping the format dependence of the original test file on a specific tool chain.

[0120] In some embodiments, after obtaining the structured description data, a verification environment can be automatically generated to drive the test of the first chip, and the environment template includes a test stimulus generation template and a test result comparison template. For illustration, refer to Figure 6 , Figure 6 is a flowchart of a method for automatically generating a verification environment provided by an exemplary embodiment of the present application, which can be executed by a terminal, a server, or both a terminal and a server, and the embodiment of the present application takes the execution by the terminal as an example for illustration, as shown in Figure 6 the step 220 includes the following steps: Step 221, injecting the structured description data into the test stimulus generation template and the test result comparison template to generate test stimulus code and test comparison code.

[0121] 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 result based on the test result comparison logic.

[0122] In some embodiments, an environment template including a test stimulus generation template and a test result comparison template needs to be obtained first.

[0123] The environment template is a predefined standardized test logic program framework, which is stored in a template library of a computer device, and the design goal is to realize rapid instantiation of the test environment through "general logic encapsulation + parameter interface reservation".

[0124] When obtaining the environment template, the system can automatically match the corresponding environment template according to the type of the first chip (such as a digital chip, a mixed signal chip) or the test scene (such as a functional test, a timing test), such as a "digital chip general test template", a "high-speed interface special test template", etc.

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

[0126] The test stimulus generation template is a program framework for carrying test driving logic, and its core role is to define a general process of how to send test signals to the first chip, and after parameter injection, specific signal driving code (i.e. test stimulus code) can be generated.

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

[0128] For the test stimulus generation template, parameter injection can be achieved by reserving input slots corresponding to structured description data, for example, a test vector interface is used to receive input vector sequences in a test vector set, a timing parameter interface is used to receive clock period, signal setup time, signal hold time, etc. Parameters in a timing constraint set, and a signal attribute interface is used to receive signal name, direction, bit width, etc. Parameters in a signal attribute set.

[0129] The test result comparison template is a program framework for carrying test result comparison logic, and its core role is to define a general process of how to collect and verify the output signals of the first chip, and after parameter injection, specific result verification code (i.e. test comparison code) can be generated.

[0130] In some embodiments, the test result comparison template encapsulates the basic process of result verification, such as expected result storage, real-time signal collection, comparison rule execution, result recording, etc., to ensure the consistency of the verification logic.

[0131] For the test result comparison template, the parameter injection can be realized 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. expected result) in the test vector set, the collection configuration interface is used to receive the output signal name, bit width, sampling time and other parameters in the signal attribute set, and the comparison rule interface is used to receive the judgment standard in the structured description data, such as "complete match pass", "analog signal allows ±5% error" and the like.

[0132] It is worth noting that the above environment template types and corresponding parameter injection methods are only exemplary examples, and the embodiments of the present application are not limited thereto.

[0133] For the parameter injection process of the test stimulus module (test stimulus code), the input signal parameters in the signal attribute set in 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 into the test vector interface of the test stimulus generation template in sequence to generate stimulus sending code.

[0134] 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 collection configuration interface of the test result comparison template to generate signal collection 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 standard in the structured description data can be injected into the comparison rule interface of the test result comparison module to generate result verification code.

[0135] Step 222, assembling the test stimulus code and the test comparison code to obtain a verification environment.

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

[0137] For illustration, please refer to Figure 7 , Figure 7 is a verification environment generation flowchart provided by an exemplary embodiment of the present application, as Figure 7As shown, the verification environment generation process includes: step 701, sending JTAG timing data from the parsing engine to the Testbench generator; step 702, requesting a JTAG timing template from the JTAG timing template library by the Testbench generator; step 703, returning the timing template to the Testbench generator by the JTAG timing template library; step 704, injecting timing parameters such as test clock (TCK) period, test mode select (TMS) change edge, etc. by the Testbench generator; step 705, generating top-level interface monitoring code by the Testbench generator; step 706, outputting the JTAG Testbench by the Testbench generator to obtain the generated Testbench, i.e., the verification environment.

[0138] The method provided by the embodiments of the present application can focus the test excitation code on the chip driving logic and focus the test comparison code on the result checking logic by decomposing the generation of the verification environment into two steps of modular code generation and standardized assembly, so that the two can form complete test logic through assembly, which not only ensures the independence of the functions of the modules, but also realizes seamless cooperation through standardized interfaces, and finally generates a verification environment that has both pertinence (matching the first chip requirement) and completeness (covering the whole process of driving and comparison).

[0139] In conclusion, the method provided by the embodiments of the present application can automatically generate a verification environment based on the parameter injection mode, does not need to manually write test codes, realizes the instantiation of the structured data automatic driving template, improves the generation efficiency of the verification environment, and can avoid the requirement deviation caused by manual writing by generating the test logic based on the structured description data, so that the environment template can be applied to the test of different chips, a new verification environment can be generated only by replacing the structured data, the maintenance cost is reduced, and the chip test efficiency based on the parameter injection automatic generation of the verification environment is improved.

[0140] In some embodiments, the integrated verification environment and the first chip are required to obtain a hardware execution file used for running on a hardware simulation platform. Please refer to Figure 8 , Figure 8 is a flowchart of a chip test method based on a hardware execution file provided by an exemplary embodiment of the present application. The method can be executed by a terminal, can be executed by a server, or can be executed by both the terminal and the server. The embodiments of the present application take the execution of the method by the terminal as an example for description, as shown in Figure 8 The above step 230 includes: Step 231, integrating the verification environment and the first chip to generate a hardware execution file.

[0141] The hardware execution file is used to express the chip test logic in a hardware description language.

[0142] Integration refers to constructing a testable environment (i.e., a test logic program) and a first chip (i.e., a test object) into a testable system that can work together through physical connection and logical adaptation, and the core goal is to ensure that test signals can be stably transmitted between the two.

[0143] The generation process of the hardware execution file includes connecting the test interface of the testable environment and the first chip, and compiling to obtain the hardware execution file.

[0144] In some embodiments, it is necessary to logically bind the signal ports of the testable environment, such as the excitation output end, the result collection end, etc., to the test interface of the first chip, such as the input pin, the output pin, etc., so as to be able to drive the first chip based on the testable environment.

[0145] The hardware execution file is a binary file that can be directly run on a hardware simulation platform after integrating the test logic of the testable environment and the interface characteristics of the first chip, and is a carrier for converting the test logic from a software description to a hardware executable operation. The essence is a "test logic code + test data" complex that can be recognized and executed by a hardware simulation platform and can accurately adapt to the interface timing and signal characteristics of the first chip to achieve automatic driving and result verification of the chip.

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

[0147] The test logic code is a binary instruction set that can be directly executed by hardware, encapsulates the test logic in the testable environment, and is used to control the timing, signal interaction, and result judgment of the test flow, for example, including excitation driving logic, result collection and comparison logic, timing control logic, exception handling logic, etc.

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

[0149] The hardware execution file is a key link for software logic to land hardware execution, and converts abstract testable environment code into hardware executable instructions through compilation conversion, solving the problem that software description cannot directly drive physical chips.

[0150] In the embodiments of the present application, the chip test method provided by the hardware simulation device integrates the testable environment and the first chip into the hardware simulation platform, and compiles to generate a hardware execution file. The hardware execution file is a code file that can be directly executed in the hardware simulation platform.

[0151] Step 232: Run the hardware execution file to generate chip test results.

[0152] In an embodiment of the present application, the chip testing method provided in the embodiment of the present application is executed by a hardware simulation device. After the verification environment and the first chip are integrated into the hardware simulation platform to obtain the hardware execution file, the hardware execution file is directly run in the hardware simulation platform to generate the chip test results of the first chip.

[0153] In some embodiments, the chip test result is obtained by comparing the test result obtained by testing the first chip based on the structured description data with the expected result.

[0154] The testing process includes loading a hardware execution file, testing the first chip based on the test drive logic indicated by the hardware execution 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 execution file to obtain a comparison result; and generating a chip test result based on the comparison result.

[0155] For illustration, please refer to Figure 9 , Figure 9 This is a schematic diagram of the top-level design of chip testing provided by an exemplary embodiment of the present application. Figure 9 As shown, the test stimulus module 910 drives the test of the first chip, and the test result of the first chip is compared with the expected result by the test comparison module 920 to generate the chip test result.

[0156] In the environment integration process, the Testbench and the first chip top layer DUT are instantiated in hw_top; the atpg_dft_top interface is connected with the DUT instantiation interface, because the atpg_dft_top is a *.stil file generated based on module matching, so the signals of the atpg_dft_top have matching signals in the module. In the compilation and loading process, the Device Under Test (DUT) and the Testbench interface are integrated to generate a Database after compilation, and the Database is loaded on the Emulator through the palladium xeDebug instruction after the Database is compiled. In the accelerated simulation and monitoring process, the Testdata is loaded into the Testbench vector memory through the Memory-load instruction, the reset is released, the simulation is started, and the Testbench driver drives the test vector to the DUT top layer interface; 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 the abnormal printing is triggered at the same time, and the printing is output to the xeDebug interface.

[0157] The method provided by the embodiment of the application ensures accurate mapping of the signals of the verification environment and the physical pins of the chip through the interface connection, integrates the interface adaptation logic and the test logic into a hardware executable form through compilation, breaks through the interface barrier between the verification environment and the chip, ensures stable transmission of the test signals, and improves the test execution efficiency through compilation optimization, thereby avoiding test errors caused by signal delay or conflict.

[0158] The method provided by the embodiment of the application explicitly divides the hardware execution file into test logic code and test data, so that the test logic code can be reused to adapt to different chips, and the test data can be updated independently, thereby reducing the complexity of file generation and facilitating the expansion of subsequent test scenarios.

[0159] In a case where the test result and the expected result meet the verification condition, a first comparison result is obtained, and the first comparison result is used to indicate that the first chip passes the test based on the test vector; in a case where the test result and the expected result do not meet the verification condition, a second comparison result is obtained, and the second comparison result is used to indicate that the first chip fails the test based on the test vector.

[0160] The verification condition is a standard for judging whether the test passes or not, is the core of the comparison logic, and its essence is to determine the range in which the actual test result and the predicted result are matched.

[0161] Optionally, the verification condition can be dynamically determined according to the chip type, a test scenario, and the like, and embodiments of the present application do not limit this.

[0162] The method provided by the embodiments of the present application ensures correct deployment of test logic by loading the hardware execution file, drives precise excitation of the chip by the test, realizes automatic verification of the comparison result, and finally generates a result to complete conversion from raw data to a conclusion, thereby realizing full automation of test execution and improving test efficiency.

[0163] The method provided by the embodiments of the present application intuitively reflects the correctness of the chip function through the first comparison result, and accurately records the mismatch details through the second comparison result, which not only clearly indicates the conclusion of the single-vector test, but also provides raw data for subsequent statistical analysis.

[0164] In some embodiments, test statistical data is generated based on the comparison result, and a chip test result is generated based on the test statistical data.

[0165] Optionally, the test statistical data includes at least one of a test coverage, an error record, and a pass rate, the test coverage is used to indicate a functional coverage degree of the test vector to the first chip, the error record is used to indicate test information that the first chip fails to pass the test based on the test vector, and the pass rate is used to indicate a proportion of the first chip passing the test based on the test vector.

[0166] The method provided by the embodiments of the present application realizes a leap from a single comparison result to comprehensive performance evaluation by generating test statistical data such as test coverage, error record, and pass rate, and generating a chip test result based on these data. The test coverage reflects the comprehensiveness of the test, the error record locates specific problems, and the pass rate quantifies the overall performance. These data together constitute a multi-dimensional evaluation of the performance of the first chip, which can improve the test evaluation efficiency.

[0167] In summary, the method provided by the embodiments of the present application converts an abstract verification environment into test logic (hardware execution file) that can be directly executed on a hardware platform by integrating the verification environment and the first chip, generating the hardware execution file, and running the file to generate a result, and the integration process ensures that the verification environment and the chip interface are compatible. The generation of the hardware execution file makes the test logic fall to physical electrical signals, thereby improving the authenticity and reliability of the test result.

[0168] The embodiment of the application loads the STIL file by developing a Python script analysis tool, generates a Verilog synthesizable Testbench (extracts information such as test vectors, timing information and test period data in the STIL file description) and Testdata (test data), integrates the generated Testbench and the design into a Palladium accelerator to compile a Database database, loads test execution, collects test results, and judges test correctness and failure according to the test results.

[0169] The chip test method provided by the embodiment of the application mainly includes an STIL file processing module, a Testbench automatic generation module and a Palladium acceleration verification module.

[0170] The STIL file processing module reads an STIL format test vector file through a Python analysis tool, extracts key information such as test vector data, timing parameters, test period data and the like, and generates structured intermediate data. The Institute of Electrical and Electronics Engineers (IEEE) 1450 standard is supported, Pattern blocks (test vectors), Timing blocks (timing constraints), Signals blocks (signals and signal Input / Output (IO) attributes) and the like can be recognized, vector data is extracted according to the Pattern blocks, and Testdata is generated.

[0171] The Testbench automatic generation module generates a synthesizable Verilog Testbench based on the parsed information of the Pattern blocks (test vectors), Timing blocks (timing constraints), Signals blocks (signals and signal IO attributes) and the like, and integrates functions such as clock driving, vector loading and response capturing.

[0172] The Python analysis tool injects the parsed parameters in the STIL into a template through a Python string replacement method to automatically generate the Testbench. Specifically, the Testbench can include a clock module and a vector driving module, wherein the clock module is used to generate a clock signal according to the Timing blocks, and the vector driving module is used to generate vector driving logic.

[0173] The Palladium acceleration verification module is used to perform chip testing, integrates the Testbench and the design DUT into a palladium hardware simulator, realizes hardware acceleration and real-time monitoring of test vectors, and the top-level design is as shown in the above Figure 9 .

[0174] 1. Environment integration.

[0175] (a) Instantiate atpg_dft_top and DUT top in hw_top.

[0176] (b) Connect atpg_dft_top interface with DUT interface, since atpg_dft_top is *.stil file generated based on module matching, so atpg_dft_top signal has matching signal in module.

[0177] 2. Compile and load.

[0178] (a) Compile after DUT and Testbench interface integration to generate Database.

[0179] (b) Load Database to Emulator through palladium xeDebug instruction after Database compilation.

[0180] 3. Accelerated simulation and monitoring.

[0181] (a) Load Testdata to Testbench vector memory through Memory -load instruction, release reset, start simulation, Testbench driver drive test vector to DUT top interface.

[0182] (b) Testbench checker compare Testdata golden data with DUT output response transmitted to Testbench, if the comparison value is same, then test vector is passed, if the comparison value is different, then test vector is abnormal, at the same time trigger abnormal printing, printing will output to xeDebug interface.

[0183] For illustration, please refer to Figure 10 , Figure 10 is a chip test framework process schematic diagram provided by an exemplary embodiment of the present application, as Figure 10As shown, the chip test method provided by the embodiment of the application includes the following steps: step 1001, obtaining an STIL file; step 1002, parsing the STIL file, that is, obtaining structured description data by parsing the STIL file through an STIL parsing engine; step 1003, extracting test data; step 1004, obtaining an environment template, that is, using a Testbench generator; step 1005, generating a verification environment, that is, obtaining AXI / APB Testbench code; step 1006, obtaining a design netlist; step 1007, integrating the verification environment and the first chip, for example, using a Palladium integration module; step 1008, generating a hardware execution file, that is, using an accelerated simulation environment; step 1009, running the hardware execution file, that is, test execution and monitoring; step 1010, obtaining a test result; and step 1011, error analysis and defect positioning.

[0184] Illustratively, the tool and environment configuration used by the embodiment of the application are as follows: Parsing tool: Python parsing tool; Input file: STIL format ATPG test vector file (compliant with IEEE 1450 standard); Output file: Verilog synthesizable Testbench, binary test data Testdata.

[0185] The internal flow of the STIL parsing engine can be referred to Figure 5 In the STIL syntax parsing, test vectors, timing constraints, signal mapping and other information in the STIL file are parsed to construct internal data structures. For example, test vector data is extracted through a Pattern block, state changes of a WaveformTable block in different periods are parsed through a Timing block, and clock periods Period and waveform definitions in a Waveforms block in the same period. Test vectors, timing information and test period data are extracted from the parsing results and converted into a format loadable by a Palladium accelerator.

[0186] In some embodiments, the Testbench generation flow can be referred to Figure 7 The generation logic can include state machine generation logic, vector data driving module generation logic, signal check generation logic and test result report generation logic.

[0187] For accelerated simulation and monitoring, the generated Testbench and the design are integrated into a Palladium accelerator, and the compilation and execution efficiency is optimized. Please refer to Figure 11 , Figure 11 is an accelerated test flowchart provided by an exemplary embodiment of the application, as Figure 11As shown, step 1101, obtaining Testbench code; step 1102, obtaining design netlist; step 1103, Palladium compilation; step 1104, simulation mirror; step 1105, test execution; step 1106, real-time monitoring; step 1107, test log; step 1108, error analysis; step 1109, defect positioning.

[0188] The tool and environment configuration are as follows: Simulation platform: Palladium hardware simulator (including ICE Flow tool chain); Input file: chip netlist, Verilog synthesizable Testbench, Testdata binary file; Output result: simulation log (xeDebug.log), test pass / fail flag.

[0189] For the compilation and loading process, first, database compilation is performed, and Palladium ICE Flow is used to compile the chip netlist and Testbench; accelerated simulation execution is performed, Palladium simulation is started, the compiled database is loaded, and the Testbench is placed in the vector memory test data Testdata; the test execution process is controlled, the test result is analyzed, and the test is passed or failed, and the number of test vectors that pass the test or the number of test vectors that fail the test can be output.

[0190] The method provided in the embodiment of the application supports multiple versions of STIL standards through an STIL analysis engine; a high-efficiency test vector and timing information extraction and conversion method is implemented; a template-based hardware acceleration test platform generation method is adopted; adaptive interface adaptation technology is used to implement a Testbench automatic generation technology; through Palladium accelerator optimization integration, a high-efficiency test vector partitioning and parallel execution method on a hardware accelerator is implemented; an incremental compilation and cache mechanism can be implemented to improve iteration efficiency; a test execution and monitoring system can be implemented to implement a real-time exception detection and test progress tracking method.

[0191] In summary, the method provided by the embodiments of the present application reduces manual intervention, shortens the test preparation period, and improves test efficiency by automatically analyzing and generating a testbench; and the test execution speed is improved by efficiently using a Palladium accelerator. The dependence on a third-party STIL analysis tool is eliminated, tool authorization fees are saved, manual coding workload is reduced, and human costs are lowered. Customized test sequences and special protocols can be supported to adapt to diversified test requirements; new STIL syntax features and accelerator functions can be easily extended to enhance flexibility and scalability. The consistency of the automatically generated testbench is high, human errors are reduced; comprehensive coverage analysis and abnormality detection are performed to improve defect detection rates and improve test quality.

[0192] Figure 12 is a structural block diagram of a chip test device provided by an exemplary embodiment of the present application, as shown in the figure, the device comprises the following parts: Figure 12 The processing module 1210 is configured to obtain structured description data based on a standard test description file of a first chip, the standard test description file being used to describe test requirements of the first chip. The processing module 1210 is further configured to inject the structured description data into an environment template to obtain a verification environment, the verification environment being a program used to carry chip test logic, and the environment template being a preset test logic program framework. The test module 1220 is configured to drive the first chip based on the verification environment to obtain a chip test result.

[0193] In some embodiments, the processing module 1210 is further configured to: obtain the standard test description file; extract test vectors, timing parameters, and signal parameters from the standard test description file, the test vectors being used to drive the test of the first chip, the timing parameters being used to constrain signal interaction timing when the first chip is tested, and the signal parameters being used to indicate test signal attributes; generate the structured description data based on the test vectors, the timing parameters, and the signal parameters.

[0194] In some embodiments, the structured description data comprises a test vector set, a timing constraint set, and a signal attribute set. The test vector set comprises at least two test vectors, and the test vectors correspond to expected results, which are used to provide a reference for test results output by the first chip based on the test vectors; ​The set of timing constraints is configured to indicate timing parameters when testing the first chip, and the timing parameters include at least one of a clock period, a signal setup time, and a signal hold time. The set of signal attributes is configured to indicate signal parameters when testing the first chip, and the signal parameters include at least one of a signal name, a signal type, and a signal direction.

[0195] In some embodiments, the environment template includes a test stimulus generation template and a test result comparison template. The processing module 1210 is further configured to: inject the structured description data into the test stimulus generation template and the test result comparison template to generate test stimulus code and test comparison code; assemble the test stimulus code and the test comparison code to obtain the verification environment, the test stimulus code being configured to drive testing of the first chip based on test driving logic, and the test comparison code being configured to generate the chip test result based on test result comparison logic.

[0196] In some embodiments, the test module 1220 is further configured to: integrate the verification environment and the first chip to generate a hardware execution file, the hardware execution file being configured to express the chip test logic in a hardware description language; run the hardware execution file to generate the chip test result.

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

[0198] In some embodiments, the hardware execution file includes test logic code and test data. The test logic code is configured to indicate the chip test logic. The test data includes test vectors and expected results. The test module 1220 is further configured to: load the hardware execution file; drive testing of the first chip based on test driving logic indicated by the hardware execution file; compare a test result of the first chip based on a test vector with an expected result based on test result comparison logic indicated by the hardware execution file to obtain a comparison result; generate the chip test result based on the comparison result.

[0199] In some embodiments, the test module 1220 is further configured to: In a case where the test result meets the verification condition, a first comparison result is obtained, the first comparison result being used to indicate that the first chip passes the test based on the test vector; In a case where the test result does not meet the verification condition, a second comparison result is obtained, the second comparison result being used to indicate that the first chip fails the test based on the test vector.

[0200] In some embodiments, the test module 1220 is further configured to: generate test statistical data based on the comparison result, the test statistical data including at least one of test coverage, error record, and pass rate, the test coverage being used to indicate a degree of functional coverage of the first chip by the test vector, the error record being used to indicate test information that the first chip fails the test based on the test vector, and the pass rate being used to indicate a proportion of the first chip that passes the test based on the test vector; generate the chip test result based on the test statistical data.

[0201] To sum up, the device provided by the embodiments of the present application can automatically generate a verification environment by injecting structured description data obtained based on a standard test description file into an environment template. The device can generate structured description data independent of a hardware platform by parsing a standard test description file, and can adapt to the test requirements of different chips by only injecting parameters of the structured description data based on an environment template encapsulating general test logic. The generated verification environment complies with a general specification of a hardware description language and can be recognized and compiled by various hardware simulation platforms, and is not limited to a specific tool chain or hardware platform. The device can improve the flexibility of cross-platform integration, implement a fully automatic chip test process, and does not need to manually adjust a verification environment to adapt to a hardware simulation platform, thereby reducing test costs and improving chip test efficiency.

[0202] It should be noted that the chip test device provided by the above embodiments is only exemplarily described based on the division of the above functional modules. In actual applications, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the above described functions.

[0203] Figure 13 A structure block diagram of a terminal 1300 provided by an example embodiment of the present application is shown. The terminal 1300 can be a smart phone, a tablet computer, an MP3 player, an MP4 player, a notebook computer, or a desktop computer. The terminal 1300 can also be referred to as a user equipment, a portable terminal, a laptop terminal, a desktop terminal, or other names.

[0204] Generally, the terminal 1300 includes a processor 1301 and a memory 1302.

[0205] The processor 1301 can include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 1301 can be implemented in at least one of a hardware form of a Digital Signal Processing (DSP), a Field-Programmable Gate Array (FPGA), a Programmable Logic Array (PLA). The processor 1301 can also include a main processor and a coprocessor. The main processor is a processor for processing data in an awake state, also known as a Central Processing Unit (CPU). The coprocessor is a low-power processor for processing data in a standby state. In some embodiments, the processor 1301 can be integrated with a Graphics Processing Unit (GPU) that is responsible for rendering and drawing the content required to be displayed by the display screen. In some embodiments, the processor 1301 can further include an Artificial Intelligence (AI) processor for processing machine learning related computing operations.

[0206] The memory 1302 can include one or more computer-readable storage media that can be non-transitory. The memory 1302 can also include a high-speed random access memory, and a nonvolatile memory such as one or more disk storage devices, flash storage devices. In some embodiments, the non-transitory computer-readable storage medium in the memory 1302 is used to store at least one instruction for being executed by the processor 1301 to implement the chip testing method provided by the method embodiments in the present application.

[0207] In some embodiments, the terminal 1300 further includes other components 1303, which can be understood by those skilled in the art, Figure 13 The structure shown in FIG. 13 is not a limitation on the terminal 1300, and can include more or fewer components than those shown, or combine certain components, or use different arrangements of components.

[0208] Embodiments of the present application also provide a computer device, which can be implemented as Figure 1The computer device shown is, for example, a terminal or a server. The computer device includes a processor and a memory. The memory stores at least one instruction, at least one program, a code set, or an instruction set. The processor loads and executes the at least one instruction, the at least one program, the code set, or the instruction set to implement the chip testing method provided by the above method embodiments.

[0209] Embodiments of the present application also provide a computer readable storage medium, which stores at least one instruction, at least one program, a code set, or an instruction set. A processor loads and executes the at least one instruction, the at least one program, the code set, or the instruction set to implement the chip testing method provided by the above method embodiments.

[0210] Embodiments of the present application also provide a computer program product or a 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. The processor executes the computer instructions to enable the computer device to perform the chip testing method provided by the above method embodiments.

[0211] Optionally, the computer readable storage medium can include a read only memory (ROM), a random access memory (RAM), a solid state disk (SSD), an optical disk, or the like. The random access memory can include a resistance random access memory (ReRAM) and a dynamic random access memory (DRAM). The above-mentioned embodiment numbers of the present application are only for description, and do not represent the advantages and disadvantages of the embodiments.

[0212] Those of ordinary skill in the art can understand that all or part of the above-mentioned embodiments can be completed by hardware, or by a program instructing relevant hardware. The program can be stored in a computer readable storage medium. The above-mentioned storage medium can be a read only memory, a magnetic disk, or an optical disk.

[0213] The above-mentioned only describes optional embodiments of the present application, and does not limit the present application. Any modification, equivalent replacement, improvement, and the like made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A method of testing a chip, characterized by, The method comprises: obtaining structured description data based on a standard test description file of a first chip, the standard test description file being used for describing test requirements of the first chip; injecting the structured description data into an environment template to obtain a verification environment, the verification environment being a program used for carrying chip test logic, and the environment template being a preset test logic program framework; driving test of the first chip based on the verification environment to obtain chip test results.

2. The method of claim 1, wherein, The obtaining of the structured description data based on the standard test description file of the first chip comprises: obtaining the standard test description file; extracting test vectors, timing parameters and signal parameters from the standard test description file, the test vectors being used for driving test of the first chip, the timing parameters being used for constraining signal interaction timing when the first chip is tested, and the signal parameters being used for indicating test signal attributes; generating the structured description data based on the test vectors, the timing parameters and the signal parameters.

3. The method of claim 2, wherein, The structured description data comprises a test vector set, a timing constraint set and a signal attribute set; the test vector set comprises at least two test vectors, and the test vectors correspond to expected results, the expected results being used for providing reference for test results output by the first chip based on the test vectors; the timing constraint set is used for indicating timing parameters when the first chip is tested, and the timing parameters comprise at least one of clock periods, signal setup times and signal hold times; the signal attribute set is used for indicating signal parameters when the first chip is tested, and the signal parameters comprise at least one of signal names, signal types and signal directions.

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

5. The method according to any one of claims 1 to 3, characterized in that, The driving of test of the first chip based on the verification environment to obtain chip test results comprises: integrating the verification environment and the first chip to generate a hardware execution file, the hardware execution file being used for expressing the chip test logic in a hardware description language; running the hardware execution file to generate the chip test results.

6. The method of claim 5, wherein, The integrating of the verification environment and the first chip to generate a hardware execution file comprises: connecting test interfaces of the verification environment and the first chip to compile to obtain the hardware execution file.

7. The method of claim 5, wherein, The hardware execution file comprises test logic code and test data; the test logic code is used for indicating the chip test logic; and the test data comprises test vectors and expected results. The running of the hardware execution file to generate the chip test results comprises: loading the hardware execution file; driving the first chip to be tested based on test driving logic indicated by the hardware execution file; comparing the test result of the first chip based on the test vector with an expected result based on test result comparison logic indicated by the hardware execution file, to obtain a comparison result; generating the chip test result based on the comparison result.

8. The method of claim 7, wherein, The comparison result is obtained by comparing the test result of the first chip based on the test vector with an expected result based on test result comparison logic indicated by the hardware execution file, and includes: a first comparison result is obtained when the test result meets a verification condition, and the first comparison result is used to indicate that the first chip passes the test based on the test vector; a second comparison result is obtained when the test result does not meet the verification condition, and the second comparison result is used to indicate that the first chip fails the test based on the test vector.

9. The method of claim 7, wherein, The chip test result is generated based on the comparison result, and includes: test statistics are generated based on the comparison result, the test statistics including at least one of test coverage, error record, and pass rate, the test coverage being used to indicate a coverage degree of the test vector on the function of the first chip, the error record being used to indicate test information of the first chip failing the test based on the test vector, and the pass rate being used to indicate a proportion of the first chip passing the test based on the test vector; the chip test result is generated based on the test statistics.

10. A chip testing apparatus characterized by comprising: The apparatus includes: a processing module configured to obtain structured description data based on a standard test description file of a first chip, the standard test description file being used to describe test requirements of the first chip; the processing module is further configured to inject the structured description data into an environment template to obtain a verification environment, the verification environment being a program used to carry chip test logic, and the environment template being a preset test logic program framework; a test module configured to drive the first chip to be tested based on the verification environment, to obtain a chip test result.

11. A computer device, comprising: The computer device includes a processor and a memory, and the memory stores at least one computer program, which is loaded and executed by the processor to implement the chip test method according to 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 the processor to implement the chip test method according to any one of claims 1 to 9.

13. A computer program product, characterised in that, The computer program is executed by the processor to implement the chip test method according to any one of claims 1 to 9.

Images