EU Cookie Directive: Please see the following note regarding opting in to the use of cookies for this wiki: EU Cookie Directive

Please Note: You must be logged in to edit this wiki. To login, you must have an account on the SJTAG Forums and have been granted membership of either the Core_WG or the Extended_WG usergroups on the forums. You may then login to the wiki using the same credentials* you use for the forums.

* In some rare cases, it may be necessary to assign a wiki username that is different to your forum username.

Volume 3

From SJTAG
Jump to: navigation, search

Volume 3 - Hardware Architectures Document

Work-in-Progress version: System Architectures

Context

About this Document

This document, Volume 3 of 5 volumes, ...

Documentation Map

Readers seeking further information on specific topics are directed to the following volumes:

  • Volume 1 – Overview
    • Scope of SJTAG
    • Purpose of SJTAG
    • Primary Constraints
    • Relationship to Other Standards
  • Volume 2 – Use Cases
    • Structural Test
    • Configuration/Tuning/Instrumentation
    • Software Debug
    • Built-In Self Test
    • Fault Injection
    • Programming/Updates
    • Root Cause Analysis/Failure Mode Analysis
    • Power-on Self Test
    • Environmental Stress Test
    • Device Versioning
  • Volume 3 – Hardware Architectures
    • Hardware Topologies
    • Device Under Test Connectivity Schemes
    • XBST - External BST
    • Built-in Self-Test
    • In-System Programming/Configuration (ISP/ISC)
    • EBST - Embedded BST
    • Tooling Requirements
    • Conformance Levels
  • Volume 4 – Languages and Data Formats
    • Language Mapping to Circuit Model
    • Role of Languages
    • Dynamic and Static Information
    • Implementation Issues
  • Volume 5 – Business Case
    • Topic 1
  • Abbreviations and Glossary

Quick Terms, Acronyms, Abbreviations, & Concepts Introduction

There are many terms, acronyms, and new concepts that will be introduced

in the course of the Hardware Proposal Summary – the most common and

prevalent ones will be listed and defined here. A full Glossary is included

after the main body of the Hardware Proposal Summary document.


Note: the following style formats are used in this document:


IEEE 1149.1 instructions are written upper case and bold e.g. PRELOAD


IEEE 1149.1 state-machine states are written mixed case and italicized e.g. Shift-DR


Signal names are written mixed case and bold e.g. Select-WIR


Rule directives are written in lower case and bold e.g. requires


ƒIEEE 1149.1-2001: the board-test standard that defines an on-chip testaccess-

port (TAP) of 4, optionally 5, pins and associated signals and

mandatory on-chip logic (Instruction Register, 16-stateTAP Controller, Bypass

Register and Boundary-Scan Register) that is used to verify device

connectivity in the board-environment. The standard is sometimes

synonymously referred to as JTAG.

ƒJTAG: the acronym for the Joint Test Action Group - the group identity used

by the original creators of the 1149.1 standard. JTAG is often used to mean

the 1149.1 standard itself rather than the group of originators.


ƒ1149.1-Zone: the compliant board-test portion of the device that is the

implementation of the 1149.1 Standard and includes all of the required

portions, and may contain some of the optional portions described in the

1149.1 Standard – items such as the 4 or 5 pin Test-Access-Port (TAP), 16-

state TAP Controller, Boundary-Scan Register (BSR), the Bypass Register,

the 1149.1 Instruction Register, and the IDcode Register.


ƒ1149.1-Overlap-Zone: the compliant board-test portion of the device that is the implementation of the 1149.1 Standard when it also includes a 1687 Gateway and the instruction that selects and configures the Gateway.


1149.1-IR: the compliant and defined 1149.1 Instruction Register that supports the defined required and optional Public Instructions – for example,

EXTEST, SAMPLE, PRELOAD, HIGHZ, IDCODE, and CLAMP.


ƒ1149.1-SM: the compliant 1149.1 16-state State Machine that supports a

Test-Logic-Reset state; a Run-Test-Idle state; a Select-DR Scan set of states

that allow DR-Scans; and a Select-IR Scan set of states that allow IR-Scans.


ƒ1149.1 Compatible: any instrument or element that operates using only the

signals and sequences available from a fully-compliant 1149.1 TAP and TAP

Controller.


ƒ IEEE 1500-2005: core-test standard that defines core-test-wrappers and the core test-access-mechanism (TAM).


ƒ TAM: Test Access Mechanism – the connectivity and protocol structure used to access an instrument. For the IEEE 1500, a defined TAM exists.


ƒ WIR: Wrapper Instruction Register – the local instruction register associated with the IEEE 1500 TAM.


ƒ IEEE P1687: the on-chip instrument access and control standard that defines the connectivity and interfaces of embedded instruments other than those associated with 1149.1 that are used for board-test.


ƒ Hierarchical Element: an element is a standalone Test-Data-Register (TDR) or TDR-Bit whose only purpose is to provide a hierarchical connection – there is no other functionality that would classify it as an instrument.


ƒ Instrument: any logic structure within a device with a purpose other than just providing 1687 connectivity that is accessed by the 1687 architecture (connectivity-only is defined as an Element) – instruments can be Design-for-Test (DFT), Design-for-Debug (DFD), Design-for-Yield (DFY), Test, or Functional items.


ƒ Hierarchical Instrument: an instrument that also provides a hierarchical connection by passing on, at a minimum, the Select-Instrument signal and the TDI-TDO serial scan-path which may be referred to, using the IEEE 1500 nomenclature, as the WSI-WSO serial scan-path to distinguish it from the serial scan path in the 1149.1-Zone. Basically, a Hierarchical Instrument provides access to other instruments that do not require a direct IR-Scan.


ƒ DR-Scan: the use of the Select-DR Scan side of the 1149.1 State-Machine – this action is generally associated with accessing or using a targeted TDR.


ƒ Shift-DR: a noted sub-operation of DR-Scan that represents the action of shifting data through the selected Data Register that is connected between the device’s TDI-TDO when the 1149.1-SM is in the Shift-DR state.


ƒ Update-DR: a noted sub-operation of DR-Scan that represents the action of synchronizing all change actions of the target 1149.1 Data Register or 1687 instrument that is active under the current selected instruction when the 1149.1-SM is in the Update-DR state at the falling-edge of TCK.


ƒ IR-Scan: the use of the Select-IR Scan side of the 1149.1 State-Machine – this action is associated with accessing the 1149.1 Instruction Register.


ƒ Test Manager: the term used to describe any combined hardware/software test control system that is used either as a free-standing off-line test program developer and/or as a free-standing or integral on-line runtime controller for UUT test or configuration operations. Free-standing Test Managers are typically PC-based boundary-scan program-development and test-application controller products that provide the ability to generate tests and apply them to the UUT using an external connection to the UUT.

Hardware Topologies

The HW Proposal covers several concepts and described architecture

elements (each described more fully in later sections):


  • The concept of the compliant 1149.1-Overlap-Zone.
  • The concept of 2 Connectivity-Types – Flat and Hierarchical – with:
    • 4 Flat Connection-Schemes: Flat, Daisy-Chain, Star, Concatenate;
    • 3 Hierarchical Connection-Schemes: Replace, Concatenate-Before, Concatenate-After.

There are items discussed at the end of the main body of this document that fall outside of the 4 main sections under discussion, and these topics should eventually be a part of the Hardware Architecture Proposal. However, these items were not detailed in the voting document as anything more than concepts, but are included as items that are identified as being important for a comprehensive architecture consideration.

The 1149.1 Overlap Zones

According to the SJTAG Scope and Purpose, access to the SJTAG portion of the architecture is through an 1149.1 Test Access Port and associated control logic (Instruction Register, State Machine, addressable Test Data Registers, etc.). To this end, there is a need to maintain an efficient and compliant 1149.1 architecture for board-test purposes and SJTAG can not impose any requirements that would result in a non-compliant and non-efficient 1149.1 board-test architecture. The best way to accomplish this is to limit “what of the SJTAG hardware architecture” that the compliant 1149.1 board-test portion must see and describe. Conversely, there is not a need for SJTAG to replicate all items that are already defined and described by 1149.1 in order to be rated as a compliant SJTAG architecture.


This portion of the HW Proposal puts forth the concept that 1149.1 exists; has a defined architecture and instructions; needs to remain compliant in its defined usage-space; and it is mandated that SJTAG does not cause any non-compliance, and preferred that SJTAG does not cause any inefficiencies, to the 1149.1 usage-space:


RULES:


ƒ It is our stated scope and purpose to require use of an 1149.1 compliant TAP

and TAP Controller as defined by 1149.1.


ƒ …with no requirement for 1149.1 to be in a Compliance-Enable mode to use

or access the SJTAG portion of the architecture.


ƒ …with no requirement of using a device supporting SJTAG apart or in isolation

from other devices in a multiple 1149.1 board-test system.


ƒ …with no requirement or allowance of placing other functions, logic or filters

in front of the 1149.1 TAP (external to the device, or between the 1149.1 TAP

and TAP-Controller) for SJTAG purposes.


ƒ …with no requirement to change any element of the publicly described

portions of the 1149.1 standard: the 1149.1 TAP; the 1149.1 State Machine;

the Boundary-Scan-Register (BSR); the Bypass Register; the ID-Code

Register; the Instruction-Register; etc.; the Public Instructions (EXTEST, INTEST, SAMPLE, PRELOAD, IDCODE, CLAMP, HIGHZ, etc.).


ƒ …with a preference that board-test-only instruments (that can be described in BSDL) should be included within the 1149.1-Zone and may be accessed with declared public-instructions or private-instructions.


ƒ …with an acknowledgement that the Overlap-Zone of the architecture is shared by 1149.1 and SJTAG and the dominant considerations of this zone is 1149.1 and so the zone will be described using BSDL as stated in the 1149.1 Standard; connection-schemes will be driven by 1149.1 requirements; and compliance-checking is in compliance with 1149.1 criteria.


ƒ …that SJTAG formally acknowledges that it does not want to replace or re-describe the board-test elements defined in the 1149.1 standard as part of the SJTAG standard (but to reference to 1149.1-2001, for example, as the port, controller, and access to the SJTAG Gateway).


ƒ …that it is preferred that the inclusion of SJTAG features and functions do not make for operation, engineering, or use inefficiencies of the BSDL-described board-test portion of the 1149.1 architecture.


ƒ …that the preferred extent of impact to the 1149.1-Overlap-Zone, by inclusion of 1687 concepts and hardware, will be to place 1149.1-compatible instruments; and/or 1149.1-defined Test Data Registers (TDRs); and/or hierarchy-support elements within the 1149.1-Overlap-Zone that can be described by BSDL.


 …that any of these instruments that enable hierarchical-access (hierarchical access meaning to access other instruments that do not require a direct IRScan) shall be known as Gateway elements.


ƒ …that it is required to add instructions to the 1149.1 Instruction Set for the elements contained within the 1149.1-Overlap-Zone.


ƒ …that it is required that the connectivity of instruments in the 1149.1-Zone be driven by 1149.1 requirements, optimizations, and compliance-checks.


ƒ …that any SJTAG instrument that cannot be described by BSDL should not be directly connected to the 1149.1-IR and should not be allowed in the 1149.1-Overlap-Zone (but should be moved to the SJTAG-Zone) – this includes instruments that may be board-test instruments but can not be described with BSDL.


ƒ NOTE: the SJTAG hardware items in the 1149.1-Overlap-Zone should be the only 1687 instruments that can react to an IR-Scan – all other SJTAG instruments should be accessed, configured, and controlled using only DRScans (Shift-DR and the Update-DR synchronizing events).

Examples & Clarifications:

Text and Figures

Rules:

Text

Device Under Test Connectivity Schemes (Chain Topologies)

Ring Topology

The daisy-chain, or ring architecture is in many ways similar to a standard 1149.1 board level JTAG chain, where all devices in the chain are supplied with a common set of control signals and clock, and a daisy-chained data path between devices. This architecture presents several challenges for the system designer; there are naturally imposed speed limitations in the parallel clock tree, which can be mitigated somewhat by additional buffer circuitry - and the requirement the test clock rate be maintained in accordance with the slowest board in the system. There's is also risk of the data path chain becoming broken when a defective card is placed in the system, or one of the common control signals becoming corrupted for the entire system by a defective card. Additionally, there's a need to devise and implement circuitry or special connectors on the system backplane that allow for routing of the data path signal past non-populated card slots

Advantages to this implementation are reduction or elimination of special SJTAG circuitry for the system cards themselves, but often at the cost of additional test time and data file size required to control multiple cards and coordinate their operation during tests.


Examples & Clarifications:

Sjtag ring topo.jpg

Rules:

Text

Star Topology

In a full radial, or star implementation, each system board has its own dedicated test bus connection to a common system test manager. This has significant advantages in terms of data path fault isolation over the daisy-chain implementation. Additionally, the test manager interface hardware could be designed to allow for multiple test clock speeds, thereby alleviating the requirement of limiting the test clock speed to be compatible with the slowest card contained in the system.

Gains are also noted in terms of possible reuse of data files when implementing board-to-board tests, with interboard synchronization taking place in the software and making best use of the facilities provided by the test manager interface hardware.

The full radial implementation does impose additional routing on the system backplane and require a test manager hardware implementation to allow independent and parallel bus connections to all system cards, as compared to the daisy-chain approach.


Examples & Clarifications:

Sjtag star topo.jpg

Rules:

Multi-drop Architecture

Multi-drop systems require minimal system backplane routing resources, and place minimal restrictions - most notably drive requirements due to the parallel signal connection nature - on the test manager hardware interface. However, multi-drop does complicate the implementation of the various system level boards. A gateway device from the system level test bus to the card level 1149.1 test structures becomes mandatory in such a system; in complex systems with multiple 1149.1 test structures located on each card, the gateway device and path selection device could be a single entity, controlling additionally required hardware overhead.

Clocking and control bus speed limitations are also present in the multi-drop architecture, to the extent that all gateway devices must be in communications and under the control of the test manager to allow for proper system control and synchronization between various system cards. There remains flexibility on the system cards themselves in terms of test interface speed, given this interface resides on the isolated side of the gateway device.

Some multi-drop systems may benefit from additional buffering on the system backplane to mitigate possible speed limitations for clock and data signals.

Examples & Clarifications:

Sjtag multidrop topo.jpg

Rules:

Text

XBST – eXternal BST

Conventional eXternal Test is carried out by applying test stimuli or configuration data to the Unit-Under- Test (UUT) from some external source under the control of an external Test Manager and evaluating the results by observing the response from the UUT and comparing with expected results back at the external Test Manager. The connection between the external runtime-control Test Manager and the UUT can be direct (wired) or remote (wireless) over a communication path such as the Internet.

A “bare-bones” implementation of system-level test using boundary-scan infrastructures would require just some form of backplane access, Ethernet/USB or similar, plus a UUT addressing scheme based on a gateway device per UUT (for multi-drop systems). Everything else would be set up and controlled by an external Test Manager. This scenario, is referred to as eXternal Boundary Scan Test (XBST).

Examples & Clarifications:

Text and Figures

Rules:

Text

Built In Self Test (BIST)

Text

Examples & Clarifications:

Text and Figures

Rules:

Text

In-System Programming/Configuration (ISP/ISC)

Text

Examples & Clarifications:

Text and Figures

Rules:

Text

EBST – Embedded BST

Text

Examples & Clarifications:

Text and Figures

Rules:

Text

Tooling Requirements

ATPG

Language Support

Conformance Levels

Mandatory

Optional

The Loose Ends

This portion of the HW Proposal lists the elements that are not specified by

this proposal, but are items that will need to be considered in the future. It

is expected that these items will be revisited, analyzed and eventually specified as a result of the language effort:


Glossary of Terms, Acronyms, and Abbreviations

There are many terms, acronyms and abbreviations used in this document that may be unfamiliar to the reader. A Glossary organized hierarchically by Standard is provided.


IEEE 1149.1-2001

ƒ the board-test standard that defines an on-chip test-access-port (TAP) of 4, optionally 5, pins and associated signals and mandatory on-chip logic (Instruction Register, 16-state TAP Controller, Bypass Register and Boundary-Scan Register) that is to be used to verify device connectivity in the board environment. The standard is sometimes synonymously referred to as JTAG – see below.


1149.1 Controller: the logic attached to the TAP that includes the TAP State-Machine (1149.1-SM) and the TAP Instruction-Register (1149.1-IR) and its decode logic.


1149.1-IR: the acronym for the 1149.1 Instruction-Register which is a shift register that installs defined public and private instructions on the falling-edge of TCK when the TAP State-Machine is in the Update-IR state.


1149.1-SM: the acronym for the 16-state 1149.1 State-Machine which when coupled with instructions in the 1149.1-IR provides control signals for the connected BSR, Bypass Register, and other TDRs; and for the 1149.1-IR.


Board-Test: the verification that the devices connection to the board is intact by use of on-chip logic that can drive output pins to known logic values; can establish the direction of bidirectional pins; can establish the high-impedance state on three-state pins; and can sample logic values applied to input pins.


Boundary-Scan: the use of a serial scan-shift register called the Boundary-Scan Register (BSR) to provide controllability and observability of device I/O pins.


BSDL: the boundary-scan description-language – a VHDL-based language associated with the 1149.1 architecture that is used to describe all of the features of an implementation of the 1149.1 hardware inside of a device.


BSR: the abbreviation for Boundary-Scan-Register.


Bypass: a single-bit register applied in parallel to the BSR that reduces the device’s scan shift-path to only 1 bit.


Capture-Shift-Update Sequence: three states in the 1149.1 State-Machine involved in a DR-Scan that drives BSR or TDR cells – or involved in an IRScan that drives the 1149.1 Instruction-Register – in direct association with their named actions: Capture allows the cell to observe a signal; Shift allows a cell to pass data from one cell to another cell through a serial shift path; and Update allows a cell to transfer data from the shift path to the parallel output of the cell – this sequence of events is the fundamental basis for how 1149.1 operates.


DR-Scan: the use of the Select-DR Scan side of the 1149.1 State-Machine – this action is associated with accessing and using a targeted TDR.


Shift-DR: a noted sub-operation of DR-Scan that represents the action of shifting data through the defined serial scan-path that is connected between the device’s TDI-TDO when the 1149.1-SM is in the Shift-DR state.


IR-Scan: the use of the Select-IR Scan side of the 1149.1 State-Machine – this action is associated with accessing the 1149.1 Instruction Register.


JTAG: the acronym for the Joint Test Action Group - the group identity used by the original creators of the 1149.1 standard. JTAG is often used to mean the 1149.1 standard itself rather than the group of originators.


Public Instructions: a set of instructions defined in the 1149.1 Standard as being required or optional, but that are fully defined in their operation and the registers they access – the ten public instructions are: EXTEST, SAMPLE, PRELOAD, BYPASS (all mandatory), INTEST, RUNBIST, IDCODE, USERCODE, CLAMP, and HIGHZ (all optional).


TAP: the acronym for the Test-Access-Port, the four (optionally five) dedicated 1149.1 pins and associated signal names: TDI, TDO, TMS, TCK and, optionally, TRST*.


TCK: an 1149.1 dedicated signal, the Test-Clock that synchronizes all 1149.1 actions.


TDI: 1149.1 dedicated signal, the Test-Data-Input that is the beginning of the device’s 1149.1 serial scan-path.


TDI-TDO: the abbreviation for the 1149.1 serial scan-path inside a device from the device’s TDI pin to the device’s TDO pin via either the 1149.1-IR or any one of a variety of 1149.1-TDRs.

TDO: an 1149.1 dedicated signal, the Test-Data-Output that is the end of the device’s 1149.1 serial scan-path.


TDR: the abbreviation for the Test-Data-Register – any serial shift-register that operates in accordance with the 1149.1 DR-Scan sequence.


TLR: the acronym for the Test-Logic-Reset state in the 1149.1 State-Machine – entering this state places all 1149.1 logic into an inert reset state.


TMS: an 1149.1 dedicated signal, the Test-Mode-Control that directs the state transitions of the 1149.1 State-Machine on the rising-edge of TCK.


TRST*: an 1149.1 dedicated signal, the active-low asynchronous Test-Reset signal.


Update-DR: a noted sub-operation of DR-Scan that represents the action of synchronizing all change actions of the target 1149.1 register or 1687 instrument that is active under the current selected instruction when the 1149.1-SM is in the Update-DR state at the falling-edge of TCK.


IEEE 1500-2005: the core-test standard that defines core-test-wrappers and the core test access-mechanism.


WBY: the Wrapper-Bypass Register – a single-bit register applied in parallel to the 1500 registers (e.g. WIR, CDR, WDR) that can be used to reduce the Wrapper’s scan shift-path to only 1 bit.


PTDI-PTDO: the abbreviation for the 1500 parallel port – Parallel-Test-Data-Input to Parallel-Test-Data-Output.


Select-WIR: a signal unique to the 1500 TAM that unconditionally selects the Wrapper-Instruction-Register (WIR).


TAM: the acronym for Test-Access-Mechanism.


WBR: the Wrapper-Boundary Register – a serial shift-register similar to the BSR of a device, but with more defined capabilities, that is meant to wrap around a core to provide the ability to test the core in isolation (in-facing mode), or the test logic attached to the core using the wrapper instead of the core (out-facing mode).


WIR: the acronym for Wrapper-Instruction-Register.


WSI: a 1500 TAM signal, Wrapper-Serial-Input, that is the beginning of the serial scan-path for the 1500 Test Wrapper.


WSI-WSO: the abbreviation for the 1500 serial scan-path, Wrapper-Serial-Input to Wrapper-Serial-Output.


WSO: a 1500 TAM signal, Wrapper-Serial-Output, that is the end of the serial scan-path for the 1500 Test Wrapper.


IEEE P1687 the on-chip instrument access and control standard that defines the connectivity and interfaces of embedded instruments other than those associated with 1149.1 and used for board-test.


Bandwidth: the use of any data and control mechanisms other than the defined 1149.1 TDI-TDO serial scan-path to deliver/extract more data to/from the instruments:


PTDI-PTDO: a Bandwidth concept of using a Parallel set of signals similar to the 1500 Parallel Port and under the synchronization control of the TCK – Parallel-Test-Data-Input to Parallel-Test-Data-Output. Also defined in the IEEE 1500 definition section.


HSTDI-HSTDO: a Bandwidth concept of using a High-Speed serial set of signals that are synchronized to an alternate and higher-frequency clock than the TCK – High-Speed-Test-Data-Input to High-Speed-Test-Data-Output.


Connectivity-Scheme: the defined limited number of ways to interconnect 1687 instruments to the top-level 1149.1 logic and interface or to each other:


  • Flat: a Connectivity-Scheme where an instruction in the 1149.1-IR or a local Instrument-IR selects one instrument and connects only that instrument to the TDI-TDO serial scan-path – also called “one-at-a-time”.


  • Daisy-Chain: a Connectivity-Scheme where an instruction in the 1149.1-IR or a local Instrument-IR may select one, many, or all instruments, but all instrument serial scan-paths are active and connected to the TDI-TDO serial scan-path.
  • Star: a Connectivity-Scheme where an instruction in the 1149.1-IR or a local Instrument-IR selects a pre-defined grouping of instruments and only these instruments are connected to the TDI-TDO serial scan-path.


  • Concatenate: a Connectivity-Scheme where an instruction in the 1149.1-IR or a local Instrument-IR selects an instrument and that instrument is added to the already active TDI-TDO serial scan-path – this scheme requires the concept of a 1-hot instruction so that multiple instruments may be enabled simultaneously.


  • Hierarchy: a Connectivity-Scheme where an instruction in a local Instrument-IR of a Parent-Instrument selects a Child-Instrument and enables the selected Child-Instrument to be added into the TDI-TDO serial scan path.


  • After: a Hierarchy Connectivity-Scheme where a Parent-Instrument selects a Child-Instrument and concatenates the TDI-TDO serial scan-path of the Child-Instrument after the Parent-Instrument’s TDI-TDO serial scan-path.


  • Before: a Hierarchy Connectivity-Scheme where a Parent-Instrument selects a Child-Instrument and concatenates the TDI-TDO serial scan-path of the Child-Instrument before the Parent-Instrument’s TDI-TDO serial scan-path.


  • Replace: a Hierarchy Connectivity-Scheme where a Parent-Instrument selects a Child-Instrument and concatenates the TDI-TDO serial scan-path of the Child-Instrument directly to the TDI-TDO serial scan-path applied to the Parent-Instrument without including the Parent-Instrument’s TDI-TSO serial scan-path.


HIP: a Hierarchy Connectivity-Scheme acronym for the Hierarchical-Interface-Port – a port on a Parent-Instrument used to pass the Select signal and serial scan-path connections to the Child-Instrument.

SELi: a HIP output signal that passes the Select-Instrument signal from a Parent-Instrument to a Child-Instrument.


WSIo: a HIP output signal, Wrapper-Scan-Input-output that passes the serial scan-path from the Parent-Instrument to the Child-Instrument.


WSOi: a HIP input signal, Wrapper-Scan-Output-input that is the return of the serial scan-path from the Child-Instrument back to the Parent-Instrument.


WSIo-WSOi: a HIP abbreviation for the serial scan-path passed between a Parent-Instrument and a Child-Instrument.


SIB: a Hierarchy Connectivity-Scheme acronym for the Select-Instrument-Bit – an example is a TDR-Bit that includes a HIP and enables a hierarchical connection.


ShSIB: a SIB abbreviation for the Shift portion of the SIB-cell.


UpSIB: a SIB abbreviation for the Update portion of the SIBcell.


SIR: a Hierarchy Connectivity-Scheme acronym for the Select-Instrument-Register – an example TDR that is made up of SIBs that each support a HIP and enables multiple hierarchical connections.


Gateway: a hierarchical enabled instrument or element whose purpose is to be the only 1687 Shift-Update construct that is allowed to be enabled by an 1149.1-IR Instruction in the 1149.1-Overlap-Zone – and once enabled it becomes an alternate local Instrument-IR that can select other 1687 instruments using only DR-Scans.


DR-Scan: (see DR-Scan under the 1149.1 section) – a 1687 Gateway operates through the defined active serial scan-path of 1687 instruments that are connected between the device’s TDI-TDO while the 1149.1-SM is in the Select-DR state – for 1687 this is how all data and control is delivered to 1687 instruments.


IR-Scan: (see IR-Scan under the 1149.1 section) – a 1687 access of the 1149.1-IR to install a “select the Gateway-Enable instruction” (GWEN) when the 1149.1-IR is connected between the device’s TDI-TDO and when the 1149.1-SM is in the Select-IR state.


Gateway-Instrument: an instrument with a Type-B (TDR-like) or Type-C (1500 TAM-like) interface that supports a Hierarchical Connection-Scheme and can be selected by an 1149.1-IR instruction; the hierarchical portion is used as the beginning of the 1687 defined architecture.


GWEN: an acronym for Gateway-Enable that represents an instruction placed in the 1149.1-IR that selects a Gateway-Element or Gateway-Instrument.


Update-DR: a DR-Scan action of synchronizing the changing of the selection, configuration or use of 1687 instruments when the 1149.1-SM is in the Update-DR state and the falling-edge of TCK occurs.


IJTAG: the synonymous acronym for 1687 – it stands for Internal-JTAG where JTAG is being used as the synonymous acronym for 1149.1.


Instrument: any item within a device whose control and configure structure is provided by an 1149.1 TAP and 1149.1 Controller and is optionally accessed by the TDI-TDO serial scan-path. Examples include functional items such as clock-control or bus configuration; Design-for-Test items such as LBIST, MBIST, Mfg-Scan, Embedded Vector-Compression (also known as Test-Data Compression), and 1500 TAMs; Design-for-Debug items such as Trace-Buffers, Embedded Logic-Analyzers, and Bus-Monitors; and Design-for-Yield items such as Ring-Oscillators and Environment-Sensors.


1687 Instrument: an instrument that meets the definitions imposed by 1687 – an interface compatible with the ABCD Taxonomy; a connection scheme limited to the 4 Flat and 3 Hierarchical schemes; and control and configuration driven by an 1149.1 TAP and 1149.1 Controller.


Hierarchical-Element: an element is a standalone TDR or TDR-Bit whose only purpose is to provide a hierarchical connection – there is no other functionality that would classify it as an instrument.


Hierarchical-Instrument: an instrument that supports a hierarchical connection and can act as a Parent-Instrument to a Child-Instrument – passes on the Select-Instrument signal and the WSI-WSO serial scan path.


Instrument Interface: the set of allowed mandatory and optional signals to provide control, configuration, and data sourcing from the defined 1149.1 TAP and TAP-Controller.


Mfg-Scan: a single or set of serial scan-paths that are comprised of functional registers, instead of 1149.1 or 1500 control registers, and are generally used in conjunction with ATPG (automatic-test-pattern-generation) – these scan paths can be concatenated into the TDI-TDO serial scan-path and the clock synchronization can be changed to TCK to enable a concept known as scan dump where the Mfg-Scan Architecture then becomes an instrument to be accessed by 1687.


Protocol: the sequence of application of signals needed to operate an instrument. For 1687 instruments, this will require the operation of the 1149.1-SM and the delivery of data through the serial scan-path on the rising-edge of TCK when the 1149.1-SM is in the Shift-DR state; and actions or configurations will be changed on the falling-edge of TCK when the 1149.1-SM is in the Update-DR state. These actions can be short-hand referred to as

Shift-DRs and Update-DRs.


Protocol-Explosion: the exponential increase in the number of DR-Scans for each level of Hierarchy enabled. This is a result of the Select-Instrument and Select-WIR type signals having to source from one instrument to enable another as opposed to the control being local (selfcontained) to the instrument. For example to enable three hierarchical instruments past a Gateway requires: an IR-Scan to select the Gateway; a DR-Scan to select the enable-bit in the Gateway which should select the first hierarchical instrument; a DR-Scan to select the hierarchy-enable bit in the first hierarchical instrument which enables the second instrument; a DR-Scan to select the Select-WIR of the second instrument; a DR-Scan to select the hierarchical-enable bit in the second instrument; a DR-Scan to de-select the WIR in the second instrument which selects the third instrument; and another DR-Scan to select the WIR in the third instrument.