CTL: the new language of DFT; what is CTL, and why is it important to the semiconductor industry? The answers are here

EE-Evaluation Engineering, Oct, 2003 by Kathleen R. Miller, Wayne J. Lonowski, Rohit Kapur, Peter Harrod, Davide Appello

Although the IEEE 1450.0 Standard Test Interface Language (STIL) was adopted in March 1999, widespread industry acceptance was quite slow. In contrast, the IEEE P1450.6 Core Test Language (CTL) has not been adopted yet, but already a complete design-through-test solution based on CTL is available to the industry.

[ILLUSTRATION OMITTED]

Starting With STIL

STIL is a broad industry-standard initiative intended to enable unambiguous and complete communications of test and design-for-test (DFT) information throughout the design-to-manufacturing flow. The emerging STIL standard includes several extensions. Some have been adopted; others are in varying stages of development.

Typically, when engineers discuss STIL, they are referring to IEEE 1450.0, the extension that defines the standard data format used to convey vector and timing information from automatic test pattern generation (ATPG) tools to test program generation tools.

When STIL was adopted, the industry already had matured with solutions based on existing vector languages such as Waveform Generator Language (WGL). STIL presented a more efficient representation over the existing solutions. However, not enough of the significant new capability inherent in the language had been implemented to provide a compelling reason for potential users to change their existing infrastructure.

And although point solutions existed for some time, a complete, seamless, STIL-based DFT solution was not available until very recently. Without a complete solution and a compelling reason to change, adoption was very slow.

However, as system on a chip (SOC) companies recognized the powerful time-to-market and cost-of-test savings inherent in emerging STIL extensions, demand for support increased. Electronic design automation (EDA), ATE, and test program generation tool companies responded to the increasing interest in STIL with new standards-based products for intellectual property (IP) core and SOC providers.

[FIGURE 1 OMITTED]

Today, EDA, ATE, and test program generation tool support for STIL is an assumed capability. As the time-to-market and cost-of-test benefits of the STIL extensions crystallize, momentum in the market around these standards continues to build. To make this point, we will explore one of these extensions, P1450.6, in greater detail.

CTL-Based Solutions

CTL (P1450.6) is an extension of STIL that creates a standard format to describe IP core and SOC test information. The IEEE CTL committee was initiated on July 4, 2001, and has been active since its inception, with members from many companies. CTL has been stable for more than a year, and activity is matured to review stages that will lead to balloting in the near future.

CTL is a software language targeted to SOC DFT, just as COBOL is targeted to business applications and SNOBOL to string manipulation for text editing. CTL can be used to capture all of the data needed to test each IP core in the device hierarchy. It enables unambiguous communications of test-related information among core providers and system integrators dealing with test issues on the SOC. If successful, CTL, together with other STIL extensions, will greatly facilitate IP core and IP core test reuse for SOCs.

As shown in Figure 1, information represented in CTL is partitioned across configurations of the design. These configurations are called test modes.

To handle the needs of different designs, the language uses sequences that establish the test modes by leveraging STIL syntax. For each test mode, CTL provides information about structures available, characteristics of the terminals of the design, connectivity that is relevant to test applications, and test patterns. With test information for a core provided in CTL, you can reuse the test patterns that came with the core; perform all the necessary DFT, ATPG, and fault simulation operations on the SOC; and successfully test the SOC logic in the presence of the cores.

A public document of the standard explains its intent and generality and provides examples for understanding basic CTL concepts. (1)

CTL is designed to allow any DFT and test methodology to be used. Considering all the possible integration scenarios of cores, the language literally must describe every known DFT concept and test method. This generality allows for many other applications of the language.

CTL can be used to perform hierarchical DFT and as an information-rich test interface between the design environment and the ATE environment. CTL constructs that were created for test-pattern reuse support test methodologies that depend on protocol manipulation after the fact. For example, test patterns supplied with one interface could be changed to work with an alternate interface for improved ATE utilization using a concept called retargetable tester patterns. (2)

Of course, the adoption of CTL is not without barriers. Specifically, CTL is a very extensive language. The sheer number of constructs and the flexibility of the syntax will prevent parties from immediately adopting the language as a whole. Instead, usage is likely to begin with support of a limited number of CTL constructs. Eventually, as applications are developed and usage increases, the language will be supported more widely.