PAR scope and direction

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

Re: PAR scope and direction

Post by Ian McIntosh » Wed Jul 13, 2016 2:52 pm

I looked at the Purpose statement (in the post here: viewtopic.php?p=1140#p1140) and what struck me, reading it again after a substantial gap, was that it felt more like it was the simplified Need statement we want for the PAR!
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 » Wed Jul 13, 2016 4:25 pm

Ian's post prompted us to revisit the PURPOSE and the SCOPE with the goal to clarify exactly what each is responsible for as well as compare the existing proposals to that goal. Adam Ley provided some insightful aid via the WebEx chat that is captured below:

scope = what is included and what is excluded purpose= what you hope to accomplish by implementation\work out.
scope = what is included and what is excluded
purpose= what you hope to accomplish by implementation\work out.
(credit to answers.com)
Here's another, yet similar take (credit to stackexchange.com)
Purpose- It is the reason or aim for which something is done.
Scope- Scope refers to the extent of area or range a matter is dealt with.
proposed:
  • Scope is a broad take on what the standard Is/ Is Not
  • Purpose is directed at what the standard Aims for.
  • Need explores the Why
  • Look at it another way:
  • Scope answer these questions:
  • What is the standard?
  • What is the standard NOT?
  • Purpose answers this(these) questions:
    • What is(are) the aim(s) of the standard?
  • Need answers this question:
    • Why is the standard needed?
As a result, the SCOPE has been revised in coloring as shown to indicate the primary aim (the nouns) of the standard are "methods" and "descriptions." The "test interfaces" are the means that are exploited to get the work done.

SCOPE: This standard defines enabling methods to allow, in conjunction with existing methods, for the coordination and control of one or more (possibly different) device, board, and sub-system test interfaces to extend access to the system level. It also defines the architectural philosophy anddescription of such a system to allow better management of the test interfaces that exist when used at the system level.

Adam raised the question on whether the SCOPE was missing some sort of exclusion phrasing to enhance the description of what the standard is not intending to be. He made a suggestion of thought as example: The standard does not replace or provide an alternative to <name your favorite standard here>.

Adam suggested the next point as an example of what to put into the PURPOSE for this type of exclusion:
[PURPOSE for Exclusion]The aim of the standard is to reuse existing standards so as to exploit them in the system context

Brad noted that we should probably also think about adding:
Without defining the features inside each device (exploiting the existing standards)

Homework for this week is to review the SCOPE and identify if there are explicit exclusions we are missing and what they would be.
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 » Wed Jul 27, 2016 4:22 pm

In today's meeting we revisited the questions Adam gave us for clarifying how to view the SCOPE, PURPOSE, and NEED statements.

The SCOPE shaped up to the following text:
SCOPE: This standard 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. The standard does not replace or provide an alternative to existing test interface standards, but aims instead to leverage them by defining a description to better manage how they are used in the system.

Please review the new SCOPE and provide your feedback. The goal of the revision was to address the questions:
  • What is the standard?
  • What is the standard not?
With the suggestion Ian made on a previous forum post, we moved the current PURPOSE over to become the new NEED section for the PAR as it better addressed the question Adam proposed of, Why is the standard needed? The new NEED section has now become:

NEED: 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. IEEE 1687 and IEEE 1149.1-2013 provide methods for describing each of the instrument interfaces on a per component basis, but fail to 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.

The question relating to the PURPOSE is: What is(are) the aim(s) of the standard?
To begin that thought process we began to brainstorm about the aims we are looking for and came up with this preliminary list. Please review what you feel you need from the standard to address your own aims before next meeting.
  • PURPOSE:
  • Seamless Access
    • system, board, device meld into a uniform description (Abstraction of “Assembly”)
    • Metamorphosis into a common interface description
    • A delineation between topology and physical structure (topology is more important to SJTAG) (Behavioral aspects than structural)
  • Problem Domain (what we are trying to do)
    • Inadequacy of existing standards
Please respond on the forum with any ideas you come up with. This is brainstorming so no idea is a bad idea. Thanks.
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 » Thu Jul 28, 2016 3:54 pm

Based on hints given in the scope and need statements, I'd propose something along the following to be part of the purpose statement:
The purpose of this standard is to provide a means to coordinate component access topologies, interface constraints, and other dependencies at the board and system level based on a common interface description with focus on topology and behavior (as opposed to physical structure).
- Heiko

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

Re: PAR scope and direction

Post by Ian McIntosh » Tue Aug 02, 2016 6:46 am

This is slightly tangential to the current discussion, but I'm dropping it in here as an aide memoire for the next call...

There have been several new membership requests for the SJTAG LinkedIn group over recent weeks, many are names I don't recognise and from a range of companies: PLX Technologies, Intel, Fujitsu, etc. To be honest, I'm surprised people are even finding the group!

We've mainly used LinkedIn to promote our Newsletters/Green Papers so the group there has been very quiet lately and I feel the need to "throw them a bone": We have talked about issuing a Newsletter to present the draft of our Scope, Purpose and Need, but maybe we could drip feed these individually as posts to the LinkedIn group?
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 » Tue Aug 02, 2016 12:40 pm

Heiko wrote:
The purpose of this standard is to provide a means to coordinate component access topologies, interface constraints, and other dependencies at the board and system level based on a common interface description with focus on topology and behavior (as opposed to physical structure).
This is probably a sentence we should start with in the next meeting, but I do sense there is information we are missing that needs to be added. For example, we need to emphasize the point that we are trying to identify the common aspects of the problem domain to be able to exploit the "common interface description" concept. Our goal is abstracting out the differences and delegating those differences to the underlying interfaces at the same time identifying the features that are in common (e.g., addressing, access link connection, data link transmission) to be able to simplify the way tools interact with the various standards being leveraged.

So there are going to be two aspects we need to describe: 1) the end user's perspective, control, and operation of the "networks" as a description of the topology and behavior and 2) the description to the tooling what kind of access links and data links are used for a particular scan segment representing a portion of the whole configuration. I personally feel this latter description is going to be the most difficult as it needs to identify a means to accurately describe the connection to the embodied standards being used. In 1687, the ICL seems to try to handle this latter interface where the PDL is attempting to handle the former. However, ICL is far too involved with the physical structure of the network for what we in SJTAG are needing to address. We really only need to describe the access mechanism to the device interface that is fully described by other standards from the device interface to the data register.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

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

Re: PAR scope and direction

Post by Ian McIntosh » Wed Aug 03, 2016 8:15 am

Bradford Van Treuren wrote:... but I do sense there is information we are missing that needs to be added.
I think that's a given. We only just scratched the surface last week and the bullet points above were just what we could collect in the last few minutes of the call.
I think "Seamless Access" describes the aim in the broadest sense but it needs to be refined into a set of more specific aims that the reader can assimilate.
"Problem Domain" gives me a sense of "what"/Scope, so I'm not sure that provides the "aims" of the project but it may offer the context for the aims.
With regard to 2) in Brad's post immediately preceding, I think what we're hoping to do is treat the interfaces (access links, data links) as "black boxes"; we define what needs to be transacted and when, with the how being left the standard defining the interface and the creativity of the tooling, so we're aiming to be abstract from and agnostic to the specifics of the interface. We're concerned with the board and system level "routing" of control and data and use cases end up being largely irrelevant because once you can readily control and route data you can implement any use case you can imagine.
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 » Wed Aug 03, 2016 12:35 pm

Ian wrote:
We're concerned with the board and system level "routing" of control and data and use cases end up being largely irrelevant because once you can readily control and route data you can implement any use case you can imagine.
I find this quite interesting as it proposes no difference between the pre-computed vector based use cases and the dynamically created vectors of interactive use cases. The value added by the tool vendor that distinguishes them from another tool is the way in which they manage the application of the data and the topology. One vendor might rely on the traditional perspective of a global retargeted vector whereas another vendor might compose the vector on-the-fly as vector segment applications like Michele and I proposed. SJTAG is responsible for describing how the system and board "routing" (as Ian described it) is implemented. How you manage that routing is up to the tool vendor. I think of the analogy of the difference between an Ethernet HUB and an Ethernet SWITCH. They both route packets of information from a source to a destination. One is more efficient than the other as it intelligently routes the packets to where the destination resides and not to all paths. That is a value add in terms of performance and power management. The end aim is the same, but the implementation is significantly different. From a description perspective, the routing tables are the same, but the SWITCH has additional data it manages as to where a destination resides and on what port communication with that destination is performed. SJTAG is describing the equivalence of the "routing table" for a system. How that is used and interpreted is up to the tool vendor.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

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

Re: PAR scope and direction

Post by Ian McIntosh » Wed Aug 03, 2016 1:33 pm

Bradford Van Treuren wrote:I find this quite interesting as it proposes no difference between the pre-computed vector based use cases and the dynamically created vectors of interactive use cases.
I'm not sure if that's a "plus" or a "minus" when everything shakes out, it's just my view of what I think we've been suggesting. What does it do to "portability" if tool vendors take different approaches? Is "portability" still one of our aims?
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 » Wed Aug 03, 2016 2:08 pm

The issue is the order in which the data is applied to the target must be the same no matter what method of application the tool uses in order to be compliant to SJTAG. The real issue for me in portability is ensuring each of the individual segments (e.g., 1149.1 branches, I2C branches) are applied to the target with the changes made in the same order between the tools. This is a struggle that 1687 has right now with concurrency. It seems possible that different tools could apply concurrent threads in different orders.
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 » Wed Aug 03, 2016 4:23 pm

One item from the meeting today is for everyone to review the current SCOPE and provide a response as to whether you approve the current SCOPE or disapprove. You can find the latest version listed on this forum.

In the meeting today we fleshed out more brainstorming topics for the PURPOSE paragraph. The latest points identified are as follows:
  • PURPOSE:
    • Seamless Access
      • system, board, device meld into a uniform description (Abstraction of “Assembly”)
      • Metamorphosis into a common interface description
      • A delineation between topology and physical structure (topology is more important to SJTAG) (Behavioral aspects than structural)
      • Our goal is abstracting out the differences and delegating those differences to the underlying interfaces at the same time identifying the features that are in common (e.g., addressing, access link connection, data link transmission) to be able to simplify the way tools interact with the various standards being leveraged.
      • treat the interfaces (access links, data links) as "black boxes“
      • concerned with the board and system level "routing" of control and data
    • Problem Domain (what we are trying to do)
      • Inadequacy of existing standards
      • Aspects
        • the end user's perspective, control, and operation of the "networks" as a description of the topology and behavior
        • the description to the tooling what kind of access links and data links are used for a particular scan segment representing a portion of the whole configuration
      • Problem Domain may offer the context for the aims
      • we define what needs to be transacted and when, with the how being left to the standard defining the interface and the creativity of the tooling
      • use cases end up being largely irrelevant because once you can readily control and route data you can implement any use case
      • “routing” proposes no difference between the pre-computed vector based use cases and the dynamically created vectors
      • Bridging between an embedded environment and an external tool for deciphering the results (interchangeability between execution and diagnostic environments)
Please review these bullet points and identify items that are missing, wrong, or incomplete from what you feel SJTAG is aiming to achieve. A second action is to begin to refine these bullet points into sentences we may use to accompany the text Heiko provided earlier for the PURPOSE.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

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

Re: PAR scope and direction

Post by Ian McIntosh » Tue Aug 16, 2016 6:25 pm

I know we address "what we are providing" in the Scope, but should the Purpose/aims be offering some suggestion of how we see what we are offering being used, how industry may exploit it? I think that may be a difficult thing to explain concisely, as we're not presenting a fully worked solution, more a set of templates from which you "roll your own solution".
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 » Wed Aug 17, 2016 9:30 pm

In today's meeting we added some bullet points. I will post just the added points in this message.

PURPOSE:
  • Seamless Access
    • how industry may exploit it?
  • Problem Domain (what we are trying to do)
    • Aggregation of circuit boards (w/ varying protocols e.g., 1149.x, 1687, I2C, USB, SPI)
    • Trying to create a software abstraction to the existing hardware standards
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 » Wed Aug 24, 2016 4:11 pm

The following is the paragraph developed during the meeting today as the proposed new PURPOSE statement. It is a very, very rough draft to be reviewed. There were only four of us on the call today, so we could sure use your feedback on the forum before next meeting. Thanks.

The purpose of this standard is to provide a means to seamlessly coordinate integrate component access topologies, interface constraints, and other dependencies at the board and system level based on with a common interface uniform description with that focuses on topology and behavior (as opposed to physical structure): a “black box”. This integration requires coordination between these access topologies (communication interfaces) to provide a means of routing data sets to particular destination registers in the correct time order. The primary aim of this standard is to model the board and system domains in such a way as to allow for common sets of interfaces to route the data to the target registers.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Michele
SJTAG Established Member
Posts: 31
Joined: Wed Nov 11, 2009 8:39 am
Location: Grenoble, France

Re: PAR scope and direction

Post by Michele » Wed Aug 31, 2016 2:24 pm

There is one point I would like to add to the Interface discussion. IMHO there is one misleading point that is making things more difficult: all discussions focus around the "entrance" block, trying to define all interface/protocol issues so that we can then access the "raw" logic that is behind. Passing from "protocol" to "raw" is the big difficulty". But if you analyse with care the right-hand side, you will realize that this not not "raw" at all: as long as we stay on the JTAG domain, we are imposing a memorization protocol based on the shift register: Capture-Shift-Update. This is mirrored in PDL by the iApply cycle: all iWrites (U) are deferred to the following scan operation (S), which takes care also of refreshing the iRead/iGet buffers (C). The role of the Interface is therefore not of defining from scratch a complete transmission protocol, but rather to provide a translation. So, for instance, a SIR operation causes a CSU cycle on the IR chain of a TAP, while an SDR causes a CSU cycle on the DR chain. Similarly, in address-oriented access like I2C you can add @ decoding to identify the chain. I have it working in my MAST software, when you look at it this way it is not too complex to implement.

This means that the abstraction of the Interface is much simpler as you just need to describe how it can trigger CSU cycles to a given chain. This of course means that any register on the right side remains CSU compliant: for I2C and SPI this is pretty simple because you can emulate a CSU by a Read followed by a Write. This point of view is high-level enough that it completely abstracts from the actual implementation of the Interface, which I believe is one of the points 1687.1 is putting the most effort into. So whatever architecture comes out from there, it will still be describable in this way.

Things would indeed become much more complex if you decided to remove the requirement for CSU from the right-hand side .... but this would means renouncing to PDL and define a whole new language for vector application!

Post Reply