[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-03-02

Meeting called to order at 10:36 AM EST

1. Roll Call

Tim Pender
Eric Cormack
Ian McIntosh
Carl Nielsen
Heiko Ehrenberg
Brad Van Treuren
Harrison Miles
Adam Ley (joined 10:46)
Peter Horwood (joined 10:48)

Excused:
Carl Walker
Patrick Au

2. Review and approve previous minutes:

2/23/2009 minutes

  • Correct [Bard] to [Brad] in notes on Slide 10
  • Brad moved to approve, Eric seconded, no objections

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?
  • Establish whether TRST needs to be addressed as requirements in the ATCA specification if it is not going to be managed globally (All)
  • Adam review ATCA standard document for FRU's states
  • Patrick contact Cadence for EDA support person.
  • 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)
  • Adam: (continue) revise wording of section 5 - Ongoing
  • Carl W./Andrew: Set up conference call to organise review of Vol. 3 - Ongoing
    • [Carl W by proxy] I'm still waiting for feedback from Harrison.
    • [Harrison] I've still to do this; real work conspires to stop me.
  • Andrew: Make contact with VXI Consortium/Charles Greenberg. - Ongoing
    • [Harrison] I did e-mail Andrew; I'll try to follow up.
  • Ian/Brad: Draft "straw man" Volume 4 for review - Ongoing
    • [Ian] I made a small comment; We'll be discussing this later.
  • All: Review "Role of Languages" in White Paper Volume 4 - Ongoing
  • All: Consider structure/content of survey - Ongoing
  • Ian: Post Brad's presentation as PDF on the SJTAG website. - COMPLETE

4. Discussion Topics

  1. White Paper
    • Volume 2:
    • [Ian] As I recall, some sections still needed to be filled in. Could that come from the information we have in forums discussions on the Use Cases?
    • [Heiko] I'd need to look back, but I'm pretty sure that I went through all the forum material and took what I could use.
    • [Ian] OK, so we probably won't gain much by trying to look back there now.
    • Volume 3:
    • [Ian] We had thought that this volume was headed towards too deep a level of detail. Harrison's suggestions were adding new content areas?
    • [Harrison] What I was working towards was something on the small form factor area. I have been assuming that we're just looking for something on the general direction of things?
    • [Ian] Yes, it White Paper discussion document material, not normative text we're writing at this point.
    • Volume 4:
    • [Ian] I added a relatively small comment to the discussion page.
    • [Brad] Ian, I'm following the link from the wiki, but I'm not finding the post I made on chain segments: Has it been lost? I wanted to look at your reply.
    • [Ian] Sorry, I moved it into a sub-forum, but I see it's not showing up here. You can find it if you follow the breadcrumbs down from higher up the forum structure. I'll need to take a look at that and see if made a mistake by changing the structure the way I did.
    • [Brad] OK, got it now.
    • [Ian] I wanted to discuss this post anyway and it leads us nicely into the next topic.

  2. Device Modelling/Representation
    • http://forums.sjtag.org/viewtopic.php?p=171#p171
    • [Harrison] I wanted to ask where we thought we were headed as regards languages.
    • [Ian] We're really still at the stage of understanding what data were trying to deal with; once we've got to grips with that then we'll be able to look to see what existing languages might fit or if we need to develop something of our own. If you're asking if we're targeting some specific language, then the answer is "no".
    • [Harrison] OK, I'm comfortable with that approach.
    • [Brad] Also identifying in which domains the data resides.
    • [Harrison] Good. You're getting into what domains you're trying to solve for; some domains will just want to monitor and collect, other will do more.
    • [Brad] That's why we started out by studying the Use Cases and that helps to delineate what can be done in embedded systems; what things can be done on-line vs what is done off-line.

    • [Ian] Returning to the Chain Segments post: Brad made this post over a week ago, but it wasn't getting any replies, so I thought we should discuss it here. Basically, where we left off with the UML diagram, we had represented a system down to "devices" where we then pulled in things like the BSDL files. Brad's question here is whether we need a different abstraction, perhaps considering a device as a collection of registers.
    • [Ian] As an aside, I linked my reply to an earlier post on data formats where I suggested that we needed to forget about the formats used to describe devices for the time being and concentrate on what data we need to be in control of.
    • [Brad] Part of this was to see if we can achieve an abstraction for devices that is similar to the way we created an abstraction for a system.
    • [Brad] SVF, STAPL define a complete chain to be worked with; should we consider "ChainSegments" as the smallest JTAG elements in our language, in order to be able to handle dynamic scan chain configurations in a simple way and with more flexibility in our data model?
    • [Ian] that would work well for scannable components, but what about non-scannable components? I'm almost more concerned about those, since they have a big impact on the testability / test coverage; what data do we actually need for non-scannable devices (e.g. how to enable/disable the device, etc.)?
    • [Ian] My immediate thought was that we couldn't generalise all devices, as scannable and non-scannable devices have very different attributes. A non-BSCAN only has some inherent logical function, while the scannable device has a controllable boundary.
    • [Adam] I need to point out that a scannable device will also have some function and need not be in test mode, in which it will behave like a non-scan part.
    • [Ian] That's a good point, I was forgetting that.
    • [Brad] I think we're saying there are two different interfaces.
    • [Ian] What I feel is that however we end up describing a device, then we need to be able to use the same method to describe something like an OEM board that we include in our system; it should just look like another device.
    • [Harrison] I think you need that.
    • [Harrison] there is a hierarchy of interfaces; top-level would be human readable content (level at which you want to take an action); mid-level are automated actions; low-level interface would be data collection, for example; This fits with the idea that you have growing levels of intelligence as you work up the chain. You can think of Dot 1 as the most primitive; just a state machine. Then Dot 7 adds a OSI-like "Layer 2", with the notion of a network. P1687 adds the assumption that every element has some intelligence.
    • [Brad] When IJTAG started considering registers, they set aside whether they were accessed from a serial scan chain or from a parallel interface. Then the PDL (Procedural Description Language) was written to describe what data is written or read to/from the instrument registers.
    • [Brad] Ian, I think you're proposing that stimulus points are the more important thing for non-BSCAN devices?
    • [Ian] From where I stand today, yes, but I am prepared to be convinced otherwise.
    • [Harrison] Typically, going forward we expect most boards will have some kind of intelligence. We just need to describe a common port; a landing zone. Every board has this common port, although it's up to the designer how he realises it.
    • [Ian] That possibly helps with some of the other items we've talked about previously: Common methods for board identification, fault storage, etc.
    • [Brad] My only concern in dealing with ports and their control is taking them into the domain space for SJTAG for things like concurrency.
    • [Harrison] Yes, that's going to be hard.
    • [Harrison] Think of any vendors device; it'll have modes when it's quiescent, when it's running functionally, when it's in test mode.
    • [Brad] There's more than that; command and control, configuration, etc.
    • [Harrison] In some sense these can be outside the scope of the standards.
    • [Harrison] From an object oriented perspective, we don't need to understand the private data, just the signals.
    • [Brad] Yes, but Use Cases like Fault Injection have an application at board level and a meaning at system level, but don't really have a device level.
    • [Harrison] If you've looked at the iNEMI survey, one thing they raise is at the final production stage when they load the final software or firmware and suddenly get problems, and need an independent way of looking at the problem.
    • [Brad] to summarize, it seems that ChainSegment may be a bit too simplistic and we may need to look at it from a Port perspective; registers should still be representable from a Port perspective;
    • [Ian] I think the way to move forward here might to diagram up a couple of things to talk round.

  3. 2009 Survey
    • Discussion postponed due to lack of time.

5. Schedule next meeting

Schedule for March 2009:
Monday Mar. 9, 2009, 10:30 AM EDT (14:30 GMT)
Monday Mar. 16, 2009, 10:30 AM EDT (14:30 GMT)
Monday Mar. 23, 2009, 10:30 AM EDT (14:30 GMT)
Monday Mar. 30, 2009, 10:30 AM EDT (15:30 BST)

6. Any other business

  • [Ian] One small point: I've enabled a feature on the forums that allows you to add attachments to your posts, such as diagrams. It means that you don't have to arrange for them to be held elsewhere now.

7. Review new action items

None.

8. Adjourn

Moved to adjourn at 11:30 AM EST by Heiko, seconded by Tim.

Many thanks to Heiko for providing additional notes.

Respectfully submitted,
Ian McIntosh

Copyright 2007-2009 The SJTAG Working Group
The SJTAG Initiative is "work-in-progress" and the views and opinions expressed here are subject to change without prior notice.