[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2010-05-10

Meeting called to order at 10:36 AM EST

1. Roll Call

Carl Walker
Adam Ley
Brad Van Treuren
Peter Horwood
Eric Cormack
Michele Portolan
Tim Pender
Ian McIntosh
Heiko Ehrenberg (part-time)

2. Review and approve previous minutes:

05/03/2010 minutes:

  • Updated draft circulated on 5th may:
  • No corrections.
  • Brad moved to approve, seconded by Eric, 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] Brad managed to get some more slides out, which we'll go through. I've got a couple too, but they're more just some thoughts I had. They kind of fit in with some of Brad's, so I'll jump to them when it comes up.
    • {'SJTAG Volume 3 Consolidated V4.pdf' shared}
    • {Slide 26}
    • [Brad] I put the 1s and 0s in on this, that's all.
    • {Slide 27}
    • [Ian] This is a new one on the switch.
    • [Brad] Yeah, I'm following the ordering that was suggested last week.
    • [Tim] You might want the 'Selects' labelled more functionally.
    • [Brad] Well Select1 and Select2 are each shown selecting two different switches; I'm not sure how I could make that more functional - If you can, send me some suggestions.
    • [Ian] You make the point about complexity growing, and that's what my thoughts had been on, so I'll flip to my couple of slides now.
    • {'Switch_Complexity.pdf' shared}
    • {Slide 44}
    • [Ian] This was building from Brad's Simple Linker. I didn't have all Brad's primitives, so I just used some simplified ones of my own. Going from the 2-port linker Brad had to a 4-port one essentially comes down to adding one extra TBE per path, so the linker logic increases almost linearly with the number of secondary paths.
    • {Slide 45}
    • [Ian] However, we've already noted that a switch needs more logic than a TBE, and to go from a 2-port switch to a 4-port switch and continue to use the same super-primitive means you need to cascade a further switch onto each of existing branches, trebling the amount of logic. You can reduce the logic requirement, but only by breaking up the primitive.
    • [Brad] So you lose the reuse?
    • [Ian] Well that or you get the exponential growth that you mention. Anyway, this was just some thoughts I had.
    • [Brad] I think we can use those, or a version of those later.
    • {'SJTAG Volume 3 Consolidated V4.pdf' shared}
    • [Brad] Here I was trying to put the switch complexity 'in your face'. I was struggling a bit to draw one for three ports.
    • [Ian] I concluded that three ports was a waste of time with the switch; once you added the extra selection bits you might as well go for four ports. At least that was the case if you tried to scale using primitives.
    • [Brad] We may need to reiterate that point. The complexity may not be 2n, maybe 2n-1, since you'll usually have one port selected.
    • [Peter] May have the case where you want no local scan port selected, a loopback to check the thing is soldered down for example.
    • [Brad] Ah, loopback, good point!
    • {Slide 28}
    • [Brad] No change.
    • {Slide 29}
    • [Brad] No change.
    • {Slide 30}
    • [Brad] This is an attempt to introduce the concepts used by a lot of gateway devices used with bussed TAPs.
    • [Brad] This can support broadcast access if a separate select is supplied for TDO. You'll see I've now fixed TRST to use a switch.
    • {Slide 32}
    • [Brad] I've changed the text here to make it more of a protocol discussion. In this section we're now talking about controller logic.
    • {Slide 33}
    • [Brad] This is the slide on the 1149.1 state machine.
    • {Slide 34}
    • [Brad] This shows how you can use a Data Register to map onto the selection logic. More than one DR could be used. At the bottom, in red, I present the comment that the Scan Path Selection device is now part of the scan segment topology.
    • [Tim] Why does it need to be part of the chain? The ASP, for example, isn't.
    • [Brad] Well, it's from what we showed two slides before. The update protocol is 1149.1: ASP rides on top of that using a proprietary protocol.
    • [Tim] So this is just showing an example?
    • [Brad] Hold on to your thought, Tim; we'll come to it. I'm trying to show a progression here.
    • [Brad] I'm using the generic TAP selection blue box - could be a switch or a linker.
    • {Slide 35}
    • [Brad] Now I move on to the bridge type device, using a protocol to address a device. Combining the Instruction Register with the Address Register to create a SAIR.
    • [Brad] There is a state machine that goes with this, described in the text. Again we point out that the device is part of the scan segment topology.
    • [Brad] This slide is getting pretty busy, and I wondered if maybe it needed more than one slide.
    • [Ian] First thought is that the state machine could go onto it's own slide; maybe by making the diagram a bit bigger and annotating it we could reduce the description text. I'm not to sure how the rest of the slide would hang together though if we did that.
    • [Brad] That's what I wondered. I did try to overlay this onto 1149.1 state machine diagram, but it was difficult to show how it changes over time.
    • [Carl] The complexity ends up going somewhere, whether in text or graphics.
    • {Slide 36}
    • [Brad] This is the ASP, and introduces a different idea for the addressing. This puts the addressing into a different protocol space.
    • [Brad] The text here is straight off the TI data sheet.
    • [Brad] This does not add extra cells but it is a proprietary protocol.
    • [Brad] I was struggling with people who use I2C, etc., for addressing; all these things that are outside 1149.1. Should we talk about that here?
    • [Ian] I'd say we should bring that up earlier. It's likely to be the way people would approach the problem when they first see it anyway, to use some external control.
    • [Brad] The problem was I wanted to highlight the difference of transparency versus control.
    • [Peter] Transparency is only valid if you have a single chain. In most of the cases we're considering there are multiple boards.
    • [Brad] The argument for transparency is being able to use the same vectors from the edge multidrop and from a local controller.
    • [Tim] The sync bits - I don't really see the need for them in my applications.
    • [Brad] There are pros and cons on both sides. There's no one technology that suits everyone - it's dependent on the application. Some are more cost effective than an ASP. That's the tradeoff and some will only test from external or multidrop.
    • [Peter] It depends on the design.
    • [Ian] I think that's very true but it will disappoint some people who are looking for 'reference design' they can just take away and use.
    • [Tim] One thing I was noticing is that the 'problem' in the red text maybe doesn't come across that this may not be what you want.
    • [Brad] I couldn't really point it out as an issue.
    • [Tim] The industry probably wants one solution.
    • [Brad] I was wondering how we cover link bits, e.g. In an 'SJTAG Compliant' part the link bits can be either on or off, and existing devices are 'SJTAG Compatible'? There are a couple of places where link bits have saved the day, although usually I agree that they get in the way. When we used long cables for EST the link bits allowed us to wind up the TCK frequency. Now that we've moved to embedded we don't need the long cables.
    • [Brad] To review - We should introduce the external controls first, then show that we can to it using the scan path.
    • [Brad] Maybe even start off with user defined jumper blocks.
    • [Tim] Show that the control needs large amounts of I/O, then the user will want to move to something else.
    • [Brad] The next concept is how to introduce things inside devices like the P1687 SIB.
    • [Ian] Well maybe the way we've going up to now is starting from the board and building up to a system. Looking to the insides of a device is kind of changing direction. Maybe we should leave device internals to a later, 'advanced' section.
    • [Brad] I'm conscious of the presentation size - we've got a lot in here in a relatively short period of time.
    • [Ian] Any thoughts? are we still heading in the right direction?
    • [Tim] Yeah, I think so.
    • [Brad] I don't want the symbols to become too complex.
    • [Ian] Yes, when I threw my slides together, I felt the 'super-primitives' didn't need all the signals shown, at least for my purpose: Only the TDI and TDO were of interest.

5. Schedule next meeting

Schedule for May 2010:
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

At last week's meeting Brad made the following motion, seconded by Eric:

"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."

  • {Forum thread 'Path Selector TDI/TDO Naming Convention' shared}
  • [Ian] Did this wording make sense to everyone?
  • [Brad] I was fine with it!
  • [Tim] I still think this is something we'll want to come back to. You can't always guarantee the way you'll want to ame the signals, for example what about differences on the host side?
  • [Ian] I suppose even if we agree on a convention that satisfies us, we still have the real world devices that may not conform to our convention.
  • [Brad] Then they're only 'SJTAG Compatible'!
  • [Tim] Once we get further along we may find we want to put 'IN' or 'OUT' in the names.
  • [Brad] Like 'TCK_IN' or 'TCK_OUT'?
  • [Tim] Yes. Then there's the situation with multiple masters - what happens then? It's more complex, it's not always easy to see. Probably only way is to say 'IN' and 'OUT'.
  • [Brad] That was something Adam and I struggled with in the µTCA MCH with bidirectional signals; in one case it'd be an input, in another case it'd be an output.
  • [Brad] It sounds like we need to table this again.
  • [Ian] I think so. It could be that as we work through these slides some more that a natural conclusion will suggest itself.

7. Review new action items

None.

8. Adjourn

Eric moved to adjourn at 11:48 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.