Minutes of Weekly Meeting, 2009-12-14

Meeting called to order at 10:34 AM EST

1. Roll Call

Carl Walker
Adam Ley
Brad Van Treuren
Brian Erickson
Ian McIntosh
Michele Portolan
Heiko Ehrenberg

Eric Cormack
Patrick Au

2. Review and approve previous minutes:

12/07/2009 minutes:

  • Draft circulated on 7th December:
  • No corrections noted
  • Brad moved to approve, seconded by Heiko; 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?
  • 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
  • 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
  • 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.
  • Ian: Make slides used today accessible on website - COMPLETE
  • 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.
  • Ian: Mail out reminder message to people who have not yet responded to the Survey Invitations. - COMPLETE

4. Discussion Topics

  1. White Paper Review - System Architecture
    • [Ian] Following on from last week's discussion, I thought I could see a way I could develop the slide set I shared last week. Unfortunately I had some distractions that meant I didn't spend any real time on it. One thing I did start to run into though was a question of granularity. One building block I came up with was "TAP Controller" but then I realised that could mean many things, but I didn't feel I should be detailing what was in there. Maybe I'm heading the wrong way?
    • [Brad] I was trying not to steer people, so I wouldn't necessarily say you're heading the wrong way, but I was thinking more in register terms: We know that we have to deal with Test Data Register, Instruction Registers. Those are our interfaces to the hardware. Then there's the various chain management elements, like gateways, with Instruction Registers in the device that are steering data. There are the control elements that are needed to manage the application of the data.
    • [Brad] We have to think about what are the aspects of BSCAN we need to deal with?
    • [Ian] The biggest problem I'm having is my own mindset; trying to think about the problem space without simultaneously overlaying my own, fixed idea of a 'correct' solution.
    • [Brad] Carl and I may have an advantage in that our companies are the product of acquisitions so we get to see variability in the way things can be done. And the implementation often depends on the Use Case. Usage can dictate the tradeoff between using a GPIO to run a chain or something more specialized to get a high rate TCK. We need to know what we're trying to do within the problem space. A lot of this applies at the board level too.
    • [Ian] What I'm seeing now is boards that start to have many of the issues we used to associate with 'systems'.
    • [Brad] Maybe we should look at this from a board test perspective; that may allow more people to comment.
    • [Brad] Primary thing is that we can ensure the right firmware is in place for the board management. Then bringing up the power.
    • [Brad] I'm working on a design just now that has its interface via Telnet.
    • [Ian] We'll tend to want to test boards without firmware loaded as far as possible, especially at our CMs.
    • [Brad] I can understand that, but many boards now need some sort of control to bring up the power.
    • [Ian] True. We often have a CPLD that manages the power, so we'll do a BSCAN test of the permanently powered circuit around the CPLD, load the CPLD, then let it bring up the rest of the board and complete the testing. Sometimes that may mean we need control of some additional lines that the system would normally supply, like an FRU_ON.
    • [Brad] We may even have dedicated power pins for the power management circuits.
    • [Ian] We don't usually have that on boards, but it's often the case on systems. The main power is the 3-phase, 400Hz supply, but the unit only turns that on once 28VDC is applied to the standby circuits and they've completed initial checks.
    • [Brad] Getting back to the building blocks, I'd like to know if anyone else feels that considering TDRs, etc., is being too specific?
    • [Michele] I thinks TDRs are a good building block. We know we need a TDR.
    • [Ian] In considering TDRs and IRs, are we in danger of rehashing some of 1149.1?
    • [Brad] Fair question. I'm suggesting we just acknowledge it as a register. Look at it in a more functional way, where dot 1 would be the 'Phy' in the layers you spoke about last week.
    • [Ian] So, do we drop some kind of barrier at the device boundary and say "we go this far only"?
    • [Brad] We need to leverage other standards like 1500, and P1687, so we do need to know about what's inside the devices.
    • [Ian] OK, so in a similar way to my diagram last week with the cloud between the backplane and the boards, now we have a cloud between the board and the JTAG front end of the device.
    • [Brad] Yes, there are similar building blocks at board and system as there are at device and system-on-chip; there can be gateways in the devices. You have gateways where you need to preserve state information.
    • [Ian] Maybe one of the differences we have to deal with is that there are many different gateway devices around: They don't all work the same but we need to be able to handle them all. Things like P1687 have the opportunity to define a common gateway mechanism.
    • [Brad] The other things is that in P1687 the chain structure remains static over time. We may have changes occurring monthly, weekly, daily as things get added or removed from the system. Even a change in the programmed logic may constitute a 'change'.
    • [Ian] We probably don't really have that problem as we don't usually have systems that user can alter.
    • [Brad] No, but I guess you get new board revisions, or changed art that is functionally the same but needs a different BSCAN test.
    • [Ian] That is true.
    • [Brad] That's why we need to define our vocabulary on our way to understanding the requirements.
    • [Brad] Does this seem too complex? Is that why we're not hearing much from the others?
    • [Carl] I don't know if it's too complex or just that we don't have any good answers. Maybe we need a less optimal example.
    • [Brad] OK, what are the solution elements currently in use? That's where Gunnar started from in developing the Star and Multidrop schemes in the original White Paper. The diagrams have been copied into the wiki, I think.
    • [Carl] That is correct.
    • {Wiki Volume 3 shared}
    • {Ring diagram}
    • [Brad] What blocks do we have here? There's 'Path Select'. I remember there was a lot of discussion to get the best names for some of these blocks.
    • [Brad] On one board we have 'BIST Engine' added.
    • [Ian] It's not shown as having any influence on the chains. It could be some BIST control entirely outside of JTAG.
    • [Brad] I think it was Gunnar's intention to show it that way. It's just something that needs to be supported.
    • [Ian] And it is optional, there's no absolute necessity for it with an SJTAG context. I guess you could say the same about the Path Select, if the board were simple enough to use a single chain.
    • [Brad] Some of the things we have are:
      • Internal/local scan paths
      • External/off-board scan paths
      • Chain management logic, which is optional as you say
      • BIST Engine, again optional and not necessarily 1149.1 driven
      • Flash/PROM which could be treated as a virtual register: Indirectly represents the interface
    • [Ian] I feel that it may be unnecessary to detail all the device types we have here; they're surely all just 1149.1 parts.
    • [Brad] I think the point was to show that all of these different devices types, the microprocessor, FPGA, 1532 memory, dot 6 devices, etc., were included.
    • [Brian] I'd say that it is relevant to show these part types, as they can have debug ports, for example FPGAs with ChipScope.
    • [Brad] That also brings in localized management of chains.
    • [Brian] Maybe we just need some notation to indicate secondary port access.
    • [Brad] Multiport access to a scan path; multidrop and local access.
    • [Ian] That's like Tim's paper where several tools were linked to several chains via one MUX device.
    • [Brad] That's a good representation of this.
    • [Ian] When you have local and external access the there needs to be some form of control path arbitration.
    • [Brad] Yes, it's important that there's a protocol hierarchy.
    • {Star diagram}
    • [Ian] What's missing here is that there's another Path Select back where we see the TAP Connector. In effect, cascading Path Selects, that could continue down through the daughterboard connector.
    • [Brian] Sounds like the SIB in P1687.
    • [Michele] The SIB is more a specialized path selection. What's shown here is more generic.
    • [Brad] There are variations on this. A system I worked on back in 1992 separated out the TMSs but the rest of the signals were just bussed. That was using the AT&T controller that brought out two TMSs. The arbitration was done in software.
    • [Ian] A recent system we did used a Scanbridge to create a star to a few modules, but on one of the branches we had several identical modules in a multidrop arrangement. So it was a real hybrid.
    • [Brad] I guess there's no reason why Scanbridges and ASPs can't be in the same system
    • [Ian] No, it's more of a concept problem, in that the method of accessing Board X is different from Board Y. I guess maybe you just forget about that and let the tooling deal with it. Maybe that's how you deal with COTS boards that are architected differently from the others in your system.
    • [Brad] uTCA had the JTAG Switch. We didn't specify how the switch operated, the important point was the connections it made.
    • [Ian] I guess that means that tests written for one backplane wouldn't port to another?
    • [Brad] If the switch is on the backplane, no. But often the switch is part of one of the boards.
    • {Multidrop diagram}
    • [Brad] The new things here are the Gateway and the JTAG Protocol Manager. I guess you can think of the gateway as a boolean path selector, either on or off.
    • [Ian] The diagram implies that addressing supplied over the JTAG chain, but that could be done by other methods. Which makes me think of something Tim has mentioned before: Nowhere are we accounting for any additional non-JTAG I/O signals. I usually find I need at least two; maybe a write pulse to help Flash programming or something to enable external JTAG access.
    • [Brad] The JTAG Protocol Manager is there for board-to-board test, to allow the microprocessor on one board to send out commands and data over the test bus to other boards and collect the results back for processing.
    • [Ian] We've overrun our time. We better resume this next year, although I guess the first meeting back may be looking at the early results from the survey.
  2. 2009 Survey
    • {Not discussed due to lack of time}

5. Schedule next meetingM

Schedule for January 2010:
Monday January 11, 2010, 10:30 AM EST
Monday January 18, 2010, 10:30 AM EST
Monday January 25, 2010, 10:30 AM EST

6. Any other business


7. Review new action items

None. General reminder that the Forums are available to record any thoughts or ideas that members have between meetings as well as responding to the meeting discussion topics.

8. Adjourn

Carl moved to adjourn at 11:51 AM EST, seconded by Brad.

Respectfully submitted,
Ian McIntosh