Minutes of P2654 Working Group Meeting No.59, 2020-03-23

Meeting called to order: 11:12 AM EDT

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

1. Roll Call

Ian McIntosh (Leonardo)
Eric Cormack (DFT Solutions)
Terry Duepner (National Instruments)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd)
Bill Huynh (Marvell Inc.)
Joel Irby (AMD)
Jan Schat (NXP Semiconductors)
Jon Stewart (Dell)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)


By email (non-attendees):

Louis Ungar (A.T.E. Solutions)

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.
  • LoA is still expected from Michele in due course.

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #58, March 16 (draft circulated March 16)
    • No corrections noted.
    • Terry moved to approve, Eric seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • None.

7. Discussion Topics

7 a) Sketch out an outline of the draft

  • {Slide 14}
  • Bullet points recorded during the earlier meetings are now moved to a separate reference file: http://files.sjtag.org/P2654WG/P2654_Reference_Pack.pptx.
  • Draft outline is in slides 17-28 of this week's pack (linked in the heading of these minutes).
  • Louis had proposed consideration of would form a system and what might not be a system.
  • Terry shared a perspective from NI where this had been recently discussed in relation to test stations as a product.  The conclusion from this was that in order to be a system the item had to have a "brain" or controller of some sort - a part that services a set of functions. There may or may not be software on top of that.
  • Could something be a system without a brain? Not within NI's chosen definition, although in other domains you could consider, e.g., a purely mechanical system.
  • Ian noted that the term "system" would be typically applied to an entire radar, i.e. "system test" would relate to testing the antenna, processor, receiver and power supply LRUs as one. However it more typical to supply the radar as separate LRUs as each type of LRU is fully interchangeable with others of the same type. Each of the LRUs has a controller and so would fit in with the definition that NI suggest. LRUs are sold off against their own ATP, and "System Test" is used mainly for DVT and software integration. 
  • A USB PHY is probably not a system - more a functional block or perhaps a sub-system, and would be tested as part of a module or higher assembly.
  • Louis had previously raised a point about boards that have no function on their own. Ian agreed that a function can be split, e.g. a selectable filter network where the FPGA and digital control are on one PCA and the analogue filter elements on another. Individually, neither is very useful and the function only exists when the two are brought together. The PCAs are a practical decomposition for noise immunity in this case, not because of functional needs. They would usually only be supplied as a module or SRU, not PCAs.
  • System is a matter of perspective: A PC, as a general purpose computer, might be considered a system, but if that PC is incorporated into test station then it become a sub-system of the system that is the test station.
  • Does it matter what is a system and what is a sub-system?  Probably not from a STAM standard perspective, but it likely matters in communicating to potential users of STAM where the standard could be used.
  • A block diagram approach may help - show parts and sub-parts; communications across interfaces. Show transformations happening at the level where interfaces change. UML/SysML were suggested previously in this regard.
  • While the blocks would have different interfaces as you move through the hierarchy, they would be similar in generic/abstract terms, and that's what STAM can exploit to be universally applicable, with specialisation applied at each level. 
  • Above discussion captured in slide pack {slides 22 and 23}.
  • Forum thread for comments on the outline: http://forums.sjtag.org/viewtopic.php?f=3&p=1444#p1444.

8. Any Other Business

  • {Slide 15}
  • Joel has created a "Company Page" for STAM/SJTAG (https://linkedin.com/company/SJTAG), and requests that members "follow" the page. Once it reaches a critical mass (~10 followers) Joel will make a post on the page, likely a re-share of the notice on the release of IEEE Std 1838.  Posts on this page should be publicly visible, unlike those on the SJTAG "group" page in LinkedIn.
  • Brad has been sharing some of our discussion on "system" definition with the P1687.1 group..

9. Today's Key Takeaways

  • None.

10. Glossary Terms from This Meeting

  • Nothing new.
  • 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, 2019 meeting.
    • "Event", "Access Interface" as proposed at April 15, 2019 meeting.
    • 'Port' needs to be developed.

11. Schedule next meeting

  • March 30, 2020.
    • Reminder on time: Meeting returns to 11 US Eastern, 4 PM BST/5PM CET.

12. Topic for next meeting

  • What is a system, what is not a system? (Continuation)
  • Use Cases: Intent and objectives.

13. Reminders

  • None.

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh