Minutes of Study Group Meeting, 2017-09-18

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

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Heiko Ehrenberg (Goepel Electronics)
Brad Van Treuren (Nokia)
Eric Cormack (DFT Solutions Ltd.)
Bill Eklow (Retired)
Brian Erickson (JTAG Technologies)
Peter Horwood (Firecron Ltd.)
Carl Walker (Cisco Systems)
Adam Ley (ASSET Intertech)
Terry Duepner (National Instruments)
Bill Huynh (Marvell Inc.)
Joel Irby (ARM)
Rajesh Khurana (Cadence Design Systems) (joined 11:08)
Roger Lin (Via CPU Platform Inc.)
Richard Pistor (Curtiss-Wright)
Naveen Srivastrava (Nvidia)
Jon Stewart (Dell) (joined 11:06)
Louis Ungar (ATE Solutions)
Sivakumar Vijayakumar (Keysight, Singapore)

By email (non-attendees):
---

Excused:
---

2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • September 11
    • Draft circulated 9/11/17
    • No corrections
    • Brad moved to approve, seconded by Terry, no objections or abstentions. Approved.

4. Review Open Action Items

  • {Slide 11}
  • No open actions.

5. Discussion Topics

a) Scope and Purpose

  • {Slide 12, 13, 14}
  • These are provisional text for Scope, Purpose and Need, drafted by the Initiative group and should only be considered as something to talk around and develop from.
  • For the PAR, Purpose is optional but is encouraged.
  • From previous discussions:
    • Purpose should be expansive (big picture) and allow any follow-on "dot" standards to pursue the same purpose.
    • Scope should be narrow to keep the task achievable in the working group's timeframe; Not so narrow as to artificially limit the standard and not so broad as to risk accusations of not fulfilling the scope.  
  • Need (slide 14) should be considered first - what is the gap we are trying to fill?.
    • Previous discussion (for background) is in the forum thread: http://forums.sjtag.org/viewtopic.php?f=3&t=740
    • While some boards may be mainly digital and suitable for vector-based test, systems are far less likely to be purely digital, and part of value of system test is to be able to get some analogue values out.
    • Should be more about providing the access up through the hierarchy of the assembly.
    • Some analogue measures will be accessible via some digital interface or through a software API.
    • Product application software may not include features that are useful/necessary for test purposes.
    • Less and less DFT support through tools as the assembly level increases.
    • At the board level, do we want to test each component or the function of the board or both?
    • Do we expect to re-use tests from the chip-level?
    • At the system level, what are we testing? We can ensure the system is working but if it isn't then diagnostics and locating the failing sub-assembly is critical.
    • At the system level, there can be many different vendors involved.
    • May take a "black box" approach with third party boards.
    • That could be extended to build black boxes together into a superset black box.
    • In an 1149.1 environment, there's a dependency on where the test controller resides:
      • With an embedded controller, a test could be delegated to a black box.
      • With a multi-drop over a backplane then there needs to be control over some of the I/O and that needs more than just a black box understanding.
    • We could have something that is roughly equivalent to INTEST and EXTEST.
    • INTEST could offer some diagnostic capability from re-use of lower level tests.
    • There are cases where a board may not have a defined specification and is just a collection of components.
    • It's possible to capture a snapshot of a device/board state at the time of failure and have that reported out for analysis even before an engineer attends.
    • Some systems can have smart monitoring that can be queried to determine what they were doing at the point of a failure.
    • SJTAG can be an enabling technology - gives you access to instruments/data and the user application defines the Use Case.
    • Round-up of points:
      • Don't present the standard as being inherently vector based.
      • Diagnostics should be a core emphasis.
      • A system should be targeted towards a specific end-use (with defined environment) else it's not really a system.
      • Value in trying to turn black boxes into grey boxes (or even white boxes), if possible.
      • Feeding back information surrounding failure can reduce the incidence of "no trouble found".
      • There should be some information captured on the environment in which the failure occurred.
    • Software/firmware (in the system) is generally created for the end user problem space. May need special loads of software/firmware for testing.
    • Security considerations and accessibility tend to compete against each other.
    • Need to recognise that there needs to be a way to open and close the access paths before and after test.
    • SJTAG shouldn't be trying to manage security - That should be the problem of:
      • the standards we are leveraging (for chip level security),
      • the board designer (for board level security - e.g. obscured path selector).
    • Chip designers will want to lock down "back-doors" but may open up a limited/minimal set of functions for test (mainly structural).
  • Post-meeting points, in email:
    • Software/firmware may not be available at all during early development and (hardware) design verification. Cost vs benefit of test code for this period is case dependant.
    • In highly parallel development lifecycles, application code may not even be available as the product moves into production.
    • Production support evolves as the product matures.

6. Today's Key Takeaways

  • {Slide 15}
  • Notion of transitioning from black box to grey box to white box.
  • Test Engineer's need is really access to diagnostics in the system.
  • Operating environment is an important part of state capture.
  • Security needs to be considered (need recognised).
  • Focus on an enabling technology that is used by applications.

7. Glossary Terms from This Meeting

  • None.

8. Topic for next meeting

  • Scope and Purpose - continued

9. Schedule next meeting

  • September 25.
    • Louis and Terry will be out.

10. Reminders

  • None.

11. Any Other Business

  • None.

12. List New Action Items

  • [5.1] Ian to re-circulate link to forum thread on Scope and Purpose.

13. Adjourn

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

Respectfully submitted,
Ian McIntosh