Minutes of Weekly Meeting, 2011-04-25

Meeting called to order: 11:15 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Brian Erickson (left 11:48)
Tim Pender
Carl Walker
Brad Van Treuren (joined 11:17)

Heiko Ehrenberg
Adam Ley
Peter Horwood
Patrick Au

2. Review and approve previous minutes:

{Brad joined}
04/18/2011 minutes:

3. Review old action items

4. Discussion Topics

  1. The Multiple BSDL Problem
    • [Ian] Has the intervening week allowed anyone to think some more on this problem, or have any thoughts on the use of keywords?
    • [Brad] I've thought a little bit on this and I'm feeling that by considering the use of keywords we're maybe getting into tool implementation issues.
    • [Ian] I don't feel I've fully got to grips with this, but I was thinking that the range of possibilities here might mean we start talking about keywords with parameters, and that starts to raise other issues.
    • [Brad] I think we're starting to talk about changes in functional behaviour as opposed to static or structural change. This is new territory, somewhere no-one has gone down.
    • [Ian] I had a little think about this and bounced some things off a colleague: At test generation time, all the configurations we discussed could be handled, but by manually manipulating the netlists, BSDL mappings, etc., to get each test step. But what a lot of people really expect, maybe unrealistically, is to pull in the CAD files, push a button and get all the tests presented to them. But you still have the problem of system configuration changes to deal with.
    • [Brad] The Dynamic Path in HSDL is trying to deal with this. But that's still outside of the device. When we get inside the device it's a little different. We're not just changing the path; in the case of the FPGA we're also changing the functional behaviour of the IO.
    • [Brian] It is a reconfiguration of structure, but that term is already taken by 'FPGA land' - we need to find another term.
    • {Brian's connection dropped, 11:27}
    • [Ian] Internal path reconfiguration appears in P1687 - How do they term it there?
    • [Brad] I don't really see a definition - they just refer to the use of the SIBs. Most discussion is around reconfiguration of the TDR, so what we mean is somewhat like P1687, but not completely.
    • [Brad] When you look at the board level, with scan path linkers you're doing much the same thing, but our scope is now inside the device.
    • {Brian rejoined, 11:31}
    • [Brad] We're talking about a single TAP controller having its behaviour redefined. The same instruction register, but different definitions of the TDR for that instruction.
    • [Brad] May what we should try is to map out the features for each of these cases?
    • [Ian] OK, I'll pull up the slides so we can see as we talk.
    • {Ian shared the slides from the previous meeting}
    • [Ian] Here's the first case.
    • [Brad] What is key here is that you have two TAP controllers on a single instance of a device.
    • [Tim] One is the 'Hard TAP' and the other is the 'Soft TAP'.
    • {Second case displayed}
    • [Brad] This has a single TAP controller with a common Instruction Register but multiple Data Registers for that instruction.
    • [Tim] Which vendors offer that User register? I know it's in Xilinx.
    • [Brad] Altera. Possibly Lattice too. Probably any that have modules that you can load to allow you spy on the internals.
    • [Ian] I can only comment on Xilinx and Altera, as those are mainly what we use.
    • [Brad] Something to note is that this is a different design implementation from the normal mission mode.
    • [Ian] It's possible that it could be part of the mission mode.
    • [Brad] For serial programming yes, but I was thinking of where the address and data lines might normally be connected to a processor, through the FPGA.
    • [Tim] Was this Flash some isolated device or was it intended to maybe be used to configure the FPGA?
    • [Brad] It was sort of like a processor Flash. But the processor could use that to pump the FPGA.
    • {Third case displayed}
    • [Brad] Here, the left hand FPGA has to have some characteristics set up to allow testing of the ASIC. But the right hand one is unconfigured.
    • [Brad] We want to be able to map several models. But if you map models based on the part number, then you'll get goofed up. The normal process, if you're creating a cluster test is to define a model per device for the non- scannable parts. For the scannable parts, you define a BSDL per part number.
    • [Ian] So maybe you map by circuit reference?
    • [Tim] Circuit references still need instance data since the first case has two TAPs.
    • [Ian] Yes, so there's no single, universal, easy way out of this.
    • [Brad] As I said in my initial email to Ian on this, I don't where we're going to go with this in terms of a solution, but it's certainly making people think!
    • [Tim] In HSDL can you adapt the naming convention so you could use U3-TAP1 and U3-TAP2 instead of just U3 for that first case?
    • [Brad] The problem with that is when you map back to the netlist, which you need for things like getting the connections to the Flash. Otherwise you don't know what boundary scan pins are driving which non-boundary scan signals.
    • [Brad] HSDL provides some of the solution through the Member syntax, but you still have the question of how you define that second TAP.
    • {Brian left, 11:48}
    • [Tim] The BSDL would need define both TAPs.
    • [Brad] There is a requirement in BSDL that there is only allowed to be one TAP controller defined.
    • [Ian] It's almost a case of nesting one device within another.
    • [Brad] Or like multiple cores. I've tried looking at this from a IEEE Std 1500 perspective, and several other standards that all deal with similar issues but in different ways.
    • [Ian] That maybe gives us another problem in that we are trying to mesh with those other standards, while they're actually divergent.
    • [Brad] I was hoping that we can get to an abstraction that makes them all look similar. This is some of what Michele and I were trying to deal with in the NSDL we presented to P1687 - trying to leave whether it is a dot7 connection, etc., out of the part definition. Leave that to the procedural aspect.
    • [Tim] Going back to what Ian was saying about the push-button solution - I can't really see that being possible.
    • [Brad] You can get more automated than something purely manual.
    • [Ian] I think the push-button idea is aspirational. The nature of systems is that there will always be aspects that you can't derive from CAD data and that will require manual intervention in the test generation process. As it is, we can't even get a common description that can be shared across tooling.
    • [Brad] 'Common' can mean different things. I'm reminded of the Cube concept we discussed a while back, Ian, where you turn this thing called SJTAG around and you see different things from each face.
    • [Tim] What if we had some ECAD property attached to the chain, so if you had, say, 4 chains on your board, you might require that one chain is intact before you can use the others. Maybe create small chains first before assembling the big chain.
    • [Ian] Yes, there could be some value in that, but I think it only solves a small part of the problem.
    • [Brad] There is the concept of dependencies, but that's not strictly SJTAG.
    • [Ian] True, that applies at the board level too.
    • [Brad] What this does say is that we need to be very cautious about defining our data models, to not back ourselves into a corner.
    • [Ian] But it maybe requires a bit of crystal ball gazing over what may be in the future.
    • [Brad] There is some predictability. People knew that programmable devices were coming back in 1989. We know that there will be multiple cores; that we will want to test between those cores; that some cores may be powered up and some not, just as some boards in green systems may be in low power mode.
    • [Brad] Really, we are going to be getting into dynamic models.
    • [Tim] On those Energy Star systems, when part of the system is shut down you need to be sure you're not back driving anything.
    • [Brad] On multicore devices, as temperatures go up, you have each core getting different clocks.
    • [Ian] It seems to me that a lot of this is really a packaging issue. Higher levels of integration are putting multiple cores inside a single package.
    • [Brad] In some cases, the vendor is starting to view dot1 as the access mechanism.
    • [Ian] We're out of time again for this week. Although we've discussed it here today, we still need to close out the discussion on the value of keywords here with a larger group representation than today.

5. Key Takeaway for today's meeting

6. Schedule next meeting

Next Meeting:
May 2nd (11:00 AM EDT, 4:00 PM BST)
Please note new meeting number for next week!
Patrick will miss.

Schedule for May 2011:
9th, 16th, 23rd.
Probably no meeting on 30th due to Memorial Day holiday in US.

7. Any other business


8. Review new action items


9. Adjourn

Brad moved to adjourn at 12:19 PM EDT, seconded by Tim.

Respectfully submitted,
Ian McIntosh