[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-02-09

Meeting called to order at 10:35 EST

1. Roll Call

Ian McIntosh
Tim Pender
Patrick Au
Eric Cormack
Carl Walker
Adam Ley
Brad Van Treuren
Carl Nielsen
Peter Horwood
Harrison Miles

Excused:
Andrew Levy
Anthony Sparks
Heiko Ehrenberg

2. Review and approve previous minutes:

2/2/2009 minutes -

  • [Ian] I should add the link to the hillside.net pattern writing article that Brad referenced.
Approved with above amendment, moved by Brad, second by Patrick.

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
  • Patrick contact Cadence for EDA support person.
  • 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)
  • Adam: (continue) revise wording of section 5 - Ongoing
    • [Adam] I've only managed to drop in some little comments so far.
  • Ian: Draft sample questionnaire by 02/09 - COMPLETE
  • Carl W./Andrew: Set up conference call to organise review of Vol. 3 - Ongoing
    • [Ian] Andrew has passed this task on to Harrison now.
    • [Carl W] I didn't set anything up, last week was just too busy. This week should be OK, though.
  • Andrew: Make contact with VXI Consortium/Charles Greenberg. - Ongoing
    • [Harrison] I don't know if that has happened yet. I can follow up.
  • Ian/Brad: Draft "straw man" Volume 4 for review - Ongoing
    • [Ian] Brad managed to put together some sections of the draft.

4. Discussion Topics

  1. White Paper
    • [Ian] Again, there hasn't been much movement on the White Paper sections, other than Brad's contribution for Volume 4 and some minor edits.
    • [Ian] I copied Brad's text onto the wiki as he was experiencing some problems with the website. I made a few minor corrections, but otherwise haven't contributed anything worthwhile.
    • [Brad] This still needs some fleshing out.
    • [Ian] I struggled to find time to read this properly over the weekend, but I think that "Role of Languages" is pretty much ready for review?
    • [Brad] Yes I think so. The discussion on static versus dynamic elements is proving difficult to express in a way that could go into the wiki.
    • [Ian] And the Implementation Issues section is a collection of items drawn from elsewhere, I guess, so currently needs some re-wording to put it in third person?
    • [Brad] That's right.
    • [Tim] In that last section there's mention of Plug'n'Play Boundary Scan - Wouldn't it be nice, if we could take a board from a vendor, build it into a system and access the board's chains to test out ribbon cables, etc, to the rest of our UUT?
    • [Ian] This is where we talked about abstracing from the physical hardware detail some weeks back. What you really need to know is how you can exercise the board's boundary to achieve these tests.
    • [Brad] I had a paper back in 2005 which presented our concept of Boundary Scan Plug'n'Play. The vectors are stored on the board in JTAG compatible PROMs, fairly small size. It's a form of future proofing, because you don't need to re-write your software when you introduce a new board, you just pull the tests from the PROMs. It makes sure that the tests and the data are right for that board.
    • [Ian] Is that the sort of thing you had in mind Tim.
    • [Tim] Yes, it is.

  2. Survey
    • [Ian] As promised, I put together a fairly basic outline of a survey form just to get things started. Brad also sent out a list of ten or eleven more probing questions which made my initial efforts look a bit inadequate!
    • [Brad's connection was dropped for a few minutes at this point]
    • [Ian] I'd like to run through what we have so far with these and see if anything is prompted. Brad also suggested that some of the questions from his original survey (launched at ITC 2006) may be re-usable.
    • [Brad re-joined]
    • [Ian] Some of you won't be familiar with Brad's survey - this was aimed at those people who had expressed an interest in joining or continuing as members of the SJTAG group. Given that couple of years has elapsed since that survey, I can see how a number of the questions may have new relevance.
    • [Brad] Yes I was surprised at some of the outcomes from that survey.
    • [Brad] There are lots of ways you could consider distribution. One thing we're looking at is extending JTAG from a backplane to a remote site.
    • [Harrison] More people will be wanting to do things like this, but maybe in the backgound. The original phone network achieved a form of BIT using a maintenance channel at very low rate.
    • [Brad] The flip-side is system integration. There are lots of protocols that will do system-to-system checks at speed.
    • [Harrison] We need to consider what types of problem SJTAG could address: Some may genuinely be real-time, some will be quasi-time, maybe if you need to know something is happening but you don't need to do anything right now.
    • [Brad] And we need to look at waht we're doing today, what we might be doing in the future. If we can deal with SERDES links on boards, is there any reason why we couldn't extend that to the edges between systems?
    • [Harrison] You should also talk to the people who own the network management.
    • [Brad] I guess many of those folks won't be aware of SJTAG.
    • [Ian] I think lack of awareness is more general issue - I've several times heard surprise that JTAG isn't "just for boards".
    • [Harrison] You probably want to send this survey to whole new cadre of people, like Google and Yahoo. For example. Google will either strongly specify what goes into their network or they'll design a closed system. This is a differnt approach to many of the network element guys who think very traditionally.
    • [Brad] Yeah, and I guess with the advent of Android they might want to be aware of what could be done with SJTAG.
    • [Harrison] These companies want the network, without the pain of the large staffing that usually goes with it.
    • [Ian] How de we make this accessible to them?
    • [Harrison] It'll need some re-wording. JTAG will be alien, but they'll recognise the context behind a number of the questions.
    • [Harrison] Other possible targets are HBO, Time Warner, ComCast: All people who were "internet ready" before most others, and are looking to solve their problems on the cheap.
    • [Ian] OK, but how do we get to them? I don't have contacts in the engineering groups of any of these firms.
    • [Harrison] May be able to get something through CableLabs?
      [Ian] Brad in your last question, one of the things you give as an option for things that may be important fo SJATG to cover is "Centralized repository of tests for the system" - I'd be inclined to add "Common access to distributed repositories", and I'd want my test results stored on the FRUs, so the fault history travels with the FRU if it is sent for service/repair.
    • [Brad] That tells me you've thought about the issue; some would say "we'll just put a hard disk in the system and store everything there". There are probably lots more that could added.
    • [Brad] Also, where do you get test data from? This gauages how well people understand the data management. How do you get access to the test or data if the unit is at a customer site behind a firewall?
    • [Brad] Boeing have some significant views on test and there are some interesting papers coming out of there. And there are other questions: Should SJTAG be an integral part of BIT or a deferred test?
    • [Harrison] It could be a little bit of both. To understand the whole picture you need to get many different perspectives.
    • [Brad] There are some types of systems that can probe to find similar items that it could link up with, as well as operating locally.
    • [Harrison] SETI@home is basically such an application. I'd expected things to have developed in the space sector first; long range probes with a need for a self-healing capability.
    • [Harrison] JTAG is present in most high-end cell phones, even though it isn't brought out to the edge for whatever reason.
    • [Brad] We need to look at the bigger picture to determine the ultimate scope for the use of SJTAG. But first we need some primitive building blocks.
    • [Harrison] You need to reach out into areas like aerospace, broadband service providers. Nokia produce small form factor equipment with compute power comparable to desktop machines.
    • [Brad] There are protocols that are being buil into things like WiMax. You might have some intelligence in the base stations rather than in the cell phone.
    • [Harrison] That works OK until the density goes up and the base station load becomes excessive.
    • [Brad] And the issue of bandwidth utilisation that goes with that.
    • [Harrison] I see this survey being in two passes: The first is level setting; how SJTAG fits in, while the second is determining which Use Cases are appropriate.

5. Schedule next meeting

Monday Feb 16, 2009, 10:30am EST (Partick cannot attend)
Monday Feb 23, 2009, 10:30am EST

6. Any other business

  • [Ian] I had an e-mail from Rohit asking if there was interest in standardizing test for "low power structures". This is an IC Test area that isn't of great interest to me personally.
  • [Patrick] I might be interested - can you forward me the details?
  • [Ian] I'll pass on all I was sent, but it's not much. There may be more if you indicate an interest.

7. Review new action items

  • All: Review "Role of Languages" in White Paper Volume 4.
  • All: Consider structure/content of survey.

8. Adjourn

Moved to adjourn at 11:44am EST by Brad, seconded by Peter.

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.