Minutes of Weekly Meeting, 2008-06-30

Meeting was called to order at 8:23am EDT

1. Roll Call (Participants):

Brad Van Treuren
Ian McIntosh
Carl Walker
Heiko Ehrenberg
Carl Nielsen
(Peter excused: was travelling and unable to attend)

[Jim Webster via Proxy]

2. Review and approve minutes

6/23/2008 minutes approved (Ian moved, Heiko second)

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?
  • Establish whether TRST needs to be addressed as requirements in the ATCA specification if it is not going to be managed globally (All)
  • Register on new SJTAG web site (http://www.sjtag.org) (All)
  • Look at proposed scope and purpose from ITC 2006 presentation and propose scope and purpose for ATCA activity group (All)
  • Continue Fault Injection/Insertion discussion on SJTAG Forum page (All)
  • Continue Structural Test use case discussion on SJTAG Forum page (All)
  • We will need to begin writing a white paper for the System JTAG use cases to provide to the ATCA working group (All)
  • Locate ATCA glossary of board and system states (Adam, Brad)
  • Adam review ATCA standard document for FRU's states

4. Discussion Topics

    1. Brief status on document progress

Volume 1:

      • [Brad] I've not had a chance to work on it;
      • [Ian] I haven't worked on it either; was busy working on the Copyright and survey on the website

Volume 2:

      • [Heiko] I'm sorry to say I haven't made any progress

Volume 3:

      • [Carl N.] No progress from my side;
      • [Carl W.] A few notebook additions, but not on the website yet
      • [Brad] Ian, you had done some work on the Glossary
      • [Ian] Yes, a little bit. I'm inclined to think that the Glossary may fit better into the Wiki rather than the static website
      • [Brad] I'd agree
      • [Ian] I've to think about it a little more
    1. Status of SJTAG Survey
      • [Brad] Ian’s most recent email gives a good overview of the survey.
      • [Ian] There was a short discussion going on, initiated by Jim, about whether or not to present section 3 to people answering "no" to both questions in section 2; Heiko and myself agree that there is value in still presenting this section
      • [Brad] I also agree.
      • [Ian] Unless there is other comments/changes, I'd be ready to send it out
      • [Brad] I'd suggest we add the option for people to get colleagues / other contacts invited to the survey
      • [Ian] That is easy enough to do
    2. Discussion of remaining Use Cases

Software Debug

      • [Brad] Software Debug has not progressed as far as I would like to see it go from a system perspective. I would like to be able to gain access to a processor which is hung is some unknown code and be able to interrogate the PC, stack, registers, and possibly be able to do some peek and poke primitives to get a handle on the state of the processor and system to better understand where in the software it has gone to.
        Ideally, this would greatly assist the root cause analysis of the software failure. It would be nice to be able to do this at the system level and perform the analysis with the covers on. Unfortunately, the current emulator interfaces, except for possibly the nexus interface, requires the processor to use additional signals from the standard JTAG signals to force the processor into an emulation mode. It is unfortunate, that this process also wipes out the state of the processor. To do this at the system level, one needs to also route these additional signals to the outside and have a way of controlling their access to the processor under emulation through the SJTAG connection process. Without the ability to take control of the processor and observe its current state, I am not sure that software debug is a useful case. There may be some reasons to support it at a system level to perform some software debug tasks so one does not have to use extender boards or open up the system to run the experiment. I am not sure this value is able to justify the overhead to provide the access.
      • [Ian] Need to work out how to get the emulation interfaces to the outside (the SRESET and HRESET etc.) The other problem is that the current emulation tools do not support any kind of system level JTAG connection protocols (e.g., SCANBRIDGE, ASP, etc.).
      • [Ian] For me it is not a big deal with accessing the additional signals for the emulation ports and I can see others might have a difficulty with pin counts and such with their environments.
      • [Brad] There seems to be a difficulty supporting more than one processor at a time with the emulation interfaces as well.
      • [Heiko] We use Emulation functions for board/system level connectivity test, not really software debug; this works fine also with different processors and through Gateway/ScanBridge type devices; I'd think a big problem for software debug would be to keep up with the system speed;
      • [Ian] Along with that, on-chip programming is also done through the JTAG port and emulation functions, especially for programming FLASH.
      • [Carl N.] I think what Heiko has said is correct. I think meeting the access for software debug tools is a problem for current emulation interfaces. These should be minor DFT issues that must be highlighted as best practices on how to implement the emulation interface.
      • [Ian] I think it is typical that the vendors have no urgency to support other vendor parts in the chain.
      • [Brad] I think this is what 1149.7 can help with. I have seen vendors support other devices in the chain now that are assumed to be in BYPASS first.
      • [Carl N.] I think there are mechanisms on the gateway devices to turn them into transparent mode.
      • [Ian] We try to use the guideline to separate out the same brand of devices out to their own chain to make it easier for the tooling connectivity.
      • [Carl N.] Add to the board level test area the notion of at-speed testing for things like SERDES testing and other aspects.
      • [Carl N.] Another application to be mentioned is at-speed test of dynamic circuitry through emulation functions accessible from the JTAG port (e.g for testing DDR2 RAM, etc.)
      • [Brad] I wish Jim Webster was on the call today, I remember he had success with some interesting applications related to software debug at system level using the 2 additional controlled signals in the LASP.
      • [Brad] How about security issues?
      • [Carl W.] It is a valid concern
      • [Ian] With covers-on it's probably less of a concern; once someone has access to the physical system, there are may ways security can be compromised
      • [Carl W.] We would be mostly concerned about the IP inside the systems, which may be accessible even with covers-on
      • [Brad] Getting access to the system could also allow someone to interrupt the service; safeguards are needed to avoid accidental Boundary Scan access to boards that are in service when troubleshooting other parts of the system;
      • [Ian] I think anytime you start using emulation / debug functions you need to accept the risk that there may be unintentional interferences with system functions
      • [Ian] I think this is a general problem.
      • [Brad] Should SJTAG work on establishing a protocol to ensure proper access?
      • [Ian] We should at least provide guidelines as to the need for being aware of these problems.
      • [Brad] At a minimum we should at least make people aware of the problem and educate them to this need.

Remaining discussion from Root Cause Analysis/FMA

    • [Brad] We covered how SJTAG could provide trends of failures to identify design problems. Any other issues?
    • [Brad] I'll review the prior discussion on this topic again and suggest others do the same; then review during next meeting;
    • [Silence]
    • [Jim sent email that he will be trying to locate his notes on the emulation from the edge of the system through the backplane gateway interface, but will not be able to provide something in time for the minutes record.]

5. Schedule next meetings:

Monday, July 7th, 2008, 8:15am EDT
Wednesday, July 16th, 2008, 8:15am EDT
Monday, July 28th, 2008, 8:15am EDT

6. Any other business

  • [Ian] one of the action items from last meeting was the review of Privacy Policy and Copyright Statement
  • the group agreed that the wording of General Disclaimer, Privacy Policy, and Copyright Statement are sufficient as is;
  • Brad thanks Ian for the hard work and the time put into putting this together;

7. Review new action items

  • Heiko/Peter: review use case discussions on Forum; identify what is missing, prepare for discussion during next meeting;

8. Adjourned at 9:20am EDT

(moved by Heiko, second by Ian)

Thanks goes to Heiko for assisting in the drafting of these minutes.

Respectfully submitted,