Minutes of Weekly Meeting, 2009-11-23

Meeting called to order at 10:39 AM EST

1. Roll Call

Carl Walker
Brian Erickson
Eric Cormack
Ian McIntosh
Heiko Ehrenberg
Brad Van Treuren
Adam Ley
Michele Portolan (joined 11:03)

Excused:
Tim Pender
Patrick Au
Peter Horwood

2. Review and approve previous minutes:

11/09/2009 minutes:

  • Updated draft circulated on 12th November:
  • No corrections noted.
  • Eric moved to approve, seconded by Carl; no objections or abstentions.

11/16/2009 minutes:

  • Updated draft circulated on 18th November:
  • No corrections noted.
  • Eric moved to approve, seconded by Carl; 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
  • All: Review 'straw man' virtual systems and notes on forums:
    http://forums.sjtag.org/viewtopic.php?f=29&t=109. - Ongoing
  • Brad: Provide citation for paper on distributed systems. - COMPLETE
  • Ian: Create sanitised survey results page and post link on private forums. - COMPLETE

4. Discussion Topics

    1. White Paper Review - Review of Virtual Systems
      • [Ian] Last time we discussed two methods we wanted to try: Setting up headings similar to those we did for Volume 2, and then decomposing some existing systems to see what architectural features they used.
      • {Wiki shared}
      • [Ian] If we look at some of the headings we have here, section 4 seems to have some kind of structure, but 5 onwards look like they could be grouped in a similar kind of way.
      • [Brad] Ian, one of the things I struggled with in the original White Paper and here is that it's very implementation or solution specific. We're presenting solutions without first showing what it is that needs those solutions. I'd be looking for something more generic, higher-level.
      • [Brad] What is it we really need from hardware for system level access? We need some sort of introduction that explains that SJTAG needs to be designed into the system and these are the issues you need to solve in order to support SJTAG.
      • [Ian] OK, so let's brainstorm a bullet list of what issues need to be addressed.
      • [Brad] That will be beneficial. If we enumerate issues then it may help to address the 'requirements' that Adam referred to.
      • - Multiple assemblies in a system - For externally controlled system, all chains should generally be brought out to a single TAP
    2. [Brad] I'm glad you said "generally"; it's important we leave room for things like the Intellitech cJTAG for concurrency
    3. {Michele joined}
      • Means to isolate assembly under test from other signals on the backplane
      • Coexistence of embedded control with option for external control
      • Signals going off-board must not be floating (DFT rules)
    4. [Ian] Buffering and termination rules?
    5. [Brad] More than that; things like a bent pin leaving a signal undriven.
    6. [Ian] OK, unterminated TRST causing a board to go into test mode on power up.
      • Fanout may be large, especially across large backplanes
      • Individual control of tests in a FRU
      • Signal integrity of 5-wire TAP when taken external to a system
    7. [Ian] Can't really use long cables, so may want to run JTAG over some other bus or medium.
      • Uniformity of interface - don't mix multidrop and star
    8. [Brad] If one assembly uses multidrop, then the whole system should use multidrop.
    9. [Ian] What about COTS boards? - Does the choice of architecture influence your choice of COTS items or do your COTS items influence your architecture?
    10. [Brad] It depends! If you use mainly COTS then your architecture should probably match those parts, otherwise you may just provide an adaption for the COTS items. COTS is becoming more modular: In the ATCA type of systems there are a few baseboards around but a whole lot of mezzanines.
    11. [Ian] Slightly different for us: We use a few COTS processor boards from Curtiss-Wright or GE-Fanuc which have mezzanine slots we rarely use. But from what I've seen they generally have some kind of ASP-like gateway.
      • Means to address assemblies: "Slot code", hardwired by board type or a mixture of the two
    12. [Brad] Yes, it's important to mention that there's some form of addressing involved.
    13. [Ian] I'll add this list as a forum post on the SJTAG website and everyone can then add to it as they think of additional issues. {ACTION}

 

  1. 2009 Survey
    • [Ian] Not too many responses yet, but I hope that a reminder will trigger a burst of responses before we close the survey.
  2. Newsletter
    • (This topic was discussed first)
    • [Ian] I sent out a draft Newsletter over the weekend. I know it's still early morning for some of you, so I don't know if you've had time to look at it yet. It's a 'straw man' so changes are welcome.
    • [Brad] I'm just reading it now. I think the wording you have on the White Paper is just right.
    • [Ian] I felt we ought to comment on our absence from ITC, and the other obvious thing to mention was the survey.
    • [Brad] Is the mailing list for the newsletter the same as foe the survey invitations?
    • [Ian] Mailing list for the survey is similar to mailing list for newsletter, but not exactly the same - some people did not show interest in followup survey; some people indicated interest in taking the survey but not in receiving the newsletter.
    • [Brad] You may want to add a comment that if people haven't received an invitation that they can contact us to be added.
    • [Ian] There's actually a link to the survey below the article, so I guess we just tell people to follow that link.
    • [Brad] That's good. Then people who may have changed their mind can still participate.
    • [Ian] This isn't due out until the end of the month so we'll leave this open for any more ideas, and we can deal with approval next week.

5. Schedule next meeting

Schedule for November 2009:
Monday November 30, 2009, 10:30 AM EST

Schedule for December 2009:
Monday December 7, 2009, 10:30 AM EST
Monday December 14, 2009, 10:30 AM EST
  • Eric won't make Dec 7 or 14
  • Ian, Carl, Brad will possibly miss Dec 21
  • Agreement that there will be no meeting on Dec 21 as holiday plans will impact likely attendance.

6. Any other business

  • [Ian] There are a couple of things that Brad had passed on to me in recent weeks that we probably should mention. One was a note from the TTSC on IEEE policy on copyright that I think originated out of a P1687 discussion. The other was an article on developing standards that highlighted the need for simplicity. That's possibly very relevant as we potentially have a complex scope here.
  • [Brad] At least we need to take a 'learning approach', to give people a simple understanding first then let them grow into the greater depth.
  • [Ian] On the copyright issue, I was originally concerned to make sure that our policy kept in line with the direction given by the TTSC: This was the first time I'd seen it written down.
  • [Brad] It was the first time I'd seen it written, so that's why I thought you'd be interested.
  • [Ian] Yes. The key message was that copyright in material submitted to a working group, remained with the originator of the material. The copyright in the standard itself lies with IEEE. I reviewed our statement on copyright and that's pretty much what we already say, so I don't think we're out of line.
  • [Brad] That's what I thought.
  • [Ian] Maybe the only extra thing we've added is a comment on reuse of elements within our own group material, but we're clear that the copyright lies with the creator.

7. Review new action items

  • Ian: Post bullet points (architecture drivers) from today's discussion on forum.
  • All: Add to, or comment on, the bullet point list of architecture drivers.

8. Adjourn

Brad moved to adjourn at 11:31 AM EST, seconded by Eric.

Thanks to Heiko for providing additional notes.

Respectfully submitted,
Ian McIntosh