The System JTAG Working Group

Return to index of Meeting Minutes

Minutes of Weekly Meeting, 2008-03-31

Meeting was called to order at 8:24am EDT

1. Roll Call (Participants):

Brad Van Treuren
Carl Walker
Ian McIntosh
Timothy Pender

Proxy responses from:
Peter Horwood
Timothy Pender (Comments for portion of meeting he missed)
Yingwu Li

2. Review and approve 3/19/2008 minutes

Unable to approve minutes due to lack of quorum

No revisions proposed to the 3/19 minutes from the group present

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 (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)
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)
Brad to create a list of types of things programmed in a system for the Forum discussion (Done)
Adam review ATCA standard document for FRU's states
Brad to review Service Availability Forum

4. Discussion Topics

SJTAG Value Proposition � Programming/Updates

[Brad] Strategies for programming FLASH

Program all FLASH memory
Program boot loader and program FLASH with CPU

[Timothy] Been a while since programming with pure JTAG. We used to use a parallel port interface where the TCK was slow back then but a faster TCK improves things for time.
[Timothy] Some programming took us 20 minutes.
[Carl W.] Uses boot loader method due to time constraints because images are 30-40MBytes (huge)
[Ian] We have used the emulation interface to be the programming interface. We really use every method for our products. No one method is ideal. There is always something that is less than ideal.
[Ian] Problems with accessing emulator ports or other things that are more inconvenient. JTAG is most convenient since access is usually available to perform testing.
[Ian] Some programming takes 2 hours for a FLASH image
[Timothy] Problem with speeds is the TCK speed. We have actually reconfigured the FPGA to be the programming mechanism to be able to program at speed. If there was some way to load code into RAM and have an FPGA be a dedicated programming tool with a special image for that purpose the time would be fast.
[Brad] Use of the write pulse with JTAG programming is an improvement over straight JTAG
[Timothy] Prefer to use JTAG as last resort to perform FLASH programming. Would like to use functional means since they are faster.
[Ian] Having JTAG as a fall back position if the board is corrupted is its real purpose.
[Ian] Most people run into a speed issue that is becoming a brick wall. The biggest negative against JTAG is the programming time.
[Brad] Reprogramming FPGA to reduce the DR size using specialized DR wired to the FLASH I/O pins with the USER instructions is an improvement we talked about before.
[Ian] This can make a big difference regarding scan size for large FPGAs interfacing to the FLASH.
[Brad] Strategies for programming FPGAs?
[Ian] There are many FPGAs that are configured from FLASH now. We still use configuration SPROMS. For larger FPGAs we are relying on FLASH.
[Timothy] In large projects we rely on a hard drive to store the images. We would use the host CPU to program the FPGA without using JTAG.
[Timothy] If you have multiple FPGAs with the same configuration, you can load them concurrently.
[Brad] We also have cases where multiple images need to be supported for a single FPGA as well. This is very true in supporting the foundry BIST images for testing the internals of the FPGA hardware. There may be as many as 5 BIST loads required to get 95% coverage.
[Timothy] I have not been able to keep up with the costs associated with supporting configuration proms. It seems it is so hard to get the densities good enough.
[Ian] This is the primary reason we are using FLASH for the large FPGAs because the SPROMS are not big enough.
[Ian] We try to have one FLASH that is responsible for configuring multiple FPGAs. The Microprocessor is responsible for redirecting the images to the appropriate locations.
[Timothy] The most difficult think I find is managing the order of the strategy to know what has to be programmed with what technology first.
[Ian] There is a hierarchy of things to be done to get the board to be able to program the rest of it.
[Brad] Multi-drop access to FPGAs for fall back is a good thing. We have found adding this capability costs no more because it is the same as the test interface. We rely on on-board resources to perform programming of the board as the primary interface.
[Ian] We have found the JTAG is a great way for developers to test out new designs into the FPGA. So there is benefit to including this JTAG interface.
[Timothy] Are you able to program the FPGA directly using STAPL or SVF?
[Brad] We use STAPL or SVF to program FPGAs using the embedded software.
[Timothy had to leave at 900 EDT for another meeting]
[Ian] No serious issues with CPLDs since they tend to be a lot smaller. It is not worth the effort to find alternate means.
[Brad] Programming FPGAs and CPLDs cause the functional mode to be lost during programming.
[Ian] We tend to use CPLDs to control power management of the board. We use CPLDs where it is less likely to change over time for that reason.
[Carl W.] We tend to do the same and use them were there is less likely an impact to the rest of the system.
[Timothy (P)] I will proxy with info covered after I left. Regarding CPLD controlling board power. Much care needs to be taken when performing boundary scan tests on a board level and at even more so at system level. Some have mentioned CPLDs being used for board power up/down sequence, I have encountered a similar caveat when developing tests for Space Application. In our application we had a primary and redundant board with their outputs cross strapped. The issue is that the interlock circuitry that controls the power enable comes from a CPLD. The interlock circuit prevents both boards from being powered simultaneously. However via boundary scan both of these boards can be powered simultaneously because extest bypasses the programmed interlock logic.
[Brad] We can talk about strategies for storing the programming image as Adam proposed two weeks ago.
[Ian] It is difficult for me to imagine there would be data coming from anywhere other than outside the system.
[Brad] We obtain the data sometimes from the Shelf Controller for the on-board resources to use, but is this an alternate mechanism or just a continuation of transfer of data from the outside to the resource performing the update?
[Carl W.] There is typically a management interface where this kind of thing take place. This interface is where the remote technician gains access to the system.
[Ian] The method of getting data into the system is almost irrelevant to the discussion on JTAG. It is more important to deal with what you do with it once it is in the system.
[Ian] This is something that is going to be defined as part of the product and not about the JTAG design.
[Brad] As far as I know, all the programming tools are able to produce STAPL and/or SVF files to perform the programming operation. Since most of the embedded tools also support these languages, are STAPL and SVF good enough?
[Ian] They seem to be the most portable languages to support the embedded environment.
[Ian] SVF can become problematic dealing with the clock timings. Most designers do not realize the assumptions made by the tools regarding the TCK frequency.
[Brad] Xilinx, I know, assumes a 1MHz TCK.
[Ian] Yes and the designers don't realize we use different TCK frequencies in the system.
[Ian] The designers use the development pods and expect the embedded tools to work the same way since they are all JTAG.
[Brad] We are out of time today. For the next meeting we will continue the Environmental Stress Test discussion and table the Programming/Update discussion since we seem to have quite a bit of information right now to work with.
[Peter (P)] I would like to add we are looking at system JTAG so there may be many other ways of programming system flash, ie emulator pods using the micro etc. But the key point is to define a way that JTAG can be used to update flash in the field. This maybe for just the boot block or failure recovery but the capability would be there. The infrastructure is present (the Jtag signals) on a card for free by default so the end user can then decide if time/cost allows for alternate methods to be also included on the card.
[Yingwu (P)] Commonly we program the BootRom with SJTAG and program FLASH with CPU. If the CPU can't work well, we will also program FLASH with SJTAG. It would take us two hours more.

5. Schedule next meeting

Monday, April 7, 2008, 8:15am EDT

6. Any other business

none

7. Review new action items

none

8. Adjourned at 9:20am EDT

(moved by Ian, second by Carl)

Respectfully submitted,
Brad