Elements of STIL bridge design and test

The Standard Test Interface Language (IEEE Standard 1450) defines a common data format to facilitate the transfer of high-density digital test patterns among automatic test-pattern generators, BIST tools, simulators, and ATE systems.

Tony Taylor and Robert Ruiz, Synopsys, Mountain View, CA -- Test & Measurement World, 1/1/2001

The need for a common standard for the “EDA-to-tester” data flow is clear. A multiplicity of standards was fostering duplicated effort, wasted resources, and user frustration. About five years ago, a group of ATE and EDA tool users launched an effort to develop a standard test interface language (STIL, pronounced “style”) for transporting test-pattern data to all makes of high-speed IC production-test systems. This community of users needed improvements over proprietary formats and WGL—the de-facto standard.

The work on STIL is being carried out under the sponsorship of the TTSC (Test Technology Standards Committee) of the IEEE. Because the most successful standards are those built upon existing, time-proven practices (or in this case, languages), the STIL committee began its work by soliciting input from all interested vendors. Submissions were received from several companies: the UTIC language from Motorola, an IBM internal standard language, enVision from LTX, TDL from Texas Instruments, and WGL from Summit Design.

Much of the first year was spent analyzing the benefits of each of these languages, and serious consideration was given to simply adopting one of them as the standard. After many meetings and deliberations, the committee decided to take the best of each language and build a new standard.

The basic syntax structure of STIL comes from UTIC, which defines the basic way that blocks and statements are constructed. The enVision language provides STIL’s timing and waveform flexibility. And STIL’s most influential contributor is WGL, because it is the most widely used.

WGL is a proprietary language developed by Test System Strategies Inc. (TSSI) and is now owned by Fluence Technology (Beaverton, OR), TSSI’s successor company, after an intermediate ownership by Summit Design. WGL was created roughly 15 years ago to support a tester-translation product in a tester-neutral syntax. For many years, WGL has been the best language available for translation needs, and many other companies have adopted it for their own tools and applications.

The P1450 committee took advantage of the way WGL supports scan-chain definitions and the application of scan-shift procedures and built these features into STIL. Also from the WGL influence comes the STIL technique of using events (e.g., drive-up, drive-down, drive-on, drive-off, compare-high, compare-low) to define waveforms as opposed to fixed waveform definitions as is common in ATE languages (such as RZ, NRZ, and DNRZ).

Before any input from WGL or other sources, the STIL committee’s initial plans for the language targeted these main objectives, listed in order of importance:

• solve the “gigabyte” problem—that is, provide a way to transport large volumes of data efficiently,

• provide a standard that all ATE manufacturers can use, and

• provide a language flexible enough to address all current and foreseeable needs.

Activity beyond the initial IEEE 1450-1999 core specification is also under way on five “dotted extension” Project Authorization Requests (PARs)—see “STIL Extensions in Process”.

Waveform representations evolve

Like WGL, STIL expresses a signal waveform that, along with a vector in a pattern, defines the activity on all DUT inputs and outputs. The data structures that in WGL are called Timeplates become WaveformTables in STIL. Although Timeplates and WaveformTables share some concepts, they also have some significant differences (Figure 1). The events in both cases are a series of up/down/on/off identifiers that are independent of any given tester. Yet, WaveformTables and Timeplates differ significantly in the level of flexibility they provide.

WGL supports a limited number of vector characters available for selecting waveforms: 0, 1, X, and Z. Only a single waveform type can be defined by the data state (0/1), the compare state (High/Low/Don’t Care), and the drive state (On/Off). Any signal changes a design engineer makes require a new Timeplate; and because each Timeplate must define all signals, even if only one is different, a great deal of redundant waveform definitions accumulate. This is sometimes referred to as the “Timeplate explosion” problem (Figure 2).

STIL addresses this issue by allowing use of the full alphanumeric set in vectors; up to 63 different waveforms can be defined on any given signal. In addition, within a STIL WaveformTable definition, one waveform table can reference another. The new one need redefine only the unique parts, leading to many fewer definitions. In fact, a designer should never need to define a given waveform more than once.

STIL WaveformTable representations afford considerable flexibility in the number of actual waveforms that may be associated with any given pattern. Any number of WaveformTables may have the same name as long as each is contained in a different STIL “Timing” block. The top level “PatternExec” block selects which waveforms to apply to a DUT. In contrast, the Timeplates in WGL must be part of the pattern file, and only one pattern may be defined in each file. Thus, in WGL, designers must define timing repeatedly.

Efficient vector data formatting

STIL addresses the primary objective set by the STIL committee—solving the “gigabyte problem” to permit the efficient transport of large volumes of data. A STIL file is typically about 30% to 50% the size of an equivalent WGL file (on a fully self-contained file that comprises a single pattern with the necessary signal, waveform, and pattern data). The main reason for this reduction is the STIL vector data format.

In STIL, for any bidirectional signal, a single character can represent the information that in WGL requires three characters—one for the input state, one for the output state, and one for a space character between the two. Also, in STIL, only signals that change need be referenced in any given vector. All unspecified signals are assumed to repeat the behavior of the prior vector.

In addition, STIL has included a number of other vector-formatting capabilities. These features may be beyond the implementation capabilities of present-day testers, but they are proving to be useful in efforts to test embedded cores in system-on-chip (SOC) ICs. For example, the IEEE P1500 committee (see "IEEE P1500 STIL core test language”), which is developing a core test language for SOCs, is making use of these STIL vector-formatting features.

Macros and procedures

STIL provides a means of reducing pattern data through the use of macros and procedures. In STIL, macros are defined only in the context of patterns because that is where the bulk of the data volume exists. In addition to reducing the amount of data, these macros define complex sequences of vector operations that are required repeatedly. These constructs allow for the definition of

• operations that are expected to be flattened out into “in-line” vectors (macros) and

• operations expected to be executed by transferring control to a single instantiation in vector memory (procedures).

In practice, either type of operation may be made into in-line vectors if a particular test system requires it. The P1500 committee is fully exploiting this type of flexibility.

A major use of procedures is in defining protocols for loading and unloading IC embedded scan chains. STIL allows any combination of vectors and shift operations to accommodate the various types of protocols that devices require. With use of these protocols, test engineers can easily see the scan-pattern data and scan-shifting sequence partitioned, making for easy debug.

Scan structures

A strength of WGL is its ability to reference a DUT’s scan-vector data back to an original device design. The STIL committee recognized the value of this approach (which can be invaluable for diagnosing device failures), and although STIL’s data representation differs significantly from WGL’s, STIL retains a WGL-like design back-annotation capability.

In STIL, scan data is formatted as needed by a tester (if there are any inversions in the scan chain, the data is formatted into tester-ready states). A STIL data structure called the ScanStructures block provides for mapping data back to the design environment. ScanStructures can model complex cells (those having several I/O connections exhibiting individual inversion conditions) that WGL can’t accurately represent. ScanStructures is unnecessary for production go/no-go test.

Finally, to reduce the amount of storage needed for scan data on a device with full scan, scan data in STIL can be represented in a compact hexadecimal format. T&MW

For more information

STIL working-group home page: grouper.ieee.org/groups/1450/. 

Tony Taylor is R&D manager of TetraMAX ATPG, Test Automation Products at Synopsys and co-chair of the IEEE-1450 (STIL) working group. E-mail: tonyt@synopsys.com.