The System JTAG Working Group

Minutes of Weekly Meeting, Unpublished

Meeting called to order at 10:36 AM EST

1. Roll Call

Eric Cormack
Ian McIntosh
Carl Walker
Brad Van Treuren
Heiko Ehrenberg
Michele Portolan
Brian Erickson
Tim Pender

2. Review and approve previous minutes:

04/26/2010 minutes:

• Draft circulated on 26th April:
• No corrections.
• Eric moved to approve, seconded by 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
• Ian: Make forum post inviting discussion of TDI/TDO naming convention in path selectors, for vote at next meeting. - COMPLETE
• Ian: Determine method for circulating diagrams for markup by the group. - COMPLETE

4. Discussion Topics

1. White Paper Volume 3 Review - Discussion of system description diagrams
   • [Ian] I think if we start by reviewing the forum posts.
   • {Forum thread 'Path Selector TDI/TDO Naming Convention' shared}
   • [Ian] We started out with a diagram from last week that showed a TAP Selector. This caused some debate over the naming of the TDI and TDO signals on the secondary side.
   • [Ian] There were a couple of responses, and then Brad posted some new diagrams showing lower level primitives that may influence the opinions.
   • [Brad] I realized we were comparing apples and oranges: It's the functionality of the pin versus the signal names. I’ve decomposed the TAP Selector into smaller core elements, as discussed at the end of last week’s meeting. At the higher level you may carry over signal names, but for the primitives I'm trying to deal with the functionality of the ports, the input and output, of a particular block.
   • [Tim] I think I like that better, it's kind of like a manufacturer's datasheet.
   • [Brad] This insight came when I decomposed it. Create a box and label the ports based on the IO function: Inputs are labelled to show they're inputs and have arrows pointing in to suit. Similarly for outputs or bidirectional pins. This way we can try to distinguish between signals and functions.
   • [Heiko] I like the way it looks.
   • [Tim] I like the way you have split up the primitives in smaller elements.
   • [Ian] This should help clarify things, I think.
   • [Brad] the arrows and block function should communicate the intent of the signals on a block, the signal names could be arbitrarily chosen by the designer.
   • [Brad] I think we should come up with some motion to the extend of approving these primitives for use in the white paper.
   • [Ian] Do we want to go through the other slides you prepared for today, Brad, before we vote on this?
   • [Brad] I was going to propose the voting to be done in 'Other Business' at the end of today’s meeting.
   • [Ian] Good, I agree.
   • [Brad] Heiko made some comments that were worth considering. Do you agree that there are two perspectives?
   • [Heiko] I agree, yes.
   • [Brad] A point on distribution: It's possible to have one distributution block then use its OutA to drive another distribution block, but the gate delays become unbalanced. There maybe needs to be something in our standard about balanced delays.
      
   • {Brad's "slides.pdf" shared}
   • {Slide 26}
   • [Brad] on the slide 'Path Selection Primitives' I show seven primitives that seem to be needed as a minimum set to control scan chains, with details on the left side and compact, less detailed drawings on the right side (ISW = Input Switch; OSW = Output Switch; GBUF = Gated Buffer; PBUF = Pulled Buffer; SYNC = Synchronization Latch; DIST = Distribution Circuit; BUF = Buffer); these are the basic primitives. The PUBUF from the post on the forum site is now just PBUF as I couldn't find a need for a pulldown buffer.
   • [Tim] Where is GBUF used? Is there maybe a need for a PBUF on the GBUF?
   • [Brad] There may be times when we want to gate outputs.
   • [Tim] OK, but is it maybe High-Z or a weak pull?
   • [Brad] Would you map that onto a PBUF?
   • [Tim] Well, it may be that we need to revisit that once we find a use.
   • [Brad] The basis for this slide was to present the types.
   • [Tim] GBUF looks like TDO and PBUF is TDI, the pull-up ensuring the lines doesn't float. In the SYNC, is there 2 flops in there?
   • [Brad] Most devices maybe have a reset/preset to set it to a known value, although sometimes it's a Don't Care.
   • [Tim] It creates a pipeline delay of one bit.
   • [Brad] I deliberately didn't mention that here. Maybe add another section that shows additional primitives used in the state-of-the-art scan path control devices.
   • [Tim] Are these going to use TCK as the master clock?
   • [Brad] The current linker devices seem to use TCK. It doesn't really matter what value it captures as long as it passes through the data or instruction stream during the shift cycles.
   • [Brad] The color scheme is using the same blue color for internal functions in the primitives that we used for Dynamic Path Selection circuitry on previous slides, with orangey background color, indicating that these are primitives.
   • {Slide 27}
   • [Brad] On the next slide I looked at the "TAP Bypass Element", using the primitives proposed on the previous slide.
   • [Brad] The concept was to build things up in a progression. One thing that I may need to explain is the numbers relating to the state of the Select pin. That maybe need to be on the previous slide.
   • [Carl] As long as it's consistent, it should be OK.
   • [Tim] /TRST might need some kind of a switching function, too. If /TRST is applied, the parked TMS may become overwritten by a TAP reset.
   • [Brad] The GBUF function with a weak output may be useful. Probably, some circuitry external to this block would be needed to take care of gating the /TRST signal in a parked state.
   • [Brad] The point I am trying to make on these slides is these are just building blocks and not the final design solution that gets wired to the outside world. There may need to be wrapper logic around each of these blocks/primitives.
   • {Slide 28}
   • [Brad] On this slide I show a 'Simple Linker' structure. This may make it a bit easier, to understand the previous slide. This drawing shows two TAP Bypass elements implemented in a circuit with some wrapper logic on the front end that allows two scan paths to be linked or used individually or even bypassed altogether.
   • [Tim] This would still not take care of the /TRST issue, right?
   • [Brad] Right. There are some commercial devices I can't use because they don't have the gating techniques I need.
   • {Slide 29}
   • [Brad] This is the beginnings of a switch. I didn't have time to get it finished.
   • [Ian] OK, so this still needs some work.
   • [Tim] Can you explain the bit about A AND B?
   • [Brad] With a switch you select either A OR B, but not A AND B; that's where a linker comes in.
   • [Tim] The AND could be accomplished using three switches, I think.
   • [Ian] I can see that the Linker is a simpler entity than the Switch, but is it logical to have the Linker presented before the Switch, from the novice's viewpoint?
   • [Brad] It's a pity Peter isn't on the call; he has some insights on this.
   • [Heiko] In the earlier slides we showed the Bypass for the mezzanine, so the Linker makes sense.
   • [Brad] I struggled with this on µTCA where we called it a JTAG Switch, but we didn't want to prevent linking, so it's not really a switch.
   • [Brad] Tim suggested in the past that we pose a problem and then offer a solution.
   • [Tim] the TAP Switch creates a problem in that it can control only one chain at a time, and it cannot link them together. The TAP Linker offers a solution in that it can link TAPs together but also can work with individual TAPs.
   • [Brad] So, that should be the order we introduce/discuss these in then: First introduce and discuss the TAP Switch and once they've grasped the complexity, we can show them the TAP Linker.
   • [Ian] That makes sense to me.
   • [Brad] OK how is this looking? Are we going the right way?
   • [Tim] I like the primitives.

5. Schedule next meeting

Schedule for May 2010: May 10, 2010; 10:30am EDT
May 17, 2010; 10:30am EDT - Heiko may not make this call
May 24, 2010; 10:30am EDT - Heiko won't make it to this call

No meeting on May 30.

6. Any other business

Brad made the following motion:

"That the naming convention for a hardware structure at its IO points will follow the function of the IO and does not mandate the use of the functional name as the signal name when used within another block."

This was seconded by Eric. Brian proposed that the motion be tabled until next week to allow the wording to be considered.

This was agreed.

7. Review new action items

None.

8. Adjourn

Carl moved to adjourn at 11:34 AM EST, seconded by Heiko.

Thanks to Heiko for supplying additional notes this week.

Respectfully submitted,
Ian McIntosh