Minutes of Weekly Meeting, 2010-12-06

Called to order at 10:37 am EST

1. Roll Call

Patrick Au
Peter Horwood
Carl Walker
Brad Van Treuren
Brian Erickson
Heiko Ehrenberg
Adam Ley {joined mid-meeting}

Ian McIntosh
Tim Pender

2. Review and approve previous minutes:

11/29/2010 minutes

  • meeting was aborted due to limited number of people on the call, but that those present approved the release of the Newsletter before closing.

11/22/2010 minutes (draft circulated 11/23/2010)

  • Brian moved, Carl seconded; no objections; -> minutes approved

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
  • 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
  • Carl: Contact Zoe about what material we could obtain for our use. - Ongoing
    [Carl] no feedback from Zoe yet; Carl will ping her again;
  • Ian/Brad: Condense gateway comments and queries into a concise set of questions. - Ongoing
    [Brad] not complete yet
  • All: Revisit Gateway properties for next meeting.
  • All: Email any ideas for Newsletter content to Ian.

4. Discussion Topics

  1. White Paper Volume 3
    • Revisit Building Blocks, leading into:
    • "Adam's objectives" wrt Gateway definition:
      • define what a gateway is
      • describe what role gateways play in SJTAG environments
      • identify key characteristics for gateways (and, to extent possible, which are mandatory/optional)
      • elaborate the properties of gateways (and, to extent possible, the pivots) (by pivots, I mean, the various (typically exclusive) values for each property = which brings to mind the idea of expressing the properties as key:value pairs …)
    • Key Gateway Features: Questions for tool vendors (time permitting)
    • [Brad] {sharing slides} we left off with slide 30; next topic would be Port Addressing Primitives; trying to define a left-hand and right-hand side;
    • [Brad] {slide 35} Manual Chain Selection/Configuration Via Jumper Blocks;
    • [Brad] {slide 36} Precondition of Boundary-Scan Register (BSR) to configure Linker; trying to build up the concept of what is needed on the "left-hand side"
    • [Brad] {slide 37} Independent GPIO controlled selection and park logic
    • [Brad] {slide 38} I2C GPIO Expander used as linker controller;
    • [Brad] {slide 39} I2C GPIO Expander used as Gateway controller; Gateway needs to be able to disconnect itself from the primary side;
    • [Brad] {slide 40} Including GPIO signals from TAP Data Register(s) in Linker device; driving GPIO signals from a TAP data register
    • [Brad] {slide 43} Port Addressing Via 1149.1 Data Register
    • [Brad] {slide 44} TAP Controller used as Linker controller
    • [Brad] {slide 45} TAP Controller used as combined Gateway and Linker controller
    • [Brad] {slide 46} next section would talk about commercial implementations
    • [Brad] {slide 47 + 48} Scan Bridge protocol
    • [Brad] {slide 49} ASP protocol
    • [Brad] {slide 50} LASP protocol
    • [Brad] those were the changes to the slides, which brings us to identifying the gateway characteristics and properties; maybe we should focus on defining what a gateway is and what role gateways play in SJTAG environments;
    • [Brad] what are differentiators between Linkers and Gateways?
    • [Heiko] you pointed out one thing earlier: a Gateway needs to be able to disconnect from the primary side, whereas a Linker generally stay connected and links the secondary paths to the primary path;
    • [Brad] addressing supported by Linker may be limited; Gateway needs some addressing mechanism that’s outside the 1149.1/JTAG domain (there needs to be some selection/setup be done before JTAG can be used)
    • [Brad] should we spend some time coming up with some text for a definition of Gateways, maybe that helps in formulating the characteristics?
    • [Heiko] that sounds like a good idea
    • [Brad] or should we define the Gateway environment first?
    • [Patrick] I’d say we should define the gateway environment first;
    • [Brad] well, part of the environment for Gateways is that multiple scan chains that need to coexist;
    • {Patrick left the call}
    • [Brad] also multiple scan chains may have to work in concert with each other;
    • [Heiko] may need to manage the bridging of non-JTAG signals;
    • [Carl] but then: which direction do those signals need to flow,
    • [Peter] and how many do you need each way
    • [Peter] Need to specify a standard voltage level on the primary side
    • [Ian; by proxy] This can be a touchy subject (this a bit of a philosophical and slightly off-topic thought): While it's essential that primary side TAPs in a multi-drop arrangement need to be compatible, I've encountered push-back at the board level. I've seen where we may have a COTS board in the system using 3V3 levels for the TAP and that seemed like as good a reason as any to select 3V3 as the "common" TAP voltage. Then one of the in-house board designers will grumble that his design uses nothing at all over 2V5 "so I'll have to add a 3V3 supply just for that". There are two angles here: The first is that it seems quite reasonable to allow the system designer to declare the backplane TAP signal level, rather than having it mandated in a standard, especially where the entire design content is under the control of one design team. The other, opposing, angle is that to allow re-use of designs, or the use of COTS assemblies, within a system then the TAP signal level at the assembly boundary needs to be in a standard than overarches individual systems design specs. How do we reconcile these views?
    • {Brian dropped off the call}
    • [Brad] Gateway needs to enable or disable access to individual scan chains
    • [Brad] access commands must be coordinated with scan operations on the TAP ( not really an environment issue, though)
    • [Brad] will a Gateway primary side always be a bussed environment (such as in multi-drop?)
    • [Carl] no, you could have a star configuration
    • [Peter] Right. You could have a star configuration that had the same behavior of the multi-drop architecture. It really depends on the application needs. You could even have a gateway manage the access to other gateways in a hierarchy.
    • [Brad] I like this mental picture you are painting. This is getting into the view of a hierarchical order for gateways.
    • [Ian; by proxy] I've also seen a star where one of the branches is a multi-drop. I'm not at all suggesting that this is good architecture, but mixed topologies do become possible within a hierachical order.
    • [Brad] I could picture a cabinet with multiple chassis in it, each with their own multi-drop backplane interface. There is some sort of a cabinet controller that interfaces with each of these chassis via a gateway interface.
    • [Peter] Exactly. We have customers that have multi-drop backplanes that are interfaced to using a gateway device as a hierarchical control system.
    • [Brad] Does this mean you can use the same interface at the top level as you do at the multi-drop?
    • [Peter] It could be. It all depends on your application interface needs.
    • [Brad] Is a gateway more than just a chain management selection mechanism?
    • [Peter] Yes. In a system hierarchy you may have more than one level of interface that needs to be managed.
    • [Heiko] Does this mean we need different levels or classes of gateways?
    • {silence}
    • [Peter] You also have dot7 that gives you just a 2 wire system
    • [Adam] I would disagree with that statement because dot7 also has support for a 4 or 5 wire perspective.
    • [Peter] I would agree, but in the future, if we think about future proofing SJTAG, you may end up with just a 2 wire system.
    • [Peter : by proxy] The point I was trying to make is should we mandate 2 wires or 4 wires? if we mandate 4 wire then users could use .7 if there system supports it and they then have 2 wires for other functions if they wish and they have devices that support it, or they can use standard .1. Routing 4 wires provides more flexibility for the user as not all systems are the same or have the same requirements.
    • [Brad] I was trying not to go down the dot7 path because I feel it is only going to side track us on a tangent that will not help us resolve the current issue of defining what a gateway is. Dot7 is an important topic, but needs to be addressed at a later date.
    • [Heiko] Yes, but should we be thinking of dot7 as another form of gateway to the internals of the device?
    • [Brad] Yes and no. We have been discussing this issue internally and find it to be a real struggle to define in terms of gateways. This is why I would prefer to defer discussion on dot7 until we have a better understanding of what the general gateway is in our minds.
    • [Ian; by proxy] Maybe it's a case of "burying our heads in the sand", but I'd be inclined to suggest leaving dot 7 support to one side for now, possibly for a future extension. There's limited product available right now anyway, and I think we have to think about defining our "scope": I see SJTAG as dealing with the interface between the board chains, the backplane and the outside world (oversimplification) and dot 7 as primarily something that will crop up in the board internal chains. It may be something we interface to, but not something we integrate into SJTAG.
    • [Heiko] The time is running out, so I think we will table this discussion for this week.
    • [Heiko] I take an action item to make a forum post for this Gateway environment discussion
  2. Academic involvement in SJTAG: Research challenges
    • [Brad] I have some University interactions; in the US Universities usually need corporate funding to do any research like this; Ian and Michele are talking about possibilities with some European Universities, but I don’t know what the status is.

5. Schedule next meeting

December 13
  • [Heiko] I suggest we all think about our availability for a January calling schedule, and let’s agree on the schedule at next week’s meeting;

6. Any other business

Motion on naming conventions, tabled from 05/03.

7. Review new action items

[Heiko] post this Gateway environment discussion on the SJTAG forum

8. Adjourn

motion to adjourn by Brad, seconded by Carl;
adjourned at 11:33am EST