Patent Publication Number: US-2006020920-A1

Title: Methods and apparatus for providing automated test equipment with a means to jump between tests in a test program

Description:
BACKGROUND  
      Prior to manufacture and distribution, electrical devices must be tested to ensure that they perform as intended. One way to test electrical devices such as integrated circuits and system-on-a-chip devices is via automated test equipment (ATE). Although ATE is a great tool, it must be provided with a test program for each device that it is to test. Often, these test programs comprise thousands or even millions of tests that must be sequentially executed to ensure that various structures and functions of a device are adequately tested. The development of such a test program is an arduous task. Furthermore, the storage and memory requirements for handling such a program can be significant.  
     SUMMARY OF THE INVENTION  
      In one embodiment, a number of machine-readable media have stored thereon sequences of instructions that, when executed by a machine, cause the machine to perform the following actions: 1) execute one or more ordered sequences of tests and control functions in a test program (with execution of the tests causing stimuli to be applied to an electrical device under test), and 2) upon execution of a control function that specifies a GOTO function, redirect program flow to a target of the GOTO function (with the target of the GOTO function not immediately following the GOTO function in test program order).  
      In another embodiment, a graphical test program editor comprises a window to graphically display a test program comprising one or more ordered sequences of tests and control functions. The sequence order is conveyed by graphical connections between the tests and control functions. The test program editor also comprises a user-selectable GOTO control function that a user may graphically place and connect within the test program.  
      In yet another embodiment, a test program comprises one or more ordered sequences of tests and control functions, the tests of which cause stimuli to be applied to an electrical device under test, and the control functions of which comprise at least one GOTO function that, when executed, causes execution of the test program to jump to a target of the GOTO function (again, with the target of the GOTO function not immediately following the GOTO function in test program order).  
      Other embodiments are also disclosed.  
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
      Illustrative and presently preferred embodiments of the invention are illustrated in the drawings, in which:  
       FIG. 1  illustrates exemplary automated test equipment (ATE);  
       FIG. 2  illustrates a first exemplary test program;  
       FIG. 3  illustrates an exemplary test program, wherein the test program comprises an IF/THEN control function;  
       FIGS. 4 &amp; 5  illustrate exemplary test programs comprising GOTO control functions;  
       FIGS. 6 &amp; 7  illustrate the use of a GOTO control function in a subsidiary testflow, wherein the GOTO function provides a return to a point other than a default return point in a calling testflow;  
       FIG. 8  illustrates a GOTO control function that jumps to a LABEL element;  
       FIGS. 9 &amp; 10  illustrate the use of a GOTO control function to repeatedly call a subroutine of tests;  
       FIG. 11  illustrates an alternate embodiment of the  FIG. 10  test program, without the use of a RETURN element;  
       FIG. 12  illustrates a primary sequence of tests that calls various subroutines of tests;  
       FIGS. 13-15  illustrate actions that may be performed by a machine during execution of one of the previously illustrated test programs comprising a GOTO function;  
       FIG. 16  illustrates a graphical test program editor via which a GOTO function may be inserted into a test program;  
       FIG. 17  illustrates a jump to a GOTO function&#39;s corresponding LABEL element within the  FIG. 16  test program editor; and  
       FIG. 18  illustrates an interface of the  FIG. 16  editor for turning a placed GOTO function “on” or “off”.  
    
    
     DETAILED DESCRIPTION OF AN EMBODIMENT  
       FIG. 1  illustrates exemplary automated test equipment (ATE  100 ) for testing an electrical device under test (DUT  102 ). By way of example, the DUT  102  could be an integrated circuit (i.e., an IC, either packaged or in wafer form) or a system-on-a-chip (SOC). The ATE  100  tests the DUT  102  by executing a number of tests which cause electrical stimuli to be applied to the DUT  102 . During test, the ATE  100  collects responses to the stimuli (i.e., test results), and evaluates the responses to determine whether the DUT  102  has passed or failed its testing. If the DUT  102  has failed, the ATE  100  can sometimes indicate 1) which test caused the DUT  102  to fail, or 2) what part of the DUT  102  caused the DUT to fail.  
      In some embodiments, the ATE  100  may be connected to (or comprise) a computer system  104  having a display  106 . In this manner, a user may interact with the ATE  100  while developing tests for, or executing tests on, the DUT  102 . Alternately, a user may develop tests for the DUT  102  using software running on a computer system that is not connected to the ATE  100 .  
      One exemplary embodiment of ATE  100  is the Agilent 93000™ SOC Series tester provided by Agilent Technologies, Inc. of Palo Alto, Calif., USA.  
      Typically, ATE  100  will test a DUT  102  under the control of a test program comprising one or more ordered sequences of tests and control functions. Each test may cause a single stimulus, a plurality of stimuli, or a pattern of stimuli to be applied to the DUT  102 . By way of example, tests may control and/or measure the following aspects of a DUT: voltages, currents, resistances, capacitances, inductances, frequency responses, jitter, and data inputs and outputs (I/O).  
      The control functions of the test program may initiate various “setups” prior to the execution of a test, or they may dictate the flow of a test program. For example, one type of control function is the IF/THEN function, wherein program flow is redirected if a given condition has been met. Other types of control functions include FOR loops and WHILE loops.  
      Often, a test program will comprise thousands or even millions of tests. The development, debug and maintenance of a test program that appropriately and adequately tests a DUT  102  is therefore a time-consuming task that may involve days, weeks or even months of a test developer&#39;s time.  
       FIG. 2  illustrates a first exemplary test program  200  comprised of a sequence of tests (i.e., Test 1 -Test 8 ). By way of example, the tests of the test program  200  may be contained in a plurality of nodes  202 - 216  in a linked list, with each node element being uniquely addressable, and with each node element pointing to a next node in the list. Alternately, tests and control functions may be maintained by one or more list structures, each of which can only be entered at its head (e.g., Test 1  in  FIG. 2 ).  
       FIG. 3  illustrates a second exemplary test program  300 . This second test program  300  comprises an IF/THEN control function  302  following Test 1 . If the condition(s) specified by the control function are met, the sequence of tests  204 - 216  beginning with Test 2   204  is executed. Otherwise, the sequence of tests  304 - 310  beginning with Test 5   304  is executed. Note that Test 5 -Test 8  are replicated in each of the two alternative branches  204 - 216 ,  304 - 310  of the test program  300 . Yet, they are the same tests (with the exception that the contexts in which they are executed may cause them to be executed with different inputs or under different conditions).  
       FIG. 4  illustrates a third exemplary test program  400 , wherein the IF/THEN control function  302  of the test program  300  has been replaced with a GOTO control function  402 . Note that the GOTO control function  402  eliminates the duplicated instances of Test 5 -Test 8  found in test program  300 .  
      Given that sequences of tests in an actual test program can be quite long, and the same tests must often be repeated under different conditions, the GOTO function  402  shown in  FIG. 4  can significantly reduce the number of discrete tests that need be included in a test program. In some cases, this can significantly reduce the storage and memory requirements of the test program. Use of a GOTO function  402  can also reduce the effort that is needed to debug and maintain a test program. For example, consider a need to edit Test 5  in each of the test programs  300 ,  400  shown in  FIGS. 3 &amp; 4 . In the test program  400 , Test 5  need only be edited in one place. However, in the test program  300 , Test 5  will likely need to be edited in two places. If Test 5  is repeated in additional IF/THEN branches of the test program  300 , the difficulty of consistently editing Test 5  merely increases. In a large test program comprising thousands or even millions of tests, there comes a point where a test developer can no longer track all of the separate instances of a common test. At this point, the test developer can debug only those instances of a test they can find, with additional instances causing failures (and requiring additional debug efforts) at a later time. Further, if failures of some tests occur at the design stage, while failures of other tests occur during device manufacture, different people may be required to debug different instances of the same tests, and each may do so in different ways, thereby leading to a lack of consistency in a test program. The GOTO control function  402  can therefore be very useful.  
      The GOTO function  402  presumes that some sort of conditional analysis is built into it. In some cases, it may be desirable to separate these functions, as shown in  FIG. 5 . By separating the IF/THEN and GOTO functions  500 ,  502 , a test developer or debugger may choose to implement an unconditional GOTO. This can be especially useful during test debug, when it is desired to narrow the possible cause of a problem down to a selected subset of tests. In such a case, an engineer could simply insert a GOTO function that jumps over tests that they do not want to execute.  
       FIGS. 6 &amp; 7  illustrate another use for a GOTO function.  FIG. 6  illustrates a test program  600  comprised of three testflows  602 ,  604 ,  606 . A testflow, as defined herein, is merely a commonly managed set of tests and control functions. Testflows are useful in some cases in that they provide a means of dividing a test program into more easily manageable chunks. By way of example, the Agilent 93000™ SOC Series tester is one example of ATE that processes test programs comprised of testflows. During execution of a testflow  602 , a control function such as an IF/THEN function  608  may cause one testflow to call another testflow. The subsidiary testflow (e.g., testflow  604  or  606 ) may then execute a control function (not shown) that causes yet another testflow to be called, such that testflows are called in a nested manner. Upon execution of a calling function (e.g., IF/THEN  608 ), an identifier of the calling testflow  602  will typically be pushed onto a stack. Then, after the subsidiary testflow (e.g., testflow  606 , and any additional testflows that it calls) has completed execution, program flow will return to the calling testflow  602 , and the sequence of tests and control functions specified by the calling testflow  602  will finish execution.  
      One limitation of executing a program comprised of testflows is that, after execution of a subsidiary testflow  606 , program flow returns to the calling point in the calling testflow  602 . However, there are times when it would be preferable not to return to the calling point. For example, an engineer may realize during debug of the test program  600  that it would be best not to execute Test 3  following Testd. In the past, this problem might have been solved by moving Test 3  from the calling testflow  602  to the subsidiary testflow  604 . However, if Test 3  were buried in the middle of a much larger testflow, or if it was desired to move a large number of tests from a calling testflow to a subsidiary testflow, this solution might quickly become unwieldy.  FIG. 7  therefore illustrates an alternative solution to the problem, wherein a GOTO function  700  is merely inserted at the end of the subsidiary testflow  606 . Thus, a GOTO “jump” is made to Test 4  of the calling testflow  602  prior to a conventional “return” to Test 3  of testflow  602 . Note that jumping between testflows  602 - 606  may, however, require the deletion of one or more entries from the return stack maintained for “call” returns.  
      Although the figures illustrate various forward jumps that may be triggered by a GOTO function, the jumping initiated by a GOTO element is not so limited, and backward jumps can also be implemented. In other words, jumping to a target that precedes a GOTO function in test program order is permitted.  
      In some cases, the target of a GOTO function may be a test or other control function. However, to clearly delineate the bounds of a GOTO element, it may be desirable to implement a GOTO  800  that jumps to a LABEL element  802 . See  FIG. 8 . Each LABEL element in a test program can then be associated with an identifier (or identifiers) of the “GOTO(s)” of which it is a target. In this manner, accidental deletion of a test or other control function does not leave a GOTO without a target. A label manager implemented in program code may be used to ensure that all labels are identified uniquely.  
       FIGS. 9 &amp; 10  illustrate the use of a GOTO control function to repeatedly call a subroutine of tests. As shown in  FIG. 9 , one way to repeatedly execute a sequence of tests (e.g., TestA and Test B) is to repeatedly insert the tests (e.g.,  902 / 904 ,  910 / 912 ,  918 / 920 ) in a test program  900 - 922 . However, repeating tests within a test program increases the storage requirements of the test program, and can make it difficult to understand and debug.  FIG. 10  therefore shows how TestA  902  and TestB  904  can be placed in a subroutine of tests, with the subroutine of tests being repeatedly called via a number of GOTO control functions  1000 ,  1002 ,  1004  in a primary test sequence  900 ,  906 ,  908 ,  914 ,  916 ,  922 . Each time the subroutine of tests  902 ,  904  is called, an identifier of the calling GOTO function is logged by, for example, pushing it onto a stack or passing it to a RETURN control function  1008 . Upon execution of the RETURN element  1008 , test program flow is then redirected to an element of the test program that sequentially follows the GOTO function that called the subroutine  902 ,  904 . As shown in  FIG. 10 , the subroutine of tests  902 ,  904  may be preceded by a LABEL element  1006 .  
      Although  FIG. 10  shows a GOTO function  1000  and its target  1006  to be located within different ordered sequences of a test program (e.g., different testflows), they could alternately be located in the same sequence (or testflow).  
       FIG. 11  illustrates an alternate embodiment of the  FIG. 10  test program. The  FIG. 11  embodiment is similar to the  FIG. 10  embodiment, without the use of the RETURN element  1008 . In  FIG. 11 , upon completing execution of the subroutine  902 ,  904 , test program flow is automatically redirected to an element of the test program  1100  that sequentially follows the GOTO function that called the subroutine  902 ,  904 . In one embodiment, such automatic redirection of test program flow may be accomplished by 1) executing tests  900 ,  906 ,  908 ,  914 ,  916  and  922  in a first testflow  1102 , 2) executing tests  902  and  904  in a second testflow  1104 , and 3) executing all tests and control functions in a WHILE loop. Then, upon execution of all of the tests and control functions in the second testflow  1104 , the next element executed will, by default, be the element following the GOTO function that called the second testflow  1104 .  
       FIG. 12  illustrates how a primary sequence of tests and control functions  1200 - 1214  may be used to call various subroutines of tests (e.g., subroutines FUNC_ 1   1216 - 1224 , ANALOG  1226 - 1230 , and TIMING  1232 - 1236 ). Note that subroutine FUNC_ 1  further calls another of the subroutines (i.e., TIMING).  
      Any of the afore-mentioned test programs comprising a GOTO function may be stored on a number of machine-readable media such as memory (e.g., RAM) or a disk (e.g., a fixed disk such as a hard drive, or a removable disk such a CD-ROM). The same or additional machine-readable media may also store sequences of instructions (e.g., program code) that, when executed by a machine (e.g., ATE  100 ), cause the machine to perform the actions illustrated in  FIG. 13 . The actions comprise: executing  1302  one or more ordered sequences of tests and control functions in the test program, the tests causing stimuli to be applied to an electrical DUT  102 ; and, upon execution of a control function that specifies a GOTO function, redirecting  1304  test program flow to a target of the GOTO function (with the target of the GOTO function not immediately following the GOTO function in test program order).  
       FIGS. 14 and 15  illustrate additional actions that a sequence of instructions stored on machine-readable media may cause a machine to perform. In  FIG. 14 , the actions comprise: 1) executing  1402  one or more ordered sequences of tests and control functions in the test program, the tests causing stimuli to be applied to an electrical DUT  102 ; 2) upon execution of a control function that specifies a GOTO function, redirecting  1404  test program flow to a target of the GOTO function (with the target of the GOTO function not immediately following the GOTO function in test program order); and 3) upon execution of a control function that specifies a RETURN, redirecting  1406  test program flow to an element of the test program that sequentially follows the GOTO. In  FIG. 15 , the actions comprise: 1) executing  1502  one or more ordered sequences of tests and control functions in the test program, the tests causing stimuli to be applied to an electrical DUT  102 ; 2) upon execution of a control function that specifies a GOTO function, redirecting  1504  test program flow to a target of the GOTO function (with the GOTO and its target being members of two different ordered sequences of tests); and 3) upon completing execution of a sequence of tests and control functions in which said target of the GOTO resides, redirecting  1506  test program flow to an element of the test program that sequentially follows the GOTO.  
       FIG. 16  illustrates a graphical test program editor  1600  via which a GOTO function may be inserted into a test program  1604 . In general, the editor  1600  comprises a window  1602  to graphically display a test program  1604  comprising one or more ordered sequences of tests  1608 ,  1612 ,  1614  and control functions  1606 ,  1610 , and a user-selectable GOTO control function  1610  that a user may graphically place and connect within the test program  1604 . Note that the sequence order of the test program  1604  is conveyed by graphical connections (e.g., connecting lines) between, and order of, the tests  1608 ,  1612 ,  1614  and control functions  1606 ,  1610 . By way of example, the GOTO function  1610  may be selected from a drop-down menu  1616  or iconic toolbar of the editor  1600 .  
      In one embodiment, the editor  1600  further comprises 1) a user-selectable LABEL element  1700  ( FIG. 17 ) that a user may graphically place and connect within the test program  1604 , and 2) an interface  1618  to define connections between placed ones of the GOTO control functions and LABEL elements. The editor  1600  may also comprise a user-selectable RETURN control function that a user may graphically place and connect within the test program  1604 .  
      To assist in defining the connections between GOTO functions  1610  and LABEL elements  1700 , the editor  1600  may further comprise an interface for naming GOTO functions  1610  and LABEL elements  1700 . This interface may take the form of dialog boxes that are launched by selecting (e.g., right-clicking on) ones of the GOTO functions  1610  or LABEL elements  1700 .  
      The test program editor  1600  may further associate GOTO commands with the placed GOTO functions. In one embodiment, a GOTO command is executed as a result of 1) selecting one of the placed GOTOs, and then 2) selecting the GOTO command (e.g., from a pop-up menu launched by right-clicking on the GOTO). Execution of the GOTO command causes the test program window  1602  to update its display to show at least the target  1700  of the selected GOTO  1610  (see  FIG. 17 ).  
      The test program editor  1600  may further comprise an interface  1800  for turning placed GOTO functions “on” and “off” (see  FIG. 18 ). The “on” and “off” statuses may then be used to determine whether the GOTO functions will be executed during execution of the edited test program  1604 . In one embodiment, the interface  1800  for turning the GOTO functions “on” and “off” further accepts user-defined conditions  1802 . These conditions may then be assessed during execution of the edited test program  1604  to determine whether GOTO functions should be executed. This can be especially useful in debugging a test program (e.g., by using GOTO functions to skip tests and thereby isolate a problem).  
      Preferably, placed GOTO control functions are graphically connected to their GOTO targets (whether they be label elements, tests, nodes or other control functions). In one embodiment, these graphical connections are displayed in different manners, depending on different statuses associated with the placed GOTO control functions. For example, if a GOTO function is “on”, a connection between a GOTO function and its LABEL element may be designated by a solid or green line. If the GOTO function is turned “off”, its connection with its LABEL element may be deleted, shown with a dashed line, or shown in a red color.  
      As discussed in part above, GOTO control functions can be variously used to eliminate duplicated tests within a test program, to bypass tests during debug, to jump to tests out of sequence, to reduce test program bulk, and to make test programs easier to understand.