Defining SJTAG

Discuss the generic proposals for SJTAG
Post Reply
User avatar
Ian McIntosh
SJTAG Chair
Posts: 405
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo MW Ltd, UK
Contact:

Defining SJTAG

Post by Ian McIntosh » Fri Mar 16, 2018 7:05 pm

I've had a look through some of the historical work and don't see anything that jumps out as pointing towards a "definition", at least not one that seems relevant to how we view the subject today. Very simplistically, we would in the past have said it was about taking JTAG (i.e. 1149.1 and allied technologies) and making it available to the system user, but things have evolved from there, although that probably remains within our aims[1]. SJTAG has become rather difficult to draw a box around.

Additionally, I think we all originally envisaged SJTAG as a single standard, but again that has morphed through notions of a standard with extensions and on to multiple discrete standards that may themselves have extension; this really just reflects the expanding scope of things that could fall under the heading of "SJTAG".

I rather feel that STAG isn't so much a definable entity as a concept, or perhaps more accurately a system of concepts, which could generally be described as improving the utility, at system and sub-system levels, of inherent design features that can be utilised to provide testability, maintainability and supportability in the product.

The underlined words above are because I don't see SJTAG as being a driver to embody additional DFT in the board designs but is instead a user of the DFT. Perhaps you could say SJTAG drives the DFT of the infrastructure of the system but it doesn't really add sensors or stimuli to the design.

[1] To some extent, since the formation of the SJTAG initiative, tooling and component support has improved somewhat to the extent that this specific point is perhaps less of an issue than it was in 2005.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Adam W Ley
SJTAG Established Member
Posts: 27
Joined: Mon Nov 12, 2007 1:35 pm
Location: ASSET InterTech, Inc./ USA
Contact:

Re: Defining SJTAG

Post by Adam W Ley » Wed Mar 21, 2018 1:16 am

With apologies for replying to this without the benefit of reading for the full context of this recent attempt at "Defining SJTAG", here's a thought or few ...

While I concur that inherent built-in test capabilities at the lowest level are unlikely to be impacted by "SJTAG", there is the matter of accessibility to those capabilities, within a system/hierarchical context, that requires its own design-for-test (DFT) consideration at levels higher than the lowest level.

At the risk of seeming obtuse by stating what many will take as obvious ...
  1. if we take "JTAG" boundary scan as a built-in test capability of interest, as encapsulated within digital ICs and accessible via 1149.1 Test Access Port
  2. at board level, the several such ICs with JTAG boundary scan may need to be chained
  3. at multi-board subsystem level, the multiple board chains may need to be aggregated; in fact, we may want to have a gateway facility on each board to facilitate multidrop topology at this level
  4. at the next higher level of system hierarchy, we may want to ???
  5. etc
Clearly, "a" is "chip DFT" and may be considered out of our scope.

On the other hand, boards (or any multi-die packaging) may be considered systems from our perspective and so any "board DFT" such as "b" *might* be within our scope?

Further, then, "c" seems clearly within our scope = call it "system DFT"?! And more so "d" and still more "e" (whatever it is) ...

So, that said, let me get on with Defining SJTAG. I'll take this stab at it.

"SJTAG is a practice of, in hardware and software, coordinating any built-in features, such as, for example, "JTAG", inherent to various components within a system so as to accomplish coherent test and management objectives within said systems"

I look forward to your flames, slings and/or arrow (or, levity aside, your constructive comments and criticisms).

User avatar
Ian McIntosh
SJTAG Chair
Posts: 405
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo MW Ltd, UK
Contact:

Re: Defining SJTAG

Post by Ian McIntosh » Wed Mar 21, 2018 3:23 pm

As usual Adam, you provide very thoughtful input. I don't think you're missing much in the way of context - this was really an exercise in trying to come up with a definition that would help to provide clarity on the distinction and relationship between "SJTAG" and the current "System Test Access Management" activity.

If I have a criticism of your proposed definition, it might be that I could envisage that some of the features might arise from an aggregation of components rather from a single part (although I'm not sure I could offer a specific example) so I'd maybe suggest altering "inherent to various components" to "inherent to various components and sub-assemblies" (but that may not be quite right either).
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Adam W Ley
SJTAG Established Member
Posts: 27
Joined: Mon Nov 12, 2007 1:35 pm
Location: ASSET InterTech, Inc./ USA
Contact:

Re: Defining SJTAG

Post by Adam W Ley » Wed Mar 21, 2018 3:58 pm

Thanks Ian. But doesn't our common practice as regards the use of "component" encompass boards and other such "aggregations" as well as atomic units?

From a post you made in "PAR scope and direction" not too long ago:
a component part of an assembly (e.g. a board within a sub-system) to be passed to that higher level assembly
I think the key point about (the very definition of?) inherent features is that someone other than the person specifying the component has implemented such features. Our standard(s) may be a means to leverage such features into such components to the benefit of these users??

User avatar
Ian McIntosh
SJTAG Chair
Posts: 405
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo MW Ltd, UK
Contact:

Re: Defining SJTAG

Post by Ian McIntosh » Wed Mar 21, 2018 7:54 pm

Touché, Adam :) .

You make a good point about "inherent features". I guess I was a little concerned about common interpretation of what "component" might imply. But it maybe doesn't matter anyway: It's probably only a very small step to extend any principles to an aggregation.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

Post Reply