Minutes of P2654 Working Group Meeting No.70, 2020-06-22

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_70.pdf

1. Roll Call

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


By email (non-attendees):


2. Agenda

  • Date in item 4 should read "June 15" (corrected in pack linked above).
  • Brian moved to accept the agenda as amended, seconded by Terry, no objections.

3. IEEE Patent Slides

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

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #69, June 15 (draft circulated June 15)
    • No corrections advised.
    • Brad moved to approve, Terry seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • 1149.7 group has received some feedback from outside the group, which they are considering.

7. Discussion Topics

7 a) Definitions from forum

  • {Slide 14}
  • Probably deal with one or two definitions each week - ensure there is time to progress other items in parallel.
  • Work through forum list from the bottom (anything that gets updated within the forum will automatically move to the top). Keep record of the items we've addressed.
  • May be best to simply note what needs to be done (if anything) and take the actual editing off-line, bring the revised text back to the meetings for approval.
  • Callback: 
    • Synchronous/blocking: Does it need to be? Probably, to ensure that action is allowed to complete.
    • May be different in STAM from P1687.1 due to different constraints applying.
    • Callback may not be the correct term and perhaps "handler" would be more accurate. Callbacks are frequently registered and perform a function that is indirectly referenced by the caller.
    • P1687.1's definition is expressly written in terms of transformations - that is probably also true for STAM.
    • Should it be qualified as "Transformation Callback"? Do we think we will have any other kinds? Perhaps not but limiting the scope may give readers better insight into what is intended.
    • Further notes recorded on slide 48 of the meeting pack.

7 b) Diagrams for Standard

  • Identify what diagrams we need during the meeting then try to find or create them off-line.
  • Before looking the sections, we ought to decide how we will represent hierarchies, vertically or horizontally, and ensure that we are consistent about how we present them.
  • Are we considering physical hierarchies or test flow hierarchies we may want to think of them orthogonally - at least, they may not readily align.
  • Jeff Rearick has proposed a horizontal hierarchy for P1687.1 (example was not available to share with this group).
  • A concern of P1687.1 is supporting design validation and control of aspects of timing. STAM may not need to be concerned about the specific timing of circuits and can rely on the leveraged standards to handle that instead. But does that always hold true? The intent of a test might imply some timing aspect, so how will the leveraged standard know about that?  Or is STAM concerned only with the order of events and can defer specific timing to the leveraged standards?
  • Need for timing may depend on the system, e.g. for safety it might necessary that sub-system B responds within a set timeframe of a particular event occurring in sub-system A.
  • Further notes recorded on slide 49 of the meeting pack.

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • Does STAM consider Order over Timing?
  • Does STAM need a mechanism that supports a trigger for time critical event sequences?

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

  • June 29, 2020.

12. Topic for next meeting

  • Continue from today:
  • a) Definitions from forums
  • b) Diagrams for Standard

13. Reminders

  • None.

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh