Evaluating the Digital Fault Coverage for a Mixed-Signal Built-In Self-Test by Michael Alexander Lusco A thesis submitted to the Graduate Faculty of Auburn University in partial ful llment of the requirements for the Degree of Master of Science Auburn, Alabama August 31, 2011 Keywords: Built-In Self Test, Mixed-Signal, Testing Copyright 2011 by Michael Alexander Lusco Approved by Charles Stroud, Chair, Professor of Electrical and Computer Engineering Foster Dai, Co-Chair, Professor of Electrical and Computer Engineering Victor Nelson, Professor of Electrical and Computer Engineering Abstract This thesis focuses on a digital Built-in Self-Test (BIST) approach to perform speci cation- oriented testing of the analog portion of a mixed-signal system. The BIST utilizes a direct digital synthesizer (DDS) based test pattern generator (TPG) and a multiplier-accumulator (MAC) based output response analyzer (ORA) to stimulate and analyze the analog devices under test, respectively. This approach uses the digital-to-analog converter (DAC) and the analog-to-digital converter (ADC), which typically already exist in a mixed signal circuits, to connect the digital BIST circuitry to the analog device(s) under test (DUT). Previous work has improved and analyzed the capabilities and e ectiveness of using this BIST approach to test analog circuitry; however, little work has been done to determine the fault coverage of the digital BIST circuitry itself. Traditionally additional test circuitry dedicated to testing would be added to the BIST circuitry to provide adequate fault cov- erage of digital circuitry. While ensuring that the digital circuitry is thoroughly tested and functioning properly, this circuitry incurs a potentially high area overhead and performance penalty. This thesis focuses on using the existing BIST circuitry to test itself by utilizing a dedicated digital loopback path. A set of test procedures is developed and analyzed which can be used to provide a set of functional tests which provide a high e ective fault coverage of the digital portion of the BIST. To determine the e ectiveness of these test procedures, the mixed-signal BIST circuit is simulated and single stuck-at gate-level fault coverage results are determined and presented. Finally several improvements to the dedicated loopback path are proposed and simulated to analyze possible ways to improve the fault coverage of the BIST with minimal area and performance impact. ii Acknowledgments I would like to express my thanks to Dr. Charles Stroud for his help, patience, and guidance in preparing this thesis and for a ording me the opportunity to work on my Master degree. His constant encouragement and insight has pushed me to develop my skills and to learn. Without his help I may never have pursued my graduate degree or be publishing this thesis. I would also like to thank my co-adviser Dr. Fa Dai for his work in preparing this thesis and his assistance with my research and related projects. I?d also like to extend my thanks to my committee members including Dr. Victor Nelson and Dr. Vishwani Agrawal for their input in nishing this thesis as well as the wisdom and knowledge I have learned from them in my studies. My thanks also goes out to all of the students who I have worked with at Auburn University: Brad Dutton, George Starr, Joseph Cali, Justin Dailey, and Neil Da Cunha. I?d especially like to thank Jie Qin for his help with my research and testing especially during the Fall semester. Also to Justin Dailey, I owe you the most { one day soon I won?t lose by a million. To all of you as well as the students I didn?t name, I couldn?t have done it without all of your help. For my parents Rhonda and Michael Lusco, thank you so much for your support both morally and nancially. Your help and guidance has made this journey much easier and more fun. Without your in uence over my entire life, I am not sure I would have had the con dence necessary to pursue this goal. Finally I?d like to thank my beautiful (soon to be) wife, Leann Stokes. Thank you for all of your patience, advice, and support with not only this thesis but for our entire time at Auburn. You?ve made my life so exciting and fun and I can not wait to be married to you! iii The views, opinions, and/or ndings contained in this article/presentation are those of the author/presenter and should not be interpreted as representing the o cial views or policies, either expressed or implied, of the Defense Advanced Research Projects Agency or the Department of Defense. iv Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix List of Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Why Test Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 The Basics of Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Built-In Self-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3.1 Digital Systems and Faults . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3.2 Analog Systems and Faults . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3.3 Mixed Signal Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1 Fault Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1.1 Collapsed vs Uncollapsed Faults . . . . . . . . . . . . . . . . . . . . . 17 2.1.2 The Bridging Fault Model . . . . . . . . . . . . . . . . . . . . . . . . 19 2.1.3 Design Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2 AUSIM Fault Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.1 ASL Netlist Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.3 BIST Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.3.1 DDS Based TPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.3.2 ORA Multiplier-Accumulators . . . . . . . . . . . . . . . . . . . . . . 28 v 2.3.3 On-Chip Calculation Circuit . . . . . . . . . . . . . . . . . . . . . . . 31 2.3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.4 Thesis Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3 Test Preparation, Development, and Veri cation . . . . . . . . . . . . . . . . . . 40 3.1 Converting to ASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.2 ASL Veri cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.2.1 Value Change Dump File . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.2.2 OutToVCD Converter . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.3 Test Vector Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4 Fault Simulations and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.1 Performing the Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.1.1 Test Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2 Fault Coverage Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.2.1 Potentially Detected Faults . . . . . . . . . . . . . . . . . . . . . . . 54 4.2.2 Undetectable Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2.3 Overall Fault Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.3 Experimental Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5 Analysis and Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.1 Fault Coverage Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.2 Fault Coverage Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3 SSA BIST Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 vi List of Figures 1.1 AND Gate with Input A Stuck-At ?1? . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Simple BIST for an AND Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3 BIST Approach for Mixed-Signal Systems[1] . . . . . . . . . . . . . . . . . . . . 9 1.4 Mixed-Signal BIST with Multiple Loopback Paths . . . . . . . . . . . . . . . . 10 1.5 Fault Coverage v. Acceptable Value Range[7] . . . . . . . . . . . . . . . . . . . 11 2.1 NOR Gate with Six Uncollapsed and Four Collapsed Faults . . . . . . . . . . . 18 2.2 Structural Fault Collapsing Performed on a Group of Logic Gates . . . . . . . . 18 2.3 Bridging Fault where Net A Dominates Net B . . . . . . . . . . . . . . . . . . . 21 2.4 A Half-Adder Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.5 General BIST Architecture[20] . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6 Block Diagram of DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.7 The OR Chain Which Calculates the Number of Clock Cycles from the Logical OR of All Frequency Words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.8 Calculation Circuit Presented in [25] . . . . . . . . . . . . . . . . . . . . . . . . 33 2.9 Input Spectrum v. DUT Output Response for two-tone test . . . . . . . . . . . 34 vii 3.1 Development Work-Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.2 VCD File Visualized in the GTKWave Viewer . . . . . . . . . . . . . . . . . . . 47 3.3 The Test Vector Development Process . . . . . . . . . . . . . . . . . . . . . . . 48 4.1 Method used to Represent Connection to VDD and to GND in AUSIM . . . . . 55 4.2 Individual Fault Coverage vs Cumulative Fault Coverage Percentage . . . . . . 58 viii List of Tables 1.1 Advantages and Disadvantages of BIST[1] . . . . . . . . . . . . . . . . . . . . . 4 2.1 Built-In AUSIM Gates[9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2 FW3 and FW4 De nitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.3 Read Address Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.1 C17 Verilog Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.2 C17 ASL Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.3 Using the VerilogParser tool to convert a netlist to ASL . . . . . . . . . . . . . 43 3.4 Example VCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.5 Example Usage of ASLToVCD Tool . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.1 Simulated BIST Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.2 Fault Simulation Test Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.3 Individual Fault Coverage Results . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.1 Fault Coverage of BIST Sub-Systems . . . . . . . . . . . . . . . . . . . . . . . . 62 5.2 Fault Coverage of BIST Sub-Systems w/ Improvements . . . . . . . . . . . . . . 66 ix List of Abbreviations ADC Analog-to-Digital Converter AIM Auburn University SIMulator ASIC Application Speci c Integrated Circuit ASL Auburn Simulation Language ATPG Automatic Test Pattern Generator BIST Built-in Self-Test CAD Computer-Aided Design CORDIC COordinate Rotation DIgital Computer DAC Digital-to-Analog Converter dB Decibel DDS Direct Digital Synthesizer DFF Data Flip-Flop DFT Design For Testability DUT Device Under Test FPGA Field-Programmable Gate Array FR Frequency Response FW Frequency Word x HPCC High Performance Computing Cluster IC Integrated Circuit IM3 third-order inter-modulation term IMP Integer Multiple Period IO Input-Output IP3 Third Order Interception Point LTU Logarithmic Translation Unit LUT Lookup Table MAC Multiplier Accumulator MISR Multiple Input Signature Register NCO Numerically Controlled Oscillator NF Noise Figure ORA Output Response Analyzer PDT Potentially Detected PVT Process, Voltage, and Temperature Variations SNR Signal-to-Noise Ratio SPI Serial Peripheral Interface SSA Selective Spectrum Analysis TCW Test Control Word TPG Test Pattern Generator xi VCD Value Change Dump VHDL VHSIC Hardware Description Language VHSIC Very-High-Speed Integrated Circuit xii Chapter 1 Introduction The testing of embedded systems is a large eld with many di erent approaches and techniques. Some techniques work most e ectively for digital systems and others for analog systems. One approach is a hybrid test and is used to test a mixed-signal system { a system with both digital and analog circuitry. Mixed-Signal systems typically require the use of multiple testing techniques from both the digital and analog domains to be fully tested. In this chapter a short introduction to testing and relevant testing techniques for digital, analog, and mixed-signal systems is given so that the reader can develop a foundation for understanding the mixed-signal testing approach studied in this thesis. 1.1 Why Test Circuits According to Stroud[1] there are three phases of a product where testing is of critical importance: the design phase, manufacturing phase, and the system operation phase. Each phase of the product?s life cycle uses testing to achieve di erent goals. During the design phase of the product life cycle, the goal is to focus on nding and eliminating design errors. During manufacturing the goal changes and is focused on eliminating manufacturer defects, and nally the operation phase is focused on ensuring fault-free operation. All of these di erent testing goals work to improve the device by reducing costs, improving reliability, etc. 1.2 The Basics of Testing The basics of testing a circuit are similar during all phases of a product?s life-cycle: 1 Generate a set of input stimuli or test vectors Apply those vectors to the device-under-test (DUT) Compare the output of the DUT to the expected output for each input value Note any discrepancies as indication that there is an error in the device (a fault) In reality it is often more di cult to test circuits than this basic process makes it appear. One way to ease this di culty is by using design for testability (DFT) techniques to increase the observability and controllability of a device during the design process[1]. Stroud de nes observability and controllability in [1] as the following: \Controllability is the ease with which we can control a fault site and observability is the ease with which we can observe a fault site.[1]" Ultimately these properties determine the complexity of testing a circuit. As chips grow it becomes increasingly challenging to maintain an acceptable level of controllability and observability. According to [3]: \The growth rate in integrated circuit (IC) transistor count is far higher than the rate for IC pins and steadily reduces the accessibility of transistors from chip pins { a big problem for IC test.[3]" Large, modern circuits can contain billions of transistors and comparatively few input-output (IO) pins[3]. Without careful design considerations these properties can negatively a ect the testability of a device[1]. There are many di erent methods for physically testing a device. Each method varies in its requirements and has its own unique set of challenges, costs, and advantages. One traditional method of testing uses automatic test equipment. Automatic test equipment is commonly used during manufacturing to verify chips are manufactured without defects[3]. Unfortunately as the complexity and speed of ICs has increased, automatic testing equipment 2 has struggled to maintain an acceptable test coverage of performance-related defects[3]. To test these more complex circuits requires more advanced and higher speed automatic test equipment with additional IO capabilities[3]. [3] examines the cost of high-end automatic test equipment and nds they may become cost prohibitive for complex circuits. [2] estimates that without the inclusion of alternative testing approaches \tester costs will reach up to $20 million dollars in 2010". One such alternative to more expensive testing equipment is Built-In Self-Test (BIST). BIST describes the technique of designing a device to test itself[1] and can complement or eliminate the need for automatic test equipment[3]. 1.3 Built-In Self-Test [1] de nes BIST as a circuit which can test itself and determine whether it is \good" or \faulty." In essence this entails designing the circuit to perform all of the steps in section 1.2 on itself. [1] continues by outlining the basics of a BIST architecture. This simple architec- ture consists of several major components including a test pattern generator (TPG) which generates the input stimuli necessary to test the circuit and an output response analyzer (ORA) which compares the output of the circuit to the expected output for a given input value. Additionally there is circuitry which isolates the device under test (DUT) during testing as well as circuitry which controls the test during execution (Test Controller)[1]. BIST has many advantages and disadvantages when compared to other techniques. [1] quanti es these advantages and disadvantages in Table 1.1. In addition [4] performs a detailed economic analysis of including BIST in circuitry. [4] concludes that: \As the product develops from the IC to system level and its complexity in- creases, so does the complexity of successfully identifying a failure?s root cause. So it makes economic sense for system owners and perhaps system producers to implement BIST.[4]" 3 Table 1.1: Advantages and Disadvantages of BIST[1] Advantages Disadvantages Vertical testability (wafer to system) Area overhead High Diagnostic resolution Performance penalties At-speed testing Additional design time & e ort Reduced need for automatic test equipment Additional risk to project Reduced test development time & e ort More economical burn-in testing Reduced manufacturing test time & cost Reduced time-to-market Though in some cases BIST can negatively impact the area and/or performance of a circuit, the advantages of BIST and its ability to reduce test time and cost make it an excellent choice for testing devices[3]. 1.3.1 Digital Systems and Faults Faults in a system are characterized by a fault model. A common model used for digital systems (systems functioning at discrete ?1? and ?0? logic values) is the gate-level stuck-at fault model[1]. According to [1], the stuck-at fault model allows for faults at the input or output of a digital logic gate. These faults can cause the input or output to be stuck-at a logic value ?0? or ?1? regardless of which value is applied or expected. Figure 1.1 provides a truth table listing the faulty and fault-free output of an AND gate with its ?A? input stuck-at ?1?. The ?X? notation is used to indicate the location of the fault and the ?SA1? (or ?SA0?) designates whether the fault is a stuck-at ?1? or stuck-at ?0?[1]. The truth table given in Figure 1.1 shows how a single fault can change the behavior of a gate, often having a major impact on the overall behavior of the circuit. Since digital circuits will always produce the same outputs for a given set of inputs, any di erence between the expected and actual output can be exploited to determine if a circuit is functioning correctly[1]. In each clock cycle an input vector is applied and the output is compared with the expected output. If any output does not match the expected output then the chip is 4 considered faulty and is discarded. Unfortunately the storage required to hold each input and expected output vector can be signi cant for large or complex chips and while feasible for costly automatic test equipment, it is often impossible due to area considerations when using a BIST approach[13]. When using BIST the input vectors are often generated by the TPG circuitry deter- ministically, algorithmically, or pseudo-randomly (among other methods)[1]. This keeps the size of the TPG to a minimum and removes the need for a large memory or other means of storing every input vector. Likewise it is impractical to store every expected output pattern and compare it to the actual output in each clock cycle. To minimize storage requirements a signature is often used to compress the output of the circuit into a single vector. Instead of comparing each output at the end of each clock cycle, the signature is generated during the test and compared to the expected signature at the end of a test[1][13]. A signature can be generated in a number of di erent ways and may be as simple as a counter counting the num- ber of 1?s or 0?s which occur in the output, 1?s or 0?s counting, or as complex as using a large Multiple Input Signature Register[1]. The most appropriate signature generation method is dependent on the requirements and output of the design and can signi cantly impact the e ectiveness of a BIST approach. If a method is used which does not produce a suitably unique signature then faulty circuits can escape detection[1][13]. The use of an expected signature to compress the circuit output allows for a signi cant reduction in storage cost, as in most cases only a single comparison needs to be performed to verify the circuit[13]. Inputs Fault Free Faulty (AB) Output (Z) Output (Z) 0 0 0 0 0 1 0 1 1 0 0 0 1 1 1 1 Figure 1.1: AND Gate with Input A Stuck-At ?1? 5 Figure 1.2: Simple BIST for an AND Gate Returning to the example in Figure 1.1, a simple BIST can be constructed to test the AND gate. In Figure 1.2 a 2-bit counter is used as the TPG to generate all of the input patterns possible for a two input AND gate: \00", \01", \10", and \11". Also in the gure the output of the AND gate is connected to the Enable of an additional 2-bit counter to count each ?1? and produce a signature. The fault-free signature for this circuit is \01" since a normally operating AND gate should only produce a single logic ?1? when both its inputs are logic ?1?. If any input is stuck-at ?1? then it will produce at least one additional ?1?; if any input is stuck-at ?0? it will never produce a logic ?1?. These two conditions will produce invalid signatures. During execution of the BIST sequence, the TPG counts from \00" to \11" and the 1?s counter will increment for each ?1? occurring at the output of the gate. At the end of the sequence, if the value in the 1?s counter is not \01" then the gate is faulty. This example is greatly simpli ed and is missing required circuitry to start and stop the BIST as well as a method to isolate the inputs of the gate; however, it does demonstrate the general principal behind using BIST to test a digital circuit. 1.3.2 Analog Systems and Faults Analog systems function di erently than digital systems. Unlike a digital system which only has two discrete values, analog systems are continuous waveforms with multiple levels of magnitude and in various frequency bands[5]. In addition to the complexities of analog waveforms, analog components operate within a range of acceptable values[5]. This di er- ence makes testing analog components for defects (defect-oriented testing) signi cantly more 6 challenging and requires a more complex fault model. In analog components faults are clas- si ed as either parametric (soft-faults) or catastrophic (hard-faults)[11]. Parametric faults are those which a ect the performance of a speci c component causing it to operate outside of its expected tolerance range, for example an on-chip resistor value could vary 30% due to process, voltage, and temperature (PVT) variations. In contrast catastrophic faults are those which cause a component to fail, such as resistor which is no longer conductive and appears as an open circuit[11]. To catch analog faults due to PVT variations requires com- plicated and time consuming methods, such as Monte Carlo analysis, to determine di erent component values which allow fault-free circuit operation[5]. Compounding these issues is the fact that analog components \function collectively to perform the overall functionality of a given circuit and, as a result cannot always be treated as a collection of individual components[5]" and consequently are di cult to isolate for e ective defect-oriented testing[14]. Furthermore any circuitry added into an analog circuit may potentially interfere and change the operating range or output of that circuit[5]. This potential interference requires that any analog test- ing circuitry be carefully simulated and veri ed to ensure it does not negatively a ect the overall circuit performance. An example of a defected-oriented approach, oscillation testing is a testing approach which recon gures the analog CUT so that it oscillates; this oscilla- tion frequency is then measured and compared to an expected frequency. If the measured frequency falls outside the expected range, the circuit is considered faulty[12]. This method has been shown to be e ective for the detection of catastrophic faults and some parametric faults; however, it can require a signi cant amount of planning and design e ort as it may signi cantly impact the analog circuitry[12][5]. A simpler (and preferred[5]) method for testing analog components is via functional testing. [6] de nes functional tests as: \... those which measure a circuit?s dynamic behavior ...[6]" 7 Functional or speci cation testing is achieved by performing a set of tests to determine if a system is operating correctly as de ned by its speci cations. This approach is used to test the entire analog system collectively instead of attempting to understand the impli- cations of speci c faulty components[14]. Speci cation testing may include the testing of important analog characteristics such as frequency response, linearity, and signal-to-noise ratio (SNR)[5]; however, the characteristics which are important to test will vary between designs. To adequately test most analog components, multiple measurements of several dif- ferent characteristics must be taken, as a single characteristic is usually not su cient to ensure fault-free operation[14]. This process may require extra development time as test procedures must be developed to test each characteristic and additional time is required to perform each test[14]. 1.3.3 Mixed Signal Testing In a mixed-signal environment both digital and analog systems coexist and interact. Due to the previously discussed di erences in testing analog and digital systems, the testing of the analog and digital sub-systems is generally developed separately and performed using using di erent test procedures and approaches[14]. Ideally a designer would like to limit any duplicate work and take advantage of a BIST approach which can be used to test both the analog and digital sub-systems. [1] de nes a BIST approach to testing mixed-signal systems shown in Figure 1.3. This BIST uses a digital BIST approach to functionally test the analog sub-system by measuring certain analog characteristics which can be used ensure that the circuit is operating within its speci cations. This architecture is largely digital and thus can be integrated into the digital circuitry already in the system with minimal analog overhead. This prevents excessive interference with the analog circuitry, excluding analog multiplexers which facilitate the sending and retrieving of test values to and from the analog sub-system[1]. To test the analog circuitry, the BIST uses the existing digital to analog converter (DAC) to convert 8 Figure 1.3: BIST Approach for Mixed-Signal Systems[1] digitally generated test patterns from the TPG to analog signals and the existing analog to digital converter (ADC) to convert the analog response back into the digital domain for analysis by the ORA[1]. Figure 1.3 shows a basic version of this mixed-signal BIST approach using two multi- plexers. In this case one multiplexer is placed before the DAC to select between the BIST patterns and the system circuitry and a second multiplexer is positioned at the input of the analog system to select between the system level inputs and the analog outputs. These two multiplexers form a loop allowing the generated TPG pattern to be converted into an analog signal and propagate through any analog circuitry before being routed back through the analog inputs to the DAC for analysis by the ORA. While this implementation does allow testing of all analog components, it does not allow a high level of diagnostic resolution[5]. To obtain a higher diagnostic resolution, additional analog multiplexers can be added to further partition the system. Figure 1.4 shows an example of an implementation with three separate multiplexed or loopback paths to facilitate a higher level of diagnostic resolution. In Figure 1.4 the shortest loop, the short dashed path, is a digital only path (digital loopback path) which can be used to test that the digital BIST is fault-free. The next loopback path, the dashed path, connects the output of the DAC to the ADC bypassing any of the analog circuitry (from here on referred to as the bypass path). This allows the veri cation of the 9 Figure 1.4: Mixed-Signal BIST with Multiple Loopback Paths ADC and DAC separately from the analog circuit. The nal path is the analog test path, the dotted path, and is similar to the path in Figure 1.3 in that it is responsible for testing the analog circuitry. There is no limit to the number of multiplexers that can be added to the system other than the increase in area overhead[5]. Additional analog multiplexers could be added to the example in Figure 1.4 to further partition the analog circuitry and resolve faulty behavior to a speci c portion of the analog DUT. In Figure 1.4 the digital loopback path is of particular importance. [7] has shown that a digital loopback path is highly advantageous when testing the digital portion of the BIST circuitry. When testing in a digital only environment a circuit produces exactly one output signature for a given set of inputs. Veri cation of this signature allows for a quick an e cient method of testing digital circuits. In the case of the BIST when no digital loopback path is present, the digital TPG outputs are not directly observable and can only be observed after conversion via the DAC and reconversion via the ADC. This will cause variations in the output signature due to the inherent variations and noise which occur in analog signals and circuits. To account for these variations, a range of acceptable output signatures must be considered instead of an exact signature[7]. Unfortunately allowing for a range of good signatures lowers the observability of the digital portion of the mixed-signal BIST and lowers the maximum fault coverage which can be achieved. Figure 1.5 shows a comparison of the maximum, digital fault coverage which can be 10 Figure 1.5: Fault Coverage v. Acceptable Value Range[7] achieved for several di erent ORA designs when di erent ranges of acceptable circuit signa- tures are allowed. In the gure, three di erent 8-bit ORA accumulator designs are considered (ORA design is discussed in more detail in the next chapter). Figure 1.5 shows that regard- less of ORA design a (in some cases signi cant) reduction in the maximum achievable fault coverage is to be expected when a range of good signatures is considered instead of an exact signature. Thus the only way to achieve the maximum possible digital fault coverage is to not allow a range of acceptable circuit signatures. This requires that no analog circuitry be involved when performing a test; consequently, the digital loopback path must be used[7]. Performing a digital-only test using the digital loopback path separates the digital and analog systems when testing the system for faults. This allows for the usage of tools and techniques which target digital components separately from those used to generate the analog functional tests on the analog sub-system[7]. When the three loopback paths shown in Figure 1.4 are present, the test procedure should be performed rst over the digital loopback path to verify the digital BIST, then using the bypass path to verify that the ADC and DAC path are functioning correctly, and nally over the entire circuit to verify the analog DUT[5][7]1. 1Several additional considerations must be made when verifying the analog DUT such as the impact the of the ADC/DAC or any up/down converters may have on DUT performance 11 Though this technique still requires separate testing of the analog and digital circuitry, it is an improvement over the previously discussed method since the same BIST circuitry can be used to test both the digital and analog circuitry[1]. This limits the amount of work that must be duplicated to the determination of which tests must be run and the expected values or range of values that must be considered. Furthermore the basic procedure for testing the analog and digital circuits is the same (the only di erences being which loopback path is selected and the actual test being performed) which will limit the di erences between test sessions. 1.4 Summary In this chapter a high-level look at both digital and analog systems has been given as well as the challenges of testing these systems for faults. The concept of BIST has been presented along with its advantages and a simple BIST architecture. In addition the challenges of test- ing mixed-signal systems have been discussed and a basic mixed-signal BIST model has been given along with an overview of the di culties of testing the BIST without a digital loopback path. In the next chapter a more detailed explanation of fault simulation and of the speci c mixed-signal BIST approach studied in this thesis is given. This approach builds upon the simple architecture discussed in the previous section and addresses the challenges discussed in Section 1.3.2. Building upon this explanation, Chapter III explores the preparation neces- sary for simulating the mixed-signal BIST including necessary conversions and veri cation. Chapter IV explores the main topic of this thesis: testing the actual mixed-signal testing circuitry to determine its e ectiveness and the level of fault coverage achievable. Methods for improving the BIST and the maximum achievable fault coverage are explored before a summary and conclusions are given in Chapter V. 12 Chapter 2 Background Before discussing the fault simulations performed in this thesis, it is important to have a more thorough understanding of fault simulation techniques. In this chapter, an overview of several fault simulation techniques will be given as well as an overview of the bridging fault model which models faults between nets. Following this discussion a more detailed outline of the simulation and design process will be given. Next the fault simulator AUSSIE is detailed which is used to evaluate the fault coverage of the mixed-signal BIST approach studied in the rest of this thesis. This chapter concludes with a detailed discussion of the architecture of the mixed-signal BIST and its capabilities. 2.1 Fault Simulations Knowledge of the basic concepts of simulation is important to understanding how fault simulations are performed. The simulation process begins with a netlist. The netlist rep- resents the circuit design to be simulated and de nes the structure of the circuit at the gate level. This includes both the gates used by the circuit as well as the interconnections between those gates[19]. The generation of a netlist is discussed in more detail in Section 2.1.3. According to Section 1.2, the next step is to generate a set of test vectors to be used to stimulate the circuit during testing. Test vectors may be generated automatically us- ing Automatic Test Pattern Generation (ATPG) software [19] or manually by the designer. When performing fault simulations, these vectors should ideally exercise as much of the in- ternal circuitry of the design as possible so that high fault coverage can be achieved (fault coverage is discussed towards the end of this section); consequently, test vectors generated using ATPG can be advantageous as they typically guarantee a very high fault coverage[19]. 13 If vectors are created manually by the designer then it may be necessary to perform a logic simulation of the circuit to ensure the vectors are valid and to obtain the fault-free output of the circuit (when using ATPG the fault-free output is generally recorded along with the test vector set). With both the test vector set generated and fault-free output of the circuit known, fault simulations can begin. Fault simulation starts with the selection of a fault model which characterizes the fault behavior to be simulated. There are several di erent fault models used for digital circuits, but the focus of this thesis will be the gate-level stuck-at fault model which was introduced in Section 1.3.1. The stuck-at fault model has a low computation cost and accurately rep- resents the behavior of most faults seen at the gate-level of digital circuits[1]. Other models exist which characterize di erent fault behavior and have their own sets of advantages and disadvantages. The bridging fault model, which will be introduced in Section 2.1.2, focuses on faults which occur between nets as opposed to those that occur at gate inputs and outputs and is used to accurately simulate faults that occur in circuit routing[17]. The transistor fault model targets faults which occur at the transistor level. This level of detail makes it more computationally expensive to simulate compared to the gate-level model; however, this model more accurately represents the behavior of faults which occur during the manufac- turing process[15] and may detect faults which are not detectable using the stuck-at fault model. Regardless of its accuracy, it is more common to use the gate-level stuck-at model for digital fault simulations since it is less computationally expensive and is acceptably accurate at modeling the behavior of common defects in digital systems[15]. Once a fault model is chosen each fault must be simulated and the output of the circuit recorded. The output of the faulty circuit is compared to the fault-free output and if any discrepancy is found then the fault is recorded as detected. Similarly if the output of the circuit is always the same as the fault-free circuit then the fault is not detected[15]. In some cases a fault may be considered potentially detected; this special case is caused by an unknown logic value occurring in the circuit and is an artifact of simulation. An unknown 14 logic value will occur if a circuit element is not initialized properly[1]. In physical hardware the value must be either logic ?0? or logic ?1?; however, in simulation it is unknown which logic value it will initialize to which causes the detection of the fault to be uncertain in simulation[1]. The percentage of faults detected is said to be the fault coverage of the test vector set[15][1]. Fault coverage is typically calculated using Equation 2.1 where D is the number of detected faults, P is the number of potentially detected faults, Y is the probability of potentially detected faults being detected, X is the number of undetectable faults and T is the total number of faults simulated[1]. FC = (D + (Y P))(T X) (2.1) Undetectable faults are faults which are impossible to detect by any test vector. These faults are often caused by design issues such as re-convergent fan-out and redundant logic[1] and since they cannot be detected are typically not considered when calculating fault coverage. In the equation Y is typically :5 denoting that there is a 50% chance of a potentially detected fault being detected. This represents the chance of an uninitialized logic value initializing to the logic value required for detection when testing is performed in physical hardware. This coe cient may be changed to represent a higher or lower chance of detecting potentially detectable faults[1]. For a large number of faults or large number of test vectors the simulation process can take a large amount of time to complete. In the worst case the time required to complete a fault simulation is shown in Equation 2.2, where Tvec is the time required to simulate a single vector, Nvec is the number of test vectors to be simulated, and Nflts is the number of faults to be simulated. Time = Tvec Nvec Nflts (2.2) There are a couple of methods which can decrease the amount of time taken to simulate a list of faults. One common method is fault dropping. When using fault dropping a fault is only 15 simulated until a discrepancy between the output of the circuit and the fault-free output is found. At that point the fault is recorded as detected, simulation of the fault is halted, and a new fault is simulated[1]. The time required to perform fault simulation when using fault dropping is shown in Equation 2.3 where Nflts is the number of faults to be simulated, Tvec is the time required to simulate a single vector, and Nveci is the number of vectors simulated for the ith fault. Time = NfltsX i=0 Tvec Nveci (2.3) In the case where the ith simulated fault is detected early in the simulation, Nveci will be small, shortening the simulation time for the fault; in contrast, if the ith fault is detected toward the end of the simulation or not detected at all then Nveci will be approximately Nvec, causing little to no savings in simulation time for the fault[1]. Further speed up can be obtained by performing parallel fault simulation. Equations 2.2 and 2.3 show the time required to perform serial fault simulations where a single fault is simulated at a time. To decrease the time required for simulation, it is bene cial to simulate multiple faults concurrently1. This is a common approach to decreasing simulation time and at least in the case of gate-level stuck-at fault simulation, does not require any additional considerations by the user[18]. Commonly 32 faults2 are simulated in parallel though di erent simulators may have options to simulate more or less faults[18]. Equation 2.4 de nes the worst case time required to perform parallel fault simulation and Equation 2.5 de nes the time required to perform parallel fault simulation with fault dropping, assuming 32 faults are simulated in parallel (in this case Nvec is the number of vectors required to detect all faults in a parallel group). Time = Tvec Nvec dNflts32 e (2.4) 1This does not mean perform the simulation of multiple faults in the same circuit simultaneously; but instead, it means perform multiple simulations in parallel each with a single fault[18] 2An integer is 32-bits on a 32-bit machine; consequently, simulating 32 faults allows for the use of the integer data type in the simulator and makes parallel fault simulation easier to implement[18] 16 Time = dNflts32 eX i=0 Tvec Nveci (2.5) Using both fault dropping and parallel fault simulation can greatly decrease the required simulation time for a large circuit. Due to this bene t both of these methods are used in the fault simulations performed in this thesis. The next section discusses further optimizations which can be performed to reduce the number of faults simulated and consequently the time required to perform simulation. 2.1.1 Collapsed vs Uncollapsed Faults When performing fault simulations certain optimizations can be made to improve the e ciency of the simulation. One such optimization is fault collapsing. With the gate-level single stuck-at fault model, each gate input and output can be stuck-at logic ?0? or logic ?1?. For elementary logic gates this leads to many faults which produce identical faulty behavior; these faults can be said to be equivalent[15]. During simulation these equivalent faults can be collapsed, requiring only a single fault out of the group of equivalent faults to be simulated[15]. Depending on the circuit this can substantially reduce the number of faults to be simulated while still accurately representing the faults which can occur in the circuit[15]. Figure 2.1 shows an example of fault collapsing. The NOR gate in the gure has six uncollapsed faults; however, when either input is stuck-at ?1? it is equivalent to the output being stuck-at ?0? and vice versa (since a logic ?1? is the controlling input for a NOR gate) which results in four collapsed faults. These equivalent faults are shown in bold in the gure. [1] states that the number of collapsed faults for any elementary logic gate with greater than one input is K + 2 where K is the number of inputs to the gate. This is certainly apparent with the NOR gate in Figure 2.1, where K + 2 = 4. Additionally when the output of a gate is connected to exactly one input of another gate, a fault occurring at the output of the source gate is indistinguishable from the same fault occurring at the input of the connected gate[1]. These faults can be structurally collapsed together which leads to a large chain of 17 Figure 2.1: NOR Gate with Six Uncollapsed and Four Collapsed Faults Figure 2.2: Structural Fault Collapsing Performed on a Group of Logic Gates faults being collapsed such as the example in Figure 2.2[1]. In the gure groups of equivalent faults are shown with a line drawn between them. Unfortunately due to the limitation of the single stuck-at fault model, which does not allow multiple faults to appear in the circuit simultaneously (as opposed to a multiple fault model which allows this), the fan-out stem in Figure 2.2 cannot be collapsed[15]. Since the output of the inverter fans-out to the input of two di erent gates, collapsing these faults would make a fault appear to be on both the input of the AND gate and the OR gate simultaneously which violates the single stuck-at fault model and is not allowed[15]. Counting the faults in the gure, there are a total of 22 uncollapsed faults and a total of 12 collapsed faults, a signi cant reduction. In the single stuck-at fault model the number of uncollapsed faults in a circuit are 2 Gio where Gio is the number of gate inputs and outputs in the circuit[1]. In contrast the number 18 of collapsed faults can be determined by Equation 2.6 where Po is the number of primary outputs, Fo is the number of fan-out stems, Gi is the number of gate inputs, and Ni is the number of inverters in the circuit[1]. F = 2(Po + Fo) + Gi Ni (2.6) As an example, the BIST model evaluated in this thesis has a total of 83386 uncollapsed faults. It has 30 primary outputs, 4436 fan out stems, 27861 gate inputs, and 2740 inverters. By using Equation 2.6 the number of collapsed faults in the BIST circuitry is 34053. This results in a 59% reduction in the number of faults to be simulated. [1] discusses the advantages and disadvantages of using the collapsed or uncollapsed fault set for simulation purposes. According to [1] it is obvious that the simulation time can be greatly reduced by using the collapsed fault list. This is very advantageous as more simulations can be performed in the same amount of time. However, [1] does say that the uncollapsed fault list more accurately represents the possible defects which occur during manufacturing. Due to this di erence, the fault coverage obtained with the collapsed fault list may be di erent than the coverage according to the uncollapsed fault list by a few percent[1]. Through the accuracy of the uncollapsed fault list is preferable, the collapsed fault list is more often used due to its decreased simulation time[1]. 2.1.2 The Bridging Fault Model Though the focus of this thesis is gate-level stuck-at fault simulations, additional models may be of interest for future work; speci cally bridging fault simulations are commonly performed to assess the fault coverage of faults which occur between nets. There are a number of di erent fault models which describe the behavior of bridging faults, faults where two nets are shorted together due to a manufacturing defect, including the Wired OR/AND, Dominant, and Dominant OR/AND fault model[17]. In this section we will focus on the 19 dominant bridging fault model, as it is the most commonly used[1]. For many years it was a commonly held belief that a high stuck-at fault coverage provided a high bridging fault coverage; however, more recent work has shown that this is not always the case and that it is important to perform these simulations separately to ensure that an acceptably high bridging fault coverage is achieved[16]. Unfortunately bridging fault simulation can be signi cantly more time consuming than stuck-at fault coverage due to the large number of fault sites that must be considered. Equation 2.7 shows the calculation to determine the number of possible bridging fault sites in a circuit, where N is the number of nets in the circuit[1]. FB = (N2 N)=2 (2.7) Like the previous section, the BIST model can be used to give a sense of scale. The BIST studied in this thesis has 15221 nets; applying Equation 2.7 results in 115,831,810 bridg- ing fault sites. Depending on the bridging fault model up to four faults (when using the Dominant AND/OR model[17]) are possible at each fault site, so this means that the worst case number of faults to be simulated is almost 500 million! Similar to the gate-level model, bridging faults can also be structurally collapsed, which can substantially lower the num- ber of faults to be simulated (using the same circuit the number of collapsed faults was approximately 30K when using the more common dominant model). As discussed in the previous paragraph, there are di erent models to de ne the types of bridging faults which can occur. Since it is the most common, the dominant bridging fault model will be discussed. According to the dominant bridging fault model, two di erent faults can occur at a bridging fault site: net A can dominate net B or net B can dominate net A. Whichever net is dominated will be a ected by the other net?s current logic value; this occurs due to the dominant net having a stronger drive transistor[17]. Figure 2.3 shows an example of a dominant bridging fault where net A dominates net B, along with a truth table containing the fault-free and faulty behavior of the circuit. When net B has the same logic 20 Net A Net B Faulty? Net B? 0 0 0 0 1 0 1 0 1 1 1 1 (A) (B) Figure 2.3: Bridging Fault where Net A Dominates Net B value as net A its output is una ected; however, when the logic value of net B is di erent than that of net A, net B?s logic value will be changed to that of net A. The rst two columns of the truth table in Figure 2.3 represent the fault-free behavior of net A and net B and the remaining column B? represents the faulty output of net B when net A dominates it. In the second row when net A is a ?0? and net B should be a ?1?, B? is instead a ?0? since it is dominated by net A. Likewise in the third row when net A is a ?1?, net B should be a ?0? but instead is a ?1? due to the in uence from net A. Bridging faults are important to address during the design of a circuit. Unfortunately they can be computationally expensive and can be di cult to test and observe[17]. Bridging faults were not simulated in this thesis though it is a target of future work. 2.1.3 Design Process The design of a digital circuit typically starts with a behavioral description of a circuit. This is generally done in a high-level design language such as Verilog or VHSIC Hardware Description Language (VHDL) and usually will not include any implementation details of the circuit[19]. This code is then fed into a synthesis computer-aided design (CAD) tool which will interpret the behavioral description of the design, combine it with parameters such as the implementation technology, timing information, and/or area constraints, and ultimately produce a gate-level netlist of the design[19]. Following this step a place-and- route tool takes each gate and its interconnections and decides where on the silicon chip (or 21 in a eld-programmable gate array (FPGA) or other programmable device) to place the gate so that any timing and area constraints can be achieved. Once completed the design is said to be \post-layout" indicating it is ready for fabrication[19]. Logic simulation is important during each step of this design process, so that the circuit behavior can be veri ed before fabrication[19]. During the behavioral modeling phase, design veri cation is performed to ensure the description of the circuit is correct and that no design errors have been made. Simulation is also performed after synthesis has taken place to verify that the circuit?s behavior is still correct after it has been implemented at the gate-level and to investigate any potential timing problems with the circuit[19]. Following post-synthesis simulation, post-layout simulation is also performed. Post-layout represents the nal version of the circuit to be fabricated. Simulation can be performed using the circuit?s nal timing information and can incorporate many di erent performance characteristics. Post-layout is the nal opportunity to verify a circuit is functioning correctly before fabrication[19]. In contrast to logic simulation, fault simulation is not typically performed at any of the high-level steps in the design process[1]. Ideally the post-layout netlist should be used for all fault simulations, since the layout can have a signi cant impact on the faults in a circuit[15]. This is especially true of bridging fault simulations, as routing is not nalized until the layout stage and thus cannot be accurately performed earlier in the design process[15]; however, other fault models may be simulated earlier in the design veri cation process[1]. In this thesis all fault simulations of the BIST are performed using the post-layout design. As discussed in the next chapter, this does present a challenge since the post-layout design produced by the CAD tools is a Verilog netlist which is not a format used by the fault simulator. As such a tool was written to convert a Verilog netlist to the ASL netlist format recognized by our simulator AUSIM (ASL and the fault simulator AUSIM will be discussed in Section 2.2). 22 2.2 AUSIM Fault Simulator For the fault simulations performed in this thesis the Auburn University SIMulator or AUSIM is used. Developed by Dr. Charles Stroud[8][9], AUSIM can perform both logic and fault simulations. In addition it supports multiple fault models including the gate-level stuck-at and multiple bridging fault models[8]. It supports all of the previously discussed methods of improving simulation time including fault collapsing and parallel fault simulation of both bridging and stuck-at faults[8]. A detailed description of the operation and usage of AUSIM will not be given in this thesis; however, more information can be found in [8][9]; instead, the focus of this section is an overview of the Auburn Simulation Language or ASL which is the netlist format used by AUSIM. 2.2.1 ASL Netlist Format Before a circuit can be simulated by AUSIM it must be in a format that AUSIM can understand. The Auburn Simulation Language (ASL) is the circuit description used by AUSIM[9]. ASL is used to provide a textual representation of a circuit at the gate-level to the simulator. This gate-level netlist is used to describe each connection and gate used in a circuit design and allows the simulator to build a representation of the circuit under test. ASL begins with a top-level circuit declaration. This declaration de nes the name of the circuit and uses the in and out keywords to de ne the inputs and outputs to the circuit[9]. An example circuit is given in Figure 2.4. Figure 2.4 A is a half-adder which takes in two inputs and outputs a sum (S) and carry bit (C); the corresponding ASL description is given in Figure 2.4 B. As can be seen from the gure the circuit declaration is started by the ckt keyword[9]. Each keyword in ASL is followed by a ?:? character[9]. Following the ckt keyword is the name of the circuit in this case \HF". Following that, the primary inputs and outputs are declared using the in and out keywords. Each statement in ASL is terminated using a ?;? character[9]. After the circuit statement the gate-level description of the circuit is given. The format of each gate is similar to the format of the circuit statement: 23 Half-Adder Circuit 1. # Half-Adder ; 2. ckt: HF in: A B out: S C ; 3. xor: X1 in: A B out: S ; 4. and: A1 in: A B out: C ; (A) (B) Figure 2.4: A Half-Adder Circuit GATE: Name IN: In1 In2... InN OUT: Out1 Out2... OutN ;[9] All gate declarations in ASL follow this simple syntax. All of the elementary logic gates (AND, OR, XOR, etc..) as well as the data ip- op (DFF) and two input multiplexer are built-in to AUSIM and available to all circuits[9]. Table 2.1 shows each built-in gate and its inputs and outputs. Table 2.1: Built-In AUSIM Gates[9] AUSIM Keywords Gate Example AND AND: a1 in: i1.. iN out: Z ; OR OR: o1 in: i1.. iN out: Z ; NAND NAND: na1 in: i1.. iN out: Z ; NOR NOR: no1 in: i1.. iN out: Z ; NOT NOT: n1 in: A out: Z ; XOR XOR: x1: in: i1... iN out: Z ; MUX2 MUX2: m1 in: i1 i2 s1 out: Z ; DFF DFF: d1 in: CLK D out: Q Qn ; It is important to understand that custom gates can be implemented hierarchically and used in a similar syntax. To do this one must use the subckt command. While an ASL le can only have a single circuit declaration, it can have any number of sub-circuit declarations[9]. 24 Each sub-circuit has its own set of top-level inputs and outputs and its own gate-level net- list. Once de ned the name of the sub-circuit can be used as a gate and be instantiated elsewhere in the circuit description. These sub-circuit de nitions can be used to de ne the behavior of more complex CMOS standard cell gates such as the OAI222 etc. For the BIST discussed in this thesis, an entire library of sub-circuits was created to support simulation. This library is required for simulation and de nes many of the complex CMOS logic gates and several technology speci c standard cells used by the BIST circuitry. 2.3 BIST Architecture The BIST architecture analyzed in this thesis is a mixed-signal BIST approach which uses Selective Spectrum Analysis (SSA) to functionally test analog circuitry[26]. SSA has many advantages when used to measure frequencies in an analog spectrum. First it bene ts from being a largely digital approach and integrates well into a BIST environment. In addition, due to SSA measuring only a single frequency point at a time, the hardware overhead is much lower when compared to alternative approaches such as FFT[27]. However, since only a single frequency is measured at one time, test time can become long when a large number of frequencies are of interest. Likewise SSA can prove very advantageous when only a few frequencies are of interest in the analog spectrum, such as when performing a two-tone linearity measurement[26]. Furthermore, [24] discusses a number of optimizations (some of which will be discussed in Section 2.3.2) which when used can greatly reduce the time required to perform a measurement. A block diagram of the basic architecture of the SSA BIST approach can be seen in Figure 2.5. This BIST architecture is capable of measuring a number of di erent analog char- acteristics including the frequency response and linearity (also known as third-order intercep- tion point or IP3) of a DUT[22]. In addition, by sweeping through a frequency spectrum both Signal-to-Noise Ratio (SNR) and Noise Figure[21] can be measured. The architecture in Fig- ure 2.5 consists of a Direct Digital Synthesizer (DDS) based TPG, Multiplier-Accumulator 25 Figure 2.5: General BIST Architecture[20] (MAC) based ORA, and test controller (not shown). Also not shown in the gure is an on-chip calculation circuit which will be discussed in Section 2.3.3. The following sections will discuss each of the major BIST components and discuss how each test is performed and calculated so that the reader can develop an understanding of the capabilities and uses of this BIST architecture as it pertains to this thesis. 2.3.1 DDS Based TPG DDS is a popular technique for generating analog frequencies on chip. Compared to other techniques of frequency generation it o ers the ability to produce very precisely con- trolled frequencies which can be rapidly manipulated and changed using digital inputs[28]. In addition with adequate design considerations, DDS designs can have extremely ne fre- quency and phase resolution. The BIST TPG is DDS based consisting of three numerically controlled oscillators (NCOs) which utilize the existing DAC in the mixed-signal system to generate the analog waveforms for testing[20]. Each NCO utilizes a phase accumulator and sine/cosine lookup table (LUT) to produce a frequency based on a supplied frequency word fw. The supplied frequency word is accumulated each clock cycle by the phase accumula- tor. The value of the phase accumulator is truncated and used as a lookup address to nd the appropriate sine or cosine value in the LUT. The value retrieved from the LUT is then 26 Figure 2.6: Block Diagram of DDS converted by the DAC into an analog signal. The basic steps of this process are shown in Figure 2.6. The resulting frequency generated by the NCO is determined by Equation 2.8, where fgen is the generated sine wave frequency, fw is the supplied frequency word, fclk is the system clock frequency, and n is the number of bits in the frequency word. The max- imum frequency resolution of the DDS is shown in Equation 2.9 and is directly related to the number of bits used for the frequency words, n. fgen = fw fclk2n (2.8) fres = fclk2n (2.9) As shown in Figure 2.5, there are three NCOs. The rst two NCOs are used to generated frequencies which stimulate the analog DUT. There are two possible con gurations for these two NCOs when testing the analog DUT. In case one, only a single tone needs to be generated for testing. This case is used when performing measurements such as frequency response at a given frequency (measurements will be explained in more detail in Section 2.3.3[26]). When only a single tone is necessary, both NCOs are supplied the same frequency word and produce the same frequency[24]. This frequency output is then selected and passed into the DUT. In the second case, two di erent tones are generated, such as when a linearity measurement is performed. In this case NCO1 is assigned the rst frequency word and NCO2 is assigned the second. The outputs of these two NCOs are added together so that the two sine waves are super-imposed before being converted by the DAC[24]. The third NCO NCO3 is used by the ORA. NCO3 is slightly di erent from both NCO1 and NCO2 in that it produces both the sine and cosine output for a given frequency word. These two outputs are used 27 by the ORA to measure the in-phase and out-of-phase components of the DUT response at a frequency of interest (the ORA operation is explained in detail in the next section)[24]. These three NCOs allow for up to two separate frequencies to be generated simultaneously as well as any frequency of interest to be measured by the ORA. When coupled with the test controller, this architecture is very powerful and, as will be discussed shortly, can be used to measure several signi cant analog characteristics. 2.3.2 ORA Multiplier-Accumulators After generating the analog frequencies required to stimulate the DUT, the output of the DUT is analyzed by the BIST ORA. The ORA consists of two multiplier-accumulators, DC1 and DC2[22]. By multiplying the response of the DUT by the cosine wave output of NCO3, DC1 will accumulate the out-of-phase component of the DUT response at the frequency of interest, !. Likewise by multiplying the response of the DUT by the sine wave output of NCO3, DC2 will accumulate the in-phase component of the DUT response at !. The accumulator values of both DC1 and DC2 can be described in Equations 2.10 and 2.11. In these equations nTclk represents the sampled output response of the DUT[27]. DC1 = X n f(nTclk) cos(!nTclk) (2.10) DC2 = X n f(nTclk) sin(!nTclk) (2.11) It has been shown in [24],[27] and others that these calculations are similar to an FFT. Unlike the FFT, the entire frequency domain is not computed simultaneously; instead, only a single frequency is measured for each accumulation[27]. When more than one frequency ! is of interest, each must be measured through successive accumulations (each accumulation at a single frequency will be referred to as a single measurement). The DC1 and DC2 results of a measurement can be used to obtain both the amplitude and phase of the signal at the measured frequency !. The amplitude calculation is shown in 28 Equation 2.12 and the phase calculation is shown in Equation 2.13[24]. A(!) = q DC21 + DC22 (2.12) (!) = tan 1 DC2DC 1 (2.13) To obtain these measurements a hardware method must be used to calculate arc-tangent function used in Equation 2.13 and the square and square-root functions used in Equa- tion 2.12. These calculations are performed using on-chip calculation circuitry and will be discussed in the next section. Before discussing the calculation circuitry, it is important to understand how the amount of accumulation time required for a measurement is determined. The accumulation time is exceptionally important to achieving an accurate measurement due to potential AC calcula- tion errors which are accumulated[24]. A large body of work has been devoted to determining both the appropriate length of time to accumulate and a method for determining the length of time e ciently in hardware. [24] and [20] discuss in detail the complexity and importance of stopping accumulation at the correct moment to reduce error. As it is only pertinent to this thesis due to its relation to fault simulation time, it will only be brie y discussed here. More details can be found in [24]. As mentioned, there is the potential for errors to occur in an SSA approach due to AC errors accumulating in the ORA[24]. One method of minimizing or eliminating these AC errors requires that the BIST accumulate for a very long period of time (referred to as free-run accumulation). Unfortunately the amount of time required for accumulation would be prohibitively high[20]. [24] discusses a method of reducing the required accumulation time while still retaining the accuracy of free-run accumulation. This method requires that accumulation occur for an exact number of clock cycles, determined by the integer multiple period (IMP) of the frequency being measured. Though there are intricate complications 29 associated with determining the IMP in hardware, it will be discussed at a high-level so that the reader can understand how measurement time is a ected. As explained in [20], if accumulation is stopped at a multiple of the interested frequency?s period (n 1f) the AC error will be greatly reduced resulting in a very accurate measurement. This does not mean that frequencies with the shortest periods result in the shortest tests; instead, it is a function of both the frequency word chosen and the width of the phase accumulator which determines the length of the test. More speci cally the length of the test is determined by the e ective number of bits used in the DDS by the frequency word (Meff). Equation 2.14 shows how the e ective number of bits is calculated, where Mfull is the bit-width of the phase accumulator and m is the bit position of the least signi cant ?1? in the given frequency word(s)[24]. The resulting number of accumulation clock cycles is determined by 2Meff. Meff = Mfull m (2.14) For example, if given a four-bit wide phase accumulator and the frequency word 1010 (or decimal 10), Meff would be equal to 4 1 or 3. This makes the required number of clock cycles 23 or 8. In hardware this corresponds to the moment when all bits of the phase accumulator are logic ?0? and the carry-out bit is a logic ?1?[24]. For large phase accumulators the number of clock cycles to accumulate can vary greatly depending on the frequency word(s) chosen. In the studied BIST, 16-bit phase accumulators are used. In this case the di erence between the shortest possible accumulation time of two clock cycles and the longest possible accumulation time of 65535 clock cycles is signi cant. Consequently frequency words should be carefully chosen so as to minimize test time when test time is of concern[24]. The previous example represents the simple case where only a single tone is of inter- est. For a multi-tone test (one where either two-tones are generated or where the measured tone is not the same as the generated tone) the IMP must be the common IMP of all 30 Figure 2.7: The OR Chain Which Calculates the Number of Clock Cycles from the Logical OR of All Frequency Words frequency words[24]. In this case logically OR?ing all frequency words together then calcu- lating the resulting Meff number of bits will result in the number of clock cycles required for accumulation[24][20]. In hardware a similar method is used which directly calculates the number of clock cycles required for accumulation. After rst OR?ing all frequency words together, an or-chain is used to determine the number of clock cycles to accumulate. Figure 2.7 shows this or-chain. As shown in the gure, if a logic ?1? is in the LSB of any of the frequency words, it will result in the maximum number of clock cycles for the given phase accumulator width. Using the resulting clock cycle count, the BIST uses a clock cycle counter to determine when to stop accumulation on an IMP and minimize the error. Once accumulation has completed the calculation step is triggered and the results are handed o to the calculation circuitry for further processing. 2.3.3 On-Chip Calculation Circuit The ORA portion of the BIST accumulates the in-phase and out-of-phase components into DC1 and DC2 at the frequency of interest. Using these values more advanced measure- ments of special analog characteristics such as linearity, SNR, and NF can be performed. To do this, DC1 and DC2 must be transformed mathematically into the relative magnitude and phase using Equations 2.12 and 2.13[25]. Traditionally this can be performed o -chip using 31 a mathematical tool such as MATLAB; however, the BIST architecture discussed in this thesis uses an on-chip calculation circuit to perform both of these calculations and to per- form multi-measurement tests on-chip[25]. First the calculation Coordinate Rotation Digital Computer (CORDIC), which converts the DC1 and DC2 values to the magnitude and phase values, will be discussed. [25] discusses the original implementation of the calculation circuitry for the BIST ap- proach. Shown in Figure 2.8 the original calculation circuit uses a custom CORDIC de- veloped in [25] to perform the operations from Equations 2.12 and 2.13 and determine the magnitude and phase from the DC1 and DC2 values; TC indicates control signals from the test controller. The CORDIC algorithm, explained in depth in [25], is a well-known, low- overhead approach to approximating a number of linear, circular, and hyperbolic functions using successive approximation and inexpensive digital operations such as shift, add, and subtract. Due to its low area-overhead and convenience, an implementation of this algorithm is used to calculate the magnitude and phase from the DC1 and DC2 values[25]. Since it requires successive approximation, the calculation CORDIC requires several clock cycles to complete. At the end of the approximation the outputs of the calculation CORDIC are the raw magnitude and phase values which can be read directly and used by the remaining calculation circuitry to perform higher-order analysis[25]. The remaining circuitry in the BIST is used for performing multi-measurement tests including measurements of the DUT linearity, SNR, noise gure (NF), and frequency sweeps. Before discussing each test in detail, it is important to understand that the result of the calculation circuit will be a logarithmic value expressed in decibels. Decibels (dB) are a common unit used to represent signal strength. To simplify the evaluation of measurement output, the calculation circuitry converts the output to decibels as described in Equation 2.15[25]. This operation is performed by the Logarithmic Translation Unit (LTU) shown at 32 Figure 2.8: Calculation Circuit Presented in [25] 33 Figure 2.9: Input Spectrum v. DUT Output Response for two-tone test the output in Figure 2.8. dB = 20 log10(MAGNITUDE) (2.15) With the help of the test controller the BIST can perform multi-measurement tests and consequently measure several di erent important analog characteristics. The rst such test measures the linearity of the analog DUT. The linearity of a system is usually measured by analysis of the third-order inter-modulation point (IP3) using a two-tone test[22]. When two tones f1 and f2 are generated and are used to stimulate the DUT, the resulting output frequency will consist of not only f1 and f2 but also the third-order inter-modulation terms (IM3) caused by the non-linearity of the DUT. The resulting output spectrum due to non- linearity of a DUT is shown in Figure 2.9. The linearity of a system can be measured by injecting two tones into the DUT and calculating the di erence in magnitude between the fundamental tone and the IM3 tone; this is often referred to as P[22]. When performed in the BIST this requires two measurements. In both measurements, two frequencies are generated by the DDS, f1 and f2. In the rst test the measured frequency is set to f2 and the ORA will accumulate the magnitude and phase of the fundamental frequency f2. This result is stored in the calculation circuit while a second measurement is performed. The 34 second measurement measures the IP3 tone at 2 f2 f1[20][24]. The resulting magnitude is subtracted from the magnitude of the previous calculation and the result is the P. The frequency sweep test searches a given spectrum for the largest magnitude frequency. Spurious tones can appear in the spectrum and may negatively a ect the output of a DUT. These tones may be caused by undesired harmonics or due to other issues such as clipping. It is often required to minimize spurious output and therefore it may be bene cial to measure the magnitude and location of spurious tones in the output of the DUT[25]. To perform a frequency sweep no fundamental frequency is generated by the DDS. To begin the test the frequency of interest f is set to a starting frequency fs and the magnitude measured. This magnitude is stored in the calculation circuitry while f is incremented by a predetermined amount finc. A new measurement will be made at the new frequency of interest f and the magnitude compared to the previously recorded magnitude. If the new magnitude is greater than the previously stored magnitude, the existing stored values are replaced with the new frequency word and magnitude. This process will repeat for the number of samples speci ed. The result of the test will be the magnitude and frequency word of the largest magnitude spur located in the measured bandwidth[25]. In a special case, if Samples = 0 only a single frequency?s magnitude is measured. This allows for the frequency response of the DUT to be measured at the speci ed frequency. This test can be repeated with a fundamental tone supplied by the DDS and swept through the spectrum to measure the frequency response of the DUT over the speci ed bandwidth[22]. Signal-to-Noise ratio (SNR) and noise gure (NF) are important characteristics of an analog system. SNR measures the power of the signal of interest in comparison to the average power of the noise in the system over a speci ed bandwidth. NF measures the amount of noise and signal degradation added to the system by the DUT by measuring the SNR at the input to the DUT, SNRin, and comparing it to the SNR at the output of the DUT, SNRout. 35 The formulas for these calculations are given in Equations 2.16 and 2.173, respectively[29]. SNR = 20 log10( Signal MagnitudeAverage Noise Magnitude) (2.16) NF = SNRin SNRout (2.17) The BIST can directly perform these tests and measure both of these characteristics. When performing a SNR measurement the BIST rst measures the magnitude of the fundamen- tal signal and stores it. The next measurement begins at the starting frequency of the bandwidth of interest, f and measures the magnitude. This measurement is repeated for a predetermined number of samples and the result of each measurement is accumulated in the calculation circuit. For each repetition the measured frequency f is incremented by a constant finc speci ed by the user. After the speci ed number of samples has been taken, the accumulated noise magnitude is divided by the number of samples to obtain an average noise magnitude as shown in Equation 2.18, where fs is the starting frequency, Samples is the number of noise samples to take, and finc is the constant frequency value by which f is incremented. Average Noise Magnitude = Pfs+Samples finc f=fs jfj Samples (2.18) After the average noise magnitude is calculated the original signal magnitude is divided by the noise magnitude to obtain the SNR ratio shown in Equation 2.16. The calculation for NF is very similar. When performing a NF test the SNRin is calculated by bypassing the DUT (using the previously discussed bypass path) and then divided by the result of a second SNR test SNRout calculated using the standard loopback path. The result is the NF ratio of the DUT[29]. While the general principals and methods employed by the calculation circuit described in [25] are still used, improvements to this circuit have been made in the BIST studied in this thesis. Like the previous calculation circuit it uses the same calculation CORDIC based 3The noise gure formula assumes that SNRin and SNRout are already in dB 36 Table 2.2: FW3 and FW4 De nitions Test Type Frequency Word 3 (FW3) Frequency Word 4 (FW4) Linearity IM3 Frequency Unused Frequency Sweep Starting Frequency Fs Frequency Step (Finc) SNR & NF Starting Frequency Fs Frequency Step (Finc) on the design by [25] to convert the DC1 and DC2 values to their magnitude and phase representations. Unlike the previous circuit, the LTU has been moved to the front of the circuit so that all operations are performed in the logarithmic domain. The divider was replaced by a subtractor as division is performed via subtraction in the log domain. Coupled with other improvements, the new circuit allows for faster operation and a large reduction in area and power (approximately 33%). 2.3.4 Summary With an understanding of the TPG, ORA, and calculation circuitry of the BIST, the last important aspect of the BIST is how it is controlled and observed (recall that Section 1.1 states that controllability and observability directly in uence the testability of a circuit). Excluding a run signal and the ADC inputs, the majority of the BIST is controlled via a Serial Peripheral Interface (SPI) interface. An overview of this SPI interface is important to understanding the BIST model. The SPI input to the BIST consists of an 88-bit SPI word which includes four 15-bit frequency words, FW1 through FW4, the number of samples, and a test control word (TCW) specifying which test to run. FW1 and FW2 always control the two frequencies generated by the BIST DDS circuitry. FW3 and FW4 have di erent meanings depending on the test run and are shown in Table 2.2. The number of samples is optional and will only be used when a frequency sweep, SNR, or NF test is being executed as discussed in Section 2.3.3. The TCW includes the test type to run as well as some additional 37 Table 2.3: Read Address Values Address Values 00 DC1 01 DC2 10 Magnitude and Phase 11 Spur FW, Log Result, Noise Floor Value ags including those which optionally select for the use of the digital loopback or bypass path and a bit to enable the use of the half-IMP accumulation time4. To read data out of the BIST the same SPI is used. For a read to occur, a SPI write is performed with the read ag set and must include two address bits. The address bits are decoded by the test controller and correspond to four di erent 64-bit words which can be read out of the BIST, each containing di erent calculation data related to the test. The values retrievable are summarized in Table 2.3. DC1 and DC2 correspond to the in-phase and out-of-phase components of the measured frequency (the contents of the MACs). The magnitude and phase output is the output of the calculation CORDIC and corresponds to the magnitude and phase of the measured signal (directly calculated from DC1 and DC2). The nal values include values speci c to each test. The \Spur FW" value corresponds to the location of the largest spur detected when performing a frequency sweep, the \Log Result" represents the result of the test in dB, and nally the \Noise Floor Value" represents the average noise power as calculated during a SNR test. In addition to the SPI inputs and outputs, there are a few other important outputs used in simulation. First there is the DDS output which is the generated tone for the test being executed. There is also a 10-bit test result output which is the result of the test in dB. Finally, there is a \Done" ag used to denote that the BIST has nished performing the test requested and that the results are ready for retrieval via the SPI. 4Half-IMP accumulation time causes the BIST to accumulate for half of the number of clock cycles that a test would usually require. This introduces additional error into the calculation but will greatly decrease test-time for long tests[26]. This mode is used extensively for fault simulations to minimize test time. 38 2.4 Thesis Statement While these descriptions of the BIST architecture are not a comprehensive operating manual, they are provided to give a background of the circuit so that a basic understanding can be developed by the reader. The focus of subsequent chapters will shift away from the underlying BIST architecture instead focusing on evaluating the e ectiveness of the developed test procedures for achieving a high fault coverage when testing a mixed-signal BIST approach by using the SSA BIST circuit as both a benchmark and for context. In the next chapter the necessary steps for conversion and veri cation of the circuit model to ASL is discussed. In addition the development and veri cation of fault simulation vectors is presented. These test vectors utilize the digital loopback path5 to perform measurements and are used to exercise the BIST circuitry. After verifying both the ASL and the test vectors, fault simulations are performed and the resulting fault coverage obtained is evaluated in Chapter 4 before a summary and conclusions are drawn in Chapter 5. 5The digital loopback path is the loopback path which directly connects the TPG to ORA bypassing any analog circuitry including the ADC and DAC. It is discussed in Section 1.3.3 and its e ectiveness in testing the digital portion of mixed-signal circuitry is evaluated in more depth in [7] 39 Chapter 3 Test Preparation, Development, and Veri cation To perform fault simulations using AUSIM several steps must be injected into the de- velopment process. This new work- ow, shown in Figure 3.1, rst requires conversion of the circuit model to the ASL netlist format which AUSIM can simulate. Once converted this netlist must be functionally veri ed as equivalent to ensure that no errors have been introduced during the conversion process. This chapter will focus rst on the conversion process to ASL and the di erences between the ASL and Verilog formats. Following the conversion process, a method of functionally verifying the ASL netlist is introduced which simpli es the veri cation process by using the Value Change Dump (VCD) format and a VCD Viewer. Finally using a similar method the development and veri cation of the test vectors for fault simulation is discussed. In the case of the SSA BIST, these test vectors con- sist of a number of di erent measurements including frequency sweep, frequency response, SNR, NF, and IP3 measurements which will exercise the BIST circuitry during simulation. These measurements utilize the digital loopback path (the path which bypasses any external circuitry, including the ADC and DAC, and directly connects the output of the TPG to the ORA) to facilitate the testing of the digital portion of the BIST for faults, avoiding any interference that could be caused by any external analog circuitry. 3.1 Converting to ASL Behavioral models are commonly written in a high-level hardware description language such as the VHSIC1 Hardware Description Language (VHDL) or Verilog. These languages 1VHSIC is an acronym for Very-High-Speed Integrated Circuit 40 Figure 3.1: Development Work-Flow allow for the behavior of a circuit to be modeled without speci cally de ning how the behav- ior is to be implemented in hardware. For Application Speci c Integrated Circuit (ASIC) design this implementation is usually a gate-level implementation of the circuit behavior using technology speci c standard cells. This synthesized netlist is then taken through a place-and-route tool where routing is nalized and a nal Verilog netlist is generated[19]. As discussed in Section 2.1.3 simulation should ideally be performed using this nal implementa- tion of the circuit; unfortunately, AUSIM requires a netlist in the ASL2 format. To facilitate the rapid simulation of this netlist a tool was developed which allows easy conversion from Verilog to the ASL format. The VerilogParser tool is written in C#[23] and allows a user to perform fault simulations on any circuit model by synthesizing it to a Verilog netlist then converting it to ASL. By using the VerilogParser tool, fault simulations using AUSIM can be integrated into the design work- ow easily and e ciently. As a simple example, a post-layout Verilog netlist of the ISCAS?85 C17 benchmark circuit3 is shown in Table 3.1 and its ASL equivalent is shown in Table 3.2. C17 is a small circuit and works well for demonstrating the conversion process as well as the di erences between a Verilog and ASL netlist. 2See Section 2.2.1 3C17 and other ISCAS?85 benchmark circuits can be downloaded from http://courses.engr. illionois.edu/ece543/iscas85.html 41 Table 3.1: C17 Verilog Netlist 1 module c17(gat1, gat2, gat3, gat6, gat7, gat22, gat23) 2 input gat1, gat2, gat3, gat6, gat7; 3 output gat22, gat23; 4 wire gat1, gat2, gat3, gat6, gat7; 5 wire gat22, gat23; 6 wire n 0, n 1; 7 AO21 B g58(.A1 (gat1), .A2 (gat3), .B(n 1), .Z (gat22)); 8 AO21 B g59(.A1 (n 0), .A2 (gat7), .B(n 1), .Z (gat23)); 9 AND2 B g60(.A (n 0), .B (gat2), .Z (n 1)); 10 NAND2 A g61(.A (gat3), .B (gat6), .Z (n 0)); 11 endmodule Table 3.2: C17 ASL Netlist 1 CKT: c17 IN: gat1 gat2 gat3 gat6 gat7 OUT: gat22 gat23 ; 2 AO21: g58 IN: gat1 gat3 n-1 OUT: gat22 ; 3 AO21: g59 IN: n-0 gat7 n-1 OUT: gat23 ; 4 AND: g60 IN: n-0 gat2 OUT: n-1 ; 5 NAND; g61 IN: gat3 gat6 OUT: n-0 ; The most signi cant challenge converting from Verilog to ASL is the di erence in the treatment of inputs and outputs of gates. In Table 3.1, line 7, the instantiation of the AO21 gate is shown. In Verilog, the gate?s inputs and outputs are not designated separately; instead, they use a type of keyword notation which assigns a net to an input or output name. In this notation, the order of the inputs and outputs does not matter and as such no guarantee is made that the order will be consistent between synthesis tools. In contrast to this method, Table 3.2, line 2, shows the same gate instantiated in ASL. ASL uses a syntax that declares the inputs and outputs to a gate by position rather than by name and uses the keywords IN and OUT to clearly separate the input nets from the output nets. For the translation from Verilog to ASL to be successful, the inputs and outputs of the instantiated gates must be ordered correctly; this includes the ordering of any custom gates de ned in an ASL library (library les are discussed in Section 2.2.1). 42 Table 3.3: Using the VerilogParser tool to convert a netlist to ASL C:nApplicationsnausim>VerilogParser.exe -aio c17.v c17.asl Please select the top level module from the list: |||||||||||||{ 0) c17 Please input the number corresponding to the top level module: 0 To solve this problem, several assumptions are made by the VerilogParser tool. First, it is assumed that in the Verilog netlist elementary logic gates will follow a standard net naming convention where ?Z? is the output of the gate. A similar assumption is made for a Data Flip-Flop (DFF) where the ?Q? and/or ?QBAR? net names are used for outputs and the ?D? and ?DBAR? are used for inputs. More complex logic gates, those gates which are not built-in to AUSIM and require a sub-circuit de nition, are treated in a special manner. With these gates the inputs and outputs are sorted from A-Z when converted. This means to function correctly each ASL library sub-circuit should have its input and output nets sorted alphabetically. To determine which nets are inputs and which are outputs, the tool rst checks if the instantiated logic gate is de ned as a Verilog module. If a module de nition is found, the tool extracts the inputs and outputs of the module to determine how to convert the instantiation to ASL. Failing this method, the standard rules for elementary logic gates are used where nets pre xed with ?Z? and ?Q? are assumed to indicate an output while the remaining letters indicate an input4. Currently there is no method for de ning custom translations of the inputs and outputs other than to make modi cations to the source code and recompile the tool from scratch. As a reference, Table 3.3 demonstrates how to use the tool on a Verilog netlist. The tool works by scanning the Verilog le for module de nitions, subsequently parsing those modules into an intermediate representation of the circuit. It then prompts the user to choose which module should be used as the top-level circuit in the ASL netlist before outputting the resulting ASL. Certain improvements could be made to the parser including automatic 4There are several other net names which are explicitly recognized as outputs such as Sum and Cout 43 detection of the top-level module. This improvement would require static analysis of the netlist to determine which module is not dependent on any other and as such is suggested for a future version of the tool. It is also important to note that while the ASL generated by the tool will always be syntactically correct, the tool does not check the validity of the netlist. It is assumed that any required sub-circuits have already been created and veri ed in ASL. In addition to use in this thesis, this tool has been used to perform other simulations including bridging fault simulations in [30]. In [30] the VerilogParser tool is used to convert the nal post-layout Verilog netlist to the ASL format so that accurate bridging fault sim- ulations can be performed. The VerilogParser allowed [30] to easily integrate multiple CAD tools which required di erent netlist formats (in this case a .bench format for automatic test pattern generation using Atalanta, .v for synthesis and place-and-route, and .asl for bridg- ing fault simulations using AUSIM). The ability to convert between netlist formats easily is clearly advantageous when working with multiple, specialized CAD tools. 3.2 ASL Veri cation Once the netlist has been converted to ASL using the VerilogParser tool, it must be functionally veri ed to ensure that it performs identically to the original Verilog circuit model. This ensures that there were no errors introduced by the conversion process and that the ASL model will behave as expected during simulations. The most direct way of verifying the ASL netlist is to perform logic simulations using the ASL netlist and subsequently compare the output to the output of logic simulations using the original Verilog model. If the circuit output of both simulations is identical then the ASL netlist is veri ed5. For the SSA BIST test vectors had already been developed to verify the behavioral model of the circuit during the design process. A subset of these test vectors were converted to the 5It is important to note that a single logic simulation is not enough to fully verify the ASL model. Ideally the same logic simulations used to verify the behavior of the Verilog model should be repeated to verify the ASL model; regardless the model is not fully veri ed unless an exhaustive set of inputs is used. 44 AUSIM vector format and logic simulation performed. The results were then compared to the simulation results from ModelSim to ensure that they were identical. Unfortunately the comparison between the AUSIM output and ModelSim can be di cult since the formats used are di erent. AUSIM uses a straight-forward text based output format where each line of text represents a test vector applied to the circuit and the corresponding circuit output. This makes a direct comparison between the output of AUSIM and ModelSim impossible; consequently, a tool was written to convert the AUSIM output to a standard format, the Value Change Dump (VCD) format. By using a VCD viewer a graphical comparison between the ModelSim and AUSIM output can be performed and the output can be easily analyzed each clock cycle. This signi cantly reduces the time required for veri cation. The next section provides more information on the VCD format and the conversion process. 3.2.1 Value Change Dump File The Value Change Dump or VCD format is de ned in section 15 of the IEEE 1364-1995 standard for Verilog[10]. Originally created as a light-weight format to dump simulation re- sults for post-processing[10], the VCD format is an industry standard format and is typically used to store logic simulation results in as small of a footprint as possible[10]. In addition as an IEEE standard it is supported in a number of free and commercial viewers which can easily visualize and navigate the underlying simulation data. The VCD format compresses simulation results into a smaller footprint by only storing the changes between vectors instead of every vector[10]. While this can make the output of the le less readable it makes it very easy to store large amounts of simulation data and for a viewer to parse and display the le. An example of a VCD le is shown in Table 3.46. On the right in Table 3.4 is a text description explaining each section of the VCD le. In addition to the le size reduction, the key bene t of conversion to the VCD format is the ability to visualize the output of a logic simulation in one of a number of commercial viewer 6It is important to note that while all IO in this example are a single bit, values in a VCD le can be any arbitrary width and in that case operate as a bit-vector. 45 Table 3.4: Example VCD File VCD File Description $date The date section de nes the day Tuesday, December 07, 2010 which this le was created $end $version Generated For ASL2VCD 1.0 A comment detailing the Alex Lusco version of the application creating this le $end $comment VCD File An additional comment section detailing $end information about the le $timescale 10ns $end De nes the time scale used in this le $scope module logic $end The simulation scope, particular to the simulation $var wire 1 ! A $end This section aliases each input with a single ASCII $var wire 1 " B $end character. For long IO names this shrinks them to a $var wire 1 # S $end single character allowing for the ability to condense $var wire 1 $ C $end the dump for large simulations greatly $upscope $end $endde nitions $end End of header $dumpvars Sets the initial value for each input 0! Each IO must be set to an initial value here 0" The !,",#, & $ characters represent the 0# nets aliased in the $var section 0$ $end #1 The #N construct denotes a time step to apply the 1" following value changes at, in this case at 10ns 1# Only nets whose value changed will appear in the time step #2 These changes occurred at 20ns 1! 0" #3 These changes occurred at 30ns 1" 0# 1$ #4 The end of the simulation, no changes occurred 46 Figure 3.2: VCD File Visualized in the GTKWave Viewer Table 3.5: Example Usage of ASLToVCD Tool C:nApplicationsnausim>ASLToVCD.exe -g groups.txt c17.out c17.vcd applications. For the example in Figure 3.2 GTKWave was used to visualize the VCD le in Table 3.4. GTKWave is a free, open source VCD le viewer for Linux available on-line at http://gtkwave.sourceforge.net. In GTKWave each IO is displayed as a waveform which changes over time. The displayed waveforms can be panned, zoomed and combined. This functionality alone makes it much easier to verify the output of a complex logic simulation. 3.2.2 OutToVCD Converter The OutToVCD tool is used to convert an AUSIM output le to the VCD format. It is fairly straight forward to use and greatly simpli es veri cation of an ASL model by allowing visual inspection of its output using GTKWave. An example of using the tool is shown in Table 3.5. This command will convert the logic simulation output of C17 to a VCD le which can be viewed in GTKWave. The ?-g? switch provides a list of outputs which should be concatenated and treated as a bit vector instead of individual bits. This switch allows for easier veri cation of multi-bit values. The tool performs all necessary conversions with no user interaction. 47 Figure 3.3: The Test Vector Development Process 3.3 Test Vector Development After verifying the ASL, the test vectors to be used for fault simulation must be de- veloped and veri ed. This process is similar to the veri cation of the ASL in that a set of test vectors must be created, logic simulation performed, and the output veri ed. Once logic simulation is performed, the output is converted to VCD and analyzed in GTKWave to verify that the test vector set produces the expected output. Additionally in the case of the SSA BIST, the test vector development process is not automated; instead, an iterative process is required. This process, outlined in Figure 3.3, shows the procedure used for developing these test vectors for the SSA BIST. Initially the test vectors used for fault simulation were manually developed based on an understanding of the underlying BIST architecture. Using knowledge of the BIST architecture, an attempt was made to develop disparate tests which perform measurements that exercise as many di erent sub-systems of the BIST as possible. The nal measurements used in the fault simulations and the fault coverage obtained are detailed in the next chapter; however, it is important to note that the test procedure shown in Figure 3.3 does not allow for the fault coverage of a set of test vectors to be accurately pre- dicted in advance. Consequently improvements to the test vector set must occur iteratively using feedback from the fault simulations being performed using the current test vector set. 48 For the SSA BIST, simulations were repeatedly performed using several di erent measure- ments and the undetected faults analyzed. Using this feedback, changes to the initial test vector set were made and new measurements were developed and simulated leading to more analysis and modi cations until a suitable fault coverage was obtained. 3.4 Summary Using both the VerilogParser tool and the VCD format, ASL conversion and veri cation can be performed e ciently and quickly. Once veri ed, the test vector development process can begin and an initial set of test vectors developed. This set of test vectors is not the nal set of vectors used for fault simulation but instead is simulated and the resulting fault cov- erage analyzed. Using this analysis, the test vector set can be modi ed allowing for iterative improvements in fault coverage. The next chapter discusses the fault simulations and result- ing fault coverage achieved using a test vector set developed using this iterative approach. In addition certain methods are presented which greatly speed up the fault simulations and simplify the analysis of the results. 49 Chapter 4 Fault Simulations and Results Six measurements were developed using the previously discussed methods and used in fault simulations of the SSA BIST. These six measurements are the result of e orts to develop a set of measurements which would exercise as much of the BIST circuitry as possible so that a high fault coverage can be obtained. As previously stated, no tool exists to develop these measurements automatically; consequently, development must occur iteratively with additional measurements added and existing measurements modi ed based on feedback from fault simulation until a suitable fault coverage is obtained. In the next section the six measurements are discussed, as well as the challenges associ- ated with simulating these measurements. Following that the results of the fault simulations are analyzed including methods used to determine the individual fault coverage of each measurement, the cumulative fault coverage of all six measurements, and a method used to optimize the ordering of the measurement set. 4.1 Performing the Simulations Table 4.1 shows the details of the six measurements that are used in fault simulations of the SSA BIST. The rst column is the type of measurement (SNR, NF, Linearity (IP3), Frequency Response (FR), or Frequency Sweep (Sweep)) that is performed during the sim- ulation. The rst and second frequency word columns (FW1 and FW2 ) correspond to frequencies that are generated by the SSA BIST during the test. The meaning of the FW3 and FW4 varies depending on the type of measurement being executed by the BIST and is de ned in Table 2.2. TC Word is the test control word used for the measurement, this word includes information for the test controller including the measurement type as well as several 50 Table 4.1: Simulated BIST Measurements Type FW1 FW2 FW3 FW4 TC Word Samples Clock Cycles SNR 1200 1400 600 200 13CC 513 103000 Long FR 101 101 102 33 0D24 0 34500 Sweep 1000 1500 100 100 0CA4 513 131500 IP3 3000 5000 800 0 070C 0 1050 Short FR 4000 6000 2000 0 07A0 0 900 NF 0CFC 0AFC 10FC 7CCC 1B60 2 91601 other measurement ags such as the half-IMP ag1 which halves accumulation time at the expense of measurement accuracy and can greatly shorten the time required for fault simu- lation. Measurement accuracy is not a concern for fault simulations since no real signal is being measured; consequently, the half-IMP ag is enabled in most simulated measurements to take advantage of the shortened simulation time. Samples corresponds to the number of frequencies to measure when performing a frequency sweep, SNR, or NF measurement. The Clock Cycles column is the total number of clock cycles the measurement is simulated and includes SPI writes, reads, and actual measurement accumulation time. The accumulation time a measurement requires is directly related to the values of its frequency words and is explained in Section 2.3.2. Fault simulations were performed for each of the measurements shown in Table 4.1. For each separate simulation the entire fault list containing 39,497 collapsed, gate-level, single stuck-at faults was used to determine the individual fault coverage of each test. Using the entire fault list for each test causes a large increase in fault simulation time (recall that Equation 2.2 shows that fault simulation time increases as the number of faults simulated increases); however, due to available computing power this was the preferred approach and will be discussed in more detail in the next section. 1Discussed in Section 2.3.4 51 4.1.1 Test Time Initially fault simulation was performed using a standard desktop computer performing very short measurements such as the IP3 measurement from Table 4.1. This soon proved un- feasible as even fault simulation of the relatively short IP3 measurement took approximately 24 hours to complete. Realizing that longer tests would prove impossible to complete using this method, an alternative approach was implemented which utilized the Auburn Univer- sity High Performance Computing Cluster (HPCC). More information can be found about this system at http://www.eng.auburn.edu/admin/ens/hpcc. As a general overview the Auburn HPCC consists of four separate computing nodes, each with 128 processing cores. It has 20.48TB of raw storage, 1.536TB of shared RAM, and has an overall performance calcu- lated at 5.735 tera ops2. By using this system to perform the fault simulations in parallel, simulation time can be drastically reduced. To take advantage of the HPCC a method was developed to split a given fault list into a number of smaller fault lists each containing the same number of faults. Each new fault list was copied into its own sub-directory along with a copy of the AUSIM les required to perform the fault simulation including the ASL netlist of the BIST, a test vector le for the measurement being performed, and the output from a previously performed logic simulation. Once the fault list has been split up and prepared, a job scheduler script was submitted to the HPCC scheduler which requests the required number of processing cores. Once loaded into the HPCC, this script forks the appropriate number of AUSIM processes (one for each CPU core) and each split fault list is simulated in parallel. Due to limitations imposed by the HPCC administrator a maximum of only 128 CPU cores could be requested by a single user, thus limiting the number of parallel simulations that could be run at a given time to 1283. 2This and more information about the HPCC is available at the HPCC website 3As shown in Table 4.2 greater than 128 CPU cores were used in some measurements due to temporary changes in the restriction by the HPCC administrator 52 Table 4.2: Fault Simulation Test Time Type CPUs Used CPU Time (Hr) Wall Time (Hr) Speed Up Combined 128 6072 74 x82 SNR 127 2018 20 x100 Long FR 25 12.5 .6 x21 Sweep 384 3450 28 x123 IP3 25 8.5 .5 x17 Short FR 99 609 9 x68 NF 256 2544 21.7 x117 Table 4.2 shows the total CPU time used by each test in hours vs the number of ac- tual hours required to perform the simulation (wall time). In addition to the original six measurements shown in Table 4.1, an additional simulation is also shown where all six mea- surements were combined together and run sequentially in a single fault simulation. Looking at the worst case fault simulation time (the combined simulation), without using the Auburn HPCC for simulation the combined measurement would have take 6072 hours or approxi- mately 253 days to complete! Instead, by splitting it up and running 128 parallel simulations it required only three days to perform. This speed up provided the exibility to perform longer measurements without concern for the simulation time. This technique does not come without disadvantages. First additional development was required to create the methods and techniques used to perform these simulations as no previous work had been done which used the HPCC for fault simulation purposes. This process involved some trial and error as the HPCC job scheduling system was not well documented and best practices for using the system had to be determined. Second, it can complicate the analysis of the fault simulation results since results are split among a number of di erent parallel simulations and must be recombined and processed before any results can be determined. The next section discusses in detail the methods used to calculate both the individual and cumulative fault coverage obtained for the six tests in Table 4.1. 53 4.2 Fault Coverage Results Once a fault simulation has been completed using the HPCC, the fault coverage results are split amongst separate sub-folders. In each folder (one for each CPU core used in the simulation) there are three les of interest, the detected fault list, the potentially detected fault list, and the undetected fault list. The rst step to determining the fault coverage is to recombine all of these separate fault lists, creating one combined list for each type of fault. To do this a simple script is used which utilizes the Linux cat and awk commands to concatenate the les together and then remove any blank lines or comments from the output. The result of this operation is three les (one for each type of fault: detected, undetected, or potentially detected (PDT)). Each of these les contains either the total number of detected, undetected, or PDT faults for this measurement. By applying Equation 2.1 to this data, the fault coverage can be calculated by taking the number of detected faults, adding a percentage of the potentially detected faults, and then dividing by the total number of faults (less any faults which are undetectable). However, before using Equation 2.1 to calculate the fault coverage, an analysis of the PDT fault list is performed so that a more accurate estimate of the likelihood of a potentially detected fault being detected can be formed. 4.2.1 Potentially Detected Faults It is common to assume that 50% of the PDT faults will be detected in a real system and subsequently multiply P by :5 in Equation 2.1. This is an easy assumption to make; however, with some simple analysis of the PDT fault list we can do a better job approximately the likelihood of a PDT fault being detected. The PDT fault list that AUSIM outputs includes both the fault name and the number of times the fault was potentially detected during simulation. By making the assumption that a high number of detections of a PDT fault will result in a high likelihood of that PDT fault being detected in a real system, the fault list can be post-processed to mark any PDT faults that ful ll this criteria as detected faults. When analyzing the fault simulation results 54 Figure 4.1: Method used to Represent Connection to VDD and to GND in AUSIM of the SSA BIST, there proved to be a large separation between the PDT faults which were detected only a few times and those which were detected a high number of times. Based on this qualitative data, a threshold of 300 detections was chosen to separate the two categories. An automated script was then developed to perform this processing, and, when run, marks any PDT fault detected greater than or equal to 300 times as detected. In the future more research should be done to determine a more quantitative relationship between the number of times a PDT fault is detected verse the likelihood of detecting the fault in real hardware. 4.2.2 Undetectable Faults As shown in Equation 2.1, any undetectable faults should be excluded from the total number of faults when calculating fault coverage. Due to optimizations made by the syn- thesis tools when generating the post-layout Verilog netlist of the SSA BIST, a number of undetectable faults were encountered when performing fault simulations that had to be re- moved. These faults occur due to nets which may be tied directly to VDD or GND due to logic minimization performed by the synthesis tool4. Unfortunately AUSIM has no direct method of representing a net tied to VDD or GND so a slightly modi ed sub-circuit is used. Shown in Figure 4.1 an AND gate and inverter are used to generate a value which is always logic ?0? (GND) and an OR gate and an inverter are used to generate a value which is always logic ?1? (VDD). In both of these circuits, CLK is used as the input net; however, any net can be used that is convenient. Regardless of the input value these circuits will always generate a logic ?0? and logic ?1? respectively. While these two sub-circuits work well to solve the issue 4Other undetectable faults may exist in the BIST circuitry but are generally more di cult to prove as undetectable. 55 during conversion and logic simulation, they each introduce an additional undetectable fault which must be accounted for during fault simulation. In the case of the AND circuit, any net stuck-at ?0? is undetectable since the output of the AND gate is always a logic ?0?. Likewise in the case of the OR gate, any net stuck-at ?1? is undetectable since the output of the OR gate is always a logic ?1?. After conversion to ASL, the SSA BIST contained approximately 14 undetectable faults due to these circuits. These faults were removed via an automated script from the fault list and not included in any of the fault coverage calculations. 4.2.3 Overall Fault Coverage Each of the six measurements in Table 4.1 were simulated and the results recorded. Each test was simulated against the entire list of 39497 faults. The individual fault coverage of each test is shown in Table 4.3. The Raw Detected and Raw Potentials columns are the number of faults reported by AUSIM; however, as discussed in the previously any potentially detected faults which were detected greater than 300 times were marked as detected. This is shown in the Detected column which contains the number of raw detected faults plus the number of PDT faults which were detected greater than 300 times and in the Potentials column which contains the number of raw PDT faults less any PDT faults detected greater than 300 times. The overall fault coverage is in the Coverage column and is calculated using Equation 2.1. This coverage is calculated using the modi ed detected and PDT fault numbers and assumes a 50% probability of detecting any remaining PDT faults (those which were potentially detected less than 300 times). It is important to note that Table 4.1 is the individual fault coverage of each measurement and that further processing must be done to obtain the cumulative fault coverage of all measurements. To determine the cumulative fault coverage, all measurements must be combined and the unique set of both detected and potentially detected faults extracted. Once extracted the unique PDT fault list is analyzed and PDT faults which are detected more than 300 times are removed and marked as detected. The nal fault numbers are then used with Equation 56 Table 4.3: Individual Fault Coverage Results Type Raw Detected Raw Potentials Detected Potentials Coverage SNR 27310 3387 30570 127 77.55% Long FR 25526 3337 28313 551 72.38% Sweep 25256 3406 28419 243 72.26% IP3 22122 3102 24994 230 63.57% Short FR 20617 3456 23815 258 60.62% NF 27883 3354 31007 230 78.80% 2.1 and the nal cumulative fault coverage can be determined. In the case of the SSA BIST the raw, cumulative number of detected faults was 31639 and the raw, cumulative number of potential faults was 3521. After ltering out the potential faults which were detected greater than 300 times, the number of detected faults rose to 34831 and the number of potential faults became 360. This results in a cumulative fault coverage of 88.64%. To obtain a better understanding of which measurements are most e ective at detecting faults in the SSA BIST, it is bene cial to determine the incremental fault coverage each test contributes to the cumulative fault coverage total of 88.64%. By determining the number of additional unique faults each measurement detects, the measurements can be ranked and ordered by highest incremental improvement in fault coverage. This has a number of practical implications. First it can be used to determine which measurements are providing the most bene t to the cumulative fault coverage. Measurements which provide only a minor increase in the cumulative fault coverage may need to be reworked or replaced. Unfortunately as the cumulative fault coverage becomes higher, it becomes increasingly more di cult to obtain substantial improvements in fault coverage with each additional measurement. Secondly if the measurements are ordered from the highest to least number of unique detected faults then the time required to perform a combined fault simulation (similar to the one performed in Table 4.2) of all measurements can be minimized. This decrease in time occurs due to fault dropping of detected faults (Section 2.1) causing a decrease in the number of faults simulated for the entire length of the simulation. In addition when verifying an actual 57 Figure 4.2: Individual Fault Coverage vs Cumulative Fault Coverage Percentage hardware implementation using this test procedure, measurements which detect the most faults will be performed rst, increasing the likelihood that a fault is detected early in the test sequence. This will shorten the overall veri cation time as unnecessary measurements are not run. To determine the optimum measurement order a script was developed which analyzes the detected fault lists from an arbitrary number of simulated measurements. First the measurement with the highest number of detected faults is selected as the initial measurement to be run. Starting with this initial list of detected faults, the measurement which provides the highest incremental improvement of fault coverage is then selected to be run next. This is repeated until the optimum test order is determined. Figure 4.2 shows the optimum ordering of the six measurements and the individual and cumulative fault coverage gain for each measurement. As discussed previously any potentially detected faults detected greater than 300 times are included in the number of detected faults. As shown in the graph the cumulative fault coverage rises little after the rst three measurements have been performed (NF, SNR, Long FR). In fact these rst three 58 measurements detect a total of 34335 faults, a cumulative fault coverage of 86.93%. The remaining measurements only detect an additional 623 faults. After determining the optimum order to perform the measurements, a fault simulation was performed where all measurements were executed sequentially in a single fault simulation and the fault coverage obtained veri ed. This combined fault simulation required a total of 1,011,900 test vectors to be simulated, requiring approximately 673 hours of CPU time. As shown in 4.2 this time was reduced to approximately 74 hours using the parallel fault simulation techniques discussed previously. As expected the fault coverage obtained in the combined test was 88.64% matching the coverage calculated from the individual measurement simulations. 4.3 Experimental Results The six measurements developed using this test procedure have successfully been used to verify a hardware implementation of the SSA BIST discussed in this thesis. Using the digital loopback path of the SSA BIST, each of the six measurements was executed on each SSA BIST chip and the output compared to the previously performed logic simulations. This entire process was automated and performed at the system clock speed of 80MHz. Approximately 500,000 clock cycles are required to perform all six measurements which correlated to a test time of a little under 10ms. If, during the testing process, a chip did not produce the expected results after performing a given measurement then it was considered faulty. Using this procedure several chips were identi ed as faulty after failing to return the correct values. In addition, in one speci c case the location of the fault was able to be diagnosed based on analysis of the invalid BIST results. The successful use of this test procedure to verify actual hardware proves that this method is an e cient and viable method for the fault-free veri cation of mixed-signal systems and in some cases can aid in fault diagnosis. 59 The next chapter will summarize these ndings and address some of the implications of the fault coverage obtained as it relates to the observability and testability of the BIST approach. Opportunities for improvements to the BIST approach will be brie y discussed including some simple modi cations to the underlying BIST architecture which may result in an increase in fault coverage by improving the testability of the BIST. 60 Chapter 5 Analysis and Summary While a cumulative fault coverage of almost 89% is an excellent starting point, a higher fault coverage of at least 95% would be better. In an e ort to obtain a higher fault coverage, key sub-circuits of the BIST which are not throughly tested by the current test vector set need to be identi ed. This chapter starts by analyzing the fault coverage obtained in Chapter 4 and determining areas of the SSA BIST which are not easily controllable or observable. After identifying these weakly covered areas, several design modi cations to the BIST are explored and simulated to see if an increase in the cumulative fault coverage is obtained. Finally an overview of this thesis is provided and a summary is given of the work completed. 5.1 Fault Coverage Analysis By analyzing the faults which were undetected in the fault simulations performed in Chapter 4, a better understanding of the testability of the SSA BIST can be obtained. Table 5.1 shows the fault coverage of several of the BIST sub-systems obtained by running the six previously discussed measurements1. Each major sub-system of the SSA BIST is represented in the Table and the approximate fault coverage of each is given. As shown in the table, several areas of the BIST, including the DDS, MACs, and reference CORDIC, have greater than 95% fault coverage using the existing measurement set. The high fault coverage of these sub-systems is not particularly surprising as each is extensively exercised every time a measurement is performed. Unfortunately several of the other sub-systems are not as easily testable. Particularly the calculation circuitry, some related normalization 1The Fullswing Power and Spur Calibration sub-systems are circuitry which normalize the result of an accumulation when performing a single frequency response measurement 61 Table 5.1: Fault Coverage of BIST Sub-Systems Subsystem Total Faults Coverage DDS 4995 99.7% Fullswing Power 438 70.09% LOG Calculation 11621 81.06% ORA Accumulators 10608 98.37% Reference CORDIC 3977 95.22% Spur Calibration 660 71.06% Test Controller 1829 85.27% SPI Interface 4259 81.71% circuitry, portions of the test controller, and the external SPI interface have a relatively low fault coverage compared to other sub-systems. In an attempt to improve the overall fault coverage obtained, several improvements to the BIST are proposed and simulated. The subsequent fault coverage is analyzed to determine if any improvement in the coverage of the LOG calculation, test controller, spur calibration, and fullswing power sub-systems. Due to design restrictions it is not possible to make modi cations to the SPI interface and any improvements that could be made to it were excluded from consideration. 5.2 Fault Coverage Weaknesses By analyzing the logic simulation results of the six measurements performed in Chapter 4 several weaknesses were identi ed in the testability of the SSA BIST. The rst major weakness identi ed was the limited signal magnitudes that could be measured when using the digital loopback path. When simulating or performing measurements using the digital loopback path any signals to be measured must be generated by the DDS. Since the digital loopback path is a purely digital path, there is no noise introduced nor is there any signal degradation or loss possible. This means that the only type of measurable signal when using the digital loopback path is a pure, DDS generated, sine-wave with no noise. This measured signal can only be one possible magnitude: the maximum possible power (full-swing power) of the signal generated by the DDS. When performing a frequency response measurement 62 this limits the resulting values calculated by the BIST to either zero, when no signal is present, or the full-swing power, when a signal is present at the measured frequency. This limits the bits exercised in the calculation circuitry as well as the fullswing power and spur calibration circuitry. A second major weakness identi ed is also rooted in the pure digital nature of the digital loopback path. As stated previously the digital loopback path introduces no noise or signal degradation; consequently, it has perfect linearity and SNR. This is an issue when performing linearity or SNR measurements, as it limits the values that are calculated by the calculation circuitry, subsequently lowering the maximum fault coverage achievable. Finally the test controller has a fairly low test coverage, though the reasoning behind this isn?t quite as easily attributed to a single issue. For one this is likely due to the mea- surement set developed in this thesis not exercising all of the measurement options available. Unfortunately this is di cult as some measurement options cannot be performed when in loopback mode (such as usage of the bypass path or using the certain preset circuitry2). An additional measurement option that is di cult to observe is the samples register. The samples register controls the number of samples that are taken when performing an SNR, Frequency Sweep, or Noise Figure measurement. This register is a 10-bit register allowing up to 1024 samples to be taken in a single measurement. To fully verify that this register is fault-free, a measurement must be performed which takes a minimum of 5133 samples and the results veri ed. Performing a measurement that takes 513 samples requires a lengthy simulation time. Currently a measurement that does exactly this is performed as part of the six measurements simulated in Chapter 4 to test this register and associated circuitry; however, if this register was easier to observe it would not require that such a 2The preset circuitry holds a number of predetermined BIST measurements hard-coded into the model and selectable via the SPI and external pins. These measurements each include the test type and options not allowing for the digital loopback path to be used. This e ectively prevents this circuitry from being tested. 3This ensures that while decrementing the counter all of its bits are toggled between a logic ?1? and ?0? at least once. 63 long measurement be included in the test vector set potentially, allowing for a more e ective measurement or even multiple shorter measurements to be performed in its place. 5.3 SSA BIST Improvements To address these issues, four main improvements to the SSA BIST were suggested and subsequently simulated to determine if any improvement in fault coverage was obtained. These four improvements incurred little area penalty (<2%) and include: The option to disable certain output normalization circuitry when performing fre- quency response measurements The ability to perform a shift operation on the DDS output to attenuate the signal so that multiple magnitude signals can be produced and measured The ability to purposely clip the DDS output within the digital loopback path intro- ducing harmonics that can be measured in linearity tests Allow the testing of the preset circuitry by forcing any preset measurement to be performed using the digital loopback path Allow the samples register to be read out via the BIST SPI interface The original six measurements discussed in Chapter 4 were re-simulated using the mod- i ed BIST architecture and the fault coverage recorded. Following the original six mea- surements four additional measurements were developed using the test procedure outlined in Chapter 3. Each of these four measurements utilized the improvements made to the BIST circuit to determine the e ectiveness of the discussed improvements. The four newly developed measurements are: A frequency response measurement with a single sample which uses the shift function- ality to reduce the magnitude of the generated DDS signal 64 A linearity test which utilizes the clipping ability to introduce non-linearity into the digital loopback path A SNR measurement with 513 samples which uses the clipping and shifting to modify the DDS signal measured A frequency response measurement that is stored in the preset circuitry of the BIST and utilizes the override ag to run using the digital loopback path The resulting fault coverage of all ten measurements is broken down in Table 5.2. Each of the sub-systems in represented in the table and compared to the fault coverage obtained using the previous model. It is important to note that, due to the design changes, the new model contains an additional 669 faults compared to the previously discussed BIST model. As shown in the table, two of the sub-systems with the lowest fault coverage (LOG Calculations and SPUR Calibration) did show some improvement in fault coverage using the new measurement set; while the other two low-coverage sub-systems, the Fullswing Power and Test Controller, showed almost no change and a decrease in coverage, respectively. Also shown in the table is a new sub-system, the BIST loopback. This sub-system encapsulates most of the modi cations made to the BIST loopback path and facilitates the newly added clipping and shifting operations. Even though this sub-system is exercised in nearly all of the newly performed measurements, it has a surprisingly low fault coverage. Unfortunately the overall fault coverage of the measurement set (bottom of the table) using the new BIST model proved to be only 89.5%; an increase in coverage of almost 1%. While this does not invalidate the improvements made to the BIST loopback (some fault coverage increase was obtained), it does show that the fault coverage is not explicitly limited by the factors discussed. This likely means that future improvements to fault coverage will come via iterative improvements to the measurement set. This also likely indicates that it will be di cult to achieve major increases in fault coverage in future iterations and any progress made will require adding additional measurements to the measurement set with 65 Table 5.2: Fault Coverage of BIST Sub-Systems w/ Improvements Subsystem Total Faults Coverage Old Coverage DDS 4801 99.63% 99.70% Fullswing Power 434 70.05% 70.09% LOG Calculation 11582 82.00% 81.06% ORA Accumulators 10618 98.5% 98.37% Reference CORDIC 3957 95.35% 95.22% Spur Calibration 661 74.36% 71.06% Test Controller 1833 82.76% 85.27% BIST Loopback 557 70.56% N/A SPI Interface 4485 80.97% 81.71% Overall BIST 40170 89.5% 88.64% only small increases in the number of detected faults (on the order of a few hundred faults). 5.4 Conclusions Unfortunately 89.5% fault coverage is as high as was achieved using the measurement set developed in this thesis. Even with the improvements proposed and implemented in the BIST the gain realized was minimal. This does not mean that the maximum fault coverage that can be achieved using this test procedure is limited to 89.5%; however, it does indicate that without more analysis to understand the factors limiting the fault coverage, progress beyond 89.5% may prove di cult. One factor which may be contributing to the lower than expected fault coverage is the fact that certain areas of the BIST are impossible to test while using the digital loopback mode in simulation. These areas are mostly related to external circuitry such as external run control and the bypass and ADC paths and control logic. Since these areas are unable to be tested, they represent a potentially signi cant group of undetectable faults. As an example, by removing all faults associated with the SPI interface (a sub-system of the SSA BIST that cannot be modi ed due to project constrains and has a low testability), the fault coverage obtained using the six measurements from Chapter 4 improves to 91.8%. This represents a 66 little more than a 3% improvement in fault coverage. In this case the SPI interface is not a sub-system that is untestable in the loopback mode; however, it does show how signi cantly an untestable circuit could negatively in uence the fault coverage. Future research should determine the number of faults attributed to untestable paths and what fault coverage could be achieved after removing these faults. Regardless of the marginal improvement in fault coverage provided by the changes to the BIST, a fault coverage of almost 90% was obtained using the test procedure outlined in this thesis. In this test procedure a method was presented to iteratively develop a set of measurements to be executed by a mixed-signal BIST system to test itself for faults. A conversion process was outlined which converts any post-layout Verilog model to the ASL format (and veri es the correctness of the ASL model) so that fault simulation can be performed and the fault coverage of developed measurements evaluated. Using the SSA BIST as a benchmark, this procedure has shown that by utilizing the digital loopback a set of measurements can be created which allow a mixed-signal BIST to e ectively test itself for faults without the need for external test equipment and without requiring dedicated testing circuitry. As compared to other testing approaches there were several di culties associated with this test procedure that were explored in this thesis. First this procedure does require a signi cant amount of time to iteratively develop and simulate the measurement set used when testing the mixed-signal BIST. There is no automated tool that can develop the test vector set and some trial and error is needed to develop a test vector set which yields a su ciently high fault coverage. Second, as discussed earlier, it may prove di cult to achieve the highest levels of fault coverage (>95%) due to some portions of the BIST, such as external run pins and external loopback paths, being untestable. These types of circuitry (and related control circuitry) cannot be tested in a digital loopback mode and could potentially be the source of a number of undetected faults limiting the maximum fault coverage obtained in the SSA BIST. Additional testing would be required to fully test this circuitry. 67 Regardless of these disadvantages, this test procedure does have a signi cant number of advantages compared to other methods. It is circuit agnostic and can be applied to a number of mixed-signal BIST setups since it only requires a post-layout Verilog model for the conversion process and a digital loopback path for testing purposes. So while development of the test vector set must occur iteratively, it can be ne-tuned for the speci c architecture being tested and intuitively evolved. In addition by utilizing this method of testing no performance penalty and little area overhead is incurred in the circuit. This is a signi cant advantage compared to many other BIST techniques which require additional circuitry to be included in the circuit which in some cases can negatively a ect system performance and increase chip area. In the discussed procedure all testing is performed using the digital loopback path and no dedicated test circuitry must be inserted into critical path ways. This means that the testing of the BIST can be performed at system speed and without the need for external test equipment. Furthermore this allows for the testing of the BIST at all stages of the product life cycle including during the manufacturing process and at any point during in-system operation, such as before being used to make measurements in the analog portion of a mixed-signal system, making this procedure an excellent candidate for systems with high availability and reliability requirements. 68 Bibliography [1] C. Stroud, A Designer?s Guide to Built-In Self-Test. Kluwer Academic Publishers, 2002. [2] The International Technology Roadmap for Semiconductors: 2009 Edition - Test & Test Equipment, Semiconductor Industry Association, San Jose, CA. [3] Y. Zorian, \Testing the Monster Chip," IEEE Spectrum, vol. 37, no. 7, pp. 54-60, 1999. [4] L. Ungar and T. Ambler, \Economics of Built-In Self-Test," Proc. IEEE Design & Test of Computers, vol. 18, no. 5, pp. 70-79, 2001. [5] L. Wang, C. Stroud, N. Touba, Eds., System On Chip Test Architectures. Elsevier, 2008. [6] L. Milor and V. Visvanathan, \Detection of Catastrophic Faults in Analog Integrated Circuits," Proc. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 8, no. 2, pp. 114-130, 1989. [7] C. Stroud, P. Karunaratna, and E. Bardley, \Digital Components for Built-In Self-Test of Analog Circuits," Proc. IEEE 10th ASIC Conference and Exhibit, pp. 47-51, 1997. [8] C. Stroud, \AUSIM: Auburn University SIMulator - version 2.0," Dept. of Electrical & Computer Engineering, Auburn University, July 7, 2003. [9] C. Stroud, \ASL: Auburn Simulation Language," Dept. of Electrical & Computer En- gineering, Auburn University, July 7, 2003. [10] \IEEE Standard Hardware Description Language Based on the Verilog(R) Hardware Description Language," IEEE Std 1364-1995, 1996. [11] L. Milor, V. Visvanathan, \Detection of Catastrophic Faults in Analog Integrated Cir- cuits," IEEE Transactions on Computer-Aided Design of Integrated Circuits and Sys- tems, vol.8, no.2, pp.114-130, 1989. [12] K. Arabi and B. Kaminska, \Oscillation-Test Strategy for Analog and Mixed-Signal Integrated Circuits," Proc. IEEE VLSI Test Symposium, 1996, pp. 476-482. [13] V. Yarmolik, Fault Diagnosis of Digital Circuits. John Wiley Sons, 1990. [14] B. Vinnakota, Analog and Mixed-Signal Test. Prentice Hall, 1998. [15] M. Sachdev, Defect Oriented Testing for CMOS Analog and Digital Circuits. Kluwer Academic Pub, 1998. 69 [16] C. Stroud, J.Emmert, J. Bailey, D. Nickolic and K Chhor, \Bridging Fault Extraction from Physical Design Data for Manufacturing Test Development", Proc. IEEE Inter- national Test Conference, 2000. [17] J.M. Emmert, C. Stroud, J.R. Bailey, \A New Bridging Fault Model For Accurate Fault Behavior," Proc. IEEE Automatic Test Conference, pp 481-485, 2000. [18] D.G. Saab, I.N. Hajj, J.T. Rahmeh, \Parallel-Concurrent Fault Simulation," Proc. IEEE International Conference on Computer Design: VLSI in Computers and Pro- cessors, pp.298-301, 1989. [19] C. Last, Advanced Digital Design The Verilog HDL. Prentice-Hall, 2004. [20] J. Qin, C. Stroud, F. Dai, \Test Time of Multiplier/Accumulator Based Output Re- sponse Analyzer in Built-In Analog Functional Testing," Proc. 41st Southeastern Sym- posium on System Theory, pp.363-367, 15-17 2009. [21] J. Qin, C. Stroud, F. Dai, \Noise Figure Measurement Using Mixed-Signal BIST," Proc. IEEE International Symposium on Circuits and Systems, pp.2180-2183, 27-30 2007. [22] F. Dai, C. Stroud, and D. Yang, \Automatic Linearity and Frequency Response Tests with Built-in Pattern Generator and Analyzer," IEEE Transactions on VLSI Systems, vol. 14, no. 6, pp. 561-572, 2006. [23] Microsoft. The C# Language. Visual C# Developer Center. [Online] http://msdn. microsoft.com/en-us/vcsharp/aa336809.aspx. [24] J. Qin, \Selective Spectrum Analysis (SSA) and Numerically Controlled Oscillator (NCO) in Mixed-Signal Built-In Self-Test," Doctoral Dissertation, Auburn University, 2010. [25] G. Starr, \Built-in Self-Test for the Analysis of Mixed-Signal Systems," Master?s Thesis, Auburn University, 2010. [26] J. Qin, J. Cali, B. Dutton, G. Starr, F. Dai, C. Stroud, \Selective Spectrum Analysis for Analog Measurements," IEEE Transactions on Industrial Electronics, no.99, pp.1, 2011. [27] J. Qin, C. Stroud, and F. Dai, \Phase Delay Measurement and Calibration in Built-In Analog Functional Testing, Proc. IEEE Southeastern Symposium on System Theory, pp. 145149, 2007. [28] S. Qi, \Analog Circuit Testing using Built-In Direct-Digital Synthesis," Master?s Thesis, Auburn University, 2005. [29] J. Qin, C. Stroud, F. Dai, \Noise Figure Measurement Using Mixed-Signal BIST," Proc. IEEE International Symposium on Circuits and Systems, pp.2180-2183, 2007. 70 [30] J. Tacey, M. Lusco, J. Qin, N. Da Cunha, \Weighted Bridging Fault Coverage Using Capacitance Extraction", Proc. IEEE Southeast Symposium on System Theory, pp. 216-221, 2011. 71