Minutes of Study Group Meeting, 2017-11-13

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/StudyGroup/SG_Meeting_13.pdf

1. Roll Call

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

By email (non-attendees):

Heiko Ehrenberg (Goepel Electronics)
Peter Horwood (Firecron Ltd.)

2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • November 6
    • Draft circulated 11/06/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.
  • [12.1] All: Consider what you need/want from an SJTAG infrastructure.

5. Discussion Topics

a) Scope, Purpose and Need: Focus on "Need"

  • Discussion following this forum post: http://forums.sjtag.org/viewtopic.php?p=1227#p1227 {shared}.
  • There are appear to be two primary needs expressed by the group and would seem to require two standards. A question is whether they share anything in terms of PAR Need and Purpose.
  • Need 'A' requires a communication structure, which Need 'B' could provide, although 'B' may not totally encompass all the needs of 'A': There may be a need to format the data. 'B' is not a subset of 'A'.
  • Need 'A' requires some level of "intelligence" in each sub-system, while Need 'B' does not necessarily require it.
  • For 'A', each sub-assembly will report up the the hierarchy with some sort of diagnostic information. This is similar to the OBD-II in automotive systems and some of the network server fault reporting.
  • 'B' is a control and communications structure.
  • 'B' probably doesn't know what the data it's passing means, while 'A' has the notion of "application" needs some understanding of the result.
  • If we want something that is scalable we probably want both Need 'A' and Need 'B'.
  • Boards can have JTAG that can provide information at the chip level but we want to be able to diagnose at all levels, e.g. diagnose to a board rather than a chip. But we may not even have access to the board level JTAG from the system level.
  • Perhaps there is a Need 'C' that requires that whatever test/diagnostic access exists at board level should be available at the system level.
  • Brad described his slide from the 2006 ITC Tutorial {http://files.sjtag.org/Brad/ITC2006-Tutorial-8-Part-4-Slide18.pdf, shared}.
  • Using the system of diagnostic agents, it is possible for an agent running JTAG tests (perhaps salvaged from manufacturing tests) to return pin and net diagnostics. The system needs to be architected this way, you can't just add this to an existing system.
  • Some sub-assemblies might be locked out for security.
  • How much extra space needs to be allocated in memory to support the kind of testing described? It depends: Some tests may reside on a shelf controller  and be passed to the board in question, in other cases it may be part of the local memory, in PROM.
  • How you transmit data to the user is an issue.
  • There should be some kind of guidance on how you implement this. Need requirements that can be put into a contract.
  • It is an attempt to turn a hardware problem into a software problem, but it has to be part of the system architecture.
  • Perhaps standardising a requirement to report data to a sub-system's users begs the question of whether there then needs to be a standard port/interface/protocol at the sub-system edges. That be another layer to deal with.
  • There's still a question of integrating COTS items - you may not have much control over what is in the architecture.
  • We should probably only state the need to provide diagnostic agents and leave the working group to address the implementation.
  • How do these diagnostic agents compare to VIs (virtual instruments)? A VI is just a program; what you're doing with it is going to change what is in it.
  • Need to have some level of diagnostics available to the user of the sub-assembly; this eases the question of how it is handled.
  • In Brad's diagram, the diagnostic manager is shown as if it were a "hub" to the diagnostic agents, but this does not preclude an agent from acting as a manager to lower level agents (hierarchy).
  • Does the diagnostic agent deliver a Pass/Fail? That would be the minimum but it could send back pin/net data, perhaps salvaging a board level test.
  • There are many ways of collecting the data, this leads to a lot of variability. A standard would likely need to bound that in order to make it manageable, but other standards could then extend it to deal with other cases.
  • Many boards already have some form of self-test, even if only Power-On Self-Test. Board suppliers could be asked to provide access to the result data.
  • Secure communications: Each sub-system may choose to keep some information secure, and that will affect what test data they will provide. That may depend on how we label the test data, for example simple Pass/Fail indication could be considered quite safe - it could be the result of a test of it's own.
  • Also worth noting that exposing something that could initiate a test could allow a system to be disrupted; test is intrinsically disruptive.
  • Can we come up with a single sentence to address security for the Need statement? Possibly too much to expect in the meeting, better to defer that to the forums.
  • CIM integration is very similar to the scheme Brad described.
  • Most boards/sub-systems have at least some kind of power control that used to "stage" it into the system. That will have features that could map to a diagnostic agent, and may use IPMI or Ethernet over Backplane, so some COTS items can supply the necessary infrastructure to implement this.
  • What proportion of the group require Need 'A', what proportion require Need 'B' and what proportion require both? Ian can set up a forum poll for the question {ACTION}.  

6. Today's Key Takeaways

  • {Slide 13}
  • Scalability requires both Need 'A' and Need 'B'.
  • There a concerns over the impact of security, both data content and disruption prevention.

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 - continued
    • Continue with "Need" (exact topic will depend on how forum threads develop).
    • Reference: http://forums.sjtag.org/viewtopic.php?p=1232#p1232
    • Group is encouraged to continue discussions via email or the forums in the interim (forums are preferred, as it helps maintain a record).

9. Schedule next meeting

  • November 20
    • Jon may be absent.

10. Reminders

  • None.

11. Any Other Business

  • None.

12. List New Action Items

13. Adjourn

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

Respectfully submitted,
Ian McIntosh