Minutes of Study Group Meeting, 2017-11-27

Meeting called to order: 11:08 AM EST

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

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Heiko Ehrenberg (Goepel Electronics)
Terry Duepner (National Instruments)
Bill Eklow (Retired)
Brian Erickson (JTAG Technologies)
Peter Horwood (Firecron Ltd.)
Bill Huynh (Marvell Inc.)
Joel Irby (ARM)
Mukund Modi (NAVAIR Lakehurst)
Richard Pistor (Curtiss-Wright)
Naveen Srivastava (Nvidia)
Jon Stewart (Dell)
Brad Van Treuren (Nokia)
Carl Walker (Cisco Systems)
Craig Stephan (INTELLITECH Inc.)
Louis Ungar (ATE Solutions)
Sivakumar Vijayakumar (Keysight) (joined 11:11)

By email (non-attendees):

Eric Cormack (DFT Solutions Ltd.)
Ed Gong (Intel Corp.)
Russell Shannon (NAVAIR Lakehurst)

2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • November 20
    • Draft circulated 11/20/17
    • No corrections noted.
    • Brian moved to approve, seconded by Terry, no objections or abstentions. Approved.

4. Review Open Action Items

  • {Slide 11}
  • [10.2] Brad will draft a definition for "boundary".
    • ONGOING.
  • [14.1] ALL: Develop Purpose description.
    • ONGOING.

5. Discussion Topics

a) Review forum poll.
b) Purpose.

  • {Slide 12}
  • Topics combined.
  • {Poll post shared: http://forums.sjtag.org/viewtopic.php?f=3&t=774}
  • Only 9 votes; all but one show members would like to see both Need 'A' and Need 'B' addressed.
  • Does this answer the question that it was raised for? Not really: It was expected that most people would want 'A' and 'B' but there was an expectation there'd be more looking only for 'A' than is shown. Suggestion that the poll doesn't capture any notion of priority or preference.
  • There seem to be two camps; one supporting diagnostics at the system level, the other supporting lower-level data access.
  • There is a question of how deep the diagnostics go and how that affects the perception of the merit for Need 'B'.
  • Something like configuring a system uses Need 'B' but has no reliance on Need 'A'.
  • Some instruments may be operated at a higher level to propagate access to other instruments, e.g. an instrument that provides an I2C master used to control another instrument.
  • Need 'A' and Need 'B' are interlinked; Means you can dynamically re-configure your system to get at the diagnostic data, so they amount to one need.
  • There are cases where you may not need to diagnose precisely where the fault lies, e.g. if the policy is to discard failed items.
  • Does Need 'A' have dependencies on Need 'B' and does Need 'B' have any dependencies on Need 'A'? Need 'A' can perhaps make use of Need 'B' but Need 'B' does not seem to require Need 'A'. 'B' is dealing with accessibility, 'A' is dealing with diagnosability.
  • If a system served Need 'B' then you could serve Need 'A' from that. but in the absence of 'B' you'd need a secondary way of delivering Need 'A'.
  • If you're assembling a system using COTS boards and have a choice of boards to use, you'd prefer one that gives some BIT or health reporting over one that doesn't - SJTAG compatible. The system designer should recognise that there's some sort of instrument on the COTS item that provides that. In an ATCA COTS board there might be an IPMI message set up that supports the transfer of that kind of data.
  • For Need 'A', do you need to know that Need 'B' is in the design or just that the message is provided? probably only need to know that the message is available.
  • if a COTS vendor implements Need 'B' then that kind of SJTAG compatibility could be promoted as a selling point .
  • Some chip vendors have complex configuration schemes, perhaps via SPI, but don't provide the configuration detail, and instead supply libraries of code that run on specific hardware platforms, so you may not even know it's using SPI.
  • Is there some way to verify that a device is correct, i.e. not counterfeit? ECID (Electronic Chip ID) is a feature in some parts and is referenced in 1149.1-2013. It is a form of electronic serial number that can trace a die back to its wafer. The format is often obscure/encrypted so that only the manufacturer can validate that an ECID is legitimate.
  • What is sufficient to test vs what would be really cool to have available: Need 'B' seems to be rippling up from the low levels while Need 'A' seems to be more top-down.
  • If an item has to report it's overall health (Need 'A') then that can be applied hierarchically as you go down through the system levels. How each report is propagated up through the level above it possibly doesn't matter.
  • There is a dependency on some kind of software communication and that can be corrupted by bad hardware, possibly leaving an entire system down with no clue as to why. Systems that include a form of health reporting may have an alternate communication path that can be used if the primary path no longer works (may be an implementation detail of the standard).
  • Reporting on health is not giving access to control sub-systems.
  • A common requirement is to test with "covers on". It is nice to be able to do some detailed interrogation and largely this requirement is driven by "no trouble found" issues. Need 'B' is a way to gain a bit of capability. The ROI here is mainly for the design team.
  • NAVAIR want to have diagnostics available at all levels (first line, through to depot, etc.) and to ensure that the diagnosis is indicting the correct replaceable assembly.
  • In many cases JTAG is not available after manufacture. Even when it is, it may not be accessible. 
  • Two different manufacturers given the same requirement for testability may implement it differently.
  • Security can block JTAG at board level, because it could reveal protected design features. How do we treat these security concerns? There are methods to disable and enable such protective features in a secure manner. 
  • Security concerns should not preclude reporting basic health status of an item.
  • Al Crouch (with others) has been doing a lot on security in JTAG environments. Perhaps get Al to join a call to talk about it? {ACTION}
  • There are discussions and articles about such things but not a lot is finding its way into real applications so far.
  • We should add something to our Need  regarding a means to deal with security aspects (at a high level). There could be multiple levels of capability, e.g. one level for the COTS vendor, another for the client.
  • Could say that the "need" is really Need 'A' but the quality may be dependent upon how good the outcome from Need 'B' is. Possibly better to say that Need 'B' is a sub-set of the contingencies for Need 'A'.
  • Concern is whether this is something that single working group can handle. Does it get too big to be manageable in the timescale of a WG?
  • Could be looking a something like RESTful API interfaces/services like those used in data centres.
  • Data centers often use cloud architectures with virtual machines running on physical hardware and there's a question of how a test running in a virtual environment can identify where in the physical realm the fault actually lies.
  • Maybe Need 'B' is separate from Need 'A' but needs to have a common interface.
  • Maybe we should define the "interface" a messages (types) and with associated data, that would achieve the required diagnostics with the required level of granularity.
  • Some primitives are listed at bottom right of Brad and Ben's 2006 tutorial slide: http://files.sjtag.org/Brad/ITC2006-Tutorial-8-Part-4-Slide18.pdf.

6. Today's Key Takeaways

  • {Slide 13}
  • Need 'B' is a sub-option of Need 'A'.
  • A "Need 'C'" should address security management.

7. Glossary Terms from This Meeting

  • None.
  • Carried over:
    • Test Salvage - Limited re-use of a test due to imposition of additional constraints.

8. Topic for next meeting

  • Scope, Purpose, Need - continue developing concepts of what the standard(s) needs to address.

9. Schedule next meeting

  • December 4
    • Joel may be out.
    • Only three more meetings this year.

10. Reminders

  • None.

11. Any Other Business

  • None.

12. List New Action Items

  • [15.1] Bill Eklow: Invite Al Crouch to talk about managing security in a JTAG environment.

13. Adjourn

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

Respectfully submitted,
Ian McIntosh