[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2010-07-12

Meeting called to order: 10:39 AM EDT

1. Roll Call

Ian McIntosh
Patrick Au
Carl Walker
Brad Van Treuren
Tim Pender
Adam Ley

Apologies:
Heiko Ehrenberg
Brian Erickson

2. Review and approve previous minutes:

6/28/2010 minutes:

  • No corrections noted.
  • Motion - Patrick, Second - 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

4. Discussion Topics

  1. White Paper Volume 3 Review - Key Gateway Features: Review forum submissions.
    • [Ian] I tried to collect the submissions from Peter, Heiko and Brad into a single list. Peter started out by suggesting 'addressability'; Brad then expanded on that with addressing for each path in the hierarchy.
    • [Tim] I don't think that is possible right now?
    • [Brad] No, currently that is not possible with presently available parts, but it is something we need for SJTAG.
    • [Ian] I think that we have been trying to work round what exists now, and have largely avoided thinking about what's really needed. To some extent, we still need to consider what can be done with current devices, but it will be limiting.
    • [Brad] That's why I was willing to stick my neck out and make the suggestion!
    • [Tim] It's something we should tackle but it does complicate things: You'd need to select the secondary paths to carry out the addressing.
    • [Brad] It's no more complex than P1687 has to do to get the SIBs to open. It's also an issue that Dot 7 has in trying to address specific cores.
    • [Tim] How would you propose to do this? You made have chains you want to isolate. Maybe you need an addressing mode so once you've selected your scan path you can then isolate the ones you want inactive.
    • [Brad] Nothing I've said says addressing is a one time only - it could be a series of selections. SJTAG needs the paths to be selectable from the top, but need not be common protocols, especially if I2C is used at one level.
    • [Brad] It may also be that there's a common I2C through the hierarchy. We should not be impeding the ingenuity of how users gain control of their chains.
    • [Brad] In the fourth bullet, my first, I was trying to say that every branch needs to be uniquely addressable, even when multiples of the same board are present.
    • [Ian] So, including a geographical element to the address, physical position of the board?
    • [Brad] Yes, we'd call it a slot address.
    • [Ian] Yes, that idea was in my mind, but I guess I just wrapped that up in Peter's simple term 'addressability' and didn't break it out.
    • [Brad] I think Peter was including that, but I just wanted to bring it out.
    • [Ian] Heiko added the item about GPIO signals. Some devices will offer one or two fixed direction IO lines that can be routed between the primary and secondary. Do we feel that's valuable? I guess it ties in with the issue that Tim raised a few weeks ago about signals needed to support emulation.
    • [Tim] I agree with Heiko, that we may want to route signals that are used by controls. And they need to be fixed direction, as managing bidirectional signals gets complicated.
    • [Tim] I might have four identical FPGAs each in it's own chain, so I may want to bring the ProbeA and ProbeB lines back.
    • [Brad] I'd almost modify that to at least have some enabler that the gateway can drive when a path is selected and can turn on some other buffer. One you start specifying the number of lines in your device it may be either too few or too many.
    • [Ian] True, but I guess that may be the point Peter made about competitive advantage: If a vendor wants to provide some pass through signals and use that as a marketing advantage then they still can.
    • [Brad] Yes, but vendors may not know what I need.
    • [Ian] No, but there's maybe the reliability question too. Avoiding an additional part may be a consideration in reliability or manufacturability; the difference in the numbers will likely be small, but may be a consideration.
    • [Brad] True, but it'd have to be traded against performance issues. If I specify the interface then I know it's characteristics.
    • [Ian] Brad, did I get the summary of your last two points right? I got the first as being about tool reuse and the second being test reuse.
    • [Brad] I don't think you quite captured it. The first one was that I only want to prove-in the test once. So if I prove the test using external tools and the scan chain topology looks the same for an embedded controller then I don't need to repeat the proving. {ACTION}
    • [Brad] The last one follows up on that, in that the local, on-board view should be identical to the view from the multidrop.
    • [Brad] Both are about test reuse. I wasn't sure about whether to use 'must' or 'should' in these. It's something we really want to have for SJTAG, though.
    • [Ian] It's certainly something SJTAG should aspire to. Maybe it's another 'SJTAG Compliant' versus 'SJTAG Compatible' situation.
    • [Brad] That could be a way to handle it. I remember CJ Clark citing some work that Jose Miranda and I had shown at a BTW and claiming that our method required multiple prove-ins, while his method didn't. Ours /might/ have needed multiple prove-ins but we had rules in place to ensure portability.
    • [Ian] I think we're getting towards the idea of multiple primary side ports.
    • [Tim] That's how I handle things, with multiple hosts.
    • [Ian] I think the problem there is that many commercial parts don't offer multiple primary side connections.
    • [Brad] Any time you add things into the topology for one path then you can't achieve your goal here. The flip-side is the difficulty in addressing any path from local level.
    • [Brad] You can have addressing at various levels or common topology, but currently not both. This may be the motivation behind using other protocols for chain selection. The concern is that it becomes a nightmare for the tool vendors to support all these alternatives.
    • [Ian] It does seem rather unfair to expect that of the tool vendors. And I2C is really an industry 'standard', rather than a formal standard.
    • [Brad] There are variations: ATCA has IPCI which is I2C but has a higher level protocol on top. Can we suggest how to simplify things for tool vendors?
    • [Ian] I think it's true that there are too many options around. Even looking at the support for gateways, trying to foresee all the possible contexts must be difficult. I know our tooling could cope with some configurations of ScanBridge but struggled with others. It may be OK for some people who want to have control over the test generation, but this probably a big segment who just want to push a button on an ATPG and get a good test out.
    • [Brad] Tools vendors have always been leery of board-to-board testing that can be reused repeatedly through all these different protocols. I've got to provide flexibility in my tooling.
    • [Ian] We've talked previously about the lack of CAD data for the system. Having discussed that around the company here, that's probably a problem for more than just JTAG - things like getting proper simulations of system behaviour.
    • [Brad] Multiple configurations too, but they're still the same 'system'.
    • [Ian] That's possibly less of a problem for us, but I do recognise it. Maybe this is really a CAD tools issue, and partly outside our remit.
    • [Tim] Why couldn't the test tooling do the net merging?
    • [Ian] It could, but I don't know that net naming or connector IDs across boards and backplanes will be obvious enough for it to be a simple job.
    • [Brad] What do you use as your protocol? You have to use board level tools on a flattened netlist. How do you get synchronisation and no conflicts? Board level tools run out of steam when looking at the system level complexities.
    • [Tim] A dynamic netlist - I want to change my netlist based on the chain selection.
    • [Brad] Right. I used to use standard board level algorithms to do board-to- board interconnects, but that takes too much time, so I developed my own.
    • [Ian] Should we continue this discussion next week or move on to some other aspect?
    • [Brad] Before we leave gateways, I want to make sure I'm not offending any tool vendors.
    • [Adam] No complaints here!
    • [Tim] Do we want to go down the road of looking at hosts?
    • [Brad] Yes, that's probably a good idea.
    • [Ian] OK, we can quickly look at this again next week to see if anyone who missed today has anything to add, then take a look at hosts.

  2. Sample Webpages to Present Survey Results - Review submitted commentary text.
    • {Not discussed due to lack of time.}

5. Schedule next meeting

Schedule for July 2010:
July 19, 2010 - Brad will miss
July 26, 2010 - Brad and Brian will miss

6. Any other business

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

7. Review new action items

  • Ian: Correct summary of Brad's latter two bullet points in forum post.

8. Adjourn

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

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.