The System JTAG Working Group

Return to index of Meeting Minutes

Minutes of Weekly Meeting, 2008-01-14

Participants:

Brad Van Treuren
Heiko Ehrenberg
Ian McIntosh
Carl Walker
Carl Nielsen
Peter Horwood
Adam Ley

Email Proxy on the Structural Test Use Case Discussion:

Guoqing Li

Meeting was called to order at 8:18am EST

1. Roll Call (See list above)

2. Review and approve 1/7/2008 minutes

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

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 (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)
Contact Guoqing regarding alternate meeting time process (Brad)
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) (Only Ian responded to request)
Continue Fault Injection/Insertion discussion on SJTAG Forum page (All)
Send additional sub topics to Heiko for the continued Structural Test use case discussion for 1/14/08. (All)

Guoqing's list is a very good start

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

SJTAG Value Proposition - Structural Testing (Continued...)

Brad turned the meeting over to Heiko, Champion of the Structural Test Use Case discussion.

Heiko: Many questions raised last time. There was a discussion about control of the clocks, especially for memory devices. The control of the clocks is still going to be important at the system level if these devices are going to be tested in-system.
Heiko: Jim made a good point last week about logs stored in memory that must not be touched at the system level when testing is performed.
Brad: This is where careful DFT needs to be done at the architectural level to ensure proper partitioning of the memory so testing could be performed without clobbering these memory regions.
Brad: Memory required to perform the test is also not able to be tested in the system.
Heiko: problems with memory test at system level could be resolved with IEEE P1581 (if the memories would implement such a test methodology)
Brad: I agree, especially for FLASH memory devices where the contents would be preserved after and during the test with P1581.
Heiko: reconfig of FPGA at the system level my need new BSDL file to enable interconnect testing since the logic family and voltage levels for the design are defined post-program condition.
Heiko: reconfiguration of FPGA's after test should be feasible, since the load must be stored somewhere in the system for FPGA configuration upon system boot/reset anyway
Brad: size of modern FPGA can cause problems concerning storage space (amount of memory needed to store various FPGA loads) and configuration time (if JTAG access would be used); some of the configuration devices don't support version rollback;
Carl N.: Customers are looking to do at speed memory test and high speed SERDES testing using FPGAs. These can be reprogrammed or embedded in the design of the FPGA. These little IP designs better quantify the test coverage metrics than what is done by using functional test.
Brad: Since the days of AT&T, we have always required certain levels of BIST in our ASICs. Moving to FPGAs meant we lost this deterministic test coverage of the device. We have been able to reuse tests from the FPGA vendor's foundary testing in-system to perform BIST tests that yield us as much as 95% coverage of the FPGA.
Heiko: Anthony Sparks mentioned 1149.6 and his concern that not supporting multi-drop may cause problems for board-to-board connectivity tests? any comments?
Brad: we need to provide a functional equivalent of multi-drop to support board-to-board connection tests within the ATCA provisions. This means we need some form of TAP transition synchronization that is provided by the current multi-drop technologies.
Peter: By bring the 4 wires from each card back to JSM a multi drop back plane can be made here
Heiko: spoke about the diagnostic capability from foreign tools vendors, brad demo'ed concept 2 years ago at BTW. It is important as part of sjtag to describe how this info should be transfered
Heiko: What kind of test diagnostics is going to be needed when you have an aggregate of boards from different vendors used in a slot?
Heiko: standardize data formats (test and diagnostics formats), diagnostics is an important result of structural test and should be provided in a usable format;
Ian: Systems that are multi-vendor indicates that there is a need for a standardized data format.
Heiko: ATCA is an open system supporting multi-vendor packages.
Brad: should SJTAG deal with data formats?
Ian: I don't think you'll get around that at the system level
Adam: it seems like SJTAG will need to drive data format specification because nobody else seems to be interested; what good is structural test without diagnostics information?
Ian: You almost need a BSDL for the board.
Adam: what is the real value of deploying structural test at system level?
Carl W.: test between modules/boards at system level
Adam: won't you get the same coverage with functional test?
Carl W.: maybe, maybe not
Ian: Knowing a board is faulty is still important.
Brad: functional test may not be able to provide the same level of diagnostics as boundary scan
Adam: Well written functional tests could give you the same or even better coverage.
Brad: The key with boundary-scan at the system level is you write the application process once and are able to use it for many missions. This is where a real cost savings comes into play. For functional test, you have to craft each one by hand for each new mission.
Adam: We haven't spent much on on the value of running structural testing at the system level - the pro side of the question.
Peter: Structural testing provides benefits to test between modules.
Adam: Won't functional test give you the same coverage controls?
Brad: We need to keep in mind and separate the different structural test technologies. 1149.1 is targeting faults different than 1149.6.
Ian: The greatest benefit is obtaining the diagnostics at the system level. GO/NO-GO is not worth it. Active backplanes really need good diagnostics.
Ian: 1149.6 becomes important as we use more active backplanes
Heiko: so, I'm hearing that diagnostics and ease of development are the biggest values that speak for boundary scan based structural test at system level?
Ian: I'd agree with that
Adam: manufacturers may want to protect intellectual property of their boards/modules; testing with boundary scan may make that easier than functional test;
Adam: In multi-vendor environments, we need to have some format in the test data stream that does not divulge the vendors IP information of the design.
Brad: the diagnostics provided by boundary scan may also help finding design problems in specific cards under certain conditions (e.g. temperature) by revealing failure trends; would be helpful in resolving such issues
Brad: The failure reports would be sent back to the third party vendor of that board to resolve the issues.
Adam: Board vendors may not want to develop fine grained functional blocks since this would expose their design. Boundary-Scan could simplify this coverage while hiding the design.
Peter: I have real concerns over pcb vendors wanting to provide the bear minimum for test coverage.
Adam: so we need a methodology to lower test generation effort while providing a means to protect IP
Brad: Test coverage that is not good will not sell the product in the telecom industry. This has already been seen with ATCA already. Interface device vendors are also realizing that if you cannot diagnose where a problem is in the system, the devices will not be sold. Diagnostic time is still down time and lost revenue for the customer.
Adam: how do card suppliers provide board level test for use at system level today?
Brad: mostly as functional test libraries; with go/no-go results only; kind of a "black box" approach
Adam: so, there is no adequate structural testing capabilities today?
Brad: correct
Brad: This is some of the reason why ATCA has not taken off as much since end users want to know more about system failures
Adam: There is not enough current capability in system test available today, either functional improves or we deploy structural testing in system
Brad: This requirement is coming from customers
Adam: Push back probably on test dev time and IP protection, need to identify way to lower test generation time and some IP protection
Heiko: this indicates value
Brad: Commented that we do need the full diags, looking to do real time diagnostics in system how do you process errors and store them. When does the error reporting need to be done?
Heiko: At the card level?? ie does net fail on card
Brad: When embedded test is used after structural test then when a test fails at functional they would want to know right then as well as where the failure is located. No sense in running functional test if you know there is a structural failure.
Brad: Where do diagnostics get stored? How and where would they get processed? Seems that people want failure information right then and there at any product life cycle stage
Carl N.: Storing failure locally is important. what level of diags is related to cost of product
Heiko: We all agree, we need to define a vector format for how it is stored, should be binary and system controller takes care of displaying the results to the user
Carl N.: Agrees that storage in non-volatile memory so that it can be extracted out to give full diag resolution. Some sort of a compressed format should be used to be able to capture more information.
Carl N.: Diagnostics down to component level, stored on the board, seems important to users; especially when failures occur under certain environmental conditions only;
Carl N.: Diagnostics down to the card as go/no-go means the card is going to get tossed if it is inexpensive or spend a lot of time in repair. More expensive cards should have the failure information stored on-board. Analysis of failure trends is important. It is not clear what needs to be stored - vector or bit level information.
Heiko: that brings us back to formating the diagnostic information for later use, data needs to be small to save memory space
Brad : Modularity in pcba's ie multi paths in card to boost performance, partitioning tests in future may soon be at a functional block level, then use this to select outage in PCB. For example, a board that has many parallel DSP filter paths processing incoming data may be partitioned to pass data through the remaining lanes of data if a DSP path goes down due to a failure. The board will not then be out of service, but service will be degraded in performance only. Thus, the customer will not be losing revenue as bad as he could if there were deemed a total outage of that board when one part of it fails.
By Proxy:
Guoqing:

Generally, Test could be at least classified into offline test and online test. Structural test belongs to offline test in most cases. Of course there are exceptions. Some company's blade server product monitors system work status around processors array in real time by JTAG built in main CPU. Said to a system, JTAG bus is a typical outband bus or can be called as escape bus. We could use it test part or all of system while function test cannot be executed in special situation by inband bus, for example, system is breaking down but it can be powered on.
If boards in a system are transported individually to field and then built up as a system at roll out, structural test could be as a part of POST.

5. Schedule next meeting

Wednesday, Jan 23, 2007, 8:15am EST

6. Review new action items

None

7. Any other business

SJTAG website will be moved to www.sjtag.org

8. Adjourn

Meeting adjourned at 9:35am EST