Minutes of Weekly Meeting, 2014-12-01

Meeting called to order: 11:06 AM EST

1. Roll Call

Ian McIntosh
Eric Cormack
Carl Walker
Tim Pender
Heiko Ehrenberg
Brian Erickson
Peter Horwood
Bill Eklow
Michele Portolan (joined 11:09)
Brad Van Treuren (joined 11:21)

Adam Ley

2. Review and approve previous minutes:


  • Draft circulated 11/17/2014.
  • No corrections noted.
  • Eric moved to approve, seconded by Peter. 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.
  • Brad: Contact Gunnar for clarification on the scope of his "system". 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. Test Managers - Determine attributes, behaviours, primitives.

  • The aim was to start trying to brainstorm the features that would typify a Test Manager or and External Controller.
  • {Test Managers slide shared}
  • Probably what we're concerned with is the interface between the External Controller and the Test Manager, rather than the "bottom side" of the Test Manager box.
  • Tim asked where the Connect and Disconnect that was mentioned in Michele's demo would fit in.  Michele replied that the Connect call was probably somewhere in or around the Test Step Controller.  It was really a configuration step and so could present either internally or externally to the Test Manager - it was setting up a condition prior to executing the test step.  There was maybe a need to maintain differentiation between configuration and execution.
  • Ian wondered whether the External Controller acted on the Test Step Controller to perform a single Test Step or a sequence of Test Steps (how much delegation is expected?).
  • Tim was unclear on where the partitions lay.  It may be easier to draw the line if there was more of an understanding of the demarcations.  Brad mentioned the need for collaboration between Test Managers, either peer-to-peer or via the External Controller.
  • Ian suggested that in some cases the roles of the External Controller and the Test Manager may be rolled into one piece of software making it harder to distinguish each.  Brad noted that locality is one aspect but function is separate and need not be based on locality.
  • Brad felt the group was moving towards an OO software model but wasn't sure that was where the group wanted or needed to go.  Ian thought we had established that SJTAG was mainly a software issue - a tools issue - so some sort of software model was probably what was needed.  Brad worried that this approach might be dictating an implementation, even though there may be a need for decomposition in this form.  Michele generally agreed with Brad but didn't feel this was fixing an implementation, it was a means of conveying the requirement.
  • Brad felt we were all doing something similar already in our ad hoc approaches: We may not be aware of it but the External Controllers, Test Step Controllers (or Sequencers), etc., were all there in some form.
  • Bill asked to clarify if we were aiming to create an IEEE standard and suggested that if so then trying to set out a PAR can help to clarify thoughts on what is important.  Brad replied that we had tried that a few times and each attempt seemed to raise new questions.  Bill felt that maybe meant we were delving into it too deep.
  • Brad commented that we seeing it as a software problem because of the need to leverage other existing standards.  Bill believed we could still make SJTAG a hardware standard and push the software aspect off for someone else to deal with; maybe standardise what needs to be in each block, what needs to be in a controller.  Brad wasn't sure that was possible, citing that 1687 invoked ICL and PDL because of the need to provide information that was needed beyond what was in the hardware.
  • To Bill, there seemed to be a hierarchy of resources and consumers of those resources; the issue then was identifying and managing those resources and consumers.  Brad saw there being accesses, linkages and states and some SJTAG uses cases there may be links in states that need managed that are not a concern for manufacturing test.  Bill was inclined to "cheat" and address the manufacturing case, expecting academics to leap on how to extend to other cases. 
  • Ian remarked that we'd long been aware that the scope of SJTAG was too big do deal with as a single standard and needed to be broken down to get to a "core" first, but that had proven difficult to achieve.
  • At this point Brad suggested sharing the diagrams that went with topic 5b. 

b. SJTAG Standards Roadmap - continue organising topics.

  • {Standards Hierarchy shared}
  • Bill noted that this diagram was very similar to what SCC20 was working on, but remarked that it'd need four times the number of people that were currently on the group tackle this.
  • Ian pointed out that this hierarchy was just a "straw man" to talk round, and it still remained to work out what the "core" was to go in the first standard.  It wasn't necessarily intended that these would all be worked on together.
  • Brad drew a parallel with the way the 1149 standards are structured.
  • It was still necessary to get an understanding of what is within SJTAG.  We had the concept of "assemblies" from some time back and there was continuum of levels of assembly that might be considered a "system", from SoC, through boards, shelves, racks, etc.
  • One problem we had identified with regard to multiple boards in a backplane was the typical lack of CAD data that described the interconnection.  Defining data was probably where we dropped out previous look at "assemblies".
  • Bill accepted that there was a hierarchy of systems and a SoC could have similar levels of complexity to a board.

6. Key Takeaway for today's meeting

  • It is worth revisiting our draft PAR to succinctly define our goal.

7. Glossary terms from this meeting

  • None.

8. Schedule next meeting

  • December 8 Brad likely to be absent.
  • December schedule: 8, 15, 22

9. Any other business

  • None.

10. Review new action items

  • None.

11. Adjourn

Eric moved to adjourn at 12:05 PM EST, seconded by Peter.

Respectfully submitted,
Ian McIntosh