Minutes of Weekly Meeting, 2011-10-17

Meeting called to order: 11:05 AM EDT

1. Roll Call

Richard Foster
Patrick Au
Ian McIntosh
Carl Walker
Heiko Ehrenberg
Tim Pender
Adam Ley (left 11:57)
Peter Horwood
Brian Erickson (joined 11:18)
Harrison Miles (joined 11:30)

Brad Van Treuren
Eric Cormack

2. Review and approve previous minutes:

10/10/2011 minutes:

  • Draft circulated on 10/11/2011.
  • No corrections advised, but Ian asked if the group felt that Brad's proxy should be included as part of the minutes. It was thought that this would be worthwhile.
  • Patrick moved to approve with the above inclusion, seconded by Carl, 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.
  • All: Review Programming/Updates Use Case from Volume 2 of the White Paper: http://wiki.sjtag.org/index.php?title=Volume_2#Programming_.2F_Updates_.28PU.29 - COMPLETE.

4. Discussion Topics

  1. Examine Programming/Updates Use Case and expand to consider structure and behavior.
    • [Ian] What we hoped to do today was to work from the Programming/Updates Use Case description that we have in Volume 2, and see how we could expand on that 'template' to add in aspects of 'structure' and 'behavior'.
    • [Ian] To try to help that along, I sent out a few slides on what I saw as typical programming scenarios.
    • {Programming.pptx shared}
    • [Ian] I'm not going to claim that these cover every situation, or even that they're completely accurate, they were more to give something to help visualize and talk round.
    • {Slide 2}
    • [Ian] Firstly, I felt that it didn't matter whether we were considering an embedded or external controller as the paths were essentially similar. Also, in either case, there would most usually be some scan path management device present. In some cases that could be transparent.
    • {Slide 3}
    • [Ian] This is the most basic case, a single device in the chain and directly programmed vis JTAG.
    • [Patrick] I thought Platform Flash wasn't programmed via JTAG.
    • [Ian] Platform Flash XL certainly isn't, but I think the older version is. But the point is that there are some Flash devices that are JTAG programmable. As I said, I may not have everything correct here.
    • [Tim] The Platform Flash, is that Flash that is programmed and then used to provide the configuration of an FPGA?
    • [Ian] Yes, Xilinx' particular flavour of that.
    • {Slide 4}
    • [Ian] Now we have two programmable devices in the chain. They may be different parts or even from different vendors or possibly the same parts with different programs. You need to get the data to the right part.
    • {Slide 5}
    • [Ian] Maybe a simpler version of the previous case, including some non- programmable part in the chain, or several nonprogrammable parts.
    • {Slide 6}
    • [Ian] The indirect programming of parallel Flash, where the data, address, and control signals are all supplied from JTAG IO cells on a device like a FPGA, PLD or possibly a processor. JTAG vectors setup the address and data lines and provide the write pulse.
    • {Slide 7}
    • [Ian] The configuration Serial PROM scheme, like the Altera EPCS configuration PROMs or the Xilinx SPROMs. The serial data and clock pins on the FPGA are usually dedicated to the function, and in some cases it may be necessary to configure the FPGA with a loader utility to get data from the JTAG port to the serial configuration port.
    • [Ian] OK, that was my slides. I should probably get the Use Case description open now. I guess I didn't really mention the scan chain management in there; It's kind of a constant presence in all of it.
    • {Shared Volume 2, Programming/Updates use case from the wiki}
    • [Ian] Now, what we wanted to do was extract the structural and behavioral aspects to add to what we've already recorded. I guess that under 'Application Fields' we've already touched on some of the things I had in my slides, so there's some allusion towards 'structure' and architecture.
    • [Tim] I think that scan chain management is the important thing here. Whatever tooling you have needs to be able to deal with it. You might have and ASP that you get into a transparent state: That's really nice but your tooling needs to know how to get it to that state. Or if you have some CPLD to switch chains then the software you're using needs to know about it.
    • [Tim] The software needs to have some abstracted view of the scan path management, how to select the chain, and have the tooling pad programming files appropriately.
    • [Ian] This applies to all Use Cases, and is a key element for SJTAG. These devices probably have both structure and behavior to be described.
    • [Tim] The ideal thing is that once you have the vendors tools open, you should be able to export to SJTAG the programming data with a setup of the path selection, etc. If you go through an intermediate tool, like STAPL, there is no real support for that.
    • [Ian] Getting from device vendor's tools to something usable in a practical, system level application is often awkward.
    • {Harrison joined}
    • [Harrison] The Connection here is on two levels: First you kind of need the notion of instruments, the other thing is testing between devices where the board hasn't yet been brought up to operation.
    • [Ian] Are you talking about interconnect test? What we're looking at here is programming.
    • [Harrison] Yes, interconnect, but it can be more than that. Once you have the instruments it opens up other possibilities. The Silicon guys need to get used to that idea yet.
    • [Tim] I can see how in the future you might have an instrument for programming: Maybe a processor that doesn't need to be alive, but you can access the instrument then just blast data at it.
    • [Harrison] Now you're using an instrument more broadly than test. A lot of people haven't even begun to look at that yet. Using instruments is radically different.
    • [Harrison] There are different stages of the language; you'll see issues once you get your board to full operation as there will be different, more, constraints acting then.
    • [Tim] I don't think I really see anything changing with what we have today. Instrumentation may be a factor, but in the future and on more complex devices. Dot 1 is still what we need to address the simplest case.
    • [Harrison] I can agree, but FPGAs are becoming vastly more sophisticated, and even in Altera's FPGAs you can see some instruments appearing, so there's acknowledgement there.
    • [Tim] I agree it may be important, but it's maybe a Dot2 for us. In the present, there are voids that we need to address. To get SJTAG moving forward we need to address the problems that people have.
    • [Harrison] Yes, and that is some of what's driving the current 1149.1-2012 proposals. Those wouldn't be needed if 1687 existed.
    • [Ian] OK, but that's really a current standard updating itself to address evolving comprehension of its problem space. I guess though it's also looking to silicon changes for support. I don't think that's where we are.
    • [Ian] While 1687 has its SIBs for managing path selection, we have an existing variety of ASPs, Scanbridges, Gateways, that all have slightly different control methods, protocols, and effects on the resultant chain. There's a parallel between the SIB and these gateway devices but they're not the same.
    • [Harrison] OK, but you maybe have to look at the SIB as a primitive. One way you can look at it is that once you get to the edge of the chip you send a setup command to kick off the path selection. That way they can look similar.
    • [Ian] That's the problem or part of it; current tooling doesn't see those in any consistent way.
    • [Harrison] I ind of look at instrumentation as the micro level of boundary scan and 1149.1 as the macro level. In 1149.1 you can't see below the chain level. Instrumentation lets you see into the micro level, and offers the possibility of going at speed.
    • [Harrison] One question is how do I take advantage of these to take control of my tests? I don't know the language, but its orchestration of the instruments, maybe for BIST.
    • [Ian] That's really where Gunnar was a few years back with his STAPL++.
    • [Harrison] You need orchestration between chips, and that chip orchestration is needed before you bring the board fully to life. To me that defines the scope. And clearly that's not anyone's domain right now.
    • [Tim] I have a question on IJTAG: Does it support broadcast to set something up? If that is the case and we also have traditional scan path devices then they might prevent that from happening.
    • [Harrison] I don't think that is precluded. The bigger issue is probably parametric, as you gradually ratchet up the power as it typically wont be linear. As you bring in other instruments they may demand other resources, such as clocks, or maybe the clock demand conflicts with another instrument.
    • {Adam left}
    • [Ian] OK, but I think the issue that Tim is trying to flag up is that if you have instruments in two devices that maybe need to be synchronized for some test, then other scan path management devices on the board might create problems with a broadcast instruction.
    • [Harrison] OK, but see that as an issue for the tool vendors. It's solvable and might need a two pass compilation, so you deal with it at generation time and not run time.
    • [Ian] But embedded situations you may need to do these things at run time.
    • [Harrison] But then that's outside of JTAG.
    • [Ian] But possibly not outside of SJTAG. It's part of the nature of the systems we deal with that the configurations are not always constant; they will vary over time.
    • [Ian] There is more we need to discuss on this, but we'll need to continue next time.

5. Key Takeaway for today's meeting

  • [Tim] Scan path management will be relevant in all Use Cases.

6. Schedule next meeting

Next Meeting:
October 24th (11:00 AM EDT, 4:00 PM BST)

Schedule for October 2011:
24th, 31st.
It was noted that the end of European DST will impact the meeting on 31st for members in Europe.

7. Any other business


8. Review new action items


9. Adjourn

Brian moved to adjourn at 12:08 AM EDT, seconded by Patrick.

Respectfully submitted,
Ian McIntosh