Meeting Minutes - 2010-11-22

Minutes of Weekly Meeting, 2010-11-22

Meeting called to order: 10:36 AM EST

1. Roll Call

Patrick Au
Tim Pender
Ian McIntosh
Carl Walker
Brad Van Treuren
Brian Erickson
Adam Ley (joined 10:52)

Excused:
Peter Horwood
Michele Portolan

2. Review and approve previous minutes:

10/25/2010 minutes:

  • Draft circulated on 10/25/2010.
  • No corrections noted.
  • Carl moved to approve, seconded by Patrick, no objections or abstentions.

11/15/2010 minutes:

  • Draft circulated on 11/16/2010.
  • No corrections noted.
  • Adam moved to approve, 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
  • Carl: Contact Zoe about what material we could obtain for our use. - Ongoing
  • Ian/Brad: Condense gateway comments and queries into a concise set of questions. - Ongoing
  • [Ian] We're coming up towards the year end, which seems like an appropriate time to see if we can clear out some of the old actions. I guess they'll fall into two categories: Those we don't expect to ever progress and those we still need.
  • [Ian] Maybe in the new year we should cancel off those that we don't think we can progress.

4. Discussion Topics

(Agenda item b) was discussed first)

  1. White Paper Volume 3
    • [Ian] This is under the banner of White Paper Volume 3, but today it's more about seeing how we can start to condense an outline for a core standard from the material we've built up over the last three years.
    • [Ian] That sounds like a long time but if you're considering only the one hour for the meeting, then the 135 or so meetings really only amounts to the equivalent of a month's work in the "day job"!
    • [Ian] I guess the first question is whether we feel we need to complete the excercise we started on the primitives and building blocks before we start trying to split out the core and extension material?
    • [Ian] We've left it a bit open ended, but maybe we don't need to close that out before moving on?
    • [Adam] I would opt for completing that work.
    • [Carl] I'd say it's not desirable to leave it flapping in the breeze.
    • [Ian] OK, so I think the follow up to that is about completing the discussions we were having on Gateways. We'd got some way on that in the primitives, but we still had open discussions on the properties.
    • [Tim] It's been so long, I've forgotten where we were on that. I like the idea of having the path selection separate, but synchronization of the selection operations is a problem.
    • [Brad] I handled that with TFCL: Selection is a separate step from executing a SVF. But I have found conditions where that can still be restrictive.
    • [Tim] I'm trying to think of when you maybe have to program a fairly large flash and maybe don't want to use the expensive pods, but use a cheap USB pod, like a vendor pod, instead. It'd be nice if the vendor tools could export to some intermediate format where you can then map the write strobe to an IO.
    • [Brad] SVF with PIO already provides some of that. It's an ordered sequence so you can't do anything conditional.
    • [Brad] That gets us into the issue of how you pass along "intent" to an embedded program, because the intent of an operation is lost in a SVF. The player can't really determine what it was you were trying to do.
    • [Ian] Generally, external tools are aware of the kind of operation being attempted and may have access to more data aid understanding. It's typically the exports from vendor tools that are the problem.
    • [Brad] TFCL can use only a segment of the SVF, but it still isn't as I'd like for some of the newer technical features.
    • [Tim] It's like STAPL having Action Names; something that can define what the action of the file is supposed to be.
    • [Tim] Some tools can export to a file but if it fails you simply get a no-go indication.
    • [Brad] You may be able break it down to get to whether it failed during erase, during program, or during verify. Call an erase event, a program event, etc.
    • [Brad] I can fragment it up in TFCL while still having a single repository for the vectors. That compacts smaller than if they were separate.
    • [Ian] I guess that important for the embedded applications; rather less so for externally controlled tests.
    • [Tim] Sometimes you may have no explicit TLR, but it's implicit in the operation. Maybe if there was a way to ensure that happens when you need it.
    • [Ian] This may be crossing over into some of the territory that the 2011 update to 1149.1 has planned, with initialization and recovery.
    • [Brad] Usually a power on reset gets you into a known state, so often that's what you end up doing after a test.
    • [Ian] But I guess that's not what you want if working with a live system.
    • [Adam] I should caution on using INIT to talk about recovery: The purpose of INIT is to prepare a device so it's ready to perform a test; shut down a PLL, other things that may stop it overheating for example. Recovery is the flip-side. You've taken the core circuits and driven them out to the weeds, now you're trying to get them back somewhere close to the fairway.
    • [Ian] OK. If a recall Resume/Recovery wasn't something that was slated for the 2011 edition?
    • [Adam] I think it's now called ICRESET and has actually been discussed over several weeks recently, so it is planned for 1149.1-2011.
    • [Brad] There are time when you want to drive the core logic, like INTEST.
    • [Adam] That's why the recovery mechanism is essential. The core has received out-of-band stimulus. I guess INTEST is kind of in-band though.
    • [Ian] I expect that most people running INTEST will be aware, to some extent, of how they're disrupting their system.
    • [Adam] Not necessarily. By the way, if anyone is interested in these dot 1 discussions there are typically two calls each week: The first on Tuesday at 11 AM Eastern, the second on Friday at 11:30 Eastern. You can send me an email and I'll pass on the invitations.
    • [Ian] Thanks Adam.
    • [Ian] Getting back to Gateways, Adam had listed a number of things we ought to be doing (noted in the agenda). It seem like a good outline to work from; mostly we were already attempting to do those things, but it's good to have it written down in one place.
    • [Brad] Where we got bogged down, and we had things pretty well worked out for the back end - the path selection side of things, was with the infrastructure: The primitives for the selection logic - what should SJTAG be supporting?
    • [Brad] We can answer the properties question for the back end but the front end is wide open.
    • [Ian] That was making me wonder if we should consider a gateway as if it were a composition of two devices, splitting the back end and front end. That way you could mix and match one of a range of front ends to a back end to describe a particular device.
    • [Brad] That was where we were heading with the "universal slide", the one we used for the Poster.
    • [Ian] Well, we're running out of time for today, but we probably all need to refresh ourselves on the slides we had. {ACTION}
  2. Newsletter
    • {2010_Nov.htm shared}
    • [Ian] I used "From the Chair" to give a quick summary of ITC from SJTAG's perspective.
    • [Tim] I sent you an email on this: I thought the first sentence of the last paragraph there was maybe a bit confusing. It'd be simpler to say "I was a bit disappointed..."
    • [Ian] OK, I can change that.
    • [Adam by email] Too bad the ITC photo doesn't feature the poster or at least some SJTAG members.
    • [Ian] Following up a discussion we had a few weeks ago, I thought we should use the Newsletter to make people aware of the email Reflector. I've amended the contact page so people can ask to be added, in which case Carl will get a copy of the request automatically. It reduces the risk of me forgetting to pass on the request.
    • [Ian] What forgot to add was a note, as we discussed previously, that people need to make an explicit request to be removed from the Reflector.
    • [Ian] The bit on Gateways was left over from the last issue and is just a placeholder for anything we might add.
    • [Ian] As regards the website news items, I was beginning to wonder if these were worth keeping: Most are just commenting on the issue of the weekly minutes. There are few other things, like the publication of the survey results that are worth noting.
    • [Tim] Maybe there should just be a single link to the minutes?
    • [Adam by email] The mention of Meeting Minutes from October 11th seems to be misplaced.
    • [Brad] The value of these items is it shows there's activity in the group. A general link to the minutes wouldn't show that.
    • [Tim] Maybe if we keep the minutes to the bottom: People could miss some of the other items if they think "Oh, that's all just minutes below there."
    • [Ian] So, put all the less usual items at the top?
    • [Brad] That sounds like a good strategy.
    • [Ian] Is there anything we can add to the Newsletter?
    • [Tim] Do we have a roadmap? There was mention of a roadmap recently; that would be a good thing to put in.
    • [Ian] It would, but we don't really have that yet. It's what I'm hoping to do next, but I'm a little wary of writing up things we intend to do, but haven't even started.
    • [Tim] It could be generic at this stage, "We're working on a roadmap to better plan our activities."
    • [Adam by email] It would be nice if the SJTAG "poster", or a link to it, were featured in the newsletter either as mentioned in the ITC blurb or in a separate item, replacing the Gateway item perhaps.
    • [Ian] OK, email me any other suggestions. {ACTION}

5. Schedule next meeting

November 29th

Schedule for December 2010:
6th
13th

No meeting on 20th or 27th as several people will be on vacation.

6. Any other business

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

Michele made a suggestion on using the research challenges of SJTAG as a means to draw academic interest.

7. Review new action items

  • All: Revisit Gateway properties for next meeting.
  • All: Email any ideas for Newsletter content to Ian.

8. Adjourn

Tim moved to adjourn at 11:34 AM EST, seconded by Patrick.

Respectfully submitted,
Ian McIntosh