Development of a Boundary Scan Test controller creation tool

Transcription

1 Eindhoven University of Technology MASTER'S THESIS Development of a Boundary Scan Test controller creation tool by J.H. Coenen Supervisors: Prof. Ir. M.T.M. Segers Ir. M.N.M. Muris The faculty of Electronical Engineering of the Eindhoven University of Technology does not accept any responsibility regarding the contents of student project and master's thesis

2 Acknowledgements First of all, I would like to thank Rene Segers for making it possible for me to do my graduation project at the Philips Research Laboratories Eindhoven. I am very grateful to Math Muris for his considerable support during the last seven months and for bringing up the idea for this thesis. I am also grateful to the Philips Research Laboratories Eindhoven, at which the research for this thesis was carried out. I am in particular thankful to all the members of group Segers, who often helped me with various problems and with whom I had interesting conversations about various subjects during my period at the Philips Research Laboratories Eindhoven. Ronald Coenen, July RWR-558-RC RC Page i

3 Abstract Boundary Scan Test is a different approach to printed circuit board testing. It requires additional hardware around the core logic in an Integrated Circuit. This additional hardware consists of boundary scan cells and a controller. Functionality of the test logic is determined by the instruction set implemented in the controller. This thesis addresses the development of an automatic Boundary Scan Test controller creation tool, named Concreto. Concreto can create a Boundary Scan Test controller design on basis of a flexible instruction set specification. The generated Boundary Scan Test controller is part of a Boundary Scan Test circuit compatible with the IEEE Std on Boundary Scan Test. This Boundary Scan Test circuit can automatically be added to an Application Specific Integrated Circuit design by a tool named TimNet. Concreto can generate an interface file required by TimNet. The generated Boundary Scan Test controller design is described in VHDL, on Register Transfer Level. This design can be simulated on a VHDL simulator. Concreto can generate the required test bench and the test patterns for functional verification. RWR-558-RC RC Page ii

4 Acronyms and Abbreviations ANSI ASCII ASIC BNF BSDL BST Concreto DFT DUT FSM IEEE LOCAM RTL RTI SDM TAP TCK TDI TDO TIM TMS TRST TSSI VHDL VHSIC VSyn The American National Standard Institute The American Standard Code for Information Interchange Application Specific Integrated Circuit Backus Naur Form Boundary Scan Description Language Boundary Scan Test BST Controller Creation Tool Design For Testability Device Under Test Finite State Machine Institute of Electrical and Electronic Engineers Philips suite of synthesis tools Register transfer level Run Test/Idle state of the TAP controller System Development Methodology Test Access Port Test Clock input pin contained in the TAP The Test Data Input pin contained in the TAP The Test Data Output pin contained in the TAP Testability IMprover Test Mode Select input pin contained in the TAP Asynchronous test logic reset input pin contained in the TAP Test Systems Strategies Inc. VHSIC Hardware Description Language Very High Speed Integrated Circuits VHDL Synthesis system, component of the LOCAM Logic Synthesis Package RWR-558-RC RC Page iii

5 Table of Contents Acknowledgements. Abstract Acronyms and Abbreviations Table of Contents III IV 1 Introduction Purpose Overview 1 2 Boundary Scan Test Introduction to Boundary Scan Test The Boundary Scan Test architecture The Boundary Scan Test controller The boundary scan register The Boundary Scan Test instruction set Providing an IC with Boundary Scan Test Problem definition 7 4 Analysis of the Boundary Scan Test Controller Introduction Functional units of the BST controller The TAP Controller The instruction register The instruction decoder The output multiplexer The bypass register The single transport chain concept Timing of the BST controller Parameters of the BST architecture VHDL description Introduction to VHDL Aspects of VHDL VHDL design units Inputs and outputs Variables, signals and constants 17 RWR-558-RC RC Page iv

6 5.3 Simulation of a VHDL design Synthesizing the VHDL design The BST controller model in VHDL Definition study Purpose Information requirements Required output Required input 22 7 Functional design Introduction Input The instruction library The instruction set specification Process Reading the input Processing the input information Writing the output Output The VHDL description of the BST controller The test patterns The VHDL description of the test bench The TimNet interface file The data structure of Concreto Technical design Input Syntax of the instruction library Syntax of the instruction set specification Process Parsing the instruction library Parsing the instruction set Processing the information Writing the VHDL description of the BST controller Writing the test patterns Writing the test bench Writing the TimNet interface file Output The VHDL description of the BST controller The test patterns The VHDL description of the test bench 40 RWR-558-RC RC Page v

7 8.3.4 The TimNet interface file 41 9 Programming and testing Programming Description of the test cases An elaborate example Conclusion 48 Bibliography 49 Appendix A : State diagram of the TAP controller 51 Appendix B : Invocation of Concreto 52 Appendix C : Concreto syntax description 53 Appendix D : Syntax Concreto instruction library Appendix E : Syntax Concreto instruction set specification Appendix F : Syntax of the signal definition file Appendix G : Syntax of the signal level file 60 RWR-558-RC RC Page vi

8 1 Introduction 1.1 Purpose This thesis describes the graduation project that I carried out at the Philips Research Laboratories Eindhoven. The purpose of the project was to design and implement an automatic VHDL generator for Boundary Scan Test controllers. The main goal of this thesis is to treat the research that is performed during the graduate project. This is performed by describing the research and development path of the software tool. Finally, the aim of this thesis is at a clear discussion of all problems that are encountered during the graduation project. 1.2 Overview This thesis starts with a short introduction to Boundary Scan Test (BST), described in [IEEE90]. The Boundary Scan Test controller has been analyzed and all parameters have been determined, in order to be able to generate the controller automatically. The controller will be generated in a VHDL description. VHDL is treated in [IEEE88]. The aspects of VHDL will be described in chapter 5. Automatic BST controller generation is accomplished by a software tool named Concreto. The design and implementation of this tool is described using the System Development Methodology (SDM), described in [EILE87]. First the information requirements are determined in chapter 6. The input, process and output of Concreto are described in chapter 7 and 8. The implementation is treated in chapter 9. An elaborate example of the design of a BST controller generated by Concreto IS described in chapter 10. RWR-558-RC RC Page 1

9 2 Boundary Scan Test 2.1 Introduction to Boundary Scan Test The old way of testing a printed circuit board (PCB) by means of bed-of-nails fixtures has reached technological limits. The increasing miniaturization of the PCB's and the use of more complex IC's makes board testing more difficult. Boundary Scan Test (BST) technology is a different approach to PCB testing. BST resolves the test node accessibility problem by offering access to the input and output pins of complex digital circuits on a PCB. This is done by means of a test bus which may consist of merely 4 wires, thereby providing an effective method for board level and system level testing. In 1990 the document titled "Standard Test Access Port and Boundary-Scan Architecture" was approved by the IEEE standards Board as IEEE Std , described in [IEEE90]. In August 1990 the American National Standards Institute (ANSI) also recognized this standard. In a Boundary Scan IC a shift register is placed between the core logic and the input and output buffers adjacent to each IC pin. This shift register is called the boundary scan register. Each shift register stage is contained in a boundary scan cell. A boundary scan cell can observe and control what happens at each input and output pin of an Ie. The serial path is provided with serial input and output connections and appropriate clock and control signals. Within a product assembled from several integrated circuits the boundary scan registers of the individual components can be connected in series to form a single path through the complete design. Alternatively, a board design could contain several independent boundary scan paths. 2.2 The Boundary Scan Test architecture The overall test architecture, as prescribed by the IEEE Std distinguishes four basic elements: The Test Access Port (TAP) The TAP controller The instruction register A group of test data registers The TAP is a general purpose port that can provide access to many test support functions built into a component, including BST. It is composed as a minimum of the three input connections and one output connection required by the test logic defined by the IEEE Std The input connections consist of the Test Clock input (TCK), the Test Mode Select input (TMS) and the serial Test Data Input (TDI). The RWR-558-RC RC Page 2

10 output connection is the serial Test Data Output (IDO). An optional fourth input connection, the active low Test Reset input (TRST*), provides for asynchronous initialisation of the test logic. The BST architecture is shown in figure 1. The dotted outlined test data registers are optiona}. The dark shaded blocks of the architecture are part of the BST control section. test data registers ---. Device ill register tdi Output buffer tdo trst* tins tck Figure 1. The Boundary Scan Test architecture. The TAP controller is a synchronous finite state machine that is controlled with the TMS signal. The function of the TAP controller is to provide clock and control signals required for the correct operation of the on chip test circuit. The instruction register and the group of test data registers have separate, alternative shift-register based serial access paths, connected in parallel between TDI and TDO. Selection of the alternative path is made under control of the TAP controller. The Boundary Scan architecture must contain a minimum of two test data registers: the bypass register and the boundary scan register. A third register, the device identification register, is optional. Each named test data register included in the architecture has a fixed length and is addressable through at least one instruction of the instruction set. The addition of a design specific test data register is accomplished by adding RWR-558-RC RC Page 3

11 an instruction, which addresses that test data register, to the instruction set of the architecture. For every IC with Boundary Scan Test a BST circuit has to be added to the core logic. This process can be automated. To make this process easier, the BST circuit is functional divided in two parts: The Boundary Scan Test controller The boundary scan register, and optional test data registers The Boundary Scan Test controller The BST controller contains all the logic to implement Boundary Scan Test in to an IC, except for the test data registers. An exception forms the bypass register, which is contained in the BST controller. The controller generates the control signals to control all test logic in an IC, for example the boundary scan register. The BST controller is built from several functional blocks. These blocks are contained in the BST controller because they are part of every BST circuit, and their architecture is a function of only a few parameters. Although the bypass register is a test data register, it is part of the BST controller. The bypass register is a mandatory register, with a fixed length of one cell, which can share hardware with the instruction register. This will be described in section The boundary scan register The boundary scan register consists of a chain of boundary scan cells. This chain can be different for every type Ie. During normal IC operation, the boundary scan cells are transparent. When the IC is placed in a scan mode, the boundary scan cells are configured to allow test stimulus to be shifted in and applied from each boundary scan cell output. Test response data is captured into each cell input and shifted out for inspection. Depending on the control signals, each boundary scan cell either captures data on its input, updates data on its output, or serially shifts data to its neighbour. 2.3 The Boundary Scan Test instruction set To perform operations on the test data registers, the instruction register allows instructions to be serially entered into the test logic. The IEEE Std on Boundary Scan Test describes a number of instructions, and their functionality. The instructions are divided in two groups: public instructions RWR-558-RC RC Page 4

12 private instructions Public instructions are instructions that must be available for all purchasers of a component. These instructions are documented and supplied by the manufacturer along with the component. Some of the public instructions are mandatory, a few with mandatory instruction codes. This implies that every BST circuit must support these instructions. Design specific instructions can be added to allow the functionality of the test logic built into a component to be extended. These instructions are called private instructions. They allow the component manufacturer to use the TAP and test logic to gain access to test features embedded in the Ie for design verification, production testing or fault diagnosis. The operation of private instructions need not to be documented for the purchaser of the component. 2.4 Providing an Ie with Boundary Scan Test TIM (Testability IMprover) is a software package developed to assist a designer to incorporate a BST circuit in an Ie. The concept of the TIM package is described in [MURI90]. TIM consists of two parts, TimNet and TimPat. In figure 2 the flow of the TIM package is listed. TimNet will add both the BST controller and a chain of boundary scan cells around the core logic of the Ie. The inputs, function and output of TimNet are described in [EERE92]. The controller and cells are selected from a library. An implementation of such library is described in [MURI93]. Besides the actual BST circuit and peripheral buffers, TimNet will also produce a data sheet describing the BST relevant aspects of RWR-558-RC RC Page 5

13 the device in the VHDL based Boundary Scan Description Language (BSDL). More information about BSDL can be found in [PARK92]. TimPat is a software package supporting test pattern generation and design verification of devices with BST. Given the description of a BST device in the BSDL format, TimPat will either generate test patterns for design verification of the device, or will generate test patterns for production testing of the device. RWR-558-RC RC Page 6

14 3 Problem definition As described previously, the BST controller and the boundary scan cells are selected from a library by TimNet. This implies that only a limited set of BST controllers is available for implementation. The IEEE Std allows beside public instructions, the implementation of private instructions. Theoretically, an infinitive number of different instruction sets can be defined. For every combination of instructions in the instruction set, a controller circuit has to be designed. This has to be performed manually. It is unfeasible to design all those controllers manually. To be able to create a new controller description quickly and easily, this process must be automated. The possibility of generating the BST controllers automatically on the basis of a specification, is researched. To do this, an overview of the architecture of all possible variants of the BST controller has to be created. This is described in the following chapter. RWR-558-RC RC Page 7

15 4 Analysis of the Boundary Scan Test Controller 4.1 Introduction The circuit which the BST controller is part of, is based on IEEE Std , "Standard Test Access Port and Boundary-Scan Architecture", and is fully compatible to it. The IEEE Std contains a number of rules that specify the mandatory aspects of the BST controller architecture. In this chapter the architecture of the BST controller is analyzed, with use of the IEEE standard and the set of currently specified instructions. Research has been done to the consequences the specification of each instruction has on the architecture of the controller. This is done on basis of an existing implementation of a Boundary Scan Test library, described in [MURI93]. Note that automatic generation of a BST controller is only possible when all possible variants are fully specified and all parameters are determined. 4.2 Functional units of the BST controller The architecture of a BST controller as shown in figure 1 can be divided in several functional units. These functional units are: The TAP controller The instruction register The update register and instruction decoder The output multiplexer The bypass register The BST controller is a synchronous design with an optional asynchronous reset. This means that all memory elements of the circuit are synchronous to one clock signal, the externally connected TCK signal. Note that due to the specification in the standards document, transitions take place on both rising and falling edges of TCK The TAP Controller The TAP controller is a 16 state synchronous finite state machine (FSM) that is controlled with the input Test Mode Select (TMS). The FSM keeps track of the present state of the TAP controller. State transitions occur on rising edges of the Test Clock (TCK), whereas actions in the connected test logic occur at either the rising or the falling edge of the TCK. The TAP controller controls the sequence of operations of other BST circuitry. No matter what the original state of the controller, it will enter the Test Logic Reset state when TMS is held high for at least five rising edges of TCK, or by applying a RWR-558-RC RC Page 8

16 low logic level to the active low asynchronous reset input, if present. The test logic is disabled in this state so that normal operation of the on-chip system logic can continue unhindered. State assignment of the FSM has already been performed in an optimal manner with respect to a minimum of combinatorial logic. The state diagram of the TAP controller is listed in appendix A. In order to be able to simulate the function of a BST controller circuit on a logic simulator, an additional flip-flop has been included in the TAP controller to keep the previous value of TMS. By introducing this additional memory element, the TAP controller can be initialized by the logic simulator, without the need of forcing internal nodes. Due to the fact that at the start of a simulation the values of all flipflops of the TAP controller are set to UNKNOWN, the current state is UNKNOWN, and the next state will also be UNKNOWN, and will remain UNKNOWN. With the previous and the current value of TMS, it is possible to set the flip-flops of the TAP controller to a defined state. With this flip-flop, the TAP controller will enter the Test Logic Reset state during simulation after TMS held high for 5 clock periods The instruction register The instruction register allows an instruction to be shifted into each IC along the PCB-level path. The design of the instruction register is a serial-in/out parallel-in/out register. The serial shift register holds the instruction bits moving through the instruction register. Actions of the serial shift register take place on the positive edge of TCK, at the end of the current TAP state. Information can be shifted through the instruction register in the Shift-IR state. The instruction register is specified to hold the current value in the Exitl-IR, Exit2-IR, Pause-IR and Update-IR states. The cells of the instruction register can capture a value in the Capture-IR state of the TAP controller. The two least significant instruction register cells must load a fixed binary "01" pattern, the other cells capture design specific values. Functions of the instruction register other than the states described above are not defined by the IEEE Std All implemented instructions must have fixed instruction codes of equal length. The length of the instruction register is determined by the length of the instruction codes. The capture code must also have this length. The minimum length of the IR is 2 bits, to meet the rule of the three mandatory instructions. The output latch of the instruction register, holds the current instruction of the BST controller. This parallel register can only change value when the TAP controller is in the Update-DR or Test Logic Reset state. The parallel output latch operates at the negative edge of TCK. RWR-558-RC RC Page 9

17 The output latch is updated in the Update-IR state. In this state the instruction represented by the instruction code present in the serial instruction register, is latched into the output latch. When the TAP controller is in the Test Logic Reset state, a fixed instruction is captured by the output latch. This fixed instruction is captured asynchronously by the instruction register when the external asynchronous reset signal TRST is low. This is achieved by initializing the instruction register to contain the IDCODE instruction, or if the IDCODE instruction is not provided, the BYPASS instruction. Figure 3 shows the architecture of the serial instruction register, instruction decoder and the parallel update register. Serial out TAP-state Serial instruction register Output latch FF logic (State-dependent) Instruction decoder Outputs to test logic (Static) TCK TCK Serial in Figure 3. Architecture of the instruction register and instruction decoder The instruction decoder The output of the instruction decoder determines the test to be performed and the test data register to be accessed. The selection and operations of the test data registers are controlled by several signals. The values of these signals are determined by the current state of the TAP controller and the current instruction. For design specific test operations, some control signals must be applied to the core logic of an Ie. Signals controlled by private instructions, are also generated by the instruction decoder. Some of these signals have a value that is asynchronously controlled by one RWR-558-RC RC Page 10

18 of the inputs, e.g. TDI. Basically the instruction decoder consists of combinatorial logic, and the value of the outputs is a function of the inputs only. For timing purposes, the output latch of the instruction register is combined with the instruction decoder. Before an instruction is captured, it is decoded, and the decoded signals are captured by a parallel register. Functionally, this circuit is equivalent to the original configuration of the output latch and decoder. The length of the parallel register may be different from the length of the serial shift register, which is determined by the length of the instruction code. The length of the parallel register is determined by the functionality of the instruction set. In this way, the register contains instruction code independent information. From the value in the parallel register and the current state, the values of the outputs must be determined. The representation of the instructions in the output latch is determined on the basis of the specified values of the outputs of the instruction decoder, see figure 3. These outputs are divided in two classes: Static outputs: Outputs that can only change value in the Update-DR state or Test Logic Reset state of the BST controller for all implemented instructions. State-dependent outputs: Outputs that have a value determined by the current instruction and the state of the BST controller. For each static output a flip-flop is reserved in the parallel register. The value of the flip-flop determines the value of the static output. The value of the state-dependent outputs depend on the current instruction and the current state of the TAP controller. The values of all state-dependent outputs for all states for an instruction are called a set. Some instructions have identical values of the state-dependent outputs for all states, and are said to have identical sets. When instructions have identical sets, it does not matter which of those instructions is the current instruction in order to determine the output values of the state-dependent outputs. When more then one set exists, a variable needs to be stored that selects the correct set of all sets of values of the state-dependent outputs. In most cases this implies information reduction, resulting in smaller silicon area The output multiplexer The output multiplexer connects the serial output of a register to the TDO pin of the chip. Besides the bypass register, all test data registers must have an unique input name on the controller. When a test data register is selected, its input is connected to TDO. An additional test data register is implemented in the design of the BST controller by adding an input to the output multiplexer. Which register is selected is determined by the state of the TAP controller and the RWR-558-RC RC Page 11

19 current instruction in the instruction decoder. In the Shift-IR state the serial output of the last instruction register cell is connected to TDO. In the state Shift-DR the serial output of the last cell of the test data register, selected by the current instruction, is connected to TDO. To prevent glitches on the TDO output, the value is captured by an output flip-flop on the negative edge of TCK in the Shift-IR and Shift-DR states. Figure 4 shows the architecture of the output multiplexer. Current instruction TAP state From test data registers M U X From instruction register " " M U X M U X " OEN TAP state FF FF IDO TCK Figure 4. Architecture of the output multiplexer. The output enable signal (OEN) controls the output buffer of TDO. This signal can be active high or active low, depending on the type of output buffer that is available in the used technology. The signal OEN is controlled by the TAP state. Only in the states where the instruction register or the test data registers are shifted, is the buffer enabled. Because the TDO flip-flop is updated at the negative edge of TCK, the output buffer may only be enabled after this event. Therefore a negative edge flipflop is used to synchronize the OEN signal with IDO The bypass register The bypass register is a mandatory single stage shift register. It is implemented to be able to provide a minimum length synchronized serial path between TDI and IDO. This path can be selected when no other test data register needs to be accessed during a board level test operation. If on a board only one IC has to be tested, all the RWR-558-RC RC Page 12

20 other IC's can be bypassed. This reduces the length of the test patterns and therefore the testing times considerably. The function performed by the bypass register is determined by the state of the TAP controller. The bypass register captures a logic 0 in the capture-dr state of the TAP controller. In the Shift-DR state it shifts data from IDI to IDO. Operations on the bypass register take place on the positive edge of TCK, at the end of a TAP state. 4.3 The single transport chain concept The single transport chain (STC) concept is a means to reduce the hardware cost of the additional BST circuit by combining different registers into one single transport chain. The only two registers part of the BST controller are the instruction register and the bypass register. These two registers can be combined into one register, for they operate in disjunct states of the TAP controller. Figure 5 shows a simplified example of a four bit length instruction register combined with the one bit length bypass register. TDI Register cells Instruction register output to TDO ~ ~ Bypass register output to IDO Figure 5. The single transport chain concept (STC). The bypass register is implemented in the most significant cell of the combined register. This is the cell nearest to IDI. The serial output of this cell is connected to the next cell of the serial register and to the output multiplexer. In the Capture-IR state, the instruction register capture code is loaded in the register, and in the Capture-DR state a 0 is loaded in the most significant cell of the combined register. 4.4 Timing of the BST controller The BST controller operates on both the positive and the negative edge of TCK. As a result the output signals of the controller can alter also on both edges of TCK. The RWR-558-RC RC Page 13

21 TAP controller and instruction register combined with the bypass register operate both on the positive edge of TCK. Therefore the instruction register and the bypass register operate at the end of the current state. The flip-flops of the output latch of the instruction register can only change value on the negative edge of TCK in the Update-IR state or in the Test Logic Reset state. Some outputs of the instruction decoder depend on the state of the TAP controller, and therefore can alter on both edges of TCK, for state changes occur at rising edges. In some cases it is desired that the outputs of the instruction decoder change value only at the negative edge of TCK. In that case an additional negative edge flip-flop is provided in the data path of those signals. 4.5 Parameters of the BST architecture The architecture of each functional block of the BST controller is a function of one or more parameters. The parameters of all blocks are listed in table 1. Table 1. Parameters of the BST controller architecture. IFunctional unit I Parameter(s) I TAP controller instruction register instruction decoder Asynchronous reset Instruction code length Capture code Implemented instructions (codes) Selected test data register. Specified outputs Asynchronous reset Buffered outputs output multiplexer implemented test data registers asynchronous reset active high/low output enable bypass register - These parameters together with the static definition of the BST controller fully specify the architecture of a BST controller. Automatic BST controller generation can be defined as a function with the parameters as input, and the description of the BST controller circuit as output. RWR-558-RC RC Page 14

22 5 VHDL description 5.1 Introduction to VHDL The BST controllers are described in VHDL (VHSIC Hardware Description Language). One reason is that VHDL is rapidly emerging as one of the most important electronic design languages. VHDL was developed under a US Government contract and became an IEEE standard in 1987, the IEEE Std , "IEEE Standard VHDL Language Reference Manual", described in [IEEE88]. The VHDL language is also treated in [COEL89] and [LIPS89]. The reason for developing VHDL was to address a number of recurrent problems in the development, exchange and documentation of digital hardware. Other reasons are that VHDL is technology independent, is theoretically not tied to a particular simulator or value set, and does not enforce a design methodology on a designer. VHDL has a wide range of descriptive capabilities. It supports behavioral description of hardware from the digital system to the gate level. In this chapter a few aspects of the language are explained. These aspects concern the VHDL description of the BST controller. 5.2 Aspects of VHDL VHDL is a hardware description language that makes it possible to describe a design in a hierarchical form. Therefore, VHDL defines several design units. These design units are described in the next paragraph. The remaining paragraphs describe some aspects of constructs in the VHDL language VHDL design units The design entity is the primary hardware abstraction in VHDL. It represents a portion of hardware design that has well-defined inputs and outputs and performs a well-defined function. Conceptually, the entity is the components symbol. Entities can be instantiated in a higher level of a design. The actual function of the component is defined in an architecture. The architecture contains the model for all of the behaviour of the entity. It is possible to create a number of uniquely named architectures for one entity, as long as each architecture shares the same ports as the entity. Because an entity can have multiple architectures, VHDL provides a mechanism for linking an entity to a particular architecture for simulation. Configurations describe how VHDL should bind libraries and components in order to form the complete design. In case one design file contains the entity and RWR-558-RC RC Page 15

23 only one architecture, a configuration statement is not necessary. Unlike most programming languages, VHDL is a concurrent language. Therefore, VHDL defines constructs contained in an architecture, called processes. Processes are functional units that can contain any number of operations that specify how data moves through the functional unit and what happens to the data as it passes through. Therefore a number of constructs are available to build the algorithms contained in a process. These constructs look like constructs used in programming languages like C or Pascal. Processes can all execute at the same time. Although code within a particular process executes sequentially, code in separate processes can execute concurrently. The execution of a process statement consists of the repetitive execution of its statements. A sensitivity list can be defined for a process, and consists of a list of signal names that are input signals of that process. When a sensitivity list is specified for a process, the process will wait at the end of its sequence of statements until at least one of the signals named in the sensitivity list is assigned a new value. Then the process is executed from the beginning of the statement part down to the end where it will wait again. Such a process executes once through at the beginning of simulation. Among the other VHDL elements, packages are collections of subprograms that can be used in a design. Like functional units, which are composed of entities (external view) and architectures (internal view), packages are built in two pieces. The package declaration describes the interface to each of the subprograms in the package. The package body specifies and implements each of these subprograms. There are two types of subprograms: Function: returns a value without affecting the input(s). Procedure: acts on and modifies input variables, able to return several values to the calling program. All of these VHDL constructs reside in a library. Although VHDL allows user defined libraries containing user packages, entities and architectures, the language provides a working library WORK, used as default Inputs and outputs In an entity declaration all the signals that interface to that entity must be declared. The signal declarations include the signal's type and its mode. The mode defines the RWR-558-RC RC Page 16

24 direction of data flow into and out of the entity. VHDL defines 4 modes: in out inout buffer According to the IEEE Std VHDL Language Reference only objects of mode in and inout can be read. Reading input values from objects of mode out or buffer is an erroneous operation. Writing is allowed to all objects of mode other than in. An object of mode out can not be used as select variable or source variable for another object, for it is not possible to read the value of the variable within the entity. One can bypass the problem by inserting a buffer between the actual out port and the node that drives it. The difference between inout's and buffer's is that when an inout is read, the result is the port's incoming value, not the assigned value (if any). In contrast a buffer can only have one driver. Thus the result of a read operation is the value assigned to it Variables, signals and constants VHDL provides two mechanisms for transferring data values, signals and variables. Although both synthesize into the same element, a wire or signal line, they simulate differently. A variable is defined as an object with a single current value, no history and variable changes are immediate. Although variables can be used for data transfer within a process, they are local values that have no visibility outside that process. A signal is defined as an object with a past history of values. Signals can have multiple drivers, and value assignments are scheduled to occur later in time. These assignments are called events of the signal. Signal assignments contained in a process do not take effect until the end of the process. Signals are global elements that can move data between processes. Signals are also a means to account for wired-or constructions. All variables, signals and constants in a design need to be declared by assigning a type. A type is characterized by a set of values and a set of operations. Some types are predefined and declared in the package STANDARD. This package contains e.g. the types BIT and BIT VECTOR. Constants also need to be assigned a value of the declared type. RWR-558-RC RC Page 17

25 5.3 Simulation of a VHDL design To be able to simulate a design model written in VHDL, a so called test bench has to be created. A test bench is a means of validating VHDL models. A test bench can be described as a shell that includes an instantiation of the design model. This piece of VHDL code applies stimuli to the inputs of the design model, and when a test bench is thorough, verifies the responses. Figure 6 shows the flow of a test bench. Stimuli Test patterns / '- Expected responses Device Under Test Responses Verification Figure 6. Flow of a test bench. Simulations are carried out on a VHDL simulator. There are a number of simulators from several vendors. Because of the availability of the simulators and the simplicity of the designs to be simulated, the author has chosen to make use of the Cadence VHDL-XL simulator, explained in [CADE90]. The Cadence VHDL-XL simulator version accepts only a subset of the complete VHDL language. The constructs that the simulator does not support are: Multi-dimensional arrays. Multi-dimensional arrays are useful for modelling blocks like RAM or ROM. User defined attributes. Information about a signal or an entity can be obtained through the use of attributes. For example, it is possible to define the fan-in and fan-out of a signal by means of attributes. There are some built-in attributes, but they are not always properly evaluated by the VHDL-XL simulator. Declaration of a separate configuration. In case of more than one architecture for an entity it is not possible to define which architecture should be used Copyright N. V. Philips' Gloeilampenfabrieken, 1993 RWR-558-RC RC Page 18

26 during simulation. Therefore only one architecture for an entity is allowed. Alias definition. Aliases can be useful for making VHDL descriptions better readable and manageable. Examples are splitting and renaming of bus signals. Because a BST controller does not contain ROM or RAM, multiple architectures or busses, the Cadence VHDL-XL simulator version can be used for this project. 5.4 Synthesizing the VHDL design The VHDL description of the controller must be synthesized into gates. VSyn, component of the Philips LOCAM logic Synthesis Package, performs synthesis of VHDL designs. The usage of VSyn is described in [ED&T92]. Developing digital circuits using VSyn requires a particular VHDL design style. VHDL is a very flexible language, and not all VHDL constructs can be synthesized. Besides the non-synthesizable constructs, Vsyn only supports a subset of the synthesizable VHDL constructs. If during an evaluation of a process, a signal is not assigned a new value, it will keep the value it got in a previous evaluation. Thus, memory is introduced in an implicit way. Such a signal has in fact become a state variable. VSyn does not support implicit state variables. This results in the restriction that the VHDL description of the design must be in register transfer level (RTL) description style. This restriction implies that every memory element in the design must be explicitly declared. VSyn does not support the variable type. For instance it is not possible to use a variable to split up a large evaluation expression. A signal can be used instead. 5.5 The BST controller model in VHDL The BST circuits as described in the previous section must be described in VHDL, in such a manner that applies to the constraints of both the simulator and the synthesis tool. These constraints are listed above. As a result of these constraints, the level of description of the design is partly structural, partly behaviourial. The design of the controller is described in one architecture. The architecture contains signal assignments, processes, and instantiations of all flip-flops of the circuit. RWR-558-RC RC Page 19

27 The design of the controller is divided in 5 processes: The TAP controller The instruction register The instruction decoder The output assignments The output multiplexer These processes represent blocks of combinatorial logic, calculating the next states of the flip-flops and output values. The advantage of multiple processes instead of one is that the sensitivity list of each process is short for it only contains the input signals of that process. Some simple signal assignments are not part of any process, because this results in smaller process bodies and shorter sensitivity lists. Because optimal state assignment has already been performed, constants are used to represent the state values of the TAP controller. Constants are also defined for the implemented instruction codes and the implemented test data registers. These constants have the extension ' instruction' or ' register', to prevent incorrect double declarations of constants. - - Explicitly specified signals of the design must have a unique names. This for instance applies to the signals connected to the flip-flops instantiated in the design. Output signals which values must be used inside the design, are buffered. The signal name before the buffer is extended with' but. This signal can be used inside the design and is also used to assign the value to the output signal. The next state calculation of the TAP controller is described in a case structure. The next state is selected by the current state and the value of TMS. Some if-then statements are used to implement the additional TAP controller initialisation. The combinatorial logic of the instruction register is implemented as a case structure. Depending on the current state and instruction register value, the next instruction register value is determined. This can be a shift operation, a hold operation or a capture operation. The instruction register must capture a value in the Capture-IR and for the bypass register in the Capture-DR state. The bypass capture value must be a O. This is implemented by capturing the IR capture value with the most significant bit a 0, thereby specifying an operation for the rest of the instruction register. The instruction decoder determines the next values for the current instruction flipflops. In the Update-IR state the value is selected in a case structure on the basis of the instruction code present in the serial instruction register. The output decoder process assigns values for all states of the TAP controller to the RWR-558-RC RC Page 20

28 state-dependent outputs of the instruction decoder. This process is constructed with nested case structures. The main case structure makes a selection on the current selected test data register. When more than one instruction selects an implemented test data register with different values for the outputs, the nested case structure selects on the value of the decode flip-flop. The lowest order case structure selects on the current state of the TAP controller. Finally the output multiplexer is implemented as case structure that selects on the current state. The TDO output is assigned a new value only in a shift state. In the shift-dr state one of the implemented test data registers is connected to the TDO flip-flop. Selection is performed by a nested case structure on the basis of the current selected register. RWR-558-RC RC Page 21

29 6 Definition study 6.1 Purpose The VHDL description of the BST controller described in the previous section must be generated automaticly. This will be performed by a tool named Concreto, the BST controller creation tool. The purpose of Concreto is to generate a BST controller circuit, on the basis of a flexible BST controller specification. Concreto will be platform independent. 6.2 Information requirements The information requirements of Concreto are described in this section. The functionality of Concreto is determined by the required output. This output is written into several files. In order to be able to generate the output, specific input information is required for Concreto Required output The output of Concreto consist of several parts. One part is the VHDL description of the BST controller design. To be able to simulate the design on a simulator, a so called test bench is generated. This test bench is described in paragraph 5.3. Simulation is performed by assigning stimuli to the input pins of the BST controller. Therefore Concreto will also generate the test stimuli and responses for functional verification of the VHDL description of the BST controller. The generated design is intended to be part of a complete IC design. TimNet, the software package that adds a BST controller and BST cells to the IC core logic, requires some information about the BST controller. This information must be generated by Concreto and is called the TimNet interface. Figure 7 shows the required output of Concreto Required input To be able to generate a BST controller description, the architecture and all parameters of the BST controller must be specified. These specifications are divided in three parts. The first part describes the general architecture of the BST controller. Concreto contains the BST architecture rules, so it can create a controller, part of a BST circuit that is compatible with the IEEE Std These rules are seldom subject to RWR-558-RC RC Page 22

30 changes and therefore part of the Concreto source code. The second part contains information that is static for all possible configurations of the BST controller. This part is called the instruction library and contains specifications of all known instructions. This library can be extended with all kinds of new instructions. The implementation of the instructions depends on the implementation of the test logic control, and can be subject to changes. Therefore this library is not part of the source code but listed in an external file, so that maintenance of the library is possible without altering Concreto. The last part contains specific information that specifies a certain controller. This input file is called the instruction set specification. It specifies the set of instructions implemented in the controller, together with the instruction code(s). The instruction codes are specified in the set specification, for they can be controller design specific, and instructions can have multiple codes. Further, all the other parameters of the BST controller, that can be different for each controller, are specified in this file. The information structure model of Concreto is shown in figure 7. Instruction set specification Instruction library Concreto / VHDL behavioural description of BST controller TimNet interface VHDL description of test bench Test patterns Figure 7. Information structure model of Concreto. RWR-558-RC RC Page 23

31 Nederlandse Philips Bedrijven B.V, 7 Functional design 7.1 Introduction This chapter describes the functional design of Concreto. The information contents of the input and output files are recorded by specifications. The function that Concreto will perform can be derived from these input and output specifications. 7.2 Input As described in the previous chapter, the input information of Concreto consists of two external parts: The instruction library containing instruction specifications. The instruction set specification. The set of instructions in the instruction set specification must be enclosed by the set of instructions specified in the library. The contents of both inputs is described in the following paragraphs The instruction library The instruction specifications in the instruction library shall contain the following value specifications for each instruction: The output values of the controlled outputs The selected test data register The test mode The IEEE Std states that each instruction shall fully define the set of test data registers that may operate while the instruction is current. The operation on a test data register (other than the bypass register) is specified by a set of outputs of the BST controller, that controls the test data register(s). In case of a set of control signals per test data register, it inherently specifies the test data register(s) that may operate. The bypass register is part of the BST controller and is combined with the instruction register. Therefore, when the bypass register is selected, operation of the bypass register is controlled by the TAP controller. Another rule of the standard is that each instruction shall cause a single serial test data register path to be enabled to shift data between TDI and IDO in the Shift-DR controller state. This test data register must be specified, and the corresponding control signals that control the selected register must have values that result in correct operation in each state of the TAP controller. To achieve maximum flexibility and/or simplicity of the specifications, Concreto does not check correct operation of RWR-558-RC RC Page 24

32 the selected test data register. The specification of the outputs controlled by instructions is not necessarily complete. Output signals that are not specified are assumed to be not used or to be 0, depending on the signal being controlled by an other instruction of the instruction set. The exception to this is when a value is specified for an output by an instruction when that instruction is not current. This is called the 'else' specification. When such a signal is specified by a second instruction, the 'else' specification is overwritten in case this second instruction is current. The 'else' specification can for example be used to place the control signals of a test data register in a defined state when another instruction, not operating that test data register, is current. Depending on the type of operation that is performed by an instruction, a test mode is assigned to the instruction. TimNet requires such a test mode for each instruction. Concreto can not generate the test modes on the basis of the output specifications, so the test modes have to be explicitly specified for each instruction in the library. The possible test modes are: sample external internal Because the instructions BYPASS, SAMPLE PRELOAD and EXTEST are mandatory, the library shall at least contain the specifications of these instructions. According the IEEE Std it is possible to define additional test data registers beside the mandatory boundary scan register, bypass register and the optional identification register. These additional test data registers are not part of the BST controller. Each test data register is identified with a unique name. The serial output of each test data register must be connected to the output multiplexer. This requires an input per test data register on the BST controller. The name of the test data register and the input on the BST controller must be declared in the instruction library The instruction set specification The instruction set specification contains all controller specific information. This information concerns: Controller name Controller version Implementation of the asynchronous reset Logic type of the enable control signal of the output buffer of TDO Capture code of the instruction register RWR-558-RC RC Page 25

33 Set of instructions implemented in the BST controller Delayed output signals The controller name is the name of the VHDL design that Concreto will generate. The version specification allows version management of generated controllers. Because the implementation of the asynchronous reset is optional, one must specify whether it must be provided in a BST controller. When the asynchronous reset is provided, the BST controller enters the Test Logic Reset state directly when a logic 0 is provided to this input. If this option is not provided, the test logic can only be reseted by holding TMS high for 5 periods of TCK. This causes undefined operation of the test logic directly after power-up. The asynchronous reset is controlled by the TRST* pin of the IC or by an internal power-up control circuit. The instruction set shall at least contain the mandatory instructions EXTEST, BYPASS and SAMPLE PRELOAD. The instruction codes will therefore have a minimum length of two bits. Not specified instruction codes will be implemented as BYPASS instruction, as stated by the IEEE Std Each instruction must have a unique instruction code. The length of the instruction codes is determined by the length of the instruction register. This length is specified in the instruction set specification by the length of the capture code. The capture code is the binary code that will be captured by the instruction register when the TAP controller is in the Capture IR state. Each cell will capture one bit. For timing purpose, some of the outputs of the BST controller that control a test data register may in some cases only change value at the negative edge of TCK. These signals must be specified in the instruction set specification, for they are controller specific. This is implemented by adding a negative edge flip-flop in the path of the specified signals. To allow the possibility to define private user instructions without changing the instruction library, private instructions can be declared in the instruction set specification. These declarations specify the instruction name, and the output that it controls. The instructions are implemented as the BYPASS instruction, with addition of the specified output. When the instruction is the current instruction, the output is active. In all other cases the output is not active. 7.3 Process Concreto is divided in a number of subsystems and processes. The result is represented in the hierarchical scheme of figure 8. The function of these subsystems and RWR-558-RC RC Page 26

34 :9 July 1993 processes is described in the next paragraphs. Concreto I Read the input files Process the infonnation Write the output files I Check information I Create architecture I I I I Parse instruction Parse instruction Write BST Write test Write test Write TinlNet library set controller patterns bench interface Figure 8. Hierarchical scheme of Concreto Reading the input The command line is used to pass options and file names to Concreto. It contains the filename of the instruction set specification and optional the name of the instruction library. If no instruction library name is specified in the command line, the default name is used by Concreto. Further, some other options can be passed to Concreto by the command line. Each string preceded by the character '-' is recognized as an option. Unknown or invalid options are ignored by Concreto. The invocation of Concreto is described in appendix B. An example of the command line is: concreto bs2conk1.set -I instnict.lib -a Concreto checks the existence of the input files. \Vhen the files exist, Concreto will parse them. If no syntax errors occur during parsing, the data structures containing the information from the input files are built Processing the input information Concreto checks the information from the instruction set with the rules stated in the RWR-558-RC RC Page 27

35 IEEE Std on Boundary Scan Test. These checks concern: Mandatory instructions Mandatory instruction codes Correct capture instruction code in Capture-IR state of the TAP controller When one of these checks results in an error, Concreto will try to correct it. In case of a missing mandatory instruction it will add it with the correct instruction code, on condition that the code is not already assigned to another instruction. When Concreto is not able to correct the detected error, it will halt. If the capture code does not end with the mandatory "01", Concreto changes it into the correct value. Concreto checks also the information from the input files on the following conditions: Only valid identifier names may be used. All specified instruction codes must have equal length. No duplicate instruction codes may occur in the instruction set. All instructions to be implemented in the BST controller must be specified in the library. During the construction of the architecture of the BST controller, checks are performed concerning consistency of the information. There checks are: Ports may be specified only as input or output, but not both. No complementary value specifications of the same signal may occur. Only two possible value specifications are allowed for one output. A value can be a 1 or 0, but also the value present at an input of the BST controller. Only two different values are allowed, because storage of the values has to be accomplished in one flip-flop. If at least one of these checks results in an error, Concreto can not create a BST controller circuit. In that case the program must halt. If no errors have occurred during the checks, the architecture of the BST controller is designed. The set of input and output pins is created on the basis of the TAP signals, the controlled outputs of the implemented instructions and the implemented test data registers. When an output pin is controlled by at least one instruction in the instruction set, it is added to the set of BST controller output pins. The output is added to the output specifications of the other instructions that are part of the instruction set. The result is a set of complete output specifications for each instruction of all the output pins of the BST controller. For the BST controller architecture is described in RTL, all flip-flop's of the circuit must be instantiated. Flip-flop allocation of the parallel output latch of the instruction decoder is performed as described in paragraph The value in the parallel RWR-558-RC RC Page 28

36 instruction register determines the value of the outputs of the controller. The corresponding values of the flip-flops of the output latch are assigned to each instruction Writing the output As stated in the definition study, Concreto will create a VHDL description of a BST controller, test patterns, a test bench and a TimNet interface file. The test patterns contain the stimuli and the expected responses of the BST controller. The expected responses have to be generated by Concreto, for they depend on the architecture of the generated controller. The other output can directly be generated with use of the controller architecture description. 7.4 Output The output generated by Concreto consists of several files. The contents of these files are described below The VHDL description of the BST controller The generated VHDL description of the BST controller is part of a BST circuit compatible with the IEEE Std on Boundary Scan Test. The architecture of the circuit is described in chapter 3. The VHDL description is described in chapter 4. The functionality of the generated design corresponds to the instruction set specification The test patterns The test patterns can be used for simulation of the generated VHDL description of the BST controller. Two different kinds of test patterns are generated by Concreto. These are the stimuli for the inputs of the BST controller and the expected responses of the outputs. For the BST controller operates on both edges of TCK, outputs can change also after the positive and negative edge of TCK. To verify the responses of the generated controller, the simulation clock cycle is divided into 3 parts. At the start of the cycle the input values applied to the BST controller are set and TCK is O. At the next step TCK is set to 1, and at the start of the last cycle step TCK is set to 0 again. The resulting clock signal is asymmetric, and is called a return to zero signal. The responses of the BST controller are valid at the most for 90% of each cycle step. RWR-558-RC RC Page 29

37 When each cycle step lasts 1000 ns, a clock cycle consists of the following actions: t = 0 ns: set values at input pins of the BST controller, TCK is O. t = 900 ns: verify output values of the BST controller t = 1000 ns: set TCK 1 t = 1900 ns: verify output values of the BST controller t = 2000 ns: set TCK 0 t = 2900 ns: verify output values of the BST controller Figure 9 shows the waveform of TCK of a simulation clock cycle. 1 TCK o c: Verify 1~ responses ~ t=o t t CO Apply stimuli ~ -----_. Time Cns) ) Figure 9. Simulation clock cycle. The generated test vectors can be used for functional verification of the generated controller. To verify the complete function of the controller, a full coverage of all functions must be realized. These functions are: Entering the Test Logic Reset state after five clock periods with TMS held l. Correct state transitions of the TAP controller. Loading the correct instructions represented by the instruction code in the instruction register. An instruction can be identified by the selected test data register in the Shift-DR state and the set of output values for all states. Entering the Test Logic Reset state when TRST* held low (if provided). These checks are executed by walking through all states of the TAP controller, and passing all possible state transitions. To verify the correct instruction capture, the outputs of the controller during all states are verified. Correct function of the instruction register is accomplished by shifting a pattern through the instruction register in the Shift-IR state. The instruction register forms a delay depending on the length of the instruction register. The first values that are shifted out consist of the capture code of the instruction register, starting with "01". RWR-558-RC RC Page 30

38 Checking all specified instruction codes covers only the specified functionality, but does not check unused codes. Although all unused codes are implemented as BYPASS instruction, it is sometimes preferred that all possible codes are checked. Therefore Concreto is able to generate both sets of test patterns, selected by a command line option. The register selection of the test data registers is tested by simulating the corresponding registers. Repeating patterns are applied to the test data register inputs of the BST controller. If the correct register is selected, the pattern that corresponds to the input is assigned to TDO. The patterns that simulate the values from the test data registers all differ in period. The pattern of the bypass register is applied to TDI, and is delayed for a half period. When shifting through the bypass register, the first output value of TDO is the capture value "0" of the bypass register. The function of the asynchronous reset is tested by activating TRST* in a certain state. When TRST* is high again, it must be verified that the TAP controller is in the Test Logic Reset state The VHDL description of the test bench The test bench is a piece of VHDL code that instantiates a design for simulation. The test bench contains routines to read external test patterns, in order to specify stimuli for simulation for all input ports of the BST controller. The results of the simulation are compared with the expected results that are also listed in the input file. The number of erroneous vectors is counted and a summary is reported at the end of simulation. During simulation, the resulting test vectors are written in an output file. This for allowing automatic verification of the simulation results after synthesis. The only parameters of the test bench are the name, the list of input pins and the list of output pins of the BST controller design The TimNet interface file The TimNet interface file contains information that TimNet needs to include the generated controller in a BST circuit. This is described in [EERE92]. TimPat also uses this information to generate test patterns. This information specifies the following items: Controller name Implemented instructions by name, code, test mode and selected test data register Inputs by name, TimNet name and load Outputs by name, TimNet name and drive RWR-558-RC RC Page 31

39 7.5 The data structure of Concreto To accomplish efficient data processing and storage of the BST controller architecture by Concreto, a data structure is designed. This data structure consists of three parts, designed to store: Information from the instruction library Information from the instruction set specification Information of the controller architecture The instruction library data structure contains a list instruction specifications as specified in the instruction library. Each instruction specification contains its name, test mode, selected test data register and a list of outputs controlled by this instruction. It can also contain a list of the declared user defined test data registers. The instruction set data structure consists of a list of instruction names with codes. Furthermore it can contain a declaration list of user instructions, and a list of outputs that require a half clock cycle delay. The architecture of the created controller is stored in the controller data structure. This data structure contains the information necessary to create the output files. The data structure consists of several lists. These lists are: Input pins Pin name Index (in SLF file) Output pins Pin name Pin type (Controlled by instruction / static or state-dependent / Delayed) Index (in SLF file) Possible output values (0, 1 or input name) Implemented test data registers Register name Input name Selection id A non empty list of instruction specification pointers Implemented instructions Instruction name A non empty list of instruction codes Name of selected test data register RWR-558-RC RC Page 32

40 Test mode A list of output pins (all output pins controlled by instructions) Pin name A value for each state A list of variables of the parallel instruction register Variable name Value (representation of instruction) Variables of the parallel instruction register name output pin name (if exists) length (number of bits) RWR-558-RC RC Page 33

41 8 Technical design 8.1 Input All input files are in ASCII format, allowing for easy file transfer between different work stations. The input files can be created and edited with any text editor producing ASCII files. The input may be both upper case and lower case. Concreto converts all input strings to lower case while reading the input files. This to prevent name inconsistency due to case differences. To make the information readable for Concreto, syntaxes for both inputs are designed to describe the input format. The syntaxes of these two inputs are specified by a context free grammar. The syntax of this metalanguage is specified in appendix C. All input information must explicitly be specified. No default values are used when an item is not specified in the input files. This to reduce the risk of assuming incorrect default values Syntax of the instruction library The specification of the instructions is formatted according to the syntax listed in appendix D. All instruction names, register names and signal names are identifiers that must start with a letter and may only consist letters, digits and the character' '. The instruction library starts with the keyword 'instruction_lib' and ends with the keyword 'end instruction lib'. The library is identified with a name and a version, - - specified after the keywords 'name' and 'version'. These values are strings of ASCII characters except space, newline and tab. User defined test data registers are implemented in a controller when at least one instruction that selects that register is part of the instruction set. Each user test data register must be declared in the instruction library by its name and input name. The name of the test data register is specified after the keyword 'user-,eg'. The input name after the keyword 'input' specifies the input of the controller which the serial output of the test data register is connected to. Each instruction is specified by a number of fields. These fields are enclosed by the keyword 'instruction' followed by the unique instruction name and the keyword 'end instruction'. The value of the field 'register' determines which test data register is connected to IDO when data is shifted out. This can be one of the mandatory or optional test data RWR-558-RC RC Page 34

42 registers, or one of the user defined test data registers. The test mode, specified after the keyword 'mode', determines the mode of test operation that the instruction performs on the selected test data register. There are only three test modes: 'external', 'internal' and 'sample'. The test performed by an instruction is determined by the value of the outputs that control the test logic. These specifications are enclosed by the keywords 'def_outputs' and 'end_def_outputs'. When an output signal is a constant value during the execution of an instruction, it can be specified after the keyword 'set output'. This specified value can either be a 1, o or an input signal, e.g. TD!. When an output does have different values in different TAP states, it must be specified for each state. This requires the following set of keywords and values. After the keyword 'output' a signal list is specified. This signal list contains the signals whose values are specified. The specification consists of a table with in the first column the state acronym, and the following columns the value of the signals in that state. This table is enclosed by the keywords 'states' and 'end states'. When an output must have a certain value in case the instruction is not current, it must be specified with the value after the 'else' keyword. This keyword can only be used in combination with the 'set output' keyword followed by a signal name. Appendix D contains beside the syntax definition of the instruction library an example of an instruction specification Syntax of the instruction set specification The syntax of the instruction set specification file is listed in appendix E. This appendix also contains an example of an instruction set specification. The information in the instruction library is enclosed by the keywords 'instruction_set' and'end_instruction_set'. The controller is identified by a name specified after the keyword 'name'. Only the first 8 characters of this name are used by Concreto. The keyword 'version' precedes the version specification of the controller. The switch 'asyn reset' ('yes' /,no') determines whether the asynchronous test logic reset (TRST*) pin is implemented in the controller. The switch 'output_enable' ('active_low' /,active-'ligh') determines the type of the output enable signal that controls the output buffer of TDO. RWR-558-RC RC Page 35

43 The capture code specified after the keyword 'capture' is the value that is captured by the serial instruction register in de capture-ir state of the TAP controller. The length of this binary code determines the length of the serial instruction register. The least significant part of the capture code must be equal to "01" to comply to the rule stated in the IEEE Std The list of instructions that are part of the instruction set are enclosed by the keywords 'instructions' and 'end_instructions'. The instructions in the instruction set are specified by their unique name and a binary code. All codes must have equal length, corresponding to the length of the serial instruction register, specified by the capture code. 8.2 Process Parsing the instruction library The instruction library is parsed by code generated by LEX and YACC, both described in (LEVI92]. LEX generates a lexical analyzer that searches an input string for regular expressions. When an expression is found, an action is performed. In combination with YACC, an action consists of returning a token to the parsing routines generated by YACe. YACC is a code generator that generates code that can accept an input language. A data structure is built during the parsing of the instruction library, which contains all information from that library Parsing the instruction set The instruction set specification file is parsed by means of a finite state machine that accepts the syntax of the instruction set specification. The FSM is implemented as a case structure which indices are selected by a state variable. The input of this FSM consists of strings of characters, separated by spaces, tabs and newlines. The FSM changes state when a string is accepted. The parsing routine halts if an input string is read which is not expected, and an error is reported. During parsing a data structure is built containing information of the instruction set Processing the information The controller data structure described in paragraph 6.5 is built next. The information from the instruction library and the instruction set specification is used to fill the controller datastructure. All instructions specified In the instruction set are placed In a list. Although an RWR-558-RC RC Page 36

44 instruction can be included more than once in the instruction set, it is only placed once in the list. A list is added to each instruction which contains the specified instruction code(s). The data structure contains a list of inputs and a list of outputs of the BST controller. The mandatory TAP connections and the OEN output are always part of the lists. When the asynchronous reset is implemented, the TRST* input is included in the input list. The list of outputs is completed by adding all output names specified in the library for each instruction that is part of the instruction set. Each output is only added once in the output list. These outputs are marked as controlled_by_instrnctions. After the list of outputs is completed, the instruction specifications are constructed. To each instruction a complete list of outputs is added, which are marked as controlled by instrnctions. To each output in the list, the values for all states are added. These values are specified in the instruction library. In most cases, some output values are not specified in the library for a certain instruction. These values are filled with a 0, or an 'else' value specified by another instruction. During this operation, the consistency of the specifications is checked constantly. The result consists of a fully specified lists of outputs for every instruction in the instruction list of the controller data structure. On basis of these lists, the type of the outputs can be determined. This type can be static or dynamic, as described in paragraph Next, the list of test data registers is built. The bypass register is the only register that does not have an input on the BST controller. The inputs from the other test data registers are added to the input list of the BST controller. An exception is the STC register. The output of this register is combined with the output of the boundary scan register. This requires only one input pin for both registers on the BST controller. The STC register is treated as the boundary scan register during controller architecture creation. The register list of the controller data structure does therefore not contain the STC register. Each instruction that is specified to select the STC register is implemented to select the boundary scan register. Only in the TimNet interface file, the register is specified by its own name. Finally, the list of variables that form the output latch of the instruction register is constructed. For each output, marked controlled by instrnction and static, a variable of length 1, identified by the output name, is added to the list. The number of test data registers is counted and a variable named 'select' is added with length: length =2LOG (number of test data registers) The maximum number of sets of the dynamic outputs is determined for all test data registers. This operation compares for all instructions that select the same test data RWR-558-RC RC Page 37