Minutes of Weekly Meeting, 2012-03-05

Meeting called to order: 11:04 AM EST

1. Roll Call

Adam Ley
Eric Cormack
Carl Walker
Ian McIntosh
Heiko Ehrenberg
Peter Horwood
Brian Erickson
Brad Van Treuren
Harrison Miles (joined 11:30)

Excused:
Patrick Au

2. Review and approve previous minutes:

02/27/2012 minutes:

  • Updated draft circulated on 02/29/2012.
  • Amendment: Correct the circulation date of the 2/20 minutes.
  • Eric moved to approve with the above amendment, 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
    (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)

4. Discussion Topics

  1. Discussion: "SJTAG in a nutshell - What I think SJTAG is all about"
    Continuing with Brad's thoughts.
    • {Ian shared Brad's email sent on Feb 27, 2012}
    • [Ian] I can't remember just what we were talking about when we left off.
    • [Brad] We left of with how a board ID fits into SJTAG testing.
    • [Ian] We developed a custom ASIC for board ID, the Electronic Module Identification or EMId, for use with many of our designs (providing information such as module type, serial number, fault history, and more). That got a bit dated and has been replaced with an off-the-shelf ID chip, but that is still not a perfect solution, since those type devices are typically low-pin-count and don't support JTAG / boundary scan.
    • [Brad] I would tend to agree with that.
    • [Ian] Part of where we were headed last time was parts or features in the gateway devices like Firecron has, but that led us into a discussion where there are some boards that don't have a gateway device on them. This still leaves you with a question of what is the universal method of giving the ID for the board when you have multiple devices on it.
    • [Brad] We also discussed that the topology of the scan chain was not sufficient to determine what type of design the board is.
    • [Ian] whatever identification mechanism we choose for the board identity needs to be designed in, it doesn't just come with the board or can be deduced from its topology
    • [Brad] Identification topology could be the default configuration of a scan chain, allowing all boards in a system to be interrogated and identified first, before moving on to test or other operations.
    • [Ian] I agree, but this could be tricky, since not all gateways work the same way. We need some predefined, consistent access protocol for the ID.
    • [Brad] Yes, a common topology.
    • [Heiko] wouldn't that be something we can specify as part of the SJTAG standard?
    • [Ian] I'd think so. This might get us back to 'SJTAG compliant' and 'SJTAG compatible' levels if it's not implemented on a specific board.
    • [Brian] We could specify a multi-register identification scheme, for board serial number, type, and other information. The serial number could be made large enough to include a MAC address for example.
    • [Ian] We'd still need centrally controlled register for identities. I wonder if this is overhead that would hinder adoption.
    • [Brian] Yes, but one message that contains everything might make people more motivated to make use of it. If this is going to go anywhere the big thing is to create a market for it. Hopefully the specification will create that market.
    • [Ian] I see two ways this can pan out, dealing with situations of having or not having the gateway: In general, most systems that we're considering will have these types of gateway devices, and then it makes sense for the gateway to implement this ID instead of having to access the gateway to get to the ID, and for those cases where there is no gateway, there needs to be some sort of an add-on device. That could be a material burden people will want to avoid.
    • [Brad] Chain management logic on boards without gateways may contain the ID register, but you still have to deal with the case where you have a simple chain that might just be a single FPGA like on an AMC board.
    • {Harrison joined}
    • [Ian] Brad, in your Plug'n'Play scheme, did the standardization constrain gateway selection?
    • [Brad] Not really. We were using ASPs in that design. The point was that the chains looked similar from the backplane. The data you could pull was in different sections. The standard header contained a lot of the information we're talking about here.
    • [Brad] So long as a new design followed the protocol, the system didn't really know it was new and just followed the protocol as it always had done.
    • [Ian] But that's going way beyond just the ID.
    • [Brad] There's a notion of module identification in Dot5.
    • [Ian] OK, but probably 'local' and not considering COTS boards.
    • [Brad] I wish we had some folks from the automotive industry - they'll have experience of multiple processors that need to be interrogated for test features.
    • [Ian] Yes, and they may well have to deal with multiple vendors for various 'sub-systems'.
    • [Carl] Would OBD-II perhaps be a good spec to look at?
    • {Wikipedia link: http://en.wikipedia.org/wiki/On-board_diagnostics}
    • [Ian] I think OBD-II concentrates more on reporting diagnostics of the vehicle and less on diagnostics of the electronics itself. I'm not even sure if ODB-II interconnects systems - that might bve in CANbus. Too bad we lost active membership from the automotive industry here.
    • [Brad] A similar stakeholder would be avionics.
    • [Harrison] MIL-STD-1553 might be another interesting candidate to look at.
    • [Ian] In what way?
    • [Harrison] Well it's serial, it's defined, it provides a lot of information including identification.
    • [Ian] With 1553, the bus controller (BC) manages a number of remote terminals (RT) by address - it doesn't really know what's on that address, or what each RT can offer in its sub-addresses. STANAG-3838 took 1553B and added mandatory data that would be provided by certain sub-addresses, so that makes things a bit more predictable. There are other avionics buses, like ARINC-429, ARINC-629 too.
    • [Brad] The other thing I was thinking about with avionics is the diagnostics that goes on over a long time. I remember on the 747 it had 3 inertial navigation units and if one went out of agreement with the other two, it would drop out. Many other aircraft only had dual redundancy.
    • [Ian] I wonder if we can entice the auto people back in?
    • [Brad] Perhaps a 'plea for help/input' from the automotive industry would be a good topic for the next newsletter.
    • [Ian] Good idea. I think the next newsletter is due in April. ACTION
    • [Ian] We didn't really get to continue the discussion of point 3 in Brad's email, but we did kind of touch on his point 5.
    • [Harrison] You maybe need to think about the principles in P1687 for the board.
    • [Ian] Well, P1687 is at a device level, but something like that or as was mentioned previously a BSDL for the board - something to define how you can control the board edge. It might be difficult to get.
    • [Harrison] Well that could be in XML. I don't think it'd be difficult to get; it would add time to the schedule.
    • [Brad] I'd disagree. It's not that simple - it depends on how the board edge integrates into the rest of the system. You have to design it in, not just supply a board BSDL.
    • [Harrison] I said before, there's what you can do before bring-up and what you can do after bring-up. The problem exists.
    • [Brad] It comes down to how you get accessibility. You still need to get the 1s and 0s to control the board edge.
    • [Ian] But maybe that's just because we don't typically make it part of the board designer's remit to consider those things?
    • [Harrison] You can also see that in Hot Swap. The designers had to think about the things that were needed to make it work, like ensuring that ground pins mated first. It needed a change to the design paradigm.
    • [Ian] I'd still like to get some perspective from tool vendors and possibly others as to what they think SJTAG is about, but we'll have to continue that next week.

5. Key Takeaway for today's meeting

  • [Brad] A board ID code by itself may not be enough. Other uses may make it more attractive. Compare with PCI ROM: Standardized information.
  • [Brad] Plug'n'Play requires standardized architecture; may not be easily attainable with multiple vendor products.

6. Schedule next meeting

Next Meetings:
12th March - Heiko expects to miss this meeting
19th March
16th March

7. Any other business

None.

8. Review new action items

  • Ian to consider an appeal to SJTAG email newsletter recipients for participation from the automotive industry in the next newsletter.

9. Adjourn

Peter moved to adjourn at 12:06 PM EST, seconded by Carl.

Thanks to Heiko and Brad for supplying additional notes this week.

Respectfully submitted,
Ian McIntosh