Minutes of P2654 Working Group Meeting No.7, 2019-02-11

Meeting called to order: 11:03 AM EST

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

1. Roll Call

Ian McIntosh (Leonardo)
Eric Cormack (DFT Solutions)
Terry Duepner (National Instruments)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Bill Huynh (Marvell Inc.)
Joel Irby (Arm)
Richard Pistor (Curtiss-Wright)
Jan Schat (NXP Semiconductors)
Naveen Srivastava (Nvidia)
Craig Stephan (INTELLITECH Inc.)
Jon Stewart (Dell)
Brad Van Treuren (Nokia)
Carl Walker (Cisco Systems)
Louis Ungar (A.T.E. Solutions)

Guests:
---

By email (non-attendees):
---

Excused:
---

2. Agenda

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

3. IEEE Patent Slides

  • {Slides 5-9}
  • Patent slides reviewed.
    • There may be a newer pack available.

4. Review and Approve Previous Minutes

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

5. Review Open Action Items

6. Discussion Topics

6 a) Update on WG Elections {Slide 12}

  • Status on nominations provided by Brian as Elections Administrator:
    • 4 nominations for Chair
    • 7 nominations for Vice-chair
    • 4 nominations for Editor
    • 5 Nominations for Secretary
  • While the majority of the above are current IEEE-SA members some are not but may still be eligible should they wish to take up the relevant memberships.

6 b) Mapping of STAM onto OSI-like layers; top-down vs bottom-up approaches {Slide 13}

  • Slides 14-16 had previously been used in SJTAG meetings.
  • {Slide 14}
  • From BTW in 2008, attempting to describe static test cases in an embedded environment.
  • The Test Manager and Test Controller could be the same computer or may be different computer/resources. Locality really depends on the system design.
  • The Test Manager was meant to be something like the test execution tooling provided by Goepel, Asset, JTAG Technologies and others, managing what tests can be applied, when to apply them and collecting the results.
  • Slides were created at a time when 1149.1 was the clear focus.
  • Now recognise that there is a need to support dynamic or interactive tests, not just static tests.
  • {Slide 15}
  • Added identification of possible points between stack layers where standardisation may be possible.
  • SVF and STAPL references show their respective scope within the stack. ICL and PDL were not in existence at this time, but otherwise might have been featured.
  • What about a COTS item where you have little control over its design? Likely that a COTS items would mask out some (or many) of the lower layers. Equates to Gunnar Carlsson's ATCA presentation of a shelf manager sending a "go to yourself" command over the IPMI bus and then querying the result.
  • If we still think of a stack like this, then we really mean a stack of stacks as move down the hierarchy. This enables a transfer of autonomy (delegation) across hierarchical boundaries.
  • {Slide 16}
  • Attempts to build on the stack idea by mapping onto standards and languages and drawing analogies with real-world hierarchy.
  • Difficulties of creating the decomposition: May be a single board system, a mezzanine assembly of boards, a mini-shelf, a hierarchy within a shelf, multiple shelfs, etc.
  • There's possibly a version of the stack at each level.
  • Recognising the need for flow control at every level - PDL arose out of that.
  • 1687 uses abstraction to make all instruments look the same. 1149.1-2013 only details access to the Test Data Register - register level rather than scan chain level. 1687 abstracts the TAP Controller in the device.
  • For larger systems, they really need a way of describing and using the functionality of the sub-systems. The sub-systems could give finer granularity but not necessarily. This gives control over IP exposure.
  • Can we develop on the stack diagram? The stack levels are "artificial" and not abstract enough for our current purpose.
  • We can define hierarchy based on the topology of the system, and have certain primitives that will describe what is available at each level. Scope may be different and less detailed as you go up the hierarchy.
  • Granularity of control defines what is available at each interface (noting that "interface" has become an overloaded term).
  • Are the interfaces between layers really "protocols"? Possibly in some cases but the callbacks may be a somewhat more complex than that.
  • The OSI model (Open System Interconnect, https://en.wikipedia.org/wiki/OSI_model) which we were trying to compare against is fixed in terms of what it's top and bottom represent, while we have a flexible hierarchy. The OSI model also has the concept of each layer providing a wrapper to the layer below, which we cannot emulate.

7. Any Other Business

  • {Slide 17}
  • None.

8. Today's Key Takeaways

  • The stack diagram is of little relevance now and a new form of diagram is required.
  • Larger systems need a description of, and instructions to use the functionality of its sub-systems (or deeper, depending on what is made available).

9. Glossary Terms from This Meeting

  • "Interface" is overloaded and requires disambiguation.
  • 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 18, 2019 (Presidents' Day, US).
    • Eric and Louis are likely to be out, possibly some others.

11. Topic for next meeting

  • Top-down vs bottom-up approaches.

12. Reminders

  • None.

13. List New Action Items

  • None.

14. Adjourn

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

Respectfully submitted,
Ian McIntosh