Minutes of P2654 Working Group Meeting No.6, 2019-02-04

Meeting called to order: 11:06 AM EST

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

1. Roll Call

Ian McIntosh (Leonardo)
Eric Cormack (DFT Solutions)
Terry Duepner (National Instruments)
Brian Erickson (JTAG Technologies)
Peter Horwood (Firecron Ltd.)
Bill Huynh (Marvell Inc.)
Adam W. Ley (ASSET InterTech)
Jan Schat (NXP Semiconductors)
Naveen Srivastava (Nvidia)
Craig Stephan (INTELLITECH Inc.) (joined 11:11)
Jon Stewart (Dell)
Brad Van Treuren (Nokia)
Carl Walker (Cisco Systems)
Louis Ungar (A.T.E. Solutions)


By email (non-attendees):

Heiko Ehrenberg (GOEPEL Electronics)
Joel Irby (Arm)
Richard Pistor (Curtiss-Wright)

2. Agenda

Eric 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 #5, January 28 (updated draft circulated January 30)
    • No further 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.
  • [5.1] Ian: Ask Jeff Rearick to supply his elections templates and materials to Brian.
    • Jeff has passed on email templates.
  • Action Item Register: http://files.sjtag.org/P2654WG/ActionItemRegister.xlsx

6. Discussion Topics

6 a) Update on WG Elections {Slide 12}

  • Brian, as Elections Administrator, proposed to commence the nominations period today, closing in 14 days time, and so moves to start the process, seconded by Eric.
  • Nominees should be IEEE and SA members (or willing to become such if elected), voting members of the group and not one of the Elections Officers.
  • Although not specified in the P&P, it is conventional that nominations are only accepted from voting members. Eligibility to participate in the elections is similarly conventionally taken to be determined at the start of the elections procedure, i.e. today.  Ian will make a list of voting members available to the EOs {ACTION}.
  • There being no more discussion and no objections, the motion to commence the nomination period is passed.
  • A email from the Elections Administrator will follow in due course to invite nominations and will give advice on the aspects of eligibility mentioned. Responses should be sent to the elections(at)sjtag.org email address.

6 b) Hand-off between STAM and leveraged interfaces {Slides 13}

  • What is meant by "callback"? An example might be a request from a device for a read or write operation to take place on a particular register of that device.  If you are considering a register that initiates a BIST and another register that reports the result of the BIST then it might be static data and the same every time.  In 1687, the comparison of the result with the expected data is masked by the retargeting and only the pass/fail is presented, but in many cases you may want to see the actual data.
  • Where data might be passed through a protocol bridge, e.g. between 1149.1 and I2C where multiple operation on side may be necessary to effect a single operation on the other, the callback handler needs to be able to reformat data to suit what is expected by the receiver of the data.
  • It would be ideal, but possibly not practical to compose everything from CAD data. 1687 uses ICL to describe the pseudo-structure and PDL for behavioural aspects. STAM will likely need something similar.
  • Who has responsibility for producing callbacks? For bridges, they would need to come from the chip designer, but the board designer would need to provide them for the interfaces between devices as only they know how they're being used.
  • Concern about this seeming to flow from instruments/registers upwards... A system designer probably won't be aware of details all the way down to the registers and would need something higher up that lets them know what they can do.
  • There could be a minimal list, as an extension, that could be applied to the design. Are we describing something hierarchical here? With conditions: There may be things that the (e.g. COTS) board designer doesn't wish to share. In-house test could have access to a more detailed set of features and a more restricted set, perhaps simply a Go/NoGo test, supplied for "customers". Such a test capability wouldn't be "STAM" but STAM could be part of it.
  • STAM should still be able to report what features a board can provide.  If you have register access then you could assemble a library that presents "procedures" for things you may want to do commonly, in which each procedure may involve a combination of register accesses. That library might want to be in a binary form in order to help protect IP, something like Python's PYC (and others) - portable but obscure enough to deter reverse engineering.
  • The source would be the descriptive form that STAM would address in the standard. STAM would probably also define the option to produce a binary form but providing the actual capability could be left as a value-add for tool vendors who may be able to add encryption.
  • The group has previously tried to keep away from "owning" any aspect of security but we need assist in making it possible. A device designer (e.g. SOC) may not want to give register access to the device.  This makes it similar to the COTS board case and the problem probably scales through the hierarchy: The board scope solution also gives the solution for the device scope.
  • A board edge may not have a single access and it is also worth noting that each access port likely will not be able to access the same resources as another, and some activities might mandate the use of multiple ports.    

7. Any Other Business

  • {Slide 14}
  • None.

8. Today's Key Takeaways

  • What is available from a board is not identical what STAM is providing but STAM facilitates it.
  • Scalability. Interface access is the same problem at all levels.
  • Resource primitives (reads, writes), testability feature, ends up being a function call.
  • Different levels of adherence:
    • Minimal list on how you access a resource,
    • Behavioural methods for higher levels (extension).

9. Glossary Terms from This Meeting

  • Callback.  Brad will attempt to draft a definition {ACTION}.
  • 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 11, 2019.

11. Topic for next meeting

  • Mapping of STAM onto OSI-like layers; top-down vs bottom-up approaches.

12. Reminders

  • None.

13. List New Action Items

  • [6.1] Ian: Supply EOs with list of voting members.
  • [6.2] Brad: Draft definition of 'callback'.

14. Adjourn

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

Respectfully submitted,
Ian McIntosh