Abstract:
The technology and economics of system testing have evolved to the point where a radical change in methodology is needed for effective functional testing of systems at clock rates of 1 GHz and higher. Rather than providing a test fixture to interface between the system under test and an external tester, it is preferable to provide critical testing functions within each electronic system in the form of one or more special-purpose test chips. An architecture is proposed that supports full-speed testing with improved noise margins, and also efficient methods for learning correct system behavior and generating the test vectors. The test program is preferably written using the same programming language as used for the system application.

Description:
RELATED APPLICATIONS 
       [0001]    This application is a continuation of pending U.S. patent application Ser. No. 10/448,611 filed May 29, 2003, which claims priority to provisional Application Ser. No. 60/452,793 filed Mar. 7, 2003. These applications are each incorporated by reference herein. 
     
    
     BRIEF DESCRIPTION OF THE INVENTION 
       [0002]    This invention relates to apparatus and method for testing electronic systems, and more particularly to apparatus and method for functionally testing electronic systems at clock rates of 1 GHz and higher. 
       BACKGROUND OF THE INVENTION 
       [0003]    Conventional test methods include a hierarchy of tests including wafer probe testing, packaged part testing, and system testing. In each of these, it is customary to use a test fixture between the device under test, DUT, and the tester. The test fixture normally includes a switch matrix for connecting tester pins to DUT pins, and a collection of driver and receiver circuits, switches and relays that are commonly referred to as the “pin electronics” of the tester. 
         [0004]    In digital systems, clock rates have increased to 1 GHz and beyond. At high frequencies it becomes desirable to place components close together, and minimize trace lengths. To this end, systems have been produced that employ bare IC chips rather than packaged parts, with the IC chips attached to the system board using flip chip bonding methods, resulting in dense systems and short trace lengths. It is similarly desirable to minimize the electrical path lengths between a system under test, SUT, and the comparator circuits that are used to verify system behavior. 
         [0005]    Conventional testing methods provide a hierarchy of inspections and tests for testing complex systems. Automatic optical inspection, AOI, employs cameras and lighting systems to examine board assemblies for correct component placement and orientation, acceptable traces and solder joints. Automated X-ray inspection, AXI, can check solder joints that are hidden from AOI equipment. In circuit test, ICT, is often employed to measure values of discrete components, and to find open and short circuits. The fixture for ICT is typically a grid of electronic probes (or “bed of nails”) that make contact with test points designed into the board assembly. The maximum number of nodes that can be tested using ICT is currently around 7,000. Complex system boards may have 10,000 nodes and upward. Boundary scan is a test method commonly used to check that all components are present and properly oriented. Boundary scan methods add logic and control signals to each component, internal blocks are chained together, and access to internal nodes is greatly improved. After all the passive elements of the system have been verified and boundary scan has been performed, a board functional test is typically required. Normally, a test fixture is used to connect system nodes to tester nodes. With the system under power, stimulus vectors are applied while system outputs are measured for the correct values. A lot of effort is required to determine the stimulus vectors and the correct system responses, and the effort increases as system complexity increases. For some complex systems this approach is abandoned because the time and effort are judged to be too great. In these cases, less rigorous testing may be accomplished using a “hot mockup” which is a version of the end-user system, or by using system equivalency tests. These methods are weak in terms of diagnosing problems, because only system level results are accessible. 
         [0006]    Recent test fixtures have included expensive GaAs circuits for increased switching speed and electro-optical receivers for isolation between test circuits. Despite these efforts, some systems cannot be tested at full speed and others have to compromise on test coverage to keep the test time within reasonable bounds. 
         [0007]    Recent advances in high-density interconnection (HDI), circuits, and in flip chip bonding techniques have made it possible to add additional IC chips to a system board at a low assembly cost. Also, advances in IC chip design and implementation make it possible to include most or all of the functions of a sophisticated tester on a single IC chip, especially if the pin electronics are simplified. 
         [0008]    Built in self test (BIST) is a methodology that has been developed for testing individual components by providing test circuits within the component, rather than connecting them to an external tester. TOB is similar in concept, except that the test target is a system board rather than a component of that board. 
       SUMMARY OF THE INVENTION 
       [0009]    The proposed test method, tester on board (TOB), performs the system functional test with most of the tester functionality implemented on an IC test chip that is placed on the system board. The test chip is connected to system nodes using the interconnection method of the system board; preferably the components are assembled as bare die using flip chip assembly methods. Since in circuit tests and boundary scans are typically low speed tests employing simple test hardware, they are preferably provided by a test support computer that includes such hardware, without involving the IC test chip. 
         [0010]    In the preferred embodiment, a single test chip samples test signals of three different types: digital, analog, and radio frequency (RF). The digital signals are carried on digital bus lines, the analog signals are carried on analog bus lines, and the RF signals are sampled at antenna inputs. System behavior is evidenced by the various signals sampled and tested at the discrete instants in time represented by test cycles. The ultimate format for each item of captured behavior is preferably a test vector or digital word, although analog comparisons may be preferred for parametric tests such as a leakage current test. The main focus of this application applies to functional testing of digitized signals. However, reference sources including voltage and current sources, amplifiers and analog comparators may be included in the preferred test hardware for parametric testing. For digital signals the number of bits in the word corresponds to the number of digital bits sampled. Analog test signals are preferably converted from analog to digital format; the number of bits in each analog test vector is calculated as the number of analog signals sampled times the number of digitized bits per sample. RF test signals may be down-converted to a suitable intermediate frequency, then demodulated and digitized. The number of bits in each RF test vector is equal to the number of RF signals sampled times the number of digitized bits per sample. 
         [0011]    The test system includes a learn mode and a test mode. The learn mode allows test vectors generated during selected cycles of system behavior to be automatically accumulated in memory. These vectors can be created by a reference system that is hopefully fully functional, or close to fully functional. The cycles selected are test cycles; they capture critical system behaviors or responses. Eliminating redundant or unnecessary test cycles has the benefit of reducing the required amount of memory on the test chip. The test program starts at time=0 with cycle count=0. The cycle count increments with each cycle of the timing reference or system clock. The temporal locations of selected cycles (cycle counts) are captured in a test mask which includes a memory bit for each test cycle performed. A “1” in the mask memory represents a selected cycle for which verification is required (a test cycle); a “0” represents an unselected cycle for which verification is not required. Typically, only a small percentage of total system cycles are required to be test cycles in order to reliably validate system behavior. 
         [0012]    Successive approximations are employed to capture and refine the learned behavior of a properly functioning system. The goal is to automate the process where possible, avoid writing a detailed test program in a software language foreign to the system designers, and reduce the amount of labor required to optimize the selection of effective test vectors. After the learned behavior is refined and verified, the test vectors become proven test vectors; they can be loaded into reference memories for comparison with observed behavior of a system under test (SUT). 
         [0013]    A test support computer stores a master copy of the test program, a master copy of the test mask memory, and a complete set of proven test vectors. These are loaded into the appropriate memories before testing commences. A test is performed by running the test program and comparing test vectors generated by the SUT against the proven test vectors. Any mismatch raises a flag which is reported at a given test cycle count. The test result is passed to the test support computer which diagnoses potential causes of any flagged mismatches, and displays recommendations to the test operator for reworking defective components in the system. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0014]    Preferred embodiments of the invention are described below with reference to the following accompanying drawings. 
           [0015]      FIG. 1  is a high level block diagram of the test system of the current invention, showing primary data and control flows; and 
           [0016]      FIG. 2  is a timing diagram showing representative test signal waveforms for both a passing and a failing test event. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0017]      FIG. 1  shows a high-level block diagram of a test apparatus of the current invention including a test chip  1  and a test support computer  2  connected to the system under test (SUT)  3 . SUT  3  includes digital circuits  4 , analog circuits  5 , and RF circuits  6 . System access port  7  is preferably a high-density connection between SUT  3  and test support computer  2 . This port is preferably used to validate the interconnection circuits of the SUT using continuity-testing circuits typically provided on a plug-in board within test support computer  2 . Similarly, another plug-in board within test support computer  2  may include circuits for testing boundary scan circuits  8  of SUT  3 . Plug-in boards can be used for these tests because the clock rates are typically slower than for functional testing; the test hardware is less demanding and is typically available as a commercial-off-the-shelf (COTS) item. Also, connecting wires or cables can be tolerated at the lower test frequencies. In combination, the continuity and boundary scan tests validate the integrity of the conductive traces and also the placement and orientation of components mounted on the system board. The rest of this description will focus on the more challenging task of functionally testing the SUT at clock rates of 1 GHz and higher. 
         [0018]    Three signal types are tested by test chip  1  in the preferred embodiment. Digital input bus  10  is a collection of digital signals bussed to input pads and input buffers (not shown) of test chip  1 . Similarly analog input bus  11  is a collection of analog signals bussed to test chip  1 . RF inputs  12  are collected at one or more antenna sites on the SUT as shown. Preferably, signals of each type are routed in a manner that protects them from electrical noise sources in the system, typically by providing spatial separation between circuit blocks of different types, and among the signals of a given type. 
         [0019]    Timing circuits  13  on the SUT provide a timing reference (TREF)  14 . In a digital system employing synchronous design TREF  14  may be a digital system clock, with one system cycle represented by one period of the system clock. This is the most common type of system and for the purpose of illustration this is the type of system discussed herein. However, asynchronous designs and other timing methods are possible and are included within the scope of the present invention. TREF  14  is an input to cycle counter  15  which increments every system cycle, and provides a pointer (CCNT)  16  to every system cycle within a test program. 
         [0020]    As a preferred first step in the process of learning correct system behavior, an application program that would run in system processor  17  is augmented with additional instructions to produce a test program. This is a convenient way to generate the first draft of the test program. The application software is typically written in a high level language; both the software and the program language are usually familiar to the system developers. The program is written to thoroughly exercise all of the features and components of the system. It is augmented with additional instructions that generate a test enable signal (TSTEN)  18  to highlight critical system cycles whenever it is judged that system behavior should be captured and tested. The behavior is preferably captured in test vectors. An example of a critical system cycle would be an instruction to read a register in a system component containing a digital variable that has just been calculated or has otherwise just changed to reflect a new result. The selected cycles are combined with TREF  14  to produce a mask memory  19  and also to generate test strobes such as TSTB  20 . The mask memory is a serial memory that contains a 1 for system cycles that are selected as test cycles, and a 0 for all other cycles. In practice the sampling circuits may operate continuously, with only a few of the samples tested. We shall define “sample and test” as a unified sequence that includes both sampling and testing of the sampled input. System behavior is only sampled and tested during test cycles, which are typically a small fraction, perhaps 1% of the total system cycles. Similarly a test strobe  20  is generated only during test cycles, and is referenced to TREF  14 . This preliminary process for generating test vectors may be imprecise because the instruction used to generate TSTEN  18  typically occupies several system cycles. Consequently, too many 1s may be placed in mask memory. However, a test program developer can easily scan these sequences and cull the number of 1s to create an optimal set. This refinement of the mask memory is typically performed using software running on test support computer  2 . 
         [0021]    A bi-directional bus interface  21  is provided between test support computer  2  and system processor  17 . Interface  21  is used for general communications such as may be required for synchronization, and also for passing test programs and augmented test programs back and forth between SUT  3  and test support computer  2 . 
         [0022]    After the first phase of selecting critical test cycles is complete as outlined above, a preliminary version of mask memory  19  is available in test chip  1 . Bi-directional interface  22  allows the mask image to be passed back and forth between mask memory  19  and test support computer  2  as it is successively refined and tested. 
         [0023]    Other interfaces to test support computer  2  include results bus  23  for reporting test results from the fail memories, and a bi-directional interface  24  to the reference memories. As will be described, the reference memories contain proven test vectors used for comparison with system outputs. As with the test program and the mask memory, it is desirable to pass the contents of the reference memories in and out of test support computer  2  during the process of refining them. 
         [0024]    We shall first examine testing of system behavior represented by digital signals. A core logic block  25  on test chip  1  includes a reference memory  26 , a digital comparator  27 , and a fail memory  28 . Digital input bus  10  is sampled to form a test vector, DVIN,  29  at one input to comparator  27 . The number of bits in test vector DVIN  29  corresponds to the number of digital bits sampled. During test mode, the other input to comparator  27  is provided by reference memory  26  in the form of a proven digital test vector, PDV  30 . During learn mode, digital inputs  10  are sampled and captured in reference memory  26 . If the SUT is fully functional, then the learned test vectors will indicate correct system behavior. This method of learning the correct system behavior can eliminate a lot of work in generating and validating the test vectors by simulation or other means. 
         [0025]    Multiple system prototypes may be used to generate the learned behavior; some will contribute only a portion of the total behavior, others will be used to statistically validate the learned responses. The learned test vectors are transferred to test support computer  2  where they are assembled and saved in a memory block comprising a full set of digital test vectors. For a given test cycle, if the compared vectors DVIN and PDV are the same, then no error flag is raised and no entries are written to fail memory  28 . Conversely, if the two vectors are not the same, comparator  27  will send an error flag for digital signals, DFLG,  31  to fail memory  28 . DFLG  31  will cause CCNT  16  to be saved in fail memory  28  as a pointer to a failed test cycle. It is preferable to store in fail memory  28  the value of CCNT when the failure occurred, plus all the bits of the comparison vector. At least one of these bits will be a zero to indicate that a failure occurred. The location of 0&#39;s within the comparison vector may be used by diagnostic software hosted in test support computer  2  to help determine the specific failing component or components, to support subsequent recommendations to the test operator about which components need to be replaced. 
         [0026]    An alternative embodiment of the test architecture will provide the comparison test vector in the appropriate reference memory by sampling a second operating system with known good behavior. The critical requirement is that a known good test vector be provided at the instant of comparison, whether it is predetermined and loaded into reference memory or provided by a parallel operating system. 
         [0027]    Next we shall examine testing of system behavior represented by analog signals. The same core logic block  25  is used in the test path for analog inputs  11 , enumerated as digital comparator  35 , reference memory  36 , and fail memory  37 . An analog to digital converter, ADC,  38  digitizes each waveform of the sampled data and concatenates the digitized words to form a test vector, AVIN,  39 . Again, system behavior can be learned by loading sampled and digitized analog inputs into reference memory  36  and then reading the digital words into test support computer  2 , to create a memory block comprising a full set of analog test vectors. In test mode however, reference memory  36  has been pre-loaded with known good or proven test vectors from test support computer  2 . If a digital comparison produces a mismatch between test vector AVIN  39  and proven test vector PAV  40 , error flag AFLG  41  for analog signals is sent to fail memory  37 . 
         [0028]    Next we shall examine testing of system behavior represented by RF signals. The same core logic block  25  is used in the test path for radio frequency inputs  12 , enumerated as digital comparator  45 , reference memory  46 , and fail memory  47 . An RF converter, RFC, down-converts each RF signal to a suitable intermediate frequency, IF, and demodulates the signal. The parallel stream of demodulated signals  49  is digitized by analog to digital converter, ADC,  50 , and the digitized words are concatenated to form test vector, RVIN,  51 . Again, system behavior can be learned by loading sampled and digitized RF inputs into reference memory  46  and then reading the digital words into test support computer  2 , to create a memory block comprising a full set of RF test vectors. In test mode however, reference memory  46  has been pre-loaded with known good or proven test vectors from test support computer  2 . If a digital comparison produces a mismatch between test vector RVIN  51  and proven test vector PRV  52 , error flag RFLG  53  for RF signals is sent to fail memory  47 . 
         [0029]      FIG. 2  shows representative timing of both a passing test event [designated “(A)”] and a failing test event [designated “(B)”]. Waveforms are presented with voltage on the vertical axis and time on the horizontal axis. The timings are shown for a digital input signal and represent just one possible example of how the various edges of TREF could be used to generate test control signals. Since in the preferred embodiment analog and RF signals are converted to digital signals in test chip  1  prior to the comparison event, a similar timing diagram would apply for those signal types as well. TREF  14  is the timing reference previously discussed. It has a system cycle time, T,  55  as shown. TSTB  20  is the test strobe previously discussed. DVIN i    60  is one bit of a digital test vector that has been sampled from digital input bus  10 . PDV i    61  is the corresponding bit of a known good or proven test vector for comparison with DVIN i    60 . DFLG i    62  is the flag used to indicate a failure in bit i of the comparison word, and CCNT  16  is the cycle count. CCNT  16  increments for every system cycle T,  55 . Sequence (A) in  FIG. 2  is for a passing test event. A rising edge  63  of TREF causes transition  64  in DVIN i , because the sampled digital signal is high during this test cycle. The compared value PDV i  also transitions  65  to a high because the corresponding ith bit of the proven test vector in reference memory  26  is high. CCNT also switches,  66 , in response to rising edge  63  of TREF. The following trailing edge of TREF  67  causes a positive transition  68  in TSTB as shown. TSTB activates the comparison of level  70  of DVIN i  with level  71  of PDV i . Since the compared levels are the same, indicating correct system behavior, DFLG i  remains low  72 , and the corresponding value of CCNT is not saved in fail memory  28 . Conversely, sequence (B) in  FIG. 2  is for a failing test event. The waveforms are similar to those depicted for sequence (A) except for DVIN i  and DFLG i  The sampled test vector bit DVIN i  is low when it should be high. Thus at edge  79  of TSTB the compared levels  80  of DVIN i  and  81  of PDV i  are not the same. This causes DFLG i  to transition high  82  which in turn causes the value of CCNT  84  to be captured in fail memory  28 , along with the comparison vector having 0&#39;s for the failed bit locations.