P1687 2008 Update: The Whole Story The IJTAG Features and Capabilities Alfred L. Crouch Chief...

P1687 2008 Update: The Whole StoryThe IJTAG Features and Capabilities

Alfred L. CrouchChief Technologist & Director of IJTAG R&DVice-Chair IEEE P1687 “IJTAG” Working Group

BTW – Sept 2008

Crouch

The Current CommitteeActive P1687 (IJTAG) Working Group

Chair: Ken Posse (Avago) Vice Chair: Al Crouch (Asset-InterTech) Editor: Jeff Rearick (AMD) Std. Liaison: Ben Bennetts (Bennetts Assoc. – Ret) Web Master: Michael Laisne’ (Qualcomm)

Current Working Group Members:

Jason Doege (AMD); Mike Ricchetti (ATI); Srinivas Patel, Mike Wiznerowicz (Intel);

Bill Eklow, Hongshin Jun, Ted Eaton (Cisco); Thai-Minh Nguyen (LSI

Songlin Zhuo (Qualcomm); Pradipta Ghosh (Broadcom);

Hugh Wallace, Rick Nygard, Richard Dugan (Agilent); Scott Hartranft (Tektronix)

Thomas Rinderknecht, Paul Reuter (Mentor); J.F. Cote (LogicVision);

Rohit Kapur (Synopsys) – 1450.6 CTL Liason; Ed Malloy (Cadence);

Bill Tuthill (Intellitech); Stylianos Diamantidis (GlobeTech); John Potter (Asset-InterTech);

Harrison Miles, Andrew Levy (Corelis); Heiko Ehrenberg (Goepel);

Brad Van Treuren, Michele Portolan, Suresh Goyal (Alcatel-Lucent);

One Hump

Two Hump

Three Hump

5-Legged Moose

Basic Camel

A Camel is a Horsedesigned by committee…

Chip & Board Design

External Instruments

EDA Tool Providers

JTAG Tool Providers

System Level Users

We have broad representation, but it has slowed us down a little

Some Semantics…from the Corporate Confusion Department…

Lots of new and used Acronyms and Abbreviations:• IJTAG = Internal JTAG• BSDL Zone = Boundary Scan Description Language Zone• TDR = Test Data Register• IIF = Instrument Interface Register• GDR or GIR = Gateway Data or Gateway Instruction Register• SIB = Select Instrument Bit• MIB = Multiple-Input Bit• GWEN = Gateway Enable Instruction• HIP = Hierarchical Interface Port• HDL = Hardware Description Language• IDL = Instrument Description Language• CDL = Connectivity Description Language• PDL = Protocol Description Language• S/C/U = Shift/Capture/Update

P1687 2008 Update: The Whole Story – Part 1The IJTAG Features and CapabilitiesThe Instrument and Hardware Portion


BTW – Sept 2008

Crouch

What is IJTAG? What are Instruments?

IJTAG is the P1687 Proposed Standard which will be designed to enable more efficient access and optimized interconnect to embedded logic and electrical/environmental monitors inside the chip:• for all purposes: functional configuration, test, debug-diagnosis, yield• for all environments: wafer probe, package test, die-stack, board test, in-system• to promote reuse from one environment to the next

• P1687.0 will stipulate the 1149.1 JTAG port as the primary access mechanism

• Embedded content is defined as instruments and includes items such as: FCN: Bus Configuration, Pin Configuration, Power Modes, Clock Modes DFT: MBIST, LBIST, Scan-Compression, Test-Wrappers, Clock-Controllers DFD: Logic Analyzers, Bus Monitors, Traffic Monitors, Trace-Buffers, Hardware

Assertions, Embedded O-Scopes DFY: Voltage Sensors, Temperature Sensors

• The goal is to enable standard control and configuration (architectures, connections, and interfaces) and to also:

allow higher bandwidth data delivery to instruments that need it allow instrument-to-instrument communication allow TAP-asynchronous instrument operations (e.g. a fail flag)

What Problem Does IJTAG Solve?

IJTAG solves two main problems:

1. Specifying how to Include embedded logic not meant for board test under the 1149.1 TAP and TAP Controller without causing problems with 1149.1 Complianceo Clogging up the 1149.1 BSDL with non-board test content – higher probability of bad BSDLo Badly or inadequately describing complex instrumentso Growing the Instruction Register with tens, hundreds, or even thousands of instructionso Dealing with one-hot instructions (instead of IR encoding)o Dealing with hierarchical nesting and changing scan-path lengths

2. Enabling optimization, efficiency, and tradeoffs to be applied to the growing volume of embedded logic and electrical monitor content (instruments) in modern chipso Allows a variety of connections instead of just JTAG daisy chain (all-at-once serial) or star (one-

at-a-time)o Allows organization of embedded content into groups and hierarchies…o …enables reuse of IP that may have entire instrument architectures (as opposed to TAPs)o Offloads the non-board-test content out of the 1149.1 Instruction Register

TestAccessPort

Standard JTAG Flow-Through Model

TCK

TMS

TDI

TDO

XTRST

Instruction Register (IR)

Bypass Register (BYP)

Boundary Scan Register (BSR)

TAP ControllerState-Machine[4]

ComplianceEnable

1. TAP2. TAP Controller

1. SM2. IR

1. Instructions2. Decode

3. Bypass4. ½ Cycle-Adj

3. Registers4. BSDL

Decode

Z

Today, 1 Instrument usually = 1 TDR + at least 1 JTAG Instruction

TAP State Machine

TestLogicReset

0

1

RunTestIdle

0 1SelectData

Register

1

0

SelectInstructRegiste

r

1

0

UpdateData

Register

1

0

UpdateInstructRegiste

r1

0

CaptureData

Register

01

CaptureInstructRegiste

r0

1

Exit 1Data

Register

0

1Exit 1

InstructRegiste

r0

1

Exit 2Data

Register

1

0Exit 2

InstructRegiste

r1

0

PauseData

Register

1

0 PauseInstructRegiste

r1

0

ShiftData

Register

0

1

ShiftInstructRegiste

r

0

1

• Legal Sequences: those allowed by the compliant 1149.1 TAP SM

1. Normal Event Order: Capture-Shift-Update

2. All State Changes on Rising-TCK & TMS

3. Five 1’s on TMS goes to TLR from anywhere in the State Machine

4. All “Inputs and Samples” on Rising-TCK

5. All “Outputs and Updates” on Falling-TCK

The IJTAG Differences

TAP & TAP Controller

1149.1 JTAG Zone

Small Instruction Register

All Items Described in BSDL

Keeps JTAG Logic Simpleand Compliant – only addition

is Instruction to small IR toselect Gateway Register

Instruments

P1687 IJTAG Zone

Instrument Control Connections

Instrument Data Connections

All Items Described in “HDL/PDL”

Allows complex instrumentsto be described and to includethe extra information neededthat would complicate BSDL

GATEWAY

REG

The Gateway Register is a TDR-like structure existing in both sides

1149.1 Supports P1687 by…

By including a TDR called a Gateway and an instruction (GWEN: GateWay ENable) to select it in the 1149.1 Instruction Reg; to describe the Gateway in the BSDL

TDI 1149.1-IR

BYP

Gateway

BSR

IDCode

TDOGwen

WSOi

WSIo

All inside the boxdescribed in the1149.1 BSDL

HIPen

Min Fixed Length &Private for BSDL

The Gateway Select-Instrument-Bit (SIB)

TDI

Shift-Update Cellused as a SIB

Sel_i

TCK

U

TDO

WSOi

WSIo

SCThe HIP

The HierarchicalInterface Port (HIP)

opens up a connectionto embedded instruments

when an Assert valueis placed in the U-Cell

after a TAP State- MachineUpdate-DR action

The Sel_Instrument Signalis used to gate the

ShiftEn, CaptureEn,UpdateEn, and if needed,

the TCK signal of thetarget register to enablethe register if selected

andto disable the register if

not selected

The Key Element for Adding, Organizing, Managing Embedded Content

Scan Path Management Bit

The Gateway Register is made of one or more of these SIBs

1687 Hardware Architecture

TCK

TRST*

TMS

TDI

TDO

WSIWSO

A GatewayInterfaceRegister

JTAG TAPMaster

Controller

TAP-IR[n:0]

1 2 3 4 5A

B

C

D

E

F

G

H

THE VIEW FROM THE TAP

All Activity in the1687-Zone is

a DR-Scan from theTAPs Point-of-View

In-Line Instruments

This Hierarchy Thread inserts fromWSIo-to-WSOi of the Gateway-A SIB

1149.1-Zone

P1687-Gateway

HIP

1687-Only-Zone

Instruments connected to theGateway may be connected inseveral different schemes:1. Flat – one gateway-bit is connected to

one instrument2. Daisy-Chain – one gateway-bit is

connected to many instrument serially and simultaneously

3. Star – one gateway-bit is connected to some grouping of instruments

4. Concatenate – one gateway-bit isconnected to a serial string ofinstruments that insert into the TDI-TDOpath as they are activated

5. Hierarchy – one gateway-bit is connectedto an instrument that may support furtherhierarchical connections

The 1687 Zone is accessed by opening up Scan Paths to Embedded Instruments

1687 Hardware Architecture

TCK

TRST*

TMS

TDI

TDO

WSIWSO

JTAG TAPMaster

Controller

TAP-IR[3:0]

A

B

C

D

E

F

G

H

THE VIEW FROM THE TAP

This Hierarchy Thread inserts itself from theWSIo to the WSOi of the Gateway-A SIB

WSIWSO

1 1 2 3 4 4 5 5 6 7 8

This Hierarchy Thread inserts itself from theWSIo to the WSOi of the Gateway-E SIB

1687-Only-Zone

1149.1-Zone

Example of In-Line Instruments opening upHierarchical Connections to other Instruments

1 2 3 4 5 5 6 7 7 8WS

IW

SO

1 1 2 2 3 3 4 4 1 2 3 4

WS

IW

SO

WS

IW

SO

1 2

Gateway SIB Bits may be used within Scan Paths to open new Scan Path Hierarchies

1687 Hardware Interfaces: 1687 Starts at GW

WSIWSO

A

BCDE

FGH

THE VIEW FROM THE CONTROLLER

This Hierarchy Thread inserts itself from theWSIo to the WSOi of the Gateway-A SIB

WSIWSO

1 1 2 3 4 4 5 5 6 7 8

This Hierarchy Thread inserts itself from theWSIo to the WSOi of the Gateway-E SIB

Gateway is beginning of 16871687-Only-Zone

Example of use of a non-compliant TAP andTAP-Controller or other State-Machine

Gateway may be TDR-like or 1500-TAM-like

1 2 3 4 5 5 6 7 7 8WSI

WSO

1 1 2 2 3 3 4 4 1 2 3 4

WSI

WSO

WSI

WSO

1 2

Update-En

Serial-Out

Shift-En

Capture-En

Reset

TCK

Example of SignalsRequired to operatea 1687 Gateway and

Connected Instruments

HIP_En

Select

Serial-In

The 1687 Standard starts at the Gateway, not the TAP, to allow other future controllers

Basic 1687 Hierarchy DescriptionSignals defined by Allowed Hierarchical Level and Node Boundaries: Basic Minimalist Structure - The General Case

Level of Hierarchy Root (TAP) Node [Dot-0]

Gateway Node (e.g. Instrument Access Register)

Instrument Interface Node (e.g. Instrument Registered Wrapper)

Leaf Node (Unwrapped Raw Instrument Signal Interface)

PortList Left Right Left Right Left Right LeftClock Clock Clock Clock

TCK to_TCK TCK to_TCK TCK

Control Control Control ControlTMS TRSTN to_ResetN ResetN to_ResetN ResetN to_Select Select to_Select Select to_CaptureEn CaptureEn to_CaptureEn CaptureEn to_ShiftEn ShiftEn to_ShiftEn ShiftEn to_UpdateEn UpdateEn to_UpdateEn UpdateEn to_SelectLIR SelectLIR to_SelectLIR

Data Data Data DataTDI to_ScanIn ScanIn to_ScanIn ScanIn TDO from_ScanOut ScanOut from_ScanOut ScanOut to_DataBits DataBits from_StatusBits StatusBits

This portion can be described by a hardware language similar to BSDL with the exception that hierarchy and dynamic scan chains must be described as well as local or distributed instructions.

This portion is beyond BSDL and this is where the PDL needs to be applied.

Note: the Instrumentitself is actuallyoutside of the

Standard since wedo not Specify it inany way other than

requiring StaticSignals

1687 Instrument Interface Bit Definitions

C/S U

CombinationStatus CaptureSignal Generation

C/S

Status Capture

S U

Signal Generation

C/S U

CombinationStatus CaptureScan Path Add-In

Read-Write Cell

Read-Write Cell*

* Require Capture to be onlyfrom U-cell output as Self-Check

II_1

II_0

II_2

II_3

II_4

WSIWSO

A

BCDE

FGH

WSIWSO

Sel_WIR

HIP

Serial-Out

Update-En

Shift-En

Capture-En

Reset

TCK

HIP_En

Select

Serial-InC/S U

CombinationSelf-CheckingSignal Generation

Read-Write Cellwith Self-Check

Cells can be defined similar to Boundary Scan Cells to make up the Interface Register

Write-Only Cell

Read-Only Cell

II_x = Instrument Interface

I’m Confused???

Why all the complexity? Isn’t Daisy-Chain and Star enough – it seems to be good enough for the board world…

…is there a difference inside the chip as opposed to outside the chip and on the board?

And who is supposed to use this stuff anyway?

How does it help board-test?

I’m Confused???

Why all the complexity? Isn’t Daisy-Chain and Star enough – it seems to be good enough for the board world…• Chip Designers still get measured by successful implementation of

meeting their engineering and budget goals

• Development of the access architecture versus chip tradeoffs is key




I’m Confused???


…is there a difference inside the chip as opposed to outside the chip and on the board?• Right now, chips have an incredible amount of “embedded” test,

debug, and yield logic that must be accessed

• One key technology is “power management” with requires shutting down clock domains and even power domains inside the chip



I’m Confused???



And who is supposed to use this stuff anyway?• Use Case 1: Instruments-Only, Sub-Architectures given to integrator – result is an

“inserted & verified” tradeoff-driven 1687 Architecture

• Use Case 2: Whole chip with 1687 Architecture given to chip-test engineers for wafer, package, die-stack test – locating instruments, reusable or auto-generated vectors; debug & diagnostics; data-collection

• Use Case 3: Multiple chips with 1687 Architectures given to board-test, system-development, or for in-system use to assess chip goodness/margins and to help board-test – locating instruments, reusable or auto-generated vectors; debug & diagnostics; data-collection; comparison to ATE test results


I’m Confused???




How does it help board-test?• Testing complex board is no longer just about interconnect, chip orientation, and

power delivery

• High-Speed routes and traces must be characterized (e.g. chip-to-chip SerDes channels with BERT and Eye-Diagrams)

• Chips must be re-verified in-situ because of different environment conditions from ATE test

• This requires operating the test logic and monitors associated with and embedded within chips

The Connections and Tradeoffs (inside chips)

4 Non-Hierarchical: Flat, Daisy-Chain, Star, Concatenate Hierarchical: Use of the SIB to open nested Gateways

Tradeoffs:• Engineering:

Area, Timing, Routing Power-Thermal Risk

• Compliance/Efficiency: IR-Depth, Scan-Path-Depth, Scan-Path-Depth-Stability

• Utility/Automation: Concurrence Post-Silicon Flexibility Protocol-Complexity Language-Complexity

The application of tradeoffs results in different architectures

1687 Flat Example

Low-Cell Area ImpactHigh Route-Congestion

High-Scan-PathHigh-Control

Wide-IRShortest Scan-PathsStable Scan-PathNo ConcurrencySimple ProtocolSimple DescriptionLow Risk

1

TAP

Inst.

Inst.

Inst.

Inst.

Inst.

Inst.

Inst.

Inst.

1. IR maps all Instructions2. TDI-TDO applied 1-at-a-time

FLAT – 1-at-a-Time1

TAP-IR

TAP-SM

TDO

TDI

CTRLCTRLSelect-InstrumentReset~CaptureEnShiftEnUpdateEnSelect-WIRTCK

1687 Daisy-Chain Example

TAP

Inst.

Inst.

Inst.

Inst.

Inst.

Inst.

Inst.

Inst.

1. IR maps all Instructions2. TDI-TDO to all Instrumentseven those that are not active

Daisy-ChainLow-Cell Area ImpactHigh Route-Congestion

High-ControlMed-Scan-Path

Small-IRLongest-Stable Scan-PathPotential Power ProblemAll ConcurrentSimple ProtocolSimple DescriptionHigh Risk

2

CTRLTAP-IR

TAP-SM

TDO

TDI

CTRLSelect-InstrumentReset~CaptureEnShiftEnUpdateEnSelect-WIRTCK

2

1687 Star Example

TAP

Inst.

1. IR maps to Instrument groups2. TDI-TDO organized by groups

Star

Inst.

Inst.

Inst.

Inst.

Inst.

Inst.

Inst.

Medium Cell Area ImpactMed Route-Congestion

Low-Scan-PathMedium-Control

Med-IRMed-Stable Scan-PathsHW-Fixed ConcurrencySimple ProtocolMedium DescriptionMedium Risk

3

CTRLTAP-IR

TAP-SM

TDO

TDI


3

1687 Concatenate Example

TAP

Inst.

Inst.

Inst.

Inst.

Inst.

Inst.

Inst.

Inst.

1. IR maps all Instruments2. TDI-TDO to active selectedinstruments only – similar todaisy-chain but some instrumentsare bypassed by wires

Concatenate

CTRLTAP-IR

TAP-SM

TDO

TDI


High-Cell Area ImpactMed Route-Congestion

Low-Scan-PathHigh-Control

Wide-IRShort Scan-PathsStable Scan-PathConcurrency-SchedulingPost-Si FlexibilityMax- ProtocolMedium DescriptionMedium Risk

4

4

1687 Hierarchy Example

TAP

Inst.

Inst.

Inst.

Inst.

Inst.

Inst.

Inst.

Inst.

1. IR opens Gateway2. TDI-TDO to SIB only3. Gateways are distributedinstruction registers4. Non-Selected instruments areinvisible

Hierarchy

CTRLTAP-IR

TAP-SM

TDO

TDI


Medium-Cell Area ImpactLow Route-Congestion

Low-Scan-PathLow-Control

Small-IRShort Scan-PathsDynamic Scan-PathConcurrency-SchedulingPost-Si FlexibilityMax ProtocolMedium DescriptionLow Risk

5

5

SIB

SIB

SIB

SIB

SIB

Do the Math (we are engineers, after all)

Hierarchy –vs- Daisy-Chain:

• 5000 Bits of Daisy-Chain takes 5000 clocks each time an instrument is accessed (flush whole chain, put back whole value with modification for 1 instrument) – 10 accesses (capture, shift, updates) requires 10x5000 shifts + 10x5 protocol clocks (SeDR, CaDR, ShDR, E1DR, UpDR) = 50050 clocks

• With 50 Bits of L-0 SIBs and each Bit expands to 100 Bits of L-1 SIBs – is 5000 Bits in 2-Levels of Hierarchy – addressing the worst case instrument (farthest from TDI) is 50 Shifts + 5 Protocol Clocks to open the 50th L-0 SIB; then shifting 150 Bits to reach the last instrument in the chain; times 10 accesses results in 55+10x150=1555 clocks

• Better more optimal hierarchical architectures are easily possible – instruments that need to be accessed a lot should be nearest SIB Bit[1] of the Level-0 Gateway; earlier hierarchy levels should have shorter registers – the image should look like a right-triangle

TestLogicReset

0

1

RunTestIdle

0 1SelectData

Register

1

0

SelectInstructRegiste

r

1

0

UpdateData

Register

1

0

UpdateInstructRegiste

r1

0

CaptureData

Register

01

CaptureInstructRegiste

r0

1

Exit 1Data

Register

0

1Exit 1

InstructRegiste

r0

1

Exit 2Data

Register

1

0Exit 2

InstructRegiste

r1

0

PauseData

Register

1

0 PauseInstructRegiste

r1

0

ShiftData

Register

0

1

ShiftInstructRegiste

r

0

1

SIB[0]

SIB[1]

SIB[2]

SIB[3]

SIB[4]

SIB[5]

SIB[6]

SIB[7]

SIB[8]

SIB[9]

SIB[10]

TDI

TDO ScanPath Depth

An Optimized AccessArchitecture

Tradeoffs vs Connectivity

# of Instruments

Connectivity

<10

<50

<100

<500

>1000

Flat Daisy-Chain Star Concatenate Hierarchy

One Instrument at-a-timeNo Concurrence AvailableMutual-Exclusive InstructionsNo Test Scheduling FlexibilityMost Routing Impact

One Instrument at-a-timeNo Concurrence AvailableMutual-Exclusive InstructionsNo Test Scheduling FlexibilityMost Routing Impact

All Concurrent – Most PowerOne Instruction – Most RiskMinimal Route/Area ImpactNo Test Scheduling Flexibility

All Concurrent – Most PowerOne Instruction – Most RiskMinimal Route/Area ImpactNo Test Scheduling Flexibility

Pre-Designed Instrument GroupsSome Post-Design FlexibilityManaged RiskMedium Route/Area Impact

Pre-Designed Instrument GroupsSome Post-Design FlexibilityManaged RiskMedium Route/Area Impact

Most Non-Hierarchical FlexibilityMost-Instructions (1 per Instrument)Variable Scan-PathsManaged Power – Managed Risk/2

Most Non-Hierarchical FlexibilityMost-Instructions (1 per Instrument)Variable Scan-PathsManaged Power – Managed Risk/2

Most-FlexibilityMost-InstructionsDistributed InstructionsVariable Scan-PathsManaged Power/RiskHidden InstrumentsComplex ProtocolMost Support LogicMost Reusable/Portable

Most-FlexibilityMost-InstructionsDistributed InstructionsVariable Scan-PathsManaged Power/RiskHidden InstrumentsComplex ProtocolMost Support LogicMost Reusable/Portable

The IEEE 1500 Connection

The 1500 WSP Configuration is ideally made for a Daisy-Chain connection:

1) because of the mandatory Bypass Register; and

2) would be best applied to a TAP Controller that either has no TAP-IR or the TAP-IR is concatenated to all 1500 WIRs (so the TAP-SM IR-Side can be used for the SelectWIR)

3) more commonly, 2 TAP Instructions select one 1500 WSP

The 1500 Standard has stipulated that Data remain separated from Instructions:

1) which is only useful when there is only 1 1500 WSP, or the 1149.1 TAP does not support its own IR, or when all WIRs and the TAP IR are concatenated when the State-Machine is on the Instruction-Side

2) this is why 1500 is still a multiple parallel register architecture with the WIR, BYP, and any WBR/CDR configured in parallel

3) the WIR can only be selected by the SelectWIR signal while other registers are selected/configured by the WIR

The 1500 ConnectionWBR

BYP

WIR

CDR

TDI

TDO

SWIR1500 WSP

WBR

BYP

WIR

CDR

TDI

TDO

SWIR1500 WSP

WBR

BYP

WIR

CDR

TDI

TDO

SWIR1500 WSP

WBR

BYP

WIR

CDR

TDI

TDO

SWIR1500 WSP

TDI

TDOWBR

BYP

WIR

CDR

TDI

TDO

SWIR1500 WSP

BSR

BYP

TAP-IR

TDR

TDI

TDO

SIR1149.1 TAP Controller

SeDR

CaDR

ShDR

E1DR

PaDR

E2DR

UpDR

TLR

SeIR

CaIR

ShIR

E1IR

PaIR

E2IR

UpIR

RTI

The use of an 1149.1 Instruction toselect the 1500 units in a daisy-chainwith a 2nd Instruction to select theWIRs

The SeIR path selects only the TAP-IR

5 Daisy-Chained 1500 Units with 2 TAP-IR instructions to select 1500 and select WIR

TAP Regs Out

1500 Regs Out

The 1687 Connection

WIR | Data | BYPTDI

TDO

1687 SIP

TDI

TDO

BSR

BYP

TAP-IR

SIB TDR

TDI

TDO

SIR1149.1 TAP Controller

SeDR

CaDR

ShDR

E1DR

PaDR

E2DR

UpDR

TLR

SeIR

CaIR

ShIR

E1IR

PaIR

E2IR

UpIR

RTI

In-Line WIRs

The SeIR path selects onlythe TAP-IR

WIR | Data | BYPTDI

TDO

1687 SIP

WIR | Data | BYPTDI

TDO

1687 SIP

WIR | Data | BYPTDI

TDO

1687 SIP

Four 1687 Units with embedded instructions to select Instrument Registers

The embeddedinstrument interfaceregisters are selectedby embedded instructions

What HW is missing or not quite described?

Bandwidth Port• Internal Instrument Bandwidth• External Pin/Port Bandwidth• Parallel versus Serial

Asynchronous Events• Instrument Events (triggers, breakpoints, assertions, flags)• Pin/Port Events (semaphore, sync pulses, interrupts)• Broadcast Events (resets, starts, stops)

Instrument-to-Instrument Communication• Actions of one instrument to another or many• Actions of multiple instruments aggregated to one instrument

But “Serial and JTAG-Like” Isn’t Enough!!!

Many have expressed concerned with Bandwidth and non-1149.1 Sequences• More instruments means more data – need higher bandwidth for

some instruments

• Coordination between instruments – need instrument-to-instrument communication

• Non-1149.1 Operations – need to conduct and describe TAP-asynchronous instrument operations such as a “fail flag” or “action trigger” that occurs when a fail happens, not when the State-Machine happens to be in Capture-DR (e.g. capture the comparator bus immediately if a fail is detected)

Parallel Operations

They already occur• Only the serial shift-in and serial shift-out are not parallel operations• Capture is a parallel load into the Shift/Capture Cell• Update is a parallel load into the Update Cell• JTAG Operations such as Extest, Intest, Clamp, HighZ are parallel

operations

To make use of these operations, terminology needs to be defined• Read: currently capture+scan-out of the Shift/Capture Cell• Write: currently scan-in+update of the Update Cell• TAP Synchronous: Read or Write aligns with State-Machine• TAP Asynchronous: Read or Write not aligned with State-Machine• Data-Operation: Read or Write involving Data• Control-Operation: Read or Write involving WIR

Parallel Notes

How does this replace a non-JTAG Instrument Interface?• Loading/Reading/Writing the parallel registers directly turns a

multi-clock-cycle serial operation into a single-clock-cycle operation – Bandwidth

• Parallel Reads and Writes that are TAP-Synchronous use TCK to synchronize the data transfers

• Parallel Reads and Writes that are not TAP-Synchronous can use any clock or trigger to synchronize the data transfers

• Instruments can create the triggers that other instruments would use to conduct data/control transfers – facilitates Instrument-to-Instrument communication

The Example TDR: The Serial Operations

S/C

S/C

S/C

S/C

Type-B TDR

U

U

U

U

Inst_Data[0]

Inst_Data[1]

Inst_Data[2]

Inst_Data[3]

Note:1. Update Register is Parallel2. Both Input and Output sideA Serial Preload

SIBSel/Mode

TDI

TDO

A Serial Read

The Example TDR: A Parallel Load

S/C

S/C

S/C

S/C

Type-B TDR

U

U

U

U

Inst_Data[0]

Inst_Data[1]

Inst_Data[2]

Inst_Data[3]

SIBSel/Mode

TDI

TDO

Some System Bus

Inst_Data /4

Pins/4

IDI

IDI

IDI

IDI

This is a PLoad

= A Capture

The Example TDR: A Parallel Read

S/C

S/C

S/C

S/C

Type-B TDR

U

U

U

U

Inst_Data[0]

Inst_Data[1]

Inst_Data[2]

Inst_Data[3]

SIBSel/Mode

TDI

TDO

Some System Bus

Inst_Data /4

Pins/4

IDI

IDI

IDI

IDI

Some System Bus

P_Bus /4This is a PRead

Pins/4

The Example TDR: A Write

S/C

S/C

S/C

S/C

Type-B TDR

U

U

U

U

Inst_Data[0]

Inst_Data[1]

Inst_Data[2]

Inst_Data[3]

SIBSel/Mode

TDI

TDO

Some System Bus

Inst_Data /4

Pins/4

IDI

IDI

IDI

IDI

This is a P/SWrite

Some System Bus

= An Update

The Example TDR: A Functional Apply

S/C

S/C

S/C

S/C

Type-B TDR

U

U

U

U

Inst_Data[0]

Inst_Data[1]

Inst_Data[2]

Inst_Data[3]

SIBSel/Mode

TDI

TDO

Some System Bus

Some System Bus

Pins/4Inst_Data /4

This is a FCN Apply

The Example TDR: A Parallel Diagnostic

S/C

S/C

S/C

S/C

Type-B TDR

U

U

U

U

Inst_Data[0]

Inst_Data[1]

Inst_Data[2]

Inst_Data[3]

SIBSel/Mode

TDI

TDO

Some System Bus

Some System Bus

P_Bus /4 Pins/4This is a DiagP_Bus /4

The Example TDR: A Parallel Transfer

S/C

S/C

S/C

S/C

Type-B TDR

U

U

U

U

Inst_Data[0]

Inst_Data[1]

Inst_Data[2]

Inst_Data[3]

SIBSel/Mode

TDI

TDO

Some System Bus

Inst_Data /4

Pins/4

IDI

IDI

IDI

IDI

Some System Bus

P_Bus /4P_Bus /4

This is a Transfer

Inst_Data /4

Connecting Instruments to the Pin Map

PIN

D Q

Update

Mode=Extest-like

Functional Data

Borrowed Pin Data

Select Borrowed Pin

UpdateEn

TDI

TDO

D Q

Capt/Shft

CaptureEn

CaptureEn OR ShiftEnRequires mixed instructions; a GW-CLAMP

in the TAP – a Select_IO in a Local-IR

Most-likely connection for chips that support 1149.1 Boundary Scan

TCK

I’m Board…

Let’s look at how this impacts the board-level today…

Triple-Point Diagram [PVTF]

Voltage

Temperature

Frequency/Process

ATETest

Location

BoardOperationLocation

Must correlate fails found atBoard/System operation toATE Test to avoid parametricNTF (No Trouble Found orFail not Repeatable)

Must give Silicon Providerfail information in context

Silicon Provider must adjustMfg Process or must adjusttest to screen closer toBoard/System operation point

In a Disaggregated World: must trace Systematic Si problemsback to ultimate provider – Si Library, EDA Tool, Core Provider,Chip-Stack, Die-Provider, Design Organization, Mask, Fab, Package…

Cost LimitsATE Test tominimumPVTF points

1687 Hardware Architecture at the Board Level

ArchitectureChip-2 GWEN-3 SIB-B

TCKTRST*TMSTDITDO

Chip #1TAP-IR[3:0]

1 1 2 3 4 4 5 5 6 7 8

ArchitectureChip-1 GWEN-1 SIB-B

1 1 2 3 4 4 5 5 6 7 8

TCKTRST*TMSTDITDO

Chip #2TAP-IR[4:0]

Example of two 1687 Chips in a Daisy-Chain

AB

C

WSIWSO

AB

C

WSIWSO

At the Board-Level – the two separate chip 1687Architectures become one seamless unified Architecture

THE VIEW FROM THE BOARD

Shows Scalability: Note – concern is mixed-use at board of 1149.1 and P1687

Chip 1

Chip 2

Chip 3

Chip 5

Chip 8

Mux 1

Chip 7b

Chip 6a

Chip 6b

Hierarchy Lev-0

Chip 9

The Board World Today

Scan PathLinking Module

Chip 4

TAP atBoard

Connector

Chip 7a

Daisy-ChainedChips

TCK

TMS

TDI

TDO

BSDLDescription

a

b

BSDL issufficient

forchip JTAG

descriptionand

connection

Groupings orStar Connectionsmay imposemutual-exclusivity

Representsa Black-Box

ChipDesign


ChipDesign


ChipDesign


ChipDesign

There is a needfor a simple linearindexing systemto map chips

Chips need to bedescribed in termsof pins and boundaryscan cells

Connectivity needsto be understoodto deliver vectorsto the chips


ChipDesign


ChipDesign


ChipDesign


ChipDesign


ChipDesign


ChipDesign


ChipDesign

Daisy-ChainedChips

Chip TDI-TDOconnections create the access map andare not required to beidentical on all chips

Chip instructionsare not required tobe mappedidentically

Chip JTAG InstructionsExtest, Sample, Preload,HighZ, etc. allow pins tobe interconnect tested

Inside-the-Chipis generally notknown and so isa Black-Box atBoard Test

Chips are deliveredwith BSDL Filesto describe JTAGfeatures

When Chips fail in systemsand boards today, they alsofail because of environmentAnd parametric margins;not just interconnect ororientation; these fails mustbe related back to provider

Let’s lookinside

Basic Goal of Board Test:

To verify that the correct chipsare in the correct spots; theorientation of chips; and thecompleteness of interconnect;

1149.1 (JTAG) is usedon board designs toconduct board testbecause it can be usedwithout external probingequipment

Gateway-1

Gateway/InstrumentInterface -1.a

InstrumentInterface -1.b

Gateway-1.c

InstrumentInterface -1.c.d or 2.b.d

InstrumentInterface -1.c.a

Gateway-1.c.b

InstrumentInterface -1.c.b.c

InstrumentInterface -1.c.b.a1

InstrumentInterface -1.c.b.b

Hierarchy Lev-0 Hierarchy Level-1 Hierarchy Level-2 Hierarchy Level-3

InstrumentInterface -1.a.a

1a

1b

1aa

1ca

1cc

1cbc

1cbb

1cba1

Inside-the-Chip Instrument Map

IndividualLeafCell

InstrumentInterface

CompoundGateway

MIB- GatewayG1=DefaultG2=Select

Gateway

Mutual-ExclusiveGateway

(G1 & G2 cannot beselected simultaneously)

Gateway-2

InstrumentInterface -2.c

2c

TAP IRWith

GWENs


1cba2

Daisy-ChainedInstruments

CombinationInstrument-IF

andGateway

TCK

TMS

TAP SM

TAP IR

TDI

TDO

JTAG Regs

BSDLDescription

a

b

c

a

b

c

a

b

c

123456a

a

b

cd

Instruments needto be described interms of purpose

and attributes

Connectivity needsto be understoodto deliver vectorsto the instruments

BSDL isinsufficient

forinstrumentdescription

andhierarchy

Groupings maybe separate IP

cores or macros

There is a needfor an adjustableindexing systemto allow mapping

Instrument Interfaces may include SIBs and can be

classed as Gateways

Gateways may bedaisy-chained tocreate Hier-Levels

Groupings maybe to align useor align latency

Gateways enableHierarchical Connectionsthat allow architectures

driven by tradeoffs

Instruments aremost-likely to bedelivered “raw”with signal I/Fs

Scan Compression

Logic BIST

Memory BIST

Voltage Monitor

Trace Buffer

Bus Monitor

Bus Configuration

Process Monitor

There may be fault-tolerantmulti-input connections tominimize broken scan path

risk – a multi-scan pathshared resource

Core Debug Unit

MFG Scan Chains

Gateways groupSIBs and SIBs are

dynamic scan pathmanagement bits

1149.1Zone

1687Zone

c/s u

WSO

TDI

WSI

SEL

TDO

Gateways can be viewedas distributed instructions

that represent “bypass” bitsto bypass instruments

Instrument Interfaces maybe viewed as Data Registers

or Instrument InstructionRegisters

The Handoff between the BSDLZone and the 1687 description

(HDL) is the chip identifiier in theBSDL (Entity); an instruction and the

register it selects

The Goal: To deliver StaticDrive signals and to extractStatic Status signals froma Leaf Instrument Nodeusing a JTAG-OperatedOpen Access Interface

P1687 2008 Update: The Whole Story – Part 2The IJTAG Features and Capabilities

The Language and Description Portion


BTW – Sept 2008

Crouch

Part II: The Description Languages

This Section includes the description, documentation, development and file handoff of the 1687 Architecture

Speaking of IJTAG: Can you see what I am saying?

How is all of this Documented and Described?

What is the “language” (human and otherwise) associated with 1687

If a chip is full of instruments…and they come from multiple IP Vendors and EDA tools and the local cube-dwelling design engineer…and then Bob the Integrator adds this JTAG-like infrastructure…

…how does all of this get documented? Where does the documentation come from? How hard is it to make the documentation? Who is going to use the documentation? How do I verify that the documentation is correct?...

Gateway-1



Gateway-1.c



Gateway-1.c.b






1a

1b

1aa

1ca

1cc

1cbc

1cbb

1cba1


IndividualLeafCell

InstrumentInterface

CompoundGateway


Gateway



Gateway-2


2c

TAP IRWith

GWENs


1cba2



andGateway

TCK

TMS

TAP SM

TAP IR

TDI

TDO

JTAG Regs

BSDLDescription

a

b

c

a

b

c

a

b

c

123456a

a

b

cd

Scan Path Connectivityneeds to be documentedsince it is a non-specified(variable) part of the 1687

architecture

Gateways may beviewed as InstructionRegisters that hold

instructions that controland configure other

defined Gateway andInstrument-Interface

registers

Gateways can produce“Add_Scan_Path”,

“Bypass_Other_Register”,“Configure_Other_Register”,“Modify_Register_Actions”,

and “Connect_IO_Pins”types of Instructions

The Name and theAttributes of theInstrument need

to be documented aspart of the SW part of

the 1687 Standard (e.g.signal connections)

The actual Instrumentitself is viewed as beingoutside of the HW partof the 1687 Standardsince it is not beingdefined or specified

by the Standard

The Level-0 Gatewayis Selected by a TAPInstruction and can

be viewed as anoffloaded DistributedInstruction Register

Instrument Interfaces maybe viewed as Instrument

Data Registers since theypass only DataBits and

StatusBits

The Point-of-View: the ScanPaths and Registers are viewedas the Delivery or CDL part; aLeaf Instrument Node is viewedas the IDL part; the CDL partmay also be viewed as a datadelivery mechanism and a set ofDistributed Instruction-Registers

The Level-n Gateways, bydefinition receive their control

and configuration (instructions)only from other Gateways

Peer Block

IJTAG Language AnalysisController Block

1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

In Terms of Software Code Blocks

SS

CellDef Block

SIB

Warning! This stuff is changingas we speak…meetings are beingheld…skids are being greased…engineers are skulking around indark corners (uh, different onesthan they usually hang around)…crayons are being brought to bear…waitresses are being short-tippedfor all day meetings in restaurants…

Peer Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn


SS

CellDef Block

SIB

Peer Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn


SS

CellDef Block

SIB

A CellDef Block:• describes the cells (BitType) similar tothe way 1149.1 defined the BC_2;

• maps available functions to the registers;1) Shift;2) Capture/Load;3) Update/Apply4) Pause/Hold5) Set/Reset6) Open/Close Scan Path


Peer Block

IJTAG Language ComponentsController Block

1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

A Controller Block:• describes operation sequences & signals;

• holds Instructions to select & configurethe access architecture;

• for dot-0 the defined controller is acompliant 1149.1 TAP Controller;

• 4 basic items are needed:1) BSDL Entity;2) Level-0 Access Instructions;3) Register selected;4) TAP Compliance = True or False


Peer Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

An I/O Pin Block:• Brings chip pins to the Instrument;

• is most-likely a shared resource(multiple instrument signals will goto the same pin);

• link from BSDL on 1149.1 chips & HDL;

• 3 basic items needed:1) the Pin;2) the Instrument Signal(s),3) the IO Enable Instruction(s)


Peer Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

A Gateway/Access Block:• Holds Architecture Configuration &Control Instructions that are offloadedfrom the main controller block;

• basic instruction is to add/remove(open/close) scan paths – thiscan be viewed as a Bypass action;

• other instructions can select,configure, and organize the AccessArchitecture resources or InstrumentInterface registers;

• Note: L-0 Gateway is in BSDL & HDL;

• basic items needed:1) number and types of bits;2) bit functions (instructions);3) Connectivity to other GW/IIFs;


Peer Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

A Peer Block:• Holds multiple instrument andinstrument interface rules andinformation;

• or multiple Gateways and theirpeer-to-peer connections;

• example, 2 daisy- chained elementshave individual bits using a sharedresource, the priority and encoding canbe represented here;

• only needed when peer-to-peerconnections exist


Peer Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

An Instrument Interface Block:• Includes the Wrapper that providesthe registered static signals to theinstrument;

• receives the raw sticky responsesfrom the instrument;

• viewed as a Data Register or anInstrument Instruction Register;

• may also include the control oraccess mechanism selection (serialor parallel)


Peer Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

An Instrument Block:• Includes the Leaf Instrumentdeclaration and portion of descriptionneeded;

1)Instrument attributes2)the signals;3)signal direction;4)signal attributes5)the link to the Instrument PDL


Peer Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

A PDL Block:• Includes vector-based procedures orsequences required to configure andoperate the instrument;

• should be independent of the accessmechanism (associated to the rawinstrument signal interface);

• PDL can be described as Methods toconduct individual configurations oroperations (primitives) or completetests (complex);

• Basic PDL is simply:1) Reads – Read<Instrument>2) Writes – Write<Instrument>3) Applies – Apply <R1, R2, W1…>

Peer Block

IJTAG Code Block RulesPeer Block

Controller Block

1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAF

I/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

PDLBlock

Method1

Method2

Methodn

Level-n GWBlock

GW1

GWn


One Controller Block percomplete architecture (onechip);

Multiple controller structuresmay exist within the Blockand their select mechanismsmust be described

Peer Block


Controller Block

1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAF

I/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

PDLBlock

Method1

Method2

Methodn

Level-n GWBlock

GW1

GWn


An Instrument Block may onlycontain and describe oneLeaf Instrument Object

An Instrument-Interface Blockmay only contain and describeone Instrument-InterfaceRegister

An Instrument Peer Block isrequired when more than oneInstrument+Instrument-Interfacegroup is under a Gateway and atthe same hierarchical level (e.g.a daisy chain of 5 IIFs)

Peer Block


Controller Block

1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAF

I/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

PDLBlock

Method1

Method2

Methodn

Level-n GWBlock

GW1

GWn


Multiple Gateway Blocks(Level-0 or beyond) mayexist per hierarchical level – ifmore than one block exists,then peer connections mustbe described

A Gateway Block is a Peerblock in that it may holdseveral Gateway Registers atthe same hierarchical leveland their local connections

Peer Block


Controller Block

1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAF

I/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

PDLBlock

Method1

Method2

Methodn

Level-n GWBlock

GW1

GWn


Instrument-Interface andGateway connections arelimited to being within thesame level of Parent-Child orPeer-to-Peer hierarchy;

Only Instrument-Interface toPin-Map connections cancross hierarchical boundaries

Where Does HDL Come From?

The Chip Provider must supply HDL for end users of the chip…

…but as the HDL is being built, its sections come from several sources – the goal = reusable code sections


Peer Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

Instruments and PDL aredelivered by the IP provider orby the EDA Tool that creates theHDL/RTL and synthesis-timingconstraints;

the standalone Instrumentdescription (IDL) does not needto contain any connectivityinformation


Peer Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

Gateways, Instrument-Interfaces,and the connectivity architectureare generated by the integrator orby an insertion tool that evaluatestradeoffs and creates an optimalarchitecture;


Peer Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

the integrator or insertion tool addsto the IDL portion of the HDL bydescribing the CDL portion of thearchitecture – note that the integratormay have cores with completearchitectures and may have someportions of completely described HDL;


Peer Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

a valid IJTAG Description mayjust include the Level-0 Gatewayand all subsequent connectionsdown to the individual instruments;

a complete IJTAG Description mustinclude a description of the controller


Peer Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

The Controller may be generatedby the integrator or by the toolused for insertion;

or it may be an existing Core ordescription generated by an 1149.1JTAG EDA tool;

the controller is added to theexisting IDL+CDL to complete theHDL architecture description


Peer Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

The Chip Provider must evaluatethe final HDL to adjust it to meetthe Proprietary and End-Userneeds – instruments that may beused in ATE Testing, but not inboard-integration or in-systemuse, must be hidden, obfuscated,or removed

Code Examples

What do the code groupings actually look like for these defined Code Blocks?

Note: these examples are ASSET’s working language – not the stuff the 1687 committee is brewing up…

…the key is to make sure the SAME CONTENT exists…the syntax can be changed through a parser


Parent Block

IJTAG Language DescriptionController Block

1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

Instrument MBIST {// the Raw Instrument Description InstrumentAttributes { IType Test {// Others: Functional, Debug, Monitor Category BIST {// Others: Monitor, Self-Repair Class Memory {// Others: Digital, Analog, etc... SubClass SRAM;// Others: DRAM, FLASH, } Complexity Simple;// Others: Combin| Seq } } } Signals { In CLK { SType Clock; } In ON { TAM; SafeValue 0; SType Control; } In CACHE_RST { TAM; SafeValue 0; SType Control; } In BIST_RST { TAM; SafeValue 0; SType Control; } In FREEZE { TAM; SafeValue 0; SType Config; } Out DONE { TAM; SType OpStatus; PIO_Access } } Static_Dependencies {// signal dependencies like Oes In OE { TAM; SafeValue 0; Stype Config; DONE/Z} } PDL MBIST; // link PDL file or declared methods here}

Parent Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

PDL MBIST { // the Protocol or Pattern Description Method Reset { apply { "TAM" = 0*; } apply { RESETS = 00; } apply { RESETS = 11; } apply { RESETS = 00; } } Method Start_MBIST { apply { ON = 1; } } Method Get_Status { read { DONE; FAIL; } }}



Parent Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

Interface MBIST_P1687 { // Instrument Interface Signals { In TDI { ScanIn; } Out TDO { ScanOut; } iBit bit[35..0]; Out DONE { PIO_Access; } }

InterfaceAttributes { // OPTIONS: Access Serial {} and/or Access Parallel {} Access Serial { // TapCompliant True; // OPTIONS: True | False TapMode Synchronous; } } BitOrder {// "MSB" = bit nearest TDI iBit bit[0] { BitType II_1; Write FREEZE; } iBit bit[1] { BitType II_1; Write ON; } iBit bit[2..33] { BitType II_0; Read DOUT[31..0]; } iBit bit[34] { BitType II_0; Read DONE; } iBit bit[35] { BitType II_2; Write EMODE; Read FAIL; } }}


Parent Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

From_Output <=> To_Input or List of To_Inputs

Parent Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

PIO_Access_Encodings {// dealing with direct IO pins Signals { Out DONE; In Breakpoint; In Breakpoint_2; In Toggle_Signal; In CLK { Clock; } In TCK { Clock; } } Encoding Bkpt_Stop_Enable { 0 => Breakpoint <=> NULL; 1 => Breakpoint <=> Instrument GL0.GL1.MBIST_1.MBIST.Bkpt_Stop }}


Parent Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

Gateway "1.c.b_part1" { // Gateway Instance Signals { In TDI { ScanIn; } Out TDO { ScanOut; } iBit bit[1..0]; In RESET { RESETN; } In Capture { CaptureEN; } In Shift { ShiftEN; } In Update { UpdateEN; }} BitOrder { iBit bit[0] { BitType SIB { Interface "1.c.b.a1" = MBIST; Interface "1.c.b.a2" = MBIST; } } }}


Parent Block


1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

Tap_Connection My_Chip { // My_Chip is Entity Name Instruction "GWEN1" { GDR GW1[2..0] = TDR gateway_1[2..0]; GDR GW1.2.WSIo <=> Gateway 1.TDI; GDR GW1.2.WSOi <=> Gateway 1.TDO; } Instruction "GWEN2" { GDR GW2[1..0] = TDR gateway_2[1..0]; GDR GW2.1.WSIo <=> Gateway 2.TDI; GDR GW2.1.WSOi <=> Gateway 2.TDO; }}


An Alternate View – Instructions

An alternate view is that there is no specific Hardware Description, but a map of Instructions – this view requires only the scanpaths to be described (since they are variable and not fixed by the Standard)

Different Users may get benefit from different representations:• Design Verification; ATE Test; Board Test; Yield-Analysis; In-System Test

There are two basic types of Instructions in the 1687 architecture:• Those that configure and control the Access Mechanism or Architecture

Configuration (e.g. ScanPaths, Gateways) – Gateway Registers can be viewed as Distributed Instruction-Registers

• Those that configure and control the Instrument Interface – the Instrument-Interface Register can be viewed as Data-Registers

• Note: the Instrument itself is outside of the Standard since it is not specified or standardized by the 1687 Standard


Parent Block

IJTAG Language Alternate View

Controller Block

1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

The Instruction View:Instruction {// INSTRUCTION REG | BIT ENCODING | INSTRUCTION NAME [TARGET REG]// ----------------+--------------+------------------------GW1.Bits[3:0]{ <= encoding[011X] = Select[GW2] // 2 instructions enable gateway reg2 <= encoding[1000] = Select_NO_Update[GW2] // select but block updates <= encoding[1001] = Select_NO_Capture[GW2] // select but block captures }GW2.Bits[1:0]{ <= encoding[00] = Bypass_IInterface_5[IIF5] // close SIB for IIF_5 <= encoding[01] = AddPathSelect_IIF_5[IIF5] // open SIB and Select <= encoding[11] = Clamp[II5] // update, hold data, & close SIB }GW2.Bits[2]{ <= encoding[0] = Bypass[GW3] // Close the SIB for GW3 <= encoding[1] = AddPathSelect[GW3] // Open SIB and Select GW3 }}The PDL could be as simple as:INSTRUMENT-INTERFACE | DATA---------------------+---------------------IIF5 <= DATA=[01001001001]


Parent Block


Controller Block

1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

The Instruction View – reduces the language to:

The Controller BlockThe Instrument BlockThe Instrument-Interface BlockThe ScanPath/DataPath Connectivity BlockThe Instruction BlockThe PDL Block


Parent Block


Controller Block

1149.1TAP Link

Level-n GWBlock

GW1

GW2

GWn

InterfaceBlock

WRAP

InstrumentBlock

LEAF

InterfaceBlock

WRAP

InstrumentBlock

LEAFI/O Pin Block

Pin A

Pin B

Pin n

PDLBlock

Method1

Method2

Methodn

PDLBlock

Method1

Method2

Methodn

The Gateway Instructions

• Gateways are Distributed Instruction Registers andcan only do a finite number of things:

• OpenScanPath-CloseScanPath• Modify a ScanPath (scan path branching/muxing)• Modify another Register’s Actions (e.g. deny Capture)• Configure another Register (e.g. put in Parallel mode)• Connect a Register to IO Pins

We’re almost there…

Only a few hundred more slides to go…

Just Kidding!

What’s Left to Define?

Which Code blocks are optional? Which are required?• Is a Gateway Level-0 Block required – if there are only a few

instruments, can their Instrument-Interfaces (TDRs) be accessed directly from TAP Instructions?

What Keywords are associated with each Code Block?• Are blocks defined by Keywords such as Instrument, Interface,

Controller, etc.? What are the “legal” groupings of Code Blocks? For example:

• More than one Controller Block?• A Controller Block connected directly to an Instrument Interface with

no Gateway Blocks?• PDL as a separate file or PDL embedded within the Instrument Block?• Mixed Gateway and Instrument-Interface Blocks?

Have we defined all of the HW elements (GDR, IIF, Pins, etc.)? Can 1687 concepts be applied above the chip? (Dot-2)

• Board-Level clock/power domains break daisy-chain connections• Test-Scheduling including multiple chips break star connections

IJTAG Automation Landscape

DesignModeling &Synthesis

DesignVerification

Gate-LevelAnalysis

StructuralVerification

CoreAcquisition

& Integration

PhysicalLayout &Routing

VectorGeneration

& Test

In-SystemOperation

Debug &Diagnosis

Existing Instruments

Described with 1687 Language file

Existing Instruments

Described with 1687 Language file

Concept of PublicInstruments vs

Private Instruments

Concept of PublicInstruments vs

Private Instruments

EDA Generation ofInstrument Interfaces &

Connectivity to Gateway

EDA Generation ofInstrument Interfaces &

Connectivity to Gateway

Automation of 1149.1 JTAG Protocol Vector Generation to Access

Instruments

Automation of 1149.1 JTAG Protocol Vector Generation to Access

Instruments

Real-Time Generation of 1149.1 JTAG Protocol Vectors

to Access Instruments

Real-Time Generation of 1149.1 JTAG Protocol Vectors

to Access Instruments

Architectural Exploration of

Instrument Connectivity vs Tradeoffs

Architectural Exploration of

Instrument Connectivity vs Tradeoffs

Verification and Simulation of Instrument Interfaces and Gateway

Connectivity

Verification and Simulation of Instrument Interfaces and Gateway

Connectivity

Automated Data Analysis Processes for Debug, Diagnosis, and

NTF

Automated Data Analysis Processes for Debug, Diagnosis, and

NTF

Generation of 1687 Description Language File and

Assessment of 1687 Compliance

Generation of 1687 Description Language File and

Assessment of 1687 Compliance

Concept ofInstrument

Provider

Concept ofInstrument

Provider

Concept of DeliveredReUse Vectors

Concept of DeliveredReUse Vectors Insertion and connection of

Physical Layout Instruments such as Proc-Mons

Insertion and connection of Physical Layout Instruments

such as Proc-Mons

Perception of Provider – Rollup

Potential Product Descriptive Name EDA SWJTAG

HW/SW ATE HW In-House SW Other

Roll-Up 1-to-5 1-to-5 1-to-5 1-to-5 1-to-5

IJTAG Insertion & Verification 1.13 2.38 4.71 2.43 2.75

Instrument Modification 2.13 3.43 4.71 1.89 2.00

Instrument Library & Insertion 1.75 3.13 4.57 2.25 1.60

IJTAG Architecture Trade-Off Analysis 1.25 2.29 4.17 3.17 2.20

Instrument Mapping and Cataloguing 2.29 1.63 4.00 2.67 1.75

Vector Reuse and Modification 1.88 2.17 3.29 2.63 2.00

Test Scheduling Analysis 2.71 1.88 3.14 2.43 2.50

Power Characterization 1.86 2.86 3.43 2.29 2.75

Timing Characterization 1.86 3.17 3.13 2.43 2.75

External Interface BIST 2.50 2.14 4.17 2.00 2.25

Internal Interface BIST 2.17 2.17 4.17 2.17 2.25

Debug Translator 3.00 2.00 3.33 2.43 2.40

Scan Compression Diagnostics 1.11 3.00 3.63 3.14 3.25

Scan Dump Analysis 2.00 2.86 3.38 2.57 2.00

MBIST Diagnostics 1.75 3.00 3.86 1.63 3.00

NTF Diagnostics 1.75 2.17 2.71 2.50 2.50

Protocol-Based Test 3.00 1.71 3.17 2.71 2.50

#1's #2's #1-Ties

Design-SideComplement

Accesss &Operation

DataCollection& Analysis

Rollup from 20 Industry Thought Leaders

The Identification of Tools and their perceived providers in the marketing survey

Partnering Opportunities

Summary-Conclusions

Several Companies are already implementing IJTAG Concepts• They’ve already run into the “volume of instruments” problem• They are beginning to merge DFT, DFD, DFY into Design-for-Access• They are already having “efficiency” and “scheduling” problems• Some companies are struggling with SIP and 1149.1 inadequacies

The concepts presented have been filtered through real designs and tradeoff criteria• Separation of 1149.1 and P1687• The Gateway; various budget-based connectivity schemes• Instrument Interfaces; parallel data transfers, instrument-coordination• Architecture implementation seems complex but is actually very simple

The committee work now is focused on Language:• Describe the architecture (instrument interfaces, Gateways, TAP)• Describe instrument modes or features• Generation and Retargeting of vectors

We’re not done yet – keep clicking…

To Finally Answer Ken Parker’s Question…

How does this chip stuff ever help me and board test…

Gateway-1



Gateway-1.c



Gateway-1.c.b






1a

1b

1aa

1ca

1cc

1cbc

1cbb

1cba1


IndividualLeafCell

InstrumentInterface

CompoundGateway


Gateway



Gateway-2


2c

TAP IRWith

GWENs


1cba2



andGateway

TCK

TMS

TAP SM

TAP IR

TDI

TDO

JTAG Regs

BSDLDescription

a

b

c

a

b

c

a

b

c

123456a

a

b

cd

Gateways can produce“Add_Scan_Path”,

“Bypass_Other_Register”,“Configure_Other_Register”,“Modify_Register_Actions”,

and “Connect_IO_Pins”types of Instructions

The Instruction View:

INSTRUCTION REG | BIT ENCODING | INSTRUCTION NAME [TARGET REG]----------------+--------------+------------------------GW1.Bits[3:0]{ <= encoding[011X] = AddPathSelect[GW2] <= encoding[1000] = Select_NO_Update[GW2] <= encoding[1001] = Select_NO_Capture[GW2] }GW1c.Bits[1:0]{<= encoding[00] = Bypass_IInterface_5[IIF5] <= encoding[01] = AddPathSelect_IIF_5[IIF5] <= encoding[11] = Clamp[II5] }GW2.Bits[2]{ <= encoding[0] = Bypass[GW3] <= encoding[1] = AddPathSelect[GW3] }

PDL MBIST { // the Protocol Description Method Reset { apply { "TAM" = 0*; } apply { RESETS = 00; } } Method Start_MBIST { apply { ON = 1; } } Method Get_Status { read { DONE; FAIL; } }}

Relating TDO Data to Instruments

TDO<0100111010001111010101100110010101001001001001…>Scan Out #54: 196 bits

#3LBIST

Instrument #4Bus Data

What Data is Related?Core PartitionScan StructuresBit Definitions

What Data Mining is Required?Pattern/Chain/Bit by ATPG ToolConversion of Data to FailsFrequency of Test by STA Tool#of Toggles/Activity by Power Tool

What Data is Related?Memory TypeMemory SizePhysical Scramble Table

What Data Mining is Required?Row/Column by Bit-Mapping ToolAddress/Data by Logic-Decode ToolFrequency of Test by Timing Tool#of Toggles by Power Tool

Instrument #1MFG Scan Data

Instrument #2MBIST Data

Chip 1 Chip 2

Chip 3

Chip 5

Chip 8

Chip 7

Chip 6

Hierarchy Lev-0

Chip 9

The Board World Tomorrow???

Chip 4

TAP at BoardConnector

TCK

TMS

TDI

TDO

BSDL+HDLDescription


ChipDesign


ChipDesign


ChipDesign


ChipDesign


ChipDesign


ChipDesign


ChipDesign


ChipDesign


ChipDesign

Daisy-ChainedChips

a

b

TAP C.

1687 Type SIB canbe used as a 1-bit

board bypass

Chips in a PowerDomain can be shutoff completely withoutimpacting other scanchain – when on,scheduling is possible

Features inside of chipscan be used to test andcharacterize board-levelissues

Hierarchy Lev-1 Hierarchy Lev-2

Sample Instruction ListChip1-Extest<0000>Chip2-Sample<110Chip3-Bypass<01101>Chip2-Clamp<010>Chip8-Intest<00110101>Chip4-MBIST: TAP-IR<11100>

GW0[a].IIF1[0..3]<0101>

Chip5-ScanDump:TAP-IR<0011>

GW0[a].IIF5[0..5]<11011>

Chip7-BERT: TAP-IR<1XXX>GW0[b].IIF1[2]<1>

Secret Sauce is theTAP Synchronization

A Chip with Multiple SIBs couldaddress chips individually to

enable only those needed for aparticular test or function

P1687 2008 Update: The Whole Story The IJTAG Features and Capabilities Alfred L. Crouch Chief...

Documents

Transcript of P1687 2008 Update: The Whole Story The IJTAG Features and Capabilities Alfred L. Crouch Chief...