A Scheme for Integrated Controller-Datapath ... - ACM Digital Library

A Scheme for Integrated Controller-Datapath Fault Testing M. Nourani

Dept. of Electrical & Computer Engineering University of Tehran Tehran, Iran

Abstract In systems consisting of interacting datapaths and controllers and utilizing built-in self test (BIST), the datapaths and controllers are traditionally tested separately by isolating each component from the environment of the system during test. This work facilitates the testing of datapath-controller pairs in an integrated fashion. The key to the approach is the addition of logic to the system that interacts with the existing controller to push the eects of controller faults into the data ow, so that they can be observed at the datapath registers rather than directly at the controller outputs. The result is to reduce the BIST overhead over what is needed if the datapath and controller are tested independently, and to allow a more complete test of the interface between datapath and controller. Fault coverage and overhead results are given for four example circuits.

1 Introduction This work addresses the problem of testing systems that consist of interacting datapaths and controllers. Typically, datapaths and controllers are synthesized independently, and design-for-testability decisions are made for each component without regard to how the component will be used in the context of the pair. Similarly, testing of datapaths and controllers is typically done independently, isolating each component from the system environment for testing purposes, using a scheme like that proposed by [3]; the controller output signals are multiplexed with some or all of the datapath primary outputs, thus making them directly observable. This kind of approach has several disadvantages. Observing the controller and datapath separately, in general, implies more test time (due to the need for two separate test sessions) and more overhead (due to the need for direct observation of each) than an integrated approach. In addition, portions of the signals used to communicate between the datapath and controller are not fully tested. The goal of this work is to develop an integrated way of testing datapath-controller pairs. One major diculty is that even if the datapath and controller are designed such that they are 100% testable taken separately, when the two are taken in combination the testability may be severely deThis work was partially supported by the Semiconductor Research Corporation under Contract No. DJ-527. \Permission to make digital/hard copy of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for pro t or commercial advantage, the copyright notice, the title of the publication and its date appear, and notice is given that copying is by permission of ACM, Inc. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior speci c permission and/or a fee." DAC 97, Anaheim, California

c 1997 ACM 0-89791-920-3/97/06 ..$3.50

J. Carletta

C. Papachristou

Dept. of Computer Engineering Case Western Reserve University Cleveland, Ohio

graded [5]. This work concentrates on the controller half of the integrated testing problem, relying on the previously developed minimal behavioral built-in self-test (BIST) scheme for the datapath [18]. Under this scheme, the datapath is tested while its control inputs are driven by the controller, operating according to its normal behavior. The primary diculty with integrated test approaches is the relative inacessibility of the lines used to communicate between datapath and controller. In a separate test, the control lines are primary outputs, but in the integrated test, these lines can be viewed only indirectly through the datapath. Work in [5] seeks to improve integrated test quality by redesigning the controller so as to break correlation among the control signals. We take a dierent approach, focusing on enhancing the observability of the control lines arti cially, without doing a controller redesign. The key to our integrated test approach is to provide a method to propagate and observe the eect of certain controller faults through the datapath, i.e., at the datapath registers rather than at the controller outputs. This approach will result in a more complete test of the interface between controller and datapath than would separate tests of datapath and controller, and will avoid the degradation in test quality that can occur in other integrated test strategies. Moreover, our approach can detect certain types of redundant controller faults that, although they may not aect the overall functionality of the datapath-controller pair, do increase the power consumption of the system. Our technique will make BIST a viable alternative to non-observability-based test methodologies such as IDDQ, which are presently the only way of detecting such redundant faults. Our technique is designed to work independently of implementation details, the design-for-testability technique, or design tools used to synthesize the controller and datapath. At the same time, our technique will not substantially increase the overall system cost. Because our approach does not rely on a controller redesign, it is compatible with design techniques with a wide variety of goals. For designs based on BIST, controller design research has focused on three issues: test plan and test scheduling; controller area minimization; and controller testability enhancement. References [1], [14] and [10], among many others, have addressed the rst issue using dierent heuristics by which the steps for processing one test vector are maximally overlapped with those used in processing another vector. Area minimization has been accomplished using special state assignments and feedback polynomials [6], 1-hot encoding [17], and additional test registers to implement the system function supporting a self-testable pipelinelike controller [11]. [15] adds edges to the nite state machine (FSM) for the sake of testability of the controller when tested independently. [13] proposes to make FSMs more easily controllable by reducing the length of a synchronizing sequence. The eect of controller faults on the synthesis of hierarchical FSM models and a methodology to remove some

types of faults are discussed in [7]. The work presented in [20] identi es \darn" (Dicult And Really Needed) states and transfers them into easy-to-reach states. This paper is organized as follows. Section 2 presents a system model for testing a datapath-controller pair. Section 3 presents a classi cation of controller faults. Section 4 describes the conditions necessary to push the eects of controller faults into the datapath, and Section 5 details our solution. Experimental results are shown in Section 6, and concluding remarks are in Section 7.

2 Controller-Datapath Test Models Our system consists of an interacting datapath and controller. Structurally, the datapath consists of arithmetic logic units (ALUs), multiplexers, registers, and busses. We use a somewhat restricted architectural style for the datapath, assuming that it is composed of functional blocks like that shown in Figure 1. The most signi cant restriction of this style is the requirement that at most one multiplexer/bus exist along the path of any register-to-register transfer. This style has been successfully employed in many synthesis systems, including [12] and [19]. Behaviorally, the controller is viewed as a state diagram that speci es the time steps in which the data operations are done. For this work, controllers are implemented structurally as nite state machines using random logic. The controller guides the datapath in making computations by supplying it with control signals governing which path is selected through each multiplexer and which registers are loaded at each time step. Further, the datapath may provide the controller with status signals when the control ow depends on data-dependent conditionals. Other inputs and outputs to the system include the data inputs and outputs to the datapath, and start and done signals to the controller to synchronize the exchange of input data and output results with the outside world. Figure 2 illustrates the typical independent test approach, in which the datapath-controller pair is completely split during test, and each part is tested independent of the system environment. Multiplexers may be used to share the test resources; for example, one test pattern generation register (TPGR) and a multiplexer can be used instead of the two TPGRs shown on the gure. A completely integrated approach is shown in Figure 3. We call this the unmodi ed integrated test approach to distinguish it from the integrated approach proposed in this paper. Here, the datapathcontroller pair is treated as an inseparable unit; datapath and controller are tested simultaneously. Figure 4 shows our proposed approach, which retains the advantages of an integrated approach while addressing the issue of low fault coverage achieved by the unmodi ed integrated approach. One motivation for treating a datapath-controller pair as an integrated system has to do with coverage of the control and status lines running between datapath and controller. In an independent test of the controller, the control lines are tapped so that the output of the controller can be observed directly by a multiple input signature register (MISR). As a result, there is a segment of the control line, after the tap, that can not be observed during the controller test. This control line extends far into the datapath, and may control multiple registers and multiplexers. Portions of the line will not be covered even during an independent datapath test, since some of the line will come between the controller and the TPGR used to supply patterns to the datapath. Note that if the controller and datapath are laid out in separate

blocks, the control lines may be of signi cantly longer length than other wires, and may therefore be more susceptible to faults. By doing an integrated test, for which we observe the controller through the datapath, we ensure that we test the entire length of the lines.

3 Classi cation of Controller Faults We classify stuck-at faults internal to the controller as shown in Figure 5. We rst classify the controller faults based on whether a fault aects the functionality of the controller. By functionality, we mean the input-output behavior of the synthesized controller as it operates in normal mode. This diers slightly from the work of [7], in which faults are distinguished in terms of the controller function as speci ed by the designer. In the designer's speci cation, some outputs may be unspeci ed, whereas in the synthesized version speci c values have been chosen for all the outputs as a byproduct of the synthesis. We call faults that never aect the output of the synthesized controller in normal mode controller-functionally redundant or CFR. Detection of these faults may require, for example, the application of transitions that the designer left unspeci ed, perhaps because some of the states of the controller are unused, or because for some states some input combinations will never occur. [7] shows that controller resynthesis can be used to remove CFR faults. A controllerfunctionally irredundant or CFI fault aects the output of the controller in at least one time step of the state diagram when the controller is running in normal mode. Faults of this kind will be caught in an independent test of the controller, for which we operate the controller in normal mode and observe the controller outputs directly. We further divide the CFI faults into two subgroups, based on whether a fault aects the input-output behavior of the datapath-controller pair as a system. The rst subgroup, system-functionally irredundant or SFI faults, are those faults that change the functionality of the system as a whole. For example, a fault whose eect changes a \care" speci cation of a multiplexer select line will cause an operation to be done on incorrect data, thereby aecting a change in the results of the computation. Faults that aect a register load line in such a way that some computation result is never written also fall into this category. The second subgroup, called system-functionally redundant or SFR faults, are those faults that do not aect the input-output behavior of the system, even though they do aect the input-output behavior of the controller. For example, a fault may aect a multiplexer select line only in those time steps when it is a \don't care", i.e., in time steps when the value propagating through the mux are never written to any register. SFR faults can aect even the \care" speci cations for the outputs of the controller. For example, suppose that some fault in the controller causes a register to be loaded in a time step when it should not be loaded. If the extra load writes into a register that is not currently holding a computation value, or serves only to rewrite the same value again, the extra load will not aect the functionality of the datapath. While functionally redundant faults do not aect the computations performed by the datapath, they may cause increased power consumption. For example, a fault that causes harmless but unnecessary loading of \garbage" values into a register results in unnecessary power consumption in the register and any subsequent combinational logic, in essence, undermining the gated clock scheme extensively used for low power design. The presence of functionally re-

dundant faults may also be an indication of a manufacturing problem. One manufacturing problem is cracks in insulation layers [2]. Over time, metal migrates into the cracks, forming shorts. An SFR fault caused by this problem may indicate more serious problems to come, as more shorts form, and therefore be worth detecting.

4 Propagation of Controller Faults In this section, we discuss how to propagate the eect of controller faults through the datapath. We do not consider controller-functionally redundant faults, since they can not be detected even when the controller is tested independently. The goal of our work is to assist in pushing the eect of faults from the control lines at the controller-datapath interface into the datapath. Barring a detailed gate level analysis of the controller, if we want to be sure to catch all controller-functionally irredundant faults within the controller, we must be sure that we can detect any change in a control line during any one time step. The key to our approach is to ensure that changes in the control lines cause changes in the data owing through the datapath. In what follows, we consider multiplexer select line fault eects, register load line stuck-at-1 eects and register load line stuck-at-0 eects separately. Figure 6(a) shows a fragment of a datapath. A fault eect on the select line of a multiplexer (at location a) means that the wrong path through the multiplexer will be selected in some time step. In our case, if the multiplexer select is meant to be a `0' in some time step, but is stuck-at-1, the multiplexer passes the value y instead of the correct value x. Thus, the fault eect is successfully moved into the data ow (at location b) as long as x 6= y. The fault eect causes an operation to be performed on incorrect operands; the ALU performs the operation y + z instead of the correct x + z . Therefore, the eect of the fault is propagated to location c as long as x 6= y. To propagate the eect of the fault through the register at the output of the ALU to location d, the register must be loaded in the same time step, to save the erroneous result y + z . Figure 6(b) illustrates a fault eect on a register load line (at location e). Suppose rst that the fault causes the load line to be stuck-at-0 in some time step; in this case, the register is not loaded when it should be. Thus, it keeps its old value c(t , 1), rather than obtaining a new value c(t). This will be noticeable at the output of the register (at location d) only if c(t , 1) 6= c(t), i.e., only if the missed load would have written a new value into the register. Assuming that the system is designed intelligently so that redundant computations are not done, this should be the case for at least some of the test patterns. If a register load line is stuck-at-1 in some time step, the register is loaded when it should not be. This is noticeable at the register output (at location d) only if the new value inadvertently loaded is dierent from the old value. Referring to Figure 6(b), we see that there are a number of ways for this to happen. First, of all, the multiplexer select line could have changed value since the last time the register was loaded. For example, if the last value written was x + z , and the multiplexer select line changes, the inadvertent load will cause y + z to be written over the x + z value. This is noticeable as long as x 6= y. Alternatively, the value of x may be changed; since x is coming from another register in the datapath, it is possible that a new value has been written to x. In this case, the inadvertent load will cause x(t) + z to overwrite the correct value, x(t , 1) + z .

Another important point is that when the eect of the fault moves from a control line to the data ow, it moves from a single bit line to a multi-bit bus. The fault eect will be seen on one or more lines of the bus, depending on the speci c values of the data. From a practical standpoint, if we test the datapath using a reasonably large number of random patterns, it will be possible to observe control line faults without observing all the bits of the datapath bus; a single bit will suce, because, for any bit i that we choose, there are likely to be at least some patterns that cause a change in bit i. More quantitatively, suppose that the patterns being written to a register are random with a uniform distribution and uncorrelated in time. If we observe one bit of the register output, the probability that a register load line fault escapes detection ( 21N ) drops exponentially with the number of patterns N written to the register, and is quite small even for short test sessions. (If all bits of the register output were observed, the probability of the fault 1 escaping detection would be even smaller: 2nN for an n bit register.) While the assumptions made for this analysis are often not valid in practice, experimental evidence shows that observing one bit of each register suces to detect fault eects on the control lines.

5 A Design Solution This section describes a solution to the datapath-controller testing problem that adds a small nite state machine (FSM) to the system as shown in Figure 4. This FSM \piggybacks" onto the original controller, interacting with the controller in such a way that the eects of all system-functionally redundant (SFR) faults within the controller are pushed from the output of the controller into the data ow, where they can be observed at the outputs of the datapath registers. Note that in our justi cation of our method, we talk about the entire contents of a given register; however, as already discussed, in practice we watch only one output bit of each datapath register during the test of the controller. We justify the method by looking at a single functional block of the datapath (as shown in Figure 1) in a single time step T = i. We would like to be able to detect any change in the multiplexer select lines or register load line during this time step. Our ability to detect a change should not depend on the content of register loaded at a time step before i, and the scheme should work regardless of the values of the multiplexer select (MS) lines and register load (RL) lines. The method works by freezing the original controller to expand the time step into two time steps. In the rst of the two steps, a known value that is dierent from what it is supposed to be under normal operation is loaded into the register. This is accomplished by complementing all multiplexer select lines and loading the register. In the second of the two steps, control signals for normal operation are produced, and the original controller is unfrozen so that it will make the transition to the next normal mode state. This is illustrated in Figure 7. When testing the controller, a time step that normally would produce the control signals (MSi ; RLi ) is expanded into two time steps, one which produces (MSi ; 1), and one which produces (MSi ; RLi ). Note that this has the side eect of slowing down the execution of the state diagram by a factor of two. The logic implementation for the FSM needed to eect these changes is quite inexpensive; one implementation uses one XOR for each MS line, one OR for each RL line, a D ip- op, and two other gates. Table 1 shows how all controller faults that cause changes

at the control lines for a single functional block (see Figure 1 in a given time step i can be observed by checking the content of the block's output register R. [R] and [R] denote the content of register R when multiplexer select lines are MS and MS, respectively. Also, MSf denotes a multiplexer select for which at least one bit is faulty due to a controller fault, and MSf denotes its complement. [R]f and [R]f denote the content of register R in these two situations. The table is split into two cases, depending on whether the register is supposed to load a new value in the time step. In the rst case, in the fault-free system the register loads a new value at time step i, i.e., RL = 1. Part (a) of the table shows the contents of register R in the fault-free case, and in the presence of two dierent fault eects: stuck-at-0 on RL, and stuck-at-0 or 1 on MS. Note that if a fault causes RL to be stuck-at-1 only in time steps during which (like this one) RL is supposed to be a `1', the fault is controller-functionally redundant (CFR), and not targeted by this technique. The arrows show when a dierence in the contents of the register from the fault-free contents indicates that a fault will be detected. From the table, it is easily seen that any fault which causes RL to be stuck-at-0 or MS to be stuck-at-0 or 1 in this time step will be detected. In the second case (part (b) of the gure), in the fault-free system the register does not load a new value at time step i, i.e., RL = 0. The arrows show that any fault which causes RL to be stuck-at-1 or MS to be stuck-at-0 or 1 in this time step will be detected. Again, if a fault causes RL to be stuck-at-0 only in time steps during which RL is supposed to be a `0', the fault is CFR, and not targeted by this technique.

6 Experimental Results In this section, we demonstrate our approach using several example circuits. The circuits have been synthesized from high level descriptions using the SYNTEST synthesis system [12]. Logic level synthesis is done using the ASIC Synthesizer from the COMPASS Design Automation suite of tools with a 0.8-micron CMOS library [4]. Fault coverage curves are found for the resulting logic level circuits using AT&T's GENTEST fault simulator [8]. The probability of aliasing within the MISRs is neglected, as are faults within the TPGRs and other test circuitry. Although the datapath and controller are tested together, we have separated out the fault coverage curves for the controller to clarify the results. We work with four example circuits, all with eight bit wide datapaths. The rst evaluates a third degree polynomial. Our other examples implement three high level synthesis benchmarks: a dierential equation solver and the FACET example [9], and a fth order elliptical lter [16]. We show fault coverages and transistor counts for the independent, unmodi ed integrated, and proposed integrated test approaches. Transistor counts given are for an entire system under a given test scheme, and include the datapath, controller, and all circuitry necessary for the test. Fault coverage results for the controllers of the four examples are shown in Figure 8. During each test, the controller is run in normal mode; in the case of the polynomial, the schedule has ve control steps, and so for the independent and unmodi ed integrated approaches, after, for example, 100 clocks, the controller has run through the schedule 100/5 = 20 times. For the proposed integrated approach, the action of the added nite state machine serves to slow the speed down to twice as slow, and so for the same 100 clocks the controller has run through the schedule 10 times. We see from this that one penalty of the proposed approach

is that it takes approximately twice as long for the fault coverage curves to saturate. However, this is not as serious a limitation as it may seem, as the controller test is still quite short, especially when compared with the test for the datapath, which may easily be an order of magnitude longer. Table 2 summarizes the test circuitry needed for each of the three test schemes in terms of key system parameters. It includes the TPGR, the MISR, and any muxes associated with them. Figure 9 shows the relative sizes of systems implementing the three test schemes for our four example circuits. Overhead is given relative to the unmodi ed integrated approach, since this approach represents the minimal amount of test circuitry that can be used for any BIST scheme. We see that the unmodi ed integrated test approach has the lowest area for test circuitry, but also the lowest fault coverage. Low fault coverage here is expected, because all system-functionally redundant (SFR) faults go undetected. The independent test approach has the highest fault coverage, thanks to its ability to catch all controllerfunctionally irredundant faults, including the SFR ones, but also the highest area overhead. In the middle is the proposed integrated test approach; its nal fault coverages are very nearly as high as for the independent test approach, but its area overhead is much lower. The high fault coverage here indicates that the piggybacked FSM successfully pushes the SFR faults out into the datapath. The overhead advantage of the proposed integrated approach over the independent approach arises from two sources: reduced area requirements for the TPGR due to the use of the minimal behavioral BIST scheme of [18], and reduced area requirements for the MISR due to the indirect observation of the control lines through the datapath registers. We now compare the proposed integrated approach to the approach used in [18], which uses minimal behavioral BIST to test the datapath, but tests the controller independently. The comparison is important because it takes away the TPGR part of the overhead advantage, allowing us to see the eects of the proposed integrated approach on observation circuitry. Sizes of the TPGR and MISR circuitry required for the approaches are given in Table 2 in terms of key system parameters. While the four example circuits using the proposed integrated approach have area overheads of 6.1%, 4.0%, 3.8% and 7.6%, respectively, the same four circuits using minimal behavioral BIST for the datapath and independent controller test have overheads of 7.5%, 2.3%, 2.4% and 9.6%. For the polynomial and WAVE circuits, the proposed integrated approach uses less observation circuitry. However, the proposed integrated approach requires slightly more observation circuitry for two of the circuits: the differential equation solver, for which the number of datapath outputs outnumber the number of controller outputs, so that a savings in the MISR width is not possible; and the FACET example, which has eleven register load lines and only two multiplexer select lines. Here, m is too small relative to r to oset the addition of the logic needed for the nite state machine required for the proposed integrated approach. For many designs the number of multiplexer select lines will outnumber the register load lines, especially when distributed multiplexers, buses with tri-state buers and one-hot encoding for the multiplexer control are used. Note that even when this is not the case, the use of our approach still retains the advantage of detecting faults that cause excessive power consumption.

fault-free

faulty s-a-0 on RL s-a-0 or -1 on MS

MSi MS MS MS MS MS f RLi 1 1 1 (s-a-)0 1 content of R [R] [R] [R] [R] [R]f

6 66 6 6 s-a-0 on RL detected

MSf 1 [R]f

6

fault-free

s-a-1 on RL

MS MS MS

MS f

MSf

6 66s-a-1 on RL detected 6 6

6

1 [R]

0 [R]

MS

faulty s-a-0 or -1 on MS

1 (s-a-)1 1 [R] [R] [R]f

0 [R]f

s-a-0 or -1 on MS detected s-a-0 or -1 on MS detected (a) for the case in which R is supposed to load (b) for the case in which R is not supposed to load Table 1: The eect of interaction between the controller and piggyback on a typical register R at time step T = i. Unmodi ed Proposed Independent Integrated Integrated din : din + 1 din + 1 max(r + m + din , s + 1) dout : din + 1 din + 1 r + m + s + din + 1 r: dout + 1 max(r + 1, dout ) max(r + m + 1,s + dout ) m: min(r + 1,dout ) min (r + m + 1, s + dout ) s:

bitwidth of the input data TPGR width bitwidth of the output data # muxes number of registers number of multiplexer select lines MISR width number of status lines # muxes Table 2: Test circuitry required for the three test approaches in terms of system parameters.

7 Conclusion This paper proposes a scheme to facilitate datapath-controller pair testing. It advocates testing the pair in an integrated way, rather than testing the datapath and controller completely independently by separating each from the system environment during test. The scheme adds a small nite state machine to the system that serves to enhance observability of the controller outputs, so that controller faults can be observed at the outputs of the registers of the datapath. Experimental results show that use of the scheme results in about one-third the test overhead than that required for a scheme in which datapath and controller are tested separately, with fault coverage that is as good, or nearly as good. In addition, for the integrated scheme, the control lines used to communicate between controller and datapath are more thoroughly tested.

REFERENCES

[1] M. Abadir and M. Breuer, \Constructing Optimal Test Schedules for VLSI Circuits Having Built-In Test Hardware," Intl. Conf. on Fault Tolerant Computation, June 1985. [2] R. C. Aitken, \Finding Defects with Fault Models," Proc. Intl. Test Conf., pp. 498{505, Oct. 1995. [3] S. Bhatia and N. Jha, \Behavioral Synthesis for Hierarchical Testability of Controller/DatapathCircuits with Conditional Branches," Proc. Intl. Conf. on Comp. Design, June 1994. [4] Compass Design Automation, \User Manuals for COMPASS VLSI V8R4.4," Compass Design Automation, Inc., 1993. [5] S. Dey, V. Gangaram and M. Potkonjak, \A ControllerBased Design-for-Testability Technique for Controllerdatapath Circuits," Proc. Intl. Conf. on Comp.-Aided Design, pp. 534{540, October 1995. [6] B. Eschermann and H. Wunderlich, \Optimized Synthesis of Self-Testable Finite State Machines," Intl. Conf. on Fault Tolerant Computation, 1990. [7] F. Fummi, D. Sciuto, and M. Serra, \Synthesis for Testability of Large Complexity Controllers," Proc. Intl. Conf. on Comp. Design, pp. 180{185, Oct. 1995.

[8] AT&T, \User Manuals for GENTEST S 2.0," AT&T Bell Laboratories, 1993. [9] D. Gajski, N. Dutt, A. Wu, and S. Lin, High-Level Synthesis: Introduction to Chip and System Design, Kluwer Academic Publishers: Boston, MA, 1992. [10] I. Harris and A. Orailoglu, \Microarchitectural Synthesis of VLSI Designs with High Test Concurrency," Proc. Design Automation Conf., June 1994. [11] S. Hellebrand and H. Wunderlich, \An Ecient Procedure for the Synthesis of Fast Self-Testable Controller Structure," Proc. Intl. Conf. on Comp.-Aided Design, June 1994. [12] H. Harmanani, C. Papachristou, S. Chiu and M. Nourani, \SYNTEST: An Environment for System-Level Design for Test," EURO-DAC 92, Sept. 1992. [13] F. Hsu and J. Patel, \A Distance Reduction Approach to Design for Testability," Proc. VLSI Test Symp., pp. 158{ 163, May 1995. [14] W. Jone, C. Papachristou and M. Pereira, \A Scheme for Overlaying Concurrent Testing of VLSI Circuits," Proc. Design Automation Conf., 1989. [15] T. Kuo, C. Liu and K. Saluja, \An Optimized Testable Architecture for Finite State Machines," Proc. VLSI Test Symp., pp. 164{169, May 1995. [16] S. Kung, H. Whitehouse and T. Kailath, VLSI and Modern Signal Processing, Prentice-Hall, 1985. [17] D. Mukherejee, C. Njinda and M. Breuer, \Synthesis of Optimal 1-hot Coded On-Chip Controllers for BIST Hardware," Proc. Intl. Conf. on Comp.-Aided Design, June 1991. [18] C. Papachristou and J. Carletta, \Test Synthesis in the Behavioral Domain," Proc. Intl. Test Conf., pp. 693{702, Oct. 1995. [19] L. Ramachandran and D. Gajski, \Behavioral Design Assistant (BdA) User's Manual, Version 1.0," UC / Irvine Tech. Report 94-36, Sept. 1994. [20] K. Rajan, D. Long and M. Abramovici, \Increasing Testability by Clock Transformation," Proc. VLSI Test Symp., May 1996.

x

CONTROL

a

DATAPATH

multiplexer selects (MS)

0

y

x

z

1

+ e

register "R"

d

(a) for multiplexer select lines. (b) for register load lines. Figure 6: Propagation of a fault eect on a control line.

...

...

S = controller state MS = mux select RL = register load

TPGR data in

control

CONTROL

DATAPATH

control status

done MISR

data out

DATAPATH

done

data out MISR

Figure 3: Unmodi ed integrated test approach.

100

100

95 90 IND PI UI

85 80 0

start

DATAPATH

CONTROL status

one bit from each register

done

MISR

Figure 4: Proposed integrated test approach. controller faults controller-functionally redundant faults

controller-functionally irredundant faults

(CFR)

(CFI) system-functionally redundant faults

system-functionally irredundant faults

(SFR)

(SFI)

Figure 5: Classi cation of controller faults.

85 80 0

100 200 Time in clocks

100

Fault Coverage (%)

data in

90

(a) polynomial evaluator. (b) dierential equation solver. Fault Coverage (%)

TPGR

95

100 200 Time in clocks

100

control piggy. FSM

test mode

Si+1 MS i+1 , RLi+1

MSi+1, 1

Fault Coverage (%)

control status

normal mode

...

data in CONTROL

Si MS i , RL i

Figure 7: State diagram illustrating how the piggybacked FSM interacts with the original controller.

TPGR

start

MS i , 1

MISR

Figure 2: Independent test approach.

S i-1 MS i-1 , RL i-1

MS i-1 , 1

Fault Coverage (%)

status

c

d

...

Figure 1: One functional block de ning our datapath style.

start

+

c

e

ALU

TPGR

z

b

multiplexer

register load (RL)

y

95 90 85 80 0

200 Time in clocks

95 90 85 80 0

100 200 Time in clocks

(c) the FACET benchmark. (d) the WAVE benchmark. Figure 8: Fault coverage curves for the controllers of four example circuits under the unmodi ed integrated (UI), proposed integrated (PI), and independent (IND) test approaches. Design Poly Dieq FACET WAVE

Unmodi ed Proposed Independent Integrated Integrated 8186 8684 (6.1%) 9839 (20.2%) 9001 9357 (4.0%) 10136 (12.6%) 12966 13460 (3.8%) 14371 (10.8%) 16022 17250 (7.6%) 19847 (23.9%)

Figure 9: Transistor counts for the same four examples, with overhead gures relative to the unmodi ed integrated system in parentheses.