Meeting Minutes - 2010-09-27

Minutes of Weekly Meeting, 2010-09-27

Meeting called to order: 10:38 AM EDT

1. Roll Call

Carl Walker
Brad Van Treuren
Heiko Ehrenberg
Ian McIntosh
Adam Ley
Tim Pender
Michele Portolan (joined 10:42)

Apologies:
Eric Cormack
Patrick Au
Peter Horwood

2. Review and approve previous minutes:

9/20/2010 minutes:

  • Add the time the Tim joined the meeting as 10:45 AM
  • Motion to approve with the above amendment by Brad, Seconded by Tim, 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
  • 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. - COMPLETE

4. Discussion Topics

  1. White Paper Volume 3 - Key Gateway Features:
    • [Ian] I'm sorry, I haven't had much time to prepare for the meeting today, so I'm trying to pull the submissions into a single place that we can all look at as we speak.
    • [Ian] OK, I've just assembled everything into a text file here.
    • {New1.txt shared}
    • [Ian] First are a couple of bullets from Adam.
    • [Adam] I should say that the first item doesn't pertain to addressable devices.
    • [Ian] We got a few items from Brad; the first is on reusing code across multiple boards where only the slot address differs, the next is retention of secondary port states on deselection to ease reconnection, and the third relates to synchronization across the boards in a backplane, and here I'm tempted to jump forward into the last set of notes, from Heiko, because there is reflection of similar points there.
    • [Heiko] It can be complicated when you have multiple devices. The tests, including control sequences, can be generated automatically, once the behavior of the scan router device (Scanbridge, ASP, etc.) is modeled inside the boundary scan software (which is done by the boundary scan tool vendor). The multi-drop address assignment is currently fixed to a certain location within the hierarchy, that assignment currently needs to be specified by the user in order for the boundary scan software to properly select the desired scan chain(s). Then if you are programming PLD's using SVFs for example, the tools to generate those don't support gateways so the BScan software has to add that in.
    • [Brad] My first point is the motivation behind where we went with our Test Flow Control Language, so we could deal with it as an abstraction, and parameterizing the gateway.
    • [Heiko] Generating the test is one thing, but where to apply the test is another. Currently we generate the test based on statically assigned slot ID’s/multi-drop addresses. So, the test can be applied to a particular system configuration. If a test is generated for a particular board, then part of that board test sequence is also the selection of the appropriate gateway. And if the tool set has a fixed address assigned to the gateway when it generates the test, then the portability of that test is limited (the test would need to be regenerated targeting another slot ID if it is supposed to be run with the target board being plugged into a different slot. So, I guess my concern is more how a test is generated and where the test gets applied within the system hierarchy.
    • [Brad] That's right and it was why I was getting into indirection. There are two situations we need to handle: The first is where it's all statically defined up-front and the other is where things are more dynamic.
    • [Heiko] We can do this by assigning slot codes as part of the description file, but that's not really handling the dynamic case.
    • [Brad] We used to do that. Now we used description that have virtual addresses. Using parameterization, these virtual addresses can be resolved at runtime using a lookup table.
    • [Brad] My second item leads into the third and getting to the issue of some applications that record only whether TMS is 0 or TMS is 1 when you disconnect a chain. But you really need to know more; did you leave it in IDLE or PAUSEDR? So you need to know the state.
    • [Ian] It sounds like the ScanBridges cause more problems than ASPs?
    • [Brad] For test reuse, I'd agree, but generally they're much the same. But some of the issues are the reasons you see things like the I2C controlled parts being proposed.
    • [Tim] Does the ScanBridge allow you bypass the addressing protocol?
    • [Adam] I believe the ScanBridges have Bypass as well as transparent modes, and I assume that the Firecron devices are similar.
    • [Ian] The Firecron parts that we're selecting have Bypass and transparent or pass-thru modes. But those transparent modes are really a work round to aid vendor tools: The synchronization bits are there for a reason, to help keep the TCK rates up when you may have several chains linked.
    • [Brad] I that that was originally there to make them ICT friendly.
    • [Tim] And to keep the designer in labs happy, because if he can't connect to his devices then the gateway will pretty soon come off the board.
    • [Ian] You're right.
    • [Ian] My question was pretty simple and generic one, and that is to ask what it takes to allow the tooling to recognize or use a new or custom gateway: Let's say Tim's selector from his BTW paper, could he define it to the tools in some way or does it need software effort on the part of the tool vendor?
    • [Brad] Well some of things here are what happens when you go through TLR? How does the model handle that? It's these side effect behaviours we need to understand.
    • [Ian] I guess another question I have, and I haven't really thought through the validity of this, is whether what we're trying to do here is really jumping into what should be the tool vendor's job?
    • [Brad] I think we'd be diligent in finding common ways of describing the devices, but the implementation would still be up to the tool vendor; that way they still have the opportunity for the value add. We don't say that 'this is the way your model will work' but 'this is what your model needs to be able to represent'. If they choose to add more then that's fine, but this is the minimum.
    • [Brad] I'd like to ask the tool vendors represented here if they think we're stepping into their area?
    • [Heiko] Anything that makes it easier to get a new part into the software is fine. That's got to be a help.
    • [Adam] I'll largely echo Heiko's statement. I think the emphasis for SJTAG needs to be focussed on outcomes, and not worry about how these map onto tools or even onto specific gateways. The tendency of engineers is to move into the concrete, but we need to stay in the abstract until the issues are understood and documented.
    • [Brad] And can we describe things in behavioral terms: There's some need for describing behaviors as well as connectivity
    • [Brad] All the tool vendors have demonstrated the viability of behavioral modeling, through things like the generation of cluster tests, so it seems very possible to do. Some concreteness is going to be needed but not as structured as the real implementation.
       
    • [Ian] OK, do we think we can consolidate some questions out of this?
    • [Brad] Well, not in four minutes!
    • [Ian] Agreed, so is it workable for Brad and I to try to do that via email?
    • [Brad] I'd need to do anything in the evenings.
    • [Ian] Me too. OK, we'll see how that goes. {ACTION}
  2. Texts for Survey Result web pages
    • {Not discussed due to lack of time}
  3. Possible consolidation of Mailing lists: Reflector and Newsletter
    • {This item was discussed first}
    • [Ian] We've got two email circulation lists: The reflector and the list I use for the newsletter. I initially wondered if we should consolidate these lists, but after thinking about it a bit more felt that the reflector should be for those in the group and the newsletter list should be kept separate.
    • [Heiko] I don't think there's a need for them to be separate. If you look at other groups, the mails go to everyone who's interested in the group. But maybe they don't have a newsletter.
    • [Heiko] It's OK just now because there isn't much email, but I guess it could be annoying if there were a lot.
    • [Brad] That was my thinking on this.
    • [Ian] Mine too. But I was wondering if we should send the calling notices to the newsletter list, to try to stimulate a little more participation.
    • [Ian] The other thing I'd been thinking of here was whether the reflector list needed revalidate, to confirm that people still want to be on it?
    • [Brad] That might be a good thing to do.
    • [Ian] We may have some dead addresses in there; people that have moved on.
    • [Carl] I sometimes get a bounce but that's usually when someone's mailbox is full.
    • [Tim] The object of this is to increase participation, but asking people to confirm that they want to stay on the list means you might end up with less members. You should say that they'll be kept on the reflector unless they ask to be removed.
    • [Carl] OK, a reminder that they must tell us if they wish to be removed.
    • [Tim] A lot of people will just use the Junk folder anyway if they don't want to be bothered by your emails.
    • [Ian] How many are on the reflector anyway?
    • [Carl] Give me a moment and I'll find that out for you.
    • [Heiko] We could put something in the newsletter, in case people would like to be added to the reflector.
    • [Carl] There are 24 people on the reflector.
    • [Ian] OK, there's something over 60 on the newsletter list, so quite a lot more potential members.
    • [Ian] So, to summarize: The enquiry should be worded to ask people to tell us if they want to be removed from the reflector, otherwise we keep them on. Then, in the next Newsletter, we can offer the opportunity for folks to get themselves added to the reflector.

5. Schedule next meeting

October 4th

Schedule for October 2010:
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.

The second draft of the ITC Fringe Meeting schedule has been circulated and the SJTAG Meeting is pencilled in for Thursday November 4th, 10 AM until noon.

7. Review new action items

  • Ian/Brad: Condense gateway comments and queries into a concise set of questions.

8. Adjourn

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

Respectfully submitted,
Ian McIntosh