Abstract:
A technique for controlling instrumentation in an automatic test system includes providing a group of hardware resources that can be configured in a variety of ways to realize different instrument configurations, which generally correspond to different traditional instrument types. An instrument driver is provided for each of the different instrument configurations, and calls to each instrument driver may be inserted into a test program for controlling the respective instrument configuration. The instrument drivers direct control of the hardware resources via a support driver. The support driver thus provides a central location through which control of the various hardware configurations is processed. From the user&#39;s point of view, the instrumentation is programmed as if it consists of a collection of traditional instrument types. But at the hardware level the instrumentation is highly integrated and efficiently realized.

Description:
CROSS-REFERENCES TO RELATED APPLICATIONS 
       [0001]    Not Applicable. 
       STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT 
       [0002]    Not Applicable. 
       NAMES OF PARTIES TO A JOINT RESEARCH AGREEMENT 
       [0003]    Not Applicable 
       REFERENCE TO A “SEQUENCE LISTING,” A TABLE, OR A COMPUTER PROGRAM LISTING APPENDIX 
       [0004]    Not Applicable. 
       BACKGROUND OF THE INVENTION 
       [0005]    1. Field of the Invention 
         [0006]    This invention relates generally to automatic test equipment for electronics, and, more particularly, to the control of instrumentation of automatic test equipment for interacting with devices under test. 
         [0007]    2. Description of Related Art 
         [0008]    Automatic test equipment, or “ATE,” is an integral part of electronics test and manufacturing. What began decades ago as collections of manually operated benchtop instruments has evolved into highly integrated systems optimized for precision, speed, and control. 
         [0009]      FIG. 1  shows an simplified example of a modern ATE system, or “tester.” The tester includes a host computer  110  that controls electronic subsystems  112 - 118 . The electronic subsystems are wired to an interconnect  120 , which selectively connects signals from the subsystems to a unit under test, or “WUT”  122 , under control of the host computer  110 . The WUT is generally a manufactured device or assembly, or a partially manufactured device or assembly, on which electronic testing may be conducted. 
         [0010]    The electronic subsystems may include, for example, a power subsystem  112 , a digital subsystem  114 , an analog subsystem  116 , and a microwave subsystem  118 . Each subsystem includes instruments. For example, the power subsystem  112  may include fixed power supplies ( 112   a  and  112   b ) as well as various user-programmable power supplies ( 112   c - 112   d ). The digital subsystem  114  may include digital drive/detect instruments ( 114   a - 114   b ) for sourcing digital signals to the WUT  122  and detecting the levels of digital signals produced by the UUT. It may also include a timing generator  114   c  and a pattern generator  114   d.  The analog subsystem  116  may include a parametric measurement unit (PMU)  116   a,  digitizer  116   b,  arbitrary waveform generator  116   c,  and timer/counter  116   d.  The microwave subsystem may include a continuous wave (CW) microwave synthesizer  118   a,  modulated wave synthesizer  118   b,  and multi-tone synthesizer  118   c,  as well as a microwave receiver  118   d.    
         [0011]    The interconnect  120  is generally an array of switches and connectors arranged for flexibly connecting the instruments of the subsystems  112 - 118  to different electronic nodes, or “pins,” of the WUT  122 . 
         [0012]    The host computer is the control center of the system. It is configured with computer software for creating and executing “test programs,” i.e., collections of user or machine-generated code for testing a UUT. The computer software includes a programming language as well as numerous instrument drivers. The programming language is sometimes a standard computer language, such as Microsoft Visual Basic™. Alternatively, the programming language may be proprietary to the ATE manufacturer, or a combination of standard and proprietary components. The instrument drivers are generally proprietary to the instrument manufacturers. 
         [0013]    The role of an instrument driver is to control an instrument. It can generally write to the instrument to configure and activate it and read from the instrument, for example, to determine measured results. The driver exposes one or more software functions to the test program. The test program generally accesses the driver via function or method calls inserted into the test program. 
         [0014]    An example of a tester programming language is VBT™, or “Visual Basic for Test,” which is used in the Flex™ line of testers produced by Teradyne, Inc. of North Reading Mass. VBT is a modified form of VBA™ (Visual Basic for Applications), and is accessed through a customized version of Microsoft Excel™, known as IG-XL™. Instrument drivers for IG-XL are provided as software modules accessible by a VBT test program. 
         [0015]    A longstanding organizing principle of ATE system architecture is to provide a three-way correspondence between instrument function, instrument assembly, and instrument driver. An instrument for performing any given function is generally housed in a physical assembly unique to that instrument and is controlled by a driver unique to that instrument. Different instrument functions are provided in different physical assemblies and are controlled by different drivers. 
         [0016]      FIG. 2  illustrates this correspondence. A test program  210  includes function calls to instrument drivers  212 ,  214 , and  216 . Each of these drivers controls a single instrument function. Instrument functions are provided in distinct instrument assemblies  222 ,  224 , and  226 . 
         [0017]    The three-way correspondence offers many benefits. It is simple to use. To control an instrument, a user simply makes one or more function calls to the instrument&#39;s driver. The driver&#39;s functions are generally a direct reflection of the instrument&#39;s capabilities. The three-way correspondence also avoids many hardware conflicts. Because each instrument is a separate assembly containing essentially all the hardware needed to achieve its functionality, the instrument can be configured over the full range of its functionality without concern about how other instruments in the system are configured or whether resources needed for certain functions are available. 
         [0018]    We have recognized that this organizing principle may not be optimal, however, particularly going forward. ATE manufacturers are engaged in continuing efforts to reduce costs, power, maintenance requirements, and the physical space occupied by instruments. An effective way of supporting these efforts is through integration of instrument hardware, where different instrument functions are combined on single, or smaller numbers of, assemblies. 
         [0019]    We have recognized, however, that instrument integration presents design challenges. These challenges essentially involve maintaining much of the simplicity of use and avoidance of hardware conflicts that the three-way correspondence provided. What is needed is an integrated instrument architecture that addresses these challenges. 
       BRIEF SUMMARY OF THE INVENTION 
       [0020]    In accordance with one embodiment, an architecture for controlling instrumentation for testing devices in an automatic test system includes a plurality of hardware resources. The hardware resources can be grouped and interconnected to form a plurality of instrument configurations, each corresponding to a particular instrument type for performing the functions of the respective instrument type. The architecture also includes a plurality of instrument drivers, one for each of the plurality of instrument configurations, and a support driver. The support driver is accessible by each of the plurality of instrument drivers and includes software for controlling the plurality of hardware resources. 
         [0021]    In accordance with another embodiment, an architecture for controlling microwave instrumentation in an automatic test system includes a plurality of microwave testing resources. The microwave testing resources can be grouped and interconnected to form a plurality of instrument configurations, each corresponding to a particular microwave sourcing instrument. The architecture further includes a plurality of instrument drivers, one for each of the plurality of instrument configurations, and a support driver. The support driver is operatively disposed between each of the plurality of instrument drivers and the plurality of microwave testing resources, for controlling the plurality of microwave testing resources in response to direction from the plurality of instrument drivers. 
         [0022]    In accordance with yet another embodiment, a method of controlling instrumentation in an automatic test system includes providing a plurality of hardware resources and configuring the plurality of hardware resources for realizing a plurality of instrument configurations. The method further includes controlling the plurality of hardware resources using a support driver and invoking the support driver from a plurality of instrument drivers, wherein a different instrument driver is provided for each of the plurality of instrument configurations. 
     
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 
         [0023]      FIG. 1  is a block diagram of the architecture of an ATE system according to the prior art; 
           [0024]      FIG. 2  is a block diagram of an arrangement of drivers and instruments according to the prior art; 
           [0025]      FIG. 3  is a block diagram showing an arrangement for controlling instrument resources according to an embodiment of the invention; 
           [0026]      FIG. 4  is a block diagram showing a variant on the arrangement of  FIG. 3 ; 
           [0027]      FIG. 5  is a block diagram showing an example of microwave instrument resources that can be controlled according to the arrangement(s) of  FIG. 3  and/or  4 ; 
           [0028]      FIG. 6  is a simplified schematic that shows an example of front end circuitry of  FIG. 5 , configured for providing continuous wave (CW) or modulated wave output signals; 
           [0029]      FIG. 7  is a simplified schematic showing a pair of front-end circuitry configured for providing multi-tone output signals; 
           [0030]      FIG. 8  is a block diagram of drivers for controlling the microwave instrument resources of  FIGS. 5-7 , including a support driver; and 
           [0031]      FIG. 9  is a block diagram showing an arrangement of software classes for implementing the support driver of  FIG. 8 . 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0032]    As used throughout this document, words such as “comprising,” “including,” and “having” are intended to set forth certain items, steps, elements, or aspects of something in an open-ended fashion. Unless a specific statement is made to the contrary, these words do not indicate a closed list to which additional things cannot be added. 
         [0033]      FIG. 3  shows an illustrative embodiment of the invention. Like the architecture shown in  FIG. 2 , the embodiment shown in  FIG. 3  includes a test program  310  for testing a unit under test, or UUT,  390  via an interconnect  380 . The elements  310 ,  380 , and  390  operate essentially as described above. However, in contrast with the prior art, which shows discrete instrument types  222 ,  224 , and  226 ,  FIG. 3  shows a collection of hardware resources  330 . Five hardware resources are shown, i.e., resources  342 ,  346 ,  350 ,  354 , and  358 . The resources  330  can be grouped and configured in a variety of ways to provide different instrument configurations. Each instrument configuration corresponds to an interconnected grouping of hardware resources. For example, a first instrument configuration  370  can be formed from the hardware resources  342  and  346 . A second instrument configuration  372  can be formed from hardware resources  346 ,  350 , and  354 , and a third instrument configuration  374  can be formed from hardware resources  350 ,  354 , and  358 . Each of these instrument configurations  370 ,  372 , and  374  performs a particular instrument function, and in effect forms a realization of an instrument type, similar to instrument types  222 ,  224 , and  226  found in the prior art. 
         [0034]    Each instrument configuration  370 ,  372 , or  374  is associated with a different instrument driver. For instance, configuration  370  is associated with a driver  312 , configuration  372  is associated with a driver  314 , and configuration  374  is associated with a driver  316 . The drivers  312 ,  314 , and  316  are similar to the drivers  212 ,  214 , and  216  of the prior art to the extent that they can be accessed by the test program for operating respective instrument types. They differ, however, in the scope of their functions. 
         [0035]    A support driver  320  is operatively connected between the instrument drivers  312 ,  314 , and  316  and the hardware resources  330 . The support driver  320  controls the hardware resources, and the instrument drivers  312 ,  314 , and  316  access the support driver  320  for effecting this control. 
         [0036]    Optionally, a hardware abstraction layer (HAL)  322  is operatively disposed between the support driver  320  and the hardware resources  330  for providing an interface between software and hardware. In addition, each hardware resource  342 ,  346 ,  350 ,  354 , and  358  may optionally be provided with a corresponding resource driver ( 344 ,  348 ,  352 ,  356 , and  360 , respectively). Each resource driver performs low-level reading and writing of the respective hardware resource, in response to direction from the support driver  320 , optionally via the HAL  322 . 
         [0037]    The term “operatively connected” is used herein to describe pathways of communication and/or control that are available to different software elements. It is understood that different software elements are not “connected” in the usual physical sense. Rather, when operating in a computer-controlled environment, they interact through data structures, function calls, software classes, or other software constructs. The term “operatively connected” thus suggests a pathway for data communication and/or control. In a similar manner, software elements may be “operatively disposed” in certain described ways. It should be understood that the physical location of the software code is not what is being described, but rather the logical position of the software element with respect to data flow and/or control. Operative connections need not be direct. Therefore, two software elements can be “operatively connected” even when a third element is “operatively disposed” between them. 
         [0038]    The embodiment of  FIG. 3  operates essentially as follows. The test program  310  contains encoded instructions for conducting various electronic tests on the UUT  390 . These instructions include function calls to the instrument drivers  312 ,  314 , and  316 . The instrument drivers receive the function calls, along with any parameters passed, and pass the function calls along to the support driver  320 . In some instances, the drivers  312 ,  314 , and  316  simply pass through their respective function calls to the support driver  320 . In other instances, the instrument drivers may perform additional processing specific to the respective instrument type. 
         [0039]    In response to the function calls from the drivers  312 ,  314 , and  316 , the support driver  320  configures the hardware resources  330  to form the desired instrument configuration(s). It sets up the hardware of each instrument configuration for performing the desired testing operations (such as forcing a signal or measuring a signal) prescribed in the test program. 
         [0040]    Different instrument configurations may require some of the same hardware resources. For example, in the embodiment of  FIG. 3 , resource  350  is required by both configuration  372  and configuration  374 . Conflicts over hardware resources may therefore arise. In the preferred embodiment, the HAL  322  performs the function of allocating the hardware resources. Alternatively, the support driver  320  may perform this function. If the support driver requires a hardware resource that has already been allocated, the HAL  322  generates an exception. The overall system is preferably designed with sufficient redundancy and flexibility to avoid most allocation exceptions. 
         [0041]    In the preferred embodiment, the test program  310  is written in a computer language that is suitable for rapid application development, such as Teradyne&#39;s VBT. The instrument drivers  312 ,  314 , and  316 , support driver  320 , HAL  322 , and resource drivers  344 ,  348 ,  352 ,  356 , and  360  are preferably written in an object-oriented computer language, such as Microsoft Visual C++™ or C#™. Drivers are preferably represented as classes having sub-classes, properties, and methods. “Function calls” to drivers are implemented by instantiating the driver classes and executing their methods. Values returned by executed methods preferably provide status, such as any errors (including allocation exceptions) produced by executing the method. 
         [0042]      FIG. 4  shows an alternative embodiment of the invention.  FIG. 4  is similar to  FIG. 3 , with corresponding features performing corresponding functions. The difference between the two is that instrument drivers  412  and  416  in  FIG. 4  are operatively connected to hardware resources  442  and  458  in addition to being operatively connected to the support driver  420 .  FIG. 4  thus illustrates that control over hardware resources  430  may be shared between the instrument drivers and the support driver. This arrangement may be effective where certain hardware resources are used by one and only one instrument configuration. In these instances, the hardware resources that are common to different instrument configurations are controlled by the support driver  420 , whereas the resources that are unique to single instrument configurations may be controlled by the respective instrument drivers. 
         [0043]      FIG. 5  shows an example of hardware resources  330 / 430  that can be used in connection with the embodiments of  FIGS. 3 and 4 . The hardware resources include microwave synthesizers  510  and  530 , attenuators/splitters  518  and  538 , and front end circuits  520 ,  522 ,  540 , and  542 . 
         [0044]    The microwave synthesizers  510  and  530  are preferably identical, although this is not required. Each synthesizer preferably includes a CW (continuous wave) source  512 / 532 , an AWG (arbitrary waveform generator)  514 / 534  and a modulator  516 / 536 . The CW sources generate sinusoidal microwave signals of programmable frequency and power level. The AWGs generate signals at sub-microwave frequencies, with programmable frequency, amplitude, and wave shape. The modulators  516 / 536  mix the output of each CW with the output of the respective AWG to produce modulated microwave signals. The AWGs can preferably be disconnected or programmed to zero, to allow the synthesizers to produce CW signals in addition to modulated signals. This arrangement thus allows each synthesizer to fill the role of both a CW source instrument and a modulated source instrument. 
         [0045]    Each synthesizer  510 / 530  is connected to a respective splitter/attenuator  518 / 538 . The splitter/attenuators are also preferably identical, although this is not required. Each splitter/attenuator preferably includes a power splitter, for distributing the respective synthesizer output to different circuit paths. Each circuit path preferably includes its own programmable step attenuator, for coarsely adjusting the power level of its respective version of the synthesizer output. 
         [0046]    The different versions of the synthesizer output are provided on different outputs of the respective splitter/attenuator. These outputs are then connected to the front end circuits. In particular, the outputs from splitter/attenuator  518  are connected to inputs of front end circuits  520  and  522 , and the outputs of splitter/attenuator  538  are connected to inputs of front end circuits  540  and  542 . Connections are provided between front end circuits  520  and  540  and between front end circuits  522  and  542 , to allow signal combination for providing multi-tone output signals. Outputs of the front-end circuits are provided to the interconnect  380 / 480  for connection to the WUT  390 / 490 . 
         [0047]      FIG. 6  shows a detailed view of the front end circuits  520 ,  522 ,  540 , and  542 . The front end circuits are preferably identical, although this is not required. Each front end circuit includes a first VCA (voltage-controlled attenuator)  610 , a first amplifier  612 , a second VCA  614 , a second amplifier  616 , a coarse attenuator  618 , a combiner  624 , and switches  620 ,  622 , and  626 . 
         [0048]    The front end circuits are programmable for adjusting the output level and frequency response of signals, and for optionally combining signals to produce multi-tone outputs. The first VCA  610  is preferably a “tilt” VCA, which is programmable for achieving desired frequency response characteristics. The second VCA  614  is preferably “reflective,” with programmable impedance, and the coarse attenuator  618  is preferably programmable for achieving a desired level of signal attenuation. The role of the combiner  624  is to add together the two signals at its inputs to produce a multi-tone signal at its output. With the switches  620  and  626  in their respective “up” positions, the combiner  624  is bypassed. In this arrangement, there is no signal combination and a multi-tone signal is not produced. The configuration shown in  FIG. 6  can be used, however, for producing either a CW output signal or a modulated output signal, with the nature of the signal being determined by the synthesizer ( 510  or  530 ) that drives the respective front end circuit. 
         [0049]      FIG. 7  shows a pair of front end circuits  700  and  702  configured and connected together for producing a multi-tone output signal. Each of the front end circuits  700  and  702  is identical to the one shown in  FIG. 6 ; however, their switch configurations are different. For the circuit  700 , the switch  620  is set to its middle position. This setting conveys a conditioned version of the circuit&#39;s input signal (CW/MOD Input) to a first input of the combiner  624 . The switch  622  is set to its “down” position, connecting the output of the second front end circuit  702  to a second input of the combiner  624 . The switch  626  is also set to its “down” position, so that the output of the combiner  624  provides the output of the circuit  700 . 
         [0050]    In the second front end circuit  702 , the switch  720  is set to its “down” position and the switch  722  is set to its “up” position. This arrangement conveys the conditioned version of the circuit&#39;s input signal to the switch  622  of the front end circuit  700 , and then on to the second input of the combiner  624 . The output of the combiner  624  thus consists of a sum of the signals received and processed by both front end circuits  700  and  702 . Notably, the signals that are added by the combiner  624  can each be either CW or modulated signals. Thus, the multi-tone output signal can be the sum of two CW signals, one CW signal and one modulated signal, or two modulated signals. 
         [0051]    The hardware resources shown in  FIG. 5  can thus be flexibly configured for achieving no fewer than three instrument functions: CW source, modulated source, and multi-tone source. 
         [0052]      FIG. 8  shows an arrangement of software drivers for controlling the hardware resources shown in the implementation of  FIG. 5 . Three instrument drivers correspond to the three instrument types supported, i.e., a CW source driver  812 , a modulated source driver  814 , and a multi-tone source driver  816 . Each of these drivers is operatively connected to a support driver  820 , which is operatively connected to a HAL  822 . The HAL is operatively connected to hardware resource drivers. These include a synthesizer resource driver  828 , a front end resource driver  830 , and a splitter/attenuator resource driver  832 . These resource drivers provide low-level reading and writing of the synthesizers  510  and  530 , front end circuits  520 ,  522 ,  540 , and  542 , and splitter/attenuators  518  and  538 . An additional layer of board-level drivers is optionally provided between the HAL  822  and the resource drivers  828 ,  830 , and  832 , in the form of a synthesizer board driver  824  and a measurement board driver  826 . The role of the board-level drivers is to provide control over particular types of circuit board assemblies. In the implementation of  FIG. 5 , synthesizers  510  and  530  may be housed on one or more circuit board assemblies, and front end circuits  520 ,  522 ,  540 , and  542  and splitter/attenuators  518  and  538  may be housed on one or more others. Circuitry can be allocated to circuitboard assemblies in whatever manner is desired and convenient. Providing separate drivers per board type confers an additional level of control. 
         [0053]      FIG. 9  shows the object model for the support driver  820 . The support driver  820  is preferably implemented as a software class  910  including various subclasses. The subclasses include a software state subclass  912 , a hardware state subclass  914 , and a number of subclasses corresponding to different hardware elements from among the hardware resources. 
         [0054]    The main support class  910  includes code for setting up hardware and interpreting results. This code preferably includes configuration code for arranging the various hardware resources into the desired instrument types, calibration processes for manipulating calibration data and calibrating the hardware resources, and leveling software. The leveling software performs the function of adjusting the power level and frequency response of output signals delivered from the CW source, modulated source, and multi-tone source instrument functions. 
         [0055]    The software state subclass  912  maintains a record of how the hardware resources have been programmed by the various instrument drivers ( 812 ,  814 , and  816 ). Settings for all programmable aspects of the hardware resources are preferably stored in this subclass. 
         [0056]    The hardware state subclass  914  maintains a record of directives to read and write the hardware resources. Whereas the software state subclass  912  maintains a record of settings sent to the support driver  820  to configure or use instrumentation, the hardware state subclass  914  maintains a record of settings sent from the support driver to lower level drivers to configure or use the hardware. 
         [0057]    The support driver  820  also includes subclasses that correspond to different hardware elements of the hardware resources. For controlling elements of the front end circuits  520 ,  522 ,  540 , and  542 , subclasses  916  and  918  are provided for the first and second VCAs  610  and  614 , and a subclass  922  is provided for the step attenuator  618 . There is also a subclass  920  for controlling the splitter/attenuators  518  and  538 , and a subclass  924  for controlling the synthesizers  510  and  530 . Each of these subclasses defines properties that correspond to physical aspects of the respective hardware element. Each also defines methods that correspond to actions that can be performed on or by the hardware element. 
         [0058]    The class  910  and each of its subclasses can be instantiated to produce particular instances, which can then be manipulated and executed in software. Multiple instances of a particular subclass can be created to control multiple hardware elements of the same type. For example, two instances of the synthesizer subclass  924  can be created to control the two synthesizers  510  and  530 . In the preferred embodiment, users have the option to purchase different numbers and combinations of hardware elements. By allowing different instances to represent and control different hardware, the object model of the support driver is able to support the full range of available hardware configurations. 
         [0059]    In addition, the support driver  820  manages the interactions of all the hardware elements as if they formed a single, reconfigurable instrument. It maintains state information, handles interactions to achieve high accuracy, and avoids duplication of code which would result if different instrument drivers were used to control the hardware resources directly. 
         [0060]    The architecture described hereinabove achieves a high level of integration, while still presenting a familiar interface to the user. Functionality for different instrument types is achieved without the need for providing instrument types in physically distinct assemblies. At the same time, redundancy is reduced by avoiding undue replication of hardware that is common across different instrument types. By providing different instrument drivers for different instrument types, the experience of the user is not significantly different from the user&#39;s experience when different physical instrument types are used. Test programs can be written using driver constructs that are similar to those used before, with different instrument drivers being provided for different instrument types. Internally, however, the support driver manages and coordinates the different hardware resources in a unified and efficient manner. 
         [0061]    Having described one embodiment, numerous alternative embodiments or variations can be made. For instance, the preferred embodiment hereof pertains to microwave sourcing instruments. However, this is merely an example. The invention hereof may be used with any type of instrumentation, including but not limited to microwave sourcing and measuring instrumentation, analog instrumentation, digital instrumentation, and power supplies. 
         [0062]    As shown and described, the support driver  820  exclusively controls the hardware resources. This is merely an example, however. As shown in  FIG. 4  and described above, control over some or all of the hardware resources may be shared between the support driver and one or more of the instrument drivers. 
         [0063]    In the preferred embodiment, the various hardware resources are housed on two different circuit board assemblies, a synthesizer board assembly and a measure board assembly. This is merely an example. Alternatively, the hardware resources can be housed on a single assembly or on greater than two assemblies. 
         [0064]    As shown and described, the term “instrument configuration” refers to a configuration of hardware. However, it may also refer to a configuration of software used to establish the hardware settings. 
         [0065]    Those skilled in the art will therefore understand that various changes in form and detail may be made to the embodiments disclosed herein without departing from the scope of the invention.