IEEE P1687 (IJTAG) Status

Transcription

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

2 IEEE-SA Standards Board Bylaws on Patents in Standards 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. Slide #1 Approved by IEEE-SA Standards Board March 2003 (Revised March 2005)

3 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 patcom@ieee.org or visit This slide set is available at Slide #2 Approved by IEEE-SA Standards Board March 2003 (Revised March 2005)

4 P1687 Executive Summary IJTAG -> P1687 official Framework: complete Sub-groups: in progress Spec: started; waiting on architecture decision Decisions pending: Hub architecture Procedural language Architectural Descriptions [BSDL] Interface Handoff [HUB] Procedure Descriptions [API]

5 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

6 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

7 Basic P1687 Questions and Answers! What is P1687? IEEE P Draft Standard for Access and Control of Instrumentation Embedded Within a Semiconductor Device! How does it work? P1687 will provide standardized procedural access to make on-chip test & debug features available! Why do we need it? To enable use and re-use of DFT features at all stages of product life cycle

8 IEEE P1687 Scope Topic: Access to on-chip instrumentation (not the instruments themselves) Elements: 1) Description language for characteristics of instruments 2) Protocol language for communication with instruments 3) Interface methods to instruments

9 TAP Access to Chip Test Features Power management Clock control Chip configuration Memory test Scan test Logic BIST Debug/diagnosis PLL control Reduced pin count test Fault insertion Embedded instruments B S R TAP Wrapped core Interface BIST LBIST CNTL BSR Scan chain Core logic Scan chain Interface BIST BSR SRAM MEMBIST B SerDes BERTS SerDes BERTR SerDes BERT SerDes BERT

10 P1687: TAP-based Access to Test Features Desc Lang ATE, system, remote up/asic/assp/fpga Internal test features (BIST, DIAGs, instruments, etc.) Scan chains IEEE TAP Standard Protocol Test Data Hand shake Internal interface High band width Latest Protocol

11 3 Pillars of P1687 Architectural Descriptions [BSDL] Interface Handoff [HUB] Procedure Descriptions [API]

12 Subgroups, Owners, and Relationships Targets Mike L., Bill TAP architecture Ken handshake scope instructions Overlap Ben, Mike R. language1 language2 Data architecture Bill interoperation sync, schedule Comm architecture Al Nexus parallel Instruments Procedures syntax Jeff Jason

13 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

14 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)

15 P1687 BSDL Attribute Proposals Instrument definition attribute INSTRUMENT_DEF of <device name>: entity is "Core1 IP1," & "Core2 IP1"; Chain definition 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)"; Register access attribute REGISTER_ACCESS of <device name> entity is: "Chain1 (MEMTST1)," & "Chain2 (MEMTST2)";

16 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

17 API = Application Program Interface! Software terminology: (from 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.! 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

18 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}

19 P1687 Spin on API Definition 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. Translation to test vocabulary: 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.

20 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

21 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?)

22 P1687 Static Test Assembly Flow Test program calling IP procedures (your favorite language) IP procedures (reg read/writes) JTAG-based test assembler Scanpath configuration Stream of TAP instructions/data

23 P1687 Interactive Test/Debug Env IP procedures (register read/writes) JTAG interface DLL / API Interactive program calling IP procedures in terms of JTAG interface box API Chip/Board/Sys scanpath configuration (stream of TAP instructions/data) Chip/Board/System JTAG connection

24 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

25 (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

26 Original Idea : TDR-based access TDI TDO TCK TMS TAP1 SO_A1 SI_A1 SI_B1 SO_ B1 scan chain A1 Instrument A scan chain B1 Instrument B chip

27 (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

28 Next Idea : TDR + I/O + Polling signals TDI TDO TCK TMS TAP1 SO_A1 SI_A1 SI_B1 SO_ B1 scan chain A1 Instrument A REQ scan chain B1 Instrument B ACK some interface chip Note: REQ == start ACK == done

29 P1687 Hub for I/O Interface Handoff

30 (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

31 What is a Hub? A B C HUB D E F HUB: central location enabling communication between endpoints

32 What is a P1687 Hub? TAP I/O #1 I/O #2 P1687 HUB Inst #1 Inst #2 Inst #3 P1687 HUB enables communication between I/Os and instruments

33 HUB Idea TDI TDO TCK TMS Sync TAP1 Int some interface HUB Registers for A1 Instrument A Sync Status Registers for B1 Instrument B chip

34 Scalable P1687 HUB Proposal simple Hub-less TDR interface Hub-less TDR interface with Phy & Asyncs Hub with one instrument Hub with two instruments Hierarchical Hub & Sub-Hubs complex

35 Hub-less P1687 Interface JTAG TAP JTAG SDR JTAG SDR JTAG SDR Config Reg Status Reg Data Reg Simplest 1687 Interface Instrument

36 Hub-less P1687 IF w/ Phy + Async Sigs JTAG TAP Other Phy JTAG SDR JTAG SDR JTAG SDR Hand- Shake Sync Int iclk Config Reg Status Reg Data Reg Instrument

37 Hub: One Instrument, One Phy JTAG SDR JTAG TAP JTAG SDR JTAG SDR Other Phy Hand- Shake Sync Int iclk 1687 Client-side interface HUB Config Reg Status Reg Data Reg Interface side Instrument side 1687 Host-side interface Config Reg IF Status Reg IF Data Reg IF iclk Sync Int Hand- Shake Config Reg Status Reg Data Reg Instrument

38 Hub with Two Instruments JTAG TAP Other Phy JTAG SDR JTAG SDR JTAG SDR Hand- Shake Sync Int iclk Config Reg Status Reg Data Reg Config Reg IF Status Reg IF Data Reg IF Config Reg IF Status Reg IF Data Reg IF iclk Sync Int Hand- Shake iclk Sync Int Hand- Shake Config Reg Status Reg Data Reg Config Reg Status Reg Data Reg Instrument Instrument

39 P1687 Interface Hierarchy TAP 1687-host 1687-client 1687-client 1687-host 1687-client 1687-host 1687-client P1500 WIP 1687-client

40 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

41 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

42 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

43 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

44 BACKUP SLIDES! Case studies for P1687 Memory Array BIST High-speed serial I/O PRBS testing State dump for logic analysis

45 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

46 Memory BIST Procedure! Function declaration! Function body! e.g. : int run_mbist_ram256x32sp(int repair_enable, int background); int 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; }

47 HSIO BERT Procedure! Function declaration! e.g. : int run_bert(int TX, int RX, int rate, int prbs_polynomial);! Function body int 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; }

48 Scan Dump Procedure! Function declaration! Function body! e.g. : int dump_scan (int sp_num); int dump_scan(int sp_num); { stop_clocks(); select_scanpath(sp_num); DR_SCAN(); }