The System JTAG Working Group

Return to index of Meeting Minutes

Minutes of Weekly Meeting, 2008-06-04

Meeting was called to order at 8:23am EDT (meeting has been recorded and transcribed from the recording below)

1. Roll Call (Participants):

Brad Van Treuren
Ian McIntosh
Patrick Au
Carl Walker
Heiko Ehrenberg

2. Review and approve minutes

5/28/2008 minutes approved (Ian moved, Patrick 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
All: send questions / bullets / key topics for the survey to Brad and Ian (So far only Ian, Carl N. and Heiko have responded!)

4. Discussion Topics

Survey:

[Brad] What I wanted to do to start out with this discussion is to have Ian talk a little bit about the survey demos Ian posted on the web site and try to answer any question people might have on that to give you a feel of what we are need from you for the bullet items and the key points to be able to help us and to direct the motivation for the users.
I know Ian and I have been corresponding on this and we�d like to be able to get a respondent group that is bigger than the what we had in the original survey I had with my survey I gave when I first became chairman. I like the idea Heiko had said that he would like to get some of his customers to use the survey. If we can broaden this respondent list out to more than just, as Ian put it the converts, I think it would be really beneficial for us. Ian, I will turn the meeting over to you to give us the overview on this.
[Ian] Thanks, Brad. I don�t know if there is an awful lot really to consider presuming everyone has been able to look at the form and most people that were on the call last week actually filled in one just to try it out. I didn�t want to go too far with this initially because I knew we were going to change it and there is a fair bit of work in changing the form. So really what I did was to just put something up simply as a demo to just try it out and get some feedback and see how we really want to go forward with this. I just to put a few things in here just to show the kind of things we can put in here with drop down lists and check boxes sort of thing. There we a couple of good suggestions about adding something so people could select what type of industry sectors they were representing or perhaps getting a bit more specific detail on people's understanding related to individual use cases. That particular question perhaps needs quite a bit of descriptive text, you mentioned that Heiko. One of the things we could do is perhaps pop up boxes to give explanation of the questions so the form itself stays reasonably compact. One of the things I�d be very conscious about is that the form starts to grow in size and my view of seeing these kinds of forms is to not bother to fill them in unless they are quite easy to fill in. I think a lot of people feel the same way.
There is also a result page which gives you an on-screen view of the results. I can export the information in CSV files and things like that so we can do a more thorough analysis on what we get back.
There are two ways I think we can go, we can have a very short simple form and ask a few very pointed questions or we can have a more extensive one that tries to get a lot more information out of people that might be users of SJTAG, either now or in the future. I don�t know. Maybe there is an option there for a simple form and people can fill out a more comprehensive one later on.
[Brad] I�m leaning towards that. Let�s have a filter with the simple form and come out with a more detailed form for people who are really serious later.
[Ian]I think that would be reasonable sensible, because we can get a simple form out quite quickly, but to put together a more complex comprehensive form it is going to take me time to do that. I have already spent a couple of weeks. There is only a limited amount of time I can spend on these things.
[Patrick] I don�t think we need a complex complicated form and it will put off the guy trying to receive the email anyway. There are a couple of comments I would like to add. One is that section that talks about where do you from, you know I work for IBM and I don�t find the item of Computers. And the other comment, when I looked at your form yesterday, I started filling in and towards the end I had to start typing in the bits and pieces, that totally put me off and I would fill it in at a different time. I would prefer to have less typing and just clicking the particular questions. It would be a lot easier for users.
[Ian]The fundamental problem we�ve got here is one of the original drivers behind doing this is the thing Jim raises trying to get what people�s bullet points were. If we knew what everybody�s hot topic were, then we could put them into a drop down list. I don�t know if we actually know that. From our point of view it would be a whole lot easier if we put it into a drop down list and say pick this and pick that.,
[Patrick] Exactly, that would make it a whole lot easier for anyone reading it.
[Ian] I just wonder if we�d miss a lot of feedback with that. I don�t know. I�m not dictating what goes in here. I�m just putting the demo up here so people can comment on it.
[Heiko] Maybe it can be a drop down list with one item called other. When you click on other, a text box opens up.
[Ian] I think it probably means we need to do a brainstorm on what these objectives or milestones or key points to come up with a list. I think it is more than just listing the use cases. I think there is a lot more to it than that.
[Brad] I totally agree. I know the pain and the difficulty it was to come up with the first survey. It took a lot of thought for the survey that I didn�t want to burden the people with too detailed information, but get enough information that was going to be useful for the officers to be able to start directing the focus of the group. It is a very fine line to think of where you think people are going and ask the kinds of questions that are going to be simple enough to get the kind of detail you need. It is very difficult.
[Ian] I think it is probably something, like Patrick suggests with a drop down list, but what Heiko suggest having another so you can then put in some free form text for things you can�t find on the list. I think there is a danger I suspect with that where people just try to find something that fits on the list without thinking too hard. We won�t get something that�s perfect.
[Brad] We are trying to go through a survey in the iNEMI organization right now. Fortunately, iNEMI has a professional organization that is expert at creating surveys. None of us here are experts, but I think we can come up with something beneficial. I am still struggling in finding what we have as an overall goal of this survey. It seems to be a couple of things we are trying to achieve. One is can we refine what the use case issues are to make the meetings more relevant for people? The second is really what are the topics people feel are the hot buttons SJTAG needs to solve for their particular industry? They may not be totally in alignment for a survey.
PAUSE
[Brad] Can we talk a little bit about what each of us feel we would like to see as the purpose of what we are going to get out of this survey? It is one thing to give a survey, but we really need to have an objective for why we are giving the survey. Otherwise, it is just busy work.
[Patrick] The whole purpose is to understand whether the whole industry is interested in SJTAG and what kind of a standard they expect.
[Ian] I think that is part of it. I think Jim had a much narrower focus when he came up with the suggestion in the first place which is really to get just a few bullet points probably from ourselves more than anything else and to look at what we are really trying to do strategically to get the things we need for our roadmap. There are really two questions there: What are the important things and what do the people want to see as the markers to show we are making progress.
[Patrick] If we go to the technical items, for example, SJTAG defines we must have BIST in the BSDL command to be able to run BIST. One question is whether chip vendors are prepared to put BIST within their chips so we can use it at the SJTAG level.
[Ian] In my mind, that is probably the kind of question we want to get into when we get into more detailed questions. I think we need to move those issues up to some kind of top level or abstract kind of view of what people are expecting so you can get some sort of answer out of it.
I think the question you are asking is quite relative, but you could actually come up with quite a lot of details questions like that. It comes back to the case of actually turning people off. Unless they say they are prepared to come on board to fill these questions out.
[Patrick] What you are suggesting is really aim for two surveys. One is a top level one to get a feel of what the community wants. The we could come up with am more technical detail later in the day.
[Carl W.] I think a two tier survey makes quite a lot of sense.
[Heiko] I think it would also help raising the awareness of what SJTAG is doing or discussing right now. Some people have heard of SJTAG, but I don�t think many of them have gone to the forums or went through the discussion topics. Since the survey would be highlighting what we have been doing, people will get an understanding of what we are doing.
[Brad] The face we need to show in the survey is that we know we have a good understanding of a direction, but that we need some clarification on the issues as we move forward. We don�t want to show a position where we really don�t know what we are doing is a bad position to put forth.
We have to be very careful at how we write the survey. I think the way, Ian, you were asking questions next to the text boxes was good to give me a focused direction to fill in the information needed in the text boxes.
[Ian] I think I can sympathize with what Patrick was saying about too many text boxes. The problem with just check boxes is that people just click on boxes to fill out the survey and don�t think to hard. What we are really want are people to think and not just give glib answers.
[Brad] This is going to be a survey that is needing more thought than something like a publication survey.
PAUSE
[Ian] I can take away some of the comments we had today and come up with a rework of the form and come up with a revision 2. I think I will focus on the simplified form for now. This will give us a bit more time to think about the more detailed form in the background.
[Brad] I can�t emphasize more that we need more information and support from people regarding these forms. Please provide as much feedback as you can.
[Ian] It doesn�t take me long to change the form. It is the change to the database in the back of the form that takes time. I think we have several suggestions I can work with this week.
[Brad] I think we can move on to the next discussion topic now.

Identify use case sections and outline for white paper:

[Brad] The next topic is identifying the sections and requirements needed for the use case white paper. It was clear from last meeting that we are not meeting the needs of the people that are relying on what we are doing. I am not sure what Gunnar has as his structure that it is what we should have for our current discussion topics.
[Heiko] Was there a link to Gunnar�s paper in the email you sent out?
[Brad] I noticed it was not on the sjtag.org site and I forwarded to Ian. He put it up on the site within minutes.
[Ian] I agree with you that Gunnar�s structure doesn�t quite fit with what we are talking about and that it is written more to support his MSC project. His order is not necessarily the priority of the items either.
I think it might be better to write the paper without trying to rework Gunnar�s paper. As far as our paper, we can take the use cases as we have them identified an take them as sections of their own. Then perhaps we got issues on how to possibly relate them to possible architectures and how to relate them to language selections and so on. If we want to focus on use cases, then we need to describe them and how they relate to the hardware and software.
[Heiko] We probably need some sort of an introduction at the beginning discussing why we even talk about these use cases and how it all fits together.
[Brad] I think our Venn Diagram is a good introduction for this. Ian, you coined it as the SJTAG Universe now. I think your SJTAG presentation gives us a framework for that section. It gives us the ability to inform people that boundary scan is more than just the manufacturing stuff.
When I show the SJTAG Universe slide to our internal people, I get a reaction that they did not realize how much boundary scan could do for them. I think the key is to emphasize that people can get to use boundary scan that already exists for manufacturing with little additional to do all these cases.
[Ian] I think that is right. Certainly the angle I am pushing on this is that the logic is already there when you design the boards. You are just trying to put the rest of the interconnections in place when you design the system. You suddenly open up a whole world of things you can do.
[Brad] This is what is really key about the education. There are so many people that are just not informed about what boundary scan can do for them. We have communities that just think of boundary scan as only an emulation port and don�t use it for manufacturing. We have others that just use if for manufacturing and don�t realize they can use it in system.
[Ian] I�ve had a discussion with some of our production people earlier this week about some of our older systems and they said if we had JTAG available we could save ourselves 180 minutes for test. Our production people are certainly seeing the value in it.
[Brad] Do you remember the thought process they had to go through to realize the value add?
[Ian] It wasn�t that big of an exercise to get them to think about that. Once you show them that something works, they think "why didn�t we do this all the time?". More important is understanding how they came up with 180 minutes.
[Brad] With our people, we had different motivations for each product as to why they wanted to use JTAG at the system level. Some wanted to use if for POST. Others wanted it for updates. In the whole spectrum, there was a product motivated for probably each of the use cases we talked about.
[Ian] I think it depends on who you are speaking to. For a manufacturing person the idea of an interconnect test to show the system is put together properly is important. For the in-service people it is going to be the updates and so forth. I think you need to think about how they fit into the product life cycle.
[Brad] I think there needs to be another item on the survey to indicate where they exist in the product life cycle.
[Brad] So we have an introduction, the various use cases, and a section on how these use cases correlate into the different architectures and languages for the document.
[Patrick] I think in the first phase that sounds about right.
[Ian] I think if you are scoping the document as a use case paper that is probably all you need. I think things like architectures and languages and things like that belong somewhere else.
[Brad] What I am hearing is that we don�t get into the whole language issue in this paper or should we deal with what languages are used currently and what languages are effective and what are not?
[Ian] I don�t know. I just wonder if what we are doing is going to create a back end to the document that is more open ended, a bit inconclusive if you know what I mean. I think it will be more elegant if we get to position that this is a complete description closed and let�s move onto something else.
[Heiko] Then we could have separate papers that discuss other issues such as languages. Those could be sort of living documents too. Then somebody could always have a sort of introductory paper that could be handed over to somebody that is new to SJTAG. And then we can reference them to other material when they are interested in data formats or languages or something.
[Ian] Yeah. That might be an idea.
[Brad] My biggest concern is there needs to be some way in tying these topics together and show how all of this together provides and extremely powerful and efficient technology we call SJTAG.
[Heiko] I thought that topic was the last section you talked about for the white paper.
[Brad] I was looking at that based on what Ian was talking about having a part that correlates the use cases to the existing architectures and that to me as an architecture did not imply a particular language but more referred to the topics talked about what we talked about in the first white paper � what can be embedded and what cannot.
[Ian] I think that is fair enough, Brad. It�s complicated to understand what we need to do with this because while you were actually putting a physical document together on your desktop you can see all the different sections and different documents like a master document with sub documents and if you were putting these as an on-line form that people can access that interlinks the way people would look at real documents.
[Carl W.] There is kind of an implied hierarchy here in all of it.
[Ian] I think we almost have a structure for documents here.
[Carl W.] I agree. It seems to be breaking out into a hierarchy here.
[Brad] I agree, but I am having difficulty getting my arms around it. I can see there is a natural progression we need to be following.
[Ian] The hierarchy to me is a bit like the way the IEEE standards are written. You have the standard itself. Then you have the dot 1, dot2, dot3, and so forth to describe the different aspects within it. When you think about it, it is really the natural way for how we should be trying to work. So maybe we�ve got an SJTAG overview as the master document that then links out to an architecture document, a languages document, a use case document. As far as the web site is concerned, we can replicate that kind of a structure on the site to reflect that. If we use a word document or PDFs we can actually create live links in them if necessary.
[Brad] What I would suggest this week is everyone think about this over the next couple of days and send out your bullet list of what your order of hierarchy is and your list of hierarchical topics are so we can move forward on this next week to try to narrow down the scope of where we need to be moving. I think we are identifying there is a bigger perspective of documentation we need to provide to the community. There are things that have to be tied together as a conclusion that people could go to in order to see how it all fits together. It is turning out to look like a structure I see in many modern Business Cases where there is a description and a reference to where the value for the buck comes from.
[Ian] I think what we sketched out in our minds here directly links to the perspective Jim came to us with last week of where is all this going to go. I think the impetus of what Jim kicked off last week has driven us to where we should have been anyway.
[Brad] I think so. We were too much being engineers delving into the problem domain and not thinking about this from a business perspective.
We talked about the value add, but have not organized ourselves around the value add propositions.
[Carl W.] I guess this is why they always have marketing go off and do a product requirement doc before they allow us to design circuits.
[Brad] It sounds like we are reaching a stopping point for discussion topic 4b today.

SJTAG membership:

[Brad] We are now trying to get to the topic we were trying to get to last week before we got derailed on the direction topic. Where we left off was with Ian�s proposal looking at the attendance quarterly and those with a 25% attendance rate were considered part of the core team.
[Heiko] I would agree.
[Carl W.] I also agree. This seems to add a bit of stability to this.
[Patrick] I agree as well.
[Ian] I think there are two issues: One that I am still concerned about is the approval of meeting minutes. It may not be a big issue. If we had a large percentage of people only attending 25%, it could be a problem. The other are for people like Jim that are self employed and have difficulty making the calls because he has to go out and do real work. I think he felt threatened.
[Brad] I think this is something we need to deal with. I have seen the excused absence email work for P1687, but that did not sound like something Jim was in favor of. I�m really at a loss.
[Ian] It is difficult to understand why though.
[Brad] I have asked him on numerous emails to explain himself. Are there suggestions people have for this issue?
[Heiko] You could make it a requirement to respond to draft minutes.
[Brad] It depends on the duration of the job as well.
[Ian] It seems it is going to be quite difficult to find a really comfortable accommodation that doesn�t seem like we are bending over backwards to deal with Jim�s particular issue. Jim makes some good points. I am reluctant to see him leave because he can�t see a way to contribute within the bounds we can manage.
[Patrick] I just wondered how Ben Bennetts was able to participate being self employed.
[Ian] He charged enough money.
[Brad] He also had a very successful base of customers to that was supporting him. I know Jim and Bernard Sutton struggle a whole lot more than Ben did for work.
[Ian] Maybe the simplest answer is to declare a special case for those that are self employed.
[Brad] Yes.
[Patrick] Especially for those that contribute like Jim does to SJTAG.
[Ian] I think there still need to be some means of defining there is some evidence that the contribution is really happening.
[Brad] That gets into the whole issue of how do you quantify that.
[Ian] I know.
[Brad] This is not going to be an easy resolution.
[Ian] I think we have to go about this as accepting a firm attendance policy, but we will have to have a formal thinking on how we deal with self employed people, I guess.
[Heiko] I think we all have things that come up last minute.
[Ian] At least those of us here have kind of got a fall back that when things come up, quite often you can get someone else to deal with them. It�s not quite so critical as to someone who is dependent on organizing around every offer of a job. I can manage to organize my time round about these calls. If you are self employed you have to manage your time round about the work that is available.
[Brad] I guess the bottom line is if you are motivated to help, you are going to find the time. That is the way all these volunteer organizations operate.
[Ian] I don�t think we are going to conclude anything today.
[Brad] We can at least vote on Ian�s proposal of reviewing quarterly for 25% attendance and realize we need to review how to deal with self employed people or at least hardship cases.
[Patrick] I will make the proposal if you need.
[Brad] We need to have a formal description of the proposal we can point to.
[Ian] I think the wording should be: The attendance policy to be applied will be based on a quarterly review with a meeting attendance in excess of 25% of available meeting constituting the qualification of core team membership.
[Brad] Patrick you are the one going to be making that motion?
[Patrick] Yes.
[Heiko] I will second it.
[Brad] Any opposed or abstain?
[Brad] I will record that all those in attendance approved this motion.

5. Schedule next meetings:

Monday, June 9th, 2008, 8:15am EDT
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

none

7. Review new action items

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;

8. Adjourned at 9:33am EDT

(moved by Ian, second by Heiko)

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

Respectfully submitted,
Brad