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: 

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)


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