Minutes of Study Group Meeting, 2017-10-02

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

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Heiko Ehrenberg (Goepel Electronics)(joined 11:06)
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)
Ed Gong (Intel Corp.)
Bill Huynh (Marvell Inc.)(joined 11:09)
Joel Irby (ARM)
Dilipan Jayachandran (SEL)(joined 11:07)
Rajesh Khurana (Cadence Design Systems)
Roger Lin (Via CPU Platform Inc.)
Mukund Modi (NAVAIR Lakehurst)
Richard Pistor (Curtiss-Wright)
Russell Shannon (NAVAIR Lakehurst)
Naveen Srivastrava (Nvidia)
Jon Stewart (Dell) (joined 11:10)
Louis Ungar (ATE Solutions)

By email (non-attendees):
---

Excused:
Teresa McLaurin (ARM)

2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • Slide shown had details from previous meeting: The slide pack linked in the heading of these minutes has been corrected.
  • September 25
    • Draft circulated 9/25/17
    • No corrections
    • Heiko moved to approve, seconded by Bill (Eklow), 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}
  • Considering "Purpose" - what is it that we want SJTAG to do for us?:
    • Does it help if SJTAG has a specific focus, e.g. either finding manufacturing defects or debugging design defects?
    • If SJTAG's main purpose is "system test" then how is that differentiated from a collection of sub-system tests?
    • A system has a physical layer, but may have other layers that only exhibit themselves once the system is assembled.
    • Could a system be defined as:
      •  Something that might have 1149.1 as a primary device protocol but has some minimum number of interfaces to it?
      • Something (black box-like) that can be disassembled into testable sub-systems? That would allow for MCMs to be considered systems but not single die devices.
      • Different test interfaces have different modelling perspectives.  For example, a multi-drop 1149.1 test falls outside the disassembly of autonomous test interfaces in that the test controller is now external for that sub-assembly within the system.  The model and interface is different from a sub-assembly testing itself.
      • {Post-meeting, by email} For a system with a single Multi-Drop bus with plug-in cards, if the plug in cards have a Gateway fitted, then the vectors used on the production line would be exactly the same for use within the system. If no Gateway is fitted to the plug-in card then the test fixture would have the Gateway included to provide vector compatibility to the system domain.
    • In many cases, testing only requires to identify which field replaceable unit (FRU) to swap out, but some customers may require more definitive early diagnostics.
    • Could the System Overview ("SJTAG Universe") diagram be made more hierarchical?
    • A system can comprise layers of software. Is there a way it could be modelled in the manner of the OSI 7-Layer model?
    • SJTAG cannot deal with all of "system test", and certainly not in a single standard.
      • Purpose may imply that kind of breadth but Scope needs to define a manageable task.
      • In talking about "test" we are not excluding other use cases such as programming or emulation.
    • Education may be a feature of the standard:
      • Educate chip vendors on how they detail test capabilities of their devices.
      • Educate board/system designers on recognising and utilising those capabilities - DFT.
    • The standard should define a certain level of interface that should be provided.
    • Security/IP protection needs to be considered.
      • Design security may be enforced by the device manufacturer after device test, or by the board/system manufacturer after programming.
      • Security pulls in the opposite direction from testability - attempts to limit rather than enhance accessibility.
      • SJTAG should not directly attempt to manage security (it's a big enough subject for a standard by itself) but could make recommendations on how the problems could be overcome.
    • Designs should be testable at all levels of assembly.
    • Can we define a minimum level of information that each component or assembly must provide to the next level up, including how to work with security?
    • There are cases where straight 1149.1 test falls apart, e.g. PCIe lanes that need to be tested at speed or they're not really "tested". That means testing at a relatively high level, which also means that it is not necessary to understand how the CPU, etc., interoperate with the element being tested so long as the result gets reported. This is looking more at the behavioural aspects.
    • Some customers, such as DoD may want a standard that they can point to as a functional requirement, to define the minimum service that is to be provided at that level.
  • The following was exchanged via the WebEx chat window during the course of the meeting:
    • October 2, 2017     4:35:54 PM     from Adam W Ley (ASSET InterTech, Inc.) (Guest) to everyone: 
      Certainly it could be (should be) expanded upon, but, for reference, here's the definition of "System" from our (legacy) glossary:
    • October 2, 2017     4:35:57 PM     from Adam W Ley (ASSET InterTech, Inc.) (Guest) to everyone: 
      http://wiki.sjtag.org/index.php?title=Glossary:System
    • October 2, 2017     4:36:56 PM     from Adam W Ley (ASSET InterTech, Inc.) (Guest) to everyone: 
      fyi. here's the link to the complete index of the glossary:
    • October 2, 2017     4:36:58 PM     from Adam W Ley (ASSET InterTech, Inc.) (Guest) to everyone: 
      http://wiki.sjtag.org/index.php?title=Glossary
    • October 2, 2017     4:39:09 PM     from Louis Ungar (Guest) (privately): 
      From Adam's link the definition is: For the purposes of SJTAG, a system may be described as an organized collection of components or assemblies that are designed to operate together to perform one or more tasks or functions.
    • October 2, 2017     4:40:36 PM     from Ian McIntosh (Guest) to everyone: 
      Indeed, but that "definition" is still "up for grabs".
    • October 2, 2017     4:41:27 PM     from Louis Ungar (Guest) (privately): 
      I agree.  IMO it needs more discussion
    • October 2, 2017     4:43:03 PM     from Naveen Srivastava (Guest) to everyone: 
      http://files.sjtag.org/BTW2014/Test_Managers_and_Controllers.pdf

6. Today's Key Takeaways

  • {Slide 14}
  • Notion that SJTAG may be pointed to for functional requirements is a new concept.
  • Diagnostics needs to considered within the scope as well as testability.

7. Glossary Terms from This Meeting

  • None.

8. Topic for next meeting

  • Scope and Purpose - continued
    • Group may wish to continue the discussion via email or the forums in the interim.

9. Schedule next meeting

  • October 9.
    • Columbus Day Holiday in US - Terry, Jon, Russell, Mukund and Roger expect to be absent.
    • Still expect to be able to form a quorum.

10. Reminders

  • None.

11. Any Other Business

  • ITC Poster should be submitted soon - may be possible to get an abstract mentioned in the official proceedings.
  • Ian would like the poster to mention the companies that are involved in the group. If using logos that would probably mean getting permissions, so may just list names.
  • Email reflector is now using the stds-sjtag(at)ieee.org address, although the old cisco.com address will still work for a little while. 

12. List New Action Items

  • None.

13. Adjourn

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

Respectfully submitted,
Ian McIntosh