Minutes of P2654 Working Group Meeting No.79, 2020-09-21

Meeting called to order: 11:05 AM EDT

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

The cumulative reference pack is located here: http://files.sjtag.org/P2654WG/P2654_Reference_Pack.pptx 

1. Roll Call

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


By email (non-attendees):

Bill Huynh (Marvell Inc.)

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. 

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #78, September 14 (draft circulated September 14)
    • No 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}
  • 1149.4 and 1581 are approved by TTSC for PAR revision.

7. Discussion Topics

7 a) Discussion of perspectives on STAM

  • {Slide 14}
  • New slides 31-40 have been provided by Brad. These replace the existing slides 23-30, which will be removed from future packs.
  • Commencing from slide 31.
  • Recap of material previously shown. Slide 33 added to show transition from model to hardware at the top of the hierarchy in response to question raised in Meeting 78. The top is the only access point to the hardware.
  • Dependencies: Example is TAP TDR being dependent on preceding TAP IR. 
  • Understandable why we tend to focus on 1149.1 TAP based examples but may be useful have a different example for readers to help show that P2654 can be applied to other cases. 1687 may not be enough of a help as there still isn't a widespread usage of that standard.  PCI Express, Ethernet and I2C may be more common and in many case TAP access may have been turned off for security reasons.
  • P2654 should offer benefits by providing access without the need to install software on the board.
  • Board test isn't the end objective. Need to be able to e.g. take boards and install a cable between and check that cable provides the expected comms. We need to support different Use Cases (user role perspectives), System manufacturer/integrator, field diagnostics, system installer, etc.
  • Many systems are assemble using 3rd party parts that are assumed to be good, e.g. building up a PXI chassis, and you want to check those parts communicate.
  • May be hard for people to see how they can use P2654 if they don't have access to the TAP without examples. Perhaps Ethernet with TCP/IP might be a more relevant example.
  • 1687 describes "primitives". SJTAG has looked at that concept and P2654 probably needs similar, possibly expanding on 1687's list.
  • Slides 39-40 detail the logic blocks of the Callback scheme.
  • Problematic to grasp why request in the model flow up from the target register when the initiation of a test has start with something applied at the top of the hierarchy. The model is providing the means of access - access to do the test is different from applying the test.
  • This is essentially software modelling and perhaps the group would benefit from having more software people involved. 
  • A "bulletin board" (shared memory block) might be used in debugging.
  • The hierarchy of slide 40 relates closely to Brad's simulated design. 

7 b) Diagrams and Terms

  • Not discussed during this meeting.

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • P2654 primitives need to be considered.
  • Alternative Use Case examples are required.

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

  • September 28, 2020.

12. Topic for next meeting

  • Continue from today.
    • a) Demo of software messaging (Brad)
    • b) Alternative Use Cases (All)

13. Reminders

  • None.

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh