Printer Friendly

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

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.

Because of this expected transition from partial to complete support, it is critical for SOC providers to ensure that all tools in their CTL-based SOC development process are well integrated. For example, it will be critical that the downstream test program generation tool used in the development process supports at least the same constructs as the upstream ATPG tool used to generate the STIL patterns.

Fortunately, key companies in the areas of EDA, ATE, IP core, and SOC development already have been working to provide a cohesive, CTL-based DFT solution for the semiconductor industry. Initial CTL-based solutions provided by Synopsys, Agilent Technologies, and ARM have been announced. ST Microelectronics also has worked to verify early CTL-based product solutions and actively promoted CTL in industry forums. With initial products and tools already available to users, it is expected that industry adoption of CTL should follow soon.

[ILLUSTRATION OMITTED]

CTL-Based EDA Tools

Synopsys recognized early on that developing a commonly shared information conduit could bridge the gulf between the independent steps involved in creating an SOC and dramatically improve time to market for the users. The company identified this potential in P1450.6 and, from there, became the first EDA tool provider to announce CTL-based design generation and ATPG support.

[FIGURE 2 OMITTED]

Its DFT Compiler[TM] SOCBIST tool, announced in March, resulted in a core creation flow that outputs CTL for core providers and an SOC integration flow that accepts core-level CTL for DFT/ATPG tasks at the next level of integration (Figure 2). In addition, the hierarchical DFT available through CTL eliminated issues with very large designs, giving the standard DFT tool the capacity to handle designs it could not accommodate before.

Because CTL is not yet adopted, the Synopsys design tool flow was built on a specific draft of the emerging standard. To ensure a smooth DFT flow for its customers, Synopsys worked closely with Agilent Technologies to develop that company's test program generator and related tools, particularly the Agilent SmarTest PG CTL Browser.

[FIGURE 3 OMITTED]

CTL-Based ATE

From Agilent Technologies' perspective, standardization of the interfaces between design and test offers one of the best opportunities for accelerating IC product development. In 2001, Agilent and Synopsys announced their strategic alliance and intent to improve time to market and cost of test with EDA-aware ATE and ATE-aware EDA. STIL, with CTL and other STIL extensions, provides the mechanics to make much of this happen. By moving forward with CTL even before it is ratified as a standard, the two companies have enabled faster industry evaluation and implementation, particularly by early adopters such as ST Microelectronics.

The Agilent CTL Browser, an addition to its SmarTest Program Generator, enables a single-step test program generation flow that accepts core or SOC-level CTL code and outputs directly downloadable Agilent 93000 SOC Series binary files (Figure 3).

CTL has given the SmarTest Program Generator the capability to parse designs from a test perspective. For example, test engineers now have the ability to understand which cores might be tested concurrently and which must not be, which cores might be tested with BIST or optionally with functional vectors, which cores share a specific scan chain, or which top-level I/O pins connect to which internal core I/O pins. This support for CTL offers test engineers the ability to optimize test programs based on information that existed but was previously unknown to them.

CTL-Based IP Cores

In March, ARM became the industry's first CTL-based IP core provider, announcing CTL support for its ARM1136JF-S core as well as its entire suite of future IP cores. Synthesis scripts delivered by ARM as part of the ARM-Synopsys Reference Methodology for synthesizable cores will generate CTL models if the core-wrapping option is selected. (3) For cores that have been hardened with P1500 wrappers, ARM will provide CTL descriptions for use by core integrators.

CTL descriptions of its cores will make automatic integration and test development faster and easier for ARM customers. Additionally, CTL will enable engineers to optimize silicon debug based on the full capability offered by DFT features embedded in ARM cores, such as IEEE P1500-compliant wrappers. This contribution, ARM believes, will be highly valuable to customers focused on time-to-market and cost-of-test critical applications.

CTL-Based SOCs

A newly emerging challenge in SOC development integrates design processes, fabrication technology, and test processes seamlessly integrated to ensure acceptable yield learning curves, low manufacturing costs, and ultimately, reliable products (Figure 4). ST Microelectronics believes DFT flows and tools leveraging CTL are the key instruments needed to respond to the increasingly critical need for integration.

CTL provides the communications link between the tester and the EDA-enabled DFT features of the SOC. This link enables considerable flexibility in the value delivery chain allowing, for example, dynamic distributed test scenarios based on product mix and device content. CTL also helps test engineers easily leverage new ATE software solutions to target embedded DFT structures for faster silicon debug and yield improvement.

In the future, ST Microelectronics expects a fully integrated, industry standard-based SOC development process. Virtually no engineering time will be spent on nonvalue-added activities.

The Future of CTL

Whether and how fast the industry will adopt CTL and STIL in general remain unknown. The implications are interesting to explore. Slow adopters might be left behind as their competition benefits from faster SOC development cycles and production ramps. Conversely, early adopters might modify their tool infrastructure only to discover significant constraints in industry support or limited availability of engineering expertise required to use the new tools.

Adoption of CTL is likely to impact the SOC development process in many ways as more and new forms of DFT are implemented:

* New test methodologies might arise.

* Old test methodologies, formerly believed to be required, might become obsolete.

* Increased test-engineering flexibility could result in new and more powerful test optimization capability.

* Improved silicon debug technology might be developed, further enabling rapid time to market and yield improvement.

* The separation between design and test might blur to the point that a single function owns the entire SOC development process.

Like ARM, IP vendors are likely to provide CTL descriptions of their cores. Then, foundries providing IP libraries will be required to provide these descriptions. Those who supply this data may well take market share early into the adoption cycle. Once it is visible, IP providers may begin to differentiate more heavily on DFT flexibility.

Customers might begin to demand core-level diagnostic information from their test facility. Using this information, they might quickly determine which IP providers deliver the highest quality cores or which cores function best through which foundry. These factors and others could cause secondary shifts in market share for IP providers, foundries, and test houses.

Ultimately, it is likely that the SOC business model will be impacted by industry adoption of CTL and other industry standards. Faster SOC development cycle times, faster time to market, lower cost of test, and increased competition between IP providers, test houses, EDA vendors, ATE vendors, and others undoubtedly will change the dynamics of the industry.

[FIGURE 4 OMITTED]

FOR MORE INFORMATION on CTL enter these rsleads URLs

www.rsleads.com/310ee-189

www.rsleads.com/310ee-190

References

1. Kapur, R., CTL For Test Information of Digital ICs, Kluwer Academic Publishers, ISBN#1-4020-7293-7.

2. Kapur, R. and Williams, T. W., Tester Retargetable Patterns, ITC 2001, pp. 721-727.

3. Biggs, J., ARM Ltd., and Gibbons, A., Synopsys, Reference Methodology for Enabling Core-Based Design, European Synopsys User Group, March 2002.

by Kathleen R. Miller and Wayne J. Lonowski, Agilent Technologies; Rohit Kapur, Ph.D., Synopsys; Peter Harrod, Ph.D., ARM; and Davide Appello, ST Microelectronics

About the Authors

Kathleen R. Miller is the DFT marketing manager at Agilent Technologies. She received a B.S.E.E. from the University of Iowa and an M.B.A. from Portland State University. Ms. Miller has 15 years of experience in SOC design and test, IP program management, and DFT. e-mail: kathleen_r_miller@agilent.com

Wayne J. Lonowski is the EDA/DFT marketing and alliance manager for Agilent. Previously, he held marketing, technical, and product-line management positions at National Semiconductor and Hewlett-Packard. Mr. Lonowski earned a B.S.E.E. from Iowa State University and an M.B.A. from Colorado State University. e-mail: wayne_lonowski@agilent.com

Rohit Kapur is a principal engineer at Synopsys with research interests in VLSI test. Dr. Kapur has a B.Sc. in engineering from Biria Institute of Technology, Mesra, India, and an M.S. and a Ph.D. in computer engineering from the University of Texas. He is chair of the Core Test Language IEEE P1450.6 Standard Committee and was named IEEE Fellow in 2003 for his contributions to the field of IC test technology. Synopsys, 700 E. Middlefield Rd., MS24.105H, Mountain View, CA 94043-4033

Peter Harrod is a CPU design and test manager at ARM Ltd. where he has worked since 1990 and been involved in many processor and SOC developments, particularly in the area of test. He has a B.Sc. (Eng) from the University of the Witwatersrand and an M.Sc. and a Ph.D. from UMIST. Dr. Harrod is a Chartered Engineer, Fellow of the IEEE, and senior member of the IEEE. ARM, 110 Fulbourn Rd., Cambridge, CB1 9NJ, U.K., email: peter.harrod@arm.com

Davide Appello is the test solutions manager--Telecom, Peripherals, and Automotive Operations at ST Microelectronics. He received an engineering laurea in electronics from Pavia University and has worked for 10 years testing and advancing DFT on mixed-signal SOCs. Mr. Appello is a member of IEEE and TTTC. ST Microelectronics, via Tolomeo 1, 20010 Cornaredo, Italy, email: davide.appello@st.com
COPYRIGHT 2003 NP Communications, LLC
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2003 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:Design for Test
Author:Miller, Kathleen R.; Lonowski, Wayne J.; Kapur, Rohit; Harrod, Peter; Appello, Davide
Publication:EE-Evaluation Engineering
Geographic Code:1USA
Date:Oct 1, 2003
Words:2419
Previous Article:New portable data recorders use removable PC FLASH cards.
Next Article:Family values.
Topics:

Terms of use | Privacy policy | Copyright © 2018 Farlex, Inc. | Feedback | For webmasters