Minutes of P2654 Working Group Meeting No.5, 2019-01-28

Meeting called to order: 11:05 AM EST

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

1. Roll Call

Ian McIntosh (Leonardo)
Heiko Ehrenberg (GOEPEL Electronics)
Terry Duepner (National Instruments)
Brian Erickson (JTAG Technologies)
Peter Horwood (Firecron Ltd.)
Joel Irby (Arm)
Rakesh Kumar (zGlue Inc.)
Adam W. Ley (ASSET InterTech)
Richard Pistor (Curtiss-Wright)
Jan Schat (NXP Semiconductors)
Naveen Srivastava (Nvidia)
Craig Stephan (INTELLITECH Inc.)
Jon Stewart (Dell) (joined 11:07)
Brad Van Treuren (Nokia)
Carl Walker (Cisco Systems)
Louis Ungar (A.T.E. Solutions)

Guests:
---

By email (non-attendees):
---

Excused:
Bill Huynh (Marvell Inc.)

2. Agenda

Brad moved to accept the agenda as proposed, seconded by Terry, no objections.

3. IEEE Patent Slides

  • {Slides 5-9}
  • Patent slides reviewed.
    • No comments.

4. Review and Approve Previous Minutes

  • {Slide 10}
  • Meeting #4, January 21 (draft circulated January 21)
    • No corrections noted.
    • Brian moved to approve, Terry seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

  • {Slide 11}
  • [SG21.1] Brad: Supply Ian with glossary definitions used by 1687.1 for "transformation" and "retargeting".
    • ONGOING.
  • [4.1] Ian: Circulate request for volunteers to be Elections Officers.
    • Brian and Rakesh have volunteered and been ratified by Adam Cron.
    • COMPLETE.
  • Action Item Register: http://files.sjtag.org/P2654WG/ActionItemRegister.xlsx

6. Discussion Topics

6 a) WG Elections {Slide 12}

  • Elections process summarised.
  • Brian would appreciate getting Jeff Rearick's email templates, etc.  Ian will contact Jeff and ask him to forward them {ACTION}.
  • Should aim to have the elections complete such that the results can be reported to the next TTSC meeting (April 10). There is probably a minimum of 6 weeks in the entire process, which means it could take up most of February and March. Possibly get the process started on or around February 4.
  • Officers are elected for period of two years.

6 b) Consider the hand-off between STAM and e.g. P1687.1 {Slides 13-16}

  • Slides 14 to 16 try to explain why a simplistic view of the hand-off doesn't work (or is limiting).
  • The bridges are not necessarily that different from the selector or gateway. While those don't transform protocols, data still has to be redirected.
  • PDL describes operations on the instrument at the RHS but still need a way to describe the "intent". This is missing piece in 1687.
  • If I2C has a finite "grammar set" (and SPI another grammar set) could we define a common interface grammar set?
  • Intent is traditionally determined by the test designer; STAM would aim to automate that, but is dealing with all of the different interfaces really within our scope? We have some opportunity to influence what P1687.1 does as it is a live project. Things like 1149.1 are set for now but could be persuaded to adopt modification when next revised, but there is little chance of influencing I2C or SPI which are not covered by IEEE standards.
    [Post meeting notes, from Adam Ley:
    * 1149.1 should PAR within the next year and should ballot not later than 2023, so there will be a number of years of overlap (and perhaps overlapping membership)
    * MIPI (which is facilitated by IEEE ISTO), has recently standardized I3C “Basic” (a successor to I2C) and it’s now free to the world - https://www.mipi.org/specifications/i3c-sensor-specification.]
  • Aim is to have consistent description for all interfaces. Call-backs are a flexible way to achieve that, if you can get to a well-known set of primitives.
  • Targeting Instrument Registers with callbacks rippling up through the software model of the circuit yields the proper side effect at the top level where the sequences needing to be applied at the top to stimulate the register is performed by handling the many callbacks at the top generated by the initial register callback.
  • PDL level 0 (and even PDL level 1) are little help - PDL-1 is not able to return values; that is a requirement for the top level callback to pass back the data from the top level calls to the TAP Controller or what ever interface there is. Each callback is responsible for returning data to the previous level.
  • Would callbacks stay in PDL or might something in C# or some other language be allowed? Callbacks as "source code" disclose methods of doing things (IP) and so may be problem for hardware designers. Michele Portolan has been looking at binary libraries (and some device vendors may only supply pre-built libraries for specific platforms).
  • Jeff's diagram seems to be pushing STAM to a lower level - "System Test" might be viewed as applying from the top level downwards. There should be a protocol of query and response: "What capabilities do you have?". Maybe a minimum set of services provided to be compliant and optionally more.
  • Not necessarily fully automated but something that makes developing the tests a little easier.
  • In the first instance we need to determine "do we have access?" then "what sequence of events needs to take place at the top level?".
  • A system may not provide JTAG access to boards, so we should be clear that while we often use 1149.1 as the "main interface" in examples, it could be any interface.
  • Relying on iRead and iWrite may not be adequate.  There could be cases where packets of data are required and breaking that into a series of iReads or iWrites would be very inefficient.

7. Any Other Business

  • {Slide 17}
  • Brad advised that his continued participation is uncertain.

8. Today's Key Takeaways

  • Callbacks provide abstraction from any interface.
  • Callbacks can expose IP.
  • Top level may use any interface.
  • May need to handle packets of data, not just individual vectors.

9. Glossary Terms from This Meeting

  • None.
  • 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.
    • 1687.1: Transformation, Retargetting.
    • 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.

10. Schedule next meeting

  • February 4, 2019.
    • Richard, Joel, Heiko and possibly Louis will be absent.

11. Topic for next meeting

  • Continue discussing hand-off between STAM leveraged interfaces.

12. Reminders

  • None.

13. List New Action Items

  • [5.1] Ian: Ask Jeff Rearick to supply his elections templates and materials to Brian.

14. Adjourn

  • Brian moved to adjourn, seconded by Jon.
  • Meeting adjourned at 12:01 PM EST

Respectfully submitted,
Ian McIntosh