The System JTAG Working Group

Minutes of Weekly Meeting, 2009-07-27

Meeting called to order at 10:36 AM EDT

1. Roll Call

Ian McIntosh
Carl Walker
Patrick Au
Adam Ley
Brad Van Treuren
Heiko Ehrenberg
Brian Erickson
Tim Pender (joined 10:43)

Excused:
Eric Cormack
Peter Horwood

2. Review and approve previous minutes:

7/13/2009 minutes:

Draft circulated on 13th July:
One correction previously noted: Amend comment in 4c from "... nest time" to "... next time".

Patrick moved to approve with above amendment, seconded by Brian, no abstentions or objections.

7/20/2009 minutes:

Draft circulated on 20th July:
No corrections noted.

Heiko moved to approve, seconded by Brad, no abstentions or 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. - CLOSED
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)
Carl W/Andrew: Set up conference call to organise review of Vol. 3 - CANCELLED
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. - Ongoing
Brad: Virtual system exploiting POST and BIST Use Cases. - Ongoing.
Ian: Virtual system exploiting Environmental Stress Test Use Cases. - Ongoing
Ian/Brad: Construct new langauges/layers question(s) based on Brad's previous graphic to replace Q3.5. - Ongoing.
Brad: Propose merge of survey questions 5.2 and 5.3; post on forums. (see discussion below) - COMPLETE
All: Test at least part of the draft survey form and provide comments through forums. - Ongoing.
Ian: Update survey form to include Brad's new questions for Section 5. - COMPLETE
Heiko: Continue update of wiki for Root Cause Analysis. - COMPLETE

[Ian] I've been looking again at some of the older actions: Patrick had an action to contact Cadence. I think the response was that they were monitoring out activities.
[Patrick] That's right. Can we close the action?
[Ian] That's what I was thinking; we're not likely to get any more from them right now.
[Ian] Another was for Carl and Andrew to review Volume 3. Harrison actually did this review with Carl, but was to supply further information. Since neither of the Corelis guys have joined the call for three months, I don't think this will ever complete.
[Adam] I'm fairly sure that Andrew Levy is no longer with Corelis. I probably have a non-Corelis email address for him if we want to pursue this?
{Tim joined}
[Ian] I'm not sure it's worth the effort. We may well be getting round to reviewing Volume 3 in these meetings soon anyway.
[Carl] That's the way I'd prefer to progress this.
[Ian] OK we'll cancel that action.
[Ian] There was an action for Brad and I to come with new survey questions for "line 21": That's now Q3.5, and is the one on languages. I think the idea was to find out what languages were used at each of the interface layers?
[Brad] Yeah, I was trying to remember what "line 21" was! I'd still like to learn where people see the need to have control over things. Do they want to have vector level control, do they just want to run a sequence of tests? We need to get that layering information from the user community. Maybe the action should be revised, at least to show the current numbering.
[Ian] Agreed.
[Ian] Heiko made most of the wiki edits for Root Cause Analysis last week as we discussed it. I was then able to go over it and make a few minor adjustments.
[Heiko] I made no other edits than those I did during the meeting.
[Ian] I've had a go at editing the EST section in advance. At some point we'll need to go back over some of the earlier sections, though: Structural Test is still missing a Value Proposition as is Software Debug and several sections need Consequences, since we added that part way through.

4. Discussion Topics

White Paper Review
- Power-On Self-Test
- [Ian] This has already got much of test organized under the headings. There's quite a lot there, so I'll let people read it over.
- [Brad] The first few sentences in the Detailed Description are a copy of the overview.
- [Ian] I'm not sure that the first couple of sentences in the third paragraph are adding anything - the bit about "The 1149.1 techniques are used extensively in the manufacturing process ...".
- [Brad] I'm reading that as meaning that you've already got JTAG tests from your manufacturing operations that you can leverage into the product for a BSCAN enhanced POST.
- [Brad] The sentence with the $ values should be in the Value Proposition.
- [Ian] Are the values meaningful?
- [Brad] I'd say they accurately represent the costs as I've seen them.
- [Brad] Back to the first paragraph: The third last sentence has "let" where it looks like it should be "led".
- [Ian] Yes.
- [Ian] The bulleted list is crossing over into Tooling, but not entirely.
- [Brad] I think the issues, with question marks, stay in the Detailed Description, while the straight bullets are Tooling items.
- [Ian] That looks like a good selection.
- [Ian] In Alternative Techniques, is "ad hoc" appropriate here: A POST is surely structured and scheduled?
- [Brad] I think what is suggested is that you need to write tests for each product.
- [Carl] Or for different feature sets in a given product.
- [Brad] Yes. Maybe it should say "Product specific functional test".
- [Ian] And the cost of doing that adds weight to the value proposition.
- [Ian] The sentence about high performance interface not being necessary may be misleading. The statement occurs in two places; we should remove both.
- [Brad] In the Value Proposition we need get over two things: The first is that a functional test will generally only provide a go/nogo result. The second is that a functional test give no clear idea of the test coverage achieved, while JTAG can be quite explicit on coverage.
- [Ian] Also that you should be getting the JTAG test virtually "free" from your manufacturing test.
- [Brad] And the test infrastructure is already there, perhaps less the controller.
- [Tim] I don't see anything being mentioned about the time to run the tests. Quite often, the POST needs to be run within a certain time.
- [Brad] That's a good item for consequences. In some cases we've had to reduce the tests that we do to meet the required POST time. Or we have partitions that don't get powered and tested until later. It depends on the self-test strategy you want to employ.
- [Brad] Some things get tested at power up, others after the firmware has loaded.
- [Ian] Some people see POST and BIST as the same, but they usually aren't. The coverage in each can vary, the time allowed for each to execute can vary. It's driven by design criteria and application requirements, so we can't try to impose rules.
- [Ian] One thing that I'm reading across from my EST work, is that functional test tends to check functions sequentially, while JTAG may test many data paths in parallel, so JTAG will usually give better coverage within the same time constraint.
- [Brad] One thing we need to be sure people are aware of is that the test will essentially corrupt the core logic on the board, so you need some form of reset that doesn't then re-run the POST. Some people use an on-demand BIST only followed by a reset; that way they can ignore BSCAN on power up.
- [Ian] I think that will do for POST just now. Heiko, I take it you were editing the wiki as we talked?
- [Heiko] Yes.
- [Ian] OK, I can review using my notes {ACTION}
Topics for Future Meetings:
- [Ian] We decided to defer any decision on holding a second meeting each week. That would have allowed us to alternate the main discussion topics of each meeting.
- [Ian] Instead, should we perhaps alternate each week, say between discussing Volume 2 and Volume 3 of the White Paper.
- [Patrick] I that would be a good idea.
- [Brad] I don't know that we've got that much left to do on Volume 2 now; I think I'd prefer to see something closed out.
- [Ian] There's maybe two to three meetings left in Volume 2, I'd guess.
- [Carl] I kind of like the idea of finishing what we're working on now.
- [Ian] OK, that's one voice in favour of alternating, two in favour of continuing as we are. Are there any other opinions?
- {None voiced}
- [Ian] OK, so we'll continue with Volume 2, which means we'll look at EST next time.

5. Schedule next meeting

Schedule for August 2009:
Monday August 3, 2009, 10:30 AM EDT
Monday August 10, 2009, 10:30 AM EDT (Heiko to chair)
Monday August 17, 2009, 10:30 AM EDT
Monday August 24, 2009, 10:30 AM EDT
Monday August 31, 2009, 10:30 AM EDT (provisional)

Expected absences: Ian, 10th; Patrick, 17th; Heiko, 17th and 24th.
August 31st is a UK Bank Holiday.

6. Any other business

[Ian] I'll just reiterate that I'd like to see people trying out the survey form. I found that I only saw things wrong when I tried to fill in the form "for real".
[Patrick] Maybe you should make it an action?
[Ian] Well, it already is; maybe I can word it better.
[Ian] I'm aware people are pushed for time, and it's a big form, but you don't need to fill in the whole thing. Sections 1 and 2 are mandatory but for our purpose right now you don't need to spend time thinking about the correct answers. Entering garbage is also a good test!

7. Review new action items

Ian: Review wiki updates on POST.

8. Adjourn

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

Thanks to Heiko for helping with the notes this week.

Respectfully submitted,
Ian McIntosh