SCOPE DRAFT SCOPE: To provide a standardized enabling technology to extend device, board, and system level test interfaces for access at the system level; providing the coordination between diverse standards to fulfill a common purpose.

SCOPE DRAFT SCOPE: This standard provides enabling technology methods to extend device, board, and sub-system level test interfaces for access at the system level; providing the coordination of operations between diverse standards/specifications/protocols to fulfill a common purpose (need to state what the purpose is: enabling interfaces, provide coordination).

SCOPE: This standard provides enabling methods for coordination between diverse device, board, and sub-system test interfaces to extend test access at to the system level.

SCOPE “What” of project SCOPE: This standard defines enabling methods to allow for the coordination and control of one or more (possibly different) device, board, and sub-system test interfaces to extend access to the system level. It also defines the architectural philosophy and description of such a system to allow better management of the test interfaces that exist when used at the system level.

PURPOSE WHY? PURPOSE: IEEE 1687 and IEEE 1149.1-2013 provide methods for describing each of the instrument interfaces on a per component basis, but fail to provide the contextual prerequisites for the dependence on each instrument configuration and/or aggregation of multiple instruments for the overall board or system maintenance operations. Further, many components only support non-JTAG interfaces (e.g., I2C or SPI) to their instrumentation registers. There needs to be a supervisory standard that is responsible for defining the coordination and dependencies of instruments as well as configuration, management, and application of vector based testing at the board and system levels. A standardized method is needed to coordinate component access topologies, interface constraints, and other dependencies at the board and system level in order to be able to effectively leverage the existing and future component level standards.

NEED NEED: As signals get faster on boards, there is a need to use alternate test techniques from the traditional continuity testing that was originally supported by IEEE 1149.1. IEEE 1149.6 was developed to handle the case for AC coupled signals that were not testable by 1149.1 DC tests. High Speed Serial IO (HSIO) presents yet another problem in that 1149.6 does not address the needs for testing these signals. As such, special Bit Error Rate Test (BERT) techniques have been employed to test these signals at-speed to verify the signal integrity on the board. These tests, and others, requires special instrumentation to be implemented in the source and destination components wired together. Thus, there is a need to coordinate the configuration of such component ports and instrumentation to allow for such things as a loop-back configuration in the destination component and a BERT instrument connected to the port in the source component. There may be a single BERT instrument shared for each port being tested from the source or there could be a dedicated BERT instrument for each port. IEEE 1687 and IEEE 1149.1-2013 provide methods for describing each of the instrument interfaces on a per component basis, but fails to provide the contextual prerequisites for the dependence on each instrument configuration for the overall board test operation. To complicate the issue further, many components only support an I2C or SPI interface access to its instrumentation registers. There needs to be a supervisory standard that is responsible for defining the coordination and dependencies of instruments along with coordinating the aggregation of component access topologies at the board and system level to be able to effectively leverage the existing and future component level standards.

PURPOSE WHY? PURPOSE: A standardized method is needed to coordinate component access topologies, interface constraints, and other dependencies at the board and system level in order to be able to effectively leverage the existing and future component level standards. Thus, a new supervisory standard is required to define the coordination and dependencies of instruments as well as configuration, management, and application of vector based testing at the board and system levels. IEEE 1687 and IEEE 1149.1-2013 provide methods for describing each of the instrument interfaces on a per component basis, but fail to provide the contextual prerequisites for the dependence on each instrument configuration and/or aggregation of multiple instruments for the overall board and/or system maintenance operations. Further, many components only support non-JTAG interfaces (e.g., I2C or SPI) to their instrumentation registers.

NEED NEED: As signals get faster on boards, there is a need to use alternate test techniques from the traditional continuity testing that was originally supported by IEEE 1149.1. IEEE 1149.6 was developed to handle the case for AC coupled signals that were not testable by 1149.1 DC tests. High Speed Serial IO (HSIO) presented yet another problem in that 1149.6 does not address the needs for testing these signals. As such, special Bit Error Rate Test (BERT) techniques have been employed to test these signals at-speed to verify the signal integrity on the board. These tests, and others, requires special instrumentation to be implemented in the source and destination components wired together. Thus, there is a need to coordinate the configuration of such component ports and instrumentation to allow for such things as a loop-back configuration in the destination component and a BERT instrument connected to the port in the source component. There may be a single BERT instrument shared for each port being tested from the source or there could be a dedicated BERT instrument for each port.

NEED NEED: As signals get faster on boards, there is a need to use alternate test techniques from the traditional continuity testing that was originally supported by IEEE 1149.1. These techniques, and others, requires special instrumentation to be implemented in the source and destination components wired together. There is a need to coordinate the configuration of components, selection of access paths (scan paths?), and configuration of instrumentation access to perform the required test and maintenance operation. For example, there is a need to coordinate the configuration of component ports and instrumentation to allow for a loop-back configuration in the destination component and mapping of instruments to pins under test. Multiple host selection? Access to target

NEED NEED: A growing number of test and maintenance applications are needing to access IEEE 1149.1 compliant components and there is not a way to give these applications uniform access to the targets at the board and system levels. Current standards are only dealing with the interfaces inside of a component. Further, components may use alternate interfaces (e.g., I2C, SPI) to provide access to the test features. Consequently, special consideration must be given to the communications between the host and the target. There is also a need to configure the topology of the access mechanisms from one or more hosts, which must be described from the perspective of the tooling driving the applications. These techniques, and others, requires special instrumentation to be implemented in the source and destination components wired together. For example, there is a need to coordinate the configuration of component ports and instrumentation to allow for a loop-back configuration in the destination component connected to the source and mapping of instruments to pins under test. Need to deal with difference between configuration of topology and configuration of instruments needing to be coordinated in operation (Need this explained before we can introduce examples)

NEED NEED: A growing number of test and maintenance applications are needing to access IEEE 1149.1 compliant components and there is not a way to give these applications uniform access to the targets at the board and system levels. Current standards are only dealing with the interfaces inside of a component. Further, components may use alternate interfaces (e.g., I2C, SPI) to provide access to the test features. Consequently, special consideration must be given to the communications between the host and the target. First, any differences in the access link protocols need to be managed and described to act as a single interface form for the host tooling. Second, there is a need to configure the topology of the access mechanisms from one or more hosts to one or more targets, which must be described from the perspective of the tooling driving the applications. Third, the host needs to ensure that any pre or post-configuration of instruments/registers occurs in a timely and coordinated manner in order to facilitate the operation in hand. (Interconnect Example First) For example, there is a need to coordinate the configuration of component ports and instrumentation to allow for a loop-back configuration in the destination component connected to the source and mapping of instruments to pins under test.

NEED NEED: A growing number of test and maintenance applications are needing to access IEEE 1149.1 compliant components and there is not a way to give these applications uniform access to the targets at the board and system levels. Current standards are only dealing with the interfaces inside of a component. Further, components may use alternate interfaces (e.g., I2C, SPI) to provide access to the test features. Consequently, special consideration must be given to the communications between the host and the target. First, any differences in the access link protocols need to be managed and described to act as a single, common, abstracted interface for the host tooling. Second, there is a need to configure the topology of the access mechanisms from one or more hosts to one or more targets, which must be described from the perspective of the tooling driving the applications. Third, the host needs to ensure that any pre or post-configuration of instruments/registers occurs in a timely and coordinated manner in order to facilitate the operation at hand. (See slide 13 for suggested sentences) For example, there is a need to coordinate the configuration of component ports and instrumentation to allow for a loop-back configuration in the destination component connected to the source and mapping of instruments to pins under test.

Traditional board interconnect test relies on precomputed vectors that are applied consistently for each board design. However, when applied in a system, the test needs to be associated with an instance of a board (one of many) with a slot ID or unique identifier. More importantly, a board may require a different set of constraints at the board edge based on which slot the board is plugged into or what is mated to it in adjoining slots. Example 1 Traditional board interconnect test (precomputed ATPG vectors). Example 2 Backplane interconnect test. Not fully composed system where population may vary and new constraints may be imposed on previously known entities. Board stand-alone test is different than board in-system test. Board stand-alone may allow for applying external instrumentation that is impossible when in-system. When buying a COTS board, how can we include it in the system with test. For example, there is a need to coordinate the configuration of component ports and instrumentation to allow for a loop-back configuration in the destination component connected to the source and mapping of instruments to pins under test.

Traditional board interconnect test, targeting circuits within a given board, relies on pre-computed vectors that are applied consistently for each board design. However, when applied in a system, the test (a test version) needs to be associated with an instance of a board, which may be one of several boards, with a slot ID or other unique identifier. More importantly, a board may require a different set of constraints at the board edge, which are influenced by factors such as the slot the board is plugged into, what is mated in adjoining slots, or a change of the system configuration. A management layer needs to select which test version is to be applied to each instance in a system for the current configuration. Example 2 Backplane interconnect test. Board stand-alone may allow for applying external instrumentation that is impossible when in-system. When buying a COTS board, how can we include it in the system with test. Anyway, am I right to summarise the aims as follows?: Example 2 - Verification of the interconnects between boards installed in a system. - We are not interested in the internal circuitry of any particular board other than how it may be used to condition, drive or sense the board edges.

NEED NEED: A growing number of test and maintenance applications are needing to access IEEE 1149.1 compliant components and there is not a way to give these applications uniform access to the targets at the board and system levels. Current standards are only dealing with the interfaces inside of a component. Further, components may use alternate interfaces (e.g., I2C, SPI) to provide access to the test features. Consequently, special consideration must be given to the communications between the host and the target. First, any differences in the access link protocols need to be managed and described to act as a single, common, abstracted interface for the host tooling. Second, there is a need to configure the topology of the access mechanisms from one or more hosts to one or more targets, which must be described from the perspective of the tooling driving the applications. Third, the host needs to ensure that any pre or post-configuration of instruments/registers occurs in a timely and coordinated manner in order to facilitate the operation at hand. Traditional board interconnect test, targeting circuits within a given board, relies on pre-computed vectors that are applied consistently for each board design. However, when applied in a system, the test (a test version) needs to be associated with an instance of a board, which may be one of several boards, with a slot ID or other unique identifier. More importantly, a board may require a different set of constraints at the board edge, which are influenced by factors such as the slot the board is plugged into, what is mated in adjoining slots, or a change of the system configuration. A management layer needs to select which test version is to be applied to each instance in a system for the current configuration. (See slide 14 for suggested sentences) For example, there is a need to coordinate the configuration of component ports and instrumentation to allow for a loop-back configuration in the destination component connected to the source and mapping of instruments to pins under test.

On the other hand, interconnect test between boards, targeting circuits connected by a backplane and/or cables, may require that any pre-computed vectors are adapted based on the physical configuration of the system or that the vectors are generated dynamically. Significantly, a board may need to sense or drive a different set of values at its edge depending on the system population, influenced by the same factors from above, but with an alternative perspective. A management layer is also needed to select how vectors are to be applied to each instance in a system for the current configuration. Knowledge of operational state of the system - not just what's connected, but what is on/off, active/inactive.

On the other hand, interconnect test between boards, targeting circuits connected by a backplane and/or cables, may require that any pre-computed vectors are adapted based on the physical configuration of the system or that the vectors are generated dynamically. Significantly, a board may need to sense or drive a different set of values at its edge depending on the system population, influenced by the same factors from above, but with an alternative perspective. A management layer is again needed, to have knowledge of the operational states of the entities in the system, how to select the vectors that are to be applied to each such entity, and how these vectors are applied for the current configuration.

NEED NEED: A growing number of test and maintenance applications are needing to access IEEE 1149.1 compliant components and there is not a way to give these applications uniform access to the targets at the board and system levels. Current standards are only dealing with the interfaces inside of a component. Further, components may use alternate interfaces (e.g., I2C, SPI) to provide access to the test features. Consequently, special consideration must be given to the communications between the host and the target. First, any differences in the access link protocols need to be managed and described to act as a single, common, abstracted interface for the host tooling. Second, there is a need to configure the topology of the access mechanisms from one or more hosts to one or more targets, which must be described from the perspective of the tooling driving the applications. Third, the host needs to ensure that any pre or post-configuration of instruments/registers occurs in a timely and coordinated manner in order to facilitate the operation at hand. Traditional board interconnect test, targeting circuits within a given board, relies on pre-computed vectors that are applied consistently for each board design. However, when applied in a system, the test (a test version) needs to be associated with an instance of a board, which may be one of several boards, with a slot ID or other unique identifier. More importantly, a board may require a different set of constraints at the board edge, which are influenced by factors such as the slot the board is plugged into, what is mated in adjoining slots, or a change of the system configuration. A management layer needs to select which test version is to be applied to each instance in a system for the current configuration. On the other hand, interconnect test between boards, targeting circuits connected by a backplane and/or cables, may require that any pre-computed vectors are adapted based on the physical configuration of the system or that the vectors are generated dynamically. Significantly, a board may need to sense or drive a different set of values at its edge depending on the system population, influenced by the same factors from above, but with an alternative perspective. A management layer is again needed, to have knowledge of the operational states of the entities in the system, how to select the vectors that are to be applied to each such entity, and how these vectors are applied for the current configuration. As a further example, one that involves embedded instrumentation, there is a need for a management layer to coordinate the configuration of component ports and instrumentation, as well as mapping of instruments to the physical pins under test, perhaps to allow for a loop-back configuration (Master through Slave Mode) in the destination component connected to the source or to support Master to Master Mode connections (e.g. , Tx1 to Rx2, Tx2 to Rx1).

NEED NEED: A growing number of test and maintenance applications are needing to access IEEE 1149.1 compliant components and there is not a way to give these applications uniform access to the targets at the board and system levels. Current standards are only dealing with the interfaces inside of a component. Further, components may use alternate interfaces (e.g., I2C, SPI) to provide access to the test features. Consequently, special consideration must be given to the communications between the host and the target. First, any differences in the access link protocols need to be managed and described to act as a single, common, abstracted interface for the host tooling. Second, there is a need to configure the topology of the access mechanisms from one or more hosts to one or more targets, which must be described from the perspective of the tooling driving the applications. Third, the host needs to ensure that any pre or post-configuration of instruments/registers occurs in a timely and coordinated manner in order to facilitate the operation at hand. Traditional board interconnect test, targeting circuits within a given board, relies on pre-computed vectors that are applied consistently for each board design. However, when applied in a system, the test (a test version) needs to be associated with an instance of a board, which may be one of several boards, with a slot ID or other unique identifier. More importantly, a board may require a different set of constraints at the board edge, which are influenced by factors such as the slot the board is plugged into, what is mated in adjoining slots, or a change of the system configuration. A management layer needs to select which test version is to be applied to each instance in a system for the current configuration. On the other hand, interconnect test between boards, targeting circuits connected by a backplane and/or cables, may require that any pre-computed vectors are adapted based on the physical configuration of the system or that the vectors are generated dynamically. Significantly, a board may need to sense or drive a different set of values at its edge depending on the system population, influenced by the same factors from above, but with an alternative perspective. A management layer is again needed, to have knowledge of the operational states of the entities in the system, how to select the vectors that are to be applied to each such entity, and how these vectors are applied for the current configuration. As a further example, one that involves embedded instrumentation, there is a need for a management layer to coordinate the configuration of component ports and instrumentation, as well as mapping of instruments to the physical pins under test, perhaps to allow for a loop-back configuration (Master through Slave Mode) in the destination component connected to the source or to support Master to Master Mode connections, where a Tx instrument residing in one device communicates with the Rx instrument residing in another device and vice versa, thus a coordination of these instruments is required from a management layer.

NEED PAR VERSION enabling methods Not offering a defined manager architectural philosophy

SCOPE “What” of project SCOPE: This standard defines enabling methods to allow, in conjunction with existing methods, for the coordination and control of one or more (possibly different) device, board, and sub-system test interfaces to extend access to the system level. It also defines the architectural philosophy and description of such a system to allow better management of the test interfaces that exist when used at the system level. The standard does not replace or provide an alternative to <?>

PURPOSE WHY? PURPOSE: A standardized method is needed to coordinate component access topologies, interface constraints, and other dependencies at the board and system level in order to be able to effectively leverage the existing and future component level standards. Thus, a new supervisory standard is required to define the coordination and dependencies of instruments as well as configuration, management, and application of vector based testing at the board and system levels. IEEE 1687 and IEEE 1149.1-2013 provide methods for describing each of the instrument interfaces on a per component basis, but fail to provide the contextual prerequisites for the dependence on each instrument configuration and/or aggregation of multiple instruments for the overall board and/or system maintenance operations. Further, many components only support non-JTAG interfaces (e.g., I2C or SPI) to their instrumentation registers.

What is the standard NOT? What is(are) the aim(s) of the standard? scope = what is included and what is excluded purpose= what you hope to accomplish by implementation\work out. (credit to answers.com) Here's another, yet similar take (credit to stackexchange.com) Purpose- It is the reason or aim for which something is done. Scope- Scope refers to the extent of area or range a matter is dealt with. proposed: Scope is a broad take on what the standard Is/ Is Not Purpose is directed at what the standard Aims for. Need explores the Why Look at it another way: Scope answer these questions: What is the standard? What is the standard NOT? Purpose answers this(these) questions: What is(are) the aim(s) of the standard? Need answers this question: Why is the standard needed?

[PURPOSE for Exclusion]The aim of the standard is to reuse existing standards so as to exploit them in the system context Without defining the features inside each device (exploiting the existing standards)

SCOPE “What” of project SCOPE: This standard defines methods to allow, in conjunction with existing methods, for the coordination and control of device, board, and sub-system test interfaces to extend access to the system level. The standard does not replace or provide an alternative to existing test interface standards, but aims instead to leverage them by defining a description to better manage how they are used in the system.

PURPOSE: AIM(S) PURPOSE: Seamless Access system, board, device meld into a uniform description (Abstraction of “Assembly”) Metamorphosis into a common interface description A delineation between topology and physical structure (topology is more important to SJTAG) (Behavioral aspects than structural) Problem Domain (what we are trying to do) Inadequacy of existing standards

NEED NEED: A standardized method is needed to coordinate component access topologies, interface constraints, and other dependencies at the board and system level in order to be able to effectively leverage the existing and future component level standards. Thus, a new supervisory standard is required to define the coordination and dependencies of instruments as well as configuration, management, and application of vector based testing at the board and system levels. IEEE 1687 and IEEE 1149.1-2013 provide methods for describing each of the instrument interfaces on a per component basis, but fail to provide the contextual prerequisites for the dependence on each instrument configuration and/or aggregation of multiple instruments for the overall board and/or system maintenance operations. Further, many components only support non-JTAG interfaces (e.g., I2C or SPI) to their instrumentation registers.

PURPOSE(2): AIM(S) PURPOSE: Seamless Access system, board, device meld into a uniform description (Abstraction of “Assembly”) Metamorphosis into a common interface description A delineation between topology and physical structure (topology is more important to SJTAG) (Behavioral aspects than structural) Our goal is abstracting out the differences and delegating those differences to the underlying interfaces at the same time identifying the features that are in common (e.g., addressing, access link connection, data link transmission) to be able to simplify the way tools interact with the various standards being leveraged. treat the interfaces (access links, data links) as "black boxes“ concerned with the board and system level "routing" of control and data how industry may exploit it?

PURPOSE(2): AIM(S) PURPOSE: Problem Domain (what we are trying to do) Inadequacy of existing standards Aspects the end user's perspective, control, and operation of the "networks" as a description of the topology and behavior the description to the tooling what kind of access links and data links are used for a particular scan segment representing a portion of the whole configuration Problem Domain may offer the context for the aims we define what needs to be transacted and when, with the how being left to the standard defining the interface and the creativity of the tooling use cases end up being largely irrelevant because once you can readily control and route data you can implement any use case “routing” proposes no difference between the pre-computed vector based use cases and the dynamically created vectors Bridging between an embedded environment and an external tool for deciphering the results (interchangeability between execution and diagnostic environments) Aggregation of circuit boards (w/ varying protocols e.g., 1149.x, 1687, I2C, USB, SPI) Trying to create a software abstraction to the existing hardware standards

PURPOSE The purpose of this standard is to provide a means to coordinate component access topologies, interface constraints, and other dependencies at the board and system level based on a common interface description with focus on topology and behavior (as opposed to physical structure).