[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-06-22

Meeting called to order at 10:36 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Brad Van Treuren
Carl Walker
Adam Ley (joined 10:40 AM)
Heiko Ehrenberg (joined 10:40 AM)

Excused:
Brian Erickson
Tim Pender

2. Review and approve previous minutes:

6/15/2009 minutes:

  • Draft circulated on 15th June:
  • No corrections were noted.

Brad moved to approve, Eric seconded, no objections {the vote was taken after Adam and Heiko joined the call}.

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 (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
  • 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
  • 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 question(s) for row 21 based on Brad's previous graphic. - Ongoing.
  • Ian/Brad: Construct new question(s) on gateway devices (linkers, bridges, instrumentation gateways). - Ongoing.
  • All: Review draft 2009 survey form and comment through forums:
    http://www.sjtag.org/survey/forms/form1.html
    http://forums.sjtag.org/viewtopic.php?f=32&t=83. - Ongoing.
  • Heiko/Ian: Make amendments to Volume 2 to reflect discussion - COMPLETE.

{Adam and Heiko joined the call at this point}

4. Discussion Topics

  1. White Paper Review
    • [Ian] Heiko made most of the changes to Structural Test, Config/Tuning/ Instrumentation while we discussed them last week. I've since added in the references to GNAT and NEXUS-5001 that were suggested.
    • [Ian] I also note that Heiko has been busy making updates to some of the Use Cases we'll discuss today.
    • [Heiko] I just changed these around in the same way as last week's discussion suggested.
    • [Ian] Have people had a change to look over the changes? Are there any further changes needed?
    • [Brad] I think it's much improved. It looks a lot more robust now.
       
    • BIST
    • [Ian] The opening paragraph describes BIST as a Functional Test. Do we wish to preclude structural tests here?
    • [Adam] I'd go so far as to say that BIST is expressly not a functional test. It goes above and beyond "normal function". BIST on chips is typically aimed at detecting structural defects but at speed.
    • [Eric] The key thing that Adam mentioned is that BIST primarily involves at speed testing.
    • [Adam] It tests in semifunctional way, but on sub-blocks of the functionality.
    • [Brad] The other piece here is hierarchy and a modular structure. There may be multiple BIST blocks within a device, a super-BIST block for boards. So it depends on where the BIST is located.
    • [Brad] Modern BIST can offer gains from concurrency and modularity, as a lot of testing is traditionally done sequentially, so that's part of the Value Proposition here.
    • [Ian] So we need to reword the first couple of paragraphs here to capture those ideas.
    • [Brad] You can say that BIST is self-contained testing.
    • [Carl] If I understood, we're saying we can start testing of similar blocks in parallel?
    • [Brad] Look back at Gunnar's example with 50+ MBIST blocks. They can't all be run at once due to power limitations, but a number can be kicked off together.
    • [Ian] I guess those power issues could apply elsewhere. Ground bounce can be a problem in structural test because you could be exercising many more nets simultaneously than you might do during mission operation.
    • [Brad] We don't have anywhere in this template for "consequences" - in this case we need to be aware of power implications. In software design patterns you tend to have "positives" and "consequences".
    • [Ian] I feel "Consequences" may not be the best title but it will do for the present.
    • [Brad] It may be worth noting that BIST may not give as detailed a diagnostic as some other tests.
    • [Ian] Yes, sometimes it's just a single status pin.
    • [Brad] Should we get into how BIST is driven? Non-scannable devices having BIST controlled by nets connected to scannable parts.
    • [Ian] That may be part of an expansion on the Detailed Description.
    • [Brad] You want to be able to build up validation of modules into larger modules.
    • [Ian] In the "Alternative Techniques" you might have a CPLD that initiates BIST blocks and monitors returns.
    • [Brad] Yes, the Alternatives should concentrate on alternative means of controlling BIST rather than alternative types of test. Software or firmware enabled register sequences, maybe I2C capabilities.
    • [Ian] Some of the mission bus devices we use, like MIL-STD-1553B chipsets, may include BIST and loopback testing but have no JTAG.
    • [Brad] We need to show readers that we've done thorough analysis and have understood the problem domain.
       
    • Fault Injection
    • [Ian] I guess one thing from last week we didn't pick up on in the wiki edits was the issue of overlap between Use Cases. I don't know that there's an easy way to document that.
    • [Brad] Looking at the first paragraph: Is it really nonintrusive?
    • [Adam] It's a nonphysical means of inducing a fault.
    • [Brad] Yeah, that's better because the fault is certainly intrusive!
    • [Ian] The amin point in this Use Case for me was that the alternative generally means attaching wires to the board, which means the technique isn't really usable under environmental test conditions.
    • [Brad] The soldering operations can life the board.
    • [Carl] And for EMC, you don't want all those extra antennae.
    • [Brad] Our main use of Fault Injection is to show that software gracefully recovers from a fault condition.
    • [Ian] I don't think the description really brings out the software aspects; it implies more relevance to the hardware.
    • [Carl] Although the Detailed Description does mention software.
    • [Ian] Yes, but it's only one word. I think the significance might easily be lost on many readers.
    • [Brad] Also, we can do more that the "stuck at" faults.
    • [Brad] Do we go into various alternative implementations? May have some features designed in at pin level, or have additional devices fitted to provide fault stimulus or may have signals routed through programmable devices for fault injection.
    • [Ian] Those are things we can add to the Alternative Techniques. But I guess our value add comes because we don't need extra components so we don't take the reliability hit of increased component count; we can offer the same facilities without changing the design.
    • [Brad] Yeah, so every module is fault injection ready.
    • [Brad] EXTEST is OK but it's missing HIGHZ
    • [Ian] I guess we'll need to leave it there, our hour has gone by quicker than I realised!

  2. 2009 Survey
    • [Ian] I've added a couple of questions on gateways to the survey but I'm not particularly happy with them.
    • [Ian] I need to spend some time getting the form processing and database side of things set up, so I'd be keen to see the list of questions finalized, although the order and answer options aren't so important.

5. Schedule next meeting

Schedule for June 2009:
Monday June 29, 2009, 10:30 AM EDT - Tim cannot attend
  • [Ian] Is 6th July likely to cause problems?
  • {Carl, Brad and Adam all indicated that may not be able to attend on that date}
  • [Ian] OK, maybe it's best to skip the 6th and go for 13th, 20th and 27th July?
  • [Brad] I'd go along with that
  • [Carl] My Outlook reminder expires on 29th June. I can set up a new one starting on the 13th.
  • [Ian] Please do, Carl.
Schedule for July 2009:
Monday July 13, 2009, 10:30 AM EDT
Monday July 20, 2009, 10:30 AM EDT
Monday July 27, 2009, 10:30 AM EDT

6. Any other business

None.

7. Review new action items

  • Heiko/Ian: Make amendments to Volume 2 to reflect discussion on BIST and Fault Injection.
    (Other members may contribute if they find time to help)

8. Adjourn

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

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.