Minutes of Study Group Meeting, 2018-01-15

Meeting called to order: 11:05 AM EST

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

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Heiko Ehrenberg (Goepel Electronics)
Terry Duepner (National Instruments)
Bill Eklow (Retired)
Brian Erickson (JTAG Technologies)
Peter Horwood (Firecron Ltd.)
Richard Pistor (Curtiss-Wright)
Jon Stewart (Dell)
Brad Van Treuren (Nokia)
Craig Stephan (INTELLITECH Inc.)
Louis Ungar (ATE Solutions)
Sivakumar Vijayakumar (Keysight)

By email (non-attendees):

Eric Cormack (DFT Solutions Ltd.)
Joel Irby (ARM)
Mukund Modi (NAVAIR Lakehurst)
Naveen Srivastava (Nvidia)
Carl Walker (Cisco Systems)
Ed Gong (Intel Corp.)
Russell Shannon (NAVAIR Lakehurst)

2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • January 8
    • Draft circulated 01/08/18
    • No corrections noted.
    • For clarification, the slide numbers in the advanced slide pack sent out prior to the meeting matches those in the full version used in the meeting and linked in the minutes; the slide contents are identical.
    • Brad moved to approve, seconded by Brian, no objections or abstentions. Approved.

4. Review Open Action Items

  • {Slide 11}
  • [10.2] Brad will draft a definition for "boundary".
    • Some progress, but not ready for sharing yet.
    • ONGOING.
  • [14.1] ALL: Develop Purpose description.
    • ONGOING.
  • [17.1] Louis: Search for any standards that address what constitutes a fault (or pass) at system level.
    • FMEA/FMECA seem to be prevailing methods for judging whether a system is good or bad, and is described in MIL-STD-1629A, which Louis recommends referencing.

5. Discussion Topics

a) Work on refinement of what SJTAG is and what are merely "notations"

  • {Slide12 - What we need for a PAR}
  • SCOPE: Must appear in standard exactly as in the PAR. Should define a task achievable in the WG project timeframe. Extensions are possible, but there could be some difficult questions asked.
  • PURPOSE: If present, must appear in standard exactly as in the PAR. Purpose is "big picture" and could be common to a family of standards.
  • NEED: Required for the PAR but could be expanded in the standard. The PAR Need is mainly for the benefit of those reviewing the PAR and should be brief, so may not reflect the whole of industry's need. 
  • {Slide 13 - SJTAG Universe}
  • {Slide 14 - IEEE 1856 PHM Process}
  • Intent was to show a flow from the broad picture of potential applications through a specific and well thought-out example and then down into the instruments, but there was no suitable diagram to hand to illustrate this last part. It is represented by the "Sense" block in slide 14.
  • Perception is that in the PHM diagram, The "Analyze" and "Advise" blocks are mostly going to be "software". Sense is the physical instruments and SJTAG probably fits in the "Acquire" block; infrastructure that bridges the instruments to application via some consistent interface.
  • 1687.1 seems to be finding itself in a similar sort of position. The instruments "do something" and the standard is descriptive of how to control them but not prescriptive of what they are used for. The standards body may have difficulty with that as they will be looking to see that the standard is going to be usable. However, it's not possible to anticipate all the uses of the standard. SJTAG is probably in a similar category.
  • Is this implementational detail? Should we be focussing on No Fault Founds (NFF) or False Alarm (FA) resolution? From the Venn diagram, these could become available.
  • We shouldn't be worried about what the result are but what scope the design engineer can provide.
  • We should say what we expect the tools to be able to do, the "how" is for the working group.
  • Can argue that NFF and FA are not in scope for SJTAG for the same reason that, say, POST should not be defined by the standard.
  • The Naval people have expressed that their main need is for better diagnostics, to the FRU level. That is part of the processing of the results.
  • Should our focus be on access rather than applications? The Venn diagram is not saying "SJTAG will do these", just that they are possible.
  • If you can decouple SJTAG from specific Use Cases then you should see the potential for greatest exploitation.
  • Using BScan as the basis for SJTAG came about because it was easy to measure coverage and get diagnostic granularity.
  • In tooling, interconnect test will use a different diagnostician from a Flash programming application. 1149.1 is unable to state what the diagnostics are but can state what is available to use for that.
  • Diagnostics and resolution of NFF and FA should be identified in the purpose and these don't appear on the Venn diagram. They need access.
  • The Venn diagram isn't comprehensive, and probably can't be, but NFF and FA could be fitted in there. "Instrumentation" there is a catch all for all uses of instruments although some are spelled out. All can be used today with ad hoc methods, which perhaps begs "why is SJTAG needed?" - Answer is probably "Efficiency".
  • One way to look at it is that if you use SJTAG for one primary purpose (e.g. Flash programming) then the other uses become available anyway (if you want to exploit them). Even a single Use Case can be used differently, e.g. Flash programming can be used for pre-delivery configuration for a specific customer or updating a unit in the field. 
  • Maybe we want specify the outcomes that we want to be made available for analysis.
  • Diagnostics and NFF and FA resolution are probably features that software tools should offer. SJTAG can provide the support for that but can't require the tools to deliver it.
  • With NFFs a fault my be flagged by the system but testing of the removed item shows no fault. A key issue then must be the ability to query the item without removing it from the system - a "covers on" test of the module. So it is the ability to access that testability at the system level that is needed.
  • Useful to be able to use BScan to inspect pins states to see what alarms might be getting signalled that aren't being reported through the main system - can help with NFFs and FAs. Consider it data capture querying the health. Something similar done at Cisco for state capture in ASICs, led to improvements in the testing of ASICs. An aim had been to try to reproduce faults by injecting states, but that work probably didn't go too far.
  • Time had overrun and the discussion had to be closed at this point.

6. Today's Key Takeaways

  • {Slide 15}
  • Settling on SJTAG operating in something equivalent to the "Acquire" block (as defined by IEEE 1856) - bridging between Sense and Analyze.

7. Glossary Terms from This Meeting

  • May want to consider copying terms defined in IEEE 1856: Sense, Acquire, Analyze.
  • Carried over:
    • BIT - clarify in line with discussion from 2017-12-18 meeting.
    • BIST - distinct from BIT in that is a self-test that does not require any additional resources other than the tested item itself.

8. Topic for next meeting

  • Work on refinement of what SJTAG is.

9. Schedule next meeting

  • January 22, 2018.
    • Louis may be absent.

10. Reminders

  • None.

11. Any Other Business

  • Think about potential officers, moving towards a Working Group.

12. List New Action Items

  • None.

13. Adjourn

  • Louis moved to adjourn, seconded by Peter.
  • Meeting adjourned at 12:10 PM EST

Respectfully submitted,
Ian McIntosh