Minutes of P2654 Working Group Meeting No.124, 2021-09-27

 Meeting called to order:  11:05AM EDT

The slide references relate to the pack used during this meeting, located here: 
http://files.sjtag.org/P2654WG/P2654_Meeting_124.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)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Joel Irby (AMD)
Richard Pistor (Curtiss-Wright)
Brad Van Treuren (VT Enterprises Consulting Services)
Louis Ungar (A.T.E. Solutions)
Carl Walker (Cisco)

Guests:
---

Excused:
Bill Huynh (Marvell Inc.)
Eric Cormack (DFT Solutions)
Jon Stewart (Dell)
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 #123, September 20 (draft circulated September 20)
    • No corrections noted.
    • Brad moved to approve, Heiko seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • Nothing to note.

7. Discussion Topics

7 a) Continue Review of Standard Draft

  • Continuing review, starting around Figure 3 in section 4.1.
  • Would people understand what a "P2654 Network" is? It appears without any introduction/explanation. Even simply "Network" might need explanation.  P1687.1 has a definition for "Network" but it references PDL/ICL so would need to be significantly altered for our use.
  • Proposition is that a network involves no protocol change; protocol changes would occur in a bridging device (which would be represented by one of the "targets" in the diagram.
  • Description notes that a bridging device might "recursively support its own interface" - it's maybe not clear what that's trying to convey or what interface is being referred to, since a target will have an interface on its top side.
  • Figure 4 shows a hierarchy of networks.  But isn't a purpose of P2654 to reconcile that, through the modelling, to effectively a single (albeit complex) network.  Does that run counter to the proposition above that a network involves no protocol change?
  • A network provides connectivity from the Interface to the Target(s) and may have any degree of complexity. While it has no bearing on the diagrams themselves, the "Network" will have a different composition depending on whether you view it from a hardware perspective or a software/modelling perspective.
  • Remember that many of the current diagrams are re-used from elsewhere as placeholders and may need to be re-worked to fit the standard. 
  • Unsure how best to make reference to other draft standards - referring to "IEEE P1687.1" may not be useful in the longer term.  How should we make reference to our own standard - refer to "this standard" rather than "IEEE P2654"?    
  • Review to continue from the bottom of Page 7.
  • Version edited today saved as IEEESTD-P2654_Draft_D01_BGVT_20210927.docm in the Drafts/Group Submissions folder.

8. Any Other Business

  • {Slide 15}
  • None.

9. Glossary: 

  • Network will need to be defined.
  • Carried over:
    • PTPG - Programmable Test Pattern Generator/Generation
    • Better define structural test boundary vs functional test
    • Transfer module/library
    • Injection transfer module/library
    • RVF Message (to be refined)
    • RVF Command (to be refined)
    • "Tooling" - need to be clear on what is meant.
    • "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.

10. Takeaways:

  • A network is non-transformative while a bridge is transformative. 

11. Schedule next meeting

  • October 4, 2021
    • Joel will be out for October 11.

12. Topic for next meeting

  • Continue review of standard draft
    • IEEESTD-P2654_Draft_D01_BGVT_20210927.docm
    • Start at foot of page 7.

13. Reminders

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh