[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2010-02-01

Meeting called to order at 10:38 AM EST

1. Roll Call

Ian McIntosh
Michele Portolan
Carl Walker
Adam Ley
Patrick Au
Brian Erickson
Brad Van Treuren (joined 10:40)

Excused:
Peter Horwood
Eric Cormack
Heiko Ehrenberg

2. Review and approve previous minutes:

01/25/2010 minutes:

  • Draft circulated on 25th January:
  • No corrections noted.
  • Brian moved to approve, seconded by Patrick; 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.
  • Carl: Supply Ian with Host Code for current meeting series. - COMPLETE
  • Ian: Tabulate results for Q3.7 and Q3.8. - COMPLETE

4. Discussion Topics

  1. 2009 Survey - Preliminary review of submissions
    • Q3.7/3.8
    • [Ian] I tabulated the results for these and sent that out. Although there was one more late submission during last week, that person did not answer either of these these questions, so it does not change anything.
    • [Ian] I was expecting that everyone who ticked option h) in 3.8 would also have ticked h) in 3.7, but that's not the case. I think only three people answered both questions similarly, so maybe there was more thought went into the choices that we may have been giving credit for.
    • [Ian] Brad, you thought there might be something we could get from this - have you been able to see anything?
    • [Brad] I haven't really had the opportunity to digest this yet, but I'm sure there's useful information in there.
    • [Ian] OK, we'll leave it there for now, and look at an observation that Michele made and which we started a forum thread for.
      (http://forums.sjtag.org/viewtopic.php?f=32&t=114)
    • [Ian] Michele commented that in these questions there was a very low, almost nonexistent number of people nominating SystemC in either question.
    • [Michele] Yes, I've had a chance to think about that now, and it's probably a matter of tooling support. SystemC is often used for simulation and there is probably nothing available on the tool side at system level that can make use of it.
    • [Brad] I'd agree strongly on that. The uses I've seen here for SystemS are for simulation and for integration with higher level software. There is a lack of a flow from there into the tooling for systems.
    • [Ian] Isn't this a generic problem that we've seen, that there just isn't an adequate interface on tools that you can use to describe systems?
    • [Brad] It may be the other way too. I've talked to EDA people about writing test benches that can be used in preparing JTAG tests for the system. It's a suggestion that's not been well received by the simulation houses.
    • [Ian] Doesn't that go back to issue we encountered last year, where the EDA people didn't seem to be too keen on engaging with anything to do with system JTAG?
    • [Brad] It should be possible to describe an interface that external tooling can use into the EDA simulations. I mean an API defining the interface, not necessarily the code itself.
    • [Brad] It's what I was envisioning when I drew my stack and why I kept a very low layer in there.
    • Q5.6
    • [Brad] This shows that people are interested in a suite of tests, and not ones that are provided externally. After that it's getting into the level of granularity of control. It's also worth noting that this is specifically an embedded test question.
    • Q5.7
    • [Ian] It's clear that access for emulation is seen as important by almost everyone.
    • Q5.8/5.9
    • [Brad] I was surprised by this.
    • [Ian] I can why some people would see instrumentation as more relevant at a board level than at a system level. I think a lot of people still have designs that only require tuning at board level - set and forget types of thing. That may be an opinion that will change over time. They maybe just haven't found a need for it at system level yet.
    • [Brad] Or maybe the "multi-board" wording in the question was making people think about concurrent control. That might explain the difference.
    • [Ian] OK , I can see that. I'm not sure why we added "multi-board" to the text.
    • [Brad] The original White Paper described a system as a multi-board assembly. Anyway, it seems we need to be able to support device level instrumentation at the system level. And you can get concurrency issues at the board level too, when you about MBIST or LBIST blocks.
    • Q5.10
    • [Patrick] JTAG diagnostics to device pin at system level could be very difficult and expensive.
    • [Brad] I think I'd disagree, I think you can get that level of diagnostic quite easily.
    • [Ian] I wonder about the number of people looking for device/pin/net level diagnostics. I always feel that the important thing is to get to a Go/NoGo determination for a FRU. Anything else is a bonus.
    • [Brad] Well we've moved away from that position and want use the data to get started on Failure Mode Analysis and Root Cause Analysis - Identify any trends in the failures.
    • [Brad] There's also warranty matters - our customers are becoming more intelligent and want to have explicit failure information. Also, when boards go back to the service depot, if they are "No Trouble Found" then the field failure information may help to locate the problem. I think Carl will confirm?
    • [Carl] There is some truth in that, yes.
    • [Ian] Maybe we're seeing things go the opposite way. With a move towards support contracts based on availability, our customers are maybe saying "You provide the contracted availability - how you do it is your problem" and so are less interested in the failure details. It then become more for our benefit. It's the difference between what you'd like to do and what you're contracted to do.
    • [Ian] Maybe what we're seeing here is different projects with different criteria.
    • [Brad] And that would help explain the flatness of the responses.
    • Q6.1
    • [Brad] This seems to conflict with Q5.6!
    • [Ian] I noticed that too. Maybe it's mention of SVFs and people feel there's a need to be able to import SVFs developed elsewhere?
    • [Brad] You still need to be able to manage when the SVF is run.
    • [Ian] Or they could be thinking about using SVFs for updates rather than test.
    • [Brad] We'll need to think about this one a bit more.
    • Q6.2
    • [Ian] There seems to be a lot of uncertainty over standardizing the layer interfaces.
    • [Brad] That may help to explain the answers to 6.1.
    • Q6.3
    • [Brad] Again, this conflicts with the responses for 5.6 e). But maybe we're comparing apples with oranges - it's percentages here rather than numbers. If only four or five people answered then it might be explainable.
    • [Ian] Let me check: No, 18 people answered this question.
    • [Brad] Then that is a conflict. We should probably mark ares like this as things we want to define in post-dot0 releases.
    • Q6.4
    • [Ian] This time, the result agrees with 5.6.
    • Q6.5
    • [Ian] I thought this one might give some people problems. It's almost 50:50 between those who think they can support an object oriented architecture and those who are unsure.
    • [Michele] Maybe they are struggling with the resources - It's something they'd like to do but don't know if they have the performance.
    • [Brad] Maybe they're not realizing that it's about the architecture. I've actually read a lot of article recently where they say functional programming is making a comeback, as it's easier to manage the concurrency issues that way than it is through object orientation.
    • Q6.6
    • [Ian] Both RAM and FLASH is a clear high runner here. I know we have many instances where only FLASH may be available, bit the general opinion is different.
    • [Brad] I'm encouraged that we see a hit in every column here. It shows that people are thinking about this running at application level rather than being in the kernel.
    • Q6.7
    • [Ian] Very low numbers on this question.
    • [Patrick] I'm really surprised by these answers.
    • [Ian] Well, it's a "choose one answer", not "mark all that apply". So, basically most people fall into the area of having less than 8MB to play with.
    • [Brad] That puts a real wrinkle into doing updates for large FPGA devices!
    • [Ian] Yes, but the question does say "testing" not "updates".
    • [Brad] OK, for testing, that range is probably reasonable.

  2. How to progress revision of Volume 3
    • [Ian] At some point, we need to resume revising Volume 3. The last thing we discussed was repurposing the volume to be more of a system architecture document rather than specifically hardware.
    • [Ian] I got the feeling that we were really struggling with how to move forward from there, so does anyone have any ideas?
    • [Patrick] When do we need to do this by?
    • [Ian] There's no fixed timescale, but I think that what goes into Volume 3 will have a significant bearing on our PAR. If we don't know what we're doing with architectures then I expect we'll run into trouble when we start trying to work within a PAR.
    • [Brad] I agree, but I'm still struggling with what we discussed on this the last time.
    • [Ian] I wasn't really expecting any answers on this today. I just wanted to start people thinking about it again.

5. Schedule next meeting

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

Patrick will miss 15th.

6. Any other business

None.

7. Review new action items

None.

8. Adjourn

Brian moved to adjourn at 11:33 AM EST, seconded by Brad.

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.