Minutes of P2654 Working Group Meeting No.130, 2021-11-08

 Meeting called to order:  11:05 AM EST

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)
Terry Duepner (National Instruments)
Heiko Ehrenberg (GOEPEL Electronics)
Peter Horwood (Digital Development Consultants Ltd)
Joel Irby (AMD)
Richard Pistor (Curtiss-Wright) (joined 11:09)
Jon Stewart (Dell)
Louis Ungar (A.T.E. Solutions) (joined 11:06)
Brad Van Treuren (VT Enterprises Consulting Services)


Bill Huynh (Marvell Inc.)
Brian Erickson (JTAG Technologies)
Carl Walker (Cisco)
Tom Thompson (for IEEE)

2. Agenda

  • Joel moved to accept the agenda, seconded by Terry, 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 #129, November 1 (draft circulated November 1)
    • No correction noted.
    • Joel moved to approve, seconded by Terry, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • 1149.7 has started re-circulation ballot.
  • Joel participating in Heterogeneous Integration Roadmap (HIR) Security Technology Working Group (TWiG).
    • Considering that new standards may be increasing the potential attack surface.
    • Generally outside the scope of the standards to provide security solutions (and IP vendors may have their own ideas).

7. Discussion Topics

7 a) Continue Review of Standard Draft

  • {Slide 14}
  • Re-visit of Introduction.
  • Noted that there is an Introduction (as reviewed P2654 WG Minutes - 2021-11-01) in the pages prior to the Contents List as well as the Introduction at 4.1. The latter may need re-titled to differentiate.
  • Continuing review of clause 4.3 and representation of a system.
  • Brad is working on some "blog posts" for LinkedIn, these include systems examples: Automotive Pre-crash Safety System, Zynq SoC.  May be too detailed/specific to use for the general body of the standard, but could be useful examples, in an annex, to show diversity of "systems" that P2654 can support.
  • Probably want something more abstract or generalised for the body of the standard.
  • Existing diagram (System Example 2, slide 104) fails to show that the sub-systems are not the end-points.
  • Notable that there will be a difference between sub-assemblies that have a CPU and those that are "dumb".
  • Instruments are not always directly accessible, there may be some circuit block in front of it that limits what you have access to. In that case you have treat the instrument and the circuit block as if were "the instrument" with whatever accesses are provided by the block.
  • P2654 can't dictate what accesses are provided - there may be a DFT case to offer around that but it is outside of the scope of this standard to do that - P2654 is about making the best use of what is available and making it easier to use.
  • Slide 104 edited to start trying to expand below the sub-system - that there are things that might be driven and things that might be observed.  Observation might include manual inspection that some effect has occurred and provided that observation is fed back to the test program then it is no different to something directly observed.

8. Any Other Business

  • {Slide 15}
  • None.

9. Glossary: 

  • None.
  • Carried over:
    • 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:

  • A board overlaps to the System Domain when it enables additional objectives normally provided by sub-systems. 

11. Schedule next meeting

  • November 15, 2021

12. Topic for next meeting

  • Continue review of standard draft
    • IEEESTD-P2654_Draft_D01_BGVT_20211108.docm
    • Continue with clause 4.3.

13. Reminders

14. List New Action Items

  • None.

15. Adjourn

  • Peter moved to adjourn, seconded by Joel.
  • Meeting adjourned at 12:01 PM EST

Respectfully submitted,
Ian McIntosh