[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-03-09

Meeting called to order at 10:35 AM EDT

1. Roll Call

Ian McIntosh
Patrick Au
Tim Pender
Brad Van Treuren
Peter Horwood
Heiko Ehrenberg
Adam Ley
Carl Walker (joined 10:40)
Eric Cormack (joined 11:27)

Excused:
Carl Nielsen

2. Review and approve previous minutes:

3/2/2009 minutes

  • Change:
    • [Brad] When IJTAG started considering registers, they set aside whether they were accessed from a chain or in parallel. Then the PEL was written to describe what data is written.
    to:
    • [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.
  • Typographical corrections:
    In Discussion Topics:
    • Line 92 "then" (first instance) becomes "that"
    • Line 123 "non-scanable" becomes "non-scannable"
    • Line 148 "ting" becomes "thing"
    • Line 160 "its" becomes "it's"
    • Line 170 "independant" becomes "independent"
    In AOB:
    • Line 193 "a" becomes "as"
  • Brad moved to approve with the above amendments, Heiko 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
  • Andrew: Make contact with VXI Consortium/Charles Greenberg. - Ongoing
  • Ian/Brad: Draft "straw man" Volume 4 for review - Ongoing
  • All: Review "Role of Languages" in White Paper Volume 4 - Ongoing
  • All: Consider structure/content of survey - Ongoing

4. Discussion Topics

  • [Brad] That first link in your calling notice has a problem; I just get a message telling me I am not allowed to read this forum. I am logged in.
  • [Ian] OK, give me moment, I'll need to check the permissions.
  1. White Paper
    • Volume 2:
    • [Heiko] no work done on it
    • Volume 3:
    • [Carl] I haven't gotten to it
    • Volume 4:
    • to be discussed later today
    • Volume 5:
    • [Brad] I have made no updates

  2. 2009 Survey
    • [Ian] I'm thinking there at least two ways to approach this: We could just brainstorm a list of questions, then work out who best to set each to, or we try to work out what types of people we're targeting first then set a list of questions for each group. Alternatively, we just do what we did last time and produce one list of questions and let people simply ignore the ones they have no real input on.
    • [Peter] A long list of questions may discourage people from completing the survey.
    • [Patrick] We had this discussion before, when we worked on the first survey.
    • [Ian] Yes, long surveys are off-putting, but the difference for this survey is we already have people primed for a longer, more detailed list of questions.
    • [Peter] I'm really just suggesting that we could branch round blocks of questions based on an answer given to previous one, e.g. are you interested in this topic X? if Yes, then continue with questions a, b, c; if No, then skip on to the next block.
    • [Ian] That would make sense, but I'd need to look into whether the form creation tool allows such a structure to be created.
    • [Tim] Is that similar to the iNEMI survey.
    • [Ian] The iNEMI survey was quite long; it's difficult to tell if you were being skipped past groups of questions.
    • [Adam] I can make some comment on that. There was one branch at the beginning, based on whether you were involved in test engineering or device design. Apart from that there were no other branches.
    • [Ian] I was beginning to think along those lines; try to get a question at the front that determines which "stream" to follow. That makes building the survey forms simpler.
    • [Brad] I think Patrick talked before about overlap for particular topics; we would need to make sure we don't miss certain groups of people when asking particular questions.
    • [Ian] I think it was Eric who brought up that point, commenting that System Architects have broad interests.
    • [Ian] If we follow that route, who are the classes of people we want to survey? We've got people who have particular technical knowledge, but who are not actual users;
    • [Heiko] Maybe we can create a matrix, cross referencing the roles/functions we have listed in 1.4 to the questions we want to ask; come up with the list of questions and then mark which roles/functions apply to each.
    • [Brad] I think each of those roles is represented within our group here so we could just decide wich ones we'd each like to see.
    • [Tim] When you ask about roles, could someone be allowed to tick more than one option?
    • [Ian] Last time we asked for one role that best fitted the individual, but yes, it's easy enough to do.
    • [Brad] We would have to ask them the superset of the two sets of questions.
    • [Ian] On Feb 6th, 2009, Brad sent a number of good questions, in particular focused on embedded topics; I'll add those questions to the forum so we have them all in one place (http://forums.sjtag.org/viewtopic.php?f=32&t=83)
    • [Ian] I'd like to get more feedback, in particular other questions we want to come up with.
    • [Brad] We should also think of categories / groupings of questions. I tried to put some rough groupings into my list of questions, e.g. "features", "scope", "interface", "test management", etc., and I'm sure there are more.
    • [Ian] OK, I'll cancel any previous actions regarding the survey and set a new action to come up with questions and categories.
    • [Tim] Is there some particular timescale you have in mind? Maybe that would help to focus effort.
    • [Ian] I'm very conscious that people are limited in how much time they can give to this, and that applies to me too. Once we get a set of questions agreed, it'll still take maybe two weeks to build and test the forms before we can release them. On that basis, I'd say end of April is probably realistic.

  3. Device Modelling/Representation
    • http://forums.sjtag.org/viewtopic.php?f=30&t=87
    • [Ian] I put together some very simple diagrams, just as a basis of discussion. Earlier today, Brad sent out another diagram. This makes a connection that I hadn't got to which is that a BSCAN device is a specialisation of a device.
    • [Brad] I sent out the diagram (DeviceAbstraction.png) this morning mainly to try and show that it was possible to represent all devices as a single abstraction. A "circuit" could be a board, a system, a multi-chip module: Ultimately you can resolve everything to a single abstraction.
    • [Brad] I also tried to tie in last week's discussion about ports.
    • [Ian] I didn't quite get to grips with that last week due to taking notes.
    • [Brad] In IJTAG there BSDL ports which are really signals. These ports provide control over the instrumentation features, so how the device behaves depends on how there ports are set.
    • [Tim] Are these ports internal or can they also be external.
    • [Brad] In IJTAG these are going to be internal to the device, so you could have cells the ports of an instrument.
    • [Brad] I'm wondering, do we really need levels like ActiveDevice AND IntegratedCircuit or could we flatten these into one level?
    • [Ian] It looks like they're the same thing.
    • [Brad] Well, I was thinking ActiveDevice might be a transistor.
    • [Ian] I guess I forgot about discrete devices!
    • [Brad] Can we simplify the models for SJTAG? Can we discount passive devices like resistors,especially if you're not doing interconnect test?
    • [Ian] If you are never doing to generate an interconnect test at the system level, then maybe you don't need to describe some of the circuitry details, e.g. if you're applying previously generated board level tests, that don't interact with other system resources, and the test ends at the board boundary.
    • [Tim] When integrating a COTS PCB in your system you would like to include boundary scan interconnect to test the boundary of the COTS device. The COTs board vendor would need to provide the post configuration BSDL and chain information for the boundary. Allowing a model representing for the COTS board boundary would allow for an abstraction so that the COTS vendor could provide the users needed information without revealing their entire proprietary netlist.
    • [Brad] Yes, that's where I'm trying to go with this diagram. And we've struggled to get our designers to put the edge interfaces into their own chains to aid this. It's a design rule that needs to be followed.
    • [Brad] We have to represent not only the onboard but also dynamic characteristics of what happens when the board gets plugged into a system? How does the board interact with the rest of the system?)
    • [Brad] another question to ask: is backplane level testing something we should worry about in the time frame we expect SJTAG to become a standard, especially now that many backplanes are moving from parallel buses towards SERDES?
    • [Ian] We're using Fibre Channel onto backplanes with big crosspoint switches for routing and the chassis level is the first place we really get a chance to properly test the attachment of the BGA switch.
    • [Brad] Dot1 and even dot6 are still not going to be great help there.
    • [Ian] It's not helped by device manufacturers who don't put scan cells, on things like RocketIO pins.
    • [Carl W] This is common problem that we get asked to look at. We have run PRBS patterns to test near and far loopbacks; essentially a BIST mode.
    • [Ian] You still need to control it, If it's all done in a functional test that's fine, but sometimes that isn't convenient.
    • [Carl W] Yes, we're relying on a 1687 type of behaviour.
    • [Brad] I've seen a number of discussions on this subject.
    • [Carl W] There are some things a don't meet the eye, like how much margin there really is in the link: Half the link can be lost a still produce a reasonable eye.
    • [Brad] Ken Parker has written a paper[1] on this.
    • [Tim] I've been looking at another paper[2]. One of the things they are showing is some defects that go undetected at 35MHz can be detected at 45MHz, for example.
    • [Carl W] That somewhat different to some of the observations I've seen: Coupling capacitor defects, for example, are usually easier to detect at lower frequencies.
[1] Parker, K.P., "The effects of defects on high-speed boards", Test Conference, 2005, Proceedings, ITC 2005, IEEE International, Nov. 2005, Page(s):8pp. - 187 Digital Object Identifier 10.1109/TEST.2005.1583975

[2] 2001 ETW paper: http://www.national.com/appinfo/scan/files/ETW.pdf

5. Schedule next meeting

Schedule for March 2009:
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] Carl Nielsen is leaving Intellitech, effective this Friday, to take up a new role at Raytheon. Consequently he will be leaving our group.
  • [Brad] In his message, he indicated that he expected to be able to rejoin.
  • [Ian] I don't know if that is assured or whether he needs to find support at Raytheon, but he certainly said that he hoped to be able to return to SJTAG.

7. Review new action items

  • All: Consider existing question set and propose additions or amendments, and how these may then be grouped/categorised.

8. Adjourn

Moved to adjourn at 11:42 AM EDT by Carl, 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.