PAR scope and direction

[LYUngar1]

Maybe the following will take care of both concerns:
From:

While many standards exists at the device level, with diverse feature sets, there is currently no standard that provides for aggregation of these or the management and coordination between such standards from a board or system test perspective.

To:

While many standards exist for device level tests with diverse feature sets, there is currently no standard that provides for aggregation, management and coordination of such standards for higher level assemblies, such as boards or systems.

[Bradford Van Treuren]

Louis wrote:

While many standards exist for device level tests with diverse feature sets, there is currently no standard that provides for aggregation, management and coordination of such standards for higher level assemblies, such as boards or systems.

I have a bit of a problem with using device test as it seems to limit what busses we could coordinate in a board or system. True, the primary target application for STAM is probably going to be test or some activity related to test, but it is not limited to that. For example, voltage monitoring or thermal monitoring actions would be considered functional operation activities and not "test" in embedded applications. I2C and SPI are really instrumentation busses and not considered test busses. STAM needs to be able to coordinate their use.

Other than the use of the word test at the beginning, I find Louis' version to be closer to what I was looking for. He has elegantly resolved the problem with board, system, sub-system, etc. enumeration.

Maybe this will handle the test and instrumentation aspect:

While many standards exist to access diverse feature sets for device level test and instrumentation, there is currently no standard that provides for aggregation, management and coordination of such standards for higher level assemblies, such as boards or systems.

BUT this sounds a bit too wordy and a run-on sentence staring with while and ending with such as.

[TerryD]

How about we solve the run-on by doing the following:

Many standards exist to access diverse feature sets for device level test and instrumentation, however, there is currently no standard that provides for aggregation, management and coordination of such standards for higher level assemblies, such as boards or systems.

[Ian McIntosh]

I'm happy with that. I think it adequately deals with "what is currently missing", but there's probably a knock-on effect on Heiko's second paragraph, which also refers to "board and system level"; it's the latter paragraphs that (try to) address why we need a way to manage and co-ordinate the standards/interfaces.

[Bradford Van Treuren]

Terry said:

Many standards exist to access diverse feature sets for device level test and instrumentation, however, there is currently no standard that provides for aggregation, management and coordination of such standards for higher level assemblies, such as boards or systems.

I'm wondering if it makes better sense to break this into two sentences as:
Many standards exist to access diverse feature sets for device level test and instrumentation. However, there is currently no standard that provides for aggregation, management and coordination of such standards for higher level assemblies, such as boards or systems.

I think Heiko's second sentence of:

Users of board and system level test equipment need to be able to tell their tools what they want to do with instruments made available at the device level. Said tools need to be able to automate coordination of access to and use of such instruments to support applications defined by tool users.

is fine with the first sentence. This sentence is really a specialization use case for STAM as an example (External Test).

Heiko's last sentence is what I think needs some work to bridge with the first sentence (as Ian eluded to).

Standardization of the definition of dependencies, constraints, and coordination of instruments is needed to facilitate such automation and to enhance testability, test coverage, and diagnostics resolution at the board and system level.

I think we could change it to:
Standardization of the definition of dependencies, constraints, and coordination of said instruments is needed to facilitate such automation and to enhance testability, test coverage, and diagnostics resolution in the higher level assemblies.

I have a bias about these instrumentation standards that could explain why high use of these standards has not been achieved in industry. The primary complaint I get from my ASIC designers and board designers is the lack of insight and support for accessing such instruments from the application code embedded in the product. Standards like IEEE1149.1-2013, IEEE1687-2014, and IEEE1149.10 are scan based interfaces requiring a lot of preprocessing (retargeting or message generation) that does not seem to fit into the limited resource space of embedded applications. Thus, instrument registers requiring access during the run-time operation of products requires simple legacy interfaces, such as direct I2C or SPI addressing, to be able to access the contents of such instrument registers. One area that STAM could greatly enhance the use of these new IEEE standards is by providing a standardized access procedure for accessing such instrumentation without the need for run-time retargeting. Michele and I presented an alternate execution model that greatly reduced the resource size and provided a means of scheduling scan events accessing these instruments as a proposed alternative for the embedded environment. The STAM study group may decide to address this area in the PAR or recommend a second study group be formed to resolve this gap in technology. My recommendation is the STAM solution should be able to handle the embedded access use case as well as the external access use case. Otherwise, we may end up having disjointed standards. If STAM is to deal with embedded access, then we need to add a sentence to suggest this case. Perhaps the following:

This standardization also helps to facilitate access to these instruments during run-time embedded applications where dynamic management and control of the instruments is required.

[JCSTEW123]


Many standards exist to access diverse feature sets for device level test and instrumentation, however, there is currently no standard that provides for aggregation the aggregate, management and coordination of such standards for higher level assemblies, such as boards or systems

[Ian McIntosh]

Latest versions of STAM Scope, Purpose and Need, brought together for review:

Scope:
This standard: 1) defines a representation of conforming behavioral descriptions of interfaces and transformations, 2) defines new methods for utilizing those representations to enhance the test management and access to sub-assembly test assets. This will allow, in conjunction with existing methods, for the coordination and control of a variety of digital interfaces to devices, boards, and sub-systems to extend test access to board and system levels. The standard does not replace or provide an alternative to existing test interface standards, but aims instead to enable their usage throughout the hierarchy of systems.

Purpose:
The purpose of this standard is to provide a means to seamlessly integrate component access topologies, interface constraints, and other dependencies at the board and system level by using standardized descriptions focusing on topology, interfaces and behavior (as opposed to physical structure). This will ease the burden on those preparing test, maintenance and support applications, including ATPGs, in particular where the application requires to co-ordinate control of and data transfer through multiple interfaces and/or protocols. The providers of these conforming descriptions are the producers of devices or assemblies with digital interfaces that are intended to be used in an automated fashion within a larger assembly. This standard will include a methodology to ensure access to particular destination registers in the correct time order.

Need:
Standards exist to access diverse feature sets for device level test and instrumentation. However, there is currently no standard that provides for the aggregate management and coordination of such standards for higher level assemblies, such as boards or systems.
Users of board and system level automated test equipment need to be able to command their tools and instruments, identifying the dependencies, constraints, and required coordination. Embedded applications also need to have access to these same instruments at higher levels during run-time.
Standardization is needed to facilitate such automation and to enhance testability, test coverage, and diagnostics resolution in the higher level assemblies.

Please make any final observations on these ASAP as we aim to start a process of formally accepting these texts for our PAR at the June 11 meeting.
Additionally, one thing that we've overlooked so far is that the PAR also asks us to identify the "stakeholders":

The stakeholders (e.g., telecom, medical, environmental) for the standard consist of any parties that have an interest in or may be impacted by the development of the standard.

[Heiko Ehrenberg]

In Purpose:

The providers of these conforming descriptions are the producers of devices or assemblies with digital interfaces that are intended to be used in an automated fashion within a larger assembly.

Would "integrated circuits or printed circuit board assemblies" instead of "devices or assemblies" help?

[Ian McIntosh]

Works for me.

[JCSTEW123]

So taking a look at the Purpose, Need and Scope statement I look at these statements in the following way. The Purpose to me is the vision or the end game. The Need describes the journey as in what has to be done to get to our end game. The Scope describes the boundaries. Do others agree with what I have stated? If so then, I believe we have accomplished what we need to do with the Purpose, Need and Scope statements for the STAM ( Systems Test Access Management) segment of SJTAG. On another point in one of the statements I thought I had seen the acronym ATPGs used. Does this acronym mean Automated Test Programs? Just a guess. We should make sure in out Need, Scope, and Purpose statements that we call out what various acronyms mean before we use them. Just a check as I believe we are in fairly good shape with our acronyms.

Regards,

Jon Stewart

[Ian McIntosh]

Purpose mentions ATPGs - Automatic Test Program Generators. I agree it should expanded.

Generally, I think you're right with your overall assessment, Jon - the one thing I'd maybe differ on is that the Need is really an explanation for the sponsor (TTSC) and IEEE-SA RevCom (Review Committee) to justify why this particular standard is needed.

[Adam W Ley]

I believe that ATPG is most often "spelled out" as "Automatic Test Pattern Generation".

[Adam W Ley]

the Need is really an explanation for the sponsor (TTSC) and IEEE-SA RevCom (Review Committee) to justify why this particular standard is needed.

Agreed.

[Ian McIntosh]

I've started a separate thread for "Stakeholders": viewtopic.php?f=3&t=788
Let's keep this one for the Scope clarification and improvement.

[Adam W Ley]

Here's my take at revised test for the statement of STAM Scope:

This standard addresses use/ reuse of test assets in system context by: 1) defining a representation for behavioral descriptions of pertinent sub-assembly interfaces and of relevant transformations; 2) defining methods for utilizing such representations to enhance management of and access to said test assets. In conjunction with existing methods for test access and test management, this will allow the coordination and control of a variety of digital interfaces to devices, boards, and sub-systems to extend test access to board and system levels. This standard does not replace or provide an alternative to existing test interface standards, but aims instead to enable their usage throughout the hierarchy of systems.

For the "change bars", please see the attached docx file.

2018 06 11 PAR texts; annotated 2018 06 19, ALey.docx

NOTE: changes to STAM Purpose, for a few small word changes, and STAM Need, for hyphen usage, are also included.