The System JTAG Working Group

Return to index of Meeting Minutes

Minutes of Weekly Meeting, 2008-02-11

Meeting was called to order at 8:20am EST

1. Roll Call (Participants):

Brad Van Treuren
Ian McIntosh
Carl Nielsen
Adam Ley
Heiko Ehrenberg

By Proxy Input:
Peter Horwood

2. Review and approve 2/4/2008 minutes

minutes were approved (moved by Ian, second by Heiko)

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)
Provide feedback of more use cases not yet identified to Brad (All)
Review tables (Goals vs. use case matrix) on slides 38-41; (All)
Register on new SJTAG web site (http://www.sjtag.org) (All)
All need to check and add any missing Doc's to the site (All)
Respond to Brad and Ian with suggestions for static web site structure (Brad suggests we model the site after an existing IEEE web site to ease migration of tooling later) (All)
Look at proposed scope and purpose from ITC 2006 presentation (attached slides) and propose scope and purpose for ATCA activity group (All)
Look at use cases and capture alternatives used to perform similar functions to better capture value add for SJTAG (All)
Set up Use Case categories for forum discussions (Ian)
Volunteers needed for Use Case Forum ownership (All)
Send Ian list of volunteers for Use Case champions (Brad) (Ian and Heiko responded)
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) Most likely, champions will own their subject section and draft the section with help from others.
This paper will be based on the paper Gunnar Carlsson started in 2005.

4. Discussion Topics

Ian explained use of the SJTAG Forum, reminding people to add to use case discussions;

contact Ian with any problems using the forum;
Ian will add some suggestions and cheat sheet for common questions that come up for users that are not provided on the standard help and FAQ pages.

SJTAG Value Proposition - Power-On Self Test (POST) - continued from 2/4/08

[Brad] what kinds of boundary scan tests need to be executed as part of POST? Infrastructure Test, Interconnect Test, others? it probably depends on the application;
[Ian] yes, it definitely depends on the application;
[Ian] We may need some cluster testing. Unlikely that we may need some extensive memory test, but not guaranteed it is not needed.
[Adam] may need to interrogate the UUT configuration first; memory test may be needed, especially if plugged into DIMM socket and similar connectors;
[Ian] sometimes Memory test is prohibitive, especially for FLASH devices, in particular if those devices have a low maximum number of supported write cycles;
[Brad] should POST be looked as limited to the FRU or should it include "FRU and other things" ? (Question #24 on POST Use Case forum site)
[Brad] An example of what I am talking about is the multiple DSP filtering lanes needing to perform memory interconnect testing for their associated memories since they would require reprogramming of the filter software to the test software to perform a functional test. The BScan test would be faster and does not required reprogramming of the DSP.
[Ian] You have to be careful you don't reprogram more than you have to with FLASH.
[Carl] Make sure the board is in the proper state when tested. Also, the I/O for the board must be in the proper state upon entering and exiting of a test.
[Brad] Again, is POST limited to just the FRU boundary? I think in the future tests will need to be partitioned based on functional blocks that may be taken out of service to allow the board to continue operating but at a degraded performance. This is better than a total outage of the board.
[Carl] I think Boundary Scan based structural testing goes beyond the FRU;
[Carl] Tests are inclusive of other things. Especially, for single board systems. If the board could detect which part of the board is bad and isolate that part, not all the board must be down.
[Brad] Sounds like what I said about future of testing to test a functional block and bring a portion of a board out-of-service. My DSP example is a case in point.
[Brad] configuring tests to include only certain devices (put those in EXTEST, keep others out of EXTEST) will be necessary more and more;
[Carl] that is already practiced and shouldn't be a problem;
[Carl] Tooling needs to be able to partition a design for testing to support this at the board and system level.
[Heiko] conditioning the non-boundary scan circuitry, especially also those boundary scan devices that are kept out of EXTEST, may become more complicated/complex if only part of the boundary scan devices are used in EXTEST;
[Brad] Feels POST should be autonomous at FRU and not dependent on System level. Useful at EST and functional test station.
[Heiko] if POST is limited to a FRU, testing between FRU's can be considered a structural test for diagnostic purposes, executed after POST;
[Ian] This really is an initiated self-test in my mind. Testing a backplane as an FRU gets a bit muddy.
[Brad] Do we need to define levels of testing.
[Adam] That would be more helpful.
[Brad] board-level POST, system-level POST, and on-demand / initiated self test; each has its own recovery strategy; board-level POST will have a time constraint / time budget
- Brad will provide some information on forum, everyone to review before next meeting; The Partitions for Board POST include: FRU in total, FRU partitioned, Only tests that fit within the boot time budget, and Autonomous tests
[Brad] discussion to be continued at next meeting

By Proxy Feedback:
[Peter] Consideration must be made that, in theory, we should be able to execute all JTAG actions, but the level that the user chooses to do this for a particular design must up to them.

5. Schedule next meeting

Wednesday, 2/20/08, 8:15am EST

6. Review new action items

All: review how to use the forum
Brad will describe levels of self test in systems on Forum, everybody to review;

7. Any other business

Heiko - Need for a glossary of terms. POST would be a great candidate.

8. Adjourn

meeting adjourned at 9:30am EST

Many thanks to Heiko for assistance in writing these minutes!

Best regards,
Brad