P2654 WG Minutes - 2020-10-19

Minutes of P2654 Working Group Meeting No.83, 2020-10-19

Meeting called to order: 11:04 AM EDT

The slide references relate to the pack used during this meeting, located here: http://files.sjtag.org/P2654WG/P2654_Meeting_83.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) (left 11:30)
Terry Duepner (National Instruments)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd)
Richard Pistor (Curtiss-Wright)
Jan Schat (NXP Semiconductors)
Jon Stewart (Dell)
Brad Van Treuren (VT Enterprises Consulting Services)
Louis Ungar (A.T.E. Solutions)
Carl Walker (Cisco Systems)

Guests:
---

By email (non-attendees):
---

Excused:
Tom Thompson (for IEEE)
Bill Huynh (Marvell Inc.)
Joel Irby (AMD)

2. Agenda

  • Terry moved to accept the agenda, seconded by Carl, no objections.

3. IEEE Patent Slides

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

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #82, October 12 (draft circulated October 12)
    • 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}
  • P2929 kick-off was held on Thursday 15th, mainly re-presenting the background material offered to TTSC.
  • Brad's JSON and DSL description examples used here will be presented to the P1687.1 group tomorrow (20th). 

7. Discussion Topics

7 a) Description examples, continuation

  • {Slide 14}
  • JSON and DSL examples shown previously and used again today are here (viewable in a text editor): http://files.sjtag.org/Brad/TransformDescriptionExamples.zip
  • Tying the description back to the modelling diagrams used previously, Each device instance registers its own callbacks while the Request Handler and Response Handler are "common code" for the Assembly.
  • Each RVF packet has a command within it, working like a Remote Procedure Call, and a payload that is effectively the data/parameters associated with the callback that is to be executed.
  • Suggestion from previous meeting was that a DSL was a better fit to our needs, although in any case it is essentially just a data structure.  How does this map onto or differ from the iSCSI scheme suggested earlier? 
  • To help support "black box" it may be possible for a callback to have a call to a binary module - this would be similar to Python or TCL calling an extension.
  • The description include templates of functions: The standard defines the intended behaviour but the tool vendor details the implementation, allowing for value add in the implementation.
  • The description also defines the logic for the transformation, some of that logic may be mandatory other parts may be case dependent.
  • Appearance is that a board or system designer may need in depth knowledge of how all the component assemblies operate in order to use this and where COTS items are concerned that may not be available: If the vendor is protective of JTAG access, why would they permit equivalent access over an alternate interface?  Information that feeds into the modelling will need to come from a variety of sources. Access need not be equivalent and may vary depending on, say, access authentication provided by the user.
  • In the COTS case, it may be "just passing data", a canned test vector. This may be useful for executing a self-test of the module but would be restrictive for testing between the COTS item and some other part of the system, e.g. an interconnect test.
  • Aim is to augment the state of the UUT (e.g. set a value in a register) in some common, describable way.
  • A system may be made up of a number of black boxes where only the inputs and outputs are known about and you maybe want to get a value of '3' to appear on some interface.
  • If an assembly has software that can apply the end data, why not just get it do that instead of having everything ripple up and back down?  Comes down to timing, concurrency and scheduling, e.g. if you want to observe, from some other COTS assembly, the effect of applying '3' on an interface.
  • For clarity RVF refers to the format of a Request or Response.
  • Payloads may need to be concatenated, for example in the case of a JTAG chain where several responses may need to be assembled in order.
  • Might we encounter pushback for introducing a new DSL rather than using, say PDL? PDL is limited and difficult to use for our purposes, although it may be possible to extend PDL. We likely need to provide an argument for whatever route we choose if differs from existing options.

8. Any Other Business

  • {Slide 15}
  • Michele has agreed to send Brad the Automated Test Flow paper mentioned at the October 5 meeting, and is happy to make a joint presentation to P2654 and P1687.1 at some point when his schedule permits.

9. Today's Key Takeaways

  • None.

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

  • October 26, 2020.
    • Daylight saving ends in Europe on October 25 so this meeting will be one hour earlier than normal for European participants.

12. Topic for next meeting

  • Revisit draft outline for Standard

13. Reminders

  • Appointment of elections officers has been put forward as an agenda item for TTSC.

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh