PAR scope and direction

Discuss the generic proposals for SJTAG
Post Reply
User avatar
Michele
SJTAG Established Member
Posts: 31
Joined: Wed Nov 11, 2009 8:39 am
Location: Grenoble, France

PAR scope and direction

Post by Michele » Thu Dec 10, 2015 9:37 am

The PAR scope issue is twofold, as 1687 experience beforehand:
  • the main reason of the 7something years the WG took was that the PAR was too generic: no one really knew where the group was going. In this, we can exploit our discussions to understand WHERE we want to go, while the "how" will be decided by the WG itself;
  • ironically, 1687 was also hindered by some lines of the PAR that were far too specific. There were for instance an explicit reference to the 1149.1 TAP (http://standards.ieee.org/about/sasb/ne ... s/1687.pdf), which made it impossible to scope other possible solutions/extensions... and this is why the first 1687.1 will be about alternative interfaces. So I would not make a direct reference to ICL/PDL or it will came back to haunt us!
I propose we start by doing some sort of brainstorming about why we are in these calls and where we want to go. I will start:

For me, SJTAG is the solution to reuse and coordinate all the DfT infrastructure inside a system, using JTAG as the basic Access Mechanism. This means providing :
  • hardware guidelines for connecting together DfT features from physical or abstract (i.e. IP) devices;
  • an information flow able to collect DfT information from the basic devices and combine it into the system. If possible this will be done by reusing/extending existing languages, or by defining a new one of no suitable candidate exists.
  • an execution model able to assure not only vector delivery, but also debug and recovery actions, notably by reusing the DfT features of the composing elements (ex: accessing and executing 1687 instruments).

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

Re: PAR scope and direction

Post by Ian McIntosh » Thu Dec 10, 2015 9:40 am

Before anyone falls into temptation here (because I know it’s easy to do so), I’ll just give a reminder of one of the primary rules of brainstorming… Don’t criticise or discuss any of the suggestions until we have all the ideas on the board - even if they seem ridiculous they might in turn spawn a better idea. Only once we have exhausted the ideas can we start grouping and filtering them.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

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

Re: PAR scope and direction

Post by Ian McIntosh » Thu Jan 07, 2016 1:58 pm

My gut feeling is to concentrate on hardware aspects, perhaps the general topologies that we expect to support. The side benefit of that is that it provides a steer on how a system may be architected to best provide testability within the user's given constraints. I keep thinking of the notion of an "enabling technology" - what you need to do to make all the other things (which will largely be software and tools solutions) possible.
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 » Thu Jan 07, 2016 5:27 pm

I liked the direction Ian was taking the discussion in the Jan 6 meeting.
Ian referred to the ITC poster which stated SJTAG's goals as:

Make the "conventional" JTAG capability ACCESSIBLE through the system hierarchy
To EXTEND the JTAG capability to use cases beyond the "Conventional"
Provide COORDINATION between diverse standards for Data Links and Access Links

Were these goals something that could be built upon for a PAR? Does referring to "JTAG" limit us or cause inferences that may be misleading?

I guess something like:
This standard provides a way to make the "conventional" JTAG capability accessible through the system hierarchy allowing the extension of this JTAG capability to implement use cases beyond the "conventional". The purpose of this standard is to provide the coordination between diverse standards for the associated Data Links and Access Links to operate in cooperation with each other to fulfill a common purpose.

To achieve this, we may need to be more restrictive on the use of some of the standards in order to make it play nicely in the overall SJTAG architecture. For those areas, we will need to specify those restrictions specifically. I am not sure how to govern the cases where we need to loosen the other standard like IEEE 1687 did to IEEE 1149.1 in making a TDR a variable length. Comments?
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 » Mon Jan 11, 2016 4:26 pm

I agree that a hardware specification is probably the right topic for our base standard, with focus on the infrastructure needed to deliver the pattern to be applied to the respective use case one is interested in. I think our differentiation between control and data delivery and the associated, potentially separate, hardware infrastructure is key to the base standard.
I do wonder if "conventional" is going to be acceptable in the purpose of the PAR though. We may need to be more specific than saying "conventional", since that can mean different things to different people. One person may say that device programming is not a conventional use of JTAG, while another person might say that that is all they ever used JTAG for (so, one would consider this a conventional use case for JTAG while another may not).
- Heiko

User avatar
Peter.Horwood
SJTAG Member
Posts: 10
Joined: Fri Nov 16, 2007 9:24 am
Location: Firecron Limited, UK
Contact:

Re: PAR scope and direction

Post by Peter.Horwood » Mon Jan 11, 2016 5:35 pm

I too agree that the hardware is the place to start, with this topic requiring consideration. Do we specify standard 1149.1 to provide flexability in routing SJTAG round the system. Using other input comunication methods to the system would only be then required once which has many plus points.

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

Re: PAR scope and direction

Post by Adam W Ley » Wed Jan 13, 2016 3:02 pm

If I may offer a "meta" comment (as opposed to a comment directed toward specific "content"), I would propose that PAR discussion be directed at a PURPOSE that is expansive (the big picture), but at a SCOPE that is narrow (what we really can achieve in ~ 1-2 years).

The idea is that, as far as we can see, any "dot" standards would adhere to the same PURPOSE (which, as it happens, is actually no longer a required element of a PAR), but would have a distinct SCOPE = each SCOPE would be very carefully focused on just what can be achieved on that draft cycle.

NOTE: we might even want to consider that even the first standard is a "dot" standard (there's precedent for that, a la, 1149.1 :-), rather that thinking of it as a base ".0" that somehow anticipates all of the others ...

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 Jan 13, 2016 9:26 pm

The text I proposed was more in light of a PURPOSE statement to try to achieve a generalized statement. Adam put this into context. I like where Adam was headed. Each of the SCOPEs could narrow and should narrow the overall PURPOSE down to what needs to be considered for that part of the interface. I find it interesting and will have to look further into the discussion of a so called base standard starting with dot1 and not a base with no dot. Adam always manages to keep us honest and focused. Thanks, Adam.

I do see the general opinion of the responses have been to focus on the hardware aspects, but as Michele points out, we need to also consider the interfaces from a model or control perspective required for these hardware elements. We need to be very clear that we are not creating several disjoint dot standards that create additional modeling interfaces instead of leveraging on the same interface. I think this is where we have been going with the discussion on decoupling the access link requirements from the data link requirements. We also have to consider, not necessarily in dot1, how to leverage one of the existing SJTAG dot standards as a means for the access link for another standard. Our ultimate modeling should allow those kinds of architectures. I think this is where Ian was trying to go with his discussion on defining architecture instead of specific hardware levels and signals. It has to be a marriage of both hardware and architecture in the standard. The hardware is going to be specific to that particular SCOPE, but it is required to align with the overall architecture defined by the PURPOSE.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Adam W Ley
SJTAG Established Member
Posts: 29
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 Jan 18, 2016 9:36 pm

More meta ...

I did some poking around in the IEEE-SA eTools (myProject login required) and went deep enough into the "Submit a PAR" process (myProject login required) to get to the main form with all instructions (which I rendered in PDF here).

(While I haven't cross-checked it, the IEEE SA site also makes available a "Sample PAR Form for PAR Development (.docx)".

The PAR form describes the SCOPE and PURPOSE, respectively, as follows:

* SCOPE
The Scope should appear as it will in the draft standard.
The Scope stated on the PAR shall be written in present
tense, in complete sentences, and with proper grammar as
it is intended to appear in the published standard. All
acronyms shall be spelled out at first use. The title and (if
appropriate) date of any document referenced in the
Scope shall be listed in the Additional Explanatory Notes
field at the end of this PAR form.
* PURPOSE
A purpose statement is encouraged but not mandatory. If
the document will not include a purpose statement choose
"No" and leave the purpose field blank.
The Purpose stated on the PAR shall be written in present
tense, in complete sentences, and with proper grammar as
it is intended to appear in the published standard. The title
and (if appropriate) date of any document referenced in
the Purpose shall be listed in the Additional Explanatory
Notes field at the end of this PAR form.
As you can see, the PAR form also begs the question "WILL THIS DOCUMENT CONTAIN A PURPOSE CLAUSE?". In fact, despite the fact that it says that a purpose statement is encouraged, it doesn't even present the dialog box to enter the purpose statement until the submitter clicks the "Yes" selector ...

SO - it is quite clear that the PURPOSE is, in fact, optional ...
Last edited by Adam W Ley on Mon Jan 18, 2016 9:54 pm, edited 3 times in total.

User avatar
Adam W Ley
SJTAG Established Member
Posts: 29
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 Jan 18, 2016 9:52 pm

And still more meta ...

More information about the PAR process and other aspects of initiating a project can be found at:
- IEEE-SA | Develop Standards | SUBMITTING A PROJECT REQUEST (public pages)
- myTools: Resources for Standards Developers (myProject login required)

NOTE: the first step in the "Submit a PAR" process (myProject login required) is to "Select Working Group". Since no suitable working group presently exists, it will be required (when the time comes) to "request new working group" (which request can be made, and directed to the appropriate sponsor, C/TT in our case, I presume, using the link presented in the myProject system).

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

Re: PAR scope and direction

Post by Ian McIntosh » Tue Jan 19, 2016 6:12 pm

Thanks Adam.

I looks like you've gone through much the same process as I did some time ago (January 2009, by the looks of my files) although I actually proceeded to try to fill out the form (but not submit it, obviously). Clearly, some things have changed in the intervening time, so it's good to have an up-to-date overview!
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 Jan 19, 2016 9:50 pm

I have been reviewing the IEEE 1149.5 standard to see if I could figure out where they went wrong with their concept and lack of acceptance. I believe it was far too hardware specific and locked people into a closed (as Michele puts it) architecture. SJTAG needs to be more open (as Michele also points out). However, there are some good strategies 1149.5 started out with in concept that may have just been misdirected due to a fact that it was hardware people trying to solve a mostly software problem. I will try to use the adornments in the Wiki, but be patient with me if I get things all messed up.

The IEEE 1149.5 SCOPE states:
This document standardizes a serial, backplane, test and maintenance bus (referred to herein as “MTM-Bus”), consisting of one or more logic boards, that can be used to integrate modules from different design teams or vendors into testable and maintainable subsystems. (In this document “board” is used in a broad sense to mean an assembled, usually field-replaceable, unit immediately above the device-level in a system’s assembly hierarchy—e.g., assembled printed wiring boards, assembled multichip modules, etc.)
The bus protocol defined in this document standardizes a method for communication of test and maintenance commands and serial data between a subsystem test control module (MTM-Bus Master module) and the other modules (MTM-Bus Slave modules) on the bus. The MTM-Bus may be implemented as part of an overall test and maintenance interface architecture that includes other test buses.
IMHO, it is the mandating of the MTM-Bus as the only means to communicate in the system killed off this standard. Well, at least the primary root cause of the lack of acceptance. Industry already had far too many communications busses in a system. There are now GigE, SPI, I2C, Multi-drop JTAG, etc. that all perform a specific purpose of transporting data from one location to another in the system. Each of them use their own protocol and hardware interfaces, that on the outside, looks to be very disjoint. If you attempt to abstract the purpose of each of these interfaces, you have to realize the simplicity of data is being sent to a destination target based on some hardware interface following a specific protocol managing the control of that hardware. Some of these interfaces have actually had further protocols overlaid on top of them. For example, I2C has SMBus and PMBus layered on top of the I2C protocol stipulating further restrictions of the bus' use. ATCA uses the IPMI layered on top of I2C. So there is an aspect of the Physical Layer (what we have been terming the HW interface) and various protocol layers built on top of the Physical Layer to define specifically how that Physical Layer is used. This is where IEEE 1149.5 was starting to get things right, but focused on the wrong Physical Layer as it was too closed of an interface based on current industry implementations of the day.
IEEE 1149_5 Figure 1-5.PNG
The Physical Layer requirements specify the physical interconnections that comprise the bus. In 1149.5 they specified the physical interconnections, signal characteristics, and timing characteristics. That was too specific for SJTAG needs.

The Link Layer requirements specify the protocol features that permit error-free packet transfer between the MTM-Bus Master and one or more MTM-Bus Slaves. These features include serialization/packetization of information, parity generation and checking, and address recognition. The Link Layer also provides for the multiplexing of data and control functions on single wires.
This is corresponding more to what I have been terming as the Access Link. For SJTAG, we need to be able to support more than just one Physical Layer, but still keep the abstraction of the Link Layer standardized from a software interface perspective. This is similar to what the IP layer does for the ISO OSI model stack.

The Message Layer requirements specify the syntax for messages and identifies the functions that have to or can be supported by the MTM-Bus Master or MTM-Bus Slaves.
This layer is really the heart of what SJTAG is going to be about. This is where I think we can get hung up on various turf wars if we are not careful. For example, it could be interpreted as defining how to send messages to an IEEE 1687 network. Or it could be interpreted as how to send a message to a specific Test Data Register in a device, that happens to reside on an IEEE 1687 network. It is at this layer where we have to be very careful at how we define our SJTAG architecture that will allow us to evolve over time. If we are too narrow with our scope at this layer, we become too closed. If we are too broad, we may never reach a consensus or diverge too much with child standards. What we have to think about is whether this layer needs to be further decomposed for SJTAG so we can build upon specific application needs: much like we have TCP and UDP for IP and the layers built on top of them for a networking analogy.

The other key take away in reading the IEEE 1149.5 standard is the definition of a PORT.

Port requirements describe a set of recommended or permitted data sources/destinations (called ports) that may be useful in some S-modules. A port may be as simple as a register or as complex as an application interfacing this Standard to an on-module test bus. Data is transferred to/from ports during execution of Data Transfer class (15.1.1; clause 17) commands.

The important aspect I see with PORT is that it is an abstraction to a register as well as to an interface for some other application. The problem I have with the 1149.5 ports is they are specific ports with defined addresses reserved for each of their purposes/functions. For SJTAG, a port is really an abstraction of a destination as defined by the underlying transportation protocol used (e.g., the Access Link). For SJTAG, the address may be a specific index offset and range in an overall scan chain. It may be a specific register of a device that has its own address defined through the Link Layer. It may be a specific Test Data Register selected by a specific Instruction Register in a device. It may be a message port to a piece of software running on a board as a service using a specific TCP/IP or UDP/IP listening port. SJTAG needs to be able to handle all these cases. It needs to define the classes of PORT addressing and manage their use in the model.

Where do we go from here? Obviously, we don't want to repeat the mistakes the 1149.5 working group made. We also need to narrow our scope for each release to ensure we can get something done in the time allotted. At a minimum, we need to define dot releases for the various Physical Layers we have identified to date and define how each Physical Layer ties in with the corresponding Link Layer above it as well as how the Link Layer ties in with layers above it. The dot1 draft needs to begin to carve out what we mean by the Message Layer or what we come up with as the replacement concept as the 1149.5 is a bit too narrow. In dot1 we can also begin to introduce the concept of the PORT and how it is an abstraction for the destination for the data message. What we have to figure out is whether a PORT's address is part of the Data Link managed by the model or by the Access Link. That can be complicated as some Access Links include the addressing as part of the selection protocol. Whereas, other interfaces don't explicitly require the addressing at the Access level (e.g., an offset and range in a scan chain). Personally, I think it can reside in the Data Link and referenced per packet by the Access Link for cases where the Access Link requires that information. Where we are differing from a network applications is the System Model resides in a single place in our world. We have not been distributing the management to each entity in all of our discussions. Perhaps that is good. Perhaps that is a bad assumption.

I hope this helps get us back on track to developing a direction to pursue. We need more people to comment on this forum. So please don't be shy.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

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

Re: PAR scope and direction

Post by Ian McIntosh » Wed Jan 20, 2016 2:14 pm

I think the notion of a standardised test/maintenance bus is appealing to test/maintenance people - the idea that you only need one type of interface package to work on any piece of equipment is clearly attractive in terms of what you need to carry in your field kit. The flaw in that thinking is probably that the MTM Bus as conceived in 1149.5 adds no value for the operational use of the system and adds significant material overhead, in the presence of existing system buses that are perceived to be more capable and widely supported, so system designers (who don't always have test foremost in their minds) see little reason to factor it in. The appeal of JTAG (1149.1) is that it relies less on an assumed level of functionality and there is a broader degree of awareness of it having some "use" ("Ah! We can use that for re-programming. OK, keep it in the Test Connector"). But as Brad points out "other buses are available".
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

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 » Mon Jan 25, 2016 2:32 pm

I agree that the biggest danger is coming out with a YATS (Yet Another Test Standard): either we can immediately generate some added value or no one will follow. If I compare Brad's 1149.5 example and 1687, I believe the difference is clear: one the one hand we a clear, complete proposal (.5) that goes down to every detail, even too many, but does not seem to propose anything really new if compared to existing approaches. So, adoption remains extremely low. On the other hand we have 1687, that even with all its holes and limitations proposes new solutions to open problems. And people are already adopting it even though it barely came out.

So where is the "Killer application" for SJTAG?

Exactly in the direction Brad is looking at: finding an unified way to express existent behaviours and protocols to that they can interact and be reused easily and efficiently. I do not know if the direction of the .5 PORT is the right one (I did not know it before Brad's post), but it is the right frame of mind to follow. If you look at the work has been doing in these last years, it is indeed in this direction: by looking at different problems and existing solutions, we were able to curb out the details and identify the underlying common elements. I understood it when I started to work on my Engine: when I stopped sweating out the language details and I started to look at the abstract model, most of the solutions were already there for the taking once I took out all the "important" language details that in the end were useless. And once you understand what information is really needed and in what form, coming back to find a language/API to express it is easy!

IMHO, SJTAG should first of all focus on this task: defining the common abstract model (i.e. the "right information we need"), the execution model ("the right way to use it") to finally arrive to the informative part ("the right way to convey information"). These three things are what I would like to find in the PAR (with a better wording).

But I am the first one to admit that my priorities are probably biased by the work I have been doing!

Regards,

Michele

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

Re: PAR scope and direction

Post by Ian McIntosh » Tue Feb 02, 2016 6:34 pm

Summary so far:
  • SJTAG is:
    • Hardware guidelines for connecting together DfT features from physical or abstract (i.e. IP) devices
    • An information flow able to collect DfT information from the basic devices and combine it into the system
      • reusing/extending existing languages, or by defining a new one if no suitable candidate exists
    • An execution model able to assure not only vector delivery, but also debug and recovery actions
  • Concentrate on the general topologies that we expect to support
  • SJTAG Goals:
    • Make the "conventional" JTAG capability ACCESSIBLE through the system hierarchy
    • To EXTEND the JTAG capability to use cases beyond the "Conventional“
    • Provide COORDINATION between diverse standards for Data Links and Access Links
  • Differentiation between control and data delivery and the associated, potentially separate, hardware infrastructure is key
  • Do we specify standard 1149.1 to provide flexibility in routing SJTAG round the system?
  • Consider that even the first standard is a "dot" standard rather that thinking of it as a base ".0" that somehow anticipates all of the others
  • Need to consider the interfaces from a model or control perspective required for the hardware elements
  • Consider, not necessarily in SJTAG.1, how to leverage one of the AccessLink/DataLink interfaces to act as a bridging AccessLink to another standard (e.g., JTAG Bridge controlling an I2C Master).
  • IEEE 1149.5 was far too hardware specific
  • IEEE 1149.5 Message Layer is really the heart of what SJTAG is going to be about
  • IEEE 1149.5 PORT is an abstraction to a register as well as to an interface for some other application – a good direction to go
  • Must not be “Yet Another Test Standard”
  • Focus on:
    • defining the common abstract model (i.e. the "right information we need")
    • the execution model ("the right way to use it")
    • to finally arrive at the informative part ("the right way to convey information").
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

Post Reply