Abstract:
A reconfigurable computer is disclosed. The computer includes a controller and at least one reconfigurable processing element communicatively coupled to the controller. The controller is operable to read at least a first portion of a respective configuration of each of the plurality of reconfigurable processing elements and refresh at least a portion of the respective configuration of the reconfigurable processing element if the first portion of the configuration of the reconfigurable processing element has changed since the first portion was last checked.

Description:
RELATED APPLICATION 
       [0001]    The present application is related to commonly assigned and co-pending U.S. patent application Ser. No. 10/897,888 (Attorney Docket No. H0003944-5802) entitled “RECONFIGURABLE COMPUTING ARCHITECTURE FOR SPACE APPLICATIONS,” filed on Jul. 23, 2004, which is incorporated herein by reference, and also referred to here as the &#39;888 Application. 
     
     BACKGROUND 
       [0002]    In one type of space application, a device traveling in space transmits data to a device located on Earth. A device traveling in space is also referred to here as a “space device.” Examples of space devices include, without limitation, a satellite and a space vehicle. A device located on Earth is also referred to here as an “Earth-bound device.” An example of an Earth-bound device is a mission control center. Data that is transmitted from a space device to an Earth-bound device is also referred to here as “downstream data” or “payload data.” Examples of payload data include, without limitation, scientific data obtained from one or more sensors or other scientific instruments included in or on a space device. 
         [0003]    In some applications, the quantity of payload data that is collected by and transmitted from a space device to an Earth-bound device approaches or even exceeds the physical limits of the communication link between the space device and the Earth-bound device. One approach to reducing the quantity of payload data that is communicated from a space device to an Earth-bound device is to increase the amount of processing that is performed on the space device. In other words, the space device processes the raw payload data that otherwise would be included in the downstream data. Typically, the resulting processed data is significantly smaller in size than the raw payload data. The resulting data from such processing is then transmitted from the space device to the Earth-bound device as the downstream data. 
         [0004]    One way to process raw payload data on a space device employs application-specific integrated circuits (ASICs). Application-specific integrated circuits, while efficient, typically are mission-specific and have limited scalability, upgradeability, and re-configurability. Another way to process raw payload data makes use of anti-fuse field programmable gate arrays (FPGAs). Such an approach typically lowers implementation cost and time. Also, anti-fuse FPGAs typically exhibit a high degree of tolerance to radiation. However, anti-fuse FPGAs are typically not re-programmable (that is, reconfigurable). Consequently, an anti-fuse FPGA that has been configured for one application is not reconfigurable for another application. 
         [0005]    Another way to process such raw payload data makes use of re-programmable FPGAs. However, re-programmable FPGAs are typically susceptible to single event upsets. A single event upset (SEU) occurs when an energetic particle penetrates the FPGA (or supporting) device at high speed and high kinetic energy. For example, the energetic particle can be an ion, electron, or proton resulting from solar radiation or background radiation in space. The energetic particle interacts with electrons in the device. Such interaction can cause the state of a transistor in an FPGA to reverse. That is, the energetic particle causes the state of the transistor to change from a logical “0” to a logical “1” or from a logical “1” to a logical “0.” This is also referred to here as a “bit flip.” The interaction of an energetic particle and electrons in an FPGA device can also introduce a transient current into the device. 
         [0006]    Payload data applications continue to operate with high amounts of communication interference. Current monitoring techniques limit the re-programmable FPGAs from recovering within a minimal recovery time. The recovery time from one or more single event upsets is critical, especially in operating environments susceptible to high amounts of radiation. 
       SUMMARY 
       [0007]    In one embodiment, a reconfigurable computer is provided. The computer includes a controller and at least one reconfigurable processing element communicatively coupled to the controller. The controller is operable to read at least a first portion of a respective configuration of each of the plurality of reconfigurable processing elements and refresh at least a portion of the respective configuration of the reconfigurable processing element if the first portion of the configuration of the reconfigurable processing element has changed since the first portion was last checked. 
     
     
       DRAWINGS 
         [0008]      FIG. 1  is a block diagram of an embodiment of a space payload processing system; 
           [0009]      FIG. 2  is a block diagram of an embodiment of a reconfigurable computer for use in payload processing on a space device; 
           [0010]      FIG. 3  is a block diagram of an embodiment of a configuration interface for a reconfigurable computer; and 
           [0011]      FIG. 4  is a flow diagram illustrating an embodiment of a method for controlling at least two reconfigurable processing elements. 
       
    
    
     DETAILED DESCRIPTION 
       [0012]      FIG. 1  is a block diagram of an embodiment of a space payload processing system  100 , as described in the &#39;888 application. Embodiments of system  100  are suitable for use, for example, in space devices such as satellites and space vehicles. System  100  includes sensor modules  102   1-1  to  102   2-2 . Each of sensor modules  102   1-1  to  102   2-2  is a source of raw payload data that is to be processed by system  100 . It is to be understood, however, that in other embodiments, other sources of raw payload data are used. 
         [0013]    Each of sensor modules  102   1-1  to  102   2-2  comprise sensors  103   1-1  to  103   2-2 . In one embodiment, sensors  103   1-1  to  103   2-2  comprise active and/or passive sensors. Each of sensors  103   1-1  to  103   2-2  generate a signal that is indicative of a physical attribute or condition associated with that sensor  103 . Sensor modules  102   1-1  to  102   2-2  include appropriate support functionality (not shown) that, for example, perform analog-to-digital conversions and drive the input/output interface necessary to supply sensor data to other portions of system  100 . It is noted that for simplicity in description, a total of four sensor modules  102   1-1  to  102   2-2  and four sensors  103   1-1  to  103   2-2  are shown in  FIG. 1 . However, it is understood that in other embodiments of system  100  different numbers of sensor modules  101  and sensors  103  (for example, one or more sensor modules and one or more sensors) are used. 
         [0014]    For example, in one embodiment, each of sensor modules  102   1-1  to  102   2-2  includes an array of optical sensors such as an array of charge coupled device (CCD) sensors or complimentary metal oxide system (CMOS) sensors. In another embodiment, an array of infrared sensors is used. The array of optical sensors, in such an embodiment, generates pixel image data that is used for subsequent image processing in system  100 . In other embodiments, other types of sensors are used. 
         [0015]    The data output by sensor modules  102   1-1  to  102   2-2  comprise raw sensor data that is processed by system  100 . More specifically, the sensor data output by  102   1-1  to  102   2-2  is processed by reconfigurable computers  104   1  to  104   N . For example, in one embodiment where sensor modules  102   1-1  to  102   2-2  output raw image data, reconfigurable computers  104   1  to  104   2  perform one or more image processing operations such as RICE compression, edge detection, or Consultative Committee of Space Data Systems (CCSDS) protocol communications. 
         [0016]    The processed sensor data is then provided to back-end processors  106   1  and  106   2 . Back-end processors  106   1  and  106   2  receive the processed sensor data as input for high-level control and communication processing performed by reconfigurable computers  104   1  and  104   2 . In the embodiment shown in system  100 , back-end processor  106   2  assembles appropriate downstream packets that are transmitted via a communication link  108  to an Earth-bound device  110 . At least a portion of the downstream packets include the processed sensor data (or data derived from the processed sensor data) that was received from reconfigurable computers  104   1  and  104   2 . The communication of payload-related data within and between the various components of system  100  is also referred to here as occurring in the “data path.” It is noted that for simplicity in description, a total of two reconfigurable computers  104   1  and  104   2  and two back-end processors  106   1  and  106   2  are shown in  FIG. 1 . However, it is understood that in other embodiments of system  100  different numbers of reconfigurable computers  104  and back-end processors  106  (for example, one or more reconfigurable computers and one or more back-end processors) are used. 
         [0017]    System  100  also includes system controller  112 . System controller  112  monitors and controls the operation of the various components of system  100 . For example, system controller  112  manages the configuration and reconfiguration of reconfigurable computers  104   1  and  104   2 . System controller  112  is further responsible for control of one or more programmable reconfiguration refresh and readback intervals. Communication of control data within and between the various components of system  100  is also referred to here as occurring in the “control path.” 
         [0018]    Reconfigurable computers  104   1  and  104   2  are capable of being configured and re-configured. For example, reconfigurable computers  104   1  and  104   2  are capable of being configured and re-configured at runtime. That is, processing that is performed by reconfigurable computers  104   1  and  104   2  is changed while the system  100  is deployed (for example, while the system  100  is in space). In one embodiment, each of reconfigurable computers  104   1  and  104   2  is implemented using one or more reconfigurable processing elements. One such embodiment is described in further detail below with respect to  FIG. 2 . 
         [0019]    In one embodiment, re-configurability of reconfigurable computers  104   1  and  104   2  is used to fix problems in, or add additional capabilities to, the processing performed by each of reconfigurable computers  104   1  and  104   2 . For example, while system  100  is deployed, new configuration data for reconfigurable computer  104   1  is communicated from earth-bound device  110  to system  100  over communication link  108 . Reconfigurable computer  104   1  uses the new configuration data to reconfigure reconfigurable computer  104   1  (that is, itself). 
         [0020]    Further, the re-configurability of reconfigurable computers  104   1  and  104   2  allows reconfigurable computers  104   1  and  104   2  to operate in one of multiple processing modes on a time-sharing basis. For example, in one usage scenario, reconfigurable computer  104   2  is configured to operate in a first processing mode during a first portion of each day, and to operate in a second processing mode during a second portion of the same day. In this way, multiple processing modes are implemented with the same reconfigurable computer  104   2  to reduce the amount of resources (for example, cost, power, and space) used to implement such multiple processing modes. 
         [0021]    In system  100 , each of reconfigurable computers  104   1  and  104   2  and each of back-end processors  106   1  and  106   2  are implemented on a separate board. Each of the separate boards communicates control information with one another over control bus  114  such as a Peripheral Component Interconnect (PCI) bus or a compact PCI (cPCI) bus. Control bus  114 , for example, is implemented in backplane  116  that interconnects each of the boards. In the example embodiment of system  100  shown in  FIG. 1 , at least some of the boards communicate with one another over one or more data busses  118  (for example, one or more buses that support the RAPIDIO® interconnect protocol). In such an implementation, sensor modules  102   1-1  to  102   2-2  are implemented on one or more mezzanine boards. Each mezzanine board is connected to a corresponding reconfigurable computer board using an appropriate input/output interface such as the PCI Mezzanine Card (PMC) interface. 
         [0022]      FIG. 2  is a block diagram of an embodiment of a reconfigurable computer  104  for use in payload processing on a space device  200 . The embodiment of reconfigurable computer  104  shown includes reconfigurable processing elements (RPEs)  202   1  and  202   2 , similar to the RPEs described in the &#39;888 application. As similarly noted in the &#39;888 application, embodiments of reconfigurable computer  104  are suitable for use in or with system  100  as described with respect to  FIG. 1  above. It is to be understood that other embodiments and implementations of reconfigurable computer  104  are implemented in other ways (for example, with two or more RPEs  202 ). 
         [0023]    RPEs  202   1  and  202   2  comprise reconfigurable FPGAs  204   1  and  204   2  that are programmed by loading appropriate programming logic (also referred to here as an “FPGA configuration” or “configuration”) as discussed in further detail below. Each RPE  202   1  and  202   2  is configured to perform one or more payload processing operations. Reconfigurable computer  104  also includes input/output (I/O) interfaces  214   1  and  214   2 . Each of the two I/O interfaces  214   1  and  214   2  are coupled to a respective sensor module  102  of  FIG. 1  that receives raw payload data for processing by the reconfigurable processing elements  202 . 
         [0024]    I/O interfaces  214   1  and  214   2  and RPEs  202   1  and  202   2  are coupled to one another with a series of dual-port memory devices  216   1  to  216   6 . This obviates the need to use multi-drop buses (or other interconnect structures) that are more susceptible to one or more SEUs. Each of a first group of dual-port memory devices  216   1  to  216   3  has a first port coupled to I/O interface  214   1 . I/O interface  214   1  uses the first port of each of memory devices  216   1  to  216   3  to read data from and write data to each of memory devices  216   1  to  216   3 . RPE  202   1  is coupled to a second port of each of memory devices  216   1  to  216   3 . RPE  202   1  uses the second port of each of memory devices  216   1  to  216   3  to read data from and write data to each of memory devices  216   1  to  216   3 . Each of a second group of three dual-port memory devices  216   4  to  216   6  has a first port coupled to I/O interface  214   2 . I/O interface  214   2  uses the first port of each of memory devices  216   4  to  216   6  to read data from and write data to each of memory devices  216   4  to  216   6 . RPE  202   2  is coupled to a second port of each of memory devices  216   4  to  216   6 . RPE  202   2  uses the second port of each of memory devices  216   4  to  216   6  to read data from and write data to each of memory devices  216   4  to  216   6 . 
         [0025]    In this example embodiment, I/O interfaces  214   3  and  214   4  are RAPIDIO interfaces. Each of RAPIDIO interfaces  214   3  and  214   4  are coupled to a respective back-end processor  106  of  FIG. 1  over one or more data buses  118  in backplane  116  that supports the RAPIDIO interconnect protocol. Each of RPEs  202   2  to  202   2  is coupled to a respective one of the RAPIDIO interfaces  214   3  and  214   4  in order to communicate with the one or more back-end processors  106  of  FIG. 1 . 
         [0026]    Reconfigurable computer  104  further includes system control interface  208 . System control interface  208  is coupled to each of RPEs  202   2  to  202   2  over configuration bus  218 . System control interface  208  is also coupled to each of I/O interfaces  214   1  and  214   2  over system bus  220 . System control interface  208  provides an interface by which the system controller  112  of  FIG. 1  communicates with (that is, monitors and controls) RPEs  202   2  to  202   2  and one or more I/O devices coupled to I/O interfaces  214   1  and  214   2 . System control interface  208  includes control bus interface  210 . Control bus interface  210  couples system control interface  208  to control bus  114  of  FIG. 1 . System control interface  208  and system controller  112  communicate over control bus  114 . In one implementation, control bus interface  210  comprises a cPCI interface. 
         [0027]    System control interface  208  also includes local controller  212 . Local controller  212  carries out various control operations under the direction of system controller  112  of  FIG. 1 . Local controller  212  performs various FPGA configuration management operations as described in further detail below with respect to  FIG. 3 . The configuration management operations performed by local controller  212  include reading an FPGA configuration from configuration memory  206  and loading the FPGA configuration into each of reconfigurable FPGAs  204   1  and  204   2 . One or more FPGA configurations are stored in configuration memory  206 . In one implementation, configuration memory  206  is implemented using one of a flash random access memory (Flash RAM) and a static random access memory (SRAM). In other embodiments, the one or more FPGA configurations are stored in a different location (for example, in a memory device included in system controller  112 ). The configuration management operations performed by local controller  212  also include SEU mitigation. Examples of SEU mitigation include periodic and/or event-triggered refreshing of the FPGA configuration and/or FPGA configuration readback and compare. In one embodiment, the SEU mitigation described here (and with respect to  FIG. 4  below) is performed by local controller  212  for each of RPEs  202   1  and  2022  that sustain at least one substantial SEU. 
         [0028]    In the example embodiment shown in  FIG. 2 , system control interface  208  and configuration memory  206  are implemented using radiation-hardened components and reconfigurable processing elements  202   1  and  202   2  (including reconfigurable FPGAs  204   1  and  204   2 ), I/O interfaces  214   1  to  214   4 , and dual-port memory devices  216   1  to  216   6  are implemented using commercial off the shelf (COTS) components that are not necessarily radiation hardened. COTS components are less expensive, more flexible, and easier to program. Typically, the processing performed in the data path changes significantly more than the processing performed in the control path from mission-to-mission or application-to-application. Using COTS components allows reconfigurable computer  104  to be implemented more efficiently (in terms of time, cost, power, and/or space) than radiation-hardened components such as non-reconfigurable, anti-fuse FPGAs or ASICs. Moreover, by incorporating SEU mitigation techniques in system control interface  208 , redundancy-based SEU mitigation techniques such as triple modular redundancy are unnecessary. This reduces the amount of resources (for example, time, cost, power, and/or space) needed to implement reconfigurable computer  104  for use in a given space application with COTS components. 
         [0029]      FIG. 3  is a block diagram of an embodiment of a configuration interface  300 , for a reconfigurable computer. Configuration interface  300  comprises local controller  212 , configuration memory  206 , control bus interface  210 , and configuration bus  218 . Configuration memory  206 , control bus interface  210 , and configuration bus  218  were described above with respect to  FIG. 2 . Local controller  212  comprises internal bus controller  302 , RPE CRC generators  306   1  and  306   2 , and RPE interface controllers  308   1  and  308   2 . It is to be understood that other embodiments and implementations of local controller  212  are implemented in other ways (for example, with two or more RPE CRC generators  306  and two or more RPE interface controllers  308 ). Internal bus controller further includes internal arbiter  304 . Internal bus controller  302  is directly coupled to each of RPE CRC generators  306   1  and  306   2  by inter-core interfaces  320   1  and  320   2 , respectively. Inter-core interfaces  320   1  and  320   2  are internal bi-directional communication interfaces. Internal arbiter  304  is directly coupled to each of RPE interface controllers  308   1  and  308   2  by arbiter interfaces  322   1  and  322   2 , respectively. Arbiter interfaces  322   1  and  322   2  are internal bi-directional communication interfaces. Internal arbiter  304  prevents inter-core communications within local controller  212  from occurring concurrently, which may result in an incorrect operation. Each of RPE CRC generators  306   1  and  306   2  is directly coupled to RPE interface controllers  308   1  and  308   2  by CRC interfaces  324   1  and  324   2 , respectively. CRC interfaces  324   1  and  324   2  are internal bi-directional communication interfaces. 
         [0030]    Internal bus controller  302  is coupled to configuration memory  206  (shown in  FIG. 2 ) by configuration memory interface  316 . Configuration memory interface  316  is an inter-component bi-directional communication interface. Internal bus controller  302  is also coupled control bus interface  210  (shown in  FIG. 2 ) by controller logic interface  318 . Controller logic interface  318  is an inter-component bi-directional communication interface. In one implementation, controller logic interface  318  is one of a WISHBONE interface, a cPCI interface, or the like. Each of RPE interface controllers  308   1  and  308   2  are coupled to configuration bus  218  for communication with RPE  202   1  and  202   2  of  FIG. 2 . Each of RPE interface controllers  308   1  and  308   2  further include readback controllers  310   1  and  310   2 , arbiters  312   1  and  312   2 , and configuration controllers  314   1  and  314   2 , respectively, whose operation is further described below. In one implementation, internal arbiter  304  and each of arbiters  312   1  and  312   2  are two-interface, rotational-arbitration state machines. Other implementations are possible. 
         [0031]    In operation, a full or partial set of configuration data for each of RPEs  202   1  to  202   2  is retrieved from configuration memory  206  by internal bus controller  302 . In this example embodiment, system controller  112  (of  FIG. 1 ) determines whether a full or partial set of configuration data is to be analyzed. System control interface  208  is capable of operating at a 50 MHz clock rate (maximum) and will complete one data transfer (for example, a data frame or byte) on every rising edge of the clock during a burst read (readback) or burst write (configuration) operation. In one implementation, local controller  212  operates at a clock rate of 10 MHz. Internal arbiter  304  determines the order in which each RPE interface controllers  308   1  and  308   2  receive the configuration data without causing an interruption in operation of reconfigurable computer  104 . 
         [0032]    Once each of RPE interface controllers  308   1  and  308   2  receive the configuration data, each of readback controllers  310   1  and  310   2  controls a readback operation of the configuration data. For every readback operation of the configuration data, each of RPE CRC generators  306   1  and  306   2  perform a CRC on a full or partial set of the configuration data. The CRC determines if any configuration data bits have changed since a previous readback of the same configuration data (that is, corrupted due to one or more SEUs). In a situation where a readback CRC calculation does not match a stored CRC, local controller  212  enters an auto-reconfiguration mode. In the example embodiment of  FIG. 3 , auto reconfiguration due to a CRC error is a highest priority. Additionally, local controller  212  provides a CRC error count register for gathering of SEU statistics. 
         [0033]    Local controller  212  supports interleaving of readback and reconfiguration (refresh) operations by interleaving priority and order via arbiters  312   1  and  312   2 . Arbiters  312   1  and  312   2  are each responsible for arbitration of the configuration data between RPE CRC generator  306   1  ( 306   2 ) and configuration controller  314   1  ( 314   2 ). Each of configuration controllers  314   1  and  314   2  take in one or more input requests from an internal register file (not shown) and decode which operation to execute. Configuration controller  314   1  ( 314   2 ) identifies a desired operation to be executed and makes a request for the transaction to be performed by supporting logic within local controller  212 . 
         [0034]    Each of configuration controllers  314   1  and  314   2  select an operating mode for multiplexing appropriate data and control signals internally. Once all requested inputs are received, configuration controller  314   1  ( 314   2 ) decides which specific request to execute. Once the specific request is granted, configuration controller  314   1  ( 314   2 ) issues an access request to arbiter  312   1  ( 312   2 ) for access to complete the request. Each request is priority-encoded and implemented in a fair arbitration scheme so no single interface is rejected of a request to access configuration bus  218 . Each of configuration controllers  314   1  and  314   2  provide a set of software instructions for local controller  212  with the capability to interface to configuration bus  218  on a cycle-by-cycle basis. Specifically, upon receipt of the access request, configuration controller  314   1  ( 314   2 ) outputs the configuration data from configuration memory  206  on configuration bus  218 . 
         [0035]    Local controller  212  and control bus interface  210  provide one or more independent configuration buses (for example, RPE interface controllers  308   1  and  308   2 ). In one implementation, RPE interface controllers  308   1  and  308   2  provide simultaneous readback and CRC checking for each of RPE  202   1  and  202   2 . Subsequently, simultaneous readback of one configuration of RPE  202   1  ( 202   2 ) will occur while RPE  202   2  ( 202   1 ) is reconfigured. Further, local controller  212  provides one or more programmable reconfiguration refresh and readback interval rates. Local controller  212  also supports burst read and burst write access. In one implementation, wait states are inserted during back-to-back read/write and write/read operations. Full and partial reconfiguration of RPEs  202   1  and  202   2  occurs within a minimum number of operating cycles and substantially faster than previous (that is, software-based) SEU mitigation operations. 
         [0036]      FIG. 4  is a flow diagram illustrating a method  400  for controlling at least two reconfigurable processing elements. In the example embodiment shown in  FIG. 4 , method  400  is implemented using system  100  and reconfigurable computer  104  of  FIGS. 1 and 2 , respectively. In particular, at least a portion of method  400  is implemented by local controller  212  of system control interface  210 . In other embodiments, however, method  400  is implemented in other ways. 
         [0037]    Once a refresh interval value is established (or adjusted) at block  404 , method  400  begins the process of monitoring the configuration of each available RPE for possible corruption due to an occurrence of a single event upset. A primary function of method  400  is to automatically reconfigure a corrupted configuration of a RPE within a minimum amount of operating cycles. In one implementation, method  400  substantially improves completion time for a full or partial refresh or reconfiguration to maintain operability of the space payload processing application. 
         [0038]    A determination is made about whether the refresh interval rate has changed from a previous or default level (checked in block  406 ). This determination is made in system controller  112  described above with respect to  FIG. 1 . If the refresh interval level has changed, the system controller  112  transfers the refresh interval level to the local controller  212  at block  408 , and proceeds to block  410 . If the refresh interval level has not changed, or the refresh interval level is fixed at a (static) predetermined level, method  400  continues at block  410 . At block  410 , a determination is made about whether the current refresh interval has elapsed. Until the refresh interval elapses, processing associated with block  410  is repeated. 
         [0039]    At block  412 , method  400  begins evaluating the configuration status for a RPE (referred to here as the “current” RPE) by performing a readback operation. In one implementation of such an embodiment, the readback operation is performed by the RPE interface controller  308  for the current RPE. The local controller  212  reads the current configuration of the reconfigurable FPGA for the current RPE and compares at least a portion of the read configuration to a known-good value associated with the current configuration. If the read value does not match the known-good value, the configuration of the current RPE is considered corrupt. In one implementation, such a readback operation is performed by reading each byte (or other unit of data) of the configuration of the FPGA for the current RPE and comparing that byte to a corresponding byte of the corresponding configuration stored in configuration memory  206 . In other words, local controller  212  performs a byte-by-byte compare. In another implementation, one or more CRCs (or other error correction code) values are calculated for the current configuration of the FPGA for the current RPE by a respective RPE CRC generator. 
         [0040]    If the configuration for the current RPE is corrupt (checked in block  414 ), method  400  begins a full or partial reconfiguration (refresh) of the current RPE  202  at block  416 . The determination as to whether to perform a full or partial reconfiguration is made by system controller  112  of  FIG. 1 . If the readback operation performed in block  412  does not reveal corruption of the configuration of the current RPE  202 , method  400  proceeds directly to block  418 . 
         [0041]    At block  418 , method  400  determines whether all available RPEs have been evaluated. If not, method  400  returns to block  412  to evaluate the configuration status for the next available RPE. When all available RPEs have been evaluated, method  400  waits until at least one of the available RPEs is substantially functional (checked in block  422 ) at which time method  400  returns to block  404 . 
         [0042]    In one example of the operation of method  400  in the system  100  of  FIG. 1 , when RPE  202   1  is to be configured (or reconfigured), an appropriate configuration is read from configuration memory  206  and loaded into the reconfigurable FPGA  2041 . Similar operations occur to configure RPE  202   2 . Each of RPE  202   1  and RPE  202   2  is configured, for example, when the reconfigurable computer  104  of  FIG. 2  initially boots after an initial system power on or after a system reset. In some embodiments of reconfigurable computer  104  that support timesharing multiple operating modes, the reconfigurable computer  104  is configured so that each time the operating mode of reconfigurable computer  104  changes, the configuration for the new operating mode is read from configuration memory  206  and loaded into the reconfigurable FPGA for the respective RPEs. Also, in such an example, RPE  202   1  and RPE  2022  are configured to perform, as a part of one or more SEU mitigation operations, a “refresh” operation in which the configuration of the respective reconfigurable FPGA  204   1  and FPGA  204   2  is reloaded.