Institutionen för datavetenskap

Transcription

1 Institutionen för datavetenskap Department of Computer and Information Science Institutionen för datavetenskap Department of Computer Final thesis and Information Science Minimizing memory requirements for Final thesis deterministic test data in embedded testing Title by by Daniel Ahlström Name LIU-IDA/LITH-EX-G 10/006 SE LIU-IDA YYYY-MM-DD Linköpings universitet SE Linköping, Sweden Linköpings universitet Linköping

2

3 Linköping University Department of Computer and Information Science Final thesis Minimizing memory requirements for deterministic test data in embedded testing Supervisor: Mudassar Majeed Supervisor: Urban Ingelsson Examiner: Erik Larsson by Daniel Ahlström LIU-IDA/LITH-EX-G 10/006 SE

4

5 På svenska På svenska Detta På svenska dokument Detta dokument hålls tillgängligt hålls tillgängligt på Internet på Internet eller dess eller framtida dess framtida ersättare ersättare under Detta dokument under längreentid hålls längre fråntillgängligt publiceringsdatum tid publiceringsdatum på Internet under eller förutsättning under dess framtida förutsättning att inga ersättare extraordinära en längre omständigheter ordinära tid frånomständigheter publiceringsdatum uppstår. uppstår. under förutsättning att inga extra-ordinära om- att inga under extraständigheter Tillgång till Tillgång uppstår. dokumentet till dokumentet innebär tillstånd innebärför tillstånd var och fören var att och läsa, enladda att läsa, ner, ladda ner, skriva Tillgång ut skriva enstaka tillut dokumentet kopior enstaka förkopior enskilt innebär för bruk tillstånd enskilt och bruk att föranvända var och och attdet använda enoförändrat att läsa, det ladda oförändrat ickekommersiell ut enstaka ekommersiell kopior forskning för enskilt forskning och för bruk undervisning. och ochför attundervisning. använda Överföring det oförändrat Överföring av upphovsrätten för av ickekommersiell upphovsrätten vid vid ner, skriva för ick- en forskning senareentidpunkt och för undervisning. kan tidpunkt inte kan upphäva Överföring inte upphäva detta av tillstånd. upphovsrätten detta tillstånd. All annan vid All användning enannan senareanvändning tidpunkt av kanav dokumentet inte upphäva dokumentet kräver detta tillstånd. upphovsmannens kräver All upphovsmannens annanmedgivande. användning medgivande. av För dokumentet att garantera För att kräver garantera äktheten, upphovsmannens medgivande. säkerheten och tillgängligheten För ochatt tillgängligheten garantera finns äktheten, det finns lösningar det säkerheten lösningar av teknisk ochav och tillgängligheten teknisk administrativ och administrativ finns det äktheten, säkerheten art. lösningarart. av teknisk och administrativ art. Upphovsmannens Upphovsmannens Upphovsmannens ideella ideella rätt ideella rätt innefattar innefattar rätt innefattar rätt rätt bli att rätt nämnd bli att nämnd bli som nämnd som upphovsman upphovsman som upphovsman i den i den om- i den omfattning som omfattning somgod god sed sed som kräver kräver godvid sed vid användning kräver användning vid användning av av dokumentet dokumentet av dokumentet på på ovan ovan beskrivna beskrivna på ovansätt beskrivna samt sätt skydd samt mot sätt skydd att samt dokumentet mot skydd att dokumentet mot ändras att dokumentet eller ändras presenteras eller ändras presenteras i eller sådanpresenteras form i ellerform i sådant ellerform sammanhang som sammanhang sådant är kränkande sammanhang somför är kränkande upphovsmannens som är kränkande för upphovsmannens litterära för upphovsmannens eller konstnärliga litterära eller litterära anseende konst- eller eller konst- i eller i sådant närliga egenart. anseende närliga anseende eller egenart. eller egenart. För ytterligare För ytterligare information information om Linköping om Linköping University University Electronic Electronic Press se förlagets Press se förlagets hemsida För hemsida ytterligare information om Linköping University Electronic Press se förlagets hemsida In InEnglish In English The The publishers The publishers will will keepwill thiskeep document this document online on online the theinternet on the- -Internet or orits itspossible - or itsreplace- possible replacement - for replacement a-considerable for a considerable - fortime a considerable from timethe fromdate time theof date from publication of the publication datebarring of publication barring exceptional exceptional barring circumstances. exceptional circumstances. The online The availability online availability of the document of the implies document a permanent aimplies a permission permanent for permission for anyone tofor anyone read, to todownload, anyone read, todownload, read, print toout download, tosingle printcopies out to print single for out your copies single ownfor use copies your andown for to use your use it unchanged and owntouse and forto use anyitnon-commercial unchanged use unchanged for any research non-commercial for any andnon-commercial educational research purpose. and research educational Subsequent and educational purpose. transfers Sub- purpose. of copy- Sub- circumstances. sequent right cannot transfers sequent revoke transfers of copyright this permission. of copyright cannotall revoke cannot otherthis uses revoke permission. of the thisdocument permission. All other areall uses conditional other of uses onof the thedocument consent theof document are theconditional copyright are conditional owner. thethe consent publisher theof consent the hascopyright taken of the technical copyright owner. and The owner. administrative pub-thlisher measures haslisher to taken assure has technical authenticity, taken technical and administrative security and and administrative accessibility. measures measures to assuretoauthenticity, authenticity, pub- security According and security accessibility. to intellectual and accessibility. property law the author has the right to be mentioned when his/her According workaccording istoaccessed intellectual toasintellectual described propertyabove property law the andauthor law to bethe protected has author the right against has the to infringement. be right mentioned to be mentioned his/her when For when additional information work his/her accessed work about is the accessed as Linköping described as described University above andabove Electronic to beand protected to Press be protected and its against procedures infringement. against for publication infringement. and for assurance of document integrity, please refer to its WWW For additional homefor page: additional information information about theabout Linköping the Linköping University University Electronic Electronic Press Press and its procedures and its procedures for publication for publication and for assurance and for assurance of document of document integrity, integrity, please please refer to its refer WWW to its home WWW page: home page: c Daniel Ahlström [Författarens [Författarens för- och efternamn] för- och efternamn]

6

7 Abstract Embedded and automated tests reduce maintenance costs for embedded systems installed in remote locations. Testing multiple components of an embedded system, connected on a scan chain, using deterministic test patterns stored in a system provide high fault coverage but require large system memory. This thesis presents an approach to reduce test data memory requirements by the use of a test controller program, utilizing the observation of that there are multiple components of the same type in a system. The program use deterministic test patterns specific to every component type, which is stored in system memory, to create fully defined test patterns when needed. By storing deterministic test patterns specific to every component type, the program can use the test patterns for multiple tests and several times within the same test. The program also has the ability to test parts of a system without affecting the normal functional operation of the rest of the components in the system and without an increase of test data memory requirements. Two experiments were conducted to determine how much test data memory requirements are reduced using the approach presented in this thesis. The results for the experiments show up to 26.4% reduction of test data memory requirements for ITC 02 SOC test benchmarks and in average 60% reduction of test data memory requirements for designs generated to gain statistical data.

8

9 Contents 1 Introduction Testing of Electronic Systems Embedded Testing The Context of this Thesis Motivational Example Problems Addressed in this Thesis Brief Description of the Proposed Solutions Summary Outline Background Boundary Scan Related Work Software tool for reducing test data memory requirements The Concatenator Program Input Data Description File Test Data File Command Line Output Data Tests With Equal Amount of Test Patterns Tests With Different Amount of Test Patterns Extensions for Practical Application of the Concatenator Program Converting Output Data to STAPL Program to Evaluate Test Response from a Boundary Scan System Experiments Experiment Description and Test Data Files Result of Experiment Experiment Conclusion and Future Work 25 ix

10 Bibliography 27 Appendices 29 A Boundary scan 29 A.1 Test Access Port Controller A.2 Boundary Scan Instructions List of Figures 1 A system under test with input and output pins Overview of an embedded system with a test controller Test stimuli applied and test response fetched Boundary scan cells on the inputs and outputs of a component Duplication both in the same test patterns and between test patterns The relationship between FDTPs and CTSTPs Component employing boundary scan The Concatenator program flow chart An example system with three components, marked IC1, IC2 and IC The concatenation process of the Concatenator program shown in step 3 of Figure Description file Test data file Output data file Output data file with different amount of test patterns Flow chart with STAPL conversion Overview of an embedded system, with an external test manager Program flow for experimentation Sorted graph of Experiment 1 results TAP finite state machine List of Tables 1 Instruction support of the Concatenator program Experimental setup of the description and test data files Experiment 1 results ITC 02 benchmark results x

11 List of Abbreviations This section presents all abbreviations used in this thesis in alphabetic order. ASIC ATE BIST CTSTP DFT DR FDTP GiB IC IR ITC KiB MiB PC PCB PRPG SOC STAPL TAP TCK TDI TDO TMS TRST Application-Specific Integrated Circuit Automatic Test Equipment Built-in Self-Test Component Type Specific Test Pattern Design for Test Data Register Fully Defined Test Pattern Gibibyte (1024 MiB = 1 GiB) Integrated Circuit Instruction Register International Test Conference Kibibyte (1024 bytes = 1 KiB) Mebibyte (1024 KiB = 1 MiB) Personal Computer Printed Circuit Board Pseudo Random Pattern Generation System on a Chip Standard Test and Programming Language Test Access Port Test Clock Test Data In Test Data Out Test Mode Select Test Reset xi

12 xii

13 1 Introduction Electronic systems today can be used in anything from everyday products like washing machines and cars to base stations for mobile phones and TVs. Electronic systems are getting more and more complex [1], where a single system can contain several millions of devices, from small simple resistors to advanced integrated circuits (ICs). As people now depend on these electronic systems, the electronic systems have to be reliable. Electronic systems in operation can become faulty for several reasons including wear-out and overheating. Electronic systems that are installed in a remote location is hard to access and the environment in which it is located can be difficult to reproduce. The same system design may also be installed in different kinds of environments and therefore act different. To test remotely located systems, embedded and automated tests are used since it tests the system in the environment it operates in. This thesis concerns the high memory requirements, in the order of gibibyte (GiB) [2], for storing test data for embedded test of printed circuit boards (PCBs) or system on a chip (SOC). The thesis deals with this high requirement of memory by applying an approach to reduce redundancy of test data. As will be shown in this thesis test data may be redundantly stored because the circuit under test may contain multiple instances of the same type of component (IC or core) and so the same test data is redundantly stored for each instance of the component. In particular this thesis considers systems that are tested using deterministic test data that is stored in an embedded memory. The system can be a PCB with multiple IC components or a SOC with multiple core components. In the remainder of this thesis the word system will refer to a PCB or a SOC and the word component will refer to an IC on the PCB or a core in the SOC. This chapter starts the thesis by presenting the overview of electronic systems, their complexity, the environment in which they reside, the need to perform testing and the motivations to embed the test circuitry in the system. Furthermore this chapter presents an overview of problems in the domain of embedded tests and their solutions. 1.1 Testing of Electronic Systems A key requirement for obtaining reliable electronic systems is the ability to determine that the systems are error-free [3]. To monitor that a system is working and continues to work according to specifications, testing is required. Testing refers to the verification of manufacturing correctness such that there is no detectable defect in the system. A defect is a deviation from the intended physical structure of the system. Physical defects are modelled as faults according to their effects on a system s behaviour. To test a digital electronic system, which is the type of system considered in this thesis, a set of test patterns are applied. Test patterns consist of test stimuli (ones and zeros) and corresponding fault-free test responses (ones and zeros). Test stimuli can be generated randomly, exhaustively or deterministically. The stimuli are applied on the input pins of the system under test and the test response on the output pins of the system is compared with the corresponding response of a fault-free system. Figure 1 shows an overview of a system under test with test stimuli at the input pins and corresponding test response at the output pins. On a system, the input pins and output pins of the components can be difficult to access for testing. For example, the input pins of one component might only be accessible through another component or the physical density of the system can make access difficult. To provide test access to all input pins and output pins in a system, many systems employ a form of test-specific infrastructure, which is used to transport test data (test stimuli and test response) to and from the inputs and outputs of the systems components. One such infrastructure type is called boundary scan (Section 2.1). 1

14 Test stimuli vector Input pins Output pins Test response vector 0 System 0 1 under 1 1 test 0 Figure 1: A system under test with input and output pins To measure the effectiveness of the test patterns in detecting faults, fault coverage is used as a metric. Fault coverage is the number of faults that can be detected by the test patterns divided by the number of detectable faults i.e. the percentage of faults that can be detected. With the increasing complexity of electronic systems, the cost and time to test these systems increase. Automatic testing is used to reduce the cost and time needed. To automate tests, an external circuit can be used, which can be referred to as automatic testing equipment (ATE). An ATE is used to apply test stimuli on the system under test and to compare the test response with a fault-free test response from the system. 1.2 Embedded Testing Embedded testing is important since a system that is installed in a remote location is hard to access. With Embedded testing the system is tested in the environment it operates in, which makes it possible to detect defects that only manifest as faults in a particular operating environment. To aid the testing, some hardware can be added to the design of a system, which is called design for test (DFT). DFT techniques such as scan path design, built-in self-test (BIST) and boundary scan add test-specific circuitry to a system design. DFT include design modifications that provide improved access to internal component elements of a system such that the local internal state can be controlled and/or observed. In BIST, the component controlling the circuitry is required to perform a test on the component itself. The application of test patterns and capturing of results are both done in the internal system and not by external test equipment like in ATE-based testing. In BIST, test stimuli can be generated at the time of test using a pseudo-random test stimulus generator. Alternatively deterministic test patterns can be employed but in this approach, the test patterns must be stored in system memory. In this thesis, a BIST approach with deterministic test patterns is considered. 1.3 The Context of this Thesis In this section, the context for this thesis is presented. This thesis deals with the high memory requirements for storing predefined deterministic test data for embedded test of digital electronic systems. This thesis assumes a system with at least two components. In the trivial case of only one component, no reduction of test data memory requirements will be gained by using the proposed method. Figure 2 shows a PCB with three components and a test controller. The test controller contains an embedded processor marked CPU and an embedded memory. The components are connected with the embedded processor, marked by arrows. The arrows represent a serial interface, which can be a 2

15 Component 1 Component 2 Component 3 CPU Memory Test Controller PCB Figure 2: Overview of an embedded system with a test controller boundary scan chain (Section 2.1). The memory represents the storage of the deterministic test patterns used to test the components. Scan-in 1 Apply Scan-in 2 Scan-out 1 Apply Scan-in 3 Scan-out 2 Apply Apply Scan-out n Figure 3: Test stimuli applied and test response fetched In short, a test is conducted as follows. The test patterns stored in memory are fetched one by one by the processor. If any modifications, such as using the method proposed in this thesis, are needed to a predefined deterministic test pattern, the embedded processor apply the changes to create a fully defined test pattern (FDTP) before applying the FDTP to the serial interface. A FDTP is a test pattern with the length of the whole serial interface of the system. As can be seen in Figure 3, the test stimuli is applied to the serial interface at the same time as a test response from a previous test stimuli vector is fetched from the other end of the serial interface. The response is evaluated by the program that is running on the processor by comparing the response with the expected fault-free response and any faults are noted. 1.4 Motivational Example A system is equipped with three components (Figure 2). Component 1 has a scan chain length of 15 and use 20 test patterns. Components 2 and Component 3 are of the same type and have a scan chain length of 10 and use 15 test patterns. A scan chain is a serial interface for all components where every fully defined test pattern (FDTP) consists of one test pattern for each component. To test these components with deterministic FDTPs a total number of = 600 bits is required. As can be seen by the observation of that multiple components are of the same type, multiple components of the same type lead to duplication of stored test data, which is ineffective. This observation is utilized in the method proposed in this thesis, to reduce test data memory requirements. The method would only need = 450 bits to store the deterministic test patterns, which is a reduction of 25%. If for example a fault was detected in Component 3, more testing may be needed to that component to pin-point the defect. In this case it would be desirable to store a second set of FDTPs to specifically test Component 3. Note that, to store a second set of FDTPs would store a second set of the same test data. Special tests to explicitly test Component 3 do not need to be stored in memory and the test previously performed can be applied again without additional storage and without affecting the other 3

16 components in the system. This will further improve the memory requirement statistics in favour of the proposed method and lets the system to continue in operation while testing parts of it. 1.5 Problems Addressed in this Thesis In this thesis the boundary scan interface have been used, which is a serial interface. In boundary scan the inputs and outputs of all system components are equipped with scan cells consisting of flip-flops that form a shift register, called a scan chain (Figure 4), during test made. Since there is often only one boundary scan shift register on the system, a fully defined test stimuli vector have to be applied to fill the length of the scan chain to make sure that all appropriate scan cells are set correctly. When testing Scan Cells 0 0 Component inputs 1 1 Component outputs 1 0 Scan Chain Input Component Scan Chain Output Figure 4: Boundary scan cells on the inputs and outputs of a component a boundary scan testable system with several components in the system, the test patterns can be very long, hundreds of thousands of bits. The long test patterns occur because all components are connected on the same boundary scan chain. When several components are connected on the same scan chain, duplication of data may occur in the test patterns, especially if two or more components are of the same type. Duplication can occur in the same test pattern and/or between test patterns, as shown in Figure 5 (X, Y and Z refers to different parts of FDTPs). If a test pattern only is used to test a single component, the same part of a test pattern may occur in a test pattern used when the component is tested together with one or more other components in the system. As can be seen by this reasoning, test data can be stored inefficiently. X Y Y X Z Z Fully defined test pattern Figure 5: Duplication both in the same test patterns and between test patterns As mentioned above, the same part of a test pattern may be used to test a single component alone or together with one or more other components. Not only can the test patterns be stored inefficiently but they can also lack flexibility. In this thesis the meaning of flexibility is that test patterns can be applied in a different order or components can be tested individually by using the same deterministic test patterns. If not all of the components in a system is tested at the same time, many testing methods need to take all components out of operation even if some are not part of the test. 4

17 1.6 Brief Description of the Proposed Solutions As opposed to store fully defined test patterns (FDTPs) (Figure 6(a)), this thesis proposes a method that can be used to reduce test data volume and increase the flexibility. The method is based on a test controller software tool called Concatenator that runs on an embedded processor with an embedded memory connected to it (Figure 2). The method will concatenate component type specific test patterns (CTSTPs) on demand to FDTPs, as shown in Figure 6(b). A CTSTP is a test pattern used to test a specific type of component. The CTSTPs will be assembled into FDTPs. By storing CTSTPs, the amount of test data that needs to be stored in the embedded memory can be reduced. Since no CTSTP is stored more then once the redundancy is reduced. The test controller software tool adds flexibility by concatenating the CTSTPs depending on given commands. The commands can be issued either from a remote terminal or from a scheduled test cycle in the system. Type Type A AType Type B B Type Type A Type A Type B B Type Type A AType Type B B Concatenator Fully Fully defined defined test patterns test patterns Component Component type type specific specific test patterns test patterns Fully Fully defined defined test patterns test patterns (a) FDTPs is needed (b) CTSTPs is used to create FDTPs Figure 6: The relationship between FDTPs and CTSTPs The flexibility in the proposed method can be used to test select components or parts of the system while the rest of the system continues in normal operation. If a system can continue to operate without certain components, testing these certain components will reduce downtime due to testing and increase the overall uptime. The requirements to perform a test with the proposed method are a system with a processor, a sufficiently large memory and a communication line from the system to a system maintenance headquarters. A communication line to the system can be useful for issuing specific commands. How large memory that is needed depends on how large and how many test patterns that are used. Also the test control program uses a part of the memory. Two experiments have been conducted to evaluate the amount of memory reduced by the method proposed in this thesis. The experiments are described in detail in Chapter Summary In this introduction section, the importance of reliable electronic systems has been discussed. To determine if an electronic system is reliable, the system has to be tested regularly. Since many electronic systems are placed remotely, regular testing has to be automated and thus embedded into the system. With automated embedded testing, new methods have been created to fully automate the testing sequences. In Section 1.2, a few different methods were discussed. In this thesis the main focus is on testing embedded systems with predefined deterministic test patterns. The general problem when using deterministic test patterns is the large test data volume for which dedicated system memory resources 5

18 is required. This thesis provides a solution to the growing test data volume. This solution is based on a test control software tool running on an embedded processor together with an embedded memory. The software tool reduce the test data volume by reducing the redundancy in the test data stored in the embedded memory and adds a flexibility feature to further enhance the usability of the test data. 1.8 Outline Next chapter covers previous work done in the area of embedded testing and an introduction to where and how test patterns are used, with an introduction to boundary scan. Chapter 3 give more details on how the test control software tool works and its main features. Two experiments to get statistical information of how well the software tool performs are presented in Chapter 4. The thesis ends with a conclusion and a short discussion on future work in Chapter 5. 6

19 2 Background This chapter provides an access mechanism to test the internal parts of the system under test, namely boundary scan. In related work, the approaches for embedded testing of circuits and SOCs by using an embedded processor with deterministic test patterns stored in an embedded memory are discussed. 2.1 Boundary Scan Boundary scan is a standardized method to test interconnects and logic of components. Boundary scan makes it possible to control inputs and outputs on certain components. To accomplish this, boundary scan is implemented by three mandatory registers and a finite state machine called test access port (TAP) controller, controllable by a protocol of five signals. The three mandatory registers are a boundary scan register, an instruction register (IR) and a bypass register, where all are linear shift registers. The TAP controller controls which of the three registers test data input is shifted into, either the IR, the bypass register or the boundary scan register. By shifting in an instruction into the IR, boundary scan will be set to a test mode (Appendix A.2) equal to the instruction. If the test mode is bypass, the bypass register will be used to connect test data in (TDI) and test data out (TDO) and the component will continue in normal functional mode. The bypass register have a length of a single bit and is used to reduce unnecessary overhead when shifting in test stimuli to other components in the system. If the component is set to any other test mode, the boundary scan register will be connected between TDI and TDO. Test stimuli is shifted into the boundary scan register to set the values of the boundary scan cells, which in turn force input and output pins to the values of the boundary scan cells. Boundary Scan Cells Boundary Scan Path Core Inputs Core Logic Core Outputs TDI TMS TCK TRST Instruction Register BYPASS Register Test Access Port Controller TDO Figure 7: Component employing boundary scan Figure 7 shows the five signals of the boundary scan protocol, the core inputs and outputs, the boundary scan cells, a boundary scan chain and the core logic of a component employing boundary scan. Core logic refers to the processing logic of a component. The boundary scan chain connects the boundary cells, which in turn is connected to the core inputs and outputs. The five signals of the boundary scan protocol, TDI, TDO, TCK, TMS and TRST, are described below. 7

20 TDI, test data in, is connected to the in-pin of the boundary scan chain. TDI is the signal where instruction, bypass and boundary scan register values are applied. TDO, test data out, is connected to the out-pin of the boundary scan chain. While TDI is shifted into a register, the binary values currently in the register are shifted out through TDO. TCK, test clock, is a clock to control the boundary scan component under test. TCK is used since the internal clock, controlling the components at normal operation, is often too fast and may not be synchronized with the test controller. A slower and synchronized clock is needed to make sure that the boundary scan test is controlled properly. TMS, test mode select, is controlling the finite state machine of the TAP controller. TRST, test reset, is an optional signal used only to asynchronous reset the TAP controller. As discussed above, boundary scan is used to access inputs and outputs of components in embedded systems. Boundary scan is implemented as several shift registers between TDI and TDO. In this thesis boundary scan is assumed to provide access to components of a system. The components are assumed to imply a long shift register which is used to apply test stimuli vectors containing test data from all components. More information about the TAP controller and boundary scan instructions are found in Appendix A. 2.2 Related Work The goal for this thesis is embedded testing of multiple components using deterministic test patterns stored efficiently in an embedded memory with an embedded processor as test controller. There has been considerable research on related areas like embedded testing using compression of deterministic test patterns [4 6] and with reduction of test data volume and test application time [7], built-in self-test (BIST) with pattern generation [8, 9] and/or deterministic patterns [10 12], multi-site testing (using external testers), reduction of test data volume and test application time for application-specific integrated circuits (ASICs) with multiple identical cores [13], and embedded software based self-testing [14, 15]. None of the above approaches address all the concerns of this thesis as will be shown in this section. The main concerns of this thesis are reduction of memory requirements to store deterministic test patterns and to test multiple components at the same time. To address these concerns, this section reviews existing work in the literature related to memory requirements and embedded testing of multiple components in a system. There are three alternative approaches to deliver test stimuli to the tested system. These three approaches are (1) transporting test stimuli from a source external to the tested system, which is done typically in manufacturing testing, (2) generating the test stimuli on the system (pseudo-random pattern generation, PRPG) [8 12] and (3) storing test stimuli on the system. The first and second approaches share the benefit that no test data needs to be stored on the system. This thesis considers the third approach where test stimuli are stored on the system because the thesis is only concerned with systems that are tested in-field far from any test pattern source. This rules out the first approach, and because the second approach can only generate random test stimuli which are less effective in detecting faults [10] than the deterministic test stimuli [10 12] that can be stored on the system using the third approach. Furthermore, the problems addressed in this thesis (Chapter 3) are found in the domain of systems that employ the third approach by storing deterministic test patterns on the system. In such systems, the amount of dedicated embedded memory required to store the test data (test stimuli and fault-free test responses) is considered a cost. This total amount of test data is called the test data volume. The test data volume can be in order of GiB, which can be seen in [2] where a single component has a test data volume of 0.23 GiB alone. To reduce the test data volume, previous studies have proposed various 8

21 test data compression methods [4 6] which reduce the memory requirements for storing the data, but require some processing or dedicated circuitry for expanding the test data to its original form before it is applied to test the components. This thesis provides a method for reducing memory requirements without compression. The author of this thesis however believes that compression of test data can be useful to complement the approach presented in this thesis, which remains to be verified in experiments. Testing of multiple cores has been done in [13]. The technique in [13] reduces the test effort for ASICs with multiple identical cores. The technique generates test data once for identical blocks using PRPG. The technique evaluates tests by comparing responses from the different cores. The comparison is made bit by bit by specialized hardware and if not all bits are the same for each comparison a fault is detected. The evaluations of the tests are therefore dependent on multiple identical cores. The evaluation of test responses used with the method proposed in this thesis does not depend on identical cores and will not need specialized hardware. To summarize the above literature review, determinism in test patterns achieves high fault coverage but the test patterns need to be stored in a memory. PRPG removes the need of a memory and generates and applies test stimuli when needed and supports in-site testing, but fault coverage tends to be lower. Furthermore compression of test patterns reduces memory requirements but require dedicated hardware or some processing. As can be seen from the above review of previous research, all previous studies have either focused on manufacturing tests using ATE, compression, PRPG or the observation that test data for identical blocks only need to be stored once [13] to reduce memory requirements. The previous studies have also addressed how to deliver test data to a system for embedded testing, but no previous study has considered the combination of how to store deterministic test patterns for embedded testing while applying the observation from [13] to multiple cores. This motivates the study presented in this thesis as this thesis focuses on in-site embedded testing of multiple components with efficiently stored deterministic test patterns. 9

22 10

23 3 Software tool for reducing test data memory requirements This chapter presents a solution to reduce redundancy of test data stored in an embedded memory based on the observation that if a system contains several instances of the same component type only one set of test data is required to be stored for that component type. The first part explains the software tool by an example. The chapter continues with a more detailed look at the input and output of the software tool. 3.1 The Concatenator Program This section explains the software tool, called the Concatenator program. The Concatenator program is divided into four steps (Figure 8). First step is to read a description file of the boundary scan components within the system. The description file contains the order of the components on the scan chain, which type the components are and information for each type of component; boundary scan register length, instruction register length and available boundary scan instructions with their code words. Second step is to read and select the component specific test sets used for a particular test from a test data file, based on given commands. Third step is to process the data read and last step is to respond with the fully defined test patterns (FDTPs) created, written into an output file. Start Description file (Figure 11) 1 Read description file 2 Read test data file Test data file (Figure 12) Commands 3 4 Process data (Figure 10) Print output data file Output data file (Figure 13) End Figure 8: The Concatenator program flow chart This part will explain the program flow by an example. The example system (Figure 9) is equipped with three components connected on a boundary scan chain. The first component in the scan chain, marked IC1, is of type A and the two other components, marked IC2 and IC3, are of type B. Figure 10 shows the concatenation method to create fully defined test patterns from component specific test sets. The component specific test set marked Type A Intest 2 are specific to component IC1 and the test set marked Type B Intest 1 are specific to components IC2 and IC3. The description file (Figure 11) read in step one (Figure 8) is a description of the example system (Figure 9). In this example, the description includes on line 1 the order on the scan chain, IC1, IC2 and 11

24 Input IC1 Type A IC2 Type B IC3 Type B Output Figure 9: An example system with three components, marked IC1, IC2 and IC3 Type A Intest 2 Test stimuli 1 Test stimuli 2 Test stimuli 3 Test stimuli 4 Type B Intest 1 Test stimuli 1 Test stimuli 2 10 bits Command: Test IC1 Intest 2, IC2 Intest 1, IC3 Intest 1 Test stimuli bits Test stimuli 1 Test stimuli 1 Test stimuli 1 Fully defined test stimuli vector 15 bits 15 bits 10 bits 10 bits Figure 10: The concatenation process of the Concatenator program shown in step 3 of Figure 8 IC3, with IC1 as first component. The description file also specifies that IC1 is of type A, and IC2 and IC3 is of type B on line 2 and 3. The boundary scan register lengths are also specified, 15 bits for type A and 10 bits for type B. The command and the test data file read in step two can be seen in Figure 10. The command decides if a component specific test set should be included in the fully defined test patterns or not, if not, the test set are not read. In this example, both test sets are read and Type B s test set is read twice, Intest 2 is applied to IC1 and Intest 1 is applied to IC2 and IC3. The command is described in detail in Section In step three, the test sets are controlled and the appropriate instructions are set for each component. In this example, each test pattern is controlled to be of the right length, 15 bits for type A and 10 bits for type B. The instructions are all set to the INTEST instruction. Step four prints the fully defined test patterns to a file. As seen in Figure 10, the first test pattern in each test set are merged to the first fully defined test pattern, the second test pattern in each test set to the second fully defined test pattern, and so on. A more detailed look at the input and output data follows in the sections below. The examples in the following sections are related to the example above. 12

25 TypeA INTEST TypeB INTEST 1 IR: Input Data TypeA INTEST1 TypeB INTEST1 TypeA INTEST1 TypeB INTEST1 Test stimuli Expected response The input data consist of three parts, a description file (Section 3.2.1), a test data file (Section 3.2.2) and commands (Section 3.2.3). 1 IR: Description File IR: In 5 this section the description file format used by the Concatenator program is shown and explained. A description file contains essential information regarding the boundary scan chain and the components in the scan chain. 1 IC1 - IC2 - IC3 2 TypeA = IC1 3 TypeB = IC2 = IC3 4 5 TypeA DRLENGTH 15 6 TypeA IRLENGTH 10 7 TypeA IDLENGTH 12 8 TypeA IDCODE TypeA vidcode TypeA vidcode TypeA BYPASS TypeA EXTEST TypeA SAMPLE TypeA IR_CAPTURE TypeA INTEST TypeB DRLENGTH TypeB IRLENGTH 8 19 TypeB BYPASS TypeB EXTEST TypeB SAMPLE TypeB IR_CAPTURE TypeB INTEST Figure 11: Description file The first line of a description file describes the order of the components. In the example, shown in Figure 11, there are three components, IC1, IC2 and IC3, as can be seen on the first line. In this example IC1 is the first component in the boundary scan chain. Next, on line 2 and 3, the file contains the description of the type of the components. There is one line for each component type, which gives the list of components that are of the given type. In this example, IC2 and IC3 are of the same type. These type declarations come before the detailed information given for each component type. The detailed information of each component type includes length of boundary scan register, length of instruction register and available boundary scan instructions with their code words. The Concatenator program supports the instructions in Table 1. 13

26 Instruction EXTEST INTEST BYPASS SAMPLE/PRELOAD IR_CAPTURE IDCODE Meaning Used to test the interconnects between components. Used to test the logic of the component. Used to bypass a component by using the bypass register instead of the boundary scan chain to reduce unnecessary overhead. The component remains in its normal functional mode [16]. Used to take a sample of the functional data entering and leaving the component. Can also be used to preload data into the boundary scan register prior to an EXTEST instruction. Used to check if the instruction register of a component is working correctly. Used to fetch the ID code of a component. Table 1: Instruction support of the Concatenator program Test Data File This section shows and explains the test data file format. TypeA INTEST TypeA INTEST TypeB INTEST TypeB INTEST Figure 12: Test data file As seen in the example of a test data file (Figure 12), the file consists of component type specific test sets, which are named with a component type, a test id and the number of component type specific test patterns (CTSTPs) in the test set. The test id consists of an instruction name (for more details see Table 1 and Appendix A.2) and an identifier, where the identifier is used to separate different tests which are to be run with the same instruction. The instruction code is found in the description file (Figure 11). A test id is not component type specific, which means that the same test id can be used for many different test sets. After the line that names each component type specific test set follows the corresponding CTSTPs. The CTSTPs have two parts, which are stored on the same line separated by a blank-space character. The first part is the test stimuli and the second part is expected test response of a fault-free component. 14

27 3.2.3 Command Line This example will show how to command the Concatenator program of an intest on all three components, based on the description file (Figure 11) and the test data file (Figure 12). INTEST1 is used for all three components. The command line will then look like: concatenator.exe Description.txt Testdata.txt Outdata.data IC1 INTEST1 IC2 INTEST1 IC3 INTEST1 The command line consists of the program command followed by three file paths and pairs of test commands. The three file paths are Description.txt which is the path to a description file (Section and Figure 11), Testdata.txt which is the path to a test data file (Section and Figure 12) and Outdata.data which is the path to an output file (Section 3.3 and Figure 13). A test command pair consists of an id of a component to be tested and which test to apply to that device. For example, in the example above, IC1 is the id of a component and INTEST1 is the test applied to IC Output Data The output data file consists of two parts, the instruction for the boundary scan protocol (Appendix A.2) and the fully defined test patterns for the considered components in the boundary scan chain, which is created from input data with the Concatenator program (Section 3.1) Tests With Equal Amount of Test Patterns The output data file below (Figure 13) is the output created from using the description file (Figure 11), test data file (Figure 12) and commands (Section 3.2.3) from previous examples. TypeA INTEST TypeB INTEST 1 IR: TypeA INTEST1 TypeB INTEST1 TypeA INTEST1 TypeB INTEST1 Test stimuli Expected response Figure 13: Output data file 1 IR: In the output data file (Figure 13) the first line precedes of IR: which indicate that this line is to be read 4 IR: as an instruction and the second argument is the instruction. The following lines consist of FDTPs concatenated by the program As in the test data file (Figure 12) the first group of bits are test stimulus and the second group of bits are expected test responses. If an instruction or test stimuli of the wrong length is applied, the response may be wrong because of that. The program checks that the instruction and the test patterns is of the right length before being printed. The check is performed by comparing the 1 length IC1 - of IC2 the- test IC3 patterns to data in the description file (Figure 11). 2 TypeA = IC1 3 TypeB = IC2 = IC TypeA DRLENGTH 15 6 TypeA IRLENGTH 10

28 3.3.2 Tests With Different Amount of Test Patterns The number of test patterns in a component type specific test set will depend on the component, different tests will therefore in many cases have different amount of test patterns. A feature of the Concatenator program is to concatenate test sets with different amount of test patterns. This can for example be useful if one or more components need more extensive testing then the rest of the components or different tests are applied at the same time. In this TypeA example, INTEST component TypeB INTEST IC1 will use INTEST2 from the test data file (Figure 12), while components 1 IR: IC and IC3 still use INTEST The command line in this example looks like: concatenator.exe Description.txt Testdata.txt Outdata.data IC1 INTEST2 TypeA INTEST1 TypeB INTEST1 TypeA INTEST1 TypeB INTEST1 IC2 INTEST1 IC3 INTEST1 Test stimuli Expected response The command above creates an output data file that looks like the one below (Figure 14). 1 IR: IR: Figure 14: Output data file with different amount of test patterns 1 IC1 - IC2 - IC3 2 TypeA = IC1 As seen in Figure 14 on row four, the instruction is changed. This is done since TypeA s INTEST2 3 TypeB = IC2 = IC3 have 4 four patterns and TypeB s INTEST1 only two. Component IC1 will continue to be used in intest mode 5 TypeA whiledrlength IC2 and IC3 15 are put to bypass after the first two test patterns. Notice that this test used the same 6 TypeA test patterns IRLENGTH as the 10 example in Section 3.2.3, no duplication of data was needed to perform this second 7 TypeA example, IDLENGTH which12highlights the flexibility provided by the Concatenator program. 8 TypeA IDCODE TypeA This feature vidcode will not be useful for all types of tests, however when it can be used, both test time and memory 10 TypeA requirements vidcode can be reduced. 11 TypeA BYPASS TypeA EXTEST TypeA SAMPLE TypeA Extensions IR_CAPTURE for Practical Application of the Concatenator Program 15 TypeA INTEST Three 16 help programs have been developed to support the Concatenator program to add additional functionality. 17 TypeB The DRLENGTH most notable 10 were a program to convert the output data from the Concatenator program into 18 TypeB STAPLIRLENGTH code (Section ). A second program was used to compare expected result to the actual response from the boundary scan system (Section 3.4.2) and a third program was used to conduct 19 TypeB BYPASS TypeB EXTEST Experiment 21 TypeB SAMPLE 1 (Chapter ). 22 TypeB IR_CAPTURE TypeB INTEST Converting Output Data to STAPL Standard test and programming language (STAPL) is a high level programming language designed to simplify testing of boundary scan systems. STAPL code is written in ASCII text files called Jam files. Jam files are used together with a Jam STAPL player, which converts the STAPL code to boundary scan instructions at runtime. A Jam STAPL player can be used on an embedded processor for built in testing, which eliminates the need of an external test controller. 16

29 This program was developed to verify the output from the Concatenator program on hardware. The hardware used was a demo board developed by SAAB Aerotech AB. A Jam file with STAPL code can be created from the output data created by the Concatenator program. The response from the STAPL player can then be compared with the expected response in the output data file, to detect any faults. Start Description file (Figure 11) 1 Read description file 2 Read test data file Test data file (Figure 12) Commands 3 4 Process data (Figure 10) Print output data file Output data file (Figure 13) 5 STAPL converter Jam file End Figure 15: Flow chart with STAPL conversion As seen in Figure 15, the STAPL converter process only use the output data file as input, which contain the necessary information needed to produce STAPL code. The STAPL converter process only converts the output data file to basic STAPL code, which include application of test stimuli and caption of test response of a boundary scan system. The STAPL program run by the STAPL player does not evaluate the response. The evaluation is done by a separate program, described in the next section Program to Evaluate Test Response from a Boundary Scan System A program, developed by SAAB Aerotech AB, named TSTAP-RT was used to test the Concatenator program on hardware. The TSTAP-RT program is the only program used which is not developed by the author of this thesis. The TSTAP-RT program includes a JAM STAPL player and a function to record traffic on the boundary scan port. The recorded traffic is read to extract response from the boundary scan system, to compare with the expected response found in the corresponding output data file (Section 3.3). A log file is created with the result of the comparison. The log file includes the expected data, the read data and the result of the comparison showing which scan cells that are not equivalent. 17

30 18

31 4 Experiments Two experiments were conducted to determine how much test data memory requirement can be reduced using the Concatenator program. The first experiment was conducted to gather statistical data using 1000 randomly generated scenarios (Section 4.1. The second experiment was conducted on the ITC 02 SOC test benchmarks (Section 4.2). 4.1 Experiment 1 This section presents the experimental setup and the result of Experiment 1, which was conducted to gather statistical data with randomly generated scenarios. A total amount of 1000 scenarios were generated where each scenario corresponds to a unique configuration of the description and test data files (Section 3.2). Component 1 Component 2 Component 3 Test Manager / PC PCB Figure 16: Overview of an embedded system, with an external test manager Two simplifications are done for the purpose of the experiment. First simplification is that the program is run on a PC instead of an embedded processor on a PCB, as represented by Figure 16, compared to Figure 2 on page 3. The second simplification is that all data files used are text files instead of binary files. By comparing text files representing the stored test data, the expected result is in relative terms the same as when comparing binary files for the same data, and in this study the interesting result is only the relative difference in test data volume. As seen in Figure 17, the experiment process was divided into three steps. The first step were to generate the files needed, the second step were to run the Concatenator program (Chapter 3) with the files generated, and third step were to evaluate each set of files. The evaluation compared the file size of the description file, test data file and program size to the output data file. Result and conclusion of the experiment are presented in Section

32 Start 1 Generation Program Generate Description and Commands Generate Test data file Commands Description file Test data file 2 The Concatenator Program Output data file 3 Report size of files Database / Save data No Done? End Yes Figure 17: Program flow for experimentation Description and Test Data Files This section presents the process and boundaries concerning the generation of the description and test data files needed to conduct the experiment. To randomly generate a description file (Section 3.2.1), a few components of one or more types are needed. The content of the description files were generated by randomizing the parameters shown in Table 2. It should be noted that for each component type, the lengths of the boundary scan and instruction registers are required, and these are also taken from random generation as described in Table 2. To conduct the experiment described in this section, a test data file (Section 3.2.2) is needed for every description file. To randomly generate the test data file, some values from the corresponding description file is needed in addition to selecting the number of test patterns per component type, as can be seen in Figure 17. The random values for the description and test data files were generated between the values in Table 2. Type of value min max Number of components 2 10 Number of component types 1 #components Boundary scan register length bits Instruction register length 2 20 bits Number of test patterns Table 2: Experimental setup of the description and test data files First column in Table 2 represent which types of values are needed to make up a description file 20

33 and a test data file. The middle column represents the minimum value and the right column represents the maximum value. The range in which the number of components is chosen is realistic, as can be seen by the following discussion about the minimum and maximum values. The minimum value of two components is chosen since the Concatenator program is not needed in the trivial case of only one component. The maximum number of ten components is chosen since it is big enough to make a good diversity between the results and still small enough to keep the data volume reasonable for experimental purposes; the data volume needed is discussed later in Section The number of component types is realistic, because a design may consist of completely heterogeneous components or consist of homogeneous components. The boundary scan register length is set to give a good diversity by getting small results as well as bigger ones. Since the instruction register is a small part of the overall test data volume, the instruction register length was chosen to not impact on smaller scenarios. The number of test patterns was chosen low by intention to decrease the data volume needed to conduct the experiment Result of Experiment 1 Every pair of description and test data files generated as described in Section were processed with the Concatenator program. A total of 1000 description and 1000 test data files were generated, which gives a total number of 1000 output data files produced by the Concatenator program. A large amount of data was generated for this experiment, approximately 37 GiB, since a one or a zero generated in the experiment used one byte instead of one bit. The boundaries set on boundary scan register length and number of test patterns was made to make the time of the experiment reasonable. Below are the real numbers for the data volume for each file type generated in this experiment. The size of all 1000 description files together made up 307,995 bytes (300 KiB) and the size of all 1000 test data files together made up 11,330,582,604 bytes (10.5 GiB). The size of the description and the test data files are the amount of data that the Concatenator program need in order to create fully defined test patterns (FDTPs), including expected responses. The size of all 1000 output data files together made up 28,492,295,700 bytes (26.5 GiB). The size of the output data files are the amount of data that would be needed to store all FDTPs, including expected responses. The Concatenator program itself use 43,520 bytes (42.5 KiB) of memory. To even out the imbalance the size of the Concatenator program is multiplied by 8 to count it in bits instead of bytes. This is done since the description, test data and output data files are counted in bytes as if they were in bits, as discussed in Section 4.1 on simplification. SizeDF + Size T DF + (Size P rogram #Scenarios) SizeODF (1) Equation 1 is the equation used to calculate the relative difference in test data volume between using the Concatenator program and storing FDTPs. Size DF is the size of all description files, Size T DF is the size of all test data files and Size ODF is the size of all output data files. Since every scenario is a different test, the size of the Concatenator program (Size P rogram ) have to be multiplied by the number of scenarios (#Scenarios), which in this case is With the numbers mentioned inserted in the Equation 1 a result is obtained. 307, , 330, 582, (43, ) 0.41 (2) 28, 492, 295,

34 Calculation 2 shows that the total amount of memory consumed by the description and test data files were approximately 40% of the output data files consisting of FDTPs. In other words, the data used by the Concatenator program saves approximately 60% memory compared to storing FDTPs. Test data reduced #Scenarios >80% 8% >70% 25% >60% 41% >50% 55% >40% 69% >30% 76% >20% 82% >10% 85% >0% 90% Table 3: Experiment 1 results Table 3 shows in how many scenarios a certain percentage of test data memory requirements is reduced by the Concatenator program. The left column shows the percentage of reduction of test data memory requirements. The right column shows the percentage of scenarios where the percentage of reduction of test data memory requirements where obtained Test data reduced in percent Scenario Figure 18: Sorted graph of Experiment 1 results Figure 18 shows a sorted graph of the results from Experiment 1. The vertical axis shows the amount of test data reduced in percent and the horizontal axis shows the scenario number. As seen in Table 3 and in Figure 18, in 55% of the scenarios the Concatenator program decreased the memory needed by more then 50%, and in 76% of the scenarios the program decreased the memory needed by more then 30%, compared to the memory needed to store FDTPs. As seen in Figure 18 the decrease is approximately linear for the first 70% to 75% of the scenarios, at which point the graph starts to decrease at a higher rate towards the horizontal axis. In 10% of the cases the program increased the memory needed to store test patterns, which can be seen in Figure 18. These cases were small examples where the Concatenator program itself used 22

35 more or slightly less memory then the output data, which is seen as a steep fall in the sorted graph, or in the examples of where all components where of different types. The experiment only tested when all devices where used at once and the components of the same type used the same component type specific test patterns. No flexibility were used, for example testing the components one by one or performing different types of tests on different components, which would increase the number of FDTPs and further improve the statistics in favour of the Concatenator program. 4.2 Experiment 2 Experiment 2 was made on the ITC 02 SOC test benchmark. The purpose of this experiment was to see if the Concatenator program were able to reduce test data memory requirements for factory designs. ITC 02 SOC test benchmarks are a collection of factory designs which purpose is to stimulate research of new methods and tools for modular testing of core-based SOCs and to be able to objectively compare the methods effectiveness and efficiency [17]. The test data for these factory designs is in the order of millions of bits, which can be considered relatively small compared to newer designs with test data in order of billion of bits [2]. The calculations made in this experiment were based on that a component had to have at least one scan chain. If a component had multiple scan chains, all scan chains were added to form one long virtual scan chain. The length of the long virtual scan chain was multiplied by the number of test patterns specified for the component. If two or more components had the same number of pins, scan chains, scan chain lengths and number of test patterns, the components was considered to be of the same type. In three of the SOC designs, test data memory requirements were reduced, which can be seen in Table 4. SOC design Test data volume Test data volume Test data reduced without Concatenator with Concatenator f2126 4,914,813 4,868, % p ,515,190 22,666, % q ,129,114 10,400, % Table 4: ITC 02 benchmark results Leftmost column in Table 4 shows the name of the SOC designs. Second column from the left shows the total test data volume calculated for the SOC design when test data is not reduced using the Concatenator program. Third column shows the test data volume calculated that would be needed to store when the Concatenator program is used. Rightmost column shows the percentage of test data memory requirements reduced by using the Concatenator program. Since only three out of twelve ITC 02 SOC test benchmark designs have two components of the same type, the statistics does not favour the Concatenator program. However the SOC design q12710 reduced memory requirements with 26.4%, which demonstrates that the proposed concatenator approach is useful for reducing test data memory requirements for well known benchmark designs. 23

36 24

37 5 Conclusion and Future Work The target for this thesis was to show a possible solution where increased flexibility and reduced test data memory requirements go hand in hand for embedded testing of systems with multiple components. Many previous studies have focused on reducing test data memory requirements with several different methods. Previous studies have also focused on how to deliver test data to a system for embedded testing, but no study have focused on utilizing the observation of multiple components of the same type in a system to reduce test data requirements and increase flexibility, using deterministic test patterns. A method have been developed to reduce test data memory requirements by storing test patterns specific to every component type (component type specific test patterns, CTSTPs) instead of fully defined test patterns (FDTPs). The method reduces test data memory requirements by reducing the redundancy of test patterns. The method was implemented as the Concatenator program which uses the CTSTPs to create FDTPs when needed. The Concatenator program increase the flexibility by being able to test parts of the system without affecting the rest of the components in the system and without increasing test data memory requirements. Two experiments were conducted to evaluate how much the test data memory requirements is reduced by utilizing the Concatenator program. The first experiment was conducted on 1000 randomly generated designs and the second experiment was conducted on the ITC 02 SOC test benchmarks. For the first experiment test data memory requirements were reduced by an average of 60% and in the second experiment test data memory requirements were reduced by up to 26.4%. For future work, the Concatenator program should be evaluated as part of an embedded system. To make the program work in an embedded system it must be cross-compiled to the CPU platform of the embedded system and possibly there may be some adjustments depending on the design of the embedded system. A further improvement would be to evaluate if it is possible and viable to further reduce memory stored by combining the proposed solution with a compression technique. 25

38 26

39 References [1] G.E. Moore. Cramming more components onto integrated circuits. Electronics, 38(8): , Apr [2] Z Wang and K. Chakrabarty. Test data compression for ip embedded cores using selective encoding of scan slices. In Proceedings of the IEEE International Test Conference, pages , Nov [3] M.A. Breuer and A.D. Friedman. Diagnosis and reliable design of digital systems. Computer Science Press, [4] A. El-Maleh, S. al Zahir, and E. Khan. A geometric-primitives-based compression scheme for testing systems-on-a-chip. In 19th IEEE Proceedings on VLSI Test Symposium, pages 54 59, [5] K.J. Balakrishnan and N.A. Touba. Matrix-based test vector decompression using an embedded processor. In Proceedings of the 17th IEEE International Symposium on Defect and Fault Tolerance in VLSI Systems, pages , [6] A. Jas and N.A. Touba. Using an embedded processor for efficient deterministic testing of systems-on-a-chip. In Proceedings of the IEEE International Conference on Computer Design, pages , [7] J. Rajski, M. Kassab, N. Mukherjee, N. Tamarapalli, J. Tyszer, and Jun Qian. Embedded deterministic test for low-cost manufacturing. IEEE Design and Test of Computers, 20(5):58 66, Sep./Oct [8] V.D. Agrawal, C.R. Kime, and K.K. Saluja. A tutorial on built-in self-test. I. Principles. IEEE Design and Test of Computers, 10(1):73 82, Mar [9] A. Jutman, R. Ubar, and J. Raik. New Built-In Self-Test Scheme for SoC Interconnect. In Proceedings of 9th WMSCI, volume 4, pages 19 24, Jul [10] V. Gherman, H.-J. Wunderlich, H. Vranken, F. Hapke, M. Wittke, and M. Garbers. Efficient pattern mapping for deterministic logic BIST. In Proceedings of the IEEE International Test Conference, pages 48 56, Oct [11] G. Kiefer, H. Vranken, E.J. Marinissen, and H.-J. Wunderlich. Application of deterministic logic BIST on industrial circuits. In Proceedings of the IEEE International Test Conference, pages , Oct [12] A.-W. Hakmi, H.-J. Wunderlich, C.G. Zoellin, A. Glowatz, F. Hapke, J. Schloeffel, and L. Souef. Programmable deterministic Built-In Self-Test. In Proceedings of the IEEE International Test Conference, pages 1 9, Oct [13] Yuejian Wu and P. MacDonald. Testing ASICs with multiple identical cores. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 22(3): , Mar [14] A. Krstic, Wei-Cheng Lai, Kwang-Ting Cheng, L. Chen, and S. Dey. Embedded software-based self-test for programmable core-based designs. IEEE Design and Test of Computers, 19(4):18 27, Jul./Aug

40 [15] L. Chen, S. Ravi, A. Raghunathan, and S. Dey. A Scalable Software-Based Self-Testing Methodology for Programmable Processors. In Proceedings of the Design Automation Conference, pages , [16] IEEE Computer Society. IEEE Standard Test Access Port and Boundary-Scan Architecture. IEEE Std , pages 38 39, 66 67, [17] ITC 02 SOC test benchmarks. retrieved Jan. 20,

41 Appendices A Boundary scan This chapter is reference material regarding boundary scan (Section 2.1). In the sections below, more details are presented on the test access port controller and on the boundary scan instructions. A.1 Test Access Port Controller The test access port (TAP) controller is a finite state machine controlling a boundary scan component while testing. Three different signals control the TAP, a test clock (TCK) signal, a test mode select (TMS) signal and a test reset (TRST) signal. The TAP controller consists of two types of states, stable and temporary. A stable state is a state which can be held for more then one clock tick of TCK, while temporary states are left at the next rising edge of TCK. 1 Test Logic Reset Run Test Idle Select DR Select IR Capture DR Capture IR Shift DR Shift IR Exit1 DR Exit1 IR Pause DR Pause IR 1 1 Exit2 DR Exit2 IR Update DR Update IR Figure 19: TAP finite state machine The three TAP control signals TCK, TMS and TRST are explained below. Test clock (TCK), is a clock to control the boundary scan device under test. TCK is used since the functional clock, controlling the components at normal operation, is often too fast and may not be synchronized with the test manager. A slower and synchronized clock is needed to make sure that the boundary scan tests are controlled properly. Test mode select (TMS), is controlling the TAP controller s state machine. Test reset (TRST), is an optional signal used only to asynchronous reset the TAP controller. 29