Extending The ATE-1.0

Douglas E Shelton

NOVEMBER 2014 – Revised JANUARY 2015

Copyright © 2014 & 2015 Unified Test & Development, Inc. All rights reserved.

EXTENDING THE APPLICATION AND FUNCTIONALITY OF

DISSIMILAR AUTOMATED TEST EQUIPMENT

1 EXTENDING THE APPLICATION AND FUNCTIONALITY OF AUTOMATED TEST EQUIPMENT

INTRODUCTION

Test floor diversity is a natural condition resulting from the rapid changes thatoccur in a technology company’s product offerings. It is defined as the dissimilaritiesbetween a collection of Automated Test Equipment (ATE) makes and models presenton a semiconductor test floor. What makes this notable is that the various models inservice are isolated from each other by their vast differences in function and in theway they are programmed to test product. There are many business reasons foradding ATE units to a test floor among which capacity, system support and testfeatures are most often cited. But the underlying reason is generally obsolescence; aconstant for any high technology business. This factor most often creates the needto update ATE systems on a test floor in order to maintain competitive viability.

From a practical standpoint it is in the interest of a semiconductor manufacturerto limit the expansion of ATE diversity on a test floor in order to contain test costoverhead. It is not reasonable however to conclude that older ATE systems cansimply be replaced by newer platforms. System uniqueness forces these oldertesters to remain in service until all of the product lines dedicated to them are nolonger supported; not just when production has stopped. This can be a big problemfor the test floor manager who has little free space to allocate new ATE systems.

It is this reality that drives an entire market for the converting of a test programfrom one ATE to another. This strategy is commonly employed to help reduce testfloor diversity by moving test programs off of unsupported ATE systems and ontoother more supported systems. Moving a test program in this way is generally not aquick or easy process because many contain a small number of tests that: providetest coverage for defect types specific to that design; use the ATE in ways toovercome specific tester limitations; or have no hardware parallel between thesource and target ATE. Unless the test engineer performing the conversion isexperienced with both ATE systems involved, conversion time can get quite lengthy.

Embedded Built In Self Test (BIST) is another strategy employed to mitigate thediversity of ATE systems by enabling a device to test itself. While this is ostensibly asound solution to the ATE test problem, it suffers from a phenomenon known as acoverage plateau. These internal test engines eventually succumb to newunderstanding about a technology as it matures; mostly from the large number ofprocess steps used in its construction. It happens late in development and usuallyresults in the need for some form of invasive testing to help support test coverage.

With this bit of context, let’s briefly explore the issues created by test floordiversity to better understand the need to mitigate it. While two of the morecommon methods of dealing with this issue have already been identified, a morecomprehensive solution has emerged that borrows from these and other strategiesto allow ATE systems of all vintages to function as web applications do: withindependence from the operating systems that host them.


1. THE PROBLEM SPACE

Competent test engineering is a demanding discipline. It requires a thoroughunderstanding of the device being tested, the capabilities of the applied test system,and a strong grounding in software engineering to provide the test engineer withthe tools needed to overcome limitations of a test environment as a whole. Testprograms contain a necessary complexity that is intended to manage the testenvironment for which it was written and insure that only quality product is shipped.Most often a test engineer is dedicated to a single test platform to improve the cycletime for test program development and release. This level of specialization howeverimpedes efforts to transition products between ATE systems.

A significant amount of time is invested in the development of a test programand the importance of its integrity to the semiconductor manufacturer or test housecannot be overstated. The following topics outline the most common challengestest floor diversity imposes in the test engineering and manufacturing space withimpact implications to the overall cost of test. Considerations from new technologydevelopment and sustaining engineering efforts to the business’s need to manageproduct flow are examined. Some of these issues are dealt with at the time ofproduct release. Others occur during the product’s production cycle. The goal ofthis section is to create the scope for a core list of requirements to which a solutionshould conform, and consequently be formulated.

1.1. DEVELOPMENT TEST INTEGRATION

Before the release of a manufacturing test program occurs, there is a great dealof development that happens behind the scenes; both of the product and theprogram used to test it. It is a relationship that naturally happens on the path toproduct maturity. The development test activity helps tune the manufacturingprocess ahead of its release to production by providing systemic details about thetechnology’s performance and yield. It is assumed that most, if not all of thesefindings can later be related back to test structure parameters or be solved outright.The overall goal is that at some point in the development cycle, parametric test willbe able to monitor the process for aberrations that will eliminate the need for anexhaustive product test program.

Development test programs aims differ from manufacturing test programs in oneimportant aspect: It is the failing devices that are most important for the informationthey posses and their impact on yield. These programs are designed to amplifymarginal faults in order to insure sufficient operating bandwidth in the final product,yield notwithstanding, and then pin these observations to some parametric value forprocess monitoring. For the production test program, it is all about yield and testtime; easy metrics to use in monitoring manufacturing cost and efficiency. It isintended to be a minimal program flow with the assumption that the design andprocess issues will have been resolved during development and thus reduce thedefect space down to a well understood and manageable few.


Frequently as it is with new technologies, this clean transition from developmentto production does not occur as desired. Often the development and manufacturingtest program development is carried out by two different organizations, on twodifferent ATE models, and under two different mandates. Some tests from thedevelopment cycle must be integrated into the production test program to insurequality shipments. This task is difficult enough when the development ATE is exactlythe same as the production test platform where what is required is test and test flowoptimization. In many cases however, this is either not practical, or even possible dueto the types of automated test equipment required for product development versuswhat is used for manufacturing. The dissimilarities between these ATEs can besubstantial which magnifies the difficulty of test integration. The net result is loss oflearning from incorrect test method translation or omissions which increases theprobability of test coverage errors. Unless it is the same test engineer who isresponsible for the authoring of both test solutions, this outcome is nearlyunavoidable.

1.2. OPERATING SYSTEM DEPRECATION

When a software vendor no longer supports a version of an operating system theATE was released under, it can create serious issues from a support perspective. Thishappens most often when a consumer grade operating system installed on anindustrial ATE system is deprecated in favor of a newer version. The use of consumergrade operating systems is appealing because of its wide use and large array ofsupported software, yet they are vulnerable to periodic deprecation. Some changesmade to the upgraded operating system are not compatible with the ATE vendor’sinstalled application layer; the software responsible for controlling the ATE.Consequently the ATE’s operating system cannot be upgraded.

As a company transitions to the newer version of these operating systems to keepits IT infrastructure current, ATE platforms built on the earlier versions get leftbehind because they are not actively supported – by anyone. In some rare andextreme cases, these ATE systems may be rendered inoperable from their inability tointegrate into a more secure or advanced network construct; a disaster if these ATEsystems are used for production test. The ATE manufacturer is left with a collectionof bad options from which a choice will have to be made to support their business.ATE systems that fall into this category remain functional and capable of performingproduct testing beyond end of support. No test floor should not be hobbled by thedeprecation of an ATE’s operating system or the loss of support from the OEM. Itshould possess a software core that is unaffected by operating system changes andallows it to remain a viable option over an extended period of time; an assumptionthat may have been made at the time of its selection.


1.3. TEST SYSTEM MISALIGNMENT

According to Moore’s Law, it takes about two years for the number of transistorsin a high density integrated circuit to double. Most state-of-the-art test equipment,as well as semiconductor product releases take about two years from design torelease. It can be reasoned that new ATE releases will be on time for the technologyit is intended to service, but lag the newest technology under development. Bothsemiconductors and operating system software technology can make big leaps inthat amount of time resulting in the potential for gaps in tester capability. ATEvendors must focus their limited resources more on volume production concernsover more specialized development test paradigms because manufacturing test isresponsible for the bulk of their sales. The result is that on occasion the target ATEsolution for a product may not have the bandwidth or feature set to perform a testor test group in a straight forward manner and becomes marginally misaligned.

A second, more direct misalignment happens when ATE systems are used by onemanufacturing test floor, but need to be moved to a different production floor usingprevious or perhaps newer generation test systems. Sometimes a test capability ismissing from the target test system. To handle this situation, test engineers create asoft work-around to emulate the needed test function from the target ATE’savailable resources. Some of these emulated solutions must be crafted in animaginative and circuitous way while others are quite clever and result in significantcost savings to the semiconductor manufacturer. Most all of this learning gets lostover time when it should be integrated into the ATE’s operating system in somemeaningful way. The action of moving a test program from one generation of ATE toanother can be considered a form of rework.

Rework is a headache for any production line. It is costly and highly visible as itpertains to product shipments. Test program rework is largely an unknown becausetest engineers across different disciplines constantly create the same solutionsrepeatedly not knowing that a solution already exists in some other group. Lessonslearned from the collective test engineering body should have some way of beingadopted without continuously redeveloping them. If a test system can ‘capture’these unique solutions that expand the functionality of an ATE, it can then betteralign dissimilar tester models and lower the amount of test rework that may berequired by future product releases.

1.4. SUSTAINING PRODUCT MANUFACTURING

Product shipments do not conveniently end when an older technology base issupplanted by a newer technology. A product life cycle can be as short as 3 to 4years as in the case with mobile computing technologies, or can extend a decade ormore as with industrial or high reliability technologies. Some technologies areanalog dominant, others are purely digital. There are countless overlaps betweenold and new, long and short, analog and digital that invariably lead to a highly diversetest floor. As previously stated, solid business reasons drive most ATE purchases.


Tester utilization will rarely align with throughput efficiency since some ATEsystems will be idle when they could otherwise be testing product. It is this unevendistribution of product loadings, driven in large part by sustaining product salesmixed in-proportionately with new products that create opportunities for thisinefficiency. When combined with hardware down time and rework, bottlenecks andidle testers become an omnipresent fact of production test life. It would beadvantageous to distribute product loadings based on tester availability withouthaving to consider the need to convert a test program from one ATE system toanother with all of the quality considerations that may ensue.

1.5. IN SUMMARY

Four specific cases have been identified that demonstrate how test floor diversityinterferes with production test efficacy: Continuity between development andproduction test; Immunity to operating system changes; Retention of developedvirtual methods; Distribution of test floor resources. While some diversity of ATE isrequired for a healthy semiconductor test environment, it is in a semiconductormanufacturer’s best interest to find ways in which to remove the obstacles toproduction throughput goals from a test floor that is too diverse. Many creativesolutions have been developed to mitigate specific areas of this issue but they havenot yet comprehend it in its entirety. As the semiconductor market matures and thebandwidth of ATE systems stabilizes, there may be a motivation among the ATEvendors to establish a common application layer somewhere in the future. Eventhen, the issues created by the scores of previous generation ATE systems, alongwith their re-spins from aftermarket vendors will still need to be addressed.

2. CONSOLIDATING TEST FLOOR RESOURCES

The two most common motivations for consolidating test floor resources are:Provide test capability commensurate with new product deliveries; and thereplacement of older ATE systems that have a large idle-time versus loadings ratio. Ameans for bringing a test floor into balance can be achieved if a mechanism thatallows a test program written for one make of ATE can be executed on a differentmake or version test system. This mode of ATE operation and its supportingsoftware is defined as the “Guest Test Program Execution Model”. It comprises a coreset of software interfaces that exposes real and virtual instrumentation hardwareinternal to the ATE system out to the device contact environment, and a TesterAbstraction Layer, or TAL framework that resolves test program execution throughthe OEM’s native tester API where it is possible to do so. The framework must notinterfere with or otherwise alter the normal mode of ATE operation. This insuresthat modal or operational software changes made and tested by the manufacturerare directly available to the framework without the need to perform exhaustiveregression testing.

6 EXTENDING THE APPLICATION AND

Figure 1.

Figure 1 above illustrates three ATE systems with varying hardware and testinstrumentation capabilities.between ATE systems from this point of view is that if a test program written for anyof these examples stray beyond the Direct Compatibility Union, the task ofconverting that test program to any of the other systems becomes problematic ormaybe even prohibitive; and this is before programming language differences areconsidered. In order for our Guest Test Program Execution Model (GTPEM) tofunction properly, two components must beand an ATE driver/compiler module built on the Trellis API Framework for the targetATE system.

2.1. WHAT IS TRELLIS?

Trellis is an active Application Programming Interfacewhich all of the other elements required to execute a test program across platformsis built. This framework contains both the TAL and all of the software interfaces formanipulating ATE hardware instrumentation. The framework is written underMicrosoft’s COM+ (Component Objextensible to all operating systems, not just Microsoft Windows and its variants.Moreover, Trellis provides full window and file management services making it acomplete application development library.provides bandwidth wide enough to drive any production ATE system.

PPLICATION AND FUNCTIONALITY OF AUTOMATED TEST

Figure 1. Venn Diagram of ATE Dissimilarity

Figure 1 above illustrates three ATE systems with varying hardware and testation capabilities. The problems with simple test program conversion

between ATE systems from this point of view is that if a test program written for anyof these examples stray beyond the Direct Compatibility Union, the task of

program to any of the other systems becomes problematic ormaybe even prohibitive; and this is before programming language differences areconsidered. In order for our Guest Test Program Execution Model (GTPEM) tofunction properly, two components must be in installed: The Trellis© API Frameworkand an ATE driver/compiler module built on the Trellis API Framework for the target

Application Programming Interface framework component onr elements required to execute a test program across platforms

This framework contains both the TAL and all of the software interfaces formanipulating ATE hardware instrumentation. The framework is written underMicrosoft’s COM+ (Component Object Model) sockets based specification making itextensible to all operating systems, not just Microsoft Windows and its variants.Moreover, Trellis provides full window and file management services making it acomplete application development library. It is a singular interface model thatprovides bandwidth wide enough to drive any production ATE system.

EST EQUIPMENT

Figure 1 above illustrates three ATE systems with varying hardware and testThe problems with simple test program conversion

between ATE systems from this point of view is that if a test program written for anyof these examples stray beyond the Direct Compatibility Union, the task of

program to any of the other systems becomes problematic ormaybe even prohibitive; and this is before programming language differences areconsidered. In order for our Guest Test Program Execution Model (GTPEM) to

in installed: The Trellis© API Frameworkand an ATE driver/compiler module built on the Trellis API Framework for the target

component onr elements required to execute a test program across platforms

This framework contains both the TAL and all of the software interfaces formanipulating ATE hardware instrumentation. The framework is written under

ect Model) sockets based specification making itextensible to all operating systems, not just Microsoft Windows and its variants.Moreover, Trellis provides full window and file management services making it a

It is a singular interface model that


Trellis is both operating system independent and ATE API independent. It isconstructed using very low-level ANSI C libraries and core window management APIsthat are cemented in place by their almost universal use. It is written in this mannerto insure robust, supportable code that does not age. Trellis test applications arenothing more than generic C++ code with Trellis APIs that may be compiled on anycomputer host with Trellis installed. The framework is lower level than most as toimprove execution performance while getting the developer closer to the hardware.It is an approach that runs counter to the strategy of many modern ATEprogramming paradigms. Writing code in this environment allows a test engineerthe freedom of developing test methods, event handlers and controls with fewrestrictions on style and less dependence on OEM applications support.

Trellis has one other, perhaps more consequential feature not present in anyother test programming language. It is a dedicated set of API interfaces for the solepurpose of driving external hardware that can be built onto the device contactboard. The hardware is FPGA (Field Programmable Gate Array) systems that canexpand the capability or capacity of an ATE system far beyond its use specification.This function, mixed with the polymorphic properties inherit in the interfaceconstructs, can extend the product service bandwidth of any ATE system no matterhow primitive it is. The architectural approach is novel and the IP surrounding it iscurrently under patent consideration.

2.2. AUTOMATED TEST EQUIPMENT AS AN APPLIANCE

To fully understand how Trellis can achieve ATE application uniformity, it isimportant to think of the ATE hardware as an appliance separate from its hostcomputing environment. These machines come with an assortment of tools andsoftware designed to assist with the development of a test program or theinterrogation of a device. For the purpose of converting the tester to a functionalappliance however, the only focus required is on ATE’s complement of hardware andthe programming language used to create small stock test programs.

We will begin the discussion by making this general statement:

In order to understand how different ATEs may be consolidated on a test floor, theATE itself must be redefined as an appliance where an appliance is defined as: Amechanical device designed to perform a singular task.

Appliances are like peripheral devices. What makes an appliance different from aperipheral is that it is a self contained unit that can function autonomously such as arefrigerator or toaster oven. A peripheral device exists strictly to put informationinto or get information out of a computer. For our ATE appliance, the device undertest is its primary peripheral. This may be a bit of an oversimplification when lookingat an ATE from this point of view, but it is an important distinction to make forunderstanding its place on the Trellis backplane since the ATE is considered both realand virtual in the overall test environment at the same time.


Creating an appliance is done by coding a wrapper interface that is a test programin the form of a dynamically linked library (DLL). This DLL serves as a test systemdriver application that is invoked by the User Interface on the Trellis backplane. Itbegins executing as a normal test program except it runs as a background process.This program library creates a shell application where the program initializes the ATE,begins execution of the first test and then stops and waits for us to tell it what to donext through a mechanism called a message processor. A Message processor is astatic function created by the user and registered in the system to process smallintegral messages between the application and operating system. The otherelements needed for our appliance are a web interface, frame buffer for bitmappingand graphical exchanges and an event handler for logging events and exceptions.

It is this chunk of code that truly performs the magic needed to make crossplatform program execution possible and consequently is the most difficult toconstruct. It must be customized for each specific ATE model, the details of whichexceed the scope of this document. The ATE appliance can be thought of as aremote server that requires a Trellis interface module to communicate with theclient host. This infers that the client host may be at the ATE site, or somewhereelse. This understanding has great implications on how the appliance(s) can be madeto behave in a larger context, like a test floor. In short, each appliance communicateswith its client, receiving direction and reporting results without being driven directly.This approach leverages each tool in the most efficient manner possible.

2.3. THE FRONT-END TRANSLATOR

It might be construed from the discussion so far that a test engineer would haveto write C++ code using the Trellis framework directly to be able to make use of it.While this is an appropriate application of the library, it is not the intended usemodel. Native OEM test programs serve as the source code to be translated intoTrellis object code through a front-end translation component of an ATE driverapplication. It is constructed this way because only the ATE knows what it can andcannot do within the Trellis universe. The resulting Trellis object code is a text filecontaining an exact representation as it is written of the entire test program to beapplied to the ATE and periphery provided all of the specified capability is available.

This would seem straight forward except for the persistent issue ofincompatibilities. There are two ways to deal with this issue. The first is for the ATEdriver application to provide virtualizations of a specified function. For example, thetarget ATE has only vector memory for logic operations but the guest program usesalgorithmic patterns. The driver would need to provide a vector-based solution forthe algorithmic input. This would be considered a virtual Algorithmic PatternGenerator since both solutions arrive at the exact same signal application. This typeof solution must be programmed into the driver and requires no externalcomponents for operation.


The second method for dealing with incompatibility is to provide programmablehardware at the DUT (Device Under Test) load board or interface assembly accessibleto Trellis. For example, frequency data is requested from an analog device beingtested on a digital ATE. The load board has a read/write FFT component installed.This is considered an external test instrument since the ATE function is completelyforeign to the test system and the ATE driver defers to the Trellis object throughpolymorphism to accomplish the analog test objective. While this would seem anovertly flawed approach to resolving incompatibilities due to potential calibrationissues, it actually turns out to be a stable and surprisingly effective applicationsolution with far reaching benefits including timing multiplication, site encapsulationand error feedback capabilities.

Most test programs consist of multiple files with dependencies, global definitionsand conditional compilation. It is not as simple as inputting a single file and getting asingle file output. In order for the translator and ATE driver application to functionproperly, a user interface component must exist to organize and facilitate theapplication of all necessary functions required for a successful program translation.For this end, a user interface application called ImmIX© is being created toaccommodate this critical function including hardware identification, organizingguest test programs into projects, managing ATE limitations and defining thenumber of sites allowed for test execution. This topic will be discussed in a separatewhite paper to fairly cover the ImmIX application due to its scope.

3. SUMMARY

Over the next several years, other sea changes in firmware and softwareimplementations on ATE systems will occur due to the proliferation of mobilecomputing plus the move to single-year subscription licensing for their products.This is not a remarkable phenomenon. Versions of this have played out many timesin the past as ATE vendors jockey to differentiate their ATE systems from oneanother. What is different however is that the semiconductor market is maturingcreating new pressures to maintain profit margins while staying competitive.Semiconductors are perhaps one of the only products manufactured that require100% testing before they are shipped making test cost a prime place to improvemargins. This is true whether testing is done internally or by third party.

An unknown that has not been addressed is translation efficacy, or the loss ofefficiency resulting in an increase in test time from this process. This concern is nottrivial and requires some investigative work. This issue notwithstanding, Trellis canoffer a measurable improvement in test floor utilization by allowing test programs tobe executed across test platforms without the need to perform test programconversion. As more ATE systems are included within the scope of the Trellisframework, it is believed that with the latitude to make capacity utilization decisionsbased on the ATE availability will outweigh any test time performance losses thatmay result.


REFERENCES

Bob Smith, John Hardin, Graham Phillips, and Bill Pierce, Linux Appliance Design, NoStarch Press, ISBN-10: 1-59327-140-9; 2007

Richard Grimes, Julian Templeman, Alex Stockton, Karli Watson, and George Keilly,Beginning ATL 3 COM Programming, Wrox Press LTD, ISBN 1-861001-20-7; 2001

Gordon E. Moore, Cramming More Components onto Integrated Circuits,Proceedings of the IEEE, Vol 86, No. 1, Jan 1998

Extending The ATE-1.0

Documents

Transcript of Extending The ATE-1.0