Minutes of Study Group Meeting, 2018-02-05

Meeting called to order: 11:06 AM EST

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

The "markup slide" created during the meeting is here: http://files.sjtag.org/StudyGroup/SG_Meeting_23_bgvt_SingleSlide.pdf

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Heiko Ehrenberg (Goepel Electronics)
Eric Cormack (DFT Solutions Ltd.)
Bill Eklow (Retired)
Peter Horwood (Firecron Ltd.)
Bill Huynh (Marvell Inc.)
Joel Irby (ARM) (joined 11:07)
Mukund Modi (NAVAIR Lakehurst)
Richard Pistor (Curtiss-Wright)
Naveen Srivastava (Nvidia)
Jon Stewart (Dell)
Brad Van Treuren (Nokia)
Carl Walker (Cisco Systems)
Dilipan Jayachandran (Schweitzer Engineering Laboratories, Inc.)
Louis Ungar (ATE Solutions)
Sivakumar Vijayakumar (Keysight) (joined 11:07)

By email (non-attendees):
---

Excused:
Brian Erickson (JTAG Technologies)
Terry Duepner (National Instruments)
Russell Shannon (NAVAIR Lakehurst)

2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • January 29
    • Draft circulated 01/29/18
    • Eric moved to approve, seconded by Heiko, 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".
    • Brad has some definitions from the 1687 standard but is still distilling from the 1687.1 discussions.
    • ONGOING.

5. Discussion Topics

a) Work on refinement of what SJTAG is.

  • {Slide12 - headings}
  • {Slide 13 - Marked-up Need from previous meeting}
  • Today's intent was to review and discuss the comments collected last week.
  • Brad prepared a copy of this slide for editing and collection of comments during the discussion {shared, see link at the top of these notes}.
  • The following is a brief summary of the points raised:
    • Should the first sentence be adjusted to cover more than the test, diagnostics and prognostics mentioned? We could be more expansive to capture more interest or narrow to "test", as the most general case, for easier reading but risk failing to attract people from other domains.
    • 1149.1's illustration of using TDRs was scoped around test but does not prevent other uses. That wouldn't have been in the PAR - do we know what was in 1149.1's PAR? Scope and Purpose, yes, but may not have had a Need section (possibly a more recent introduction).
    • Could have a list of uses to help capture more of an audience.
    • SJTAG's success/utility depends on DFT, etc., being driven into the design.
    • Should have some reference to measuring what is a good test or good test coverage (they are different). Arguably, a "good test" may be more meaningful than "good test coverage".
    • With functional test it can be difficult to know what coverage you're getting, but you can get a good measure from structural tests. It should be up to the user to determine what criteria to use but that should be given as the basis for the measure of coverage claimed. FMEA is an example of what you might use but there can be other methods.
    • Standards are a template to ensure that everyone is moving in the same direction, enable everybody to do the same thing, so if I'm receiving something in then I know what I'm going to get. 1149.1 gave everyone the same interface.
    • Are there scenarios where the user doesn't care about coverage? Device programming is a Use Case that isn't a "test" so doesn't have "coverage". Checking topology, inter-module comms, etc., is more of a requirement but will have a coverage for the specific features inspected.
    • SJTAG is meant to be about facilitation of access.
    • During design proving you're looking for design defects but once you're into manufacture you're looking for assembly defects.
    • SJTAG could improve coverage, prognostics, etc., but how do you measure the improvement?
    • We/SJTAG can't deal with the whole system design lifecycle.
    • We want to be inclusive of diverse Use Cases (and not preclude any), but do we explicitly need to list them all?
    • SJTAG is different from most of the other test related standards in that we are not driving any new features into the devices, and instead just want to make better use of what the devices already provide. We need to know what the devices do provide, as Terry had mentioned in discussing top-down vs bottom-up approaches.
    • 1149.1 gives test access but sometimes you can't use it even if it is available as putting the device into test mode can upset the operation of the target excessively. The extensions provided by the 2013 revision are aimed alleviating some of these issues but there are currently few, if any, commercial devices that have these features.
  • Brad will copy the marked up text to the forums for discussion through the course of the week.
  • Reference slides (not used during this meeting):
  • {Slide 14 - Draft Scope}
  • This is draft text as proposed by the "Initiative group" (as are the following two slides).
  • {Slide 15 - Draft Purpose}
  • Red text is highlighted as it is a constraint that we might want reconsider, or at least discuss.
  • {Slide 16 - 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.

6. Today's Key Takeaways

  • {Slide 17}
  • There are different ways to define "good test/coverage", depending on the Use Case.

7. Glossary Terms from This Meeting

  • None.
  • "Boundary", as drafted last week is accepted.
  • 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.
  • General discussion of Glossary:
    • FMEA could be added.
    • Glossary can grow (but not excessively).
    • Wiki based, so a definition can easily be linked to an article that expands on the definition or gives examples.

8. Topic for next meeting

9. Schedule next meeting

  • February 12.

10. Reminders

11. Any Other Business

  • None.

12. List New Action Items

  • None.

13. Adjourn

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

Respectfully submitted,
Ian McIntosh