error and all static errors are corrected before the next single event upset can occur, .... mitigation of any kind. Soft errors, those not due to configuration errors, ...
Proton Testing of SEU Mitigation Methods for the Virtex FPGA Carl Carmichael1, Earl Fuller2, Joe Fabula1, Fernanda De Lima3 1
Xilinx, Inc. Novus Technologies, Inc. 3 (UFRGS) Federal University of Rio Grande do Sul, Brazil 2
Abstract Total ionizing dose (TID), heavy ion and proton characterization have previously been performed on Virtex FPGAs, fabricated on epitaxial silicon, to evaluate the onorbit radiation performance expected for this technology. The dominant risk is Single Event Upset (SEU), so upset detection and mitigation schemes were developed and tested to demonstrate the improvement in the programmed functional upset sensitivity and the system consequence of upsets. The Xilinx prescribed SEU mitigation schemes were tested for a generic functional usage at the proton facility in UC Davis.
monitoring for an upset in the configuration. Second, the part supports partial reconfiguration, which can speed upset recovery time.
III. RADIATION TESTING The space radiation effects of most importance for this work are single event effects including static, dynamic, and control logic upsets. The XQVR300 is the 300,000-gate device in the Virtex family that was used for testing and, because the technology scales just as SRAMS scale in complexity, is typical of all other parts in the family
A. Proton- Induced SEU Testing Because of the low threshold LET, proton upsets are possible and a similar static bit characterization was performed using the proton beam at UC Davis. The bit crosssection is presented below in figure 1. Proton SEU Cross Section for the Xilinx Virtex XQVR300
1.00E-11 Outliers
1.00E-12
2
This paper discusses the radiation performance of SEU Mitigation techniques for the Xilinx Virtex FPGA. SEU characterization has already been done for both static and dynamic modes of operation with results from both heavy ion and proton testing. Based on those results an SEU mitigation scheme has been developed to maintain functional integrity of a programmed design despite the occurrence of static and dynamic upsets.
Cross Section per Bit (cm )
I. INTRODUCTION
II. TECHNOLOGY CONSIDERATIONS
1.00E-13 1.00E-14 1.00E-15 1.00E-16 1.00E-17
The Virtex FPGA is an SRAM based device that supports a wide range of configurable gates from 50k to 1M. The XQVR Virtex is fabricated on thin-epitaxial silicon wafers XVLQJ WKH FRPPHUFLDO PDVN VHW DQG WKH ;LOLQ[
1.00E-18 0
10
20
30
40
50
60
Proton Energy (MeV)
PP
CMOS process with 5 metal layers. SEU risks dominate in the use of this technology for most applications. In particular, the reprogrammable nature of the device presents a new sensitivity due to the configuration bitstream. The function of the device is determined when the bitstream is downloaded to the device. Changing the bitstream changes the design’s function. While this provides the benefits of adaptability, it also makes the device vulnerable to inadvertent SEU reconfiguration upset. A device configuration upset may result in a functional upset. User logic can also upset in the same fashion seen in fixed logic devices. These two upset domains are referred to as configuration upsets and user-logic upsets. Two features of the Virtex architecture can help overcome upset problems. The first is that the configuration bitstream can be read back from the part while in operation, allowing continuous
Figure 1: Static proton induced bit-upset cross-section vs. proton energy for the Virtex FPGA. Note the identification of outliers in the figure indicating that the configuration control circuit upset mode was observed at the highest energies tested (63MeV).
Testing was conducted assuring that the test proceeded until a minimum of 100 bit upsets could be observed at each point provided statistical significance of the data. In this case we can fit the data to the Weibull formula as follows: :HLEXOO IRUPXOD ) [
sat
(1- exp{-[(x-x0)/W]s})
[3] where: F(x) = proton-induced SEU cross-section in 10-12 cm /bit; 2
sat =
limiting or plateau cross-section;
= 0.022 x 10-12 cm2 for Virtex x = proton energy in MeV; x0 = onset parameter; = 10 MeV for Virtex W = width parameter; = 30 for Virtex s
= a dimensionless exponent. = 2 for Virtex
This data is also used later for on-orbit upset rate analysis. It is also noted that from an analysis of the thin epi silicon that the thickness of the sensitive region is estimated to be
P
B. Discussion of Upset Modes Upsets in this FPGA can be grouped into three categories: configuration upsets, user logic upsets, and architectural upsets. The physics is the same for all, of course, but the observability and consequences vary. Configuration upsets are those that occur in the configuration bitstream and can be detected by readback. The functional consequences will either be failure or no disruption of the function. The likelihood of failure depends on which bit is upset, and the specific design utilization of the device resources. Most of the static bits in the device are accessible via readback. In the case of the XQVR300 there are 1.465M bits in the readback bitstream, which represents 84% of the total. The proton cross-section per bit is indicated in figure 4. Accordingly the static bit cross-section for the part is equal to the product of the number of bits and the cross-section per bit. Of course cross-section will actually be less because not every bit upset will have a consequence in a given design. The user logic contains elements not directly available in the bitstream for the purpose of upset detection. Actually most are in the bitstream but the contents are subject to change given the normal data manipulation functions that would be implemented. These include block RAM (BRAM), configuration logic block flip-flops (CLB-FF), and I/O block flip-flops (IOB-FF). Upset detection in these locations is not feasible because the state of each bit needs to be known apriori, and data in these locations changes state in the normal function of the user implemented logic. In addition, any sensitivity contribution from combinational logic falls into this category. Upsets can only be mitigated while in operation with redundancy, such as triple modular redundancy (TMR), implemented by a user in the FPGA logic design. Observability is limited unless the user design can capture an event. In this case the total upset sensitivity of the user logic will be the sum of the bits included in the design and some number of bits from the combinational circuits unique to the personalization of the FPGA, all moderated by the amount of and effectiveness of redundancy. Accordingly,
several designs need to be tested to develop useful metrics for these issues and this will be discussed below in section IV.C. Architectural upsets are those upsets in the control elements of the FPGA (e.g. configuration circuit, JTAG TAP controller, reset control, etc). Measurement of SEUs in these circuit elements is often only indirectly measurable in that one needs to observe and identify an upset “signature” and associate it with a control element function. As an example, it is possible for a single bit upset in the configuration control circuit to change many of the configuration bits all at once. This upset signature is observable and it’s frequency of occurrence in a heavy ion or proton test can be measured. And a small, but non-zero, cross-section can be determined in order to estimate the frequency of this type of event occurring in a given application. There are several objectives behind understanding the upset rate and the contribution of these different categories. First, one wants to understand all the possible mechanisms for the introduction of errors in the performance of a user's function. Second, to understand the severity of the upset problem, one needs an understanding of both the upset frequency and the consequence of the upsets that occur on the system function. These determine the cost of implementing mitigation measures and where they are most effectively directed. As an example, a remote sensing application which uses the FPGA to analyze sensor data may be more tolerable to upsets than for a spacecraft control function. Implementing redundancy may come at the cost of consuming 3 times the available FPGA resources available in each device, but will dramatically improve reliability and eliminate the consequence of most modes of upset.
IV. MITIGATION OF SINGLE EVENT UPSETS The goal of a mitigation technique that would be appropriate for this technology would be to remove the consequences of upsets so that there is no observable functional failure. This can be accomplished by combining two mitigation techniques, Triple Modular Redundancy design with static SEU correction through configuration scrubbing. A TMR design needs to be tolerant of any single event upset. The partial reconfiguration capability of this technology then allows static upsets in the configuration memory to be corrected before error accumulation can occur. As long as the design is immune to the effects of a single error and all static errors are corrected before the next single event upset can occur, then there should be no observable functional errors in the programmed design.
A. Triple Module Redundancy (TMR) Triple module redundancy (TMR) is used in the logic design to mitigate an upset as it occurs in the device configuration or the user’s logic. Should the upset occur in the users’ logic, TMR votes out the error. If the upset occurs in the device configuration, TMR eliminates the output of the discrepant logic path. The method for implementing TMR Page 2
suitable for designs implemented in this technology is described in the Xilinx published Application Note XAPP197[6].
readback of the bitstream is initiated and the number of bitstream errors is noted alongside the total fluence to functional error.
B. Bitstream Repair Techniques Bitstream reconfiguration, complete or partial, may occur without an interruption of service in the Virtex device. In addition, the device configuration can also be read back at any time without an interruption in service. These features allow two simple techniques for maintaining coherency of the bitstream. Scrubbing simply rewrites the device bitstream, so the time to repair an error is the scrub cycle time. Cycle time can be on the order of a few milliseconds and varies with device density. Continuous readback in conjunction with a detection algorithm (bit compare, CRC, etc) provides data on upsets encountered, time, and frequency. Partial reconfiguration (PRC) repairs any section of the device where an error is detected. The repair time is comparable to scrubbing. For a full discussion of the bitstream repair techniques and how they are implemented in the Xilinx product, the reader is referred to Xilinx application literature [5].
C. Dynamic-mode SEU Testing Dynamic testing provides an important measurement: the fluence to failure of a function. This is useful because static testing does not detect the contribution to sensitivity from combinational circuit operating at system speeds. Static testing also cannot determine the consequence of an upset; frequently an upset does not result in a functional failure. The problem with dynamic testing is that it provides poor fault isolation. It is difficult to identify the category of upset as the source of the failure. The other consideration for dynamic testing is that the test probes an FPGA design, not the device. A design will utilize some subset of the device resources and will have a unique cross-section. However, dynamic testing is perfectly suited for mitigation testing where the intent is that errors not be observed.
Figure 2: SEU Test platform.
In the stand-alone mode the test software can not be used because the control chip performs a reiterative scrub of the configuration bitstream in order to correct static upsets faster than they can occur. In this mode of operation the fluence to functional error is the only observation that can be made. The general test strategy is shown in figure 3. The control chip contains equivalent functionality to that of the configured design in the DUT and a compare circuit. Data is transferred serially from the DUT to the control chip for comparison. Control software allowed for the device function to be halted on failure and then the bitstream could be read to determine how many bit upsets may have occurred. The proton beam fluence would accumulate until failure was detected and the resulting fluence-to-failure would indicate the cross-section of the dynamic function. Trials were repeated many times to provide statistics on the measured cross-section.
1) Testing Platform The test platform, shown in figure 2, is made from two AFX V300PQ240-100 daughter cards, a MultiLINXTM cable used as an interface to a host PC, and a control panel. The system can operate stand-alone or in conjunction with a host PC and test software. The control panel communicates directly with the control chip to specify the mode of operation. Configuration of the DUT may be controlled by either the control chip or the test software via the MultiLINX Cable. The control chip also controls the dynamic operation of the DUT and dynamic error detection. The test software is used in experiments where bitstream correction will not take place so that readback may be used to analyze the nature of the dynamic errors. Test software would then load the design configuration onto the part and dynamic operation could be initiated. When an error is detected a
DUT Design XCV300
comparator
Error
Design XCV300
Figure 3: Error detection method. The test design was implemented both with and without mitigation strategies to be able to measure the potential benefit. A basic design would be developed that would use Page 3
Counter 3
Counter 2
Counter 1
Counter 0
about one-third of the device. A second version would be implemented in a TMR mode. Finally, each design would allow for the bitstream to be read and corrected (PRC), or continuously scrubbed to prevent individual bit upsets from accumulating. In this way each of the potential mitigation strategies could be tested individually or in combination. The figures below show the designs used.
32 x 8-to-1 Multiplexers and 32 bit shift
1
pipelining was also implemented within the counter modules in order to utilize the desired amount of the device CLB resources. The purpose of this design is to implement a large amount of state-machine logic within the device. Since state-machine logic is always dependent on the previous state, upsets have a more critical and long lasting effect on functionality. Therefore, this is an important exercise for the mitigation methods to be tested. The goal of the second design was to implement identical functionality as the first design but with complete immunity to single event upsets. This is accomplished by tripling all the logic of the design. The TMR method used is specific for this architecture. Every logic node is tripled, and majority voters are placed inside register feedback paths. Additionally, a TMR output scheme is used to disable discrepant outputs.
Output
32
Counter 7
Counter 6
Counter 5
Counter 4
2) Testing Procedure
State-machine Through-put IOB Logic
Figure 4: Block diagram of design without TMR. Eight multiplexed 4x8 counters, states captured in parallel and serially shifted out.
TMR Outputs 32 x 8-to-1 Multiplexers and 32 bit
The fluence to upset was measured for the baseline, no TMR, and TMR design. In each case the configuration bitstream was readback to record the number of accumulated bit errors. A logical reset of the flip-flops used in the design would then demonstrate whether the functional error is due to the corrupted configuration bitstream. Then fluence to upset was again measured for the TMR design while the configuration of the DUT is continually scrubbed by the XQR18V04 configuration Flash-PROM. For all tests the proton beam was set to an energy of 63MeV. The Flux was controlled to keep the time to failure for the non-scrubbed test runs within a few minutes. For the scrubbed test run the flux was set to a maximum limit that kept the configuration error rate slightly less than the scrub rate. Several practice runs were used with the flux much higher than the scrub rate in order to observe that rapid accumulation of errors would overwhelm the scrubber. The scrub frequency used was 11 MHz. This gives a scrub cycle time of 16ms. Therefore, in order for the upset rate to be less than the scrub rate the flux had to be set to less than 1E9 p/cm2/s, but sufficiently high enough for data to be collected. Therefore, the selected flux for the scrubbed runs was 8.4E8. 3) Results & Interpretation of Dynamic-mode SEU Testing
Figure 5: TMR version of counter design.
The first design contains 8 counter modules. Each counter module contains 4 (8-bit) counters in parallel to produce a 32bit output. The 8 counter modules are then multiplexed together. The output of the multiplexer is captured by a 32-bit serial shift register. One each clock edge the shift register shifts out a data bit. Every 32 clocks the counters are incremented for one clock. Every 8,192 clocks the selection of the multiplexer increments to select the next counter. In this manner every state of every counter is shifted out to the control chip one bit per clock cycle. Additional buffering and
The no-TMR was tested without bitstream upset correction. Two different error signatures were observed. All errors were functional failures. The first category, soft errors, recovered operation with reset. The second category, hard errors, required complete reconfiguration of the device to recover operation. Soft failures cannot be attributed to configuration upset errors, or recovery with reset would not be possible. The number of configuration bitstream upsets to cause hard failures is shown in figure 6. The significance of this data is that on average 6.5 (+- 6) configuration bitstream upsets are required to upset a design with no mitigation of any kind. Soft errors, those not due to configuration errors, Page 4
accounted for 45% of the total errors in all tests with no mitigation (TMR or bitstream). # of Configuration Bit Upsets for each Dynamic Function Upset
Frequency (9 Trials)
# of Configuration Bit Upsets for each Dynamic Function Upset Frequency (69 Trials) 9
8
8
7
7
Mean = 139 bit upsets / Dynamic Function Upset
6 Mean = 6.5 bit upsets / Dynamic Function Upset (Std Dev = 6)
6
5
5
4
4
3
3
2
2
1
1 0
TMR Design (no bitstream correction)
9
No TMR Design (no bitstream correction)
0 0
5
10
15 20 25 # of Configuration bit Upsets
30
0
50
100
35
Figure 6: This histogram shows the number of bit upsets detected for each dynamic function failure in proton testing. Often, several configuration bits upset before a hard functional upset occurs.
The TMR design was also tested in the same fashion, without bitstream correction. There were two significant differences observed for the TMR test. The first difference was that no soft errors were observed. All functional errors were due to accumulated errors in the configuration bitstream and required reconfiguration in order to recover. The second difference was a dramatic increase in the number of accumulated configuration bit errors prior to functional error. The observed minimum number of configuration upsets to functional error was 23, with an average of 139 bit upsets. This demonstrates that the TMR design is functionally immune to SEUs in the configuration bitstream, CLB flipflops, and combinatorial logic.
150 200 250 # of Configuration bit Upsets
300
350
Figure 7: : This histogram shows the number of bit upsets detected for each dynamic function failure in proton testing. Often, several configuration bits upset before a hard functional upset occurs
To show the degree of benefit demonstrated by TMR and / or bitstream mitigation, data from four different tests is shown in figure 8. Each test is many trials measuring fluence to failure for a design (hard or soft). The no-TMR and TMR designs were tested with and without bitstream upset scrubbing (PRC). The equivalent total static fluence to failure of the device is also shown on the graph for reference. This number is derived by multiplying the proton saturation crosssection for each bit, times the total number of bits in the bitstream, and then plotting the reciprocal.
Proton Fluence to Upset: Dynamic Test Results 11
Scrubbing of the configuration bitstream was then used to correct configuration errors in the TMR design as they occurred. Based on previous observations the expectation was that there would be no functional errors observed other than upsets in the control logic. The desire for these test runs was to test until the control logic was upset. However, the expected fluence to control logic upset is ~1E12 p/cm2. Such a high fluence would far exceed the 100krads(Si) maximum TID rating for the part. At a fluence of 8.7E11 the accumulated TID if the part was 118.5krads(Si). Increasing Icc began to lower the Vcc requiring that the test be paused to allow the Icc to return to within operating specifications and then the test would resume. This was repeated several times until a fluence of 1E12 was achieved which brought the accumulated TID to 136.4krads(Si). No SEU related functional errors observed nor was the control logic successfully upset. This was considered a zero error rate result. Therefore, no data points can be plotted.
10
Static Proton Fluence to Bit Upset
Proton Fluence: P+ /cm
2
10
9
10
8
10
7
10
No Functional Errors
10
6
10 NoTMR
NoTMR + PRC
TMR
TMR + PRC
Dynamic Design
Figure 8: Scatter plot of the results of fluence to failure trials of the four mitigation levels. Over the range tested, no frequency variation is evident.
Page 5
Dynamic Function Reliability Number of days to Dynamic Error at a given bit upset rate
100%
V. ON-ORBIT SEU RATE ESTIMATES Every orbital scenario is different, however, it is useful to calculate an upset rate for sample orbits. For the sake of example, several circular orbits were modeled assuming a 60degree inclination angle and operation during solar maximum. Using these assumptions and the CREME96 model [4], the upset rate for the device can be estimated. With the knowledge of both the proton and heavy ion response, this modeling tool provides both an orbital average upset rate as well as the higher rate that would occur during periodic solar flare events. The graphs below indicate some of the results of the modeling effort.
XQ VR300 SEU Rates S tatic bits upsets only
SEU’s per device day
100.00 F lare E nhanced
10.00 1.00 Quiet S un
0.10 0.01 100
1,000
10,000
TMR with Scrubbing (POR Limit)
90%
70% 60% TMR without Scrubbing
50% 40% 30%
10 Device Years
80%
5 Device Years
Functional Reliability (% Mission Success)
Several observations can be made. First, no significant difference can be achieved with either TMR or scrubbing by themselves. However, combing TMR with Scrubbing the design was observed to be functionally immune to upsets. However, this mitigation scheme is not immune to control logic upsets. Although, control logic upsets were not observed in this test, such an error has previously been observed at fluences exceeding 1E12. Therefore, if we assume that 1E12 is the upper fluence limit for the mitigation method tested (neglecting TID effects) then the improvement factor is ~10,000X.
conditions. As shown in figure 9 the static bit error rate for this device and orbit is one bit per day. Therefore, if the device is accumulating one bit error per day we can graph the expected reliability. In this case reliability means the probability that a function error will not occur.
20% No Mitigation Method
10% 0% 1
10
100
1,000
10,000
100,000
# Device Number of Device DaysDays at 1 SEU per Day
Figure 10: This plot shows the functional reliability for each mitigation scheme based on the observed number of configuration bit upsets per functional error shown in figures 6 and 7 and the expected static bit error rate shown in figure 9.
The read line of figure 10 shows the expected reliability for a non-mitigated design in an XQVR300 device. It shows that with less than one bit error there is only a 55% probability that the device will not have a function error by the end of the first day in orbit. This is due to the contribution of soft errors for a non-mitigated design. The blue line demonstrates the reliability of a TMR design. Soft errors do not contribute to the dynamic cross-section of a TMR design so it is at 100% reliability at the beginning of the mission. From the collected data we see that the minimum number of bit errors needed to generate a functional error (for this design) is 23, and the maximum is 276. The green line shows the contribution of scrubbing the TMR design. Since there is no accumulation of bit errors the device should stay at 100% reliability. However, there is a known cross-section for a control logic upset mode that must be accounted for. Therefore, applying the lambda function for this upset mode gives the eventual drop-off in the curve.
Orbital Altitude (km) (at 60 deg) XQVR300 SEU Rates
( C R EME96 & AP 8max)
'\QDPLF)XQFWLRQ8SVHW5DWH
Figure 9: This plot is obtained by calculating the hypothetical sensitive volume of the XQVR300 as the product of all of the bits in the FPGA and the average proton and heavy ion cross-section. As demonstrated by the dynamic test data, the expected upset rate should be lower depending on the degree of mitigation employed.
Taking the calculated static bit error rates of figure 9, for a particular orbit, and applying this to the measured bit upsets per functional error shown in figures 6 and 7, we can calculate an expected reliability for a given mitigation scheme. Such an example is shown in figure 10. The orbit demonstrated is 1000km solar maximum quiet sun
SE 10.00000000 U’s 1.00000000 0.10000000 per 0.01000000 day 0.00100000 0.00010000 0.00001000 0.00000100 0.00000010 0.00000001 100
1,000
10,000
100,000
Orbital Altitude (km) (at 60 deg) &5(0( $3PD[
Page 6
UHYL VHG
Figure 11: CREME96 orbital upset rate calculation for the control logic upset (SEFI-POR). Based on the known cross-sections of the circuit elements that comprise the control logic, the expected orbital upset rate is calculated and shown in figure 11. These calculations are also supprted by the observed upsets in both Heavy Ion and Proton testing conducted by Xilinx, Los Alamos National Laboratories, and Saab Ericsson Space.
VI. SUMMARY & CONCLUSIONS The results of this radiation characterization program show that the Virtex FPGA meets TID and SEL requirements for many orbital applications. The static-cross section has been measured for both heavy ions and protons by testing the device as though it were an SRAM. LET threshold determined in the heavy ion test proved the part is sensitive to the proton portion of the spectrum. Dynamic testing required a proton accelerator so that the time between upsets could be increased, thereby allowing for accurate measurements Two dynamic upset signatures have been found, soft errors where a reset is sufficient for recovery, and hard errors that require device reconfiguration. In tests without mitigation, 45% of the failures cannot be attributed to configuration bitstream upsets. It is also shown that, on average, 6.5 bitstream upsets are required for a functional failure for the test designs without mitigation. No measurable dependence on clock rate was found. Applying the correct mitigation techniques successfully hardened functionality of the device with the following benefits: The first benefit is that soft errors do not create functional errors. The second benefit is that individual static errors do not create functional errors. The third benefit is that the self recovering nature of the TMR design automatically updates internal state data when configuration correctness is restored. The fourth benefit is that error detection is not necessary thus overhead system logic is not required to facilitate mitigation.
Special thanks is also offered to Fernanda DeLima of the University of Brazil. Fernanda’s work in fault insertion analysis was instrumental in discovering test methodology flaws that had tainted previous SEU mitigation testing results.
REFERENCES [1] E. Fuller, M. Caffrey, P. Blain, C. Carmichael, N. Khalsa, A. Salazar, "Radiation Test Results of the Virtex FPGA and ZBT SRAM for Space Based Reconfigurable Computing," MAPLD 1999 Proceedings, C_2, September 1999. [2] E.L. Petersen, J.C. Pickel, J.H. Adams, Jr., and E.C. Smith, "Rate Prediction for Single Event Effects -- a Critique," IEEE Transactions on Nuclear Science NS-39, No. 6, pp. 1577-1599, December 1992. [3] A.J. Tylka, W.F. Dietrich, P.R. Boberg, E.C. Smith, and J.H. Adams, Jr., "Single Event Upsets Caused by Solar Energetic Heavy Ions" IEEE Transactions on Nuclear Science, December 1996. [4] A.J. Tylka, J.H. Adams Jr., P.R. Boberg, B. Brownstein, W.F. Dietrich, E.O. Flueckiger, E.L. Peterson, M.A. Shea, D.F. Smart, and E.C. Smith, "CREME96: A Revision of the Cosmic Ray Effects on Micro-Electronics Code" IEEE Transactions on Nuclear Science, December 1997. [5] C. Carmichael, "Correcting Single-Event Upsets through Virtex Partial Reconfiguration”, Xilinx Application Note XAPP216, June, 2000. [6] J. Wang, R. Katz, J. Sun, B. Cronquist, J. McCollum, T. Speers, W. Plants, “SRAM based Re-programmable FPGA for Space Applications” IEEE Transactions on Nuclear Science, Vol 46, No. 6, pp. 1728 – 1735, December 1999. [7] C. Carmichael, "Triple Module Redundancy Design Techniques for Virtex FPGAs”, Xilinx Application Note XAPP197, June, 2001. .
Testing of these mitigation methods have also been performed in a heavy ion environment by Saab Ericsson Space under contract with the European Space Agency. Results will be posted at the RADECS Conference in Grenoble, France, September 2001.
ACKNOWLEDGMENTS The authors wish to thank Mark Dunham, Michael Caffrey, and Tony Salazar of Los Alamos National Laboratories for their support of this work.
Page 7
