Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > T&M

Open architecture ATE tackles test woes

Posted: 02 Feb 2004 ?? ?Print Version ?Bookmark and Share

Keywords:ate? soc test? memory test? logic test? mixed-signal test?

SoC testing presents unparalleled challenges that require a fundamental change in thinking for both IC manufacturers and tester makers. The operating speed of digital logic in gigahertz and associated physics of transmission line and signal reflections alone are enough to require new testing methods and equipment. The use of new materials (copper, low-k intermetal dielectric and high-k gate dielectric) compounds that problem because of new defect mechanisms.

In SoCs, these difficulties further increase by n-fold because of integration of multiple types of blocks. That includes MCUs; SRAMs, DRAMs, content-addressable and flash memories; PLLs and DLLs; A/D, D/A and sigma-delta converters; voltage regulators and power amplifiers; bus functional controllers like PCI and USB controllers; high-speed interfaces like serial link and Serdes; RF generators and receivers; and high-speed and differential I/Os. Each of these blocks requires a unique test method and specialized test equipment as well as a test engineer who is familiar with the intricacies of the test method applicable to that specific block.

In the past, there was a clear-cut distinction in IC type and subsequently in test equipment. From test engineers to Wall Street analysts, the categorization of all test equipment was: (1) logic testers; (2) memory testers; (3) mixed-signal testers. But SoC testing requires the functionality of all these testers, plus more. At a minimum, all this functionality increases the cost of the tester until it becomes the primary cost factor in SoC test cost. Traditional logic or mixed-signal testers are just too deficient for SoC testing; extensive time overhead, logistics in material handling and a direct hit on factory throughput does not allow multiple insertions using multiple testers for an SoC.

IC makers purchase a tester with a 10 to 15-year lifetime in mind and expect to test a wide variety of ICs with it, so both hardware and software components of the tester are required to work over a wide range of operations. SoC testing also puts extensive functionality demands on the tester. Thus, SoC testers contain myriad resources that are not used most of the time. These idle resources are pure overhead from an IC manufacturer's point of view. At the same time, a tester may not have the most desirable resources suitable for a given SoC.

Platform incompatibility

The primary reason for these difficulties in SoC testing is the specialized and fixed tester architecture. Today, each tester manufacturer has a number of platforms in which all hardware and software remain in a fixed configuration. This also leads to cross-platform incompatibility that restricts the development of third-party solutions. This fixed configuration also requires dedicated test programs using some of the tester capabilities to define test data, signals, waveforms, current, voltage levels and so on. Because the test program uses specific tester resources, the program is also fixed and cannot be reused or ported to a different tester without reengineering.

To a large extent, these difficulties can be addressed if the tester is modularized and reconfigurable depending on need. The basic idea behind the open architecture test system is to provide such modularization with specific focus on the use of third-party modules and test instruments. The Semiconductor Test Consortium has specified the hardware and software tester framework Openstar and standardized interfaces so that modules from different vendors can be used in a plug-and-play manner to achieve the best desired functionality for a given SoC.

Based on the modules comprising either single or multiple test sites, various system configurations can be developed, such as:

7 Homogeneous system - Each site is identical and is composed of identical modules;

7 System with compatible sites - Each site may contain different modules. However, if the module compositions/partitions within a site are the same as at other sites, the sites are compatible;

7 Heterogeneous system - When two or more sites are composed of different modules of different types and at least two sites differ in internal module compositions/partitions, then the system is heterogeneous.

- Rochit Rajsuman

Chief Scientist

R&D Center

Advantest America Corp.

Article Comments - Open architecture ATE tackles test w...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top