The System JTAG Working Group

Return to index of Meeting Minutes

Minutes of Weekly Meeting, 2008-06-09

Meeting was called to order at 8:20am EDT

1. Roll Call (Participants):

Brad Van Treuren
Peter Horwood
Carl Nielsen
Ian McIntosh
Carl Walker
Heiko Ehrenberg
Tim Pender (joined 8:33)

Jim Webster said he had a business call during the meeting and would try to attend later.

2. Review and approve minutes

6/4/2008 minutes approved (Ian moved, Heiko second)

Changes to the minutes:

June 23rd instead of June23th in meeting dates.
I: should be [Ian]

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)
Register on new SJTAG web site (http://www.sjtag.org) (All)
All need to check and add any missing Doc's to the site (All)
Respond to Brad and Ian with suggestions for static web site structure
(Brad suggests we model the site after an existing IEEE web site to ease migration of tooling later) (All)
Look at proposed scope and purpose from ITC 2006 presentation and propose scope and purpose for ATCA activity group (All)
Look at use cases and capture alternatives used to perform similar functions to better capture value add for SJTAG (All)
Volunteers needed for Use Case Forum ownership (All)
Continue Fault Injection/Insertion discussion on SJTAG Forum page (All)
Continue Structural Test use case discussion on SJTAG Forum page (All)
We will need to begin writing a white paper for the System JTAG use cases to provide to the ATCA working group (All)
Most likely, champions will own their subject section and draft the section with help from others. This paper will be based on the paper Gunnar Carlsson started in 2005.
All: review how to use the forum
Locate ATCA glossary of board and system states (Adam, Brad)
Continue POST use case discussion on SJTAG Forum page (All)
Adam review ATCA standard document for FRU's states
all send out bullet lists of key topics for the future discussions
all to think about what the hierarchy should look like and what topics should be discussed in the separate documents; submit comments and suggestions prior to next meeting;

4. Discussion Topics

Continue the discussion on document hierarchy for SJTAG

[Brad] Review of where we left off last week. Pointed out Ian�s proposal for hierarchy on web site. Also, pointed out Brad�s response to Ian�s proposal. Jim Webster also posted a comment during the meeting on the forum site.
[Brad] Let�s talk about how we want to proceed. Do we want to have tiger teams for each document or should we have work on one document at a time with section teams?
[Peter] I think we have too small of a group to have all these tiger teams at once.
[Heiko] For some of the topics we don't have enough information to put into a document (languages for example)
[Carl W.] It might be good to have skeletons in place for all the documents that may be discovered or fleshed out as we work things out.
[Ian] I agree with Peter�s comment that we can�t do this with such a small group, but we have to break down the sections to work on them in parallel or it will take far too long to do.
[Hieko] For the use cases as we suggested earlier, our use case champions could begin working on their perspective sections at least.
[Ian] One fundamental question is how physically are we going to create this document- A word document?
[Brad] Carl W. proposed last time to use a word document with tracking of changes in place that is on an ftp site which people obtain when they are assigned the role.
[Ian] I think the first thing is to come up with a document template in place that we can use.
[Brad] I think we can have two people work on the outlines for each document to report back with next week.
[Ian] I�m happy to work on the overview document.
[Brad] I think I should be part of the introduction given that I developed the SJTAG Universe venn diagram and have been introducing this technology locally for years.
[Ian] I would be inclined to have the tool vendors take on the languages document.
[Carl N.] I would be interested in taking on the hardware document.
[Carl W.] I would be interested in the hardware document as well.
[Heiko] I think I could work on the use case document as I am not comfortable with the languages document yet.
[Peter] I don�t mind going with Heiko on the use case document to keep the two person teams consistent.
[Brad] We are then missing two documents.
[Ian] I don�t think it would be that bad to have just these three to flesh out as the start.
PAUSE
[Ian] I will work on getting a space on the web site for these activities.
[Brad] I would like to see everyone comment on Ian�s forum site this week to give what they feel they need for each of these sections in the role their company would use this technology and information for.
[Heiko] I would like to change the order of the documents. I would put the languages and data format after the hardware architecture document. I think we have to give an order to the documents as to how people should go through each document.
[Ian] I did not have any real particular order in place when I threw these things up this morning after being prompted by the minutes. I actually forgot about this task.
[Brad] I think this is what Ian and I have to capture in the introduction document.
[Tim] In the hardware architecture document, are we going to provide some sort of standard for the interface for accessing SJTAG in the system? Are we going to be leveraging other standards regarding how JTAG is implemented?
[Carl W.] I don�t think it is applicable for this format. It might be for some sort of industry standard chassis though.
[Tim] Earlier on in PCI they gave you the interface, but they did not show how to interface each of the slots together so the chains were often broken. From a tool vendor perspective, this would be important.
[Ian] From an OEM tool vendor this would become important as well so that we can implement other boards into our system from other vendors.
[Peter] I think this is more like what the AMC specification does that states it must be a 3.3V interface and what the physical characteristics for each of the signals must be.
[Tim] I think it is also necessary for standardizing a standard header for access to the JTAG because the emulation headers are sometimes so large they don�t apply well elsewhere.
[Ian] I think this is what Jim was talking about as compliance. I think the best we can do with this is give recommendations about the interfaces.
[Tim] Should there be any thought about compliance levels? Should we give these kinds of options so people can state to what level they are compliant.
[Ian] I think we can�t achieve that right now, but I have some idea that there is some level of compliance people can follow that needs to be a case by case analysis to see if it is actually applicable in that situation or not. This is the kind of details that should come out of the hardware architectures document. Certainly, the way I look at it is the hardware architecture is going to define what is possible or not to implement in a system. Without the hardware architecture in place, a particular use case would not be possible.
[Brad] I think this is what the 5th document is all about regarding the marriage between the hardware architectures and what use cases are possible.

5. Schedule next meetings:

Monday, June 16th, 2008, 8:15am EDT
Monday, June 23rd, 2008, 8:15am EDT
Monday, June 30th, 2008, 8:15am EDT

6. Any other business

Group had decided to use openoffice.org tools as the interface for creating the documents since these tools are freely available from the openoffice.org web site, are able to directly produce PDF formats, are able to produce a MS Word format, and support the change tracking features we need. The latest version is 2.4 and all agree we should standardize on this version for our work. [Windows: http://www.openoffice.org/ Mac: www.neooffice.org / Linux: www.openoffice.org or your package distribution mechanism]

Heiko: IEEE has a word template for the draft of the specification, but I regularly use OpenOffice tools for my work.
Brad: I know IEEE has used FrameMaker in the past as the standard interface since I used to help Rod Tullos in writing the original dot 1 standard that he was the editor on. There is much to be said for desktop publishing tools over word processors for many things. This is why I also use Scribus (open source desktop publishing tool) for many of my publication needs. My son even uses it for his school projects and brochures so it is easy to use.
Ian: Many of the people in my company swear by FrameMaker still.

7. Review new action items

Ian and Brad work on the Introduction outline
Carl N. and Carl W. work on the hardware architecture outline
Heiko and Peter work on the use case outline
Look at the formatting issues next week (All)

8. Adjourned at 9:11am EDT

(moved by Peter, second by Carl W.)

I want to thank Heiko for assisting on the note taking today.

Respectfully submitted,
Brad