Presentation is loading. Please wait.

Presentation is loading. Please wait.

P1687 2008 Update: The Whole Story The IJTAG Features and Capabilities Alfred L. Crouch Chief Technologist & Director of IJTAG R&D Vice-Chair IEEE P1687.

Similar presentations


Presentation on theme: "P1687 2008 Update: The Whole Story The IJTAG Features and Capabilities Alfred L. Crouch Chief Technologist & Director of IJTAG R&D Vice-Chair IEEE P1687."— Presentation transcript:

1 P Update: The Whole Story The IJTAG Features and Capabilities Alfred L. Crouch Chief Technologist & Director of IJTAG R&D Vice-Chair IEEE P1687 “IJTAG” Working Group BTW – Sept 2008Crouch

2 The Current Committee Active 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) – 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 Horse designed 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

3 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

4 P Update: The Whole Story – Part 1 The IJTAG Features and Capabilities The Instrument and Hardware Portion Alfred L. Crouch Chief Technologist & Director of IJTAG R&D Vice-Chair IEEE P1687 “IJTAG” Working Group BTW – Sept 2008Crouch

5 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 P will stipulate the 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)

6 What Problem Does IJTAG Solve?  IJTAG solves two main problems: 1.Specifying how to Include embedded logic not meant for board test under the TAP and TAP Controller without causing problems with Compliance o Clogging up the BSDL with non-board test content – higher probability of bad BSDL o Badly or inadequately describing complex instruments o Growing the Instruction Register with tens, hundreds, or even thousands of instructions o 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 chips o 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 Instruction Register

7 Test Access Port Standard JTAG Flow-Through Model TCK TMS TDI TDO XTRST Instruction Register (IR)N Test Data Register (TDR)Bypass Register (BYP)ID-Code Register (IDC)Boundary Scan Register (BSR) TAP Controller State-Machine[4] Compliance Enable 1.TAP 2.TAP Controller 1.SM 2.IR 1.Instructions 2.Decode 3.Bypass 4.½ Cycle-Adj 3.Registers 4.BSDL Decode Z Today, 1 Instrument usually = 1 TDR + at least 1 JTAG Instruction

8 TAP State Machine Test Logic Reset 0 1 Run Test Idle 0 1 Select Data Register 1 0 Select Instruct Register 1 0 Update Data Register 1 0 Update Instruct Register 1 0 Capture Data Register 0 1 Capture Instruct Register 0 1 Exit 1 Data Register 0 1 Exit 1 Instruct Register 0 1 Exit 2 Data Register 1 0 Exit 2 Instruct Register 1 0 Pause Data Register 1 0 Pause Instruct Register 1 0 Shift Data Register 0 1 Shift Instruct Register 0 1 Legal Sequences: those allowed by the compliant 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

9 The IJTAG Differences TAP & TAP Controller JTAG Zone Small Instruction Register All Items Described in BSDL Keeps JTAG Logic Simple and Compliant – only addition is Instruction to small IR to select Gateway Register Instruments P1687 IJTAG Zone Instrument Control Connections Instrument Data Connections All Items Described in “HDL/PDL” Allows complex instruments to be described and to include the extra information needed that would complicate BSDL GATEWAYREGGATEWAYREG The Gateway Register is a TDR-like structure existing in both sides

10 Supports P1687 by…  By including a TDR called a Gateway and an instruction (GWEN: GateWay ENable) to select it in the Instruction Reg; to describe the Gateway in the BSDL TDI IR BYP Gateway BSR IDCode TDO GwenGwen WSOi WSIo All inside the box described in the BSDL HIPenHIPen Min Fixed Length & Private for BSDL

11 The Gateway Select-Instrument-Bit (SIB) TDI Shift-Update Cell used as a SIB Sel_i TCK U TDO WSOi WSIo SC The HIP The Hierarchical Interface Port (HIP) opens up a connection to embedded instruments when an Assert value is placed in the U-Cell after a TAP State- Machine Update-DR action The Sel_Instrument Signal is used to gate the ShiftEn, CaptureEn, UpdateEn, and if needed, the TCK signal of the target register to enable the register if selected and to 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

12 1687 Hardware Architecture TCK TRST* TMS TDI TDO WSI WSO A Gateway Interface Register JTAG TAP Master Controller TAP-IR[n:0] A B C D E F G H THE VIEW FROM THE TAP All Activity in the 1687-Zone is a DR-Scan from the TAPs Point-of-View In-Line Instruments This Hierarchy Thread inserts from WSIo-to-WSOi of the Gateway-A SIB Zone P1687-Gateway HIP 1687-Only-Zone Instruments connected to the Gateway may be connected in several different schemes: 1.Flat – one gateway-bit is connected to one instrument 2.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 is connected to a serial string of instruments that insert into the TDI-TDO path as they are activated 5.Hierarchy – one gateway-bit is connected to an instrument that may support further hierarchical connections The 1687 Zone is accessed by opening up Scan Paths to Embedded Instruments

13 1687 Hardware Architecture TCK TRST* TMS TDI TDO WSI WSO JTAG TAP Master Controller TAP-IR[3:0] A B C D E F G H THE VIEW FROM THE TAP This Hierarchy Thread inserts itself from the WSIo to the WSOi of the Gateway-A SIB WSI WSO This Hierarchy Thread inserts itself from the WSIo to the WSOi of the Gateway-E SIB 1687-Only-Zone Zone Example of In-Line Instruments opening up Hierarchical Connections to other Instruments WSI WSO WSI WSO WSI WSO 12 Gateway SIB Bits may be used within Scan Paths to open new Scan Path Hierarchies

14 1687 Hardware Interfaces: 1687 Starts at GW WSI WSO A B C D E F G H THE VIEW FROM THE CONTROLLER This Hierarchy Thread inserts itself from the WSIo to the WSOi of the Gateway-A SIB WSI WSO This Hierarchy Thread inserts itself from the WSIo to the WSOi of the Gateway-E SIB Gateway is beginning of Only-Zone Example of use of a non-compliant TAP and TAP-Controller or other State-Machine Gateway may be TDR-like or 1500-TAM-like WSI WSO WSI WSO WSI WSO 12 Update-En Serial-Out Shift-En Capture-En Reset TCK Example of Signals Required to operate a 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

15 Basic 1687 Hierarchy Description Signals defined by Allowed Hierarchical Level and Node Boundaries: Basic Minimalist Structure - The General Case Level of HierarchyRoot (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) PortListLeftRightLeftRightLeftRightLeft Clock TCKto_TCKTCKto_TCKTCK Control TMS TRSTN to_ResetNResetNto_ResetNResetN to_SelectSelectto_SelectSelect to_CaptureEnCaptureEnto_CaptureEnCaptureEn to_ShiftEnShiftEnto_ShiftEnShiftEn to_UpdateEnUpdateEnto_UpdateEnUpdateEn to_SelectLIRSelectLIRto_SelectLIR Data TDIto_ScanInScanInto_ScanInScanIn TDOfrom_ScanOutScanOutfrom_ScanOutScanOut to_DataBitsDataBits from_StatusBitsStatusBits 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 Instrument itself is actually outside of the Standard since we do not Specify it in any way other than requiring Static Signals

16 1687 Instrument Interface Bit Definitions C/SU Combination Status Capture Signal Generation C/S Status Capture SU Signal Generation C/SU Combination Status Capture Scan Path Add-In Read-Write Cell Read-Write Cell* * Require Capture to be only from U-cell output as Self-Check II_1 II_0 II_2 II_3 II_4 WSI WSO A B C D E F G H WSI WSO Sel_WIR HIP Serial-Out Update-En Shift-En Capture-En Reset TCK HIP_En Select Serial-In C/SU Combination Self-Checking Signal Generation Read-Write Cell with 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

17 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?

18 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  …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?

19 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? 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  And who is supposed to use this stuff anyway?  How does it help board-test?

20 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? 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  How does it help board-test?

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

22 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

23 1687 Flat Example Low-Cell Area Impact High Route-Congestion High-Scan-Path High-Control Wide-IR Shortest Scan-Paths Stable Scan-Path No Concurrency Simple Protocol Simple Description Low Risk 1 TAP Inst. 1. IR maps all Instructions 2. TDI-TDO applied 1-at-a-time FLAT – 1-at-a-Time 1 TAP-IR TAP-SM TDO TDI CTRL Select-Instrument Reset~ CaptureEn ShiftEn UpdateEn Select-WIR TCK

24 1687 Daisy-Chain Example TAP Inst. 1. IR maps all Instructions 2. TDI-TDO to all Instruments even those that are not active Daisy-Chain Low-Cell Area Impact High Route-Congestion High-Control Med-Scan-Path Small-IR Longest-Stable Scan-Path Potential Power Problem All Concurrent Simple Protocol Simple Description High Risk 2 CTRL TAP-IR TAP-SM TDO TDI CTRL Select-Instrument Reset~ CaptureEn ShiftEn UpdateEn Select-WIR TCK 2

25 1687 Star Example TAP Inst. 1. IR maps to Instrument groups 2. TDI-TDO organized by groups Star Inst. Medium Cell Area Impact Med Route-Congestion Low-Scan-Path Medium-Control Med-IR Med-Stable Scan-Paths HW-Fixed Concurrency Simple Protocol Medium Description Medium Risk 3 CTRL TAP-IR TAP-SM TDO TDI CTRL Select-Instrument Reset~ CaptureEn ShiftEn UpdateEn Select-WIR TCK 3

26 1687 Concatenate Example TAP Inst. 1. IR maps all Instruments 2. TDI-TDO to active selected instruments only – similar to daisy-chain but some instruments are bypassed by wires Concatenate CTRL TAP-IR TAP-SM TDO TDI CTRL Select-Instrument Reset~ CaptureEn ShiftEn UpdateEn Select-WIR TCK High-Cell Area Impact Med Route-Congestion Low-Scan-Path High-Control Wide-IR Short Scan-Paths Stable Scan-Path Concurrency-Scheduling Post-Si Flexibility Max- Protocol Medium Description Medium Risk 4 4

27 1687 Hierarchy Example TAP Inst. 1. IR opens Gateway 2. TDI-TDO to SIB only 3. Gateways are distributed instruction registers 4. Non-Selected instruments are invisible Hierarchy CTRL TAP-IR TAP-SM TDO TDI CTRL Select-Instrument Reset~ CaptureEn ShiftEn UpdateEn Select-WIR TCK Medium-Cell Area Impact Low Route-Congestion Low-Scan-Path Low-Control Small-IR Short Scan-Paths Dynamic Scan-Path Concurrency-Scheduling Post-Si Flexibility Max Protocol Medium Description Low Risk 5 5 SIB

28 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) = 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 50 th 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 Test Logic Reset 0 1 Run Test Idle 0 1 Select Data Register 1 0 Select Instruct Register 1 0 Update Data Register 1 0 Update Instruct Register 1 0 Capture Data Register 0 1 Capture Instruct Register 0 1 Exit 1 Data Register 0 1 Exit 1 Instruct Register 0 1 Exit 2 Data Register 1 0 Exit 2 Instruct Register 1 0 Pause Data Register 1 0 Pause Instruct Register 1 0 Shift Data Register 0 1 Shift Instruct Register 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 Access Architecture

29 Tradeoffs vs Connectivity # of Instruments Connectivity <10 <50 <100 <500 >1000 FlatDaisy-ChainStarConcatenateHierarchy One Instrument at-a-time No Concurrence Available Mutual-Exclusive Instructions No Test Scheduling Flexibility Most Routing Impact One Instrument at-a-time No Concurrence Available Mutual-Exclusive Instructions No Test Scheduling Flexibility Most Routing Impact All Concurrent – Most Power One Instruction – Most Risk Minimal Route/Area Impact No Test Scheduling Flexibility All Concurrent – Most Power One Instruction – Most Risk Minimal Route/Area Impact No Test Scheduling Flexibility Pre-Designed Instrument Groups Some Post-Design Flexibility Managed Risk Medium Route/Area Impact Pre-Designed Instrument Groups Some Post-Design Flexibility Managed Risk Medium Route/Area Impact Most Non-Hierarchical Flexibility Most-Instructions (1 per Instrument) Variable Scan-Paths Managed Power – Managed Risk/2 Most Non-Hierarchical Flexibility Most-Instructions (1 per Instrument) Variable Scan-Paths Managed Power – Managed Risk/2 Most-Flexibility Most-Instructions Distributed Instructions Variable Scan-Paths Managed Power/Risk Hidden Instruments Complex Protocol Most Support Logic Most Reusable/Portable Most-Flexibility Most-Instructions Distributed Instructions Variable Scan-Paths Managed Power/Risk Hidden Instruments Complex Protocol Most Support Logic Most Reusable/Portable

30 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 WSP, or the 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

31 The 1500 Connection WBR BYP WIR CDR TDI TDO SWIR 1500 WSP WBR BYP WIR CDR TDI TDO SWIR 1500 WSP WBR BYP WIR CDR TDI TDO SWIR 1500 WSP WBR BYP WIR CDR TDI TDO SWIR 1500 WSP TDI TDO WBR BYP WIR CDR TDI TDO SWIR 1500 WSP BSR BYP TAP-IR TDR TDI TDO SIR TAP Controller SeDR CaDR ShDR E1DR PaDR E2DR UpDR TLR SeIR CaIR ShIR E1IR PaIR E2IR UpIR RTI The use of an Instruction to select the 1500 units in a daisy-chain with a 2 nd Instruction to select the WIRs 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

32 The 1687 Connection WIR | Data | BYP TDI TDO 1687 SIP TDI TDO BSR BYP TAP-IR SIB TDR TDI TDO SIR 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 only the TAP-IR WIR | Data | BYP TDI TDO 1687 SIP WIR | Data | BYP TDI TDO 1687 SIP WIR | Data | BYP TDI TDO 1687 SIP Four 1687 Units with embedded instructions to select Instrument Registers The embedded instrument interface registers are selected by embedded instructions

33 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

34 But “Serial and JTAG-Like” Isn’t Enough!!!  Many have expressed concerned with Bandwidth and non Sequences More instruments means more data – need higher bandwidth for some instruments Coordination between instruments – need instrument-to-instrument communication Non 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)

35 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

36 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

37 The Example TDR: The Serial Operations 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 Parallel 2.Both Input and Output side A Serial Preload SIB Sel/Mode TDI TDO A Serial Read

38 The Example TDR: A Parallel Load S/C Type-B TDR U U U U Inst_Data[0] Inst_Data[1] Inst_Data[2] Inst_Data[3] SIB Sel/Mode TDI TDO Some System Bus Inst_Data /4 Pins/4 IDI This is a PLoad = A Capture

39 The Example TDR: A Parallel Read S/C Type-B TDR U U U U Inst_Data[0] Inst_Data[1] Inst_Data[2] Inst_Data[3] SIB Sel/Mode TDI TDO Some System Bus Inst_Data /4 Pins/4 IDI Some System Bus P_Bus /4 This is a PRead Pins/4

40 The Example TDR: A Write S/C Type-B TDR U U U U Inst_Data[0] Inst_Data[1] Inst_Data[2] Inst_Data[3] SIB Sel/Mode TDI TDO Some System Bus Inst_Data /4 Pins/4 IDI This is a P/SWrite Some System Bus = An Update

41 The Example TDR: A Functional Apply S/C Type-B TDR U U U U Inst_Data[0] Inst_Data[1] Inst_Data[2] Inst_Data[3] SIB Sel/Mode TDI TDO Some System Bus Pins/4 Inst_Data /4 This is a FCN Apply

42 The Example TDR: A Parallel Diagnostic S/C Type-B TDR U U U U Inst_Data[0] Inst_Data[1] Inst_Data[2] Inst_Data[3] SIB Sel/Mode TDI TDO Some System Bus P_Bus /4 Pins/4 This is a Diag P_Bus /4

43 The Example TDR: A Parallel Transfer S/C Type-B TDR U U U U Inst_Data[0] Inst_Data[1] Inst_Data[2] Inst_Data[3] SIB Sel/Mode TDI TDO Some System Bus Inst_Data /4 Pins/4 IDI Some System Bus P_Bus /4 This is a Transfer Inst_Data /4

44 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 ShiftEn Requires mixed instructions; a GW-CLAMP in the TAP – a Select_IO in a Local-IR Most-likely connection for chips that support Boundary Scan TCK

45 I’m Board…  Let’s look at how this impacts the board-level today…

46 Triple-Point Diagram [PVTF] Voltage Temperature Frequency/Process ATE Test Location Board Operation Location Must correlate fails found at Board/System operation to ATE Test to avoid parametric NTF (No Trouble Found or Fail not Repeatable) Must give Silicon Provider fail information in context Silicon Provider must adjust Mfg Process or must adjust test to screen closer to Board/System operation point In a Disaggregated World: must trace Systematic Si problems back to ultimate provider – Si Library, EDA Tool, Core Provider, Chip-Stack, Die-Provider, Design Organization, Mask, Fab, Package… Cost Limits ATE Test to minimum PVTF points

47 1687 Hardware Architecture at the Board Level Architecture Chip-2 GWEN-3 SIB-B TCK TRST* TMS TDI TDO Chip #1 TAP-IR[3:0] Architecture Chip-1 GWEN-1 SIB-B TCK TRST* TMS TDI TDO Chip #2 TAP-IR[4:0] Example of two 1687 Chips in a Daisy-Chain A B C WSI WSO A B C WSI WSO At the Board-Level – the two separate chip 1687 Architectures become one seamless unified Architecture THE VIEW FROM THE BOARD Shows Scalability: Note – concern is mixed-use at board of and P1687

48 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 Path Linking Module Chip 4 TAP at Board Connector Chip 7a Daisy-Chained Chips TCK TMS TDI TDO BSDL Description a b BSDL is sufficient for chip JTAG description and connection Groupings or Star Connections may impose mutual-exclusivity Represents a Black-Box Chip Design There is a need for a simple linear indexing system to map chips Chips need to be described in terms of pins and boundary scan cells Connectivity needs to be understood to deliver vectors to the chips Represents a Black-Box Chip Design Daisy-Chained Chips Chip TDI-TDO connections create the access map and are not required to be identical on all chips Chip instructions are not required to be mapped identically Chip JTAG Instructions Extest, Sample, Preload, HighZ, etc. allow pins to be interconnect tested Inside-the-Chip is generally not known and so is a Black-Box at Board Test Chips are delivered with BSDL Files to describe JTAG features When Chips fail in systems and boards today, they also fail because of environment And parametric margins; not just interconnect or orientation; these fails must be related back to provider Let’s look inside Basic Goal of Board Test: To verify that the correct chips are in the correct spots; the orientation of chips; and the completeness of interconnect; (JTAG) is used on board designs to conduct board test because it can be used without external probing equipment

49 Gateway-1 Gateway/Instrument Interface -1.a Instrument Interface -1.b Gateway-1.c Instrument Interface -1.c.d or 2.b.d Instrument Interface -1.c.a Gateway-1.c.b Instrument Interface -1.c.b.c Instrument Interface -1.c.b.a1 Instrument Interface -1.c.b.b Hierarchy Lev-0 Hierarchy Level-1 Hierarchy Level-2 Hierarchy Level-3 Instrument Interface -1.a.a 1a 1b 1aa 1ca 1cc 1cbc 1cbb 1cba1 Inside-the-Chip Instrument Map Individual Leaf Cell Instrument Interface Compound Gateway MIB- Gateway G1=Default G2=Select Gateway Mutual-Exclusive Gateway (G1 & G2 cannot be selected simultaneously) Gateway-2 Instrument Interface -2.c 2c TAP IR With GWENs Instrument Interface -1.c.b.a2 1cba2 Daisy-Chained Instruments Combination Instrument-IF and Gateway TCK TMS TAP SM TAP IR TDI TDO JTAG Regs BSDL Description a b c a b c a b c a a b c d Instruments need to be described in terms of purpose and attributes Connectivity needs to be understood to deliver vectors to the instruments BSDL is insufficient for instrument description and hierarchy Groupings may be separate IP cores or macros There is a need for an adjustable indexing system to allow mapping Instrument Interfaces may include SIBs and can be classed as Gateways Gateways may be daisy-chained to create Hier-Levels Groupings may be to align use or align latency Gateways enable Hierarchical Connections that allow architectures driven by tradeoffs Instruments are most-likely to be delivered “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-tolerant multi-input connections to minimize broken scan path risk – a multi-scan path shared resource Core Debug Unit MFG Scan Chains Gateways group SIBs and SIBs are dynamic scan path management bits Zone 1687 Zone c/su WSO TDI WSI SEL TDO Gateways can be viewed as distributed instructions that represent “bypass” bits to bypass instruments Instrument Interfaces may be viewed as Data Registers or Instrument Instruction Registers The Handoff between the BSDL Zone and the 1687 description (HDL) is the chip identifiier in the BSDL (Entity); an instruction and the register it selects The Goal: To deliver Static Drive signals and to extract Static Status signals from a Leaf Instrument Node using a JTAG-Operated Open Access Interface

50 P Update: The Whole Story – Part 2 The IJTAG Features and Capabilities The Language and Description Portion Alfred L. Crouch Chief Technologist & Director of IJTAG R&D Vice-Chair IEEE P1687 “IJTAG” Working Group BTW – Sept 2008Crouch

51 Part II: The Description Languages  This Section includes the description, documentation, development and file handoff of the 1687 Architecture

52 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?...

53 Gateway-1 Gateway/Instrument Interface -1.a Instrument Interface -1.b Gateway-1.c Instrument Interface -1.c.d or 2.b.d Instrument Interface -1.c.a Gateway-1.c.b Instrument Interface -1.c.b.c Instrument Interface -1.c.b.a1 Instrument Interface -1.c.b.b Hierarchy Lev-0 Hierarchy Level-1 Hierarchy Level-2 Hierarchy Level-3 Instrument Interface -1.a.a 1a 1b 1aa 1ca 1cc 1cbc 1cbb 1cba1 Inside-the-Chip Instrument Map Individual Leaf Cell Instrument Interface Compound Gateway MIB- Gateway G1=Default G2=Select Gateway Mutual-Exclusive Gateway (G1 & G2 cannot be selected simultaneously) Gateway-2 Instrument Interface -2.c 2c TAP IR With GWENs Instrument Interface -1.c.b.a2 1cba2 Daisy-Chained Instruments Combination Instrument-IF and Gateway TCK TMS TAP SM TAP IR TDI TDO JTAG Regs BSDL Description a b c a b c a b c a a b c d Scan Path Connectivity needs to be documented since it is a non-specified (variable) part of the 1687 architecture Gateways may be viewed as Instruction Registers that hold instructions that control and configure other defined Gateway and Instrument-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 the Attributes of the Instrument need to be documented as part of the SW part of the 1687 Standard (e.g. signal connections) The actual Instrument itself is viewed as being outside of the HW part of the 1687 Standard since it is not being defined or specified by the Standard The Level-0 Gateway is Selected by a TAP Instruction and can be viewed as an offloaded Distributed Instruction Register Instrument Interfaces may be viewed as Instrument Data Registers since they pass only DataBits and StatusBits The Point-of-View: the Scan Paths and Registers are viewed as the Delivery or CDL part; a Leaf Instrument Node is viewed as the IDL part; the CDL part may also be viewed as a data delivery mechanism and a set of Distributed Instruction-Registers The Level-n Gateways, by definition receive their control and configuration (instructions) only from other Gateways

54 Peer Block IJTAG Language Analysis Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn In Terms of Software Code Blocks S S CellDef Block SIB Warning! This stuff is changing as we speak…meetings are being held…skids are being greased… engineers are skulking around in dark corners (uh, different ones than they usually hang around)… crayons are being brought to bear …waitresses are being short-tipped for all day meetings in restaurants…

55 Peer Block IJTAG Language Analysis Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn In Terms of Software Code Blocks S S CellDef Block SIB

56 Peer Block IJTAG Language Analysis Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn In Terms of Software Code Blocks S S CellDef Block SIB A CellDef Block: describes the cells (BitType) similar to the way defined the BC_2; maps available functions to the registers; 1)Shift; 2)Capture/Load; 3)Update/Apply 4)Pause/Hold 5)Set/Reset 6)Open/Close Scan Path

57 In Terms of Software Code Blocks Peer Block IJTAG Language Components Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn A Controller Block: describes operation sequences & signals; holds Instructions to select & configure the access architecture; for dot-0 the defined controller is a compliant TAP Controller; 4 basic items are needed: 1)BSDL Entity; 2)Level-0 Access Instructions; 3)Register selected; 4)TAP Compliance = True or False

58 In Terms of Software Code Blocks Peer Block IJTAG Language Components Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn An I/O Pin Block: Brings chip pins to the Instrument; is most-likely a shared resource (multiple instrument signals will go to the same pin); link from BSDL on chips & HDL; 3 basic items needed: 1)the Pin; 2)the Instrument Signal(s), 3)the IO Enable Instruction(s)

59 In Terms of Software Code Blocks Peer Block IJTAG Language Components Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn A Gateway/Access Block: Holds Architecture Configuration & Control Instructions that are offloaded from the main controller block; basic instruction is to add/remove (open/close) scan paths – this can be viewed as a Bypass action; other instructions can select, configure, and organize the Access Architecture resources or Instrument Interface 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;

60 In Terms of Software Code Blocks Peer Block IJTAG Language Components Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn A Peer Block: Holds multiple instrument and instrument interface rules and information; or multiple Gateways and their peer-to-peer connections; example, 2 daisy- chained elements have individual bits using a shared resource, the priority and encoding can be represented here; only needed when peer-to-peer connections exist

61 In Terms of Software Code Blocks Peer Block IJTAG Language Components Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn An Instrument Interface Block: Includes the Wrapper that provides the registered static signals to the instrument; receives the raw sticky responses from the instrument; viewed as a Data Register or an Instrument Instruction Register; may also include the control or access mechanism selection (serial or parallel)

62 In Terms of Software Code Blocks Peer Block IJTAG Language Components Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn An Instrument Block: Includes the Leaf Instrument declaration and portion of description needed; 1)Instrument attributes 2)the signals; 3)signal direction; 4)signal attributes 5)the link to the Instrument PDL

63 In Terms of Software Code Blocks Peer Block IJTAG Language Components Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn A PDL Block: Includes vector-based procedures or sequences required to configure and operate the instrument; should be independent of the access mechanism (associated to the raw instrument signal interface); PDL can be described as Methods to conduct individual configurations or operations (primitives) or complete tests (complex); Basic PDL is simply: 1)Reads – Read 2)Writes – Write 3)Applies – Apply

64 Peer Block IJTAG Code Block Rules Peer Block Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn Interface Block WRAPWRAP Instrument Block LEAFLEAF PDL Block Method1 Method2 Methodn Level-n GW Block GW1 GWn In Terms of Software Code Blocks One Controller Block per complete architecture (one chip); Multiple controller structures may exist within the Block and their select mechanisms must be described

65 Peer Block IJTAG Code Block Rules Peer Block Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn Interface Block WRAPWRAP Instrument Block LEAFLEAF PDL Block Method1 Method2 Methodn Level-n GW Block GW1 GWn In Terms of Software Code Blocks An Instrument Block may only contain and describe one Leaf Instrument Object An Instrument-Interface Block may only contain and describe one Instrument-Interface Register An Instrument Peer Block is required when more than one Instrument+Instrument-Interface group is under a Gateway and at the same hierarchical level (e.g. a daisy chain of 5 IIFs)

66 Peer Block IJTAG Code Block Rules Peer Block Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn Interface Block WRAPWRAP Instrument Block LEAFLEAF PDL Block Method1 Method2 Methodn Level-n GW Block GW1 GWn In Terms of Software Code Blocks Multiple Gateway Blocks (Level-0 or beyond) may exist per hierarchical level – if more than one block exists, then peer connections must be described A Gateway Block is a Peer block in that it may hold several Gateway Registers at the same hierarchical level and their local connections

67 Peer Block IJTAG Code Block Rules Peer Block Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn Interface Block WRAPWRAP Instrument Block LEAFLEAF PDL Block Method1 Method2 Methodn Level-n GW Block GW1 GWn In Terms of Software Code Blocks Instrument-Interface and Gateway connections are limited to being within the same level of Parent-Child or Peer-to-Peer hierarchy; Only Instrument-Interface to Pin-Map connections can cross hierarchical boundaries

68 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

69 In Terms of Software Code Blocks Peer Block IJTAG Language Components Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn Instruments and PDL are delivered by the IP provider or by the EDA Tool that creates the HDL/RTL and synthesis-timing constraints; the standalone Instrument description (IDL) does not need to contain any connectivity information

70 In Terms of Software Code Blocks Peer Block IJTAG Language Components Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn Gateways, Instrument-Interfaces, and the connectivity architecture are generated by the integrator or by an insertion tool that evaluates tradeoffs and creates an optimal architecture;

71 In Terms of Software Code Blocks Peer Block IJTAG Language Components Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn the integrator or insertion tool adds to the IDL portion of the HDL by describing the CDL portion of the architecture – note that the integrator may have cores with complete architectures and may have some portions of completely described HDL;

72 In Terms of Software Code Blocks Peer Block IJTAG Language Components Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn a valid IJTAG Description may just include the Level-0 Gateway and all subsequent connections down to the individual instruments; a complete IJTAG Description must include a description of the controller

73 In Terms of Software Code Blocks Peer Block IJTAG Language Components Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn The Controller may be generated by the integrator or by the tool used for insertion; or it may be an existing Core or description generated by an JTAG EDA tool; the controller is added to the existing IDL+CDL to complete the HDL architecture description

74 In Terms of Software Code Blocks Peer Block IJTAG Language Components Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn The Chip Provider must evaluate the final HDL to adjust it to meet the Proprietary and End-User needs – instruments that may be used in ATE Testing, but not in board-integration or in-system use, must be hidden, obfuscated, or removed

75 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

76 In Terms of Software Code Blocks Parent Block IJTAG Language Description Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block 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 }

77 Parent Block IJTAG Language Description Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block 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; } } In Terms of Software Code Blocks

78 Parent Block IJTAG Language Description Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block 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; } }

79 In Terms of Software Code Blocks Parent Block IJTAG Language Description Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn From_Output To_Input or List of To_Inputs

80 Parent Block IJTAG Language Description Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block 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 } In Terms of Software Code Blocks

81 Parent Block IJTAG Language Description Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block 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; } In Terms of Software Code Blocks

82 Parent Block IJTAG Language Description Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block 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; } In Terms of Software Code Blocks

83 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

84 In Terms of Software Code Blocks Parent Block IJTAG Language Alternate View Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block 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=[ ]

85 In Terms of Software Code Blocks Parent Block IJTAG Language Alternate View Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn The Instruction View – reduces the language to: The Controller Block The Instrument Block The Instrument-Interface Block The ScanPath/DataPath Connectivity Block The Instruction Block The PDL Block

86 In Terms of Software Code Blocks Parent Block IJTAG Language Alternate View Controller Block TAP Link Level-0 GW Block GW1 GW2 GWn Level-n GW Block GW1 GW2 GWn Interface Block WRAPWRAP Instrument Block LEAFLEAF Interface Block WRAPWRAP Instrument Block LEAFLEAF I/O Pin Block Pin A Pin B Pin n PDL Block Method1 Method2 Methodn PDL Block Method1 Method2 Methodn The Gateway Instructions Gateways are Distributed Instruction Registers and can 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

87 We’re almost there…  Only a few hundred more slides to go… Just Kidding!

88 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

89 IJTAG Automation Landscape Design Modeling & Synthesis Design Verification Gate-Level Analysis Structural Verification Core Acquisition & Integration Physical Layout & Routing Vector Generation & Test In-System Operation Debug & Diagnosis Existing Instruments Described with 1687 Language file Existing Instruments Described with 1687 Language file Concept of Public Instruments vs Private Instruments EDA Generation of Instrument Interfaces & Connectivity to Gateway Automation of JTAG Protocol Vector Generation to Access Instruments Real-Time Generation of JTAG Protocol Vectors to Access Instruments Architectural Exploration of Instrument Connectivity vs Tradeoffs Verification and Simulation of Instrument Interfaces and Gateway Connectivity Automated Data Analysis Processes for Debug, Diagnosis, and NTF Generation of 1687 Description Language File and Assessment of 1687 Compliance Concept of Instrument Provider Concept of Instrument Provider Concept of Delivered ReUse Vectors Insertion and connection of Physical Layout Instruments such as Proc-Mons

90 Perception of Provider – Rollup Potential Product Descriptive NameEDA SW JTAG HW/SWATE HWIn-House SWOther Roll-Up1-to-5 IJTAG Insertion & Verification Instrument Modification Instrument Library & Insertion IJTAG Architecture Trade-Off Analysis Instrument Mapping and Cataloguing Vector Reuse and Modification Test Scheduling Analysis Power Characterization Timing Characterization External Interface BIST Internal Interface BIST Debug Translator Scan Compression Diagnostics Scan Dump Analysis MBIST Diagnostics NTF Diagnostics Protocol-Based Test #1's#2's#1-Ties Design-Side Complement Accesss & Operation Data Collection & Analysis Rollup from 20 Industry Thought Leaders The Identification of Tools and their perceived providers in the marketing survey Partnering Opportunities

91 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 inadequacies  The concepts presented have been filtered through real designs and tradeoff criteria Separation of 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…

92 To Finally Answer Ken Parker’s Question…  How does this chip stuff ever help me and board test…

93 Gateway-1 Gateway/Instrument Interface -1.a Instrument Interface -1.b Gateway-1.c Instrument Interface -1.c.d or 2.b.d Instrument Interface -1.c.a Gateway-1.c.b Instrument Interface -1.c.b.c Instrument Interface -1.c.b.a1 Instrument Interface -1.c.b.b Hierarchy Lev-0 Hierarchy Level-1 Hierarchy Level-2 Hierarchy Level-3 Instrument Interface -1.a.a 1a 1b 1aa 1ca 1cc 1cbc 1cbb 1cba1 Inside-the-Chip Instrument Map Individual Leaf Cell Instrument Interface Compound Gateway MIB- Gateway G1=Default G2=Select Gateway Mutual-Exclusive Gateway (G1 & G2 cannot be selected simultaneously) Gateway-2 Instrument Interface -2.c 2c TAP IR With GWENs Instrument Interface -1.c.b.a2 1cba2 Daisy-Chained Instruments Combination Instrument-IF and Gateway TCK TMS TAP SM TAP IR TDI TDO JTAG Regs BSDL Description a b c a b c a b c a a b c d 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; } }

94 Relating TDO Data to Instruments TDO Scan Out #54: 196 bits #3 LBIST Instrument #4 Bus Data What Data is Related? Core Partition Scan Structures Bit Definitions What Data Mining is Required? Pattern/Chain/Bit by ATPG Tool Conversion of Data to Fails Frequency of Test by STA Tool #of Toggles/Activity by Power Tool What Data is Related? Memory Type Memory Size Physical Scramble Table What Data Mining is Required? Row/Column by Bit-Mapping Tool Address/Data by Logic-Decode Tool Frequency of Test by Timing Tool #of Toggles by Power Tool Instrument #1 MFG Scan Data Instrument #2 MBIST Data

95 Chip 1Chip 2 Chip 3 Chip 5 Chip 8 Chip 7 Chip 6 Hierarchy Lev-0 Chip 9 The Board World Tomorrow??? Chip 4 TAP at Board Connector TCK TMS TDI TDO BSDL+HDL Description Represents a Black-Box Chip Design Daisy-Chained Chips a b TAP C Type SIB can be used as a 1-bit board bypass Chips in a Power Domain can be shut off completely without impacting other scan chain – when on, scheduling is possible Features inside of chips can be used to test and characterize board-level issues Hierarchy Lev-1 Hierarchy Lev-2 Sample Instruction List Chip1-Extest Chip2-Sample<110 Chip3-Bypass Chip2-Clamp Chip8-Intest Chip4-MBIST: TAP-IR GW0[a].IIF1[0..3] Chip5-ScanDump:TAP-IR GW0[a].IIF5[0..5] Chip7-BERT: TAP-IR GW0[b].IIF1[2] Secret Sauce is the TAP Synchronization A Chip with Multiple SIBs could address chips individually to enable only those needed for a particular test or function


Download ppt "P1687 2008 Update: The Whole Story The IJTAG Features and Capabilities Alfred L. Crouch Chief Technologist & Director of IJTAG R&D Vice-Chair IEEE P1687."

Similar presentations


Ads by Google