USF Libraries
USF Digital Collections

Development of a software-defined integrated circuit test system using a system engineering approach on a PXI platform

MISSING IMAGE

Material Information

Title:
Development of a software-defined integrated circuit test system using a system engineering approach on a PXI platform
Physical Description:
Book
Language:
English
Creator:
Flores, Alfonso S
Publisher:
University of South Florida
Place of Publication:
Tampa, Fla
Publication Date:

Subjects

Subjects / Keywords:
Software-defined instrumentation
National Instruments
Semiconductor
Failure Analysis
Diode
Dissertations, Academic -- Electrical Engineering -- Masters -- USF   ( lcsh )
Genre:
non-fiction   ( marcgt )

Notes

Summary:
ABSTRACT: There are various types of test performed on Integrated Circuits, (IC), for detecting and locating defects and faults during failure analysis. Functional, logic, parametric and IDDQ tests are among the most common. Functional IC tests are designed to verify whether the IC performs its intended function. Logic tests verify the logic operation of gates and registers. AC and DC parametric tests are used to measure time, voltage and current-varying parameters associated with the operational limits of the IC. Test parameters in parametric testing include, among others, propagation delay, operating current and signals rise and fall time. Currently, almost all ICs are manufactured or refurbished in Asia. A greater portion of the ICs are processed in China and Malaysia.Presently issues with component reliability are compromised since the ICs are not tested before they leave the factory, are sometimes only remarked with different part numbers and date codes or resold even though they do not work properly. These activities lead to a high level of uncertainty among consumers all over the world. The purpose of this research was the design of a software-defined semiconductor validation test system using the PCI eXtension for Instrumentation, (PXI), platform. The test system was to be capable of performing Open and Short Circuit Tests for CMOS components. Open and Short Circuit Tests verify for faults at the protection diode circuitry of CMOS chips level. The test system reduces the overall test timing compared to the tests performed by a functional instrument such as a curve tracer. PXI is a modular instrumentation platform originally introduced in 1997 by National Instruments, (NI). PXI is an open, PC-based platform for test, measurement and control.PXI possesses the highest bandwidth and lowest latency with modular inputs and outputs for high-resolution from DC to RF frequencies. PXI was designed for measurement and automation applications that require high-performance. Concepts associated with the Systems of Systems Engineering, (SoSE), approach were applied to this research in order to facilitate the design process for the test system. The objective was to apply Systems Engineering methodologies to the design of this particular test system.
Thesis:
Thesis (M.S.E.E.)--University of South Florida, 2008.
Bibliography:
Includes bibliographical references.
System Details:
Mode of access: World Wide Web.
System Details:
System requirements: World Wide Web browser and PDF reader.
Statement of Responsibility:
by Alfonso S. Flores.
General Note:
Title from PDF of title page.
General Note:
Document formatted into pages; contains 82 pages.

Record Information

Source Institution:
University of South Florida Library
Holding Location:
University of South Florida
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
aleph - 002001389
oclc - 319704656
usfldc doi - E14-SFE0002629
usfldc handle - e14.2629
System ID:
SFS0026946:00001


This item is only available as the following downloads:


Full Text
xml version 1.0 encoding UTF-8 standalone no
record xmlns http:www.loc.govMARC21slim xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.loc.govstandardsmarcxmlschemaMARC21slim.xsd
leader nam Ka
controlfield tag 001 002001389
003 fts
005 20090430125209.0
006 m||||e|||d||||||||
007 cr mnu|||uuuuu
008 090430s2008 flu s 000 0 eng d
datafield ind1 8 ind2 024
subfield code a E14-SFE0002629
035
(OCoLC)319704656
040
FHM
c FHM
049
FHMM
090
TK145 (Online)
1 100
Flores, Alfonso S.
0 245
Development of a software-defined integrated circuit test system using a system engineering approach on a PXI platform
h [electronic resource] /
by Alfonso S. Flores.
260
[Tampa, Fla] :
b University of South Florida,
2008.
500
Title from PDF of title page.
Document formatted into pages; contains 82 pages.
502
Thesis (M.S.E.E.)--University of South Florida, 2008.
504
Includes bibliographical references.
516
Text (Electronic thesis) in PDF format.
520
ABSTRACT: There are various types of test performed on Integrated Circuits, (IC), for detecting and locating defects and faults during failure analysis. Functional, logic, parametric and IDDQ tests are among the most common. Functional IC tests are designed to verify whether the IC performs its intended function. Logic tests verify the logic operation of gates and registers. AC and DC parametric tests are used to measure time, voltage and current-varying parameters associated with the operational limits of the IC. Test parameters in parametric testing include, among others, propagation delay, operating current and signals rise and fall time. Currently, almost all ICs are manufactured or refurbished in Asia. A greater portion of the ICs are processed in China and Malaysia.Presently issues with component reliability are compromised since the ICs are not tested before they leave the factory, are sometimes only remarked with different part numbers and date codes or resold even though they do not work properly. These activities lead to a high level of uncertainty among consumers all over the world. The purpose of this research was the design of a software-defined semiconductor validation test system using the PCI eXtension for Instrumentation, (PXI), platform. The test system was to be capable of performing Open and Short Circuit Tests for CMOS components. Open and Short Circuit Tests verify for faults at the protection diode circuitry of CMOS chips level. The test system reduces the overall test timing compared to the tests performed by a functional instrument such as a curve tracer. PXI is a modular instrumentation platform originally introduced in 1997 by National Instruments, (NI). PXI is an open, PC-based platform for test, measurement and control.PXI possesses the highest bandwidth and lowest latency with modular inputs and outputs for high-resolution from DC to RF frequencies. PXI was designed for measurement and automation applications that require high-performance. Concepts associated with the Systems of Systems Engineering, (SoSE), approach were applied to this research in order to facilitate the design process for the test system. The objective was to apply Systems Engineering methodologies to the design of this particular test system.
538
Mode of access: World Wide Web.
System requirements: World Wide Web browser and PDF reader.
590
Advisor: Wilfrido Moreno, Ph.D.
653
Software-defined instrumentation
National Instruments
Semiconductor
Failure Analysis
Diode
690
Dissertations, Academic
z USF
x Electrical Engineering
Masters.
773
t USF Electronic Theses and Dissertations.
4 856
u http://digital.lib.usf.edu/?e14.2629



PAGE 1

Development of a Software-Defined Integrat ed Circuit Test System Using a System Engineering Approach on a PXI Platform by Alfonso S. Flores A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering Department of Electrical Engineering College of Engineering University of South Florida Major Professor: Wilfrido Moreno, Ph.D. Paris Wiley, Ph.D. James Leffew, Ph.D. Date of Approval: October 24, 2008 Keywords: Software-Defined Instrumenta tion, National Instruments, Semiconductor, Failure Analysis, Diode, Cost-of-the-Shelf Copyright 2008, Alfonso S. Flores

PAGE 2

Dedication This thesis is dedicated to my parents Alfonso and Maria, my sisters Mariela and Mariana, my brother in law Miguel, my ne phews Miguel Andres and Daniel, my fianc Areany.

PAGE 3

Acknowledgements I would like to give special thanks to my sister an d brother in law, Mariela and Miguel, for their continuous and unconditional support. Their support has been positive, unwavering and continuous since I was young. Their patience and confidence in me has been a stabilizing force in my life. I extend my eternal gratitude to my ma jor professor Dr. Wilfrido Moreno for his encouragement and valuable guidance during my tenure as a Masters Student at the University of South Florida. I extend my thanks to Dr. Paris Wiley and Dr. James Leffew for agreeing to serve on my supervisory committee. I thank my friends and colleagues for thei r support during this research endeavor.

PAGE 4

i Table of Contents List of Tables ................................................................................................................ ..... iv List of Figures ............................................................................................................... .......v Abstract ...................................................................................................................... ....... vii Chapter 1 Introduction and Motivation ...............................................................................1 1.1 Introduction ...........................................................................................................1 1.2 System of Systems Engineering Approach ...........................................................2 1.3 Design Methodology .............................................................................................3 1.4 Top-Down Design .................................................................................................4 1.5 Software-Defined Semiconductor Validation Test Systems .................................7 1.6 PCI eXtension for Instrumentation .......................................................................7 1.6.1 PXI Hardware Architecture .......................................................................... 8 1.6.1.1 Chassis ......................................................................................................... 9 1.6.1.2 PXI Controllers ............................................................................................ 9 1.6.1.3 PXI Peripheral Modules ............................................................................. 10 1.6.1.4 Digital Input/Output (I/O) Module ............................................................ 11 1.6.1.5 Digital Oscilloscope Module ..................................................................... 11 1.6.1.6 Switching Module ...................................................................................... 12 1.7 Motivation ...........................................................................................................13 Chapter 2 Background .......................................................................................................15 2.1 Related Work ......................................................................................................15 2.2 Requirements for Designing a Semiconductor Validation Test ..........................21 2.2.1 Hardware Limitations ................................................................................. 23

PAGE 5

ii 2.2.2 Test System Cost Analysis.......................................................................... 23 2.2.3 Required System Elements ......................................................................... 24 2.3 NI LabVIEW .......................................................................................................27 2.4 NI TestStand .......................................................................................................31 2.5 NI Switch Executive ...........................................................................................31 2.6 Virtual Instrumentation .......................................................................................32 2.7 LabVIEW Signal Express ...................................................................................33 2.8 NI PXI Chassis and Modules ..............................................................................33 Chapter 3 Design and Implementation ..............................................................................39 3.1 Semiconductor Test .............................................................................................39 3.2 Hardware Components ........................................................................................40 3.3 Software Components .........................................................................................43 3.4 Open and Short Circuit Testing Design ..............................................................48 3.4.1 Test Setup.................................................................................................... 49 3.4.2 Testing the VDD Protection Diode ............................................................... 49 3.4.3 Testing the VSS Protection Diode ................................................................ 52 3.4.4 Generation of the Test Report ..................................................................... 53 3.5 Automated Test Setup .........................................................................................54 3.5.1 Initialize the SMU, Configure and Enable the Output of the SMU ............ 59 3.5.2 Initialize the Switching Hardware and Connect DUT Pins to Ground ....... 60 3.5.3 Switching Through the Signal Pins............................................................. 61 3.5.4 Disable and Close the SMU Session Handle .............................................. 64 3.5.5 Disconnect All Signal Pins from the Switching Hardware and Close the NISE Session Handle ............................................................................ 65 3.5.6 Testing the VDD Protection Diode ............................................................. 65 3.5.7 Combining the VSS and VDD Protection Diode Tests and Report Generation Procedure ................................................................................. 66 Chapter 4 Testing and Verification ....................................................................................69 4.1 Results .................................................................................................................69 Chapter 5 Conclusions and Future Work ...........................................................................74

PAGE 6

iii 5.1 Conclusions .........................................................................................................74 5.2 Future Work ........................................................................................................75 References .................................................................................................................... ......76 Appendices .................................................................................................................... ....77 Appendix A: Open and Short Circuit Test System Report ...........................................78

PAGE 7

iv List of Tables Table 1: Required Hardware Components for Open and Short Circuit Tests in PXI ...... 41 Table 2: Required Software Components for Open and Short Circuit Tests in PXI ....... 43 Table 3: VDD Protection Diode Test Specifications ......................................................... 51 Table 4: VSS Diode Test Specifications ........................................................................... 53 Table 5: Set up Route Groups to Simplif y Indexing the Correct DUT Signal Pin .......... 62 Table 6: Test Times Using the Non-Automated Test System ......................................... 73

PAGE 8

v List of Figures Figure 1: Top-Down Design Flow ................................................................................... 5 Figure 2: A PXI Chassis with a Syst em Controller and Peripheral Modules .................. 9 Figure 3: Crosspoint Matrix Configuration ................................................................... 13 Figure 4: Test Syst em Cost Analysis ............................................................................. 24 Figure 5: Tests System Software Architecture .............................................................. 25 Figure 6: COTS Test Syst em Software Architecture ..................................................... 27 Figure 7: Typical LabVIEW Front Panel ....................................................................... 29 Figure 8: Typical La bVIEW Block Diagram................................................................. 30 Figure 9: NI PXI 1045 18-Slot Chassis ......................................................................... 34 Figure 10: NI PXI 8105 Embedded Controller for PXI ................................................... 35 Figure 11: PXI 6534 Digital Input/Output Module ......................................................... 36 Figure 12: PXI 4130 Power Source Measurement Unit .................................................. 37 Figure 13: PXI 2535 128-Cross point Matrix Switch ....................................................... 38 Figure 14: Internal Circuitry of a CMOS Chip ................................................................ 40 Figure 15: Connecting Si gnals to the PXI-2535 .............................................................. 42 Figure 16: Building a 4x272 Matrix Usi ng Two PXI-2535 FET Matrix Modules .......... 43 Figure 17: NI-DCPower and NI Switc h Executive APIs for LabVIEW ......................... 44 Figure 18: Front Panel for Open and S hort Circuit Test System Created in LabVIEW ....................................................................................................... 45 Figure 19: Creating Channel Al iases in Switch Executive .............................................. 46

PAGE 9

vi Figure 20: Switch Executive Intera ctive Switch C onfiguration ...................................... 47 Figure 21: Deploying a Switch Executiv e ‘Virtual Device’ in LabVIEW ...................... 48 Figure 22: Testing the VDD Diode .................................................................................... 50 Figure 23: Testing the VSS Diode .................................................................................... 52 Figure 24: VI Front Pane l for the Test Report ................................................................. 54 Figure 25: Automated Open and Short Circuit Test Setup .............................................. 55 Figure 26: Connecting the SMU and DUT ...................................................................... 55 Figure 27: Grounding Pins is Essentia l for Detecting Short Circuit ................................ 56 Figure 28: VSS Protection Di ode Testing Procedure ...................................................... 58 Figure 29: Initializing, Confi guring, and Enabling the SMU .......................................... 60 Figure 30: Initialize the Switching Module and Connect the DUT Pins to Ground ........ 60 Figure 31: Disconnect GND, Connect SMU, Measure, Disconnect SMU, and Reconnect GND ............................................................................................. 62 Figure 32: Array Output Using NI Switch Executive Configuration API ....................... 63 Figure 33: Determine Test Result Based on the Voltage Measurement .......................... 64 Figure 34: Disable the SMU Output and Close th e SMU Session Handle ...................... 64 Figure 35: Disconnect all Signal Pins and Close the NISE Session Handle ................... 65 Figure 36: VI Front Panel for the Open and Short Circuit Test System .......................... 67 Figure 37: VI Block Diagram for the Op en and Short Circuit Tests System .................. 68 Figure 38: NI-DCPower Measure Function ..................................................................... 70 Figure 39: Generation of Random Voltage Values .......................................................... 70 Figure 40: System Execution Time Results ..................................................................... 71 Figure 41: VDD Test Execution Time Results .................................................................. 72 Figure 42: VSS Test Execution Time Results ................................................................... 72

PAGE 10

vii Development of a Software-Defined Integrat ed Circuit Test System Using a System Engineering Approach on a PXI Platform Alfonso S. Flores Abstract There are various types of test perfor med on Integrated Circuits, (IC), for detecting and locating defects and faults dur ing failure analysis. Functional, logic, parametric and IDDQ tests are among the most common. Functional IC tests are designed to verify whether the IC performs its inte nded function. Logic tests verify the logic operation of gates and registers. AC and DC parametric tests are used to measure time, voltage and current-varying parame ters associated with the operational limits of the IC. Test parameters in parametric testing in clude, among others, propa gation delay, operating current and signals ri se and fall time. Currently, almost all ICs are manufacture d or refurbished in Asia. A greater portion of the ICs are processed in China and Malaysia. Presently issues with component reliability are compromised since the ICs are not tested before they leave the factory, are sometimes only remarked with different part numbers and date codes or resold even though they do not work properly. These activit ies lead to a high level of uncertainty among consumers all over the world.

PAGE 11

viii The purpose of this research was the de sign of a software-defined semiconductor validation test system using th e PCI eXtension for Instrumentation, (PXI), platform. The test system was to be capable of perfor ming Open and Short Circuit Tests for CMOS components. Open and Short Circuit Tests verify for faults at the protection diode circuitry of CMOS chips level. The test sy stem reduces the overall test timing compared to the tests performed by a functional instrument such as a curve tracer. PXI is a modular instrumentation platfo rm originally introduced in 1997 by National Instruments, (NI). PXI is an open, PC-based platform for test, measurement and control. PXI possesses the highest bandwid th and lowest latency with modular inputs and outputs for high-resolution from DC to RF frequencies. PXI was designed for measurement and automation applications that require high-performance. Concepts associated with the Systems of Systems Engineering, (SoSE), approach were applied to this research in order to faci litate the design process for the test system. The objective was to apply Systems Engineer ing methodologies to the design of this particular test system.

PAGE 12

1 Chapter 1 Introduction and Motivation 1.1 Introduction A software-defined Integrated Circuit Te st System allows engineers to quickly adapt to challenging test requirements. The functionality of modular instrumentation is characterized through user-defined software residing in the test workstation. Through software, engineers can program a modular instrumentation sy stem to function as a userdefined instrument using progr ammable I/O and built-in shared clocks and triggers. PXI is an example of a platform for buildi ng modular automated test systems based on software-defined instrumentation concepts. A Software-Defined Test System, (SDTS), can be as simple as a digital multimeter whose operating mode and measur ement are controlled and analyzed by a computer. A SDTS can also be as complex as a system c ontaining dozens of specialized test instruments, which are cap able of automatic test and di agnoses of faults in complex electronic systems such as tests performed on sophisticated printed circuit boards. A SDTS for semiconductor validation possesses th e capability to test a wide range of electronic devices and systems. Such testi ng extends to the component level and includes all components such as resistors, capacitors, inductors, integrated circuits for printed circuit boards and assembled electronic systems. In addition, SDTS is presently being

PAGE 13

2 used in many other industries, both commercial and military, to test various applications that range from testing aerodyna mics performance in airplanes to medical devices, [1]. There are various types of test perfor med on Integrated Circuits, (IC), for detecting and locating defects and faults dur ing failure analysis. Functional, logic, parametric and IDDQ tests are among the most common. These tests are performed in combinations at the wafer, at the bare-die, at the package, at the assembly and at the system levels. Functional IC tests are desi gned to verify whether the IC performs its intended function. Logic tests verify the logic operation of gates and registers. AC and DC parametric tests are used to measure time, voltage and current-varying parameters associated with the operational limits of the IC [2]. To insure proper implementation of software-define test systems, all the modul es and interfaces must work in synergy. Therefore, applying system desi gn principles to the design of the test system can simplify design work and can avoid problems involved with integrating the modules efficiently. PXI is a modular instrumentation platform It was designed for measurement and automation applications, which require highperformance and a rugged industrial formfactor. The flexible, modular and scalable architecture of the PXI platform provides the possibility of creating customized software-d efined test systems, which can be easily reconfigured to meet differen t test needs and requirements. 1.2 System of Systems Engineering Approach System of Systems, (SoS), engineering is a set of developing processes, tools and methods for designing, re-designing and deployi ng solutions for complex systems. SoS is widely used in military applications a nd is increasingly being adopted by non-military

PAGE 14

3 companies such as auto makers, aircraft manufacturers, healthcare agencies and global communication networks. System of systems is a term being used for a collection of dedicated systems that contribute with their resources and capabilities to support the design and development of more complex systems. Complex systems created using this approach possess the capability to offer more functionality and pe rformance than simply the sum of each subsystem, [3]. Approaching a complex system as a system of systems helps to divide the functionality and verify the working of th e subsystems independently. This design methodology also helps to enhance the interope rability and portability of the design. As a result of the diverse methodologies and applications, there exists no single unified consensus for processes involved in System of Systems Engineering. Best practices suggest a three-phase method wher e the SoS problem is defined, abstracted, modeled and analyzed for behavioral patterns Based on the overall system requirements, designers identify the subsystem require ments and then design and validate the subsystems. This approach makes it easy to test, debug and integrate the subsystems to achieve the whole system, [4]. 1.3 Design Methodology A good design methodology can help the system design process in different ways. It can help to verify the system functionality and discover early design flaws. It can help the design team coordinate and reduce the overall design effort. The design process should provide a time line for the designers and the deliverables, which will be due at

PAGE 15

4 different times. The design methodology invol ves the global approach of the chief designers to the system design. Since the projects mostly involve many teams working on the project at the same time, this met hodology can facilitate coordination, which can be very productive for achieving the design goals. The system engineering methodology helps define a group of solutions. These solu tions meet requirements, which can be used in the future to select a final design imple mentation based on additional constrains such as manufacturing cost, perfor mance and power consumption. 1.4 Top-Down Design The top-down design approach involves five main phases, which range from requirement identification to system integr ation. This approach helps the designer achieve the most favorable solution after c onsidering all the possi ble alternatives. Occasionally, the design effort may focus on tr ying to fit the solution within the available resources. This approach, which may provi de short term achievements, may lead to complications while fulfilling future need s and not necessarily yield the optimum implementation. Any application may have a large number of possible implementations. Selecting the optimal solution based on the target application can provide numerous advantages. The Top Down Design Fl ow is illustrated in Figure 1.

PAGE 16

5 Figure 1: Top-Down Design Flow The idea of fitting any problem into an already available solution may sound lucrative to the designer due th e ease of implementation. Du e to the fact that there is always a better implementation for an exis ting project, the top down approach helps in viewing the requirements in an objective way. In this approach the designer is faced with a large number of different implementa tion possibilities from which the most advantageous solution can be selected base d on system requirements. The process of selecting the most favorable solution is a very important judgment. The selection process involves the analysis of all the available resources such as non-recurring engineering cost, size and power. In addition, it can lead to advantages in terms of lowering the required resources and, consequently, incr easing the performance of the system. Requirements are an abstract description of the system which involves functional as well as non functional requirements. Requirements can also include the customers’ expectations about what the system must achieve. Requirements may put monetary and

PAGE 17

6 timing constraints on the design, which will have to be considered along with the technical specifications. Designe rs need to utilize these re quirements and build a system, which can perform the expected tasks. It is a good practice to validate each requirement during the design process and make a fi nal verification at the product level. The system specifications are more focused on system implementation. They offer the designer a road map on how to design the system. The specifi cations have to be written carefully to ensure they meet re quirements. The specifications must be comprehensible and unambiguous so that th e designer knows what has to be built. Ambiguous specifications can lead to a wr ong implementation, which can defeat the whole purpose of using a system approach. The architecture describes how the func tions are implemented in the system. Architecture is the structural definition of the system and is the framework within which the technical requirements of the system mu st be met. The architecture will involve specifications with respect to how the subsys tems are to be interfaced with each other. The components specifications are defined as functions of the architecture. The components can be hardware components as well as software components. The components perform system tasks and colle ctively perform the architecture tasks. System integration is where the benefits of using the system approach can be witnessed. This phase can be straightforwar d if the specifications and architecture are designed correctly and validated. The whole sy stem will be put together and the working system realized. The system engineering concep ts help to keep track of specifications of separate modules, which make it possible to verify modules independently. Therefore, the system integration process is simplified, [5].

PAGE 18

7 1.5 Software-Defined Semiconducto r Validation Test Systems A typical semiconductor valida tion test system consists of various instruments or modules used for testing analog, digital or mixed-signal components such as memory and system-on-chip, (SoC). Testing can occur eith er at the wafer or at the package level. Driven by the demand of electronics, compu ting and communication markets these test systems continue to evolve. To keep p ace with innovation in th e semiconductor industry, current test system products must provide more functionality and higher speeds than previous designs. Software-defined instrumentation plays an important role in the development of test systems by providing flexibility and scal ability. Functions such as timing accuracy, memory control, digital signal processi ng analysis, high speed inputs and outputs capability and jitter co mpliance are all served by software-defined instrumentation, [6]. 1.6 PCI eXtension for Instrumentation PXI is a modular instrument system designe d to take advantage of the very fast data interfaces associated with PCI and Co mpact PCI bus systems. PXI offers a cost effective solution that satisfi es the requirements of test and measurement in industry today. The PXI standard defines mechanical, elec trical and software interfaces, which are provided by PXI compliant products. Th ese products ensure th at integration costs and software costs are minimized and allow trouble free multi-vendor solutions to be implemented.

PAGE 19

8 The PXI industry standard has quickly ga ined adoption and grown in prevalence in test, measurement and control systems since its release in 1998. It is being selected as the platform of choice for thousands of a pplications such as aerospace, consumer electronics, communications, process control and indus trial automation. One of the key elements driving the rapi d adoption of PXI is its use of the PCI bus as the communication backplane. As th e commercial computer industry drastically improves the available bus bandwidth by upgrading from PCI to PCI Express, PXI has the ability to meet even more application needs by integrating PCI Express into the PXI standard. With PXI Express, users will be nefit from significantly increased bandwidth, guaranteed backward compatibility and addi tional timing and synchronization features. Most PXI instruments modules are simple register based products, which use software drivers to configure them as usef ul instruments. Such reconfiguration takes advantage of the increasing power of co mputers to improve hardware, which is reconfigured to provide new facilities and features. These features are difficult to emulate in comparable bench instruments. The PXI instruments function modules ar e connected to a chassis, which may include its own controller, r unning an industry standard opera ting system or a PCI to PXI Bridge, which provides a high sp eed link to a desktop, [7]. 1.6.1 PXI Hardware Architecture PXI systems consist of three basic components: The chassis, The system controller,

PAGE 20

9 The peripheral modules. These components are pictured in Figure 2. Figure 2: A PXI Chassis with a System Controller and Peripheral Modules 1.6.1.1 Chassis PXIs’ chassis provides the rugged modular packaging for the system. Chassis are available in both 3U and 6U sizes. Chassis generally range in si ze from 4-slots to 18slots. Chassis are availabl e with special features such as DC power supplies and integrated signal conditioning. The cha ssis contains the hi gh-performance PXI backplane, which includes the PCI bus, timi ng bus and triggering bus. Using the timing and triggering buses, systems for applications requiring precise sync hronization can be developed, [8]. 1.6.1.2 PXI Controllers In accordance with the PXI Hardware Sp ecification, all PXI chassis contain a system controller slot, which is located in the leftmost slot of the chassis. Controller

PAGE 21

10 options include remote controllers from a desktop, workstation, server or a laptop computer. In addition, options are availabl e for high-performance embedded controllers with Windows 2000/XP or real-time operati ng systems such as LabVIEW Real-Time, [8]. 1.6.1.3 PXI Peripheral Modules There are approximately 1200 products ava ilable from more than 70 members of the PXI Systems Alliance. Some of the existing modules are: Analog Input and Output, Boundary Scan, Bus Interface and Communication, Digital Input and Output, Digital Signal Processing, Functional Test and Diagnostics, Image Acquisition, Prototyping Boards, Instruments, Motion Control, Power Supplies, Switching, RF and Communications. The software-defined test system devel oped in this research uses three main peripherals modules:

PAGE 22

11 Digital input/output module, Power source measurement unit, Switching module, [8]. 1.6.1.4 Digital Input/Output (I/O) Module In principle, these modules have a relativ ely simple architecture. Digital outputs can be connected to the Device Under Test, ( DUT), and digital inputs of the module can be used to measure the lo gical outputs of the DUT. I/O modules use a clock to sequence thr ough a pattern of digi tal input and output conditions. The output signals from the modul e simulate an external data source while the inputs to the module record the DUT re sponse. A clock can be provided from the module or from an external source, wh ich includes the DUT where synchronous operation is a requirement. Modules are usually available with diffe rent memory depths behind each of the digital outputs. These modules allow the user to select a memory depth, which meets the application requirements. The memory can also be used to store more than one waveform in segments, which can be loaded and then selected for replay, [8]. 1.6.1.5 Digital Oscilloscope Module A Digital Oscilloscope, (DSO), capture s an analogue input waveform and converts the time varying signal into a digital representation. The digital representation can be displayed in much the same way as a conventional oscilloscope. However, instead

PAGE 23

12 of using a cathode ray tube, (CRT), to displa y the waveform, a soft front panel displays the signal on the monitor attached to the PXI system controller. Many of the available functions on an analog oscilloscope can be emulated on a DSO. However, there are also many additi onal functions, which can be added through the use of an embedded digital signal processor or the driver software. A record of how the signal varies with time is captured as di gital data, rather than as fleeting visual information on a screen. Such a record provides opportunities for data analysis and display enhancement capabilities, [8]. 1.6.1.6 Switching Module Switching systems are a key part of most test systems. Signals need to be routed to various parts of the DUT and signals from the device need to be routed to measuring equipment so that test results can be obtained. The selection of the proper switching sy stems varies greatly depending upon the type of the test being performed and the num ber of component I/Os. Signals can vary from high current or high voltage applicati ons to low voltage access points for 4 wire measurement on low power PCBs. There are di fferent switch types such as single pole single throw, single pole double throw, double pole sing le throw and different configurations such as cascade, multiplexer, tree and crosspoint matrix, [8]. This research chose a software programma ble crosspoint matrix configuration. This configuration utilized switches arranged in rows and columns. A switch was located wherever a crosspoint occurred, which allowe d the row and column to be connected. There was no limit to the number of connecti ons associated with a particular row or

PAGE 24

13 column. However, if more than one conn ection was made the lo ad on the signal source increased. The crosspoint matrix conf iguration is illustrated in Figure 3. Figure 3: Crosspoint Matrix Configuration 1.7 Motivation Facilitation of the design of a software-defined test system for semiconductor testing, which followed a System of System s Engineering approach was the motivation behind the research reported in the thesis. Test engineers in industri es ranging from aerospace to consumer electronics are facing the challenge of increasingly comp lex designs with shrinking timelines and budgets. To address these issues engineers and scientists ar e incorporating new test and measurement technologies, which are capable of meeting complex design requirements while keeping testing costs on budget. One issue facing test engineers is that test instrumentation is not updated as rapidly as the testing needs for new devices. The functionality of these complex devices such as most smart phones is being defi ned by the embedded software, which gives design engineers the ability to add features fast er than ever before. This is increasingly

PAGE 25

14 challenging for many test engineers since most stand-alone instrume nts often lack the measurement capabilities required by the latest standards due to the fixed user interface and embedded firmware. Ther efore, test engineers are tu rning to a software-defined instrumentation approach. This approach provides the ability to quickly customize equipment and user interfaces to meet specif ic application needs and integrates testing directly into the design process, which reduces development time. PXI is an example of a widely used software-defined instru mentation standard for building modular, reconfigurable high-performance automated test systems, [9].

PAGE 26

15 Chapter 2 Background 2.1 Related Work The scopes of test challenges, which are encountered in the military and aerospace fields, are good exampl es of how software defined instrumentation plays an important role in solving these challenges. Not so many years ago, testing for Mil-Aero products was mostly accomplished via specific -purpose test systems. These systems were often designed as part of a program by a prime or sub-contractor test systems group. Presently, it is much more likely that test requirements are met with mostly commercial off-the-shelf, (COTS), components. Still, the requirements imposed on a given test system are evolving at the same fast rate as test instrument technology. Economic pressures on Mil-Aero program s and test management are tending toward the same conditions as found in the commercial field. The primary pressures relate to reduction of capital expenditures, a dhere to bring-up schedul es and decrease test time, which would result in reduced time to ma rket. Additionally, th ere is pressure to reduce the total cost of testing even as the functionality and speed of the device or DUT are becoming more complex. There is an enormous engineering effo rt behind U.S. government programs that take on challenges such as the problems of battlefield communication or the problem of

PAGE 27

16 inter-agency communication in the event of a catastrophe. With new trends such as battlefield networking with self-repair, heig htened security measures and agile radio technology the landscape for te sting is quite complex. The reality of multi-vendor sourcing to address costs for the radio components threatens the need for successful seamless ope ration over the several protocols that the radio modules must support. This makes inte roperability testing a very high priority. Use of Golden radios, which are known to wo rk perfectly as designe d, for bit error rate, (BER), testing in manufacturing is very comm on. This approach is much less practical for modular radios integrated from bins of parts, components or modules from diverse vendors. Traditionally, high volume test applicatio ns for Military-Aer ospace products are rare. However, the DUT test volume for el ectronically steered pha sed array systems can escalate significantly. The test requiremen ts are very demanding. For example, test equipment must have the capability to m easure power levels that exceeds 50 dBm, (pulsed), and third harmonic bandwidths that can reach 36 GHz or higher. In addition, measurements to less than one degree of phase accuracy in some applications are required. In addition to the technical challenges asso ciated with the applications presented, there are cost issues, which need to be manage d. It can take hours to calibrate a system, which operates through 36 GHz. Fa ilure rates and repair times must be carefully factored into capacity models. The implementation time and expertise level required for the application can be critical. The ability of the system to prove that it is functioning properly can have surprising leverage in tota l test cost. System longevity and system

PAGE 28

17 upgradeability are equally critical. These parameters determine the mission fulfillment efficiency of a test system. Costs related to these parameters are sometimes overlooked when focusing on the capital costs at the beginning of a program. Solutions to the applications’ challenges outlined are increasingly offered in the form of software defined test instrument, (SDI), systems rather than as conventional “rack and stack” systems. Based on the conf iguration of a group of COTS subsystems, SDIs perform major functions of the measur ement science. However, they are not delineated along the lines of classic instru ment technology. For example, a synthetic instrument applies the combination of a dow n-converter and digiti zer to collect raw measurement data. The synthetic instrument negates the need for a network analyzer, spectrum analyzer and modulati on analysis instruments. Th e measurement results, which would normally come from a classical instru ment, are processed using DSP technology. This is the central concept of the synthetic system capability. Usi ng this approach, the test engineer also has finer-g rained access to the “knobs” or setting variability of the measurement procedure. Stimulus and re sponse measurement channels are all multipurpose in capability. Important Mil-Aero customers are clearly delineating their expectations for the use of modular microwave test systems with software-defined instruments for the future. Current and future Mil-Aero test systems w ill be implemented using scalable slices of more integrated technology. These slices wi ll feature industry standa rd board instrument platforms and industry standard software. Th ere are two examples in the greater test market where modular technology evolu tion has already been demonstrated.

PAGE 29

18 The IC test industry determ ined that meeting the dive rse requirements of their customer’s DUTs required board-based, modular instrumentation. Consequently, digital I/O boards, analog to digital boards, digita l to analog boards, pow er supply boards and, more recently, RF stimulus-measurement subsystems are all offered in configurable slices in virtually any IC testers. There is not yet any particular standardization of the card cage or buses utilized across multiple vendors. However, there are certainly major customers such as Intel and the Open Ar chitecture Consortium demanding that the industry institute appropriate standards. PXI-served markets provide another case in point. Engineering and production test applications can be implemented more co st-effectively using a c onfigurable PXI. A 100 M sample/s, 14-bit digitizer capability in PXI will cost approximately one tenth the price of a proprietary-arc hitecture-based IC test system, [10] This illustrates the leverage of higher production volumes and in dustry standards-based technology. State-of-the-art modular te st technologies are addr essing the two application examples described previously. The first of these two applications is the software defined radio test solutions. The data bandwid ths of the majority of Mil-Aero radios are still fairly modest. The majority fall we ll below 10 Mbits/s and many are still in the Kbit/s range. The data rate will probably increase dramatically over time. However, currently test bandwidths are bei ng driven not by data rates. They are being driven by the rates and ranges over which frequency-ag ile radios can hop. Frequency hopping Hop performance has reached the 100 KHz level and hopping range requi rements exceed 250 MHz.

PAGE 30

19 The waveform and spectral deviations, whic h can occur as a function of relatively small differences in physical circuit design, put great pressure on inte roperability quality assurance. To thoroughly explor e possible interoperability issu es, it is necessary to probe deeper into the operation of the radio. I nvestigating the dynamic behavior of the radio designs is required as a result, it is necessary to employ systems, which can generate and capture events, across the operati ng bandwidth of the radio and record all the events for a significant period of operating time. In th is case, industry-lead ing broadband signal generators, broadband signal recorders, broa dband signal analyzer s and appropriate upconverter and down-converter interfaces are employed. These instruments enable capture of waveforms transmitted by a radio. They al so enable overlay of practical impairments and playback of the resulting waveforms to test radio receivers with appropriate application stressors applied. Impairment signal overlay is controlled by software, which can deal directly with Doppler shift, fading, noise and other practical channel parameters. This software frees test engineers from dea ling with arbitrary waveform generator loads, Fast Fourier Transforms, (FFT,) and invers e FFTs. Vector Signal Source and Channel Simulator software enables the test engineer to move from theoretical or measurement parameters directly to hardware genera tion. Additionally, the software provides considerable simulation and gr aphical tools along the way. On the transmitter side of the radio, recorders can be implemented to capture events at very high sample rates for up to 20 seconds. This capabi lity allows observation of the important dynamic events of a modulated radio hopping throughout a 250 MHz instantaneous bandwidth. Record and analysis software highlights the differences, which could create radio inte roperability issues.

PAGE 31

20 The phased array transceiver module te sting application is particularly demanding. The higher counts of modules re quired to implement an electronically steered beam radar array demand both highe r throughput as well as state-of-the-art accuracy and resolution. The modules in an array must perform and conform to strict amplitude and phase specifications over a range of frequencies, power levels and control signals. Operating bandwidths for the radar may be fairly limited. However, the test system is required to operat e at three times the maximum in-band frequency of operation in order to verify harmoni c and spurious behavior. A sophisticated synthetic instrument-based system can provide multiple capabilities. For example, a system can offer the combination of a broadband upconverter and a broadband down-converter with variable bandwidth baseband capability to provide test systems to meet these re quirements up to 26 GHz. The system meets rigorous requirements for calibration and meas urement. These requirements can include capabilities such as very fast measuremen t of error-corrected s-parameters, spectral characteristics, modulation, demodulation, nois e figure and/or noise power using a single non-switched channel. The system can be ve rified in-situ without removing the DUT. These capabilities are performed to equivale nt network analyzer, error-corrected, sparameter levels of confidence. Military and Aerospace customers repres ent the vanguard of demand for RF and microwave test solutions that can be in stantiated in modular, software defined instrumentation systems. Even the most successful of the rack and stack domain instrument vendors are persuaded to talk in terms of future solutions based upon modular synthetic instrument technologies.

PAGE 32

21 COTS synthetic instrumentation subsys tems are already available and are becoming more integrated and more modular The systematic movement from COTS instrumentation components to COTS system s is dependent on the software provided. The software required to integrate the modul ar components into seamless systems is becoming less instrument and driver-specifi c and more measurements oriented. The advent of moving toward a measurement de fined environment will lead to increasing improvements in efficiency, flexibility and cost. As semiconductor devices become more co mplex, the process of testing each part completely with a traditional vector-based methodology becomes increasingly difficult. Complex systems-on-a-chip and systems-in-a -package, (SiP), require a system-level functional test more closely related to testing components placed on a printed circuit board than a typical chip test. However, th ey still require the high speeds demanded in production tests for the semiconductor industr y. The strategy of testing a device by emulating actual real-world signals provides a better method of functional test for these types of high-speed systems, [10]. 2.2 Requirements for Designing a Semiconductor Validation Test Understanding the requiremen ts is the most important task for designers and engineers in any development effort. In th e Systems of System Engineering approach understanding the requirements is the essential process. The requirement identification process helps divide the system s into the number of subsystems necessary for arriving at the proper solution of the whole system.

PAGE 33

22 The general requirements for the validation of a semiconductor system using the PXI platform must: Reduce time and investment for test system development and maintenance, Optimize test throughput, Reduce false failures or false passes, Use commercial off the shelf, (COTS), software, Provide reliability, Allow scalability in size and functionality. In more detail, the test system and the t ype of test must comply with the following requirements: The test needs to be fast enough to satis fy approximately three or four devices per minute. The test system needs to be capable of testing all CMOS devices with diode protection and no restricti on with respect to packag ing. For this purpose, a standard interface must be developed. The test must validate the results acco rding to nominal parameter values. For this requirement, a graphical user in terface is necessary, which allows the operator to introduce manufacturer datashee t parameters. For example, values for maximum and minimum voltage or maximum and minimum drain current. At the end of the test the system must be able to generate a final report with the following information: • Customer Information, which includes name, business mailing address, purchase order number and total quantity of devices,

PAGE 34

23 • Part number and part description, • Total number of devices tested, • Number of devices th at passed and failed. Save nominal parameter values for the DUT. Provide reusable test configurations for the same device in the future. 2.2.1 Hardware Limitations Some of the hardware limitations enc ountered during the requirement analysis process were: Power Supply Voltage, (30 Vdc Max.), Maximum frequency for DIO approximately 20MHz, System capable of handling current values up to 1 A. 2.2.2 Test System Cost Analysis Cost analysis is an important part of the requirement process since most companies have budget limitations. The cost percentages presented in this thesis are statistics taken from a cost survey associat ed with the development of software-defined instrumentation in companies with differe nt development fields, [11]. The cost percentages, presented graphically in Figure 4, were determined to be: Hardware and Software – 36%, Development costs – 64%, • Software development – 30%, • System integration – 23%,

PAGE 35

24 • System configuration – 7%, • System validation – 4%. Figure 4: Test System Cost Analysis 2.2.3 Required System Elements The typical system elements to consider from a high-level to low-level, when building an automated test equipment system consist of the test executive, test development software, the automation contro ller and instrumentation as well as the fixture. These elements are illustrated in Figure 5.

PAGE 36

25 Figure 5: Tests System Software Architecture The most important part of designing a software-defined test system is the development of an appropriate test software ar chitecture. If the ar chitecture is not given appropriate and careful consid eration designers run the risk of limiting reuse, hindering maintenance and greatly shortening the lif etime or the test system. Although the architecture presented may seem relatively si mple, the implications with respect to the test system are great. From bottom up, the hardware and necessary specific drivers are common to every test system. The hardware abstraction layer that sits above the specific drivers plays a vital role in the system. Its main function is to protect the investment in the software above it by providing a common interf ace to instrument and specific drivers. This arrangement allows designers to reuse code modules with di fferent equipment or exchange or replace equipment withou t affecting the test module layer. An important fact is that eighty percent, (80%), of the development time is spent developing the actual test modules. The test module layer is where specific tests and code are defined for each product being tested. By protecting and sepa rating this layer in Drivers Test Module Test Management Switch Management Operator InterfaceSoftware Architecture Hardware Components Hardware(. .) Test Module Test Module Test Module Drivers Test Module Test Management Switch Management Operator InterfaceSoftware Architecture Hardware Components Hardware(. .) Test Module Test Module Test Module Drivers Test Module Test Management Switch Management Operator InterfaceSoftware Architecture Hardware Components Hardware(. .) Test Module Test Module Test Module

PAGE 37

26 modules, designers greatly improve the system reuse capability and maintenance as well as increasing system longevity. The test management layer sits above the test modules and is designed to provide a modular and reusable framework for the test s. Its primary func tion is to handle the common tasks needed by each test module. These common tasks include result evaluation, reporting, database logging, user management, configuration management, switching and unit under test tr acking. By handling thes e functions and providing a simple interface between the modules, development on the modules, which accounts for most of the test system development time, is greatly reduced. All of these common tasks are also maintained in one location maki ng updates to the system much simpler. Switching is often used to reduce comp lexity, increase automation and reduce instrument costs. However, if switching is in cluded within a test module’s code that test module is no longer reusable since it is tied specifically to the switching system, which greatly increases development costs. Use of a switch manager, which is tied to the test management system, allows switching externa lly to be applied to the module test step directly. This direct access to the hardware abstraction la yer keeps the reuse capability high and maintenance low on switching. The final piece of the architecture is the user interface. Typically, designers will want a standard interface a pplied throughout the organizati on, which is decoupled from the testing process or the tests themselves. This provides a common look and feel, which reduces operator training costs and allows any operator to work on any station. By decoupling the interface code from the rest of the test system, designers can test any product without requiring a cha nge to the interface, [12].

PAGE 38

27 Figure 6 presents those COTS-based software and hardware systems for each level of the system architecture, which we re presented in Figure 5. The Software components and the hardware components are ex plained in detail in the discussion of NI LabVIEW in section 2.3. Figure 6: COTS Test Syst em Software Architecture 2.3 NI LabVIEW Laboratory Virtual Instrume ntation Engineering Workbench, (LabVIEW), is a platform and development environment for a visual programming language from National Instruments. Originally released for the Apple Macintosh in 1986, LabVIEW is commonly used for data acquisition, instrume nt control and indus trial automation on a variety of platforms, [11]. The programming language used in LabVIEW, also referred to as G, is a dataflow programming language. Execution is determined by the structure of a graphical block diagram, (the LV-source code), on which the programmer connects different function-nodes by drawing wires. These wires propagate variables and any node can Instrument Specific Drivers LabVIEW NI TestStand NI Switch Executive Hardware(. .) LabVIEW LabVIEW LabVIEW IVISoftware Architecture Hardware Components NI LabVIEW Instrument Specific Drivers LabVIEW NI TestStand NI Switch Executive Hardware(. .) LabVIEW LabVIEW LabVIEW IVISoftware Architecture Hardware Components NI LabVIEW

PAGE 39

28 execute as soon as all its input data becomes available. Since this might be the case for multiple nodes simultaneously, G is inherent ly capable of parallel execution. Multiprocessing and multi-threading hardware is automatically exploited by the built-in scheduler, which multiplexes multiple OS threads over the nodes ready for execution. The data-flow completely defines the execution sequence, which can be fully controlled by the programmer. Thus, the execution sequence of the LabVIEW graphical syntax is as well-defined as with any textually coded language such as C. Furthermore, LabVIEW does not require type definition of the variables. The wire type is defined by the data-supplying node. LabVIEW supports po lymorphism in that wires automatically adjust to various types of data. LabVIEW ties the creation of user inte rfaces, called front panels, into the development cycle. LabVIEW programs/subr outines are called vi rtual instruments, (VIs). Each VI consists of a block diagra m, a front panel, and a connector pane. The connector pane is used to represent the VI in the block diagrams of other calling VIs. Controls and indicators on the front panel allow an operator to input data into or extract data from a running virtual instrument. Howe ver, the front panel can also serve as a programmatic interface. Thus a virtual instru ment can either be run as a program, with the front panel serving as a user interface. Alternatively, when a VI is dropped as a node onto the block diagram, the front panel defi nes the inputs and output s for the given node through the connector pane. This implies each VI can be easily tested before being embedded as a subroutine into a larger program. A typical front panel is presented in Figure 7.

PAGE 40

29 Figure 7: Typical LabVIEW Front Panel The corresponding block diagram for the front panel is presented in Figure 8.

PAGE 41

30 Figure 8: Typical LabVIEW Block Diagram The graphical approach also allows nonprogrammers to build programs simply by dragging and dropping virtua l representations of laborat ory equipment with which they are already familiar. The LabVIEW programming environment, with the included examples and the documentation, makes it simple to create small applications. This is a benefit. However, there is also a certain da nger of underestimating the expertise required for good quality "G" programming. For complex algorithms or large-scale code, it is important that the programmer possesses an extensive knowledge of the special LabVIEW syntax and the topology of its me mory management. The most advanced LabVIEW development systems offer the possibility of building stand-alone applications.

PAGE 42

31 Furthermore, it is possible to create distri buted applications, which communicate by a client/server scheme. Therefor e, distributed applications are easier to implement due to the inherently parallel nature of G-code. 2.4 NI TestStand NI TestStand is ready to run test manageme nt software designed to help engineers accelerate the development of automated test and validation systems. NI TestStand can be used for developing, executing and deployi ng test system software. Additionally, engineers can create test sequences, which in tegrate code modules written in any test programming language. Sequences also spec ify execution flow, report database logging and connectivity to other enterprise systems. In addition, test systems can be deployed to aid production with easy-to-use operator interfaces, [11]. 2.5 NI Switch Executive One key component of National Instruments test management software is the NI Switch Executive, (NISE), which simplifies the management and control of complex switching systems. NISE is integrated w ith LabVIEW and LabWindows/CVI to decrease development time for validation of test and rese arch and development test. NISE is also integrated with the NI Teststand to provide ea se of use of test step in sequence execution and for production test, [11]. The following tasks can also be performed with NISE: Develop multiple device switch systems represented as a single virtual device, Create end-to-end signal routing, Make route selections based on signal characteristics and switch capabilities,

PAGE 43

32 Create route groups used to make intell igent resource selec tions when creating routes, Create switch routing for end-to-e nd calibration and maximum execution speed, Pre-configure routes and r oute groups that can be call ed by name at run-time, Generate a report of the switching system, Create routes graphically with an in teractive schematic view of switch devices, Configure large and complex switch ing systems quickly with Excel integration. 2.6 Virtual Instrumentation Virtual Instrumentation is the use of customizable software and modular measurement hardware to create user-defined measurement systems, called virtual instruments. Traditional hardware instrume ntation systems are made up of pre-defined hardware components such as digital multimeters and oscilloscopes, which are completely specific to their stimulus, analys is or measurement function. Due to their hard-coded function these systems are more limited in their versatility than virtual instrumentation systems. The primary diffe rence between hardware instrumentation and virtual instrumentation is that software is used to repla ce a large amount of hardware. The software enables complex and expensiv e hardware to be replaced by computer hardware. For example, an analog to digital converter can act as a hardware complement of a virtual oscilloscope or a potentiostat, which can enable frequency response

PAGE 44

33 acquisition and analysis in electrochemical impedance spectroscopy with virtual instrumentation. The concept of a synthetic instrument is a su bset of the virtual instrument concept. A synthetic instrument is a type of virtual instrument, which is purely software defined. A synthetic instrument performs a specific sy nthesis, analysis or measurement function on completely generic measurement agnostic hardware. Virtual instruments can still have measurement specific hardware a nd tend to emphasize modular hardware approaches, which facilitate specificity. Ha rdware supporting synthetic instruments is by definition not specific to the measurement nor is it necessarily or usually modular. 2.7 LabVIEW Signal Express National Instruments LabVIEW Signal Express is interactive measurement software, with no programming required, for quickly acquiring, anal yzing and presenting data from data acquisition devices and inst rumentation. Signal Express can define measurement procedures by adding and configur ing different functions in an interactive measurement environment. Most of these functions process input signals and produce output signals, [11]. 2.8 NI PXI Chassis and Modules The National Instruments PXI-1045 is a high-performance 18-slot chassis designed for a wide range of test and meas urement applications. By programmatically configuring the trigger routing modules on the chassis backplan e, triggers can be routed between devices with ease. The wide operati ng temperature range of 0 to 55 C is ideal

PAGE 45

34 for extended-temperature environments. The Compact PCI-compatible chassis features a low-jitter 10 MHz reference clock for device synchroniza tion, [11]. The NI PXI 1045 18-slot chassis is pi ctured in Figure 9. Figure 9: NI PXI 1045 18-Slot Chassis The National Instruments PXI-8105 is hi gh-performance Intel Core Duo T2500based embedded controller for use in PXI and Compact PCI systems. This embedded controller, with its 2.0 GHz dual-core processor and dualchannel 667 MHz DDR2 memory, is ideal for applications requiring in tensive analysis or system development. The dual-core processor feature is advantag eous in multitasking environments such as Windows XP where multiple applications ca n be running simultaneou sly, [11]. The PXI8105 embedded controller is pictured in Figure 10.

PAGE 46

35 Figure 10: NI PXI 8105 Embedded Controller for PXI The National Instruments PXI-6534 is a hi gh-speed, 32-bit, parallel digital 5V TTL/CMOS I/O interface. It performs pattern I/O and high-speed data transfer using a wide range of handshaking pr otocols at speeds of 20, 40, 60 and 100 MB/s. The NI PXI6534 delivers digital I/O coupled with large onboard memory. It features user-defined power-up states, start and st op triggering, pattern matching, and change detection. The 32 lines can be operated as indi vidually configurable single-li ne I/O or as 8, 16, or 32-bit ports for pattern I/O and hands haking, [11]. The PXI-6534 dig ital I/O module is pictured in Figure 11.

PAGE 47

36 Figure 11: PXI 6534 Digital Input/Output Module The National Instruments PXI-4130 PXI source measure unit, (SMU), is a programmable high power source measure unit in a single slot. The NI PXI-4130 has a single isolated SMU channel, which offers a four-quadrant 20 V output incorporating remote four-wire sense. This channel is ca pable of sourcing up to 40 watts in quadrants I and III and sinking up to 10 watts in quadrants II and IV. With five current ranges, providing measurement resolution down to 1 nA, this precision source was ideal for the validation of semiconductor test applicatio ns developed during this research, [11]. The PXI-4130 module also includes a utility channel, which can source either current or voltage with 16-bit set-point and m easurement resolution. It can be used as an output, which provides up to 6 V and 1 A, a nd as a complementary power source to the SMU channel. Both channels of this SMU m odule can act as either a constant voltage source or a constant current source with a se ttable compliance limit for either mode. The PXI 4130 Power Source Measurement Un it is pictured in Figure 12.

PAGE 48

37 Figure 12: PXI 4130 Power Source Measurement Unit The National Instruments PXI-2535 high-dens ity field effect transistor, (FET), switch matrix module features 544 crosspoint s in a compact, single-slot 3U PXI form factor. The NI PXI-2535 is configured as a 4x136 one-wire matrix. The module uses field effect transistor, (FET), switch technology. Therefore, it offers unique benefits such as unlimited switch lifetime, unlimited simultaneous connections and switching speeds as high as 50,000 crosspoints/s. These features make this switch matrix module ideal for routing low-power DC signals in validation test systems of mass produced devices such as semiconductor chips and printed circuit boards. The PXI-2535 breaks out switch connections into three VHDCI connectors. The upper left and right connectors mate with the 136 columns on the switch while the lower left connector mates with the four rows. Th e lower right connector, which also connects to the rows, is meant for matrix expans ion, [11]. The Nationa l Instruments PXI-2535 crosspoint switch matrix is pictured in Figure 13.

PAGE 49

38 Figure 13: PXI 2535 128-Cro sspoint Matrix Switch

PAGE 50

39 Chapter 3 Design and Implementation 3.1 Semiconductor Test The software-defined semiconductor valida tion test system developed during this research is intended to perform Open and S hort Circuit Tests. The test system was designed to check for faults in the protection diode circuitry of semiconductor chips. The design of the system was concerned with both hardware and software components. The system hardware consists of a source measure unit and a high-density switching matrix. Signals from individual pins, on the device under test, are routed sequentially to the SMU th rough the switching matrix. The system software is composed of switching, source and measure and test management modules. The switching software configures the highdensity switch matrix for stimulus and measurements by making appropriate connections. The source and measure software programs the SMU and synchr onizes it with the switching software to sequentially test the pins on th e DUT. All code is incorporat ed into the test management software, which provides a scalable framew ork for easily adding supplementary tests.

PAGE 51

40 3.2 Hardware Components Semiconductor validation is generally segm ented into structural and functional arenas. Structural tests ensure that th e chip was built correctly. Functional tests determine whether the chip meets design specif ications and performs as intended in its final environment. Open and Short Circuit Test checks for fa ults in the diode protection circuitry of Integrated Circuits. Therefore, these tests are associated with the structural arena. There are two protection diodes fo r each pin of a CMOS semiconductor device. The diode protection circuitry for the input and output pi ns of a CMOS semiconductor device are presented sche matically in Figure 14. Figure 14: Internal Circuitry of a CMOS Chip The first diode is placed between the signal pin and the supply voltage pin, (VDD), and the second diode is placed between the signal pin and ground pin, (VSS), for the chip. Testing each pin on the diodes is performed using the source measure unit and scaled to multiple pins using switching hard ware. The protection circuitry for every pin is tested by forcing a current through each diode and measuring the resulting voltage

PAGE 52

41 using the SMU. The voltage measurement is compared with a predefined value to determine the presence of open and short circu its in the circuit. Switching hardware is used in order to automate the making and br eaking of connections, which are required for testing each individual pin. In order to c onnect the switching hardware to the SMU and individual pins of the chi p, a cable and screw-terminal block is also necessary. The implementation of Open and Short Ci rcuit Integrated Circuit Tests requires the hardware listed in Table 1, which wa s explained in detail in chapter 2. Table 1: Required Hardware Components for Open and Short Circuit Tests in PXI Component Model Name Description PXI Chassis PXI-1045 18-Slot 3U PXI Chassis with Universal AC Power Supply PXI Controller PXI-8105 2.0 GHz Dual-Core PXI Embedded Controller SMU PXI-4130 Source Measure Unit Switch PXI-2535 544-crosspoint FET Matrix Switch Switch Cable SCH68-68 68-pin VHDCI to SCSI cable Switch Terminal Block TBX-68 68-pi n external screw-terminal block The PXI platform is inherently suited for Open and Short Circuit Tests. Its modular architecture facilitates scalability a nd flexibility. Incorporating additional test points is as easy as adding a switch module in an available slot. Reducing test time is also possible by simply adding an SMU and conducting parallel measurements. The Open and Short Circuit Test System, designed during this research was architected in PXI

PAGE 53

42 using the PXI-1045 18-slot chassis and the PXI-8105 2.0 GHz Dual-core embedded controller. This Open and Short Circuit Test system was designed to test the protection diodes on the 128 pins of a single chip. Th e two main components of test system consisted of the PXI-4130 Source Measure Unit and the PXI-2535 544 crosspoint switch matrix. Other important components of this test system included cables and connector blocks, which facilitated signal connections to the switch. Connections to the PXI-2535 were made using an external connector block and VHDCI cables. PXI-2535 signal connection possibilities are pictured in Figure 15. Figure 15: Connecting Signals to the PXI-2535 The top two connectors on the PXI-2535 4x136 switch matrix were used for the 136 column connections. Two VHDCI cables and two TBX-68 terminal blocks were required in order to connect to all 136 column s. The bottom left connector was used to connect signals to rows. One VHDCI cable and one TBX-68 terminal block was required in order to connect signals to rows.

PAGE 54

43 The bottom right connector also provides access to the rows of the matrix module and facilitates matrix expansion. Building large matrices with the PXI-2535 is very simple and can be accomplished by connec ting the bottom right connectors of two modules using a VHDCI cable. Figure 16: Building a 4x272 Matrix Using Two PXI-2535 FET Matrix Modules 3.3 Software Components The software for the Open and Short Circ uit Test System was developed using NI LabVIEW and NI Switch Executive. LabVIE W was used as the primary application development environment while switch execu tive was used to conf igure routes on the high-density matrix module. Table 2: Required Software Components for Open and Short Circuit Tests in PXI Component Description NI LabVIEW 8.5 Graphical Application Development Environment Switch Executive 2.1 Switch Management Software

PAGE 55

44 The NI DC-Power, which is the SMU driv er software, and the switch executive possess intuitive APIs for LabVIEW. These APIs offer high-level programming tools for quick deployment of hardware as well as low-level functions for greater control. The NI DC-Power and NI Switch Executive AP Is are presented in Figure 17. Figure 17: NI-DCPower and NI Sw itch Executive APIs for LabVIEW The presentation and reporting features of LabVIEW are a major component of why the application development environment, ( ADE), is so well suited for test software development. LabVIEW contains multiple gr aphs, charts, meters, knobs and switches, in both 2D and 3D, in order to f acilitate the representation of measurement data graphically. The ADE also includes the LabVIEW Report Generation Toolkit, which facilitates the creation of reports in Microsoft Word and Excel format. In this Open and Short Circuit Test System, LabVIEWs powerful graphical user interface was used to develop an intuitive front panel. The LabVIEW front panel is presented in Figure 18. The upper

PAGE 56

45 block of the front panel was used to confi gure the SMU and switch while the lower block presents test results in a graphical manner. Figure 18: Front Panel fo r Open and Short Circuit Test System Created in LabVIEW Open and Short Circuit Test Systems of ten require the ability to connect to hundreds of test points. This is accomplished by configurin g the switch matrix in to different states. NI Switch Executive is th e intelligent switch ma nagement and routing application, which renders simple this co mplex task. With Switch Executive, the development productivity is increased by in teractively configur ing and naming switch modules, external connections a nd signal routes. Switch Execu tive can also increase test code reuse and system performance with switch programming in conjunction with National Instruments TestStand, La bVIEW and Measurement Studio.

PAGE 57

46 The switch hardware in the Open and Shor t Circuit Test System was deployed in two steps using Switch Executive. First, a Switch Executive “virtual device” was created. Next, the VI was deployed usi ng the Switch Executive API in LabVIEW. With NI Switch Executive alias names can be created and unique comments can be added for each channel. This capability greatly simplifies the management of hundreds or thousands of switch channels in large switch systems since the designer can refer to a channel as "SMU" or "Pin_0" instead of "c0" or "c2". Alias construction with NI Switch Executive is illustrated in Figure 19. Figure 19: Creating Channel Aliases in Switch Executive

PAGE 58

47 Once all the required channels have been configured, Switch Executive provides an interactive utility to assist the designer in connecting pairs of channels to form routes. The interface to this capability is presented in Figure 20. Figure 20: Switch Executive Interactive Switch Configuration Using the Interactive Switch utility, two channels are se lected to be connected from the list of alias channel names or full channel names. Then Switch Executive recommends an available route based on the previously specified channel and hardwire information. After the route has been selecte d, designers can name it using an alias name for quick reference in test software program s. For example, the route to connect the SMU to each pin on the DUT was given the alias ‘SMU_DUT_n’, where ‘n’ is the pin number. Similarly, the route group, which connects all pins to ground, was named ‘GND to DUT’. The ability to connect and disconnect individual routes and route groups facilitates the deployment of complex tests su ch as those for detecting open and short circuits. For example, to test for open and/ or short circuits on pin ‘n’, the route group ‘GND to DUT’ is connected. This route gr oup connects the ground terminal to all pins

PAGE 59

48 on the chip. Next, the route ‘GND_ DUT_n’ is disconnected keeping ‘SMU_DUT_n’ connected. The process of programmatically deploying the Switch Executive ‘Virtual Device’ was performed using the Switch Execu tive API in LabVIEW. The process is depicted in Figure 21. Figure 21: Deploying a Switch Execu tive ‘Virtual Device’ in LabVIEW 3.4 Open and Short Circuit Testing Design Structural tests on Integrated circuits can quickly identify those, which were not built correctly. Each pin has a network of protection diodes and CMOS transistors. CMOS transistors on each input pin act like switches by allowing current to flow from VDD into the DUT circuitry and from the DUT circuitry to VSS. CMOS transistors can be damaged if an over-voltage condi tion is induced at an input or output pin. To protect these devices, two diodes are pl aced at each signal pin. The fi rst sits between the signal pin and VDD and the second between the signal pin and VSS. If a positive overvolta ge greater than VDD is applied on any pin, the VDD diode becomes forward-biased and allows current to flow between the signal pin and VDD. Similarly, if a negative ov ervoltage greater than VSS is applied on any pin, the VSS diode becomes forward-biased and allo ws current to flow between VSS and the signal pin. This

PAGE 60

49 arrangement of protection diodes prevents damage to the CMOS transistors and DUT circuitry in overvolta ge conditions. The VDD and VSS protection diodes must be tested for open and short conditions to ensure pr oper operation. An open circuit condition can occur if a protection diode is missing or is functioning incorrectly. A short circuit condition can occur if a direct conne ction exists in areas such as: Between the signal pin and VDD, Between the signal pin and VSS, Between one signal pin a nd another signal pin. Each of these short-circuit failure modes prevent correct operation of the device. Open and Short Circuit Tests check fo r all the failure modes considered. It is important to recall that CMOS integrated circuits are based on FET technology. Therefore, they use the VDD and VSS terminology for positive supply voltage and negative supply voltage, which is often re ferred to as ground. These terminals can also be documented as VCC and Gnd. 3.4.1 Test Setup The test set up for open and short circuits is separated into three phases. Phase one is concerned with testing the VDD protection diode. Phase two is concerned with testing the VSS protection diode. Phase thre e generates the test report. 3.4.2 Testing the VDD Protection Diode The test setup consists of connecting VSS, VDD and all other signal pins to SMU ground. In order to detect an open or short across the VDD protection diode of a signal

PAGE 61

50 pin a minimal current, (i.e. 100 A), is sent into the signal pin. If the VDD protection diode operates correctly it will become forwar d-biased and the current will flow between the signal pin and VDD. The VDD protection diode test is depicted in Figure 22. Figure 22: Testing the VDD Diode Measuring the voltage drop across the forward-biased VDD diode can determine if it is working correctly. If the voltage m easured between the signal pin and ground is close to 0 V, which is ground, then one or more short-circuits exist between the signal pin and ground through VSS, VDD, and/or another signal pin. If the voltage measured between the signal pin climbs to a potential, which is higher than an acceptable forwardbiased voltage drop, then there is an open circuit between the si gnal pin and ground. If the measured voltage is an acceptabl e forward-biased voltage drop the VDD protection diode is operating correctly. Ta ble 3 presents an example of VDD protection diode test results and the resulting pass/fail specifications.

PAGE 62

51 Table 3: VDD Protection Diode Test Specifications Voltage Reading at Signal Pin Test Result Less than +0.2 V Fail: Shorted In between +0.2 V and +1.5 V Pass Greater than +1.5 V Fail: Open The voltage between the signals pin a nd ground should be close to 0 V if the diode is shorted and the test result should i ndicate Fail: Shorted. However, if the other signal pins are not all grounded and the diode is shorted current would still flow through the forward-biased VDD protection diode, as depicted in Figure 23, and the test result would be pass. No current, other than a sm all amount of leakage current, should flow through the VSS protection diode during this test since it will be re verse-biased. Also, the acceptable forward-bias voltage drop is t ypically dependent upon the material from which the semiconductor diode is fabricate d. However, manufacturing techniques may also be used to lower the forward-biased voltage drop. The forwar d-biased voltage drop of a silicon diode is generally accepted to be 0.65 V. The exact voltage drop is dependent on the magnitude of the current flowing thr ough the diode’s p-n junc tion, the temperature of the junction and several physical constant s. The relationship between the forwardbiased voltage drop, the applie d current and the associated variables is commonly known as the diode equation, which is given by:

PAGE 63

52 The variables in the diode equation are: ID = Diode current, (mA), IS = Saturation current, (mA), VD = Voltage drop across the diode, (V), N = Ideality coefficient, between 1 and 2, Vt = Thermal voltage (V), approximately 25.85 mV at room temperature. 3.4.3 Testing the VSS Protection Diode The process for testing the VSS diode is the same as that for testing the VDD diode. All pins including VSS and VDD are connected to SMU ground. However, for the VSS diode a negative current of the same value, (i.e. -100 A), is sent into the signal pin. If the VSS protection diode operates correctly, it wi ll become forward-biased and current will flow between VSS and the signal pin. The VSS protection diode test is depicted in Figure 23. Figure 23: Testing the VSS Diode

PAGE 64

53 No current other than a small amount of leakage current should flow through the VDD protection diode since it will be reverse-biased Like the VDD diode case, measuring the voltage drop across the forward-biased VSS diode can determine if it is functioning properly. Table 4 presents the test parameters for the VSS protection diode. Table 4: VSS Diode Test Specifications Voltage Reading at Signal Pin Test Result Greater than -0.2 V Fail: Shorted In between -0.2 V and -1.5 V Pass Less than -1.5 V Fail: Open 3.4.4 Generation of the Test Report The report section collects all th e values measured during the VDD and VSS tests and places them together in a predefined format. Report layout includes customers’ name, purchase order number, part number, manu facturer and job number. The last part of the report includes a list of all the equipment used during th e test. Figure 24 presents the VI front panel for the test report. The graphical displays present the measured data as bar graphs and the tables tabulate the corre sponding voltages measured at each pin. A sample test report, generated during this research, is presented in appendix A.

PAGE 65

54 Figure 24: VI Front Pa nel for the Test Report 3.5 Automated Test Setup An external switching system front e nd and programmable source measure unit can be utilized to automate the VDD and VSS protection diode testing. The switching system can scan through pre-configured states and create the requi red current and ground paths to the VDD, VSS and signal pins of the semiconductor device. The source measure unit can send the required currents and measur e the resulting voltage s from each signal pin to ground. The setup for automate d testing is presen ted in Figure 25.

PAGE 66

55 Figure 25: Automated Open a nd Short Circuit Test Setup In order to connect the SMU to th e DUT through the FET switch, a matrix topology was used with pins from the SMU c onnected to rows in the matrix and pins from the chip connected to columns. Thes e connections are illu strated in Figure 26. Figure 26: Connecti ng the SMU and DUT Grounding all pins on the DUT was accomplished by closing all the connections on the matrix that route the ground of th e PXI-4130 SMU to the pins on the DUT. Connections from the PXI-4130 SMU Low pin to VDD and VSS were established directly

PAGE 67

56 through a cable instead of through the switch since the VDD and VSS pins are always connected to the SMU Low pin. The matrix switch was used for physically connecting all signal pins initially to ground and then each pin was sequentially tested using the SMU measurement channel. It was important to connect VSS and VDD to ground. In addition, all other signal pins were connected to ground before tes ting the protection diodes could proceed. Grounding all the signal pins ensured that shor t-circuits were properly detected. The need to ground all pins is illustrated in Fi gure 27. When a short-circuit is detected between two signal pins, the voltage between the pin under test and SMU low should be close to zero volts as presented in Tables 3 a nd 4. If the other si gnal pins were not all grounded, current would still flow through the forward-biased VDD protection diode and the test result would be Pass instead of Fail. This situation is depicted in Figure 27 Figure 27: Grounding Pins is Essen tial for Detecting Short Circuit In order to limit the voltage produced during open circuit conditions, an upper limit voltage clamp was set on the SMU in order to prevent permanent damage to the

PAGE 68

57 DUT. The voltage clamp level on the PXI-4130 is software programmable to 3 Volts as per most CMOS IC specifications. The SMU forces 100 A of current into the diode and measures the resulting voltage. For this test, a voltage of appr oximately 0.65 V is expected, which is the voltage drop across a forward-biased silic on diode. The voltage resulting from the current was measured and then compared to the test specification tables in order to complete the failure analysis test. The software for the Open and Short Circuit Test System developed during this research was created using NI LabVIEW and NI Switch Executive. LabVIEW was used as the primary Application Development E nvironment while Switch Executive was used to configure routes on the high-density matrix. The Open and Short Circuit Tests were separated into thr ee test procedures: Testing the VDD protection diode Testing the VSS protection diode Generating the test report. The first two procedures were performed using the same hardwire connections. Depending on the procedure, the forcing cu rrent can be programmed to change in direction. In addition the forced current can also change its step resolution at the SMU. Due to the similarities, between procedures ‘a ’ and ‘b’, only the procedure for testing the VSS protection diode will be describe d. The procedure for testing the VSS protection diodes is outlined in Figure 28.

PAGE 69

58 Disconnect all signal pins from switching hardware and close the NISE session handle Disable and close the SMU session handle Initialize, configure and enable the output of the SMU Initialize the switching matrix and connect all DUT pins to ground Switching through DUT signal pins Disconnect the SMU from the signal pin under test Analysis on measurements to determine test results Measure the voltage between the signal pin under test and ground Enable current forcing source and set current incremental ste p s Connect the measurement channel of the SMU to the si g nal p in under test Disconnect the signal pin under test from g roun d Reconnect the signal pin under test to ground Figure 28: VSS Protection Diode Testing Procedure

PAGE 70

59 A detailed description of the steps of th e test procedure outlin ed in Figure 28 is presented including their respec tive LabVIEW block diagrams. 3.5.1 Initialize the SMU, Configure and Enable the Output of the SMU The SMUs’ resource name is provided to the Initialize VI to initialize the SMU and to provide a SMU session handle. The SMU session handle is passed to all subsequent NI-DCPower VIs. Next, channel 1 of the SMU is configured for the DC Current, which it will be sourcing during conduct of the test. The NI-DCPower configuration VIs can be wired in any order as long as all th e parameters are set before the SMU output is enabled. The required parame ters include the current level, the current level range, the voltage limit and the voltage limit range. The step following the Initi alize VI is the NI-DCPower property node. This step instructs the SMU to automatically determ ine and set current level and voltage limit ranges based on the current level and voltage limit inputs. The VI following the property node confirms that the SMU is to be used in DC Current mode. Next, the current level is set to -100 A. In order to test the VSS protection diode, channel 1 is configured such that the current flows into the SMU, the VSS protection diode is forward-biased and the voltage limit set to 3 V, (equivalent to 3 V). A “true” Boolean constant is used to enable the SMU output. A block diagram for th is procedure step is presented in Figure 29.

PAGE 71

60 Figure 29: Initializing, Conf iguring, and Enabling the SMU 3.5.2 Initialize the Switching Hardware and Connect DUT Pins to Ground This procedure step initializes the switchi ng hardware and sets it to a state where VDD, VSS and all the DUT’s signal pins are connected to ground. There are multiple ways to control switches using LabVIEW. Howe ver, the best way to program switching hardware, as a system, is with the NI Switch Executive API. Figure 30 presents an image of the block diagram code for this procedure step. Figure 30: Initialize the Switching Module and Connect the DUT Pins to Ground The NISE Virtual Device Name is placed in the input of the Open Session VI for opening the session, which handles all the switches in the system. NI Switch Executive

PAGE 72

61 stores this session in one NISE session handle, which is passed to all subsequent NISE VIs. The ‘Disconnect All’ VI disconn ects all connections on every switch device managed by the NI Switch Executive session. This action sets the switch system configuration in a known state where no switch routes are conn ected. Then all routes in the GND to DUT route group are connected, wh ich results in the switching hardware being set to a state where VDD, VSS and all the DUT’s signal pins are connected to ground. 3.5.3 Switching Through the Signal Pins Switching through the signal pins is impleme nted using a ‘For Loop’ structure. The NI Switch Executive VIs were used within this structure to disconnect the signal pin under test from ground before connecting it to channel 1 of the SMU. Then, the ‘NIDCPower VI’ was used to measure the vo ltage from each DUT signal pin to ground. Before the next iteration, the signal pin wa s disconnected from channel 1 and connected back to ground. These activities are depicted in Figure 31.

PAGE 73

62 Figure 31: Disconnect GND, Connect SMU, Measure, Disconnect SMU, and Reconnect GND The process of accessing DUT signal pins was performed using route groups, which were created in the NI Switch Executive. Route Groups were used to put the switch matrix into a desired state. The fi rst route group contained routes connecting the DUT signal pins to ground. The second r oute group contained r outes connecting the DUT signal pins to channel 1 of the SMU. Table 5 presents the makeup of the route groups. Table 5: Set up Route Groups to Simplify Indexing the Correct DUT Signal Pin Route group 1 Route group 2 Index 0 DUT_Signal_Pin0_to_GND DUT_Signal_Pin0_to_SMU_Channel1 Index 1 DUT_Signal_Pin1_to_GND DUT_Signal_Pin1_to_SMU_Channel1 Index 2 DUT_Signal_Pin2_to_GND DUT_Signal_Pin2_to_SMU_Channel1 Index 3 DUT_Signal_Pin3_to_GND DUT_Signal_Pin3_to_SMU_Channel1

PAGE 74

63 The NI Switch Executive configura tion API in LabVIEW provides full programmatic access to all NI Switch Execu tive features. It was used to extract individual route names from all route groups. The result was two string arrays comprised of the routes from Route Group 1 and Route Group 2. The arrays are listed in Figure 32. Figure 32: Array Output Using NI Switch Executive Configuration API Passing these arrays into a ‘For Loop’ automatically indexed the arrays. For example, on the first iterati on of the loop, the indexed routes to be connected and disconnected inside the loop were DUT_Signal_Pin0_to_GND and DUT_Signal_Pin0_to_SMU_Channel1. On the s econd iteration of the loop, the indexed routes were DUT_Signa l_Pin1_to_GND and DUT_Signal_Pin1_to_SMU_Channel1. This iteration continued until the arrays indexed each route. Based on the pass and fail criteria of th e DUT, the voltage measurement indicates if the VSS protection diode on the signal pin under test passed, failed open, or failed due to a short-circuit. The determination of th e test results is illustrated in Figure 33.

PAGE 75

64 Figure 33: Determine Test Result Based on the Voltage Measurement 3.5.4 Disable and Close the SMU Session Handle The NI-DCPower VIs were used to disa ble the output of the SMU and close the SMU session handle. Figure 34 displays an image of the block diagram code for this procedure step. Figure 34: Disable the SMU Output and Close the SMU Session Handle A Boolean ‘False’ constant was connected to the ‘Configure Output Enabled VI’, which disabled the output of the SMU. Therefore, the current flow of -100 A was turned-off. The ‘ Close VI’ closed the SMU session handle and reallocated the SMU resources to default values.

PAGE 76

65 3.5.5 Disconnect All Signal Pins from th e Switching Hardware and Close the NISE Session Handle NI Switch Executive VIs were used to disconnect VDD, VSS and the signal pins from the switching hardware and close the NI SE session handle. Fi gure 35 displays an image of the block diagram code. Figure 35: Disconnect all Signal Pins and Close the NISE Session Handle The ‘Disconnect All VI’ disconnects a ll connections on every switch device managed by the NI Switch Executive session. This action sets the switch system configuration to a known state where no switch routes are conn ected. The ’Close Session VI’ closes session handles to a ll the switches in the system. Although not required, it is often helpful to include an error handler. In case an error occurs, the VI returns a description of the error and optionally displays a dialog box with the error information. 3.5.6 Testing the VDD Protection Diode To modify the VSS protection diode test, the SMU mu st first be disabled. Then the current polarity must be changed from -100 A to +100 A on channel before reenabling the SMU. The ‘For Loop’ structure is used to perform the same test sequences to generate the test VDD protection diode test report.

PAGE 77

66 3.5.7 Combining the VSS and VDD Protection Diode Tests and Report Generation Procedure Three independent VIs were created. One VI was used for testing the VDD protection diode. A second VI was used for testing the VSS protection diode. A third VI was used for generating the test report. A f ourth VI was created to combine the three VIs in sequence. The fourth VI possessed the cap ability of performing all the functionality necessary to comply with all requirement s. After typing in test identification information, the EXECUTE button was pres sed to start the test sequence. VDD Test, VSS Test and Report indicators ch ange their color from gray to red indicating, which procedure is running. When the sequence of the program arrives at the report generation phase, a ’File Save as’ window appears where th e name of the report file is typed and the file location path is selected. The re port is generated in PDF file format. After test completion, the r unning time is displayed in the bottom right corner of the front panel. The run time is for refere nce purposes only and could be used by a test engineer to estimate total test ti me for a large number of DUTs.

PAGE 78

67 The front panel of the fourth VI is presented in Figure 36. Figure 36: VI Front Panel for the Op en and Short Circuit Test System The block diagram of the fourth VI is presented in Figure 37.

PAGE 79

68 Figure 37: VI Block Diagram for the Open and Short Circuit Tests System

PAGE 80

69 Chapter 4 Testing and Verification 4.1 Results Using Interchangeable Virtual Instrume nts, (IVI), drivers for the PXI 4130 SMU and the PXI 2530 switch matrix, it was possible to emulate th e behavior of the system before wiring the DUTs to the modules and to terminal blocks. Simulation of these two instruments allowed the switch gr oup routes and the SMU terminals to be validated. This simulation guaranteed that there were no short circuits between the routed signals. Also, it was important to recall the NI Switch Execu tive software to validate routes according to the conditionals set by the designer. In order to run the emulation, a small change of the VDD and VSS test VIs was required. Recall that the ‘NI-DCPower Measur e’ function measures the voltage on each pin. Then the value is compared within the Fail Open and Fail Short limits specified in the front panel. Figure 38 presents a secti on of the original block diagram of the ‘NIDCPower Measure’ function. Given that th e instruments are driver simulated, the voltages values need to be generated. This can be accomplished by replacing the ‘NIDCPower Measure’ function by the ‘Random Number’ function. The ‘Random Number’ function is illustrated in Figure 39. The ‘Random Numbe r’ function generates numbers

PAGE 81

70 randomly between 0.0 and 1.0. Since the open an d short circuit test limits are between 0.2 and 1.5, respectively, a scale fact or of +/1.7 was incorporated. Figure 38: NI-DCPower Measure Function Figure 39: Generation of Random Voltage Values

PAGE 82

71 After completing the changes to the original VI, mentioned previously, a series of Open and Short Circuit Tests were performed and recorded different execution times. The average time obtained was 14.649 seconds for eleven test runs. Figure 40 graphically presents the different va lues achieved during each execution. Figure 40: System Execution Time Results Due to the modularity of the system design, VDD Test and VSS Test could be run separately. Therefore, execution times for th ese two VIs were obtai ned independently for analysis. The VDD test execution time results are presen ted graphically in Figure 41. The VSS test execution time results are presented graphically in Figure 42. The average times for the VDD and VSS protection diode tests were 3.655 seconds and 3.138 seconds, respectively. The same numb ers of test runs were executed, which yielded approximately 0.0265 seconds per pin. The time required for a test engineer to manually test each pin using a non-automated te st system is approximately 1.48 seconds 13 13.5 14 14.5 15 15.5 16 1234567891011 14.9374 15.71865 13.9999 14.4687 14.6248 14.4062 14.2967 14.6249 14.6874 14.7968 14.578 Time (sec) Number of TestsSystem Execution Time

PAGE 83

72 per pin. The advantage of a software-defined instrumentation based test system is clear. It is important to mention that the1.48 sec onds per pin test time doe s not include the time for data logging the results and making the test report. Figure 41: VDD Test Execution Time Results Figure 42: VSS Test Execution Time Results 3.4 3.5 3.6 3.7 3.8 1234567891011 3.7031 3.6093 3.6875 3.6562 3.6718 3.6406 3.5937 3.6562 3.75 3.625 3.6093 Time (sec) Number of TestsVDDTest Execution Time 3 3.1 3.2 3.3 3.4 1234567891011 3.2968 3.1406 3.0937 3.125 3.0937 3.1406 3.0937 3.125 3.2031 3.125 3.0781 Time (sec) Number of TestsVSSTest Execution Time

PAGE 84

73 Table 6 presents the data for three diffe rent technicians on three different parts test using a curve tracer and manually test ing pin by pin. A comparison of the times listed in the table and the average time, ( 14.694 seconds), required by the Open and Short Circuit Test System clearly indicates the superior approach. The benefit of using software-defined instrumentation test system s are clearly superior to manual testing. Table 6: Test Times Using the Non-Automated Test System Part Number Description Pins Package Time (sec) QL5130 Programmable Logic Device 144 TQFP 188 ICS9148B04 Frequency Generator & Integrated Buffers 48 SSOP 90 UDP70325 Microcontroller 94 QFP 132

PAGE 85

74 Chapter 5 Conclusions and Future Work 5.1 Conclusions A Software-Defined Integrated Circuit Te st System was successfully developed for testing the CMOS ICs protection diode st ructure. Protection diode testing is an important part of a series of tests performe d for Failure Analysis, which help to detect damages and identify counterfeit ICs. Software-defined instrumentation is a vers atile approach for different applications and is the primary method curre ntly employed in automated test systems. PXI is the leading platform for developing many software-defined instruments for multidisciplinary applications. Due to the accessibility of di verse modules for this platform and the proposed system design approach, the design of test systems with complex systems requirements and functionality is becoming straightforward. The system engineering approach wa s used for designing the CMOS ICs protection diode test system structure. A ll the defined requirements were verified through the emulation process of the PXI modules. The featur e test system was divided into three small subsystems. The subsystems consisted of VDD diode test, VSS diode test and report generation. The test system wa s designed using a modular approach, which

PAGE 86

75 was implemented in three subsystems. This approach made the design flow easy to implement and verify. 5.2 Future Work Several functionalities were identified as possible future development areas for improving the test system. Improvement areas identified were found to be: Design a functional test for digital or mixed signal devices using the DIO module available in the PXI platform, Different test sequences should be used for testin g large number of parts, Develop test modules for RF tes ting for communication applications, Expand the capability of performing testing remotely.

PAGE 87

76 References [1] www.altera.com/end-markets/test-meas urements/test-products/ate/tes-ate.html [2] Athan, Stephan, “IDDQ Te stability of Deep Submicron CMOS Integrated Circuits”, University of South Florida. December, 1995 [3] en.wikipedia.org/wiki/main_page [4] www.incose.org [5] Mehendale, Vikram, “System Appr oach to Embedded System Design”, University of South Florida. April, 2007 [6] National Instruments, “Designing Next Generation Test Systems; an In-Depth Developers Guide” [7] PCI eXtensions for Instrumentation, Revision 2.2, PXI Systems Alliance, August 22, 2005 [8] Pickering Interfaces, “PXImate”, Fourth Edition, 2005 [9] Bisking, Kevin, “Softwar e-Defined Instrumentation” Design Magazine, August, 2008 [10] Humphrey, Rick, “Addressing Modern Mil-Aero RF Test Challenges with Modular Software Defined Test Syst ems”, COTS Journal, January, 2005 [11] www.ni.com [12] Sally J. F. Baron, Ph.D, “Change-out : A System of Systems Approach to COTS Management”, Sixth International IEEE Conference on Commercial-off-theShelf, (COTS), IEEE, 2007

PAGE 88

77 Appendices

PAGE 89

78 Appendix A: Open and Short Circuit Test System Report Open and Short Test Report for University of South Florida COMPANY: Abacus PURCHASE ORDER: 123456 JOB NUMBER: 12756 PART NUMBER: AD656 MANUF ACTURER: Analog Devices Vdd Measurement Vss Mesuarement Pin Value Status Value Status 0 0.187126 Short 1.119785 Pass 1 1.524439 Open 0.431643 Pass 2 0.577031 Pass 0.607497 Pass 3 0.805448 Pass 0.860666 Pass 4 0.432947 Pass 0.449302 Pass 5 0.102208 Short 0.736958 Pass 6 0.945887 Pass 0.263317 Pass 7 1.435655 Pass 1.659638 Open 8 1.682729 Open 1.614601 Open

PAGE 90

79 Appendix A (Continued) 9 1.166671 Pass 1.651084 Open 10 0.647581 Pass 0.340525 Pass 11 1.677161 Open 1.533502 Open 12 0.122543 Short 1.385024 Pass 13 0.357408 Pass 0.394095 Pass 14 1.182493 Pass 0.258710 Pass 15 1.343115 Pass 0.382751 Pass 16 0.601738 Pass 1.542001 Open 17 1.192540 Pass 0.548545 Pass 18 1.112865 Pass 1.523647 Open 19 1.649690 Open 1.569187 Open 20 1.142805 Pass 1.414294 Pass 21 0.432354 Pass 0.922331 Pass 22 0.791020 Pass 1.258069 Pass 23 0.382837 Pass 1.124609 Pass 24 0.861317 Pass 0.675634 Pass 25 0.180155 Short 1.078821 Pass 26 1.235588 Pass 0.439198 Pass 27 1.354221 Pass 1.427448 Pass 28 1.129196 Pass 0.888540 Pass 29 1.248231 Pass 1.606556 Open 30 0.466716 Pass 0.700830 Pass 31 0.047458 Short 1.695703 Open 32 0.162436 Short 1.671912 Open 33 0.980140 Pass 1.642306 Open 34 0.132179 Short 1.633050 Open 35 0.146708 Short 1.129255 Pass 36 .043155 Short 1.656370 Open 37 1.005788 Pass 1.466424 Pass 38 0.691093 Pass 1.693167 Open 39 1.518586 Open 0.374513 Pass 40 0.872069 Pass 0.406839 Pass 41 0.124659 Short 1.381942 Pass 42 0.058358 Short 0.177010 Short 43 1.286479 Pass 1.178606 Pass

PAGE 91

80 Appendix A (Continued) 44 0.117081 Short 0.256172 Pass 45 1.274879 Pass 1.360276 Pass 46 1.402936 Pass 0.847809 Pass 47 0.228714 Pass 0.369905 Pass 48 0.525161 Pass 1.181097 Pass 49 0.640141 Pass 1.550513 Open 50 1.323500 Pass 1.500063 Open 51 1.656221 Open 1.102876 Pass 52 0.942711 Pass 1.626993 Open 53 0.001086 Short 0.806499 Pass 54 0.574649 Pass 1.405907 Pass 55 1.199725 Pass 1.075051 Pass 56 0.447933 Pass 0.769696 Pass 57 0.171234 Short 0.154223 Short 58 1.245246 Pass 1.580868 Open 59 0.653812 Pass 0.203305 Pass 60 0.405995 Pass 0.499202 Pass 61 0.452557 Pass 0.253531 Pass 62 0.274412 Pass 1.089120 Pass 63 0.925508 Pass 1.387281 Pass 64 1.513428 Open 1.372787 Pass 65 0.923241 Pass 1.034993 Pass 66 1.222140 Pass 0.220205 Pass 67 1.396794 Pass 1.661005 Open 68 0.161699 Short 0.963521 Pass 69 1.460785 Pass 1.434476 Pass 70 1.231847 Pass 0.736539 Pass 71 0.870046 Pass 0.316153 Pass 72 1.590089 Open 0.554404 Pass 73 1.092615 Pass 0.984914 Pass 74 1.058062 Pass 1.266852 Pass 75 1.263365 Pass 0.790903 Pass 76 1.060462 Pass 1.290061 Pass 77 1.659684 Open 1.174182 Pass 78 1.049395 Pass 1.674798 Open 79 0.836322 Pass 1.200990 Pass 80 1.108909 Pass 0.352898 Pass

PAGE 92

81 Appendix A (Continued) 81 0.724420 Pass 1.453072 Pass 82 0.027815 Short 1.572945 Open 83 0.576465 Pass 0.187800 Short 84 1.605419 Open 0.281719 Pass 85 1.475880 Pass 0.440498 Pass 86 0.676584 Pass 0.856728 Pass 87 1.158302 Pass 1.032188 Pass 88 0.348097 Pass 0.258112 Pass 89 0.408434 Pass 0.617304 Pass 90 1.686674 Open 1.367849 Pass 91 1.120596 Pass 0.962751 Pass 92 1.687446 Open 0.507889 Pass 93 0.602361 Pass 0.122315 Short 94 1.020057 Pass 0.713826 Pass 95 0.608204 Pass 0.628230 Pass 96 1.488129 Pass 0.157910 Short 97 1.301591 Pass 1.699087 Open 98 0.086991 Short 0.016451 Short 99 0.053475 Short 1.693068 Open 100 0.101683 Short 0.500861 Pass 101 1.045759 Pass 0.330425 Pass 102 1.287201 Pass 0.247618 Pass 103 0.173470 Short 0.381635 Pass 104 0.330563 Pass 0.834305 Pass 105 0.821084 Pass 1.462698 Pass 106 0.333805 Pass 1.546624 Open 107 1.688960 Open 0.510436 Pass 108 0.102617 Short 1.690308 Open 109 0.299792 Pass 0.009033 Short 110 0.030264 Short 0.530117 Pass 111 0.164182 Short 0.986906 Pass 112 0.776102 Pass 0.165435 Short 113 0.863756 Pass 0.866064 Pass 114 0.107027 Short 0.902936 Pass 115 1.337861 Pass 1.095554 Pass 116 1.016959 Pass 1.001589 Pass 117 1.265560 Pass 0.349866 Pass

PAGE 93

82 Appendix A (Continued) 118 0.083394 Short 0.424164 Pass 119 0.876180 Pass 0.006515 Short 120 0.611386 Pass 0.248144 Pass 121 0.181871 Short 0.727131 Pass 122 0.659669 Pass 1.606379 Open 123 1.505025 Open 1.671724 Open 124 0.064656 Short 0.427799 Pass 125 0.844302 Pass 0.767644 Pass 126 0.275767 Pass 1.169666 Pass 127 0.539814 Pass 0.525704 Pass The test was run with the following test equipment: Control # 8854: PXI-8105 Embedded Computer Control # 8866: PXI-2530 FET Switch Matrix Control # 8856: PXI-4130 S uorce Measurement Unit Control # 1253: PXI-1045 PXI Chassis