Minutes of Weekly Meeting, 2007-11-19


Peter Horwood
Carl Nielsen
Al Holliday
Ian MacIntosh
Jim Webster
Brad Van Treuren

Meeting was called to order at 8:10am EST

Review of meeting minutes for 11/12/2007;

Approved as is (moved by Peter, second by Al)

Discussion of open 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?
      • still ongoing
  • Establish whether TRST needs to be addressed as requirements in the ATCA specification if it is not going to be managed globally (All)
    • still to be resolved
  • Provide feedback of more use cases not yet identified to Brad (All)
    • awaiting feedback ...
  • Review tables (Goals vs. use case matrix) on slides 38-41; (All)
    • awaiting feedback ...

Carl Walker was unable to make meeting so email reflector overview was postponed until a later date.

Process for supporting observers requesting to monitor our activity

  • Brad indicated he was receiving email from Huawei and Alcatel-Lucent people to be able to observe and monitor the activities of this group
  • Ian suggested we set up a "Read-Only" focus group area for public viewers that we control. Ian will investigate a strategy this week and share a proposal during the next meeting.

Diagnostic preservation discussion

  • Jim Webster provided a brief overview to introduce the document he distributed on ideas he has been thinking about and the issues he feels must be handled
  • Jim: What level of diagnostics are we going to support at the system level? System Test at the factory is not the same thing as System Test in fthe field.
  • Peter: I can't see the feasibility of a USERCODE for diagnostic preservation.
  • Jim: It was just an example.
  • Jim: The Key to SJTAG is the Test Manager and how it controls the vectors and test data in the system.
  • Ian: We should be worried about getting what is failing back into service. We are needing to get the system back into use and not so much worried about diagnosis. If it fails, it will be shipped to a repair depot to go through a subsystem or board level test with greater diagnostic detail.
  • Jim: We need to get the relevant information to the failure.
  • Jim: We don't want to erase or reprogram at the system level - especially FPGAs and CPLDs like we do in production test.
  • Brad: I disagree. If a board is down because the FLASH was corrupted (either during a failure to update the FLASH or dropped bits), the replacement of the board may take more than a day if someone must be dispatched to replace the Field Replaceable Unit (FRU). If one is able to reprogram the FLASH from the multi-drop or system JTAG port, that would most likely be faster then dispatching someone to the field site.
  • Jim: indicated that flashes will typically have check sum that can be detected by other means, does not feel that systems should be re-programmed in field
  • Brad: describes system that is separated by several km where update via bscan is useful.
  • Jim: I think we need to focus on System Update and System Diagnosis separately.
  • Brad: Systems are shrinking into boards with mezzanines that used to be full systems a few years ago. We now need to diagnose down to subunit FRUs instead of system level FRUs.
  • Jim: indicates this should be done using gateways.
  • Brad: What I see coming is the need to diagnose down to the failing "Logical Unit" and no longer to the FRU. Thus, logical units may be bypassed dynamically with the SERDES switches that are beginning to connect logical units on the boards to be able to keep a board in service but running at less then optimal performance.
  • Brad/Jim: Discussion on how this chain partitioning should be done.
  • Jim: The test manager should be in charge of when the tests are to be applied to what modules on the board.
  • Brad: It is not the test manager's role to determine the state of the board (e.g., in-service, off-line) but the role of the system diagnostic software that also is responsible for the functional tests. Some 1149.1 operations may be performed on a board that is operating normally in the system as non-intrusive SAMPLEs.
  • Jim: does not feel using SAMPLE provides diagnostics
  • Brad: SAMPLE provides a snapshot of the board's signal state that is useful for determining root cause of failures.
  • Brad: indicates the scope of testing at the system level is much larger than at previous levels
  • Someone indicated that doing this sample work could lead to real large vector sizes.
  • Jim: talked about writing code to embed tests that use loops
  • Brad: indicated this is the primary advantage STAPL has over SVF in that condition branching is supported in the vector language for these types of tests
  • Brad: Asked tool vendors what level of diagnostics their customers have requested from them in support of system test
  • Carl: A lot of education is needed in industry. Most users feel System Test is done with a Functional Test approach. Why not do System Test as a structural test like what is done at production testing. Carl finds many people want full diagnostics at the system level because they have it at production test and see the power of it there.
  • Brad: The evolution of embedded boundary scan in AT&T then Lucent and now Alcatel-Lucent shows that GO/NO-GO was a fine start, but once people realize the value of embedded boundary-scan testing and begin using it in more places than just in field test, the begin to demand better diagnostics at run-time.
  • Jim: I can understand this because boundary scan gets you more of a detail of where it fails to reduce repair cost.
  • Jim: brought up the issue of cost, as the cost of failure at the system level is higher then at the PCB production
  • Carl: How do we manage the cost advantages for using system level JTAG? If we are able to show the cost advantage, people will understand our point better.
  • Brad: talked about an ITC paper from 1994 describing a system that implemented system level boundary scan and that the primary drive was the deterministic nature of testing that boundary scan structural tests provide. Test coverage is easily calculated.
  • Ian: We can continue the discussion on the SJTAG Forum site since time was running out.
  • Brad: For next time be thinking about how to deal with a 4 wire interface for the ATCA Hub boards that are also serving as the Shelf Manager. Thus, the 4 pins must be bidirectional since the HUB is able to be a Test Manager as well as a slave for the external tester or its mate HUB. The method used in MicroTCA will not work. There are some concerns people have with a configurable star to support such features.
  • Jim: make the 4 pins addressable, use a different bus to set if it was JTAG or not, indicates that first device just need to be addressable, he will try to block diagram it for next meeting.
  • Brad: the solution must be supported from an external tester as well

Next meeting:

Monday, 11/26/2007 at 8am EST

  • We need to think about another meeting time since Patrick Au is unable to join the Monday 8am calls.

New Action Items

  • Ian to look into general observer solution for visibility of our work to outsiders.

Adjourn at 9:06am EST

Many thanks to Peter for supplying his notes to assist in recording the meeting.

Respectfully submitted,