Minutes of Weekly Meeting, 2013-02-11

Call to Order: 11:06am EST

1. Roll Call:

Brad Van Treuren
Brian Erickson
Carl Walker
Eric Cormack
Harrison Miles
Heiko Ehrenberg
Adam (left at 11:33am)

Absences:
Ian McIntosh
Patrick Au

2. Review and approve previous minutes:

Approval of February 4 minutes (update sent Feb. 6):

  • Corrections:
    • Heiko: Newsletter discussion; "..., bringing them more into sight." (not "then")
    • Heiko: "dependent" in POST discussion should be "dependent" (twice)
    • Heiko: "Brad wondered if there was a stage ..." ("a" is missing)
  • Brad moves, Eric seconds to approve
  • no objections
  • -> minutes approved with noted corrections

3. Old Actions

  • 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.
  • Harrison: Send summary of iNEMI BIST Work Program to Ian and Brad. COMPLETE
  • Ian: Draft alternate Newsletter layout. Done!
  • Ian: Split the Use Case covered today onto a new slide and add annotations as discussed. Done!

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. Revised Newsletter Layout - Review and recommendations.
    • looks good; nobody voiced concerns or new suggestions
  2. Proposals for SJTAG at ITC or BTW 2013 (if any update available).
    • Ian had no contact with Bill, so probably nothing to discuss here.
  3. The relationship between lifecycle phases and Use Cases.
    • Environmental Stress Test (EST) and Device Versioning (DV)
    • Harrison wondered what the definition of Device Versioning was. Heiko brought up the White Paper section two, section for Device Versioning. Based on that definition Harrison would change the ? for Device Versioning for Field Service to a Y, especially considering the move to 3D devices. Brad agrees and questioned the dash for Environmental Stress Test in both Field Service and Workshop Repair stages. He indicated there are cases where versioning is important to know. Harrison agreed and suggested to change the blocks to Y for the following footnotes:
      1. New IDs are coming out of new FPGA architectures to identify SoC features built into the new devices.
      2. DV is going to be required to know what is configured in 3D designs appearing in SoC implementations
      3. DV is going to be necessary and is increasing in use for NAND Flash devices
      Heiko noted that reading out Flash may be a security concern, as may be access to some of the other system features. Harrison agrees. Heiko asked if that should be a separate use case. Harrison noted that then it should be a wider concept of "assurance", which would include security. Heiko thought that this security issue really applies to all use cases we have talked about, so one could consider it being an integral part rather than a stand-alone use case.
    • Heiko asked about the applicability of Device Versioning for Development. Brad felt that the question mark is fair here. Adam noted that Device Versioning for Prototyping and Development can be necessary when there are different versions or iterations of the same device being used and tried. Similarly, (FPGA) firmware or application ware versions may differ during the development phase. We should change the "-" in prototyping for Device Versioning to a "?" and then add a respective "qualifier" to both "?" for Prototyping and Development stages (for the Device Versioning use case).
    • Heiko asked if Environmental Stress Test should apply to the Prototyping stage. Brad noted that the lines between Prototyping and Development can be blurry. Heiko switched to slide 3 for the definitions of the lifecycle stages. The group agreed that we should leave the "-" for Environmental Stress Test in Prototyping and consider it a Development use case.
    • {Adam left}
    • Brad asked where the role of EST would be placed to support intermittent failure field returns that must undergo EST during the Workshop Repair stage to identify the root cause of the failure in the field. He was wondering if we should put a "?" for EST in the Workshop Repair phase and add a note 'Root Cause Analysis may require EST at this level'. A particular product may be returned multiple times but workshop repair says "no-trouble-found" (NTF). Hence, EST could be a useful tool at Workshop Repair.
    • Harrison pointed out that Field Service is also a form of EST when considering the product is in the failing environment which may be on a pole in sub-zero temperatures. The group discussed the importance of EST on field returns when there are multiple failures in the field of a board and the board tests as NTF during Workshop Repair. Harrison indicated that DV plays a critical role in these cases in that it is able to provide more information than just the art work to correlate the foundry, die, and location on the die where the failing components originated from. He feels that the ECID (electronic chip ID) discussed in IEEE Std 1149.1-2013 is important and useful in this context and it seems Device Versioning would be very important for Environmental Stress Test. Brad noted that he wouldn't say that DV is required for EST. Harrison doesn't suggest that there is an absolute requirement, but rather that there is benefit to be gained from Device Versioning capabilities during Environmental Stress Test.
    • Brad suggests a footnote for Environmental Stress Test in Manufacturing to qualify the "?" (e.g. only sample EST for most board types; but maybe 100% EST for high-reliability board; i.e. applicability depends on type board/system and its target environment).
       
    • We were getting close to the meeting end time; let's review the changed slide next week.

6. Today's Key Takeaways:

  • Design iterations (different device version, firmware, etc.) may be used during development, hence Design Versioning would be very beneficial;
  • Root Cause Analysis may require / benefit from EST at Workshop Repair stage;
  • relationship between Device Versioning and Environmental Stress Test and the benefits of the two working in concert;
  • Device Versioning can improve failure analysis;

7. Schedule next meeting:

- February schedule:
18
25 - Heiko will miss this meeting

8. Any other business

  • 1149.1-2013 is now an approved standard and has gone for publication.

9. Review new action items

  • Ian to update slide #9

10. Adjourn

Brad moves to adjourn, Brian seconds;
Meeting adjourned at 11:59am EST