Minutes of Weekly Meeting, 2011-06-20

Meeting called to order: 11:14 AM EDT

1. Roll Call

Ian McIntosh
Carl Walker (left 12:00)
Brad Van Treuren
Adam Ley (left 12:01)
Eric Cormack
Patrick Au (left 12:00)
Richard Foster (left 11:43)
Tim Pender
Brian Erickson
Harrison Miles (joined 11:16)

Peter Horwood
Heiko Ehrenberg

2. Review and approve previous minutes:

06/06/2011 minutes:

06/13/2011 minutes:

3. Review old action items

{Harrison joined}

4. Discussion Topics

  1. Continuation of Problem Space Description
    - Thoughts on a "Benchmark System"
    - Block diagram and description?
    - Terminology needs to cross industry sector boundaries
    • [Ian] Last week, Brad brought up the suggestion of a 'baseline' system to template our Use Cases against. Those who were involved at the start of these weekly meeting will remember that we used ATCA as a basis for much of our discussions then. I thought that was useful, because having something specific to relate to seemed to produce a lot of good insights. The only snag was that ATCA wasn't a particularly good example of an SJTAG system.
    • [Brad] The reason we ended up talking about ATCA was that it avoided having to deal with proprietary designs.
    • [Harrison] Have you considered microTCA?
    • [Brad] I did consider that; I wrote the JTAG chapters in the microTCA specification. I thought it was maybe a little too simplistic and was maybe shoehorning into a single type of switch module and not the multidrop and scanbridges that many were actually using.
    • [Ian] I was trying to determine what level of description we actually needed for this.
    • [Brad] That's the $64,000 question.
    • [Ian] Well, when we talked about ATCA, it was an architecture that was largely alien to me, but a kind of block diagram understanding was all I felt I needed to be able to follow the discussions.
    • [Harrison] I tend to agree with that but it depends on how far you want to go. If you want to do more than testing, if you want more than go/nogo then you maybe have to consider greater detail.
    • [Brad] But there are certain Use Cases that don't lend themselves to just a go/nogo result.
    • [Harrison] Then maybe you need to take those to a higher level; they become out of scope.
    • [Brad] Out of the scope of SJTAG? Emulation is outside of testing, but it's something that SJTAG needs to deal with.
    • [Harrison] OK, but you can break that down.
    • [Brad] I'm referring to dot7.
    • [Harrison] Dot7 is getting above the level of basic 1149.1. Dot7 opened up the possibility of debug.
    • [Brad] I'm confused on how you map that to go/nogo, or how it relates to some of the dynamic aspects.
    • [Harrison] DDR3 is the classic case of dynamic things where you can get a go/nogo result.
    • [Brad] I'm talking about dynamics at a user interface level.
    • [Harrison] But now you're going beyond a range where the TAP is useful.
    • [Harrison] Dot7 is only supporting emulation at a primitive level.
    • [Brad] It is an enabler.
    • [Harrison] I'll agree on that. But what are you trying to achieve?
    • [Brad] I'm just trying to illustrate that some things need more than go/nogo.
    • [Brad] A GDB debugger via the BDM interface to the emulation interface of dot7 is an illustration of dynamic data exchange between the user and the UUT. Variable and register access does not map into Go/NoGo modeling. The only thing close is the application of the command is Go/NoGo, but not the user's interaction with the UUT. Some 1687 use cases have the same dynamic interactions that don't map to Go/NoGo results.
    • [Harrison] Devices are primitives to a higher level; boards are primitives to the system.
    • [Harrison] How do you orchestrate across devices, never mind across boards? If you look at more than go/nogo you're no longer in the test domain.
    • [Brad] Our Venn diagram shows that test is part of SJTAG, but only one part.
    • [Harrison] What is SJTAG offering in those other cases?
    • [Brad] Well, to begin with, a common interface.
    • [Harrison] Not to all devices. You have maybe 50% adoption predicted for 2015, and around 40% of devices currently with JTAG.
    • [Ian] The number of JTAG devices isn't a measure of the access provided: If I use metrics from our designs, we may have only 2, 3, 4 or 5 JTAG parts out of 30 or more active devices on a board, but we'd still expect to get to 80% test coverage. The board boundaries are the biggest drop-off.
    • [Harrison] OK, I tend to agree on that, but I'm looking at what you're looking to extract; what SJTAG wants to have happen. Where does one domain end and the next domain start?
    • [Brad] SJTAG is not going to define a source code debugger, but it has to define access to the registers of a specific processor at a 'covers on' level. It does get kind of fuzzy on what is the edge of the system, especially when you have an embedded controller. You can't draw that edge and cast it in stone. This is what has been giving us difficulty.
    • [Harrison] I see the first edge as the device TAP.
    • {Richard left}
    • [Harrison] Then when you have several on a board you have what I call a vessel or container of devices, each with their own edge that has to get connected together.
    • [Brad] That's where we came up withe the term 'assemblies' when we looked at this previously.
    • [Harrison] There is currently no standard controlling the activity between 'containers' in the same domain, on the same board. The test world has no consistent rules for that.
    • [Harrison] How do I connect to another board?
    • [Brad] Where we got to, and where we got derailed, was that board looks like a subsystem.
    • [Harrison] And chips can look like a subsystem.
    • [Brad] Yes, and systems and subsystems are compositions of multiple assemblies. The problem was representing that in a unified way.
    • [Harrison] P1687 is knocking at the door of this, asking how do I talk to my neighbor chip?
    • [Brad] P1687 was dabbling in concurrency to synchronize instruments.
    • [Harrison] You can set that aside, people will work that out elsewhere.
    • [Brad] The P1687 instruments provide knowledge of the algorithms required to use the instruments. Knowledge sharing to end users is difficult to document.
    • [Harrison] Don't want to support something that ends up presenting artificial barriers. P1687 may become something sitting on paper that never actually gets used.
    • [Harrison] Better to concentrate on communication between neighbors, not necessarily from the same vendor.
    • [Brad] That's where we started to go at one point. There are certain actions that will relate to a specific device. Then there's the more generic ones, actions that can be applied to any device. An interconnect test algorithm is a good example of this latter case.
    • [Harrison] There's the case where you need to train SERDES devices, where they may not be at the same intelligence level.
    • [Brad] Sounds like we need to define what constitutes neighbor devices in our theoretical system
    • [Ian] So we're taking a bottom up approach?
    • [Harrison] I don't see any other way of doing that.
    • {Patrick and Carl left}
    • [Brad] May have to dig deeper into the device in some cases, but start with the device as a known black box.
    • {Adam left}
    • [Brad] At some point we may need to evaluate more than just a pair.
    • [Ian] Even though we're going bottom-up, I think I'd still like to have some kind of sketchy outline of the system we're building, so there's a outside world context.
    • [Brad] There's the three systems posted on the forums.
    • [Ian] Yes, OK, we can take a look at those for next week.

5. Key Takeaway for today's meeting

6. Schedule next meeting

Next Meeting:
June 27th (11:00 AM EDT, 4:00 PM BST)
Harrison and Brian will both be on vacation

Schedule for June 2011:

7. Any other business


8. Review new action items


9. Adjourn

Eric moved to adjourn at 12:05 AM EDT, seconded by Tim.

Respectfully submitted,
Ian McIntosh