310 likes | 532 Views
EE434 ASIC & Digital Systems. Jacob Murray School of EECS Washington State University jmurray@eecs.wsu.edu. Test Methodologies. Lecture 31. System-on-Chip Testing. Introduction Why SoC? Core-based design What makes core-based testing different?
E N D
EE434ASIC & Digital Systems Jacob Murray School of EECS Washington State University jmurray@eecs.wsu.edu
Test Methodologies Lecture 31
System-on-Chip Testing • Introduction • Why SoC? • Core-based design • What makes core-based testing different? • A conceptual architecture for Core Test Access • Test pattern source and sink • Test Access Mechanism • Wrapper
Introduction • An organized group of components that performs some specified task is called a system. • Traditional electrical systems consisted of PCBs. A board contains a number of VLSI chips and the wiring between them. • Advances in design methods as well as manufacturing technologies for ICs enable creation of complete systems onto a single die. These are called systems-on-chip (SoCs).
Why SOC? • Large number of transistors on a single chip • An entire system can be built on a chip • Faster and smaller products • Higher performance • Lower power consumption
Core based design • Creating multi-million gate system-chips from scratch using conventional method is difficult. • A new chip design paradigm based on design reuse • Integration of multiple large predesigned and preverified reusable building blocks, called embedded cores • Different types of cores • soft (RTL) • firm (gate-level net list) • hard (technology dependent layout)
What’s new in core-based system testing? • Core provider only delivers a description of the core design to the SoC designer. • The system integrator considers the core as a black-box. • No direct access to the core cell ports from the primary inputs and outputs of the end product
A Conceptual Architecture for Core Test Access • Three separate elements in the embedded core test infrastructure • Test pattern source and sink • Test Access Mechanism • Core test wrapper
Source & Sink • The source generates the test stimuli and the sink compares the response to the expected response. • Source and sink of a core can be implemented either off-chip, on-chip or as a combination of both.
Test Access Mechanism • It takes care of on-chip test pattern transport. • The key components of any TAM are its width and length. • The width refers to the TAM’s transport capacity. • The length of a TAM is the physical distance it has to bridge between the source and core or core and sink.
Different ways of implementing a TAM • When implementing a TAM, we have the following options • A TAM can either reuse existing functionality to transport test patterns or be formed by dedicated test access hardware. • A TAM can either go through other modules on the IC or pass around those other modules. • One can either have an independent access mechanism per core, or share an access mechanism with multiple cores. • A test access mechanism can either be a plain signal transport medium, or may contain certain intelligent test control functions.
ARM’s AMBA System • An example of reusing existing functionality as TAM. • 32-bit system bus transfers test stimuli from IC pin to the core under test and test responses vice-versa. • Advantages • Low additional area cost • Relative simple test expansion • Disadvantage • fixed 32-bit bus does not allow to make trade-offs between area cost and test time
Connection of IC pins to core terminals • Connect additional wires to the terminals of the core and multiplex those onto existing IC pins. • Advantage of this approach • Embedded core can be tested as if it were a standalone device; the translation of core-level tests into IC-level tests is simple and straightforward. • Disadvantage • It is not scalable.
Reuse of Boundary scan test • A scan chain around embedded cores • It provides access for the core-internal tests as well as inter-core interconnect testing. • Boundary scan test has the advantage that it builds on an existing method. • Drawback • Single bit for test control and test data access path, does not allow trade off between bandwidth and test time.
Test Bus • Flexible bandwidth • Accesses core-under test directly from the IC pins • Shares one access mechanism with multiple cores, through tri-state bus • The main disadvantage is per test bus only one core can be connected at a time.
Test Rail • Combines the strength of both the test bus and boundary scan test approaches. • One or more test rails of varying width per IC – trade off between test time and silicon area. • Multiple cores can be daisy chained into one test rail. • Per core there is a test rail bypass-allows user to test each core sequentially or multiple cores in parallel – trade off between diagnostic resolution and test time.
Core Test Wrapper • Interface between the embedded core and its system chip environment. • It connects the core terminals both to the rest of the IC, as well as to the TAM. • It is implemented on chip.
Operational modes of wrapper • Normal Operation – non-test mode, the wrapper is transparent. • Core Test Mode – TAM is connected to the core. • Interconnect Test Mode – The TAM is connected to the interconnect wiring and logic. • Bypass Mode – Test stimuli and/or responses for other cores are transported through the wrapper.
P1500 Standard • IEEE standard • http://grouper.ieee.org/groups/1500/index.html • It consists of two components • Core Test Wrapper • Core Test Language (CTL)
SoC with P1500 wrapped cores • TAM source/sink – chip I/O, test bus/rail, BIST, etc. • TAM in/out – 0 to n lines for parallel and/or serial test data, or test control • Wrapper Interface Port (WIP)
P1500 SIL Architecture • Serial Interface Layer (SIL) • WIP selects the WIR or a WDR between WSI and WSO
P1500 Wrapper Interface Port(WIP) • WIP is used to access the WIR, Bypass and other data registers.
Core Test Language (CTL) • It’s a language for capturing and expressing test-related information for reusable cores. • CTL describes three types of information • Aspects of the test data • Different configurations of the core • System integration instructions