Minutes of P2654 Working Group Meeting No.98, 2021-02-22

Meeting called to order: 11:09 AM EST

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

The cumulative reference pack is located here: http://files.sjtag.org/P2654WG/P2654_Reference_Pack.pptx (updated Dec 31, 2020)

iMeetCentral site: https://ieee-sa.imeetcentral.com/sjtag-sg/ 

1. Roll Call

Ian McIntosh (Leonardo) (chair)
Eric Cormack (DFT Solutions) (joined 11:27)
Terry Duepner (National Instruments)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd)
Joel Irby (AMD)
Richard Pistor (Curtiss-Wright)
Jon Stewart (Dell)
Louis Ungar (A.T.E. Solutions)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)


By email (non-attendees):

Bill Huynh (Marvell Inc.)
Tom Thompson (for IEEE)

2. Agenda

  • Brian moved to accept the agenda, seconded by Terry, no objections.

3. IEEE Patent Slides

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

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #97, February 15 (draft circulated February 15)
    • No corrections advised.
    • Terry moved to approve, Carl seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • Nothing to advise (most meetings were cancelled last week).

7. Discussion Topics

7 a) What does a Transform Strategy need to do?

  • {Slide 14}
  • Needs to:
    • Convey a common understanding of the "grammar" used for the inputs to the strategy and to be applied to the outputs resulting from the strategy.
    • Synchronise message and events.
  • The grammar needs to flexible: So P2654 isn't defining the grammar itself but the way the grammar should be structured and presented.
  • [Illustration of proto buff (protocol buffer) shared]
  • Common format that can then be mapped to provide interaction with a variety of code implementations.
  • Debate over whether it is necessary or desirable to define the message types (primitive messages) that should be supported for some specific communications protocols.  Might this mean we're creating two different "standards" within P2654, those with and those without these required message types?
  • Could this be done through an initial "handshake" - A declaration of "here's what capabilities I have"?
  • There's a need for context. Does this imply that there's a missing capacity for the proto buff to convey contexts through the hierarchy? Possibly, but how would you describe "context" in a written form?
  • Where does the context come from? It must end up in the system model somehow.
  • If it is acceptable to not require defined message types for a high level, abstracted proto buff then why should it be a requirement for any proto buff?  Client needs to drive what it expects through the model.
  • Client provides capabilities but the host needs to orchestrate the use of those capabilities.
  • What is the intended locality since modelling in real time may be beyond the capacity of many embedded systems?
  • Additional note on slide 54.

7 b) Defining what comprises a ModelPoint

  • Not discussed due to lack of time.

8. Any Other Business

  • {Slide 15}
  • NTF Webinar, "Automation in electronics testing", is tomorrow February 23rd (14:00 to 15:30 CET) via Zoom (virtual lobby open from 13:45).  There is further session on March 23rd (10:00-11:30 CET) on "Design for Test".

9. Today's Key Takeaways

  • Grammar of messaging: Defines verbs and nouns shared by host and client.
    • Question: Who "owns" the grammar - host or client? 

10. Glossary Terms from This Meeting

  • None.
  • Carried over:
    • ModelPoint
    • 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

  • March 1, 2021
    • Jon and Carl will be absent.

12. Topic for next meeting

  • Continue: What does a Transform Strategy need to do?
  • Defining what comprises a ModelPoint

13. Reminders

  • Reiterate: Michele Portolan has proposed a workshop at ETS 2021. Related to a special session of papers to be run by Martin Keim.

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh