KR20020060701A - Test language conversion method - Google Patents

Abstract

The present invention relates to a method of converting test vectors (21) in native test-cycle based language into target-cycle based test language (22). The method includes forming 25 a set of templates depicting waveforms defined in target test language 22; Decomposing a waveform in a unique test language into a set of configuration events, each event comprising at least data indicative of a start value of the waveform and the number of consecutive edges; Comparing 26 the template with a set of events; Storing (28) waveform data of the target test language and retrieving corresponding parameters of the waveform of the native test language when a match is detected; And forming a test vector file of the target test language by repeating the above-described steps for all of the test vectors in the native test language.

Description

How to convert test language {TEST LANGUAGE CONVERSION METHOD}

When testing semiconductor devices such as IC and LSI by an automatic test device (ATE) or IC tester, the test signal or test patterns generated by the IC tester at the pins suitable for the selected test timings are to be tested. Is provided. The IC tester receives output signals from the IC Device Under Test (DUT) in response to the test signals. The output signals are strobe or sampled by the strobe signal generated by the IC tester at a predetermined timing and compared with expected data to determine whether the IC device is functioning correctly. Typically, the timing of the test signals and the strobe signals is defined in relation to the start timing of each test cycle of the IC tester.

As described above, the IC tester generates test patterns and strobes, that is, test vectors, based on digital test vector data described in a language (format) specific to the tester. Languages for automated test equipment vary from manufacturer to manufacturer.

Recently, the IEEE has proposed a test language STIL (Standard Test Interface Language) as a standard test interface language (IEEE Std 1450-1999). STIL provides an interface between computer-aided engineering (CAE), such as automated test equipment and logic test simulators. In a CAE or Electronic Design Automation (EDA) environment, semiconductor devices are designed with the assistance of computer systems and these designs are tested through logic test simulators or test benches. It is preferable to use digital test vectors obtained from logic simulation when testing real semiconductor devices by an IC tester. STIL is designed to facilitate the transfer of large amounts of digital test vectors from a CAE environment to an automated test device (ATE) environment.

The STIL test language has recently been standardized. However, at present, most ATE systems do not use STIL as their native language. Native languages provided by test device manufacturers are not compatible with each other. Therefore, there is a need to efficiently convert STIL to the ATE native language.

<Summary>

Accordingly, an object of the present invention is to provide a method for converting digital test vectors of one cycle base test language into another cycle base test language very efficiently and accurately.

Another object of the present invention is to provide a test language conversion method for converting test vectors in STIL format into targets very efficiently and accurately.

In the present invention, a method of converting test vectors in a native cycle-based test language into a target cycle-based test language includes a set of templates for reading valid waveforms defined in the target test language and describing the waveforms, each template being a target test. Forming data corresponding to the waveform of the language and including at least a starting value of one segment of the waveform and a number of consecutive edges of the waveform; Reading test vectors of the native test language and decomposing the waveform of the test vectors in the native test language into a set of constituent events, each event comprising data indicative of at least the starting value of the waveform and the number of consecutive edges; ; Comparing the template derived from the waveform in the target test language with the set of events derived from the native test language; Storing waveform data in a target test language when a match is detected in the comparing step, retrieving corresponding parameters of a waveform of test vectors of a native test language, and storing the parameters in combination with the matched waveform data; And forming a test vector file of the target test language by repeating the above-described steps for all of the test vectors in the native test language.

Typically, the native test language is STIL (Standard Test Interface Language) specified by IEEE Std 1450-1999. Preferably, comparing the template and the set of events comprises the steps of different levels in order of signal level, wavekind level in which the signal consists of a plurality of wavekinds, and character level sequence in which the wavekind consists of a plurality of characters. Modifying the test vectors.

The set of events derived from the native test language is stored in a table format with columns assigned to the data representing the number and starting value of consecutive edges. The table storing the event set is optimized by examining the start value of a particular event based on the end state generated by the previous event, thus simplifying the data in the table.

The present invention relates to a test data conversion method for testing semiconductor devices by an automated test device, and in particular, digital test vectors recorded in STIL (Standard Test Interface Language), digital test in a test language specific to the automatic test device. To convert to vectors.

1 is a diagram illustrating an example of a format in STIL describing signals or signal groups of digital test vectors constituting intended test vectors.

FIG. 2 shows an example of a format in STIL describing the timings of an edge in each of the signals constituting the waveforms.

3 shows an example of a format in STIL describing patterns of vectors in each of the signals constituting the waveforms.

4 is a diagram illustrating an example of a format in STIL describing a pattern flow of test vectors constituting intended waveforms.

5 is a diagram showing an example of a format in TDL (Test Description Language), which is a test language unique to the ATE system developed by the assignee of the present invention.

Fig. 6A is a schematic diagram showing the basic principle of the test language conversion according to the present invention, and Fig. 6B is a schematic diagram showing an example of the functional configuration of the test language conversion of the present invention.

FIG. 7 is a diagram showing an example of an STIL structure and an equivalent TDL representation, and a template of a waveform based on the TDL representation.

8 is a diagram illustrating other examples of STIL structures, waveforms corresponding to STIL structures, and TDL representations.

9 illustrates another example of STIL structures, waveforms corresponding to STIL structures, and TDL representations for describing optimal waveforms.

10A and 10B are tables showing examples of an array depicting the number of edges and initiation values representing decomposition events of STIL test vectors for executing the pattern match of the present invention.

11 is a flowchart illustrating an example of a process of wavekind matching of the present invention with different levels of test vectors.

12 is a flowchart illustrating an example of a process of wavebinding matching of the present invention from the previous cycle to the next cycle.

FIG. 13 illustrates the basic idea of converting STIL test vectors into multi-clock test signals of TDL when the types of the DUT pin are suitable for multi-clock signals.

14 is a waveform diagram illustrating the basic idea of converting STIL test vectors into pin multiplexing test vectors of TDL.

STIL (Standard Test Interface Language) The testing language uses cycle-based representations to define pattern and timing information for testing the device. The format used does not represent the language of any ATE systems, but is configured to provide maximum flexibility when designing test programs. STIL has only recently been adopted as a standard and is not widely used yet. Many STIL-based applications have been proposed in recent years, including common test flows, scan test methods, and automatic test pattern generators (ATPGs). Currently, most ATE systems do not use STIL as their native language. Thus, there is a need to translate STIL into the native language of the target ATE system. Such languages are typically cycle-based so that the conversion is from one cycle-based representation to another.

In the present patent specification, the inventor has described some of the basic steps involved in the method of converting from one cycle-base format to another. The inventor also suggests some tips for enabling the conversion of STIL in an efficient manner. The transformation shown in the present invention is based on the analysis of data expressed in STIL. Although the provided principles are general and equally applicable to other test languages, as a sample target language, TDL (Test Description Language) developed by Advanced Test Corporation of Tokyo, Japan, the assignee of the present invention, describes the description. Used for the purpose.

1-4 show examples of formats in STIL for describing digital test vectors. 1 shows the formats of signals and signal groups, and FIG. 2 shows the formats of the timings of the edges of the signal, respectively. 3 shows an example of the STIL format describing the patterns of test vectors, and FIG. 4 shows an example of the STIL format describing the flow of patterns. 5 illustrates an example of a format in TDL, which is a target test language.

Template Matching

The conversion from one cycle-base representation to another cycle-base representation is most easily accomplished using the event-base intermediate format. Here, an event means any change, such as the edges of the test vectors, or no change defined with respect to timing. The two cycle-based representations are usually quite different from each other. For conversion from one cycle-base representation to another cycle-base representation, an arbitration event-base representation is used to decompose the data into basic building blocks. That is, the input cycle-base format (STIL) is broken down into configuration events and these events are reconstructed in the target description format (TDL).

The basic process is shown in FIG. 6A to execute the process of converting from vector to base. In the present invention, test vectors in the STIL format are decomposed into respective events and compared with templates generated based on waveforms defined in TDL, which is an example of a target test language. This concept is illustrated by the dashed arrows in FIG. 6A. When a match is found for the template, the matched template is listed in a file where the parameters of the corresponding STIL test vectors are sent to complete the waveform. In this way, TDL test vectors are generated as shown by the dashed arrows in FIG. 6A.

6B is a functional representation of the test vector transformation of the present invention from a STIL test language to a TDL test language. The STIL vector file 21 is a file for storing STIL test vectors to be converted into TDL vectors through the conversion process of the present invention. Typically, the STIL test vectors in the STIL file 21 are derived from the design stage of the semiconductor devices, i.e., the Computer-Aided Engineering (CAE) environment or the Electronics Design Automation (EDA) environment, as a result of the execution of the logic simulation. STIL vectors are decomposed into configuration events and stored in decomposition event file 24.

As mentioned above, TDL is a test language developed by Advanced Corporation, an assignee of the present invention, for establishing a logical test pattern (LPAT) file. The format of the TDL is stored in the TDL wavebind file 22. Each waveform defined in the target test language TDL is converted into a corresponding template with a set of components. Templates of waveforms are stored in template file 25.

Pattern matching is performed by the comparator 26 between the events from the event file 24 and the templates from the template file 25. When a match is found, the waveform corresponding to the TDL is listed in a file 28 that stores the template matched data representation. Also, details of the parameters for the vectors of the matched template are sent from the STIL vectors to the TDL vectors. Details of these vectors include types of timing, pattern letter, and edge. Thus, in the TDL & LPAT file 29, TDL test vectors corresponding to STIL test vectors are generated through the conversion process described above.

As an example, referring to Figures 7 and 8, consider the following STIL structure, equivalent TDL representation and corresponding waveform:

01 {'400' D / U;} => NRZ; T1 = 400 Hz; T2 = 400 Hz

Here, the STIL structure on the left is 01 {'400' D / U;} designates the falling edge D at 400 'and the letter' 1 'is the rising edge U at 400'. ). The STIL representation corresponds to the waveforms shown at the top of FIG. 8 and the nonzero return (NRZ) waveform defined by TDL. In FIG. 8, the waveform of the letter '0' shows the shaded portion from the starting edge to the falling edge T1 (400 ms from the starting edge) of the test cycle. The shaded portion means that the logical state of the region is not defined. Thus, the letter '0' specifies the falling edge T1 at 400 ms from the start of the test cycle whatever the current logic state. Similarly, the waveform of the letter '1' defines the falling edge T1 at 400 ms from the start of the test cycle, whatever the current logic state. As described above, one example of the STIL structure corresponds to the NRZ waveform of the TDL.

Thus, in the conversion method of the present invention, the construction of the TDL waveforms from the decomposition STIL waveform technique is performed using a template matching method. Valid waveforms for a given tester are read at run time and stored in a manner that facilitates template matching. Thus, as a first step, a template list is set for each waveform, such as NRZ defined by TDL. The template is characterized by a set of {pattern character, start value, number of consecutive edges} pairs describing the waveform. The representation of the example NRZ waveform described above is shown at the bottom of FIG. 7.

In the example of the template of FIG. 7, the first element of each line is a pattern letter and the next two elements represent {start value, number of consecutive edges} pairs and the remaining entries represent names for the specified edges. Using this method, the example described above can be represented using an NRZ waveform having the following values:

01 => {0,0,0}, {0,1,1 400 ㎱ D}, (1,0,1 400 ㎱ U}, {1,1,0}

Here {pattern letter, start value, number of consecutive edges} is shown. In this example TDL, storing all waveforms defined in the target test language in this way allows a simple comparison of the function of a given waveform of the decomposed STIL waveforms. Thus, the template library is provided in the template file 25 of FIG. 6B.

In comparison, the decomposed STIL waveform and the TDL templates are compared with each other. The STIL waveform is broken down into individual events represented by the combination of the starting value and the number of edges. Data describing the start value and the number of edges of each event of the STIL waveform is stored in the event file 24 of FIG. 6B. Thus, the comparison between decomposition events and the template is made by comparing the starting value and the number of edges. This is originally done as a query on the waveforms by asking, "Can you support multiple edges with this starting value?"

It should be noted that the mapping of the STIL waveform to the template needs to match all of the resulting triples containing the waveform. In the example described above, the letter '01' from STIL results in four triples shown in the template of FIG. All four triples must be mapped for the characters to be fully represented. In this example, the NRZ may support all of the required triples.

As another example of basic template matching, consider the following STIL characters, TDL representation and waveforms with reference to FIG.

0 {} 1 {'200㎱' U; '400 μs' D;} => RZ; T1 = 200 Hz; T2 = 400 Hz;

This corresponds to a zero return (RZ) waveform in TDL with the waveforms shown in the center of FIG. 8. Therefore, the template of the RZ waveform of the TDL is set in the template file 25 of FIG. 6B.

The template matching examples shown in the preceding section are very simple. These match directly with the standard waveforms, NRZ and RZ. Such waveforms may be used in a test apparatus that executes with TDL without any resource penalty. However, in actual test implementations more complex waveforms are also used. Consider the following examples: 01 {'100''D with waveforms shown in the lower half of FIG. 8 and the upper half of FIG. '200 Hz' D / U; '400 ms' D;}. This example means that the letter '0' specifies the falling edge at 100 ms, the falling edge at 200 ms and the falling edge at 400 ms, and the last two edges are redundant and are not actually preserved. The letter '1' designates the falling edge at 100 ms, the rising edge at 200 ms and the falling edge at 400 ms.

The pattern letter "0" can be matched by an NRZ or RZ waveform. The pattern letter "1" requires a more complex waveform, such as an XOR (exclusive OR) of values T3 = 100 ms, T1 = 200 ms, T2 = 400 ms. There are several reasons why undesirable situations arise. First, if two characters are actually used in the pattern block (and the definition enables it), it will cause an on-the-fly wavekind switch. In many ATE systems, this causes a limit of valid resources. In addition, in some systems, the use of an XOR waveform in certain situations may cause a reduction of tester resources. Clearly this is not a preferred solution to the waveform matching problem. Thus, below, some tips that can be used to simplify complex match cases will be described in detail.

Unused Initial Value

In STIL, all the information about the waveforms to be used is provided in the upper front of the WaveformTable structure. Analysis of this information may be performed to determine the characteristics of the effective wave shape. This information can be used to achieve known optimization. In this section, the concept of "unused initial value" is examined to see how it can help with optimization.

First, it should be noted that the set of pattern characters provided in a given signal defines a continuous waveform, even though discontinuous characters are used. Thus, the start state experienced by a given character is based on the end state caused by the previous character. Thus, the end value set is included in the information in the waveform table. An exception to this statement is the user-settable signal start value. In order to enable optimization of the template matching algorithm, it is necessary for the user to choose tactfully a starting value.

Example 01 mentioned above {'100' 'D; '200 Hz' D / U; See 400 'D;} again. Corresponding waveforms are shown in FIGS. 8 and 9. It has already been seen that the completion of the processing of the character set causes undesirable results. When analyzing the character set, it can be seen that none of the characters end with a "U" (raising) value. Thus, by initializing the signal to a value of "D" (falling) and also having only valid characters, the characters never start any cycle to the "U" state. The waveform representation shown at the bottom left of FIG. 9 is reduced (almost) to the form shown at the bottom right of FIG. Thus, a simple RZ waveform (T1 = 200 Hz; T2 = 400 Hz) can be used to match the character set.

Table Based Analysis

Along with the concept of unused initial values, the waveform table-based analysis mechanism of STIL characters is described with reference to the tables of FIGS. 10A and 10B and the charts of FIGS. 11 and 12. This involves creating a list of requirements of all pattern characters and forming a complex representation of some levels of data (S11 in FIG. 11). Note that this data does not need to be compiled for every pin or group of pins, but only needs to be compiled within the signal. For each signal, the wave form requirement data is compiled into three levels:

1. Full signal

2. waveform table, and

3. Individual pattern letters.

Ideally, signal wavebinding is used to characterize the operation of the entire signal so that data is compiled at this level. If this fails, the next logical level is the waveform table. Switching of the waveform tables often does not occur during patterns, and it is assumed that it is likely to occur only during the progression from one pattern block to another. In addition, if switching between pattern blocks occurs at the level of PatternExec blocks, it will be classified into different tests of the TDL code and any differences in wavekind will not cause on-the-fly switches.

Finally, if the operation of the pattern characters in the waveform table cannot be represented by a single wave bind, matching to individual character levels will be attempted. If this fails, it means that some pattern characters in the STIL file contain requirements that cannot be met by the test language of the target ATE system. In some cases, more advanced features of the target ATE system can be used to mitigate these problems. In other cases, this is simply reported as a fatal error in the conversion process.

The data to be stored at each of the levels described above is the same as the starting value and the number of edges required by the STIL pattern characters. It is stored in an array, where the array dimensions are based on the characteristics of the target ATE system. By using the "unused initial value" technique described above, array capacity can be significantly reduced. The number of drive edges that can be supported per set time is read at run time and used for a one-dimensional array. Another dimension is 2, the number of possible start values "1" or "0" of the binary logic system. Each combination of the start value and the number of edges that require support is set to true (T). The rest is set to false (F).

Thus, for the example described above:

0 {} 1 {'200㎱' U; '400 μs' D;} => RZO; T1 = 200 Hz; T2 = 400 Hz

The array is likely to be the table shown in FIG. 10A where it is estimated that at most four drive edges per set time can be supported. In another example:

23 {'100' 'D; '200 Hz' D / U; '400 k' D;}

The table of FIG. 10B includes additional entries. This table describes all the information for the four waveform characters. Since "1" is an initial value that will never occur (unless set during initialization), the above-described unused initial value technique can be applied to the table of FIG. 10B. As a result, the entire column classified as "1" can be set to false, which causes the same situation as described above with reference to the waveforms of the lower left and right sides of FIG. This mechanism can be applied to levels generated, i.e., tables created at any level of signal, waveform table, and pattern text.

A more detailed description of the template matching process is now made. As described above, an array of exploded events (match arrays), each forming a starting value and the number of edges, is generated in the event file 24 of FIG. 6B and compared with the corresponding waveform data of the template file 25. Once the " matching array " described above has been generated and reduced through analysis of the " unused initial value ", a match is made for valid waveforms (S13 in FIG. 11). As described above, waveforms valid for the target ATE system (read at run time) are stored in the template file 25 based on the number of edges and the starting value they can support. The structure of the templates is identical to the matcharray described above except that the entry of each box of the tables of FIGS. 10A and 10B is a set of wavebind object pointers that can satisfy the indicated combination of start value and number of edges. similar.

It should be noted that certain wavekinds will appear in some of the lists that can support various {start value, edge number} pairs. For example, an RZO waveform can be found in the {0,0}, {0,2}, {1,0} and {1,1} array elements because it can support both of these combinations. Note that this relates to the RZO waveform of the TDL without any action of the pattern letter '0'. Thus, there is a {1,0} bond. The industry standard RZ waveform returns to zero for both pattern letters '0' and '1' and {1,0} combining is not possible.

WaveKind objects can be queried for any combination they can support. For example, in order to access an RZO object via the {0,0} entry, the matching process simply returns "Can you support {0,2}" which returns true to the RZO object, "{which returns false" Can you support the other combinations? Thus, the matching process finds the object with the fewest {start value, edge number} pairs required, and then queries the object for the rest of the desired state. If any of these queries fail, WaveKind does not work and the matching process proceeds to the next entry in the unique list and attempts the process again.

If a successful match for a given wave is made, the values of the parameters must be set (S14 in FIG. 11). Decomposed STIL characters contain the time values for the transition, and WaveKind objects contain the strings for the names of related resources. For the RZO waveform, the match in the {0,2} case is completed by associating a time value of 200 ms with a string "T1" and 400 ms with a string "T2". These associated pairings are stored in a table corresponding to the STIL character '1' as defined in the waveform table.

The waveform table-based analysis method utilizes economies that are useful when the source format is cycle-based. Information about the formats to be used in the overall process can be used principally and can be processed, analyzed and optimized before the pattern conversion begins. Once done, the processing of the vectors is very simple. The STIL pattern character is accessed (S21 in FIG. 12), the previous signal value (stored at the end of the previous cycle) is recalled (S22 in FIG. 12), and the data is stored for the {start value, STIL pattern character} pair. Information, that is, used to access wavebind and parameter information determined from the matching process (S23 and S24 in FIG. 12). The end value is then stored at the beginning of the next cycle (S25 in FIG. 12).

This is significantly different from the situation where the source format is event-based, for example, VCD (Value Change Dump) data by Verilog. In this case, the wave format information is usually not important. As the vectors are processed, the matching of the source data to the target wave forms must be performed. This can lead to poor choices that are avoided using suitable table analysis techniques.

Assume the following two cycles of the waveform: If template matching is performed in a cycle-by-cycle fashion (typically in the absence of table-based analysis), the first cycle is likely to end with mapping to NRZ, which is a constraint. This is the simplest waveform that can satisfy. The second cycle is obviously RZO. Knowing the second cycle when processing the first cycle, it is noted that the first cycle may also be mapped to RZO, and the on-the-fly wavekind switch is prevented. Table-based analysis methods provide this capability.

Output Signal Conversion

The above description focuses on mapping input STIL characters to TDL equivalents. In this case, "input" means a test pattern provided to the pin of the device under test (DUT). As mentioned above, the test vectors include test patterns (input) and strobes (output or comparison). The strobe is a timing pulse with an edge (no pulse width) or window (selected pulse width) for sampling the device output signal. Here, output mapping techniques dealing with the conversion of strobe signals (comparison) in the STIL format to the TDL format are described. The actions specified in the STIL file can be translated directly into pattern characters. E.g:

LHZX {'0' 'Z; '0' X; '260㎱' L / H / T / X;}

Can be mapped directly to edge strobes for a suitable value, if all are applicable. In other words, template matching is unnecessary in this process. Similarly:

LHZX {'0' 'Z; '0' X; '260 μs' 1 / h / t / x; '500㎱' x}

Can be mapped to a suitable window strobe.

There are a few things to note about the output transformation. The first is that some ATE may not allow switching of strobe type on the fly. Thus, the edge and window strobes cannot be mixed. The solution to this case is to make all the strobes as window strobes with the edge strobes as window strobes as narrow as the system allows. The second is that STIL pattern characters that request multiple strobes within a cycle may or may not be compatible with the target ATE system. The functions of the ATE system family are built into the conversion tool with resource files that are read at run time to indicate which subset of these features are actually provided in a given target ATE system. This includes operations such as transition and double strobe modes.

Bidirectional Signal Conversion

Bidirectional signal conversion provides the greatest complexity in the overall process. The term "bidirectional" herein refers to the conversion from the STIL format of the test language to the native language format for test vectors assigned to device pins that act as both input and output. All the functions necessary for the input and output matching described above are provided as well as additional functions unique to the bidirectional signals. In addition, bidirectional signals often limit tester resources above and below that placed by simple input or output signals. As an example, the number of valid edges can be reduced due to the need for driver control signals to determine the direction state of the bidirectional signal.

Driver control considerations are based on the characteristics of the STIL pattern characters and the capabilities of the target ATE system. The standard paradigm is to provide two driver enable modes. One mode is to mimic NRZ operation and the other is for RZ. In the former case, the cycle becomes a "drive" (input) at some point and the method is maintained through ending the cycle. In the case of RZ, the cycle is "drive" and then "compare" (output) during the cycle. Note that a cycle in "comparison" mode does not mean that the comparison is actually occurring, but merely that the pin will be treated as an output. This distinction to the target ATE functions for driving and comparing cycles is important.

The driver enable mode is determined from STIL pattern features by noting that the NRZ driver enable mode is good because it requires less tester resources. The mode is selected unless specifically required to use the RZ mode. This only occurs when the "drive" region is surrounded by "comparison" regions of the same cycle. In other words, the comparison may not actually occur and the device pin will act as an output. The time values of the driver control edges are determined from the transition times for the signal direction.

By including the driver type information, the "match array" process described above is considerably more complicated. The drive portions of the signal are matched against valid waveforms, and the entire character of the cycle is compared to the functions of the target ATE system in that the "drive" and "compare" portions.

STIL includes the concept of a "DrivePrior" event. This means that it contains the drive values most recently used by the system. For input signals, the previous drive value is always the final state of the signal, so it does not need to be considered. The output signals do not have drive states, which is meaningless. Thus, DrivePrior is only relevant for bidirectional signals that represent the final drive state achieved by the signal regardless of any arbitration strobe activity. In some ATE systems, the presence of a strobe character affects the driver state of the system. For example, if the final "drive" state is "D" and a strobe of "H" follows, the driver may be set to the "U" state for the next drive cycle. "DrivePrior" is intended to handle this case. In the conversion process, the previous state as well as the actual current state of the driver must be preserved. The result is that the "match array" described above contains four columns instead of two corresponding to all possible pairs {previous value, DrivePrior}. That is, the column heads (FIGS. 10A and 10B) are {0,0}, {0,1}, {1,0} and {1,1}.

The data used in these entries must be used properly for the "DrivePrior" concept to work properly. As given by the "DrivePrior" value, the desired initial state must match the actual state of the driver, the previous value. Using the example described above, the driver is in the "U" state and the STIL pattern character is asking the device to be in the "D" state based on the inclusion of the "DrivePrior" or "P" event in the representation. The waveform selected to match this pattern letter must drive these pins from the "U" state to the "D" state at the desired time by adjusting these values. This may cause additional edges that do not appear easily from the STIL pattern character representation.

Special Features

In the following, a test language transformation is further described with respect to the processing of certain functions provided to the target ATE system. These features represent the features found in the Assignee's ATE system, the Advanced Model T6600 IC tester family, but are quite common and may be found in a variety of test systems in some form. Thus, a brief discussion of the algorithm used to map STIL information into these functions is made.

Multi-Clock Signals

The multi-clock (MCLK) signal type is typically used to provide more pulses per cycle than the ATE system can theoretically provide. This is done for repetitive waveforms by breaking the tester cycle (internally) into a series of subcycles and providing multiple copies of the basic waveform, one per subcycle. The result is that there are more edges than are possible in the relevant test cycle.

An important point in using the MCLK paradigm is that the waveform must contain a basic repeatable unit within the cycle. During the template matching algorithm described above, if the STIL pattern character is found to contain too many edges, an attempt is made to match the character using the MCLK format. For this purpose, the number of edges must be even (MCLK format is pulse base). Constraints that must be satisfied for the single-pulse repeatable waveform are derived from the upper waveform of FIG. 13.

To have a repeatable unit, the widths of all the pulses need to be the same. Also, the spacing between the pulses must be equal to the sum of the space A before the first pulse and the space B at the end of the last pulse, as shown. This means that it is necessary to have a basic repeatable unit, such as RZ, where T1 = A, T2 = A + PW and the subcycle length is A + PW + B. If any of these conditions are not met, a single pulse basic repeatable unit cannot be provided.

It is possible to create a double-pulse basic repeatable unit. Requirements are derived based on the bottom waveform of FIG. In this case, there are two pulses per repeatable block and the corresponding pulses need to be the same width, in which case the pulses are classified as PW1 and PW2. The sum of the time space and the end space must match the interval between repeatable unit iterations as described above (repeatable unit space = A + B). In addition, the spacing C between the pulses must be the same for all repeatable units. Thus, in this case, the subcycle length is A + PW1 + C + PW2 + B.

Pin Multiplexing

In pin multiplexing (PMUX), two tester channels are combined to drive a single pin. This allows resources for both tester channels to be used for the same signal and allows drive (input) and compare (output) in the same cycle in an ATE system, which may otherwise be invalid.

You can use PMUX to make ATE programming tasks easier, but it adds complexity to the conversion process by providing additional freedom. It may seem desirable in terms of providing flexibility, but it makes the wavebind space search more difficult because the requirements are not precisely required. In the following, the meaning of PMUX for various pin types will be described.

(1) input PMUX

The input pin mapping is implemented by searching the wavebind space to match the requirements of the STIL pattern character and the functions of wavebind. Details of this method have been described above. When the input signal is used with PMUX, the responsibility of matching the requirements of the STIL pattern character is shared between the two tester channels. The issue provided by the added flexibility is determining how "requirements are shared."

One way is that the simplest sharing algorithm does not share at all. If possible, one pin does all the work and the other does nothing. To do this, an attempt is made to map all of the edges specified by the STIL pattern letter to the first tester channel. The matching that occurs here is the same as the matching described above for the non-PMUX input signals. If the match attempt fails, that is, if there is no wave bind that can satisfy some of the requirements of the STIL pattern character, a difference occurs. Previously, this situation resulted in an attempt to use MCLK, or caused an error report. In the PMUX case, one edge is shifted from the first channel to the second channel, and a match for the first channel and the second channel is attempted separately. For all the requirements for the STIL pattern character, the shift of the edges continues until a match for both channels is possible.

The complexity of this algorithm needs to be added to maintain continuity between the two component channel operations. Some channels "remember" the final state of the last cycle. However, the state of the driver for the device has been set by signals from other channels. For example, if channel 1 drives the pin in the "H" state, it will have the previous state "H". Now assume that channel 2 drives the pin in the "L" state. When channel 1 drives again, it "remembers" to be in the "H" state, but with the action of channel 2, the driver is actually in the "L" state. In order to prevent this situation, coordination between two channels containing a signal is required.

As an example, consider the signal of the topmost waveform of FIG. Where T ₀ represents a cycle boundary. This signal is very simple and seems to have the NRZ character for the first signal. In fact, the second signal does not need to do anything except to keep it explicitly low. Consider a first pass solution to this problem shown in FIG.

The proposed signal for channel (pin) 1 provides the rising edge at T _a as desired (second waveform from top of FIG. 14). Since there are no edges in the second portion of the signal, pin 2 does not need to have edges (third waveform from top of FIG. 14). In the second cycle, pin 1 remains high because there are no edges. In the second part of the cycle, there is a low-going edge. Since pin 2 is already in the "L" state, no edge is created.

It can be clearly seen from the above example that the simple method does not work in this case. The signal seems to be exactly the waveform of pin 1 because pin 2 does not have edges. This occurred because continuity for the channels was not maintained. In the case of a transition to "L" in T _a of the second cycle, pin 2 needs to know that pin 1 has ended in an "H" state in order for the continuous edges of the system to be properly processed. This can be accomplished by replacing the waveform of pin 2 described above with the waveform shown at the bottom of FIG. 15.

Here, the waveform for pin 2 is in the "H" state at the split time. This has no effect on the composite signal because the driver is already in the "H" state due to the action of pin 1. However, it makes pin 2 consistent with pin 1. When the low-going edge occurs in the second cycle during the pin 2 portion, a low-going transition of pin 2 at T _b is caused as desired. This accounts for the channel coherency problem that must be addressed for PMUX signals.

(2) output PMUX

As in the case of general pattern matching, the conversion of the output signals in the presence of PMUX is simpler than the input conversion. The cycle is divided into two parts, and strobe edges are assigned to two channels (pins) based on the position related to the split time. For convenience, the split time is chosen in the middle of the period. Strobe edges occurring before this time are assigned to the first channel and strobe edges occurring later are assigned to the second channel. One notable exception to this rule is window strobes. They may not be divided for the boundary between channels. Thus, the split time is selected such that the entire window strobe falls within one of the channels.

(3) bidirectional PMUX

Using PMUX with bidirectional signals allows functions that may not be valid in other cases. This is primarily used for PMUX structures rather than for pure input or output signals. Perhaps the most important use of PMUX is to enable it if the target ATE system does not allow drive and comparison in one cycle. If the STIL pattern letter for the bidirectional signal specifies pure drive or compare operation for one cycle, the processing is virtually the same as described for the input and output pin multiplexing described above. When operations are mixed, the splitting time for splitting cycles between channels is based on the direction switch time. This leads to a very natural division of responsibility of the two channels. The continuity concept for the channels discussed for the input signals also applies here, but one must take into account the effects of the arbitration strobes.

As described above, according to the present invention, the test vectors of the native test language are converted into the target test language very efficiently and very accurately.

While only the preferred embodiments have been shown and described in detail, it will be appreciated that many modifications and variations of the present invention are possible in light of the above teachings and also without departing from the principles and intent of the invention, within the limits of the appended claims. .

Claims (8)

In a method for converting test vectors in an original cycle based text language into a target cycle based text language, A set of templates describing the waveforms by reading valid waveforms defined in the target test language, each template corresponding to a waveform of the target test language and including at least a start value of one segment of the waveform and consecutive edges of the waveform; Including data indicative of the number; Reading test vectors in the eigentest language to form a waveform of the test vectors in the eigentest language, a set of constituent events, each event comprising at least the starting value of the waveform and the number of consecutive edges; Decomposing to comprising data representative; Comparing the template derived from the waveform in the target test language with the set of events derived from the native test language; When a match is detected in the comparing step, the waveform data is stored in the target test language, the corresponding parameters of a waveform of the test vectors in a native test language are retrieved, and the parameters are matched with the matched waveform data. Storing in combination with; And Forming a representation of the waveforms in the target test language by repeating the steps described above for all of the test waveforms in the native test language. Test language conversion method comprising a. The method of claim 1, Apply the comparison algorithm at different levels of abstraction, in order of signal level, wavekind level in which the signal is composed of a number of wavekind, and character level order in which the wavekind is comprised of a plurality of characters. A test language conversion method, characterized by the steps of The method of claim 1, And the set of events is stored in a table format having columns assigned to the data representing the number of consecutive edges and the starting value. The method of claim 3, The table storing the set of events is optimized by examining the start value of a particular event based on an end state generated by a previous event, thereby simplifying the data of the table. . The method of claim 1, The test vectors include drive signals to be provided as input and strobe signals to the DUT to sample the output of a device under test (DUT) for evaluation, and the drive signals in the native test language to detect the match. And converting the template and the set of events into the target test language, wherein the strobe signals in the native test language are translated directly into the target test language. The method of claim 1, A plurality of subcycles in the target test language if the waveforms in the intrinsic test language are required by resource limitations—the plurality of subcycles in a test system operated by the target test language. And generated by multiplexing the test cycle clock. The method of claim 1, The waveforms in the native test language are multiplexed to be connected to a single pin of a DUT in a manner configured by a test system operated by the target test language, the plurality of test channels in the target test language. Test language conversion method, characterized in that it is assigned to. In a method for converting test vectors in a Standard Test Interface Language (STIL) into a target cycle based test language, A set of templates describing the waveforms by reading valid waveforms defined in the target test language, each template corresponding to a waveform of the target test language and including at least a start value of one segment of the waveform and consecutive edges of the waveform; Including data indicative of the number; Reading the test waveforms in the STIL format to decompose the waveform of test vectors in the STIL format into a set of constituent events, each event comprising data representing at least the start value of the waveform and the number of consecutive edges; Making; Comparing the template derived from a waveform of the target test language with the set of events derived from the waveform of the STIL; Storing the waveform data in the target test language when a match is detected in the comparing step, retrieving corresponding parameters of the waveform of the test vectors of the STIL, and storing the parameters in combination with the matched waveform data. ; And Forming a test vector file of the target test language by repeating the above steps for all of the test vectors in the STIL Test language conversion method comprising a.