Minutes of Weekly Meeting, 2011-04-18

Meeting called to order: 11:05 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Richard Foster
Adam Ley (left 11:58)
Peter Horwood
Tim Pender
Carl Walker
Patrick Au
Brian Erickson
Heiko Ehrenberg (joined 11:08)
Harrison Miles (joined 11:09)
Brad Van Treuren (joined 11:35)

2. Review and approve previous minutes:

{Heiko joined}
{Harrison joined}
03/28/2011 minutes:

  • Draft circulated on 03/28/2011.
  • No amendments noted.
  • Brian moved to approve, seconded by Eric. No objections or abstentions.

04/11/2011 minutes:

  • Draft circulated on 04/11/2011.
  • Three amendments noted:
    • In 'backplane' change 'out' to 'our'.
    • In 'boundary' change 'cress' to 'cross'.
    • In 'BSM' change 'ahistorical' to 'a historical'.
  • Eric moved to approve with the above amendments, seconded by Richard. 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
    (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
  • 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

4. Discussion Topics

  1. The Multiple BSDL Problem
    • [Ian] A bit of a break from the tedium of recent weeks. This was something Brad and I talked about a few weeks ago: I'd hoped he'd have been on the call by the time we started on this, but I'll try to talk through this.
    • {Ian shared the slides that had been circulated with the calling notice}
    • [Patrick] Having two BSDLs is a problem: Is there any way to merge them into a single BSDL?
    • [Ian] Well, I think that's the point - there isn't an easy way to do that.
    • [Harrison] If I can check to see that I understand what's intended here: In the first case, we typically have an FPGA that's not connected to a processor on the board. For the second case I can see two scenarios: A server blade with dual configurations or where there's an FPGA hanging off of a SouthBridge. The first case is a more classical design, while the second is a more modern approach.
    • [Tim] I've created an example just like that first one with a PLD and what I call a 'soft TAP' in addition to the 'hard TAP' for the device. For the second case, I see that as a single TAP with a MUX inside the FPGA that determines which chain to use.
    • [Ian] I have to say that the first case is something that we do a lot. It's pretty common for us to have almost exactly what's drawn on that first slide with no processor available at all. I'd say calling it 'classical design' is probably fairly accurate.
    • [Harrison] I can see that for the aerospace segment of industry.
    • [Ian] I'm just interested in why you see the presence of a processor as a factor here?
    • [Harrison] If a processor is connected to the FPGA, you can get an alternative way to get to it for programming. You can choose how to program the FPGA. The challenge going forward is that FPGAs and Flash are getting quite large.
    • [Ian] That's something we've mentioned a while back: In production test, especially for higher volumes, using BScan for programming isn't very cost effective, so you might be going through Ethernet. But I always want to have BScan as a back door in case we end up with a corrupted configuration.
    • [Harrison] I appreciate that, I just want to note that some segments may have an issue with BScan being available as a back door.
    • [Tim] The difference in the third case is that you have one FPGA in a configured state and one in an unconfigured state. So you may need multiple BSDLs per circuit reference, not just per device type.
    • [Harrison] Ah, maybe that's the key. We're talking about a runtime configuration tool. I can see maybe two ways to deal with this: You can use a keyword that the user declares as they create the procedures. Then it doesn't need the runtime decision.
    • [Harrison] The keyword determines whether the FPGA needs to be configured and effectively creates a test step. That gives you a lot of flexibility.
    • [Harrison] BSDL just gives capabilities.
    • {Brad joined}
    • [Brad] I had about 10 minutes to throw those together!
    • [Ian] Harrison was talking through his thoughts on this. I'll maybe ask he can run through it again quickly for your benefit Brad.
    • [Harrison] The easiest way I see is, well, The BSDL is a description of capability not usage. A keyword that the designer uses, say in case 3, can define that you want to test FPGA 2 after configuring FPGA 1 so that the right test step is created.
    • [Brad] That's possibly a little too simplistic. BSDL also defines the register mapping, and what I'm saying is that can change, especially if you consider the P1687 case.
    • [Harrison] For now lets break to pre-1687; that adds maybe 2 layers to things.
    • [Brad] Let's step back and look at it from a dot 1 perspective. Even the User1, User2, User3 registers can be defined, and which would need a different BSDL for each configuration.
    • [Harrison] That maps into same situation as with processors. We're talking about instances of FPGAs: Assign to the instance which configuration you're using for each test step, then string them together. It's messy, but doable. Some state information is needed though.
    • [Brad] The problem is that CAD only has a single physical instance for each device, so there's no way for tooling to know what configuration to apply to each instance at a given time.
    • [Harrison] It a bit more deterministic than that. Not all possible configurations will be used. It's not hard to manage but a bit messy. Hopefully it doesn't have a lot of recursion. Multiple BSDLs associated with instances puts pressure on the tools and on the user.
    • [Brad] You're talking about theoretical tools and not what exists today.
    • [Harrison] If we step outside P1687 - The 'glare period' for P1687 is maybe 5 or 6 years from now, based on first ballot in February 2012, as dot6 took about 5 years for adoption. How bad is this problem? Is it something that's more immediate than P1687?
    • [Harrison] This pushed the envelope of the BSDL.
    • [Brad] It's like VHDL talking about the static structure. Now we're starting to see dynamic aspects.
    • [Harrison] I don't even think P1687 is dealing with this.
    • [Brad] It's foreshadowing a problem with the circuit models. I was hoping to focus on dot1 for today.
    • [Harrison] Just to deal with what they're doing for dot1-2011 they've added five new commands. This may be more than dot1 can cope with.
    • [Brad] The reason I thought this issue relates to SJTAG is it is similar to the problem space where there is dynamic configuration of boards: A board gets pulled out of a chassis and is replaced by another board. That board might be of the same type or may be something totally different going back into that slot. In fact, I have seen boards that are physically identical, but the programming of the board turns it into a totally different application. So as we see more and more programmable devices showing up in designs, the nature of the board may not always be the same even though the CAD data is identical.
    • [Harrison] You probably at least need to have:
      • JTAG support on the backplane
      • New cards come in in Out-of-service Monitor
      • If it is a processor unit then it probably has a unique ID so you at least know it's not the same one, even if it's the same type.
      A second level depends on rules, that the industry doesn't actually use much as yet, where the manufacturer creates a hash code as a unique identifier. The third level is that each instance has a hash code. ATCA allows you to do this, but that's not necessarily true for other backplanes.
    • [Brad] That's not mandated, even in ATCA.
    • [Harrison] No but, these are things I think you'd need. For low end processors you may not have the features, but high end processors will support what I described. It no different to what happens now in pharmaceuticals where everything can traced to which lot, and which box, and which palette, in which container it was shipped.
    • [Brad] I see many designs for uTCA and ATCA coming through with the Board Management Controller implemented as a softcore processor inside an FPGA instead of a physical processor. So the processor IDs you talk about may not always be available.
    • [Harrison] Even the FPGAs have some sort of identification where you could achieve the same tagging in that case.
    • [Brad] I'm curious what others have to say as I got a few emails after Ian sent these slides out.
    • [Ian] The first case is certainly something we do. Security is part of that.
    • [Patrick] We have a CPLD attached to the SouthBridge.
    • [Brad] Does your tooling allow you to do these things?
    • [Ian] Well, we deal with it at a higher level, outside of the tooling. So the tools only ever have a static situation to consider.
    • {Adam left}
    • [Brad] So you deal with the differences in configuration in the wrapper code that is managing the test. That way you can deal with different design configurations for the same board.
    • [Tim] You can't really handle dynamics - it makes it tough to manage.
    • [Brad] Carl will maybe relate to this as another company of acquisitions, but different Business Units can see things differently. In some of our BUs the wrapper can only support a single design, while in other BUs it's fine. We need a realization of instance modelling, with the keyword to select which model.
    • [Harrison] How do you get there quick without decimating existing tooling?
    • [Brad] CAD doesn't give enough information to decide which configuration you're using.
    • [Harrison] CAD is basically a flat file.
    • [Brad] I started to look at HSDL, because it deals with dynamics, to see if HSDL could describe it. And it sort of does, but it deals with the dynamics of selecting physical instances and not of what instance to use inside a device. What this issue is dealing with is a dynamic change of a configuration inside a device or you could think of it as a different dynamic path inside the device. This is why I stated it is a similar problem to the P1687 domain. HSDL does not seem to deal with this case. It only deals with selecting which device path. If you have two HSDL devices, it does not match what the CAD defines.
    • [Harrison] I think what's needed from the team in the short term is to think about what kind of keywords we need. Even if we had P1687, it kind of makes it worse: Each has a connectivity map.
    • [Brad] My concern is dot1 is dealing with a problem where BSDL does not describe what it needs, so it is creating a PDL. This PDL is similar to P1687's PDL, but not the same. P1687 needed to create its ICL and PDL because the group felt BSDL could not describe what the standard needed. SJTAG is going to have to describe similar problems that we envision BSDL is not capable of describing. The concern is each standard seems to be dealing with this problem in their own way and not resolving the problem with a common solution. It may not be possible, but we should at least consider it.
    • [Harrison] I see Dot1 feeling that P1687 is taking too long and doing their own thing. You're seeing this problem because P1687 is taking too long.
    • [Brad] I see a lot of cases where P1687 is clearer than Dot1.
    • [Harrison] OK, but the IDM has to retool for P1687. If it were just the rules it would be OK.
    • [Brad] Are we working around a BSDL that's reaching the end of it's life?
    • [Ian] We're out of time, so we'll have to leave it there for this week.

5. Key Takeaway for today's meeting

  • [Harrison] The user should set a keyword at test generation to define the configuration to be used.
  • [Brad] BSDL is a static representation, and cannot deal with dynamics. 'Is BSDL running out of steam?'

6. Schedule next meeting

Next Meeting:
April 25th (11:00 AM EDT, 4:00 PM BST)
Patrick and Heiko will miss.

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

7. Any other business

None.

8. Review new action items

  • All - Consider how a keyword can be used to define the chain configuration for a given test step, and what that keyword might be.

9. Adjourn

Eric moved to adjourn at 12:15 PM EDT, seconded by Tim.

Respectfully submitted,
Ian McIntosh>