Minutes of Weekly Meeting, 2014-01-13

Meeting called to order: 11:05 AM EST

1. Roll Call

Carl Walker
Ian McIntosh
Peter Horwood
Michele Portolan
Brian Erickson
Heiko Ehrenberg (joined 11:08)
Brad Van Treuren (joined 11:13)
Eric Cormack (joined 11:15)

Adam Ley
Patrick Au

2. Review and approve previous minutes:


  • Draft circulated 12/16/2013.
  • No corrections advised.
  • Brian moved to approve seconded by Michele with no objections or abstentions.


  • Updated draft circulated 01/08/2014.
  • No further corrections advised.
  • Carl moved to approve seconded by Heiko with 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. Moving forward:
- How has Scope and Purpose changed? See http://www.sjtag.org/ home page.
      - Continue with 'Purpose'.
- Can we outline a hierarchy/structure of SJTAG standards? See Heiko's additional notes from BTW in the previous minutes, Brad's email of 12/09 and Ian's email of 12/31.

  • {"Mission, Scope and Purpose" from website home page shared.}
  • SCOPE:
  • Ian recognised that there have probably been several points raised that the group will need to come back to address in more detail, but was there anything further we wanted to note on "Scope" before moving on?  The IEEE Design and Test article that Brad had mentioned in the last meeting was obviously one thing that might need discussion in the future.  Ian hadn't been able to fully read the article yet but surmised that the main point was that conventional retargeting as proposed for P1687 was inadequate and too computationally intensive to be evaluated at run-time, especially for embedded platforms. Ian felt that what this might be bringing into the discussion was getting data to the right place in the chain.  Pre-calculated vectors were OK for go/nogo test but became a problem when the result had a value, more so when the value was used to determine subsequent actions within the test.
  • Brad commented that P1687 calls up a scan network rather than a "global chain".  The real insight in recent weeks has been that P1687 user are mainly using PDL-0 rather than PDL-1 where flow control resides.  Michele added that the main issue is that when go down to the vector level you move away from the "functional" aspects and lose sight of the system behaviours.
  • Brad felt that what we were recognising was that instead of managing the data we needed to manage the access links, and the access links may take different forms at different stages of the test.  We may not be able to understand what they are until run time.
  • Ian thought this was coming back to the idea of co-ordination between devices.  The vector level representation might work well enough for a single instrument but we were considering multiple instruments, multiple devices, perhaps across chains and boards.  Michele noted that staying at the vector level made co-ordination much more difficult.
  • We were concluding that relying on only 1149.1 was going to be impossible but that it remained a perfectly viable protocol for data package transmission.  Brad compared to telephone systems where you establish a point-to-point connection and VOIP where routing is established by the shortest/quickest path.  
  • Ian wondered if providing "an extension of the IEEE 1149.1 standard" was really what we were now discussing.  Brad felt that was a good question, and noted that P1687 appeared to be adopting an update that expanded it scope beyond 1149.1.  SJTAG could be centred around the 1149.1 TAP but must provide for other interfaces: We were providing the allowance of using 1149.1.
  • Peter felt this followed on his comment from the previous meeting that you have a vector you want to send, but don't care about how it gets there.  You might care about what the response is and what format it should be in. Brad agreed that there is some "virtual technology" that provides the routing path - what we'd previously described as a "cloud", but Brad was trying to avoid possible confusion with other uses of the term "cloud".  Data gets sent through that routing.  This is very similar to how TCP or UDP exploit the OSI stack.  However, Brad considered that "format" was probably an application concern.
  • Ian had concerns with the analogy to networking as in that domain some of the routing work was laid off to dedicated hardware or firmware in the network interface card, and we probably wanted to avoid imposing additional hardware requirements.  Were we perhaps introducing another computationally intensive demand?  Brad saw it as more a software level where e.g. TCP/IP ports are handled at the access link level. 
  • While it was clear that we needed to be unbound from reliance on 1149.1, Ian was worried about disenfranchising some groups that may look at 1149.1 as a familiar reference point. Brad felt that as an end user, he'd want to be able to make use of whatever was present on his board, so he didn't think engineering end users would have a problem.  Tools vendors might feel slightly more alienated but Brad thought that most were broadening their scope out already and looked for confirmation from those on the call.  Heiko and Brian both agreed that this was the case. 
  • Brad announced that he had an action from the iNEMI meeting to provide a few slides that showed how SJTAG related to the current BA-BIST activity.

6. Key Takeaway for today's meeting

  • The "Purpose" needs to be expanded to be more than just 1149.1, but have an allowance of 1149.1.
  • We need to define the inputs and outputs of "the cloud" (the scan path selection) without worrying about what is inside the cloud.
  • We are looking at this like a network - it is a routing problem more than a data management problem.

7. Schedule next meeting

  • Next Meeting: January 20.  Carl will be absent.
  • January schedule: 
    20, 27

8. Any other business

  • The presentation Eric had previously been asked to provide does not look to be happening in the near future.
  • There is a webinar in March for the iNEMI BA-BIST activity - this is probably where the slides Brad referenced will be used.
  • The Newsletter is due at the end of January.  Brad thought it may be a way to introduce the concepts that will be in the BA-BIST slides.

9. Review new action items

  • None.

10. Adjourn

Eric moved to adjourn at 11:57 AM EST, seconded by Peter.

Respectfully submitted,
Ian McIntosh