Design and Synthesis of a Generic Board-Level Test Controller Jan Håkegård and Zebo Peng Dept. of Computer and Information Science Linköping University, Sweden Email:
[email protected] Tel: +46 13 282698 Fax: +46 13 282666
Abstract1 This paper describes an approach to hierarchical self tests by use of a test controller. As design for testability and Built-In Self Tests (BIST) at the board level are becoming increasingly important, research has been carried out on formulating test controllers to control test activities. In our approach, instead of providing a fixed test controller design, an automatic synthesis tool is developed to generate test controllers based on the specific properties of a board and its test requirements. In this way the test controller is more efficient and a better performance/cost ratio can be achieved.
1. Introduction With the increasing complexity and miniaturization of today’s Printed Circuit Boards (PCBs) it is becoming more and more difficult to apply traditional test techniques such as In Circuit Testing (ICT). The further addition of Surface Mount Technology (SMT), Multi Chip Modules (MCMs) and double sided circuit boards makes the situation even worse. Therefore an increasing interest is taken in Design For Testability (DFT) techniques. A major contribution to DFT at the board level has been the standardization of Boundary Scan (BScan) by IEEE [3]. This technique, as it reduces the need for ICT tests, is often supplemented with a Test Controller (TC). The idea of such a device is to enable control of the BScan chain without using special Automatic Test Equipment (ATE). In this way, self test as well as operation and maintenance test at the board level can be achieved. Several test controllers have been developed, ranging from simple BScan interfaces such as the Boundary Scan Master described in [4] to complete controllers running test programs on their own [2]. This paper describes our approach to the design of a Board-level Test Controller (BTC), which is used to support hierarchical test based on boundary scan techniques. This approach differs from research done previously in that a fixed test controller is not designed in advance, but rather the test controller is synthesized along with the software for the specific environment in which it will operate [12]. Further, our controller is designed to support efficient self test during the whole life cycle of the product. In the rest of this paper we first present some general ideas regarding the hierarchical test framework, followed by test controller design discussions. Then we address the main topic of this paper, namely how to automatically synthesize a test controller in section 3 and 4, where modeling, transformations and optimization issues are addressed. Finally conclusions are drawn.
2. A hierarchical Test Framework The motivation for a hierarchical test framework is to simplify testing at a higher hierarchical level by including self tests at lower levels. Today this is done in many ICs mainly by BIST schemes. The purpose of a test controller is to add similar capabilities at the board level, with a concept that can later be extended to the system level. This can be done by standardizing interface and commands to the test controller, and thereby the test controller will perform tests independent of the requesting 1. This work has been partially sponsored by the Swedish National Board for Industrial and Technical Development (NUTEK).
unit. As test controllers can be inserted at different levels in the design, test commands will only be sent to the highest level test controller, which will automatically propagate test requests downwards in the system. With this technique the communication between different units will be kept low, since test vectors and programs do not have to be passed between them. Another advantage is that a design change at a board will only change the test properties locally on the board, and will be fully transparent to the rest of the system. Similar hierarchical concepts have also been described in [7]. Currently three main techniques can be used to support hierarchical test. They are BIST, boundary scan and processor BIST (P-BIST). BIST directly supports the hierarchical concept, by providing internal tests at the IC level. At the board level boundary scan, a standardized technique that organizes the boundary of ICs into scan chains, can be used to simplify interconnection tests between circuits. Test patterns that are efficient for such testing have been developed [5][6]. Boundary scan is also intended for controlling BIST tests, and therefore, a test controller automatically controls this feature as well if the IC in question has a boundary scan interface. However, some ICs will not contain boundary scan and BIST, and these parts must then be accessed either from ICs containing boundary scan or from an on-board microprocessor (P-BIST), if one exists. We have developed a hierarchical DFT architecture [12] in which test control logic is inserted at different hierarchical levels. The top level hardware of the architecture is the subrack or similar unit having a communication link to a processor executing maintenance software. A gateway function at the subrack level terminates the communication link, and feeds information to a maintenance administrator/controller. The maintenance administrator/controller turns maintenance orders into instructions for the board test controllers residing on the different boards in the subrack.
3. Automatic Test Controller Synthesis As the properties of different boards vary, so do the requirements on the test controller. To our knowledge work made by other researchers has only considered fixed test controller designs (although test controllers have been developed for specific boards manually [1]). Work has also been made on the automatic insertion of hierarchical boundary scan support [9]. We argue, however, that the test controller hardware should be developed in parallel with the software, and be targeted to a specific board according to the test cost function and constraints that have been set up for the board. Our approach to the automatic synthesis of test controllers is sketched in Fig. 1. It consists of three main parts, the Board Analyzer which analyzes and extracts test-relevant information from the board, the Test Controller Generator which produces a model of a test controller, and a Test Program Generator which generates the test programs. Board Model
Design/Test Constraints Board Analyzer
DB
Test Controller Generator
BTC Arch
Test Program Generator Test Program
Test Controller
Figure 1:Overview of the proposed synthesis tool.
To make this approach feasible, a scalable test controller architecture is necessary. Such a controller is obtained by a Lego model where pieces can be selected and interconnected in different ways [12]. By careful evaluation of the advantages versus the costs of including a specific Lego piece, nearly optimal controllers can be generated. The design will be further optimized by selecting generic parameters for the pieces, such as communication bandwidth between them or the lengths of registers within them, thereby making the controller architecture highly flexible.
4. The Synthesis Technique We have developed a transformational approach to synthesize a test controller. This approach makes use of a design representation model which captures the intermediate design of the controller. When the synthesis process starts, a naive test controller is generated from the given test functions and requirements, and is captured in the design representation. A sequence of transformations are then applied to the design representation to improve it, step-by-step, until an efficient design is generated. In this way, the synthesis problem is formulated as an optimization task, and we are developing some efficient heuristic techniques to solve this optimization problem. The modeling of the controller, the transformations used to optimize the design, and the cost function used to guide the optimization process are addressed in the following sections. 4.1 Modeling The cornerstone of our transformational approach is the design representation model of a test controller. This model has been developed in such a way that it is compatible with the Lego approach [12] in which pieces (modules with generic parameters) with different functionality are incorporated. The purpose is to enable the synthesis tool to generate a test controller containing exactly the desired functionality, without having to pay for unnecessary features. This approach also make it easy to experiment with new features, as new modules can easily be implemented and made available to a future synthesis tool. The design representation model we use for the test controller is called a Test Deign Graph, TDG, and is based on two interconnected subgraphs. The first subgraph is the control part (see Fig. 2(b) for an example), which holds all necessary information about test scheduling. It is based on a Petri net representation [11] and is defined mathematically in definition 4.1. Definition 4.1: A control part, Γ, is a four-tuple, Γ = , where S = {S1, S2, …, Sn} is a finite set of control states (places); T = {T1, T2, …, Tm} is a finite set of transitions; F ⊆ (S×T)∪(T×S) is a binary relation, the flow relation; M0: S→{0,1} is an initial marking function. The second part of the TDG is the test path (see Fig. 2(a) for an example) and is defined mathematically by definition 4.2. Definition 4.2: A test path, Λ, is a six-tuple, Λ=, where TA = {TA1, TA2, …, TAn} is a finite set of test tasks; IM = {IM1, IM2, …, IMm} is a finite set of implementation nodes; IN = {IN1, IN2, …, INp} is a finite set of interface nodes; NO = IM∪IN is the set of nodes in the test path; NP = NP(NO1)∪NP(NO2)∪…∪NP(NOq) where NP(NOi) is the set of node ports associated with node i. BN ⊆ (NP×NP) is a finite set of arcs that connects two node ports; we assume that at least one node port should belong to an implementation node; BT ⊆ (TA×NO) is a finite set of edges that associates test tasks with nodes. The test path describes three properties of the BTC: the external connections of the BTC is described by the interface nodes depicted as the left most boxes in Fig. 2; the test tasks are depicted as ellipses; and the implementation nodes describe the actual hardware implementation of the BTC (they correspond to what will eventually be implemented as Lego Pieces). The thick arcs in the graph depicts the arcs which carries the communication in the graph, while the fine ones depicts the edges which are there to associate the nodes with the test tasks that they belong to. To form a complete TDG we need to define some relations between the above independent definitions of the control part and the test path. This is done in definition 4.3. Definition 4.3: A Test Design Graph, TDG , is a six-tuple, TDG=, where Γ = is a control part; Λ = is a test path; CP = CP(TA1)∪CP(TA2)∪…∪CP(TAn) where CP(TAi) is the set of command ports associated with test task i; RP = RP(TA1)∪RP(TA2)∪…∪RP(TAm) where RP(TAi) is the set of response ports associated with test task i; BC: S→2CP is a mapping from control states in the control part to a set of command ports in the test path; BR : RP→2T is a mapping from response ports in the test path to a set of transitions in the control
part. As defined by definition 4.3, the connections between the test path and the control part go through a set of command ports and response ports. These ports reside on the test tasks and control when the action is to start and signal its completion. By having more than one response port, normal or abnormal completion can be signaled for tests. The semantics of the control part is the same as that for a Petri net [11] and command ports are activated by a token in the associated control state while response ports fire associated transitions in the control part. A TDG example is given in Fig. 2, which describes a simple BTC handling only boundary scan interconnect and P-BIST tests. It also contains a board identification feature. B s c n
BScan Inter
BScan IF
BScan Engine
C P U
P-BIST
CPU IF
P-BIST
T b u s
Core
R s t
P2
P3
P5
P7 P8
P9
All Test Test Bus Interface
Error Rep
Error Report
Identify
Identify
Reset
P6
P1
Reset
(a) Test Path
P4 P1: Start (token) P2: BScan Inter P3: P-BIST P4: Report OK P5: Identify P6: Idle, OK (token) P7: P2 Error Rep P8: P3 Error Rep P9: Reset (b) Control Part
Figure 2:A Test Design Graph for a simple BTC handling only BScan interconnect and P-BIST tests.
To fully describe a BTC we need to specify several parameters associated with both the test tasks and the nodes. Examples of such parameters, for a boundary scan interconnect test task, are the length of the boundary scan chain and the expected test signature. Therefore we associate parameters with each test task. These parameters are then propagated to the implementation nodes, since they will be used to parameterize the hardware realization of the BTC. 4.2 Transformations With our model of the BTC, we can synthesize a large spectrum of controllers emphasizing different aspects such as the relative degree of completeness and adaptability. In terms of completeness BTCs may range from simple BScan interfaces [4] to complete, autonomously running controllers [2]. With different levels of adaptability a BTC can be targeted completely to a specific design, without any options to alter scan chains lengths etc., while at the other extreme the generality of our design can be utilized to produce fully programmable controllers, and can therefore be optimized to handle more than one board design. To provide a means for automatic moves between these different solutions we use design transformations. Thus we start from a working model and transform it to a better one based on our criteria of what we consider to be better in a particular case. Currently we have developed transformations for handling the implementation nodes, but this set of transformations can later be extended to handle also other aspects of the design. For the implementation nodes we need two main types of transformations: substitution and sharing. The first transformation is shown in the upper part of Fig. 3 and the purpose is to substitute a set of implementation nodes for another functionally equivalent set. The substitution example in the figure shows how a boundary-scan engine of type A is changed for one of type B. The latter lacks some registers that are instead implemented in a separate implementation node, the boundary-scan registers. The benefit of this substitution is that a node of type B
is easier to share between two different boundary scan operations than one of type A. This comes from the fact that some of the test specific parameters can be extracted and put into the boundaryscan register node. A sharing transformation that utilizes this fact can be seen in the lower part of Fig 3. Both the substitution and the sharing transformations are reversible, our approach support therefore also the reverse transformations. 4.3 Optimization To select a sequence of transformations to be applied to our model is an optimization problem; we want to generate finally the best test controller. The optimization task can be carried out manually by the designer or be automated by a heuristic algorithm. We are currently developing a heuristic technique to allow for automated transformations. This requires an algorithmic way of estimating the goodness of each implementation alternative, i.e. a cost function, and an efficient way of exploring the design space.
BScan Inter BScan Inter
BScan IF
BScan Engine B
BScan Registers
BScan Engine A
Substitution
BScan Inter BScan Inter
BScan IF
BScan Engine B
BScan Registers
BScan Engine B
BScan Registers
Sharing BScan Inter BScan Inter
BScan IF
BScan Engine B
BScan Registers BScan Registers
Figure 3:A substitution followed by a sharing transformation applied to a boundary scan engine.
4.3.1 Cost Function We have defined two costs for the TDG: hardware cost and execution time. Hardware cost is estimated separately for the control part and the test path. For the control part we estimate the complexity of the controller by counting the number of arcs in the Petri net, which reflects its complexity. Mathematically this is expressed as: Cost(Γ)=∑i |˙Si| + ∑j |˙Tj| where ˙Si = { T | (T, Si) ∈ F}, the pre-set of Si ∈ S; ˙Tj = { S | (S, Tj) ∈ F}, the pre-set of Tj ∈ T. The same method has been successfully used before in [8] for estimating the complexity of Extended Timed Petri Nets [8]. The cost originating from the test path is estimated as a sum of three costs: the complexity of the implementation nodes, the number of external interconnections required on the BTC, and finally the complexity of the communication between the control part and the test path. A pseudo mathematical definition is given below: Cost(Λ) = K1∑i Cost(IMi) + K2∑j Cost(INj) + K3∑k Cost(TAk) where
Cost(IMi) = a function over the type of the node and its associated parameters; Cost(INj) = the number of pads in INj; Cost(TAk) = |CP(TAk)| + |RP(TAk)|; K1, K2 and K3 are weight factors, which are given by the designer. Finally we have to consider the execution time of the tests. This is done by examining the control part to see which test actions that are initiated in the test path. For each activated test task we then look at its implementation and find execution times associated with its corresponding implementation nodes. As the execution time of an implementation node varies over its parameterization we need a time/cost function associated with each implementation node along with the hardware cost used for the hardware/cost estimation. The model can be expanded with additional cost measures such as testability and reliability of the BTC. 4.3.2 A Heuristic Algorithm Optimization will be carried out with a Tabu search algorithm [10] since this algorithm is not only efficient but also has some properties which makes it naturally applicable to our kind of optimization problem. One such property is its neighborhood search character where a neighbor can directly be found in our problem by applying a transformation. Tabu search is also a flexible heuristic that we can continue to use when we eventually expand the optimization problem to handle new aspects that we are currently not optimizing for, such as scheduling optimization in the control part.
5. Conclusions We have proposed a hierarchical test approach based on test controllers and boundary scan. This approach differs from research done previously in that fixed test controllers are not designed in advance, but rather the test controller is synthesized along with the software for the specific environment in which it will operate. By doing so we achieve more efficient test controller implementations matching the requirements of the boards in terms of test efficiency and cost. We have also proposed a test controller architecture, and presented the basic ideas related to the automated synthesis of such a controller. The synthesis technique is based on a transformational approach which operates on a Petri net based design representation model. By capturing the intermediate design of a test controller precisely during the synthesis process, efficient estimation and exploration algorithms such as the Tabu search heuristics can be used to generate high quality implementations.
References [1] W. Jager, H. Hulvershorn, S. Adham, “Self-Testing Hardware to Improve Fault Detection and Isolation in switching Systems,” Fifteenth International switching symposium, pp. 299-303, April 1995. [2] J. S. Matos, F. S. Pinto, J. M. M. Ferreira, “A Boundary Scan Test Controller for Hierarchical BIST,” International test conference, pp. 217-223, 1992. [3] IEEE Std. 1149.1-1990, “IEEE 1149.1 Standard Test Access Port and Boundary-Scan Architecture,” IEEE Computer Society, 1990. [4] N. Jarwala and C. W. Yau, “The Boundary-Scan Master: Architecture and Implementation,” Second European test conference, pp. 1-10, April 1991. [5] A. S. M Hassan, V. K. Agarwal, B. Nadeau-Dostie and J. Rajski, “Testing and Diagnosis of Interconnects using Boundary Scan Architecture,” International test conference, pp. 126-137, 1988. [6] P. Goel and M. T. McMahon, “Electronic chip-in-place test,” International test conference, pp. 83-90, 1982. [7] N. Jarwala and C. W. Yau, “A Framework for Boundary-Scan Based System Test and Diagnosis,” International test conference, pp. 993-998, 1992. [8] Z. Peng and K. Kuchcinski, “Automated Transformation of Algorithms into Register-Transfer Level Implementations,” IEEE Transactions on Computer-Aided Design of Integrated Circuits, vol. 13, no. 2, pp. 150-166, February 1994. [9] O. F. Haberl and T. Kropf, “HIST: A Hierarchical Self Test Methodology for Chips, Boards, and Systems,” Journal of Electronic Testing: Theory and Applications, vol. 6, no. 1, pp. 85-106, 1995. [10] F. Glover, E. Taillard and D. de Werra, “A user’s guide to tabu search,” Annals of Operations Research, vol. 41, pp. 3-28, 1993. [11] J. L. Peterson, “Petri Net Theory and the Modeling of Systems,” Prentice-Hall, Englewood Cliffs, N.J., ISBN 0-13-662983-5, 1981. [12] J. Håkegård, G. Carlsson, Z. Peng, “A Board-Level Test Controller to Support a Hierarchical DFT Architecture,” IEEE European Test Workshop, June 1996.
