Functional Testing of Modern Microprocessors

Transcription

1 Functional Testing of Modern Microprocessors Th.J.W. Verhallen and A.J. van de Goor Delft University of Technology, Department of Electrical Engineering P.O. Box GA Delft, The Netherlands Abstract: In the early 1980's a method has been developed [l], [2] and [3] for functional testing microprocessors. Modern microprocessors have a functionality, such as on-chip caches, which is not cowed by $he model of [I-j]. lhis paper atemis that functional model and proposes fault models together with tests for such modern microprocessors. The proposed concepts and algorithms have been applied to the lntel i860" and can be found in [4J. 1: Introduction. Due to the capabilities of current VLSI technology, many functions of a microprocessor system, such as memory management, caching and floating-point operations, are integrated together with the CPU. This makes them less accessible such that classical test methods for chips containing the individual functions cannot be used [5-6]. In addition, usually only a functional description is available via the Programmers Reference Manual such that a functional test has to be performed. Because the microprocessor is usually integrated with other hardware to form a product, it is desirable to design the test in such a way that it can be performed as a self-test while the processor is part of its normal, product environment. This paper is organized as follows: paragraph 2 reviews the current literature on testing microprocessors; paragraph 3 presents the developed functional and fault models for modem microprocessors, and paragraph 4 gives the general form of the algorithms to be used. 2: Functional testing of microprocessors. 2.1: The GTAFL (Graph Theoretical Approach at the Functional Level) method. In various publications [l-31 a functional test for microprocessors, solemnly based on the instruction set, is presented and summarized below: - ste~ 1: Divide the instruction set of the processor into three classes: the 'Transfer Class', the 'Manipulation Class' and the 'Branch Class'. - steo 2: Via a graph method the microprocessor is represented by a system graph in which (groups of) registers are modeled as nodes, together with a self created IN and OUT node to represent the world outside the microprocessor; the instructions are modeled as the directed edges between these nodes. - stem 3: The microprocessor is divided into five functional units associated with their fault models: the Register Decoding Function, the Instruction Sequencing and Control Function, the Data Storage Function, the Data Transfer Function and the Data Manipulation Function, all together with their specific fault model. 2.2: Other published methods for functional testing mkroprocessors. In other publications related to functional testing of microprocessors, the presented methods are either too strongly coupled with a specific hardware item [7], or the used fault model is that of paragraph 2.1 whereby the test method has been modifid (see [8] which uses pseudo random testing); alternatively, the presented models and tests are too global (91 for being USBd for a modem microprocessor. 2.3: Functional testing of special function units. The functional tests for special chips, such as Memory Management Units [5] and Floating-Point Units [6] are not usable for testing the on-chip versions of these function units: (1) the tests have been designed to test the chip in isolation (rather than embedded in its sumunding logic); (2) usually a combination of functional and structural testing techniques are used, and (3) the equivalent on-chip function units suffer from poor controllability and observability. From the above it follows that the published methods for functional testing a microprocessor do not cover all functions of a modem microprocessor and/or are not suitable for a self-test, while the processor is embedded in its normal product environment. 3: Functional and fault models for modern micraprocessors. Because of the complexity of modem microprocessors and the fact that the current functional test methods do not cover the complete microprocessor, a modification $ IEEE 350

2 and extension of the test of [l-31 is presented. - SteD 1: Divide the microprocessor's functional blocks (as found in the manual) into two groups: the Execution Group consisting of Execution Units and the Support Group consisting of Support Units. An Execution Unit is defined as a unit which can perform a unique modification on data provided to that unit, with instructions only applicable to that particular unit. A Support Unit is defined as a unit which cannot perform data manipulation operations (data in the broadest sense: instructions, addresses and actual data) but helps the processor in accomplishing its task. These units accelerate the instruction execution process of the microprocessor. - m: Divide the instruction set into the groups defined by their related execution unit (as probably done in the manual). Then every group is divided into the three classes as described in paragraph 2.1, step 1. - steo 3: The microprocessor is represented by a graph using the definition of [l]. Support units, as defined in step l, are represented by special nodes called support nodes. The instructions (if any) which directly act on these support nodes are placed as directed edges, according to the graph method out of [I-31. Other instructions performing data transfers from the OUT or IN node in or out of the microprocessor to a register node are routed via the applicable support node to the applicable register node; they are also routed directly to the register node (normal graph method) if a software capability to turn off the support unit exists. - steo 4: For every Execution Unit, a division into the five functional units (step 3 of paragraph 2.1) with their related fault models and test algorithms is made and used to functionally test the Execution Units. To test the Support Units, the following strategy is used: 1. Divide a Support Unit into its functional blocks. 2. Group these functional blocks into the following classes: - the fetchhtore class, which contains all functional blocks that control a (stream of) data to be fetched from main memory for local storage in the support unit and vice versa. This class also includes the control logic when it is not contained in the other classes; - the memory class, which contains all the memory arrays of the support unit; - the look-up class, which contains all functional blocks that control a look-up of certain data in its local memory and provides this data to the requesting execution unit - Fault model for the support unit fetchlstore class: 1. the control logic for turning the support unit on and off (if available) is incorrect; 2. the control logic determining the need for sto- ringlfetching data is incorrect; 3. the addressldata bus lines for the support unit can be stuck-at or coupled. - Fault model for the SUDDO~~ unit memow class: I. stuck-at4 or stuck-at-1; 2. transition faults; 3. (linked) coupling faults; 4. address decoder faults. - Fault model for the SUDDO~~ unit look-ur, class: 1. incorrect selection of required data; 2. no selection of required data; 3. mom than one required 'data package' is selected; the resulting data is the logical AND or OR of the individual data packages. 4: Algorithms for functional testing a modern mimopassor. The algorithms to test modern microprocessors can be divided into two sets: (1) algorithms to test the execution units, these test can be found in [l-31; (2) algorithms to test the support units (as defined in step 4 of paragraph 3), which are the subject of this paragraph. They are divided into (for a complete description see [4]): a. the fetchlstore class algorithms, which are the same for all units. b. the memory class algorithms, which are unique for each support unit; an algorithm for a data cache, an instruction cache and a memory management support unit is presented below. c. the look-up class algorithms, which are the same for all units. 4.1: Testing the fe &store class. To perform the test of the fetchlstore class of a support unit (SU), apply the fault model derived in step 4 to the various functional blocks of this class and test them as follows: Test for the on/off control logic: - Write n main memory locations (1 snssu's internal memory size) with ZERO; {Main memory is written) - Enable the SU; - Read the memory locations; (ZERO will be written into the SU's internal memory due to misses during the look-up cycle) - Write the same main memory locations with ONE; - Enable the SU; - Read the memory locations and expect ZERO; Test for the control logic for storing data: If a writethrough policy is used, main memory is always updated. If a write-back policy is used, a 'dirty-bit' is associated with each data-line in the SU. It is set when the data in the SU is altered. In case the replacement algorithm 3s I

3 chooses to replace a block with a set dirty-bit, or when a SU block is flushed, the dirty blacks are written to main memory. The following algorithm has to be run directly after the testing of the above ontoff function. - Write the SU memory locations from the previous test with ONE; (This will set the dirty bits} - Perform a flush, i.e. order the SU unit to write back the contents of those data-lines which s dirty-bits are set; (Not necessary with write-through policy} - Read the addressed memory locations and expect ONE; (Now the dirty-bit setting and the writethrough policy has been tested} Next part needed when write-back policy is used. - Write memory locations with ZERO; - Enable the SU and perform a flush: (No data should be transferred, since no dirty bits are set) - Disable the SU and read the memory locations and expect ZERO. (Now the dirty-bit clearing is tested} Test for the control loeic for fetching data: The need for fetching data in the SU s internal memory is determined by the SU s miss signal. The possible faults are that this line is stuck-at-1 or stuck-at4 This will result in always a miss or always a hit. As can be seen during the test performed for the memory class (see paragraph 4.2), that test will detect this fault. Test for the dataladdress buses of the su~wrt unit: Since the tests\lsed for the memory array(s) of the SU are modified March-B [lo-111 tests (see paragraph 4.2), all (linked) coupling faults, transition faults and stuck-at faults in the data and/or the address buses are mapped to the memory array faults according to [lo] and will therefore be detected. 4.2 Testiag the my class. In a cache SU there are two different memory arrays: the data memory array, in which the actual data is stored, and the directory memory array, in which the tags are stored. These memory arrays have to be tested separately. Test for the data memory array of a data cache SUDport unit: Since any data pattern can be written into and read from the data memory array of a data cache a standard memory test can be used. In order to cover the fault model of step 4, a March-B test is proposed which is defined as follows ([lo] or 1111): { 4 (WO); t (ro,wl,rl,wo,ro,wl); t (rl,wo,wl); l(rl,wo,wl,wo); l(ro,wl,wo)}, in which: - t represents an incrementing or decrementing addressing mode; - t represents an incremented addressing mode; 1 represents a decremented addressing mode; - WO and wl represent writing a ZERO or a ONE, respectively; - r0 and rl represent reading the address and expect a ZERO or a ONE, respectively. If the to be tested SU has a set-associative memory, the test has to be performed for each set. Fiwe 1. A two-way set associative cache. Test for the directory memory array of a data cache SUDDO~~ unit: A line in the directory memory array (see figure 1) contains a T-bit tag-field; the number of lines in a cache is determined by the L-bit line-field; there are addresses, and the number of entries in a line is determined by the D-bit displacement-field. As with the test for the data ory array, the test for the directory memory array has to take into account the set under test. To be sure to detect all address decoder faults, the test has to cover the complete address space of 2L lines. Since the tag-field has a width of T bits, a word wide test approach [lo] for T-bit words has to be used. For this, the T-bit data background patterns can be constructed as follows: z = I 210g T 1 (1..1 indicates integer upperbound) k = O,l,.-.,z w = bit pattern of 22 bits, initially all zero = the odd 1/2k parts of the w-bit pattem are inverted word(k) = lower T bits of ~ 1 2 ~ For example, if T=5 then z=3 and w= , w/2 = oooollll (word(k) = 0111 l ), w/4 = l, ~/8= W/W= Since the tag-field cannot be read directly, because it is an address rather than data, the verification of the contents of the tag-field is done by storing a word(k) into the tag-field (this is done by using the cache miss handling facilities) and a data value (called CODE ) in the data memory array location belonging to the tagfield. A fault in the tag-field will cause a cache miss; in order to detect this, the corresponding main memory locations are initialized with the data value!code. The! symbol denotes the one s complement. For CODE, the data pattem is used, because accessing a nonexisting memory location (due to a fault) will return OOO..OO or Perform a March-B whereby the WO, Io, wl and rl operations are modified as follows: 1-0: Enable the cache; {Read operations will now access the SU; i.e. the data and directory memory array (tag-field). All entries of the 352

4 tag-field contain the value word(k) ) -x- -y- 4- READ addr(word(k) I..i.. I XX..~) expect CODE; Disable the SU; (Address main memory) WO: Disable the SU; (Address main memory) -x- -Y- & WRITE addr(word(k) I..i.. I XX..~) with CODE; Enable the SU and read the addresses; (Due to cache misses the tag-field is filled with the value of word(&); the data memory array with the value of CODE) Disable the SU and write the same addresses into main memory with!code; For the rl and wl action, the word(k) is changed into!word(k) and CODE into!code. This March-B test has to be repeated for each value of k in word(k) until the value wiw ( ) has been reached. Test for the data memory arrav of an instruction cache suuuort unit: Since an instruction cache cannot contain just any data (it has to be a valid instruction), an approach different from the one used for the data cache SU has to be taken. If there are limited possibilities of applying immediate constants within the instruction stream, it is not possible to use immediate data as test patterns for the full size of code space. To be able to write a ZERO and a ONE as needed during the tests of the data array, the following definitions are made: ZERRO: a sequence of instructions which perform a unique transformation on one or more registers and satisfies the condition that the logical AND of this sequence of instructions is OOO..OO (all bits 0). The sequence must be terminated with the RETURN FROM SUBROUTINE instruction. W E a sequence of instructions which perform a unique transformation on one or more registers (other than the registers used during the ZERRO operations) and satisfies the condition that the logical OR of this sequence of instructions is (all bits I). The sequence must be terminated with the RETURN FROM SUBROUTINE instruction. Another restriction is that the reading from this memory array can only be done in one direction by means of executing the instructions. Furthermore the possibility exists that a fault in the memory array will result in an alteration of a certain instruction into the HALT instruction, which causes the computer to stop. This problem is inherent in the functional test of [l-31. These restrictions put severe constraints on the test. The consequences for the various faults are discussed below. - Stuck-at 0 and stuck-at 1 faults These faults can be detected by writing a 0 and a I to the memory array and reading this 0 and Z. The way to test the instruction cache for stuck-at faults is as follows: - Create a self-modifying testprogram that starts at the beginning of the instruction cache (i.e. place it at an address with the L and D bits equal to zero). - The testprogram starts with writing the ZERRO instruction sequence directly at the end of the program body. Next it calls this sub-program and after return checks the value of the altered registers. - This writing/executing of the ZERRO instruction sequence is then continued, such that every writing is shifted exactly one instruction-address. The program ends, when the final instruction of the ZERRO instruction sequence is placed at the end of the cache. The result is that every bit-cell of the instruction data array contained a 0: except that part where the testprogram was situated and the top of the cache. - The above is repeated for the ONNE instruction sequence. - To test the lower and upper part of the cache, the testprogram is placed in the middle of the cache. Because of the wrap-around of the addresses, the subprogram is now executed from the top, via the bottom of the cache and the part of the cache which contained the testprogram initially. In this way the total cache is tested for stuck-at faults. - Transition faults To detect transition faults it is necessary to make per bitcell a 0 to 1 transition and a I to 0 transition. During the testprogram for the stuck-at faults, the sequence ZERRO followed by ONNE occurred. This is exactly the bit level transition from 0 to I. To test the I to 0 transition it is sufficient to execute the testprogram with the ZERRO instruction sequence once again. - Coupling faults For these faults, and all other more complex memory faults, it is necessary to read and write the memory in normal and reverse order. Since this is not possible with the instruction cache, these more complicated faults cannot be detected. Test the directory memory array of an instruction &: To test this directory memory array, the same approach is used as with the directory memory array of a data cache. Only the following alteration is needed: - For the CODE and!code we use the defined code sequences ZERRO and ONNE respectively. Test the memory array of an memory management SUIXIOI~ unit: The WRITE addr... statement should be changed into Prepare the Page Directory and the Page Table with addr... as virtual address, and word(k) as physical address and be followed by READ addr... to place the address in the MMU s internal memory array (the Translation Look-Aside Buffer). - Note: Depending on the length of the programcode, one or two entries of the Page Directory and Page Table should be reserved for the instruction addresses of the test program. Later these places can be tested by relocating the testprogram

5 4.3: Testing the look-up class. To perform the test of the look-up class, we apply the fault model to the various functional blocks of this class. Test the &/word selector of the su~wrt unit: 1. no setlword selected 2. incorrect set/word selected 3. more then one &/word selected The first fault leads to a miss signal since the set or the word 8ccessBd is not selected and therefore a miss is generated. This situation is tested with the modified March-B. The second fault, which consists of the selection of a wrong word, is covered by the March-B test. The selection of the correct set remains to be tested, since the marches assume that the set under test is fixed by status bits in some control register The third fault, in which more than one word is selected, is also covered by March-B. More than one set being accessed, still has to be tested. From the above it follows that only the set selector has to be tested; this test does not have to read and/or write the complete cache, but only the various sets in at least one location. The normal operational replacement policy has to be disabled during the set selector test. If it can be guaranteed that all other pairs of directory memory and data memory array sets contain different data values during the test, a wrong set selection can be detected. It is assumed that if the set selection hardware is functioning correctly under fixed control, it will also function correctly under control of the normally used replacement algorithm. In order to perform the set selector test, the initialization part of the March-B of paragraph 4.2 is preceeded by the initialization of all other sets with a NON-CODE WORD, which is a NO OPERATION instruction if an instruction cache is tested. Test the comparator of the su~wrt unit: The faults which can occut in the comparator will all result in a false hit or a false miss signal: either the comparator indicates a hit when it should actually have been a miss (this can happen once with a certain bit-pattern or always, independent of the bit-pattern), or the comparator indicates a miss when it should have been a hit. The modified March-B test for the directory memory array ensures that a false miss signal will be detected, because it is ensured that main memory data differs from the SU data. A false hit signal, that is the SU's internal memory is read at a certain address although the tag-field bits are not equal to the tag in the SU's directory array, is also detected by the March-B test; it is assumed that if a false hit signal occurs it will reoccur if the same conditions exist during the second and following accesses of the cache (i.e. permanent faults are assumed). To detect these faults, it has to be ensured that the data expected in the consecutive verification read operation differs from the expected value. A false hit during the reading of the main memory will cause that the CODE,!CODE or instruction sequence ZERRO or ONNE is not placed in the cache. 5: conclusion. By introducing the notion Support Unit the functional model of [l-31 can be extended to include modem microprocessor functions such as instwtion/data caches and memory management units. The Support Unit is divided into three functional classes (fetch/store, memory, and look-up class), together with their fault models. Tests for the memory class of instruction caches are restricted due to the fact that the test data has to consist of actual instructions and the addressing is performed via the program counter. Test patterns ZERRO and ONNE, consisting of executable code, are defined such that they can detect stuck-at and transition faults in instruction cache memory arrays. Coupling faults are not detected with this method. 6: References. Thatte, S.M. and Abraham, J.A. (1980), Test Generation for Microprocessors, IEEE Transaction on Computers, C-29 (6). pp Brahme, D and Abraham, J.A. (1984), Functional Testing of Microprocessors, IEEE Transactions on Computers, C-33 (6), pp Thatte, S.M. (1979), Technical Report Test Generation For Microprocessors, No. R-842; UILU-ENG Verhallen, Th.J.W. (1991), Functional Testing of modern, advanced microprocessors, implemented on a Intel i860 Microprocessor, Laboratory Task No. T-91.09, Delft University, Delft, The Netherlands. Hamilton, J. et a1 (1988), Testing Memory Management Units, Research report no. RC 14095, IBM Research Division, Yorktown Height, New York Basto, L.A. Kuban, J.R. (1985), Test Feotures of the MC68881 Floating-Point Coprocessor, International Test Conference (ITC) paper 20.5, pp Bellon, C. et al, (1988), Analysis of Experimental Results on Functional Testing and Diagnosis of CO Icr Circuits, ITC 1988 Proceedings, paper 4.1, pp.64!!. Klug, H. (1988), Microprocessor Testing by Instructwn Sequences Derived fiom Random Patterns, International Test Conference 1988 Proceedings, paper 4.2, pp Shen, L. and Su, S.Y.H. (1988), A Functional Testing Method for Microprocessors, IEEE Transaction on Computers, C-37 (10). pp van de Goor. A.J. (1991), Testing Semiconductor M m ries. lheory and Practice, John Wdey & Sons; Chichester, U.K. Suk, D.S. and Reddy, S.M. (1981), A March Test for Functional Faults in Semiconductor Random Access Memories, IEEE Transaction on Computers, C-29 (6) pp