Test description file generation method and device, equipment, medium and program product

Abstract

The embodiment of the invention discloses a test description file generation method and device, equipment, a medium and a program product. Comprising the steps of obtaining a first test description file in a first format; the first format is a serial vector format; converting the first test description file into a second format through a pre-constructed first format conversion script, and determining a second test description file; the second format is a protocol language format used by the automatic test equipment; protocol parameter modification information is received, the second test description file is modified according to the protocol parameter modification information, and the modified second test description file is determined; and converting the modified second test description file into a first format through a pre-constructed second format conversion script, and determining a third test description file. The readability of the instructions contained in the debugging process is improved, the debugging efficiency is improved, and the difficulty of iterative management for the test description file version is reduced.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit testing technology, and in particular to a method, apparatus, device, medium, and program product for generating test description files. Background Technology

[0002] Automatic Test Equipment (ATE) is commonly used in the current automated testing of integrated circuits. Currently, in ATE testing environments, debugging based on the Joint Test Action Group (JTAG) protocol typically employs binary vector patterns.

[0003] Currently, when ATE (Automatic Test Equipment) performs integrated circuit debugging based on the JTAG protocol, after the Design Verification (DV) simulation passes, a Serial Vector Format (SVF) file is generated. This SVF file then needs to be converted into a binary pattern recognizable by ATE. During ATE testing, cycle-by-cycle debugging can be performed using the hard-coded binary vector. If modifications are needed during debugging, the binary data must be manipulated directly.

[0004] However, binary patterns are difficult to modify directly and require adjustments on a cycle-by-cycle basis, resulting in a long debugging cycle and low debugging efficiency. Furthermore, binary patterns have poor readability, necessitating specialized tools for parsing during debugging to achieve proper modulation. Moreover, since changes to binary patterns during debugging cannot be reverse-engineered into SVF files for recording, changes to the debug version cannot be documented, further complicating version management of test-related files. Summary of the Invention

[0005] This invention provides a method, apparatus, device, medium, and program product for generating test description files. In the ATE testing process based on the JTAG protocol, the description files used for test debugging are presented in a more readable language format. The test description files are converted between SVF format and the format supported by the ATE machine in both forward and reverse formats, so that changes generated during debugging can be accurately recorded, improving the readability of the instructions contained in the debugging process, improving debugging efficiency, and reducing the difficulty of version iteration management for test description files.

[0006] In a first aspect, embodiments of the present invention provide a method for generating a test description file, comprising: Obtain the first test description file in the first format; the first format is a serial vector format. The first test description file is converted into a second format using a pre-built first format conversion script, and the second test description file is determined; the second format is the protocol language format used by the automated test equipment. Receive protocol parameter modification information, modify the second test description file according to the protocol parameter modification information, and determine the modified second test description file; The modified second test description file is converted to the first format using a pre-built second format conversion script, and the third test description file is determined.

[0007] Secondly, embodiments of the present invention provide a test description file generation apparatus, comprising: The first file acquisition module is used to acquire a first test description file in a first format; the first format is a serial vector format. The second file determination module is used to convert the first test description file into a second format using a pre-built first format conversion script, and determine the second test description file; the second format is the protocol language format used by the automatic test equipment. The second file modification module is used to modify the received protocol parameter modification information, modify the second test description file according to the protocol parameter modification information, and determine the modified second test description file. The third file determination module is used to convert the modified second test description file into the first format using a pre-built second format conversion script, and then determine the third test description file.

[0008] Thirdly, embodiments of the present invention also provide a test description file generation device, comprising: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by at least one processor, which enables the at least one processor to implement the test description file generation method of any embodiment of the present invention.

[0009] Fourthly, embodiments of the present invention also provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the test description file generation method of any embodiment of the present invention.

[0010] Fifthly, embodiments of the present invention also provide a computer program product, including a computer program, which, when executed by a processor, is used to perform the test description file generation method of any embodiment of the present invention.

[0011] This invention provides a test description file generation method, apparatus, device, medium, and program product. The method involves: acquiring a first test description file in a first format (serial vector format); converting the first test description file to a second format using a pre-built first format conversion script to determine a second test description file; the second format being a protocol language format used by an automated test equipment; receiving protocol parameter modification information and modifying the second test description file accordingly to determine a modified second test description file; and converting the modified second test description file back to the first format using a pre-built second format conversion script to determine a third test description file. By employing this technical solution, the first test description file in SVF format, used for ATE (Automatic Test Equipment) testing, is converted to a second test description file that is usable on the ATE equipment and has higher readability, and the second test description file supports debugging on the ATE equipment based on the JTAG protocol. Because the second test description file is more readable, it can receive protocol parameter modification information directly provided by the user for the second test description file, complete the modification of the second test description file during the debugging process, and after debugging is completed, the modified second test description file can be converted back to SVF format. This allows the converted SVF format third test description file to contain the modification information during the debugging process, existing as an iterative version of the first test description file. This ensures that changes generated during debugging can be accurately recorded, improves the readability of the instructions contained during debugging, increases debugging efficiency, and reduces the difficulty of version iteration management of the test description file.

[0012] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

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

[0014] Figure 1 This is a flowchart of a test description file generation method provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of a test description file generation method provided in Embodiment 2 of the present invention; Figure 3 This is an example diagram illustrating the structural representation of a SIR instruction as a transaction, as provided in Embodiment 2 of the present invention. Figure 4 This is an example diagram illustrating the structural representation of an SDR instruction as a transaction, provided in Embodiment 2 of the present invention. Figure 5 This is a structural example diagram of a test description file generation device provided in Embodiment 3 of the present invention; Figure 6 This is a schematic diagram of a test description file generation device provided in Embodiment 4 of the present invention. Detailed Implementation

[0015] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0016] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention 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 the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0017] Example 1 Figure 1 This is a flowchart illustrating a test description file generation method according to Embodiment 1 of the present invention. This embodiment is applicable to situations where, during ATE testing and debugging, the test description file undergoes format conversion to retain modification and iteration information during debugging. This method can be executed by a test description file generation device, which can be implemented in software and / or hardware and can be configured within a test description file generation device. Optionally, the test description file generation device can be a laptop, desktop computer, or smart tablet, etc., and this embodiment does not impose any limitations on this.

[0018] like Figure 1 As shown in the figure, an embodiment of the present invention provides a method for generating a test description file, which specifically includes the following steps: S101. Obtain the first test description file in the first format.

[0019] The first format is SVF format.

[0020] In this embodiment, the first test description file can be specifically understood as an SVF file generated based on the prepared test code after the DV simulation is passed, containing relevant information about the integrated circuit to be tested.

[0021] Specifically, when the ATE (Automatic Test Equipment) needs to test the integrated circuit under test, it will first acquire the first test description file in SVF format generated based on the prepared test code after the DV simulation passes. It is understood that the first test description file may include several SVF statement segments, each of which may contain several SVF statements. Each SVF statement may contain debugging instructions based on the JTAG protocol, or other special instructions not based on the JTAG protocol used for comments or other processing. This embodiment of the invention does not limit the content contained in the SVF statements.

[0022] S102. Convert the first test description file into the second format using a pre-built first format conversion script, and determine the second test description file.

[0023] The second format is the protocol language format used by ATE.

[0024] In this embodiment, the first format conversion script can be understood as a script pre-built according to actual conditions, used to convert SVF format files into a second format file that can be recognized and used by the ATE equipment. It is understood that although the ATE-recognizable language system is universal for the same type of equipment, different users can set different protocol language expression functions on the ATE equipment to achieve specific adaptation to test instructions under the JTAG protocol. The second format proposed in this embodiment is a function expression format corresponding to the JTAG protocol, built by technicians according to actual needs within the language system supported by the ATE equipment. Optionally, the second format of the second test description file obtained by converting the first format (.svf) can be expressed as (.pa), or the second format can be determined according to actual conversion needs, such as (.txt) format, etc. This embodiment does not impose any limitations on this.

[0025] In this embodiment, the second test description file can be understood as a test description file that has been formatted and converted from the first test description file, and can be directly read and executed by the ATE (Automatic Test Equipment) machine. It is understood that the second test description file is in non-binary pattern format, and is a file that can be directly read by technicians and supports JTAG protocol-level debugging.

[0026] Specifically, the first test description file is used as input to a pre-built first format conversion script. The first format conversion script converts the instructions contained therein into functions corresponding to the JTAG protocol, built according to the language system supported by the ATE machine based on actual needs, or performs processing such as comment format conversion. The resulting second format file is then determined as the second test description file.

[0027] S103. Receive protocol parameter modification information, modify the second test description file according to the protocol parameter modification information, and determine the modified second test description file.

[0028] In this embodiment, the protocol parameter modification information can be specifically understood as the information provided by the user during the testing of the integrated circuit under test on the ATE machine, based on actual needs, to adjust and modify the parameters in the corresponding instructions of the JTAG protocol in the second test description file.

[0029] Specifically, during the process of the ATE machine testing the integrated circuit under test according to the second test description file, the user can determine the test parameters that need to be debugged based on the real-time test results and input them as protocol parameter modification information. After receiving the protocol parameter modification information, the test description file generation device can extract the parameter values ​​that need to be modified in the second test description file and replace the required parameter values ​​with the corresponding parameter positions in the second test description file to obtain the modified second test description file.

[0030] S104. Convert the modified second test description file into the first format using a pre-built second format conversion script, and determine the third test description file.

[0031] In this embodiment, the third test description file can be specifically understood as an SVF format test description file containing modification information of the first test description file during the test.

[0032] In this embodiment, the second format conversion script can be understood as a script pre-built according to the actual situation, used to convert a second format file that can be recognized and used by the ATE machine into SVF format.

[0033] Specifically, the modified second test description file is used as input to the pre-built second format conversion script. The script extracts the instruction lines related to the JTAG protocol and converts them into SVF format according to the function type of the instruction line. The resulting SVF file is then used as the third test description file.

[0034] The technical solution of this embodiment involves obtaining a first test description file in a first format (serial vector format); converting the first test description file to a second format using a pre-built first format conversion script to determine a second test description file; the second format is a protocol language format used by the automated test equipment; receiving protocol parameter modification information and modifying the second test description file accordingly to determine a modified second test description file; and converting the modified second test description file back to the first format using a pre-built second format conversion script to determine a third test description file. By adopting the above technical solution, the first test description file in SVF format used for ATE equipment testing is converted into a second test description file that is usable on the ATE equipment and has higher readability, and the second test description file supports debugging based on the JTAG protocol on the ATE equipment. Because the second test description file is more readable, it can receive protocol parameter modification information directly provided by the user for the second test description file, complete the modification of the second test description file during the debugging process, and after debugging is completed, the modified second test description file can be converted back to SVF format. This allows the converted SVF format third test description file to contain the modification information during the debugging process, existing as an iterative version of the first test description file. This ensures that changes generated during debugging can be accurately recorded, improves the readability of the instructions contained during debugging, increases debugging efficiency, and reduces the difficulty of version iteration management of the test description file.

[0035] Example 2 Figure 2 This is a flowchart of a test description file generation method provided in Embodiment 2 of the present invention. The technical solution of this embodiment further optimizes the above-mentioned optional technical solutions. After obtaining the first test description file, the instruction parsing function and key instruction conversion function in the pre-built first format conversion script are used to convert different instructions in the first test description file. While ensuring complete comments and no loss of instructions corresponding to the JTAG protocol, the conversion from the first test description file in SVF format to a second test description file in the second format is completed. During the testing process, after modifications are made to the second test description file, the data preprocessing function and instruction recognition and conversion function in the pre-built second format conversion script are used to complete the format preprocessing of the modified second test description file that does not require conversion, as well as the corresponding conversion of JTAG instructions to the standardized SVF format. This results in a third test description file that completely contains the parameters modified during the testing process. This allows changes generated during debugging to be accurately recorded, improves the readability of the instructions contained during debugging, increases debugging efficiency, and reduces the difficulty of version iteration management for test description files.

[0036] like Figure 2 As shown, the test description file generation method provided in Embodiment 2 of the present invention specifically includes the following steps: S201. Obtain the first test description file in the first format.

[0037] The first format is SVF format.

[0038] S202. The first test description file is format-converted using the instruction parsing function in the pre-built first format conversion script, and the instructions in the first test description file that are not part of the Joint Test Action Group (JTAG) protocol are converted to general comment form to determine the first intermediate description file.

[0039] The format conversion processing includes at least one of the following: skipping blank lines; skipping comment lines; and merging cross-line instructions.

[0040] In this embodiment, the instruction parsing function can be understood as a function pre-constructed according to actual conditions, used to perform format and comment conversion processing on each instruction contained in the first test description file in SVF format. Optionally, the instruction parsing function can be used to perform format conversion on all instructions contained in the first test description file in SVF format to ensure accurate and complete identification of each instruction that needs to be converted, and can be used to convert non-JTAG protocol instructions in the first test description file into comment forms suitable for direct external display and user understanding, so as to ensure readability when used as a component of the second test description file.

[0041] In this embodiment, the first intermediate description file can be understood as a file obtained after the overall format conversion of the first test description file has been completed, and the non-JTAG protocol instructions in the first test description file have been converted to comments in the second format.

[0042] In this embodiment, the blank line skipping process can be specifically understood as a process used to skip or ignore blank lines contained in the first test description file.

[0043] In this embodiment, the comment line skipping process can be specifically understood as a process used to skip or ignore comment lines that begin with " / / " in the first test description file.

[0044] In this embodiment, the cross-line instruction merging process can be specifically understood as merging multiple lines before the semicolon in the first test description file into a single complete instruction. It is understood that cross-line instruction merging ensures the integrity of subsequent format conversion instructions, thus improving conversion accuracy.

[0045] Specifically, when converting the format of the test description files that the ATE machine needs to process, the directory that the ATE machine needs to read can be scanned, each SVF format file in it can be used as a first test description file, and each first test description file can be used as input to a pre-built first format conversion script to convert from SVF format to second format. When processing the first test description file input through the pre-built first format conversion script, the first format conversion script first performs a format conversion on the entire first test description file. This can be understood as deleting information that is not necessary for ATE equipment processing and merging cross-line instructions that are difficult for ATE equipment to understand into complete instructions for subsequent conversion processing. The instruction parsing function also converts non-JTAG protocol special instructions (such as !TESSENT_PRAGMA instructions) in the first test description file that have little impact on ATE equipment testing into general comment form. That is, it converts them into comment lines with single quotes and keeps them in the second test description file that can be read by the user during ATE equipment testing, so that the user can understand the test description file during testing. The description file obtained after the above processing is determined as the first intermediate description file.

[0046] For example, the instruction parsing function in the first format conversion script can be pre-built. For instance, in this embodiment of the invention, the pre-built convert_to_vb_comments(content_lines) function can be used to convert the original comments in the first test description file into comments in the Visual Basic (VB) style while retaining the indentation format. Alternatively, the above processing can be accomplished by building other forms of functions. In this embodiment of the invention, there are no restrictions on the way the function is built.

[0047] S203. The instructions of the JTAG protocol in the first intermediate description file are converted into machine functions of the second format by the key instruction conversion function in the pre-built first format conversion script, and the second test description file is determined.

[0048] In this embodiment, the key instruction conversion function can be understood as a function pre-constructed according to the actual situation, used to specifically convert the instructions given in the first test description file in SVF format based on the JTAG protocol, so that the instructions are converted from JTAG protocol instructions described in SVF format to function forms that can be read by the ATE machine.

[0049] Specifically, the first intermediate description file, which has completed format conversion and comment form conversion, is used as the input to the key instruction conversion function in the first format conversion script. Different types of JTAG instructions in the first intermediate description file are converted into corresponding machine functions under the second format. After all JTAG instructions have been converted, the resulting description file is determined as the second test description file.

[0050] Optionally, converting JTAG protocol instructions in the first intermediate description file into machine functions in the second format using key instruction conversion functions in a pre-built first format conversion script may include the following two cases: 1) For the basic boundary scan instruction in the first intermediate description file, extract the number of runs parameter in the basic boundary scan instruction, and use the number of runs parameter as input parameter to convert the basic boundary scan instruction into the first machine function.

[0051] In this embodiment, the basic boundary scan instruction can be specifically understood as the RUNTEST instruction defined by the JTAG standard. Its core function is to keep the device in its current test / operation state for a specified duration, or to perform preset test actions (such as pin level holding or internal logic self-test). The first machine function can be specifically understood as a machine function predefined according to actual conditions, adapted to the test execution of the ATE machine, and consistent with the function of the RUNTEST instruction. For example, the first machine function in this embodiment of the invention can be represented in the format CallrunTest(...).

[0052] In this embodiment, the number of runs parameter can be specifically understood as the number of test cycles to be performed, or as a parameter used to instruct the ATE machine to define the number of clock cycles it stays in the Run-Test / Idle state when completing the test on the integrated circuit under test, so as to control the test duration.

[0053] Specifically, for the basic boundary scan instruction under the JTAG protocol in the first intermediate description file, the number of runs used to control the test duration is extracted from it, and this parameter is used as the input parameter of the machine function in the second format, which corresponds to the RUNTEST instruction in the JTAG protocol and is represented in the format CallrunTest(...). The resulting CallrunTest (number of runs parameter) is determined as the first machine function when the basic boundary scan instruction is converted to the second format.

[0054] 2) For the shift operation instructions in the first intermediate description file, the register type, pin input value, pin output value, output check identifier and check bit are determined by the key instruction conversion function and shift operation instructions in the pre-built first format conversion script, and the shift operation instructions are converted into the second machine function by taking the register type, pin input value, pin output value, output check identifier and check bit as input parameters.

[0055] In this embodiment, the shift operation instruction can be specifically understood as the Shift Instruction Register (SIR) or Shift Data Register (SDR) instruction defined by the JTAG standard. Its core function is to control the ATE machine to complete the serial shift operation of the instruction register and data register. The second machine function can be specifically understood as a machine function predefined according to the actual situation, adapted to the test execution of the ATE machine, and consistent with the function of the SIR / SDR instruction. For example, the second machine function in this embodiment of the invention can be represented in the format Call WriteReadRegJtag(...).

[0056] In this embodiment, the register type can be specifically understood as the type information of whether the register targeted by the shift operation instruction is the instruction register (IR) or the data register (DR). The pin input value (Test Data Input, TDI) can be specifically understood as the value of the instruction / data serially shifted into the IR or DR of the integrated circuit under test. The pin output value (Test Data Output, TDO) can be specifically understood as the value of the instruction / data or test result serially shifted out from the IT or DR of the integrated circuit under test. The output check identifier can be specifically understood as an identifier indicating whether the TDO output information needs to be checked. The check bit can be specifically understood as the location information that needs to be checked when the TDO output needs to be checked.

[0057] Specifically, for the shift operation instructions under the JTAG protocol in the first intermediate description file, information related to their input and output can be directly extracted from the shift operation instructions. This includes determining the register type, pin input value, and pin output value. Then, based on the key instruction conversion function, the mask value in the shift operation instructions can be judged to determine whether the ATE machine needs to check the output check identifier of TDO during test execution and the check bit when it needs to be checked. The determined register type, pin input value, pin output value, output check identifier, and check bit are then used as the input parameters of the machine function in the Call WriteReadRegJtag(...) format, corresponding to the SIR or SDR instructions in the JTAG protocol under the second format. The resulting Call WriteReadRegJtag("IR" / "DR", TDI, TDO, "True" / "False",...) is determined as the second machine function when the shift operation instructions are converted to the second format.

[0058] It should be clarified that, in this embodiment of the invention, data width frames under different JTAG protocols can be supported when performing the second machine function conversion.

[0059] Optionally, the register type, pin input value, pin output value, output check identifier, and check bits are determined through key instruction conversion functions and shift operation instructions in a pre-built first format conversion script, including: Extract the register type, pin input value, and pin output value from the shift operation instruction; The mask determination subfunction in the key instruction conversion function performs a zero-based determination on the mask value in the shift operation instruction, and determines the output check identifier based on the determination result. The check bit is determined by performing a bitwise AND operation on the mask value and pin output value of the shift operation instruction using the check bit in the key instruction conversion function.

[0060] In this embodiment, the mask determination subfunction can be understood as a function used to determine whether the mask value is all zeros in order to decide whether a TDO check is required. For example, in this embodiment, the mask determination subfunction can be represented as is_mask_all_zero(mask_str). It can be understood that when the mask value is all zeros, a TDO check is not required, and the output check identifier (check_tdo) can be set to True, without executing the subsequent check bit determination subfunction; otherwise, the output check identifier can be set to False, and the check bit in this case can be determined based on the check bit determination subfunction.

[0061] In this embodiment, the check bit determination sub-function can be specifically understood as a function for performing a bitwise AND operation on the mask value and the TDO value using strings of equal length. Optionally, the bitwise AND operation on the equal-length strings can be a bitwise AND operation on a hexadecimal string of equal length, or a bitwise AND operation on strings in other bases; this embodiment of the invention does not impose any limitations on this. For example, in this embodiment of the invention, the check bit determination sub-function can be represented as hex_and(mask, tdo).

[0062] Optionally, during the conversion of the second test description file, if there are unprocessed markers in the log information of the first test description file, or if the length of the required input data extracted from the instruction is inconsistent with the actual TDI input data length, an alarm will be issued for the abnormality, and the alarm information can be generated together with the second test description file as part of the log information.

[0063] It is understandable that `WriteReadRegJtag(...)` can be interpreted as a JTAG interface function on the ATE side, which can be processed and adjusted according to the parameters passed in. In this embodiment of the invention, this function can be used to abstract each JTAG instruction in SVF format into a transaction layer, represented in the form of Header+Body+Trailer. For example, Figure 3 This is an example diagram illustrating the structural representation of a SIR instruction as a transaction, provided in Embodiment 2 of the present invention. Figure 4 This is an example diagram illustrating the structural representation of an SDR instruction as a transaction, provided in Embodiment 2 of the present invention. Figure 3 Frame_A and Figure 4 The Frame_B in this context can be understood as the Header section mentioned above. Figure 3 and Figure 4 The Frame_C in the text can be understood as the Body part mentioned above. Figure 3 and Figure 4 The Frame_D in the text can be understood as the Trailer section mentioned above, where, Figure 3 and Figure 4In this code, TCK represents the sampling clock, TDI represents the data input, TDO represents the data output, and TMS represents the state machine selection indicator. For the DR (Data Register) and IR (Instruction Register), the header is fixed; for example, DR uses the sequence 1-0-0, and IR uses the sequence 1-1-0-0. Therefore, the headers of IR and DR can be defined as a fixed-value data frame. Similarly, the tailer is also fixed; both DR and IR use the sequence 1-1-0 to update and then return to IDLE. The body uses 32-bit data frames, with variable data length. For example, when the data length is less than 32 bits, only one data frame is needed to meet the data transmission requirements. When the data length is greater than 32 bits, multiple data frames are concatenated according to the required length.

[0064] S204. Receive protocol parameter modification information, modify the second test description file according to the protocol parameter modification information, and determine the modified second test description file.

[0065] S205. Initialize the first format blank test description file.

[0066] Specifically, when the ATE machine needs to convert the modified second test description file back to SVF format after completing the test, a blank SVF format file will be initialized first to carry the instruction information in the second test description file that needs to be converted to SVF format.

[0067] S206. The modified second test description file is preprocessed using the data preprocessing function in the pre-built second format conversion script to determine the second intermediate description file.

[0068] In this embodiment, the data preprocessing function can be understood as a function pre-constructed according to the actual situation, used to process non-instruction type data in the second format file that affects conversion accuracy, and to loosen the data used for regular expression matching to increase the robustness of regular expression matching. For example, processing non-instruction type data that affects conversion accuracy may include: removing VB-style end-of-line comments and cleaning up leading tabs and whitespace; loosening the data used for regular expression matching may include: loosening parameter matching modes, ignoring case, and other fault-tolerant designs, etc., which are not limited in this embodiment of the invention.

[0069] Specifically, the modified second test description file is used as input to the pre-built second format conversion script. The data preprocessing function in the second format conversion script scans the entire modified second test description file, removes information unrelated to instruction conversion, and relaxes the data that needs instruction matching conversion to increase the robustness of the conversion to SVF format. The resulting file is then determined as the second intermediate description file.

[0070] S207. For each line of the JTAG instruction in the second intermediate description file, the JTAG instruction is converted into the first format using the instruction recognition and conversion function in the pre-built second format conversion script, and the converted JTAG instruction is written into the blank test description file.

[0071] In this embodiment, the instruction recognition and conversion function can be understood as a function pre-constructed according to the actual situation, used to identify the instruction types belonging to the JTAG protocol in the second intermediate description file and convert them into the JTAG protocol instruction expression mode under SVF format.

[0072] Specifically, since each line in the processed second intermediate description file corresponds to a JTAG instruction, during the reverse conversion process, the JTAG instruction of each line can be used as the input of the instruction recognition and conversion function to extract the type and internal parameters of the JTAG instruction, convert it into the corresponding instruction in the standard SVF format, and write each converted JTAG instruction into the blank test description file initialized above.

[0073] Optionally, JTAG instructions are converted to the first format using instruction recognition and conversion functions in a pre-built second format conversion script, including: The function type and parameter information of the JTAG instruction are determined by the instruction recognition and conversion function, and the JTAG instruction is converted to the first format according to the function type and parameter information, thus determining the converted JTAG instruction.

[0074] For example, the JTAG instructions can be matched to their function types by identifying and converting the regular expressions contained in the function, and the test-related parameter information can be extracted from them. Based on the function type, the instruction type to be converted under SVF format can be determined. For example, the WriteReadRegJtag function needs to be converted to the SIR or SDR instruction under SVF format, and the runTest function needs to be converted to the RUNTEST instruction under SVF format. Then, the identified parameter information is used to determine the parameter information contained in the instruction under SVF format, and the conversion of each JTAG instruction under the second format to the first format is completed, and the converted JTAG instruction is determined.

[0075] Optionally, during the conversion from the modified second test description file to the third test description file, if there are any incorrectly parsed JTAG command lines, the unparsed JTAG command lines can be marked as errors, and the error information can be written to the log for later verification.

[0076] S208. The blank test description file containing all converted JTAG commands is designated as the third test description file.

[0077] The technical solution of this embodiment, after obtaining the first test description file, uses the instruction parsing function and key instruction conversion function in the pre-built first format conversion script to convert different instructions in the first test description file. While ensuring complete comments and no loss of instructions corresponding to the JTAG protocol, it completes the conversion from the SVF format first test description file to the second format second test description file. During the testing process, after modifications are made to the second test description file, the data preprocessing function and instruction recognition and conversion function in the pre-built second format conversion script complete the format preprocessing of the modified second test description file that does not require conversion, as well as the corresponding conversion of JTAG instructions to the standardized SVF format. This results in a third test description file that fully contains the parameters modified during the testing process. This ensures that changes generated during debugging can be accurately recorded, improves the readability of the instructions contained during debugging, increases debugging efficiency, and reduces the difficulty of version iteration management for test description files.

[0078] Example 3 Figure 5 This is a structural example diagram of a test description file generation device provided in Embodiment 3 of the present invention, as shown below. Figure 5 As shown, the test description file generation device includes a first file acquisition module 31, a second file determination module 32, a second file modification module 33, and a third file determination module 34.

[0079] The first file acquisition module 31 is used to acquire a first test description file in a first format, which is a serial vector format. The second file determination module 32 is used to convert the first test description file into a second format using a pre-built first format conversion script, and determine the second test description file. The second format is a protocol language format used by the automatic test device. The second file modification module 33 is used to receive protocol parameter modification information and modify the second test description file according to the protocol parameter modification information, and determine the modified second test description file. The third file determination module 34 is used to convert the modified second test description file into a first format using a pre-built second format conversion script, and determine the third test description file.

[0080] The technical solution of this invention converts a first test description file in SVF format, used for ATE (Automatic Test Equipment) testing, into a second test description file that is usable on the ATE equipment and has higher readability. This second test description file also supports debugging on the ATE equipment based on the JTAG protocol. Because the second test description file is more readable, it can receive protocol parameter modification information directly provided by the user, allowing for modifications to the second test description file during the debugging process. After debugging is complete, the modified second test description file can be converted back to SVF format, resulting in a third test description file in SVF format that contains the modification information from the debugging process. This serves as an iterative version of the first test description file, ensuring that changes during debugging are accurately recorded. This improves the readability of the instructions included in the debugging process, increases debugging efficiency, and reduces the difficulty of managing version iterations of the test description file.

[0081] Optionally, the second file determination module 32 is specifically used for: The first test description file is format-converted using the instruction parsing function in the pre-built first format conversion script, and the instructions in the first test description file that are not part of the Joint Test Action Group (JTAG) protocol are converted to general comment form to determine the first intermediate description file; the format conversion process includes at least one of the following: blank line skipping; comment line skipping; and cross-line instruction merging. The JTAG protocol instructions in the first intermediate description file are converted into machine functions in the second format using key instruction conversion functions in the pre-built first format conversion script, thereby determining the second test description file.

[0082] Optionally, the instructions of the JTAG protocol in the first intermediate description file are converted into machine functions of the second format using key instruction conversion functions in a pre-built first format conversion script, including: For the basic boundary scan instruction in the first intermediate description file, the number of runs parameter in the basic boundary scan instruction is extracted, and the number of runs parameter is used as input parameter to convert the basic boundary scan instruction into the first machine function; For the shift operation instructions in the first intermediate description file, the register type, pin input value, pin output value, output check identifier, and check bit are determined by the key instruction conversion function and shift operation instructions in the pre-built first format conversion script. The register type, pin input value, pin output value, output check identifier, and check bit are then used as input parameters to convert the shift operation instructions into the second machine function.

[0083] Optionally, the register type, pin input value, pin output value, output check identifier, and check bits are determined through key instruction conversion functions and shift operation instructions in a pre-built first format conversion script, including: Extract the register type, pin input value, and pin output value from the shift operation instruction; The mask determination subfunction in the key instruction conversion function performs a zero-based determination on the mask value in the shift operation instruction, and determines the output check identifier based on the determination result. The check bit is determined by performing a bitwise AND operation on the mask value and pin output value of the shift operation instruction using the check bit in the key instruction conversion function.

[0084] Optionally, the third-file determination module 34 is specifically used for: Initialize a blank test description file in the first format; The modified second test description file is preprocessed using the data preprocessing function in the pre-built second format conversion script to determine the second intermediate description file; For each line of the second intermediate description file, the JTAG instructions are converted into the first format using the instruction recognition and conversion function in the pre-built second format conversion script, and the converted JTAG instructions are written into the blank test description file. The blank test description file containing all converted JTAG commands is designated as the third test description file.

[0085] Optionally, JTAG instructions are converted to the first format using instruction recognition and conversion functions in a pre-built second format conversion script, including: The function type and parameter information of the JTAG instruction are determined by the instruction recognition and conversion function, and the JTAG instruction is converted to the first format according to the function type and parameter information, thus determining the converted JTAG instruction.

[0086] The test description file generation device provided in this embodiment of the invention can execute the test description file generation method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0087] Example 4 Figure 6This is a schematic diagram of a test description file generation device provided in Embodiment 4 of the present invention. The test description file generation device 40 can represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, communication base stations, and other suitable computers. The test description file generation device 40 can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0088] like Figure 6 As shown, the test description file generation device 40 includes at least one processor 41 and a memory, such as a read-only memory (ROM) 42 and a random access memory (RAM) 43, communicatively connected to the at least one processor 41. The memory stores computer programs executable by the at least one processor. The processor 41 can perform various appropriate actions and processes based on the computer program stored in the ROM 42 or loaded from storage unit 48 into the RAM 43. The RAM 43 may also store various programs and data required for the operation of the test description file generation device 40. The processor 41, ROM 42, and RAM 43 are interconnected via a bus 44. An input / output (I / O) interface 45 is also connected to the bus 44.

[0089] Multiple components in the test description file generation device 40 are connected to the I / O interface 45, including: an input unit 46, such as a keyboard, mouse, etc.; an output unit 47, such as various types of displays, speakers, etc.; a storage unit 48, such as a disk, optical disk, etc.; and a communication unit 49, such as a network card, modem, wireless transceiver, etc. The communication unit 49 allows the test description file generation device 40 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0090] Processor 41 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 41 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 41 performs the various methods and processes described above, such as the test description file generation method.

[0091] In some embodiments, the test description file generation method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 48. In some embodiments, part or all of the computer program may be loaded and / or installed onto the test description file generation device 40 via ROM 42 and / or communication unit 49. When the computer program is loaded into RAM 43 and executed by processor 41, one or more steps of the test description file generation method described above may be performed. Alternatively, in other embodiments, processor 41 may be configured to perform the test description file generation method by any other suitable means (e.g., by means of firmware).

[0092] Optionally, embodiments of the present invention also provide a computer program product, including a computer program that, when executed by a processor, implements the test description file generation method provided in any embodiment of the present invention.

[0093] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0094] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0095] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0096] To provide user interaction, the systems and techniques described herein can be implemented on a test description document generation device, which includes: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the test description document generation device. Other types of devices can also be used to provide user interaction; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0097] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0098] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0099] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0100] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for generating a test description file, characterized in that, include: Obtain the first test description file in the first format; The first format is a serial vector format; The first test description file is converted to a second format using a pre-built first format conversion script, and the second test description file is determined. The second format is the protocol language format used by automated testing equipment; Receive protocol parameter modification information, modify the second test description file according to the protocol parameter modification information, and determine the modified second test description file; The modified second test description file is converted to the first format using a pre-built second format conversion script to determine the third test description file.

2. The test description file generation method according to claim 1, characterized in that, The step of converting the first test description file to a second format using a pre-built first format conversion script, and determining the second test description file, includes: The first test description file is format-converted using the instruction parsing function in the pre-built first format conversion script, and the instructions in the first test description file that are not part of the Joint Test Action Group (JTAG) protocol are converted to a general comment format to determine the first intermediate description file; the format conversion process includes at least one of the following: blank line skipping; comment line skipping; and cross-line instruction merging. The JTAG protocol instructions in the first intermediate description file are converted into machine functions in the second format using key instruction conversion functions in a pre-built first format conversion script, thereby determining the second test description file.

3. The test description file generation method according to claim 2, characterized in that, The conversion of JTAG protocol instructions in the first intermediate description file into machine functions of the second format using key instruction conversion functions in a pre-built first format conversion script includes: For the basic boundary scan instruction in the first intermediate description file, the number of runs parameter in the basic boundary scan instruction is extracted, and the number of runs parameter is used as an input parameter to convert the basic boundary scan instruction into a first machine function; For the shift operation instruction in the first intermediate description file, the register type, pin input value, pin output value, output check identifier, and check bit are determined by the key instruction conversion function in the pre-built first format conversion script and the shift operation instruction. The register type, pin input value, pin output value, output check identifier, and check bit are then used as input parameters to convert the shift operation instruction into a second machine function.

4. The test description file generation method according to claim 3, characterized in that, The process of determining the register type, pin input value, pin output value, output check identifier, and check bit through key instruction conversion functions in a pre-built first format conversion script and the shift operation instructions includes: The register type, pin input value, and pin output value are extracted from the shift operation instruction; The mask determination sub-function in the key instruction conversion function performs a zero-based determination on the mask value in the shift operation instruction, and determines the output check identifier based on the determination result. The check bit is determined by performing a bitwise AND operation on the mask value and pin output value of the shift operation instruction using the check bit determination sub-function in the key instruction conversion function.

5. The test description file generation method according to claim 1, characterized in that, The step of converting the modified second test description file into the first format using a pre-built second format conversion script to determine the third test description file includes: Initialize the blank test description file of the first format; The modified second test description file is preprocessed using the data preprocessing function in the pre-built second format conversion script to determine the second intermediate description file; For each line of the second intermediate description file, the JTAG instructions are converted into the first format using the instruction recognition and conversion function in the pre-built second format conversion script, and the converted JTAG instructions are written into the blank test description file. The blank test description file, into which all converted JTAG instructions are written, is designated as the third test description file.

6. The test description file generation method according to claim 5, characterized in that, The step of converting the JTAG instruction to the first format using the instruction recognition and conversion function in the pre-built second format conversion script includes: The function type and parameter information of the JTAG instruction are determined by the instruction identification and conversion function, and the JTAG instruction is converted to the first format according to the function type and parameter information to determine the converted JTAG instruction.

7. A test description file generation apparatus, characterized in that, include: The first file acquisition module is used to acquire a first test description file in a first format; The first format is a serial vector format; The second file determination module is used to convert the first test description file into a second format using a pre-built first format conversion script, and determine the second test description file. The second format is the protocol language format used by automated testing equipment; The second file modification module is used to receive protocol parameter modification information and modify the second test description file according to the protocol parameter modification information to determine the modified second test description file; The third file determination module is used to convert the modified second test description file into the first format using a pre-built second format conversion script, and then determine the third test description file.

8. A test description file generation device, characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the test description file generation method according to any one of claims 1-6.

9. A storage medium containing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to perform the test description file generation method as described in any one of claims 1-6.

10. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the test description file generation method as described in any one of claims 1-6.

Images