Paper report
This presentation is the property of its rightful owner.
Sponsored Links
1 / 21

Paper Report PowerPoint PPT Presentation


  • 81 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Paper Report

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Paper report

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 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

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

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

Compare with [15]

  • March test: March C-

  • Cache array is similar with LEON3

  • Data cache verification

  • Result:


Compare with 19

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

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


  • Login