Minutes of Weekly Meeting, 2011-06-06

Meeting called to order: 11:05 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Patrick Au
Harrison Miles
Carl Walker (left 11:56)
Adam Ley
Peter Horwood (left 11:47)
Richard Foster
Brian Erickson
Tim Pender (joined 11:07)
Brad Van Treuren (joined 11:09)

2. Review and approve previous minutes:

05/23/2011 minutes:

  • Draft circulated on 05/24/2011.
  • No corrections noted.
  • Motion to approve by Eric, seconded by Patrick, 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?
  • 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: Condense gateway comments and queries into a concise set of questions. - Ongoing
  • All: Forward text file to Ian containing keywords from review of meeting minutes. - Ongoing.
  • Carl/Brad: Get annotated keyword worksheets to Ian by Wednesday Close of Business. - Ongoing
  • All: Consider how a keyword can be used to define the chain configuration for a given test step, and what that keyword might be.
  • Ian: Send Patrick newsletter extract on ITC 2011. - COMPLETE

4. Discussion Topics

  1. Chain Dynamics
    - Is the multiple BSDL problem a special case?
    - Is 'Dynamics' too vague a term?
    - Can dynamics be modeled hierarchically?
    Ref:
    - http://www.sjtag.org/minutes/minutes080827.html
    - http://forums.sjtag.org/viewtopic.php?f=3&t=77
    • [Ian] Towards the end of the last meeting I asked if maybe the multiple BSDL problem was a specific case, and we risked losing sight of a broader issue of 'dynamics'. It could also be that there are very diverse things we're using the term 'dynamic' to describe, so maybe there's better terminology. Since then I've also looked back at some older material where we talked about 'assemblies' as a generic term when discussing hierarchies: I was starting to wonder if some things we see as dynamic at chip level scale up through boards and systems or vice versa.
    • [Brad] Last time I think we were realizing that there are issues that fall outside of BSDL but appear to have similar problem space. There can be a different perspective depending on what you're looking at.
    • [Brad] It was good to note from our discussion on dot7 last time that it is dealing with some issues as being outside of the standard. I think SJTAG is going to be faced with needing to deal with those things.
    • [Ian] I think what we'd hoped to get to was a generic description, some way of modeling things that would translate into tooling.
    • [Brad] I'm not convinced that there's a generic, abstract way. We've tried several times to do that and failed: We tried to look at it for a particular device, through the Use cases, from the perspective of the technology. We haven't been able to define what are the properties required in a description to do a particular job. We've not been able to define the problem space well enough.
    • [Harrison] I'm assuming you're coming from a testing perspective, or is it more than testing?
    • [Ian] It's part of the remit we've given ourselves, through the use cases we have defined, to address more than just testing.
    • [Harrison] If that's the case then it's more of a problem than if you just consider test.
    • [Brad] This is where I struggle, as 'test' means so many different things, e.g. BIST, or performing MBIST in a particular ASIC where the board power won't support all the blocks running simultaneously - That's where we get into more complicated problems. It's more than just the structural test.
    • [Harrison] OK, I'm trying to slice it up. I wanted to try someplace where it's reasonably atomic.
    • [Harrison] BIST is probably only ever useful before power up.
    • [Brad] Some will want BIST in POST and some will want it after.
    • [Harrison] From discussion with the silicon vendors, most on-chip BIST is not designed to solve problems outside of the package; it's not designed to solve problems after the power-up.
    • [Brad] I disagree, There can be the case where you run a board to a known state so you can use BIST.
    • [Harrison] I'm separating what you want to do from what it was designed to do, and most BIST is not designed to do what you want to do.
    • [Ian] Well I see that there's a need to scale BIST up beyond the chip level, through boards and up to the system level. Clearly there are times you'll want to run a self test on a system.
    • [Brad] There's not a binary solution. You need to consider the domain of the board; the states the board may be in - off, powering-up, offline, online will determine what tests are possible.
    • [Harrison] I think it scales back. Once a device becomes more operational it becomes more dependant on other things.
    • [Brad] A board may, through usage or over time, go into a sleep state.
    • [Harrison] Smart 'phones probably fall heavily into that, while a lightweight example might be a server blade. In other segments it may not even be true; different domains have different drivers.
    • [Ian] Every case is probably different. Does that mean that we can't easily get to models of the problem space that can be used to direct tooling?
    • [Brad] Well, it's why I don't think you can have a base class that you can derive all your solutions off.
    • [Ian] I'm thinking of general 'methods' but without the detail of exactly 'how'; a bit like being unable to tell someone exactly how to decipher a coded message, since every cipher is different, but you can tell them how to work out what they need to do.
    • [Brad] A year ago we wouldn't have considered the BSDL problem, so we've gotten smarter.
    • [Harrison] A complexity is the stages: 1149.1-2011, P1687 are things that are precursors for what we're trying to do.
    • [Ian] Certainly, they're exposing things that we need to consider.
    • [Harrison] You can kind of take the cases of Xilinx and Altera where at the top of their lines they're starting to look at instrumenting their designs. You can do all the synthesis and modeling but the customer wants to know if the design is working on the board.
    • [Harrison] Part of making SJTAG work is to push for silicon vendors to instrument their devices. Now the question becomes how do you orchestrate across vendor domains. Then you have the possibility of scaling.
    • [Harrison] While a device is offline you can ask 'Can I do an assessment?' Then the BSDL problem becomes incidental.
    • [Harrison] You'd have a menu of instruments, but to begin with these wouldn't be autonomous, they'd be primitives and would need human intervention.
    • [Brad] To clarify - Are you proposing that all problem spaces can be put into a collection of instruments?
    • [Harrison] The Go/NoGo structural assessment could be done that way. Does the board still have the same characteristics as when it left the factory? This is solving the structural problem not the design problem.
    • [Ian] It seems to me that we might be replacing the BSDL with an instrument description.
    • {Peter left, 11:47}
    • [Brad] I'm just trying to see something we said before when we looked at the primitives; we had cells that made up a data register or an instruction register and then ended up as a 'scan chain segment'. An Instrument gives that a lot more personality.
    • [Harrison] You have to know what the instrument is and then give an interlocking description for it. P1687 and its ICL give you some of that, so what you want to achieve here inherits that.
    • [Brad] There are also different mechanisms in dot7, for the linkers, for the gateways, etc.
    • [Harrison] OK, but dot7 was solving in a different world; what drove dot7 doesn't drive P1687.
    • [Brad] But SJTAG needs to do all of those.
    • [Harrison] But it doesn't need to be that. Dot7 was for the low pin count, P1687 was looking at FPGAs and ASICs.
    • [Brad] Look at examples of 1500 and there's an overlap of domains.
    • [Harrison] 1500 could have been dot7. The key thing is that SJTAG needs to take more advantage of P1687 than of dot7.
    • [Ian] OK, with that, I think we maybe need to leave this for this week.
    • [Brad] And you thought we'd have nothing to talk about this week!

5. Key Takeaway for today's meeting

  • [Brad] May require a unique solution for each problem space.
  • [Brad] May need to revisit what we term as a 'SJTAG leaf element'.
  • {Carl left 11:56}

6. Schedule next meeting

Next Meeting:
June 13th (11:00 AM EDT, 4:00 PM BST)

Schedule for June 2011:
13th, 20th, 27th.

7. Any other business

None.

8. Review new action items

None.

9. Adjourn

Tim moved to adjourn at 11:58 AM EDT, seconded by Eric.

Respectfully submitted, Ian McIntosh