Minutes of Weekly Meeting, 2013-11-11

Meeting called to order: 11:07 AM EST

1. Roll Call

Ian McIntosh
Carl Walker
Brad Van Treuren
Brian Erickson

Excused:
Adam Ley
Eric Cormack
Michele Portolan
Heiko Ehrenberg
Patrick Au

2. Review and approve previous minutes:

11/04/2013:

  • Draft circulated 11/04/2013.
  • No corrections advised.
  • Insufficient attendance to vote on approval.

3. Review old action items

  • All: do we feel SJTAG is requiring a new test language to obtain the information needed for diagnostics or is STAPL/SVF sufficient? See also Gunnar's presentation, in particular the new information he'd be looking for in a test language (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
  • Harrison will attempt to come up with a table of use cases and their associated layer and what can be done at that layer. Ongoing.
  • Ian/All: Look for real world examples of boards that we could take through from board test to a system test implementation as a worked example case. Ongoing.
  • Ian - Add the previously discussed lists to the 'master' template. Ongoing.
    • Some sections need further expansion that may take time to develop.
  • All - Consider material for BTW: Either specific sub-topics related to our Templates or any other alternative subject we could present. Ongoing.

4. Reminders

  • Consider Adam's three points (from the action from the first weekly meeting) and suggest what is preventing us from answering those questions:
  • Establish consensus on goals and constraints
  • What are we trying to achieve?
  • What restrictions are we faced with?
  • Forum thread for discussion: http://forums.sjtag.org/viewtopic.php?f=3&t=172

5. Discussion Topics

a. BTW - What do we offer?
b. Templates - Tx Rx lane selection amendments: Review edits.

  • Ian felt that the two topics for today were related, so they have been merged.
  • Ian advised that he will be able to attend BTW and is making travel arrangements.
  • {Wiki Template Go/NoGo Instrumented Test of AC Coupled Links with Multiple Loopbacks at One End shared}
  • Updated the Assumptions at the previous meeting and had concluded that there was probably no need to add anything to Consequences.  Ian has copied the new Assumptions text in to the other related templates with some minor amendments to suit context.
  • Brad commented that the key thing noted was that the Test Manager had control of the access interface as well as the TAP.
  • [ALey, Proxy] I looked at the template but couldn’t tell how this comment was reflected therein. Also, I can’t say that I understand it in this context; in particular, what is meant here by “access interface”? And what does it mean for the Test Manager to have control of same?
  • Most existing JTAG tooling is composed of independent pieces that don't interoperate well, or don't readily allow a single program to have control of all the operations.  Some toolsets are better than others in that respect but it still very difficult to extract data acquired in the course of a test and use it elsewhere.  Brad cited an example of extracting datasets from instruments and running them through MatLab to get a presentation format that the customer could use.
  • Each toolset implements its own view of the domain.  However, it may well seem to the tool vendors that these end uses are too diverse to be readily captures in the tooling.  Certainly Brad and Ian both have examples where extensive, custom tooling had to be created to fulfil needs that weren't met by "stock" toolsets.
  • [ALey, Proxy] Concerning both of the comments above, I can only speak for one toolset, but I expect that all such vendors are open to inputs and insights in such regards.
  • 1149.1-2013 and P1687 are beginning to standardize the representation of data within the vectors.
  • [ALey, Proxy] I'm afraid that I have no idea what this means ... Perhaps an example would help make the case?
  • No longer enough to simply ask "did this test step fail?"
  • Any requirements for tooling probably need to consider the "what" rather than the "how" but there's nothing in the current template that addresses this in any way.  Even the iNEMI BA-BIST activity hasn't considered the tooling implications, only what happens at the device pins.
  • Dedicated testers no longer exist: ICT machines have added BST and functional test but not always with much coherence.  Add-ons rather than a clean architecture.  Ian thought that could be driven by the customers wanting to enhance the capability of existing capital assets and the machine vendors trying to offer additional capabilities as a differentiator from competitors.
  • Brad saw that testing was traditionally algorithmic and not related to what actually happens on the board.  Ian commented that the drive in his company was to be smarter about what you tested for and when, since the defect spectrum could be quite different during each of design verification, manufacture and field returns.
  • [ALey, Proxy] Perhaps Brad can elaborate on his comment?  Otherwise, I can only suppose that he means that JTAG (boundary scan) testing is generally performed on a structural basis as opposed to a functional basis??
  • Tool vendors are unlikely to admit to having problems with test architectures, although Ian thought there wasn't a reluctance to broaden their tool scope but probably just that they don't know what is needed, because it has never been stated/asked for.
  • [ALey, Proxy] Noting, again, that I can only speak for one toolset (tool vendor), I expect that all such vendors are open to inputs and insights in such regards (and thanks to Ian for the benefit of the doubt Smile).
  • Brad restated that we need to document, through the templates or elsewhere, what the tooling needs are.
  • [ALey, Proxy] Yes! That would be most welcome!!
  • Brad noted his continuing frustration at the difficulty in moving the diagnostic content of a test between toolsets and described an attempt to create an "SVF-II" in collaboration with Teradyne and Texas Instruments as means to allow transfer of diagnostic information.
  • [ALey, Proxy] Begging pardon, I'll note that, as a representative of a toolset vendor, I am also frustrated. On the other hand, I'll offer that the toolset vendors operate in a very small market with very high overhead and that adding inter-toolset exchanges just adds more overhead without, so far at least, expanding the market ... Still, I have been a proponent, since this effort first began, of such inter-toolset exchanges and I would welcome the opportunity to collaborate in such efforts, be they a reprise of SVF-II or some other ... I'll also note that the early work done by ASSET and Firecron demonstrated an inter-toolset exchange that facilitated diagnostic reporting (albeit, admittedly, not in a way that actually moves diagnostic content between toolsets ...) And, perhaps it's worth noting that the work has been used for more than just demonstration (which is to say, that it has been used by real customers for real testing)
  • Ian suggested that as we were unlikely to have answers to the questions raised today for BTW, we should perhaps pose the questions as part of the discussion.

6. Key Takeaway for today's meeting

Templates need to include (somehow) the requirements on tooling to support the test architecture described by the template.

7. Schedule next meeting

  • Next Meeting: November 18. Heiko expected to be absent.
  • November schedule: 25. Thanksgiving may restrict attendance on 11/25.

Ian would like to know who is expecting to be absent on Nov 25, as there may not be enough people for a viable meeting {ACTION}.

8. Any other business

  • None.

9. Review new action items

  • All - Please advise Ian by email of availability for Nov 25 meeting.

10. Adjourn

Brian moved to adjourn at 12:06 PM EST, seconded by Brad.

Respectfully submitted, Ian McIntosh