Minutes of Weekly Meeting, 2012-02-04

Meeting called to order: 11:05 AM EST

1. Roll Call

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

Excused:
Patrick Au

2. Review and approve previous minutes:

1/21/2013:

  • No corrections noted
  • Brian moved to approve, seconded by Brad. No objections or abstentions.

1/28/2013:

  • Three corrections recorded:
    • The word 'each' was missing from Brad's remark midway through RCA/FMA.
    • The date of next meeting should be 'February 4'.
    • Adjournment was seconded by Peter.
  • Brad moved to approve with the above amendments, seconded by Peter. 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.
  • Harrison: Send summary of iNEMI BIST Work Program to Ian and Brad. COMPLETE
  • Ian: Split the two Use Cases covered today onto a new slide and add annotations as discussed. 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.
    • Brad had drafted an article on the iNEMI BIST project, which Ian had incorporated into the newsletter, adjusting only the links near the end. Ian asked about the relevance on the News items that have been included at the end of the Newsletter. Brad thought these may be more likely to engage readers if they included the key takeaways from the meetings. Ian noted that would need to be a change for the future as he'd need to modify what goes into the XML for RSS feeds as that is where that content is taken from.
    • Heiko had previously noted a concern that there may have been too many main articles in previous newsletters, and wondered how many people looked at the links at the bottom of the newsletter. Ian agreed that people may simply not scroll down the page and suggested that it may be possible to move those into a sidebar alongside the main articles, bringing them more into sight. Ian would try to mock up a layout for use with a future newsletter. {ACTION}
    • Brad observed that many similar newsletters often carried a 'byline', so there was a means to contact the author for further information. The group agreed that providing an email link was unnecessary but that it was quite reasonable to credit the author of any article. Ian will add a byline to the BIST article before publication.
    • Eric moved to approve the newsletter for publication with that amendment, seconded by Brian, no objections.
  2. Website.
    • Ian commented that the website was now restored to full operation, but had found a problem with the old File Manager software that was in use and had now replaced it. Ian demonstrated the use of the tool, and reminded the group that it was only really needed when a file was to be uploaded for sharing.
    • The main points to note are:
      • Login details are as for the previous tool (see forum post http://forums.sjtag.org/viewtopic.php?f=18&t=8);
      • There is no 'Back' link to navigate up through folders - instead the top bar has a 'breadcrumb' trail of links that performs the same function;
      • Several files can now be uploaded together - click the 'Browse' button to add a file to the upload queue, repeat for any other files then click 'Upload';
      • To delete, rename or move a file once it has been uploaded click on the small diamond symbol to the left of the filename to open/close the file operations menu.
  3. Proposals for SJTAG at ITC or BTW 2013
    • No discussion.
  4. The relationship between lifecycle phases and Use Cases.
    • Ian had circulated updated slides by email prior to the meeting.
      {Slides shared}
    • Slide 7:
    • It was agreed this reflected the conclusions from the previous meeting.
       
    • POST:
    • Ian remarked that he was doubtful over the '?' against System Assembly, but Brad noted that it could help identify defects resulting from handling. Harrison felt POST could be very complicated and have different meanings across the stages. Brad observed that it was an architectural issue in terms of what had a reporting mechanism, what was the smallest unit capable of self-diagnosis - generally a board, although Harrison commented that modern silicon was moving that to a much lower level. Ian agreed but wondered what level was actually meaningful for SJTAG: Brad thought that was likely to be the FRU, at least for the purposes of most economics. Ian was inclined to agree adding that testing and diagnostics at board level and below are possibly 'JTAG' rather than 'SJTAG'.
    • With regards to Development, Ian remarked that his experience tended to be that self-test firmware tended to arrive quite late on, so there was little opportunity to use it in Development. Brad agreed but noted that the tests were often available but the automation of a POST was often lacking. This led to the conclusion that for Development the Use Case applicability depended on the maturity of test automation.
    • Across the stages beyond Manufacturing, Brad observed that there needed to be a mechanism to allow the board POSTs to report to higher levels, so Ian questioned if this meant the 'Y' against Field Service and Workshop Repair were incorrect and should be annotated '?' instead. Brad agreed for Field Service, but thought it was different for Workshop Repair since there may be access to test connectors or other diagnostic facilities there that would be less dependent on the architecture to gain access to POST. Brad cited an example from ALU where GNAT had been implemented in a FPGA to provide a pseudo-serial link via JTAG that was only available at board test. Ian also noted that it was common to provide access to 'processor hosts' via a Test Access Connector that may be inaccessible when installed.
    • {Adam left}
    • Brad wondered if there was a stage between System Assembly and Field Service to cover 'System Installation'. Ian was inclined to feel this more in the Field Service area and suggested that maybe the description of the stage on an earlier slide should be amended to include that. Brad agreed.
    • The conclusion here was that System Assembly, Field Service and Workshop Repair should be '?' entries with a note that it was dependent on a supporting architecture. Workshop Repair should have an additional note that the Use Case may be more applicable due to better access to test and diagnostic features.
       
    • 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.
  3. Support for diagnostic reporting of the POST use case must be addressed at the architectural phase of the product development.

7. Schedule next meeting

Next Meeting:
February 11 - Ian, Patrick will miss.

February schedule:
11 - Ian, Patrick will miss.
18
25 - Heiko will miss.

8. Any other business

None.

9. Review new action items

  • Ian: Draft alternate Newsletter layout.
  • Ian: Split the Use Case covered today onto a new slide and add annotations as discussed.

10. Adjourn

Eric moved to adjourn at 12:07 PM EST, seconded by Peter.

Respectfully submitted,
Ian McIntosh