Minutes of P2654 Working Group Meeting No.114, 2021-06-28

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_114.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)
Louis Ungar (A.T.E. Solutions)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)

Guests:
Tom Thompson (for IEEE)

By email (non-attendees):
---

Excused:
Bill Huynh (Marvell Inc.)
Jon Stewart (Dell)

2. Agenda

  • Brad moved to accept the agenda, seconded by Terry, 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 #113, June 21 (updated draft circulated June 23)
    • No further 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}
  • Ballot for P1500 will be closing soon (July 1st).
  • To what extent does P2654 need to support P1581? Probably does not do so explicitly as the P1581 behaviour is probably dealt with at the application level; P2654 needs to concern itself with moving the test data through the interface to the 1581 target device, often, but not exclusively, using 1149.1.

7. Discussion Topics

7 a) Continue review of standard draft

  • {Slide 14}
  • Some diagrams in 4.1 (Introduction) may be going beyond what is appropriate hence attempts to simplify some.
  • Section 4.3 is "Architecture" so more involved diagrams may be appropriate, but again some of those currently proposed may be stretching beyond the scope of architecture.
  • Attempting to simply the diagramatic description of a node; Can we resolve towards fewer, more generic node types?
  • Selector is a case in point.  Notionally it appears that it could become a single form but TAP selector presents a problem as it is dependent on an attained state rather than a value set in a register.
  • For a system test, will we have access to those lower levels? Sub-system provider may not expose them. Intent is not to force provision of access but encourage it and exploit what is provided.
  • Does the mention of TAP selector imply that this is 1149.1 centric? No, simply that the TAP Selector is different from the others (as noted above). Does this mean that we could resolve to perhaps value-based selectors and state-based selectors? Some gateways may exhibit aspects of both behaviours but that could probably be described by layering one type on top of the other - move away from thinking of the overall function of the device to the behaviours of its constituent parts.
  • Notion of 'selection by index' - this is good, but needs rules to ensure consistency across EDA tools, e.g. whether the index starts at 0 or 1.
  • How will opening up a new (e.g.) scan chain in the path be handled?  the 'control observer' needs to be notified of the change in the chain.  Some of this is dealt with in Brad's demos, but the concern is how to convey some of these ideas from the document, since the demos can't realistically be referenced.  Some other form of illustration is required, perhaps a UML Sequence Diagram.
  • There are cases where control may use different bus system to the bus(es) being controlled.
  • Should some of the utility be left to EDA tool vendors to provide?
  • But what do we mean by 'EDA tool vendor'? Do we need to be more specific: Chip-level EDA, board-level EDA or even test EDA tooling?  Depends on perspective.
  • Some test tooling may be COTS, others may be in-house.

8. Any Other Business

  • {Slide 15}
  • Louis mentioned UCLA Webinar: https://www.linkedin.com/posts/louisungar_ucla-offers-free-dft-online-course-on-june-activity-6798774137792925696-B507.

9. Today's Key Takeaways

  • Selectors might be 'value-based' or 'state-based'.

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

  • July 12, 2021
    • July 5 cancelled for holidays.
    • Louis and Joel both out July 12 and 19.

12. Topic for next meeting

  • Continue to review standard draft - where does STAM fit in the foodchain?.

13. Reminders

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh