Minutes of P2654 Working Group Meeting No.116, 2021-07-19

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_116.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)
Terry Duepner (National Instruments)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd)
Joel Irby (AMD)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)


By email (non-attendees):

Bill Huynh (Marvell Inc.)
Richard Pistor (Curtiss-Wright)
Jon Stewart (Dell)
Louis Ungar (A.T.E. Solutions)
Tom Thompson (for IEEE)

2. Agenda

  • Brad 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 #115, July 12 (updated draft circulated July 14)
    • No further corrections noted.
    • Brad moved to approve, Terry seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • P1149.7 now expect to have one further meeting prior to being ready to re-ballot.

7. Discussion Topics

7 a) Continue review of standard draft

  • {Slide 14}
  • Mentioned "Named tests" last time - surely that doesn't need to be a "name" (text string) just some form of ID. Might need to be human readable for some uses?
  • If the test is provided by a sub-assembly at level lower than the tier directly visible to the "test controller", how is the test "name" exported up through the hierarchy?
  • There probably needs to be some way to map the intent of a test to the steps needed to apply the test, naming may help here.
  • "Test" may not be the correct term as not everything we want to do will be a test - P1687.1 has adopted the term "objective".
  • Events: P2654 could initiate an event but it cannot react to an event asynchronously - it must poll.
  • Some objectives may return multiple values or variable lengths of data, e.g. diagnostic information.
  • Security will be an issue in some cases. Can something use P2654 if access to some data is restricted? Is there a minimum that has to be available, e.g. "I'm alive" signalling? Not sure if that could be mandated as the way in which that might be indicated will vary depending on what the target node is capable of.
  • May be touching on "what makes something 'P2654 compliant' as opposed to 'P2654 compatible'? 
  • P2654 can move data around but it shouldn't need to be aware of the data is or its intent.  The data formats in the hardware are not standardised but the RVF message formats within the model need to be.  Hence, the application is probably the only thing that knows that certain data represents a presence/health check.
  • If an entity cannot provide any data then it clearly can't claim to be implementing P2654, so it must contribute 'something' although what may be undefined.
  • See also slides: {Slides 99, 100}.

8. Any Other Business

  • {Slide 15}
  • Brad drew attention to C4model.com, possible alternative to UML-style diagramming. Concept of Context → Container → Component → Code.

9. Today's Key Takeaways

  • P2654 provides a standard way of describing messaging.

10. Glossary Terms from This Meeting

  • None.
  • Carried over:
    • "True System".
    • Comment that "End-User" is subject to perspective and so needs to be qualified.
    • 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

  • July 26, 2021

12. Topic for next meeting

  • Continue to review standard draft - where does STAM fit in the foodchain?.

13. Reminders

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh