The System JTAG Working Group

Minutes of Weekly Meeting, 2009-02-02

Meeting called to order at 10:35 EST

1. Roll Call

Ian McIntosh
Tim Pender
Andrew Levy
Adam Ley
Carl Walker
Brad Van Treuren
Heiko Ehrenberg
Harrison Miles

Excused:
Carl Nielsen
Peter Horwood

2. Review and approve previous minutes:

1/19/2009 minutes - Approved with corrections as noted 1/26/2009, moved by Tim, second by Heiko.

1/26/2009 minutes - Approved without comment moved by Adam second by Tim.

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 should have something to report by next week.
• Ian: Draft sample questionnaire by 02/09 - Ongoing
• Ian: Review PAR form for any questions that may require discussion - COMPLETE

4. Discussion Topics

1. White Paper
   • [Ian] Not much has actually happened with respect to these documents. Given we have had a few new people joining our meetings we should try to find out how we can make use of some of these new people in some of these sections.
   • [Ian] Volume 1 is closed for the time being.
   • [Ian] Volume 2 Use cases has a lot of headings and it looks quite good, but there are still a lot of sub headings that need to be populated still.
   • [Heiko] I have not had a chance to work on this at all.
   • [Ian] I don’t think Peter has been able to help either; he said as much last week.
   • [Heiko] That's right.
   • [Ian] I think much of the missing information already exists; it just needs to be pulled together.
   • [Heiko] I think so, it is just a matter of finding the time.
   • [Ian] Volume 3 Hardware Architectures: There have been comments about material being sketched out that is still not part of the document yet.
   • [Carl W.] That is true. I have a lot of thoughts written down on this, but have not been happy with what I have to make it the final form yet. In the next week I don’t have any time - really, I'm over-booked. Carl Nielsen has also been too busy.
   • [Ian] Volume 4 has no real content yet, because we have not actually had anyone assigned to this yet, but we have some outline idea of where it is going. Volume 5 is in a similar state, but I have less of an idea on how this will shape up. I'd thought of bringing in the Use Cases along with some case studies.
   • [Heiko] I wonder if the survey can be used to obtain case studies?
   • [Brad]I feel what needs to be described is to identify what it takes now without system JTAG and what it would take with SJTAG. For example, Tim Pender wrote a very good paper at a BTW on remote updates to FPGAs using JTAG at the system level. He explained the process steps required to perform the update using the traditional method of sending someone out to the field and all the steps that were involved. He also explained the process of updating the FPGA using JTAG to show the overall effort was far less with the use of remote JTAG. This helped him itemize the dollar values for each process step to show how the remote updates was a very cost effective procedure for their product. We need to do the same thing with the rest of the use cases in order to explain the value propositions. We will probably not be able to cast a dollar value to each of the process steps, but people looking at the document can assess their own dollar value if we are detailed enough in capturing the necessary process steps correctly.
   • [Harrison] Is it just a labor rate issue that is the hangup with using SJTAG? I don't believe that can be the case.
   • [Brad] It depends on the product team you talk with. Each of the products I have embedded boundary scan implemented in have chosen this technology for very different reasons. Each product has to weigh the factors according to their own product requirements.
   • [Harrison] So it's more about the engineer's experiences and comfort than the economics.
   • [Brad] Some products can get away with just implementing the JTAG interface as a set of spare GPIO pins off the processor so there is no material cost associated with adding system level JTAG as a feature. For this, they are satisfied with the lower performance as it meets their performance requirements. Others must have better performance and would be required to implement more hardware to get this performance. For them, it might not be cost effective then. It might, however, if the current way of doing things takes more time than is required or the labor involved with sending someone out to the site would far outweigh the added hardware costs. It really depends on the product and their requirements.
   • [Brad] For Volume 5 we need to lay all the cards on the table, so people can decide for themselves why SJTAG would be useful, where they will get benefit, where they will not.
   • [Brad] It's like if in some design you can only get 10% JTAG coverage then you probably won't put in the effort the develop it.
   • [Harrison] Coverage is definitely one thing, performance is another.
   • [Brad] I sent out an email with a link to the HillSide Group for software design patterns. This is a white paper describing how to write a pattern language document. I think there are many similarities between describing a software patterns and the business cases for SJTAG.
   (http://www.hillside.net/patterns/writing/patternwritingpaper.htm)
   • [Ian] That is what I think too. There is no universal answer: Each product development team is going to have to assess what they need and attribute the costs accordingly.
   • [Brad] This is why I say we need to nail down what the process steps are involved in doing the use case with the traditional methods and contrast that with the way you would do it with system JTAG.
   • [Ian] OK, getting back to how we resource the White Paper: I'm inclined to think that Volume 4 will involve myself, Brad, Heiko and Adam?
   • [Brad] Peter may be useful there, too.
   • [Ian] And we seem to have a cry for help from Carl?
   • [Carl W.] Yes, that's pretty much the case.
   • [Ian] Is there anyone who is prepared to help out on Volume 3 here?
   • [Tim] I'd love to, but I'm just too busy right now - maybe 4th Quarter.
   • [Brad] On our first assessment, we felt that was maybe more information than we needed in the document. It had really started to go into normative text rather than White Paper.
   • [Ian] Yes, I do remember that discussion.
   • [Carl W.] I'd need to go back and take another look.
   • [Brad] A lot of the information in diagrams from the original White Paper is included already.
   • [Ian] So maybe it just needs some re-organising and rationalisation?
   • [Andrew] I was willing to help on Volume 5, but I could look at Volume 3 although I'm not really expert in that area.
   • [Brad, Ian] That may actually be better!
   • [Carl W.] OK, we'll set up a call between us on this. {Action}
   • [Ian] Volume 2 shouldn't be too big a job either now. Maybe Eric or Patrick will be able to help.
   • [Ian] Volume 4 is probably the awkward one.
   • [Brad] It is certainly the one with the least understanding in the community and probably involves the most work.
   • [Ian] That why I thought it needed a bigger team.
   • [Brad] I'm not so sure - big teams often don't make progress. I think perhaps Ian and I should produce an outline document first; present a "straw man" to be picked apart.
   • [Ian] So, use Heiko, Adam and Peter as a review committee?
   • [Adam] I am open for that.
   
   
2. PAR Submission Form
   • [Ian] I quickly had a look back over the PAR submission form, just to see if there was anything in there that needed more discussion.
   • [Ian] Most of the things are fairly straightforward, although there are some inconsequential inconsistencies between the form and SA guidance documents.
   • [Ian] We have a choice of lifecycles, either "Full standard" or "Trial Use standard".
   • [Adam] I think the only substantial difference is the lifespan: Two years for Trial Use, as opposed to the normal five years. After the two years, you have to decide either to promote to full standard with no changes, or review comments, change and promote to full standard, or alternatively abandon the standard.
   • [Ian] Yes, that is my understanding, exactly.
   • [Ian] Another question is the Title: Some thing like "Standard for the Application of Boundary Scan Techniques in Multi-Board Systems? Standard for System-Level Boundary Scan?
   • [Andrew] Title should be a concise distillation of the Scope, once you have that agreed.
   • [Ian] We have the scope, but I'm not so sure it helps [read out].
   • [Harrison] Maybe the scope is too broad.
   • [Ian] Well, the problem domain for SJTAG is along a broad front.
   • [Brad] Scoping issues may come out of the survey. I have some thoughts I need to get down electronically so I can send them out. Some systems might be distributed; do we want to touch those or is that an extension for the future?
   • [Brad] For our "dot 1" we want to address 85-90% of the problem space.
   
   
3. Review Use Case Forum discussions
   • [Ian] I'd like to start re-visiting the Use Case discussions, mainly the value propositions; I thought this might help with Volumes 2 and 5. I don't think the forum posts have really captured the value arguments, so we should look at that, but I don't think we've really got the time today make any progress, and there is some Other Business I'd like to address.
   • Deferred.

5. Schedule next meeting

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

6. Any other business

• [Ian] Adam came across the PAR for the work the VXI people are working on which was what had prompted their SJTAG enquiry last year. Adam suggested that we should make contact again to see if they need anything from us.
• [Andrew] I spoke with Charles Greenberg on 13th January, and he seemed unaware of SJTAG. I pointed him at the White Paper and he seemed very interested.
• [Ian] It's odd - LXI is also referenced in the PAR, but when I spoke to the Technical Chair of the LXI Consortium late last year, there was no mention collaboration on VXI.
• [Brad] I've had no further contact after the presentation opportunity we set Dave Bonnett up for fell through.
• [Andrew] I'm happy to re-connect with Charles for you {Action}
• [Ian] Thank you, please do.
   
• [Ian] Do we think we are in a position to offer a paper for ITC this year?
• [Brad] That's a tough question. I thought we were last year, but we were rejected, although they wanted the poster.
• [Brad] If we had Volume 4 of the White Paper, then there would be a good paper opportunity in that.
• [Ian] That is exactly my opinion. March 7th doesn't really give us enough time to develop those language and data thoughts into a paper. So I guess we should aim for a Poster again?
• [Brad] Yes, you've got more time and the requirements are different.
• [Ian] OK, that really just confirms what I was thinking.

7. Review new action items

• Carl W./Andrew: Set up conference call to organise review of Volume 3.
• Andrew: Make contact with VXI Consortium/Charles Greenberg.
• Ian/Brad: Draft "straw man" Volume 4 for review.

8. Adjourn

Moved to adjourn at 11:32am EST by Brad, seconded by Tim.

Many thanks to Brad for additional notes.

Respectfully submitted,
Ian McIntosh