Meeting Minutes - 2010-12-13

Minutes of Weekly Meeting, 2010-12-13

Meeting called to order: 10:36 AM EST

1. Roll Call

Eric Cormack
Ian McIntosh
Patrick Au (left 11:22)
Heiko Ehrenberg
Carl Walker
Brad Van Treuren
Brian Erickson (left 11:20)
Adam Ley (joined 10:43)
Tim Pender (joined 10:45)

2. Review and approve previous minutes:

12/06/2010 minutes:

  • Updated draft circulated on 12/08/2010.
  • No corrections noted.
  • Patrick moved to approve, seconded by Brad, 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 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
  • All: Review 'straw man' virtual systems and notes on forums:
    http://forums.sjtag.org/viewtopic.php?f=29&t=109. - Ongoing
  • All: Add to, or comment on, the bullet point list of architecture drivers. - Ongoing.
  • All: Provide forum comment on the graphics used during the meeting; suggest "building blocks" that may be used in future:
    http://forums.sjtag.org/viewtopic.php?f=29&p=257#p257 - Ongoing.
  • ALL: review / comment in preparation for upcoming meetings. - Ongoing
  • Tim: Draft matrix of SJTAG features against evolving solution options. - Ongoing.
  • All: Post suggestions for key SJTAG gateway features on the forum (Ian will create topic) - Ongoing
  • Carl: Contact Zoe about what material we could obtain for our use. - Ongoing
    [Carl] no feedback from Zoe yet; Carl will ping her again;
  • Ian/Brad: Condense gateway comments and queries into a concise set of questions. - Ongoing
    [Brad] not complete yet
  • All: Revisit Gateway properties for next meeting. - COMPLETE
  • All: Email any ideas for Newsletter content to Ian. - COMPLETE
  • Heiko: Post Gateway environment discussion on the SJTAG forum. - COMPLETE
  • [Ian] I think we can try to clean out some of the old or redundant actions as part of our first meeting in 2011.

4. Discussion Topics

  1. Gateways - continuation from 12/6
    • [Ian] I suggest we continue the discussion from last week.
    • [Ian] You went through the complete slide set last week, didn’t you Brad?
    • [Brad] Yes.
    • [Ian] Was there a specific point in the discussion where you guys left off and we could continue today?
    • [Brad] The discussion kind of dried out towards the end of the meeting.
    • [Heiko] We were talking about the environment of Gateway devices, in order to identify key characteristics that need to be addressed in SJTAG.
    • [Ian] There was mentioning of standard voltage parameters for Gateway interfaces; is this something we really can standardize in an IEEE standard or is that something left up to implementers?
    • [Patrick] It would be difficult to standardize; technologies keep changing.
    • [Brad] I don't think it's for an IEEE standard. But there will be industry standards: In the case of the µTCA and ATCA they're already declaring standard voltages for their interfaces.
    • [Ian] OK, that addresses the concern I was having: Module interchangeability will be covered by the standards or specification of the system, not SJTAG.
    • {Adam Ley joined}
    • [Brad] at the end of last week’s meeting we started talking about hierarchy and got hung up a bit with 1149.7. And there was a comment that you made by proxy, Ian, that some people may use branches to control multidrop.
    • [Ian] As I said, I wasn't recommending that, but I've seen where we used COTS boards that didn't really fit the topology of the rest of the system, so we hybridized it by tucking them away on their own branch.
    • [Ian] Thinking about that made me realize that the topologies we have talked about previously are really just advisory examples, and people may need to find innovative solutions for their own problems.
    • [Ian] And with the mention of Dot7 - Is that something that we need to encompass within SJTAG or is it just something that we refer to?
    • [Brad] I think we need to be more than just aware of 1149.7; it needs to be an integral part of our system concerns providing the infrastructure to support it. We can't just defer everything to the Dot 7 standard; there's a piece above it that's missing as far as testing in the system goes. I have the feeling that tool vendors will be looking to users to define how we are going to use Dot 7, as it will affect the tooling that's needed.
    • [Ian] I'd guess that the level of treatment will be similar for P1687 then?
    • [Brad] Yes and no. There's a difference in that 1687 is isolated into a single device, and it doesn't affect the netlist as we recognize it. There's a separate definition for the instrument access - there's more info to digest, just like our discussion that system architecture sits in some high- level description document.
    • [Ian] Once you decide to support hierarchies, are you committing to support some infinite level of hierarchies?
    • [Brad] Well, maybe it was you who mentioned that there might only be a need for around 6 levels.
    • [Ian] Yes, in an old Marconi Electronics group Systems Engineering course there was an exercise where they hierarchically decomposed a submarine until they got to component level. I think it was 6 levels, or at least of that order.
    • [Ian] But, to support one level of hierarchy is one thing: As soon as you decide you want two or more levels of hierarchy or recursion then it seems that it makes no difference algorithmically how many levels you then extend to.
    • [Brad] Yes, that's what I feel too.
    • [Brian] I look at recursion, as in logic synthesis, as something that can be difficult, but subfunctions can be easily handled.
    • [Brad] In P1687 there was debate over whether it needed a functional interface or a structural interface. In the end they settled on something in between. There was many months of debate.
    • [Ian] The key thing here is the control of the Gateways; being able to select the paths, etc., without needing to know what devices are involved.
    • [Brad] Things like the I2C control are all just logic mechanisms. The decisions are made in external tooling.
    • [Brad] Dot 5, when it was active, relied on some intelligent host. When you look at papers like some of those Gunnar presented in 2005, he was putting intelligence on the board to do some of the delegation. That's something we haven't even considered.
    • [Brian] Maybe that's for Dot 2.
    • [Brad] Yes. It's also why I'd like some of the automotive people involved, as they're using distributed systems. Of anyone in this group, maybe your work is closest to that, Ian.
    • [Brian] My expectation is that once we get to a Dot 1, then we'll see a broader scope of people wanting to be involved: "Hey, you forgot this!", "No we were just waiting for you to come on board."
    • [Ian] Yeah, you can look at a radar system and see it composed of several boxes: Transmitter, Receiver, Processor, but each box can be considered a system in it's own right, even some of the modules would be a "system", by some people's standards.
    • [Ian] But, I think that most complex systems could really be described that way.
    • [Brad] I agree. A lot of boards in the Comms field have a FPGA path or DSP path: Some boards will now have 8 paths or maybe even 32 paths through the same board to get the data density up. So the conventional concept of the FRU is becoming fuzzy, as a DSP can fail, but the board is still functioning properly.
    • [Ian] Redundancy and self-recovery is an important issue: This is getting a bit off-topic, but while it's often desirable to have these features for robustness they can get in the way of testing. For example, ECC RAM can protect you from a level of failure, but if you're not aware that correction is going on you might suddenly be faced with a catastrophic fail. Degradation needs to be reported for prognostics.
    • [Brad] Delineation about where hierarchy starts and ends is becoming fuzzy because of the way systems are architected. Maybe that what's making it difficult for us to wrap our hands around it, and is part of why I started looking at the building blocks, to try to get to a core set of capabilities that people could recognize.
    • [Tim] Hierarchy could be handled pretty easily with addressing schemes, at least with some protocols like the TI ASP protocol.
    • [Brad] That was some of the premise in the Brocade paper, using I2C for addressing. They talk of configuration management rather than addressing, and it doesn't really matter where that configuration is taking place.
    • [Brad] From an SJTAG perspective, I think the real goal is what is required to perform a specific operation within a particular system configuration rather than a specific scan chain.
    • [Ian] So it's mainly a difference in terminology.
    • [Brad] And in perspective; they viewed systems less as hierarchy and more as configuration of modules.
    • [Ian] I think we’ll close this discussion here for today and move on to other matters.
    • [Tim] Brad, is there a link to this paper you are referring to?
    • [Brad] This was an ITC paper (ITC 2006 paper 10.3). I think we have referred to it in previous minutes.
    • [Ian] I think so, or possibly on the forums.
  2. Academic involvement in SJTAG: Research challenges
    • [Ian] I haven't taken this any further yet. I was hoping to talk with Michele about his suggestion a bit more. I have a couple of people at Heriot Watt University I can approach if I have the right kind of lure - they're often looking for something practical for the PhD students to do novel research on.
    • {Patrick left the meeting}

5. Schedule next meeting

  • [Ian] does anyone have problems continuing with the same day of the week, at the same time?
  • {nobody voiced concern}
Schedule for January 2011:
10th
17th
24th
31st

No meeting on 3rd as several people will still be on vacation.

6. Any other business

The motion on signal naming conventions from the meeting of May 3rd remains tabled.

7. Review new action items

None.

8. Adjourn

Eric moved to adjourn at 11:31 AM EST, seconded by Tim.

Thanks to Heiko for supplying his additional notes this week.

Respectfully submitted,
Ian McIntosh