Graduate Assistant Research
Software and hardware development of a low cost semiconductor test system.
Spring 2003
Reference: Dr. Jay Porter
The Low Cost Tester (LCT) is part of an ongoing project within Electronics Engineering Technology called the Parallel Tester. The idea is that while the cost of producing chips has decreased with time, the cost to test these chips has remained the same, or even increased as the complexity of the chips continue to grow. Therefore, the cost of testing each device after manufacture has become an even larger percentage of the total cost of the chip. The Parallel Tester is a multipart project designed to help semiconductor manufacturers test chips faster and cheaper. The largest cost associated with semiconductor test is the amount of time it takes to test the device. Companies must purchase large test machines that cost millions of dollars and run each device they produce through these machines to verifies correct operation. The majority of this time, the chips either waiting to be tested, or waiting for the rest of the batch to be tested. The idea of parallel testing is to create a low cost tester that is capable of doing many of the same tests, perhaps to a lessor extent or lower resolution, and pretest the chips waiting to be tested. If a chip fails the pre-tester (Low Cost Tester), do not waste the expensive tester's time testing it, simply place it in the bin of failed devices.
Development of the LCT has taken two directions. There is already a company out there called Third Millennium Test Solutions that sells relatively low cost testers. We have acquired one of these testers, but without technical support, little development was made with this tester. The other route was to create our own tester from the ground up using National Instruments PXI devices. Good progress has been made in this area, and development continues. My contribution pertaining to the development of the LCT was primarily in three ways:
1. National Instruments more or less convinced 3MTS that it would be good for them to give us a tester so we could develop stuff on/for it. Meanwhile, NI also liked the idea of having us do development work on the 3MTS tester (3M20) to allow test engineers to develop tests in LabVIEW, instead of purely using 3MTS's proprietary software. So in a sense, receiving this tester helps all three parties. My first job was to learn how to make the tester hardware accessible from LabVIEW. 3MTS already provides significant software hooks to incorporate their hardware control into your own OOP software through DLLs. However, LabVIEW does not fully support object oriented programming, and making calls to class methods inside of the DLL became nearly impossible because of the name mangling associated with DLL exported functions. Anywho, my solution to this was to write my own wrapper DLL to instantiate and operate the 3MTS software, and providing simple C function stubs to the LabVIEW environment. I then created a tool palette in LabVIEW to allow a G programmer easy access to the functionality provided by the 3MTS software interface. I completed this connectivity, but without documentation or technical support from 3MTS, I was not able to actually begin developing tests for our sample chip, the AIC10. For example, I was able to generate and read voltages with the software interface I implemented, but had no clue where on the hardware the signal was coming out.
2. So, to continue development, we decided to put aside the 3M20 and simply use a PXI system to develop our low cost tester. However, before developing the tests for the AIC10, it was important to learn how to synchronize all the devices in the tester so we can ensure acquired signal continuity so we can do the necessary digital signal processing for speedy test results. This required considerable investigation to discern what devices would be needed to adequately test the AIC10, and to learn how to synchronize all of the device using LabVIEW. In short, I successfully simultaneously synchronized a PXI-6534 digital I/O card, PXI-6608 timing card, PXI-5411 arbitrary waveform generator, PXI-6052E multifunction I/O, all to a PXI-4472 digital signal analyzer, a very untraditional thing to do.
3. My last contribution to this project was the development of a simple device interface board to allow us to connect the AIC10 to the PXI hardware. This DIB does not include all hardware necessary to perform the tests, but was simply an intermediate learning/development board.
This is only one part of a much larger project, and development continues on multiple fronts. It is my hope that someday my work will be adopted by a large corporation such as Texas Instruments.