Minutes of Study Group Meeting, 2018-03-05

Meeting called to order: 11:07 AM EST

The slide references relate to the pack used during this meeting, located here: http://files.sjtag.org/StudyGroup/SG_Meeting_26.pdf

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Eric Cormack (DFT Solutions Ltd.)
Terry Duepner (National Instruments)
Bill Eklow (Retired)
Brian Erickson (JTAG Technologies)
Peter Horwood (Firecron Ltd.)
Bill Huynh (Marvell Inc.)
Joel Irby (ARM)
Rajesh Khurana (Cadence Design Systems)
Mukund Modi (NAVAIR Lakehurst)
Richard Pistor (Curtiss-Wright)
Naveen Srivastava (Nvidia)
Jon Stewart (Dell)
Brad Van Treuren (Nokia)
Carl Walker (Cisco Systems)
Russell Shannon (NAVAIR Lakehurst)
Craig Stephan (INTELLITECH Inc.)
Louis Ungar (ATE Solutions)

By email (non-attendees):

Heiko Ehrenberg (Goepel Electronics)

2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • February 26
    • Updated draft circulated 02/28/18
    • No further corrections.
    • Terry moved to approve, seconded by Bill Eklow, no objections or abstentions. Approved.

4. Review Open Action Items

  • {Slide 11}
  • [21.1] Brad: Supply Ian with glossary definitions used by 1687.1 for "transformation" and "retargeting".
    • These will be coming in the draft standard.
    • ONGOING.

5. Discussion Topics

a) Work on refinement of what SJTAG/STAM is - Re-focus on agreement on STAM Scope.

  • {Slide12 - headings}
  • "Need" discussion seemed to be stuck, try looking at the what the intended Scope is.
  • {Slides 13 - Study Group Goal}
  • Presented last week, this is the group aim used in the TTSC sponsorship request for the current study group.
  • {Slides 14 - "STAM" and "SJTAG"}
  • Presented last week, considers "SJTAG" as a broader scope that encompasses "System Test Access Management" within it - related but not equivalent.
  • {Slide 15 - Stack/Layers}
  • Based on the notion of "layers" or a "stack" that emerged in last week's discussion. Shows STAM as a bottom layer (but possibly not the only element in the bottom layer), an unnamed middle layer that describes standardized communications between sub-system and system, and at the top, the application of tests at the systems level - this might be what we consider to be "SJTAG". The STAM layer is really what this study group was formed to prepare a PAR for, although many of the other things discussed recently are probably all worthy of their own PARs/standards.
  • What is really different between STAM and the middle layer - they seem to be the same thing? The middle layer seems to imply a level of sentience in the sub-system to support the communication of test requests and results. The STAM layer deals with how devices with differing interfaces can be inter-operated to deliver some function. That can then be used by the middle layer (although it doesn't have to).  May also consider that the middle layer could encompass embedded functional or boundary scan tests that are applied using STAM. 
  • Isn't SJTAG a way of attacking system level test through the use of JTAG?  That was probably the starting position when the SJTAG initiative was formed (2005), but in many respects part of that problem solved itself while many more emerged. The scope of SJTAG became very broad, so STAM is simply a starting point.
  • There should be some kind of definition for what SJTAG is, what it will offer, features we want it to provide, such as diagnostics information, prognostics, etc.
  • {Terry and Russell dropped off the call around 11:30}
  • 1149.1 mentioned as an example, detecting shorts/opens, but noted that the standard really provides data that can then be used to detect shorts/opens.
  • Need to be careful and acknowledge that STAM is not SJTAG, it is only a contributing part of SJTAG.
  • STAM does not always need to "permeate to system level" but could be used at the board level, especially in the COTS case and the board may then only report a Go/NoGo result to the higher level.
  • It seems that STAM is implementation detail and SJTAG is the "need"? That would suggest that 1149.1, 1581, 1687, etc., are all "just implementation details".
  • Why is there a need? There currently is no way for tools to know how to make tests that involve devices that adhere to different standards. But the other "needs" are also valid and could be developed into standards; there's nothing to stop another group working on one of those - in the end it would ultimately fit under the banner of "SJTAG".
  • For the PAR, the "Need" section is really to provide justification to the Sponsor and RevCom why this particular standard is needed, so it's probably different from the "industry need". In the broad sense SJTAG should be fulfilling (at least part of) the industry need, but the PAR Need has to say why a standard with the defined scope will be useful.
  • The broad need is maybe more suited to going into the Purpose section. Multiple standards can share a common Purpose. Perhaps SJTAG needs a "Mission Statement" to cover the broad need and allow other standards to fit underneath it.
  • STAM is only a piece in the puzzle - we need to get started somewhere. There are other things that the initiative group identified as possible standardization opportunities, for example scan chain bridge devices/path selectors. 
  • The PAR Need doesn't necessarily find it's way into the standard in the way that Scope and Purpose do. In 1149.1 it looks like it is addressed in the standard under "History of Development"; there was probably no Need section in the PAR when 1149.1 was drafted.

  • Note for discussion next time - How did 1149.1 phrase its Purpose (it is several paragraphs)?

  • Reference slides (not used during this meeting):
  • {Slide 16 - Draft Scope}
  • This is draft text as proposed by the "Initiative group" (as are the following two slides).
  • {Slide 17 - Draft Purpose}
  • Red text is highlighted as it is a constraint that we might want reconsider, or at least discuss.
  • {Slide 18 - Draft Need}
  • The wording of this has already been pointed out to be deficient as it stands. It is probably too long anyway - the latter part has been greyed as it is largely just an expansion of the main points.
  • {Slide 19 - Collated comments}
  • Yet to be considered.

6. Today's Key Takeaways

  • {Slide 20}
  • SJTAG should have a Mission Statement recorded.
  • SJTAG should have a "definition" ("JTAG" tends to imply an access protocol).

7. Glossary Terms from This Meeting

  • None.
  • Carried over:
    • "Interface" is missing.
      • No obvious IEEE accepted definition.
      • 1687 has definitions for specialised forms: Device Interface and Instrument Interface.
      • We may need specialised forms for Software Interface and Hardware Interface.
    • 1687.1: Transformation, Retargetting.
    • IEEE 1856: Sense - "Sensor" done, Acquire, Analyze not really defined.

8. Topic for next meeting

9. Schedule next meeting

  • March 12.

10. Reminders

11. Any Other Business

  • None.

12. List New Action Items

  • None.

13. Adjourn

  • Eric moved to adjourn, seconded by Brian.
  • Meeting adjourned at 12:06 PM EST

Respectfully submitted,
Ian McIntosh