Minutes of P2654 Working Group Meeting No.65, 2020-05-11

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

1. Roll Call

Ian McIntosh (Leonardo)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd)
Bill Huynh (Marvell Inc.)
Joel Irby (AMD)
Richard Pistor (Curtiss-Wright)
Jan Schat (NXP Semiconductors)
Jon Stewart (Dell) (joined 11:17)
Louis Ungar (A.T.E. Solutions)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)


By email (non-attendees):

Terry Duepner (National Instruments)

2. Agenda

  • Peter moved to accept the agenda, seconded by Brad, no objections.

3. IEEE Patent Slides

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

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #64, May 4 (draft circulated May 4)
    • No corrections noted.
    • Brian moved to approve, Carl seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • 1149.7 group expects to vote this week on taking their 2nd draft forward to IEEE-SA for editorial work and balloting.

7. Discussion Topics

7 a) Close in on definition of 'System'

  • {Slide 14}
  • Jan had emailed simple and more complex versions of a proposed definition for 'system', from a STAM perspective, and explained the motivations: That it may not have a "brain" but that it should have some property that is worth testing, that it couldn't be accomplished simply by applying existing standards and that aspects of the access depend on the nature of the system.
  • "Everything is worth testing" Light bulb example: A lamp failing to light may not indicate that the bulb is faulty, you need to check that the entire system that supports he bulb (supply, fuses, switches, wiring) is functional. Perhaps better to suggest that there is a need for test rather than that there is worth in testing.
  • If a 'system' is testable using only a single standardised interface, does that mean that STAM has no part to play? The standard generally only tells you how the interface behaves at the device pin face, but STAM will address the broader aspects of the test as a whole, e.g. the sequence of events, any pre-conditioning that is necessary, constraints, etc.  STAM carries more of the "intent".
  • Constraints, especially when testing a board/sub-system as part of a larger system, can be difficult to determine and convey (e.g. avoidance of inadvertently triggering a shut-down).
  • Definitions cited in published books compared (the first two are reproduced on slides 44 and 45 of the meeting pack) :
    • System Test and Diagnosis, William R. Simpson, John Sheppard, 1994
    • Computer Dictionary, Sippl and Sippl, 1974
    • Radio Shack Dictionary, Rudolf F. Graf, 1978
  • From the above, two new terms emerge as recurring: 
    • System Element.
    • System Resources.
  • System Element may equate to a sub-system or perhaps a component.
  • STAM's definition of 'system' may well diverge from 1687.1's definition as STAM's necessarily needs to be broader.
  • Further points are recorded on slides 41 to 43 of the meeting pack.

  • Bullet points recorded during the earlier meetings are now moved to a separate reference file: http://files.sjtag.org/P2654WG/P2654_Reference_Pack.pptx.
  • Forum thread for comments on the outline: http://forums.sjtag.org/viewtopic.php?f=3&p=1444#p1444

7 b) Select other definitions from forum

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • STAM's definition of 'system' needs to be broader than that for P1687.1.

10. Glossary Terms from This Meeting

  • System Element, System Resources.
  • Carried over:
    • '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

  • May 18, 2020.
    • Brian may be unable to join.
    • May 25 is a holiday in both US and UK.

12. Topic for next meeting

  • a) Conclude on additional 'System' definition aspects and/or define Controller aspect
  • b) Select other definitions from forum

13. Reminders

  • None.

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh