P1687 status VTS06 - IEEE-SA - Working Groupgrouper.ieee.org/groups/1687/P1687_status_VTS06.pdfIEEE...

48
IEEE P1687 (IJTAG) Status Ken Posse, Chairman Al Crouch, Vice-Chairman Jeff Rearick, Editor Ben Bennetts Jason Doege Bill Eklow Mike Laisne Mike Ricchetti May 2, 2006 at VTS Core team:

Transcript of P1687 status VTS06 - IEEE-SA - Working Groupgrouper.ieee.org/groups/1687/P1687_status_VTS06.pdfIEEE...

IEEE P1687 (IJTAG) Status

Ken Posse, Chairman

Al Crouch, Vice-Chairman

Jeff Rearick, Editor

Ben Bennetts

Jason Doege

Bill Eklow

Mike Laisne

Mike Ricchetti

May 2, 2006 at VTS

Core team:

6. Patents

IEEE standards may include the known use of essential patents and patent applications provided the IEEE receives assurance from the patent holder or applicant with respect to patents whose infringement is, or in the case of patent applications, potential future infringement the applicant asserts will be, unavoidable in a compliant implementation of either mandatory or optional portions of the standard [essential patents]. This assurance shall be provided without coercion and prior to approval of the standard (or reaffirmation when a patent or patent application becomes known after initial approval of the standard). This assurance shall be a letter that is in the form of either:

a) A general disclaimer to the effect that the patentee will not enforce any of its present or future patent(s) whose use would be required to implement either mandatory or optional portions of the proposed IEEE standard against any person or entity complying with the standard; or

b) A statement that a license for such implementation will be made available without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination.

This assurance shall apply, at a minimum, from the date of the standard's approval to the date of the standard's withdrawal and is irrevocable during that period.

IEEE-SA Standards Board Bylaws on Patents in Standards

Slide #1 Approved by IEEE-SA Standards Board – March 2003 (Revised March 2005)

Inappropriate Topics for IEEE WG Meetings

• Don’t discuss the validity/essentiality of patents/patent claims

• Don’t discuss the cost of specific patent use

• Don’t discuss licensing terms or conditions

• Don’t discuss product pricing, territorial restrictions, or market share

• Don’t discuss ongoing litigation or threatened litigation

• Don’t be silent if inappropriate topics are discussed… do formally object.

• NO DISCUSSION OF AL’s APPAREL!!

If you have questions, contact the IEEE-SA Standards Board Patent Committee Administrator at [email protected] or visit http://standards.ieee.org/board/pat/index.html

This slide set is available at http://standards.ieee.org/board/pat/pat-slideset.ppt

Slide #2 Approved by IEEE-SA Standards Board – March 2003 (Revised March 2005)

P1687 Executive Summary

• IJTAG -> P1687 official

• Framework: complete

• Sub-groups: in progress

• Spec: started; waiting on architecture decision

• Decisions pending:– Hub architecture– Procedural language

ArchitecturalDescriptions[BSDL]

InterfaceHandoff[HUB]

ProcedureDescriptions [API]

Outline

! Where are we today?

! IEEE P1687 (IJTAG) Background! P1687 BSDL approach! P1687 API approach! P1687 hub approach

! Where are we going?

! Open issues! Discussion

Outline

! Where are we today?

! IEEE P1687 (IJTAG) Background! P1687 BSDL approach! P1687 API approach! P1687 hub approach

! Where are we going?

! Open issues! Discussion

Basic P1687 Questions and Answers

! What is P1687?

! How does it work?

! Why do we need it?

IEEE P1687 -- Draft Standard for Access and Control of Instrumentation Embedded Within a Semiconductor Device

P1687 will provide standardized procedural access to make on-chip test & debug features available

To enable use and re-use of DFT features at all stages of product life cycle

IEEE P1687 Scope

Topic:Access to on-chip instrumentation(not the instruments themselves)

Elements:1) Description language for characteristics of instruments2) Protocol language for communication with instruments3) Interface methods to instruments

TAP Access to Chip Test Features

SRAM

MEMBIST

Interface BIST

Interface BIST

Core logicLBISTCNTL

Scan chain

Scan chain

SerDes BERT

SerDes BERT

SerDes BERT

SerDes BERT

TAP

BSR B

SR

BSR

BSR

Wrapped core

• Power management

• Clock control

• Chip configuration

• Memory test

• Scan test

• Logic BIST

• Debug/diagnosis

• PLL control

• Reduced pin count test

• Fault insertion

• Embedded instruments

uP/ASIC/ASSP/FPGA

IEEE 1149.1TAP

Scan chains

Internal test features

(BIST, DIAGs, instruments,

etc.)

P1687: TAP-based Access to Test Features

Standard Protocol

ATE, system, remote

High band width

Internal interface

Latest Protocol

Handshake

TestData

DescLang

3 Pillars of P1687

ArchitecturalDescriptions[BSDL]

InterfaceHandoff[HUB]

ProcedureDescriptions [API]

Subgroups, Owners, and Relationships

Targets

Overlap

Procedures

InstrumentsComm architecture

Data architecture

TAP architecture

language2language1

syntax

handshake

sync, schedule

Nexus parallel

instructions

scope

interoperation

Ken

Bill

Al

Mike L., Bill

Ben, Mike R.

Jeff

Jason

Outline

! Where are we today?

! IEEE P1687 (IJTAG) Background! P1687 BSDL approach! P1687 API approach! P1687 hub approach

! Where are we going?

! Open issues! Discussion

P1687 BSDL Usage Proposal

• Describe ARCHITECTURE of instruments, not use

• Provides inventory of instrument content on a chip

• Necessary to identify number and location of

instruments

• Not known in advance by instrument IP provider

• Must be assembled in context of chip (like BSR)

P1687 BSDL Attribute Proposals

• Instrument definition

• Chain definition

• Register access

attribute INSTRUMENT_DEF of <device name>:entity is"Core1 IP1," &"Core2 IP1";

attribute CHAIN_DEF of <device name> entity is:// first register in chain is R1 of Core 1 and it is 4 bits

"Chain1 (Core1.R1,4)," & "Chain1 (Core1.R2,4)," &

// first two elements of Chain2 are R1 and R2 of Core2"Chain2 (Core2.R1,4 Core2.R2,4)";

attribute REGISTER_ACCESS of <device name> entity is:"Chain1 (MEMTST1)," &"Chain2 (MEMTST2)";

Outline

! Where are we today?

! IEEE P1687 (IJTAG) Background! P1687 BSDL approach! P1687 API approach! P1687 hub approach

! Where are we going?

! Open issues! Discussion

! Software terminology: (from www.webopedia.com)

! Purpose and benefits of an API:! Re-use: procedures are written once, used many times! Maintainability: procs distributed from single source! Controlled access: interface to DB restricted to API! Security: procedure source code hidden from end user

API = Application Program Interface

Abbreviation of application program interface, a set of routines, protocols, and tools for building software applications. A good API makes it easier to develop a program by providing all the building blocks. A programmer puts the blocks together.

API Elements

! Specification for calling (procedures | functions | subroutines)

! Function name! Type of value returned (if any)! Argument list (if any)

! Argument list must contain types, may contain names

! a.k.a. “declarations” or “prototypes” or “interfaces”! C/C++ examples:

! extern double sqrt(double);! extern char* strcpy(char* to, const char* from);

! Code elsewhere defines the body of the function! The API = {function declarations + library}

P1687 Spin on API Definition

• Translation to test vocabulary:

Abbreviation of application program interface, a set of routines, protocols, and tools for building software applications. A good API makes it easier to develop a program by providing all the building blocks. A programmer puts the blocks together.

A P1687 description is a set of routines, protocols, and descriptions for building test and debug programs. A good API makes it easier to develop a test by providing all the building blocks that describe how to use the capabilities of the components in the system being tested. A test engineer puts these procedures together by calling them from a test program.

IEEE P1687 API Model

! P1687 procedures can be thought of as an API:! Can be called from a variety of higher-level

environments! Delivered as a package by IP provider! Expose only those features that IP provider chooses! Hide low-level details from user

! Layers:1. test / measurement algorithm

2. exported instrument procedures

3. register writes and reads

4. TAP commands

End user

IP provider

Compiler

IEEE P1687 API Implementation Options

1) Description of IP instances in system being tested" Scanpath location of registers used by IP procedures

(BSDL?)" Documentation of instrument functionality and interface

(English?)2) Procedures

a) Function declarations (C?)b) Library containing function bodies (Verilog subset?

STAPL? CTL? C? your_favorite_programming_language?)

P1687 Static Test Assembly Flow

JTAG-basedtest assembler

Test program calling IP procedures(your favorite language)

IP procedures(reg read/writes)

Scanpathconfiguration

Stream of TAP instructions/data

P1687 Interactive Test/Debug Env

Interactive programcalling IP procedures

in terms of JTAGinterface box API

IP procedures(register

read/writes)

Chip/Board/Sysscanpath

configuration

Chip/Board/System JTAG connection

(stream of TAP instructions/data)

JTAG interfaceDLL / API

Outline

! Where are we today?

! IEEE P1687 (IJTAG) Background! P1687 BSDL approach! P1687 API approach! P1687 hub approach

! Where are we going?

! Open issues! Discussion

(Continuing) Evolution of HUB Concept

• Phase 1: simple instrument-to-TAP interface

– Need: spec for standard interface to instruments– Solution: scan-based: TAP TDRs

• Phase 2: higher bandwidth I/O

– Need: hand off data transfer to another interface with higher bandwidth than TAP

– Solution: mux controls to configure I/Os

• Phase 3: instrument intercommunication

– Need: instrument-to-{instrument/ATE} comm– Solution: hierarchical HUB with async signals

Original Idea : TDR-based access

Instrument A

Instrument B

TAP1

chip

TDITDOTCKTMS

scan chain A1

scan chain B1

SO_A1SI_A1

SI_B1 SO_ B1

(Continuing) Evolution of HUB Concept

• Phase 1: simple instrument-to-TAP interface

– Need: spec for standard interface to instruments– Solution: scan-based: TAP TDRs

• Phase 2: higher bandwidth I/O

– Need: hand off data transfer to another interface with higher bandwidth than TAP

– Solution: mux controls to configure I/Os

• Phase 3: instrument intercommunication

– Need: instrument-to-{instrument/ATE} comm– Solution: hierarchical HUB with async signals

Next Idea : TDR + I/O + Polling signals

Instrument A

Instrument B

TAP1

chip

TDITDOTCKTMS

scan chain A1

scan chain B1

SO_A1SI_A1

SI_B1 SO_ B1

some interface

REQ

ACK Note: REQ == startACK == done

P1687 “Hub” for I/O Interface Handoff

(Continuing) Evolution of HUB Concept

• Phase 1: simple instrument-to-TAP interface

– Need: spec for standard interface to instruments– Solution: scan-based: TAP TDRs

• Phase 2: higher bandwidth I/O

– Need: hand off data transfer to another interface with higher bandwidth than TAP

– Solution: mux controls to configure I/Os

• Phase 3: instrument intercommunication

– Need: instrument-to-{instrument/ATE} comm– Solution: hierarchical HUB with async signals

What is a Hub?

HUB

CB

F

ED

A

HUB: central location enabling communication between endpoints

What is a P1687 Hub?

P1687 HUB

I/O #2I/O #1

Inst #3

Inst #2Inst #1

TAP

P1687 HUB enables communication between I/Os and instruments

HUB Idea

Instrument A

Instrument B

TAP1

chip

TDITDOTCKTMS

Registers for A1

Registers for B1

some interface

Sync

Status

HUBSync

Int

Scalable P1687 HUB Proposal

• Hub-less TDR interface

• Hub-less TDR interface with Phy & Asyncs

• Hub with one instrument

• Hub with two instruments

• Hierarchical Hub & Sub-Hubs

simple

complex

Hub-less P1687 Interface

JTAG SDRJTAG SDR

JTAG TAP

Config Reg Status Reg Data Reg

Instrument

Simplest1687

InterfaceJTAG SDR

Hub-less P1687 IF w/ Phy + Async Sigs

Other Phy

JTAG SDRJTAG SDR

JTAG TAP

Hand-

Shake

SyncInt

iClk

Config Reg Status Reg Data Reg

Instrument

JTAGSDR

Hub: One Instrument, One Phy

HUBInterface side

Instrument side

Config Reg IF Status Reg IF Data Reg IF

Config Reg Status Reg Data Reg

Hand -

Sh ake

SyncIn t

iClk

Other Phy

JTAG SDRJTAG SDR

JTAG TAP

Hand-

Shak e

Syn cI nt

i Cl k

Config Reg Status Reg Data Reg

Instrument

1687 Client-side interface

1687Host-side interface

JTAG SDR

Hub with Two Instruments

Config Reg IF Status Reg IF Data Reg IF

Config Reg Status Reg Data Reg

Hand-

Shake

SyncInt

iClk

Other Phy

JTAG SDRJTAG SDR

JTAG TAP

Hand-

Shake

SyncInt

iClk

Config Reg Status Reg Data Reg

Instrument

JTAGSDR

Config Reg IF Status Reg IF Data Reg IF

Hand-

Shake

SyncInt

iClk

Config Reg Status Reg Data Reg

Instrument

P1687 Interface Hierarchy

1687-client

1687-host

1687-client

1687-client

1687-host

1687-client

1687-client

P1500 WIP

1687-hostTAP

Hub Summary & Issues

• Goal: Make the HUB just simple enough

– Enable TAP-based interaction with instruments– Enable high-bandwidth data transfer (optional)– Enable instrument interaction (optional)– Enable cascading hierarchically (optional)

• Status: Closing in on an architecture

Outline

! Where are we today?

! IEEE P1687 (IJTAG) Background! P1687 BSDL approach! P1687 API approach! P1687 hub approach

! Where are we going?

! Open issues! Discussion

Open Issues

• Exact architecture of the Hub– Patent issues: Xilinx ICON & Altera SLD Hub– Mandatory connection to TAP?

• BSDL for architectural description: syntax, specs

• Procedural language choice(s):– Simple stream of register reads/writes?– Full-featured programming language?

• Compliance checking

• HELP!! Staff subcommittees; provide examples

Outline

! Where are we today?

! IEEE P1687 (IJTAG) Background! P1687 BSDL approach! P1687 API approach! P1687 hub approach

! Where are we going?

! Open issues! Discussion

BACKUP SLIDES

! Case studies for P1687

– Memory Array BIST– High-speed serial I/O PRBS testing– State dump for logic analysis

The Need for Case Studies

• A useful standard must pass the “who-cares” test

• The industry is full of embedded instruments

• IJTAG working group is soliciting real examples

– Validate our proposals– Facilitate understanding and adoption

Memory BIST Procedure

! Function declaration! e.g. : int run_mbist_ram256x32sp(int

repair_enable, int background);

! Function bodyint run_mbist_ram256x32sp(int repair_enable, int background);

{start_clock(MCK);done_reg = 0;pass_reg = 0;repair_enable_reg = repair_enable;background_reg = background;start_BIST = 1;

}

HSIO BERT Procedure

! Function declaration! e.g. : int run_BERT(int TX, int RX, int rate, int

prbs_polynomial);

! Function bodyint run_BERT(int TX, int RX, int rate, int prbs_polynomial);

{launch_TX_PRBS(TX,rate,prbs_polynomial);launch_RX_PRBS(RX,rate,prbs_polynomial);

}int launch_TX_PRBS(int TX, int rate, int prbs_polynomial);

{start_ref_clock(TX,rate);prbs_reg[0:7] = dec2hex(prbs_polynomial);select_PRBS_reg = 1;enable_TX_reg = 1;

}

Scan Dump Procedure

! Function declaration! e.g. : int dump_scan (int sp_num);

! Function bodyint dump_scan(int sp_num);

{stop_clocks();select_scanpath(sp_num);DR_SCAN();

}