Upload
olympe
View
69
Download
1
Tags:
Embed Size (px)
DESCRIPTION
David Lavo. A Good Excuse for Reuse: “Open” TAP Controller Design. Purpose. TAP controllers are becoming a delivery and control mechanism for DFT Reuse and integration of DFT are hampered by incompatible TAP designs RTL standardization of the TAP is facilitated by the IEEE Standard - PowerPoint PPT Presentation
Citation preview
David Lavo
A Good Excuse for Reuse:“Open” TAP Controller Design
Purpose
TAP controllers are becoming a delivery and control mechanism for DFT
Reuse and integration of DFT are hampered by incompatible TAP designs
RTL standardization of the TAP is facilitated by the IEEE Standard
Extending the core organization to add-on DFT increases reuse and productivity
Outline
TAP controllers and board testTAP controllers and DFTA particular problemThe benefits of organization“Open TAP” architectureAutomated TAP configurationA discussion of reuse and its potential
TAP Controllers and IEEE 1149.11149.1 was established primarily for board testTargets shorts and opens in board interconnectEliminates probe & bed-of-nails testingAll tests conducted through the TAP controller:
Shifting in and decoding instructionsShifting, capturing and driving pin dataDisabling pad outputs (high-z)Polling chips on-board, internal tests, etc.
IEEE 1149.1 Components
Instructions and data scanned into TDI, out TDOState of the controller is determined by TMSTCK clocks the FSM and other test componentsTRST is an asynchronous reset
The TAP Controller Grows Up (and becomes popular)
On-board test control is too tempting for test engineers to leave alone
The TAP controller is evolving into a platform for all sorts of test purposes:
Logic and memory BIST controlInternal scan chain controlRunning and modifying internal testsClock generation and controlDebug and diagnosis facilities
Every TAP for Itself
Basic TAP functions are defined by 1149.1, but:Implementations vary widelyMany different ways of adding functionality
TAP controllers created for a single purpose or chip are difficult to re-use, extend and modify
Re-designing core components is inefficient and error-prone
Third-party DFT often comes with its own TAP
One (Common) Scenario
Reused TAP Controller
withScan Control Internal Scan Chains
New JTAGPads
Scan WrapperControl
ClockControl
Third-Party TAP Controller
withBIST Control
Third-Party BIST
Controller(s)
Incompatible Boundary Control SignalsTAP Merge?Incompatible Boundary Control SignalsUndefined Interface to TAP State and Logic
Order From ChaosThere are many different ways of organizing a
TAP controller design in RTL code The RTL architecture can make a big difference
when re-using and extending TAP designs
Flat Architecture: module TAP(…);
endmodule // TAP
Bypass Register
Instruction RegisterInstruction Decode
Instruction Decode
Instruction DecodeRegister MUXing
Glue Logic
Misc Logic FSM
Order From ChaosThere are many different ways of organizing a
TAP controller design in RTL code The RTL architecture can make a big difference
when re-using and extending TAP designs
Hybrid Architecture:
module TAP(…);
endmodule // TAP
Bypass Register
module Inst_Reg(…)
Instruction Decode
module Reg_MUX(…)
Glue Logic
module FSM(…)
Instruction Decode
Ideal TAP RTLShould be easy to understandShould conform closely to 1149.1 documentationTAP core should be complete and compliantTAP core should have only essential logicShould be extendable for different types of boundary
registers and other specializationsShould have parameterized values for register
lengths, opcode values, state encoding, etc.
Object-Oriented RTLPrinciple: Build up complexity from well-defined, inviolable
objectsInterface over implementationA TAP has core objects and interfaces defined by an IEEE
StandardA methodology for extension:
Build from core signals and interfacesExtensions should themselves be modular and object-orientedExtensions should be “well-behaved”
The “MPH” Model
The “MPH” Model (cont)
TAP Controller Core Components
Finite State
Machine(FSM)
{ ShiftDR, ClockDR, UpdateDR }
{ ShiftIR, ClockIR, UpdateIR }
SelectIREnableTDO
TCK
TMS
TRST_N
TAP FSM Signals
TAP Controller Core Components
Bypass Register
Instruction Register
StandardInstruction
Decode
Finite State
Machine(FSM)
RegisterSelect (MUX)
TCK
TMS
TRST_N
{ ShiftDR, ClockDR, UpdateDR }{ ShiftIR, ClockIR, UpdateIR }Instruction[N-1:0]
breg_sout
TDI
TDOEnableTDO
SelectBoundarySelectBypass
Adding an IDCODE Register
Bypass Register
Instruction Register
StandardInstruction
Decode
Finite State
Machine(FSM)
RegisterSelect (MUX)
breg_sout
TDI
TDO
IDCODEInstruction
Decode
IDCODE Register
TCK
TMS
TRST_N
idcode_sel
Expanded RegisterSelect (MUX)
{ ShiftDR, ClockDR, UpdateDR }
Boundary Control
Bypass Register
Instruction Register
StandardInstruction
Decode
Finite State
Machine(FSM)
RegisterSelect (MUX)
TCK
TMS
TRST_N
breg_sout
TDITDO
{ ShiftDR, ClockDR, UpdateDR }{ ShiftDR, ClockDR, UpdateDR } { Custom Control Signals }
BISTControl
BBC
{ ShDR, ClkDR, UpdDR } → { BIST Breg Ctl } → { User Breg Ctl }
UserBReg
Control
Handling Resource ConflictsSharing common resources can lead to conflictsEspecially true at Register Select/MUX, Boundary RegisterAt Register Select:
Multiple selects indicates error, select Bypass RegisterAt Boundary Register:
Allow multiple controllers, optionally check for simultaneous accesses
Well-behaved and well-designed modules shouldn’t compete
Benefits for the Design Organization
The modular nature of the “Open TAP” makes configuration and support much easier
Highly-tested core componentsStandard model for developmentMuch improved reuse of extensions
The designer benefits as wellWell-organized RTLReuse of DFT, support tools, documentation“Plug-and-play” configuration
Web-Based TAP Configuration
The TAP Controller as Reuse Ideal
A nearly-ubiquitous chip component A core set of functions well-defined by a StandardSome specialization is almost always required or
desiredRelatively low performance requirements!
The TAP Controller as DFT OS (?)TAP controller sits at the tool interface to DFTTest IP could be delivered with its interface:
Core and submodule testLogic and memory BISTAnalog testDifferent types of boundary registers and scan flopsTest and diagnosis
A common TAP base enables mixing of third-party DFT and other test IP
Is Cooperation Possible?
It is not easy to get designers to agree on a design, even for TAP controllers
However:Most TAP designs are still relatively simpleThe core interfaces are key, not implementationThe benefits may outweigh the inconvenience
Partial adherence - modularity - is better than nothing
ConclusionsEveryone has his or her own use for a TAP
controllerAd-hoc RTL designs are difficult to re-use, extend,
and debug Simple organization of RTL creates opportunities
for a high level of reuseDelivery of DFT becomes standardizedBottom line:
Increased productivity for test engineerIncreased productivity for test support personIncreased testability for designs