Minutes of Weekly Meeting, 2012-03-26

Meeting called to order: 11:08 AM EDT

1. Roll Call

Ian McIntosh
Eric Cormack
Carl Walker
Adam Ley
Brian Erickson
Brad Van Treuren
Tim Pender
Patrick Au (joined 11:09)
Harrison Miles (joined 11:24)
Peter Horwood (joined 11:33)

Heiko Ehrenberg

2. Review and approve previous minutes:

03/05/2012 minutes:

  • Draft circulated on 03/05/2012.
  • No corrections noted.
  • Eric moved to approve, seconded by Brian. No objections or abstentions.

03/12/2012 minutes:

  • Draft circulated on 03/12/2012.
  • No corrections noted.
  • Patrick moved to approve, seconded by Carl. No objections or abstentions.

03/19/2012 minutes:

  • Draft circulated on 03/19/2012.
  • No corrections noted.
  • Carl moved to approve, seconded by Patrick. 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] What is the bare minimum we need for a board ID? On the face of it, this sounds like it should be quite simple, but I think we'll find complications as we dig into this.
    • [Ian] One question is maybe whether this is something that we want to access purely through JTAG or whether other interfaces might be involved.
    • [Patrick] Well, I don't think it should be purely JTAG. The ID should be accessible by several methods as there are other places where it would be useful to have the board ID, so the firmware should be able to read it.
    • [Carl] Is it our place to say that what those other methods are or just to note that other methods should be available?
    • [Brad] I could see where we should try to mandate what we need as a minimum but not mandate that it should only be available by JTAG.
    • [Ian] Is it for the SJTAG standard to require other methods or just a side note to point out the value of providing other means of access?
    • [Ian] In the discussions over the last two weeks, I think Harrison mentioned possibly hashing the IDs of devices in the chain as part of the building an ID. Is that useful? I'm thinking that there may be different boards that have the same scan chain topology, so you're still left needing to program in something to make it unique, so why not just program the whole thing?
    • [Tim] Some sort of address that gets used for say slot codes is obviously useful. The ID could be programmed by the EMS to include things like the assembly number, date code, and serial number.
    • [Carl] That kind of thing we handle in an 'ID PROM'.
    • [Ian] We're currently using an FRAM for similar things.
    • [Brad] There's a chicken and egg problem: Boundary scan is often one of the first actions during board test, so if that's data that gets programmed then it may not be available for the board tester to use.
    • [Carl] There's a need to know what it is before you program it. During manufacture there's usually labelling for a number of things, but one is often a barcode that identifies the product and that can be scanned in.
    • [Brad] And typically the board tester can generate the appropriate tests based on that scanned data.
    • {Harrison joined}
    • [Brad] You can scan in information, so at initial board test there may not be a requirement for the board ID.
    • [Ian] Again there's a chicken and egg situation, if like us you delay doing any programming until the system is built. We keep common stock and commit to an end use at system assembly. So you may need to know which boards are in the unit to know what programming to do.
    • [Harrison] I think you need to consider separate stages: Before power on and after power on.
    • [Ian] Even before power on you can have problems.
    • [Harrison] You have to take the notion from P1687 with canned vectors.
    • [Ian] Brad was also talking about stages but I think we've two different sets of stages here: Brad was referring to stages through manufacture, while I think you're referring to different levels of operation?
    • [Harrison] Correct.
    • [Brad] Production stages versus Operational stages.
    • [Tim] I don't know why there's a problem during production stages because the EMS has the order, they know what they're building.
    • [Harrison] That's not completely true. I know there are people who don't build the programmed item straight off. They have a functionless board and then load the functionality when they know which customer it's to go to.
    • [Carl] So you create a new part number for the functionless board.
    • [Tim] I thought the idea here was to identify the board.
    • [Harrison] Everything that's needed exists now, but is currently optional. It's really an operational problem.
    • {Peter joined}
    • [Brad] I think we're missing the value add that SJTAG can bring: We can standardize on a minimum set of information and the protocol to access it. That will make bringing in third party boards much easier than it is now. It's like what PCI did in the PC world.
    • [Harrison] PICMG is a perfect example.
    • [Brad] As I look back on Dot 5 and how tried to tackle this, I see that they were using a 802.3 thing based on a MAC address, where each manufacturer had a code as part of the MAC address. Now many manufacturers have 5 or 6 codes and it may be dependant on if they outsource, so that gets messy.
    • [Ian] The principle is similar to VXI where there was an assigned code for each manufacturer and then a local code for each instrument from that manufacturer. I guess lots of people have tried to solve the same problem. Maybe it highlights the need for a universal board ID scheme.
    • [Brad] In our Plug and Play we tried to deal with the case where we knew a board was installed but it wasn't registering. There was minimal circuitry needed to get the information on what testes could be run: An ASP, some memory and a CPLD to manage the scan path. So the board could be dead in a lot of places but we could still get the tests to run.
    • [Ian] Well that's largely the basis of JTAG - you don't need function in the UUT in order to test it. In fact function can be a hinderance.
    • [Ian] OK I think we're heading towards the idea that an ID is something that needs to be programmed in.
    • [Brad] I think it's a packet of information not a strapping of information.
    • [Harrison] I think you've said it well.
    • [Ian] Dallas have their one-wire ID chips that have 64-bit unique IDs burned into them. The problem is that little will talk to that one wire bus natively.
    • [Tim] We need to mandate that the ID gets put in during EMS. The ID is useful for storing board type and serial number, but there should also be a user definable space too, for the different things that some manufacturers might want.
    • [Ian] Yes, in the FRAM I mentioned we have the board version and serial number then there's the firmware version numbers. But we also record things like elapsed time - important for monitoring MTBFs. We can power the FRAM from the test connector without powering the whole unit, so we can read data while the unit is sitting on the shelf.
    • [Harrison] You're asking for something like the electronic dog tag issued to soldiers.
    • [Tim] Saved information can be useful.
    • [Ian] Yes, in the FRAM and in the older EMId ASIC, we'll write in fault codes with time tags, so there's a history of events we can check on later. Some of might be environmental, high or low temperatures, or shock.
    • [Brad] Field failures, where fault occurs in a specific configuration but not in the configuration in the workshop, so you get a 'no trouble found'.
    • [Brad] Carl, I think Bill and Bill's boss saw the value in that - you guys could start working on the diagnosis before you even got the board back in the workshop.
    • [Carl] Yep.
    • [Ian] I think we're moving out of the SJTAG domain and into the overall maintenance domain here. I'm not saying that's a bad thing but it's probably more than an SJTAG remit covers.
    • [Brad] We initially tried to go with just an ID code with a mapping of tests to that ID. But then during NPI a white wire might be added that changed the test and we'd need to update the database. That was a pain. That's why we tried to keep the test data with the UUT. You didn't have to worry about maintaining a database.
    • [Harrison] What it comes down to is what segments are ready for this, essentially, 'over-design'? Some segments will be more ready to accept this than others. It's applicable in general but not everyone will want it.
    • [Brad] We would also need to change the execution model of conventional JTAG tooling.
    • [Harrison] We have to assume some of the concepts from Dot7. We can use JTAG one way for NPI and another way for system use.
    • [Brad] The point I'm making is that data and vectors are not the same thing. The stream is not just vectors, it's information.
    • [Harrison] Looking into what 1149.1-2012 will bring there's the ECID. There's no standard on the ECID string so you need to read it and look up how the manufacturer says you need to handle it.
    • [Brad] I'm also looking at it in a BDM type of interface. The patterns you get there are very different from a traditional test.
    • [Harrison] I agree with that. You kind of need to know state information for the board, whether it is operational or nonoperational.
    • [Brad] I can run nonintrusive tests any time.
    • [Harrison] Some memory tests may be intrusive or nonintrusive, depending on what you're trying to do, so it can be tricky.
    • [Ian] OK, we need to wrap up there, but there's more to go on this. I don't think we've really drawn all the conclusions yet.

5. Key Takeaway for today's meeting

  • [Brad] JTAG is capable of providing test results with minimal functionality in the UUT.
  • [Harrison] There are minimal facilities required on a board to get an ID. The board ID should a mandatory requirement for SJTAG.

6. Schedule next meeting

Next Meeting:
2nd - Heiko and Patrick will be absent

Schedule for April:
9th - No meeting (Easter Monday)
16th - Tim and possibly Harrison will be absent

7. Any other business


8. Review new action items


9. Adjourn

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

Respectfully submitted,
Ian McIntosh