Minutes of Weekly Meeting, 2009-10-12

Meeting called to order at 10:38 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Tim Pender
Patrick Au
Heiko Ehrenberg
Brad Van Treuren

Excused:
Carl Walker
Peter Horwood

2. Review and approve previous minutes:

10/05/2009 minutes:

  • Updraft circulated on 6th October:
  • Two further corrections noted:
    • Halfway through 4.b:
      [Ian] As we're way over time I'll quickly go over the pop-ups we have now.
    • Remove October 5 from list of upcoming meetings
  • Brad moved to approve with the above amendments, seconded by Eric. 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. - Ongoing
  • Brad: Virtual system exploiting POST and BIST Use Cases. - Ongoing.
  • Ian: Virtual system exploiting Environmental Stress Test Use Cases. - Ongoing
  • Ian: Update the White Paper web page to encourage use of the wiki pages, and add links to each section. - COMPLETE.
  • All: Review draft survey form. Specifically consider where "tooltip" help may be required. - Ongoing - See discussion topic 4b.
    http://www.sjtag.org/survey/forms/form1.html
    http://forums.sjtag.org/viewtopic.php?f=32&t=83.
  • Ian: Make revision to the survey form as discussed in 4b. - COMPLETE
  • All: Review "tooltip" help, especially considering the placeholder items in section 7. - Ongoing - See discussion topic 4b.

4. Discussion Topics

  1. White Paper Review - Filling the Gaps
    • [Ian] Since Carl isn't on the call today, I can't take over the host role, which means we don't have use of the application sharing, which will make things a little trickier.
    • [Ian] The first thing we have to fill out is the Value Proposition for BIST.
    • [Patrick] I was wondering, if you are using something like PCIe, you only a limited time for BIST and JTAG tests can take a long time. Shouldn't we be making a statement on that?
    • [Ian] It should be for the designer to ensure that he's complying with all the relevant requirements, but it's fair to note that you may need to limit the JTAG tests you can do to meet execution time requirements. It probably comes under 'Consequences'.
    • [Brad] I think the key thing for the Value Proposition is that as we move to System on Chip architectures, JTAG gives you a standardized access interface into those devices. You can then use parallelism to reduce the overall test time.
    • {Wiki edited}
    • [Brad] Another thing we've found is that previously we had a requirement that all ASICs should include BIST, but with the move towards FPGAs that has been lost. To make up for that, we've worked with vendor supplied foundry test loads that can give up to 95% coverage of the device. Depending on the device, you may need 3-5 loads to get that coverage.
    • [Brad] Large devices, like the Virtex 5, could be slow to load, so you may want to use parallel loading get the overall execution time down, but you can still use JTAG to fetch the result.
    • {Wiki edited}
    • [Ian] Are we comfortable with BIST's Value Proposition now?
    • [Brad] I think it's stable. Now we should add Patrick's point on the execution time to 'Consequences'.
    • {Wiki edited}
    • [Tim] What kind of test time do you get with the foundry tests?
    • [Brad] It really depends on the size of the device; the time increases in proportion to the size, but the test time is much shorter than the load time.
    • [Tim] a couple of minutes to load and 20-30 seconds to run?
    • [Brad] Probably even shorter than that.
    • [Ian] The tests only need to give a go/nogo signature, so the test vectors can be simpler since they don't need to diagnose faults, only detect them.
    • [Tim] How do you get the result? In a data register?
    • [Brad] Some newer devices will use User1 or User2, older parts sometimes need you read the states of certain pins.
    • [Ian] The vendors don't really push this; they'll usually say "You don't need a BIST for our devices because we extensively test every part before we ship it so you should never receive a faulty part". That's fine for when it comes out the pack, but I'm also interested in what's happened after it's been in use for three years.
    • [Brad] Or had ESD damage during handling or assembly.
    • [Ian] Xilinx referred to their device tests as XRST - Xilinx Reconfigurable Self-Test.
       
    • [Ian] Next is 'Consequences' for Fault Injection. We currently say "None" - is that true?
    • [Brad] The injected signal that you think you're sending to one place may end up also going somewhere else and that could cause damage.
    • [Brad] If your design doesn't include the resources to support the signals you want to inject, you may need to add gating and switching explicitly for injection, at extra cost.
    • {Wiki edited}
    • [Ian] Is there anything else?
    • [Brad] I had a look back over Alternative Techniques: There was a paper that Bill Eklow gave to a Board Test Workshop, maybe in 2002, where he talked about injecting faults in a simulation. That way they could identify fault characteristics that could then be tested for.
    • [Ian] Maybe we should leave this until we can get the correct citation?
    • [Brad] I'll take an action to look out the paper. {ACTION}
    • {Post Meeting Note: [Brad] Here is Bill's paper I was referring to. It was in BTW2003. Co-verification-BillEklow-Slides.pdf}
    • [Ian] That pretty much brings Volume 2 to a close. A major milestone, I think.
    • [Eric] Indeed.
    • [Brad] I'll make a motion that, with the addition to Alternative Techniques, Volume 2 can now be moved to the "Stable" section of the White Paper index.
    • {Seconded by Patrick, no objections. Motion carried}
    • [Heiko] I'd just like to thank Ian for driving this forward; I just wasn't getting the time.
  2. 2009 Survey
    • [Ian] I've tried to make some adjustments to the pop-ups. I've increased the offset from the pointer and made the pop-up fade out after 5 seconds. They also only activate over the questions now, not the answers. There's also a question mark icon on each question that has help.
    • [Eric] It seems to work well.
    • [Ian] I got Carl to check it over as he raised the issue originally. He felt it was OK now. I tried the 'sticky' option Brad suggested, but this javascript module doesn't allow you to drag the pop-up once it's stickied.
    • [Heiko] I felt that sometimes 5 seconds maybe wasn't long enough.
    • [Ian] I know, but all you need to do is move the pointer a little to get it back.
    • [Heiko] OK.
    • [Ian] Heiko has posted a number of comments on the survey. The first was about mixing the use of the terms 'JTAG' and 'Boundary Scan'. They don't necessarily mean the same things to different people.
    • [Eric] I prefer 'Boundary Scan', myself.
    • [Tim] I look at it as when I'm exercising the pins on the device boundary, then it's 'Boundary Scan', but for programming a device, I'd call it 'JTAG'.
    • [Brad] If you speak to our software people about 1149.1 then they say "Oh, that's for test", but for JTAG they'd be thinking about emulation!
    • [Ian] I guess I need to review the usage within the form, and maybe add some kind of explanation.
    • [Brad] That should go on the Landing Page for the survey, I think.
    • [Ian] Yes. I'll review the form and add something to the Landing Page to help with the interpretation {ACTION}
    • [Ian] The next thing was adding "Don't know" options to questions 5.7 - 5.9: I felt that for these, if you didn't know, then it wasn't important to you so the appropriate answer was "No".
    • [Heiko] I agree with that, now.
    • [Ian] In question 8.1, which asks which Use Cases people might apply, should we allow an "Other" response?
    • [Eric] We're open to suggestions aren't we?
    • [Ian] I just feel that we'd then have to decide, with limited background, whether it's really a new Use Case or an existing one described differently.
    • [Brad] I've been thinking about these Use Cases since maybe 1990, so I'd be surprised if anyone really comes up with a new one now!
    • [Ian] I'm happy enough to add the option.
    • [Brad] This was really about trying to find which were the most important Use Cases for the core standard.
    • [Ian] And I guess anyone who's read and absorbed the White Paper should get the right Use Cases, and it ought to be fairly easy to detect the people who haven't and weight their responses accordingly.
    • [Brad] I can see someone who uses GNAT thinking that it doesn't fit any of those, while it's really in Configuration/Tuning/Instrumentation.
    • [Eric] Just leave the question as it is.
    • [Brad] Yes, I'd agree.
    • [Ian] Time has beaten us again. There a couple of placeholder pop-ups on question 7.5 and 7.6. I'll continue the action to think about those.

5. Schedule next meeting

Schedule for October 2009:
Monday October 19, 2009, 10:30 AM EDT
Monday October 26, 2009, 10:30 AM EDT (2:30 PM GMT)

Eric may be absent for a two week period late October or early November.
Patrick may be absent on 19th.

  • [Ian] Hopefully, Carl will send out new Outlook Meeting Reminders to begin from 19th October. The Meeting ID number, and WebEx URL will most probably change, so remember to use the right ones. Once I get the details, I'll make sure they're included in my next calling notice.

6. Any other business

  • [Ian] I enquired about interest for an SJTAG Fringe Meeting at ITC. It seemed that our likely attendance was between two and five people and that didn't justify requesting facilities, so I advised that we would not seek a meeting this year. People generally just don't seem to have any travel budget this year, so I feel ITC itself may not have good attendance.
  • [Heiko] I have similar concerns, from a vendor perspective.
  • [Ian] It's sad that SJTAG doesn't have any obvious presence for ITC this year; no paper, no poster and no fringe meeting. Hopefully things will improve next year.

7. Review new action items

  • Brad: Supply details of BTW paper on Fault Injection simulation {Completed by e-mail during meeting}
  • Ian: Review use of the terms 'JTAG' and 'Boundary Scan' throughout the survey and add interpretation on use to survey landing page.

8. Adjourn

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

Respectfully submitted,
Ian McIntosh