PAR scope and direction

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

Re: PAR scope and direction

Post by Bradford Van Treuren » Fri Apr 08, 2016 10:05 pm

Here is my draft of a new SCOPE.

To provide a standardized enabling technology to extend device, board, and system level test interfaces for access at the system level; providing the coordination between diverse standards to fulfill a common purpose.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

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

Re: PAR scope and direction

Post by Ian McIntosh » Sat Apr 09, 2016 7:50 pm

Bradford Van Treuren wrote:... and system level test interfaces for access at the system level;
Is that perhaps redundant? Might it not be taken as given?
Bradford Van Treuren wrote:... to fulfill a common purpose.
Is that too loose/vague? I know we don't want to lock ourselves into a tight definition of the use cases, but perhaps this goes too far the other way.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Ian McIntosh
SJTAG Chair
Posts: 395
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 11, 2016 9:32 am

I've been thinking about "Need" for SJTAG. I don't have this in a form of words for a PAR, but I also think that we might each see "need" slightly differently depending on our own perspectives; what we each see as shortfalls in the status quo.

Rather than think about why we need a PAR, I've been considering "why we need SJTAG" - it's almost the same thing, but maybe changing the focus makes it easier to think about.

For me the "need" arose from a lack of any objective guidance on what makes a usable system level JTAG scheme. JTAG tool vendors can only provide sketchy advice because they don't know what chain management device you're likely to use (though they can be more helpful once you've decided) and the device vendors are, understandably, only interested in presenting their vision of how to use their devices and even then it can become more vague once you go beyond the board edge. So that is mainly an educational or "best practice" thing on physical architecture.

I think once you get there, you can go to software/tools to enhance what you can do, but if you don't make that first step you won't get anywhere.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

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

Re: PAR scope and direction

Post by Bradford Van Treuren » Wed Apr 13, 2016 5:27 pm

During the meeting we took a crack at editing the Scope statement. Here is the evolution of the process from the meeting for people to comment on:

Slide 1: Initial proposal by Brad
SCOPE: To provide a standardized enabling technology to extend device, board, and system level test interfaces for access at the system level; providing the coordination between diverse standards to fulfill a common purpose.

Slide 2: Rework of Slide 1
SCOPE: This standard provides enabling technology methods to extend device, board, and sub-system level test interfaces for access at the system level; providing the coordination of operations between diverse standards/specifications/protocols to fulfill a common purpose (need to state what the purpose is: enabling interfaces, provide coordination).

Slide 3: Proposal by Heiko with group rework
SCOPE: This standard provides enabling methods for coordination between diverse device, board, and sub-system test interfaces to extend test access at to the system level.

Please comment on the versions presented during the meeting so we can establish a crisper SCOPE and begin to work on the PURPOSE and NEED.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

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

Re: PAR scope and direction

Post by Ian McIntosh » Thu Apr 14, 2016 6:49 am

Heiko's form is certainly more compact and maybe easier to read.

"Enabling" is a key word in this for me. I don't think the standard(s) should be about providing all the solutions but providing the foundations on which the end users and tool vendors can readily build the solutions. With that in mind, I might suggest that "enabling methods for coordination between diverse [...] test interfaces" may be too limiting for our scope (given Adam's guidance that the standard should not cover more than the scope describes but may cover less). I feel there are things we need to have to enable system test that are e.g. architectural/physical rather than just "coordination".
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

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

Re: PAR scope and direction

Post by Bradford Van Treuren » Thu Apr 14, 2016 4:49 pm

I think Ian is correct in his thoughts about "coordination" alone may be too limiting for what we need to endeavor. I tried to spend some time reworking what Heiko proposed to see if I could capture the idea. It still seems awkward to me, but at least it is something people can throw stones at to improve.

SCOPE: This standard provides enabling methods to allow for the coordination between and control of diverse device, board, and sub-system test interfaces to extend access to the system level. The standard needs to define the architectural philosophy and description of such a system to allow tooling to better manage the various test interfaces that exist when used at the system level.

I added the aspect of control of the test interfaces as I felt that was also missing. By architectural philosophy, I am meaning that we need to educate what works and does not work and why as well as define the best common practice methods and perhaps require to introduction of some new hardware elements to bridge gaps not currently covered by today's technology and methods. This philosophy will need to be described to the tooling in such a way that it can understand how to manipulate the test interface into doing what it needs to do. The word philosophy may not be the best choice of word here.

What is not clear to me is whether the test interface represents the underlying test standard technology (e.g. 1687, 1149.1-2013, 1149.1-2001) or represents the Access Link to such standards (e.g., JTAG, I2C, SPI). Should separate dot standards be used to describe the interfaces to each leveraged standard or should the dot standards specify how to control and use different Access Links to each leveraged standard? I am not convinced we can do all this in a single standard.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

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

Re: PAR scope and direction

Post by Ian McIntosh » Fri Apr 15, 2016 7:09 am

A question: The PAR is written ahead of the standard, but the Scope is copied (verbatim?) to the standard, so does that affect the form of words used? Should "The standard needs to define ..." become "The standard will define ..." (a more positive statement of intent) or "The standard defines ..." (a statement of fact)?
Bradford Van Treuren wrote:What is not clear to me is whether the test interface represents the underlying test standard technology (e.g. 1687, 1149.1-2013, 1149.1-2001) or represents the Access Link to such standards (e.g., JTAG, I2C, SPI). Should separate dot standards be used to describe the interfaces to each leveraged standard or should the dot standards specify how to control and use different Access Links to each leveraged standard? I am not convinced we can do all this in a single standard.
I think we want to avoid citing any specific interface or standard as that will become a limiting factor and potentially lead to the kind debate 1687 had over whether or not they were bound to "1149.1 only" by their Scope. I have the notion that the "base standard" should probably be about "what" you need to do to be SJTAG compliant (or SJTAG compatible - I'm not sure if that's 'either' or 'both'), while the "how", which can include dealing with specific interfaces, can be in appendices or extension standards. It would seem proper that an extension standard might limit it's scope to a single interface/protocol.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

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

Re: PAR scope and direction

Post by Bradford Van Treuren » Wed Apr 20, 2016 4:02 pm

Here is the text for the SCOPE we settled on in the meeting today:

SCOPE: This standard defines enabling methods to allow 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 and description of such a system to allow better management of the test interfaces that exist when used at the system level.

As we discussed. The SCOPE needs to define the "WHAT" of the work that needs to be done in a way that is not too broad and yet not too restrictive.

If you are inclined to work on posting a draft of the PURPOSE to the forum before next meeting, please keep in mind the PURPOSE is suppose to be a couple sentences that describe more of the "WHY" we need to work on such a standard.

Be thinking about the "NEEDS" section regarding the description of what is wrong with the methods used today and how they can be improved by the creation of this standard.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

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

Re: PAR scope and direction

Post by Ian McIntosh » Thu Apr 28, 2016 10:34 am

Michele's feedback from VTS indicates that we're not clearly communicating 'why' we need SJTAG and 'who' benefits. These are fairly fundamental points and distilling the key elements for both probably goes a long way towards defining our purpose.

The 'who' is something we've considered before and is probably captured in this diagram:
UseCases.jpg
Use Case Diagram
We maybe don't have anything equivalent to describe 'why' but I guess it partly exists in this:
Universe.png
SJTAG Universe
Both are now "old" diagrams so may not accurately reflect our current views and of course we can't include diagrams in the PAR, so the challenge is maybe trying to get the ideas these represent (corrected as necessary) into a concise form of words.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

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

Re: PAR scope and direction

Post by Bradford Van Treuren » Tue May 03, 2016 1:21 pm

I took a stab at creating a paragraph for the NEEDS section. I hope it will trigger some ideas about other deficiencies with the current process.

As signals get faster on boards, there is a need to use alternate test techniques from the traditional continuity testing that was originally supported by IEEE 1149.1. IEEE 1149.6 was developed to handle the case for AC coupled signals that were not testable by 1149.1 DC tests. High Speed Serial IO (HSIO) presents yet another problem in that 1149.6 does not address the needs for testing these signals. As such, special Bit Error Rate Test (BERT) techniques have been employed to test these signals at-speed to verify the signal integrity on the board. These tests, and others, requires special instrumentation to be implemented in the source and destination components wired together. Thus, there is a need to coordinate the configuration of such component ports and instrumentation to allow for such things as a loop-back configuration in the destination component and a BERT instrument connected to the port in the source component. There may be a single BERT instrument shared for each port being tested from the source or there could be a dedicated BERT instrument for each port. IEEE 1687 and IEEE 1149.1-2013 provide methods for describing each of the instrument interfaces on a per component basis, but fails to provide the contextual prerequisites for the dependence on each instrument configuration for the overall board test operation. To complicate the issue further, many components only support an I2C or SPI interface access to its instrumentation registers. There needs to be a supervisory standard that is responsible for defining the coordination and dependencies of instruments along with coordinating the aggregation of component access topologies at the board and system level to be able to effectively leverage the existing and future component level standards.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 395
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 03, 2016 2:17 pm

Thanks for starting the ball rolling Brad.

On a first reading, I'd wonder if the example given maybe comes over as defining a specific scope or applicability - it feels to me like it's making the need seem particularly narrow :?
Bradford Van Treuren wrote:IEEE 1687 and IEEE 1149.1-2013 provide methods for describing each of the instrument interfaces on a per component basis, but fails to provide the contextual prerequisites for the dependence on each instrument configuration for the overall board test operation. To complicate the issue further, many components only support an I2C or SPI interface access to its instrumentation registers. There needs to be a supervisory standard that is responsible for defining the coordination and dependencies of instruments along with coordinating the aggregation of component access topologies at the board and system level to be able to effectively leverage the existing and future component level standards.
This seems to be the key, and more generalised, part of Brad's text, and what preceded was more explanation of a particular case.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

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

Re: PAR scope and direction

Post by Ian McIntosh » Wed May 04, 2016 3:46 pm

I just realised that misread the intent of Brad's post... I was reading it as if it was for "Purpose", not "Need" as Brad intended :oops: .

However, I still think the part that I extracted above is relevant to Purpose. I have the sense that Need is expected to be relatively concise and possibly identify who benefits, e.g. Tools vendors need it to simplify how their tools acquire the necessary design data, test developers need it to simplify how they implement their test strategies, etc.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

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

Re: PAR scope and direction

Post by Heiko Ehrenberg » Wed May 11, 2016 2:58 pm

I agree that the extracted text would be a good start for our purpose statement, should we decide to include one in our PAR (as the Purpose statement is now optional).
Perhaps it would make sense to also bring 3DIC test (P1838) into the mix, as they define themselves as a die-centric standard that doesn't concern itself with stack-related issues. The die stack can be considered a system and may fall within the SJTAG scope.
- Heiko

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

Re: PAR scope and direction

Post by Bradford Van Treuren » Wed May 11, 2016 4:15 pm

In the meeting today we discussed the PURPOSE section. This is what we settled on:

PURPOSE: 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 or system maintenance operations. Further, many components only support non-JTAG interfaces (e.g., I2C or SPI) to their instrumentation registers. There needs to be a supervisory standard that is responsible for defining the coordination and dependencies of instruments as well as configuration, management, and application of vector based testing at the board and system levels. 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.

We started with the quote from the NEED section that Ian highlighted from Brad's proposal. The section in RED is the basis used for the discussion on the PURPOSE today.

NEED: As signals get faster on boards, there is a need to use alternate test techniques from the traditional continuity testing that was originally supported by IEEE 1149.1. IEEE 1149.6 was developed to handle the case for AC coupled signals that were not testable by 1149.1 DC tests. High Speed Serial IO (HSIO) presents yet another problem in that 1149.6 does not address the needs for testing these signals. As such, special Bit Error Rate Test (BERT) techniques have been employed to test these signals at-speed to verify the signal integrity on the board. These tests, and others, requires special instrumentation to be implemented in the source and destination components wired together. Thus, there is a need to coordinate the configuration of such component ports and instrumentation to allow for such things as a loop-back configuration in the destination component and a BERT instrument connected to the port in the source component. There may be a single BERT instrument shared for each port being tested from the source or there could be a dedicated BERT instrument for each port. IEEE 1687 and IEEE 1149.1-2013 provide methods for describing each of the instrument interfaces on a per component basis, but fails to provide the contextual prerequisites for the dependence on each instrument configuration for the overall board test operation. To complicate the issue further, many components only support an I2C or SPI interface access to its instrumentation registers. There needs to be a supervisory standard that is responsible for defining the coordination and dependencies of instruments along with coordinating the aggregation of component access topologies at the board and system level to be able to effectively leverage the existing and future component level standards.

Please review the new PURPOSE statement and advise of required or necessary changes. Also, indicate if there are missing features that have not been addressed by the PURPOSE. We would like to complete the PURPOSE section next week.

Please also begin to look at the NEED text and suggest changes that are needed to complete it as well. This dialog may be started using the forum to save us some time next meeting. Thanks.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 395
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 17, 2016 8:30 pm

My comment relates to both Purpose and Need:
Are these too "instrument centric"? Might these statements turn-off people who feel they want something for system level but don't feel or don't recognise that they're using "instruments"?

I think I'm just questioning the particular terminology - I think the general form/intent of the Purpose statement is correct.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

Post Reply