Minutes of Weekly Meeting, 2012-12-03

Meeting called to order: 11:06 AM EST

1. Roll Call

Ian McIntosh
Patrick Au
Carl Walker
Eric Cormack
Adam Ley
Harrison Miles (joined 11:09)
Brad Van Treuren (joined 11:11)
Tim Pender (joined 11:15)

Heiko Ehrenberg
Peter Horwood

2. Review and approve previous minutes:

11/26/2012 minutes:

  • One correction noted: In 5a, change 'restricted one' to 'restricted to one'.
  • Eric moved to approve with the above amendment, seconded by Carl. No
  • objections or abstentions.
  • {Harrison joined}

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
  • Harrison will attempt to come up with a table of use cases and their associated layer and what can be done at that layer. See 5a.
  • Ian - Complete edits to the newsletter and publish by November 30. COMPLETE

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
  • {Brad joined, vote taken on approval of previous minutes}

5. Discussion Topics

  1. Consider 'layers' and dependencies as they relate to Harrison's table and Brad's cube model.
    • Ian relayed a question from Heiko, asking if a diagram or description of the cube model existed. Brad could not recall anything that was shared with the group but thought he would have something on this, while Ian noted that he and Brad had discussed the idea in email some time ago. It was agreed that it would be useful have a description to aid discussion. Brad remarked that this was based on Grady Booch's object oriented strategy and there was a diagram featured in his book.
    • Recapping from last week, Ian noted that we'd recognized that there were dependency trees joining our Use Cases. Ian had hoped to try to make an attempt at diagramming those, but had not found the time. Harrison had made some progress on capturing his thoughts in diagrammatic form.
    • {Slide pack shared}
    • Harrison moved to the Use Case Inheritance Tree slide (slide 5) showing inheritance flowing from Structural Test, and noted that we may want to break up Configuration/Tuning/Instrumentation as had been discussed at the previous meeting and invited comment. Ian thought that Configuration and Instrumentation may well sit between Structural Test and BIST, but was less convinced about Tuning. Harrison explained a typical application of tuning in optimizing the paths between a processor and RAM, particularly as applied to a multicore processor. Ian still felt that he was unable to place Tuning in the tree. Harrison thought that while it could come just before or just after BIST it was mainly required right after Structural Test while Configuration could be just after BIST. Harrison considered Configuration and Tuning as higher primitives.
    • Ian could see that there may different Configuration cases that might apply, perhaps a Configuration that is needed prior to Tuning and then another kind of Configuration that is required prior to POST; our terminology does not address any such distinction.
    • Moving to Structural Test Use Case Level of Knowledge (slide 6) Harrison admitted that he did not really have a language to adequately describe this. The essence was that at this lowest level of test was a hardware confidence test and gave a pass/fail on the connectivity, with no knowledge of what the board was. Brad argued that it was possible to provide more than just a pass/fail indication and that reporting pin and net level diagnostics was quite possible. Harrison agreed but explained that his point was that the UUT had no knowledge of what its intended function was; that only becomes apparent at a higher level. SJTAG was really only showing where to apply other standards.
    • Brad observed that Use Cases may have 'branches' that are 'grafted' on at multiple levels within the tree. Brad also countered Harrison's remark on SJTAG not bringing much other than applying other standards by noting that SJTAG has some of the same hierarchical aspects as P1687 where the subject of retargetting has consumed considerable time, and so there must also be some level of retargetting within SJTAG.
    • Harrison noted a comparison between 3D test and SJTAG, as boards may not be from the same vendor and so, as in 3D test, an elevator protocol would be needed. Ian agreed that the issue of differing chain architectures was a real one, especially when dealing with COTS boards. Brad added that one of the choices may be how do we isolate the board so we can get on with testing the bits we do know about, although the ideal would be to have tests and some sort of API supplied. Harrison considered that an uptake on instrumentation would make that easier to achieve in the future. Ian noted that Selex had been successful in obtaining sufficient design data from one of their COTS suppliers in order to prepare BScan tests, but that was the exception rather than the rule. Brad added that the delegated control architecture that we had been discussing provided for this, in that it becomes a mainly software issue. Once a multidrop is introduced it becomes more blurred on the locality of where the function is taking place.
    • Harrison referred to work by iNEMI on Board Assisted BIST and that table shared between the board and IC people produced an 'Aha! moment', and felt that another such moment would occur between board and software people, although it needs someone to act as a catalyst for that.
    • Ian recapped on the main conclusion, that the elements of Configuration, Tuning and Instrumentation probably all (in the main) sat below BIST in Harrison's chart on slide 5. Harrison agreed but noted that possibly BIST would actually be replaced by Instrumentation, while Configuration and Tuning might be 'super-instruments'.
    • [Proxy addition from Adam Ley]
    • There seems to be some confusion/ imprecision in the use of the terminology. Take slide 5, for instance, where we see
        Built-In-Test (BIST)
      Is this intended to be BIT (Built-in Test) or Built-in Self Test (BIST). If the latter, I note that Built-in Self Test is typically defined, at least in design circles, as a chip-level primitive, intended for structural testing of on-chip circuits (such as logic, memory, etc). If that's what's meant, then it might be said to exist at an even lower level than board structural test ...
    • If a board-level function is intended, then BIT is more commonly used in my experience. And, in that case, I would think that configuration and tuning would be prerequisite (at least if we consider such configuration and tuning (training?) as that which provides for basic input/output functions).

6. Key Takeaway for today's meeting

  1. The idea of an elevator protocol (mirroring that used in 3D test) for SJTAG is anew concept to consider.
  2. The elevator protocol is easier to implement in an architecture with delegated control.

7. Schedule next meeting

Next Meeting:
December 10. Brad and Patrick may miss.

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

8. Any other business

  • Ian reported that the deadline for the recirculated 1149.1 standard has been extended to December 10.

9. Review new action items

  • Harrison - Supply Ian with the presentation material used today for inclusion with the draft minutes.

10. Adjourn

Eric moved to adjourn at 12:01 PM EST, seconded by Tim.

Respectfully submitted,
Ian McIntosh