Minutes of P2654 Working Group Meeting No.112, 2021-06-14

Meeting called to order: 11:04 AM EDT

The slide references relate to the pack used during this meeting, located here: http://files.sjtag.org/P2654WG/P2654_Meeting_112.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) (joined 11:14)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd) (Joined shortly after call to order, time not noted)
Richard Pistor (Curtiss-Wright)
Jon Stewart (Dell)
Louis Ungar (A.T.E. Solutions)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)

Tom Thompson (for IEEE)

By email (non-attendees):

Bill Huynh (Marvell Inc.)
Eric Cormack (DFT Solutions)

2. Agenda

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

3. IEEE Patent Slides

  • {Slides 5-10}
  • Patent (newly updated) and Copyright slides reviewed without comment.

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #111, June 7 (draft circulated June 7)
    • No 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}
  • Discussion within P1149.4 kick-off meeting over whether P1149.4 might be superseded by P1687.2 or whether they complement each other. 1149.4 may not be widely used and might have "been ahead of its time". Automotive sector is possibly the primary consumer for either of the standards. May want to see if an 1149.4 use case can be implemented using P1687.2 methods.

7. Discussion Topics

7 a) Continue review of standard draft

  • {Slide 14}
  • Discussion of simplified stack diagram (slide 95).  Ian unsure if it serves the intended purpose.
  • What is considered as the "top-level controller" is dependent on the observer's context, but rolls up to notions of Test Controller and Test Manager.
  • The scope what constitutes the "UUT" is probably greater that shown as it is more than just the interfaces.
  • What we're dealing with is "communication"; General requirement is to get some item of information that is held in a sub-assembly back up to the "controller". But are we defining a communication protocol that all the sub-systems need to share?  Not really possible when you get down to e.g. chip level where the device will define what protocol(s) is(are) supported.  So what we want is more of an abstracted protocol used for modelling purposes, with translation to what the physical interfaces actually need.
  • Slide 96 created to show two different cases:
    • Top is where sub-systems share a common "grammar" with the host system,
    • Bottom shows the sub-systems each adhering to their own, incompatible grammars. The System needs to be able to understand both grammars.
  • Protocol and Command: Protocol is grouping of data so that it can be understood between the components transacting the data, a Command is an instruction contained within the data.
  • Does the System only need to know about the first level of sub-systems?
  • Brad referenced a 2005 presentation by Gunnar Carlsson.

8. Any Other Business

  • {Slide 15}
  • Two session being proposed for ITC:
    • “Talk to TTSC” panel on standards
    • Special Session on standards work (P1687.1, P1500, P1581).

9. Today's Key Takeaways

  • P2654 needs to be able to utilise existing design elements, not necessarily impose additional HW requirements.

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

  • June 21, 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

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

Respectfully submitted,
Ian McIntosh