The System JTAG Working Group

Return to index of Meeting Minutes

Minutes of Weekly Meeting, 2008-04-14

Meeting was called to order at 8:23am EDT

1. Roll Call (Participants):

Brad Van Treuren
Carl Nielson
Ian McIntosh
Peter Horwood
Heiko Ehrenberg
Timothy Pender

Proxy additions provided by:
Yingwu Li

2. Review and approve 4/7/2008 minutes

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

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)
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 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)
Volunteers needed for Use Case Forum ownership (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)
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.
All: review how to use the forum
Locate ATCA glossary of board and system states (Adam, Brad)
Continue POST use case discussion on SJTAG Forum page (All)
Adam review ATCA standard document for FRU's states
Brad to review Service Availability Forum
Brad send out Ken Parker's response on the device stress issue (Done)

4. Discussion Topics

SJTAG Value Proposition � Built-In Self Test (BIST)

[Ian] I am slightly out of my comfort zone on this one because we no longer use JTAG to perform embedded testing any more. JTAG is traditionally used for testing the structure of the UUT. With BIST we are looking at more of a functional test of a device with device level BIST. At issue is where should a BIST controller reside: at the board level, at the system level? We need to ensure the board level BIST does not cause triggering of signals at the system level.
[Ian] device, board, or system level BIST; where are the resources located? Is there a time constraint? need to make sure the rest of the system is not disturbed (negatively impacted) by the BIST
[Heiko] Do we need to differentiate what BIST means as the device, board, and system level?
[Ian] That is a good idea since we need this for the glossary and people do have different terminology.
[Tim] What do you term as FRU? Field Return Unit?
[Ian] We use LRU (Line Replaceable Unit) and SRU (System Replaceable Unit). FRU in this group means Field Replaceable Unit.
[Brad] I think we also need to address the difference between Built-In Self Test and Built-In test. There is a difference because BIT used for externally initiated tests built in to the device/board/system; BIST is self-initiated by the respective component;
[Ian] BIST seems to be defined by the actual design requirements of the system. Thus, we might not be able to fully qualify what BIST is. We probably can only come up with the characteristics of BIST instead of defining what it is.
[Ian] We need to define when BIST is run (under which conditions) and how it is initiated/controlled
[Ian] I think a lot of people use the term BIST to mean when the test data required for applying the test is contained within the system/board/device and not needing to be brought in at the time of the test. Everything needed to apply the test is part of the environment for BIST.
[Carl N.] I am going to agree that we need to narrow down the definition because SJTAG as a whole is a broad topic so it is beneficial to highlight everything in as narrow a term as possible to help differentiate each of these technologies. There is a difference in technology required between something that is self sustaining and having tests stored in the system that is initiated by some other means. That other means might actually be a field service person needing to plug into as system to initiate the test that is stored in the system.
[Ian] Simple example of built in test vs. BIST is a monitoring program that is monitoring a power rail and shuts down the board if the power goes out of its thresholds. Built-In Test is often a set of designed in features that monitor the internal health of the system. Whereas, BIST is checking out the functionality of the devices and how they operate. We have a Power up BIT (like POST) and we have an initiated set of tests that we are able to request to run. For us, BIST fall more into the latter category.
[Ian] we are really looking at component features with BIT, not as much down to the logic function (like BIST does)
[Ian] Continuous BIT (running in the background in cycles) vs. Initiated BIT
[Tim] There are many ways BIST can be accomplished. Most common is processor based where a routine is stored locally or downloaded and checks how your system is run. Another is to reconfigure FPGAs on the board to be a BIST controller to be able to check out all things connected to it. Another method would be to use JTAG INTEST to pump in stimulus and monitor the outputs from the core and your generally JTAG initiated RUNBIST type of operations.
[Ian] There are some devices that are BScan devices where the BIST are not necessarily accessible from the JTAG interface. Some of the Cypress devices have a test pin and a result pin with no JTAG interface to the BIST operations.
[Yingwu(P)] About the BIST in the SJTAG, we find we mostly use the RUNBIST mode of the devices. But only a few devices provide the RUNBIST instruction. BIST is very helpful. But some BISTs can not be accessed from the JTAG interface. So that we think the BIST is limited in SJTAG up to now.
[Brad] I think we are still dancing around the definitions and characteristics and propose we focus on defining device BIST and move on from there.
[Ian] At device level, BIST provides a level of testing to test the functional operation of a device.
[Brad] A side effect is that the structural aspects of the device are also being tested, typically 95% coverage is supported.
[Tim] There could be internal BIST that covers the internal logic of the device (e.g., LBIST and MBIST) and there could also be BIST that controls external memory BIST or a peripheral BIST.
[Ian] You get into the issue of causing external stimulus that might affect the rest of the board with peripheral BIST.
[Brad] I think most of these peripheral BIST interfaces are quite dedicated to an isolated interface.
[Ian] I still think it warrants a note of caution still.
[Brad] I think we should post our current views of the definitions on the forum site and have people comment and add to the information as an output of this meeting.
[Heiko had to leave at 8:57]
[Ian] As we move up to the board level, not everything is going to have a device level BIST capability. Thus, you might not be able to click off the device BIST operations one by one to provide the board level testing.
[Brad] At board BIST do we need some sort of an embedded ATPG as part of the board?
[Ian] I think it makes things a bit easier to implement at an execution level by having a hierarchical control like this.
[Brad] Our Boundary Scan Master device with AT&T used to have this ATPG capability but only one product used the ATPG. Most relied on stored sets of vectors to be used as part of BIST.
[Tim] Do you mean there was an LFSR in the BSM?
[Brad] Yes.
[Tim] TI used to have levels of ATPG for board test in their original buffers.
[Ian] One of the other areas is creating the best capability for FPGAs and CPLDs to ensure testability features are incorporated these features in the design.
[Brad] FPGAs are a gray area between device and board. We are able to load in foundry tests to perform structural testing using these foundry tests to cover 95% of the FPGA structure. Unfortunately, there are 5 or more tests performed.
[Peter] What percentage of the devices are showing failures.
[Brad] I only know of one device failing, but for this product group, one failure is enough to require this level of testing.
[Ian] If you can load these foundry test externally, they can always be used as a diagnostic for investigation.
[Brad] This gets back to Ian's point that the requirements are going to drive what level of BIST is available.
[Ian] We have never tried to push on our vendors to obtain BIST level tests. It did not seem like there was something available.
[Brad] What motivated us to pursue the FPGA BIST is to recover the test coverage lost when we moved from ASICs to FPGAs. In the past, AT&T and Lucent required BIST as part of the ASIC design. We lost this when moving to FPGA designs. This is what spurred on the consideration of locating a way to do BIST with FPGAs. The FPGA vendors responded with the foundry tests because they did not know there was a need for these tests by their users.
[Ian] Clearly, you are not going to get great diagnostics, but if the FPGA test fails, you have to remove the device anyway.
[Brad] We do capture the response signature to be able to hand back to the vendor, but we are looking for a GO/NO-GO golden signature.
[Brad] Each of the tests focus on specific parts of the device so the results and which test fails provides some level of diagnostics to the vendor. It also provides some failure trending information.
[Ian] I think we are starting to run out of steam on this discussion today and I propose we continue the discussion next week and on the forum site.
[Brad] I have a few more points in my notes for today that I will post on the forum site that I hope will spawn more dialog next week.
[Brad] We will plan to continue this discussion at our next meeting.

5. Schedule next meeting

Wednesday, April 23, 2008, 8:15am EDT: Topic is BIST Use Case

6. Any other business

Who should be on proxy list? What constitutes regular attenders?

Brad will be addressing this item and look for advice on reworking the core group list based on participation activity at the next meeting. It is generally felt that core members should attend the meetings to be listed as core group members. It is unfair to companies that are supporting this activity with active participation when other companies are represented with little to no effort or cost.

7. Review new action items

None identified.

8. Adjourned at 9:30am EDT

(moved by Tim, second by Ian)

Many thanks to Heiko for assisting in taking notes for these minutes.

Respectfully submitted,
Brad