CC BY
50
FUNCTIONAL TEST DERIVATION FOR RISC
MICROPROCESSORS
SHARSHUNOV S.G.____________
Far Eastern State Technical University, 10, Pushkinskaya str. Vladivostok, 690600, Russia E-mail: shsg@festu.ru, koshevenko@pisem.net Tel: (4232) 33-77-50
Abstract. A functional approach applied to testing RISC microprocessors are considered. Based on a detailed function partition we have analyzed groups of MP functions, their fault models and means to detect them. A special attention was given to the control hardware testing. The RISC peculiarities allowed us to put an accent on the registers decoding and operation decoding functions. W e formulated and grounded two main hypothesizes that permitted us to construct test procedures for the control hardware on the basis of RISC architecture only, without resort to implementation details. The complexity of these rather efficient procedures may be estimated as O(M+m), where M is a number of MP instructions and m is a number of MP registers.
1. Introduction
On the creation of high-performance computer systems it is often used the reduced-instruction-set computer architecture, so that testing of RISC microprocessors is a vital problem. It is natural to apply the functional testing methodology, which basis has been formed in [1,2]. The methods for functional testing in [3,4] emphasize the most acute difficulties in testing the control part ofthe MP hardware. Having in mind the register transfer level (RTL) model of a CISC microprocessors they have been to reconstruct the MP microarchitecture for obtaining elaborate and tedious test procedures. In [5,6] an accent has been put on the functional partition of MP hardware and investigating MP mechanisms as the objects for testing. In one of a few papers devoted to functional testing of RISC microprocessors [7] the main attention has been given to the data storage and storage management units.
The goal of this paper is development of the functional testing techniques [5,6] on application to RISC microprocessors. The paper is organized as follows: section 2 describes the functional testing peculiarities on application to RISC microprocessors; section 3 is concentrated on the control hardware testing.
2. Functional testing and RISC peculiarities
We represent a microprocessor as a set of interrelated functions. To emphasize the relation between MP functions and its structure we specify the term ‘mechanism’ as a part of MP hardware which implements a certain function; the structure of a mechanism itself may be unknown. Testing a MP is implied to be testing all of its mechanisms, and while generating tests for a mechanism we do not take into account faults of any other mechanism.
Analysis of MP functions has enabled us to single out the groups of data manipulation and data storage/transfer mechanisms. Because of a high level of the functional concurrency we shall use, together with the term ‘mechanism’,
the term ‘functional unit’ for a mechanism, implemented in a decoupled logic.
The data manipulation is usually, beginning from [1], is excluded from the consideration. This fact has been explained by followed reasons:
(1) There is a great variety of functional units, so that the creation of more or less general models is not possible.
(2) Many results are accessible, that had been obtained for pertinent devices.
(3) As a rule, functional units are well controllable and observable owing to its decoupled logic.
To these reasons we can add more arguments as follows:
(4) Most of functional units implement combinational processing, and if a unit logic is known, there is an opportunity to use well-known testing algorithms. It is typical of the mechanisms forming status signals (flags).
(5) In most cases we have some knowledge of a unit structure, that can facilitate testing. It may be a structure regularity (logic units, ripple-carry adders, etc.) or a structural recursion (carry look-ahead adders).
We also do not propose any special model for such functional units, however we mind them in view of testing control mechanisms.
For the data transfer mechanism it is convenient to apply RTL model (1, 3-7). In this model memories and MMU are attributed to the generalized nodes of RT graph IN and OUT. The rest of nodes concern the registers, register files and buffers. The graph arcs are associated with register transfers, activating by relevant instructions or special program procedures.
The test generating will be better organized into two steps. On the first step a subset of the paths from IN to OUT is to be found that jointly cover all the RT graph arcs. The simplicity of this task makes it possible to find a minimal coverage. The second step consists of generating the instruction sequence (test program), activated all the paths found. Operands for an instruction may be selected from the so-called transfer test se4t, so that all constants and bridging will be detected.
The transfer test set has to meet the following requirements: (1) for any couple of bits it has to be a test with different meanings of these bits; (2) for any bit it has to be a couple of tests with different meanings of this bit. The number of the register and bus bits is usually a power of 2. Then the first requirement is met by constructing the sequence of log2n tests, each of them to be obtained by halving the identical bits of the previous one. For example, if n=8, these tests may be (1111 0000), (1100 1100) and (1010 1010). In the test sequence so constructed the meanings of the first and the last bits are the same. To meet the second requirement we need one more test, e.g., (00001111). Hence, the transfer test set ofa minimal length consists of (log2n +1) tests and may be constructed as stated above.
The testing of register files may be executed with a memory test (as in [7]) or with the transfer test set together with the register decoding test (see below).
32
R&I, 2003, Ns 3
For the data storage mechanism (memory) it may be recommended the Memory March Test (MMT). In [8] four classes of faults are determined (stuck-at, transition, coupling and multiple access) and a minimal test is given which detects all the multiple faults of any class. The MMT test includes four march elements:
{ i (R,Wc,Wc,Wc), t (R,Wc,Wc), i (R,Wc,Wc,Wc), i (R,Wc,Wc)}
A march element is the sequence of reading (R) and writing complementary code ( Wc) which executes over a memory cell in the order of increasing (^) or decreasing (^) the memory cell addresses.
In [7] the MMT and its modifications has been used for testing IC (Instruction Cache), DC (Data Cache) and MMU (Memory Management Unit) of a RISC microprocessor.
Analysis of MP functions has enabled us as well to single out in the MP control part the groups of data manipulation control and data transfer control mechanisms. Such a hardware separation essentially depends on MP architectural features, in particular RISC peculiarities. Let us express this fact more formally.
Firstly, minding a MP as a functional integrity, it is obvious that an arbitrary fault can distort any MP instruction execution inan arbitrary way. Letus consider, for example, an instruction, executing an operation f over operands Qi and Q2 with a result Res. Then the functional fault model concerning this instruction can be expressed as follows:
Res = f(Q1, Q2) / Res*:= W,Q2*), (1)
where Q1 *, Q2*, Res* are operand and result values and f* is the operation (function) under the fault. In the generally accepted from A/A* the left (right) part relates to the fault-free (faulty) functioning.
Now, in view of MP representation as a set of mechanisms we can associate the fault with the selected groups of mechanisms. An operand or a result can be destored (O/O* or Res/Res*) because of a) data distortion in registers, memories or busses (the data storage / transfer group); b) incorrect decoding a source or a destination (the data transfer control group). An operation (function) and consequently a result can be destored (f/f* and Res/Res*) because of a) a functional unit logic is incorrect (the data manipulation group); b) decoding an opcode or activating a functional unit is incorrect. Besides, any of these distortions can be caused with the an instruction sequencing violation.
Separate testing the control mechanisms, under assumption that the data storage/transfer and the data manipulation mechanism as well as the instruction sequencing are fault-free turns the model (1) into the models:
d 1 <= f (sj s2k) / £ d <= f ( £ s, £ s ); (2)
d^D seS1 seS2
f / £ f; (3)
f eF
Here, S1, S2, D are the sets of possible contents of sources for operands and the set of possible destinations for a result, and F is the set of possible functions (functional units). Instead of assignment symbol :=, the symboL<= is used to emphasize
the data transfer. The expression ^ a means some subset
aeA
R&I, 2003, Ns 3
of objects a from the set A, in particular the empty subset, under assumption about the objects unification.
Further simplifications of the fault models and, as a result, test procedures efficiency are conditioned by the RISC peculiarities. Note the main of these [9]:
1) Only the data from registers are subjected to processing. Special instructions LOAD and STORE only realize memory access.
2) There are a few of simple and regular instruction formats and addressing modes.
3) The result of an instruction is formed at a clock cycle.
Accordingly to the feature (1) the model (2) may be modified applied to the register files. The feature (2) permits us to consider the instructions with separate fields for register numbers and opcodes. Then for the data processing operations the model (2) may be represented as follows:
(Ri )<=f((Rj),(Rk)) / £(R) <=f( £ (R), £(R))(4)
Rg^Rd Rg^ Rg5Rs2
For the LOAD / STORE operations:
(Ri )<=>M(A) / £ (R) <=>M(A). (5)
Rg«
Owing to the feature (3) we can change the function symbol f for the (micro)operation symbol 9 to “bind” a result to a certain cycle of a pipelined processing. For one-shot operations f and are the same, for complicated operations using the symbol T we fix the moment when a result becomes observable. Then the model (3) will be as follows:
9i / ^ ; (6)
q)G®
We use following notations in the models (4-6):
(R) - register R contents; M(A) - the contents of a memory cell withthe logical address A; B ,B S1,B S2,BD - sets of registers, register-sources and register-destinations accordingly; F--a set of possible MP operations.
Finally, the given reasoning’s allow us to formulate the following.
Assertions
1. As a data transfer control mechanism for a RISC microprocessor we can employ the register decoding
mechanism with the fault model Ri / £ R for R e B.
2. As a data manipulation control mechanism for a RISC microprocessor we can employ thLe operation decoding
mechanism with the fault model j i / £ T for ^eO .
3. Testing control hardware
An architecture of a typical RISC microprocessor is represented in Fig. Let us briefly describe a part named PROCESSING. There are three instructionformats F1, F2 and F3. The fields RA, RB and RC give the register-sources and register-destinations of the register file B, the fields OP and FUNCTION determine a function (operation), the field
33
LITERAL gives a constant in instruction, and the field OFFSET gives a displacement for a logic address forming. There are four addressing models: direct, immediate (format F2), relative (format F3) and implied, in particular, with the use of register-accumulator R. The multiplexers MA and MB under control of the fields RA and RB select register-sources, and the demultiplexer DMC under control of the field RC selects register-destination in the register file B. The multiplexers M1, M2 and demultiplexers DM1, DM2 are under control ofthe addressing modes (the field OP). The functional blocks FUNCTIONAL UNITS and ADDRESS ARITHMunder control of the fields OP and FUNCTION implement various functions (operations).
The group of functions SUPPORT is represented by the instruction cache (IC), data cache (DC) and memory management unit (MMU). These blocks are interacted with the MAIN STORAGE (MEMORY), perhaps through the additional caches.
We can single out three classes of the RISC MP instructions:
- the data transition and manipulation instructions (class TM);
- the LOAD and STORE instructions (class LM);
- the BRANCH instructions (class B).
Instructions of the class TM execute various functional transformations under registers from the file REGISTERS. All the registers are characterized by the same access method, that is they are so-called equivalent registers [3]. In most cases the data transitions and manipulations are realized by the instructions with a direct addressing mode. So, for simplicity, we restrict the class TM to the format F1 instructions (immediate and implied addressing modes will be easily take into account in the future realization).
Instructions of the class LM provide for some means of forming the data logical address of the main memory. The transformation of a logical address to a physical one is implemented on the michroarchitecture level.
Instructions of the class B as a rule require MP status analyzing. We intentionally did not include relevant mechanisms into the model of Fig. because we are going to use a simple and well known procedure to test the class B instructions.
The RISC architecture is crucially differed from the previous CISC architecture with nonregular instruction formats, numerous addressing modes and active using memory cells in executing instructions, that cause employing microarchitecture level models. The very complicated test procedures [2-4] are hardly relevant to a simple and clear RISC architecture.
We are going to derive tests on the base of a RISC architecture level only. To do that we have to have very comprehensive test procedures and to have a sound reasoning. Let us formulate the following arguments.
1. Independly of any control hardware complicatedness (superpiplining, supersealarity, out-of-order issue and so on) the result of any instruction is observable at some pipelined executing cycle.
2. The RISC architecture is characterized by a high degree of controllability, that is operations and operand addresses are given immediately in the instruction codes.
3. The control hardware defects are immanently “integral” faults, that is they influences at once on a set of instructions.
4. We intently have not restricted the register and operation decoding fault models:
Ri / ZR , j i / .
ReiR
In fact, these models give arbitrary mappings of the sets B and F with the sets of all the subsets of these sets.
These arguments allow us to formulate the following hypothesizes.
Hypothesis 1. Any control hardware steady fault, which is essential for the class TM instructions executing and is not detected with the tests for the data transfer or the data manipulation mechanisms, will be detected with the tests detecting functional faults in the fault models (4) or/and (6).
Hypothesis 2. Any control hardware steady fault, which is essential for the class LD instructions executing and is not detected with the memory tests, will be detected with the tests detecting functional faults in the fault model (5). Note, we mean that the memory tests include the MMT, which a part from anything else, detects the multiple access faults with the
fault model ci / Ec forc e C (cis a memory cell and C is a set of memory cells).
As for the class B instructions testing, we can refer to the procedure from [3]. The procedure successively executes all the class B instructions updating at every brunch point a storaged checksum.
On the base of the Hypothesizes 1 and 2 we can derive tests for control hardware faults. The tests will detect the faults immediately, through the supposed fault-free data processing and storage environment, without resort to the control hardware implementation details. So, it is logical to name relevant test procedures as test indicators. A procedure, basing on register decoding fault model, we name test indicator of decoding registers (TIR), and a procedure basing on i-operation decoding fault model we name test indicator of decoding i-operation (TIO(i)).
Let us get down to test indicators constructing. Accordingly to the Fig. and models (4,5), we determine two types of the TIR: TIRj for the register selection and TIR2 for the register interchange.
The TIR1 is founded on the models:
IN=>Ri / IN=> Z R, Ri =>OUT / ^ R=>OUT, (7) ReiR ReiR
generalizing the model (5) (instead of M(A) we means any source or destination, external to the B).
The TIR2 is founded on the model:
Ri =>Rj / Z R => Z R , (8)
ReiR ReiR
which is obtained from the model (4). Here we means that a proper function (and may be operands) transfer the Ri contents to the register Rj through the multiplexer MA or MB, and that bs=bd=b.
34
R&I, 2003, N 3
In [6] the test procedures for the register selection and register interchange mechanisms were grounded. So we give these procedures without proof as the test indicators. As the test operands we use, as in [3-7], (n,k)-codewords, that is different binary n-bit codes with k 1-components. Let us B=(Rj, R2, ... Rm) and codewords are e1, e2, ... em.
TIR1:
1. Write in successively e1 to R1, e2 to R2, ... em to Rm (execute relevant LOAD operations).
2. Read out each register Ri and check it up (execute relevant STORE operations).
3. Write in an inverse order: e1 to Rm, e2 to Rm-1, ... em to R1.
4. Repeat step 2.
5. The end.
TIR2:
1. Write in successively e1 to R1, e2 to R2, ... em to Rm (execute relevant LOAD operations).
2. Transfer successfully Rm to Rm , Rm-1 to Rm-1 , ... Ri to Ri (execute relevant Transfer operations).
3. Read out the register R1 and check it up (execute a relevant STORE operation).
4. Transfer successfully R2 to R1, R3 to R2, ... Rm to Rm-1, R1 to Rm (execute relevant Transfer operations).
5. Read out each register Ri and check it up (execute relevant STORE operations).
6. The end.
Test indicator TIR2 have to execute twice for the demultiplexers DMA and DMB. It is obvious that the complexity of test indicators TIR can be estimated as O(m), where m is the number of registers of the set B.
For the TIO(j) constructing we can use the results from [5,6]. Let us some of them.
When the (micro)operation 9j (j=1,2,...M) from the set O = {91,92,..., ^M} is to be execute, the control block activates a proper data processing functional unit. Let us define a Boolean variable Uj, so that U=1 if j J is executed, otherwise U=0. Let zi be the meaning of the i-bit of the result register, ^i be the function implemented by the i-bit of the functional unit of operation ^j, and zi* be the previous meaning of the zi. We can express the multifunctional data processing as follow:
m . * m_____
zj = v (Uj -9 i) v zj - a Uj, i = 1,2,...n. (9)
j=1 j=1
The expression (9) may be considered as an implicit model of
the operation decoding mechanism under a fault 9j / £9 for
9e® provided that, under a fault, every one of concurrent operations is executed correctly and the result is formed by the bit-wise OR function (a similar expression canbe obtained for the AND function).
Let us consider a procedure for finding tests of the operation decoding mechanism. For simplicity we shall restrict here the
set F by only bit-wise logical operations, so that 9- = 9j, i
= 1,2,...n. We shall use binary tables to represent functional units behavior. With respect to a table we shall say that the raw a 1 (0)-covers the raw P, if in all columns where P =1(0), a =1(0) too.
Suppose we know the results of operations from the set F over the operands (vectors) from the set E (see, for example, Table 1). Let us fix some operation 9 and denote by E0 the subset of vectors with z=0 and by E1 the sub set with z= 1. Let us single out the subset F0eF such that for every operation 9j e® 0 the function 9j = 0 for all the vectors from the E0. The rest of operations F\(F0 U9) will be denoted by F1.
TIO (9):
1. Construct the table M(E0,F1) which rows correspond to all vectors ek e E0, and columns correspond to all operations 9j e®1. Derive a minimal subset of the table rows which jointly 1-cover all rows of the table. The subset will be denoted by <E1>.
2. Construct similar the table M(E1,F0). Eliminate from the table each row which is 0-covered by some other one. The retained vectors will be denoted by <E0>.
3. The set <E>=<E1> u <E0> will be the operands of the operation 9.
4. The end
Table 1. Functions of the set F
(a,b) Functions 9 (a,b)
9 1 9 2 9 3 9 4 9 5
a v b a-b a © b a-b ab
e1=(00) 0 0 0 0 1
e2=(01) 1 0 1 0 1
e2=(10) 1 0 1 1 1
e4=(11) 1 1 0 0 0
Table 2. Results of the procedure TIO(j j )
9 E0 E1 ®0 ®1 <E0> <E1>
9 1 e1 e2 e3 e4 9 29 3 9 4 9 5 e1 e2 e4
9 2 e1 e2 e2 e4 - -g -e -U -G -6 e3 -
9 3 e1 e4 e2 e3 9 4 9 1 9 2 9 5 e1 e4 e2
9 4 e1 e2 e4 e3 - 9 1 9 2 9 3 9 5 e2 e4 -
9 5 e4 e1 e2 e3 9 3 9 4 9 1 9 2 e4 e1
In Table 2 the results of the procedure TIO(j) applied to the operations j1 j2,..j5 , given in the Table 1, are represented.
The given example is very simple and has been described here only for illustration. A more complicated procedure providing for different meanings on p bits (i=1,2,...p) are given in [5,6]. Moreover our researches in [6] permit us to claim that for most of MP operations a number of bits which are to be
R&I, 2003, N 3
35
analyzed for function distinguishing is not more than 3 (p J 3). So we can estimate the complexity of test indicators TIO(j) as O(M), where M is the number of functions of the set F.
4. Conclusion
We have considered a functional approach applied to testing RISC microprocessors. Based ona detailed functionpartitionwe have analyzed groups ofMP mechanisms, implementingvarious MP functions and determined means for their testing. A special attention has been given to the control hardware testing. The RISC peculiarities allowed us to put an accent on the register decoding and operation decoding mechanisms. Further, we have formulated and grounded two main hypothesizes that permitted us to construct test procedures for the control hardware on the base of RISC architecture only without resort to michroarchitecture peculiarities. In other words, the control hardware faults are revealed immediately, throughthe supposed fault-free data processing and storage environment, and we tried to detect them without resort to the control hardware implementation details. Such an approach allowed us to obtain very efficient test procedures, their complexity being estimated
as O(M+m), where M is a number of MP instructions and m is a number of MP architectural registers. The procedures, which we named as test indicators, can be easily implemented for computer selftesting or external testing.
References: 1. Thatte S.M., Abraham J.A. Test Generation for Microprocessors // IEEE Trans. on Computers, 1980. C-29(6). P.429-441.2. Robach C., Saucier G. Dynamic Testing of Control Units // IEEE Trans. on Computers, C-27(7). 1978. P.617-623. 3. Brahme D., Abraham J.A. Functional Testing of Microprocessors // IEEE Trans. on Computers, C-33(6). 1984. P.475-485.4. Shen L., Su S. Y.H.A Functional TestingMethodforMicroprocessors // IEEE Trans. on Computers, C-37(10), 1988. P.1288-1293. 5. Tchipulis V.P., Sharshunov S.G. On Generating Tests for Microprocessors // Measurement, 1986. Vol.4, N°1. P.28-38. 6. Tchipulis V.P., Sharshunov S.G. Analysis and Test Construction for Digital Programmable Devices // Moskow: Energoatomisdat (in Russian). 7. Van de Goor A.J., Verhallen Th.J.W. A Functional Testing of Current Microprocessors (applied to the Intel i860O ) // In Proc. IEEE Int. Test Conference, 1992. P.684-695. 8. Suc D.S., Reddy S.M. AMarch TestforFunctional Faults in Semiconductor Random Access Memories // IEEE Trans. on Computers, C-29(6), 1981. P.982-985. 9. Tanenbaum A.S. Structured Computer Organization. // Prentice Hall. 1999.
PROCESSING
SUPPORT
F2
OP RA LITERAL RC
ADDRESS
ARITHM.
rc=
DM2
RISC architecture representation
36
R&I, 2003, N 3
