LCT – Low Cost Tester
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.
FiST – Fingerprinting Sobriety Tester
Graduate Assistant Research
Software development for PDA-based sobriety tester.
Summer 2002
Reference: Dr. Jay Porter
The concept of FiST is to create a set of tests on a handheld device
that can objectively and empirically determine the ability of an individual to
operate a vehicle. This is done through a combination of cognitive and motor
skill tests administered on an iPAQ. One of these test can be seen to the
below, the DAT test. The user must divide his/her attention between two tasks,
tapping any red stoplights that may appear in the matrix of randomly changing
road signs, and keeping the black box over the red circle. In addition to these
two primary tasks, the software is also recording information like response
time, standard deviation of the responses, accuracy in hitting the center of
the buttons, ability to track the red circle, invalid and incorrect taps,
etc… Ideally, all of these scoring parameters would be processed to return a
final pass/fail result to determine whether a subject was able to safely
operate a vehicle.
This project was fun because I got to learn how to develop
applications for the iPAQ using eMbedded Visual Basic and eMbedded Visual C++.
This project was primarily software development and data collection, but also
incorporated some hardware integration. Being geared towards law enforcement, I
encorprated a fingerprint reader and card swipe device into the project
developing software for off the shelf hardware. Using the card swipe device,
information about the test subject can be imported into the application easily
by swiping the subject’s drivers license. Cool eh? The results of the
experimental data on the tests I developed were not conclusive. Some trends
were visible, indicating declining test scores with BACs, but the results were
not profound enough to allow this to be a reliable sobriety test, in its
current state. I believe that with more research and development, and lots of
time capturing and analyzing test data, it may some day be feasible.
This project was recently featured in A&M’s school news paper: Sober research
Tester Sentry
Graduate Assistant Research
Software development of an ATE monitoring system.
Summer 2002
Reference: Dr. Jay Porter
The idea behind Tester Sentry is to provide capability to
companies that have many device testers like Texas Instruments. Each chip that
is manufactured must be run through a tester. Down times can cause large delays
and ultimately cost lost of money. Therefore, it would valuable to be able to
immediately be notified when problems occur, and to maintain statistics on the
testers performance and results to analyze what problems are occurring. Tester
Sentry is an independent server machine that is designed to be a data sink for
tester floors. All testers would connect to the server and provide information
about its performance, and in case of emergencies, the server would immediately
notify the correct personnel via emails, pages, web pages, etc… It is also a
central location to store statistics for yield analysis.
The project was a lot of fun. I developed an extremely versatile
and scalable server in LabVIEW. The ease of LabVIEW allowed for an extremely
quick development time. This was actually the minor part of the project. The
major part of this project was providing this client/server capability to the
clients (the testers) and the test engineers. I developed an ActiveX EXE
application in Visual Basic that can be implemented in the tester application
software. This gives the test engineer a high degree of abstraction from the
client/server tasks and TCP operations, and gives him/her the ability to use
high level functions to do all the work. The basic capability and technology is
in place, a proof of concept/demonstration is ready. The next step will be for
Dr. Porter and Dr. Ochoa to contact Motorola and Texas Instruments and find out
exactly what capability they would like for us to provide, so we can further
develop the server functionality to suit their needs.