Minutes of Weekly Meeting, 2012-10-22

Meeting called to order: 11:06 AM EDT

1. Roll Call

Ian McIntosh
Carl Walker
Patrick Au
Heiko Ehrenberg
Peter Horwood
Brad Van Treuren
Eric Cormack
Tim Pender (joined 11:09)
Harrison Miles (joined 11:12)

Excused:
Brian Erickson

2. Review and approve previous minutes:

10/15/2012 minutes:

  • No corrections advised to updated draft sent October 16.
  • Brad moved to approve, seconded by Peter. No objections or abstentions.

3. Review old action items

  • Adam proposed we cover the following at the next meeting:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • 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: Contact Bill Eklow regarding use of the ITC mailer to promote an SJTAG Fringe Meeting at ITC. - Ongoing
  • All: 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?
  • It had been proposed to move this into a new section within the minutes where it would remain visible, but was no longer an action. Heiko suggested including a link to a forum thread where discussion of the points could be recorded. Ian proposed creating a new section titled 'Reminders' to appear below the Actions in the minutes.
  • Heiko: Prepare SJTAG poster for ITC and send out a draft for review/comments. See Discussion 5a.
  • 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 Discussion 5b.

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?

5. Discussion Topics

  1. ITC Poster - What do we present this year?
    • Heiko hasn't had much time to work on the poster. He was proposing to show graphics in the four upper boxes and bullet point text in the four lower boxes, however all the graphics were likely to look very similar and he was struggling to find enough bullets for the lower boxes. He would try get a draft circulated shortly and would value any feedback or suggestions from the group.
  2. Can we fulfill all our Use Cases if we consider a single architecture featuring an intelligent controller?
    • {Harrison's table from email of Oct 16 shared}
    • Harrison led the group through his reasoning in completing the columns in the table and concluded by noting that there maybe ought to be another column for 'layers' but that this was a first cut.
    • Ian wondered about the Environmental Stress Test and noted that he felt it was essentially a structural test that repeated while subject to different environments. Much of the value arose from being to complete tests faster than conventional functional testing, giving better observability during, e.g., a temperature ramp, so he questioned if there was any need for the functional aspect in the table. Brad agreed with most of this but pointed out his customers may require proof of system function during environmental test. That differed from Ian's experience and Ian wondered if there was some mixing of design proving with production test in that scenario, and Brad accepted that there may be an element of that, but it could be a valid requirement nonetheless.
    • Ian also repeated a comment he had made previously regarding a distinction he perceived between BIT and BIST; that BIST was essentially a self-hosted chip test while BIT was part of a larger scheme operating at a higher level and often firmware or software driven. Harrison agreed that the view of BIST was commonly that of an IC floorplan test, and that BIST usually has no dependencies. POST, as a form of BIT, was typified by the POST seen on laptops/PCs. Ian expanded on this saying that he recognized PBIT (Power-on BIT), IBIT (Initiated BIT) and CBIT (Continuous BIT). PBIT was analogous to POST and could be the most intrusive of the three, IBIT may be allowed to disrupt system operation but usually only for a very limited time, while CBIT would generally be non-intrusive. Harrison felt that most 'system people' did all of those, but there may be a shift in mindset over BIST as P1687 will expose instruments on the chip that could be used within a higher level BIT.
    • Brad introduced another facet in that since our Use Cases were posted there was an increasing use of instrumented BIST in FPGAs, meaning there could be multiple transient applications as well as the previously discussed multiple BSDL scenario. Harrison commented that much of this seemed to be down to Xilinx and Altera reacting to customer needs. Ian noted that BIST was often implemented in ASICs but seemed to be dropped when people moved to FPGAs as it became costly to keep the BIST matching the more flexible FPGA designs. This may be a return towards embedding BIST.
    • Harrison noted that those people who are just testing boards would not see many of the aspect we are considering. Ian remarked that in his view there was a big difference between the manufacturing test at board level and the test within a system: At board level/CM test you needed to keep the testing at a structural level that allowed diagnosis without specialist domain knowledge of the design. Any functional testing would be partly synthetic as the boards environment would not be exactly as in a system. Once fitted in a system the test could be more functional.
    • {Harrison's chart shared}
    • Ian confessed to not understanding what this represented. Harrison explained that while he was preparing the table he felt that there was a difference in focus between what the application and non-application level uses and these were pulling in different directions. Harrison noted that it was possible to have faults that did not affect function, and cited where navigation units may be fitted to an aircraft, Brad adding that FAA rules were that 2 of 3 should be operational to allow a takeoff.
    • Brad remarked that he had looked up a BTW paper by Bill Eklow (BTW2002, paper 3-1, 'Model Based Automated Debug Process') which described modeling of functional test to map of the defect syndromes to specific hardware faults, and to help identify which tests might be redundant. It provided a bridge between the functional tests and the underlying structure that was being tested. Ian felt that went someway to addressing his earlier concern about domain knowledge at CM test, but felt it was still some way off before we could get a tool to output the kind of necessary data.
    • There was possibly further expansion of the table that could be made, but Harrison would need to give that more consideration.

6. Key Takeaway for today's meeting

  1. How much can SJTAG do in the system without domain knowledge?
  2. There may be a cube perspective for each of the architectures we consider: Facets: Structural Test, Functional Test, Use Cases. Use Harrison's table and see how these map to the architecture.

7. Schedule next meeting

Next Meeting:
October 29 - Eric will miss.

November schedule:
12, 19, 26 (no meeting on Nov. 5 as that is ITC week).

8. Any other business

None.

9. Review new action items

None.

10. Adjourn

Eric moved to adjourn at 12:11 PM EDT, seconded by Heiko.

Respectfully submitted,
Ian McIntosh