[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2010-04-26

Meeting called to order at 10:37 AM EST

1. Roll Call

Carl Walker
Ian McIntosh
Eric Cormack
Heiko Ehrenberg
Brad Van Treuren
Peter Horwood
Patrick Au
Tim Pender (joined 10:39)

Excused:
Adam Ley
Brian Erickson

2. Review and approve previous minutes:

04/19/2010 minutes:

  • Draft circulated on 21st April:
  • The Call to Order should be noted as 10:35.
  • Eric moved to approve with the above amendment, seconded by Brad, 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 to come up with some board representation graphics - COMPLETE.

4. Discussion Topics

  1. White Paper Volume 3 Review - Discussion of system description diagrams
    • {Brad's updated slides were shared}
    • [Ian] I think slide 16 was the first where there was any change.
    • {Slide 16}
    • [Brad] I added the Select signal here as Ian pointed out that we didn't introduce that until Slide 18.
    • {Slide 17}
    • [Brad] This has just the same change.
    • {Slide 18}
    • [Brad] Again, this is the same change, but in the third bullet I mention that some selection is taking place to route the TAP signals through the Dynamic Path Selection Logic.
    • {Slide 20}
    • [Brad] With slide 20 I started using the symbolized representation for individual boards as proposed by Ian. This is the Ring or Serial chain. I'm really just showing that it's no different from what was described for the board level. I start to make the distinction of a TAP Interface going into the board and an External Path coming out of the board; HSDL calls both External Paths.
    • [Brad] I added some 'issue' bullets in red that indicate limitations of the ring/serial chain architecture, in line with Tim's theme from last week.
    • {Slide 21}
    • [Brad] slide 21 shows a bus chain (partial star/partial radial) with shared TCK and individual TMS or shared TMS and individual TCK. Diagrammatically they are equivalent. We use the same text as on the board level slide, except that in the third bullet 'Static Path' becomes 'External Path'.
    • [Tim] In this diagram, where is the master?
    • [Brad] The master is external. With these slides we don’t show any embedded controllers as that may be confusing right now. All these slides are showing architectures driven by nothing other than external controllers.
    • [Tim] I just wondered what was controlling the blue box on the left (backplane).
    • [Brad] Good point, we should take a note to add the Select signal on this diagram. Probably on all of this group of slides.
    • {Slide 22}
    • [Brad] Slide 22 shows full star/full radial scan chain. We're trying to standardize on the color scheme, so people can start to associate the colors with the functions, without us having to repeat detailed descriptions.
    • [Brad] Very similar to board level version, except that the Static Paths become Dynamic Paths.
    • [Tim] Is it implied that the JTAG signals will be controlled in the path selection?
    • [Brad] This is where we are missing the Select control signal.
    • [Tim] Well, does the blue box on the left represent a scan chain selection circuit that utilizes a shadow protocol or just some switching circuitry?
    • [Brad] All the scan chain control is inside the path selection logic on the backplane; the individual boards look at their TAP as just being connected to an external path. The blue box on the backplane is missing some control signal(s).
    • [Brad] I don’t think we should introduce protocol specifics at this time, like the shadow protocol, just say there are 'some control signals' for the path selection logic that selects which board path gets activated.
    • [Tim] I think if some people look at this and realize "Wow, I'll need 32 bits to control my system" then that show the problem.
    • [Brad] And that'd be a good segue into showing why these protocols are invented.
    • [Ian] It's useful to explain that as lot of people see these protocols as just 'getting in the way'.
    • [Brad] That part of our role of educating people.
    • {Slide 23}
    • [Brad] Slide 23 is the switchable star/radial together as they're conceptually no different. Introduces some form of addressing protocol for path selection that is not through TDI/TDO.
    • [Brad] The diagram is the same as before, but now uses an addressing protocol. I should probably add a note that this is done to reduce the pin count required for selection.
    • [Ian] Maybe we should take out the GPIO option from the fourth bullet to really show the difference between this slide and slide 22?
    • [Brad] Sounds good.
    • {Slide 24}
    • [Brad] Slide 24 is trying to depict a multidrop architecture, introducing the term 'Gating Function'. The fourth bullet will need some word smithing and we'll need to take out GPIO.
    • [Tim] You get the advantage of a passive backplane, but you need to note that only one board can drive TDO.
    • [Brad] I need some way to introduce things like the Scanbridges, but I don't really know if it goes here. I want to discuss it in the next section.
    • [Ian] We could add a forward reference, saying that we'll explain the path selection in the next section.
    • [Tim] There are so many ways to do things, and a System Engineer may want a passive backplane for example; maybe we need a matrix so people can select the features they need and see what solutions fit.
    • [Ian] That sounds good, but it'd need to be a 'back end' slide.
    • [Tim] Oh yeah, it'd be too confusing up front!
    • {Slide 28}
    • [Brad] I start breaking down into the concepts of selection logic types. This slide basically describes a TAP selector circuit. Can we use this as a White Box that we can use later?
    • [Eric] Because the selects are all the same you can only select all A or all B?
    • [Brad] I think I need another box that pulls in the selection signals.
    • [Tim] Does TDI really go through to TDO? Since this is just a selector surely TDI is still TDI when it gets to A or B?
    • [Ian] I guess that the selector effectively becomes the Master to the board chains.
    • [Peter] Well that maybe means that it should be TDO coming out of the selector as that is what most external controllers will have. I prefer what Brad has drawn.
    • [Ian] I think we just need to be consistent, but I think we'll have to put it to a vote to see what is preferred. I'll take an action to put something in place for a vote. {ACTION}
    • [Brad] Slide 26 is daunting, so I think we need to avoid that kind of representation. If English isn't someone's first language we need to be sure that it's all understandable.
    • [Tim] As you break this down, you're fanning out of signals; with more chains you daisy-chain several boxes so you pass through several muxes. That helps your understanding.
    • [Brad] Maybe we want to have a fanout block too. It's the different functional roles not really the TAP selection itself we need to show. I guess there's three primitives:
      • Fanout of TCK/TRST
      • Parking for TMS
      • Routing of TDI/TDO - concatenation and bypassing - fanout/fan-in or mux-out/mux-in.
    • [Ian] That also works as a justification for sync bits.
    • [Brad] That could be another primitive. We maybe need another color for these primitive boxes.
    • [Ian] I agree, but maybe we can put them inside a blue box to show that they are part of the larger entity?
    • [Brad] Or an expansion similar the Muxes at board level.
    • [Ian] Looks like we need to work with this slide (28) and come up with some primitives. I guess that's this week's work. Does anyone feel cut out by Brad and I doing this?
    • {silence}
       
    • [Brad] Overall are we progressing? Is this a good representation of primitives that allow scan path selection options?
    • [Eric] Definitely.
    • [Tim] I really like it.
    • [Tim] We need to bring the TDI/TDO convention to vote soon before we need to redo lots of work.
    • [Ian] Probably best to put the slide on the forums and let people put forward their arguments or alternatives there, then review and vote next meeting. {ACTION}
    • [Tim] Could the diagrams be sent in PowerPoint format?
    • [Ian] Probably, or it could be made a download from the File Manager. Files can also be attached to forum posts. Do we need the whole PPT file or just selected slides?
    • [Brad] I need to think about that.
    • [Ian] OK, we'll see what the best way of getting the information out and back in is.

5. Schedule next meeting

Schedule for May 2010: May 3, 2010; 10:30am EDT
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

None.

7. Review new action items

  • Ian: Make forum post inviting discussion of TDI/TDO naming convention in path selectors, for vote at next meeting.
  • Ian: Determine method for circulating diagrams for markup by the group.

8. Adjourn

Brad moved to adjourn at 11:51 AM EST, seconded by Tim.

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.