On the Use of Distributed Reconfigurable Hardware in ... - CiteSeerX

Digital Avionics Systems Conference, 2001.

On the Use of Distributed Reconfigurable Hardware in Launch Control Avionics B. Earl Wells and Sin Ming Loo Department of Electrical and Computer Engineering University of Alabama in Huntsville Huntsville, AL 35899

Abstract This paper discusses the feasibility of employing reconfigurable hardware in the avionics systems of future generations of launch vehicles for space. Such technology has the potential of being orders of magnitude faster than conventional embedded computer technology for many applications. It can be argued that avionics architectures that use such reconfigurable elements may vastly improve the flexibility, efficiency, performance and reusability of the avionics system. It can also be argued that such a flexible environment will facilitate the implementation of advanced and mission-specific real-time fault tolerance, avoidance, and corrective techniques and would greatly facilitate sensor/data fusion operations. However, before this technology can be applied to such safety critical applications there are several issues that must be resolved. Such issues center around the suitability and robustness of reconfigurable hardware for in-flight operation. In this paper we investigate many of these issues, focussing upon the use of reconfigurable hardware to form a generic multi-functional launch controller element that can be replicated as needed and distributed throughout the launch vehicle.

Introduction Hardware that can reconfigure itself has great potential for use in the avionics system of future Reusable Launch Vehicles, RLVs [1,2], and Expendable Launch Vehicles, ELVs. Such hardware would have the flexibility that is commonly associated with traditional embedded system software but have the performance that is close to specifically design hardware that performs the desired function. This technology could be used in multiple avionic systems including Guidance and Navigation (GPS/Inertial), Engine Controls, Telemetry System (with data encryption), Range Safety Functions, and Payload Control. Generic avionics launch controllers, considered as black boxes, could be constructed which would combine traditional embedded microcontrollers with reconfigurable hardware [3,4,5]. These would be distributed throughout the launch vehicle where they would be programmed/configured to perform the specific functions for the particular avionic system that they have been assigned. In the case of RLVs, these black boxes could be reused in future missions being reprogrammed/configured to perform the function that is associated with the new mission. Such technology could also have an impact on the avionics systems in ELVs, because the generic launch controllers could be produced in large quantities through a single procurement thereby reducing their per unit cost. The common avionics system platform would then serve to foster an environment which could greatly facilitate hardware and software design reuse as mission requirements evolve from mission to mission.

1

Digital Avionics Systems Conference, 2001.

The remainder of this paper is organized as follows. The advantages and disadvantages of reconfigurable hardware [3] in this application domain are first discussed. Then the reader is introduced to some of the general characteristics of Field Programmable Gate Arrays since this technology appears to be one of the most promising mechanisms to implement reconfigurable hardware in the avionics systems of RLVs and ELVs in the near future. The suitability of these devices for spacebased application and their robustness is then discussed. In this discussion, it is assumed that the RLV or ELV will be designed to take its payload to the Low Earth Orbit, LEO, region of space -the suitability of avionics systems for vehicles or stages that penetrate further in space are not a focus of this paper. Potential contributions of reconfigurable hardware to system fault tolerance are then briefly discussed followed by an investigation into how such hardware can affect system maintenance and test. This is followed by a brief investigation into the level of design automation support that is currently available in the market place as well as the availability of pre-designed Intellectual Property core modules that can be used to facilitate hardware/software co-design. At the end of this paper some general conclusions are presented.

Reconfigurable Hardware Current avionics systems extensively utilize embedded microcontrollers and dedicated hardware peripherals to perform their intended function. There is much flexibility present in these systems but this flexibility is restricted to the software portion of the design -- the hardware portion remains fixed from the time of its fabrication. Unfortunately, the embedded microcontroller is very sequential and it spends much of its time not performing useful computation but rather simply moving data around. A very large portion of the logic gates which make up its hardware (up to 99%) are in fact idle most of the time [6]. Reconfigurable hardware allows flexibility to be implemented that avoids this bottleneck. With reconfigurable hardware it is possible to apply much of the flexibility, that was formally restricted only to software, to highly parallel hardware allowing high speed mission-specific applications to be executed in a general purpose manner. Another area which could benefit from the better mapping of reconfigurable hardware to the application is that of real time processing. In addition to potentially decreasing the execution time by several orders of magnitude for certain tasks, the incorporation of reconfigurable hardware could also provide the mechanism for more deterministic execution. This is because many of the hardware constructs associated with modern embedded microcontrollers such as those associated with interrupt processing and cache memory operations are very nondeterministic in nature. This nondeterminism compromises attempts to guarantee that all time constraints will always be met. The incorporation of reconfigurable hardware gives the avionics system designer additional flexibility which could be used to assign many time critical applications to their own hardware, making these functions more independent and autonomous of such nondeterministic operations. Reconfigurable hardware can take on at least two forms which differ from one another by when the hardware is actually configured to perform its intended function [7,8,9,10,11]. The simplest form of configuration is the pre-launch configuration which allows the reconfigurable devices to be configured at any time prior to the launch of the vehicle. This type of reconfiguration utilizes what is known in reconfigurable computing terminology as spacial partitioning, where all functionality is determined a priori and distributed across the reconfigurable hardware before in-flight

2

Digital Avionics Systems Conference, 2001.

operation. If in-circuit reconfigurable devices are utilized, this type of reconfiguration will allow the same hardware design to be reused in a different manner for each mission. This will facilitate design reuse, since most missions are evolutionary in nature. As experience with the avionics system and vehicle grows and failure modes become well known, small changes to the launch avionics hardware may even be possible right before launch by downloading new configurations through the Ground Support Equipment (GSE) port. Another form of reconfigurable hardware that has possible merit in the RLV and ELV arena include hardware that can be reconfigured in flight. This hardware would facilitate the use of what is called temporal partitioning or run-time reconfiguration where the hardware is configured to perform a series of tasks one after the other by reconfiguring itself between each task. This time multiplexing allows for the possible reduction of such hardware since each reconfigurable module would be able to perform different functions at different phases in the mission. The alternative is often the incorporation of hardware in the system avionics which is not used during a large portion of the mission. Both forms of reconfigurability have the potential of improving the test and maintenance of vehicle avionics as well as improving its tolerance of operational and design faults. They also give great flexibility allowing functionality of different components of the avionics system to be optimally placed without the need to fabricate and test dedicated hardware for each new mission. Advances in reconfigurable hardware technology continue to result in ever increasing amounts of processing power being incorporated into electronics that possesses an ever-shrinking footprint (volume, power, and mass). This in turn allows for algorithmic techniques to be employed in this hardware that are much more complex than those previously implemented. For terrestrial operations, reconfigurable computing has been applied in a number of areas with much success. Significant improvements in performance have been obtained for problems such as data encryption/ decryption, long multiplication, RSA cryptography, data compression, image and video processing, string matching, heat and Laplace equations, Newton's mechanics, binary 2D convolution, Boltzmann machine, 3D graphic accelerators, discrete cosine transforms [12,13,14,15,16,17,18,19]. Even some NP-hard type problems such as the Boolean satisfiability problem have been shown to be solved much faster on reconfigurable hardware than on traditional high-end workstation processors [20]. In general, such reconfigurable hardware is a good candidate for use in situations which large amounts of data must be acted on in a very similar manner. Good candidate applications in the launch avionics domain include advanced digital signal processing, encryption/decryption operations associated with vehicle telemetry communications, implementation of high speed guidance navigation and control algorithms, advanced signal conditioning and data reduction operations associated with traditional and smart sensors/actuators, advanced application specific fault diagnostics and detection, and high performance and adaptive algorithms for range safety and vehicle health monitoring. It should be noted, though, that there are some applications which will not efficiently utilize reconfigurable hardware. These include those which have complex control information flow and those which have irregular computations. Fortunately these applications tend to execute quite well

3

Digital Avionics Systems Conference, 2001.

on a traditional embedded microcontroller. While reconfigurable logic can be configured to implement such microcontrollers it does so at a large price in terms of Integrated Circuit, IC, real-estate, circuit board area, and performance. For this reason, it is not expected that avionics systems will ever be entirely composed of reconfigurable logic. These systems will most likely be made from an appropriate mix of traditional embedded microcontrollers and reconfigurable logic to create generic reconfigurable avionics processing units which can be configured in hardware and programmed in software to take on the designated functions. It may be possible to integrate the reconfigurable logic and the microcontroller functions in a single integrated circuit. There has been much work done in the area of reconfigurable computing for terrestrial systems [21,22,23] and there is some movement in the market in this direction [24]. There are at least two companies that have introduced 8 and 32 bit embedded system microcontrollers which have a portion of the IC which contains reconfigurable logic [10,25]. The advantage of this setup is that the communication delays between the embedded processor and the associated reconfigurable logic are reduced through the incorporation of wide internal busses. There is always a trade off between the time it takes to send the reconfigurable logic the desired information from an embedded microcontroller and the time it takes the reconfigurable hardware to perform the desired operations on the data and send the results back to the microcontroller. This single IC arrangement has the advantage that higher speed communication of information is achieved allowing for much finer grained operations to be performed by the reconfigurable hardware. It also has the added advantage that power consumption and external I/O wiring is reduced. The major problem that has been observed, though, is that these processors were not designed to be in a space based environment since such products are relatively new to the market place. At this point in time such products are being applied to Earth based applications where they are in direct competition with low and medium scale embedded microcontrollers and their derivatives. No radiation hardened versions appear to be under development. There is also great uncertainty as to whether the commercial market will ever be large enough to allow these companies to spin off space qualified versions of these products. While it is felt that avionics system designers should continue to consider this possibility, the more likely scenario for the generic processing unit in the near term future appears to be to combine a high-end space qualified embedded processor with one or more of the commercially available radiation hardened Field Programmable Gate Array, FPGA, units. The general capabilities of these devices as they relate to their possible incorporation in future avionics launch control systems will now be discussed.

Field Programmable Gate Arrays, FPGAs Field-Programmable Gate Arrays, FPGAs, were introduced to the hardware design community in the mid 1980s as a means to incorporate so-called random logic into a minimal amount of ICs. (In this paper, we use the term FPGA in a generic sense. It also includes devices that can be classified as Complex Programmable Logic Devices, CPLDs, the major difference being the particular internal connection architecture.) As these devices have grown in size and function they have had a major effect in the areas of rapid prototyping of low volume application specific designs, digital logic emulation, and have served greatly to improve the time-to-market for new product designs. Although there are many differences in the internal structures of these devices, they all can be described as having a large number of configurable logic blocks, each of which can be configured

4

Digital Avionics Systems Conference, 2001.

to emulate a certain amount of combination and/or sequential logic. These logic blocks themselves are interconnected to other logic blocks and the input/output pins of the FPGA IC through some form of a routing matrix. Both the logic blocks and the routing matrix can be configured by the user after the chip has been constructed. The switches that allow this reconfiguration can be constructed from fuse, antifuse, EPROM, Flash/EEPROM, and SRAM technology [26,27,28]. The fuse and the antifuse technology are one time programmable devices which would not support the reconfigurability necessary for in-circuit pre-launch or in-flight reconfigurable systems and the EPROM based FPGAs are usually not incircuit programable and must be irradiated with a UV light in order to reconfigure their contents. This precludes their use as reconfigurable hardware in these avionics systems as well. This leaves the Flash/EEPROM based devices which are good candidates for pre-launch reconfigurable avionics and the SRAM based FPGAs which can be used to support both pre-launch and in-flight reconfigurability. It is possible in principle to use the Flash/EEPROM based FPGAs for the inflight reconfigurability but the high reconfiguration time of modern devices precludes this use in most scenarios. The major drawback to SRAM-based FPGAs for many applications such as avionics has been its volatility. If power is lost for any significant portion of time the device will lose all or part of its configuration leading to unpredictable operations which could be disastrous. But this is also true of traditional embedded microcontrollers. Both would have to circuitry that would in effect reset the electronics in the event of a power failure. In the FPGA case the configuration memory would have to be reloaded from a nonvolatile source -- in the embedded microcontroller case, program memory would have to come from a non-volatile source. Both would have to have the necessary rollback mechanisms to avoid loss of data and to return to proper execution. The reconfiguration time of early SRAM based FPGAs was also a major concern. This was because most of the original FPGAs were designed to facilitate rapid prototyping of glue logic so the reconfiguration time was not the major factor that FPGA designers were asked to address. Often reconfiguration data was clocked in one bit at a time using a relatively slow clock. In modern devices, this reconfiguration time has been greatly decreased from that of seconds to in some cases less than a millisecond. Also, original SRAM based FPGAs utilized what is called destructive reconfiguration where the act of reconfiguring the device disrupted the operation of all FPGA logic, even that which did not need to be reconfigured. Newer devices such as the Xilinx Virtex Series of FPGAs support non-destructive reconfiguration where only the portion of the device that is being reconfigured is affected [29,30]. This reconfiguration time is still a major issue when developing in-flight run time reconfigurable avionics systems -- it is still very large compared to the propagation delay of the gates -- but the trend is encouraging. It seems that the major factor that affects the use of these devices is not so much their volatility or reconfiguration time (at least for pre-launch reconfigurable avionics) but rather their suitability and robustness for launch and space based environments. In the next section we will discuss these issues as they relate to both the volatile and nonvolatile FPGAs.

5

Digital Avionics Systems Conference, 2001.

Suitability and Robustness of FPGAs The suitability and robustness of FPGA-based avionics is very much based upon such issues as device reliability, power consumption, and susceptibility to radiation. A major assumption here is that the launch vehicle will be designed to take its payload to the Low Earth Orbit, LEO, region of space -- the suitability of this avionics for vehicles or stages that penetrate further into space is an area for further research. Device reliability is a major issue for launch control avionics because such systems undergo much mechanical and acoustic vibration during the launch process and must operate in a wide range of thermal environments. In this regard one would expect FPGAs to have as other CMOS integrated circuits that posses the same feature size. This is because FPGA device packaging options are equivalent to other ICs. It should also be noted that there has been no mention of reliability problems inherent in the designs of FPGAs in the literature that describes their use in large scale applications. Of course specific detailed engineering reliability analysis would need to be performed before any particular FPGA device (or any other new electronic device for that matter) is put into safety critical avionics applications. Power consumption and thermal dissipation are also major issues with launch controller avionics. Again FPGAs have followed the trend of other application specific ICs -- they posses the thermal heat dissipation packaging options as other ICs. The reconfigurable interconnect portion of their structure, though, does introduce additional parasitic capacitances which in turn lead to additional power consumption at high clock rates when compared to application specific ICs which have been design to perform the same function. This problem has been compensated for, at least in part, by the introduction of new device capabilities which allow the FPGA to selectively disable sections of the IC which are not needed. In many applications, power consumption can also be decreased by developing large pipelines that closely match the natural data flow present within the application. This allows much lower clock speeds to be used which results in lower levels of power being dissipated. Also by incorporating the sizable glue logic functions inside the FPGA the amount of external signaling that exit and enter each IC is reduced. This in turn reduces the amount of drive power that is required by the I/O drivers [5]. The susceptibility of these devices to radiation effects is also another important concern [31,32,33]. As the RLV or ELV travels from the Earth's surface into space to deliver a LEO payload it will be subjected to ever increasing amounts of incident radiation. When it enters into LEO region of space the Earth's magnetosphere protects the vehicle and its avionics from the worst of the radiation problems but the radiation levels that exist still have the potential to produce soft and hard circuit faults in the device electronics. These effects are likely to become more pronounced as the VLSI feature size of the ICs continues to shrink. Reconfigurable hardware such as FPGAs are not immune to these effects, especially the volatile SRAM based ones. Another important factor to remember is that upsets in the FPGA configuration memory have the potential to create hardware configurations that cause internal or external damage to avionics electronics due to electronic contention that might be created on internal and external busses. So obviously these must the avoided or properly recovered from in order to avoid disaster in any launch vehicle scenario.

6

Digital Avionics Systems Conference, 2001.

Three major metrics that are commonly used in determining the level of radiation susceptibility are Total Ionizing Dose (TID), Single Event Latch-up (SEL) and Single Event Upsets (SEU). The TID measures the cumulative amount of ionizing radiation (usually in Krads) that the device can be exposed to before it may fail. TID ratings for devices can be improved through special circuit design techniques and shielding methods [31,32,34]. In RLV based avionics TID is a major concern which will be one of the factors determining how many missions the same generic avionics unit can fly. In ELV based systems, TID is much less of a concern since the vehicle will spend such a short time in these radiation prone environments. SEL is an abnormality that occurs before a device has reached its TID when relatively high radiation levels produce energetic particles that cause a low resistance path from power to ground. It is sometimes measured in probabilistic terms. Sometimes SEL can be destructive to the device -- in other cases the device will work properly again if it power is removed and applied again after all transient effects have been allowed to diminish. Obviously devices that are subject to SEL would pose major problems for space based applications since in both cases they interrupt the normal operation of the device. Fortunately, this problem has been all but eliminated for many FPGA devices which are targeted to operate in a typical LEO radiation environments through the incorporation of special current limiting circuitry and other techniques. The SEU poses a more persistent problem especially for SRAM based FPGAs. Here radiation interaction with the device electronics causes one or more bits to be flipped in the configuration memory of the FPGA. This problem is not a major issue for FPGAs that are based upon the less volatile FLASH/EEPROM technologies once they are correctly configured, although there is significant upset potential if these devices are reconfigured while in such radiation environments. The major manner in which similar devices, such as SRAMs, that are used in traditional embedded microcontroller applications control this problem is to employ some form of Error Detection and Correction, EDAC, circuitry which uses from 10% to 50% [35] additional storage and hardware to implement a special EDAC algorithm to detect and correct single and sometimes multiple bit errors. While such technology could also be incorporated within space based FPGAs it is not prevalent since this significantly reduces the amount of programmable logic available to the user. One current solution to SEU problem makes use of the architectural feature which is present on some FPGAs that allows the configuration memory to be read without affecting the current operation of the FPGA. This would allow external readback circuitry to be constructed which would constantly readback the current configuration and compare it with a nonvolatile or EDAC protected copy of this configuration. If there is an error, the device will be reconfigured at an acceptable point in time. Problems with incorrect configuration could be all but eliminated by incorporating redundant logic for the reconfigurable logic portion of the design. This can be done automatically with many logic synthesis tools by selecting such options as Triple Module Redundancy, TMR when the design is synthesized to the targeted FPGA. It should be noted that the use of TMR in the synthesis process, the relatively low SEU rate (in the orders of several hours per expected SEU for some SRAM devices that are subject to LEO conditions) and the relatively short mission durations for launch vehicles may result in such read back circuitry being unnecessary to achieve the desired level of safety.

7

Digital Avionics Systems Conference, 2001.

While there appears to be few projects that specifically target launch vehicles as an application area for reconfigurable logic there are several projects that propose using FPGAs and other devices in LEO satellites and other space based applications. The robustness analysis performed here should be a conservative guide which will allow us to set the design parameters for such radiation concerns as TID, SEL, and SEU. The idea is that if such technology were robust enough for use in vehicles which are designed to reside many years in these higher radiation environments it is reasonable to assume that similar device technology can also be employed within RLVs and ELVs which will spend much less time in these environments. There are several projects that are on the horizon which will serve to experimentally test some of the most sensitive FPGAs characteristics in space. One is the Australian FedSat-1 Satellite project which is a LEO satellite which is scheduled for launch in February 2002. One of the items which is present on board this satellite is an engineering research experiment which contains a high-performance computing module called the Adaptive Instrument Module, AIM, which incorporates reconfigurable logic [21,22]. A major focuse of this project is to collect actual engineering data on the radiation effects of SRAM based FPGA technology during the life of the mission. It is expected that this module will be involved in a number of spacecraft activities including digital filtering, communications system error detection/correction/monitoring and, data encryption/ compression/decryption.This module is to utilize the Xilinx XQR4062 SRAM based FPGA which has the non-intrusive configuration memory readback capability discussed previously. It should be noted that conservative analysis from this team expects that SEU will occur at a rate of around one SEU an hour. Another notable project which proposes to use SRAM based FPGAs in space is the Adaptive Scientific Data Processing project of NASA Goddard Space Flight Center [23]. In this project it has been suggested that SRAM based FPGAs be used to provide the on-board processing power that will greatly reduce the quantity of remote sensing data produced by Earth Observation System satellite missions (which includes data from the areas of atmospheric chemistry, hydrology, geophysics, climate change and trends, land use, etc.) thereby making better use of the limited down link assets. The project has focussed primarily on analysis of the feasibility aspects from the data processing point of view. This research highlighted new usages for reconfigurable technology. Such innovative applications have resulted in a number of new product offerings by FPGA vendors [24,36]. One such product offering was recently made in May of this year by Xilinx corporation. It is a radiation hardened million gate version of its high-end Virtex SRAM based line of FPGAs. Xilinx reports that this device has a TID rating of 100 Krads, is immune to SEL, and SEU immunity is possible through design redundancy. Xilinx has announced that this device has been selected for use by NASA's Jet Propulsion Laboratory in the 2003 Mars Exploration Rover mission [24]. In summary, there are many options to consider when choosing a FPGA for launch vehicle reconfigurable avionics. The most promising in-circuit reconfigurable devices from a TID, SEL, and a SEU point of view are those that are based upon FLASH or EEPROM. In most cases such devices meet or exceed the ratings which are a common requirement for three to five year LEO satellite missions [35] -- TID rating of greater than 100 K rads, SEL immunity, and very low probabilities of SEU (in the order 10-5 SEU per Device/Day in LEO) without needing special SEU recovery

8

Digital Avionics Systems Conference, 2001.

techniques. The SRAM based FPGAs are less robust but the SEU could probably be dealt with LEO bound launch vehicles -- especially given the fact that the operating environments during the early most critical phases of launch are very benign from a radiation point of view.

Fault Tolerance The manner in which reconfigurable logic can be used to make the vehicle less susceptible to hardware and software faults is a very broad and encompassing topic. In this section, this vast area of research will only be briefly highlighted. Fault tolerance is usually obtained through space redundancy -- physically replicating a portion of the design -- and/or through time redundancy -redoing failed portions of operations when a failure has been detected by healthy hardware or software. In the previous section, we described some of the possible failure modes that the FPGA based reconfigurable logic could be subject to and discussed how one space redundant technique TMR, and one time redundant technique, FPGA configuration memory roll--back correction can be implemented. These are common techniques that have been adapted from the vast amount of literature and experience in the area of fault tolerance. There are at least two main areas where FPGA-based reconfigurable launch control avionics can incorporate fault tolerance, detecting faults within the FPGA devices themselves and detecting faults in external hardware. In the previous section we briefly mentioned how FPGAs, especially SRAM based ones could use fault tolerant techniques such as TMR and rollback to improve their robustness. There are two types of fault that can occur in reconfigurable hardware, faults in the configurable logic and I/O blocks and faults in the configurable routing. The prevalence of these faults depend upon the architecture of the devices. There are a host of fault tolerant techniques that can be used to statically or dynamically configure the device to route around these faults. These are described in detail in the literature [37,38,39,40]. In cases where connected hardware is faulty, run-time reconfigurable FPGAs can be used to route around this hardware and/or take on some of the functionality of the faulty hardware. This is one of the proposed uses for the reconfigurable hardware of the FedSat-1 project [21]. FPGA based reconfigurable hardware can also be used as part of larger systems that handle fault tolerance at a coarser level of granularity. For example, TMR can be applied by replicating entire reconfigurable avionics modules. For greater diversity and less susceptibility to common mode design faults the FPGA in each module could be configured in a functionally equivalent but distinctly different manner by utilizing equivalent but different algorithmic or synthesis techniques. Another system level technique which fits into the generic reconfigurable avionics processor paradigm discussed previously is the idea of incorporating an extra reconfigurable avionics module on the launch vehicle which could act as a common spare which would automatically be reconfigured in-flight to take over the function of any one of the faulty avionics units. (It should also be noted that this common spare concept can also be applied to the configurable logic blocks within a FPGA). Reconfigurable hardware at both the system and device level has the potential to greatly facilitate the implementation of advanced application-specific fault detection, diagnosis, and isolation strategies. These strategies can make good use of the FPGAs high speed, memory, and routing

9

Digital Avionics Systems Conference, 2001.

resources much quicker than software only based implementations. This will allow fault tolerant techniques to be implemented in a timely manner. It will be left up to the avionics system designer to determine which fault tolerant techniques hold the most promise. It does appear, though, that the incorporation of FPGA-based reconfigurable logic will only serve to enhance the fault tolerant design options open to the avionics engineer.

Impact on Test and Maintenance It is no secret that test, verification, validation, and maintenance operations are major contributors to the reoccurring cost of the overall avionics system. It is believed that FPGA based reconfigurable hardware can greatly contribute to lowering these costs in a number of ways, some of which will now be briefly discussed. On the surface it may appear that the implementation of FPGA technology might even have a negative impact on the test and maintenance of the device avionics. This is because it is not enough to verify that the reconfigurable devices perform to specifications and that they are connected properly to each other and the other electronic elements in the avionics system -- one must also be concerned with exactly how they are to be internally configured before determining whether or not the overall system meets specifications. This would definitely be a major drawback in cases where the reconfigurable hardware itself was altered significantly from mission to mission but this is probably not the case if truly reusable generic reconfigurable launch modules can be created which can be reused for significant periods of time. In such a situation, the original design and test of the unit would require significant effort but once the unit itself was tested, and the first mission flown, the test effort for subsequent missions would probably be significantly reduced. This is because nondestructive testing of the avionics flight modules would be the same for all missions and all testing techniques that were applied to this unit previously could be reused. Any destructive testing employed to test the basic design concepts of the reconfigurable module would not have to be repeated. The major portion of the flight implementation that would have to be tested for each new mission is the application-specific portion. Since missions tend to be evolutionary in nature a good bit of this design will most likely be reused and the test procedures themselves can be reused. The only new test procedures that will have to be developed from scratch are those to test any new functionality being incorporated into the reconfigurable hardware. It is also important to note that the reconfigurable hardware itself can be used to facilitate the testing of the generic avionics unit in a number of ways. It can be configured to perform two functions, the intended function and extensive Built-in-self-Test, BIST functions. Comprehensive testing on the unit can be done after configuring both the hardware and software of the generic launch control module to perform extensive BIST of all hardware components. Then when the module is configured to perform its desired function a portion the logic can be configured to perform run time tests of the application and report its results in real time to diagnostic test equipment. The combination of the BIST and the previously mentioned fault tolerance techniques has the potential of greatly improving the test and maintenance of the vehicle.

10

Digital Avionics Systems Conference, 2001.

Design Automation Support Another consideration that is very important is the level of design automation that is supported. Reconfigurable logic is much too complex to create everything from the ground up or to configure the devices at the gate or register level. To address the "recreating the wheel" problem which occurs when one has vast amounts of reconfigurable hardware at ones disposal but a limited time and budget to create a viable design, many companies are selling as Intellectual Property, IP, core modules which posses great functionality. These modules include such common functions as arithmetic functions, signal processing (digital filters, digital encoder/decoder, convolutional encoder, Reed-Solomon encoder/decoder, etc.), communication interface, bus interface, peripheral devices, and basic microcontroller/microprocessor cores [25,41]. Most of these core modules are written in a portable form such as a hardware description language like VHDL or VERILOG and can be synthesized into a number of FPGA architectures. The modules can be licensed or purchased in a manner similar to traditional software libraries. Depending upon the license agreement, users can use all or part of the IP core and modify it to meet their current needs and make it operate efficiently in their particular environment. Of course each organization can create their own IP core library which is specific to their needs. This is one way the hardware portion of evolutionary avionics could be managed . The design automation tools for hardware description language synthesis are fairly mature since they have been evolving for over a period greater than fifteen years. If one comes from a hardware background their ease of use seems reasonable. Even so they are far from being bug free. The major disadvantage is that they further divide the hardware from the software. This is true even though a textural hardware description language is being used in most cases to represent the reconfigurable hardware. An ideal solution would be to create an environment where a common language could be used to represent the problem with the optimal mapping to hardware or software being done automatically or semi-automatically. This approach is being researched in a number of embedded system domains and forms the basis of new hardware/software co-design techniques which may be applied to reconfigurable avionics [42-60].

Conclusion This paper has surveyed a number of issues that concern the incorporation of reconfigurable hardware in the launch control avionics systems of future generations of RLVs and ELVs. In both cases, it is suggested that generic launch controller avionics modules be created which would be distributed throughout the vehicle. It has been proposed that these modules be composed of both traditional embedded microcontrollers electronics and reconfigurable hardware. The great flexibility and high speed advantages of reconfigurable logic has been discussed. Many of the challenges associated with incorporating this technology such as device reliability, power consumption, and susceptibility to radiation effects have also been discussed. The paper has also briefly described some of the fault tolerance, maintenance and testing benefits that are possible through the incorporation of reconfigurable hardware. The state of design automation which could be applied to this area both now and in the near future has also been surveyed. There are obviously major challenges that need to be addressed before actually employing such reconfigurable technology in launch control avionics -- especially technology that is based upon

11

Digital Avionics Systems Conference, 2001.

SRAM. Future attempts to utilize reconfigurable hardware in launch vehicles will depend upon the results of many commercial and academic efforts in such areas as device fabrication, hardware/software co-design, real-time systems, and reconfigurable computing. But at the same time, the feasibility of using reconfigurable computing already shows great promise. FPGA device robustness appears to be significantly improving, with even the SRAM devices now being proposed for use in deep space applications. The fault tolerant and built-in-self-test techniques that could be employed abound in the literature and practice. Large portions of the designs can now be readily procured and reused through Intellectual Property agreements. New hardware/software co-design paradigms are on the horizon. The ease of which it is possible to make evolutionary changes to missions has the potential to more efficiently use the limited avionics hardware potential, improve safety, reliability and augment maintenance.

References [1] Advanced Space Transportation Program Office, Project Plan for Reusable Launch Vehicle Technology, TD15-PLN-001, Marshall Space Flight Center, December 1999. [2] Powell, R. W., M. K. Lockwood, S. A. Cook, "The Road from the NASA Access-to-Space Study to a Reusable Launch Vechile," 49th International Astronautical Congress, Melbourne, Australia, 1998. [3] Hartenstein, R. , "A Decade of Reconfigurable Computing: A Visionary Retrospective," Proceedings of Design, Automation and Test in Europe, pp. 642-649, 2001. [4] Mangione-Smith, W. H., et. al., "Seeking Solution in Configurable Computing," IEEE Computer, IEEE Computer, vol. 30, no. 12, pp. 38--43, 1997. [5] Villasenor, J., and B. Hutchings, "The Flexibility of Configurable Computing," IEEE Signal Processing Magazine, , Vol. 15, No. 5, pages 67-84, Sept. 1998. [6] Deeker, Wayne, "Computing on the fly," CRCSS Space Industry News, Issue 83, June 1999, http://www.crcss.csiro.au/spin/spin83/SPIN8304.htm. [7] Lysaght, P., and J. Dunlop, "Dynamic Reconfiguration of Field Programmable Gate Arrays", in Third Int. Workshop on Field Programmable Logic and Applications, Oxford, England, Sept. 1993. [8] Hauser, J. R., J. Wawrzynek, "Grap: A MIPS Processor with a Reconfigurable Coprocessor," Proceedings of the IEEE Symposium on Field-Programmable Custom Computing Machines, pp. 24-33, April 16-18, 1997. [9] Waingold, E., et. al., "Baring It All to Software: Raw Machines," IEEE Computer, Vol. 30, No. 9, September 1997.

12

Digital Avionics Systems Conference, 2001.

[10] Triscend Corporation, Configurable Processors: An Emerging Solution for Embedded System Design, A White Paper, 1998 [11] French, P. C., and R. W. Taylor. A self-reconfiguring processor. In Duncan A. Buell and Kenneth L. Pocek, editors, IEEE Workshop on FPGAs for Custom Computing Machines, pages 5059, Los Alamitos, CA, April 1993. [12] Bertin, P., D. Roncin, J. Vuillemin, "Programmable Active Memories: A Performance Assessment," Digital Paris Research Laboratory, Digital Equipment Corporation, 1993. [13] Abott, A. L., P. M. Athanas, L. Chen, R. L. Elliott, "Finding Lines and Building Pyramids with Splash 2," IEEE Workshop on FPGAs for Custom Computing Machines, pp. 155-161, April 1994. [14] Riaz, M., H. M. Heys, "The FPGA Implementation of the RC6 and CAST-256 Encryption Algorithms," pp. 367-372, IEEE Canadian Conference on Electrical and Computer Engineering, Alberta, Canada, 1999. [15] Kim, Ihn, C. S. Steele, J. G. Koller, "A Fully Pipelines 700MBytes/s DES Encryption Core," Proceedings of Ninth Great Lakes Symposium on VLSI, 1999. [16] Shand, M., "Flexible Image Acquisition using Reconfigurable Hardware," IEEE Workshop on FPGAs for Custom Computing Machines, pp. 125-134, April 1995. [17] Ross, D., O. Vellacott, and M. Turner, "An FPGA-based hardware accelerator for image processing," International Workshop on Field-Programmable Logic and Applications, pp. 299-306, Oxford, England, September 1993. [18] Drayer, T., W. King, J. Tront, and R. Conners, "MORRPH: A modular and reprogrammable real-time processing hardware," IEEE Workshop on FPGAs for Custom Computing Machines, pp. 11-19, April 1995. [19] Paar, Kevin J., and Peter M. Athanas, "Implementation of a Finite Difference Method on a Custom Computing Platform", Photonics '96, Boston, MA, Nov.1996. [20] Boyd, M. J., T. Larrabee, "A Scalable, Loadable Custom Programmable Logic Device for Solving Boolean Satisfiability Problems," pp 13-21, IEEE Symposium on Field-Programmable Custom Computing Machines, Napa Valley, California, April 2000. [21] Bergmann, Neil, W, Peter R. Sutton "A High-Performance Computing Module for a Low Earth Orbit Satellite Using Reconfigurable Logic" pp. 416-420, FPL 98. [22] Conde, R., A. G. Darrin, F. C. Dumont, P. Luers, S. Jurczyk, N. Bergmann, and A. Dawood, "Adaptive Instrument Module -- A Reconfigurable Processor for Spacecraft Applications," MAPLD 99.

13

Digital Avionics Systems Conference, 2001.

[23] Figueiredo M. A., Flatley T. P., Stakem P. H. , Hines T. M; "Extending NASA's Data Processing to Spacecraft", IEEE Computer Volume 32 number 6, pages 115-118, June 1999. [24] Xilinx Press Release, Xilinx Radiation hardened Virtex FPGAs Shipping to JPL Mars Mission and Other Space Programs, May 15, 2001, http://www.xilinx.com/prs_rls/ 0145xqvr1000.htm. [25] Altera Corporation, Intellectual Property Selector Guide, March 2001. [26] Rose, J., et. al., "Architecture of Field-Programmable Gate Arrays," Proceedings of the IEEE, Vol. 81, No. 7, pp. 1013-1029, July 1993. [27] Trimberger, S. , "A Reprogrammable Gate Array and Applications," Proceedings of the IEEE, Vol. 81, No. 7, pp. 1030-1041, July 1993. [28] Hauck, S., "The Roles of FPGAs in Reprogrammable Systems," Proceedings of the IEEE, Vol. 86, No. 4, pp. 615-638. July 1998. [29] Xilinx Corporation, Virtex Series Configuration Architecture User Guide, February 2000. [30] Xilinx Corporation, QPRO High-Reliability QML Certified and Radiation Hardened Products for Aerospace and Defense Applications, June 2000. [31] Katz, R., et. al., "Radiation Effects on Current Field Programmable Technologies," IEEE Transactions on Nuclear Science, Vol. 44, No. 6, pp. 1945-1956, December 1997. [32] Katz, R., et. al., "Current Radiation Issues for Programmable Elements and Devices," IEEE Transactions on Nuclear Science, Vol. 45, No. 6, pp. 2600-2610, December 1998. [33] Wang, J. J., et. al., "SRAM Based Re-Programmable FPGA for Space Applications," IEEE Transactions on Nuclear Science, Vol. 46, No. 6, pp. 1728-1735, December 1999. [34] Actel Corporation, Using Synplify to Design in Actel Radiation-Hardened FPGAs, May 2000. [35] Hillman, R. A., Microprocessor Design for Small Satellites, Master Thesis, University of Alabama in Huntsville, 2000. [36] Xilinx Press Release, Radiation Tests Show Xilinx FPGAs Can Be Used Without Limitation In High Altitude Avionics Applications, August 5, 1998, http://www.xilinx.com/prs_rls/neutron.htm. [37] Jean, J. S. N., et. al., "Dynamic Reconfiguration to Support Concurrent Applications," IEEE Transactions on Computer, Vol. 48, No. 6, June 1999.

14

Digital Avionics Systems Conference, 2001.

[38] Lach, John, W. H. Mangione-Smith, and M. Potkonjak, "Low Overhead Fault-Tolerant FPGA Systems," IEEE Transactions on VLSI Systems, Vol. 6, No. 2, pp. 212-221, June 1998 [39] Lach, John, William H. Mangione-Smith, and Miodrag Potkonjak, "Enhanced FPGA Reliability Through Efficient Run-Time Fault Reconfiguration," IEEE Transactions on Reliability, Vol. 49, No. 3, pp. 296-304, September 2000. [40] Keymeulen, Didier , et. al., "Fault-Tolerant Evolvable Hardware Using Field-Programmable Transistor Arrays," IEEE Transactions on Reliability, Vol. 49, No. 3, pp. 305-316, September 2000. [41] Filippi, E., "Intellectual Property Re-use in Embedded System Co-design: an Industrial Case Study," Proceedings of 11th International Symposium on System Synthesis, pp. 37-42, 1998. [42] Xiong, X., E. Barros, W. Rosenstiel, "A Method for partitioning UNITY Language in Hardware and Software," European Design Automation Conference, pp. 220-225, 1994. [43] Madsen, J., J. Grode, P. V. Knudsen, M. E. Petersen, A. Haxthausen, "LYCOS: The Lyngby Co-Synthesis System," Design Automation for Embedded Systems, Vol. 2, Nm. 2, 1997. [44] Carchiolo, V., M. Malgeri, G. Mangioni, "Hardware Software Synthesis of Formal Specification in Codesign of Embedded Systems," ACM Trans. Design Automation Electronic Systems, pp. 399-432, July 2000. [45] Osterling, A., T. Benner, R. Ernst, D. Herrmann, T. Scholz, W. Ye, "The Cosyma System," Hardware/Software Codesign: Principles and Practice, pp. 263-281, 1997. [46] Gupta, R. K., G. De Micheli, "Hardware-Software Co-synthesis for Digital Systems," IEEE Design and Test of Computers, 10(3), pp. 29-41, September 1993. [47] Antoniazzi, A. , A. Balboni, W. Fornaciari, D. Sciuto, "The Role of VHDL within the TOSCA Hardware/Software Codesign Framework", European Design Automation Conference, pp. 612-617, 1994. [48] Herrmann, D., J. Henkel, R. Ernst, "An Approach to the Adaptation of Estimated Cost Parameters in the COSYMA System", CODES '94, 1994. [49] Jantsch, A., P Ellervee, J. Oberg, A. Hermani, H. Tenhunen, "Hardware/Software Partitioning and Minimizing Memory Interface Traffic," European Design Automation Conference, pp. 226-231, 1994. [50] Kalavade, Asawaree, Edward A. Lee, "A global Critically/Local Phase Driven Algorithm for the Constrained Hardware/Software Partitioning Problem," Third Intl. Workshop on Hardware/ Software Codesign, pp 42-48, 1994,

15

Digital Avionics Systems Conference, 2001.

[51] Smith, T. E. and D. E. Setliff, "Towards an Automatic Synthesis System for Real-Time Software," In Proc. of 12th Real-Time Systems Symposium, pp 34-42, 1991. [52] D'Ambrosio, J. G., X. Hu, "Configuration-Level Hardware/Software Partitioning for RealTime Embedded Systems," In Proc. of Int. Workshop on Hardware/Software Codesign, pp. 34-41, Sept. 1994. [53] Wolf, W., J. C. Martinez, "C Program Performance Estimation for Embedded Systems Architecture Sizing," In Proc. of Int. Workshop Hardware/Software Codesign, Oct. 1993. [54] Hardt, W., R. Composano, "Trade-Offs in Hw/Sw Codesign," In Proc. of Int. Workshop on Hardware/Software Codesign, Oct. 1993. [55] Gupta, R. K., G. De Micheli, "Constrained Software Generation for Hardware-Software Systems," In Proc. of Int. Workshop on Hardware/Software Codesign, pp. 56-63, Sept. 1994. [56] Ye, W., R. Ernst, Th. Benner, J. Henkel, "Fast Timing Analysis for Hardware/Software Codesign," In Proc. of ICCD, pp. 452-457, Oct. 1993. [57] Dave, Bharat P., "CRUSADE: Hardware/Software Co-Synthesis of Dynamically Reconfigurable Heterogeneous Real-Time Distributed Embedded Systems," Design Automation and Test in Europe Conference, 1999. [58] Micheli, G. De, and R. K. Gupta, "Hardware/Software Co-Design," Proceedings of the IEEE, Vol. 85, No. 3, pp. 349-365, March 1997. [59] Edwards, S., et. al., "Design of Embedded systems: Formal Models, Validation, and Synthesis," Proceedings of the IEEE, Vol. 85, No. 3, pp. 366-390, March 1997. [60] Bolsens, I., et. al., "Hardware/Software Co-Design of Digital Telecommunication Systems," Proceedings of the IEEE, Vol. 85, No. 3, pp. 391-418, March 1997.

16