Minutes of Weekly Meeting, 2014-10-06

Meeting called to order: 11:06 AM EDT

1. Roll Call

Ian McIntosh
Eric Cormack
Carl Walker
Tim Pender
Peter Horwood
Brad Van Treuren (joined 11:09)
Brian Erickson (left 11:13)
Heiko Ehrenberg (joined 11:14)

Adam Ley
Michele Portolan

2. Review and approve previous minutes:


  • Draft circulated 09/29/2014.
  • Eric noted three corrections:
    • "Peter wondered in portability" → " Peter wondered if portability"
    • "Phil Geiger's iNEMImailing list" → "Phil Geiger's iNEMI mailing list"
    • "Tim noted that there'd some advantage " → "Tim noted that there'd be some advantage "
  • Eric moved to approve with the above amendments, 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)
  • Ian: Add the previously discussed lists to the 'master' template. Ongoing.
    • Some sections need further expansion that may take time to develop.

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. Test Managers - formulate our proposition

  • The previous meeting concluded that we would need to propose our own evaluation of the optimal management architecture and present that for feed back from the wider community {Test Managers slide 6 shared}.
  • Likely, we would need to expand upon the diagram with textual descriptions of the various roles and possibly include the Control System model (slide 7) for further explanation.  There may also be a need for further graphical support but Ian was wary of creating a large presentation as it would lead to side discussions and divert focus from the key questions.
  • Brad noted this would not be resolved overnight and cited IJTAG's experience of doing lots of presentations and getting lots of feedback, some of it contradictory.  We may want to go through BTW, ITC, DATE, etc., soliciting opinions, but we should at least take a position on our preferred concept and list alternatives with reasons why they are not preferred.  P1687s SIB is an example that had lots of discussion and feedback, a notable comment being that it changed the DR length and so broke the rules of 1149.1.  A lot of this discussion took place after the PAR was created.  Ian noted that Brad's suggestion implied a long lifecycle to resolving our questions on the architecture and wondered how much of a barrier this was to creating a PAR.  Brad thought that may be down to how the PAR wording is crafted as some of P1687's recent trouble has been because of differences of interpretation on the scope.
  • Ian brought in a topic that he had intended to hold for the next agenda item:  In a recent email, Adam had commented that the three central bullet points added to the ITC poster seemed to amount to a statement of scope for SJTAG.  There seemed to be broad agreement with that view.  P1687's experience seems to highlight the potential difficulties that could arise from setting the scope too tightly, but Ian also took note of the point made previously by Brad that in setting it too loosely, there was a risk of being accused of failing to achieve the promised potential of the standard.
  • Ian wished to confirm that the group agreed that the Test Managers area was a key topic which needed to be resolved.  Brad was of the opinion that we needed an architectural block diagram and what we have just now is pretty close to what people are doing in the real world on an ad hoc basis, and aligns well with our "stack":  We simply need to formulate it into a standard fashion.  The key question remains whether the Test Manager is an abstraction or another layer.  Ian thought that Brad had made a good case for it being an abstraction but Brad commented that he could argue for both cases.  Either way, since we'd failed to get an opinion from BTW, we would have to resolve the question for ourselves first and then seek feedback.
  • As a layer, the Test Manager could provide a communications backplane between the External Controller, SJTAG Manager and Chamber Manager, although the same result could be achieved by each of the objects implementing a common API (i.e. specialisations off the abstract Test Manager).  Ian noted that was fine for the SJTAG side but there could be resistance in the case of a third party Chamber Manager which might then require a "wrapper" to provide the common interface.  The Test Manager as a layer could handle this but would need customised for each different configuration , e.g. a plugin for the Chamber Manager in use. This would be like a new interface in C#, etc.
  • The question is how do we make the plug-and-play work?  Re-use and portability across tolls, mentioned last time by Peter, becomes possible once the interfaces for plug-and-play exist.
  • Ian felt that presenting one case as preferred alongside a brief summary of a less preferred alternative may not produce good feedback, and wondered if both versions of the Test Manager should be presented side by side.  Brad felt it was better to give one case in detail, outline the other as an alternative and state why.
  • What we need to do is define what we expect to see between the External Controller and the SJTAG Manager, between the External Controller and the Chamber Manager and between the SJTAG Manager and the Chamber Manager.  Brad thought there may be some parallels with the CIM initiatives of the 1980s and wondered if there might be any standardisation that arose from that {to be investigated in "slow time"}.
  • For clarification, Ian noted that he probably was tending to think of the External Controller as literally being physically external to the system under test, but wondered if it really just meant "external to the SJTAG domain".  Brad tended to feel it was more the latter.
  • In summary, Brad's view was of an abstract Test Manager that you could use to plug in any manager interface and a JTAG controller that supported the type of leaf function described by Gunnar and could delegate down to lower levels to provide distributed control.

b. SJTAG Standards Roadmap - continue organising topics.

  • {Not discussed due to lack of time}

6. Key Takeaway for today's meeting

  • None.

7. Glossary terms from this meeting

  • None.

8. Schedule next meeting

  • October 13
  • October schedule: 20, 27. Heiko likely to be absent 20 (this is also the ITC week)

9. Any other business

  • Brad expects to have time after this week to prepare the next Newsletter item.

10. Review new action items

  • None.

11. Adjourn

Peter moved to adjourn at 12:01 PM EDT, seconded by Eric.

Respectfully submitted,
Ian McIntosh