Test Languages:STIL

STIL

STIL is used as an interface between test tools and test equipments. Test tools generate a set of test vectors for a design with specified timings. They can be applied to the real design and their responses can be compared with the expected outputs using a STIL file loaded to an ATE. Unlike WAVES, which is a set of packages written in VHDL, STIL is a stand-alone language and not a library.

Several test tools that generate test vectors for design inputs or its scan chains have the option to save their generated test vectors in the STIL format. In contrast, STIL has become a popular language supported by most ATEs. Since STIL is easy to understand, a STIL file can also be generated or changed manually. As there can be a large number of test vectors to test a design, this standard also accepts GNU gzip format as its input file. This reduces the amount of data transferred to ATE.

The STIL standard was published in August 1999 under the IEEE standards for digital test vectors. In December 2002, the STIL working group released another version of this language identified as the IEEE 1450.2-2002. This version was an extension to STIL for DC-level specification. In June 2005, another extension to STIL for semiconductor design environments was published under the IEEE P1450.1 standard. Other extensions are also being developed by the STIL working group. An extension to STIL for supporting core test language (CTL) has been approved in 2005 under the P1450.6 standard. Extensions to STIL for tester target specification (P1450.3), test flow specification (P1450.4), semiconductor test method specification (P1450.5), and analog and mixed-signal (P1450.AMS) are the extensions that the STIL working group is working on.

In the next section the different parts of a STIL file, its constructs, and a simple example for each construct will be described. Then, a sample test vector file developed in STIL (IEEE 1450.0-1999) will be demonstrated to test Sayeh processor (this processor is discussed in Section 86.3). To study more details on STIL, see Refs. [3,4].

STIL Syntax

The main purpose of STIL is to develop a file containing the characteristics (IO pin information), related input test vectors and expected responses of a design in a proper timing. This file consists of several different parts and blocks. These parts must be ordered as defined in the STIL standard. These parts and their ordering are listed below.

1. STIL statement

2. Header block

3. Signals block

4. SignalGroups block

5. ScanStructures block

6. Spec block

7. Timing block

8. Selector block

9. PatternBurst block

10. PatternExec block

11. Procedures block

12. MacroDefs block

13. Pattern block

The above-mentioned parts will be discussed in the following subsections. There are also other blocks and definitions that can be written in any part of a STIL file. These parts are:

• Ann. This keyword shows an annotation statement and can be placed anywhere after the STIL

statement.

• UserKeywords. The UserKeywords defines additional keywords to STIL. This construct can be written anywhere in a STIL file, not inside STIL blocks.

• UserFunctions. It defines additional timing expression functions. It can be written anywhere except inside other blocks.

• Include. This keyword opens a specified file in a STIL file (like #include preprocessor in C-language). It can be written anywhere after the STIL statement.

Several points about this language are worth mentioning. STIL is a case-sensitive language, e.g., InputBus is interpreted different from inputbus. The other point is that the user identifiers in STIL can be defined as both quoted identifiers and nonquoted identifiers. Nonquoted identifiers should begin with an alphabetical or an underscore sign and include only alphanumeric or underscores. In contrast, a quoted identifier can include any character. A quoted identifier should be referenced with its quotes. For example, if a quoted identifier named “my-bus” is defined, it must be referred to as “my-bus” everywhere, and not as my-bus. Identifiers in STIL should not exceed 1024 characters (including the double quotes in the quoted identifiers). In addition, an identifier longer than 1024 characters can be defined by partitioning it into 1024 character-length quoted identifier segments and concatenating the various segments by placing a period (.) between them.

The format of line comments in STIL is similar to those in C++ (// is used). For block comments, (∗…∗) is used.

STIL Statement

The STIL statement specifies the version of STIL used in the file. Its syntax and example are shown in Figure 94.16. In all figures in this chapter, (a) and (b) parts are separated by a line.

Header Block

The Header block comes after the STIL statement and contains file title, its creation date, and other file- related information. Figure 94.17 illustrates the Header block syntax and a related example. Note that History in this figure is a block which contains one or more annotations.

Signals Block

The input and output pins of a CUT are defined inside a Signals block shown in Figure 94.18. Only one Signals block is considered in a file and any other Signals block is ignored by the parser. The following characteristics of a signal can be specified in this block:

• Signal type. The signal type can be In for inputs, Out for outputs, InOut for input/outputs, Supply for power or ground (power supply signals), or Pseudo for a pseudo input/output signal (not a primary input/output).

• Termination. This attribute shows the value that an ATE applies to a signal when it finishes the testing process. Termination value is useful for increasing the fault coverage and speeding up the state transitions in a design. It can be TerminateHigh, TerminateLow, TerminateOff, or Terminate Unknown values.

The TerminateHigh and TerminateLow switch the signal to high and low state, respectively. TerminateOff causes the ATE to set the voltage for the signal to float-state voltage. In Terminate Unknown, the ATE is programmed to set the load to float-state voltage level.

• DefaultState. This attribute indicates the default value assigned to a signal. It is used if the signal is not derived by a test vector.

• Base. A signal can be evaluated by hex (Hex option) or decimal (Dec option).

• Alignment. This attribute is useful when signal groups are used instead of individual signals, and the length of assigned data is larger than the number of signals in the group. It has two options: MSB and LSB. The MSB option maps the left-most bit of the data to the left-most signal of the group and other bits follow this pattern. The LSB option maps the right-most bit of data to the right-most signal in the group.

• Scan Signals. Scan signals include ScanIn and ScanOut and are used to define the scan chain scan-in and scan-out signals of a design. The length of these signals can also be defined.

• DataBitCount. This option is useful for multibit signals. It defines the number of data bits required for a waveform to be completed.

SignalGroups Block

The SignalGroups block, shown in Figure 94.19, defines a group of signals. This group can be empty or it can have only one member. The group of signals is treated as an individual signal in a STIL file. A SignalGroups block may have a domain name. Several SignalGroups blocks with different domain names can be defined in a STIL file, but only one global SignalGroups block can be defined in each file. The syntax and an example of SignalGroups block is shown in Figure 94.19.

ScanStructures Block

The ScanStructures block is an optional block and is mainly used for documentation. In this block, the characteristics of one or more scan chains in the design are specified. These characteristics include the name of scan chain input and output signals, the name of scan cells, the list of scan clocks, and the

inversion value of the scan path. In Figure 94.20, an example and the syntax of this block are shown. The design of the example in Figure 94.20 has two scan chains. The first scan chain has four D-type flip- flops, its input signal name is sc_in1 and its output signal name is sc_out1. The clock signal for this chain is clk. The second scan chain has five master–slave flip-flops. Its input signal name is sc_in2, its output signal is sc_out2, the clock signal for master parts of the scan cells is mclk, and the clock signal for slave parts is sclk. The different parts of the block syntax are:

• ScanChain. This option indicates the name of a chain.

• ScanLength. The length of the scan chain is defined by this parameter. This parameter is mandatory in the block.

• ScanOutLength. This option specifies the number of observable cells in the scan chain. Its default value is the value of ScanLength.

• ScanCells. This parameter is a list of cell names that constitute this scan chain. The number of cells in the list should be equal to the ScanLength parameter. The left-most member of this list indicates the input cell of the scan chain, while the right-most member is the output cell of the scan chain. The order of the cells in the list must be identical to that in the scan chain. If there is an inversion before a cell, it must be defined by ! before the name of that cell in the list. The cells in the list are separated by a white space.

• ScanIn. This parameter defines the signal name through which scan data propagates into the scan chain.

• ScanOut. This parameter defines the output signal of the scan chain.

• ScanMasterClock. This parameter defines the list of signals that are connected to the clock ports of the master latches in a dual memory or the clock ports of single memories.

• ScanSlaveClock. This parameter defines the list of signals connected to the clock ports of the slave latches in a dual memory.

• ScanInversion. The value of this option can be 0 or 1. Value 1 means that an overall relative inversion exists between the input of the first scan cell (before a scan cell) and the output of the last scan cell (after the last scan cell).

Spec Block

The Spec optional block, shown in Figure 94.21, is used for timing purposes. A signal in a design may have different delays in different situations. The kinds of delays defined in STIL are:

• Min. For minimum delay

• Max. For maximum delay

• Typ. For typical delay

• Meas. For measured delay. This delay is measured during run-time and its mechanism is not specified in STIL

In a Spec block, there can be one or more categories and variables defined. A category may contain several variables and each of them can have their own timings. In contrast, a variable may belong to several categories, and it can have different timings in each category. Therefore, Spec blocks can be defined as a list of categories or a list of variables, but not both. The categories can be used in the PatternExec block (see Section 94.2.1.10).

Timing Block

The Timing block, shown in Figure 94.22, is one of the main blocks in a STIL file. The Timing block specifies the waveform values and their timings for design signals. This block contains a number of waveform tables. In a waveform table (defined by WaveformTable block) a cycle time and the list of signals and their waveform shapes (defined in Waveforms block) are defined. All shapes in the Waveforms block use the same cycle (period) in a waveform table.

The Timing block is a large block of STIL. We will discuss each part and option of this block with simple examples.

• SignalGroups. This part is optional. In this part, the signal groups for which timings are to be defined are selected. In the absence of this part, the global SignalGroups block (a SignalGroups block with no domain name) will be used.

• WaveformTable. A Timing block can have several waveform tables. A waveform table has its own period (cycle) and waveform shape for the signal groups. The following options are defined inside a WaveformTable block.

• Period. This option indicates the period of signals defined in the Waveforms block. For example, the expression Period ‘500 ns’; indicates that each test vector is applied 500 ns after the previous one.

• InheritWaveformTable. This construct allows the use of definitions done in other waveform tables. A local definition always overwrites the inherited definition. The Period option can be removed from a waveform table if we inherit a waveform table that already has a period.

• SubWaveforms. Waveforms defined for different signals may have common parts. We can define common parts of several waveforms in the SubWaveforms block and use it in our waveform definitions. A SubWaveform is referenced in a waveform definition by its label (SubWaveform label in Figure 94.22). A SubWaveform can have a duration (defined by Duration keyword in Figure 94.22). This duration is used when a SubWaveform is repeated in a waveform. The rest of a SubWaveform block is an event list definition which is similar to the definition of an event list in Waveforms block and is described in the Waveforms part, described next.

• Waveforms. In this block, which can only be defined once in a WaveformTable block, one or more waveform shapes can be defined for a signal in the design. A signal waveform shape indicates that a given event in a given time should be applied or measured on that signal. A waveform consists of the following parts:

○ Waveform Character. This is a simple character (shown by wf_char in Figure 94.22) which is used in a vector (in the Patterns block). This character is the representative of a set of events that happens on a signal. For example, if we need to apply a periodic 10 ns 0 pulse to a signal,

we can define a waveform for this signal with waveform character s. Then, in the Patterns block, this character can be used to represent the defined pulse.

○ Event label. This is a label (shown by event_label in Figure 94.22) assigned to the time expression that follows it. We can use this label instead of its next time expression in the current block. This label can be interpreted as a local variable which is assigned once by a time expression and can be used several times in other timing expressions. Event labels are useful to calculate the timing of a signal from its durations. There is a special label @ which is used to store the last timing expression used in a waveform.

○ Event. There are several predefined values in STIL for deriving events (used for inputs) and comparing events (used for outputs). Some of these values have both short and long repre- sentations. Events used for inputs include:

■ ForceDown or D. Shows that a signal is forced to be logic low.

■ ForceUp or U. Shows that a signal is forced to be logic high.

■ ForceOff or Z. Shows that a signal is forced to be high impedance.

■ ForcePrior or P. Shows that a signal should preserve its last derived state. Values used for comparison are as follows:

■ CompareLow or L. Shows that a signal should be logic low.

■ CompareHigh or H. Shows that a signal should be logic high.

■ CompareOff or T. Shows that a signal should be high impedance.

■ CompareUnknown or x or X. Indicates that the signal should not be compared with any values.

■ CompareValid or V. Shows that a signal should be compared for a valid logic level. It is compared for a voltage lower than the low threshold or higher than the high threshold.

■ CompareLowWindow or l/CompareHighWindow or h. Shows that a signal should be compared with logic low/logic high in a period of time and should be terminated by CompareUnknown.

■ CompareOffWindow or t/CompareValidWindow or v. Shows that a signal should be high impedance/a valid logic level in a period of time and should be terminated by CompareUnknown.

The following values are expected values from the outputs:

■ ExpectLow or R. The CUT output is expected to be logic low.

■ ExpectHigh or G. The CUT output is expected to be logic high.

■ ExpectOff or Q. The CUT output is expected to be high impedance.

■ Marker or M. With this event, no activity from the CUT or the tester is expected. There are also a few unresolved events defined in STIL as follows:

■ ForceUnknown or N. Shows the driver is turned on, but the up or down state is not defined yet.

■ LogicLow or A. Shows that the driver is low, but its direction is unknown.

■ LogicHigh or B. Shows that the driver is high, but its direction is unknown.

■ LogicZ or F. Shows that the driver is high impedance, but its direction is unknown.

■ Unknown or ?. Shows that the driver has an unknown logic with an unknown direction. Using the events described above, a waveform for a signal can be defined. The shape of this signal is shown in Figure 94.23(a). The STIL file corresponding to this waveform is shown in Figure 94.23(b). In this figure p and n characters are defined for pulsing and turning off the clk signal.

○ Waveform character list. The various waveforms defined by a waveform character for a signal can be merged. The merged waveform is called a waveform list. For example, in Figure 94.23(b) we can merge two waveforms defined for the clk signal as shown in Figure 94.24.

• Using subwaveforms. Figure 94.25 shows an example subwaveform. A waveform can use another waveform as one of its parts. If a waveform is completely similar to another waveform, then it is best to use that waveform by the InheritWaveform option (see the last part of Figure 94.22). A subwaveform should be defined in a SubWaveforms block. This subwaveform can be repeated in a waveform by \rN option shown in Figure 94.22, where N is a positive integer. Also the two formats sub_wf_lab[N] and sub_wf_lab[#] in Figure 94.22 are related to the subwaveform event list with event_num index and are not discussed here.

Selector Block

A Selector block, shown in Figure 94.26, selects a delay type for each variable in a Spec block (see Section 94.2.1.6). These selected times are used in a PatternExec block. The example in Figure 94.26 is based on the Spec example shown in Figure 94.21. In this example, if sayeh-sel is used in a PatternExec block, the default delays for low_to_high will be 2 ns, while the default delay for the high_to_low variable will be 1 ns.

PatternBurst Block

Figure 94.27 shows the syntax and an example of a PatternBurst block. This block defines a set of patterns and defines certain characteristics for them. Application of test vectors defined in a PatternBurst block takes place in a PatternExec block. As shown in Figure 94.27(a) (the syntax part), the PatternBurst block has several parts. In this block a specified signal group, macro definitions, procedures, scan structures, and a termination state for signals can be defined. Also the first and the last test vectors in the burst can be specified (by Start and Stop options).

The main part of a PatternBurst block is the PatList block. In this block, a set of patterns or another previously defined PatternBurst block can be specified. Note that the termination state for a signal in a defined PatternBurst block overwrites the termination state defined in the Signals block. An example of this block is shown in Figure 94.27(b). In this example, list1 and list2 are pattern lists defined in the Pattern block. list2 includes a vector with label vect100.

PatternExec Block

The syntax and example of a PatternExec block are shown in Figure 94.28. This block can be considered as a bridge between the signals in a design and the test vectors. As stated in the previous section, the PatternBurst block defines a set of patterns with necessary macros and procedures. By instantiating a PatternBurst block and a Timing block in the PatternExec block, test vectors in the Timing block and signal waveforms are related to each other. Also a Selector and a Category block are defined in the PatternExec block and linked together. The PatternExec block in STIL is similar to a testbench in WAVES.

Procedures Block

The syntax and example for Procedures block are shown in Figure 94.29. This block performs a given set of operations on its arguments. It can be called from inside a Pattern block, a MacroDefs block, or another Procedures block. When a procedure or macro calls another procedure, the caller procedure should be defined after the called procedure to prevent recursion. Procedures can also have domain names. Only one global procedure (a procedure without a domain name) can be defined in a STIL file.

MacroDefs Block

A macro in STIL is defined in a MacroDefs block (Figure 94.30). Macros are similar to procedures. A macro is expanded via the Macro statement. Unlike procedures, macros do not need to be meaningful portions of a block. For example, the procedure of Figure 94.29 must have a waveform statement, while in the macro of Figure 94.30 the waveform statement (W wf1) can be removed. This is because this statement can be defined before macro expansion.

Pattern Block

Test vectors and the expected output responses are defined in the Pattern block. As shown in Figure 94.31, this block contains an optional statement for time unit definition and several pattern statements.

Pattern statements have been designed to define a set of test vectors for a design. There are several types of Pattern statements which we list below:

• Vector statement. A test vector is applied by this statement. Its syntax is shown in Figure 94.32.

As shown in the syntax part of Figure 94.32, there are two kinds of data for a test vector: cyclized and noncyclized. Cyclized data are the vectors that are applied in common period of time (defined in the WaveformTable block). V {Abus = 00011010;} defines data on Abus as cyclized data. On the other hand, a noncyclized data is a kind of data that is applied to the design or measured from a design in a specified time. Its syntax and an example are shown in Figure 94.33. In this figure, the time_value is a positive integer which shows the relative time (in the defined time unit) to the start of the vector (or a common T0).

In addition to cyclized and noncyclized data, there is a serial data construct defined in STIL. This is useful for applying and reading data to and from a scan chain. An example of two vector statements is shown in Figure 94.34.

• WaveformTable statement. A waveform table, shown in Figure 94.35, is defined in this statement. Signal values in the vector statements up to the next WaveformTable statement follow the timings and shapes defined for the waveform characters in this defined WaveformTable.

• Procedure call statement. A procedure can be called in a Pattern block, as shown in Figure 94.36. Arguments can be passed to the procedure being called.

• Macro call statement. Similar to a procedure, macros can be called inside a Pattern block. This is done by the Macro keyword, as shown in Figure 94.37.

• Goto statement. An unconditional branch can happen inside a Pattern block by the Goto

statement. The syntax and an example of the Goto statement are shown in Figure 94.38.

• Condition statement. This statement, shown in Figure 94.39, causes an input vector or output value to be established, but its actual application is postponed until a vector statement is defined.

• Loop/MatchLoop statements. A Loop statement repeats a set of vectors for a specified number of iterations. Its syntax and an example are shown in Figure 94.40. A Loop statement can enclose another Loop statement. MatchLoop statements are conditional. They can be infinite loops (until that condition is met) or they can have an upper limit. Figure 94.41 shows the syntax and an example of a MatchLoop statement.

• Breakpoint statement. The Breakpoint statement, shown in Figure 94.42, is generally used for segmenting a large number of vectors (which may exceed the memory of the tester). A Breakpoint statement may also contain a statement. The signals in this statement run until the next vector after the Breakpoint statement is executed. The other signal values of the CUT do not change during this statement.

• IDDQ testpoint. This statement is used when an IDDQ measurement is to be performed on a design. Its syntax is shown in Figure 94.43.

• ScanChain statement. This statement defines the name of the scan chain on which the data is going to be applied. Figure 94.44 shows its syntax and an example.

• Stop statement. The Stop statement (its syntax is (label:) Stop;) stops the execution of patterns.

This section gave an overview of the STIL language. Other details and features not discussed here can be found in references listed at the end of this chapter [3,4].

An Example: A STIL File for Sayeh Processor

A simple example of a STIL file is demonstrated in Figure 94.45. Only a few of STIL features are used in this example. This example tests a processor called Sayeh by first resetting the processor (this is done by activating the ExternalReset signal), and then pulsing the clock in each tester cycle. For testing this processor, a specified program, which has known outputs, is loaded into the memory of the system. Therefore, after each cycle address and data busses (Abus and Dbus in Figure 94.45) have known values. The tester would stop applying the vectors to the CUT (Sayeh in this example) when it reaches the vector labeled sp_lab in the Pattern block. In the next cycle after applying this vector, data bus and address bus go to the high impedance state.

Our Coverage of STIL

In this section, STIL, which is a language used for testing a design, was discussed. This language is widely used for manufacturing test, and many commercial test tools and ATEs support this language. This section used several illustrative examples to discuss syntax and semantics of STIL. The last section in this section showed a complete example of STIL for testing a simple CPU.

This chapter discussed two test languages widely used in design and hardware testing. The first language was WAVES, which is actually a library based on the VHDL language. The second part of this chapter discussed the STIL language. STIL is a stand-alone language for testing devices and designs. Several examples were discussed in this chapter, which describe the features of these two languages.