Minutes of P2654 Working Group Meeting No.75, 2020-08-10

Meeting called to order: 11:06 AM EDT

The slide references relate to the pack used during this meeting, located here: http://files.sjtag.org/P2654WG/P2654_Meeting_75.pdf

1. Roll Call

Ian McIntosh (Leonardo)
Terry Duepner (National Instruments)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd)
Bill Huynh (Marvell Inc.)
Richard Pistor (Curtiss-Wright)
Jan Schat (NXP Semiconductors)
Jon Stewart (Dell) (joined 11:08)
Louis Ungar (A.T.E. Solutions)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)


By email (non-attendees):

Eric Cormack (DFT Solutions)
Joel Irby (AMD)

2. Agenda

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

3. IEEE Patent Slides

  • {Slides 5-10}
  • Patent and Copyright slides reviewed. 

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #74, August 3 (updated draft circulated August 5)
    • No further corrections advised.
    • Terry moved to approve, Brad seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • P1149.7 ballot group formation has commenced.

7. Discussion Topics

7 a) Diagrams for Standard

  • {Slide 14}
  • Follow up on questions posed on slide 61 of the meeting pack.
  • Do we need a detailed/complex diagram as shown on slide 61 or would a simple host/client diagram suffice? Working through what P2654 needs to do and how it should be used is probably best done using a simple case., but an illustration of how it could be used in a more complex scenario is probably useful to show what may be possible. Perhaps a worked example showing a case where two interfaces are involved could be in an annex.
  • We may have a difference compared to many of the other standards in that we're not defining rules for what goes into the hardware. We may be using different communication buses and so the questions are "what is the data?", "what features does the component (device/board/sub-assembly?) need to have to comply with the standard?" Not defining how the data is obtained just that the requested data is passed.  Rules may need to change dependent on what type of component is being considered.
  • A "keyword" may provide access to a given test feature. Does a keyword relate to a callback? The keyword is part of an outward-facing mechanism and does not imply any specific method or implementation.
  • Model language would need to export the interface that makes up that  mechanism.  However a different export may be needed so that EDA tools can understand the "method" behind the "mechanism".
  • Interoperability was a key objective for SJTAG.  Users may want to execute tests on run-time test system from a vendor different to the toolset that generated the tests. PDL needs to be compiled - do we really want to be mandating that a run-time system needs to be able to do that?  Provided the data patterns applied at the system interface are the same then the effect on the hardware should be the same. This is OK for canned/static test but doesn't really work for interactive cases. Are we clear on what we mean by "interactive"?  Possibly we need to set the interactivity aside as a more advanced case requiring additional information.
  • Does the system test user ever need to know or care how e.g. a temperature value is obtained? Does it matter that it may be using 1687 or some other interface?  At the moment, 1687 doesn't present a way for it to be used beyond the device level, P2654 is intended to fill the gap between the user application and the hand-off to the lower level standards, per the PAR.
  • There are clearly multiple perspectives that need to be reconciled in order to for the group to progress:
    • End user/System tester
    • Embedded application
    • Component/sub-system designer
    • EDA Tool vendor (are we talking about board schematic tools or chip design/test tools or something else?).  
  • Further notes on slides 76-77 of the meeting pack.

7 b) Definitions from forum

  • Absorbed into 7a) but not discussed during this meeting.
  • Previously discussed:
    • Callback; AccessLink, Access Point, Access Interface; Component; Device; Hierarchy; BIST/BIT.

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • A keyword is part of a mechanism and does not imply a specific method.  

10. Glossary Terms from This Meeting

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

  • August 24, 2020.
    • No meeting August 17.

12. Topic for next meeting

  • Continue from today, perhaps pick up further on the questions posed by Brad today.
    • a) Discussion of perspectives on STAM
    • b) Diagrams and Terms

13. Reminders

  • None.

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh