David Lavo

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