[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-09-28

Meeting called to order at 10:35 AM EDT

1. Roll Call

Ian McIntosh
Adam Ley
Eric Cormack
Carl Walker
Brian Erickson
Tim Pender
Brad Van Treuren (joined 10:38)

Excused:
Patrick Au

2. Review and approve previous minutes

9/21/2009 minutes:

  • Draft circulated on 21st September:
  • No corrections noted.
  • Brian moved to approve, seconded by Brad. 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. - CANCELLED.
  • Brad/Brian/Ian: Develop "Application Fields" descriptions for Device Versioning on the forums (http://forums.sjtag.org/viewtopic.php?f=14&t=52). - COMPLETE, See discussion 4a

4. Discussion Topics

  1. White Paper Review - Continuation on Device Versioning
    • [Ian] From the action that we had carried from last week, I tried to consolidate the earlier forum posts into some proposed text for the Application Fields part of Device Versioning. I think Brad generally agreed with that text, so I've posted it onto the wiki for review, next to the old text.
    • {New text read out for the benefit of dial-in attendees}
    • [Ian] Is there any comment on this text?
    • [Brian] It sounds like a pretty comprehensive statement.
    • [Ian] Is there anything from the old text we're missing.
    • [Brad] The last point points towards using a Config. PROM, but we've covered indirect access in our new text.
    • [Ian] So we can delete the old words?
    • [Brad] I'd suggest we can.
    • {Wiki edited}
    • [Ian] I drafted some new text for Value Proposition {read out}.
    • [Brad] You can add conformal coating or your heatpipes making it hard to verify boards manually.
    • [Brad] And in the field, you might avoid having to send someone out to check a board version, and it's nonintrusive, so you don't have to take the board offline while you check.
    • [Tim] You can find out what is really on the board, not just what the label on a device says.
    • {Wiki edited}
    • [Ian] The new text we have for Consequences is just a rewording of the old text {read out}.
    • [Ian] I'm not sure that the comment about needing a standard method of access for reading indirect data.
    • [Brad] It may be something you'd want. It does help, but it's not essential.
    • [Ian] So we can note it something that would be beneficial?
    • [Brad] Yes, and this would be a good place to bring in Heiko's point about the IDCODES and chain topology not being enough to define the board, but I'm not sure where to add it.
    • [Ian] Doesn't the first sentence already cover it?
    • [Brad] I'm not really picking that up.
    • [Ian] OK, I think we can add it as a lead-in then.
    • {Wiki edited}
    • [Ian] That finishes Device Versioning. There are a few sections that we missed, mainly because we added the Consequences heading part way through this review. I'll let people have look over those gaps in their own time and we can try to fill them next week.

  2. 2009 Survey
    • [Ian] There's not much changed on the survey - I had hoped to spend some time at the end of last week adding some pop-up help, but it just didn't happen.
    • [Ian] Section 1 is fairly self-explanatory, and I don't think it needs any extra help.
    • [Ian] Section 2 is the White Paper "test" to see who's actually read it.
    • [Brad] Yes, we used those questions in 2006, to see who'd done their homework before taking the survey. They're really Ben's.
    • [Ian] This was where Heiko was suggesting we should give a link to the White Paper, but we're really handling that on the Survey Landing Page now.
    • [Ian] What I have noticed from the website logs is that there are still a lot of download requests for the old v0.4 White Paper, which is a bit worrying. I'm not sure if it's just some web "harvesters" or real people downloading copies.
    • [Brad] It might be interesting to see if there's a demographic of universities taking it.
    • [Ian] I keep all the logs. I can trace the requests; it shouldn't be too hard.
    • [Tim] Is the Wiki version downloadable? That may be part of the reason.
    • [Ian] The plan was to use the wiki to collaborate on editing the document, then convert it into a downloadable document. You can view and print the wiki pages, but can't really save them very easily.
    • [Ian] Volume 1 is finished and Volume 2 is almost there, so I guess we could go ahead and make the "print" versions of those. Or is it better to wait until we have the full set?
    • [Eric] I think you publish as you go.
    • [Brad] It depends on whether you aim to have one document or retain the five sections.
    • [Ian] The worst thing about publishing the existing sections is that as we write up the later parts we may find things we want to change in the earlier parts. Those should be relatively small scale though. It may be worth doing so people find the new documents as "current" on the White Paper web page.
    • {Web page displayed}
    • [Ian] Ah! Of course this list the v0.4 as the latest "published" version, so that might be why people are still taking it: The wiki is just a "work in progress". Maybe I should revise the page to present the wiki in a more positive way?
    • [Brad] I think that would be a good idea.
    • [Brad] You should maybe give links to each section instead of just to the wiki. Then you can mark Volume 1 and 2 as "stable" like they do with open source.
    • [Ian] Good idea, I'll do that. {ACTION}
    • [Ian] For now, I think I'll just reiterate that everyone should make some effort to check out the survey form and in particular think about where the user might need help interpreting the questions or answer options. {ACTION}

5. Schedule next meeting

Schedule for October 2009:
Monday October 5, 2009, 10:30 AM EDT
Monday October 12, 2009, 10:30 AM EDT
Monday October 19, 2009, 10:30 AM EDT
Monday October 26, 2009, 10:30 AM EDT (2:30 PM GMT)

Eric will be absent for a two week period mid to late October

{Ian demonstrated how to log in to the SJTAG Google Calendar and some its features, notably the Timezone display for meeting events}

6. Any other business

  • [Ian] I sent out a draft "Roadmap" for the rest of the year, just to give everyone an idea of where the next few meetings are going and where that's all leading.
  • [Ian] Basically we need finish off what we're doing on the Use Cases and move on to Volume 3 of the White Paper (Hardware). I've idea how long that'll take, so what's on the chart is just a shot in the dark.
  • [Ian] At the same time, we need to get the survey rolled out. I've scheduled that as being open for eight weeks. In practice, the last survey had activity for the first two weeks then again for about a week when I sent out a reminder. Maybe eight weeks is too long, but you do get stragglers who find their way there via the website.
  • [Ian] We then need to spend a little time to look at the results. Hopefully, that will give us a steer on reviewing our Scope and Purpose and possibly our position with respect to a PAR. Are there any comments on this?
  • [Eric] That roadmap seems fine.
  • [Ian] I really just wanted to have some kind of outline, through to the year end.
  • [Carl] A quarter seems like the right sort of period for this.

7. Review new action items

8. Adjourn

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

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.