Minutes of Weekly Meeting, 2012-11-26

Meeting called to order: 11:06 AM EST

1. Roll Call

Ian McIntosh Eric Cormack Brian Erickson Peter Horwood (left 11:40) Carl Walker Adam Ley (left 11:55) Harrison Miles (joined 11:07) Brad Van Treuren (joined 11:08) Heiko Ehrenberg (joined 11:08)

2. Review and approve previous minutes:

11/12/2012 minutes:

  • {Harrison, Brad, Heiko joined}}
  • One correction noted: In 4a, change 'Brain' to 'Brian' in one place.
  • Eric moved to approve with the above amendment, seconded by Brian. 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)
  • Harrison will attempt to come up with a table of use cases and their associated layer and what can be done at that layer. 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

  1. Overdue Newsletter - please consider possible topics prior to the meeting.
    • {Draft newsletter shared}}
    • Ian had corrected the typos indicated by Heiko, but otherwise the content was identical to the draft circulated last week. There were no suggestions for further amendments to the existing content. Ian invited suggestions for additional topics, but none were forthcoming as during the past quarter much of the group's work had been data mining that had yet to produce a result worth reporting. Heiko added that the newsletter was already quite long, and that many people may not be inclined to read much of it anyway. This seemed to be a valid point, so the ITC article should be sufficient. Ian also inferred that perhaps future newsletters should also be restricted to one article. Heiko agreed but offered the alternative of a number of single paragraph items with links to larger writeups.
    • For the current newsletter, Ian proposed to leave the ITC article unchanged and to delete the 'placeholder' item. Heiko moved to approve the newsletter with those amendments, seconded by Eric. No objections or abstentions were recorded. {ACTION: Ian to complete agreed edits and issue the newsletter by November 30.}
  2. Consider 'layers' as they relate to Harrison's table and Brad's cube model.
    • {Table from Harrison's slide pack of October 15 shared}}
    • Ian recalled that Harrison had suggested that P1838 might represent the 'SJTAG of silicon.' Harrison elaborated that the issues would be similar. Although P1838 was die centric there would be a plug'n'play aspect as the die in a stack may come from several different vendors with perhaps one die having Wide IO, another die with a straight 1500 interface and yet another implementing Dot7. The assumption may be that the base die would be Dot1 compliant but there would need to be a elevator protocol to accomodate the other die. After that the analogy breaks down as the TSVs (Through Silicon Vias) of P1838 offer potential that is not available to SJTAG.
    • Consider Structural Test as the simplest Use Case, Harrison noted that as you move up through the layers you may or may not discover more information depending on what you actually want out of the test. Brad observed that at this point we had not actually defined what these layers were or what they encompassed; this would be necessary before making any further progress. Harrison was assuming that we were talking about tests conducted at a post-manufacture stage in the product lifecycle. Brad inferred that meant basing the levels on where the vectors were applied and that this could be one of the facets of his cube view. Harrison explained that he was using this as manufacturing tests would normally offer greater flexibility. Ian agreed, noting that test within a system will inevitably impose some constraints on what could be done during test. However, Brad commented that Power On Self-Test could accomplish a lot and could be used to check the health of a board before it is installed in a system, using minimal fixturing.
    • Harrison then observed that there was overlap in the use cases and that inheritance could be applied in that POST inherits from both Structural Test and Configuration/Tuning/Instrumentation, and may also depend on BIST.
    • {Peter left}}
    • Harrison felt Structural test did most with least constraint, then BIST and thirdly Configuration/Tuning/Instrumentation. Brad suggested that we might want to look at this from the point of view of dependencies as it seemed that Harrison was discovering capabilities that were needed before you could apply particular use cases. Brad was also inclined to suggest that C/T/I may come before BIST in the ordering as BIST may be dependant on some aspect of configuration. Harrison admitted to being divided on this point, noting that tuning was largely a manifestation of the system integration. Ian wondered if there may be a case for breaking the C/T/I Use Case up. Brad noted that it was originally grouped this way based on what could be accomplished through 1149.1 at that time and there has been significant progress since. Brad added that there may be additional things that need to be in place for C/T/I such as configuration words in Flash, although Harrison felt that if you got to the point of accessing Flash then the board was probably in pretty good shape as typically a lot of code had to run before you got that far.
    • Ian summarized the we had established:
      There is a dependency tree, from which we can identify dependency levels:
      1. Structural Test
      2. Configuration/Tuning/Instrumentation
      3. BIST
      4. POST
      Other Use Cases may fit in at various levels. Brad suggested that Fault Injection may be similar to BIST while Ian thought Environmental Stress Test may sit at the highest level, reflecting the potential that it might make use of several of the other Use Cases.

6. Key Takeaway for today's meeting

  1. Dependency levels exist within the current Use Cases and offer one facet of the cube view.
    {Adam left}}
  2. Another facet arises from considering use in the product lifecycle.

7. Schedule next meeting

Next Meeting:
December 3.

December schedule:
10, 17, no meeting on 24. Brad is likely to miss the meeting on Dec. 17.

8. Any other business

  • Ian noted that the 1149.1 standard is now out for reballot and is due to close on December 5. As 75% approval had been achieved at the first ballot, comments may now only be made on the changed portions of the standard.

9. Review new action items

  • Ian - Complete edits to the newsletter and publish by November 30.

10. Adjourn

Eric moved to adjourn at 12:00 AM EST, seconded by Heiko.

Respectfully submitted,
Ian McIntosh