Minutes of Weekly Meeting, 2015-01-26

Meeting called to order: 11:06 AM EST

1. Roll Call

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

Excused:
Adam Ley

2. Review and approve previous minutes:

01/12/2015:

  • Updated draft circulated 01/15/2015, further addendum 01/17/15.
  • Approval was deferred until agenda item 5a had been discussed.
  • Brad moved to incorporate Al's notes circulated 1/17 into the minutes, seconded by Eric.
  • Eric moved to approve as amended, seconded by Bill. 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.
  • Ian - Put Gunnar's material on the SJTAG website. COMPLETE
    • Add link to the location to last week's minutes. COMPLETE
    • Posted on forums. At Adam's request, Ian also attached the slide pack where Gunnar makes reference to "slide 10" - this was assumed to be from the "Test Managers Proposition" slide pack which Ian presumed Brad had sent to Gunnar as part of the enquiry.

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. Follow-up (if any) on the proxy input from Adam and Al.

  • There had been significant email correspondence since the last meeting and Ian asked if there were any follow-up comments arising from that.
  • Bill had briefly read through the comments and felt that Al was focussing on the chip; 1687, etc., were maybe subordinate to what we were trying to address although they were tools that we need to use.  Although co-ordination of instruments was mentioned, Ian interpreted that as possibly more at the level of instruments within a single device rather crossing chip boundaries, so not crossing over into what might be the SJTAG domain.  Bill thought that writing, say, some sort of sequential tests for an instrument or group of instruments was probably not what was needed for system test.
  • There may be other kinds of instruments we need to use (not just BScan accessible).  Michele had previously questioned whether we might also need to consider external (i.e. not hosted on the UUT) instruments and indeed our EST example includes "instruments" that make up the environmental chamber and need to be co-ordinated with the UUT testing.  Bill noted that even on the UUT there may be a need for more functional or operational tests than would traditionally be required of BScan, although mostly it means loading some registers, toggling and action then reading some more registers.  Ian noted that JTAG was essentially conceived for checking "static" connectivity as a manufacturing test and not for functional types of test although various means existed to offer some support for that.  Brad wondered in that aspect of test was maybe something that should be in a "dot" release of SJTAG and that the initial release should concentrate more on the hardware and infrastructure.  Bill agreed, and suggested that the System level test controller alone could be a good starting point.
  • Brad commented that in the 1687 discussion he found that what constituted the "top level" was rather fuzzily defined.  SJTAG would need to define it in order to work out what to hand off to BSDL or pass through BSDL.  Bill added that 1149, 1687 and 1500 are all tools that can use at a low level. Ian noted that the "top level" was rather dependent of where you looking within the hierarchy as there was delegation possible throughout, although it probably didn't matter too much as the "top" would simply be the top of the current perspective.
  • Ian wondered if maybe SJTAG should be less worried about what data a particular chip needs but more concerned about how to get the data there and back at the right times - are we the "transport" for other tools?  Could, say, a 1687 tool determine what data needs to be applied at a chip edge, and SJTAG works out how to deliver it?  Brad remarked that this would then raise the issue of whether SJTAG is responsible for the dependencies between instruments or if that is something the tool vendor provides?  The answer is probably "it depends".
  • Bill was inclined to think that the types of product he and Brad worked on (and most "networking- type products) were probably quite similar in structure.  Ian felt that it was likely even more general than that, and that even single boards had much in common with large, multi-board systems.  Brad added that issues that once only affected "systems" (e.g. hot-swapping boards) can now apply at board-level (hot-swapping mezzanines), and even down into SoCs , e.g. with different internal power domains.  Clearly, there are considerations that can be applied across all levels.
  • How do you manage connectivity through the layers? Is it just a protocol you have to go through to get to your final destination?  Ian felt this was the current situation with gateways as most tooling simply presents them as "black boxes" and then some magic makes the attached chains work.  In general this probably what the user wants, not to need to know how the addressing and selection works.  Ian noted that the problem with that approach is that not all device features may be accessible and the multidrop bus may not be easy to test since they don't really "exist" as devices in the chain.  Brad felt it may be necessary for a standard to restrict what can be done unless you follow certain procedures. 
  • Brad commented on the work he and Michele had done on NSDL, trying to avoid pre-built solutions but allowing the user to define their own protocols.  Key is abstraction - only define what you need to accomplish the transaction and not get into the nuts and bolts of how it works.
  • Bill knows of some companies that are starting to use 1687, but it's mostly to run BIST engines or reading sensors and suspects it may be a while before there is much emphasis on trying to co-ordinate instruments.  A potential benefit of SJTAG is to offer a means to interoperate a bunch of instruments.
  • Brad mentioned that in Gunnar's STAPL++ work he couldn't run all his LBIST engines together due to the excessive power demand and had provide a means to partition and sequence the tests.  SJTAG could be very useful for this, and managing shared resources (e.g. I2C bus as a shared resource to several temperature sensors).  Ian thought the example was similar to the "ground bounce" problem you can get in a conventional JTAG test caused by the test switching far more outputs simultaneously that would ever happen in the board's normal operation.  You need to know the power parameter information before you create/run the test.

b. Revisit draft PAR statements - continuation.

  • {Not discussed due to lack of time}

6. Key Takeaway for today's meeting

  • Some problems that 10 years ago were system-level only are now appearing at board and chip-level, e.g. power management.
  • Need to distinguish between the control path and the path the data has to travel through.
  • Where does ownership belong for management of dependent instruments and resources?

7. Glossary terms from this meeting

  • None.

8. Schedule next meeting

  • Next meeting February 2.
  • February schedule: 2, 9, 16, 23. Ian will be absent Feb. 23.

9. Any other business

  • The newsletter is due. Brad is making progress.
  • Group officers needs to be addressed.
  • Adam has offered to co-author and present at ITC if someone has material that could be presented but is unable to travel. Bill mentioned to possibility of "invited talks" which have less stringent criteria than a formal paper.

10. Review new action items

  • None.

11. Adjourn

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

Respectfully submitted,
Ian McIntosh