The System JTAG Working Group

Return to index of Meeting Minutes

Minutes of Weekly Meeting, 2008-05-28

Meeting was called to order at 8:23am EDT

1. Roll Call (Participants):

Brad Van Treuren
Carl Nielsen
Peter Horwood
Ian McIntosh
Heiko Ehrenberg
Patrick Au
Jim Webster

Proxy feedback submitted by:
Carl Walker

2. Review and approve minutes

5/19/2008 minutes approved (Peter moved, Heiko second)

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

4. Discussion Topics

In light of the number of people discussing the membership and attendance proposals, I feel it is in our best interest to dedicate this meeting to this subject instead of the Root Cause Analysis discussion.

Review proposal for attendance and membership to core group (Brad)

Proposal sent out under separate email (Please review for next meeting)
There are some counter proposals being made, so please have your's ready as well

[Brad] Review of old policy that was sent out at the end of April in email. sent out proposal on 4/29/2008, trying to summarize prior discussion on 4/23; Ian submitted alternate proposal (see also http://forums.sjtag.org/viewtopic.php?t=55); Carl W. also mentioned that there would probably be too much variance to make Brad's proposal work; Jim W. suggested that for certain members (especially self-employed) it is difficult to adhere to a strict meeting schedule due to other business dynamics;
[Ian] Points 1 and 6 were the issues I had, since the attendance policy would affect the frequency of change in the core group membership. Membership would be changing 2 to 3 weeks on average. Attendance on a longer term, every quarter, would work better. My suggestion was to review the membership every quarter with membership being those who attend at least 25% of the meetings during that quarter.
[Patrick] Ian�s proposal is better than the original proposal.
[Ian] Still concerned that an attendance metrics of only 25% could give us a problem with the minutes approval.
[Jim] We need to look at why people are not attending; we need a bigger core than the people that are attending; what is the overall system level strategy, what are we trying to do, and how does it fit into our target audience's business;
[Jim] One way to get people to attend is to have more topics that are interesting each week. We need to have an overall strategy for why we are meeting. I remember the original presentations in Tallinn there was a discussion on languages. All this seems to be gone. How are people going to use these use cases in an overall system test strategy? Is there a road map for what we are doing?
[Brad] We need a clear understanding where we are today to make sure we don't miss important topics, then decide where we want to go from here; use case discussion is the basis for determining what the scope for SJTAG should be.
[Ian] Over the past few weeks we have been trying to address what the requirements are and then baseline what we need to do from them.
[Jim] I still believe that we need a road map now;
[Brad] Before we can finalize a road map and submit an IEEE PAR we need to find out what our scope is and come up with a value proposition;
[Jim] As long as we focus on small topics, without a clear strategy or overall picture, the core group will stay small because people may not be interested in those topics;
[Jim] What there should be is a key concept in place to have a clear way to transport these things. Are we going to recommend how we are going to transport embedded vectors and other things?
[Jim] We need a road map to show where SJTAG is going.
[Patrick] I agree with Jim. We need a road map to indicate when we can submit to IEEE.
[Brad] We need to identify what needs to go into the PAR for IEEE first.
[Brad] In a meeting Ben, Gunnar, and Brad had regarding how to proceed with SJTAG as Ben retired, we all felt the next step was to clarify the uses people have for JTAG in a system already and from there we can look at the architectural commonalities and differences as well as other features that are in common and differ. This is why Gunnar started to write a white paper on SJTAG Use Cases.
[Jim] We have not made recommendations for use of each use case. I don't see the summaries coming together. A list of meeting notes is going to get lost. We need to have a living document that shows how this all fits into it. There should be a document that is added to as topics are finished. We have been discussing topics but there is no final objective that we would put in an IEEE specification.
[Brad] We do not know what SJTAG is going to be limited to. The IEEE PAR and Scope require the problem to be solved to be well defined and scoped to something achievable.
[Ian] What Jim is saying is that we should probably have been doing the document while discussing the topics. One thing that has been concerning me is that the white paper on the web site is a 2 to 3 year old document.
[Jim] I'm not saying use cases should not be done. Maybe we should split each meeting into x time for use cases, y time for administration, and z time to discuss where the use case fits into the overall strategy. If a meeting is split up, there there is more of a reason for people to join the call rather than just take the whole call on one use case.
[Brad] That is a fair point, but if people want to just attend the wrap up, they would need to be on the call to know when the topic is switched.
[Brad] Should we have the white paper updated in real time?
[Ian] Probably. It should be updated when a use case is completed.
[Jim] Then people can see the paper being updated and activity happening in the working group.
[Jim] More than just a white paper about the use cases and the results from each discussion, they need to see how the use case will probably fit into the standard implementation.
[Brad] I tried to have the forum pages to help flesh out the use cases as preparation to the white paper, but additions to the forum pages don't happen. I cannot do the white paper alone. I need people to step up to help do the work. I would like to do more, but I cannot. Writing the paper would take up too much time. To make this work, I need more participation. It is fine to say we need to do the work, but we need participation to make it a reality.
[Heiko/Ian/Peter] Agree.
[Ian] We do need to look at what we can do with the white paper because trying to update it for the PAR at the last minute is going to take a lot of time.
[Jim] To start we could build up a framework of use cases as bullet points to begin to flesh out each section.
[Jim] What we could do rather than have use case champions is to have people as champions of sections of the white paper. Is there a way to do this on the web site?
[Ian] There are ways to do this.
[Jim] The white paper is a large amount of work.
[Brad] Should this be taken out into separate teams?
[Jim] We need to have more types of companies participating � automotive, system test houses, tool suppliers that provide system level tooling.
[Patrick] I am not sure these tool people are interested or understand what SJTAG is really all about for them. Device vendors really don�t have a clear interest in SJTAG.
[Patrick] There is no company that provides embedded test houses.
[Jim] We don�t have anything to sell to other people to bring them on board. I don�t see it growing much beyond the people we already have.
[Jim] We need these people to be able to correctly integrate ATPG tools into this test platform.
[Patrick] This will be very hard until SJTAG becomes a standard.
[...Pause...]
[Patrick] My wish is that SJTAG becomes an IEEE standard. If this is just a talk without any concrete road map/schedule, there is no point in meeting. We need to have objectives with a set timescale to move things forward.
[Brad] We need to start the white paper to capture what we have done so far, then we need to set time lines for the purpose, scope, etc. to lead to submission of the PAR. The issue is that the PAR must be right as it is difficult to change
[Brad] In order to get the IEEE standards process running, you need a PAR. From that, you get the number and are established as an official IEEE working group. For the PAR, you need a clear purpose statement and a clarified scope detailing the limits and boundaries to the problem you are trying to solve.
[Heiko] The PAR needs to be worded carefully as it is the text that appears in the standards document.
[Brad] I have thrown out to the team sample scope documents on various occasions since I have been chairman and have received no feedback. I agree with Gunnar that doing the use cases would get us what we need to begin to specify what we need to be doing and scope the work.
[Brad] Having use cases is a milestone. Let's spend some time identifying the milestones we feel are important to move our work forward.
[Brad] Capture the use cases already demonstrated for SJTAG. Have a road map. What are the milestones you feel are important?
[Ian] Recommendations on architectures. Recommendations on data exchange formats. Recommendations on language formats.
[Heiko] The white paper that comes out of the use cases would be another milestone, with a defined time line (ITC 2008)
[Ian] Is the white paper restricted to the use cases or trying to describe what we are doing overall?
[Brad] I could see this showing up as two separate artifacts.
[Jim] A clear direction. I believe with a road map in place people will come on board. What is the size of the reflector? Maybe develop a questionnaire of people's interest. We should cover the key issues of SJTAG. What people should take away from this meeting is for all to create a list of key issues they feel SJTAG should be dealing with. Give us their bullet points to be able to develop the road map. Next week we can begin to look at defining a road map from these points.
[Ian] I am just concerned there won�t be people participating in developing the points.
[Peter] Brad has talked about trying to get people to respond to the minutes and no one responds with just that short time effort.
[Jim] I am talking about getting people to respond to their key topics.
[Ian] A couple of issues. The forum is up there for people to respond. The problem is getting it out to a wide enough audience.
[Patrick] Personal email to each is important.
[Heiko] Having it on-line is better because we can get our customers to participate.
[Patrick] A personal email with a link pointing to it is important.
[Ian] I can try to begin to work on this. We all can then audit it before release.
[Ian] Would it be better to post the meeting times in advance?
[Jim] Even for the month would be good.
[Carl W. (P)]

Current size of the email reflector is 21 members.
A roadmap would seem to be a good idea; it should assist in the creation of a clearly defined PAR.

5. Schedule next meetings:

Wednesday, June 4, 2008, 8:15am EDT

6. Any other business

[Brad] SJTAG Use Case Paper NOT accepted by ITC; next year we should be in a much better position;
[Brad] IJTAG established tiger team for language definition, starting June 2nd;

7. Review new action items

All: send questions / bullets / key topics for the survey to Brad and Ian (So far only Ian has responded!)
IJTAG: New language tiger team established to look at the language issues while working group deals with the hardware description document draft for the standard. Contact Brad if you want information about how to join this new tiger team.

8. Adjourned at 9:36am EDT

(moved by Ian, second by Patrick)

I want to thank Peter and Heiko for their assistance in writing these minutes. We managed to capture much of the information without much overlap.

Respectfully submitted,
Brad