Minutes of Study Group Meeting, 2017-10-30

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

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Heiko Ehrenberg (Goepel Electronics)
Eric Cormack (DFT Solutions Ltd.)
Terry Duepner (National Instruments)
Bill Eklow (Retired)
Brian Erickson (JTAG Technologies)
Peter Horwood (Firecron Ltd.) (left 11:44)
Bill Huynh (Marvell Inc.)
Adam Ley (Asset Intertech)
Richard Pistor (Curtiss-Wright) (joined 11:09)
Jon Stewart (Dell)
Brad Van Treuren (Nokia) (joined 11:10)
Ed Gong (Intel Corp.)
Dilipan Jayachandran (SEL)
Russell Shannon (NAVAIR Lakehurst) (joined 11:06)
Louis Ungar (ATE Solutions)

By email (non-attendees):

Joel Irby (ARM)
Carl Walker (Cisco Systems)

2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • October 23
    • Updated draft circulated 10/25/17
    • No further corrections noted.
    • Eric moved to approve, seconded by Terry, no objections or abstentions. Approved.

4. Review Open Action Items

  • {Slide 11}
  • [10.1] Louis will revise the definition of "system" (dependency on 10.2).
  • [10.2] Brad will draft a definition for "boundary".
    • ONGOING.

5. Discussion Topics

a) Consider revised definitions

  • {Slide 12}
  • Loius' updated proposals had been copied to the forums {Forum post shared: http://forums.sjtag.org/viewtopic.php?p=1224#p1224}.
  • 'System:'
    • Suggestion that part of what is required is to show how the gap to other standards is filled - that is the "Need" but probably doesn't directly impact the definition of a system.
    • Perhaps leaves a question of how a 'subsystem' is defined.
    • The group is generally satisfied with the updated definition.
  • 'System Test:'
    • Some "system tests" may only be Go/NoGo and not require to have a diagnostic capability.
    • What a system test is may be a matter of perspective: the needs for an embedded test would be different to those for an external tester although both would expect to leverage the capabilities in the UUT.
    • Much of the thought is probably about "manufacturing test", but for a retuned item it may be looking at how much the system has degraded over time.
    • What level of subsystem test is expected? Not necessarily saying that the "subsystem is tested", but that a fault can be traced to a subsystem.
    • System Tests could fall into two categories: Showing the system has been designed correctly, and then showing that something built to the proven design is free from defects. Could possibly be broken down even more.  However, there needs to be room for diagnostics even though not all tests will necessarily require diagnostics.
    • The diagnostics granularity is not a fixed view: While many cases will only want to diagnose to the subsystem some application may require a net/pin diagnostic so that e.g. a minor connectivity issue can be quickly resolved by removing, cleaning and replacing the affected module rather than requiring a swap.
    • Could we replace references to 'subsystem' with something representing a flexible granularity? Difficult: we could have anything from "black box" representations to fully "white box".
    • Should keep the definition at a high level, only defining what is required to support our need.
    • Probably best to defer further definition until we have made progress on the Need statement.

b) Scope, Purpose and Need

  • Louis had obtained permission from the ATest group to share their draft PAR {shared sections 5.2, 5.4 and 5.5 of: http://files.sjtag.org/StudyGroup/Draft_PAR_analog_defect_coverage_Oct2017_v1.2.pdf}.
  • It was felt that the content didn't offer anything to assist our effort to prepare a PAR as defect accounting is probably too far removed for our immediate sphere of interest, but it was nevertheless useful to make the group aware of the activity.
  • The discussion on the definitions highlights that we have an outer boundary to the system and that each subsystem similarly has boundaries that interconnect the subsystems.
  • These boundaries are necessary to "isolate", if not necessarily test, the subsystem, e.g. in the case of a design with redundancy.
  • If we consider that these boundaries are "ports" (or collections of ports), the question we're dealing with is "How do we get to those ports?" - we may need to go through one or more subsystems to reach a given port or boundary.
  • {Peter left, 11:44}
  • The boundaries ought to support any application, not just test.
  • The standard should address the need of the higher level application. A view might be the degree of control over the subsystem and the minimum information  you'd like it to report: The subsystem makes information available to the higher level system.
  • The data passed may only have meaning in the context of the application that uses the data. At the subsystem level, there may be a meaning in the context of an application of that subsystem. However the data could be considered as just "bits from one register being moved to another register": It's routing from a source to a destination.
  • Is there a way to characterise what a system test is? And SoC and a missile may both be systems but they are clearly different and tested differently, so what is "common" between them? Possibly that there is some sense of "overall function" or application.
  • In an example of routers, you may have ASICs that you test by running a form of traffic through them. Similarly at higher levels of assembly you can still test by running simulated traffic through.

  • Current draft "Need" statement, for reference, is included in this forum post: http://forums.sjtag.org/viewtopic.php?p=1176#p1176. The preceding thread provides a history of modifications to the texts.

6. Today's Key Takeaways

  • {Slide 13}
  • Promising start made on "Need".

7. Glossary Terms from This Meeting

8. Topic for next meeting

  • Scope, Purpose, Need (and title) - continued

9. Schedule next meeting

  • November 6
    • Return to regular time for European participants.
    • Eric may be absent.

10. Reminders

  • None.

11. Any Other Business

12. List New Action Items

13. Adjourn

  • Eric moved to adjourn, seconded by Bill E.
  • Meeting adjourned at 12:07 PM EDT

Respectfully submitted,
Ian McIntosh