Improving Datapath Testability by Modifying Controller Specification

A digital circuit includes two main parts: a controller and a datapath. After connection of these two parts, both are subject to a sharp fall in testability due to the lack of controllability and observability at the interface. In this paper, we propose a method for specifying the control part in order to restore the testability of the datapath to a level close to the initial one, in other words its testability before connection. This testability driven speciﬁcation affects the next state logic as well as the decoder part of the controller but does not make use of any scan-based element. Based on the ﬁnite automata theory and on results of a testability analysis performed on the datapath, the proposed method entails very little area penalty.


INTRODUCTION
Most of digital circuits are composed of a datapath and of a controller (Fig. 1).This dichotomy is particularly apparent when the circuit is obtained through a High-Level Synthesis flow.The datapath performs computation on data applied on its primary inputs.The controller sequences the normal flow of execution of 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 Refs. [1,2] for a survey), its testability can be strongly affected after connection to the control part.
In fact, the controller implements only the normal flow of execution.As a consequence, (1) the actual set of control words and (2) the word sequencing in system mode may limit the possibilities of faults testing in the datapath.
The first point is shown in Fig. 2. Let us 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 the decoder is not specified to generate a control word containing (0, 1) on (sel_mux1, sel_mux2).
The limitations due to the sequencing are shown with the help of the datapath in Fig. 3a.Let us consider the faults in the adder.One way of testing these faults is given in Fig. 3b (load R1, then write data on output PO).Unfortunately, in system mode, the adder response is never observed directly on the primary output.Adder results are first shifted then subtracted with data stored in R3 (Fig. 3c).Consequently, some faults cannot be tested due to the presence of other operations in the propagation path.In this example, the required "words" for testing the adder exist in the controller, but their sequencing does not allow the observation of some adder faults.
One solution for solving the problem of datapath test control is to insert a scan chain at the datapath/controller interface.Such scan chain provides full controllability of the datapath in such a way that any control sequence can be used during the test mode.However, the drawbacks of this approach are well known: the need of test data serialization, the area overhead, the extra delays between controller and datapath.
The methods proposed in Refs.[3,4] tackle each of the above-mentioned problems (lack of control words and limitations due to the sequencing) but not both.Conversely, the technique presented in Ref. [5] targets both problems.It is based on high-level testability results [6] and consists in re-synthesizing the controller.This method may entail some datapath modifications.

PRINCIPLE
We propose here to modify the controller specification for enhancing the testability of the datapath.Neither the testability of the controller itself nor the observation of datapath faults through the controller is addressed in this paper.The method consists of adding new control words and new transitions to the controller specification in order to maintain the testability of the datapath as high as possible.
The structural modifications of the controller are shown in Fig. 4: they concern the next state logic, the decoder and the introduction of new primary control signals for activating the added transitions.New control words and transitions are intelligently chosen and added to the controller while minimizing the area overhead.
First, a register transfer (RT) level testability analysis [7] is performed on the datapath.This analysis delivers a "test path" for each datapath module, i.e. a path along which as many patterns as possible can be propagated to test this module.Test data must be propagated through this path from the primary data inputs to the module under test, and from the module to the primary data outputs.Activation of a path may involve the use of non-existent control words or control sequences because during analysis, the testability of the datapath is examined without taking into account the controller.On the other hand, it must be noted that several test paths may exist for a given module but a single one is returned by the analysis step.This point will be further discussed in the "Discussion" section.A test path returned by the testability analysis can be scheduled in different ways.Scheduling of such a path gives a sequence of instructions (control words) for testing the module.The second step of our approach consists in including such sequences in

PROBLEM STATEMENT
For each module, the test path can be scheduled in many different ways (an infinity in fact), giving rise to several sequences of instructions, each being a candidate for inclusion in the controller with a related area overhead.Such a sequence of instructions is called a test plan in the remainder.
For instance, let us consider the test of the register R3 in the datapath shown in Fig. 5a.The initial control is shown in Fig. 5b.The R3 test path, depicted by bold lines in Fig. 5a, can be scheduled in at least three ways as given in Fig. 5c -e.The first two require the addition of 1 state, 2 transitions and 2 control words for their inclusion in the controller specification.The third one can be activated without any modification.
Thus, the problem is to choose for all modules the right test plan in such a way that the overall area overhead is minimized.The method we developed is detailed in the next section.It exploits the similarities between (1) the control words and the transitions to add and (2) the ones that already exist in the initial controller.It also relies on the possibility of fixing unspecified values on some control bits (do not care) for improving testability.The method is based on automata theory [9].

METHOD Modeling
Before selecting the best test plan for a module, we are first faced with the problem of modeling all the schedules of its test path.Rather than explicitly enumerate all the schedules, we represent them implicitly with a help of a finite automaton.Let us recall that a finite automaton is a 5-uple (A, Q, I, T, E) in which A is an alphabet, Q is a finite set of states, I , Q a set of initial states, T , Q a set of terminal states and E a set of edges.An automaton allows recognizing a language L and a language allows recognizing some words, i.e. some sequences of letters from A. In our context, A is the set of control words (existing in the initial controller or not).A* represents any sequence of any value.
Formally, the finite automaton for a test path is constructed following the data stream from the inputs to the outputs.For instance, let us consider the example shown in Fig. 6 in which the test of the register R3 is addressed.As in the example of Fig. 3, R3 cannot be fully tested in the system mode because of the shift operation that is planed after R3 loading.Thus, the testability analysis derives the test path depicted in bold lines in the datapath.We build up the corresponding automaton in the following way.First, two elementary finite automata (P1, P2), (Q1, Q2) are constructed for the registers connected to the inputs as shown in Fig. 7.Then, the automaton corresponding to the different ways of loading R1 and R2 is built up as the cross product * of the two previous automata.It is represented by the graph fragment (P1Q1, P2Q1, P1Q2, P2Q2) in Fig. 8. Finally, this automaton is completed by the automaton corresponding to the R3 (state T1) and R5 loading (state T2).With this formalism, any valid test plan (i.e. one schedule of a test path) corresponds to a graph traversal from the initial state (P1Q1) to the terminal one (T2).For instance, the path P1Q1, P1Q1, P2Q1, P2Q1, P2Q2, T1, T2, T2 corresponds to the following test plan: . do anything .load R1 from I1 .do anything any number of times but loading R1 .load R2 from I2 .load R3, while selecting input 1 of the mux .load R5 .do anything any number of times but loading R5.
In this model, the infinite number of test plans is represented in a compact way.The initial controller can be modeled in the same way.

Principle
The principle of the proposed approach consists in including a test plan for every module in the controller *A modified version of the cross product is used in order to avoid test data reconvergence.For instance, if R1 and R2 are connected to the same input, the transition from P1Q1 to P2Q2 (Load R1 and R2 at the same time) is not generated.specification.This inclusion does not induce additional cost when the initial controller already implements a test plan for the module under consideration.Otherwise, we have to add new control words and/or transitions.The strategy consists in selecting the less expensive test plan, i.e. the one that is the closest to the initial controller.
For instance, in the previous example, the test plan P1Q1, P2Q2, T1, T2 is selected for the test of register R3.This test plan is simply embedded in the initial controller specification by modifying the control word from state S4 to S5 (Fig. 9).From a bit representation point of view, the initial do not care value assigned to the R5w signal is replaced by a 1.This modification may impact the decoder logic.

Implementation
The first goal of the method is to check whether the controller already contains one test plan of the datapath module under consideration.If not, the method includes a test plan in the controller with a minimal cost.
The test plan selection is done according to a cost function taking into account (1) the number of added transitions, (2) the number of added control words, (3) the number of added test pins, (4) the number of do not care values fixed and (5) the number of modules this test plan can be used for.
Formally the algorithm for test plan selection is the following: 1. MinCost ¼ þ1 M is a module under test, P of M is a test plan extracted from the M test path and P min is the minimal cost test plan.BestImplementation returns the lower cost solution for implementing P in the current controller specification (Controller).
In which the BestImplementation is the following: For instance, let us consider the example in Fig. 10.Among all test plans, the path depicted in bold p1, p4, p5, p6 is selected.Transition p1-p4 is mapped onto transition s1-s2 on the initial controller; transition p4-p5 is mapped on transition s2 -s3.None of the transition p5 -p5 or p5 -p6 of the test plan can be mapped on a transition issuing from s2.One solution is to add a transition from s3 to s6, this extra transition will implement the test mode transition p5 -p6.

RESULTS
This method has been applied to five HLS benchmarks circuits.The RTL descriptions have been obtained with our HLS tool.Table I gives the fault coverage (FC), test efficiency (TE) and ATPG CPU time (CPU) for the datapath considered in isolation, the datapath connected to the initial controller and the datapath with the modified controller.These results have been obtained using the Synopsys suite.They show that the testability level have been raised very close to the maximum.Another way of solving the problem is to use scan chains in the controller either on the controller outputs (Scan-dec) or the next state flip-flops (Scan-sec).We compared these strategies with ours.For each strategy, Table II reports the fault coverage (FC), the test efficiency (TE), the area overhead (Over) and the test application time (in number of clock cycles).These numbers shows that the proposed technique compares favorably with scan insertion techniques with the advantage of shorter test time.
While the proposed method targets testability improvement of the datapath only, the results reported in Table III concerning the faults in the controller show that it improves a lot the testability of the whole circuit.
To have a fair comparison with the method proposed in Ref. [5] which in the general case involves modification of the controller and of the datapath, we used the example "Simple-RTL" for which only the controller is modified by TAO.Table IV reports the results in terms of fault coverage and area overhead.It can be seen that at least on this example, our method leads to better results.

DISCUSSION
As presented here, this method leaves some room for further improvements.In particular, the command words and transitions to add are the results of one test path for each module obtained from the datapath RT level testability analysis.This path can be insufficient for fully testing the module, even in the case of regular structures like datapaths.The testability analysis could be modified to produce several test paths and all these paths could be specified in the controller.This approach should lead to more testable designs but at the cost of a higher computation complexity and higher number of controller modifications.This last point gives room for trading off testability improvements vs. area overhead.Concerning area overhead, it must be noticed first that this method in its current version entails very little area penalty (cf."Results").Secondly, the larger the number of instructions of the original controller, the fewer testspecific instructions is needed.Furthermore, the larger the number of transitions, the easier it is to solve the test sequencing problem.In summary, the more complex the initial controller in terms of its transition density, the smaller the required overhead.

CONCLUSION
The controller modification method presented here raises the testability of a datapath to a level close to the achievable maximum.It is mainly based on a RTL testability analysis and does not require ATPG.When used in conjunction with the synthesis for testability of datapaths method presented in Ref. [8], highly testable circuits can be directly obtained at the cost of small area overhead.
As confirmed by the results, this method compares favorably with scan techniques while avoiding their drawbacks (additional delays, test time, number of test pins).

FIGURE 2
FIGURE 2 Fragment of a datapath.

FIGURE 3
FIGURE 3 Test limitations due to sequencing.

FIGURE 4
FIGURE 4 Circuit's architecture after modification.

FIGURE 8
FIGURE 8  Finite automata of test path for R3 in Fig.6.
Flottes received her Ph.D. degree in Electrical Engineering in 1990 from the University of Montpellier.She is currently a researcher for the French National Scientific Research Center.Since 1986, she has been conducting research in the domain of test at LIRMM laboratory.M.-L.Flottes' interests include Design For Testability, BIST, High Level Synthesis For Testability and test synthesis.Bruno Rouzeyre received his M.S. degree in Mathematics in 1978, Ph.D. degree on CAD in 1984, all degrees from the University of Montpellier.Currently, he is a

TABLE II
Professor at the University of Montpellier and conducts his research at LIRMM.His main fields of research include High Level Synthesis, Test and Testability and Verification.Laurent Volpe received his M.S. and Ph.D. degrees in Electrical Engineering from Montpellier University in 1996 and 1999, respectively.His research focused on the testability improvement from behavioral level (during High Level Synthesis) to RTL level (before logic optimization).Since 1999, he has been working for Cadence Design Systems.