Minutes of P2654 Working Group Meeting No.77, 2020-08-31

Meeting called to order: 11:07 AM EDT

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

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

1. Roll Call

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

Guests:
---

By email (non-attendees):
---

Excused:
Peter Horwood (Digital Development Consultants Ltd)
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 #76, August 24 (draft circulated August 24)
    • 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}
  • Revision PARs for 1149.4 and 1581 are circulating for sponsor approval.

7. Discussion Topics

7 a) Discussion of perspectives on STAM

  • {Slide 14}
  • Brad's slide 23, unseen last week, has been copied to slide 26 and supplemented by additional slides 27-30.
  • Architecture is shown horizontally on slide 26, similar to representation used by P1687.1.
  • Jigsaw piece "connectors" intended to imply that assemblies can connect to each other,
  • "Assembly" is used in the sense previously established in the group, and may represent a device, a board, a sub-system, etc.
  • Relocatable Vector Format (RVF) is a suggested term from Michele Portolan and is similar in principle to formats used in iSCSI.
  • "Vector" can imply serialised data, but this should not be assumed.
  •  Within the Hierarchical model, each "leaf" is represented by an Assembly description (slide 27). The callback and handlers used by each assembly instance are drawn from "libraries", avoiding duplication across instances of the code associated with each.
  • Is there a need to transform everything to a JTAG model? No, it can remain native if the data paths permit, but wherever there is a need to transform data then there will be a performance impact.
  • Direction of requests may not be clear. In fact there are two types of request: The application will make requests to change the state of the model and the target will then make requests to change the physical state of the hardware. 
  • The bottom leaf(s) may not want to be exposed. As you move up through the hierarchy, at each Assembly, the model will encompass that assembly and everything below, so the exposed interface at that level may hide what is below and could have encryption features encapsulated.
  • Part of P2654 is to describe how you publish what is available.
  • Models could be distributed as binary libraries to make them more secure but that may be limiting to portability.  Portability for re-use is a desirable outcome.
  • The scheduler has to have knowledge of the whole, so needs to be built up from the provided descriptions.

7 b) Diagrams and Terms

  • Not discussed during this meeting.

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • Software model is distinct from hardware implementation.
  • Request run two ways: Application sends requests to change the state of the model; the target sends requests to change the physical state of the hardware.

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 14, 2020.
    • No meeting September 7 (Labor Day, US).

12. Topic for next meeting

  • Continue from today.
    • a) Discussion of perspectives on STAM
    • b) Diagrams and Terms

13. Reminders

  • None.

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh