Minutes of Study Group Meeting, 2018-03-12

Meeting called to order: 11:07 AM EDT

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

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Heiko Ehrenberg (Goepel Electronics)
Eric Cormack (DFT Solutions Ltd.)
Terry Duepner (National Instruments)
Bill Eklow (Retired) (joined 11:08)
Brian Erickson (JTAG Technologies)
Peter Horwood (Firecron Ltd.) (joined 11:11)
Bill Huynh (Marvell Inc.)
Joel Irby (ARM)
Richard Pistor (Curtiss-Wright)
Naveen Srivastava (Nvidia)
Jon Stewart (Dell)
Brad Van Treuren (Nokia) (joined 11:18)
Russell Shannon (NAVAIR Lakehurst)
Louis Ungar (ATE Solutions)
Sivakumar Vijayakumar (Keysight) (joined 11:08)

By email (non-attendees):
---

Excused:
Carl Walker (Cisco Systems)

2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • March 5
    • Draft circulated 03/05/18
    • No corrections.
    • Eric moved to approve, seconded by Terry, no objections or abstentions. Approved.

4. Review Open Action Items

  • {Slide 11}
  • [21.1] Brad: Supply Ian with glossary definitions used by 1687.1 for "transformation" and "retargeting".
    • These will be coming in the draft standard.
    • ONGOING.

5. Discussion Topics

a) Work on refinement of what SJTAG/STAM is - Re-focus on agreement on STAM Scope.

  • {Slide12 - headings}
  • Look at the what the intended Scope for STAM is.
  • Side discussion on question raised at previous meeting on how 1149.1 presented its Purpose:
    • Text is lengthy, several paragraphs: Probably not helpful to try to present it on-screen during the meeting.
    • Can be posted on the forums so that everyone can read it in their own time.
    • Further question remains on defining what SJTAG means.
  • {Slide 13 - Draft Scope}
  • This is draft text as proposed by the "Initiative group".
  • The heading should show that this is a scope for "STAM" and not "SJTAG" (SJTAG can be defined as a parallel activity).
  • Seems to be OK for STAM, but is the language accessible? Concern that it maybe neglects inter-board test access. A board can be a system, so why would inter-board access be any different? Relates to concept of describing everything as an "assembly", to avoid inference of a place in a physical hierarchy.
  • Most obvious first point of application for STAM is at the board level, where all the CAD data is available to describe the design. At module or system level, some of that CAD data may be missing or the system composition might be dynamic. So a system might be a slightly different problem to a board. There can be a diversity of interfaces above the board level. A slot may have different modules installed and which might have mezzanines that adapt the module's function. May not be "static data" available on the system.
  • If modules are designed as separate units (especially e.g. COTS) then you don't have a consistent set of CAD data to use with tooling. This can happen even where all the data is available but originates from different design toolsets. Better to consider a behavioural description rather than a structural description.
  • Would like to query the system to find out what is available to use. Does that mean physically querying the hardware or referring to some form of "documentation" that describes the hardware (akin to BSDL or PDL). Either would work but the key is to encourage the creation of the information.
  • An Access Link provides access but it doesn't tell you how the data is used - Should STAM tell you put your access to use (1149.1 doesn't and leaves that to the application)? Possibly STAM should not mandate the usage; takes away the value add opportunity for tool suppliers.
  • Could query a module for an ID and what revision it is and then look that up in a database for details of what is possible with that module. The response only needs a small amount of data to standardise. May be difficult in an embedded case where access to an external database is difficult and holding the database locally is not practical. Cloud latency might be another issue. Could be an optional feature of the standard to automate the identification of modules, but leave a manual process to deal with current designs that don't support such queries. Some systems may already have a method of reporting ID, so may not see a need to change to a STAM way of doing it.
  • Is STAM maybe more about what the access information is and how you use it rather than how you discover what the accesses are?
  • Could suggest that if you don't already have a module identification system then "add it this way to be STAM compatible".
  • What about multiple access points - do we want to support that? Don't want to mandate a specific interface, like 1149.5 did. Communications might well require multiple interfaces: It's common to use 1149.1 to configure a module for test and then use something like Ethernet (faster than JTAG) to run at-speed tests on the module. This is a Use Case we need to think about.
  • We've talked about Access Links and Data Links as if they're distinct but the reality is maybe more complex with Access Links being set up to then become Data Links used to transfer data that is used to set up another Access Link, etc.: Layering of the Links. You can tunnel down until you reach the destination.
  • Is there a table of interfaces we should be considering? The Initiative Group did draft up such a table although it won't be comprehensive . Links can be provided in the notes as the files are probably in the file share.
  • {Post Meeting Note} Brad provided the following links:
  • Reference slides (not used during this meeting):
  • {Slide 14 - Draft Purpose}
  • Red text is highlighted as it is a constraint that we might want reconsider, or at least discuss.
  • {Slide 15 - Draft Need}
  • The wording of this has already been pointed out to be deficient as it stands. It is probably too long anyway - the latter part has been greyed as it is largely just an expansion of the main points.
  • {Slide 16 - Collated comments}
  • Yet to be considered.

6. Today's Key Takeaways

  • {Slide 17}
  • SJTAG ≠ STAM, SJTAG needs to be defined.

7. 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.

8. Topic for next meeting

9. Schedule next meeting

  • March 19.

10. Reminders

11. Any Other Business

  • Opportunity exists to get SJTAG/STAM into ITC. May be getting late for submitting a paper, but some leeway exists and a poster or invited talk is possible. Biggest problem, as usual, is likely to be availability of someone to present on behalf of the group.

12. List New Action Items

  • [27.1] Brad to provide Ian with links to the tables of interfaces.
  • [27.2] Legacy Initiative Group to propose definition for "SJTAG".

13. Adjourn

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

Respectfully submitted,
Ian McIntosh