Minutes of Weekly Meeting, 2013-03-11

Meeting Called to order by Brad at 11:09. Informed the group that Ian was out sick today and Heiko was on the road and will call in later by cell phone. So Brad was going to run the meeting today to cover the discussion on Mike Westermeier's presentation.

1. Roll Call

Roll Call:
Carl Walker
Adam Ley
Brian Erickson
Brad Van Treuren (arrived 11:07)
Harrison Miles
Heiko Ehrenberg (arrived 11:12)
Tim Pender (arrived 11:12)

Patrick Au
Ian McIntosh (Sick)

2. Review and approve previous minutes:

Approval of March 04 minutes (sent Mar. 04): Deferred due to not enough people to vote at the time

Any corrections?

3. Review old action items

  • 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
  • Harrison will attempt to come up with a table of use cases and their associated layer and what can be done at that layer. Ongoing.

4. Reminders

  • Consider Adam's three points (from the action from the first weekly meeting) and suggest what is preventing us from answering those questions:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • Forum thread for discussion: http://forums.sjtag.org/viewtopic.php?f=3&t=172

5. Discussion Topics

  1. Consideration of BTW 2005 presentations (Mike Westermeier, Brad Van Treuren)
    • Brad shared the presentation Mike Westermeier presented at BTW 2005. This presentation is stored on the sjtag.org web site under:
    • Brad stated he was not going to cover the whole presentation, but felt it was important to capture some of the key concepts Mike was presenting that relate to the issue of the SJTAG ScanInterface as per last week's discussion.
    • Slide 5: Mike was doing more than just test with his application. There were a lot of programming applications, control of different bus protocols, like I2C, and the use of SAMPLE to obtain values of signals from the hardware.
    • Slide 6: Mike had the Application Layer as well as the TAP Controller Layer and all this was fit together by the Embedded JTAG, which ended up being the STAPL player. So the middle layers we talked about last week all resided inside his STAPL program.
    • Slide 11: Why not SVF? There were features required to be supported that could not be represented in a single SVF file. Things like devices with the same ID code, but different scan chain lengths; alternate IDCODES; and the support of system level gateway selection commands like the ASP.
    • Slide 16: There are a set of ScanInterface primitives available that allows one to write and read data to/from the UUT. There are functions available to perform vector modification within the language. There is even flow control supported within the language so one could alter the flow of execution after comparing captures responses with selective expected responses. One can even control board signals that are tied to non-boundary-scan devices.
    • An important aspect Mike shared is his ability to control a DAC (a non-boundary-scan device) using the boundary-scan pins surrounding that device so he was basically able to demonstrate he could control anything if he could digitize it into a series of scan commands. This is a very important and critical piece to Mike's insights.
    • Slide 17: Mike claims that all of the scan primitives required at the system level were available inside STAPL with the ability to define additional user defined commands through the EXPORT command. STAPL provided the flow augmentation necessary to respond to differences in results as well as provide mechanisms for reporting the decision process. STAPL also provides powerful bitwise and math operations and the support of vector data.
    • Slide 19: The EXPORT statement provides a very powerful mechanism for extending the command set of STAPL. The player detects the EXPORT command and calls a user defined command handler that takes the and the argument expression . The user handler then performs the appropriate operation requested by the extension. This feature opens up a wide range of possible things the program can do, including calling functional test aspects to be integrated into the command flow.
    • Slides 20 and 21: Here are some more examples of what can be done with the EXPORT statement.
    • Brad: I was hoping this was a different presentation of Mike's than the one shown. In that presentation, Mike shared the case where he was able to control the BIST operation inside of a non-boundary-scan device using the surrounding boundary-scan pins to manipulate the functional registers to kick off the BIST operation. He was then able to SAMPLE the output pin of the device that showed the status of the BIST results after a period of time. So Mike was able to show how he could turn any instrumentation operation into a scan sequence that could be controlled via a boundary-scan interface and language at the system level. The most important point to make out of this presentation as it relates to the discussion we had last week is the last item on Slide 16.
    • Basically, anything you could digitize you could test. This provides great possibilities into what can be done at the SJTAG level and Mike has demonstrated and illustrated many of the key core primitives required from an interface through the commands he uses within his version of STAPL.
    • Harrison: This really does get back to what we were talking about the ScanInterface in that Mike is demonstrating what I was calling the south direction of the stack we looked at last week. There is a north direction that points up to the Application Layer that Mike has rolled all into one with STAPL here, but there are definitely primitives he is using that exist as the south direction.
    • Brad: I would agree with that assessment.
    • Harrison: You talked about how Mike's access to functional instrumentation through the digitization using boundary-scan is much like what is now available with the existance of P1687. Certainly, P1687.0 is not defining for us the portion we need to perform the inter-device actions required at the board level and system level. There is going to need to be some sort of an ICL at the board and system level that will be able to describe how all of this stuff fits together.
    • Adam: I am not sure if I agree with that statement. I am not sure if ICL is really the right abstraction for this interface.
    • Brad: I am not comfortable with the level of structural details ICL requires to describe a "behavioral" connection to an instrument. It may not be the actual logic involved, but behaves like the logic implementation. There is more described than is necessary to describe the interface. Certainly, the tooling needs more than just the netlist.
    • Adam: I think it is going to be up to the Test Engineer to use the netlist, BSDLs, some description of the interactions between devices or instruments and the definition of the functional behaviors of the devices. I don't know what that is right now or what it should even look like. I just know what is in ICL is not the total solution and it is really going to be up to what the Test Engineer needs in order to do their application.
    • Harrison: OK, but there will need to be some level of description to show how these instruments are connected together to get to the understanding of how they interact at the board level. P1687.0 does not supply this level of description required for us. It may be something coming an a P1687.1 or maybe it is the lowest level of SJTAG.0. Time will tell. My point was we need to have some description that tells us the what the instruments interact with each other across chip boundaries. Right now, P1687 does not do that and we need that to move forward at the board and system level.
    • Brad: I would agree that we need some level of description to define the interactions, but I think ICL is overkill for what is needed to describe that capability.
    • Harrison: Maybe so. But I just wanted to have people realize that there is an aspect not yet covered by any of the standards for describing the cross device and cross board boundaries. This is something that we may have to take on.
    • Brad: The main problem I have with ICL, as stated by P1687, is the purpose is for addressing how to decide what to do at the "Retargeting Level". What Mike has shown is there is a real need to make decisions real-time and on-the-fly as to what vector content needs to be applied to the UUT. It is not something that can be done by a canned retargeting tool.
    • Adam: I will have to say that Retargeting is really not that difficult when you look at the purest sense of it. We have header and trailer manipulation in SVF and STAPL that performs the ability to retarget a vector defined by a PDL by using padding bits. That is a pretty simplistic form of Retargeting. When you get into P1687, it becomes much more complicated in that you now have to deal with opening up SIBs and the necessary structures to gain access to the registers targeted by the PDL. That requires more intelligence than just padding with header and trailer bits. But it is something that can be done for a vector.
    • Brad: My problem is retargeting is pretty straight forward when you are dealing with a single instrument. The original purpose for retargeting was to be able to support legacy ATE equipment needing to validate the instrument is doing what it was intended to do. When you start mixing in interactions between devices, retargeting becomes much more complex. You then find that one has to adapt the vector patterns for the board more in real-time that relying on canned pre-processed retargeted vectors. This is the kind of example Mike was sharing in his presentation.
    • Adam: Certainly, retargeting becomes more complex as you add more interactions across the chip boundary, but it is something than can be managed and that is what the tool vendors have to handle. I don't think the P1687 community has a solution for this yet.
    • Harrison: That was not the vision of the P1687.0 domain and will have to be addressed either by P1687.x or by some aspect of SJTAG.

6. Key Takeaway for today's meeting

  • Important ScanInterface primitives were defined my Mike in his presentation.
  • Basically, anything you could digitize you could test.
  • Need for a description for defining the interactions between devices/ instruments. This is currently missing from any of the current standards.
  • Retargeting becomes more difficult as you include interactions between devices.

7. Schedule next meeting

- March schedule: 18, 25
Brad reminded attendees about the US being on daylight savings time and the UK still on standard time until the end of the month. UK call-in users need to call in at 3PM.

8. Any other business


9. Review new action items


10. Adjourn

Adjourn Called by Tim. Second by Heiko. Closed at 12:02PM EDT.