Notes of P2654 Working Group Meeting No.152, 2022-06-06

 Meeting called to order:  11:06AM EDT

The slide references relate to the pack used during this meeting, located here:

Reference pack 1 is located here: (all 2020 material)
Reference pack 2 is located here: (all 2021 material)

iMeetCentral site: 

1. Roll Call

Ian McIntosh (Leonardo) (chair)
Brian Erickson (JTAG Technologies)
Richard Pistor (Curtiss-Wright)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco)


Peter Horwood (Digital Development Consultants Ltd)
Joel Irby (AMD)
Louis Ungar (A.T.E. Solutions)
Tom Thompson (for IEEE)

Noted that the meeting was not quorate.

2. Agenda

  • Abridged agenda used.

3. IEEE Slides

  • {Slides 5-13}
  • Not commented.

4. Review and Approve Previous Minutes

  • {Slide 14}
  • Meeting #152, May 23 (draft circulated May 23)
    • Insufficient attendance to vote on approval, carried over to next meeting.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 16}
  • Not discussed.

7. Discussion Topics

7 aClause 6 - Flesh out  subclauses (continue)

  • {Slide 17}
  • Work from IEEESTD-P2654_Draft_D01_BGVT_20210523.docm {shared}.
  • Brad present elements from the P1687.1 Codification slide pack and talked through some of the key points and how parts of this copied across into P2654 {added to meeting pack as slides 22-30}.
  • Commentary that discussions of top-down/bottom-up alongside left-to-right and right-to-left may be confusing, so may need more consistent orientation. 
  • {Brad encountered networking issues and had to leave and rejoin}
  • "Parser", as shown in the diagrams, may be an incorrect term.
  • The P2654 version of the main diagram is expanded from the P1687.1 version by the addition of InjectionProcs and DebugProcs.
    • Could DebugProcs be optional? What do they do?
    • Could omit them by why would you? They log actions allowing you to see how messages are being processed; Can help you understand if something isn't working as you expect. Could also be to e.g. export SVFs of the operations.
  • TransferProcs are green-to-blue while InjectionProcs are blue-to-green - important as this shows that the InjectionProc needs to update the model state "upwards".
    • Note that we can't rely on colour in the standard document - may need text annotation in the boxes instead.
  • The older diagram we used (slide 104 from Reference Pack 2) showed "flow" while the new diagram (slide 24) describes what we need to write rules for in the standard.
  • We (or the Translator) don't need to know what goes on inside the TransferProcs, we just need to have checked that the message is valid and has an associated TransferProc, return error signals, etc.
  • We probably need to wait on P1687.1 consolidating some of its views and text before we can incorporate our version of it into our document. So, are there parts of the Standard we can progress while we wait, e.g. the Glossary elements?
  • Does the Translator really exist? Isn't it a composite of the TransferProcs and the configuration information?
    • It is an aggregation but having the "Translator" as an entity allows separation of the different APIs involved.
  • Retargeting occurs when we are working with the same protocols at both host and client sides, e.g. with a scanbridge.
    • Does this suggest a different view of "retargeting" from 1687? No, but we probably don't need all the aspects of retargeting that 16987 employs.
  • Latest revision remains: IEEESTD-P2654_Draft_D01_BGVT_20220523.docm (

8. Any Other Business

  • {Slide 18}
  • Not discussed.

9. Glossary: 

  • Not discussed.
  • Carried over:
    • Transfer Channel, replacing P2654 Message Channel
    • Network will need to be defined
    • 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:

  • Not discussed. 

11. Schedule next meeting

  • June 13, 2022

12. Topic for next meeting

  • Clause 6 - Flesh out  subclauses (continued).
  • Follow with clauses 7, 8.

13. Reminders

14. List New Action Items

  • None.

15. Adjourn

  • Brad moved to adjourn.
  • Meeting adjourned at 12:02 PM EDT

Respectfully submitted,
Ian McIntosh