Minutes of P2654 Working Group Meeting No.97, 2021-02-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/P2654WG/P2654_Meeting_97.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)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd)
Erik Larsson (Lund University)
Jon Stewart (Dell)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)


By email (non-attendees):

Eric Cormack (DFT Solutions)
Heiko Ehrenberg (GOEPEL Electronics)
Bill Huynh (Marvell Inc.)
Joel Irby (AMD)
Richard Pistor (Curtiss-Wright)
Louis Ungar (A.T.E. Solutions)
Tom Thompson (for IEEE)

2. Agenda

  • Brian moved to accept the agenda, seconded by Brad, 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 #96, February 8 (draft circulated February 8)
    • No corrections advised.
    • Brad moved to approve, Terry seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • Nothing to advise.

7. Discussion Topics

7 a) How much transparency do we need at each level?

  • {Slide 14}
  • Could each level be a black box? If not, why not? I could be, as far as the next level is concerned, but you still need some algorithm at each level in the model.
  • Do we have to drive those transforms through the standard or can the device vendors choose what to provide? We may need to offer some primitives. But is that practical? Perhaps examples, making them mandatory may not be workable.
  • We spoke of plug-ins but a vendor could decide to provide an executable module.  It would still need to offer a conforming "interface" so that the model would know to incorporate it.  In essence it may still be a plug-in, only one that does not provide insight into its workings.
  • What we apply is "just a data stream", but we still need the model to work out what needs to be in that data stream.
  • We don't always need to be controlling a register.  An SVF player is an example of applying a data stream to an interface rather than a register.
  • Encryption is another transformation.
  • ModelPoint is where the hand-off from the leveraged non-P2654 domain to P2654 occurs.  The upper (outward) face of the ModelPoint needs to be consistent so that the model can deal with it.  Standardizing this is probably key to P2654. 
  • ModelPoints could act on remote sub-assemblies, perhaps using remote procedure calls. It is also possible that a remote sub-assembly may be able to host its own P2654 network without that being visible to the primary system.
  • May not need details of registers in a sub-assembly, just how it is controlled and the form of data going in and coming out. That may be enough to plug into the ModelPoint.
  • We need to show that the ModelPoint concept can be made work across a breadth of interfaces, and even into EDA tools.  This does not need to be normative within the standard, just examples to illustrate how it might be done (possibly not the most efficient methods but the most illustrative methods). 
  • Additional material referenced today is included as slides 50-53.

7 b) What does a Transform Strategy need to perform?

  • Is it correct to think this is about defining mandatory behaviours?  Not really: Need to support the protocols for moving data in/out, need to be able to synchronise where aspects of the control or flow are dependent on the order of events.

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • ModelPoint is key to making P2654 work. 

10. Glossary Terms from This Meeting

  • None (ModelPoint may be needed later).
  • 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

  • February 22, 2021

12. Topic for next meeting

  • 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

  • Brian moved to adjourn, seconded by Carl.
  • Meeting adjourned at 12:02 PM EST

Respectfully submitted,
Ian McIntosh