Minutes of Study Group Meeting, 2017-11-06

Meeting called to order: 11:05 AM EST

The slide references relate to the pack used during this meeting, located here: http://files.sjtag.org/StudyGroup/SG_Meeting_12.pdf

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Heiko Ehrenberg (Goepel Electronics) (joined 11:10)
Eric Cormack (DFT Solutions Ltd.)
Terry Duepner (National Instruments)
Brian Erickson (JTAG Technologies) (joined 11:07)
Peter Horwood (Firecron Ltd.)
Bill Huynh (Marvell Inc.)
Joel Irby (ARM)
Adam Ley (Asset Intertech)
Richard Pistor (Curtiss-Wright)
Naveen Srivastava (Nvidia)
Jon Stewart (Dell)
Brad Van Treuren (Nokia) (joined 11:26)
Carl Walker (Cisco Systems)
Ed Gong (Intel Corp.)
Craig Stephan (INTELLITECH Inc.)
Louis Ungar (ATE Solutions)

By email (non-attendees):

Russell Shannon (NAVAIR Lakehurst)
Mukund Modi (NAVAIR Lakehurst)
Roger Lin (Via CPU Platform Inc.)
Bill Eklow (Retired) (present prior to call to order)

2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • October 30
    • Draft circulated 10/30/17
    • No further corrections noted although Louis wished to advise that the ATest PAR shared last week and referenced in the minutes was for the Test Coverage portion of the activity, not the Test Access portion intended. Louis will share the correct PAR once it becomes available.
    • Terry moved to approve, seconded by Louis, no objections or abstentions. Approved.

4. Review Open Action Items

  • {Slide 11}
  • [10.2] Brad will draft a definition for "boundary".
    • ONGOING.

5. Discussion Topics

a) Summary on ITC and TTSC meeting

  • {Slide 12}
  • Heiko reported on ITC:
    • Apparently the least well attended ITC.
    • Around 10-15 visitors to our poster, mostly previously unaware of SJTAG. A few acknowledged the potential value. A couple of people took pictures of the poster and expressed intent to download a copy from the website.
    • There were a couple of tutorials on system test that Heiko wasn't able to attend and a panel on system-level test, but this had a different perspective to us; more like an SoC view of "system".
    • Impression is that visitors that are talking about system-level test are not thinking about to the same extent that we are. Surprise when told that SJTAG is looking at more than just testing.
  • TTSC Meeting:
    • Presented our status with an indication that we were still on track to have a PAR by the time our time window runs out.
    • ATest group is also on track to submit their PARs; the Access one may be of interest to us (this is the PAR Louis referred to in the review of minutes).

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

  • Current draft "Need" statement, is included in this forum post: http://forums.sjtag.org/viewtopic.php?p=1176#p1176.
  • First sentence talks about "leveraging existing standards" but system test gets far removed from pin level that these standards address. Really ought to leverage sub-system level information.
  • "Need" should also express an ability to re-use tests, e.g. re-use chip-level tests at board-level, and board-level tests at system-level. Arguably, "test salvage" is a more realistic term, since the lower level tests can rarely be re-used verbatim, due to additional constraints imposed at the higher level.
  • "Leveraging" a standard doesn't specify how it will be used. However the existing wording implies that the reason is to make use of the pin-level standards and force a flow up through the hierarchy, which is likely to be difficult. Utility becomes a question.
  • May be easier to look at it from an "API-level", related to the functional level of the sub-assemblies.
  • Perhaps a more benign term than "leverage" is required, perhaps "interface" or "access". What we want to do is use the facilities available from the lower level tests.
  • There appear to be two things we're trying to do:
    • Support hierarchical test and utilise features of the sub-systems,
    • Support P1687.1 tooling, where specific registers need to be loaded with data to do e.g. a SERDES test at board level.
  • "How" we go about any of these is probably for the working group to decide. Work at the Use Case level rather than the solution.
  • Gunnar Carlsson's ATCA testing used IPMI code calls delegate on-board testing - a proxy of the JTAG interface.
  • We may be pulling ourselves in different directions. Perhaps need to agree a framework of what we think the standard is about. There could be multiple standards that share the same Need (and perhaps Purpose) but have different Scopes: Perhaps one looking at the 1687 Use Case and another looking at the more general infrastructure, in which case we need to determine which has higher priority (is one dependant on the other?).
  • What is sent and read? Is it messages or is it content that carries intent?
  • Some of the discussion here is why the initiative group moved away from a general test standard towards considering data links and access links.
  • Looking at the specific 1687 case (using 1149.1) may have helped to reveal what was required of the more general case that P1687.1 is tackling. However, there's an evolving understanding of the callback methods used by 1687 and at least three events have been identified:
    • Reset to a known state,
    • Initiate the capture-shift-update cycle,
    • Do state transitions of the 1687 network.
  • Brad may share a couple of slides from the ITC 2006 Tutorial during next week's call.
  • You could have "agents running on a board that can carry out tests, often in embedded systems, and is typically "functional test".
  • It is possible to create 1149.1 tests that look no different to the functional tests but also have pin and net level information. But that suggests having more access (and design control) than is often available and security considerations may impose even more restrictions on access.
  • It'd be useful to have a basic command structure for sub-assemblies, so you can know some information about sub-systems and have that feed back up the system.
  • An interface and what it does: You could think of the interface as part of a routing infrastructure: Considering the interface itself would help address the 1687 need while how the interface gets used is another aspect. 
  • May not need to separate anything out in the "Need" - that could come in the Purpose or Scopes of relevant PARs.
  • The "functional" kind of information may be difficult to control - would vendors buy-in to standardised behaviours? Probably don't want to go the way that 1149.5 did and mandate a standardised interface - designers/manufacturers weren't interested in supporting it.
  • We will always have the problem of some boards/devices making little or no information available (perhaps because of privacy/security concerns).
  • Proposal that all members think about what they'd want from an SJTAG infrastructure to help seed next week's discussion {ACTION}.

6. Today's Key Takeaways

  • {Slide 13}
  • There is a distinction between and interface and how it is used.

7. Glossary Terms from This Meeting

  • Test Salvage - Limited re-use of a test due to imposition of additional constraints.

8. Topic for next meeting

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

9. Schedule next meeting

  • November 13
    • Heiko may be absent.

10. Reminders

  • None.

11. Any Other Business

  • None.

12. List New Action Items

  • [12.1] All: Consider what you need/want from an SJTAG infrastructure - preferably post to forums (see link in section 8, above).

13. Adjourn

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

Respectfully submitted,
Ian McIntosh