Minutes of Weekly Meeting, 2011-11-14

Meeting called to order: 11:05 AM EST

1. Roll Call

Ian McIntosh
Brad Van Treuren
Brian Erickson
Peter Horwood
Carl Walker
Tim Pender
Richard Foster
Harrison Miles (joined 11:28)

Patrick Au
Heiko Ehrenberg
Eric Cormack

2. Review and approve previous minutes:

10/17/2011 minutes:

  • Draft circulated on 10/18/2011.
  • No corrections advised.
  • Brian 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: 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: Condense gateway comments and queries into a concise set of questions. - Ongoing
  • All: Forward text file to Ian containing keywords from review of meeting minutes. - Ongoing.
  • Carl/Brad: Get annotated keyword worksheets to Ian by Wednesday Close of Business. - Ongoing
  • All: Consider how a keyword can be used to define the chain configuration for a given test step, and what that keyword might be.
  • Harrison: Prepare slide showing matrix of industry sectors by volume/mix. - Ongoing.

4. Discussion Topics

  1. SJTAG Website
    • [Ian] This maybe really AOB, but I just wanted to get this out of the way first. There are a couple of things I wanted to mention regarding the website.
    • [Ian] First, the hosting service has advised that they plan to move our site onto a cloud host. That should give a more reliable service, but a side effect is that the databases will be moved to dedicated MySQL server, which potentially breaks the existing script linkages to the databases. The server guys reckon they will automatically update the scripts during the migration, but I'm always sceptical of these things. In any case, there will be some site downtime during the migration, but it should only be a few minutes.
    • [Ian] The second thing, maybe less important, is that in the past several weeks I've upgraded all the software for the forums and wiki to the latest versions. From a user perspective, you shouldn't see any difference.
    • [Ian] One final thing: The 'Contact us' form on the website has been attracting offers from search engine optimization (SEO) marketers wanting to sell us services. I've made adjustments to the form submission script to detect these approaches and automatically tell them we're not interested.
  2. Examine Programming/Updates Use Case and expand to consider structure and behavior.
    • [Ian] It's four week since we last met and it's hard to remember exactly what we were trying to achieve at the last meeting! Basically we were using the Programming/Updates Use Case and looking to extend our description to include structural and behavioral aspects. We ended up discussing a possible P1687 based future where instruments might assist the programming.
    • [Ian] However, I think it's possibly dangerous to consider only an as yet incomplete draft, and would probably limit the scope for SJTAG adoption, so I'd like to concentrate on current technologies. I probably need to share the slides I had last time.
    • {Programming.pdf shared}
    • [Tim] I think the reason for going with this exercise was to see what should be in our 'dot0', narrowing down the focus.
    • [Ian] That's right, what we hoped was that by looking at the structural and behavioral aspects we'd start to see things are common attributes. And it tied in with some other discussions about the applicability of languages.
    • [Tim] What I recall was that when you ignored the tap selection, there were no issues at all, and everything worked. The whole TAP selection issue comes to two things: There's a need to be able to select a path, and that needs to managed by some software abstraction. As a follow on you get into things like multiple BSDLs, etc.
    • [Ian] Yes, OK. The chain management issue is one that goes across all the Use Cases. It's highly probable that any system we're likely to see will have some form of path selection and multiple chains. We've considered this before but always had difficulty with the abstraction.
    • {Harrison joined}
    • [Tim] At a high level you could have some directive like SetScanPath 0. You might want that to be something like SetTiAspPath 0, putting a device ID in the directive.
    • [Ian] That seems limiting. If you need to be device specific, I think you'd want to have something extensible so you can deal with future device types.
    • [Brad] Why we started talking about structural and behavioral aspects was that chain management was falling outside the scope of 1149.1: We can't really use 1149.1 constructs to describe path selection.
    • [Harrison] Thats the difference between SJTAG and the 1149.X standards. The first stage of instrumentation is probably more about managing the silicon floor plan. Really what is being considered just now is only for chips on a single board.
    • [Brad] In the purest sense of P1687, that's true. But you should be able to expand that out, adding the functional aspect.
    • [Harrison] I see two types of devices: Those that have chains to them and those with chains within them.
    • [Brad] P1687 still has some of the same issues: In the SIB, that 1 bit still needs to be set somehow. The SIB is a specialized form of our Bypass Element primitive. I don't think there's going to be an 'SJTAG way' and an 'Internal way' of doing this.
    • [Brad] To answer Tim's earlier point, for any path, there should be a way to call it to turn it on or turn it off. In P1687 there is a simplified problem space - they're not allowing anything that doesn't fit with dot1.
    • [Ian] P1687, like some other standards, is engineering the silicon to meet the standard. In SJTAG we're trying to work with the silicon and board architectures that currently exist.
    • [Harrison] One thing I've mentioned is working within Test Mode - that limits what you need to deal with. Once you go out of test mode you have a whole other load of things to deal with. Does SJTAG want to do things outside of Test Mode?
    • [Brad] Dot7 is already dealing with some of these same conditions.
    • [Harrison] Not really. There are similarities: The first thing is that the Star Hub is basically the SIB as I view it. Second, Dot7 allows hot insertions and third you could run an application that serves as a debug port. But none have explored not being in Test Mode.
    • [Ian] Is this maybe a pointer that Test Mode operation is a defining boundary for our Dot0?
    • [Harrison] That's what I was kind of leading up to.
    • [Tim] Does te SIB select one scan path or can you daisy chain several paths together?
    • [Harrison] Both.
    • [Brad] It's like our Bypass Element primitive. You can have a gang of them.
    • [Brad] We keep getting hung up on this entity we call 'chain management'.
    • [Ian] I guess because it's a key, recurring feature in system JTAG architectures. We can't really avoid chain management.
    • [Brad] So, should our Dot0 really be about chain management?
    • [Harrison] Maybe you have chain management in Test Mode and chain management in functional mode.
    • [Ian] I don't think so. So long as there's nothing travelling down into the chains, the chain management doesn't really care whether the downstream devices are in Test Mode or not. Our Use Cases are about how you use the chains. The chain management is separate from that.
    • [Brad] I think you're right. We're trying to work in the Dot1 domain. You get into the structural side once you have a configuration that's defined. Getting into that configuration requires the behavioral aspect.
    • [Brad] The configuration of system in the field may not be known up front.
    • [Ian] I think you can amplify that with the condition where you may have part of a system that's gone into a protective shutdown, but you still want to test the remainder of the system.
    • [Brad] There's a similar situation in P1687: A P1687 device may not be fully powered, so you need to take care that the SIB remains powered.
    • [Ian] I think Harrison alluded to that in the past.
    • [Harrison] There's a lot that can be done with a processor to test even a board that's not fully powered. It's a complication for instrumentation.
    • [Ian] OK, to summarize, our Dot0 might be centered around chain management or it might focus on operations only inside Test Mode.
    • [Tim] If there was an ideal SJTAG gateway, would it be a SIB?
    • [Brad] Probably not a SIB. The whole premise of a SIB is that it's dynamically changing the length of a data register. That contravenes Dot1 which assumes a fixed length.
    • [Brian] The Dot1 group is working on expanding Dot1 to nonstatic chain lengths to deal with unpowered blocks, although it doesn't have the hierarchy below it like P1687.
    • [Brad] That's part of the 1149.1-2012 work?
    • [Brian] Yes.
    • [Harrison] That's not that surprising. It's a direct response to the technology.
    • [Brian] That's why we're all here; systems are changing.
    • [Harrison] Possibly a superset concept.
    • [Brian] Another thing is that with P1687 and 1149.1 adopting PDL we need to consider where we are with this.
    • [Brad] Clearly that's where Rohit is trying to drive things.
    • [Harrison] That gives you the 'board BSDL'.
    • [Brad] One hang up with Unified PDL is how do you reference structural aspects in ICL that may not be present in P1687.
    • [Brad] Other standards are finding the need support both structure and behavior.
    • [Ian] As I understand it, PDL is still a 'moveable feast'?
    • [Brad] It is a moving target, yes.
    • [Ian] OK, we'll need to continue this later. Think over some of the things we've discussed today.

5. Key Takeaway for today's meeting

  • [Brad] Scan chain management may be the prime topic for the SJTAG "dot0".

6. Schedule next meeting

Next Meeting:
November 21st (11:00 AM EST, 4:00 PM GMT)
- Tim, Brad, Patrick and Heiko are likely to miss.

Schedule for November 2011:
21st, 28th.

7. Any other business


8. Review new action items


9. Adjourn

Tim moved to adjourn at 12:09 AM EST, seconded by Brian.

Respectfully submitted,
Ian McIntosh