IMPROVING TRANSPUTER INTERNAL MEMORY RELIABILITY WITH TRANSPARENT TEST: CASE STUDY AND PERFORMANCE ANALYSIS

Transcription

1 University of Hull, UK, p69-614, August, 1997 IMPROVING TRANSPUTER INTERNAL MEMORY RELIABILITY WITH TRANSPARENT TEST: CASE STUDY AND PERFORMANCE ANALYSIS Eduardo Augusto Bezerra 1, Fabian Vargas 2, Ingrid Jansch-Pôrto, João Paulo Kitajima 4 1 eduardob@infpucrsbr - Instituto de Informática PUCRS - Porto Alegre Brazil 2 vargas@eepucrsbr - Escola Politécnica PUCRS - Porto Alegre Brazil ingrid@infufrgsbr - Instituto de Informática UFRGS - Porto Alegre Brazil 4 kitajima@dccufmgbr Depto de Ciência da Computação UFMG - Belo Horizonte - Brazil Abstract: This paper presents a test procedure allowing on-line fault detection for the transputer internal memory during periodical field tests The technique is based on Transparent BIST, which was implemented by software (transputer instruction set) and by taking advantage of the existing transputer hardware characteristics The main characteristics of the transputer and internal memory are presented, as well as a detailed description of the test implementation and experimental results Additionally, the degradation induced by the periodical field test in global system performance is discussed The test approach can also be applied at the board level in order to verify the main memory system Aiming to improve the performance of this type of test, it is also described some features being developed along with the PISH Project (Projeto Integrado de Software/Hardware - CNPq - Protem/CC) These features deal with the use of programmable logic devices (FPGAs) to implement dedicated hardware for boardlevel testing purposes Keywords: Memory cell; Test generation; Fault detection; Parallel processors; Satellites 1 INTRODUCTION Like most of the commercial processors, the design of INMOS transputers is not based on Design for Testability (DfT) techniques (INMOS 1988) However, transputers are drastically different from other commercial processors when the support for concurrent and parallel processing is taken into account With respect to their architecture, while commercial processors present basically an internal floating point unit (FPU) and cache memory, transputers present (in addition to the internal FPU and RAM memory) timers/counters, processes scheduler, interruption controllers and serial communication channels This high level integration of functions into a processor, associated with the possibilities of implementing high-performance distributed computation arrays, allows the use of transputers in applications where volume and weight of the electronic equipment must be as small as possible such as is the case for avionics and spacecraft applications (Thompson, 1991; Castro and Gough, 1992; Paula, 1995) Electronics used in these types of applications must keep a fault tolerant behaviour even in the presence of faults (Nicolaids, et al, 199; Vargas and Nicolaids, 1994) In radiationexposed environments, the accumulated (total dose) radiation degrades the electrical parameters of transistors (eg threshold voltage, carrier mobility and leakage current) This has as consequence the generation of deleterious spurious erroneous outputs until permanent functional failures of circuits (Nicolaids, et al, 199) The test approach described and implemented in this paper is intended for using in such critical applications, particularly in the case of micro-satellites, where reliability and cost constraints are always at a premium TestC PU TestFPU Manager Fig 1 Transputer testing processes TestRAM TestLinks The use of transputers in applications where a high reliability level is required depends on the use of online fault detection techniques Considering that DfT techniques were not integrated into the design of the IMS T8 transputer, a test approach for it has been proposed by Bezerra and Jansch-Porto (1995a); ad hoc techniques are used to perform on-line periodical field tests on the transputer IMS T8 by exploring functional block partitioning and a test model based on the specific organisation of this component Then

2 University of Hull, UK, p69-614, August, 1997 each functional block can be tested separately The CPU and FPU are tested through a functional method based on (Robach and Saucier, 198), with the processor instructions being modelled by means of graphs, which form the basis for a minimum instruction set (Bezerra and Jansch-Porto, 1995b) The execution of this instruction set exercises all the elements in the respective functional block of the transputer However, this procedure is not a direct implementation of the Robach s approach (198) due to the particular characteristics of the transputer (instructions for parallel process execution and its internal block structure) A reduced instruction set allows a fast on-line test, minimising performance degradation For the remaining blocks (RAM memory and communication channels), specific test procedures were developed The test procedure proposed by Bezerra and Jansch-Porto (1995a) is composed by communicating concurrent processes (see Fig 1) A manager process monitors and synchronises the testing processes of the transputer functional blocks The testing processes were written in occam2 (INMOS, 1989) and assembly (INMOS, 1987) The frequency in which the testing processes are applied to each block is determined independently Depending on application constraints, some test procedures may be omitted to reduce system performance degradation The internal RAM memory test is a problem not adequately solved by Bezerra and Jansch-Porto (1995b), although two algorithms for the TestRAM process were proposed The first one verifies the memory by off-line test or during system start-up and it is restricted to these conditions because the first algorithm (the mtest program developed by INMOS) erases the contents of the memory The second algorithm copies the contents of the internal RAM into an external RAM previously to the test This procedure is not suitable for periodical tests of the memory Next it is proposed a test approach that does not erase the contents of the memory when implementing process TestRAM which intends to solve those problems This approach is named Transparent BIST (Nicolaidis, 1992; Kebichi and Nicolaidis, 1992) Therefore, in the following resent, an implementation of this approach according to the specific transputer architecture is presented It is also discussed some modifications in this test in order to improve test execution time of both internal and external memory at the board level of the system 2 PRELIMINARIES A typical memory is composed by an address decoder, address and data registers, read/write logic and memory cells (Breuer and Friedman, 1976) This concept is also applicable to the transputer RAM A RAM memory is said to be fault-free if it can store a or a 1 in each cell, change this cell from to 1 and vice-versa, and finally, read all these values in each cell of the memory RAM memory test procedures are generally executed by means of read/write test patterns applied to the memory cells, being the address decoding and read/write logic implicitly tested with the test of memory cells Due to the fact that the RAM memory presents a very regular structure, the generation of the test procedure is reasonably simple, but other sources of problems exist These ones are the test time duration that grows according to the assumed fault model and the moment when the test is applied, since if an on-line test is carried out it must be ensured that the contents of the RAM memory at that moment will not be lost In Breuer and Friedman (1976), several test procedures for RAM memories are described such as MSCAN, marching, walking and galloping Among them, the marching test is considered the more powerful due to its simplicity of generation and reduced time for application (Castro Alves, 1995) The marching test is generally applied by off-line tests The drawback of this approach for on-line tests is that the contents of the memory are all lost Therefore, if used as on-line test, memory contents have to be previously saved into an auxiliary memory; and after restored This constraint implies in an unacceptable test cost in terms of time and hardware overhead To solve the mentioned problem, Nicolaidis (1992) proposed the Transparent BIST to test on-line RAM memories, which ensures that the contents of the memory are not lost by the procedure application The Transparent BIST approach is introduced by Nicolaidis (1992) together with the requirements to transform a conventional test algorithm, the Marinescu s approach (Marinescu, 1982), into the Transparent one, with the same fault coverage (see Fig 2a) In this algorithm, four read(ri)/write(wi) sequences are performed, where index i represents the memory cell that is being accessed In sequences S1 and S2, the cells are accessed in one direction, while in sequences S and S4 the cells are accessed in the opposite direction This is done in order to detect decoder and read/write logic faults During the first read operation in S1, the initial values for the test are obtained Then, successive write operations inverting or not the value to be written and successive read operations inverting or not the value to be read are performed The symbol Wi ( Ri ) means that the value to be written (obtained during a read) must be inverted with respect to the value obtained (read) during the last write (read) At

3 University of Hull, UK, p69-614, August, 1997 (a) S1 S2 S S4 W 1 W 1 W 1 W 1 W 1 W 1 W W 1 W 1 W 1 W 2 W 2 W 2 R W W W W n W n W n (b) R W 2 W 2 R W R W W n W n W 2 W 2 R W W W n W n W S1 o S2 o S o S4 o R R R W n W 2 R R R W 2 2 R W R W W n W n W 2 1 Fig 2 Transparent BIST (a) Modified Marinescu s algorithm; (b) Test signature generation the end of the test, the value written during the last write operation of sequence S4 will be the same value read during the first read operation of sequence S1, and thus, characterising the Transparent BIST An important step of this approach is the comparison of the final test result with the reference one Since the final state (as well as the initial state) of the memory cells is unknown, a test signature must be generated before the test begins To do so, in order to generate the test signature, the sequences listed in Fig 2b are executed The obtained memory signature is then stored for further comparison with the test results obtained after the read operations of sequence S4 The fault model adopted in such an approach is composed of: stuck-at faults; coupling faults; transition faults; read/write logic faults; and addressing faults Once the whole test procedure is finished, the obtained fault coverage is 1% for the assumed fault model THE PROPOSED APPROACH The transparent test is implemented in three steps: CRC calculation of the memory contents (memory signature); execution of the test procedure over the memory; and the verification of the signature generated during the test against the value obtained during the first step In order to do the test, the following resources are needed: support for CRC generation; registers to store CRC results; and a register to store memory contents of the word under test The registers used to store temporary data are needed because of the fact that, once started the test, new data cannot be added to the memory, since this action would change memory signature In the case of the transputer memory, no additional hardware is necessary to implement the transparent BIST which may be directly implemented using the existing CPU registers, the instruction for CRC calculation (crcword), and words from the external memory for the storage of auxiliary variables Then, the signature is computed by using the crcword instruction that calculates the CRC over the bits of a word The transparent test for the transputer memory may be expressed by the following algorithm: Used variables: crc1 and crc2 - used to store the signatures obtained after each test step; desloc - used to store the offset related to the internal memory; max4k - address of the last position to be tested in the internal memory; aux4k - stores partial results; mem4k - the mem4k variable is an array of integer with 996 units of 4 bytes each (making 984 bytes to be tested) The mem4k[desloc] addresses memory words that may be written or read To the memory address #1C (first address of the user internal memory - the addresses before #1C are used for the processor workspace) is associated the label mem4k[] (occam2 command: PLACE mem4k AT #1C), allowing the internal memory access (read/write) All variables, but mem4k, are located in the external memory First step: Sequence S1 S4 (Fig 2b) 1 Initialisation: crc1:= (only for S1 ), max4k:=#ff and desloc:= (for S and S4, desloc:=#ff); 2 For all addresses between mem4k[] and mem4k[max4k]: Load aux4k with the contents of the memory according to the sequences S1 to S4 of the algorithm given in Fig 2b Instruction: aux4k:=mem4k[desloc]; Calculate the CRC for each value of aux4k, using the CCITT generator polynomial (x 16 + x 12 + x 5 + 1) Instruction: crc1 := CRCWORD (aux4k, crc1, #881), where #881 is the generator polynomial For the sequences S1 or S2, increment desloc; otherwise decrement desloc Test desloc in order to verify if all the memory has been visited, for a given sequence Once all the addresses have been visited, crc1 will have the memory signature

4 University of Hull, UK, p69-614, August, 1997 Second step: Sequence S1S4 (Fig 2a) 1 Initialisation: crc2:= (only for S1), max4k:=#ff and desloc:= (for S and S4, desloc:=#ff); 2 For all addresses between mem4k[] and max4k: Read/write memory words according to the algorithm sequences S1 to S4 (fig 2a) In this step the faults belonging to the fault model adopted may be detected Instructions: aux4k:=mem4k[desloc] (to read), mem4k[desloc]:=aux4k (to write), and mem4k[desloc]:= ~aux4k (to write with negation); In case of read operation: compute CRC for each value of aux4k Instruction: crc2 := CRCWORD (aux4k, crc2, #881); For the sequences S1 or S2, increment desloc; otherwise decrement desloc Test desloc in order to verify if all the memory has been visited, for a given sequence Third step: compare signatures obtained in the first and second steps and stored, respectively, in crc1 and crc2 (µs) (a) 2 (s) T MHz 64 CPU FPU Links (b) 46 T85-25 MHz (ms) RAM Fig Execution time for: (a) TestRAM process in T414 & T85; (b) the four test processes of the T85 As stated before, the transputer has a processes scheduler implemented in microcode, which shares the CPU time among the concurrent processes that are in execution at a given time This characteristic may affect the executions of the described algorithm: if the TestRAM process is pre-empted by another one during its execution, this second process using the internal memory will violate the integrity of the CRC computation that was in course by the TestRAM In order to prevent this kind of problem, TestRAM has to be executed in high priority In the transputer, high priority processes only miss the CPU to other high priority processes if certain instructions occur: communication, timers operation and branch (instruction j) During TestRAM execution, instructions of communication and timers operation are not used, but the FOR and IF occam2 constructors employ branch instructions Due to this fact, these constructors had to be written in assembly in order to eliminate the branch instructions (in this case, the unconditional jump was replaced by a conditional jump) For this reason, the TestRAM algorithm described before has been partially implemented in occam2 and partially in assembly 4 EXPERIMENTAL RESULTS The proposed algorithm has been executed in two different 2-bit processors from the transputer family: the IMS T414, installed in a B4 card with 15 MHz clock; and the IMS T85, installed in a B8 card with 25 MHz clock The processor T85 has a FPU and some instructions that do not exist in the T414 The used B4 card has just one processor while the B8 has four T85 processors working in parallel In the B8 card implementation, each T85 transputer has four instances of TestRAM procedure running concurrently with the processes from the user application From Fig a, note that the execution of TestRAM in the T85 is about 25 times faster than in T414 This difference is mainly due to the fact that T85 has a specific instruction for CRC calculation (instruction crcword) while in the T414, it is executed by a sequence of instructions The values presented in Fig were obtained from individual executions of each test procedure Related with these procedures, the main problem is to define an ideal frequency of test procedures activation, resulting in acceptable system performance degradation without compromising fault coverage requirements In order to simulate typical applications on transputer-based systems, and also to measure application execution times with and without the test procedures, a simplified version of ANDES (Kitajima, 1994) was implemented ANDES is a performance evaluation tool based on synthetic programs (in a synthetic execution computing resources are used in a controled way without implementing a real application) From the measures obtained, it is possible to determine the best activation frequency of the test procedures It is also possible to verify the impact of the inclusion of a given test procedure ANDES is based on the execution of a synthetic parallel workload whose parameters can be easily modified The simplified version of ANDES is composed of three kinds of processes: the master executes on the transputer responsible by the communication with the host; the slaves execute on the other transputers of the network; and the idle, responsible by the computation of the idle time, also executes on the network

5 University of Hull, UK, p69-614, August, 1997 transputers The master receives data from the user concerning the workload These data are sent to the slaves The master then keeps the starting time of the synthetic execution, sends a starting signal to the slaves, and waits a signal from the same slaves This signal informs that each slave has finished its synthetic task The master then keeps the time again, and the total execution time is computed Before finishing the synthetic parallel program, the slaves send to the master their respective idle Each slave is programmed as an alternation of execution and communication broadcast phases The user can determine the size of these phases (that is, the granularity of the parallel application) More or less communication can be generated At the end of the synthetic execution on each slave, it sends to the master and to the local idle process a finish flag The idle time (see Fig 4b) is then read and sent to the master Using the synthetic loops and the broadcast messages, it is possible to model a large range of typical parallel applications (s) (s) A N D E S al on e A N D E S al o ne cpu cp u, f pu cpu cp u, f pu I dl e Processes cp u, f pu, ram c cpu, f pu, r am a b I dl e ti m e f or each sl av e (o btai ned b y the i d l e pr ocesses) w hen ex ecutin g A N D E S: w i th test w i th test w i th test alone cpu cpu & cpu, fpu & f p u ram a b c Fig 4 Degradation of a system due to the insertion of test procedures In Fig 4, comparative graphs are presented for an ANDES synthetic typical application (three slaves: a, b and c; broadcast message length with 5 bytes; and synthetic loops size 2), the synthetic application running standalone (without the test procedures) has an execution time of 6197 seconds With the insertion of CPU and FPU test processes (execution frequency = 5), this time goes to 621 seconds and, with the insertion of the RAM test procedure (execution frequency = 4,), the total time is 625 seconds (see Fig 4a) Fig b shows the execution times for the T85 testing processes (CPU, FPU and Links) defined by Bezerra and Jansch-Porto (1995a) and the TestRAM process as described in the present paper It is possible to observe that the RAM memory test is approximately 55 times slower than others transputer units test (a ) ( b ) 5 EXTERNAL MEMORY TEST The proposed procedure may be also applied to the transputer external memory at the board level without any significant changes For example, to execute the test in 2 Mbytes of memory it is necessary, basically: split the memory into 41x5 Kbytes blocks; change the length of the integer array mem4k in order to allow the mapping of the 128 words (512 bytes to be tested); to execute the test procedure 41 times, placing mem4k in a different memory position after each execution (PLACE command of occam2); and to load max4k with the higher block address For the external memory, as well as for the internal one, the main drawback of the test procedure is the execution time For the external memory, the time spent to access the memory cells is much longer Thus, aiming to improve the external memory test at the board level, some procedure modules that were implemented by software procedures are now implemented directly in hardware This work is being accomplished in the PISH Project (Barros, 1994) This is a multi-institutional project involving four research centres: UFPE, UFRGS, PUCRS and UFSE The PISH goal is to develop methods for hardware/software co-design automation of systems from a functional description in a high level of abstraction In the PISH Partitioning Step, a system described in high level of abstraction is partitioned in two parts: one mapped to hardware and the other part into software The prototyping step uses the Harp-2 platform (Bailey, 1996), which is basically composed of a transputer, an FPGA (Field Programmable Gate Array) and memory The software part of the description is executed in the transputer, while the hardware part in the FPGA The internal memory test procedure is entirely implemented in software With Harp-2 the CRC operation may be implemented by a dedicated hardware (into the FPGA), keeping the rest of the procedure implemented in software to be executed by the transputer So, the idea is to take advantage of such a facility to allow hardware/software co-design of more suitable test procedures targeted to specific system configuration and reliability level constraints For example, we may: implement different generator polynomials or signature analysers; do the read/write memory access; compress read values; and generate/evaluate test signature operations may be implemented directly by the FPGA module instead of using the transputer

6 University of Hull, UK, p69-614, August, CONCLUSIONS The decision of using the Transparent BIST approach to test the transputer internal memory is due to its corroborated effectiveness in fault detection modelled by: stuck-at, coupling, transition, and address decoder and read/write logic faults (Kebichi and Nicolaidis, 1992) The proposed algorithm has been implemented and used in both transputers T414 and T85 In order to apply this algorithm to the new member of the transputer family: T9, it is necessary to change the size of the array mem4k to 16k bytes (this is the size of the T9 internal RAM), and to load the max4k variable with the new address of the last word to be tested in the memory In the same way, the proposed approach can be applied to other processor embedded memories and/or external memory systems For applications in which the periodical test of the RAM may not be based on a 458 ms procedure (see RAM at Fig b) due to system reliability and/or performance degradation, this procedure may be split into smaller ones, where only a small area of the cell array (and respective read/write logic and decoders) is tested at a time In this case, slices of the test procedure are interleaved with the application as many times as necessary But this approach will work well only with the memory cell array decomposed into predefined areas Then, each area is tested at a time: first by generating the test signature and then by applying the test procedure to this specific region of the memory Due to the fact that TestRAM may cause a great overhead and turn inefficient the on-line test procedure, a possible solution can be its execution with low periodicity (in the order of hours) For instance, in space applications, this test may be executed each 1 hours, since in general, the accumulated radiation (total dose) degrades system performance and reliability at low rates An immediate application of the test procedure herein presented can be the SACI-1, a micro-satellite for scientific applications being developed at the Brazilian Institute for Space Research - INPE (Paula, 1995) The CPU subsystem of this satellite has three transputers T85 and it is scheduled for launching during the second half of 1997 Note: The TestRAM process is available in: ftp://wwwinfpucrsbr/~eduardob/transputer/testador REFERENCES Bailey, A (1996) Programming the Harp-2 using Handel- C Oxford University Computing Laboratory, Oxford Barros, EN (1994) PISH: Projeto Integrado Software/Hardware Protem/CC - CNPq project Bezerra, EA and I Jansch-Pôrto (1995a) Procedimento de Teste para Detecção de Falhas no Transputer In: VI Fault Tolerant Computers Simppp UFRGS, Brazil Bezerra, EA and I Jansch-Pôrto (1995b) A Minimal Test Set for the Transputer Processor In: X SBMICRO pp UFRGS, Brazil Breuer, MA and AD Friedman (1976) Diagnosis & Reliable Design of Digital Systems Computer Science Press, Woodland Hills Castro, H and M Gough (1992) Mars94: A Fault-Tolerant Multi-Transputer Array for Space Applications In: Transputers 92: Advanced Research and Industrial Applications pp IOS Press, Amsterdan Castro Alves, V (1995) Functional Test of Single and Multi-Port SRAMs In: X SBMICRO pp UFRGS, Brazil INMOS (1987) The Transputer Instruction Set - A Compiler Writer s Guide INMOS Limited, Bristol INMOS (1988) The Transputer Databook INMOS Limited, Bath INMOS (1989) OCCAM 2 Reference Manual INMOS Limited, Bristol Kebichi, O and MA Nicolaidis (1992) Tool for Automatic Generation of BISTed and Transparent BISTed RAMs In: European Design Automation Conference, pp IEEE, Paris Kitajima, JP (1994) Modèles Quantitatifs d'algorithmes Parallèles INPG, Grenoble, 1994 (PhD Thesis) Marinescu, M (1982) Simple and Efficient Algorithms for Functional RAM Testing In: IEEE International Test Conference Nicolaidis, M (1992) Transparent BIST for RAMs Grenoble, TIMA/INPG (Technical Report) Paula, AR (1995) Aspectos de Tolerância a Defeitos do Sistema de Computação do Primeiro Microssatélite de Aplicações Científicas do INPE In: VI Fault Tolerant Computers Simp pp 6-75 UFRGS, Brazil Robach, C and G Saucier (198) Microprocessor Functional Testing In: IEEE Test Conference, pp 4-44 USA Thompson, HA (1991) Transputer-Based Fault Tolerance in Safety-Critical Systems In: Microprocessors and Microsystems, Vol 15, N 5, pp Vargas, F and M Nicolaidis (1994) SEU-Tolerant SRAM Design Based on Current Monitoring In: 24th FTCS - International Symposium on Fault-Tolerant Computing Austin, USA