Minutes of Weekly Meeting, 2012-10-29

Meeting called to order: 11:08 AM EDT

1. Roll Call

Ian McIntosh
Patrick Au
Carl Walker
Brad Van Treuren
Brian Erickson
Heiko Ehrenberg (joined 11:11)

Eric Cormack

2. Review and approve previous minutes:

10/22/2012 minutes:

  • No corrections advised to updated draft sent October 22.
  • Brad moved to approve, seconded by Patrick. No objections or abstentions.

3. Review old action items

  • 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
  • Ian: Contact Bill Eklow regarding use of the ITC mailer to promote an SJTAG Fringe Meeting at ITC. - Nothing more to report. Close, as ITC is only a week away.
  • Heiko: Prepare SJTAG poster for ITC and send out a draft for review/comments. See Discussion 5a.
  • Harrison will attempt to come up with a table of use cases and their associated layer and what can be done at that layer. See Discussion 5b.

4. Reminders

  • Consider Adam's three points (from the action from the first weekly meeting) and suggest what is preventing us from answering those questions:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?

5. Discussion Topics

  1. ITC Poster - What do we present this year?
    • {Draft poster shared}
    • Heiko had circulated two drafts prior to the meeting, this was the later one, but still did not include the comments that Brad had sent by email. Since the first draft, Heiko has added a small box to explain the SJTAG goals, and has merged the four larger boxes into two.
    • Brad explained that his comment on firmware was to help illustrate why there may be different firmware versions. His other comment was to highlight that applications may be run at more that the two conditions of 'power-up' and 'running'. Heiko was happy to incorporate those changes. It was agreed that the latter of Brad's suggestions should be shown as a sub-bullet.
    • Heiko will update the poster and get it sent out, requesting final comment by the end of the week. Ian felt that at this stage there was little opportunity to review new suggestions so comments should maybe be restricted to correcting errors.
  2. Explore if and how we can map to/from an architecture via a 'cube model' (different perspectives).
    • Ian suggested that the idea of the 'cube model' needed some consideration of how it was to work. It presently seemed like an idea that did not yet have a real means to work with it; this was probably something that would develop as we explore it. So far we had identified that it probably had a Functional facet and a Structural facet.
    • Brad felt that Harrison's table (from the previous meeting) would be part of the workings of the cube, and noted that a Layers column needed to be added to the table.
    • {Slide showing table shared}
    • Ian wondered if we were somehow suggesting that the Layers were orthogonal to Structural and Functional Test. Brad referred to the graph on Harrison's third slide and explained that his interpretation was that at the bottom right the blue line represented the lower Layers while the top left was the higher Layers.
    • {Graph slide shared}
    • Brad added that the he saw the X-axis as Structural Test (Is it assembled correctly?) and the Y-axis as Functional Test (Is it operating the way we expect it to?) with Harrison's second bullet reinforcing the notion that 'Non-functional Test' was equivalent to 'Structural Test'.
    • Brad viewed that the two facets in the cube model would have intersections and that this may be why Harrison seemed to have difficulties with the table on slide two. Ian noted that a Structural Test and a Functional Test could be near identical: For example, reading a temperature sensor could be used to check that the sensing device has been assembled on to board correctly and also used operationally to monitor temperature. The operation is the same in both cases but the end objective is different.
    • Considering EST, Brad reiterated that structural test can permit faster execution during ramp times and when a BIST in modular form is implemented then it allows parallelism to further improve test times. Ian noted that externally driven tests will tend to be serial in nature, although parallel execution becomes possible when the boards in the system support some level of autonomy. Brad remarked that this was why he was keen to use an architecture that incorporated intelligence. This also helped to allow for power states of the boards. Ian felt that the power up sequence would often be determined by the design of the system. Brad disagreed, noting that contrary to normal operation, the power profiles during test could be quite different. Ian accepted this, citing ground bounce effects that could be observed in JTAG testing at board level due to switching that was far outside the expectations of normal operation, and that it wasn't practical to provision or design for that power profile. Brad added that this was the same issue that Gunnar described in his STAPL++ paper in trying to run 55 MBIST blocks in parallel.
    • Ian noted that we seemed to have concluded that 'Non-functional Test' on the table was what we conventionally know as 'Structural Test'. Brad added that some things were not just about 'observability' but about 'diagnosability' and that diagnosability had different levels as you moved through the table. Ian then wondered if diagnosibility had some correlation to the blue line on Harrison's graph. Brad felt it was related but not 1:1.
    • Another aspect introduced by Brad was that while an intelligent controller may have access to data that would allow a diagnostic, it might not have a way to report it, in which case it becomes a go/nogo test. This was a capability issue that is largely unrelated to the type of test that is being performed. Brad noted that this was the Test Controller and Test Manager domains and Ian suggested that this represented a further facet to the cube.
    • For the next meeting, Brad thought it might be useful to think about the layers. Currently there was not enough detail to be gleaned from the table to consider the cube facets yet.

6. Key Takeaway for today's meeting

  1. The term 'Non-functional Test' seems to be equivalent to 'Structural Test'.
  2. Test Controller/Test Manager represents another facet (perspective) for the cube model.

7. Schedule next meeting

No Meeting on Nov. 5 as that is ITC week. Fringe Meeting at ITC on Thursday, Nov. 8, at 10AM PST.

Next Meeting:
November 12 - Heiko will miss.
Time reverts to 4PM GMT for UK attendees.

November schedule:
19, 26.

8. Any other business


9. Review new action items


10. Adjourn

Brian moved to adjourn at 12:04 PM EDT, seconded by Heiko.

Respectfully submitted,
Ian McIntosh