The ASIC product range addresses medium- and high-volume applications where optimum performance is required at the lowest unit cost. The ASSPs are geared toward the consumer multimedia and communications markets.

Fundamentally, both product lines are advanced SOC solutions incorporating sophisticated intellectual property (IP). Some of the primary IP blocks available are nonvolatile memory such as flash and EEPROM, embedded RAM, processor cores such as ARM and AVR, analog IP blocks such as PLLs and audio and video converters, and I/O cell blocks with programmable pull-ups/pull-downs and bus holders.

Our business model necessitates the design and manufacture of very complex devices at very competitive prices. This combination drives a requirement to aggressively cap the overall cost of test including test program development.

Atmel created an automated test program development flow to accomplish these seemingly contradictory objectives. Our automatic test program generation (ATPG) system traces its lineage back to the acquisition of the European Silicon Structure more than 10 years ago. Our early efforts in ATPG produced test programs for the Credence Quartet and ITS 9000 tester family and the Nextest Maverick and were relatively successful.

Unfortunately, as the complexity of our devices continued to track Moore’s law, we needed to integrate newer, more powerful platforms into our ATPG system. Extending our automated flow to suit the Sapphire platform met this challenge and resulted in enhanced capabilities.

A generic design interface tools (DIT) suite was developed within our design-flow group. The actions of these tools are moderated by a set of files created by test engineering that defines the specific tester constraints and design-to-test rules. Together, these files specify the authorized timing formats, initial pin states, strobe placements, and test rate limitations.

Another input to the flow is provided by the designer through a Block Access Descriptor file which describes the available ASIC library blocks such as processors or memory. Using this description, the TPG for the target ATE can generate special program modules and patterns for some of the large IP blocks available. These include an ARM core with full test insertion or nonvolatile memory patterns and flow using a standard serial test interface port that is part of the design library.

Based on the inputs given, the DIT produces a set of files for downstream use by the target TPG:
• A collection of test vector files, together with timing information using an internal data representation.
• A bounding description file which defines the I/O cells being used and their electrical parameters extracted from SPICE simulations performed by the design group.
• The block access description file created by the designer.

In cases where special cores are instantiated in the design, such as an ARM core, additional predefined vectors are linked into the VECT files for processing.

DFT insertion and driving the creation of test vectors through ATPG are the design group’s responsibilities. Very high fault coverage goals have been set for DFT.

The bounding description and block access description files are used as inputs to the Bounds manager. Information about the device package type and die pads is extracted from a database written in Oracle and used for load-board and probe-card build instructions. The Bounds manager outputs the test sequences needed by the I/O cell technology together with the test limits to be applied taking into account factors such as temperature and V_DD level.

The Test Database file together with the VECT + TIMSET files then are sent to the target TPG to generate the actual test-program source code.

Typically, the test program would comprise the following:
• Load Board Tests Executed Once After Program Installation
• Opens and Shorts Tests
• Gross I_dd Tests
• Device Trimming Procedures
• Memory Tests
• Functional and Structural Tests
• Analog Tests
• I_dd Standby Tests
• V_ol and V_oh Tests
• Leakage Tests

These automatically generated analog tests are primarily simple static tests for most of the simple analog cell structures such as op-amps, band-gap references, and simple DAC/ADC and used primarily in prototype debug because they would be too slow for production use. For leading-edge custom mixed-signal cells, the test code needs to be added by a test engineer. Given the current technology available, fully automated tests for advanced mixed-signal cores still is a subject of intense research in academia.

Many of the test routines are written generically and stored in external libraries accessible to the test programs. They perform various functions normally associated with all test programs such as the test session program (TSP) interface which includes prober/handler data and lot information.

Different versions of the test programs are generated by our tools during the device life cycle from the same set of inputs:
• First silicon test program, usually carrying many scan and functional test vectors, created by ATPG and the designers for silicon debug purposes.
• Production test programs optimized for wafer sort package test.
• Device characterization test program, suitable for use in yield enhancement programs and failure analysis lab work. This version is the most sophisticated kind of test program. It is geared for use by a product engineer and includes features for bit mapping and special routines for interacting with some of the test parameters.

To speed up first-silicon prototype turnaround time, we have created a special per package loadboard with jumper fields that allow the operator to patch in the needed tester resources such as power supplies to the appropriate DUT pins. This can save weeks in the fabrication of a custom loadboard. The TPG produces loadboard patch instructions for the operator, correct pin definition statements, and loadboard diagnostic tests to ensure correctness.

Most of the products have multiple package delivery mechanisms plus wafer sort. This leads to multiple test programs and test vector files to accommodate the different tester pinouts. To reduce this logistics complexity, we try to leverage as much capability as is available from the tester in terms of pin scrambling and pin definition switching.

Race Time Checker
Race time checker allows timing edges to be easily shifted in time during tests (Figure 2). With this tool, we can catch all remaining simulation timing race conditions that may be present at prototype test. The tool also expedites the transfer of test programs between platforms such as from the characterization to a production system that may have additional timing restrictions.

Figure 2. Timing Race Checker

Fail Vector Listing
All test programs can generate a listing of failing vectors per pattern in a format suitable for the designer. The designer can use this information to create additional ATPG vectors to more precisely localize the physical defect.　

First-Fail-Per-Pin Listing
The goal of this tool is to give the designer the maximum information about the failing functional pattern.

The test program is but a part of an integrated test software environment. For example, the test program is linked with a lot tracking system through our embedded TSP interface. This interface also has the capability to generate tagged test measurements per die/device directly to send to an engineering database for statistical data collection.

The Sapphire system has a totally different hardware and software architecture than our previous testers. We had to rethink how to integrate it into our automated flow, but the end result was a more powerful and easier to maintain flow than was previously possible.

Figure 3 illustrates some of the new tools developed for Sapphire. Included are the following:

Figure 3. Production Interface Tools

Object-Oriented Programming
XTOS incorporates an object-oriented programming language (Java) in which to write test templates. Templates come with the system, or new ones can be created and made available in a library. The Sapphire TPG makes extensive use of this capability.

XML Data Structures
The test program data values are kept separate from the test templates in XML blocks. XML is an industry-standard mark-up language derived from the older HTML used in websites. XML blocks are very easy to parse and create with computer tools. With XML, we can develop our own highly customized data structures such as for the TSP without totally changing the existing test programs or TPG.

The separation of test procedures from the data they require resulted in considerable simplification of the TSP code generation that was needed for Sapphire.

Scripting Capability
XTOS includes Python scripting capability. Python is another industry standard having more capabilities than the older PERL. Anything that an XTOS test program can do to control the tester hardware or terminal I/O can be controlled from a Python script. This allowed us to develop very comprehensive characterization test suites requiring a combination of test programs and scripts through minimum operator interaction—a big boost in total possible automation.

STIL
The native vector source language used by XTOS is standard test interface language (STIL), an IEEE standard. STIL is very similar in capability to our VECT + TIMSET format. Since the new ATPG tools available today can output STIL, we have converted our vectors and timing formats to use STIL and save on the maintenance of VECT + TIMSET for new testers.

NAME MAPs
In XTOS, the device pin-to-tester channel assignment is defined through a NAME MAP data structure. By itself, this is not unusual. The vectors are dynamically loaded to the tester memory based on the NAME MAP, and multiple NAME MAPs can be defined in the test program. In effect, the NAME MAP that is conditionally selected determines how the vectors will be loaded.

In the past, we had to generate and keep multiple versions of the patterns for the same device that could include a wafer sort pattern set and unique pattern sets per package type. With hundreds of active device types in manufacturing, keeping track of all these patterns was a logistics challenge. With XTOS, we only need to create one pattern set and let XTOS handle the DUT-to-tester channel mapping.

The concept of NAME MAP also is central to developing programs for multisite testing needed on many devices to lower the cost of test. For multisite test, the TPG creates a NAME MAP that replicates the DUT-to-tester channel connections as many times as there are test sites. During testing, extensive amounts of data are collected for off-line analysis using the industry-standard STDF format. Figure 4 is an example of some of the types of analysis we can perform.

Figure 4. Analysis Plots From Wafer Test Results

Extending our flow to the Credence Sapphire system resulted in an even more powerful implementation of our automated flow than was previously possible. This was a direct result of the architecture and the capabilities brought by XTOS software. For this reason, the Sapphire platform has become our system of choice for silicon prototype debug and characterization.