Minutes of P2654 Working Group Meeting No.117, 2021-07-26

Meeting called to order: 11:05 AM EDT

The slide references relate to the pack used during this meeting, located here: http://files.sjtag.org/P2654WG/P2654_Meeting_117.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)
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)
Jon Stewart (Dell)
Carl Walker (Cisco Systems)

Tom Thompson (for IEEE)

By email (non-attendees):

Bill Huynh (Marvell Inc.)
Brad Van Treuren (VT Enterprises Consulting Services)

2. Agenda

  • Carl moved to accept the agenda, seconded by Joel, 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 #116, July 19 (draft circulated July 19)
    • No corrections noted.
    • Brian moved to approve, Terry seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • Brad has given a presentation to P1687.1 aiming to unify some of the concepts and show delineation between P2654 and P1687.1 - Ian relayed the slides but was unable to comment on them. A link will be provided once Brad has posted the slide pack.

7. Discussion Topics

7 a) Continue review of standard draft

  • {Slide 14}
  • Still to answer some key questions:
    • Who is expected to provide the information that goes into the P2654 model?
    • What is that information?
  • Are we trying to describe a process flow, e.g. for a Use Case? That might be an example, but we can reasonably assume that there is some sort of software tool that will hold the model. There needs to be inputs to build the model detailing specific features/attributes of the constituent parts of the system.
  • Information might be at component level, circuit board level, sub assembly level...  Some data might be produced by the in-house circuit/system designers (e.g. exported from CAD tools or possibly hand-generated), some might be provided by the component or sub-assembly vendor.  Notion might be considered vaguely similar to a BSDL describing an 1149.1 component to JTAG software tools.  Potentially more complex since functionality of some parts, even at component level, might be contingent upon the presence of firmware/software (e.g. getting a processor into a testable state).
  • P2654 is likely to be more meaningful to a) people who might produce software tools to implement P2654 and b) people designing tests. To a person executing a test, the use of P2654 is likely to be transparent. The test operator is more likely to be interested in the diagnostics that are provided: This will be dependent on the tests applied and the data that is made available via P2654, but in any case is an opportunity for tool vendors to add value in the application level.
  • The tooling supporting the software model shouldn't be overly constrained by P2654 but the form of information that goes into the tooling will need to be standardised else it will not be portable - but is that an essential part of this standard or could it be in some follow-up extension?  What have we got time for?
  • Should the inputs to the model be described in terms of being "necessary" or is it more a "minimum that is useful"? Certainly, it needs to be given in the context of the tooling it is to be used with (the model).
  • We may need to allow differing formats for inputs. In simple terms these could be described as:
    • Binary: Where the design detail is obscured, e.g. in order to provide design security or prevent mis-use,
    • Source: Where the design detail is open and CAD data etc., is available.
  • Also need a way to introduce the system hierarchy into the model.  Often this isn't held in CAD files and there may be cases where the configuration is dynamic: Equipment user has changed the system composition, some circuit parts may be intentionally switched on/off, or an item has failed invalidating the perceived model. In the latter case, we may just have to accept that it is "broken".
  • Ian summarised the process and timeframe required to move from a "complete" draft standard through the reviews and balloting process to get to a published standard, noting that our PAR expires at the end of 2022.

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • Tooling to maintain the model is expected to be a key enabler for application of P2654.

10. Glossary Terms from This Meeting

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

  • August 2, 2021

12. Topic for next meeting

  • Continue to review standard draft - where does STAM fit in the foodchain?.
  • May talk through Brad's P1687.1 presentation (if available).

13. Reminders

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh