Minutes of Weekly Meeting, 2009-05-04

Meeting called to order at 10:35 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Brian Erickson
Adam Ley
Heiko Ehrenberg
Tim Pender
Brad Van Treuren

Patrick Au
Peter Horwood
Carl Walker

2. Review and approve previous minutes:

4/27/2009 minutes:

  • Draft circulated on 27th April:
  • No corrections noted.

Brian moved to approve, Eric seconded, no objections.

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
  • Carl W/Andrew: Set up conference call to organise review of Vol. 3 - Ongoing
  • Andrew: Make contact with VXI Consortium/Charles Greenberg. - Ongoing
  • Ian/Brad: Draft "straw man" Volume 4 for review - Ongoing
  • All: Review "Role of Languages" in White Paper Volume 4 - Ongoing
  • All: Consider structure/content of survey - Ongoing
  • Harrison: Virtual system exploiting Configuration/Tuning/Instrumentation and Root Cause Analysis/Failure Mode Analysis Use Cases. - Ongoing
  • Brad: Virtual system exploiting POST and BIST Use Cases. - Ongoing.
  • Ian: Virtual system exploiting Environmental Stress Test Use Cases. - Ongoing
  • Brad/Ian - Prepare draft survey for review by group. - Ongoing
  • All: Propose answer options for the questions shown as needing completion. - Discussed in topic 4a
  • All: Assess which section each question should be placed into. - Discussed in topic 4a

4. Discussion Topics

    1. 2009 Survey
      • [Ian] What is the best approach to discuss this? Maybe we should start with rows 21 and 49 which need expanded and then go through the questions in order to sort them into their sections?
      • [Brad] I like that idea; 21 and 49 are the most important to deal with.
      • [Ian] OK, let's start with line 21. Are there other languages we should offer in this list of suggestions?
      • [Heiko] I'd know of one, but it is proprietary and most likely only users of Goepel tools would recognize it.
      • [Ian] That could still be relevant, if that's what the user sees as the language.
      • [Eric] And there may be other proprietary languages: Maybe we could just add an option for "other proprietary language"?
      • [Heiko] Yes, some people may even use scripting languages or C/C++, and so on.
      • [Ian] That's fine. But were getting languages for scripting flow and languages for describing vectors. Do we need to start splitting these up?
      • [Brad] IJTAG had similar problems differentiating between vector language and scripting language: We've got descriptive languages like BSDL and HSDL, vector or test languages like SVF and STAPL and script languages like Python and TCL. And things like STAPL can kind of sit across vectors and scripts.
      • [Ian] Should we try to separate vector languages and test/scripting languages?
      • [Heiko] Later in the survey we ask if people are more interested in storing vectors and execute those controlled by the test controller, or if they would be more interested in storing complete tests on a board/module. If vectors are stored locally, there would be a need for a vector language and a control language, the latter to control which vector to run and what time.
      • [Brad] we need to step back and assess what is the information we want to get out of answers to this question. I'd like to understand how people are partitioning the architecture with regard to test execution, test control, etc.
      • {Brian's connection dropped at 10:55}
      • [Ian] Yes that's useful knowledge - I'm just not sure how to form that into a question, though.
      • [Brad] Yeah, I've been just thinking that too.
      • [Ian] This is probably a question for more experienced users, as it goes beyond basic use of tooling.
      • [Brad] Or people like me who are porting across to embedded applications.
      • [Ian] Maybe we can set questions for each of the layers of languages people are using.
      • [Tim] Where in this would the shadow protocol fall?
      • [Brad] Well that's it; it's a protocol. It isn't really tied into in to a language, it sits outside things like SVF, although some vendors have made SVF extensions for it.
      • [Tim] Yeah, I'd like to keep that outside of the vectors.
      • [Brad] Do we see this as a multi-answer question?
      • [Ian] Yes, my thought was a "check all that apply" kind of question.
      • [Brad] Is there a way to show an image of the different stack layers, similar to what I showed in one of my presentations, to illustrate where we are going with this question?
      • [Ian] I haven't really explored that: There's possibly a couple of ways to do it, pop-ups or embedded images.
      • [Brad] I can envisage aligning questions with that graphic. Do others agree?
      • [Eric] It'd certainly help people get down through the layers.
      • [Ian] OK, we should do that. {ACTION}
      • [Tim] I think it would also point out that there is no standard for gateway devices.
      • [Brad] I don't think it would explicitly make that point.
      • {Brian rejoined at 10:59}
      • [Ian] Should we add a question related to those devices?
      • [Brad] I think it would be more than one question, since there are different types of such devices, path linkers, instrumentation gateways, and so on.
      • [Ian] Lets look into that too, then. {ACTION}
      • [Ian] Now, let's take a look at row 49, "Which single feature of SJTAG would you expect to give you the most ROI?". We don't have any suggested answers here yet.
      • [Ian] For me it probably would be ease of Field Reprogramming.
      • [Brad] That is probably the same for us
      • [Eric] System diagnostics, field diagnostics has to hae some value.
      • [Brad] Explicit knowledge of test coverage when compared to functional test.
      • [Ian] Reduced support equipment costs for Field Service or ESS/EST.
      • [Brad] I'd add Software Debugging too.
      • [Brad] I'm also inclined to add Fault Injection/Fault Insertion.
      • [Ian] There must probably be at least 10, since we have that many use cases.
      • [Heiko] We should add a text box for "other" for survey participants to add things that are not listed as options.
      • [Ian] OK that gives us something to go on for now.
      • [Ian] Another question is, how do we determine which sets of questions to present? Is it too simple to just present the options "Technical" and "Managerial" and let the user pick one?
      • [Heiko] Some people may be managers but have technical experience and might want to answer both sections.
      • [Brad] Can we allow someone to wear a different hat when filling out the survey a second time?
      • [Ian] Last year's survey didn't have any mechanism to stop people taking the survey twice - and at least one person did that, but it's easy to spot. I don't see have any reason why someone couldn't have two passes at it if they wanted to.
      • [Eric] It just means they'd have to fill out the general questions twice.
      • [Brad] At the end of the survey, we should add a summary of the answers given, for the participant to print out as reference.
      • [Ian] You mean for when they take a second pass at the survey?
      • [Brad] That's right.
      • [Ian] I'm thinking we can just have check boxes to select either the technical, the managerial or both sections, so it can be done in one pass.
      • [Brad] Ah, OK.
      • [Ian] But I think allowing people to print a copy of their own submission might be a good idea anyway.
      • [Ian] Let's try sorting the questions into sections. Please try to ignore my markups in the Section columns - they're my thoughts only, and the Common column should probably be ignored anyway.
      • [Ian] Rows 3 through 9, user details: General Section is ok?
      • {Agreed}
      • [Ian] Rows 11 through 14, a reworking of some of the questions from Brad's original survey.
      • [Brad] The first few were to see if people had read the White Paper.
      • [Ian] Yes, but row 14 really exposes whether people have really thought about JTAG at the system level.
      • [Brad] I agree.
      • [Ian] General or Technical?
      • [All] General.
      • [Ian] Rows 16 though 21, Use of JTAG: I have these listed in the Common Section, which really means General - is that appropriate?
      • [Eric] I think so. Most companies use Technical Managers now so it does seem appropriate.
      • [Brad] One of the things we need to be getting from the survey is to make sure we don't start addressing things where people say "we already solved that problem".
      • [Eric] I think some of that comes from one of the other questions?
      • [Brad] We know we don't want to reinvent board testing, but is there an issue in integration we should deal with. Or maybe users feel that the tooling industry can/will deal with these things on their own?
      • [Ian] Rows 23 and 24, use of SJTAG:
      • [Eric] Can we add comment boxes? e.g. if someone answers "I've never used JTAG at system level", have a comment box where we can ask "why not?".
      • [Ian] Certainly, we did that in some of the later questions.
      • [Ian] Again these seem to be General?
      • {Agreed}
      • [Ian] Row 26, SJTAG Features: Technical Section OK?
      • [Eric] I'd say so.
      • [Ian] Rows 28 to 31, Scope of SJTAG: I had these as "Common" but I think Brad saw them as technical questions. I'm now inclined to agree.
      • [Eric] Again, it would be good to ask "why not?" for some of these questions.
      • [Ian] Row 33, Diagnostics: Pretty much a technical issue?
      • {Agreed}
      • [Ian] Our time is running out. Do we want to break at this point and continue discussion from line 35 onwards at the next meeting?
      • [Brad, Eric] Sounds good.


    1. System Diagnostics (continuation)
      • Not discussed due to lack of time.


  1. Select new subject from Priority Objectives in 2008 Survey
    • Not discussed due to lack of time.

5. Schedule next meeting

Schedule for May 2009:
Monday May 11, 2009, 10:30 AM EDT
Monday May 18, 2009, 10:30 AM EDT

6. Any other business


7. Review new action items

  • Ian/Brad: Construct new question(s)) for row 21 based on Brad's previous graphic.
  • Ian/Brad: Construct new question(s) on gateway devices (linkers, bridges, instrumentation gateways).
  • Ian: Reformat questions through to row 34

8. Adjourn

Eric moved to adjourn at 11:35 AM EDT, seconded by Heiko.

Thanks again to Heiko for additional notes.

Respectfully submitted,
Ian McIntosh