Minutes of P2654 Working Group Meeting No.67, 2020-06-01

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/P2654WG/P2654_Meeting_67.pdf

1. Roll Call

Ian McIntosh (Leonardo)
Eric Cormack (DFT Solutions)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd)
Bill Huynh (Marvell Inc.)
Richard Pistor (Curtiss-Wright) (joined 11:09)
Jan Schat (NXP Semiconductors)
Jon Stewart (Dell)
Louis Ungar (A.T.E. Solutions)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)

Guests:
---

By email (non-attendees):
---

Excused:
Terry Duepner (National Instruments)
Joel Irby (AMD)

2. Agenda

  • Eric moved to accept the agenda, seconded by Carl, no objections.

3. IEEE Patent Slides

  • {Slides 5-10}
  • Patent and Copyright slides reviewed.

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #66, May 18 (draft circulated May 18)
    • No corrections noted.
    • Eric moved to approve, Carl seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • Michele has shared information on the connectivity modelling he is using. Michele is unlikely to have time to present this to P2654 but Brad can likely relay at some point.

7. Discussion Topics

7 a) Finish off 'System' discussion

  • {Slide 14}
  • Important to close out the textual definition.
  • The notion of "control" as part of the definition was in order to focus on what a system is from a STAM perspective - we need to step away from trying to generalise the definition. Although this suggestion originated from Terry the NI adoption seems to align with STAM.
  • The control may be programmable or defined by a state machine but it will follow well defined "rules".
  • The control needs to be "functional": As well as the controller there needs to be something that is controlled in order for there to be a "system".
  • If there are data paths allowing external application of tests, then that could bypass the system's control - would that mean it is no longer a system? No, because you haven't actually altered the hardware. The capacity to control remains even if it is not used.
  • Are we defining "system" as something that STAM would simply recognise as a system or are we expecting the system to be something where STAM would provide value?
  • For STAM to useful, a "STAM System" would need to have testability that can be exploited; there needs to be some form of testability infrastructure present.  That could be dedicated test buses or could use existing "mission" data paths.
  • Definition update marked-up on Slide 14.
  • It is likely that during the preparation and review of the standard that we will re-visit this definition but for now it seems complete.
  • System Elements and System Resources are to be defined separately.  So far as seems necessary, the concepts are wrapped up in the STAM System definition.
  • Diagrams will provide the basis for much of the section text we will need to prepare.
  • Counter examples are not a requirement but will help readers to determine when something falls outside the definition of a STAM System.
  • Bullet points recorded during the earlier meetings are now moved to a separate reference file: http://files.sjtag.org/P2654WG/P2654_Reference_Pack.pptx.
  • Forum thread for comments on the outline: http://forums.sjtag.org/viewtopic.php?f=3&p=1444#p1444

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • Definition of STAM System considered complete.

10. Glossary Terms from This Meeting

  • None.
  • Carried over:
    • System Element.
    • System Resource.
    • 'System' needs the concept of a controller capability added.
    • "Filtering" may need to be defined.
    • "Translation" may need to be defined.
    • "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.
      • "Interface" is overloaded and requires disambiguation.
    • 1687.1: Transformation.
    • IEEE 1856: Sense - "Sensor" done, Acquire, Analyze not really defined.
    • Device - do we mean a packaged device? May be many devices in a package. "Device" is often used as a modifier, e.g. "device package", "device identification".
    • Use Case Context, Application Context
    • Legacy Infrastructure, SJTAG Infrastructure (placeholders for now, really for working group to define).
    • "Generators": May need to be qualified as "Test Generators" (used by the integrator/tester) and "Model Generators" (used by IP providers, interface designers, etc.).
    • AccessLink and DataLink descriptions will need to be revised.
    • See P1687.1's definitions on Slide 31 of the pack presented by Jeff Rearick on Jan 14, 2019.
    • "State", "Vector", "Sequence" and "Pattern" as proposed at April 8, 2019 meeting.
    • "Event", "Access Interface" as proposed at April 15, 2019 meeting.
    • 'Port' needs to be developed.

11. Schedule next meeting

  • June 8, 2020.

12. Topic for next meeting

  • a) UTAP development (Peter Horwood)

13. Reminders

  • None.

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh