1. 2012.3.12 Presenter: PCLee

2. Semiconductor manufacturers aim at delivering high-quality new devices within shorter times in order to gain market shares. First silicon debug and diagnosis are important issues to be tackled in order to minimise the time-to- market and avoid expensive re-spins, while volume testing is necessary for guaranteeing acceptable quality levels. In this study, the authors propose an infrastructure intellectual property (I-IP) intended to be a companion for embedded processor cores. The proposed I-IP is an efficient, flexible, low cost and easy-to-adopt solution for managing silicon debug, diagnosis and production test of microprocessor cores and of other cores in a system-on-chip (SoC), offering full support to the three domains of test, diagnosis and debug. A key characteristic of the proposed solution is that the requirements from the three domains are faced in an integrated manner, and the interface to the device during test, diagnosis and debug is a single one, supporting command-based interaction (instead of bit based). A prototypical design has been developed and integrated in an OGG Vorbis decoder SoC including a Leon2 microprocessor core, thus allowing a first practical evaluation about costs and benefits of the introduced I-IP-based approach. On this sample scenario, the key aspects in the process of testing, diagnosing and debugging a typical SoC are discussed.

3. What’s the problem  Diagnosis, test and debug is for different manufacture stage, but they have common requirements to integrate in an I-IP. Proposed method  Integrate diagnosis, test and debug in I-IP  Support software-based self-test(SBST) and software-based diagnosis(SBD) to achieve low-cost.  Cross-fertilisation achieved by 。 Resource sharing 。 Common automatic test equipment interface(ATE) 。 Common system interface

4. Debug:  Finding errors that are introduced during design before manufacturing.  Logic errors, timing errors or physical design/process errors.  Find during design verification, static analysis, simulation, design-rule checking and formal verification. Diagnosis:  Finding, locating and identifying physical defects in post-silicon.  Physical design/process errors. Test:  Relying on DfT harware structure.  Scan chain,built-in self-test modules and SBST(software-based self-test).  SBST is flexibile, reduced application costs.

5. Common points of test, diagnosis and debug:  Diagnosis is more powerful and longer procedure than testing-devoted mechanism. 。 It also relying on scan-based and software-based strategies. 。 So DfT is suitable for test and diagnosis.(if adequate)  DfT and DfD structures may not be efficient enough to debug pupose 。 Implement 3 debug modes

6. SBST requirement  Upload program to suitable memory area.  Run program and Stimulating components  Observe behavior and retrieve the result suitably stored. Upload mechanism  Selection circuitry for directly accessing the memory  Transfer code and data from buffer to memory by running preliminarily loaded software procedure. Mechanism for running test program  As above  Interrupt mechanism. Record program into ISR.

7. Procedures for devising SBST can be used to devise SBD  But diagnosis require more detailed analysis of result to determine faults. diagnosis programs generating step approach is proposed by Chen and Dey[22]  “Software-based diagnosis for processors” ACM Design Automation Conf., 2002

8. ISR debug mode:  Halt processor. It allows ATE to access user register and memory location. Clock-gating debug mode:  Using scan-based approach leads to a more thorough debug.  As soon as the breakpoint hits, its internal registers can be accessed through the scan chains and the processor stops.  Also using on step execution. Snapshot debug mode:  If some reason prevents clock-gating mode, it works.  Used to collect flip-flop contents.  If needed, compress through a LFSR(linear feedback shift register) module.

9. Include logic for test program upload and activation through the interrupt request Include logic for programming and activating the breakpoints, for selecting the debug mode, and actuating it.

10. Environment:  LEON2, 32-bit processor  256 kbyte SRAM  Audio core and MDCT core

11. IIP can support test, diagnosis and debug functionalities for minimising area occupation, reducing the redesign efforts and unifying the protocol test/diagnosis/debug procedures development. The proposed approach guarantees a high flexibility in applicable flows and easy adaptability to different processor configurations.