Minutes of P2654 Working Group Meeting No.113, 2021-06-21

Meeting called to order: 11:03 AM EDT

The slide references relate to the pack used during this meeting, located here: http://files.sjtag.org/P2654WG/P2654_Meeting_113.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) (joined 11:20)
Joel Irby (AMD)
Richard Pistor (Curtiss-Wright) (joined 11:07)
Jon Stewart (Dell) (joined 11:05)
Louis Ungar (A.T.E. Solutions) (joined 11:07)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)

Guests:
---

By email (non-attendees):
---

Excused:
Bill Huynh (Marvell Inc.)
Eric Cormack (DFT Solutions)
Tom Thompson (for IEEE)

2. Agenda

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

3. IEEE Patent Slides

  • {Slides 5-10}
  • Patent (newly updated) and Copyright slides reviewed without comment.

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #112, June 14 (draft circulated June 14)
    • No corrections noted.
    • Brad 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).
  • Resolution of comments on P1149.7 is drawing to a close, next meeting is likely to be the last regular WG meeting. Draft has met ballot approval requirements.
  • Louis raised the topic of collaboration with P1687.2 and the need for P2654 to include analog test within the scope of system test. Brad noted that he and Jeff Rearick are already working together on ensuring there is compatibility across approaches.  One issue being worked in P1687.2 is whether an analog MUX is a new type or can simply be expanded from the digital MUX.
  •  

7. Discussion Topics

7 a) Continue review of standard draft

  • {Slide 14}
  • Carrying on from Inter-group Collaboration: Desire to avoid a similar situation to, e.g., the divergent PDLs of 1687 and 1149.1-2013. 
  • Aside from digital and analog buses there may also be a third type, a virtual, software messaging bus that writes to a behaviour.
  • Reminder that "Transfer Procedure" is replacing what we've commonly referred to (possibly incorrectly) as 'callback'.
  • {Slide 40} Transformation Engine could reasonably be common code for all nodes. So, would the Client and Host interfaces then be node specific? No, these could also be common as the RVF message format is standardised - it's the Transfer Procedures that specializes the behavior of the node. The RVFMessage is a wrapper around the real context message similar to the way te IP packet wraps TCP or UDP packets for Ethernet. Thus, the Transform Engine is just a router of the RVFMessage to the TransformStrategy (via the handleRequest( ) interface. The handleRequest( ) method of the TransformStrategy API deserializes the context message from the RVFMessage to call the appropriate transfer procedure. 
  • The code for the Transfer Procedures have to be supplied by the provider of the node entity, be that a board, device, etc., and could be supplied as a binary.
  • Injection {slide 43}: Calls a particular operation to be applied at this node level. The scope of the calls is at the Client Interface context, whereas the context of the TransformStrategy is following that of the Host Interface. For example, the Client Interface is JTAG messaging of SIR, SDR, etc. The Host Interface transacts Scan objectives such as CSU, SU, CS, S, etc. Thus, children would issue CSU type requests to the TransformStrategy and the Injection Node issues SIR/SDR type messages to the InjectionStrategy. Both the TransformStrategy and InjectionStrategy send JTAG scoped requests to the Client Interface. Note that the Injection node itself is to the left of the diagram and the main block here is the target node. Does it matter that there's a host interface at the bottom here? Is it effectively transparent to the injection operation? Depends on what might be perceived to be below. The Injection Node allows for an alternate data injection path concurrently supporting a full model branch below this node.
  • {Slide 41}: The reason for multiple Injection Nodes is to allow for multiple points of injection through different forms. For example, one node might be an SVF player and a second may be a STAPL player all operating on a JTAG chain segment.
  • Who needs to know what it terms of retargeting injected test vector? It maybe depends on whether the vectors are or are not targeted at the same model point as perceived by the Injection node. If they're the same then the vectors could be applied directly, else there needs to be some re-targeting performed.
  • {Slide 82}: Brad noted there may be a simplification of the abstraction of the ModelNode specializations. A Network really represents a CHAIN and LINKER, where a CHAIN represents an aggregation structure and a LINKER is a composition structure. The Target represent the leaves and the Adapter is the ModelPoint.

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • None.

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

  • June 28, 2021

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:02 PM EDT

Respectfully submitted,
Ian McIntosh