System and method for generating test program code simultaneously with data produced by ATPG or simulation pattern capture program

[0002] This application is related to commonly-assigned U.S. patent application Ser. No. 08/844,807, filed Apr. 22, 1997, U.S. Pat. No. 5,845,234 for SYSTEM AND METHOD FOR EFFICIENTLY GENERATING TESTING PROGRAM CODE FOR USE IN AUTOMATIC TEST EQUIPMENT.

[0003] This invention relates generally to automatic test equipment and more particularly to a system and method for efficiently generating a test program for use in automatic test equipment.

[0004] Digital integrated circuits, such as microprocessors and application specific integrated circuits (ASICs) require substantial testing to ensure high quality and performance with low defect levels. During electronic circuit design, the testing of these devices is generally performed by automatic test equipment (ATE) which performs the testing under the control of a test program. The data for the test program can originate from several sources including scan and pattern data extracted from a design simulation program or from scan based automatic test program generation (ATPG).

[0005] A variety of commercial companies offer test data generation programs, either ATPG programs or design simulation programs. Since there are a variety of test program formats, most test data generation programs output to the intermediate format of a waveform language (the intermediate waveform format) instead of to the many different test program formats. It then becomes the user's problem to find a method of translating the intermediate waveform format into the format required for the test program. Getting the data from the source form to the ATE requires complicated data manipulation and often, custom programming, all of which requires large amounts of time and disk space.

[0006] Existing methods use the intermediate waveform format for two reasons. First, an intermediate waveform format conventionally provides a common starting point for all translations to all ATE formats. Second, existing methods presume that the translator needs to make many passes over the source test data to create the format required for the ATE. Therefore, existing methods presume a need for an intermediate data structure, such as the intermediate waveform, that contains all the source test data.

[0007] Existing methods treat the process of generating a test program from source test data as a multi-step process: first generating the intermediate waveform and then translating. Often, the translating step has multiple sub-steps that also operate serially, requiring each sub-step to be completed prior to the next sub-step.

[0008] There are a number of disadvantages with this approach. First, this process is slow. It requires that the test data generation program first create the intermediate waveform format which is separately run through a translator. Each step in this process can take hours for a state-of-the-art integrated circuit. Second, the intermediate waveform format consumes a considerable amount of disk space. The size of these files can quickly fill up disk drives of modern computers. The intermediate waveform format is often thrown away after the translation, making this a wasteful and inconvenient step.

[0009] When going from the intermediate waveform format to the test program, current methods require using or writing a separate translator for every ATE format. Typically, this translator is written by a test engineer, though there are commercial programs available to translate from the intermediate waveform format to an test program. But existing translation methods require a different translation program for each ATE format and follow the known methodology of making multiple passes over an intermediate waveform format.

[0010] Existing programs are inflexible and do not allow for an automatic way to go from the source test data all the way to the test program in one process.

[0011] Therefore, there is a need for a flexible system and method for automatically generating a test program from source test data.

[0012] Further, there is a need to automatically translate source test data without writing a separate translator for every ATE format.

[0013] Additionally, it is desirable to be able to run a test data generation program, such as a Scan ATPG or a Simulation program, and concurrently translate the data into a test program, thereby saving large amounts of both time and disk space.

[0014] The invention provides a flexible and efficient system and method for generating a test program for use in automatic test equipment. According to the invention, this is accomplished by a software program (the translator program) which requires two inputs: a setup control file and a data stream of source test data.

[0015] The invention enables the user to specify a setup control file to define information to the translator in advance, such as the target ATE platform, the desired format of the test program and desired run time warnings. This definition is accomplished by use of a setup control mechanism, preferably a Graphical User Interface (GUI), that allows the user to select the target ATE (such as the IMS ATS and the Teradyne J971) as well as a variety of other characteristic information to customize the test program. The selection can also be done by any variety of user input methodologies, such as a conventional User Interface(UI) or by inputting a list of settings. Once the user has defined the system setup file, that file may be stored and reused or revised in future test program generations.

[0016] Second, a data stream of source test data is input into the translator program. This invention is flexible to accept source test data generated from a test data generation program, such as a scan ATPG or a simulation program, or from an existing test data file, generated previously. The invention is also flexible to allow different configurations of the testing system. For example, the ATPG program can run on the same processor or on a different processor than the translator program.

[0017] Preferably, the source test data is streamed serially into the translator as it is generated by the test data generation program. Alternately, the input is streamed serially from an existing test data file. Streaming the data in serially allows for a significant benefit of this invention: concurrent translation of the source test data into an ATE format while the source test data is being generated by the test data generation program. Under this scenario, the source test data is coming from a test data generation program, either a Scan ATPG program(such as View Logic, Mentor Graphics and Synopsis) or a capture from a design simulation program (such as Cadence Verilog XL). By running the test data generation program and streaming the data to the translator program to receive and process concurrently, there is no need for the large memory-consuming intermediate waveform format.

[0018] Further, if the test data generation program and the translation program run on separate microprocessors, there is the additional benefit of a large time savings of doing these tasks concurrently rather than one step at a time. The test program is generated in essentially the same amount of time as it takes the test data generation program to generate the source test data.

[0019] The inputting of source test data is different from the prior art in several ways. Prior art translators read a file containing the source test data in the waveform intermediate format. The translator has access to the entire file at all times and often makes several passes over the data. This invention takes data, either from a source test generation program or from an existing file, and marks the scan (serial) and pattern (parallel) data of the source test data. The only data that is important to the translator in this invention is the scan and pattern data. The other data conventionally found in the source test data, such as waveform and timing data, is ignored by the invention. The source test data, including the scan and pattern data, is streamed to the translator. The translator processes each unit of data only once, as it is streamed in. When using a source test generation program, this invention accomplishes this single-pass processing by utilizing function calls linked directly into the source test generation program. When using an existing test data file, this invention uses a parser program to stream the data as if it was being generated by a test data generation program.

[0020] The translator program takes the input of the streamed-in source test data and transforms it into a test program in accordance with the parameters in the setup control file. By accepting only one unit of source test data at a time, the translator program generates test code without making multiple passes over an entire data structure, as was done in the prior art. This is possible due to three innovative realizations. First, the translator can utilize a series of buffers to collect input data to allow for transformation of a group of data into test code. This buffer series eliminates the need to do multiple passes over the source test data to group together related data. Second, the invention ignores the components of source test data that define the sequences of waveform templates used to set ATE timing or formats in conventional translators. By doing so, the translator can process the remaining source test data as it is streamed in. Third, to accommodate test program formats that allow waveform template data to be embedded in the pattern data, the invention allows for user definition of character set maps. These character set maps define substitution characters that embed waveform template data into the parallel data on a signal and pattern data type basis.

[0021] In the intermediate waveform format used by conventional systems, waveform templates are used to set ATE timing or formats. To avoid the multi-pass processing of the source test data required to process the waveform template data, this invention ignores the waveform templates and instead gets the waveform templates from a data file. The user can select a data file containing the desired waveform templates by using the setup control mechanism.

[0022] Some ATE platforms allow the waveform template data to be embedded in a unit of pattern data. Prior art translators, with full access to all data at all times could make these substitutions to meet the needs of the ATE. In this invention, data is streamed in, so this power is now given to the user to define. The user may define for any pin signal of any pattern data type, a character set which defines a substitution of one character for another based on a table. These character sets allow the user to embed waveform template data into pattern data. There are examples of character substitution tables in the prior art, but novel to this invention is the use of a table to substitute characters for any pin signal of any pattern data type.

[0023] Another aspect of this invention is the ability to generate more than one output test program from one execution of the invention. The user may select several test program formats on the setup control mechanism. The invention launches several parallel translation processes or instances, one for each desired output, each producing a different test program from the same source test data and setup control file. The output test programs may be ATE programs that can run on a specific ATE or target output program, used for other test purposes such as re-simulation or providing a readable format for the tester to follow.

[0024] The foregoing and other objects, features and advantages of the invention will become more readily apparent from the following detailed description of a preferred embodiment of the invention which proceeds with reference to the accompanying drawings.

[0025] FIG. 1 is a block diagram of an example system for generating, translating and using test program code for use in automatic test equipment according to the present invention.

[0026] FIG. 2 is a flow diagram of a prior art method for generating test program code for use in automatic test equipment.

[0027] FIG. 3 is a flow diagram of a method for generating test program code for use in automatic test equipment according to the present invention.

[0028] FIG. 4 is a block diagram of the preferred system setup according to the present invention.

[0029] FIG. 5 is a detailed flow diagram of the translation process according to the present invention.

[0030] FIG. 6 is a diagram showing the functional contents of the setup control file of FIGS. 3 and 4.

[0031] FIG. 7 shows a sample character set stored in the character set map block of FIG. 6.

[0032] FIG. 8 shows a sample table of character sets stored in the character set map block of FIG. 6.

[0033] 1.0 Overview

[0034] 2.0 Setup Control Mechanism

[0035] 2.1 Contents of the Setup Control File

[0036] 2.1.1 Input Source

[0037] 2.1.2 ATE Selection

[0038] 2.1.3 Data Capture Range

[0039] 2.1.4 Pattern Row Processing

[0040] 2.1.5 Run Time Rule Checks

[0041] 2.1.6 Program Layout

[0042] 2.1.7 Signal to ATE Channel Map

[0043] 2.1.8 Output Format

[0044] 2.1.9 Column Order

[0045] 2.1.10 Name Map

[0046] 2.1.11 Character Set Map

[0047] 3.0 Generation of Input Stream

[0048] 3.1 Origin of the data

[0049] 3.2 Interface Routines

[0050] 3.3 The Parser Function

[0051] 4.0 Translation to Output

[0052] 4.1 The Translator

[0053] 4.1.1 Start

[0054] 4.1.2 Parallel Setup

[0055] 4.1.3 Parallel Row Data

[0056] 4.1.3.1 Map Waveform Template Names

[0057] 4.1.3.2 Repeat Identification

[0058] 4.1.3.3 Grouping And Ordering

[0059] 4.1.3.4 Map Parallel Characters

[0060] 4.1.3.5 Line Format

[0061] 4.1.3.6 Program Assembly Control

[0062] 4.1.4 Serial Setup

[0063] 4.1.5 Serial Data

[0064] 4.1.6 End

[0065] 4.2 Output

[0066] 1.0 Overview

[0067] FIG. 1 is a block diagram of an example system 10 for using test program code to test a designed electronic device 16 in automatic test equipment (ATE) 11 according to the present invention. Conventional ATE 11, such as the MTS Advanced Test Station series, manufactured and licensed by Integrated Measurement Systems (IMS) of Beaverton, Oreg., test modern electronic devices under the control of test programs 12, each test program 12 comprising test program code. The test programs 12 are generated, as further described below with reference to FIG. 3 et. seq., on an engineering workstation 15 physically interconnected with (or interconnectable to) the ATE 11 using data generated by a test data generation program such as a scan automatic test program generation (scan ATPG) or a design-based simulation.

[0068] The test workstation 15 can generate test programs 12 for several different types of ATE 11 platforms. Prior to testing, the user selects an ATE 11 platform and the desired characteristics for the test program 12. The test workstation 15 generates the ATE-specific test program 12 for the selected ATE platform from the data generated by a test data generation program. The test program 12 is loaded into the ATE 11 which then tests the designed electronic device according to the test program 12. The ATE 11 can be controlled via communications 13 by the test workstation 15 which also displays the results of the test. The test workstation 15 is a conventional computer, including a processor, memory and input/output facilities.

[0069] FIG. 1 also shows where the invention fits into such a system. The ATPG or simulation based digital capture program 20 creates data that is translated by the translation system 19 of the present invention into one or several test programs 12.

[0070] FIG. 2 is a flow diagram of a standard prior art method for generating test program code for use in automatic test equipment. The starting point is either an ATPG or simulation based capture program 20 which outputs test data in a cyclized waveform format 21. Separate translators 22A-C must be written to generate a test program 12A-C that will run on a particular ATE.

[0071] FIG. 4 is a block diagram of the preferred system setup according to the present invention. One workstation, the source generation workstation 40, will execute either an ATPG 41 program or a simulation program 43 to generate test data. The test data will be transmitted on a high-speed data link 42 to the translation workstation 44. The translation workstation 44 will generate one or more test programs 12 based on the configuration given in the setup control file 37. Under this two-workstation system, the translation workstation 44 can translate simultaneously as the test data is generated by the source generation workstation 40.

[0072] FIG. 3 is a flow diagram of a method for generating testing program code for use in automatic test equipment according to the present invention. The invention comprises a translator 36 receiving two inputs: a setup control file 37 and a stream of source test data 35. The form of translator 36 used in the invention is different from conventional translators 22, as is the portions of the test data used to create the test program code. The setup control file 37 is used to tailor the test program to the target ATE platform.

[0073] The setup control file 37 can come from an existing previously-created data file or can be created by a test engineer, who selected setup parameters on a setup control mechanism 38. In the preferred embodiment, the setup control mechanism 38 includes a graphical user interface (GUI). The selected parameters are stored in a setup control file 37. The selected parameters include the target ATE, character mapping definitions, output format controls, and pattern row repeat identification. The setup control mechanism 38 and setup control file 37 are described further below in section 2.0.

[0074] The stream of source test data 35 can come from one of two sources. It can come from a first source 29, which is a parser program 34 which parses one line of data at a time from an existing test data file 33. Or, in the preferred embodiment, it can come from a second source 31, a test data generation program 30 such as an ATPG or design simulation program, which has linked into it a series of interface routines 32 that stream a source test data 35 to the translator 36 as the test data generation program 30 generates source test data. The subsystem for streaming source test data 35 into the translator is described further below in section 3.0.

[0075] The translator 36 generates a test program 12 simultaneously as the source test data is fed in. Typically, the test program is executable code operable on an ATE, though other formats are possible. This invention may use multiple translators or instances of the translator 36 to produce multiple test programs from the same source test data inputs simultaneously, using different sets of data in the setup control file 37. The translator 36 is described further below in section 4.0.

[0076] 2.0 Setup Control

[0077] The setup control mechanism 38 allows the user to define the contents of the setup control file 37. The setup control mechanism 38, in the preferred embodiment, utilizes a graphical user interface (GUI). The selection can also be done by any variety of user input methodologies, such as a conventional User Interface(UI) or inputting a list of settings. Once the user has defined the system setup file, that file may be stored and reused or revised in future test program generations. Section 2.1 lists and describes the typical contents of the setup control file 37.

[0078] 2.1 Contents of the Setup Control File

[0079] The setup control file 37 is used by the translator 36 to transform the source test data 35 into a test program 12 that will operate on the specified ATE platform 11 as well as have the characteristics desired by the user. FIG. 6 shows the functional contents of the setup control file 37. Each functional parameter is described further below.

[0080] 2.1.1 Input Source 71

[0081] Referring to FIG. 6, the user can specify the input source 71 of the source test data 35 (FIG. 3). The user specifies that the source test data 35 comes from either a test data generation program 30, such as an ATPG or design simulation program, or that the data comes from an existing test data file 33, such as an ASCII file. The default input source 71 is a test data generation program 30. If the input source is an existing test data file 33, the user must also identify the name of this file.

[0082] 2.1.2 ATE Selection 72

[0083] The user can define the ATE selection 72, comprising the ATE family and model. The selections available to the user are based on the ATE definition files 39 available to the setup control mechanism 38 (FIG. 3). ATE definition files 39 are user editable ASCII files which contain the model identification and rules to be applied for that model.

[0084] 2.1.3 Data Capture Range 73

[0085] The user can select a data capture range 73 defining a subset of all the source test data 35 to be translated. This allows for short trial runs of the translation process as well as allowing the user to select segments of the source test data 35 to translate at any one time. The user defines a start and stop range. Source test data 35 is fed to the translator 36 either in parallel rows at a time or serial scan chains on a per signal basis. Since the source test data 35 does not necessarily contain any timing information, the start and stop range is based on a row counting mechanism. Only the parallel rows are counted, with the first row being row one. The default setting of the data capture range 73 is “empty” indicating that no start or stop range is in effect.

[0086] 2.1.4 Pattern Row Processing 74

[0087] The user sets the desired Pattern row processing 74, consisting of two parameters which determine how pattern row data is processed. The two parameters are serial to parallel conversion and repeat identification. If both are set, the serial to parallel conversion will be performed first.

[0088] Serial to parallel conversion is a Boolean operator indicating if the translator 36 should convert serial data into parallel data. The default for serial to parallel conversion is False. Since serial rows are specified on a per signal basis, the conversion occurs when all the serial rows have been read in and the next parallel row is found. Data values for the non-serial rows are filled in from the last parallel row before the serial data started.

[0089] Repeat identification instructs the translator 36 to identify repeat pattern rows. Repeat pattern rows are adjacent, have exactly the same pattern data and have the same waveset name. If repeat pattern rows are detected, only one row is passed to the test program 12 with a count of the number of times it is duplicated. Repeat identification has two parts: an activation setting which turns on the detection and a range setting, giving a minimum and maximum value, designating a range of repeat values to be consolidated into one row of data passed to the test program 12. The translator processing based on the parameter is described below in section 4.1.3.2.

[0090] 2.1.5 Run Time Rule Checks 75

[0091] During run time translation, the source test data 35 translated by the translator 36 may exceed the capabilities of the ATE 11. Translation will continue, but the user will get an on-screen warning message and all warnings will be sent to a report file. These warnings are issued based on the run time rule checks 75. These are ATE specific and default values are based on the ATE selection 72. The user may change the run time rule checks values 75. The run time rule checks include the following values:

[0092] 1. Parallel Vector Maximum: The maximum size for a parallel vector for a particular ATE.

[0093] 2. Scan Chain Length Maximum: The maximum size of any one scan chain.

[0094] 3. Total Scan Serial Memory: The maximum size of the sum of the scan chains entered into scan memory.

[0095] 4. Scan Signal Maximum: The maximum number of scan signals which can be active at any one time. It is calculated by counting the number of scan signals found between parallel pattern rows.

[0096] 2.1.6 Program Layout 76

[0097] The user can direct the translator 36 to produce one or several test programs 12. The user can also specify which of several test program elements will be contained in each test program 12. The specification of the number and format of the test program files is found in the program layout 76.

[0098] 2.1.7 Signal to ATE Channel Mapping 77

[0099] The user can define the signal to ATE channel mapping 77. Most ATEs 11 define the order of the pattern column data in the pattern file preceding the pattern data. The order of the pattern column data is typically a list of ATE channel names, but can also be ATE channel numbers. The signal names generated by the ATPG program 30 will often not be compatible with the requirements of the ATE 11, therefore the user may define the mapping from a signal to a ATE channel name or number. This mapping comprises the following:

[0100] 1. Signal Name—the name of the signal to be remapped.

[0101] 2. ATE Channel Name—the channel name to which the signal is remapped. This shall default to the Signal Name.

[0102] 3. ATE Channel Number—the channel number to which the signal is remapped. This will have no default settings.

[0103] 4. Direction—A value of in or out, this may be useful for additional checks. It must be set by the user and should default to no value.

[0104] 5. Scan/Normal—The user can select a pin to be defined as either scan or normal, which will allow the pin channel number to be checked against the legal ranges. Default is normal.

[0105] 2.1.8 Output Format 78

[0106] The output format 78 is a series of user-defined parameters directing which way the translator 36 will format the test program 12. These parameters are:

[0107] 1. Comment labels—Vertical name labels of the signal groups displayed above the data columns in the test program 12.

[0108] 2. First Line Label—If enabled, the user can attach a label to the first pattern row. Default is off.

[0109] 3. Last Line Label—If enabled, the user can attach a label to the last pattern row. Default is off.

[0110] 4. Line Wrap and Number—If Line Wrap is enabled, the pattern data will be formatted to wrap at the designated Number. Line wrapping only occurs at legal places in the line, typically spaces.

[0111] 2.1.9 Column Order 79

[0112] The user can designate the column order 79, directing the translator 36 to group and reorganize columns of pattern data in the test program 12.

[0113] 2.1.10 Name Map 80

[0114] Name mapping allows the user to replace original timeset, edgeset and format set names in the source test data 35 with a custom name. The user-defined names are in the name map 80 parameter of the setup control file 37. The translator 36 substitutes the custom name for the original name when generating the test program. Though this process can be done after the translation, it can be done most efficiently during the translation. This feature is important when multiple sets of pattern data are translated, because it allows the output files to use compatible names independent of input names.

[0115] Two types of name mapping are supported: Waveset name mapping and IDDQ name mapping.

[0116] 1. Waveset Name Mapping. Each pattern row generated by a test data generation program 30 must have a label, called the waveset name, associated with it indicating the type of timing or format information to use. The waveset name label is typically defined separate from the ATPG run. To allow for changing of this label during translation, the user may define a simple two column table to replace the original waveset name with a custom waveset name. For some ATEs, the user may need to define multiple names for each original waveset name. For example, the LTX micromaster has format and timing names on each row. The two column table can still be used, with the second column containing both the custom format waveset name and custom time waveset name.

[0117] 2. IDDQ Name Mapping. The user can define a custom name to be placed in the OpCode field of a pattern row of the test program 12, identifying the pattern row as an IDDQ pattern row, allowing the user to define how the IDDQ test will be run.

[0118] 2.1.11 Character Set Map 81

[0119] A few ATEs 11 (e.g., LTX Synchromaster, LTX Micromaster Series, the MachII mode on the J971) and at least one target output format (STIL), allows for user-programmable character definitions in the pattern data. These character definitions allow the user to embed format data into pattern data. The user can define one or more character sets in the setup control mechanism, up to one for each pin signal of a pattern data type. Each column in a unit of pattern data corresponds to an ATE pin, so that column is the pin signal. Each unit of pattern data is of a pattern data type such as read, write or idle. The user may also define character sets to remap a particular pin signal for any type of pattern data. The character set map parameter 81 of the setup control file 37 comprises a table of character sets and the character sets themselves.

[0120] Each character set comprises a table defining a character and its substitution. Each character set will be identified by a letter character. These character sets may have default values for a particular ATE. FIG. 7 shows a sample character set. FIG. 8 shows a sample table of character sets. The pin signal and the pattern type of a character of pattern data may have a character set defined for it. If it does, the character of pattern data is remapped according to the character set. See section 4.1.3.4 below for an example of remapping according to a character set. This process can take place with the parser on one computer and the translator on another, thereby speeding up the overall process.

[0121] 3.0 Generation of Input Stream

[0122] 3.1 Origin of Data

[0123] Referring back to FIGS. 3 and 4, the test data used in this invention can come from one of two sources, either a test data generation program 30 or an existing test data file 35.

[0124] The invention allows for data to be sent directly to the translator as it is generated by a test data generation program such as an ATPG or a design simulation program. This invention provides software routines (the interface routines 32) to a commercial test data generation program to link as part of their program. When the test data generation program utilizing the interface routines is run, the source test data output is streamed serially to the translator. The interface routines mark the significant source test data as it is sent to the translator. In an optimal setup, the data is streamed using a high speed data link to another computer, as the test data is generated.

[0125] The user may wish to create a test program from an existing test data file. This file will typically be an ASCII file in a waveform format such as WGL or STIL. By use of a parser 34, the data in the existing test data file is streamed to the translator in such a way as to look to the translator like the data is coming from a test data generation program. The significant data is marked the same way and it is serially streamed the same way.

[0126] 3.1 Interface Routines 32

[0127] Embedded in the test data generation program 20 are interface routines which mark the significant data and serially stream it to the translator 36. The following are the interface routines used along with a description of the marks they make to the source test data streaming to the translator.

[0128] 1) ‘Start’: marks the beginning of the source test data to the translator and must precede all other function calls. It insures that the proper remote process is set up and opens up the data path.

[0129] 2) ‘Parallel Setup’: marks the beginning of the parallel (or pattern) data section. It must precede any parallel row data. It defines the order of the data bits for pattern data.

[0130] 3) ‘Parallel Row Data’: marks one row of pattern data and streams it to the translator. The order of data bits must match the definition in the parallel setup, or a run time error results. A parallel row data call may include a mark associating special characteristics with a pattern row, such as marking the pattern row as a IDDQ test candidate.

[0131] 4) ‘Serial Setup’: marks the beginning of data (typically scan signals) represented in a serial form.

[0132] 5) ‘Serial Data’: marks one signal of serial data (typically one scan chain).

[0133] 6) ‘Program End’: marks the end of data, allowing for a graceful termination of the translator.

[0134] 3.2 Parser function 34

[0135] The parser 34 streams data from an existing data file to the translator in the same way that the interface routines stream data from a test data generation program. The parser inserts the same marks in the source test data as the interface routines and streams the data to the translator, one unit of source test data at a time, in the same way that the interface routines stream data to the translator.

[0136] 4.0 Translation to Output

[0137] The invention can generate more than one test program from the same source test data and setup control file. The test programs may be operable on an ATE (an ATE program) or used elsewhere in the testing process(target output program). The following scenarios are examples where more than one test program may be useful.

[0138] 1) The user may generate both an ASCII version of the test program and an ATE executable program. The ASCII version can be used for visual inspection and the ATE program used for loading and execution onto an ATE.

[0139] 2) The user may generate both simulation vectors and an ATE executable program. The simulation vectors can be used to re-simulate the circuit with the translator results while the ATE program tests the actual circuit.

[0140] 3) The user may generate both an intermediate “check-off” format and an ATE executable program.

[0141] A separate translator process runs for each desired test program.

[0142] 4.1 The Translator

[0143] FIG. 3 shows the translator's place in the overall layout of this invention. A translator takes as input a stream of source test data 35 and a setup control file 37 and generates as output a test program 12.

[0144] FIG. 5 is a detailed block diagram of the translation process according to the present invention. The interface routines split the data flow into segments which are directed to different parts of the algorithms. The translator operates only on source test data 35 marked as ‘start’ 50, ‘parallel setup’ 54, ‘parallel row data’ 51, ‘serial setup’ 55, ‘serial data’ 52 and ‘end’ 53. The translator operates on the specific type of source test data as described in each of the following sections. Many of the functions within the translator use the Setup Control File 37. FIG. 5 indicates the setup control file 37 being used generally by the entire translator. How functions use the setup control file 37 is described for each relevant functions below.

[0145] 4.1.1 Start 50

[0146] For source test data marked as start 50, the translator performs the ‘initialize algorithm’ function 60, initializing the translation process.

[0147] 4.1.2 Parallel Setup 54

[0148] For source test data marked as Parallel Setup 54, the translator prepares for parallel data as input. It contains header block and comment block information that is passed to the test program using the ‘program assembly control’ function 66.

[0149] 4.1.3 Parallel Row Data 51

[0150] For source test data marked as Parallel Row Data 51, the translator performs several steps, including buffering of the data, before the information contained in the data is output to the test program.

[0151] The first step is to remap the name of the parallel data row, if necessary, using the ‘Map Waveform Template Names’ function 61. The data is then passed to the ‘repeat identification’ function 62 which looks for repeat values in the parallel data. When all the consecutive repeat values are found, the data is then grouped according to the setup control file in the ‘grouping and ordering’ function 63. The characters of the data can be remapped according to the character sets defined by the user, if appropriate, using the ‘map parallel characters’ function 64. The output line of test code is formatted according to the selected test program format in the ‘line format’ function 65. The data is output to the test program using the ‘program assembly control’ function 66.

[0152] Each of these functions is described in more detail below.

[0153] 4.1.3.1 Map Names 61

[0154] The user can define custom names for parallel data, typically a waveset name, using the setup control mechanism. This information is stored in the name map parameter 80 of the setup control file 37 for use by the translator. If the parallel data name input into the translator has a corresponding new name defined in the name map parameter, the new name will be substituted for the old one by the ‘map names’ function 61.

[0155] 4.1.3.2 Repeat Identification 62

[0156] The user can request that the translator recognize repeat parallel data and output only one unit of this data along with a count of the number of units of data repeated. This repeat identification flag is found in the pattern row processing parameter 74 of the setup control file 37. The translator detects repeat parallel data in the ‘repeat identification’ function 62. If the repeat identification flag is set, each unit of parallel data is compared to the previous unit of parallel data. The two units are compared for identity in contents and waveform sheet reference. If the two units are identical, the repeat count is incremented. If the two units of data are different or if the end of parallel data is detected, the buffered data is passed to the next step in the process along with a count of the number of repeated units of data. If the two units of data are different or this is the first unit of parallel data, the new parallel data are buffered for comparison to the next data unit.

[0157] 4.1.3.3 Grouping and Ordering 63

[0158] The user can control the re-ordering of pattern data, the grouping of data associated with more than one ATE pin, and the assignment of a radix (hex, decimal, binary, or octal) to a group of data. The user selects his choices for the ordering and grouping on the setup control mechanism which is available to the translator in the column order parameter 79 of the setup control file 37. In the ‘grouping and ordering’ function 63, the input buffered data is reorganized according to the setup control file and passed to the next step in the process.

[0159] 4.1.3.4 Map Parallel Characters 64

[0160] Some test program formats allow for user programmable character definitions in the pattern data. These character definitions allow the user to embed format data into pattern data on some ATEs. Alternatively, this mapping control allows for the override of existing data or a signal or the creation of a signal and corresponding data values. The user can define one or more character sets in the setup control mechanism, up to one for each pin signal of a pattern data type. The user can also define character sets to remap a particular signal pin for any type of pattern data. These definitions are available to the translator in the setup control file 37.

[0161] The ‘map parallel characters’ function 64 maps the parallel data according to the character sets defined in the setup control file. FIG. 7 shows an example of a character set. FIG. 8 shows an example of a table of character sets, with each entry of the table potentially pointing to a character set such as the one shown in FIG. 7. If, for example, the unit of parallel data is a unit of ‘read’ data and signal 4 is a ‘Z’, then a lookup of the table in FIG. 8 would indicate that character set ‘A’ should be used to remap the character. A lookup of the character set in FIG. 7 shows that a ‘Z’ should be remapped to ‘z’.

[0162] The two sets of tables allow the user to define a remapping for any signal pin of any pattern data type. A good method to optimize this process for speed is to have the links for each character set stored in a calculated lookup table at the start of the processing.

[0163] 4.1.3.5 Line Format 65

[0164] The parallel row data 54 is formatted in the ‘line format’ function 65 according to the user's choice of test program format found in the ATE selection 72 and output format 78 parameters of the setup control file 37. The format information for each test program format is available to this function as a data structure.

[0165] 4.1.3.6 Program Assembly Control 66

[0166] Data is written to the test program output file in the ‘program assembly control’ function 66. For test programs that will be run on an ATE, any data needed by the test program not passed in as source test data are integrated here to produce a test program that is operable on the ATE.

[0167] 4.1.4 Serial Setup 55

[0168] For source test data marked as Serial Setup 55, the translator prepares for serial data 52 as input. It contains header block and comment block information that is passed to the test program using the ‘program assembly control’ function 66.

[0169] 4.1.5 Serial Data 52

[0170] For source test data marked as Serial Data 52, the translator remaps characters of serial data using the ‘map serial characters’ function 67. The process is the same as the ‘map parallel characters’ function 64 described in section 4.1.3.4 above. The serial data then proceeds to the ‘line format’ function 65 and proceeds as described in section 4.1.3 above. In the pattern row processing parameter 74 of the setup control file 37 is the serial-to-parallel conversion flag. If this flag is true, a plurality of units of serial data will be converted to a unit of parallel data and the parallel row data 51 functions will be performed on the parallel data.

[0171] 4.1.6 End 53.

[0172] For source test data marked as End 53, the translator finishes up the translation process. It processes any data held in the buffers by a call to the ‘repeat identification’ function 62. This call moves the buffered data onto the next step in the process, ‘group and ordering’ 63, and proceeds as described in section 4.1.3 above. It also generates a termination line for the test program using the ‘program assembly control’ function 66.

[0173] 4.2 Output

[0174] This invention has the ability to generate multiple ATE files at the same time from the same data being fed by the run-time translator. Cases where this might be desirable include:

[0175] 1. The generation of ASCII and binary-executable versions of the test program at the same time, in the case where the ASCII is created for visual inspection and the binary is directly loaded on the ATE;

[0176] 2. The generation of simulation vectors along with a test program to allow a re-simulation of the results; or

[0177] 3. The generation of an intermediate “check-off” format and an executable test program at the same time.

[0178] Having described and illustrated the principles of the invention in a preferred embodiment thereof, it should be apparent that the invention can be modified in arrangement and detail without departing from such principles. We claim all modifications and variations coming within the spirit and scope of the following claims.