[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2010-04-12

Meeting called to order at 10:39 AM EST

1. Roll Call

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

Excused:
Eric Cormack

It was noted that the meeting number and link included in the calling notice for this meeting were out-of-date. Carl's later Outlook invitation supplied new and correct details. Ian resent these details through the reflector during the meeting.

2. Review and approve previous minutes:

03/22/2010 minutes:

  • Draft circulated on 22nd March:
  • No corrections noted.
  • Insufficient attendance to approve these minutes at this time.

03/29/2010 minutes:

  • Draft circulated on 29th March:
  • No corrections noted.
  • Heiko moved to approve, seconded by Patrick, 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

4. Discussion Topics

  1. White Paper Volume 3 Review - Discussion of system description diagrams
    • [Ian] I sent out an update to the slides I'd been working on, and Brad has subsequently circulated his new slide set.
    • {Ian's Generic_System_v3.PDF slides shared}
    • {Slide 1}
    • [Ian] I've added a new first diagram showing the chain through the devices. Nothing strikingly new in this, but it was an attempt to bridge from Brad's representation of the JTAG primitives to my more physical board representation.
    • {Slide 2}
    • [Ian] I made a small adjustment here to break the inference that all of the configurations shown were on a single backplane.
    • {Slide 3}
    • [Ian] No change here.
    • {Slide 4}
    • [Ian] This one I'm not sure about. It's where I bring in the idea of path selection within the JTAG Connectivity Infrastructure. The problem is that I have Path Selection in both the backplane and the board, and I'm not sure that's helping anyone.
    • [Brad] I had also been struggling with where you show path selection, in just the way you are.
    • [Ian] I feel it needs to come in here, but you have selection of a path to a board, and then selection of a path within a board.
    • [Brad] This is where I liked HSDL's labelling of the different kinds of path: The Dynamic Path not being rigid or fixed in the topology.
    • [Brad] I'm still struggling with the representation of Board Test Controller and System Test Controller; I think I like the way you currently show this from left to right in your slide 3.
    • [Tim] The only other progression is maybe to first show a board and how you control the paths there. You want to show the basics first; on slide 4 you're going from no path selectors to four path selectors in one go.
    • [Ian] So, maybe in the manner of primitives, we should develop a path selector first that we can then use as a black box here?
    • [Brad] That's a bit of what I was trying to do in my slides.

      •  
    • {Brad's SJTAG Building Blocks.pdf slides shared}
    • [Ian] I think slide 8 is where the new material starts.
    • {Slide 8}
    • [Brad] This is similar to Ian's: We have the register in the device, from the previous slide, which we can connect together with other devices to produce a scan chain.
    • [Brad] I also introduce the concept of the TAP Interface, which I don't think we've mentioned anywhere else yet. There has to be at least one point on the board that is the TAP Interface.
    • {Slide 9}
    • [Brad] Here I introduce paths, starting with the static path, although it's not entirely 'static' as instruction/data registers can be selected, but they stay in the same place in the chain. So what is static is the order of the devices in the path remains the same over time.
    • {Slide 10}
    • [Brad] This brings in mezzanine connection and hierarchy. The parent with it's mezzanine forming an aggregate unit. We have a scan path going off- board, but I've shown this differently to how Ian did.
    • [Brad] One point to get across here is that the configuration of the external path cannot be determined from the netlist of the parent.
    • [Brad] And then we come to my question in blue: 'Should we delineate between a TAP Interface and an EXTERNAL PATH?'
    • [Ian] Surely it depends on where you're viewing it from: For the mezzanine the edge connection is a TAP Interface, but from the parent board it is an External Path connection.
    • [Brad] Exactly. I suppose the point is that you can't connect an External Path to an External Path, or a TAP Interface to a TAP Interface. Some people get confused between the input of an External Path and the output of an External Path. This is different than the way HSDL describes it. In HSDL the TAP Interface may also be described as an External Path, which has led to confusion by many of my test engineers in interpreting HSDL representations.
    • [Tim] In the example, if the mezzanine providing the external path is not installed then it will break the chain.
    • [Brad] Well my next slide introduces multiplexers to deal with that.
    • [Tim] Yes, maybe that blue box should be shown on this slide.
    • [Heiko] As it stands, this shows that the path will be broken if the mezzanine is removed, so then we add another slide to describe how to fix that?
    • {Slide 11}
    • [Ian] I maybe wonder if we're bringing mezzanines in too early and we should concentrate on structures without that extra hierarchy first. Maybe that's just my viewpoint as mezzanines don't feature as much in my business.
    • [Brad] How many feel like Ian?
    • {silence}
    • [Ian] Not many it seems!
    • [Brad] I think we need to introduce the external path before we have a reason for gateways and chain management.
    • [Brad] Are people happy with the terminology we're using here?
    • [Tim] I think the terminology is good. Thinking of the chain getting broken, I think it's useful to show the problem and then show the solution. Maybe we need to identify the problem on the External Path slide, then this slide gives the solution.
    • [Ian] Yes, although, maybe the example here doesn't readily map on the hierarchy problem in the reader's mind.
    • [Brad] I think what Tim's suggesting is going through a model design, but then we run into a problem and show a solution. That seems like a good strategy.
    • [Tim] Then you can show this with backplanes, with daisy chained boards.
    • [Ian] And a lot of people fail to see what's wrong with that.
    • [Brad] OK, the simplest way is to connect things serially, but if you go off-board it'll break down. In the case of a backplane, missing boards will do the same. So then you put active logic on the backplane, but people don't like doing that, so you put active logic on the boards instead.
    • [Brad] A big take-away for me from this session is the forward reference: Introduce a problem and place a pointer to a later solution.
    • [Tim] You can also add slides to show the strategy for partitioning, e.g. a microprocessor that wants to be in it's own chain.
    • [Ian] Those device-driven factors have a huge bearing on how you allocate chains, but maybe that's for much later. I think we want to get people familiar with the more basic stuff first.
    • [Tim] Oh, yes.
    • [Brad] So, what I'm hearing is that we want to reorganize the introduction, discussing dynamic paths before external paths. We need to use forward- referencing, i.e. introduce a problem and the defer to a solution being discussed later.
    • [Brad] I think I prefer to discuss the problem and then to introduce a solution as a black box, and then later these black boxes would be discussed in more detail. An example for a general, black-box-solution is the MUX block on slide 11 (Dynamic Path).
    • {Slide 12}
    • [Brad] Here I'm showing how things get complex once you start to plug things together.
    • [Ian] I think that was your last slide?
    • [Brad] Well I started to mark places for the chain configurations.
    • [Ian] Yes, at first I was thinking that this was too soon for that, but now that I think about maybe it's better that we introduce those schemes now and develop thing like gateways into them.
    • [Brad] Yes, and maybe even this slide should really come after those configurations.
    • [Ian] At some point we need to try and figure out how our two sets of slides marry up, if at all.
    • [Brad] Well I think your slides are revealing the problem space. I guess it's our action for this week to share the PowerPoint files and produce a common set of graphic elements. {ACTION}
    • [Brad] I also struggled with the representation of the primitives, e.g. when can I stop showing the registers inside a device, since they don't scale very well when shown smaller and smaller on more complex drawings (compare slides 10, 11, and 12).
    • [Tim] I think gradually showing less and less detail would work well, still keeping the same color scheme.
    • [Ian] That's essentially what I did if you compare my slides 1 and 2, for example.
    • [Tim] Maybe you don't even need to show devices; on slide 11, you could just show the chains without the distraction of devices.
    • [Ian] I think you need to be careful of oversimplifying too soon though.
    • [Tim] If you take the slide 12 diagram and put it in two-column White Paper layout you won't be able to see anything.

5. Schedule next meeting

Schedule for April 2010:
Monday April 19, 2010, 10:30 AM EDT
Monday April 26, 2010, 10:30 AM EDT

Eric will likely miss all meetings in April.

6. Any other business

Ian noted that Rohit Kapur has requested a Working Group status update.

7. Review new action items

  • Ian/Brad: Consolidate PowerPoint diagrams used during recent meetings.

8. Adjourn

Tim moved to adjourn at 11:42 AM EST, seconded by Carl.

Thanks to Heiko for supplying additional notes this week.

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.