Minutes of Weekly Meeting, 2013-01-28

Meeting called to order: 11:06 AM EST

1. Roll Call

Ian McIntosh
Carl Walker
Harrison Miles
Peter Horwood
Brad Van Treuren
Adam Ley (left 12:00)
Tim Pender (joined 11:11)
Brian Erickson (joined 11:18)

Eric Cormack
Patrick Au

2. Review and approve previous minutes:

1/14/2013 minutes:

  • One correction noted: Add Adam as Excused attendance.
  • Carl moved to approve with the above amendment, seconded by Peter with no objections or abstentions.


  • No corrections were noted, but in the absence of a motion to approve the approval is deferred to the next meeting.

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. Ongoing.
  • Ian: Split the two Use Cases covered today onto a new slide and add annotations. 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

5. Discussion Topics

  1. Newsletter.
    • Ian had not had time to work on anything for the newsletter. Current activities were not well enough developed to report on yet. Brad suggested that the iNEMI activity considering the requirements for instrumentation in support of board level BIST. Harrison agreed that this might be a useful topic. It was important to have access to these features at the board and not just as a silicon foundry tool. Harrison noted that whatever BIST was already in silicon was likely to remain the status quo until around 2020, so the activity was looking at what might come after that. Brad felt that board people perhaps didn't know what questions to ask on this.
    • Harrison agreed to supply Ian and Brad with a summary of the Work Program, {ACTION} and Brad will add some notes to provide an SJTAG angle that can then be used as the basis of an article.
  2. Proposals for SJTAG at ITC or BTW 2013
    • The proxy comment from Eric for last week's meeting was reviewed. The key point that was not addressed during the call was the subject of a hardware demonstration. While Ian felt that could be a better attraction than a conventional presentation, Brad was concerned that 'SJTAG' was not yet well enough defined to know whether even the previous Proof of Concept demonstration really represented what SJTAG was. IJTAG had the same issue and early demonstrations do reflect what is now proposed, however they did help to describe the problem space and in that respect were useful.
    • Ian considered that even if BTW should become the preferred venue, it was worth maintaining a presence at ITC.
  3. The relationship between lifecycle phases and Use Cases.
    • Ian had circulated updated slides by email prior to the meeting.
    • {Slides shared}
    • Slide 6:
    • Brad questioned footnote 2 in respect Fault Injection, noting that there was significant discussion around using Fault Injection to assist with advanced diagnostics and suggested that under Prototyping both notes 2 and 3 should be shown. There were no objections to this amendment.
    • Programming/Updates:
    • While Programming/Updates was a widely applicable Use Case, for Prototyping Ian felt it depended on what was being prototyped. Brad felt that in the ALU labs, if JTAG was used for some level of tests then that would also facilitate Programming. Harrison noted that with over 60% of board designs featuring a processor of some sort, this provided a convenient 'back door'. Ian added that it wasn't just boards with processors; virtually any board with a programmable device of some sort, FPGA, PLD, Flash, would benefit. Brad noted that JTAG was useful to bring a bord back to known good state which could be beneficial during prototyping.
    • Peter wondered how processor based testing or emulation fitted into this, highlighting that there was a difference in the origin of the material: Rather than being written by the test engineer it was provided by the tooling. Ian wondered if the net result was really any different, as the process was similar. Brad picked up on this and noted that contrary to some opinions Updates are not 'just done in the field'; there is not a special tool for it. Ian remarked that 'Programming' and 'Update' are just terms reflecting the perspective of the user and not really different activities.
    • Brad commented that during Developement and Prototyping it was just as important to keep track of software and firmware inventories as during manufacture. Ian though it may even be more important, in order to understand interactions that might emerge.
    • The conclusion was that this row should show '?' across all stages with note stating applicability when programmable devices are present.
    • Root Cause Analysis/Failure Mode Analysis:
    • Brad was curious about the '-' under Development. Ian answered that his view was that this was mainly a Use Case for assessing defects during manufacture or faults arising post manufacture. Brad was suggesting that methods similar to those used to examine field returns could be used to assess design defects. Harrison was tempted to agree with Ian's initial view, noting that during manufacture the objective was to improve yield, so the view is of a hardware nature.
    • Brad realized that we were implying that the purpose of the Use Case at each stage was different. In Manufacturing you assume that the design is good. In System Assembly you may be uncovering marginality issues, while in Development you are looking for issues with the design even though you were applying the same procedure in all cases. Harrison an Ian reaffirmed that there was a different spectrum of faults to focus on at Manufacture compared to Field Service.
    • Ian wondered if this recognition of differences in purpose and expectation had an effect on reuse of tests. Brad agreed that it could in this Use Case.
    • Harrison was inclined to consider this as 'functional modules'. Ian noted that this Use Case was more an aggregated overview of several tests. Brad was reminded of a presentation by Al Crouch on External Memory BIST: There could be a Go/NoGo instrument that had small size for use when you weren't interested in diagnostics if you got a 'Go' that could be easily bundled. But you may need a more complex instrument for diagnostics if you get a 'NoGo', so there was a functionality requirement for each lifecycle stage.
    • Ian will split the table again. {ACTION}

6. Key Takeaway for today's meeting

  1. The objective of a Use Case will vary depending on the Lifecycle stage in which it is applied.
  2. The functionality required of the Use Case will vary depending on the Lifecycle stage in which it is applied.

7. Schedule next meeting

Next Meeting:
February 4.

February schedule:
4 - Patrick will miss.
11 - Ian, Patrick will miss.

8. Any other business

The update to 1149.1 has now passed RevCom approval.

9. Review new action items

  • Harrison: Send summary of iNEMI BIST Work Program to Ian and Brad.
  • Ian: Split the two Use Cases covered today onto a new slide and add annotations as discussed.

10. Adjourn

Tim moved to adjourn at 12:06 PM EST, seconded by Peter.

Respectfully submitted,
Ian McIntosh