SCOPE DRAFT

1
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.

2
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).

3

• 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.

4
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.

5
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.

6
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.

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

8
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.

9
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

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

11
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.

12
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.

13

• 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.

14

• 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.

15
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.

16

• 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.

17

• 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.

18
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).

19
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.

20
NEED PAR VERSION

• enabling methods
• Not offering a defined manager
• architectural philosophy

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

22
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.

23

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

24

• PURPOSE for ExclusionThe 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)

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

26
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

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

28
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

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

30
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).