Minutes of Study Group Meeting, 2018-05-21

Meeting called to order: 11:06 AM EDT

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

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Heiko Ehrenberg (GOEPEL Electronics)
Eric Cormack (DFT Solutions)
Bill Eklow (Retired) (joined 11:19)
Brian Erickson (JTAG Technologies)
Peter Horwood (Firecron Ltd.) (joined 11:07)
Bill Huynh (Marvell Inc.)
Joel Irby (ARM)
Naveen Srivastava (Nvidia)
Jon Stewart (Dell)
Brad Van Treuren (Nokia)
Carl Walker (Cisco Systems)
Dilipan Jayachandran (SEL Inc.)
Louis Ungar (ATE Solutions)
Sivakumar Vijayakumar (Keysight)

By email (non-attendees):
---

Excused:
Terry Duepner (National Instruments)
Mukund Modi (NAVAIR Lakehurst)

2. IEEE Patent Slides

  • {Slides 5-9}
  • Patent slides reviewed, no comments.

3. Review and Approve Previous Minutes

  • {Slide 10}
  • May 14 (draft circulated May 14)
    • Brad moved to approve, Eric seconded.
    • No objections or abstentions → minutes approved.

4. Review Open Action Items

  • {Slide 11}
  • [21.1] Brad: Supply Ian with glossary definitions used by 1687.1 for "transformation" and "retargeting".
    • No updates.
    • ONGOING.
  • [27.2] Legacy Initiative Group to propose definition for "SJTAG".
    • No updates.
    • ONGOING

5. Discussion Topics

a) Re-visit PAR Need; Current Scope and Purpose drafts are context..

  • {Slide12 - Outline plan}
  • Reminder of "plan" for getting PAR submission ready.
  • {Slide 13 - Draft Need}
  • Refresh: Scope is narrow (specific to what this standard will do), Purpose is broad (could apply to several related standards). Need is focussed on providing a justification to TTSC and IEEE-SA RevCom on why this new standard is required - that may not reflect all of the "Industry Need" we could identify although it may reflect some part of it.
  • Quick summary of Scope {Slide 15 - Draft Scope} and Purpose {Slide 16 - Draft Purpose} as they currently stand.
  • No other standard seems to pull things together. Existing standards provide "services", mainly at the chip level, while STAM aims to allow the user to make use of those services at the board and system levels. It will bring in more direct support to the applications.
  • C/ATLAS tried to offer some system level interfaces. C/ATLAS' main aim was making test programs portable across ATEs, but within that it did include some common interfaces although downstream the test designer still needed to manage the coordination aspects within the UUT.
  • The key element is "aggregation".
  • It would be useful to be able to look up what standards are available, what we could go after so we could get better coverage. Some standards mentioned in these meetings that may not be familiar, probably no-one knows all the standards that could be applied or all the interfaces that could be used.
  • It is possible to envisage that tooling, such as ATPGs, could, if supplied with all the relevant device "model" information and netlists, largely automate the selection of which standards could be applied for a given task; the user only needs to state the objective: "get this data to that location".
  • Total coverage improvement is the common factor. Most of the IEEE standards we've mentioned will claim to improve test coverage.
  • Could have a SERDES link between a device of Brand A and a device of Brand B. If the link fails then there may be no easy way to determine cause as the link self-tests may not co-operate so local loopbacks might be required and may not be satisfactory.
  • JTAG and IJTAG may only getting half-way there: We have IJTAG and access to instruments but it doesn't go out. To get the coverage we want we need a mixing between IJTAG and JTAG, to extend IJTAG from chip to board, then we can test the board (noting trade-off of what might be subject to IP protection). 1687 nods at using it within a board but the detail is really all on using it inside the chip boundary.
  • The access already exists on the devices, we're trying to address how to get to it. Within that is a need to specify dependencies in order to get the access.
  • We may be bringing in some aspects of the overall "intent" of the application (or step).
  • Diagnostics hasn't featured so far.
  • {At this point it became apparent that Brad had been collecting comments on a markup slide, believing he was sharing it with the group while in fact, Ian's Slide 13 had been showing throughout. Sharing transferred to Brad's slide.}
  • Diagnostics has specific importance for the military and avionics sectors, with requirements for fault isolation to a single FRU, so diagnostics improvement is something that will get those sectors engaged. Granted, but his should not be a diagnostics standard. It can provide (better) data that can be used for diagnostics, but it needs the UUT design to implement the testability and it's up to the application/user to do the diagnosis.
  • Diagnostics may be more an "Industrial Need" than a "PAR Need": The wording needs to be sorted out a little before we can tell how well mentioning will fit.
  • Do we have a version of the text we are working on? Not as such: We have the original Need text (from over a year ago) plus the comments we collected a few months ago plus the comments collected today (slides 14-16 as Brad was sharing them). We can put those together in a pack linked to these notes {now posted on the File Manager at http://files.sjtag.org/StudyGroup/SG_Meeting_36_bgvt_subset.pdf} and also copy them to a forum post {now posted at http://forums.sjtag.org/viewtopic.php?p=1345#p1345}.
  • The comments need to be sorted through and relevant items put together into a form of words. We should aim to do this over the two week period we have before the next meeting as we will need to move quickly on approving final text and entering material into IEEE-SA MyProject prior to the TTSC meeting {ACTION}.
  • Reference slides (not used during this meeting):
  • {Slide 14 - Collated comments}

6. Today's Key Takeaways

  • {Slide 17}
  • The broad Need for Industry is not the same as the PAR Need, which is mainly for TTSC and SA benefit.

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.
    • SJTAG: Discussion on forums - http://forums.sjtag.org/viewtopic.php?f=3&t=782
    • Device - do we mean a packaged device? May be many devices in a package (1149.1 opted for "entity" in order to be non-specific).

8. Topic for next meeting

9. Schedule next meeting

  • June 4.
    • May 28th cancelled due holiday absences.

10. Reminders

11. Any Other Business

  • None.

12. List New Action Items

  • [36.1] All: Work up draft wording of Need prior to June 4 meeting.

13. Adjourn

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

Respectfully submitted,
Ian McIntosh