ANM052 Radiation Tolerant SRAM for SPACE Applications Introduction The purpose of this document is to analyze the selection criteria for memory chips to be used in Spacecraft computers. A general trend is to implement more autonomous functions in Spacecraft, making use of increased processor performances, but requiring larger embedded flight software sizes and larger storage on board. This note provides an introduction to the current organization of European Spacecraft On-Board Data Handling systems and identifies the criticality of Spacecraft computer based functions. It recalls the constraints on memory planes linked to the Space environments, and gives examples of memory banks designs for typical sizes. In order to introduce the context of Space projects, the following figure represents a logic flow diagram of a typical Phase A /Phase B for a Spacecraft, where the most important trade-offs in term of Data Handling architecture and components selection have to be performed. Both Hardware and Software activities are represented, due to a strong interaction of both designs necessary to achieve the most appropriate processing system. Design of current Spacecraft on board data handling subsystems. Starting from an approved mission concept, the Spacecraft has to be designed to meet a number of operational and environmental constraints. The software functions are then detailed to size more precisely the necessary resources to fulfil the Spacecraft mission, and an interactive work at subsystem level is necessary to match hardware and software functions. The Spacecraft design is then reviewed at system level to check that it will meet the mission objectives, especially taking into account Space environment. Issues are then identified (mass, reliability, thermal aspects...) and corrective actions taken as necessary for each equipment or subsystem. For that concern RAM banks, they have a particular importance at system level, since they contain most of flight software functions. Single event upsets have now been identified since early 80s and corrective hardware methods have been implemented to avoid catastrophic effects. The main effect remains some degradation of the Spacecraft availability, whose impacts on the mission have to be assessed. To summarize, the steps in the selection process for memories in Space applications, are: D D D D PRELIMINARY ARCHITECTURE SIZING OF COMPUTER RESOURCES ANALYSIS OF SEU EFFECTS ON MISSION HARDENING STRATEGY A preliminary On-Board Data Handling architecture is defined, based on the experience gained by the industry, with a parallel allocation of hardware and software functions. This phase A work relies on existing hardware, re-utilization of standard functions and typical software figures. 1 Rev. C (11 March 97) ANM052 2 ORBIT PARAMETERS SPACECRAFT FUNCTIONS MISSION INDUSTRY PROCESSING ARCHITECTURE Existing HARDWARE AVAILABLE COMPONENTS ENVIRONMENT MARGINS COMPUTER Function Allocation RELIABILITY AVAILABILITY Preliminary SOFTWARE definition Preliminary HARDWARE definition SOFTWARE functions REPRESENTATION OF RAM MEMORY TRADE OFF LOGIC DURING A SPACECRAFT PHASE A / PHASE B FAULT Estimate of COMPUTING POWER Estimate of RAM/ROM SIZES Estimate of total RAM/ROM SIZES Input ROM Micro- RAM Output processor memory memory Theoretical RAM UPSET RATES Estimate of total COMPUTING POWER MISSION Impacts Theoretical MICRO UPSET RATES ANALYSIS OF COST IMPACTS Microprocessor frequency HARDENING POWER STRATEGY Rev. C (11 March 97) DIMENSIONS SELECTION OF SOLUTION HARDWARE & SOFTWARE UPDATES ANM052 The following figure shows the most general architecture for a European Spacecraft: TC GROUND CCSDS/PUS Communication Standards Central Terminal Unit TM OBDH bus Intelligent Control Unit MACS bus Remote Terminal Unit 1553 bus ICU RTU ICU A Central Terminal Unit interfaces with the Telecommunication subsystem and drives the Spacecraft bus on which terminals are computers (ICU for Intelligent Computer Units dedicated to the management of an instrument or to the Spacecraft Attitude and Orbit Control) or acquisition Units (such as the RTU, remote Terminal Units). A certain level of standardization has been achieved in the data transfer on-board and between the Ground and Flight segments. Communication systems for spacecraft follow the recommendations of the CCSDS (Consultative Committee for Space Data Systems). This ensures a certain level of inter-operability between the main International Space Organizations. This architecture can be now considered as stable, with a number of Space qualified ASICs supporting the protocols. The allocations of functions in a Spacecraft are also almost standardized. On-Board, data transfer buses are mainly the ESA On-Board Data Handling (OBDH) standard or 1553 bus. A specific bus for Attitude and Orbit Control subsystems (MACS bus) is also used. 3 Rev. C (11 March 97) ANM052 The functions are generally split according to the following hierarchy: Table 1: Location Spacecraft Bus Payload Type of Computer Typical Functions Central Computer Ground–Board interface Operational sequences storage and execution Telemetry storage during non visibility periods Attitude and Orbit Control Subsystem Computer Interface with the Central Computer Spacecraft Manoeuvres execution S/C attitude control laws AOCS monitoring and re–configuration Survival/safety mode attitude Paymoad Controller Interface with the Central Computer Payload operational sequences storage and execution Payload monitoring Scientific Telemetry storage Instrument processors Signal or image processing Data compression Instrument or equipment activation or positioning control loops As a general trend, data storage becomes more decentralized, especially in the Payload controllers, due to a change in the Telemetry system organization. In previous systems, the TM bandwidth allocation used to be fixed, the telemetry system was based on a cyclic acquisition scheme within the Spacecraft. Packet Telemetry systems nowadays allow a dynamic bandwidth allocation, which implies storage requirements for the computers generating the source packets. As a general trend for European Spacecraft, the availability of Space qualified component in Europe for the 90s should show the following type of computers. Table 2: Location Spacecraft Bus Payload Type of Computer Typical Components Central Computer Processor Mil Std 1750 (MAS 281, MA 31750...) Memory 128 to 256 Kbytes Attitude and Orbit Control Subsystem Computer Processor Mil Std 1750 (MAS 281, MA 31750...) Memory 128 Kbytes Payload Computer Processor Mil Std 1750 (MAS 281, MA 31750...) Memory 128 Kbytes Instrument processors Digital Signal Processors Motorola 68xxx 4 Rev. C (11 March 97) ANM052 A typical example of such a Spacecraft is the XMM satellite, whose Data Handling Architecture should be close to the following one: These are current data, and one can predict the use of RISCs for re-entry vehicles as well as Digital Signal Processors for Guidance, Navigation and Control associated with image processing. The following computer configurations can be considered as typical for space applications: Table 3: Microprocessor type Selected chip Memory size in Kbytes 8 bit microcontroller Atmel WM 80C32Ε 64 16 bit microprocessor MA 31750 256 32 bit RISC Atmel WM TSC691E 1024 For what concerns the memory type selection, the designer can select Rad Hard SRAMs or radiation tolerant SRAMs which are available on the market. The following diagram represents the availability of the various technologies, along several years. Memory integration Technology RH 6T SRAM RT 6T SRAM 4T SRAM 64K 256K 64K 256K 256K 1M 1M 90 91 4M 92 93 94 95 Time 5 Rev. C (11 March 97) ANM052 6 OPTICAL MONITOR REFLECTION GRATING SPECTROMETER MACS bus DIGITAL PROCESSOR UNIT 4 DSP 56001+local RAM+ Program memory + 11 Megabytes SRAM DBU Optical Monitor ICU RGS DATA UNIT RGS DATA UNIT 1750 MA 31750 48 Kword ROM 128 Kword RAM MA 31750 48 Kword ROM 128 Kword RAM 512 Kword RAM DBU CENTRAL UNIT DBU DBU Service Module RTU AOCS RTU OBDH BUS 1750 48 Kword ROM 128 Kword RAM DBU ATTITUDE CONTROL UNIT 1750 48 Kword ROM 128 Kword RAM MACS bus Rev. C (11 March 97) DBU DBU EPIC Data Handling Unit EPIC Data Handling Unit EDHU EDHU 1750 48 Kword ROM 128 Kword RAM 1750 48 Kword ROM 128 Kword RAM 1750 48 Kword ROM 128 Kword RAM 1750 48 Kword ROM 128 Kword RAM CONTROLLER CONTROLLER CONTROLLER 68000 48 Kword ROM 128 Kword RAM 68000 48 Kword ROM 128 Kword RAM 68000 48 Kword ROM 128 Kword RAM EUROPEAN PHOTON IMAGING CAMERA POSSIBLE ON BOARD DATA HANDLING CONFIGURATION FOR THE XMM SPACECRAFT DBU DBU RADIATION MONITOR Payload RTU ANM052 1.1. Analysis of single event upsets effects on a mission Single event upsets may cause malfunctions in several sensitive functions: microprocessors are affected by bit flips in the microprocessor registers, with immediate effects during the execution of an instruction. Memory bit flips in the programme code have similar effects. Bit flips in Input/Output registers may corrupt an address or data in transmitted messages, which is normally detected during protocol verifications. In terms of criticality, the service interruption of the Spacecraft computers can be described as follows, according to the computer class. Bit flips in the data area may have effects on a longer term if no automatic detection and correction are performed. Table 4: Function SEU Effects Corrective action Prevention in the design Instrument processors Not critical : interruption in an instrument operation loss of mission data Reconfiguration of processor possible need for instrument recalibrations Protection by EDAC of programme code area is recommended Payload processor Not critical : interruption in a major instrument or several instruments loss of mission data Reconfiguration of processor HW watchdog protection by EDAC of programme and data area is recommended AOCS processor Highly critical : loss of nominal AOCS possible loss of Spacecraft safe mode Interruption of mission possible automatic protection of sensitive instruments HW watchdog Software in ROM, dumped and executed in RAM with EDAC Hardware survival logic in backup Central processor Critical : interruption of the mission need for the S/C to enter a safety mode Interruption of mission operations HW watchdog protection by EDAC of programme and data area Up to now, Spacecraft design have been efficient enough to limit the SEU effects to mission interruptions only. Bit flips occurring in microprocessors or code create immediate crashes, which are generally detected by hardware watchdogs. There is no additional feature required for SEU, since this function is implemented to monitor both hardware and software behavior. The watchdog effect is generally a computer restart. In order to avoid complete software reloading, the flight software code is often resident in ROM, and copied on to RAM for execution. This implementation offers the advantage of allowing executable code modifications during the mission. The implementation choice between Rad Hard chips and Radiation Tolerant components associated to Error Detection and Correction devices (EDACs) depends on several criteria which have to be weighted according to each mission context. The following criteria can be identified: D D D D D D D D D Reliability Mass Size Power consumption Speed Sensitivity to heavy ion Error detection capability Availability Cost The following chapter details technical design aspects, which allow to establish comparison for these criteria between three implementations for typical microcontroller and microprocessor applications (from 64 to 256 Kbytes memory size). 7 Rev. C (11 March 97) ANM052 1.2. Solution For embedded computer applications where high reliability and autonomy is indispensable, protection of the RAM memory contents is of paramount importance. Such protection is achieved by using Error Detection and Correction (EDAC) circuitry in the hardware design. EDACs are integrated circuits to be connected to the data bus. The characteristics of an EDAC is to detect and correct single bit errors, and to detect double bit errors (present in one same data word) - this at the expense of so called check bits added to each data word and a minimum of additional processing. The Atmel Static RAM design separates the cells that represent the different dataword bits. This feature virtually eliminates the risk for one impact to provoke dual bit upsets, leaving only a minute risk for single bit upsets - an error that can be detected and corrected by an EDAC. Figure 1. Atmel Static RAM Design 8 bytes cells for bits 0..7 of one byte an impact here does not upset these cells The additional processing associated with an EDAC protected solution is the initialization of the checkbit RAM and a refresh procedure that performs read-write operations on the protected memory (“scrubbing”). The initialization of the checkbit RAM does not introduce an overhead since most spaceborne applications move their code from ROM to RAM at reset, and automatically initialize the check bit RAM at the same time. The scrubbing - performed during processor idle time - is necessary to eliminate the risk for two separate impacts to generate a dual bit upset in one same dataword. However, if a dual bit upset in one same data word should occur it would still be detected and signalled by the EDAC. 1.3. EDAC System Configurations In a “Correct-Always” system all data passes through the EDAC, where check bits are generated for each write operation and read data is always corrected. To reduce the additional amount of circuitry necessary to implement this type of system, a flow-through EDAC (separate data buses for CPU and RAM) should be selected. 8 Rev. C (11 March 97) ANM052 Figure 2. “Correct-Always” system with flow-through EDAC Address Address Flow Through EDAC CPU CHECKBIT RAM Check Bits CODE and DATA RAM Data Data Address Read/Write/Control In a “Bus-Watch” system all write data is fed to RAM and to the EDAC, where check bits are generated. Read data is always checked by the EDAC, and data errors are signalled to the CPU. Flow-through EDACs as well as regular EDACs are suitable for this type of system. The address with error and the syndrome should be latched to allow correction. Figure 3. “Bus-Watch” system Address Check Bits Interrupt or Waitstate CODE and DATA RAM EDAC CPU CHECKBIT RAM Data latch Data Read/Write/Control The “Bus-Watch” system is suitable for very fast systems, but implies more overhead in the error handling hardware and software. With respect to the processor speeds used in spaceborne systems, the propagation delay of flow-through EDACs is fast enough and therefore the “Correct-Always” solution has been used for the examples below. 9 Rev. C (11 March 97) ANM052 1.4. An 8 bit Microcontroller Application In 8 bit systems, error correction schemes become relatively expensive with respect to the check bits that have to be added - virtually twice the normal memory is required. This example uses the Atmel 80C32Ε, capable of speeds up to 30 MHz, together with Atmel EDAC & RAMs including 64k x 6 bits of additional Check Bit RAM. The timing diagram shows the External Code Memory Read cycle (fetch) which is more critical than the Data memory read and write cycles. Table 5: Power & board space consumption for protection of 8 bit application (64 Kbytes) Part count Flatpack size (mm2) – 30 MHz µC 6 ICCOP / iccsb1 (mA) EDAC : SMKS–29C516E 1 362 20 / 0.02 SRAM 32Kx8RT : SMDP–65656FV–45 4 190 170 / 0.1 Total for 1st Atmel solution 3) 5 1122 360 1) EDAC: SMKS-29C516E 1 362 20 / 0.2 SRAM 128Kx8RT: SMDI-65608EV-45 2 220 60 / 0.3 Total for 2nd Atmel solution 3) 3 802 140 2) EDAC: SMKS-29C516E 1 362 20 / 0.02 SRAM 32Kx8RH: (45 ns) 4 421 122 / 2 Total for Rad Hard solution 3) 5 2046 268 1) Type of Component 1) 2) 3) Two RAMs in operation, two in standby. EDAC Two RAMs in operation. EDAC Not taking into account space board design rules Figure 4. Atmel 80C32E at 30 MHz with Atmel 29C516E and SMDP–65656FV–45 (Instr.Read) CLK ALE tPLIV<65ns tLLPL=25ns PSEN tLLIV<100ns Latched Address ÏÏÏÏ ÏÏÏÏ ÏÏÏÏÏÏÏ ÏÏÏÏÏÏÏ tGLQV=20ns RAM Dout t4=34ns Corrected Data EDAC16 Data Out 2.5 ns tLLPL : 80C32E ALE low to PSEN low 0.20.53 tPLIV : 80C32E PSEN low to valid instruction available Read Interval tLLIV : 80C32E ALE low to valid instruction available tGLQV : RAM Output Enable Access time 10 Rev. C (11 March 97) ANM052 1.5. Application with 16 bit microprocessor and 64k Words RAM The example for this application is built around the space qualified MA31750 16 bit microprocessor at 9 or 16 MHz, and Atmel EDAC & RAMs including 64K x 6 bits of additional Check Bit RAM. Table 6: Power and board space consumption for protection of 16 bit application (64 KWords / 128 KBytes) Part count Flatpack size (mm2) - 9 MHz µP ICCOP / ICCSB1 (mA) - 16 MHz µP ICCOP / ICCSB1 (mA) EDAC: SMKS-29C516E 1 362 20 / 0.02 20 / 0.02 SRAM 32Kx8RT: SMDP-65656FV-45 6 190 65 / 0.1 100 / 0.1 Total for 1st Atmel solution 3) 7 1502 215 1) 320 1) EDAC: SMKS-29C516E 1 362 20 / 0.02 20 / 0.02 SRAM 128Kx8RT: SMDI-65608EV-45 3 220 36 / 0.3 45 / 0.3 Total for 2nd Atmel solution 3) 4 1022 128 2) 155 2) EDAC: SMKS-29C516E 1 362 20 / 0.02 20 / 0.02 SRAM 32Kx8RH: (55 ns) 6 421 93 / 2 120 / 2 Total for Rad Hard solution 3) 7 2888 305 2) 386 2) Type of Component 1) Three RAMs in operation, three in standby. EDAC Three RAMs in operation. EDAC 3) Not taking into account space board design rules 2) 11 Rev. C (11 March 97) ANM052 1.6. No wait state limits clock to 9 MHz Figure 5. MA31750 at 9MHz with Atmel 29C516E and SMDP–65656FV–45 (Read, No wait state) ÇÇ ÇÇ ÉÉ ÉÉ CLK AS A0–A15 RDN ÏÏÏ ÏÏÏ ÏÏÏÏÏ ÏÏÏÏÏ RD/WN tGLQV=20ns RAM Dout t4=34ns EDAC–16 Data Out MA31750 data valid required 5ns Corrected Data Read tGLQV : RAM Output Enable Access time t4 : EDAC “RAM data in” to “user data out” propagation time Interval (0 w.s) Figure 6. MA31750 at 9MHz with Atmel 29C516E and SMDP–65656FV–45 (Write, No wait state) ÇÇ ÇÇ ÉÉ ÉÉ CLK AS WRN A0–A15 ÏÏÏÏÏ t12=15ns MA31750 D[0..16] t12+=45ns ÂÂÂÂÂ ÏÏÏÏ ÂÂÂÂÂÏÏÏÏ RD/WN t22=19ns EDAC Data and Checkbits Out t3=26ns t12 : 31750 WRN low to data low.Z t12+ : 31750 WRN low to data out valid 5ns t22 : EDAC write enable to RAM data active tDVWH>20ns Write Interval (0 w.s) t3 : EDAC RAM data active to checkbits valid tDVWH : RAM data setup time 12 Rev. C (11 March 97) ANM052 21.7. 16 MHz clock speed requires one wait state Timing analysis at 16 MHz shows that one wait state must be inserted for each memory access cycle with 32K x 8 Atmel RAMs - H-65656FV-45. The increase in execution time due to one wait state in the memory access cycle is estimated to be in the order of 6%. Figure 7. MA31750 at 16MHz with Atmel 29C516E and SMDP–65656FV–45 (Read, 1 wait state) CLK ÇÇ ÇÇ AS A0–A15 ÉÉ ÉÉ RDN RD/WN tGLQV=20ns ÏÏÏ ÏÏÏ ÏÏÏÏ ÏÏÏÏ RAM Dout t4=34ns EDAC–16 Data Out MA31750 data valid required 5ns tGLQV : RAM Output Enable Access time Read Interval (0 w.s) Corrected Data Read Interval (1 w.s) t4 : EDAC “RAM data in” to “user data out” propagation time 13 Rev. C (11 March 97) ANM052 Figure 8. MA31750 at 16MHz with Atmel 29C516E and SMDP–65656FV–45 (Write, 1 wait state) CLK ÇÇ ÇÇ ÉÉ ÉÉ AS WRN A0–A15 ÏÏÏÏ ÏÏÏÏ ÏÏÏÏÏÏÏ ÏÏÏÏÏÏÏ t12=15ns MA31750 D[0..16] t12+=45ns RD/WN t22=19ns EDAC Data and Checkbits Out 5ns t3=26ns t12 : 31750 WRN low to data low.Z t12+ : 31750 WRN low to data out valid Read Interval (0 w.s) tDVWH>20ns Read Interval (1 w.s) t22 : EDAC write enable to RAM data active t3 : EDAC RAM data active to checkbits valid tDVWH : RAM data setup time 14 Rev. C (11 March 97) ANM052 1.8. Application with 16 bit microprocessor and extended memory The example for this application is built around the space qualified MA31750 16 bit microprocessor and MA31751 memory management unit (MMU) at 16 MHz, Atmel EDAC & Atmel RAMs including 128Kx6 bits of additional Check Bit RAM. Table 7: Power and board space consumption for protection of 16 bit application (128 KWords / 256 KBytes) Part count Flatpack size (mm2) - 16 MHz µP -ICCOP / ICCSB1 (mA) EDAC: SMKS-29C516E 1 362 20 / 0.02 SRAM 32Kx8RT: SMDP-65656FV-45 12 190 100 / 0.1 Total for 1st Atmel solution 3) 13 2642 321 1) EDAC: SMKS-29C516E 1 362 20 / 0.02 SRAM 128Kx8RT: SMDI-65608EV-45 3 220 45 / 0.3 Total for 2nd Atmel solution 3) 4 1022 155 2) EDAC: SMKS-29C516E 1 362 20 / 0.02 SRAM 32Kx8RH: (45ns) 12 421 120 / 2 Total for Rad Hard solution 3) 13 5414 398 1) Type of Component 1) Three RAMs in operation, nine in standby. EDAC Three RAMs in operation. EDAC 3) Not taking into account space board design rules 2) 15 Rev. C (11 March 97) ANM052 1.9. 16 MHz clock requires two wait states At 16 MHz clock speed, the use of the MMU requires one wait state in the write cycle and two wait states in the read cycle. The increase in execution time due to the MMU wait states is estimated to be in the order of 20%. Figure 9. MA31750/51 at 16MHz with Atmel 29C516E and SMDP–65656FV–45 (Read, 2 wait states) ÇÇ ÇÇ ÉÉÉ ÉÉÉ ÇÇ ÇÇ CLK AS ÄÄÄÄÄ ÄÄÄÄÄ ÂÂÂÂÂ ÂÂÂÂÂ A0–A15 MMU EAS MMU EAS and PA RDN ÏÏÏÏÏ ÏÏÏÏÏ ÏÏÏÏ ÏÏÏÏ RD/WN tAVQV=45ns RAM Dout t4=34ns EDAC Data Out Corrected Data MA31750 data valid required 5ns Read Interval (0 w.s) Read Interval (1 w.s) Read Interval (2 w.s) tAVQV : RAM Address Access time t4 : EDAC “RAM data in” to “user data out” propagation time 16 Rev. C (11 March 97) ANM052 Figure 10. MA31750 at 16MHz with Atmel 29C516E and SMDP–65656FV–45 (Write, 1 or 2 wait states) CLK ÉÉ ÉÉ AS WRN A0–A15 MMU EAS MMU EAS and PA ÉÉÉÉÉ ÉÉÉÉÉ ÂÂÂÂÂ ÂÂÂÂÂ ÏÏÏ ÏÏÏ ÉÉ ÉÉ t12=15ns MA31750 D[0..16] t12+=45ns RD/WN tAVWH (1w.s.)>40ns ÂÂÂ ÏÏÏÏ ÂÂÂÏÏÏÏ t22=19ns EDAC Data and Checkbits Out 5ns t12 : 31750 WRN low to data low.Z t12+ : 31750 WRN low to data out valid t22 : EDAC write enable to RAM data active t3=26ns tAVWH (2w.s.)>20ns tDVWH (1w.s.)>20ns tAVWH (2w.s.)>20ns Read Interval (0 w.s) Read Interval (1 w.s) Read Interval (2 w.s) t3 : EDAC RAM data active to checkbits valid tAVWH : RAM address setup time tDVWH : RAM data setup time 17 Rev. C (11 March 97) ANM052 1.10. Examples of bit flip predictions for typical computers Theoretical bit flips for a memory plane based on 256 Kbits memory chips (M-65656F) are the following for a shielding of 5mm (cf RD10 and attached annexes). Table 8: Bit flip prediction per bit and per day due to Heavy Ions Bit flip prediction per bit and per day due to Protons Total Bit flip prediction per bit and per day Low Earth Orbit 6.7 E-11 1.6 E-7 1.6 E-7 Polar Orbit 1.6 E-7 4.9E-7 6.5 E-7 Deep Space or Geostationary Orbit 6.2 E-7 Orbit type 6.2 E-7 Table 9: Recalling the two computers detailed in this document Computer Microprocessor type Selected chip Memory size in Kbytes A 8 bit microcontroller Atmel 80C32Ε 64 B 16 bit microprocessor MA 31750 256 The bit flips probability to be considered are as follows for inactive and powered chips: Table 10: Computer Memory size in Kilobits SEU in LEO SEU in Polar orbit SEU in Geosynchronous Orbit A 512 1 per 12.2 days 1 per 3 days 1 per 3 days B 2048 1 per 3 days 1 per 18 hours 1 per 19 hours Those figures are for inactive chips, and correspond to the probability of mission interruptions in the absence of any corrective design. For Low Earth Orbit missions which do not cross the South Atlantic Anomalia (SAA), the M-65656F can be used as such and no need for protection is actually needed. For all applications in low Earth, Polar and Geo-synchronous orbits, protective devices are necessary to limit the impact of SEU on the spacecraft mission. If an EDAC correction device is added, the necessary memory size is increased due to the correction code implementation, so the EDAC activation probability is increased. 18 Rev. C (11 March 97) ANM052 The SEU probability is given hereunder : Table 11: Computer Memory size in Kilobits SEU in LEO SEU in Polar orbit SEU in Geosynchronous Orbit A 896 1 per 7 days 1 per 1.7 days 1 per 1.8 days B 2816 1 per 2.2 days 1 per 13 hours 1 per 14 hours In terms of occurrence, there is no major difference, but the corrective design based on memory scrubbing has to be performed with a slightly higher frequency. 1.11. Conclusion The previous analysis allows to conclude that M-65656F can be used for Space applications. For the most current applications in low earth Orbit, Polar Orbit and Geo-synchronous Orbit, (MA 31750 at 16 MHz using 128 KWords of memory), the use of Atmel SRAM (M-65656F or M-65608E) with an EDAC (29C516E) appears as a valid solution from a system point of view, at the expense of one additional wait state. If the processing unit power happened to be actually an issue in an early state of a project, one should consider that a system problem does exist, which is not likely to be solved at the level of memory chip selection. For 8 bit microcontrollers in polar Orbit and Geo-synchronous Orbit, using an EDAC means practically to double the memory size, which might have a significant impact on the design. But for such applications, which are non critical, parts costs and availability have to be considered. 1.12. Reference documents This application note is based on a study done by THARSYS in 1994. (RD1) (RD2) (RD3) (RD4) (RD5) (RD6) (RD7) (RD8) (RD9) (RD10) High Reliability Products, Military and Aerospace Components Data Book, Temic (Atmel) 8 Bit Microcontrollers, Data Book, Temic (Atmel), 1997 80C32/80C52, Data Sheet, Temic (Atmel) SOS Radiation Hard, Hi-Rel IC and ASIC Handbook, GEC Plessey Semiconductor, 1993 16 Bits EDAC, Product Specification, Saab Ericsson Space, 1993 Detect/Correct Errors to improve data reliability, A. Hegde (IDT),Electronic Design, Vol 40, No 12, 11/6/1992 Designing with the IDT49C460 and IDT39C60 Error Detection and Correction Units, Application Note AN-24, Integrated Device Technology, Inc., 1989 High Performance Logic, Data Book, Integrated Device Technology, Inc., 1992 Radiation Hardened 32kx8 SOI CMOS Static RAM, Data Sheet, Harris Semiconductor, 12/1992 Evaluation of Heavy Ions and Protons induced upset rates of HM-65664E and M-65656F static RAMs (HIREX Technical Note, HRX/93.276, 26/11/93). 19 Rev. C (11 March 97)