Minutes of Weekly Meeting, 2013-11-18

Meeting called to order: 11:10 AM EST

1. Roll Call

Carl Walker
Eric Cormack (left 11:53)
Michele Portolan
Ian McIntosh
Brian Erickson
Peter Horwood (joined 11:11)
Tim Pender (joined 11:12)
Brad Van Treuren (joined 11:22) 

Adam Ley
Heiko Ehrenberg
Patrick Au

2. Review and approve previous minutes:


  • Draft circulated 11/04/2013.
  • No corrections advised.
  • Eric moved to approve, seconded by Carl. No objections or abstentions.


  • Updated draft circulated 11/12/2013.
  • No further corrections advised.
  • Brad moved to approve, seconded by Carl. No objections or abstentions.

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.
  • All - Please advise Ian by email of availability for Nov 25 meeting. COMPLETE.

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. Templates - Some clarifications and explanations..

  • Ian wished to address the points raised by Adam's proxy input to the previous meeting as it indicated that there was a need to clarify some things for those who were not present on the recent calls.
  • "[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?"
  • Ian felt that we had introduced the term "access interface" without ever defining what that was. Ian saw this as the interface used to gain access to the instruments within a device: It may be a JTAG interface but could equally be some other interface such as SPI or I2C.  Brad commented that it was similar to the access link invoked by P1687 and checked the definition used there but it found not to be very helpful.
  • Ian conceded that the diagram gave no suggestion that non-JTAG interfaces might be involved, although Brad remarked that this was something that was only recognised very recently.  In any case, it would probably make the diagram too cluttered to be usable.  Ian suggested that a more detailed diagram of the circuit segment under consideration could be prepared but Eric felt the wording in the Assumptions, Dependencies and Consequences sections provided enough additional information.  Brad also noted that such a diagram would address one specific case only.
  • Brad remarked that there were two aspects here: Command and Control and Data Transfer and that these were separate. Ian agreed and noted that it was possible that each could use a different interface.
  • Access Interface probably needs to be added to the SJTAG glossary - http://wiki.sjtag.org/index.php?title=Glossary.
  • It was important for the Test Manager to be able to coordinate the JTAG TAP with the access interface (especially where the access interface does not use JTAG) in order to perform the tests.
  • "[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."
  • There is a customer dependency here.  Brad felt that we as users may not be defining clearly enough what we need.  We may ask e.g. for tools to talk to embedded instruments and we may get them but not with the level of interoperability with other tools that we hoped.  Ian thought that in many cases the user may just accept the available tooling for what it is and not go the extra step to state what they feel is missing.
  • Brad felt that perhaps the developers producing the tooling might be unaware of many of the problems faced by test engineers; that had been his own experience when he was in the position of providing software tooling and we need to find a way to adequately express our software requirements.
  • Brad thought that FAEs should be able to provide some level of feedback.  Ian noted that sometimes it is difficult even to allow FAEs full access to some of our problem areas due to security restrictions.
  • Ian was unsure whether the tooling requirements might prove to be big or small: Big might become too much to include within the template.  Additionally, Ian though that some requirements may span many templates even if the templates themselves are not related. That orthogonality might mean that the requirements are best captured elsewhere.  Brad suggested that the type of analysis used in Jacobsen's Use Case analysis might help to pick out the common or recurring aspects of the tooling requirements.
  • {Eric left}
  • "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?"
  • Brad had meant that PDL in both of the standards was providing a degree of commonality in the representation of the vectors; behaviours were starting to be captured at a high level in the PDL.
  • "[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??"
  • Traditionally, BScan tests were structural and produced algorithmically by ATPGs.  Now we are beginning to see BScan as an interface to other functions and features.
  • Ian thought that most of the other comments made by Adam were statements that required no further explanation.

b. What can we do for BTW?

  • Not discussed due to lack of time.

6. Key Takeaway for today's meeting

  • Documenting tooling requirements will need to be done outside of the Templates.
  • Techniques similar to Jacobsen's Use Case Analysis (ref: ISBN-13: 978-0201544350) might be used to identify the commonalities in tooling requirements.

7. Schedule next meeting

  • Next Meeting: November 25. Tim, Brad, Adam expect to be absent.
  • December schedule:
    2 - Ian may use this to review material for BTW. Brad will be absent.
    16 - Brad, Carl, Peter absent.
    23 - Tim, Carl, Peter, Ian absent. Meeting cancelled.

8. Any other business

  • None.

9. Review new action items

  • None.

10. Adjourn

Brian moved to adjourn at 12:09 PM EST, seconded by Peter.

Respectfully submitted, Ian McIntosh