Minutes of P2654 Working Group Meeting No.73, 2020-07-27

Meeting called to order: 11:04 AM EDT

The slide references relate to the pack used during this meeting, located here: http://files.sjtag.org/P2654WG/P2654_Meeting_73.pdf

1. Roll Call

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

Guests:
---

By email (non-attendees):
---

Excused:
---

2. Agenda

  • Eric moved to accept the agenda, 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 #72, July 13 (updated draft circulated July 15)
    • No further corrections advised.
    • Brian moved to approve, Terry seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • None.

7. Discussion Topics

7 a) Definitions from forum

  • {Slide 14}
  • Previously discussed:
    • Callback; AccessLink, Access Point, Access Interface; Component; Device; Hierarchy.
  • Common conclusion is that many of the terms we might use will require to be qualified by context.
  • TTSC would like to see common definitions across standards.  While that will be possible for some terms many others will need to be specific to their usage within STAM, but we need to be careful where there may be crossover with e.g. P1687.1.
  • We could make a general statement that terms are defined specifically in the context of STAM so that we do not need to state the context every time, but it may not always be that simple as we overload some terms, such as 'interface' - device interface, board interface, etc.  This ought to be manageable as there are not too many cases.
  • BIST/BIT:
    • A common view may be that BIST (Built-In Self-Test) relates to a device feature while BIT (Built-In Test) is something that a system (or board) might have.
    • Also introduces concepts like POST (Power-On Self-Test).
    • Previous definition of BIST (http://forums.sjtag.org/viewtopic.php?f=40&t=778) suggested that BIST was device-level and noted that could be either run at power up or in response to some external command or event.
    • BIST is self-sufficient and does not rely on any additional resources.
    • BIT is often driven by a customer requirement and is tailored in as part of the design.  The designer may make more features available than requested for their own diagnostic purposes. BIST will tend to be part of the hardware and cannot be altered.
    • BIT is often associated with programmed parts.
    • The end-user may not be interested in diagnostic details, only if the system is "good" or not.  The diagnostics and repair aspects in the event of a fault may be seen as "someone else's problem" but may be part of the bigger picture the supplier has to consider.  Maintainer's certainly want diagnostic information.
    • BIT and BIST information may well be used during manufacture, even if what the end-user is presented with is filtered. 
    • What the end-user needs to see may be case dependent: While in some cases detail of what is failing may help the user decide what they want to do, but e.g. a pilot may not want the additional workload and simply want a Go/NoGo status.
    • Some faults may not affect system availability, e.g. if there are redundant modules such that one can fail but the system remains fully operational.  Dependant on the use case, it may not be a priority to alert to end-user but the maintainers still need to be alerted.
    • BIT is frequently sub-divided into three areas:
      • PBIT - Power-on BIT, runs at switch on. my have some execution time constraint,
      • CBIT - Continuous BIT, runs continuously or perhaps cyclically, and is usually heavily time and resource constrained,
      • IBIT - Initiated or Interruptive BIT, run on demand, usually in response to a suspected fault, and may be quite extensive.
    • In addition you may have:
      • Concurrent BIT vs Non-concurrent BIT
      • Distributed BIT vs Centralized BIT
    • STAM does not provide the BIT (or BIST) functions, but provides the accesses that BIT (within the application) can utilise.
    • That application can change, for example as a product moves through manufacture the "customer" at any stage will be the next stage in the process so the applications (tests) you apply will vary ("Customer Shift").
    • Further notes on slide 58 of the meeting pack.

7 b) Diagrams for Standard

  • Absorbed into 7a) but not discussed during this meeting.

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • The application context in which BIST/BIT may be applied is not directly relevant to STAM..  

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

  • August 3, 2020.
    • [Post-meeting note] Richard will be out.

12. Topic for next meeting

  • Continue from today, but change focus to diagrams:
  • a) Diagrams for Standard
  • b) Definitions from forums

13. Reminders

  • None.

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh