Test vector file generation method and apparatus, electronic device, chip, and medium

Abstract

The application provides a test vector file generation method and device, electronic equipment, a chip and a medium, and relates to the chip verification technical field. The method comprises the following steps: embedding fast simulation code in original simulation code of a to-be-tested chip to obtain target simulation code; performing simulation verification on the to-be-tested chip based on the target simulation code, generating a simulation log containing key test information, and generating a test vector file according to the simulation log. By adding macro-enabled fast simulation branch code in the to-be-tested chip verification case simulation code, a simulation log containing necessary information required for testing can be quickly formed, the simulation time is effectively reduced, and the test vector file is generated by using the simulation log, so that the processing complexity can be effectively reduced.

Description

Technical Field

[0001] This application relates to the field of chip verification technology, and in particular to a method, apparatus, electronic device, chip, and medium for generating test vector files. Background Technology

[0002] With the rapid development of integrated circuit design and manufacturing technologies, system-on-chip (SOC) design is becoming increasingly complex, and chip testing has become a critical link in ensuring product quality. Chip testing includes functional verification during the chip design phase and functional testing using Automated Test Equipment (ATE) after manufacturing. Since the testing objectives of the two are consistent and the stimulus content highly overlaps, converting verified SOC simulation stimulus into test vector files required by ATE has become an important industry requirement in order to achieve test reuse, improve efficiency, and reduce costs.

[0003] Currently, there are three main ways to generate test vector files: one is to use tools to automatically generate them based on the Design for Test (DFT) structure; the second is to directly extract stimulus information from the SOC verification test case file; and the third is to generate them by parsing the complete waveform or complete simulation log file generated by the SOC verification test case simulation.

[0004] However, using tools to generate test vector files is only applicable to structured test items, and cannot generate functional test vectors solely from the DFT structure. Generating test case files based on SOC involves multi-level calling relationships, and the associated files and directory structures are cumbersome, resulting in high processing complexity. Furthermore, generating complete waveforms or complete log files from SOC-based test case simulations is time-consuming and lacks flexibility. Summary of the Invention

[0005] This application provides a test vector file generation method, apparatus, electronic device, chip, and medium to solve problems in related technologies. By adding fast simulation branch code to the simulation code of the verification test cases of the chip under test, a simulation log containing key information required for testing can be quickly generated, effectively reducing simulation time. Using the simulation log to generate test vector files can effectively reduce processing complexity.

[0006] The first aspect of this application proposes a method for generating test vector files. The method includes: embedding fast simulation code into the original simulation code of the chip under test to obtain target simulation code, wherein the fast simulation code is used to replace the simulation-driven operation in the target simulation code and directly output key test information during the execution of the target simulation code; performing simulation verification on the chip under test based on the target simulation code to generate a simulation log containing key test information, thereby generating a test vector file based on the simulation log, wherein the test vector file is used to perform automated functional testing on the manufactured chip under test.

[0007] In some embodiments of this application, embedding fast simulation code into the original simulation code of the chip under test to obtain target simulation code includes: performing simulation verification on the original simulation code of the chip under test to obtain the verification result of the original simulation code; when the verification result of the original simulation code is that the verification is passed, determining the key operation code in the original simulation code; embedding fast simulation code into the key operation code to obtain target simulation code, wherein the key operation code is the test simulation operation code for the chip under test.

[0008] In some embodiments of this application, the simulation verification of the chip under test based on the target simulation code and the generation of simulation logs containing key test information include: executing the target simulation code in response to the simulation execution signal for simulating the chip under test; collecting key test information output by the fast simulation code according to the call time of the fast simulation code during the execution of the target simulation code, and generating simulation logs.

[0009] In some embodiments of this application, generating a test vector file from a simulation log includes: extracting key test information from the simulation log using a preset extraction tool; and generating a test vector file based on the key test information, wherein the test vector file includes a test vector file in a first format and / or a test vector file in a second format.

[0010] In some embodiments of this application, generating a test vector file based on key test information includes: obtaining a pin information file of the chip under test, wherein the pin information file is a pin mapping and attribute configuration file predefined according to the chip design; generating a test vector file in a first format based on the key test information and the pin information file; and converting the test vector file in the first format into a test vector file in a second format using a preset file conversion tool.

[0011] In some embodiments of this application, after generating a test vector file based on the simulation log, the method includes: performing simulation verification on the verification code to obtain the verification result of the verification code, wherein the verification code is obtained during the generation of the test vector file; when the verification result of the verification code is unverified, identifying the abnormal step in the test vector file generation process; correcting the abnormal step to obtain the corrected update step; performing simulation verification on the chip under test based on the update step and the target simulation code to generate an updated simulation log containing key test information, so as to generate an updated test vector file based on the updated simulation log; when the verification result of the verification code is verified, determining the test vector file as the target test vector file.

[0012] A second aspect of this application provides a test vector file generation apparatus, the apparatus comprising:

[0013] The embedding unit is used to embed fast simulation code into the original simulation code of the chip under test to obtain the target simulation code. The fast simulation code is used to replace the simulation-driven operation in the target simulation code and directly output key test information during the execution of the target simulation code.

[0014] The generation unit is used to perform simulation verification of the chip under test based on the target simulation code, generate simulation logs containing key test information, and generate test vector files based on the simulation logs. The test vector files are used to perform automated functional testing on the manufactured chip under test.

[0015] A third aspect of this application provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the methods described in the first aspect of this application.

[0016] A fourth aspect of this application provides a chip including one or more interface circuits and one or more processors; the interface circuits are configured to receive signals from the memory of an electronic device and send signals to the processors, the signals including computer instructions stored in the memory, which, when executed by the processors, cause the electronic device to perform the methods described in the first aspect of this application.

[0017] A fifth aspect of this application provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the methods described in the first aspect of this application.

[0018] In summary, the test vector file generation method proposed in this application involves embedding fast simulation code into the original simulation code of the chip under test (DUT) to obtain target simulation code. This fast simulation code replaces the simulation-driven operations in the target simulation code during execution, directly outputting key test information. Simulation verification of the DUT is performed based on the target simulation code, generating a simulation log containing key test information. This simulation log is then used to generate a test vector file for automated functional testing of the manufactured DUT. This process effectively reduces simulation time by replacing the time-consuming stimulus-driven operations with the printing of key test information. Furthermore, subsequent modifications and iterations to obtain the simulation log and generate the test vector file do not require the entire verification simulation time, thus effectively reducing processing complexity and improving flexibility.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application, and do not constitute an undue limitation of this application.

[0021] Figure 1 A flowchart illustrating a test vector file generation method provided in this application embodiment;

[0022] Figure 2 A flowchart illustrating the second test vector file generation method provided in this application embodiment;

[0023] Figure 3 A flowchart illustrating the third test vector file generation method provided in this application embodiment;

[0024] Figure 4 A flowchart illustrating a test vector file generation scheme provided in this application embodiment;

[0025] Figure 5 A schematic diagram illustrating a script file calling relationship provided in an embodiment of this application;

[0026] Figure 6 A schematic diagram of a test vector file generation device provided in an embodiment of this application;

[0027] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0028] Figure 8 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0029] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0030] With the rapid development of VLSI design and manufacturing technology, the integration and complexity of System-on-a-Chip (SoC) are increasing exponentially. To ensure the correctness of chip functionality and reduce overall production costs, chip testing is a crucial guarantee link from chip R&D to mass production. Chip testing is generally divided into two core stages: front-end design verification and back-end production testing. The front-end verification stage is conducted in a SoC system-level verification environment, based on a full-chip-level Design under Test (DUT). The back-end further confirms the chip's functional effectiveness after chip manufacturing using Equipment for Test and Analysis (ATE). Since the goals of ATE functional testing and SoC system-level functional verification are highly consistent, and the stimulus content required for ATE functional testing is basically the same as the simulation stimulus for SoC testability functional verification, converting the verified SoC simulation stimulus into the test vector files required by ATE has become an important industry requirement.

[0031] Currently, the technical paths for generating the functional test vector files required for ATE (Automatic Test Equipment) can be mainly divided into the following three categories:

[0032] Automatic generation by tools: Primarily based on the DFT structure, it uses tools such as Synopsys TetraMax and Mentor Tessent to automatically generate test vector files in the format required by ATE.

[0033] SOC verification test case file generation: Utilizing the consistency between SOC testability function verification and ATE stimulus content, for SOC verification test case files that have been verified as reliable through simulation, the stimulus information can be extracted through scripts and converted into test vector files in the format required by ATE.

[0034] SOC simulation generates complete waveform or log files: First, run the SOC verification test case simulation to generate waveform files in formats such as VCD (Value Change Dump) (containing information on all signal changes over time). Then, use a script to extract the excitation vectors and expected outputs of the outer pins; or generate a complete log file (containing all excitation inputs and expected outputs), extract the valid content from it, and use a script to parse and generate the test vector file in the format required by the ATE.

[0035] As can be seen, the relevant technologies can all automatically generate the test vector files required for ATE testing, but the following shortcomings still exist:

[0036] The tool's automatic generation has strong limitations: it is only applicable to structured test items. For functional test items involving different functional configuration processes of self-developed or third-party IP (Internet Protocol, Internet of Things Protocol), it is not possible for the tool to automatically generate test vectors solely from the DFT structure.

[0037] High processing complexity: The SOC verification test case file is a service simulation verification, which has a multi-level calling relationship and a complicated associated file and directory structure, resulting in high processing difficulty and low conversion efficiency when the script extracts incentive information.

[0038] High time cost and poor flexibility: Generating test vector files from complete waveforms or complete log files requires performing a complete SOC verification test case simulation every time a test vector is generated or modified. For test vectors with long simulation times (a single simulation can take several days to several weeks), the time cost is extremely high. Moreover, when there are subtle differences between ATE test requirements and SOC verification, the simulation results need to be processed additionally, making it difficult to adapt quickly and resulting in a serious lack of flexibility.

[0039] To address the aforementioned issues, this application proposes a test vector file generation method. This method embeds macro-enabled rapid simulation code into the original simulation code of the verified chip under test (DUT), replacing time-consuming stimulus-driven operations with the printing of key test information. Simulation is then performed, generating a rapid simulation log containing key test information. A script is used to extract the key test information from the simulation log, thereby generating the test vector file required by the ATE (Automatic Test Array). In this process, the simulation log prints the necessary information for the test vector in the order of call time. Furthermore, obtaining the simulation log does not require each complete verification simulation, significantly improving simulation efficiency, reducing the processing complexity of modifying and iterating to generate test vector files, and increasing flexibility.

[0040] The method for generating test vector files provided in this application will be described in detail below with reference to the accompanying drawings.

[0041] Figure 1 This is a flowchart illustrating a method for generating test vector files according to an embodiment of this application. Figure 1 As shown, the test vector file generation method includes steps 101-102.

[0042] Step 101: Embed fast simulation code into the original simulation code of the chip under test to obtain target simulation code. The fast simulation code is used to replace the simulation-driven operation in the target simulation code and directly output key test information during the execution of the target simulation code.

[0043] In the embodiments of this application, the chip under test refers to a system-on-a-chip (i.e., SOC). The original simulation code is the complete code used for functional verification during the SOC verification stage (including DUT model, stimulus generation, timing drive, monitoring and comparison logic, etc.).

[0044] The fast simulation code is a fast simulation branch enabled by macro definitions. That is, in the underlying tasks called by the basic operations, the stimulus-driven operations that occupy simulation time are replaced by macro definitions to print out only key test information, so as to quickly generate simulation logs containing key information required by ATE test vectors.

[0045] Specifically, before developing rapid simulations enabled by macro definitions, it is essential to ensure the SOC verification environment is stable, meaning that module connections, timing models, and basic functions are normal, and the SOC verification test cases corresponding to the required test vectors have passed simulation. After successful simulation verification, the stimulus content of the SOC verification test cases for the testability function is largely reusable. Only at the differences in the original simulation code (parts that only serve SOC verification and are not suitable for ATE test vector requirements), a rapid simulation branch controlled by macros is added to the key operation tasks (the basic operation tasks required for ATE testing). This allows subsequent simulations to avoid executing real signal-driven or redundant debugging, and instead directly output the key test information required by the ATE test vectors through log output.

[0046] Among them, key test information refers to the operation information corresponding to keywords that can be recognized by the script, including writing to the IR (Instruction Register), writing to the DR (Data Register), reading the DR and comparing it with the expected value, assigning values ​​to pins, and waiting for multiple test clock cycles, etc.

[0047] Step 102: Perform simulation verification on the chip under test based on the target simulation code, generate a simulation log containing key test information, and generate a test vector file based on the simulation log.

[0048] In embodiments of this application, the test vector file is used for automated functional testing of the manufactured chip under test. The target simulation code includes original SOC verification test case simulation code and rapid simulation code controlled by macro definitions.

[0049] Specifically, the simulation is started based on the target simulation code. When the macro is enabled (i.e., the macro branch is manually triggered through the compilation options), the sequence creation and signal driving operations in the original simulation code are skipped, and only log printing is performed. The output contains structured information containing keywords (such as IR, DR, etc.) and key parameters (such as keyword length, value, etc.), generating the simulation log.

[0050] After obtaining simulation logs through rapid simulation during SOC verification, the conversion from simulation logs to test vector files recognizable by the ATE test environment can be achieved using a corresponding Python script. The script identifies and extracts corresponding operation information from the logs based on keywords, thereby converting this key test information into test vector files in the format required for ATE testing.

[0051] In summary, the test vector file generation method proposed in this application involves embedding fast simulation code into the original simulation code of the chip under test (DUT) to obtain target simulation code. This fast simulation code replaces the simulation-driven operations in the target simulation code during execution, directly outputting key test information. Simulation verification of the DUT is performed based on the target simulation code, generating a simulation log containing key test information. This simulation log is then used to generate a test vector file for automated functional testing of the manufactured DUT. This process effectively reduces simulation time by replacing the time-consuming stimulus-driven operations with the printing of key test information. Furthermore, subsequent modifications and iterations to obtain the simulation log and generate the test vector file do not require the entire verification simulation time, thus effectively reducing processing complexity and improving flexibility.

[0052] As one possible implementation method, Figure 2 A flowchart of the second method for generating test vector files is shown. Figure 2 based on Figure 1 The illustrated embodiment further defines steps 101 and 102. Figure 2 In the illustrated embodiment, step 101 includes steps 201, 202, and 203, and step 102 includes steps 204, 205, 206, and 207. Figure 2 As shown, the method includes the following steps:

[0053] Step 201: Perform simulation verification on the original simulation code of the chip under test to obtain the verification result of the original simulation code.

[0054] In the embodiments of this application, before macro definition, it is necessary to perform simulation verification on the chip under test based on the original simulation code of the chip under test (i.e., SOC verification test case simulation code) to ensure that the original simulation code can correctly simulate the chip function (such as JTAG (Joint Test Action Group) interface, IP module interaction conforming to design specifications), and that the test-related logic in the code (such as writing IR / DR, PIN control) has no functional errors.

[0055] Once the simulation results from the original simulation code are correct, the development of the macro-defined rapid simulation branch can then proceed.

[0056] Step 202: When the verification result of the original simulation code is "verification passed", determine the key operation code in the original simulation code.

[0057] In the embodiments of this application, critical operation code refers to the operation logic in the original simulation code that is directly related to the generation of ATE test vectors, i.e., the core operation code for testing and simulating the chip, for example:

[0058] Operations related to the test protocol (such as JTAG write IR, write DR, read DR and compare with expected value, etc.).

[0059] PIN assignment operations (such as setting specific pin levels, configuring input / output directions, etc.);

[0060] Waiting for test clock cycle operations (such as waiting for clock edge, delay control, etc.).

[0061] These key operations are the core of ATE testing, and test vectors must accurately reproduce these operations.

[0062] It is worth noting that the tasks of writing IR, writing DR, reading DR and comparing with expected value in the JTAG protocol are defined in dfx_api, while the tasks of PIN assignment and waiting for test clock cycles are defined in io_uvc.

[0063] Step 203: Embed rapid simulation code within the key operation code to obtain the target simulation code.

[0064] In the embodiments of this application, a fast simulation branch is added to the already located key operation code through macro definition. That is, under the key operation task, macro control can be performed using conditional compilation instructions to form target simulation code in which the original operation logic and fast simulation logic coexist.

[0065] When the target simulation code is executed, if the macro is invalid, the operation logic of the original simulation code will be executed (i.e., the actual driving sequence will be executed and key test information will be printed out); if the macro is valid, only the key test information will be printed out and the actual driving sequence will not be executed to save simulation time.

[0066] It should be noted that in actual ATE testing of physical chips, it is not suitable to rely on the real-time return value of read operations to determine the next action (this is different from SOC simulation). For example, in SOC simulation, the verification test case can execute the "read until / polling" operation, but ATE testing relies on pre-generated fixed test vectors. Each step of the test vector is predefined and cannot be dynamically adjusted based on the real-time return value as in simulation. Therefore, the read operation in the original verification test case needs to be specially processed, that is, the waiting time is specified and the expected value and mask are preset. The waiting operation and the read operation with the expected value are replaced with the read operation with the mask value. By waiting for a fixed number of clock cycles / duration to replace the uncertain number of polling, the timing of ATE testing is guaranteed to be predictable.

[0067] Additionally, during the execution of SOC verification test cases, certain explanatory text (such as test steps, precautions, etc.) needs to be retained as comments in the final generated test vector file. This can be achieved by adding the keyword "[macro name]" for the script that converts logs to test vector files to recognize. It should be noted that the print level in SOC rapid simulation mode must be at least UVM_LOW to avoid the loss of operation information in the rapid simulation log due to insufficient print levels.

[0068] Step 204: In response to the simulation execution signal for simulating and verifying the chip under test, execute the target simulation code.

[0069] In the embodiments of this application, the target simulation code is code with embedded macro definitions in a fast simulation branch. Upon receiving an execution signal, the target simulation code runs according to a preset test procedure, i.e.:

[0070] If macros are enabled, the fast simulation branch will be executed, and the simulation will focus on outputting key test information.

[0071] If macros are not enabled, normal simulation logic will be executed, that is, the actual driving sequence will be executed, and relevant operation information will be printed out.

[0072] Step 205: During the execution of the target simulation code, collect key test information output by the fast simulation code according to the call time of the fast simulation code, and generate simulation logs.

[0073] In the embodiments of this application, key test information refers to the structured information related to ATE testing output by the rapid simulation code, such as JTAG operations (IR / DR read / write operations), pin drivers, waiting timings, etc., including operation type, parameters, time points, etc.

[0074] Each call to the rapid simulation code (such as executing the write IR task, write DR task, etc.) corresponds to a specific step in the test process. The logs will record information strictly according to the execution order (time sequence) of these steps, rather than being arranged randomly.

[0075] Finally, all key test information collected in chronological order will be compiled into a complete simulation log file.

[0076] Step 206: Use the preset extraction tool to extract key test information from the simulation log.

[0077] In the embodiments of this application, the preset extraction tool refers to a Python script, which is a pre-written automated tool that can accurately filter out key test information related to ATE test vector generation from messy simulation logs and filter out irrelevant and redundant logs.

[0078] The script can identify the following types of operations corresponding to specific keywords: write IR, write DR, read DR and compare with the expected value, assign a PIN value, and wait for multiple test clock cycles. It identifies and extracts the operation information corresponding to the keywords through keyword matching, regular expression parsing, etc. At the same time, the script will parse the core parameters in this information (such as register bit width and value, pin name and level, number of clock cycles to wait, etc.).

[0079] Step 207: Generate test vector files based on key test information. The test vector files include test vector files in a first format and / or test vector files in a second format.

[0080] In the embodiments of this application, the first format of the test vector file refers to the SVF (Serial Vector Format) format, and the second format refers to the STIL (Standard Test Interface Language) format. The SVF format is more readable, while the STIL format has a more complex syntax and more precise description. It is understood that the two formats of test vector files can be selected according to actual needs in subsequent ATE testing, and this embodiment of the application does not impose any restrictions.

[0081] This application, based on key test information, generates test vector files by including: obtaining the pin information file of the chip under test, wherein the pin information file is a pin mapping and attribute configuration file predefined according to the chip design; generating a test vector file in a first format based on the key test information and the pin information file; and using a preset file conversion tool to convert the test vector file in the first format into a test vector file in a second format.

[0082] In the embodiments of this application, the pin information file is formed based on the mapping relationship of each pin of the chip under test (such as the corresponding association between pins and internal circuit modules) and the initial state values ​​(such as default level, enable state, etc.).

[0083] Specifically, the structured data (i.e., key test information) extracted from the simulation log by the Python script contains all the core operations required for ATE testing. The script calls the pin information file of the chip under test and uses it as input. Then, according to the syntax rules of SVF (Single Format First), it maps the key test information into specific operation instructions corresponding to the pin attributes, and finally generates a test vector file in SVF format.

[0084] Using a pre-defined file conversion tool (such as Tessent), an SVF file can be input to generate a STIL test vector file.

[0085] In summary, this application achieves a rapid simulation branch by embedding macro definitions into the original code of the SOC verification test cases that have been verified by simulation. The target simulation code controlled by the macros is executed in response to the simulation execution signal to generate a simulation log containing key test information. Based on the simulation log, a test vector file in the format required by ATE is generated, which greatly improves the speed of simulation log generation and effectively reduces the processing complexity.

[0086] As one possible implementation method, Figure 3 A flowchart of the third method for generating test vector files is shown. Based on the above embodiments, after generating the test vector file from the simulation log, the following steps are included:

[0087] Step 301: Perform simulation verification on the verification code to obtain the verification result of the verification code.

[0088] In the embodiments of this application, the verification code is obtained during the generation of the test vector file. That is, when the preset file conversion tool (such as Tessent tool) generates the STIL format file based on the pin information file and the SVF format file, it will generate a set of Verilog language stimulus files and a matching simple simulation environment VTB (Verilog TestBench, Verilog test platform) (corresponding to the verification code in this application).

[0089] Specifically, when the Tessent tool generates a VTB, it strictly follows the logic and timing of the input SVF format file, directly converting the operations in the test vector (such as JTAG instructions and PIN level control) into Verilog executable stimulus code. This ensures the consistency between the VTB stimulus and the SVF / STIL file stimulus. Therefore, if the VTB simulation is correct, the correctness of the SVF / STIL file can be confirmed, and the consistency between the test vector file and the SOC verification test case can be indirectly checked.

[0090] Step 302: When the verification result of the verification code is that the verification failed, identify the abnormal step in the test vector file generation process.

[0091] In the embodiments of this application, if the verification code fails (i.e., VTB simulation fails), it indicates that the currently generated test vector file has a substantial defect (such as logical errors, operation timing conflicts, data value errors, etc.). At this time, a reverse tracing mechanism needs to be initiated to locate the abnormal step in the test vector file generation process that caused the problem. Specifically, this may include:

[0092] 1) Source inspection: Check whether the SOC verification test cases accurately describe the test scenario and whether the simulation logs completely record key test information;

[0093] 2) Intermediate conversion check: Check whether the pin information (such as signal direction and timing parameters) is correctly mapped when the Python script parses the simulation log to generate the SVF file, and whether there are any script logic vulnerabilities that may cause data loss or incorrect conversion;

[0094] 3) Format conversion check: Check whether the conversion is abnormal due to incomplete pin information file (such as missing electrical properties) when the Tessent tool converts SVF files to STIL, and whether there are any tool configuration errors.

[0095] Step 303: Correct the abnormal steps to obtain the corrected update steps.

[0096] In the embodiments of this application, targeted measures need to be taken to correct the anomalies located in step 302: for example, if the problem originates from the SOC verification test case, the verification test case logic needs to be corrected and the simulation log regenerated; if the problem originates from a script parsing error, the mapping rules of the Python script need to be optimized (such as fixing the pin information association vulnerability); if the problem originates from an abnormal conversion of the Tessent tool, the missing parameters of the pin information file need to be supplemented or the tool configuration needs to be adjusted (such as timing constraint parameters).

[0097] The revised steps form an update process to ensure that the output of each step in the test vector file generation process meets the expected standards (such as complete simulation logs, accurate SVF mapping, and STIL format compliance).

[0098] Step 304: Based on the update steps and target simulation code, perform simulation verification on the chip under test, generate an updated simulation log containing key test information, and generate an updated test vector file based on the updated simulation log.

[0099] In the embodiments of this application, the essence of this step is iterative optimization, that is, through a closed loop of "correction, regeneration, and re-verification", defects in the test vectors are gradually eliminated to ensure that the newly generated test vector files meet the requirements of logical correctness and timing matching.

[0100] Specifically, after correcting the abnormal steps, the entire process of generating test vector files needs to be re-executed, which means re-simulating and verifying the chip under test based on the target simulation code to generate an updated simulation log containing complete key test information; then, through steps such as script parsing and Tessent tool conversion, an updated SVF / STIL format test vector file and its corresponding VTB are generated.

[0101] Through continuous iterative optimization, we ultimately ensure that the correct test vector files that meet the requirements of ATE are generated.

[0102] Step 305: When the verification result of the verification code is that the verification is successful, the test vector file is determined as the target test vector file.

[0103] In the embodiments of this application, if the verification code passes (i.e., the VTB simulation is successful), it indicates that the logic of the test vector file is consistent with the chip design requirements, and it can be determined as the final target test vector file (SVF / STIL format) and formally delivered to the ATE team for physical chip testing and production.

[0104] To further explain the entire process of generating test vector files, please refer to [further details]. Figure 4 , Figure 4 This is a flowchart illustrating a test vector file generation scheme provided in an embodiment of this application.

[0105] Reference Figure 4 The generation of test vector files involves three stages:

[0106] SOC rapid simulation phase: In the test platform, modules such as LIB (basic function library), API (application programming interface), UVC (general verification component for standardized stimulus generation), and VSQR (vector sequencer for managing the timing and logic of test vectors) are combined to perform rapid simulation verification of the chip under test (SOC) using the target simulation code and generate simulation log files.

[0107] Test vector file generation phase: The simulation log file generated during the SOC rapid simulation phase is used as input to a Python script for preprocessing, generating an intermediate format file (SVF). The Tessent tool is then used to generate STIL format test vector files based on the SVF file. Further processing (post-processing, such as timing adjustments and format adaptation) of the test vector files output by the Tessent tool is performed to ensure that the test vector files meet the requirements of subsequent ATE tests.

[0108] Simulation verification stage of test vector files: In the test platform, using modules such as VTB (Verilog test platform, corresponding to the verification code of this application, used for simulation verification of test vectors) and tb_patch (test platform patch) generated by the Tessent tool, the chip under test is simulated and verified again (to verify the correctness of the generated test vector files) to determine whether the simulation passes:

[0109] If it fails (No), proceed to the debugging stage, backtrack to check for problems with the test vectors or the design of the chip under test, correct them, and then re-execute the process;

[0110] If successful, the test vector file will be stored in the Git Lib (version control library, which stores valid test vector files for easy version tracking and reuse).

[0111] Subsequent ATE testing will retrieve the simulated test vector files from the GIT Lib to test the physical chip. If the final verification result fails (No), the debugging phase will resume to troubleshoot hardware or test vector issues. If the final verification result passes (Yes), it proves that the test vector is officially effective and can be used for chip mass production testing.

[0112] It should be noted that in chip system-level verification projects, dedicated files related to the test vector file generation process are stored under the path $SOCDV_PROJ / src / verif / meta / pattern / , including Python script files, VTB simulation files, etc. The calling relationship of the Python script files is as follows: Figure 5 As shown, Figure 5 This is a schematic diagram illustrating a script file calling relationship provided in an embodiment of this application.

[0113] Reference Figure 5 The script files include runpat.py (responsible for option parsing, calling step-by-step processing tasks, etc.), PatFlow.py (used to call SOC simulation instructions, log parsing scripts, Tessent tools, VTB simulation instructions, etc.), and GenSvf.py (containing key operations such as writing IR, writing DR, reading DR and comparing with expected values, PIN assignment, waiting for multiple test clock cycles, etc.).

[0114] The generated file is case_pattern.svf, which ultimately generates an SVF format file containing various test vector related modes, such as JTAG related test vector modes (IR / DR read / write), test vector modes related to the chip's PIO (Parallel Input / Output) interface (PIO mode), delay mode, comment mode, etc.

[0115] The `runpat.py` script is the top-level execution script in the test vector file generation process. Its main functions include obtaining, parsing, and passing supported execution command parameters, as well as scheduling and calling functions in other scripts. At different stages of the execution process, `runpat.py` will call the corresponding tasks in `GenSvf.py` or `PatFlow.py` as needed, thereby driving the orderly progress of the entire test vector generation process.

[0116] The PatFlow.py script file defines the core components of the test vector file generation process, including the specific operation functions, tool call instructions, and basic file processing functions required during the process.

[0117] The core function of the GenSvf.py script is to extract key test operation information from the simulation log file and combine it with the pin mappings and initial values ​​defined in the PIO-related files to finally generate a compliant SVF test vector file. Currently, this script supports identifying and matching the following types of key operation keywords in the simulation log, each corresponding to a specific test operation logic:

[0118] Write IR: Performs a write operation on the instruction register of the JTAG interface;

[0119] Write DR: Performs a write operation on the data register of the JTAG interface;

[0120] Read DR and compare with expected value: Read the value of the data register and verify that it matches the expected value;

[0121] PIN assignment: Apply a voltage level (such as high or low) to the pin.

[0122] Waiting for multiple test clock cycles: Waiting for multiple rising edges of the test clock to meet timing wait requirements;

[0123] Insert SVF comment information: Insert comments into the generated SVF file to identify the testing phase or key nodes, improving file readability.

[0124] The various operation keywords identified by the script will be converted into specific instruction statements according to the SVF format specification and finally written into the SVF test vector file.

[0125] In addition, three PIO files—pio_chip, pio_pkg, and pio_init (organized according to the chip pin mapping relationship and initial values ​​in the project)—are necessary inputs for converting simulation log files into SVF files, and are called by GenSvf.py. The pin names in pio_chip and pio_pkg are mapped one-to-one, determining the pin name mapping relationship between the chip level and the package level. pio_init contains necessary input pin initial value information; the pin initial values ​​and their corresponding chip-level pin names are written to the SVF file, ensuring that the ATE can configure the chip pins according to the preset initial values ​​at the start of the test, simulating the initial state of real operation and avoiding test deviations due to incorrect initial states.

[0126] The dft_tool / directory contains files related to chip information and DFT (Design for Testability) structure. When the chip system-level verification project (the project root directory specified by the $SOCDV_PROJ environment variable) changes, the following chip information or DFT structure related files need to be updated:

[0127] src / verif / meta / pattern / dft_tool / COMMON / Common_ClockAlias_DV.proc;

[0128] src / verif / meta / pattern / dft_tool / COMMON / Common_Setup_Clocks_DV.dof;

[0129] src / verif / meta / pattern / dft_tool / COMMON / Common_Setup_PinCons_DV.dof;

[0130] src / verif / meta / pattern / dft_tool / COMMON / Common_Timeplates_DV.proc;

[0131] src / verif / meta / pattern / dft_tool / svf2stil / chip_top.icl;

[0132] src / verif / meta / pattern / dft_tool / svf2stil / chip_top.v;

[0133] src / verif / meta / pattern / dft_tool / svf2stil / svf2stil.dof.

[0134] The files Common_ClockAlias_DV.proc, Common_Setup_Clocks_DV.dof, Common_Setup_PinCons_DV.dof, and Common_Timeplates_DV.proc are some general configuration files. chip_top.icl is the input control file for SVF to STIL conversion, chip_top.v is the top-level RTL (Register Transfer Level) file, and svf2stil.dof is the input file when calling the tessent tool. These files are used in the SVF to STIL conversion process and are provided by the DFT team.

[0135] Under the path $SOCDV_PROJ / src / verif / meta / pattern / , there are several files required for the VTB simulation process, which are unrelated to the generation process of SVF and STIL files. Details are as follows:

[0136] The comp_post_dfx.flist file is a list of files for the full-chip RTL of the post-DFT (post_dft) version, and the top-level modules specified therein must match the compilation options in svf2stil.dof and PatFlow.py;

[0137] The dump.do file is used to define the waveform capture hierarchy information during the VTB simulation process, and its configuration can be modified according to debugging needs.

[0138] tb_patch.v is a VTB supplement file shared by test vectors and is included in the top-level module of the VTB. The file contains clock generation logic, waveform dump code, power signal assignments, data external loopback pin pad connections, and signal forced operations that need to be added due to simulation environment limitations.

[0139] The `synopsys_sim.setup` file is used to configure the compilation result paths for the Design Under Test (DUT) and Test Platform (TB) during VTB simulation. Currently, the DUT path points to the public directory ` / project / dv / prj_dorstar / centrals / soc_dv / pattern / PreCompIp / work`. Since the RTL design in the test vector stage is stable, the DUT can be compiled and reused independently without repeated modifications. Its compilation result (work library) is stored in the public directory and is automatically called during VTB compilation. Ordinary users do not need to concern themselves with these details; management is solely the responsibility of maintenance personnel.

[0140] The `dfx_test / ` directory is automatically created after the test vector file generation process is executed, and is used to store the generated SVF and STIL files. Within this directory, a separate subdirectory is created for each test vector (pattern), containing the relevant files generated for that test vector.

[0141] Finally, based on the above documents, regarding Figure 4 The usage instructions for the test vector file generation process shown are as follows:

[0142] Specifically, all operations in the test vector file generation process are performed by calling... Figure 5 The top-level script `runpat.py` is executed within the system. The environment setup command is abbreviated as: `alias runpat "python . / src / verif / meta / pattern / script / runpat.py"`. Because timing-accurate STIL files are large, and each test vector's corresponding independent VTB environment and simulation waveform file requires significant storage space, sufficient server memory must be ensured before batch execution of test vector generation and VTB simulation.

[0143] The available execution parameters are as follows:

[0144] -t dfx_test: ssm_thm_trimming: Specifies the name of the SOC verification test case corresponding to the current test vector;

[0145] -q regression: Specifies the command execution queue as regression. This parameter will be passed synchronously to the -q and -cq options of the SOC simulation call command.

[0146] -sim_only 1: Enable the sim_only option. When calling the SOC environment for fast simulation, only the simulation steps will be executed, and compilation will not be repeated (compilation is required by default).

[0147] -dbg 1: Enables waveform dump function (which records detailed data of circuit signal changes during simulation and saves it as a waveform file in a specific format), applicable to two scenarios: generating simulation logs for SOC verification test cases and VTB simulation (waveform dump is not enabled by default).

[0148] The single-step operation commands for the test vector file generation process are as follows:

[0149] (1) genlog (generate simulation log): calls simulation commands in the SOC environment to perform fast simulation. The generated log results are stored in the same location as the SOC DV (SOC Design Verification) simulation. It supports waveform dumping, and when the SOC verification environment only modifies the C file and has no other changes, the sim_only mode simulation can be enabled. For example, runpat genlog -t dfx_test:ssm_thm_trimming -sim_only 1 -dbg 1;

[0150] (2) log2svf (log to SVF file): In the $SOCDV_PROJ / dfx_test directory, create a subdirectory (i.e., VTB path) with the current test vector name; read the simulation log file generated by genlog, parse it, generate an SVF file, and store it in the $SOCDV_PROJ / src / verif / meta / pattern / dfx_test / casename subdirectory. After verification, it can be used as the test vector file delivered to ATE (corresponding to the target test vector file in this application). For example, runpat log2svf -tdfx_test: ssm_thm_trimming;

[0151] (3) svf2stil (SVF to STIL file): This function calls the Tessent tool, combining the SVF file with other configuration files in the dft_tool directory (such as chip information, constraint files, etc.), to generate a timing-accurate STIL file and VTB-related Verilog files (used for test vector simulation to verify the correctness of the corresponding STIL stimuli). The STIL file is ultimately stored in $SOCDV_PROJ / src / verif / meta / pattern / dfx_test / casename. Once verified, it becomes a deliverable target test vector file. For example, runpat svf2stil -t dfx_test: ssm_thm_trimming;

[0152] (4) compvtbfast (VTB test platform compilation): Compiles the VTB test platform (TB), and elaborates the compilation results with the DUT compilation results (the process of simulation tools parsing the design hierarchy and binding modules) to form a complete TB compilation result, which is stored in $SOCDV_PROJ / dfx_test / casename. For example, runpat compvtbfast -tdfx_test: ssm_thm_trimming;

[0153] (5) runsim (execute VTB simulation): Runs the VTB simulation of the current test vector in the $SOCDV_PROJ / dfx_test / casename directory. The generated simulation logs, waveforms, and other result files are stored in this directory. For example, runsim -t dfx_test: ssm_thm_trimming;

[0154] (6) Verdi (view simulation waveform): Invokes the Verdi tool (waveform viewer) to open the waveform file generated by the test vector simulation for debugging and analysis. For example, runpat verdi -t dfx_test: ssm_thm_trimming.

[0155] (7) precomp (DUT standalone pre-compilation): As a pre-operation of (4) compvtbfast, it compiles the DUT separately. It only needs to be executed once (after the process debugging is completed). All subsequent test vector generation processes will automatically reuse the compilation result without repeating the execution. The compilation result path (public path, shared by all users) is: / project / dv / prj_dorstar / centrals / soc_dv / pattern / PreCompIp / work. Example: runpat precomp -t dfx_test:ssm_thm_trimming.

[0156] (8) compvtb (complete VTB compilation): The regular VTB compilation method, without splitting (7) precomp and (4) compvtbfast, directly completes the complete compilation. Example: runpat compvtb -t dfx_test: ssm_thm_trimming.

[0157] In the regular use of the test vector generation process, the above processes (1)-(6) can be executed to complete the entire process of generating test vector files; process (7) is a pre-compilation operation, which only needs to be executed once after the process debugging is completed; process (8) is a simplified compilation method, which can be selected and used according to needs.

[0158] As an optional implementation, the above multiple single-step operations can be merged (i.e., multiple single-step operations can be executed automatically in series without manual step-by-step triggering) to simplify the process call. The specific merge operation command is as follows:

[0159] log2stil: merges (2) and (3), that is, automatically concatenates the single-step operations log2svf and svf2stil. For example, runpat log2stil -t dfx_test: ssm_thm_trimming.

[0160] log2sim: merges (2), (3), (4), and (5), that is, automatically executes single-step operations log2svf, svf2stil, compvtbfast, and runsim in a chain. For example, runpat log2sim -t dfx_test: ssm_thm_trimming.

[0161] svf2sim: Combines (3), (4), and (5), i.e., automatically executes the single-step operations svf2stil, compvtbfast, and runsim in a chain. Example: runpat svf2sim -t dfx_test: ssm_thm_trimming

[0162] runflow: merges (1), (2), (3), (4), and (5), that is, automatically chaining single-step operations genlog, log2svf, svf2stil, compvtbfast, and runsim. For example, runpat runflow -t dfx_test: ssm_thm_trimming.

[0163] In summary, the test vector file generation method provided in this application generates a simulation log containing key test information required for ATE testing by embedding macro-defined rapid simulation branches in the SOC verification test case environment and executing the simulation. By using the printing of key operation information instead of the actual operation-driven sequence, the simulation time can be effectively improved. Then, the key test information of the simulation log is extracted by the script to generate a test vector file in the format required for ATE testing. This method has low maintenance cost, facilitates problem tracing, and effectively reduces processing complexity.

[0164] To implement the above embodiments, this application also provides a test vector file generation apparatus. Figure 6 This is a schematic diagram of a test vector file generation device 600 provided in an embodiment of this application. Figure 6 As shown, the device includes:

[0165] The embedding unit 610 is used to embed fast simulation code into the original simulation code of the chip under test to obtain target simulation code. The fast simulation code is used to replace the simulation drive operation in the target simulation code and directly output key test information during the execution of the target simulation code.

[0166] The generation unit 620 is used to perform simulation verification of the chip under test based on the target simulation code, generate a simulation log containing key test information, and generate a test vector file based on the simulation log. The test vector file is used to perform automated functional testing on the manufactured chip under test.

[0167] In some embodiments of this application, the embedding unit 610 is used to: perform simulation verification on the original simulation code of the chip under test to obtain the verification result of the original simulation code; when the verification result of the original simulation code is that the verification is passed, determine the key operation code in the original simulation code; embed fast simulation code in the key operation code to obtain the target simulation code, wherein the key operation code is the test simulation operation code for the chip under test.

[0168] In some embodiments of this application, the generation unit 620 is configured to: execute target simulation code in response to a simulation execution signal for simulating and verifying the chip under test; and collect key test information output by the fast simulation code according to the call time of the fast simulation code during the execution of the target simulation code, and generate simulation logs.

[0169] In some embodiments of this application, the generation unit 620 is used to: extract key test information from the simulation log using a preset extraction tool; and generate a test vector file based on the key test information, wherein the test vector file includes a test vector file in a first format and / or a test vector file in a second format.

[0170] In some embodiments of this application, the generation unit 620 is used to: obtain the pin information file of the chip under test, wherein the pin information file is a pin mapping and attribute configuration file predefined according to the chip design; generate a test vector file in a first format according to the key test information and the pin information file; and convert the test vector file in the first format into a test vector file in a second format using a preset file conversion tool.

[0171] In some embodiments of this application, the generation unit 620 is configured to: perform simulation verification on the verification code to obtain the verification result of the verification code, wherein the verification code is obtained during the generation of the test vector file; when the verification result of the verification code is unverified, identify the abnormal step in the test vector file generation process; correct the abnormal step to obtain the corrected update step; perform simulation verification on the chip under test based on the update step and the target simulation code to generate an updated simulation log containing key test information, so as to generate an updated test vector file based on the updated simulation log; when the verification result of the verification code is verified, determine the test vector file as the target test vector file.

[0172] Since the apparatus provided in this application corresponds to the methods provided in the above-mentioned embodiments, the implementation of the methods is also applicable to the apparatus provided in this embodiment, and will not be described in detail in this embodiment.

[0173] The methods and apparatus provided in the embodiments of this application have been described above. To implement the functions of the methods provided in the embodiments of this application, the electronic device may include a hardware structure and software modules, and may implement the above functions in the form of a hardware structure, software modules, or a hardware structure plus software modules. One of the above functions may be executed in the form of a hardware structure, software modules, or a hardware structure plus software modules.

[0174] Figure 7 This is a block diagram illustrating an electronic device 700 for implementing the above-described test vector file generation method, according to an exemplary embodiment. For example, the electronic device 700 may be a mobile phone, computer, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0175] Reference Figure 7 The electronic device 700 may include a communication interface 701, capable of interacting with other devices; a processor 702, connected to the communication interface 701 to interact with other devices, used to execute the methods provided by one or more of the above-described technical solutions when running a computer program; and a memory 703, on which the computer program is stored. Specifically, the specific processing procedure of the processor 702 can refer to the test vector file generation method described in the above embodiments of this application.

[0176] Of course, in practical applications, the various components in electronic device 700 are coupled together through bus system 704. It can be understood that bus system 704 is used to realize the connection and communication between these components. In addition to a data bus, bus system 704 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, in... Figure 7The general designated all buses as Bus System 704.

[0177] The memory 703 in this embodiment is used to store various types of data to support the operation of the electronic device 700. Examples of such data include any computer program used to operate on the electronic device 700.

[0178] The methods disclosed in the embodiments of this application can be applied to processor 702, or implemented by processor 702. Processor 702 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 702 or by instructions in the form of software. The processor 702 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 702 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory 703. Processor 702 reads the information in memory 703 and combines its hardware to complete the steps of the aforementioned method.

[0179] In an exemplary embodiment, the electronic device 700 may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned method.

[0180] Embodiments of this application also propose a chip, such as Figure 8As shown, the chip includes one or more interface circuits 801 and one or more processors 802; the interface circuits are used to receive signals from the memory of the electronic device and send signals to the processors, the signals including computer instructions stored in the memory, and when the processor executes the computer instructions, it causes the electronic device to execute the test vector file generation method described in the above embodiments of this application.

[0181] Embodiments of this application also propose a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the test vector file generation method described in the above embodiments of this application.

[0182] Embodiments of this application also propose a computer program product, including a computer program that is executed by a processor using the test vector file generation method described in the above embodiments of this application.

[0183] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0184] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0185] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0186] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processing module, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (control method), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic device, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0187] It should be understood that various parts of the embodiments of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0188] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0189] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc.

[0190] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for generating test vector files, characterized in that, The method includes: Fast simulation code is embedded in the original simulation code of the chip under test to obtain target simulation code. The fast simulation code is used to replace the simulation-driven operation in the target simulation code and directly output key test information during the execution of the target simulation code. The step of embedding fast simulation code into the original simulation code of the chip under test to obtain the target simulation code includes: The original simulation code of the chip under test is simulated and verified to obtain the verification result of the original simulation code; When the verification result of the original simulation code is "verification passed", the key operation code in the original simulation code is determined; The target simulation code is obtained by embedding rapid simulation code within the key operation code. The key operation code is the test simulation operation code for the chip under test. The chip under test is simulated and verified based on the target simulation code, and a simulation log containing the key test information is generated. A test vector file is then generated based on the simulation log, and the test vector file is used to perform automated functional testing on the manufactured chip under test.

2. The method according to claim 1, characterized in that, The step of simulating and verifying the chip under test based on the target simulation code, and generating a simulation log containing the key test information, includes: In response to a simulation execution signal that verifies the chip under test, the target simulation code is executed. During the execution of the target simulation code, key test information output by the fast simulation code is collected according to the call time of the fast simulation code, and the simulation log is generated.

3. The method according to claim 1, characterized in that, The step of generating the test vector file based on the simulation log includes: Use a preset extraction tool to extract key test information from the simulation log; Based on the key test information, a test vector file is generated, which includes a test vector file in a first format and / or a test vector file in a second format.

4. The method according to claim 3, characterized in that, The step of generating the test vector file based on the key test information includes: Obtain the pin information file of the chip under test, wherein the pin information file is a pin mapping and attribute configuration file predefined according to the chip design; Based on the key test information and the pin information file, generate a test vector file in the first format; Using a preset file conversion tool, the test vector file in the first format is converted into a test vector file in the second format.

5. The method according to claim 1, characterized in that, After generating the test vector file based on the simulation log, the method includes: The verification code is simulated and verified to obtain the verification result of the verification code, which is obtained during the generation of the test vector file; When the verification result of the verification code is that the verification fails, an abnormal step in the test vector file generation process is identified; The abnormal steps are corrected to obtain the corrected update steps; Based on the update steps and the target simulation code, the chip under test is simulated and verified to generate an update simulation log containing the key test information, and an update test vector file is generated based on the update simulation log. When the verification result of the verification code is "verification passed", the test vector file is determined as the target test vector file.

6. A test vector file generation device, characterized in that, The device includes: An embedding unit is used to embed fast simulation code into the original simulation code of the chip under test (DUT) to obtain target simulation code. The fast simulation code is used to directly output key test information, replacing the simulation-driven operations in the target simulation code during execution. The process of embedding fast simulation code into the original simulation code of the DUT to obtain the target simulation code includes: performing simulation verification on the original simulation code of the DUT to obtain a verification result; when the verification result of the original simulation code is successful, determining the key operation code in the original simulation code; and embedding fast simulation code within the key operation code to obtain the target simulation code. The key operation code is test simulation operation code for the DUT. The generation unit is used to perform simulation verification on the chip under test based on the target simulation code, generate a simulation log containing the key test information, and generate a test vector file based on the simulation log. The test vector file is used to perform automated functional testing on the manufactured chip under test.

7. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-5.

8. A chip, characterized in that, The device includes one or more interface circuits and one or more processors; the interface circuits are configured to receive signals from the memory of the electronic device and send the signals to the processors, the signals including computer instructions stored in the memory, which, when executed by the processors, cause the electronic device to perform the method of any one of claims 1-5.

9. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-5.

Images