Transcript PowerPoint 簡報 - National Sun Yat

2012.3.12 Presenter: PCLee

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-tomarket 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.

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

Debug:




Diagnosis:



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.
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.

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

SBST requirement




Upload mechanism



Upload program to suitable memory area.
Run program and Stimulating components
Observe behavior and retrieve the result suitably stored.
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.

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

ISR debug mode:


Clock-gating debug mode:




Halt processor. It allows ATE to access user register and memory location.
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.
Include logic for programming
and activating the breakpoints,
for selecting the debug mode,
and actuating it.
Include logic for test program
upload and activation
through the interrupt request

Environment:



LEON2, 32-bit processor
256 kbyte SRAM
Audio core and MDCT core

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.