PAR scope and direction

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

Re: PAR scope and direction

Post by Ian McIntosh » Sun Mar 25, 2018 5:19 pm

Bradford Van Treuren wrote:
Wed Mar 21, 2018 9:10 pm
Adam Ley wrote:
To the whole, I think I'm aligned, also, though I do wonder about the use of articles in proximity to "system".
I am thinking the first article is referring to level and not system. To me removing the first the in Adam's proposal reads a bit awkward. Without the being present, IMHO, it does force the subject of the sentence to system and not level.
I'm not sure I agree with that assessment - I don't think anyone could read it that way because then you'd be left with the word "level" dangling so you'd know that's not right. In my view "the" could be either in or out, I'm not fussed.
Ian McIntosh
Testability Lead
Leonardo UK

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

Re: PAR scope and direction

Post by Bradford Van Treuren » Mon Mar 26, 2018 1:18 pm

to extend test access to the system level
We should discuss to what we are extending access to. If "level" is left off, I believe the meaning of the sentence is too weak. What is meant then as extending access to the system? Some could argue they already have access to the system for functional test. So what would be the need for STAM? I feel we are trying to explain STAM provides access to lower-level test features to the upper-levels. "System" is needing to refer to what level of access we are targeting and not to the system in general. Perhaps using a hyphenated "system-level" would clarify things.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

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

Re: PAR scope and direction

Post by Ian McIntosh » Mon Mar 26, 2018 1:25 pm

Am I missing something? I didn't think anyone had suggested dropping the word "level" (other than the re-phrasing of the end of the last sentence) - I thought it was only "the" that was in question?
Ian McIntosh
Testability Lead
Leonardo UK

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

Re: PAR scope and direction

Post by Ian McIntosh » Mon Mar 26, 2018 6:43 pm

Moving on to Purpose, we removed the clause on requiring the CSU cycle:
STAM 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 a uniform description that focuses on topology and behavior (as opposed to physical structure). By modeling this topology at the board and system level, a set of familiar and yet interchangeable interfaces may be used by higher level tools to coordinate these access topologies and provide a means of routing data sets to particular destination registers in the correct time order.
Ian McIntosh
Testability Lead
Leonardo UK

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

Re: PAR scope and direction

Post by Adam W Ley » Mon Mar 26, 2018 7:31 pm

Ian McIntosh wrote:
Mon Mar 26, 2018 1:25 pm
Am I missing something? I didn't think anyone had suggested dropping the word "level" (other than the re-phrasing of the end of the last sentence) - I thought it was only "the" that was in question?
That's the way I see it, Ian.

At any rate, I won't be fussed either way, but now your reprising of the Purpose brings in new phrasing for level ("the board and system level") == perhaps we should be consistent??

Also, with apology for pedantry, if there is a board level and a system level then there are (at least two) levels, so it should be stated as "board and system levels"? (once again, I would propose to drop "the", though I'm not stuck on it ... it just seems to me that no article is required and since we're dealing with somewhat indefinite abstractions then a definite article seems overstated, yet an indefinite article is clearly not suitable; kind of like how we don't use articles with some other such abstractions like "outer space"?)

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

Re: PAR scope and direction

Post by Bradford Van Treuren » Mon Apr 09, 2018 4:14 pm

Here is the content of the discussion held during the 9 April 2018 STAM Study Group meeting:

STAM Purpose:
  • The purpose of this standard is to provide a means to seamlessly integrate component access topologies (that follow a Capture, Shift, Update cycle), interface constraints, and other dependencies at the board and system level by using a uniform description that focuses on topology and behavior (as opposed to physical structure). By modeling this topology at the board and system level, a set of familiar and yet interchangeable interfaces may be used by higher level tools to coordinate these access topologies and provide a means of routing data sets to particular destination registers in the correct time order.
  • Need to ensure destination register is explicit
  • Destination register is part of the leveraged standard interface. STAM ends at the interface and not the register.
  • There is an implicit assumption that all entities of the system can be represented in a digital form for measuring.
  • Need caution when dealing with access to lower level interfaces as the interface may not be a standard interface.
  • Part of purpose is to provide a uniform way to define and access various interfaces. This ties in with SJTAG as we use the data register as the intermediary register to manipulate what goes into the register from various interfaces like we use 1149.1 to get into test data registers.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

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

Re: PAR scope and direction

Post by Ian McIntosh » Mon Apr 16, 2018 7:52 pm

The following revisions to the Purpose (intermediate and revised wording) and Scope were produced during the April 16, 2018 Study Group meeting:

STAM Purpose (intermediate):
  • The purpose of this standard is to provide a means to seamlessly integrate component access topologies (that follow a Capture, Shift, Update cycle), 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). By modelling this topology such at the board and system level, a set of familiar and yet interchangeable interfaces a uniform way to define and access various interfaces may be used by higher level tools to coordinate these access topologies and provide a means of routing data sets to particular destination registers in the correct time order.
STAM Purpose (revised):
  • 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 standard will include a methodology to ensure access to particular destination registers in the correct time order.
STAM Scope:
  • 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 the system level. 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 the system.
I'm aware that in the Purpose above, we haven't addressed Adam's grammatical concerns.
Ian McIntosh
Testability Lead
Leonardo UK

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

Re: PAR scope and direction

Post by Adam W Ley » Tue Apr 17, 2018 6:36 pm

Sorry that I haven't found more time to contribute more regularly or more substantially.

At any rate, being apart does give one the opportunity to look at the work product with fresh eyes ...

As I do so, I am struck that a person coming to these without context might not get much of what it's trying to propose.
Particularly:
  • what manner of "thing(s)" would claim conformance to the standard?
  • who produces this(these) thing(s)?
  • who uses this(these) thing(s)?
Well, that's all for now. Hopefully this is more than just a digression. And, hopefully, I can make some further contribution if others engage this line of inquiry.

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

Re: PAR scope and direction

Post by Ian McIntosh » Wed Apr 18, 2018 5:56 pm

These are good questions and I see how they're probably essential to explaining the purpose. Maybe the easiest thing to do is try to answer the questions and then work out how and where we can fit those in.
  • what manner of "thing(s)" would claim conformance to the standard?
    Or put another way, what are we standardising? We're clearly not standardising the interfaces but we are aiming to unify the descriptions of the behaviours of those interfaces and (I think) the behaviours of any routing mechanisms that exist between the source and destination of any data that needs to be transacted.
  • who produces this(these) thing(s)?
    Who will provides these standardised descriptions? Possibly the trickiest question to answer. Some interfaces might be sufficiently common that a tool vendor might be able to supply a generic description that their users could apply, but I suspect that mostly we'd have to rely on the device producers to provide them. That may mean that ECAD tools could be involved.
  • who uses this(these) thing(s)?
    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).
Ian McIntosh
Testability Lead
Leonardo UK

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

Re: PAR scope and direction

Post by Bradford Van Treuren » Wed Apr 18, 2018 7:54 pm

Jeff Rearick shared some interesting diagrams in the last P1687.1 meeting that relates to the STAM question "what manner of thing(s) does it standarize.
Image
STAM is looking at describing the behavior of the Device to Device interface and not specifically how it operates. In my understanding, STAM has to describe enough to know what may be applied to an interface and attempt to generalize the description to a series of commands able to be applied to the interface following a common behavior for all STAM compliant interfaces.
Image
This diagram shows there needs to be some sort of transformation of behavior from what is needed on the right hand side and what has to be provided on the left hand side to effect the necessary transactions between the two devices.

What can be standardized is a description of the behaviors of the interfaces as well as describing the transformation mapping from right to left. It probably is not just a simple template translation as there needs to be an understanding of when commands have to be applied and hand-offs for coordination between concurrent tasks. That is what the working group will need to resolve.

So my impression is STAM defines these two relationships and the behaviors of how they communicate.

Regarding the who:
  • For the transformation (second picture), the device vendor will have to describe this behavior
  • For the left hand side interface, the interface designer of the slave will have to describe its behavior using the standard defining its design (P1687.1, I2C, SPI, etc.)
  • For the right hand side, the interface design of the master will have to describe its behavior using the standard defining its design (P1687.1, I2C, SPI, etc.)
    For the board, the Test Engineer will have to describe the interface relationships shown in the first figure.
    For the system, the Test Engineer will have to describe the interface relationships shown in the first figure regarding system to sub-system topologies
For the who uses, Ian did an excellent job of describing that in his post.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

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

Re: PAR scope and direction

Post by Ian McIntosh » Wed Apr 18, 2018 8:02 pm

It took a few moments for me to spot the green braces versus the yellow braces in those diagrams, and was beginning to wonder if you'd accidentally linked the same image twice! :D
Ian McIntosh
Testability Lead
Leonardo UK

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

Re: PAR scope and direction

Post by Ian McIntosh » Fri Apr 20, 2018 7:18 pm

The challenge seems to be putting the "what" into a relatively concise form of words. I think it's permissible for a PAR to have attachments for diagrams, but I don't recall ever seeing that done.

I think we will always need the behavioural descriptions for the device-to-device interfaces, but there may be cases where the intra-device connection doesn't exist (or can be ignored). I'm possibly analysing the situation incorrectly there, but either way we can probably assume that the standard needs to address both for the purposes of the PAR.

Since Brad's post suggests that the descriptions we want, by necessity, come from different sources we actually have three types of interface description that any tooling would need to pull together:
  1. Description of the "master" behaviour in a device-to-device link,
  2. Description of the "Slave" behaviour in a device-to-device link,
  3. Description of the behaviour of the intra-device transformation.
So a description would conform if it fulfils any one of those. However, for a device such as 'device j', the device creator* would need to supply description 1 for Interface j2, description 2 for Interface j1 and description 3 for the internal transformation.
* I'm saying "creator" here rather than "vendor" because we might be talking about an entity that is created by firmware.

In part, this is probably getting into "detail", but I'm just trying to flush out what the PAR might need to say so we don't find ourselves backed into a corner further on down the road.
Ian McIntosh
Testability Lead
Leonardo UK

rpistor
SJTAG Member
Posts: 1
Joined: Mon Nov 20, 2017 2:12 pm

Re: PAR scope and direction

Post by rpistor » Mon Apr 23, 2018 7:57 pm

I found the usage of the expression "Virtual Test Bus" from the meeting today to be concise and resonate. I would like to see how that expression fits in the PAR/Scope. The what as I understand it is standardizing a Virtual Test Bus to bridge digital interfaces for test access.

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

Re: PAR scope and direction

Post by Bradford Van Treuren » Mon Apr 23, 2018 8:59 pm

The STAM study group meeting today focused on discussing the graphics I presented on the Forum. I will try to summarize the discussion later in this post.

Regarding a response to Adam's questions regarding the Scope and Purpose,
Particularly:
•what manner of "thing(s)" would claim conformance to the standard?
•who produces this(these) thing(s)?
•who uses this(these) thing(s)?
The group settled on the following decomposition as to where to address each question:
  • what manner of "thing(s)" would claim conformance to the standard? (In Scope?)
  • who produces this(these) thing(s)? (In Purpose?)
  • who uses this(these) thing(s)? (In Purpose?)
The conversation at today's meeting described the relationships between graphic 1 and graphic 2 that I presented on the forum site. The first diagram (the green braces) is describing the relationship between the right hand side of a device (master) interface and the left hand side (slave) interface of the device at a lower level. In spite of the interface being a physical interface, STAM needs to try to describe the behavior of its function in generalized terms common to all device-to-device interfaces used for test and control access on a board/system. The term "Virtual Test Bus" was thrown out to help describe this abstraction and to contrast it with IEEE 1149.5. Whereas, IEEE 1149.5 required the physical Module Test and Maintenance (MTM) bus, STAM needs to integrate the behavior of existing busses in a system that take on the same roles (and more) from what IEEE 1149.5 was assuming. IEEE 1149.5 could not get traction because it was requiring a yet redundant feature bus of systems. 1149.5 also dictated the way operations were to be performed. STAM needs to try to abstract out the behaviors of existing interfaces as to how they are used for test, measurement, and maintenance today. It also leads to providing an interface at the access level (board or system) to where stimulus and response data may be written/read from a higher level interface. This interface provides the correct stimulus and response required at the low level to achieve the desired goal. The device-to-device interface is not really a "Test Bus," but more a communications channel between devices following a deterministic protocol. As a communication channel , it is responsible for moving data between one device and another, and vice versa. That is the common behavior of all these types of interfaces. The "how" of the interface is what is different and is able to be described by an existing standard or by some other means (as it must be deterministic and repeatable). STAM would leverage the how to provide a description of what is to be transmitted and received over this interface.

The second diagram (yellow braces) describes the intra-device behavior of how the "master" side of the device (the right hand side) is stimulated or affected by actions performed on the left hand side interface (the slave side). Is this a pure template matching transformation? Perhaps, but more likely there are other factors affecting the operation of this behavior. For example, there may be timing requirements between when a command could be sent and received on the master interface (right hand side) that have to be accounted for when stimulating the device's slave interface (the left hand side). The transformation may also require more than one left hand side action to be performed before a single right hand side stimulus action is performed. These all have to be decoded in-order to ensure the proper sequence at the lowest level in the hierarchy is applied properly. This raised the issue of how does one propagate the transformations up the hierarchy until it reaches the access point or top of the hierarchy? Are all commands required to perform a task on the low level instrument to be retargeted/transformed for the entire sequence or should the tools process one command at a time per level and apply that segment of the overall patterns one at a time until all actions are requested and applied? It really depends on the model of your tooling. ATE equipment will probably desire complete processing of the requests as the retargeting/transformation process as the tool has to translate the actions to native language code to be applied. For embedded applications, the retargeting/transformation process has to happen real-time in a request-apply process decomposing a task into micro-tasks to achieve the desired goal. But then how to you roll back a change if an error is encountered?

We also discussed how use cases would be applied to this perspective. After discussion, we resolved that in most cases the application is trying to affect the state of a particular instrument or set of instruments that existed at the leaf nodes of the hierarchy. As such, the retargeting/transformation takes place at that lowest level and the stimulus/response required to achieve that change requires a rippling of requests of stimulus/response events to the next higher level to transform into stimulus/response messages able to be applied to its left hand side in order to create the desired stimulus/response events on the right hand side of the device. These higher level transformation devices are what STAM terms as "bridge devices." It is imperative that the rippling of stimulus/response requests and application correctly transforms to the appropriate actions at the next higher level in the hierarchy to allow for the proper stimulus/response actions at the lowest level.

It was further posed that in some cases an application would need information from the lowest level as a request from the top to know what branch to take next in a program. Further analysis reveals that the request is still targeting the lowest level in the hierarchy as part of the retargeting required to process the action. That request would still ripple back up through the hierarchy to be performed.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

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

Re: PAR scope and direction

Post by Ian McIntosh » Sun Apr 29, 2018 7:49 pm

I've only had time to consider Adam's first question, "what manner of "thing(s)" would claim conformance to the standard?", and even then only incompletely.

Given that the group believes this question is best addressed within the Scope, we begin the current version: "This standard describes methods to allow, in conjunction with existing methods, ...". I believe that "methods" is probably not an adequate detailing of what the standard would provide and that it may be better put as "a manner of providing behavioural descriptions (of interfaces) and methods for utilising those descriptions". Putting that into the form of the existing text, that might become:
This standard describes a manner of (format for?) providing conforming behavioural descriptions (of interfaces) and methods for utilising those descriptions to allow, in conjunction with existing methods, ...
Ian McIntosh
Testability Lead
Leonardo UK

Post Reply