Minutes of Weekly Meeting, 2012-04-23

Meeting called to order: 11:07 AM EDT

1. Roll Call

Patrick Au (left 12:11)
Ian McIntosh
Adam Ley (left 11:37)
Peter Horwood
Brian Erickson
Heiko Ehrenberg
Brad Van Treuren
Carl Walker (joined 11:10, left 12:07)
Harrison Miles (joined 11:26)

2. Review and approve previous minutes:

04/16/2012 minutes:

  • Draft circulated on 04/17/2012.
  • No corrections noted.
  • Brad moved to approve, seconded by Brian. 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

4. Discussion Topics

  1. Q2 Newsletter
    • {Carl joined}
    • [Ian] I sent out a draft of the newsletter on Friday.
    • {Newsletter shared}
    • [Ian] Adam pointed out a typo in the section on Board IDs which is corrected in this version.
    • [Ian] Are there any comments?
    • [Brad] I like what you've done about my suggestion of pointing out the mezzanine issue.
    • [Ian] I should maybe point out that Brad saw an earlier draft, when I had a much leaner section on the Board IDs and Brad suggested how it could be expanded.
    • [Ian] Does the automotive item do what it needs to? It makes the appeal, but the issue is still how we get it to the attention of those people.
    • [Brad] I think you've done all you can do. The graphic highlights the breadth of things they need to deal with.
    • [Ian] OK, I'll look for approval to publish then.
    • {Patrick moved to approve, seconded by Carl, with no objections or abstentions}
    • [Ian] Thanks, I'll send that out probably next Monday as that's the last day of the month.
  2. Board ID: What is the minimum equipment and services needed?
    • [Ian] I think last week we maybe ended up talking at cross-purposes. I think Harrison was mainly thinking about uniquely identifying individual boards where Brad and I were probably considering identifying the type of board. Anyway, we still haven't identified how we might store and retrieve an ID. But perhaps I should ask if there's a consensus that an ID is even necessary?
    • [Brad] The test data is what's needed. Either the data itself or a reference to that data and traditionally that's the board ID.
    • [Adam] Perhaps is obvious, but I think we consider the board ID to be necessary but not sufficient.
    • [Brad] I think we needsome unique ID to track the board through its life but you also need information on its attributes.
    • [Ian] I expect a single register could deal with both the unique element and manufacturer/model data, if you can decode it. I think that one of the faults we found with the ECID, that you couldn't guarantee being able to decode it to anything meaningful.
    • {Harrison joined}
    • [Harrison] Even taking that into account, you come back to the same point: You just know the vectors and the BSDLs. The point I was getting at is that more boards have FPGAs that can be programmed for different purposes.
    • [Ian] I agree. We want to reuse designs across products, so the same board might be programmed differently to suit particular contracts. The unprogrammed board will have one part number, while each programmed version will have different part numbers.
    • {Adam left}
    • [Harrison] The test procedure you use before configuration is just a confidence test. Another test after configuration can check other things but will have more constraints.
    • [Ian] If Tim were here, I'm sure he'd mention that with some FPGAs you need to at least configure the IO in order to make any test 'safe'.
    • [Harrison] P1149.1-2012 gets at that issue - SERDES interfaces where you have to set levels.
    • [Ian] Regarding constraints, as soon as you put a board in a system you will have constraints due to the IO context it is in.
    • [Harrison] It moves out of traditional test and into the hands of a diagnostician in a system.
    • [Brad] What you were talking about, Ian, you need the DFT in place up-front. You need to have a strategy for test and how you reuse tests. Without that it becomes salvage rather than reuse.
    • [Harrison] It needs a different mindset once it becomes active.
    • [Brad] Gets back to Harrison's observation about the different states of the board.
    • [Harrison] The x86 is a good example. If you successfully get to the Flash then you can run tests out of the BIOS but if the Flash is corrupt that's a different ballpark. The BIOS has the memory map and knows what to expect where. If you can't get the Flash to work then the only thing you can run is primitive parts. DDR3 you have to tune before the processor can use it.
    • [Harrison] Also it's very hard to run tests once the operating system has taken over as it could be stomping all over what you're trying to test and could crash.
    • [Brad] As we're looking over this I see two different cases: One where the board is autonomously testing itself; that's one model and where the board ID is not important. Then there's a pure multidrop, where the intelligence doesn't reside on the board, and may be external. That's two different implementation models.
    • [Brad] I've sent you some slides to help illustrate. See what system services we can leverage.
    • {slides shared}
    • {Slide 1}
    • [Brad] Boundary scan should be able to exploit system features used for functional test. Need to manage getting to the right state and there are other states than listed here as Harrison has noted.
    • {Slide 2}
    • [Brad] This is the Fault Management Flow. It's based on notification of events and shows how data has to flow within a traditional model.
    • {Slide 3}
    • [Brad] This is traditionally how software deals with diagnostics. My point is that you can treat JTAG the same as functional test.
    • [Harrison] You're going to have to plan it: The wrappers will be different.
    • [Brad] Yes, the wrappers may be different, but what you get back is going to be similar.
    • [Harrison] Instrumentation will help that.
    • [Brad] That's where slide 4 comes in.
    • {Slide 4}
    • [Brad] There are different domains. Software engineers don't really understand JTAG, just their own diagnostics. An API keeps the JTAG operation hidden. When we did this we found we didn't need any level of additional identification. It's when you can't get it to run and you need to look more at the structural aspects that you need more information. Most systems have a lot of self awareness.
    • [Ian] Going back to the matter of Flash, because that's an interesting point for me, generally if our systems get to the point of loading from Flash then we probably wouldn't use JTAG for test as the BIT is probably more effective for our aims at that level.
    • [Harrison] Yes, you're probably not going to go to JTAG.
    • [Ian] But if it doesn't load from the Flash, then I probably want to run JTAG so I can determine if there's a physical fault or just a corruption. Its probably one place where we don't just want a go/nogo on the unit, because if it's just a corruption I can probably recover that right away without opening the box or swapping anything out by simply reprogramming the Flash.
    • [Harrison] You and the Telecomm folks might do that, but I don't know that many other sectors have their systems architected for that.
    • [Ian] I think we recognised that SJTAG probably has a role to educate people on what is possible.
    • [Harrison] Some device now allow you to access them through something like USB. The Altera pod is USB so it looks similar. Most appliances previously did not allow the USB to be a host. In FPGAs like Altera's you can instantiate the JTAG port.
    • [Ian] Yes, that assumes that you can get the device to configure in the first place. If the Flash image is faulty then it won't configure so the JTAG port never gets instantiated. And if you've blown the Anti-Tamper bit you've already lost the physical JTAG port which is probably why you were using a soft JTAG port.
    • [Harrison] OK, BKMs need to be in place.
    • [Brad] You mentioned Flash, Ian: Jim Webster gave a presentation where he could do reprogramming on the airframe - it was part of the requirement he had. When you do that the question is how do you know what version of firmware is required?
    • [Ian] In our case we have a separate NVM that holds all the configuration data for that unit. However is manually updated so it's prone to error. On the other hand, we're maybe in a good situation because it's unlikely that our customers will have changed the configuration since delivery.
    • [Harrison] I think what that slide deck gets to is that design teams need to have BKMs and that you may need IDs to go to primitive levels. There are levels of knowledge, the lowest levels being when you can take it out of service.
    • {Carl left}
    • [Brad] You have to ask what someone's purpose was in putting JTAG in the system; some people will want to reduce NTFs and other just want to be able to upgrade firmware and don't care about NTFs.
    • [Harrison] NTFs seem to be the hot topic. Among the people we speak to it seems that everyone wants tackle NTFs, because it costs.
    • [Ian] I agree that if you ask people if they'd rather have fewer NTFs then everyone will say yes, but it may not be that it's essential to them.
    • [Brad] The driver is economics, maybe if it causes a large outage: An outage of less than 30 minutes doesn't need to be reported to the FCC, so if our customer has a choice between getting back in service in under 30 minutes or reducing NTFs they'll take the 30 minutes.
    • [Harrison] From what I've seen everyone seems to be aligning on NTFs.
    • [Ian] I see SJTAG as an 'enabler': For whatever reason you may initially choose to have it in your system, once it's there you have a means to use it for other things if you find they're useful to you.
    • [Brad] OK, but NTFs generally need more infrastructure in place: You need to know the state of sibling boards, etc., because testing a board in the workshop using a different configuration of system may not show the fault. Often we're dealing in the design margins. A lot of people I talk to don't want to get into that problem space.
    • [Ian] OK, we need to stop there; we're way over time today.

5. Key Takeaway for today's meeting

  • [Brad] Some form of ID is more important at lower levels of primitive than at higher levels.
  • [Brad] Testability has to be architected in up-front otherwise you're simply salvaging tests at the system level, not reusing them.
  • [Brad] If you put infrastructure in up-front then most use cases can leverage that although some will require additional environment.
  • [Harrison] Business drivers, e.g. upgrades or NTFs, need to be listed to hone in on a framework for the standard.


  • [Brad] I feel we're coming up with the idea of a 'virtual ID' that is part of the system but not necessarily JTAG.
  • [Brad] Maybe for next time we can use slide 3 as a basis and look at what the system services provide for identification and data for the various tests and what the JTAG tests require. The work on pruning down the needed data set to what is necessary where only JTAG is available and not the firmware: Gather the information by pruning rather than building.

6. Schedule next meeting

Next Meeting:

Schedule for May:
No meeting on 28th due to Memorial Day.

7. Any other business

  • Ian expects to update both the Forum and Wiki software on the SJTAG website in the coming weeks. During the updates, those services will be unavailable, although it should only be for a matter of less than an hour in each case.
  • Ian has made one or two small changes to the website in order to address the requirements of The Privacy and Electronic Communications (EC Directive) Regulations 2003 (the 'EU Cookie Directive'). This requires that a user must give permission before nonessential cookies are stored on the user's machine, and that the nature and use of the cookies is explained.

8. Review new action items


9. Adjourn

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

Respectfully submitted,
Ian McIntosh