Minutes of P2654 Working Group Meeting No.78, 2020-09-14

Meeting called to order: 11:10 AM EDT

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

The cumulative reference pack is located here: http://files.sjtag.org/P2654WG/P2654_Reference_Pack.pptx 

1. Roll Call

Ian McIntosh (Leonardo)
Terry Duepner (National Instruments)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd) (joined 11:15)
Joel Irby (AMD)
Richard Pistor (Curtiss-Wright) (joined 11:17)
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:
Bill Huynh (Marvell Inc.)

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. 

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #77, August 31 (draft circulated August 31)
    • No corrections advised.
    • Terry moved to approve, Heiko seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • 1149.7 reporting a broad take-up for ballot group, currently around 20 people.

7. Discussion Topics

7 a) Discussion of perspectives on STAM

  • {Slide 14}
  • Picking up mainly from slide 27.
  • Reiterating that the diagram from slide 26 is a "leaf" of the hierarchy, and there is re-use for each instance of the same assembly, irrespective of where it occurs in that hierarchy.
  • As there has been (and there is likely to be) misunderstanding about the flow, would it be useful to have some way of diagramming the relationship of request/response flows in the model to the flow in the hardware?  This was in fact shown in previous diagram, some time ago: The coupling occurs at the top of the hierarchy, in effect in application layer.
  • There may be multiple hierarchies as each hierarchy terminates to a single interface at the system boundary. However, there is no constraint that the same interface or protocol persists through the hierarchy.
  • Request to summarise 'Callbacks' and 'Assembly Handlers': Callbacks are essentially the logic to be performed for each of the supported requests. The Assembly Handlers comprise the Request and Response handlers for that assembly. The Request Handler acts as a request decoder, determining which callback is to be used.
  • Slide 28 starts to address modelling issues.
  • PDL could be used or possibly some other domain specific language (DSL).
  • PDL is written with paths relative to the context of the object it describes as it is intended to be reused in all cases where that object is used. However an absolute path is required at run time and resolving this in the run-time or generator application is different from what has been established as retargeting.
  • PDL may become very large if the vector set involved is large or complex. It could be very limiting to only allow PDL, and perhaps executables with command line switches may be another option although the question of supported Operating Systems might be supported arises. This is perhaps dependent on whether/how "interactive dialogue" applications (e.g. debugging) might be supported.
  • Note that slide 30 has been revised from the version circulated for the August 31, 2020 Meeting.

7 b) Diagrams and Terms

  • Not discussed during this meeting.

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • PDL may not be the only description language format used.

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

  • September 21, 2020.

12. Topic for next meeting

  • Continue from today.
    • a) Discussion of perspectives on STAM (slides 29, 30)
    • b) Diagrams and Terms

13. Reminders

  • None.

14. List New Action Items

  • None.

15. Adjourn

  • Peter moved to adjourn, seconded by Jon.
  • Meeting adjourned at 12:00 Noon EDT

Respectfully submitted,
Ian McIntosh