Minutes of Weekly Meeting, 2010-03-01

Meeting called to order at 10:39 AM EST

1. Roll Call

Eric Cormack
Ian McIntosh
Peter Horwood
Michele Portolan
Tim Pender
Brian Erickson

Excused:
Heiko Ehrenberg
Patrick Au
Carl Walker
Adam Ley

By proxy:
Brad Van Treuren

2. Review and approve previous minutes:

02/22/2010 minutes:

  • Updated draft circulated on 23rd February:
  • No corrections noted.
  • Eric moved to approve, seconded by Michele; 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
  • All: Add to, or comment on, the bullet point list of architecture drivers. - Ongoing.
  • All: Provide forum comment on the graphics used during the meeting; suggest "building blocks" that may be used in future:
    http://forums.sjtag.org/viewtopic.php?f=29&p=257#p257 - Ongoing.
  • Ian: Publish newsletter before end of the month. - COMPLETE

4. Discussion Topics

  1. Review of Survey Results
    • [Ian] We got as far as Q8.3 last week.
    • {Main survey charts shared}
    • Q8.4
    • [Ian] Generally, people are prepared to tolerate up to 10% of their material cost being in support of JTAG.
    • [Eric] Seems that way.
    • [Ian] Having established that, it may have been interesting to know if that meant that 5% was nearer the mark, but that's the information we have.
    • Q8.5
    • [Ian] People are expecting that SJTAG support will contribute less than 10% of their software cost. I guess we need to read this in conjunction with Q8.6 which looks at what they're prepared to accept.
    • Q8.6
    • [Ian] The majority are in the less than 5% bracket here.
    • [Eric] Only one person is saying they'd prefer to control JTAG from off the board; I thought there would have been a lot more like that.
    • [Ian] That's a good point. It maybe suggests that people are much more amenable to adopting embedded solutions.
    • [Tim] I don't know. "Software support" of SJTAG doesn't need to mean using embedded JTAG.
    • [Ian] That's true. I don't think I ever read the question that way. I guess that means we need to be a little more cautious about how we interpret the result.
    • Q8.8
    • [Ian] We have range of responses here, the biggest proportion being for b) System/Field Diagnostics, and none for either e) Software Debugging or f) Fault Injection/Fault Insertion.
    • [Ian] Given the comments, I'm surprised that we don't have any entries for f).
    • [Tim] But those who made the comments likely all chose g) Other.
    • [Eric] The ones that are being chosen are mainly all the field service ones.
    • [Ian] I know we see that as an important area for profit/loss: Turning repairs or updates round quickly, even with permanent service personnel on site.
    • [Tim] Also, if you have to send an engineer out, there's the cost of machine downtime.
    • [Eric] Anyway, they seem to agree with our own thoughts here.
    • Q8.9
    • [Ian] Given Tim's observation on Q8.6, the word "embed" may be ambiguous. Did people really take this as meaning a fully or partly embedded SJTAG solution or simply providing an architecture to support SJTAG?
    • [Ian] Looking at the comments, I feel the first may be coming from the perspective of someone who deals with board level test and hasn't really considered the broader implications at system level. The second comment is understandable, that SJTAG may only be worth using in higher value products.
    • [Ian] However you interpret the question, you can take away that there's a general view that SJTAG is worth using.
    • Q8.10
    • [Ian] A lot of comments here so let's look at those first.
    • [Ian] The first comment is good; they've worked through a rationale and come up with a method that works for their business. It doesn't rely on JTAG, but there's no obligation. They've thought about what they're doing and that's important.
    • [Ian] The second comment is a complaint that tools are driving the processes rather than the other way round. Then a comment on concurrency issues, very much the area that Gunnar spent some time on.
    • [Ian] Next comment is looking for a standard and tools that mesh with it. The last comment is very much in the embedded domain - the need to manage the tests, the results and getting the diagnostics.
    • [Ian] Looking at the table, the high runner, but not by much, is e) 'Understanding how to connect to JTAG at the system level' - this suggests to me that it may be coming down to the lack of knowledge of gateways. Maybe a board test focus again.
    • [Eric] Yes, I think we were drawing that conclusion last week.
    • [Ian] There were indications during our discussion on the questions on gateways, but I'm not sure if the response on b) 'Understanding multidrop addressing protocols' necessarily backs up that opinion.
    • {Peter left the meeting}
    • Q9.1
    • [Ian] Now this is surprising. The vast majority of people claim to have been aware that JTAG had several uses, with only few thinking of it as test only. My experience has been that there are people who only know of it for board programming, and it had been suggested that some others only knew of it in relation to emulation. So this suggests that our target group are better informed than we thought.
    • [Eric] It's maybe a little surprising when you look at some of the previous answers we had though. Even more so when you look at Q9.2!
    • Q9.2
    • [Ian] Well, everyone agrees that JTAG is useful for more than test at the system level!
  2. Volume 3 "hot topics"{Proxy comments from Brad are indicated: [Brad, P]}
    • [Ian] We've looked at Volume 3 a few different ways up to now. Partly on the back of some of the things we're seeing in the survey results, I'd like to collect a list of the big subject ares we'll need to deal with in Volume 3. At this point I'm not looking to go into detail, just list the subjects so that we can remember to address them as we work through Volume 3.
    • [Ian] I'll start things off with a few that come to my mind:
      • Gateways. The issues with tooling, features on gateways, etc. will be something we'll no doubt talk a lot about.
      • Using OEM boards or mezzanines. For some there will be no issue here as everything will be designed in-house. Others will make extensive use of OEM parts.
      • Results storage and retrieval in embedded applications. May or may not be an issue.
      • Design Security. Can you make use of design security features and retain adequate access for test, update etc.?
    • [Eric] Could backplanes fit in there?
    • [Ian] Possibly, we have one box that has 38 plug-ins and we didn't want to put a gateway on each, so we just put 6 gateway devices on the backplane instead.
    • [Tim] You also get the issue of signal loading and integrity.
    • [Ian] True. On large backplane you may need to re-buffer and resynchronise and that can create greater problems for those folks wanting to plug in their Xilinx pods to run ChipScope.
    • [Brad, P] Dynamic backplanes were a real issue with ATCA/MicroTCA and is the reason we specified a JTAG Switch Module that could reside on or adjunct to the backplane to connect up to the plug-in AMC modules. We were constrained in that the AMC modules were small boards with a TAP port at the edge connector that normally mates to a parent board in an ATCA shelf and not to a backplane. For MicroTCA, the AMC mates to a backplane connector. So the backplane needed to look like the parent board from a JTAG perspective. Thus, the control logic had to be external to the UUT.
    • [Ian] OK, I'll leave everyone with an action to think about any other things we need to keep on our "hot topics" list. {ACTION}

5. Schedule next meeting

Schedule for March 2010:
Monday March 8, 2010, 10:30 AM EST
Monday March 15, 2010, 10:30 AM EST
Monday March 22, 2010, 10:30 AM EST
Monday March 29, 2010, 10:30 AM EST

Michele will miss March 8th.

6. Any other business

None.

7. Review new action items

  • All: Consider what may be "hot topics" for Volume 3.

8. Adjourn

Tim moved to adjourn at 11:32 AM EST, seconded by Eric.

Respectfully submitted,
Ian McIntosh