Minutes of Weekly Meeting, 2014-12-15

Meeting called to order: 11:03 AM EST

1. Roll Call

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

By email proxy:
Adam Ley

Excused:
Brad Van Treuren

2. Review and approve previous minutes:

12/08/2014:

  • Draft circulated 12/08/2014.
  • Change "There may not be much difference a SoC and a board" to "There may not be much difference between a SoC and a board.".
  • Eric moved to approve as amended, 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 - continuation.

  • Ian's aspiration for this topic was to home in on some wording for an initial PAR, but that probably meant trying to resolve what the essence of SJTAG was.  Further to last week's discussion, Ian remembered that during preparation of the ITC poster Adam had commented that the three bullets added to the poster might, in a broad sense, form the basis of a statement of the scope and purpose of SJTAG.
  • {Poster shared}
  • Ian invited any thoughts on this or last week's discussion.
  • It was Peter's opinion that in the case of stacked die, etc., it was unlikely that a single TAP would appear on the package. Instead each die would present its own TAP making it no different from using discrete parts.  This probably reflected Bill's remark at the previous meeting.  Tim thought it might be more common to see an internal selector, perhaps requiring a selection command.  Peter felt this was only possible if all die were from the same vendor else the selection mechanisms might be incompatible.
  • Ian wondered how much we needed to worry about what went on inside the device: Perhaps SJTAG's role was to get data to and from the device edge and that the actual data being carried was less important so long as it did not interfere with the selection mechanisms in the board and that the board did not interfere with the data.  Peter was inclined to agree.
  • Tim commented on the need to provide IO for compliance pins used to operate internal muxes on some devices.  Eric noted that there was ongoing activity within 3D on controlling IO used to go up and down the stack, covering both serial and parallel access (1149.1 and 1500).
  • Adam, by proxy:
    • One thing to note for 3D ICs in relation to the comments by Peter and by Eric:
    • Indeed, P1838 is looking at standardizing TAP selection mechanisms that would permit the base die to provide the board-level TAP interface as well as to direct access to upper die, which in turn can also direct access to die above …
    • Consider that in a 3D IC, if each die is to have its own TAP at the board level, then there must be open space allowed on each lower die through which to drop the TSVs. On the other hand, if die TAPs are to be chained in the fashion typical of boards, then not only must there be allowance for the dropping TSVs, but there also has to be a top-level interposer to provide the chain hook up …
    • Ref http://grouper.ieee.org/groups/3Dtest/ for more info.
    • These Slides which comprise the working group status report as of October 22, 2014 (at ITC'14 in Seattle, Washington) may be of greatest interest/relevance.
    • Note, of course, there are other methods that might be employed on 3D ICs such as selection by system Gateway (a la ASP, JTS, ScanBridge, etc) or within 1149.7 star topologies …
  • Heiko liked the goals stated on the poster as they implied a hierarchy that we could apply to our standards development.  One reservation was that it might not be possible to take the first bullet on its own:  The first two bullets may need to be taken together in addressing the hardware.
  • Bill suggested that it may be helped by adding sub-bullets as BSCan access at system level can be a little different and the applications can be a lot different.  Ian commented that there may be two views of test within a system: a) where the intent is to verify a single board and b) where the intent is verify the integration of multiple boards within the system. Each has different levels of "constraint" and data needs compared to a board test outside of a system.  Bill added that the application of instruments (not just IJTAG instruments) needs a fair amount of co-ordination across the system.  Ian assumed Bill was inferring automation through tooling:  Existing tooling typically didn't do this so it ended up being something that the test designer "manages".  Bill agreed and suggested that was something that could still be accounted for within a standard.
  • Ian felt this was touching on some of the early Use Case discussions and shared the Use Case diagram.
  • {Diagram shared - this is the Use Case diagram on the SJTAG brochure: http://files.sjtag.org/Publications/SJTAG_Flyer_US_v1.20.pdf}
  • Bill felt that maybe not all the possibilities were shown; for instance Built-in Self Test could be used by more user types than shown.  Ian agreed but remarked that the diagram could easily become very cluttered.  Bill thought there could be even more Use Cases which would make it even more cluttered, so perhaps it could be partitioned out some way to make it clearer.  It would be possible to either create a separate diagram for each "actor" (user type) or for each Use Case, but that might lose some of the oversight of the "big picture" and similarities between cases might be lost.
  • Ian was reminded that in a previous discussion it was identified that there were other problems with this diagram: Some Use Cases overlapped and others actually made use of other Use Cases, so some described "primitives" while others described "applications" {post meeting note: this is what spawned our investigation of Templates in mid-2013}.
  • Bill started considering what heading might be worth going into - validation, production test, field test.  Power on tests might be less useful as there's often not enough time for BScan there.  Ian was OK with that in an off-line test mode but agreed that "time to readiness" was often a key factor for normal operation.
  • Tim commented that they didn't necessarily want a field service engineer to be carrying around $5000 BScan test controller.  Ian felt that might depend on perspective and what level of diagnosis was required and described the typical repair strategy for Mil/Aero - Diagnose to LRU at first line, diagnose to SRU/Sub-SRU at workshop level, boards returned to factory for component diagnosis and repair.  Don't expect component level repair at first line.
  • Bill suggested that we needed to work out what applications were relevant to each user.
  • Bill noted that he felt there may be opportunities to promote awareness and attract interest in SJTAG by preparing some sort of tutorial or practical presentation at ITC.  There is something of a push to get more system items included.  Michele is writing up a paper on his IJTAG engine for that he hopes to get accepted for ITC and felt it would be good if there were some "official" supporting material from SJTAG to go alongside his personal work.  Bill admitted that ITC didn't have a strong program in 2014 with respect to System and Board Test, but hoped that there may be more in 2015 as people pick up on the release of 1687.

6. Key Takeaway for today's meeting

  • The Use Case diagram could be improved.
    • Layers for each "actor" or use a selection matrix.

7. Glossary terms from this meeting

  • None.

8. Schedule next meeting

  • Insufficient attendance expected for December 22 and 29.
  • Next meeting January 5, 2015.

9. Any other business

  • Officers need to be reappointed early next year.

10. Review new action items

  • None.

11. Adjourn

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

Respectfully submitted,
Ian McIntosh