Design Process

  The Original Plan:

 

Upon receiving the project, the team had to decide on what exactly was wanted by the customer.  The inputs and outputs had to be defined, and many proposed solutions for each aspect arose from the collaboration of ideas.  Once the general concept was agreed upon, subsystems were created to give a separation of each function desired by the client.  Each subsystem consisted of components that had to be researched and chosen.

 

 

It was decided that the team would buy as many pre-assembled, or "off-the-shelf", components as possible, minimizing what was needed to be designed, and built, by hand.  Many data acquisition cards were researched and discussed based upon the number of channels, range of voltage per channel, resolution of bits, I/O ports, available drivers, and processing speeds.

 

 

The hardware subsystems of the IC tester that needed to be constructed were designed using small, inexpensive components, such as relays.  Information exchange between “off-the-shelf” components and designed components presented a problem, but this was quickly solved by making use of I/O bits provided from the “off-the-shelf” devices.

 

The New Plan:

 

The most significant milestone for the team is marked by the trip to Santa Clara, California where the sponsor changed the direction of the project.  Instead of making an IC tester that would test the reliability of an IC, only the functionality of each IC needs to be tested.  In addition, the system itself is to be mobile in order to suffice for a traveling IC tester.  This allows it to be plugged into any PC and run without the need of prolonged set up time (provided that the PC was pre-installed with the correct software).  Many previous problems were drowned by the change, and yet many more arose.  The team now had to think of the project as a digital input and output, and forget about the analog analysis of the ICs being tested.

 

 

Before the change, the major issue was the measurement, with accuracy, of the current provided by a transistor being tested.  Since the project changed to strictly a functionality tester, current was no longer to be measured.  The issue with a functionality tester is that a ‘HIGH’ and ‘LOW’ need to be differentiated from each other using different Vccs for the various ICs.

 

 

During our design process, we encountered many difficulties. The most significant of these was the receipt of our Digital I/O board. Our project revolved around our ability to communicate between the Device Under Test (DUT) and the computer. Without having the Digital I/O board, our only source of communication between the DUT and computer, we were unable to verify correct operation of any portion of the system. The only way we could deal with this hang up was to complete as much as possible. We designed and tested the software as fully as we could. We built representative level shifting circuits to test with the DIO board. This way, when it arrived and we verified their correct operation, we could easily implement the circuit for all 96 channels.

Another problem we encountered was the shear volume of the hardware that needed to be created. It became very difficult to find breadboards with enough area to accommodate 96 channels of level shifting circuitry as well as the regulator circuits. We ultimately had to go to Phoenix to buy all of our components so we could be sure they would fit our needs. 

 

 

We had two major milestones. The first of these was our trip to Intel, which was described above. Our second milestone was receiving our DIO board, which unfortunately occurred a mere 10 days before our Capstone Conference. This left us very little time to test the card and integrate it into our system. Luckily, our design and preparation made this process go relatively smoothly. We only had minor bugs to work out with our code, which were mostly a result of the DIO board not working quite as we had anticipated. Once identified, these problems were easy to fix. Our hardware design worked as expected and construction was able to begin shortly after the verification testing done with the DIO board.

   

 

Pencil and Paper - most of our design was using knowledge and references obtained in previous classes

C++ - used to write computer software

PSPICE - used to draw schematics

 

 

Our development began after our trip to Intel when our project was redefined. We were told to use a specific DIO board, so our design began with the hardware that would interface with this board. Through research and testing of various circuits, we chose to use a MOSFET circuit to handle the level shifting from the DIO to the DUT and a BJT circuit for the DUT to the DIO level shifting.

Design of the software began with understanding the communication between the DIO board and the computer. We began by looking at sample code for the DIO board and extracting the parts relative to our application. This helped us to establish the needed communication. Another major part of the software is the file input and output. A test vector file is necessary to determine the proper inputs to the system as well as verify correct outputs. Development of the code began with creating a header file that defined all of the functions necessary. Once this was done, the code was written to implement these functions. 

After testing of each individual component of the system, integration began with testing of the DIO board with the software. First, correct reading of high and low signals was verified by applying high and low signals to various inputs. After minor tweaking of the software, the reading was in full operation. Next we tested the writing capabilities of the DIO board. This was done by reading in a sample test vector file and then measuring the corresponding outputs with a digital multimeter to validate they were outputting the correct voltages.

Finally, the level shifting hardware was connected to the DIO board. A sample test was run that did not actually correspond to a device. Outputs that normally would have come from the device under test were supplied externally. This allowed us to test the system independent of DUT operation. Once proper functionality was determined, various known good devices were tested, as well as some known bad devices. After some minor adjustments and ascetic alterations, our Functional Integrated Circuit Device Tester was complete.

 

 

   Home