Minutes of Study Group Meeting, 2018-05-07

Meeting called to order: 11:05 AM EDT

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

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Heiko Ehrenberg (GOEPEL Electronics) (left 11:45)
Eric Cormack (DFT Solutions)
Terry Duepner (National Instruments)
Brian Erickson (JTAG Technologies)
Bill Huynh (Marvell Inc.)
Joel Irby (ARM) (joined 11:07)
Dilipan Jayachandran (SEL Inc.) (joined 11:11)
Naveen Srivastava (Nvidia)
Jon Stewart (Dell) (joined 11:08)
Brad Van Treuren (Nokia)
Carl Walker (Cisco Systems)
Louis Ungar (ATE Solutions)

By email (non-attendees):

Russell Shannon (NAVAIR Lakehurst)
Sivakumar Vijayakumar (Keysight)
Richard Pistor (Curtiss-Wright)
Bill Eklow (Retired)

2. IEEE Patent Slides

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

3. Review and Approve Previous Minutes

  • {Slide 10}
  • April 30 (revised draft circulated May 2)
    • Eric moved to approve, Carl seconded.
    • No objections or abstentions → minutes approved.

4. Review Open Action Items

  • {Slide 11}
  • [21.1] Brad: Supply Ian with glossary definitions used by 1687.1 for "transformation" and "retargeting".
    • No updates.
    • ONGOING.
  • [27.2] Legacy Initiative Group to propose definition for "SJTAG".
    • No updates.
  • Side note relating to glossaries and definitions: There is an "International Vocabulary of Metrology" - this is mainly terms that have more relevance to analogue measurements, but may nonetheless be informative: https://www.bipm.org/en/publications/guides/vim.html

5. Discussion Topics

a) Continue Purpose discussion, focus on Adam’s questions.

  • Plan to spend this meeting and next on Purpose, then the following two on Need.  Try to get the bulk of the work done during the meetings and use the forums (preferably) or email to refine wording during the time between meetings, before voting on accepting the resulting text to go into the PAR (first meeting in June). Try not to overrun that timescale.
  • Brad had already prepared a slide on Scope along with forum remarks - this is not needed for today's call but will be included, for reference, with any slides edited today.
  • {Slide12 - headings, Slide 13 - Draft Purpose}
  • Two of Adam's points still to be addressed.
  • Brad prepared a copy slide to capture edits {shared}.
  • Some attempt had been made to answer Adam's points on the forums {shared: http://forums.sjtag.org/viewtopic.php?p=1326#p1326}.
  • May want to try to raise the visibility of the need for this work: JTAG is sometimes seen as something the chip vendor uses to test the chip in the foundry or to be used for programming or as a debug tool for microprocessors, with no awareness of the potential use for board test, etc. This is not an uncommon view and is often related to the background or experiences of the user.
  • Keeping chains on the board in a dense design can be difficult so only a couple of major parts might have chains accessible, typically things like FPGAs. Some testing can of course be done through the FPGA using the JTAG TAP as an interface.
  • The point on "who prepares" probably involves device providers - as well a device vendors that might include EDA tools used to design ASICs, FPGA firmware or included IP. Arguably, this really means any device that can be used in a larger assembly.
  • Device vendor's perspective:
    1. JTAG can be used for board test
    2. Would intend that SJTAG could be used at the device level, e.g. for multi-chip devices.
    3. Implement whatever is needed in the chip - customer may not feel they need it, so it won't be implemented.
  • STAM has to be a feature that people will want to use, but the customers still have to request it. In the past, Ken Parker noted that 1687 "needed a 900lb gorilla to drive its adoption", Cisco Systems being the gorilla in that case. However, STAM is different from 1687 or even 1149.1 in that it does not intend to define new hardware support within devices but instead make better use of what support already exists. That said, in the case of a multi-chip device it could influence the interconnecting paths that are required between chips.
  • There is a question of "where is the boundary?" 1687.1 also facing this - is it the pins? In that case it gets complicated for SoCs and other multi-chip devices.
  • Are we missing an important point - what are we communicating? Isn't it to exchange test and diagnostics information? That could be too limiting - we shouldn't be assuming what the information is being used for, but we do need to allow test. Test should at least be one of the stated "purposes" but it isn't mentioned at all. "Test" is in the title and is mentioned several times in the Scope. So why should it not also be in the Purpose?
  • Brian moved to vote on the issue in order to expedite the discussion, seconded by Terry. The meeting is quorate so the vote can be taken directly. The motion is to answer the question "Do we need to include a specific reference to 'test' in the Purpose as well as in the Scope?"
    • "Yes" votes: 1
    • "No" votes: 11
    • The conclusion therefore is that the Purpose does not need to explicitly mention "test".
  • Returning to the question of "who prepares", this is really anyone providing a "component" (which may be a chip or a board) which can be used automatically (or perhaps "used in an automated manner") within a larger system or assembly. This doesn't preclude that a system may be a board.
  • The description given in Brad's forum post (http://forums.sjtag.org/viewtopic.php?p=1327#p1327) identifies three "providers" that may all be distinct (the designers of the Interface Slave, the Interface Master and the intra-device transformation) and therefore might need to be pulled together by the system integrator. However this is possibly too detailed an analysis and is partly reliant on the diagram for explanation, so may not be suitable for the PAR. The suggestion immediately preceding is both comprehensive and concise.
  • Is the "time order" mentioned in the last sentence of Purpose necessary? It is part of the aims of STAM, since an action may involve different interfaces or paths to set up, e.g. a Tx-to-Rx test where each path may operate at different speeds so co-ordination is important.  
  • Edited slide: http://files.sjtag.org/StudyGroup/SG_Meeting_34_bgvt_subset_twoslides.pdf
  • Reference slides (not used during this meeting):
  • {Slide 14 - Draft Need}
  • {Slide 15 - Collated comments}
  • {Slide 16 - Draft Scope}

6. Today's Key Takeaways

  • {Slide 17}
  • It is not considered necessary to make specific reference to "test" within the PAR Purpose.

7. Glossary Terms from This Meeting

  • 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
    • "Method" - a systematic approach to accomplish an objective.

8. Topic for next meeting

9. Schedule next meeting

  • May 14.
    • Heiko and Louis will be absent.
    • Russell will be out on May 14th and 28th.
    • Terry will be out May 14th and 21st.

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:08 PM EDT

Respectfully submitted,
Ian McIntosh