Minutes of Weekly Meeting, Unpublished
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
- 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
- [Brad] I'm glad you said "generally"; it's important we leave room for
things like the Intellitech cJTAG for concurrency
- {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)
- [Ian] Buffering and termination rules?
- [Brad] More than that; things like a bent pin leaving a signal undriven.
- [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
- [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
- [Brad] If one assembly uses multidrop, then the whole system should use
multidrop.
- [Ian] What about COTS boards? - Does the choice of architecture influence
your choice of COTS items or do your COTS items influence your architecture?
- [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.
- [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
- [Brad] Yes, it's important to mention that there's some form of addressing
involved.
- [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}
- 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.
- 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