[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-08-24

Meeting called to order at 10:36 AM EDT

1. Roll Call

Brian Erickson
Eric Cormack
Ian McIntosh
Patrick Au
Carl Walker
Brad Van Treuren

Excused:
Heiko Ehrenberg

2. Review and approve previous minutes:

8/10/2009 minutes:

  • Draft circulated on 10th August:
  • There were insufficient participants in attendance to vote on approval of these minutes.

8/17/2009 minutes:

  • Updated draft circulated on 18th August:
  • No further corrections were noted.
  • Brad 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
  • 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.
  • All: think about topics for upcoming SJTAG newsletter. - Ongoing

4. Discussion Topics

  1. White Paper Review - Continuation on Device Versioning
    • [Ian] We need to look at Device Versioning again, as it still needs work.
    • [Ian] The first thing I wonder is whether people will understand what we mean here: The title refers to 'Device', but much of the text is about boards. I don't think the introductory paragraph says anything helpful.
    • [Brad] You're right.
    • [Ian] Do we have better outline?
    • [Brad] I'm looking at some of our in-house slides. We start off with a 'Problem Statement' that this is for recognising/verifying the devices on a board, and follow that with a "Test Solution" of using JTAG to query device IDs and registers.
    • [Carl] It may be the case that boards may have the same firmware loaded but be of differing hardware standards, so you may need some means of identifying the hardware version other than by the devices and firmware.
    • [Brad] In most cases, changes to the firmware or the board art will bump the board revision, but using alternate, equivalent parts wouldn't.
    • [Carl] The board version may dictate which devices are used to some extent.
    • [Brad] I mentioned before the case where we had devices that were apparently functionally identical, except for one extra feature that we used on the old device, that went unnoticed. We then had to find where all the new devices had been used and apply a firmware change to account for the difference.
    • [Ian] We had a similar case where a dual digital potentiometer was replaced by a part that looked equivalent. It turned out that the old part had a "cascade mode" that combined both potentiometers into one with a greater range. The new part didn't have that mode. It could still be used but needed different software.
    • [Carl] We had exactly the same thing come up in Cisco, recently.
    • [Ian] I think what I'm getting here is that the primary thing we want to do is to get the manufacturer and device identification from the devices on the boards. Reading back firmware versions or board standards is more of a secondary issue, although the current wiki text concentrates more on those latter aspects.
    • [Brad] Some gateways also have user registers that could be used here.
    • [Brad] Maybe we should be talking about the configuration of the boards in the system. It's the same techniques as Root Cause Analysis, using register access or SAMPLE but to get at static information instead.
    • [Brian] I agree with the concept, but using the term 'configuration' may get people confused.
    • [Brad] Yes, which is why I was hesitant to use it!
    • [Brian] Do we really mean we're interested in the board or the chain or the system? We have a very broad scope here.
    • [Brian] I guess you want to look at the population of boards in a system, then drill down into the population of the boards themselves.
    • [Brad] In some cases there are additional methods for getting at the information. In ATCA, for example, the Board Management Controller registers with the Shelf Management Controller. None of this uses BScan, but BScan may be able to use those features. Generally, in such cases BScan may be used as an alternative strategy.
    • [Brad] No-one is ready to use 1149.1 as a Test and Maintenance bus due to the low throughput.
    • [Brian] It would be possible to query hardwired board IDs using JTAG.
    • [Brad] That may not help too much when it comes to hot swapping or plug and play: JTAG doesn't lend itself to that on it's own.
    • [Brad] From my days working on aircraft we swapped out radars with the power off. Ian, I guess in your domain, on things like AWACS you may need to swap systems over live?
    • [Ian] I can't think of any specific scenarios right now, but the whole aircraft system should be tolerant of an avionics module being switched off and back on inflight. I wouldn't say it was 'normal' but it is something 'anticipated', and it should be fairly 'version agnostic'.
    • [Brad] In mine and Carl's business, it's possible that we may swap in a replacement system with different characteristics; more channels or support for a new standard.
    • [Carl] That's correct.
    • [Brad] Revision is also part of versioning. Most times you get a 'key' back that you can then look up to get at the details.
    • [Ian] The JTAG return vector isn't exactly human readable, you need something to compare against.
    • [Brad] Some of the early ASP users put a board type as well as a slot code into the ASP address, so different board types had different addresses even though they may use the same physical slot. I wasn't real keen on this, but it seemed to work for those guys.
    • [Ian] OK, can we come up with some new text for the introductory paragraph?
    • {Paragraph was revised live online, along with Application Fields}

  2. 2009 Survey
    • [Ian] I updated the survey form, but we hadn't really discussed the form of the answers in most cases, so I just took a guess at it. It really needs reviewed though as I did it quite quickly.
    • [Brad] I see a couple of questions that look a bit open-ended. I think we'll need to tighten those up. I'll review and get back to you, Ian. {ACTION}

  3. Summer Newsletter
    • [Ian] I really haven't had time to think about the newsletter this week. I haven't had any suggestions either, so I think I need to set time aside this week to draft something up for approval next week. {ACTION}

5. Schedule next meeting

  • [Ian] Next Monday is a Bank Holiday in England.
  • [Eric] I'm still OK for next week.
  • [Patrick] I will miss 31st, but should be OK for September 7th.
  • [Ian] Well, 7th will be Labor Day in the US, so I think that may give us a problem. Our schedule for September would run 7, 14, 21 and 28, but I think we'll have to skip the 7th.
  • [Brad] Yeah, that works for me.
  • {Agreement}
Schedule for August 2009:
Monday August 31, 2009, 10:30 AM EDT

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

Expected absences: Peter and Patrick 31st August.

6. Any other business

None.

7. Review new action items

  • Ian: Prepare draft of Newsletter for approval at next meeting.
  • Brad: Review survey updates and provide feedback to Ian.

8. Adjourn

Eric moved to adjourn at 11:31 AM EDT, seconded by Patrick.

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.