Minutes of P2654 Working Group Meeting No.111, 2021-06-07

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_111.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) (joined 11:44)
Terry Duepner (National Instruments)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd) (left 11:39)
Joel Irby (AMD)
Richard Pistor (Curtiss-Wright)
Louis Ungar (A.T.E. Solutions)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)

Tom Thompson (for IEEE)

By email (non-attendees):

Bill Huynh (Marvell Inc.)
Heiko Ehrenberg (GOEPEL Electronics)
Jon Stewart (Dell)

2. Agenda

  • Brad moved to accept the agenda, seconded by Carl, 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 #110, May 24 (draft circulated May 24)
    • No correction noted.
    • Brad moved to approve, Terry seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • P1500 is now in ballot.
  • P1149.7 is probably one meeting away from going to re-circulation.

7. Discussion Topics

7 a) Feedback from TAAA Workshop

  • {Slide 14}
  • Feeling is that it went well, with around 20 attendees, 15 on any given presentation.
  • EDA tool vendors concerned about clock timing/synchronisation issues which really lie outside of P2654's domain.
  • Appears to be an interest/need for what we're doing.
  • Separately at ETS, Erik Larsson presented on a paper looking at a 1687 application with a bridging device, and so is peripherally related to P2654 the video of the presentation is recommended (link is in the slide pack for this meeting).
  • Noted that in this example the bridging device uses discrete signals to indicate e.g. that data is ready: This recalls an early SJTAG/STAM discussion around a possible need for semaphores. 1149.1 relies on polling so a "wait-until-ready" action is not possible with static vectors, but can be accomplished using STAPL, etc. Commented during TAAA that some sort of interrupt capability within 1149.1 would be useful. 

7 b) Continue review of standard draft

  • Annotation made on IEEESTD-P2654_Draft_D01_BGVT_202105131.docm, and saved as IEEESTD-P2654_Draft_D01_BGVT_20210607.docm (both in folder Drafts/Group Submissions).
  • Text has been added throughout section 4.1 to supplement the diagrams. The text was not reviewed during the meeting, the group should look at this outside of the call {ACTION}.
  • "Figure 5" is new, one of Jeff Rearick's diagrams that will be added to P1687.1
  • The stack diagram from ITC '18 is possibly too complex for the Introduction and is perhaps better in 4.3 Architecture.  A simpler version might be usable here though, Ian will consider that {ACTION}.
  • Two new diagrams added attempting to show separation between the model and the plug-ins.
  • Plug-ins are described as being written in C++ or a native form: is this appropriate?
    • P1687.1 is leaning towards using C/C++ for detailing Transfer Procedures.
    • In an embedded usage, the operating software is likely to be C/C++. Requiring e.g. Python in addition may be increasing resource requirements too much. 
    • Native plug-ins, e.g. for a purely in-house solution, could possibly be more efficient or convenient but could it be compliant with a standard? If the plug-in is not portable across tooling is there really conformance with "a standard"?
    • We weren't intending to propose a DSL but what we come up will need to have some attributes similar to a DSL.
    • Are we talking about an API or is it more than that? If a plug-in is supplying code that needs to be executed, e.g. a call-back, then surely that needs to be in form that the model host can execute, so does that not dictate that there must be an acceptable "language".
    • Even if just an API there will need to be some defined messages. 
  • What do we mean by "Root" in these diagrams?  It is the highest point in the model but does that mean the point of application level control or is it the point where the hand-off from the model to the physical hardware occurs?
  • Returning to the ITC '18 diagram, does STAM ever have direct access to the hardware? Diagram suggests there's always a driver layer, so what is possible will be dependent on what the driver provides, so surely that imposes some minimum requirements on the driver? 
  • Additional diagrams included in slides 85-94 of the meeting pack - most have not been discussed in detail yet.

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • None.

10. Glossary Terms from This Meeting

  • None.
  • 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

  • June 14, 2021

12. Topic for next meeting

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

13. Reminders

14. List New Action Items

  • [111.1] All: Review text added to section 4.1 of the draft.
  • [111.2] Ian: Attempt to simplify the stack diagram.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh