Meeting Minutes - 2010-09-20

Minutes of Weekly Meeting, 2010-09-20

Meeting called to order: 10:37 AM EDT

1. Roll Call

Carl Walker
Ian McIntosh
Patrick Au (left at 11:00)
Michele Portolan
Brad Van Treuren
Brian Erickson
Adam Ley (joined 10:39)
Heiko Ehrenberg (joined 10:39)
Tim Pender (joined 10:45)

Apologies:
Eric Cormack
Peter Horwood

2. Review and approve previous minutes:

9/13/2010 minutes:

  • Three corrections noted, all in section 4a:
    • 'thopugh' should be 'thought',
    • 'wnat' should be 'want',
    • 'propety' should be 'property'.
  • Motion to approve with the above amendments by Brian, 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 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
  • All: Post suggested draft texts for survey comments in existing 2009 Survey thread (http://forums.sjtag.org/viewtopic.php?f=32&t=83) - Ongoing
  • Carl: Contact Zoe about what material we could obtain for our use. - Ongoing
  • Ian: Copy Brad's model code onto a forum post. - COMPLETE

4. Discussion Topics

    1. White Paper Volume 3 - Key Gateway Features:
      • [Ian] There have been no replies to the forum post of Brad's model. I was hoping that a week's interval to absorb this might have brought forward some comment.
      • [Brad] I just need to say that it was a discussion point and not a true model.
      • [Ian] Was this helping or was just confusing?
      • [Patrick] It is quite steep!
      • [Ian] Undoubtedly.
      • [Brad] I was trying to find a way to come to some common ground. We don't seem to have a language set that allows us to communicate effectively.
      • [Ian] Yes, we've tried a few different things and seem to keep getting stuck. We were doing pretty well with the PowerPoint slides until we hit the gateways.
      • [Brad] Where we ran into trouble was trying to deal with gateways as an abstract; I'm not even sure if we can genericize gateways.
      • [Ian] It's possibly the breadth of gateway types that's causing some of the problem, and making it hard to get a hold of.
      • [Brad] I'd like to hear from the tool suppliers on this. There seems to be lots of unique ways to deal with gateways in the tools. For In Circuit Test, support becomes nearly impossible. There must be some insights here that we're missing; some reason why you can't make this generic.
      • [Brad] I guess HSDL tried to genericize it with the concept of the Dynamic Path, but is that maybe as much as we can do?
      • [Brian] I have to apologize, because I'm driving so it's difficult for me to get into something as deep as this right now.
      • [Heiko] I'm not sure I fully understand the problem. We define the end chains then the software takes care of the selection protocol. There are models in the software to deal with specific devices.
      • [Brad] If you have I2C to select the path, as I think Brocade described in their paper (Reusable, Low-cost, and Flexible Multidrop System JTAG Architecture, ITC 2006), are there some common properties with other protocols?
      • [Heiko] No. We wouldn't really have a way to handle that easily right now. We don't have a generic model.
      • [Brad] I think that's probably a common issue with all the tools. You need to provide a model for a device type and that gets used by the tool set.
      • [Brad] When we were discussing the building blocks we were showing the bypass element. That's somewhere where you'd definitely need to have parameterization in the model, to define the number of secondary ports. Some devices may have 12 or more.
      • [Heiko] How that is modelled in our software, I don't know.
      • [Brad] Maybe that's the issue: People here don't know how the internals of their tools operate.
      • [Ian] Well, I wonder if maybe a lot of people don't really want to know how the tools work; they just want to push a button and be given something that works.
      • [Heiko] That is what people mostly want, in my experience.
      • [Ian] And even for a given device there may be multiple ways one can configure it, that may or may not be supported by the tools you have. A few years ago, working with ScanBridges one of our design ended up with a configuration of devices that was perfectly legitimate but the tools became confused and we had to pre-engineer some files to give the tools a head-start. Had we used an alternative arrangement the tools would have recognized how to negotiate the devices automatically.
      • [Ian] The you have other features or states or modes to deal with, like the Firecron JTX crosspoint capability where primary and secondary designation can swap over, or transparent pass-thru modes obviating the usual selection protocols. Maybe there are too many variations to deal with?
      • [Brian] Do we need to come up with classes of gateway?
      • [Brad] If you mean classifications, then that may be something we can use. If you mean object classes like we discussed in the model last week, then no.
      • [Brian] I meant classifications, types of gateway. Maybe we can find commonalities if we can divide things into, say, linkers, scanbridges, etc.
      • [Brad] Or what are the properties that the tooling has to have to handle these devices? Or is it the case that tooling has to have unique models for each device?
      • [Adam] We have to be realistic here, in that the tooling has grown rather organically over the years.
      • [Adam] I think looking at the tooling is going the wrong way. It can adapt; the fact that it doesn't do something now, doesn't mean that it can't do it.
      • [Brad] The problem is that we've tried to go down other routes, but can't get progress. I wanted to see if we can leverage what we have in the tooling today.
      • [Adam] I can speak only for myself, but I don't have enough direct experience of the implementation to comment on this; I can speak a little to the generic issues, but can't get into that level of detail. I could take a couple of weeks to research the answers or I could pull someone in. Kevin Fotheringham is probably our best expert on gateways. Even better would be to distill down a couple of questions that I can pass on.
      • [Brad] Thanks for the honesty. I think that confirms something Ian and I have been thinking over the last week; that of the constituents here, we have a good understanding of the problem domain space, but not of how the tooling works.
      • [Brad] Maybe the best approach is to draft a set of questions, not just for the tool suppliers but for the users: What is difficult to describe about a gateway?
      • [Ian] I think some tools will deal with specific issues better than others.
      • [Brad] Well. I know that features available in one toolset are not even present in another. What I'm very conscious of is that we can't dictate what the models look like. I know that it's not always easiest to add in an enhancement.
      • [Ian] My view was that was maybe partly behind JTAG Technologies ProVision: That the "classic" were getting trickier to extend.
      • [Brian] I understand that the newer tools still rely on the same basic principles.
      • [Brad] Fundamentally, we have be doing the same thing across tool sets, although individual implementations will differ.
      • [Brian] How do we draft this set of questions?
      • [Brad] Good question!
      • [Ian] I'm inclined to direct this strongly to the group as a whole, and ask that everyone presents at least one suggestion here, as part of a group action. Asking people in a nonspecific way to post suggestions on the forums never seems to elicit any response. I'd suggest emailing any items to me although we could use the forums?
      • [Tim] I think email. If you see something already posted then it may affect what you write.
      • [Ian] I'd agree on that.
      • [Brad] I'm still concerned with this broad spectrum of classifications, and maybe we should be focussing down onto specific devices for this week.
      • [Brad] I still don't know how we can deal with abstracts. I'm sure if we said 'scanbridges' that would bring specific things to mind for the people here.
      • [Ian] OK, to try to formulate an action, which classifications do we think are most popular?
      • [Tim] What about listing the classes?
      • [Brad] The ScanBridge protocol covers multiple vendors and IP, but I have more experience with ASP.
      • [Tim] Same for me.
      • [Tim] A third class would be the SJTAG gateway.
      • [Ian] Well it's trying to describe it that's giving us difficulty.
      • [Tim] Yeah, but I mean what we think it ought to be for SJTAG.
      • [Ian] But it's a relevant point. To get SJTAG principles adopted we need to cope with the legacy designs, as current technologies aren't about to just go away.
      • [Brad] Are there elements we can describe in a generic way that relates to what exists now?
      • [Ian] For the action, we want questions or issues associated with using either Scanbridges or ASP with the commercial tooling. From those we can then try to formulate a set of questions for the tool suppliers. {ACTION}

 

  1. Texts for Survey Result web pages
    • {Forum post shared: http://forums.sjtag.org/viewtopic.php?p=294#p294}
    • [Ian] I made a start on drafting up some text, working from the minutes of when we reviewed these results. Basically just a one paragraph comment.
    • [Ian] Given the time, I don't think we can really start to discuss this today, but I just wanted to put this out. Hopefully next week we can review these and maybe agree to add them to the webpages, and begin to work our way through the others.

5. Schedule next meeting

September 27th - Eric will likely miss

Schedule for October 2010:
4th
11th - Heiko will likely miss
18th
25th

6. Any other business

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

7. Review new action items

  • All: Each person to submit at least one issue or query arising from their own experiences of using either a scanbridge protocol device or an ASP device. Email to Ian.

8. Adjourn

Tim moved to adjourn at 11:33 AM EST, seconded by Heiko.

Respectfully submitted,
Ian McIntosh