Meeting Minutes - 2014-12-08

Minutes of Weekly Meeting, 2014-12-08

Meeting called to order: 11:06 AM EST

1. Roll Call

Ian McIntosh
Eric Cormack
Michele Portolan
Carl Walker
Tim Pender
Bill Eklow
Peter Horwood (joined 11:08)

Excused:
Adam Ley
Brad Van Treuren
Brian Erickson

2. Review and approve previous minutes:

12/01/2014:

  • Draft circulated 12/01/2014.
  • No corrections noted.
  • Eric moved to approve, seconded by Tim. 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".
    • Brad has emailed Gunnar but there is no reply yet. 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. Revisit draft PAR statements.

  • See also:
  • {Scope and Purpose on SJTAG Home page and previous discussion from January shared, for reference}
  • Ian explained that his email was an attempt to reconstruct what drew him to the SJTAG group in the first place as means to try to get to what was "important", although this was possibly just a personal view.  It  leant towards the hardware aspects while Michele's suggestion was very much a view on the software aspects. Peter added that you needed hardware in order to have something you can apply the software to.
  • Bill remarked that "system test" is becoming a hot topic among the 3D and SoC communities along with some academic interest and this may be an opportunity to take advantage of some of those "research" ideas - they could benefit from some architecture considerations and that is somewhere that SJTAG could fit in very well.  Ian conceded that he tended not to follow the chip test developments too closely and Bill highlighted that some of those technologies can and will be applied at board or system level.  There may not be much difference between a SoC and a board.  Michele agreed with Bill's points.
  • Ian explained that he was looking to find what would provide the best "value" for industry that we could deliver in some reasonably short timeframe.
  • Tim found his position to be similar to Ian's: Single access into the system but with a need to isolate chains e.g. for programming, with only the toolset native devices in the chain.  Tim saw a need to concentrate on the "selector": support multiple hosts and multiple chains out.
  • Bill felt that right now we have essentially a single BScan architecture but we need to find how we can have a distributed BScan architecture.  He was starting to investigate concurrent testing, as are some of the chip test people.  Bill didn't think it would be a problem to have the chip people involved as they will have some of the Use Cases for what we're trying to do.
  • Michele noted that he was coming from the opposite side from Ian - not exactly a "chip person", more embedded systems, but he saw the need to understand the chip perspective: The chip is where things are put, the board is where they are used.  Bill saw that what Michele was saying was that the architecture for board/system test should respect the chip level. 
  •  Michele felt that it was necessary to support as many variations of hardware as possible and that can only be done through software.
  • Tim remarked that the "selector" was often a scan linker and there may be a need to not only select a path but also indicate if that is a regular chain or another bus.
  • Bill acknowledged that there is likely to be a lot of complexities in a "real system" that won't be present in a chip - focus on real system testing and concurrent types of testing.  Michele noted that in many cases, any concurrency is only between the instruments within a chip - concurrency is really more of a "control level" feature.
  • Michele felt that 1687 ended up with only the SIB described even though early thoughts were to include much more - these others vanished as it became difficult to describe them within the constraints of ICL and PDL.
  • Bill re-stated his view that there was a set of resources and a set of consumers of those resources and what was needed was a high-level resource manager.  Resources could be a BIST engine or an instrument.
  • Bill asked if there was anything that differentiated "a system" from a similar hierarchy in a chip. Ian felt that there was probably little difference except it may not be defined which boards exist in which slots or how edge pins on one board connect to edge pins on another and he expected that would be better known in a chip, so it was a case of what data you can get and from where.  Bill remarked that in many cases for an SoC you treat each die as a distinct entity and the interconnections are not really considered.  Michele added that for SJTAG you don't really know what data you have or where it comes from - there may be cases where data is difficult to obtain due to IP protection and you just get vectors.  Ian thought that for COTS boards, where you would not expect to be carrying out repairs, vectors for a Go/NoGo test should be adequate.  Michele disagreed and thought you may need to do much more to fully exercise the board's features.  Peter wondered if that might be making use of the board's own BIT firmware.  In any case, it was agreed that at the silicon level it was more likely that the test data would be available as the level of engagement would much greater than for the purchase of a COTS board.
  • Tim wondered if chips would have a Return TCK as synching TCK can create other issues.  No-one was able to answer.
  • Tim also asked if all dice within a chip would have 1687 architectures.  Ian suspected that there may be a variety with 1500 wrappers, 1149.1, 1149.7 and 1687 all being among the possibilities.  Bill commented that it was common for each die to have its own TAP, so there was much the same issue as on a board.  Michele noted that there was a need to test each die before assembly and then to test again after assembly.
  • Bill considered the prospect of maybe grouping a set of components together as a single "resource".
  • There is the issue of hierarchy, what needs to be tested, how are they tested and how are they connected together.
  • There was a question asked whether anyone had applied 1687 to a board design.  It was suspected not although it was perhaps alluded to at one time; Michele's demo hints at this but he acknowledged that it is a software model and not a practical example. Bill wasn't sure how well it would fit in to a board level.
  • There was an opportunity for SJTAG to bring together the different standards.  Ian commented that the Illustrative SJTAG Infrastructure diagram (used on the ITC poster) attempted to show just that, but it was important that it was an open and extensible scheme to allow not just current standards and interfaces but future ones too.

6. Key Takeaway for today's meeting

  • Differentiation of component based test from board/system based testing.
  • There is a need to support concurrency in any (S)JTAG selector.

7. Glossary terms from this meeting

  • None.

8. Schedule next meeting

  • December 15.
  • December schedule: 15, 22
  • Brad is expected to be absent for the remainder of the year.

9. Any other business

  • None.

10. Review new action items

  • None.

11. Adjourn

Eric moved to adjourn at 11:58 AM EST, seconded by Bill.

Respectfully submitted,
Ian McIntosh