Datapath Testability Improvement through ad hoc Controller Modifications

Transcription

1 Testability Improvement through ad hoc Controller Modifications M. L. Flottes, R. Pires, B. Rouzeyre Laboratoire d'informatique, de Robotique et de Micro-électronique de Montpellier, U.M. CNRS rue Ada, Montpellier Cedex 5, France Tel: (33) , Fax: (33) , rouzeyre@lirmm.fr Abstract Even if a datapath has been synthesized with testability in view, its testability may strongly decreases once it is connected to its controller. In this paper, we propose controller modifications for restoring the testability of the datapath to a level close to the initial one. Those modifications concern the next state logic as well as the decoder part of the controller. The method is based on the results of a testability analysis of the datapath at RT level and on the specification of the initial controller. I. Introduction and related works Most of digital circuits are composed of a datapath and of a controller (Fig.1.a). This dichotomy is particularly apparent when the circuit is obtained through a High Level Synthesis flow. The datapath performs computation on data applied on data primary. The controller sequences the normal flow of execution on the datapath. Even if the datapath is fully testable when considered in isolation, particularly if generated using a High Level Synthesis for Testability tool (see [1] and [2] for a survey), its testability can be strongly affected after connection to the control part. As a matter of fact, the controller implements only the normal flow of execution (system mode). As a consequence, the set of actual words on the control signals and the next state logic may limit the possibilities of testing in the datapath. The first point is illustrated on Fig.2. Let's assume that in system mode, only the multiplications PI 1 * Cst2 and PI 2 * Cst1 are exercised. In order to achieve full controllability on the output of the multiplier, it may be necessary to perform the operation PI 1 * PI 2. Unfortunately no control word containing (0,1) on (sel_mux1, sel_mux2) signals is sent by the decoder. The limitations due to the sequencing are illustrated with help of the datapath depicted in Fig.3.a. Let's consider the test of the in the adder. One way of testing all in the adder is given in Fig.3.b. Conversely, in system mode (Fig.3.c), some can not be tested due to the presence of the shifter in the propagation path. Though the "right words" exist in the controller, their sequencing does not allow the observation of some adder. The first point is addressed in [3]. The authors propose decoder modifications in order to eliminate so-called "bit implications" in the control words. In order to minimize controller area overhead, a subset of command words to add is heuristically chosen. Nevertheless, the used heuristics do not look at which words are really needed to enhance the testability of the datapath. In [4], the authors address the sequencing problem during high level synthesis. They propose to modify the conditions of the behavioral loops by addition of test pins, creating thus new control paths. Doing so, the state justification is made easier during ATPG and some in the datapath are made testable. Nevertheless, not all datapath are made testable (e.g. in the adder in the above

2 Primary control Primary control Additionnal Input sequencer Next state logic Flags Next state logic Flags State register State register code code primary control decoder Controller control signals primary control decoder control signals example), furthermore the lack of control words is not addressed. We propose here a controller modification method for enhancing testability of the datapath which gets rid of some of the above mentioned limitations. This method is based on the RT level description of the circuit. Neither the testability of the controller itself nor the observation of datapath through the controller is addressed in this paper. sel_mux1 sel_mux2 II Principle a) Initial architecture b) after modification Fig.1 Circuit's architecture PI 1 PI 2 Cst mux1 mux2 mult Cst2 Fig.2 Fragment of a datapath The proposed method is two-fold : introduction of new control words and sequencing modification. o New control words are intelligently chosen and added to the decoder while minimizing area overhead. These words can be activated either by scanning the state register or by modifying the next state logic. Note that the scan solution solves the sequencing problem too. For non-scan designs, modifications of the next state logic are necessary for activating extra control words and for solving sequencing problems (Fig.3). This point is addressed in the second part. The structural modifications of the controller are depicted in Fig.1.b: they concern the next state logic, the decoder and the introduction of a new primary control signal. The modifications are done according to a RT level testability analysis of the datapath. The main features of the test analysis method are the following : - the testability of the datapath modules can be questioned in two modes. In "control mode", the testability of datapaths modules is questioned while using the command words of the normal flow of execution. In the present version, we do not look at the sequencing of the operations in the normal flow of execution. Conversely, in "free mode", the datapath is considered as an isolated circuit i.e., the control are considered as primary. In this mode test data propagation may involve some control words which do not exist in the original controller. - a controllability and an observability measures are derived for each module in the datapath. These metrics reflect the proportion of test patterns that can be propagated from the primary to the module and from the module to the primary. The metrics can be obtained for both

3 PI 1 PI 2 + R2 modes. At the evidence, metrics in "free mode" are higher than in "control mode". - one control path and one observation path are generated for each module. It must be noted that the paths obtained in control mode differ from the ones obtained in free mode if the metrics do. - a RT-level "test plan" for each module is derived by scheduling control and observation paths in both modes (Fig.3.b is an example of such a test plan in free mode). With regard to the principle, the test plan of a module is similar to the "test environment" as presented in Genesis [5]. The test plan of a module is the sequence of control words sent by the controller for activating the best test path (in the sense of the number of test data propagated to and from the MUT). Details on this testability analysis can be found in [6]. II.1. Decoder modifications - mux1 R1 R3 mux2 PO New control words are added to the decoder with regard to the difference on testability metrics obtained in "free mode" and in "controller mode". More precisely, these words are those necessary to activate the test plan of modules which have testability metrics lower in "control mode" than in "free mode". This strategy allows to select, among all missing words, only the ones that are useful to enhance the testability of the datapath. These words present the interesting feature of containing many don't care values. This point stresses the interest of working at RT level rather than at gate-level. 1 2 R1=PI 1+PI 2 ; PO=R1 ; 1 2 R1=PI 1 +PI 2 ; R2 = <<R1 ; 3 R1 = R2 - R3 ; 4 PO = R1 ; a) b) Test of the adder c) Normal flow of execution Fig.3. Example2 For instance, in the example of Fig.2, the word (xxxxx0xxx1xxx) with 0 on the sel_mux1 and 1 on sel_mux2 signals is a candidate. Thus, these words can be merged together and/or merged with the existing words allowing thus to limit area overhead during further logic minimization (see section III). Now, each test plan can be activated either by transforming the state register as a scan chain or by modifying the next state logic which is the topic of the second part of the method. II.2 Next state logic modifications In the second part of the method, new transitions are added to the controller. Those transitions are added for activating the test plan of each module. Here again, taking advantage of the don't care values, a minimal set of extra transitions is sought for minimizing area overhead. The transitions are activated by an extra control signal (see Fig.1.b). Modifying the next state logic in order to implement the sequence of command words of a test plan may increase a lot its area. Rather than to consider a test plan as a whole, we have chosen to consider every transition of the test plans individually. The process is illustrated on the controller given Fig.4.a for which the transitions T and the command words are : T 1= W 1(01101) W 2(00010) T 2= W 2(00010) W 3(10101) T 3= W 3(10101) W 4(00110) T 4= W 4(00110) W 5(00000) T 5= W 5(00000) W 1(01101) Let's assume that the transitions T p and the command words of the test plans to add are : T P1=01xxx 00xxx T P2=x1xxx xx111 T P3=0x0xx 0xx1x T P4=xx1x0 01xx1 T P5=x1x01 xx1x0 T P6=x01xx xxx1x T P7=0xxx1 0xx01 T P8=x011x xx111 Firstly, the transitions T p that cover at least one transition T are discarded from the list. For instance T p1 covers T 1 and T p6 covers T 3. Then a minimal number of transitions is added to the controller for covering all the remaining transitions T p. In a first step, transitions are added for activating new control words. Among all possibilities, the one that is covered by a

4 maximal number of Tp is chosen. For instance, if the only command word to add is W new = 01111, the transition W 3 W new is chosen among {W 1 W new,..., W 5 W new, W new W 1,..., W new W 5 } because it is covered by T P4 and T P8. The control graph is modified according to (Fig.4.b). In a second step, a minimal number of transitions covered by the remaining transitions Tp is added (Fig.4.c). W5 (a) S1 S2 S3 S4 S5 III Results W1 W2 W3 W4 T / Wnew T / W5 (b) (c) Figure 4 : Example of controller modification Concerning the addition of new control words to the decoder, we have performed experiments on six examples (A-F). In tables 1 and 2, DP refers to the datapath alone, DPD refers to the datapath and the original decoder while DPMD refers to the datapath and the modified decoder. Table 1 reports ATPG results concerning in the datapath while table 2 gives ATPG results on in the datapath and the decoder. The last column in Table 2 shows the low impact on area of the proposed method. Then we have applied the second part of the proposed method to example E (sequencing for test). Table 3 compares testability results on the datapath with the original controller and the modified one. These results S1 S2 S3 S4 S5 W1 W2 W3 W4 T / Wnew T / W1 T / W2 T / W3 T / W5 S1 S2 S3 S4 S5 W4 show that the method allows to restore the testability of the datapath to a level close to the maximal one. Though the testability of the datapath is only concerned by this controller modification method, results reported in Table 4 show that the testability of the whole circuit is not decreased but, contrarily, is widely increased. IV Discussion and conclusion The controller modification method T / Wnew presented here raises the testability a datapath to a level close to the achievable maximum. It is mainly based on a RT testability analysis and does not require ATPG. When used in conjunction with the synthesis for testability T / W2 of datapaths method presented in [7], highly testable circuits can be directly obtained. As presented here, this method leaves some room for further improvements : - the command words and transitions to T / W1 add are the results of one schedule of the test paths obtained from the datapath RT analysis. In the present version, the schedule is done without paying attention to the system mode's command words and transitions. This scheduling can be modified to reuse as many as possible initial command words and transitions. - in the same kind of idea, one single test path is derived for every module at RT level. This can be insufficient for completely testing a module, even in the case of regular structures like datapaths. The testability analysis can be modified to produce several test paths, leading thus to more controller modifications. There is place for trading-off testability improvements vs area overhead All these points are presently developed at LIRMM and we hope that they will lead to further improvemnts. References [1] L.J.Avra, E.J.McCluskey: «High-Level Synthesis of Testable Designs: an Overview of University Systems»,, International Test Conference, Test Synthesis Seminar, Digest of Papers, 1994 [2] K.D.Wagner, S.Dey,: «High-Level Synthesis for Testability: a Survey and Perspective», Proc. 33rd ACM/IEEE Design Automation Conference, pp , 1996

5 [3] S.Dey, V.Gangaram, M.Potkonjak,: "A Controller- Based Design-for-Testability Technique for Controller- Data Path Circuits", Proceedings of International Conference on Computer-Aided Design, pp , 1995 [4] F.F.Hsu, E.M.Rudnick, J.H.Patel : "Enhancing High- Level Control-Flow for Improved Testability", Proceedings of International Conference on Computer-Aided Design, pp , 1996 [5] S.Bathia, N.K.Jha: "Genesis: a behavioral synthsesis system for hierarchical testability", Proc. European Design and Test Conference, pp : , [6] M.L.Flottes, R.Pires, B.Rouzeyre: "Analyzing Testability from Behavioral to RT Level",, Proc. European Design and Test Conference, pp , 1997 [7] M.L.Flottes, R.Pires, B.Rouzeyre: "Alleviating DFT cost using testability driven HLS", Proceedings ATS 98. circuit version #detected #non-detected #non-testable Fault coverage % Test efficiency % A DP DPD DPMD B DP DPD DPMD C DP DPD DPMD D DP DPD DPMD E DP DPD DPMD F DP DPD DPMD Table 1: Faults in datapaths.

6 circuit version #detected #nondetected #nontestable Fault coverage % Test efficiency % ATPG time #command words area (µm 2 ) A DP mn DPD mn DPMD mn B DP mn DPD h DPMD mn C DP mn DPD h DPMD mn D DP mn DPD mn DPMD mn E DP h DPD h DPMD mn F DP mn DPD h DPMD h Table 2: Faults in ( + Decoder). version #detected #non-detected #non-testable Fault coverage % Test efficiency % Initial Modified controller Table 3: Faults in example E datapath. version #detected #non-detected #non-testable Fault Test ATPG area (µm²) coverage % efficiency % time Initial h Modified controller h Table 4: ATPG results on the whole circuit (example E)