Minutes of Study Group Meeting, 2018-03-26

Meeting called to order: 11:09 AM EDT

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

1. Roll Call

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

By email (non-attendees):

Heiko Ehrenberg (GOEPEL Electronics)
Mukund Modi (NAVAIR Lakehurst)

2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • March 19
    • Draft circulated 03/19/18
    • No corrections.
    • Terry moved to approve, seconded by Jon, 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.
  • [27.2] Legacy Initiative Group to propose definition for "SJTAG".
    • Some contributions on forum: http://forums.sjtag.org/viewtopic.php?p=1308#p1308.
    • Do we still need the term SJTAG if this group is STAM? SJTAG still has a place as STAM is only a first proposed standard under a SJTAG banner. There may never be a "SJTAG standard" per se but other related standards are possible, although they're not yet identified. This study group is only concerned with STAM.
    • "SJTAG" maybe doesn't sound generic enough? When the Ben Bennetts first formed the Initiative Group in 2005 concerns were how to access JTAG through gateways on multidrop buses and the considerations that arise between externally controlled BScan and embedded BScan. This was a minimalistic view that has morphed into something much bigger. At the time, SJTAG was the partner to IJTAG which became 1687.
    • In the diagram with the bubbles (Study Group Minutes - 2018-03-05) there's a bubble around SJTAG. SJTAG expects to leverage STAM. It was noted there should be a bubble around the SJTAG Applications for System Test Applications as SJTAG is a subset of System Test.
    • Are we sure SJTAG contains STAM?
    • It's more of an association: There may be another standard proposed on, e.g. multidrop architectures; that may use resources of STAM, so they belong in an association group which we call SJTAG.
    • Maybe this should be documented for reference?
    • 1149.7 is part of the 1149 family but uses a different protocol from 1149.1.

5. Discussion Topics

a) PAR - Refine PAR Scope text.

  • {Slide12 - headings}
  • {Slide 13 - Draft Scope}
  • Proposal from last week and suggested revision from forums. Probably doesn't amount to a major change issues appear to be whether the first sentence should end as "extend test access to the system level", "extend test access to system level" or "extend test access to system-level" (concern being keeping focus on "system level" rather than "system").
  • No need to agree on text right now, wait until we've considered the other sections.
  • {Slide 14 - Draft Purpose}
  • Red text is highlighted as it is a constraint that we might want reconsider. Generally felt to be limiting, there are interfaces that do not follow the CSU cycle that we might want to use. Ethernet is perhaps an obvious example and USB is probably another. It may turn out to be a necessary limitation after looking at implementation, but it is permissible for the standard to address less than is in the Scope.
  • Should we include examples of some of the buses in the Purpose? Originally we did have examples but ended up moving them to the Need section because it seemed too wordy in Purpose. It possibly isn't necessary to detail examples if the text is clear enough but it seems to talk more about "topologies" than about "interfaces". The first sentence is really about the "model" while the second sentence is about how that model is used.
  • Should we have something about connecting from one interface to another? Not really, the interfaces aren't necessarily "connected" but at some upper level of control the controlling entity has a means of getting to each of the interfaces.
  • You should be able to capture the state of a board and/or change the state to something else.
  • Should I be able to come in using Ethernet and make BScan do something? Bridging is possible but needn't be a requirement - it depends on what is in the design {"Board Example", slide 7 of http://files.sjtag.org/IanMc/System%20Examples_v4.pdf shared}. The point is that a test may need to use more than one interface (e.g. different interfaces on different devices in order to conduct a particular test, e.g. if there were a comms link between U15 FPGA and U5 DSP that was to be tested).  
  • {Some additional examples were discussed using the Board Example}
  • View that the Purpose as written may be 'accurate' but is perhaps not 'complete'.
  • A table of interfaces under consideration had been mentioned previously - this was linked in the Study Group Minutes - 2018-03-12.
  • There was no disagreement to removing the red text on the CSU limitation from the Purpose. The amended version will be posted to the forums for comment prior to the next meeting {Post Meeting Note: Now posted here: http://forums.sjtag.org/viewtopic.php?p=1320#p1320}.
  • Reference slides (not used during this meeting):
  • {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 is more of an association group: STAM is one member of that group. {Noted post-meeting}

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.
    • SJTAG: Discussion on forums - http://forums.sjtag.org/viewtopic.php?f=3&t=782

8. Topic for next meeting

9. Schedule next meeting

  • April 9 - Terry will be absent.
    • No meeting on April 2 - Easter Monday and several absences would be expected.

10. Reminders

11. Any Other Business

  • None.

12. List New Action Items

  • None.

13. Adjourn

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

Respectfully submitted,
Ian McIntosh