P1687 status VTS06 - IEEE-SA - Working Groupgrouper.ieee.org/groups/1687/P1687_status_VTS06.pdfIEEE...
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
(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 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;
}