Minutes of P2654 Working Group Meeting No.99, 2021-03-01

Meeting called to order: 11:07 AM EST

The slide references relate to the pack used during this meeting, located here: http://files.sjtag.org/P2654WG/P2654_Meeting_99.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:20)
Terry Duepner (National Instruments)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd)
Joel Irby (AMD)
Richard Pistor (Curtiss-Wright)
Louis Ungar (A.T.E. Solutions)
Brad Van Treuren (VT Enterprises Consulting Services)


By email (non-attendees):

Bill Huynh (Marvell Inc.)
Jon Stewart (Dell)
Carl Walker (Cisco Systems)
Tom Thompson (for IEEE)

2. Agenda

  • Brad moved to accept the agenda, seconded by Terry, no objections.
  • Noted that meeting link in Calling Notice is incorrect - hyperlink goes to an invalid meeting although the displayed text appears to be correct.  Ian will check and advise Louis of any correction that is needed.

3. IEEE Patent Slides

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

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #98, February 22 (draft circulated February 22)
    • 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}
  • Brad has presented the ModelPoint idea to P1687.1.

7. Discussion Topics

7 a) What does a Transform Strategy need to do?

  • {Slide 14}
  • Topic b) is blending into this discussion.
  • Email thread prior to meeting, and basis for discussion: http://files.sjtag.org/P2654WG/Meeting_99_email.pdf 
  • Protobuf discussion seems to be pointing to highly specific definitions for each type of transformation. May be better to have broader "classes" that then call up a module for the particular part. So a common interface, removing some of the "uniqueness" for each transformation.
  • Disagreement as there is a need for context to be supplied.  Akin to why P1687.1 are needing to extend ICL, PDL with new commands.
  • As described, this still seems to presume a lot of detailed IP knowledge.
  • A 1687 message may not be useful at the board level but a JTAG can certainly be applied to the board.  Are we missing the bigger system picture?  Does this suggest that we would be better focussing on things we know to be applicable at board-level (and above)? Still need to accommodate that lower-level access where needed, so it needs to be accounted for when considering the higher levels. 
  • Are we replicating what e.g. existing JTAG tools already do?  Shouldn't we just be leveraging off those?  The standard needs to account for cases where there is no prior tooling available.  The top-level host controller may be coordinating disparate interfaces to the system to effect a test, possibly different toolsets employed for each.
  • A lot of presumption that test are pattern based, but in reality a larger system is likely to have analog content, so may be preferable to talk about what behaviours need to be provided.
  • Top-to-bottom JTAG access may not be feasible as once you build up a system, particularly from COTS items, you'll run into JTAG being locked down to protect IP.  However, full system JTAG access is a legitimate Use Case and shouldn't be ignored.
  • To go from a vector form to message-based form is just another transformation step.
  • We don't want unique messages for every type of device, better to have some set of recommended commands that work well. However:
    • Are the commands/primitives proposed just now the best ones to use, do they adequately cover the needs of the most popular cases?
    • Still need to have a "Custom" case for things that won't fit the pre-defined primitives, so do we even need pre-defined primitives?
  • What if Protobuf is dropped? It is Open Source so it can still be branched and maintained.  Might mean we'd need to provide an Open Source Lead if we intend to make hat part of the standard.  Do we even want to constrain tool vendors to using Protobuf or should we be describing something that does the same job and leave it to the tool providers to find their best way to provide the same functionality?  It's the notion of a standard format that we want.

7 b) Defining what comprises a ModelPoint

  • Merged with 7 a) above.

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • Ought to resolve which are the most useful primitives to use for a Protobuf.

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

  • March 8, 2021

12. Topic for next meeting

  • Primitives: What is needed for a generic group

13. Reminders

  • Reiterate: Michele Portolan has proposed a workshop at ETS 2021 (later this month). Related to a special session of papers to be run by Martin Keim.

14. List New Action Items

  • None.

15. Adjourn

  • Eric moved to adjourn, seconded by Brian.
  • Meeting adjourned at 12:07 PM EST

Respectfully submitted,
Ian McIntosh