Minutes of P2654 Working Group Meeting No.25, 2019-07-08

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

1. Roll Call

Ian McIntosh (Leonardo)
Eric Cormack (DFT Solutions)
Terry Duepner (National Instruments)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Bill Huynh (Marvell Inc.)
Joel Irby (Arm)
Naveen Srivastava (Nvidia)
Jon Stewart (Dell)
Brad Van Treuren (No affiliation)

Guests:
---

By email (non-attendees):
---

Excused:
Jan Schat (NXP Semiconductors)
Louis Ungar (A.T.E. Solutions)
Carl Walker (Cisco Systems)

Peter Horwood (Firecron Ltd.) attempted to join prior to roll call but was unable to connect to WebEx.

2. Agenda

Eric moved to accept the agenda as proposed, seconded by Brad, no objections.

3. IEEE Patent Slides

  • {Slides 5-9}
  • Patent slides reviewed.

4. Review and Approve Previous Minutes

  • {Slide 10}
  • Meeting #24, July 1 (draft circulated July 1)
    • No corrections.
    • Eric moved to approve, Brian seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Discussion Topics

6 a) Outline for Draft Standard

  • {Slide 12}
  • IEEE-SA guidance page: https://standards.ieee.org/develop/drafting-standard/stdswritten.html. Eric expects to use the Word template for the standard.
  • Looking at the 1687 standard as an example. all sections up to and including section 3 can be assumed to be required. Beyond that, we can pretty much have what we like. 
  • The 1687 standard takes a different approach to including language aspects from 1149.1, having some elements in the main body and others in annexes (when 1149.1 added BSDL it was purely as an Annex).
  • There are limitations on the file formats used for diagrams, but none on the method of preparation.
  • There are requirements for the "management" of the draft - during preparation it is "private" to the group so should not be hosted in a publically accessible web location.  Edit access should be restricted to the Editor and perhaps a limited number of others.  At suitable points a versioned draft is made available for the group to review and comment on.  IEEE-SA editorial staff will become involved prior to the balloting stage to ensure that the document follows IEEE guidelines.
  • Brad raised the question of a business case for STAM - how the standard will be used and by whom.  It is important that industry can see how they would be able to make use of STAM.
  • While a single tool that supports the lower level standards and STAM is possible it would seem unlikely and there would need to be some hand-off between tools, e.g. 1687 retargeter leveraged by a STAM tool.
  • How are companies going achieve end-to-end solutions?
  • We don't want to detail the lower level standards we support; we aim not to be limited and don't wish to imply that there are constraints.
  • A minimal set of information for the hand-off may be desirable, but perhaps pin-level information may create problems.  In P1687.1 there has been consideration of "just data" or "just the call back".
  • Brad shared some slides from Martin Keim explaining how he could export from the TAP to a number of different target formats to suit different test hosts:, STIL, .V, PDL.
  • If you use callbacks, do you just supply the callback or a callback that gives some insight  to what is required (affects who can reasonably use it)? What would tool vendors need to support that?  Brian suggested that the group should seek that information formally and from more than those represented in this group. We would need to assemble a clear presentation of what we are asking.
  • Considering Martin Keim's slides, with an I2C interface which has its own commands, there may be many cycles involved so it may be difficult to synchronise to retrieve responses.  It is probably easier for us to be as abstract as possible but that will be more difficult for the integrator to use.
  • If you can't target the UUT and say "if you do that, I'll do this" then you may be limiting STAM to only a System-on-Board or System-on-Chip standard for many users.  Extending that to a system may be outside the STAM scope and another SJTAG layer on top of STAM (in the application level that uses STAM), but in that case it may require managing expectations of the potential users.  This may be a theme for future conference presentations. 

6 b) Glossary

  • New forum section for glossary comments: http://forums.sjtag.org/viewforum.php?f=40
  • Intent is to have a separate discussion topic for each term. Brad proposes to copy what he has on the slides as a "topic starter" for each of the terms he has so far identified.  The section is of course open for other terms to be added as members see fit.
  • Forum section is open to P1687.1 people that are registered too so it relieves some of the effort of taking discussions backward and forward between the two groups.
  • Drop this subject from the meeting agenda and use the forums as the main discussion mechanism for now.

7. Any Other Business

  • {Slide 13}
  • None.

8. Today's Key Takeaways

  • Business model needs to be investigated
  • Poll tool providers, integrators to determine what they would want/need to support STAM.

9. Glossary Terms from This Meeting

  • None.
  • Carried over:
    • "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 meeting.
    • "Event", "Access Interface" as proposed at April 15 meeting

10. Schedule next meeting

  • July 15, 2019
    • Louis out until July 28.

11. Topic for next meeting

  • Business case for STAM.

12. Reminders

  • Brad will provide Louis with a "refresher" on diagram(s) in advance of presentation.

13. List New Action Items

  • None.

14. Adjourn

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

Respectfully submitted,
Ian McIntosh