Minutes of Weekly Meeting, 2008-04-23

Meeting was called to order at 8:26am EDT

1. Roll Call (Participants):

Brad Van Treuren
Ian McIntosh
Heiko Ehrenberg
Peter Horwood
Jim Webster (joined at 8:40)

Proxy additions provided by:
Ian McIntosh (corrections to comments)

2. Review and approve 4/14/2008 minutes

meeting minutes unable to be approved since we did not have enough members from last meeting present

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
  • Brad to review Service Availability Forum (Done)
  • Brad sent a slideshow from Service Availability Forum, especially slide 19 and 20;

4. Discussion Topics

  1. SJTAG Value Proposition – Built-In Self Test (BIST)
    • [Ian] Last week we struggled with the definition of what BIST was. Have we really tackled the value proposition for BIST yet?
    • [Ian] still outstanding:
      • definition of BIST,
      • value proposition for BIST with JTAG; are there other (more suitable) options/ways to apply BIST;
    • [Peter] We haven't really defined the value add in any specific cash terms. We know it is value, but does find that even if it is redundant, in the extreme case having it available is valuable. This feature overlaps with other use cases were the BIST really comes along for free if the test use cases are added for other things.
    • [Ian] People may be able to build in the capabilities, but there may be engineering needed to enable it at an additional cost.
    • [Peter] If it is part of the firmware for the changes, it becomes more open.
    • [Ian] Yingwu made the comment last week that they use the RUNBIST but not all the BIST is accessible using JTAG.
    • [Heiko] Sometimes you don't even know BIST is available because it is not located in the BSDL and/or data sheet.
    • [Ian] I tried following up Brad's comment about using the vendor's foundry code and found the vendor unaware of this capability.
    • [Ian] The definition of BIST on the forum site last week was updated and I did not see any changes to that. It seems that component level testing definition is probably accurate. I think we found that a GO/NO-GO test gave us enough information to determine we need to replace the component. Do you agree?
    • [Peter] Yes
    • [Brad] Yes
    • [Peter] What level of BIST will we achieve with this system , will we not get push back from a cost perspective.
    • [Ian] Yes, there will be an argument if there is a PCB with high proportion of analogue then the fault coverage will be less. You get some implicit coverage, eg if the on-board PSUs start up OK, or if device testing is done with cluster tests
    • [Peter] Have we really identified the value of diagnostics from BIST for boards that may not have a lot of boundary-scan devices on them? For example, a board that is mostly analog.
    • [Ian] You can have an argument if you have a mixed signal board with a lot of analog, JTAG itself will not give you much value as far as coverage on the board. None of our boards are pure digital, thus all the boards, because of the power supplies and control, are going to be a mixed mode board.
    • [Peter] We need some sort of case in the specification that is could be optional because there is such a void in what we are trying to describe. Each system is designed differently. In a pure analog system, JTAG BIST does not make sense. I go back to my thought that we need to have optional SJTAG features for them to implement.
    • [Ian] I think you are right, we need to identify what they may use and describe the tooling support they need if they choose to use this technology. What we are looking at is the software above this and want to provide the infrastructure.
    • [Peter] Then you would want to reserve 4 or more pins on the backplane to support this even if you are not going to use it.
    • [Ian] One of our boards was predominantly analog and not suitable for JTAG. After a design update it is now mostly digital and good for JTAG: I think this is not unusual so it seems wise to provide the capability now, for possible use in the future.
    • [Jim] Even with an analog board, the result has to be read somewhere when a BIST operation takes place.
    • [Ian] I think you are right and that usually the results are fed back to somewhere else in the system and possibly stored.
    • [Ian] results could be provided by discrete signals or could be stored somewhere, for example;
    • [Jim] If they are stored, then you should be able to read them.
    • [Ian] It depends on where they are stored. Memory storage requirements might get large as well.
    • [Jim] This is true for tests that could be initiated at various stages in the system. Some can be done at initiated or requested later.
    • [Ian] We have described these cases and realize there can be a lot of information that needs to be stored to support all these cases.
    • [Jim] Have we been talking about SJTAG to initiate BIST or just to interrogate the results?
    • [Brad] With P1687 coming on-line we need to support BIST initiation as well as read back mode.
    • [Jim] Yes.
    • [Brad]: There is a lot of over lap in use cases
    • [Jim] We need to be clear on what we are recommending, as its not clear from the minutes I am reading
    • [Jim] We need to be able to draw the boundaries of the capabilities.
    • [Brad] The monitoring of the results only really falls under the SAMPLE/monitor use case and not really BIST.
    • [Ian] I think we are dealing with the differences between BIST and BIT, which is a bit muddy.
    • [Jim] Yes, thats why I indicate we should look at this for the recommendation
    • [Jim] You have to be careful; BIST mostly runs at speed; JTAG can not run at the system's functional speed; would need to enter SJTAG, initiate BIST, enter mission mode to run BIST at speed, then enter SJTAG again to read results; is that practical?
    • [Peter] If you have the infrastructure in place, it is purely up to the designer to use the infrastructure the way that you need to. It is more about providing the infrastructure. We have to be able to describe that without becoming over used or difficult.
    • [Ian] I think we need to understand the controls and things that drive the capability as that then drives the architecture of the system. It is becoming more of a template architecture which enables what can be done by the designers later.
    • [Ian] It comes back to the multidrop/point-to-point arguments and what impacts the overall architecture.
    • [Brad] Whats important is to make people aware of how they can use the technology, we have check list to show what can be done with embedded boundary scan. What we should be looking at is to encourage engineers to look at the value add for their product. Looking to indicate the common infrastructure will support many functions which the engineers can choose. A checklist ensures that designers have consciously thought about the use or lack of use of SJTAG.
    • [Brad] people need to make a conscious decision whether or not they want to implement embedded Boundary Scan, what are the benefits? designers and product managers need to understand what they can achieve with embedded Boundary Scan;
    • [Ian] Once people have the hardware to support jtag at system level then uses are found that would not have been thought of at the beginning of the project

5. Schedule next meeting

Wednesday, April 30, 2008, 8:15am EDT: Topic is ? Use Case

We are holding a special second Wednesday meeting in April because the next meeting time (May 5) conflicts with holidays for the members. We all felt it was too long to wait two weeks before meeting again. The April 30 time was proposed and adopted for the next meeting instead of waiting.

6. Any other business

  • Do we want to have a Monday meeting the following week after a Wednesday meeting?
    • [Peter] sounds reasonable as other wise you are off-line twice in 3 days for 1-1.5 hours
    • Heiko, Peter, Ian, and Brad feel we should not have the meeting the following week.
  • Who should be on proxy list? What constitutes regular attenders?
    • Brad will be addressing this item and look for advice on reworking the core group list based on participation activity at the next meeting. It is generally felt that core members should attend the meetings to be listed as core group members. It is unfair to companies that are supporting this activity with active participation when other companies are represented with little to no effort or cost.
    • [Brad] P1687 keeps track of who attends and who does not. They have a process in place where you can notify the recorder that you are unable to attend due to a conflict and your absence will be counted as an excused absence. If you do not notify the group ahead of time, it is considered an unexcused absence and thus your attendance for voting privileges is affected.
    • [Heiko] Keeping a track of who attends and who does not is difficult to track. It requires consistency.
    • [Brad] Ian has been keeping a record of this for me, but it is time consuming.
    • [Ian] It comes down to when do you drop people off the list? Two weeks absence is probably reasonable to cover for vacations.
    • [Ian] Requested hiatus sounds like a reasonable process to continue to be included on the list.
    • [Peter] I think what you propose with excused absences is a good one.

7. Review new action items

  • Brad come up with proposal for attendance and membership to core group.
  • Brad send out to the reflector the remaining use case topics for discussion for a vote on what to discuss next week.

8. Adjourned at 9:28am EDT

(moved by Ian, second by Peter)

Many thanks to Peter and Heiko for assisting in taking notes for these minutes.

Respectfully submitted,