Minutes of Weekly Meeting, 2012-04-02

Meeting called to order: 11:06 AM EDT

1. Roll Call

Ian McIntosh
Carl Walker
Adam Ley (left 12:00)
Brian Erickson
Brad Van Treuren
Tim Pender (joined 11:07)
Harrison Miles (joined 11:30)

Heiko Ehrenberg
Patrick Au
Peter Horwood

2. Review and approve previous minutes:

03/26/2012 minutes:

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

4. Discussion Topics

  1. Board ID: What is the minimum equipment and services needed?
    • [Ian] I wanted to continue from where we left off last week. Something that was mentioned towards the end of the last meeting was the ECID that is part of the proposal for 1149.1-2012. My initial reaction is that this probably doesn't help us any more than the current device ID?
    • [Adam] The ECID is intended to be a globally unique ID for the die under test. It is not intended to identify the manufacturer or the device type although it is possible that it could.
    • [Ian] So it's not necessarily decodable, but might be depending on what the manufacturer chooses to do?
    • [Adam] Right, and that may or may not be publically documented.
    • [Ian] Given that there's no guarantee of how the device ID might be constructed then it sounds like it's of little help to us?
    • [Adam] No use to us except as intended, to relate test data to a particular die which may then be traceable to a wafer lot. It may be documented or it may not.
    • [Ian] So if ECIDs don't help us and we've previously decided that Device IDs alone don't give us sufficient information then where does that leave us?
    • [Brad] Back at 'square one' trying to find something that is suitable for SJTAG.
    • [Ian] It seems that we're heading towards an ID that is programmed into some device somewhere. But where? It needs to be accessible with minimal board function. I think we've been trying to find a way to avoid that by finding and ID we can derive from the existing componentry, but it doesn't look like such a thing exists.
    • [Brad] There are things in ATCA and PCI, but they're not in a format that we can leverage for SJTAG.
    • [Ian] This would need extra facilities or components, so we'll encounter push-back from designers.
    • [Brad] Maybe not designers but accountants.
    • [Ian] Well, I've got an example: One seemingly logical place for the ID may be in the gateway device as it usually provides a single point of entry to the board. But in our Gripen antenna, putting a gateway on every board would add 38 extra ICs and eat up real estate. So instead we put 6 gateways on the backplane and took secondary chains to the boards. So that kind of architectural choice tells me that the gateway isn't always going to be the right place for an ID.
    • [Brad] So your backplane is part of a super-board that comprises your other boards. It's similar to boards with daughterboards.
    • [Ian] Yes, the whole question of hierarchical assemblies comes up.
    • [Brad] Your situation is the same problem as with plug-in daughterboards - How do you manage that? If SJTAG is hierarchical then it needs to deal with that situation.
    • [Brad] There seems to be two aspects to this: 1) The board ID itself and what it represents and 2) How to describe that to the tooling.
    • [Ian] It becomes an interesting problem with the addition of hierarchy.
    • [Brad] An ID is drawing a line in the sand. In our Plug and Play the only thing we needed to was get the tests that related to that board.
    • [Ian] OK, so you can't really account for what's in the lower or higher tiers of the hierarchy. You can only test within the bounds of the card.
    • [Brad] Well you can include daughterboards but then you can't really swap them out for a different type.
    • [Ian] That's what I mean. A fixed arrangement is OK but not a flexible one.
    • {Harrison joined}
    • [Brad] Maybe need to mandate a structure with a secondary path to any mezzanines. Where that secondary path exists it would almost let you know that you can then query for the ID and then determine the internal and external interfaces.
    • [Ian] This discussion is changing my initial view on this. I was considering that a composite assembly could perhaps combine the IDs of it's individual parts into a single module ID, but I now don't feel that's workable. There could be any number of levels in the hierarchy.
    • [Harrison] This is the same as we said before about some things that were optional now can't be. The daughterboard has to have the same attributes as its parent. I see this as similar to the 3D IC problem. All the connector is on the backplane is an interposer.
    • [Brad] When I look at what ATCA and PCI are doing, they're using an aspect of registration where the slave is able to notify the host of what the slave is. We don't have that luxury, its strictly master to slave.
    • [Harrison] You've got to differentiate between states: It's easy to get the hierarchy once you are powered up.
    • [Ian] One of the things about performing a test is that you really need to be presuming that a fault will exist and try prove that none do. If you create your tests on the presumption that the UUT works then you're going to have a hard time. JTAG's value is that you can run tests with little function or additional circuitry on the UUT.
    • [Brad] There are certain things we can do when the board is only just powered. That's really what we were targeting with our Plug and Play - Why doesn't this board register? - That may be enough for that level of test. You just need a common interface on how to pull that data out.
    • [Brad] At higher levels of functionality, you may be able to interrogate for further testing.
    • [Brad] As to the bare of how do you address the board to access the ID then it may be as simple as using the Slot ID that Tim spoke of.
    • [Harrison] If you're testing before the board is fully instantiated, is the test only a hardware confidence test?
    • [Ian] That may be user dependent. But in our case, that hardware confidence check may be all we need at that state. If the boards power up, then we can expect BIT to do much of the work beyond that.
    • [Harrison] But you also need confidence that the Flash, etc., is not corrupt. So you've got the opens and shorts first, then checks that the bus is driveable without blowing anything up, the checking of the Flash or configurable parts.
    • [Harrison] You don't need to know what the entity is for that.
    • [Brad] But you still need the test data for the opens and shorts?
    • [Harrison] I'm hoping we transition to a point where vectors are bundled. SJTAG looks a lot more palatable with a 1687 architecture where you can just chain operations.
    • [Brad] Are you proposing that interconnect tests are rewritten in the form of a P1687 test?
    • [Harrison] Not necessarily. There are clearly places where there could be advantages to retaining the traditional approach. The more complex tests are doable that way, but with lots of effort. You need skilled engineers to craft the tests.
    • [Ian] I'm not convinced about P1687 at this point. It's not a standard yet, although it's getting close, but I don't see any guarantee of widespread adoption. Besides which, there will be a legacy of non-1687 parts for some considerable time, so 1687 may be the way to go but only in the long term. I see conventional methods still being required in the short to medium-long term.
    • [Brad] I think that's especially true with FPGAs.
    • [Harrison] The major two are pretty much there already.
    • [Ian] The features may be offered but don't you still need to get the designers to enable them?
    • [Harrison] No more than with anything else. But again it's not a standard, and you need rules that enforce the use.
    • [Harrison] I can envision a mix of Dot1 with the Xilinx or Altera: I can see that working at the board level, maybe not so much at system level.
    • {Adam left}

5. Key Takeaway for today's meeting

  • [Brad] Three levels of test exist prior to achieving 'function': 1) Opens and shorts, 2) Bus driveable without fault and 3) Flash (or configurable part) integrity.


  • [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:
9th - No meeting (Easter Monday)
16th - Tim and possibly Harrison will be absent

Schedule for April:

7. Any other business

Bill Eklow has advised that the 'Meet the Working Groups' TTSG Posters will be running at ITC again this year.

8. Review new action items


9. Adjourn

Brad moved to adjourn at 12:05 PM EDT, seconded by Carl.

Respectfully submitted,
Ian McIntosh