210 likes | 370 Views
Paper Report. A Software-Based Self-Test Methodology for On-Line Testing of Processor Caches. G. Theodorou , N. Kranitis , A. Paschalis, D. Gizopoulos Department of Informatics and Telecommunications, University of Athens, Athens, Greece Test Conference (ITC), 2011 IEEE International
E N D
Paper Report A Software-Based Self-Test Methodology for On-Line Testing of Processor Caches G. Theodorou, N. Kranitis, A. Paschalis, D. Gizopoulos Department of Informatics and Telecommunications, University of Athens, Athens, Greece Test Conference (ITC), 2011 IEEE International Cite count: 3 Presenter: Jyun-Yan Li
Abstract • Nowadays, on-line testing is essential for modern high-density microprocessors to detect either latent hardware defects or new defects appearing during lifetime both in logic and memory modules. For cache arrays, the flexibility to apply online different March tests is a critical requirement. For small memory arrays that may lack programmable Memory Built-In Self-Test (MBIST) circuitry, such as L1 cache arrays, Software-Based Self-Test (SBST) can be a flexible and low-cost solution for on-line March test application. • In this paper, an SBST program development methodology is proposed for online periodic testing of L1 data and instruction cache, both for tag and data arrays.
Abstract (cont.) • The proposed SBST methodology utilizes existing special purpose instructions that modern Instruction Set Architectures (ISAs) implement to access caches for debug-diagnostic and performance purposes, termed hereafter Direct Cache Access (DCA) instructions, as well as, performance monitoring mechanisms to overcome testability challenges. • The methodology has been applied to 2 processor benchmarks, OpenRISCand LEON3 to demonstrate its high adaptability, and experimental comparison results against previous contributions show that the utilization of DCA instructions significantly improves test code size (83%) and test duration (72%) when applied to the same benchmark (LEON3).
What is the Problem • Why is essential to test cache • The caches of mulprocessor occupy almost 90% in the chip area • The hardware defects may cause • Erroneous cache miss • In the tag array • Unpredicted system behavior • In the data array • Memory built-in self test (MBIST) can be used for on-line test • The cost of MBIST is higher than the cache • Chip area, performance • The Software-based self test (SBST) is utilized to overcome the lack of MBIST
Related work SBST Direct mapped data cache [15] SBST classifying [11] Cache memory [12, 13] Embedded processor [7,8] Set-associative cache [19] Test cache when no special instruction in the ISA Classified according to ISA or RTL Aim at the some components to generate test pattern Test cache by March C- algorithm & cache controller Test data & instruction cache RAMSES memory fault simulator [22] A Software-Based Self-Test Methodology for On-Line Testing of Processor Caches This paper:
Cache array testability challenges • Not direct access by generic ISA • D-Data • Implement March write/read by ISA • D-Tag & I-Tag • March write by load instruction (occur cache miss) • Can’t implement March read • Observation by unexpected cache miss • I-tag may be covered by SBST routine and can’t implement descending order • I-Data • Test pattern is composed by valid instructions • be covered by SBST routine and can’t implement descending order
Proposal method • Using Direct Cache Access (DCA) instructions • Special instructions for debug-diagnostic and performance purposes • Direct controllability and observability of cache arrays • Alternate space identifier (ASI) store/load instructions in the SPARC • System control coprocessor (CP15) debug operations in the ARM • Prefetch instruction • As DCA to cache controllability • With generic instructions to cache observability
Cache SBST Development • Applying March tests to verify cache arrays • Ex: March SS • Main features • High controllability of DCA instructions for March write • High observability of DCA instructions for March read • if no DAC instructions, implementation March read for tag arrays by the performance monitor • Compact test response
Data cache-write operations • Have DCA instructions • Initial D-Data and D-tag array • Haven’t DCA instructions • Using prefetch instruction to fill cache lines and tags • Neither DCA nor prefetch instruction • Cache load miss and refill by the generic load instructions
Data cache-read operations • Have DCA instructions • Accessing both D-Tag and D-data arrays and comparing them • Haven’t DCA instructions • Using performance monitor to determine cache hit or not • Neither DCA nor performance monitor • Tag arrays are verified indirectly by comparing data in [13] & [15]
Data cache-addressing order (AO) • Implement ascending or descending by loop • Have DCA instructions • DD_write():initial cache line/word • DD_read():read cache line/word • can’t select way • Repeat k times for a k-ways with k different DB sets • Haven’t DCA instructions • Prefetch(A)+m load instructions • m:number of word per line • performance monitor • determine cache hit or not • Data backgrounds (DB) is defined in a memory data segment
Instruction cache challenges • SBST routine affect the instruction cache testing • Place in the same cache during test • Replace test data when fetch instruction of pattern • SBST routine should be placed in a non-cacheable • If no non-cacheable area • Using cache enable/disable mechanism • Increase code size & test duration • descending order
Instruction cache-write operations • Have DCA instructions • Initial I-Data and I-tag array • No limitary content of data array • Haven’t DCA instructions • Using prefetch instruction to fill cache lines and tags • Should be valid instructions • 1 return instruction in every cache line • Neither DCA nor prefetch instruction • Cache load miss and refill by the generic load instructions
Instruction cache-read operations • Have DCA instructions • Accessing both I-Tag & I-data arrays and comparing them • Haven’t DCA instructions • Call instruction and the target is desired cache line • Verifying by the operating result of target for I-Data • Using performance monitor to determine cache hit or not for I-Tag • Neither DCA nor performance monitor • Inserting control instruction at the different word in a cache line
Instruction cache-addressing order (AO) • Have DCA instructions • Limitation of accessing cache line in descending AO by SBST routine • Haven’t DCA instructions • Prefetch(A) + performance monitor for the descending AO • By software loop
How to prove the proposal • How many • instructions in the test program • Clock cycle for the simulation • Faults in the hardware • How much • Fault coverage • Which kind of the faults • Comparing with ?
Experimental environment • RAMSES memory fault simulator • Consist of a simulation engine & fault descriptors • LEON3 • 4KB 2-way L1 data & instruction cache • OpenRISC 1200 • 4KB direct mapped L1 data & instruction cache
Implement March test • LEON3 • Using DCA instructions for the March read/write • Expect response is zero • Fault coverage: 100% • OpenRISC 1200 • Using prefetch instruction for the March write • Using enable/disable cache for the instruction cache • Monitor cache miss by performance counter • Data cache fault coverage: 100% • Instruction cache fault coverage: • Single cell fault: 100% • Coupling fault: 99% • Corrupt a single test
Compare with [15] • March test: March C- • Cache array is similar with LEON3 • Data cache verification • Result:
Compare with [19] • March test: March SS • Both are LEON3 processor • Instruction cache verification • Result: • Code size (I-Tag & I-Data) improves 83% • Time duration improves 72%
Conclusion • Overcomes testability challenges of L1 cache array by • Special purpose instructions for debug-diagnostic and • Performance monitor • Improve 72% time duration and 83% code size in the LEON3 of experimental result • My comment • Using them to reduce code size and execution time to achieve low-cost test pattern • Hard to implement I-Data and I-tag test pattern when no DCA