Minutes of P2654 Working Group Meeting No.115, 2021-07-12

Meeting called to order: 11:07 AM EDT

The slide references relate to the pack used during this meeting, located here: http://files.sjtag.org/P2654WG/P2654_Meeting_115.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)
Eric Cormack (DFT Solutions)
Terry Duepner (National Instruments)
Heiko Ehrenberg (GOEPEL Electronics)
Richard Pistor (Curtiss-Wright)
Jon Stewart (Dell)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)

Tom Thompson (for IEEE)

By email (non-attendees):

Bill Huynh (Marvell Inc.)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd)
Joel Irby (AMD)
Louis Ungar (A.T.E. Solutions)

2. Agenda

  • Eric 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 #114, June 28 (draft circulated June 28)
    • No corrections noted.
    • Brad moved to approve, Terry seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • Ballot for P1500 has closed.
  • P1149.4 working group has formed.
  • P1149.1 is nearing revision point, can expect a Revision PAR to be raised soon.
  • P1149.7 expect to have final meeting on ballot-ready draft on July 14th {corrected}.

7. Discussion Topics

7 a) Continue review of standard draft

  • {Slide 14}
  • Question from last time was touching on "who does what?", "who is responsible for providing what information?".
  • Is there a one-size-fits-all answer in terms of who provides information needed by a P2654 implementations or does it depend on the level it is being applied? e.g.:
    • Applied to a "True System" (whatever that might mean) or
    • Applied to a SoC.
  • Tests can be "named" and run by the user/test executive without knowing the nature of the test; irrelevant whether it is a functional test or boundary scan test.
  • "End User": Be clear - may be taken to mean "the operator" in some cases, the "test developer" in other cases, etc.
  • Format of response could differ, e.g. indicating a state (such as Go/NoGo), returning a value or reporting a diagnostic.  Different data forms may need to be handled differently.  But is that P2654's concern?  In principle, no, it's a matter for the "application" and P2654 is only concerned with the RVFs but within a node, there needs to appropriate handling of different content by the Transfer Functions.
  • There may be many levels within a P2654 system where documentation could be produced.  We don't necessarily dictate what the form of result data is but the overall model needs to be able to allow the results to properly cascade through the levels.
  • General principle is that P2654 is concerned with moving the data through the system, interpretation of the data is for the system.  This does not preclude a future standard subsequently overlaying a specification for the data or its interpretation (e.g. for diagnostics).
  • When we discuss registers we seem to assume that the registers will be static, i.e. if you set it and then read it you expect to see what you set. But need to be aware that some registers may be volatile and may be altered by the hardware (e.g. an interrupt flag being raised after it was cleared). We can only expect P2654 to carry out polling as it cannot really be event driven.
  • A key issue that we have to provide a way for people to describe the structure of the data. 
  • See also slides: {Slides 97, 98}.

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • Transfer Procedures may need to know about the types of data being handled.
  • P2654 itself doesn't as the infrastructure is format agnostic.
  • The Transfer Procedures are interested in the structure of the data not its intent.

10. Glossary Terms from This Meeting

  • "True System".
  • Comment that "End-User" is subject to perspective and so needs to be qualified.
  • Carried over:
    • 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.

11. Schedule next meeting

  • July 19, 2021
    • Jon, Louis and Joel out July 19.

12. Topic for next meeting

  • Continue to review standard draft - where does STAM fit in the foodchain?.

13. Reminders

14. List New Action Items

  • None.

15. Adjourn

  • Brad moved to adjourn, seconded by Jon.
  • Meeting adjourned at 12:01 PM EDT

Respectfully submitted,
Ian McIntosh