Minutes of Weekly Meeting, 2012-04-16

Meeting called to order: 11:04 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Brian Erickson
Brad Van Treuren
Adam Ley (left 12:00)
Carl Walker
Harrison Miles (joined 11:08)
Peter Horwood (joined 11:29)

Heiko Ehrenberg
Patrick Au
Tim Pender

2. Review and approve previous minutes:

04/02/2012 minutes:

  • Draft circulated on 04/02/2012.
  • No corrections noted.
  • Brian moved to approve, seconded by Brad. 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 to consider an appeal to SJTAG email newsletter recipients for participation from the automotive industry in the next newsletter. This action needs to be completed by next meeting.

4. Discussion Topics

  1. Board ID: What is the minimum equipment and services needed?
    • [Ian] I'd had one or two thoughts about the possible problems in retrieving a board ID if we assume that it's done purely through JTAG: For various architectural reasons, it may be that the 'main' scan path isn't on the seemingly logical local chain zero as determined by the chain management device. That's partly why I'd earlier asked the question about possibly using other interfaces, such as I2C.
    • [Brad] You need to know what the architecture is for the interface. You've mentioned having gateways on the backplane, and then further chain management behind those. It's the same problem domain for mezzanine boards with gateways to secondary chains. Assuming the use on 'chain 0' may be true for some architectures but not for others.
    • [Harrison] This either looks like an automotive problem or a P1838 problem. Each car has a VIN number that is it's identity and acts like a kind of hash code. Each part has some sort of sub-hash number.
    • [Ian] OK, I understand that but the VIN is physically readable. It may also be electronically readable, but not necessarily via a consistent interface.
    • [Harrison] JEDEC has nothing that makes this unworkable, apart from some things being optional that we can longer allow to be optional. The problem then becomes part management. It's not an issue of cost because most of it is already there, it just needs turned on.
    • [Harrison] The auto industry is a perfect example of 'cheap'.
    • [Brad] But I think there and in avionics a lot of delegation takes place, with hierarchies for reporting. A unit in a supervisory role may only get information from the next level down.
    • [Harrison] It becomes the responsibility of the OEM. You have the hardware architecture, but there's no ICL that describes the relationships of the components. here are no rules that say 'I won't let you do things until I know what you can do.'
    • [Brad] In the auto sector you might have a Brake Controller: The system has no understanding of what's going on inside it. But JTAG needs to know about the structural aspects in order to test it.
    • [Harrison] All you really need to know is that the operation you're doing isn't destructive.
    • [Brad] But to determine some of the things you mentioned, like the opens and shorts, needs to know the structure, while it doesn't need to know anything about the firmware.
    • [Harrison] That's why I think SJTAG is more doable in the P1687 world. In the pre-1687 world the instruments and the vectors are not atomic and may even be orthogonal.
    • {Peter joined}
    • [Brad] You still need to know what SIBs the instrument is sitting behind.
    • [Harrison] That's phase 2. In the first stage instantiation is assumed to be on a JTAG port but could be something else.
    • [Ian] Isn't this a circular argument? Before we know what instruments might be present we need to know the board type is, which gets back to determining the ID.
    • [Harrison] Maybe I need to understand here. What is the problem with the ID. You already have that or your EMS wouldn't be able to build it.
    • [Ian] The point is that once a unit is built into a system you want to be able to determine what's in that system. There may be boards that are form, fit and function equivalent but are topologically different and require different tests. Not necessarily serial number data but board type.
    • [Harrison] You should be able to recover ID codes from the chain, they exist now, and use that to lookup a database to see what board that relates to and then download the corresponding tests.
    • [Brad] But when we visit a customer site, quite often we're not allowed to use their network for security considerations.
    • [Harrison] Tools are going to have to have the ability to use imported data.
    • [Brad] That's never going to happen!
    • [Harrison] There are customer cases where I've seen it work. It's workable but maybe not pleasant. The tool is partly open. The other model is where the tool reaches out to some repository for the data.
    • [Brad] To have to do that for every blade in the system is going to be overwhelming.
    • [Harrison] The vendor is going to have to provide information on the blades in order to do business. We see Homeland Security insisting on that.
    • [Brad] At what cost?
    • [Harrison] 'What price preservation?'
    • [Brad] I know that if I tell a customer that we're going to hold up a test while we look up data then we're not going to be popular.
    • [Harrison] You don't need a lot of information to do a JTAG test.
    • [Brad] You need to know about the structure to run the tests.
    • [Harrison] How is that different to how it is today?
    • [Brad] JTAG has not caught on at system level because of the difficulty in making it happen.
    • [Harrison] That's more a lack of BKMs (Best Known Methods) than anything else. No one uses the JTAG interface once the unit is working. Often the manufacturer will take to connector away or plug the pins.
    • [Brad] The interface may be there but not used after manufacture.
    • [Harrison] The iNEMI surveys suggest that's changing. There's engagement from some customers who want to take advantage for field service and from some silicon vendors. That comes out in the surveys. The impediment is the BKMs that are currently practiced.
    • [Brad] Still doesn't address the technical aspect of how you get that done: For the kinds of things you mentioned before, the shorts and opens, you need to understand the structure and the vectors to be applied. You cannot apply the same tests to different types of board.
    • [Harrison] No, but you look to see what tests are applicable.
    • [Brad] Going external isn't always going to be an option.
    • [Harrison] FPGAs are a perfect example: The might be 3 boards with the same FPGA but they are configured differently. Each board will have a different ID. You've got to have some rules about each board.
    • {Adam left}
    • [Harrison] There has to be something that defines it. The VIN has to be related to a part.
    • [Harrison] JTAG doesn't know about BKMs.
    • [Brad] Firmware has to reside with the UUT. I agree that there has to be a store some place. Currently that's one of three places: External to the system; internal to the system but external to the UUT; part of the UUT's memory space.

5. Key Takeaway for today's meeting

  • [Brad] Data relating to UUT must reside in one of three places: 1) External to the system, 2) Internal to the system but outwith the UUT and 3) Within the UUT's memory space.
  • [Harrison] Most things require BKMs to be in place.


  • [Brad] Makes a case for programmable devices that can verify their own checksum.
  • [Ian] Some FPGAs can to some extent but often the implementation simply reboots the board!

6. Schedule next meeting

Next Meeting:

Schedule for April:

7. Any other business


8. Review new action items

None. Update newsletter action with deadline.

9. Adjourn

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

Respectfully submitted,
Ian McIntosh