Methods for generating and querying chip test databases and related electronic devices.

Abstract

This application relates to the field of chip testing technology, and discloses a method for generating and querying a chip testing database, as well as an electronic device. The method includes: acquiring test data files of the chip under test throughout the entire testing phase; parsing a first test file to generate a first test record file and a metadata file, and storing the first test record file in a test detail repository; generating an index information file using the storage address of the first test record file in the test detail repository; integrating and processing the metadata file to obtain a global information summary file; and parsing a second test file to generate a second test record file; storing the metadata file, index information file, and second test record file in a relational database, and storing the global information summary file in a global information repository. By implementing the method of this application, unified data traceability and integrated visualization analysis throughout the entire chip testing phase can be achieved.

Description

Technical Field

[0001] This application relates to the field of chip testing technology, specifically to methods for generating and querying chip testing databases, and electronic devices thereof. Background Technology

[0002] In the field of chip testing, three core stages are typically involved: wafer probing (CP), final test (FT), and system-level test (SLT). Test data for wafer probing and final test is usually recorded in the Standard Test Data Format (STDF), while test data for system-level test is usually recorded in compressed files or tables.

[0003] Currently, STDF files are typically viewed using open-source graphical user interface tools (STDF Viewer) or various commercial tools. However, these methods fail to create a unified and standardized structured data storage system or build a complete chip testing database. This hinders the achievement of cross-stage data association, unified traceability, and comprehensive visualization analysis for the chip under test, thus limiting the efficiency of engineering applications for chip failure location and yield statistics. Summary of the Invention

[0004] This application provides a method for generating a chip test database, a method for querying the database, and an electronic device to solve the problem in related technologies where the data storage formats for different stages of chip testing are fragmented, making it difficult to achieve unified data traceability and integrated visualization analysis across the entire chip testing process.

[0005] In a first aspect, this application provides a method for generating a chip test database. The method includes: acquiring test data files of the chip under test during the entire testing phase, the test data files including a first test file stored in a first file format and a second test file stored in a second file format; parsing the first test file to generate a first test record file and a metadata file, and storing the first test record file in a test detail repository; generating an index information file using the storage address of the first test record file in the test detail repository; integrating and processing the metadata file to obtain a global information summary file, and parsing the second test file to generate a second test record file; storing the metadata file, the index information file, and the second test record file in a relational database, and storing the global information summary file in a global information repository. The chip test database includes a test detail repository, a relational database, and a global information repository.

[0006] Secondly, this application provides a method for querying a chip test database, which is constructed according to the generation method shown in the first aspect. The method further includes: in response to an input operation of a target object on query information, obtaining query information and permission information corresponding to the target object; using the query information to search the chip test database to obtain initial test records; using the permission information to desensitize the initial test records to obtain target test records; and sending the target test records to a front-end interactive interface to display the target test records on the front-end interactive interface.

[0007] Thirdly, this application provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the chip test database generation method of the first aspect or any corresponding embodiment, or the chip test database query method shown in the second aspect.

[0008] Fourthly, this application provides a computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the chip test database generation method of the first aspect or any of the corresponding embodiments described above, or the chip test database query method shown in the second aspect.

[0009] Fifthly, this application provides a computer program product, including computer instructions, which are used to cause a computer to execute the chip test database generation method of the first aspect or any of the corresponding embodiments described above, or the chip test database query method shown in the second aspect.

[0010] The chip test database generation method provided in this embodiment parses a first test file stored in a first file format to generate a first test record file and a metadata file, and integrates the metadata file to obtain a global information summary file; and parses a second test file stored in a second file format to generate a second test record file. Following a hierarchical storage concept, the first test record file containing various detailed test data is stored in a test detail repository; simultaneously, an index information file is generated using the storage address of the first test record file in the test detail repository; the index information file, metadata file, and second test record file are stored in a relational database, and the global information summary file is stored in a global information repository. This allows for categorized, hierarchical, and orderly storage based on data type and usage scenario, achieving efficient access to massive amounts of detailed test data, and facilitating convenient association queries of basic attribute data, index data, and multi-stage test records using a relational database. This solves the problem in related technologies where data storage formats for different chip testing stages are fragmented, making it difficult to achieve unified data traceability and integrated visualization analysis across all chip testing stages. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of this application, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0012] Figure 1 This is a schematic flowchart of a first method for generating a chip test database according to an embodiment of this application; Figure 2 This is a schematic diagram of a second process for generating a chip test database according to an embodiment of this application; Figure 3 This is a schematic diagram of a third method for generating a chip test database according to an embodiment of this application; Figure 4 This is a schematic diagram illustrating the generation process of a specific chip test database according to an embodiment of this application; Figure 5 This is a schematic diagram of the first method for querying a chip test database according to an embodiment of this application; Figure 6 This is a structural block diagram of a chip test database generation apparatus according to an embodiment of this application; Figure 7 This is a structural block diagram of a chip test database query device according to an embodiment of this application; Figure 8 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0015] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0016] In the field of chip testing, it is common practice to rely on open-source graphical user interface tools (STDF Viewer) to parse and view STDF files individually, as well as various commercial tools to parse and view compressed files or spreadsheet files. However, the above methods cannot form a unified and standardized structured data storage system, nor can they build a complete chip testing database. This makes it difficult to achieve cross-stage data association, unified traceability, and comprehensive visualization analysis of the chip under test, thus restricting the efficiency of engineering applications for chip failure location and yield statistics.

[0017] In light of this, this application provides a unified parsing service for test data files stored in STDF format generated from wafer testing (CP) and finished product testing / final testing (FT), as well as test data files stored in compressed or tabular formats generated from system-level testing (SLT). The parsed test data is then stored hierarchically to generate a chip test database. Subsequently, by combining the query information provided by the front-end interactive interface, the chip test database can be searched, enabling cross-stage data association, unified traceability, and comprehensive visualization analysis of the chip under test. This allows for better failure localization and yield statistics for the chip under test.

[0018] As an optional application scenario of this application, the chip test database generation method of this application can be applied to electronic devices such as computers or servers. It can establish communication connections with different test servers and different test machines to obtain test data files transmitted between the test servers and test machines, and parse the received test data files accordingly, thereby storing the information in the test data files into the chip test database according to the rules of the chip test database.

[0019] This chip testing database can be used for unified collection of chip testing data throughout the entire process, efficient management of batch testing data, rapid screening of test anomaly data, intelligent determination of chip yield level, and traceability and comparison of cross-batch wafer testing data. It can also provide complete and reliable data support for chip performance data analysis, mass production testing process optimization, and product quality control.

[0020] According to an embodiment of this application, a method for generating a chip test database is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0021] This embodiment provides a method for generating a chip test database, which can be used in electronic devices such as servers. Figure 1 This is a flowchart of a chip test database generation method according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps: Step S101: Obtain the test data file of the chip under test during the full testing phase. The test data file includes a first test file stored in a first file format and a second test file stored in a second file format.

[0022] The full testing phase here can include wafer testing (CP), final testing (FT), and system-level testing (SLT) for the chip under test. The first test file, stored in a first file format, can be an STDF file stored in STDF file format; the second test file, stored in a second file format, can be a table file stored in tabular file format or a compressed file stored in compressed archive format (the test data in the compressed archive file can ultimately be presented in tabular form).

[0023] Furthermore, as mentioned earlier, STDF files can be used to store test data during the wafer testing (CP) and finished product testing phases, while table files or compressed files can be used to store test data corresponding to the system-level testing (SLT) phase.

[0024] Here, an encrypted communication link can be established using the Secure Shell (SSH) protocol. Secure connections are then established between the local server (the entity executing the chip test database generation method) and different remote test servers and test machines using automatic password verification, enabling cross-factory and cross-device data communication. Furthermore, relying on a remote synchronization (rsync) incremental synchronization mechanism, configuration file filtering and update judgment parameters are used to synchronize only newly added test data files and updated test data files from different remote test servers and test machines to the local server. Existing files of the same origin on the local server are skipped during transmission, effectively reducing data transmission bandwidth consumption and transmission time. Simultaneously, the synchronization process masks differences in directory timestamps and file permission attributes between different operating systems, eliminating file transmission anomalies caused by heterogeneous system interactions and ensuring the complete and stable transmission of various test data files in STDF, table, and compressed formats.

[0025] Step S102: Parse the first test file to generate a first test record file and a metadata file, and store the first test record file in the test details repository.

[0026] The first test record file here can be a structured test detail file formed by streaming splitting an STDF file and classifying and aggregating it according to test type. Furthermore, during the generation of the first test record file, different first test record files can reside in different buffers. Through streaming parsing of the first test files, test detail data is continuously stored into the corresponding first test record file. If the buffer containing a first test record file reaches a threshold, a disk write operation can be automatically triggered, storing the first test record file in the test detail repository.

[0027] For example, the first test log file may include, but is not limited to, a Parameter Test Record (PTR) file, a Multiple Result Test Record (MPR) file, a Functional Test Record (FTR) file, a Chip Result Record (PRR) file, and a Pin Mapping Record (PMR) file. In the actual disk placement process, the Parameter Test Record (PTR) file can be stored in the PTR table of the test detail repository, the Multiple Result Test Record (MPR) file can be stored in the MPR table of the test detail repository, and so on.

[0028] Metadata files can be summary files of statistical classes, relational classes, and basic attribute classes extracted and organized from STDF files. Subsequently, based on query information in the front-end interactive interface, the relevant metadata files can be directly displayed on the interface.

[0029] As a specific example, the metadata file may include sub-files for hierarchical information (bin_info_table), chip statistics (dut_counts_table), chip information (dut_info_table), chip global identifier (ecid_info_table), test data statistics (file_info_table), and test batches (file_list_table). Subsequently, the hierarchical information sub-file can be stored in the corresponding bin_info_table table in a relational database, the chip statistics sub-file can be stored in the corresponding dut_counts_table table in the same relational database, and so on.

[0030] As a concrete example, the test detail repository can be a data storage repository built using a columnar storage format. Furthermore, the test detail repository can be built using the Parquet columnar storage format.

[0031] Step S103: Generate an index information file using the storage address of the first test record file in the test detail repository.

[0032] The storage address here can be the unified resource storage path corresponding to the first test record file after it is stored in the test details repository. As a specific example, the unified resource storage path can include, but is not limited to, local disk directory paths, distributed storage node paths, file hierarchy directory representations, and other location information.

[0033] The storage address can accurately locate the actual storage location of each first test record file, providing a location basis for subsequent fast retrieval, batch retrieval, and cross-file association queries.

[0034] Step S104: Integrate the metadata file to obtain a global information summary file, and parse the second test file to generate a second test record file.

[0035] This section allows for field fusion, data association, information aggregation, and unified organization of various independent metadata files to obtain a global information summary file. Additionally, it allows for the unified aggregation of chip global identifier subfiles (ecid_info_table) corresponding to all STDF files, and the merging of SLT test results corresponding to the STDF files by field mapping to obtain the global information summary file.

[0036] As a specific example, after parsing each STDF file, the corresponding chip global identifier sub-file (ecid_info_table) can be extracted and appended to the global information summary file in append mode.

[0037] As a specific example, if the second test file is in compressed format, the system uses a recursive decompression method to unpack it layer by layer, peeling off the nested compression layers one by one, until all the internal table files are completely extracted.

[0038] Here, the second test file can be read and cleaned. The column names can be unified according to the preset field mapping rules. For example, the chip serial number field can be uniformly mapped to chip_sn, the chip global unique identifier field can be uniformly mapped to ECID, and a test stage mark such as cp_or_ft='SLT' can be added to each test record to distinguish that the record belongs to the SLT test stage, thus obtaining the second test record file.

[0039] Step S105: Store the metadata file, index information file, and second test record file in a relational database, and store the global information summary file in a global information repository. The chip test database includes a test detail repository, a relational database, and a global information repository.

[0040] As a specific example, a relational database can be an SQL database; a global information repository can be constructed using the HDF hierarchical data format, i.e., an HDF storage repository.

[0041] The chip test database generation method provided in this embodiment parses a first test file stored in a first file format to generate a first test record file and a metadata file, and integrates the metadata file to obtain a global information summary file; and parses a second test file stored in a second file format to generate a second test record file. Following a hierarchical storage concept, the first test record file containing various detailed test data is stored in a test detail repository; simultaneously, an index information file is generated using the storage address of the first test record file in the test detail repository; the index information file, metadata file, and second test record file are stored in a relational database, and the global information summary file is stored in a global information repository. This allows for categorized, hierarchical, and orderly storage based on data type and usage scenario, achieving efficient access to massive amounts of detailed test data, and facilitating convenient association queries of basic attribute data, index data, and multi-stage test records using a relational database. This solves the problem in related technologies where data storage formats for different chip testing stages are fragmented, making it difficult to achieve unified data traceability and integrated visualization analysis across all chip testing stages.

[0042] This embodiment provides a method for generating a chip test database, which can be used in electronic devices. Figure 2 This is a flowchart of a chip test database generation method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps: Step S201: Obtain the test data file of the chip under test during the entire testing phase. The test data file includes a first test file stored in a first file format and a second test file stored in a second file format. For details, please refer to [link to details]. Figure 1 Step S101 of the illustrated embodiment will not be described again here.

[0043] Step S202: Parse the first test file to generate a first test record file and a metadata file, and store the first test record file in the test details repository.

[0044] Specifically, step S202 includes: Step S2021: Perform streaming parsing on the first test file to obtain the chip local identifier of each chip under test, and the number of test records corresponding to each chip under test under each test type.

[0045] The chip local identifier here can be a unique number generated by the test equipment within the STDF file, effective only within a single test file and local test procedure, used to uniquely distinguish each chip under test within the scope of this test. As a specific example, the chip local identifier can be the PART_ID in the STDF file.

[0046] The test type here can be a standard record type with different functions and uses in the corresponding STDF file, which is divided into different test categories based on chip testing business. Specifically, it can include, but is not limited to, parameter test record (PTR), multiple result test record (MPR), functional test record (FTR), chip result record (PRR), and pin mapping record (PMR).

[0047] The number of test records here can be the total number of standardized test data entries generated for a single chip under test under the corresponding test type.

[0048] As a specific example, let's define an STDF file containing two chips under test, DUT1 and DUT2. Correspondingly, the STDF file can be represented as: #DUT1:PIR: PART_ID=CP-DUT-0001, X_COORD=12, Y_COORD=35; PTR: Operating voltage; PTR: Quiescent current; PTR: ECID1; PTR: ECID2; PRR: PASS; #DUT2:PIR:PART_ID=CP-DUT-0002, X_COORD=12, Y_COORD=36; PTR: Operating voltage; PTR: Quiescent current; PRR: FAIL. Thus, by parsing the STDF file, we can extract the following information: DUT1 has a local chip identifier of CP-DUT-0001, 1 test record under the PIR test type, 4 test records under the PTR test type, and 1 test record under the PRR test type; and DUT2 has a local chip identifier of CP-DUT-0002, 1 test record under the PIR test type, 2 test records under the PTR test type, and 1 test record under the PRR test type.

[0049] In some optional implementations, step S2021 above includes: Step a1: Perform streaming parsing on the first test file to obtain the test record index list corresponding to the first test file, as well as the chip local identifier of each chip under test in the first test file.

[0050] Step a2: Determine the test record index range for each chip under test based on the start and end records of the test results in the test record index list.

[0051] Step a3: For each chip under test, based on the test type in the test record index range, count the number of test records corresponding to each test type for the chip under test.

[0052] Following the previous example, parsing the STDF file shown above allows us to directly extract the chip local identifier corresponding to the chip under test from the test records under the PIR test type. At the same time, streaming parsing of the STDF file can obtain the test record index list, which can be represented as: rec_id_list=['MIR','PIR','PTR','PTR','PTR','PTR','PRR','PIR','PTR','PTR','PRR']. Then, based on the start record (PIR) and end record (PRR) of the test results, the test record index range for DUT1 can be determined to be 1-6, and the test record index range for DUT2 can be determined to be 7-10. Finally, by statistically analyzing the test types within the test record index ranges, it can be found that in the test record index range 1-6 for DUT1, the number of PIRs is 1, the number of PTRs is 4, and the number of PRRs is 1; and in the test record index range 7-10 for DUT2, it can be found that the number of PIRs for DUT2 is 1, the number of PTRs is 2, and the number of PRRs is 1. It should also be noted that the test record index list must be generated strictly according to the order of the test records in the STDF file.

[0053] By performing streaming parsing on the first test file, the chip local identifiers corresponding to all chips under test can be extracted in batches, and a test record index list can be generated simultaneously. Then, using the test record index list, the number of test records corresponding to each chip under test under each test type can be accurately determined. Subsequently, based on the number of test records, the chip local identifier corresponding to each test record can be determined more effectively.

[0054] Step S2022: Collect the test records in the first test file separately according to the test type to obtain multiple first initial test record files. The number of first initial test record files corresponds to the number of test types.

[0055] Here, test records belonging to the same test type in the first test file can be grouped into the same first initial test record file according to the test type.

[0056] For example, following the previous example, all test records under the PIR corresponding to DUT1 and the PIR corresponding to DUT2 can be collected into the same first initial test record file (i.e., the initial PIR table), all test records under the PTR corresponding to DUT1 and the PTR corresponding to DUT2 can be collected into the same first initial test record file (i.e., the initial PTR table), and all test records under the PRR corresponding to DUT1 and the PRR corresponding to DUT2 can be collected into the same first initial test record file (i.e., the initial PRR table).

[0057] Step S2023: For any test type, in the first initial test record file, according to the number of test records for each chip under test in the test type, define the record line range of the corresponding chip under test in the first initial test record file, and match the corresponding chip local identifier in the record line range to obtain the first test record file.

[0058] Since the PTR and PRR in the original STDF file do not correspond to the chip local identifier of the chip under test, this application uses the number of test records of the chip under test under a certain test type to define the range of record lines of the chip under test in the corresponding first initial test file and add the chip local identifier of the test chip.

[0059] For example, add the chip local identifier corresponding to DUT1 to the PTR table shown above according to the number of test records under the PTR corresponding to DUT1, and add the chip local identifier corresponding to DUT2 to the PTR table shown above according to the number of test records under the PTR corresponding to DUT2.

[0060] Specifically, step 202 above also includes: Step S2024: Perform streaming parsing on the first test file, extract relevant information from the first test file, and generate hierarchical information sub-file, chip statistics sub-file, chip information sub-file, chip global identifier sub-file, test data statistics sub-file, and test batch sub-file.

[0061] As a specific example, the fields included in the hierarchical information subfile (bin_info_table) and the meaning of each field can be shown in Table 1.

[0062] Table 1

[0063] As a specific example, the fields included in the chip statistics subfile (dut_counts_table) and the meaning of each field can be shown in Table 2.

[0064] Table 2

[0065] As a specific example, the fields included in the chip information subfile (dut_info_table) and the meaning of each field can be shown in Table 3.

[0066] Table 3

[0067] As a specific example, the fields included in the chip global identifier subfile (ecid_info_table) and the meaning of each field can be shown in Table 4.

[0068] Table 4

[0069] As a specific example, the fields included in the test data statistics subfile (file_info_table) and the meaning of each field can be shown in Table 5.

[0070] Table 5

[0071] As a specific example, the test batch subfile (file_list_table) may include batch metadata, time and stage, and core yield and other related metrics.

[0072] By performing streaming parsing on the first test file to extract various metadata files, the original mixed test data can be categorized according to multiple dimensions, enabling hierarchical storage and classification management of information. Subsequently, in response to information queries, various metadata files can be quickly displayed on the front-end interactive interface.

[0073] In some optional implementations, the globally unique identifier of each chip under test in the chip global identifier subfile is generated according to the following strategy: Step b1: For any chip under test, if a preset test item under a preset test type is extracted from the first test file, a global chip identifier corresponding to the chip under test is generated based on the test record corresponding to the preset test item. The preset test type includes one of parameter test type and multiple result record type.

[0074] Step b2: If the preset test items under the preset test type are not extracted from the first test file, the wafer unique identifier, wafer sub-batch unique identifier and the coordinate information of the chip under test on the wafer are spliced ​​together to generate a global chip identifier.

[0075] As a specific example, test records corresponding to PTR / MPR values ​​3000-3010 can be extracted from the first test file. If these test records are extracted, the specific test result values ​​can be forcibly converted to integers, and the converted integer test result values ​​can be restored to characters using the ASCII code table. These characters are then concatenated in the order of 3000-3010 to generate the corresponding global chip identifier for the chip under test. If test records corresponding to PTR / MPR values ​​3000-3010 are not extracted from the first test file, the wafer_id and sublot_id are extracted from the MIR record, and the x_coord and y_coord are extracted from the PRR record. These are then combined in a fixed format to generate a unique identifier such as WAFER01_X10_Y20, ensuring that each chip under test has a global chip identifier.

[0076] By using the two strategies described above to generate the global chip local identifier for the chip under test, it can be ensured that all chips under test can successfully generate the global chip local identifier.

[0077] Step S203: Using the storage address of the first test record file in the test detail repository, generate an index information file. For details, please refer to [link to relevant documentation]. Figure 1 Step S103 of the illustrated embodiment will not be described again here.

[0078] Step S204 involves integrating the metadata files to obtain a global information summary file, and parsing the second test file to generate a second test record file. For details, please refer to [link to details]. Figure 1 Step S104 of the illustrated embodiment will not be described again here.

[0079] Step S205 involves storing the metadata file, index information file, and second test record file in a relational database, and storing the global information summary file in a global information repository. The chip test database includes a test detail repository, a relational database, and a global information repository. For details, please refer to [link to relevant documentation]. Figure 1 Step S105 of the illustrated embodiment will not be described again here.

[0080] The chip test database generation method provided in this embodiment utilizes the number of test records for each chip under test under a certain test type to define the record line range of the corresponding chip under test in the first initial test record corresponding to that test type. By using the record line range, the chip local identifier of the corresponding chip under test can be quickly matched, thereby obtaining the first test record file more accurately.

[0081] This embodiment provides a method for generating a chip test database, which can be used in electronic devices. Figure 3 This is a flowchart of a chip test database generation method according to an embodiment of this application, such as... Figure 3 As shown, the process includes the following steps: Step S301: Obtain the test data file of the chip under test during the entire testing phase. The test data file includes a first test file stored in a first file format and a second test file stored in a second file format. For details, please refer to [link to relevant documentation]. Figure 1 Step S101 of the illustrated embodiment will not be described again here.

[0082] Step S302: Parse the first test file to generate a first test record file and a metadata file, and store the first test record file in the test detail repository. For details, please refer to [link to details]. Figure 1 Step S102 of the illustrated embodiment will not be described again here.

[0083] Step S303: Generate an index information file using the storage address of the first test record file in the test detail repository.

[0084] Specifically, step S303 includes: Step S3031: Obtain the hash value corresponding to the first test record file and its storage address in the test details repository.

[0085] The hash value corresponding to the first test record file here can be a unique digital feature code of fixed length obtained by performing a hash algorithm such as Message-Digest Algorithm 5 (MD5) or Secure Hash Algorithm 256-bit (SHA256) on the complete first test record file.

[0086] Step S3032: Obtain the total number of test records, test start time, and test end time corresponding to the first test record file.

[0087] The total number of test records here refers to the total number of test records corresponding to the first test record file. The test start time and test end time can be found in the header of the corresponding STDF file.

[0088] Step S3033: Group and aggregate the hash value, storage address, total number of test records, test start time, and test end time to generate an index information file.

[0089] Here, the hash value, storage address, total number of test records, test start time, and test end time corresponding to the same first test record file can be integrated into a single index entry. Furthermore, the index entries corresponding to multiple first test record files can be summarized in an orderly manner to form a complete index information file.

[0090] By integrating hash values, storage addresses, the total number of test records, and the start and end times of tests to generate an index information file, scattered file attributes can be uniformly organized and archived, establishing a binding association between the first test record file and various file attributes.

[0091] Step S304: Integrate the metadata file to obtain a global information summary file, and parse the second test file to generate a second test record file.

[0092] As mentioned earlier, metadata files can include multiple files. Therefore, in some cases, the chip global identifier subfiles corresponding to all the first test files can be integrated to obtain a global information summary file. See the previous text for details.

[0093] Specifically, step S304 includes: Step S3041: Perform structured parsing on the second test file and extract the test records under each test item by column.

[0094] As mentioned earlier, the second test files are mostly stored in tabular format, with a mixed row and column arrangement. By performing structured parsing on the second test files, redundant formatting information can be removed, and all test record data under the corresponding test item can be directly extracted by column, achieving a rapid conversion of irregular raw data into column-structured data.

[0095] Step S3042: Fill the test records under each test item into the second initial test record file to obtain the second test record file.

[0096] The second initial test record file here can be constructed according to the preset standard field specifications of the relational database, which can ensure that the internal field structure and field names of the final generated second test record file are completely aligned and consistent with the fields in the relational database. Subsequently, data mapping and format adaptation can be completed more conveniently and efficiently, and the second test record file can be directly imported and stored in the relational database in batches, saving the complicated field conversion and format adaptation work.

[0097] Step S305: Store the metadata file, index information file, and second test record file in a relational database, and store the global information summary file in a global information repository. The chip test database includes a test detail repository, a relational database, and a global information repository. For details, please refer to... Figure 1 Step S105 of the illustrated embodiment will not be described again here.

[0098] In some alternative implementations, the method further includes: Step c1: Traverse the parameter test records in the first test file, apply a preset regular expression to the test item name to obtain the frequency value and core index, and group and aggregate the chip local identifier and its corresponding frequency value and core index to generate a core frequency structured file.

[0099] Step c2: Traverse the pin mapping records in the first test file, generate a dictionary of correspondence between pin index numbers and pin names, filter out pin failure test records from the functional test records, and use the correspondence dictionary to convert the failed pin index numbers stored in bitmap form in the pin failure test records into the corresponding target pin names, and generate a pin failure structured file based on the chip local identifier and its corresponding target pin name.

[0100] Step c3: Store the core frequency structured file and the pin failure structured file in a relational database.

[0101] As a specific example, for the PTR in the first test file, i.e. the STDF file, regular expressions can be applied to the test item name (where the test item name is presented in the form of a string) to extract the frequency value and core index from the test item name. Then, the chip local identifier, frequency value and core index of the chip under test corresponding to the test item name are grouped and aggregated to obtain the core frequency structured file.

[0102] For example, applying a preset regular expression to GROUP_1P0G_C0 can yield 1P0G and C0; then, decoding 1P0G according to the preset rules can yield a frequency value of 1.0GHz, and decoding C0 can yield core 0; thus, based on the chip's local identifier, frequency value, and core index, a core frequency structured file as shown in Table 6 can be generated.

[0103] Table 6

[0104] As a concrete example, by traversing the PMRs in the first test file, a dictionary of correspondences between pin index numbers and pin names, as shown in Table 7, can be generated. Then, the FTR is traversed to filter out pin failure test records where NUM_FAIL > 0; next, based on the correspondence dictionary, the failed pin index numbers in the pin failure test records are converted into the corresponding target pin names. Finally, a pin failure structured file, as shown in Table 8, can be generated based on the chip local identifier corresponding to the pin failure test record and the target pin name.

[0105] Table 7

[0106] Table 8

[0107] During the process of storing the first test data file into the chip test database, the core frequency structured file and the pin failure structured file are pre-calculated and stored in the chip test database. Subsequently, when responding to query information sent by the front-end interactive interface, there is no need to re-parse and calculate, which can improve the response speed to the front-end interactive interface.

[0108] The chip test database generation method provided in this embodiment, by performing structured parsing on the second test file and extracting test data column by column, can accurately split the test records corresponding to different test items, discard messy and redundant data, and ensure that the extracted data dimensions are clear and orderly. The extracted test records are then uniformly filled into a second initial test record file with a preset format to complete the orderly formation. This can quickly unify the overall data field layout and storage format, which not only greatly simplifies the subsequent data format adaptation work, but also allows various test items to be categorized in an orderly manner, improving data processing efficiency and facilitating subsequent batch import and storage into the database. It also facilitates subsequent rapid querying, statistics, and data analysis by test item dimension.

[0109] As a specific application embodiment of this application, such as Figure 4As shown, a remote incremental synchronization mechanism is used to synchronize newly added test data files and updated test data files from different remote test servers and test machines to the local server. Upon receiving the STDF files from the CP / FT stage and the compressed or tabular files from the SLT stage, the local server parses the STDF files using a streaming parsing mechanism to generate a first test record file and a metadata file. The first test record file is then stored in a test detail repository, and the metadata file is stored in a relational database. Next, an index information file is generated using the storage address of the first test record file in the test detail repository and stored in the relational database. Furthermore, metadata files corresponding to all STDF files, such as the chip global identifier subfile, are integrated to obtain a global information summary file and stored in the global information repository. Additionally, the compressed or tabular files from the SLT stage are structured and parsed to obtain a second test record file, which is then stored in the relational database. This layered storage approach achieves layered storage of STDF files from the CP / FT stage and compressed or tabular files from the SLT stage, resulting in a chip test database.

[0110] This embodiment provides a method for querying a chip test database, which can be used in electronic devices such as servers. The chip test database is constructed according to the method described above. Figure 5 This is a flowchart of a chip test database generation method according to an embodiment of this application, such as... Figure 5 As shown, the process includes the following steps: Step S501: In response to the target object's input operation on the query information, obtain the query information and the corresponding permission information of the target object.

[0111] As a concrete example, a chip testing and analysis system or application can be provided. This system or application may have a front-end user interface and a back-end server. The chip testing database mentioned earlier can provide data support for the back-end server. When a target user uses this system or application, they can input query information into the front-end interface. The front-end interface can respond to the target user's input, sending the query information and the target user's permission information to the back-end server. The back-end server then obtains the query information and the target user's permission information.

[0112] Step S502: Use the query information to search the chip test database to obtain the initial test records.

[0113] This can be done by searching the chip test database according to the query dimensions contained in the query information, thereby obtaining the initial test records corresponding to the query information.

[0114] Step S503: De-identify the initial test record using the permission information to obtain the target test record.

[0115] Here, the permission information of the target object can be analyzed. If the target object's permission information has corresponding restrictions, such as the permission field having a specific de-identification marker, the initial test records can be traversed first, retaining the real content corresponding to non-sensitive index fields such as wafer_id and lot_id. For the real content corresponding to sensitive index fields such as Initial Yield and Retest Yield, a random function such as random.uniform(0,100) is used to generate virtual content corresponding to Initial Yield and Retest Yield. Finally, the real content corresponding to non-sensitive index fields such as wafer_id and lot_id and the virtual content corresponding to sensitive index fields such as Initial Yield and Retest Yield are merged to obtain the target test record. Alternatively, if the target object's permission information does not have corresponding restrictions, such as the permission field not having a specific de-identification marker, the initial test record can be directly determined as the target test record.

[0116] Step S504: Send the target test record to the front-end interactive interface so that the target test record can be displayed on the front-end interactive interface.

[0117] Here, the target test record can be sent to the front-end interactive interface according to the communication protocol between the front-end interactive interface and the back-end server, and the target test record can be displayed on the front-end interactive interface.

[0118] The chip test database query method provided in this embodiment obtains the target test record by de-identifying the initial test record using the target object's permission information. This eliminates the need for modification of the target test record in the front-end interface, allowing it to be directly displayed. This approach fulfills both the requirement to verify the target object's permission information and the effect of making sensitive test data usable but invisible.

[0119] This embodiment also provides a chip test database generation apparatus, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0120] This embodiment provides a device for generating a chip test database, such as... Figure 6 As shown, it includes: The first acquisition module 601 is used to acquire the test data file of the chip under test during the entire testing phase. The test data file includes a first test file stored in a first file format and a second test file stored in a second file format.

[0121] The first parsing module 602 is used to parse the first test file to generate a first test record file and a metadata file, and to store the first test record file in the test detail repository.

[0122] The first generation module 603 is used to generate an index information file using the storage address of the first test record file in the test detail repository.

[0123] The second parsing module 604 is used to integrate and process the metadata file to obtain a global information summary file, and to parse the second test file to generate a second test record file.

[0124] The first storage module 605 is used to store metadata files, index information files, and second test record files in a relational database, and to store global information summary files in a global information repository. The chip test database includes a test detail repository, a relational database, and a global information repository.

[0125] In some optional implementations, the first parsing module 602 is used to perform streaming parsing on the first test file to obtain the chip local identifier of each chip under test and the number of test records corresponding to each chip under test under each test type; to separately collect the test records in the first test file according to the test type to obtain multiple first initial test record files, the number of first initial test record files corresponding to the number of test types; for any first initial test record file under a test type, according to the number of test records of each chip under test under the test type, to define the record line range of the corresponding chip under test in the first initial test record file, and to match the corresponding chip local identifier in the record line range to obtain the first test record file.

[0126] In some optional implementations, the first parsing module 602 is used to perform streaming parsing on the first test file to obtain a test record index list corresponding to the first test file, and a chip local identifier for each chip under test in the first test file; determine the test record index range corresponding to each chip under test based on the test result start record and test result end record in the test record index list; and for each chip under test, count the number of test records corresponding to each test type according to the test type in the test record index range.

[0127] In some optional implementations, the first parsing module 602 is further configured to perform streaming parsing on the first test file, extract relevant information from the first test file, and generate hierarchical information sub-files, chip statistics sub-files, chip information sub-files, chip global identifier sub-files, test data statistics sub-files, and test batch sub-files.

[0128] In some optional implementations, the device for generating a globally unique identifier for the chip under test includes a second generation module and a splicing module. The second generation module, for any given chip under test, if a preset test item under a preset test type is extracted from a first test file, generates a global chip identifier corresponding to the chip under test based on the test record corresponding to the preset test item. The preset test type includes either a parameter test type or a multiple result record type. The splicing module, if no preset test item under a preset test type is extracted from the first test file, splices the wafer unique identifier, the wafer sub-batch unique identifier, and the coordinate information of the chip under test on the wafer to generate a global chip identifier.

[0129] In some optional implementations, the first generation module 603 is further configured to obtain the hash value corresponding to the first test record file and its storage address in the test detail repository; obtain the total number of test records, test start time, and test end time corresponding to the first test record file; and group and aggregate the hash value, storage address, total number of test records, test start time, and test end time to generate an index information file.

[0130] In some optional implementations, the second parsing module 604 is further configured to perform structured parsing on the second test file, extract the test records under each test item by column, and fill the test records under each test item into the second initial test record file to obtain the second test record file.

[0131] In some alternative embodiments, the device further includes: The third generation module is used to traverse the parameter test records in the first test file, apply a preset regular expression to the test item name to obtain the frequency value and core index, and group and aggregate the chip local identifier and its corresponding frequency value and core index to generate a core frequency structured file.

[0132] The fourth generation module is used to traverse the pin mapping records in the first test file, generate a dictionary of correspondence between pin index numbers and pin names, filter pin failure test records from the functional test records, and use the correspondence dictionary to convert the failed pin index numbers stored in bitmap form in the pin failure test records into the corresponding target pin names, and generate a pin failure structured file based on the chip local identifier and its corresponding target pin name.

[0133] The second storage module is used to store the core frequency structured file and the pin failure structured file into a relational database.

[0134] The chip test database generation apparatus provided in this application embodiment can execute the chip test database generation method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects of the method execution. Further functional descriptions of the above modules and units are the same as in the corresponding embodiments described above, and will not be repeated here.

[0135] This embodiment provides a query device for a chip test database. The chip test database is constructed based on the chip test database generation device described above, such as... Figure 7 As shown, it includes: The second acquisition module 701 is used to acquire the query information and the corresponding permission information of the target object in response to the input operation of the target object for query information.

[0136] The retrieval module 702 is used to retrieve the chip test database using query information to obtain the initial test records.

[0137] The desensitization module 703 is used to desensitize the initial test records using permission information to obtain the target test records.

[0138] The sending module 704 is used to send the target test record to the front-end interactive interface so that the target test record can be displayed on the front-end interactive interface.

[0139] The chip test database query device provided in this application embodiment can execute the chip test database query method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects of the method execution. Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0140] Figure 8This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0141] The following is a detailed reference. Figure 8 The diagram illustrates a structural schematic suitable for implementing the electronic device described in the embodiments of this application. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 801, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 802 or a program loaded from memory 808 into random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the electronic device. The processor 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0142] Typically, the following devices can be connected to I / O interface 805: input devices 806 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 807 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 808 including, for example, magnetic tapes, hard disks, etc.; and communication devices 809. Communication device 809 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 8 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0143] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 809, or installed from a memory 808, or installed from a ROM 802. When the computer program is executed by the processor 801, it performs the functions defined in the chip test database generation method of embodiments of this application.

[0144] Figure 8 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0145] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that a computer, processor, microprocessor controller, or programmable hardware includes a storage component capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the chip test database generation method or chip test database query method shown in the above embodiments is implemented.

[0146] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0147] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A method for generating a chip test database, characterized in that, The method includes: Acquire test data files of the chip under test during the entire testing phase. The test data files include a first test file stored in a first file format and a second test file stored in a second file format. The first test file is parsed to generate a first test record file and a metadata file, and the first test record file is stored in the test detail repository; Using the storage address of the first test record file in the test detail repository, an index information file is generated; The metadata file is integrated to obtain a global information summary file, and the second test file is parsed to generate a second test record file; The metadata file, the index information file, and the second test record file are stored in a relational database, and the global information summary file is stored in a global information repository. The chip test database includes the test detail repository, the relational database, and the global information repository.

2. The method according to claim 1, characterized in that, The step of parsing the first test file to generate the first test record file includes: The first test file is stream-parsed to obtain the chip local identifier of each chip under test, and the number of test records corresponding to each chip under test under each test type. The test records in the first test file are separately collected according to the test type to obtain multiple first initial test record files, and the number of the first initial test record files corresponds to the number of the test types. For any given test type, the first initial test record file is defined according to the number of test records for each chip under test under that test type. The corresponding chip local identifier is then matched within the first initial test record file to obtain the first test record file.

3. The method according to claim 2, characterized in that, The step of streaming the first test file to obtain the chip-local identifier of each chip under test and the number of test records for each chip under test under each test type includes: The first test file is parsed in a streaming manner to obtain the test record index list corresponding to the first test file, as well as the chip local identifier of each chip under test in the first test file; Based on the start and end records of the test results in the test record index list, determine the test record index range corresponding to each chip under test; For each chip under test, based on the test type corresponding to the test record index range, the number of test records for each test type of the chip under test is counted.

4. The method according to claim 2, characterized in that, The metadata file includes a hierarchical information subfile, a chip statistics subfile, a chip information subfile, a chip global identifier subfile, a test data statistics subfile, and a test batch subfile; The first test file is parsed to generate a metadata file, including: The first test file is stream-parsed to extract relevant information and generate the hierarchical information sub-file, the chip statistics sub-file, the chip information sub-file, the chip global identifier sub-file, the test data statistics sub-file, and the test batch sub-file.

5. The method according to claim 4, characterized in that, The globally unique identifiers of each chip under test in the chip global identifier subfile are generated according to the following strategy: For any one of the tested chips, if a preset test item under a preset test type is extracted from the first test file, a global chip identifier corresponding to the tested chip is generated according to the test record corresponding to the preset test item. The preset test type includes one of parameter test type and multiple result record type. If the preset test item under the preset test type is not extracted from the first test file, the wafer unique identifier, wafer sub-batch unique identifier, and coordinate information of the chip under test on the wafer corresponding to the chip under test are spliced ​​together to generate the chip global identifier.

6. The method according to claim 1, characterized in that, The step of generating an index information file using the storage address of the first test record file in the test detail repository includes: Obtain the hash value corresponding to the first test record file and its storage address in the test detail repository; Obtain the total number of test records, test start time, and test end time corresponding to the first test record file; The hash value, the storage address, the total number of test records, the test start time, and the test end time are grouped and aggregated to generate the index information file.

7. The method according to claim 1, characterized in that, The step of parsing the second test file to generate the second test record file includes: The second test file is parsed in a structured manner, and the test records under each test item are extracted column by column; The test records under each of the aforementioned test items are filled into the second initial test record file to obtain the second test record file.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: Traverse the parameter test records in the first test file, apply a preset regular expression to the test item name to obtain the frequency value and core index, and group and aggregate the chip local identifier and its corresponding frequency value and core index to generate a core frequency structured file. Iterate through the pin mapping records in the first test file to generate a dictionary of correspondence between pin index numbers and pin names, and filter out pin failure test records from the functional test records. Then, use the dictionary of correspondence to convert the failed pin index numbers stored in bitmap form in the pin failure test records into the corresponding target pin names, and generate a pin failure structured file based on the chip local identifier and the corresponding target pin name. The core frequency structured file and the pin failure structured file are stored in the relational database.

9. A method for querying a chip test database, wherein the chip test database is constructed according to any one of claims 1 to 8, characterized in that, The method further includes: In response to the target object's input operation on query information, the query information and the permission information corresponding to the target object are obtained; The initial test records are obtained by searching the chip test database using the query information. The initial test record is anonymized using the permission information to obtain the target test record; The target test record is sent to the front-end interactive interface to be displayed on the front-end interactive interface.

10. An electronic device, characterized in that, include: The system includes a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the chip test database generation method of any one of claims 1 to 8, or the chip test database query method of claim 9.

Images