Minutes of Weekly Meeting, 2011-05-09

Meeting called to order: 11:09 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Adam Ley (left 11:53)
Heiko Ehrenberg (left 12:08)
Patrick Au
Carl Walker (left 12:00)
Peter Horwood (joined 11:13)
Tim Pender (joined 11:14)
Harrison Miles (joined 11:14)
Brad Van Treuren (joined 11:16)

Richard Foster

2. Review and approve previous minutes:

04/18/2011 minutes:

  • Updated draft circulated on 04/22/2011.
  • No further amendments noted.
  • Motion to approve by Eric, seconded by Brad, no objections or abstentions.

04/25/2011 minutes:

  • Draft circulated on 04/25/2011.
  • Three corrections noted, all near the end of the discussion, item 4a:.
    • In comment from Brad change 'tha' to 'that'
    • In comment from Tim change 'hern' to 'when' and 'your' to 'you're'.
  • Motion to approve with the above amendments by Eric, 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.

4. Discussion Topics

  1. The Multiple BSDL Problem
    • [Ian] Last time, we were considering that a keyword was maybe part of the tooling implementation. Also, as I was writing up the notes, I wondered if the BSDL problems we'd identified were really system level or board level or device level issues.
    • [Harrison] You could argue that BSDL is getting over strained: It's probably behind, for some of the things we discussed. BSDL in and of itself is a static description.
    • [Brad] It's important to note that it's not just a BSDL problem domain. I've just come from a meeting where we were discussing Flash devices: There are three Flash vendors allowed on our products but only two on this particular board, so we need to test that the Flash is not the third.
    • [Harrison] That's a third problem you've identified: If you look at the JEDEC specification, it optionally allows a manufacturer to incorporate ID information; it doesn't require it. If that was mandatory then it'd take away a lot of that problem.
    • [Brad] Yes, but the bottom line is that tooling needs to allow handling of those allowances and exceptions.
    • [Harrison] If there's a recommendation here, then it should probably go to JEDEC. It doesn't solve everything, but it solves one leg of the stool.
    • [Ian] In some ways, I see this issue as having less impact that some of the other things we discussed, since we're only talking about what is in the ID codes. The other cases, where the DR length can be varying, is a more disruptive form of dynamics.
    • [Harrison] Yes, but this would also help to deal with some of the counterfeit component issues.
    • [Brad] Some of the counterfeit issues aren't intentional. Sometimes parts get returned to distributors, but they're parts the user got from somewhere else.
    • [Harrison] And not all distributors are certified. Some don't have consistent mechanisms to filter out these problems. There was also the case of a major vendor who marked parts as bad but failed to filter them out from the delivered product.
    • [Ian] I think our experiences of counterfeit parts have been like Brad's, where "A N Other" client has bought parts from our approved distributor and also some grey market parts and returned grey market parts to the approved distributor, and so they ended up in our supply chain.
    • [Harrison] JEDEC has a framework in place. There are about 80 silicon vendors in the Flash market. The top 25 will follow the rules, and they control maybe 2/3 of a $300bn market. Things begin to go iffy with the last 60 or so. Removing the option would largely solve the issue, but the only buyer that could force it is probably the US Government. Most OEMs are driven by cost.
    • [Harrison] All chips have an ID and what wafer it came from anyway. It's very like the pharmaceutical industry.
    • [Brad] How does this impact on SJTAG? Last time, I think we were concluding that the keyword seemed be more an aspect of the tooling implementation of part of the solution.
    • [Ian] That's pretty much what we said.
    • [Brad] Or was there something more of an abstract perspective in what was meant by a 'keyword'?
    • [Harrison] Maybe I missed that. If I take the root premise: The Use Cases shown imply a mode change through the test procedure. The change is a consequence of the tester making a choice of what they want to do. There's nothing that makes it obvious what that choice is without a keyword.
    • [Brad] The keyword is more like labelling of the configurations: Providing a unique identifier for each configuration of a device.
    • [Harrison] There is a precedence for this in FPGAs. Maybe CPLDs is an even better example, where they have compliance pins that need to be set if you want to test before the device is configured or after. If you could have conflicting drive signals. After the device is configured, I can only do this subset of tests.
    • [Brad] That also gets into preconditions that have to exist; some state that has to be achieved.
    • [Harrison] The newer x86 family processors have a whole bunch of things that have to be right before you can test.
    • [Brad] Can all of these preconditions be asked within that notation?
    • [Harrison] I believe you can. BSDL is a flat file representation, and the vignettes are not there.
    • [Harrison] A keyword might only be a warning that tells you that you need to look for something else. For example, an x86 may give one level of warning, a high end FPGA or SoC another level, then CPLDs.
    • [Brad] I'm trying to get a handle on the relation between the keyword and a BSDL entity here.
    • [Harrison] Tools currently have to use BSDLs. I'm thinking of something that happens during the first pass compilation; if it's an x86 then put a warning statement. You can't put it out as a failure.
    • [Harrison] A lot of the vendor guides will tell you to put the processor in its own chain; I'm not sure why that is.
    • [Ian] I think the main reason is so that the vendors own debug tools will work properly.
    • [Harrison] Well, maybe they're taking shortcuts with their UIs then.
    • [Brad] I think we're talking about levels of compliance here?
    • [Harrison] I thinking of the keyword in a virtual sense.
    • [Ian] Are we talking about an extension to the Design Warning in BSDL?
    • [Harrison] No, we really need to separate design issues from test issues.
    • [Harrison] Cost drives chipset selection, so designers won't always follow the vendor recommendations on part selection. A processor manufacturer will recommend what they consider to be the optimum design, as is used on their reference board.
    • [Harrison] Self test is another issue.
    • [Ian] We often have a requirement to be 'ready' within two or three minutes after switch on. A lot can happen in that time, but we still may not be able to do all the things we'd like to, because there's a chain of events that needs to happen.
    • [Ian] Some processor boards' BIST could take 10 minutes or more if you let it do everything, so we have to choose the subset of testing we want.
    • [Patrick] Some of ours can be even longer than that.
    • [Harrison] But some those things will be relevant to board test and not system test. You need to concentrate on just those tests that confirm connectivity otherwise you get caught in that whole structure before you get to the presentation layer.
    • [Brad] I wonder if Adam could comment here on how dot7 deals with things like identification of different cores within a device?
    • [Adam] I'll need to take an action to prepare something for next week, as I'm just about to leave for another meeting right now. {ACTION}
    • [Brad] I think it's an important data point for us to make comparisons with sister standards projects.
    • {Adam left, 11:53}
    • [Harrison] Dot7 only targeted a smidgeon of the problem, like debug with multiple cores, but not some of the other stuff. I don't know if you ever saw the mipi.org website, but the main thoughts from there that went into dot7 were 'I want higher speed because I want to debug', 'I don't want to use five wires', 'I want hot insertion'.
    • [Brad] But they had to have run into the same issue of a single device with multiple personalities.
    • [Harrison] They approached it by layering it. First they figured out how to use the state machine to get their commands in, then brought in the hub architecture, then the hot insertion aspect, then as future proofing added the user defined thing to allow for future applications.
    • [Brad] I guess my question really was did they try to describe things in a physical sense or an abstract sense or was it a combination of both?
    • [Harrison] It's a combination of both.
    • [Harrison] I think all of these standards, dot7, P1687, are buzzing around the same things:
      1. The state machine of dot1.
      2. Dancing around BSDL.
      Now, devices are combinations. On top of that, they're now multicore.
    • {Carl left, 12:00}
    • [Harrison] The military have been using multicore for years.
    • [Brad] P1687 is trying to deal with just their own area. In doing that they've come to a structural description as well as a functional description.
    • [Brad] Are we coming to the conclusion that we need something structural as well as functional?
    • [Harrison] Yes, but here is the dilemma: The silicon vendors will say 'You want us to wrap up my instruments, that we've spent thousands of man-hours creating, in PDL so it can connect to ISCL, so it can connect to a network? OK, but that's going to be expensive.' Dot7 only got half way to the goal.
    • [Brad] Dot7 doesn't care how that TAP gets connected.
    • [Harrison] I haven't seen too many people doing anything with dot7 yet.
    • [Brad] Its cutting over to functionality.
    • [Harrison] Now you come down to investment - old instruments don't have a TDR; they were not intended to be used for board test.
    • [Brad] I see the question of how you validate something complies with P1687?
    • [Harrison] Yeah, there's a huge investment for the silicon vendors.
    • {Heiko left, 12:08}
    • [Brad] How does this affect SJTAG.
    • [Harrison] I think you have the hierarchy of complexity, with x86 at the top then FPGAs with softcores, SoCs, then CPLDs.
    • [Harrison] There's the issue of speed. You can't really put test points on signals much above 3.3GHz else it'll mess the signal up. Around the core is where you want to have test points, the signals to the DDR3 RAM, the Southbridge, etc., and more that 70% of boards have a processor. The key thing becomes getting at least that processor to the backplane, then you get access.
    • [Harrison] SJTAG needs to promote that. There are plenty of language structures around, like XML. The most important thing is to bring the processor JTAG out.
    • [Brad] I'm not convinced it is as clear cut as that. There could be hard cores and soft cores and processors in the package.
    • [Harrison] SoCs are now mainstream. A few years ago that wasn't the case, but they've finally made the top three, to the extent that analysts are now tracking them.
    • [Harrison] There are a few key points converging towards a nexus. Everybody is wanting speed on convergence.

5. Key Takeaway for today's meeting

Due to the volume of discussion, Brad moved to defer nominating any takeaways until the draft notes could be perused, seconded by Harrison.

6. Schedule next meeting

Next Meeting:
May 16th (11:00 AM EDT, 4:00 PM BST)

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

7. Any other business

  1. The next Newsletter is due at the end of May, and we do not expect to be meeting on 30th.
  2. Rohit has advised that the Working Group poster will be run at ITC, as last year: We need to advise Bill Eklow if we intend to support this, so anyone who anticipates attending ITC should advise Ian as soon as possible. Harrison noted that he will attend as it is "local".

8. Review new action items

  • Adam: Prepare response to Brad's enquiry on identifying different cores in a device within dot7.

9. Adjourn

Peter moved to adjourn at 12:23 PM EDT, seconded by Eric.

Respectfully submitted,
Ian McIntosh