PAR scope and direction

Discuss the generic proposals for SJTAG
User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Mon Apr 30, 2018 1:27 pm

I feel there is more involved than just a behavior description of interfaces (the green braces in my diagrams). There is the aspect of the behavioral description of the transformations inside the device as well mapping the right hand side back to the left hand side (the yellow braces in my diagrams). There is some overlap here with what P1687.1 and both 1149.1-2013 and 1687 do as far as describing behaviors to the instrument register, but STAM needs to address the behavior of how that instrument engages with the right hand side interface. This is an open/undocumented area the iNEMI BA-BIST project was attempting to define as a gap in the overall process. 1687 and 1149.1-2013 shows how to gain access and control the master instrument of the right hand side interface, but it does nothing to describe what can be done with this instrument beyond the instrument registers. STAM is a user of the instrument for a specific purpose that needs to be described in terms of manipulation of the instrument registers. The PDL for the instrument may give sufficient detail as to manipulating the register interface, but it is not guaranteed to be addressing the higher level behavior aspects of the external interface. STAM needs to define what capabilities have to be provided to the Master Instrument at a sufficient level to conform to the requirements STAM needs in order to perform the operations necessary on the right hand side interface through the instrument described by 1149.1-2013 or 1687. That is the leveraging aspect and enhancement STAM brings to these existing standards. It addresses some of the deficiencies identified by the iNEMI BA-BIST project. The existing standards fall short in showing HOW an instrument is being used or for WHY. STAM needs to address these questions to effectively use the instrumentation at the board level (and higher) beyond just stimulating the device interface for use cases such as ATE testing of the device.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

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

Re: PAR scope and direction

Post by Ian McIntosh » Mon Apr 30, 2018 2:52 pm

I agree that I've probably over simplified, but that was in a way deliberate in order to get a draft re-wording to talk around. We probably want to avoid over-elaborating in the Scope while making sure we still permit everything we need and my words don't really do the latter.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Mon Apr 30, 2018 4:13 pm

Here are the key points from today's meeting regarding the revised wording for the Scope section:
  • Original proposal with revisions proposed by Adam Ley:
    • This standard describes methods to 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.
  • Ian's proposal from forum:
    • This standard describes a manner of (format for?) providing conforming behavioral descriptions (of interfaces) and methods for utilizing those descriptions to allow, in conjunction with existing methods, ...
  • Reworked proposal from group discussion:
    • 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.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Heiko Ehrenberg
SJTAG Vice Chair
Posts: 45
Joined: Wed Nov 21, 2007 3:15 pm
Location: GOEPEL Electronics - Austin, TX
Contact:

Re: PAR scope and direction

Post by Heiko Ehrenberg » Tue May 01, 2018 11:23 am

- in this latest Scope draft, I wonder if “description“ is superfluous in the first sentence?
This standard: 1) defines a representation of conforming behaviors of interfaces and transformations, ...

- Should there be an “and” before 2) in the first sentence of this new Scope draft?

- in 2), should we add an “of”?
... enhance the test management of and access to ...
(Perhaps even leave “test” out of “test management” in that sentence?)
- Heiko

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

Re: PAR scope and direction

Post by Ian McIntosh » Sun May 06, 2018 6:34 pm

I think "descriptions" still forms a necessary part of detailing what is conforming but the comment does bring one other thing to my attention:
1) defines a representation of conforming behavioral descriptions of interfaces and transformations, ...
This seems to have the wrong subject: I'd argue that the behaviour is what it is and it is the description of that behaviour that we expect to conform, so I think this should read:
1) defines conforming representations of behavioral descriptions of interfaces and transformations, ...
Generally, I'd accept Heiko's other suggestions.

Is "transformations" adequately clear to an uninformed reader? Should that be expanded to say something like "transformations within devices"?
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Mon May 07, 2018 4:17 pm

Here are the revisions to the Purpose from the 7 May 2018 meeting.

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 a uniform description that focuses on topology, interfaces and behavior (as opposed to physical structure). The providers of these access mechanisms are people who produce components (chips or boards) 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.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

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

Re: PAR scope and direction

Post by Ian McIntosh » Sun May 13, 2018 7:08 pm

In the above, I think "access mechanisms" is the wrong subject - I think in the context here, we're really talking about the providers of the conforming descriptions (they may well be the providers of the access mechanism too, but it feels like we've confusingly switched context).

"Components", while not wrong, suffers in that many people will assume that components = devices, hence Terry's expansion in parenthesis, but it fells a bit stilted. I wonder if "components parts, including chips and boards, ..." works a little better.

In respect of Adams third point, I previously noted:
"Who benefits? I expect this is the designers/creators of any test, programming, etc., application, so that includes ATPGs (although I'm not sure if you'd express that as the ATPG benefitting, the ATPG vendor benefitting or the ATPG user benefitting. Or a combination thereof)."

I'd propose, to get the ball rolling, adding something like the following after the first sentence:
"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."
(Disclaimer: I make no claim this is anywhere near correct, but it hopefully sparks other ideas :wink: )
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Mon May 14, 2018 1:12 pm

Ian is right. Access mechanisms is only part of the design, but not what the provider is going to provide to the standard process. The provision is for the "conforming descriptions" as Ian stated it.

The term component is also troubling to me. Component parts is slightly better. But are we not really describing what the Initiative Team described as "assembly of assemblies?" In particular, are we not referring to digital assemblies with digital interfaces as stated in the scope? Is using the term "digital" too restrictive for the Purpose section?

So to try to aggregate all this together for a revised wording, I see the following:

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 a uniform description that focuses 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 people who produce digital assemblies 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.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Mon May 14, 2018 4:23 pm

Here are the revisions to the Purpose statement from the 14 May 2018 meeting:

STAM Purpose (14 May proposal):
  • 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 a uniform standardized descriptions that focuses 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 people who produce digital 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.
A further discussion needs to be held regarding the red colored words "devices or" found in the second to last sentence. At issue is the sentence is trying to provide the range of scope that standards using this Purpose will have to adhere to. Is the term "devices" a small enough unit of interaction for this family of standards or is it excluding the possibility of supporting cores or even IP blocks within a design. The term "device" may be used in a variety of ways that could and does include elements inside of a package. One point noted was the IEEE 1149.1 group debated about this very same subject and settled on the term "Entity" as their smallest unit of assembly to define in a BSDL file. However, the term "Entity" for STAM seems to be too loose of a term that we would feel comfortable to use in this case. Terms like "element" or "functional block" also don't seem to fit here. The generalized use of "device" seemed to fit with the group discussing the topic today. I would like to have a discussion on the forum regarding the terminology STAM should be using as the smallest level unit STAM will be supporting and to come up with a term that encompasses such a meaning. Please respond before next meeting.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

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

Re: PAR scope and direction

Post by Ian McIntosh » Mon May 14, 2018 8:13 pm

I'm wondering if we really have a "smallest unit"... If I go back to Brad's post on the previous page and the second diagram therein, we could be including the internal bridging between two interfaces within a chip, and we could also be dealing with the linkage between interfaces on blocks of IP within a FPGA/PLD. In other words, I don't think we have a defined boundary on any particular physical part (e.g. chip/die or package pins), more a conceptual boundary that may be on either the inboard or outboard side of any given interface. I think this is also reflected by Jeff Rearick's "Retargeting domains" slide from his presentation during our August 28, 2017 meeting. But I think at the PAR level, we want to avoid getting into any such esoteric discussion.

I'm not entirely satisfied that "devices and assemblies" really covers what we mean, but I'm reasonably content that it conveys, for the most part, the broad intent without getting into too fine grained detail.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Mon May 14, 2018 8:54 pm

Interesting insight...Ian.

So it appears we are describing interfaces as to how they interact and not really devices or assemblies per se as part of larger assemblies. The behavioral aspect of the assembly is not the device or assembly itself, but is the interfaces and how they interact.
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 sentence does not seem to be aligning us with the theme of interface descriptions. Perhaps a more aligned phrasing would be:
The providers of these conforming descriptions are the producers of digital interfaces that are intended to be used in an automated fashion within a larger assembly.
So the Purpose statement would read as:

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 digital interfaces that are intended to be used in an automated fashion within a larger assembly. This standard will also include a methodology to ensure access to particular destination registers in the correct time order.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

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

Re: PAR scope and direction

Post by Ian McIntosh » Tue May 15, 2018 6:15 pm

Are we sure that's right though? I think the "producers" we're talking about are probably not the creators of the interfaces (although that is possible) but instead are producers of some "part" that embodies one or more interfaces. I don't think that affects what the description is of, so I still lean towards the original text.

I think we're also missing something in that last sentence on what we mean by "used" - maybe needs tied into the applications mentioned in the second sentence.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

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

Re: PAR scope and direction

Post by Ian McIntosh » Mon May 21, 2018 8:07 pm

Collated material on "Need" (essentially a copy of Brad's slides: http://files.sjtag.org/StudyGroup/SG_Me ... subset.pdf)

STAM Need (pre-Study Group):
  • 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. For example, IEEE 1687 and IEEE 1149.1-2013 provide methods for describing each of the instrument interfaces on a per component basis, but do not 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. This standard will provide a means to utilize the pin level access provided by other standards.
  • Already know this doesn’t read well; probably too wordy.
STAM Need (May 21, 2018):
  • No real standard that captures aggregation of standards and management/coordination of such standards from a board or system test perspective
  • C/ATLAS provides common instrument interfaces, but no coordination
  • The standards at the device level are many and diverse regarding feature sets
  • STAM provides how to coordinate instruments and access them for the tooling. User needs to be able to tell the tool what they want to do with these instruments (the application use case)
  • Common denominator of device standards is test coverage (DC vs. AC vs. HS vs. RF)
  • Raise awareness of feature sets that we need to use for better resolution of diagnostics
  • Need to be able to resolve which subsystem is the location of root cause of failure as diagnostics (Single Field Replaceable Unit – FRU). Need to eliminate ambiguity of more than one subsystem identified. However, that is the purpose of the test application of which STAM provides access to sub-system to obtain better resolution of information to make a better decision. NEED TO HELP IMPROVE DIAGNOSTICS!
  • We have access to interface to device on the board, but not able to go down to the level we need to access in the device from the board to get the coverage we want.
  • IEEE1687 does not provide management between chip to chip at board level; only inside the chip (making standards more accessible to the board level)
  • Need to know dependencies required to provide the access
  • Need to know the constraints required on device pin interfaces for board/system applications
  • STAM becomes the glue bridging the individual standards so they become more than the sum of their parts
  • STAM enables an application to take place, whereas the leveraged standards are more about how you bring the data backwards and forwards
Initial collation of Need comments (January 29, 2018):
  • We should be looking to utilise any test features that exist within COTS items
  • We need better tools, but that requires that the tools can "see" the features that are available
  • Leveraging the interface standards is not the only way to do this
  • (I'm just copying the following directly from Brad's post as I couldn't see a better way of incorporating it here)
    • SJTAG is intended to improve the ability to test, diagnose and provide prognostic health information about systems.
      • (Analyze from top down in decomposition is necessary to be able to know what has to be exposed. How someone implements it is less important if it is clearly documented and usable. Testablilty “flow down” may be outside of SJTAG scope : Testability Framework Requirements. Available Testability “flow up” is what is advertised from the bottom up: Availability of Testability Features.)
    • A standardized method is needed to coordinate
      • (coordinate - exposure of underlying test capabilities that might exist?) (everyone puts testability at their level and don’t usually plan for use at a higher level) (Documentation of what is available at each level is key.)
    • component
      • (component could relate to discretes and not what we want)
    • access topologies,
      • (Board level BIST is more than a component access topology.)
    • interface constraints, and other dependencies at the board and system level
      • (Should really focus on system and sub-systems, which includes boards.)
    • 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.
      • (The higher up you go in the hierarchy, the more you morph into functional testing.) (Downloading code into modules and executing them is also part of this infrastructure that is needed.)
  • Specific interfaces are not really broad enough for the Needs statement
  • This standard recognizes the need for some form of standardized measurement of test coverage and quality of test, but this standardization effort does not attempt to address that need (Additional comment: As this, or words to this effect, describe an exclusion from the standard, it could become part of the stated Scope instead of the Need)
  • Should be inclusive of diverse Use Cases (and not preclude any), but should they be detailed in the PAR?
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Heiko Ehrenberg
SJTAG Vice Chair
Posts: 45
Joined: Wed Nov 21, 2007 3:15 pm
Location: GOEPEL Electronics - Austin, TX
Contact:

Re: PAR scope and direction

Post by Heiko Ehrenberg » Fri May 25, 2018 8:58 pm

Here is an attempt to put these "Need Statement" bullet points into sentences. The following would need quite a bit of word smithing, but perhaps it is a start ...

While many standards exists at the device level, with diverse feature sets, there is currently no standard that captures the aggregation of standards and the management/coordination of such standards from a board or system test perspective.
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.
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.
- Heiko

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

Re: PAR scope and direction

Post by Ian McIntosh » Sun May 27, 2018 7:40 pm

Seems like a fair start, Heiko, thanks.

Attempting to "wordsmith" the first sentence:
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.

I'm fairly happy with the rest, but I suspect we're probably still missing some bits.

You could argue that whenever we say "board and system level" we really mean "board and system level and everything in between" (or perhaps more formally, "board, sub-system and system levels"), but it may be getting too nit-picky.

Similarly, in the second sentence "test equipment" might be more narrow than we intend, but saying something like "test and support/maintenance equipment" might getting wordy for little added value. But it might be worth expanding to note that the "equipment" might be either embedded or external to the target. (Semantic question: If e.g. a shelf controller is performing a test on another board in a rack, then is the tester external to the UUT? - I ask because it might affect what we consider to be the UUT or target)
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

Post Reply