As we begin to move forward with the P2654 Working Group, our email reflector has been updated today to remove former study group members that either indicated that they no longer wished to be part of the activity or failed to respond to requests to confirm their continued participation (either as an active member or an observer).

Anyone who did any of the following will have been retained on the mailing list and should receive the WebEx meeting invite for the 2019 meeting series:

  • Supplied the chair with an email affirming their intent to participate/observe, or
  • Joined the C/TT/STAM Working Group committee in IEEE-SA myProject™, or
  • Attended the first Working Group meeting on December 10, 2018.

If you think you are no longer receiving group emails or WebEx invites and may have been removed from membership in error, then please Contact Us and we'll get you added back in.

This is a call for participation in the "System Test Access Management" (STAM) Working Group (associated as the first part of 'SJTAG').

Following approval of the PAR for a "Standard for System Test Access Management (STAM) to Enable Use of Sub-System Test Capabilities at Higher Architectural Levels" the project has been assigned the designation "P2654" and we are now in the process of forming the Working Group.  Anyone interested in joining this effort, either as an active participant or simply as an observer is invited to either:

This is a call for participation in the "System Test Access Management" Study Group (also referred to as 'SJTAG'). Those interested in joining the study group or being kept informed of its activities should notify their interest by email to This email address is being protected from spambots. You need JavaScript enabled to view it. or via the group's Contact Page (

The goal of this study group is to explore the feasibility and to develop a project authorization request (PAR), including the scope and purpose, for an IEEE standard that 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, by leveraging existing test interface standards (by defining a description to better manage how they are used in the system).

The PAR (Project Authorization Request) for the proposed System Test Access Management standard was reviewed by the IEEE-SA New Standards Committee (NesCom) at their October 2018 meeting, resulting in approval of the PAR.  The project has been designated "P2654" and the PAR is approved through to the end of December 2022.

We are now in the process of forming the Working Group and a call for new members will be issued shortly. In the meantime, interested parties can add "C/TT/STAM" and "C/TT/STAM/P2654" to their interests in IEEE myProject or can contact the officers via our Contact Us page to join the Working Group. 

An initial kick-off meeting for the new Working Group is planned for Monday, December 10, at 11 AM EST via WebEx. Joining details will be provided to those expressing interest.

An SJTAG Green Paper

By Bradford G. Van Treuren, SJTAG Chair Emeritus

(Full size images may be viewed from the gallery at the foot of this article. A description of SJTAG Green Papers can be found here.)


In this installment, I will be discussing the contrast between the need to support pre-generated tests, which are able to be replicated for factory testing, versus the need to support interactive configuration and control of an entity during Design Verification Test (DVT), Hardware Debugging (HWDB), and Software Debugging (SWDB).  Both aspects are required to support the introduction of new designs.  SJTAG needs to be able to support both these domains.  The first usage domain deals with the traditional boundary-scan testing.  A model of a circuit is created that defines the topology of the scan chain.  An algorithm is applied to the model and a set of test vectors are created that can be applied to circuits matching that topology without needing to regenerate the vectors.  The other domain concerns only a portion of the whole topology: a Test Data Register (TDR).  This application modifies the configuration of one or more data registers (e.g., TDR) over a period of time to change the behavior of the device the registers reside in.  The flow of the execution may not be the same for each execution of the application.  This is because it is dependent on the state of the device, board, system, or a combination of some set of effectors monitored during the test operation.


Pages for 2009 Survey results.