[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-11-02

Meeting called to order at 10:34 AM EST

1. Roll Call

Brad Van Treuren
Eric Cormack
Ian McIntosh
Patrick Au
Carl Walker
Brian Erickson
Tim Pender (joined 10:35)

Excused:
Adam Ley
Heiko Ehrenberg

2. Review and approve previous minutes:

10/26/2009 minutes:

  • Updated draft circulated on 29th October:
    • In 'Review and approve previous minutes', change 'corrections' to 'correction'.
    • In 'Review old action items', delete '- All: Review "tooltip" help, ... topic 4b.'.
    • In 'Discussion Topics' 4a:
      • [Brad] When do you want to release the survey?
      • [Ian] I need to make the edits to the survey form, and ...
    • In 'Discussion Topics' 4b:
      • [Brad] One thing that these diagrams are making clear is ...
      • [Ian] I am thinking that this may be about to spawn a 6th volume ...
  • Brad moved to approve with the above amendments, seconded by Carl. No objections or abstentions.

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
  • 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
    (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
  • Ian/Brad: Draft "straw man" Volume 4 for review - Ongoing
  • All: Review "Role of Languages" in White Paper Volume 4 - Ongoing
  • Harrison: Virtual system exploiting Configuration/Tuning/Instrumentation and Root Cause Analysis/Failure Mode Analysis Use Cases. - CANCELLED
  • Brad: Virtual system exploiting POST and BIST Use Cases. - COMPLETE.
  • Ian: Virtual system exploiting Environmental Stress Test Use Cases. - COMPLETE
  • Ian: Tidy survey questions 7.5 and 7.6, reinstate referral emails, and flush database. - COMPLETE
  • All: Review 'straw man' virtual systems and notes on forums:
    http://forums.sjtag.org/viewtopic.php?f=29&t=109. - Ongoing
  • [Ian] I made the changes to the survey form and scripts. One extra change I made was to remove the timeout on the pop-ups: I did this because all the help is now only on the question field, and in reviewing the form I thought there wasn't enough time to read some of the longer help texts.
  • [Brad] Ian, there were actions on you and I from a while back on the virtual systems, which I think we closed out using the action last week.
  • [Ian] Yes, that thought ocurred to me after the meeting last week. These went alongside the action on Harrison, which I don't believe we have any prospect of completing now.
  • [Ian] We can mark the actions on Brad and I complete, and unless anyone objects, I propose that we just cancel off Harrison's action.
  • {No objections}

4. Discussion Topics

  1. 2009 Survey
    • [Ian] I'd like to quickly go over some of the supporting details for the survey: First the 'Landing Page'.
    • {Survey Landing Page shared}
    • [Ian] As Tim requested, I made the link to the survey form a button with bold text. Are there any other comments?
    • [Eric] You have 'the the' in the bullet on JTAG.
    • [Ian] OK I'll fix that. Now, the email invitations.
    • {Invitation text shared}
    • [Ian] There are two emails: A primary one that we send out directly to our contacts, and one that gets sent out automatically for the referrals given in the survey form.
    • [Ian] The primary email has a statement on why the recipient is getting the invitation: This is just good practice, to stay the right side of rules on spam, as is the note at the end on requesting no further contact.
    • [Eric] In the invitation, 'to' is missing from the first bullet.
    • [Ian] OK.
    • [Patrick] You should make the '20 minutes' bolder, so people are aware of the time it takes.
    • [Eric] Or use a larger font.
    • [Ian] The intent was to send these out as plain text as it creates less of a problem for people who have HTML turned off in their email client.
    • [Patrick] Could use capitals.
    • [Eric] What about asterisks either side.
    • [Ian] Yes, the common way of marking something as bold in plain text is to put in inside asterisks.
    • [Patrick] That would do.
    • [Ian] The referral email is different because it include fields that get filled in from the survey form, to personalize it.
    • [Ian] I kept it simpler. Do you think it should include the notes on time, passing the invitation on if you're no longer interested, and so on?
    • [Eric, Patrick] Yes.
    • [Ian] OK, I'll make the changes. {ACTION}
    • [Ian] Next we were going to start having a look at what we expected to learn from the survey questions. With where we are on time, I suspect that we not get round to anything on Volume 3 today, but maybe its best we leave that until next week anyway, when we may have Heiko and Adam on the call again.
    • [Ian] Section 1 is straightforward user details. Section 2 is questions that simply test to see who has read the White Paper - a set of 'calibration' questions really.
    • [Ian] The first few question in section 3 are also 'calibrations', finding out if people are currently using JTAG and whether or not they've applied it at a system level.
    • [Ian] Question 3.5, on the use of languages, is the first one where we can really start to learn something. What can we infer from the responses here? The first two options, SVF and STAPL, are really vector languages, so if people give any of the others, does that mean they're using then for higher level control?
    • [Brian] Some tool vendors are using some of these languages within the tests: We're using Python and Goepel have their CASLAN and Asset will have similar. I think they're all going that way now.
    • [Ian] Yes, of course, I'd forgotten about that.
    • [Brad] Yes, in supporting things like P1687 we'll see more vendors supporting things like Python and TCL.
    • [Brad] Maybe we should split this question into two sections, languages for test applications and languages for flow control.
    • [Ian] I seem to remember we proposed that earlier and then abandoned the idea for some reason. I have to say that I'm not too keen on changing the structure of the survey at this late stage.
    • [Brad] Well we can always follow up with the user, to get more details.
    • [Eric] That might be a good hook for a followup: We may get a better insight as a result.
    • [Brad] I looked to see what responses we got to a similar question in the 2006 survey: There's EBST, STIL, Verilog+C#, CASLAN+SVF, EVF, JAM, C, etc.
    • [Ian] So predominantly looking at the vector level?
    • [Brad] So it would seem. The question only offered SVF, STAPl and Other as options.
    • [Ian] Maybe by listing other languages, people will consider a wider scope for the question.
    • [Brad] I hope so.
    • [Ian] It would be easy enough to add a helper to the question here to direct them to consider the wider scope.
    • [Brad] That would seem to be a good idea.
    • [Ian] I'll add something then {ACTION}
    • [Ian] In 3.6 we're looking to see if people have realized the limitations of existing languages - it's a "maturity of thought" issue.
    • [Ian] Question 3.7 and 3.8 are similar, with 3.7 focussing on board level description and 3.8 looking at system descriptions. The difference is in answer k) in 3.8 - merging of netlists, which seems to be how most people get to a system description.
    • [Brad] Yes, if they're trying to leverage the board test generation tools.
    • [Ian] But really, the ATPGs should be much the same whether at board or system; it's mainly how you get that system description.
    • [Brad] There are some differences, but the algorithms are largely the same.
    • [Brad] The big piece for me here is to find if there is some area of commonality between users: Is there a common method people are using here, even if it's only 30%, that we can then start to standardize around?
    • [Ian] So if we get a big spread then it means there is little scope to standardize?
    • [Brad] A big spread means there's a real problem here, and we can show that it's something that SJTAG can help with, by bringing in standardization.
    • [Ian] In 3.9, I guess, or hope, that every one would want to be able to reuse board tests in the system.
    • [Brad] Yes, but the question is whether they have realized that there are differences because, for example some gateways make the tests in multidrop different to those embedded on the board.
    • [Ian] I think there's a bigger difference for those who are used to the external test arrangements: Board tests that are allowed to switch signals at the board edge may need a lot of rework to make them 'safe' in a system.
    • [Brad] It depends on how you constrain the tests.
    • [Ian] Constraining tests may mean reducing coverage, and that may be something you don't want to do to the factory board-level test.
    • [Brad] What happens at the board edge is often down to the CM's facilities.
    • [Brad] The same things happen with ICT: Some CMs will use nails to probe the though hole solder points of connectors rather than use the connector pins. Electrically it should be the same, but may not be.
    • [Ian] Yes we've had bent pins, mainly on lightweight test connectors, that will pass that bed of nails check but won't connect when a plug gets fitted.
    • [Ian] It's often the case that JTAG, ICT, MDA are terms that get used loosely and what the CM means may not be what you mean.
    • [Patrick] Don't you give the CM a specification of what is required?
    • [Ian] Sometimes it's the procurement people negotiating with the CM and asking the wrong questions. Often, we're downselecting CMs for a job maybe 18 months ahead of having any solid design to talk round.
    • [Tim] Going back to question 1.4, will that determine what questions people will see?
    • [Ian] No. We thought about making it work that way, then decided it was best to let everyone see all the questions, and just ask them to answer the ones they felt comfortable with. People may have changed roles, but still carry useful insights from a previous role.
    • [Patrick] When I went through the survey a couple of weeks ago, I didn't feel comfortable answering some of the questions.
    • [Ian] I think that's natural. I expect relatively few people will have been exposed to all situations. It's important that people don't try to fill out answers by guesswork as that could end being misleading.
    • [Eric] The 'Don't Know' answers will be able to tell us things too.
    • [Ian] I agree - I expect those to give us almost as much information as the positive answers will.
    • [Ian] Well, half an hour of discussion on this has got us through section 3.

  2. White Paper Review - Review of Virtual Systems
    • {Not discussed due to lack of time}

5. Schedule next meeting

Schedule for November 2009:
Monday November 9, 2009, 10:30 AM EST
Monday November 16, 2009, 10:30 AM EST
Monday November 23, 2009, 10:30 AM EST
Monday November 30, 2009, 10:30 AM EST
  • Brad has a conflict for 9th - may join late
  • Tim won't make 23rd

6. Any other business

None.

7. Review new action items

  • Ian: Add help text to question 3.5.
  • Ian: Make amendments to survey invitations.

8. Adjourn

Eric moved to adjourn at 11:35 AM EST, seconded by Patrick.

Respectfully submitted,
Ian McIntosh

Copyright 2007-2009 The SJTAG Working Group
The SJTAG Initiative is "work-in-progress" and the views and opinions expressed here are subject to change without prior notice.