[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-09-14

Meeting called to order at 10:38 AM EDT

1. Roll Call

Carl Walker
Eric Cormack
Ian McIntosh
Heiko Ehrenberg
Peter Horwood
Brian Erickson
Brad Van Treuren
Patrick Au (joined 10:40)

Excused:
Tim Pender

2. Review and approve previous minutes:

8/31/2009 minutes:

  • Draft circulated on 31st August:
  • No corrections were noted.
  • Eric moved to approve, seconded by Heiko. 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?
  • Establish whether TRST needs to be addressed as requirements in the ATCA specification if it is not going to be managed globally (All)
  • Adam review ATCA standard document for FRU's states
  • All to consider what data items are missing from Data Elements diagram
  • 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/Brad: Draft "straw man" Volume 4 for review - Ongoing
  • All: Review "Role of Languages" in White Paper Volume 4 - Ongoing
  • Harrison: Virtual system exploiting Configuration/Tuning/Instrumentation and Root Cause Analysis/Failure Mode Analysis Use Cases. - Ongoing
  • Brad: Virtual system exploiting POST and BIST Use Cases. - Ongoing.
  • Ian: Virtual system exploiting Environmental Stress Test Use Cases. - Ongoing
  • All: Test at least part of the draft survey form and provide comments through forums. - Ongoing.
    http://www.sjtag.org/survey/forms/form1.html
    http://forums.sjtag.org/viewtopic.php?f=32&t=83.
  • Ian: Send out Newsletter within the next few days. - COMPLETE
  • Brad/Brian/Ian: Produce clarification of the intended meaning and scope of the word "configuration" in the Device Versioning use case. - See discussion 4a

4. Discussion Topics

  1. White Paper Review - Continuation on Device Versioning
    • [Ian] We had trouble defining "Configuration" last time, so we took this to the forums. We had some suggestions for wording but Brad questioned whether the scope was too great for a simple statement to cover.
    • [Brad] Yes, that's pretty much where my comments were heading.
    • [Ian] One thing in particular I picked up on was your observation that the Use Case was originally conceived to collect the IDCODEs of devices. That did seem to fit better with the use case title, while our current view has much more depth. Should we be narrowing our scope?
    • [Brad] I was thinking about that; maybe splitting this into several use cases, but I don't know if we want to do that.
    • [Ian] I felt that we have applications within our scope that we probably don't want to lose. I did wonder though, could we use some of the layer descriptions in Brad's forum post to build up the Application Fields section. That way we might avoid having to define "configuration" at all.
    • [Brad] That might be a way to go. What do others think?
    • [Patrick] It's a difficult question to answer.
    • [Brian] It seems like a reasonable course. It helps get at the layers of the hierarchy.
    • [Brad] That's what I tried to do in the first part of my post; to peel off the layers. The use case has concepts, rather than implementations, that can be used at all levels.
    • [Brad] We can get more value for the use case by using those concepts at the higher layers. With things like P1687 coming along we can leverage those. It may mean more requirements.
    • [Brian] It will hopefully mean more opportunities.
    • [Brad] And mean more value added for including JTAG in the system.
    • [Brad] We will need to explain this in some detail. Not all of our readers will be knowledgable on this one.
    • [Ian] Yes, although this maybe isn't the most technically complex use case, I felt it may one of the most difficult ones for people to get the grips with.
    • [Brad] This use case can become more important when you have heatsinks; you may not be able to read part numbers.
    • [Ian] Indeed, many of our modules comprise a pair of boards on a coldwall with all the main devices on the inside against the coldwall, so you can see almost none of the components to visually identify them.
    • [Ian] Do we agree to take the development of the Application Fields text offline?
    • {Agreed} {ACTION}
       
    • [Ian] I tried to get a bit of a head start on updating the other sections of this use case. I left the old text in, so I didn't lose anything.
    • [Ian] Does anybody have any comment on Alternative Techniques?
    • {wiki edited}
    • [Brad] On the documentation methods we should also note that physical inspection may not always be possible because markings may be obscured.
    • [Ian] Anything else?
    • [Brad] In the past I've seen an "inventory PROM" used, but that's not very common. It does, of course, add extra cost.
    • [Ian] And additional parts can also be detrimental to reliability.
    • [Ian] One of the things I've found with our CMs is that they always want to load boards with preprogrammed parts and that could end up with a PROM that has little relevance to what's fitted.
    • [Patrick] We would do that programming online.
    • [Eric] They're not usually that big anyway.
    • [Patrick] Flash is different; they can be many megabytes, so they will be programmed offline.

  2. 2009 Survey
    • [Ian] We need to move on to the survey now. Heiko made some suggestions for references; I'll come back to that. For question 6.9 there's a grammar correction: We can either have "What do you feel is important..." or "Which do you feel are important...".
    • [Brad] I lean towards "What do you feel is important...".
    • [Ian] OK, that's we'll make it. The next suggestion is to add an "Other" option to the question.
    • [Brad] I always feel that these kinds of question benefit from allowing the user to enter an "other" kind of response.
    • [Ian] OK.
    • [Ian] I sent out a draft of an invitation email. As a result of discussion on that we came up with the idea of a "landing page" where can point to references, etc., before going to the survey itself.
    • [Eric] Won't that add to the 20 minutes for the survey?
    • [Ian] The length of time it takes is going to depend on the questions the user decides to answer. So part of the point of the landing page was to give people a chance to understand how long it might really take and to prepare themselves.
    • [Eric] Good idea.
    • [Ian] One of the things we point out, at Brad's suggestion, is that it's a single page form. So the scroll bar acts as a kind of progress marker. One criticism of the iNEMI survey was that you went through pages without any sign of how much more was to come. Sometimes questions seemed to repeat similar themes.
    • [Brad] And you can't always remember how you answered the previous question.
    • [Carl] That's a problem with all multi-page forms.
    • {The group agreed that having all questions on one page is beneficial compared to other surveys}
    • [Ian] We list the White Paper and the Glossary on the landing page. I'm not sure we want to mention anything else as I'm keen not to prejudice the responses we get.
    • [Eric] I don't know how you do that. Even the White Paper could influence people.
    • [Ian] I agree it could.
    • [Heiko] We ask if people have read the White Paper in one question.
    • [Ian] Yes, so people might go there anyway, and some people will be following us through the website. They may have formed their own opinion already and that's fine. I don't want the survey itself to influence people. We can't do that 100 per cent, but we have been careful about how we phrased questions. We've tried to maintain the integrity as far as possible, but we can only go so far. In the end, getting a volume of responses will help accuracy.
    • [Ian] I'll email a link to the landing page, should anyone want to comment on it.

5. Schedule next meeting

Schedule for September 2009:
Monday September 21, 2009, 10:30 AM EDT
Monday September 28, 2009, 10:30 AM EDT

Patrick may be absent for 9/28

6. Any other business

None.

7. Review new action items

8. Adjourn

Brad moved to adjourn at 11:38 AM EDT, seconded by Eric.

Thanks to Heiko for taking additional notes this week.

Respectfully submitted,
Ian McIntosh

Copyright 2007-2009 The SJTAG Working Group
The SJTAG Initiative is "work-in-progress" and the views and opinions expressed here are subject to change without prior notice.