Minutes of Weekly Meeting, 2016-07-13

Meeting called to order: 11:06 AM EDT

1. Roll Call

Ian McIntosh
Eric Cormack
Adam Ley
Brian Erickson
Brad Van Treuren
Heiko Ehrenberg
Peter Horwood (joined 11:07)

By Proxy:

Carl Walker

2. Review and approve previous minutes:

  • Approval of July 6 minutes (draft circulated 07/06/2016).
    • No corrections noted.
    • Eric moved to approve, seconded by Heiko. No objections or abstentions.

3. Review old action items

  • All: do we feel SJTAG is requiring a new test language to obtain the information needed for diagnostics or is STAPL/SVF sufficient? See also Gunnar's presentation, in particular the new information he'd be looking for in a test language (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
  • Ian: Add the previously discussed lists to the 'master' template. Ongoing.
    • Some sections need further expansion that may take time to develop.
  • All (those not on the call today): Confirm that you are satisfied with the updated Scope. Comments to be posted to the forums (http://forums.sjtag.org/viewtopic.php?p=1155#p1155).
    • No comments received, all assumed to be in agreement. COMPLETE.
  • All: Re-familiarise with Purpose prior to next meeting. Discussed in section 5. COMPLETE.

4. Reminders

  • Consider Adam's three points (from the action from the first weekly meeting) and suggest what is preventing us from answering those questions:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • Forum thread for discussion: http://forums.sjtag.org/viewtopic.php?f=3&t=172
  • The Newsletter was due at the end of July 2015.

5. Discussion Topics

a. Continue PAR discussion
- Review "Purpose" statement

  • The intent was to re-visit the Purpose in the same manner as the last meeting had reviewed the Scope.
  • {Brad shared Slide 22 as a copy of the Purpose for editing}
  • Ian's comment was that the Purpose perhaps read more like a Need. Brad agreed that the wording introduced it in that manner. Brad had noted the Purpose as being the "why?" of the PAR, but Ian questioned if Need was really the "why?" and that instead of Scope being "what?" it was perhaps "how big?", leaving Purpose to be the "what?" of the PAR. Ian and Brad sought Adam's experience on this.
  • Adam agreed that the Purpose should not re-state the Need, and vice versa, and suggested that Scope was the "what?" in a broad brush sense, while Purpose was a refinement of that.
  • Adam had previously posted the PAR guidance to the forums (http://forums.sjtag.org/viewtopic.php?p=1104#p1104) and the group explored that although it provided little clarification on what was expected. Adam noted that Purpose was optional perhaps even becoming deprecated.
  • Ian felt that id Scope was the "what?" and the Need is the "why?" then it is difficult to see what value the Purpose is adding. Brad felt that Need was detailing the problem but Ian though that would then be contrary to the view that the Need should be a concise argument for the Sponsor and NESCOM, and suggested that perhaps we had simply transposed our Purpose and Need statements. Brad argued that while Ian's original remark that the current Purpose might really be the Need, the current Need was not the Purpose, so they were not transposed.
  • Adam attempted to clarify that the Scope should be a terse statement of what is included and excluded, and the Purpose is what should be accomplished in the implementation of the standard. Ian asked if that last remark referred to the implementation of the standard by the end user or the authors' work in preparing the standard. Adam if felt it could be either. Brad thought it should be more related to the Scope, defining what the standard has to provide.
  • Peter suggested looking at the Purpose in 1149.1 for reference. This is actually 3 pages long and includes a diagram, so clearly was not what could reasonably fit on the PAR form. It was noted that 1149.1-2013 updated a pre-existing standard and the PAR format would likely have changed significantly in the intervening time.  1149.7, 1687 and 1581 were looked at as more recent examples. Where present, the Purpose was one or two short paragraphs. The 1581 Purpose explains what is to be done with the standard, not what is to be done by the users.
  • Heiko suggested that if the Purpose is optional then why not simply omit it? 1149.10 does not have a Purpose.
  • Adam submitted further comment. in WebEx chat, captured by Brad in Slide 23 {shared}. Part of this was to set out the questions that each of Scope, Purpose and Need should answer. Brad reviewed the Scope {Slide 21, shared} to see if it answered those questions and felt it did. Adam agreed while noting that it did not make any particular exceptions, such as that we are not defining the actual test interfaces. some discussion followed concerning delineation between software interfaces/APIs and physical interfaces.
  • Green colouring was added to the slide to show what was being defined by the standard and purple to highlight references to "test interfaces" that are utilised by the standard.
  • Adam explained he had not meant to imply that an exclusion was required but Ian and Brad felt it was worth asking the question. Ian thought it may help the first time reader. Brian suggested getting colleagues to read the text and see how they interpret it.
  • Ian felt that an exclusion might be pertinent as we did not intend to define any physical interfaces or anything within a device but simply exploit what was already in existence. Adam suggested that form of words might be that "The standard does not replace or provide an alternative to [1149.1, etc.]". Brad captured bullet points on reuse, which were labelled as being part of the Purpose {slide 24, shared}.
  • Ian suggested that the group consider possible exclusions for next meeting {ACTION}. Bard will post Slides 21, 23 and 24 to the forums.
  • Scope (Slide 21) as amended:
    • 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 and description of such a system to allow better management of the test interfaces that exist when used at the system level.
  • Scope (Slide 23) as edited:
    • 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?
  • For next week:
  • The revised slide pack has been added to the file manager: http://files.sjtag.org/Brad/SCOPE%20DRAFT20160713.pptx.

6. Topic for next meeting

  • Continue PAR discussion
    • Continue reviewing "Purpose" statement.
    • Distil concise paragraph for formal Need clause in PAR.

7. Key Takeaway for today's meeting

  • None.

8. Glossary terms from this meeting

  • None.
    • Definition of "interchangeability" required.
    • 'Instance' (or a more specific version of the term) may require definition in future.
    • 'Master through Slave Mode'
    • 'Master to Master Mode'

9. Schedule next meeting

  • Next meeting July 20 - Ian will be absent, Brad may be absent.
  • July schedule:
    • 27.

10. Any other business

  • Ian hopes Michele will be able to provide a fuller report on the TESTA tutorial in due course.

11. Review new action items

12. Adjourn

  • Eric moved to adjourn, seconded by Brad.
  • Meeting adjourned at 12:04 PM EDT

Respectfully submitted,
Ian McIntosh