Minutes of Study Group Meeting, 2017-10-23

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

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Eric Cormack (DFT Solutions Ltd.)
Terry Duepner (National Instruments)
Bill Eklow (Retired)
Brian Erickson (JTAG Technologies)
Peter Horwood (Firecron Ltd.)
Bill Huynh (Marvell Inc.)
Joel Irby (ARM)
Roger Lin (Via CPU Platform Inc.)
Richard Pistor (Curtiss-Wright)
Jon Stewart (Dell)
Brad Van Treuren (Nokia)
Carl Walker (Cisco Systems)
Ed Gong (Intel Corp.)
Russell Shannon (NAVAIR Lakehurst)
Craig Stephan (INTELLITECH Inc.)
Louis Ungar (ATE Solutions)
Sivakumar Vijayakumar (Keysight)

By email (non-attendees):

Heiko Ehrenberg (Goepel Electronics)
Naveen Srivastrava (Nvidia)
Mukund Modi (NAVAIR Lakehurst)
Dilipan Jayachandran (SEL)

2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • October 16
    • Draft circulated 10/16/17
    • No corrections noted.
    • Eric moved to approve, seconded by Terry, no objections or abstentions. Approved.

4. Review Open Action Items

  • {Slide 11}
  • [9.1] Louis will draft a proposed definition of "system" and will try to also propose a definition of "system test".

5. Discussion Topics

a) Consider Louis' proposed definitions

  • {Slide 12}
  • Important to get 'System' definition updated for the poster before Heiko needs to get it printed (30th), but we also need to be aware that the study group's time is elapsing and we must conclude the Scope, Purpose and Need discussions. 
  • Loius' proposals had been copied to the forums {Forum post shared: http://forums.sjtag.org/viewtopic.php?p=1223#p1223}.
  • 'System' definition:
    • OSI description included for consideration as it relates to how systems might talk communicate and it has aspects of hierarchy. Probably not directly relevant to the definition but it potentially something to leverage. Previous discussion had suggested it holds relevance for pre-generated tests but was harder to map for interactive execution where the tests might adapt on the fly.
    • Definition might be semantically correct but does it help the reader know what we mean by a system? Some may recognise the synergistic nature but we need to also recognise that it is a collection of parts.
    • We need to be able to get to the boundaries to get to a diagnostic.
    • Can a system be created without some kind of "soft layer" that allows the parts to communicate? Possibly, if you're considering low-level, structural types of test.
    • Why would you call something an SoC rather than an ASIC? Because the SoC is made up of a structure of IPs - what makes it a "system" is that it has structure and boundaries.
    • The definition probably needs to be condensed for use on the poster. Louis will try to do this and bring the qualifications into the main definition {ACTION}.
    • Soft Systems and Hard Systems probably warrant their own definitions, as specialisations of the generic definition. 
  • 'System Test' definition:
    • Regarding isolation of a sub-system for testing, for e.g. a COTS item, you might assume that the vendor will have tested it so there would be no need to "test" that, although you probably want to know that it is good/bad.
    • You may not always test complete "systems" routinely during manufacture if sub-systems are designed (and tested) to have assured interchangeability and are installed by the customer.
    • Bought-in plug-ins may have limited scope for test but should aim to offer enough to allow a faulty one to be indicted, to a reasonable confidence level. Often this will require BIT along with observation of how the item interacts with other parts of the system - observing behaviour. This is generally "high-level" testing and may require the "soft layer" alluded to earlier.
    • The level of test granularity offered by a module will determine the kind of system testing that is possible. 
    • The result of a sub-system's self-test ought to be made available at the boundary of that sub-system.
    • A 'boundary' is not just an interface, it also involves the hand-off between the entities on either side of the interface. The "host boundary" and the "sub-assembly boundary" need to be compatible to be SJTAG compliant, although it is not necessary for SJTAG to specify what that boundary is.
    • Questions: What are the important aspects of that boundary? What are the capabilities we would want to get the best testability?
    • Whether it is an aggregate of multiple message or a single message, there is "content" that is handed off from one entity to another.
    • A definition of a boundary is likely to be a rather abstract one, but Brad will attempt to produce such a definition {ACTION}.
    • A boundary, in this context, is a combination of the Access Link and Data Link. This implies some kind of port and we may need to avoid also implying that Access Link or Data Link refers to a "path" from source to destination that may cross multiple boundaries.
    • What we are describing is really interactions - events taking place. These interactions are just communications - there is not necessarily an understanding of the intent within what is transacted, as that is interpreted by the entities, which then ripple up through the levels of granularity and hierarchy as necessary.
    • For clarification, the original point of "isolation of a sub-system" was meant to imply the constrained isolation of a sub-assembly for test while still installed, not physical isolation by removal. Hence, a manufacturing JTAG test could not be re-used directly to test a board within a system but could be "salvaged" and parts of the system constrained to allow a form of the test to be applied without adversely impacting the remainder of the system. This raises the concept of "logically isolating/constraining" the sub-assembly, although a less ambiguous expression is probably needed. The group could consider this over the coming week.
  • It would be preferred if feedback or continued discussion took place on the forums, as that provides a more visible and permanent record.

b) Scope, Purpose and Need

  • Not discussed due to lack of time.

6. Today's Key Takeaways

  • {Slide 13}
  • A "boundary" describes not just an interface but a hand-off between the entities.

7. Glossary Terms from This Meeting

  • 'Boundary', 'structure' and 'synergy' may all require definitions.

8. Topic for next meeting

  • 'System' definition
  • Scope, Purpose, Need (and title) - continued
    • Try to get through "Need".

    • Group may wish to continue all discussions via email or the forums in the interim (forums are preferred, as it helps maintain a record).

9. Schedule next meeting

  • October 30
    • Remains 11 EDT, so meeting will begin one hour earlier for European (all non-US?) participants.
    • Joel and Carl will be absent, expectation that Heiko and Adam will also be absent.

10. Reminders

  • None.

11. Any Other Business

  • An updated draft of the poster is available on the File Manager: http://files.sjtag.org/ITC2017/ITC_2017v4.pdf
  • Dilip had suggested merging two of the points in the Draft Purpose section. In reviewing those bullet points, Ian was inclined to leave them as each was addressing a slightly different aspect even though they referenced the same attributes.
  • At this stage, we probably only have time to update the System Definition box.
  • Bill Eklow noted that Krish Chakrabarty is giving a presentation on system test and offered to try to get the SJTAG poster promoted within that.

12. List New Action Items

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

13. Adjourn

  • Brad moved to adjourn, seconded by Joel.
  • Meeting adjourned at 12:09 PM EDT

Respectfully submitted,
Ian McIntosh