Fast reconstruction and loading / refreshing system for FPGA (Field Programmable Gate Array) software

Abstract

The invention discloses an FPGA (Field Programmable Gate Array) software rapid reconstruction and loading / refreshing system, which belongs to the technical field of satellites and mainly comprises a storage management board card, a single-machine internal interconnection and a service function board card. Wherein the storage management board card mainly comprises a processor, a plurality of groups of storage particles and a control FPGA (Field Programmable Gate Array), and is mainly used for realizing data uploading receiving, analysis, verification, caching and rapid reconstruction functions of software such as the FPGA, and the plurality of groups of storage particles are used for storing program data of the FPGA. A shared centralized storage architecture is adopted, centralized storage management of multiple FPGA program data is achieved, the total storage capacity of the system is reduced, and the system cost is reduced; a rapid reconstruction method is adopted, the FPGA program reconstruction time of the system is shortened, and the reconstruction efficiency is improved; parallel loading and refreshing of the FPGA are realized, and the refreshing period is shortened; according to the method, the single event upset resistance in the FPGA program running process is effectively improved, and the stability of the on-orbit running function of the FPGA is improved.

Description

Technical Field

[0001] This invention relates to a rapid FPGA software reconfiguration and loading / refresh system, belonging to the field of satellite technology, and is particularly suitable for complex satellite payload devices that contain multiple FPGAs. Background Technology

[0002] As satellite payloads become increasingly complex and integrated, dozens, or even hundreds, of FPGAs are integrated within them, working collaboratively within complex electronic systems. Traditional multi-FPGA software storage management, reconfiguration, and loading schemes have some shortcomings: The storage resources are severely redundant: Each FPGA is independently configured with at least two copies of memory, including the fixed memory and the on-grid memory. FPGAs with the same function need to store the program repeatedly. The storage resource consumption increases linearly with the number of FPGAs, resulting in a waste of hardware costs. The large number of on-grid memories makes the payload products expensive, which does not conform to the development trend of low-cost payload products. Low reconstruction transmission efficiency: External reconstruction data is transmitted to local storage via a link, lacking a parallel scheduling mechanism, which cannot meet the needs of rapid updates of batch FPGA programs; The startup time is lengthy: Using a "chip-by-chip loading" mode with multiple FPGAs results in a total startup time that is N times the time required for a single FPGA (where N is the number of FPGAs), which cannot meet the rapid startup requirements of low-Earth orbit (LEO) satellite payloads after on-orbit power-on. After startup, a refresh operation is required for each FPGA to eliminate the cumulative effects of single-event upsets during FPGA operation. Currently, the refresh uses a "chip-by-chip refresh" mode, resulting in a long total FPGA refresh cycle.

[0003] While existing technologies utilize centralized storage across multiple FPGAs and step-by-step FPGA loading and refresh techniques, they fail to achieve integrated collaboration of "centralized storage sharing - parallel reconstruction and transmission - multi-FPGA parallel loading / refreshing," thus failing to completely resolve the issues of multi-FPGA software storage management, rapid reconstruction, and rapid loading / refreshing solutions. Summary of the Invention

[0004] To address the problems existing in the aforementioned background technology, this invention provides a centralized storage management architecture for FPGA software, which can realize rapid reconstruction of multiple FPGA program data and parallel loading / refreshing of multiple FPGAs. This invention employs a centralized storage management scheme to solve the problems of large storage space requirements and redundant storage resources for multiple FPGAs on multiple boards in complex satellite processing payloads; it adopts a multi-bus memory access method to realize parallel fast read / write of multiple sets of storage particles, solving the problem of rapid software reconstruction in satellite products; and to address the problem of long FPGA loading time during system startup, it adopts a parallel loading and refresh method for FPGAs with the same function, reducing system startup time and shortening the overall system refresh cycle.

[0005] The technical method of this invention is implemented as follows: An FPGA software rapid reconfiguration and loading / refresh system mainly includes a storage management board and a service function board, wherein the main body of the service function board is a service FPGA; The storage management board includes a processor, a storage granular group, and a control FPGA. The processor is used to receive, parse, verify, and cache the software data uploaded to the business FPGA, and to access the storage granules through the control FPGA to perform parallel reconstruction of the business FPGA and realize on-orbit updates of program data. The control FPGA is used to implement the loading and refreshing functions of the business FPGA. The storage granular group is used to store the program data files of the business FPGA. The reconstruction process is as follows: The processor sends the data to be reconstructed to the control FPGA. When the same software program needs to be reconstructed in parallel, the control FPGA distributes it to multiple memory chip groups and writes it to the memory chips at the same time. When multiple software programs need to be reconstructed in parallel, the control FPGA distributes them to the corresponding memory chip groups one by one and writes them to the memory chips one by one in a time-sharing manner. The loading and refreshing process is as follows: The FPGA is controlled to clear the program status of the service FPGAs to be loaded in parallel, and the initialization completion status of the service FPGAs to be loaded is polled. After all service FPGAs have completed initialization, the service FPGAs are distinguished according to their functions, and the service FPGAs with the same function are loaded in parallel. After the service FPGAs have completed loading, the FPGA is controlled to refresh the service FPGAs with the same function in parallel, and the refresh operation of service FPGAs in different functional groups is completed in sequence.

[0006] Furthermore, the storage management board and the service function board are interconnected through a backplane. The interconnection of load / refresh control information is implemented using the Slave SelectMap bus, which enables the loading and refresh functions of multiple FPGAs. In the storage management board, the processor, multiple memory chip groups and the control FPGA are all connected through the BPI bus.

[0007] Furthermore, the software programs of the business FPGAs are classified, and the number of business FPGA software types is counted as M. The storage space of the storage granular group is divided into M spaces, which store the M types of software programs of the business FPGAs respectively.

[0008] Furthermore, during the reconfiguration process, the processor receives the software data to be reconfigured, parses and verifies the received software data, caches it in memory, parses and reads the memory location information of the business FPGA software to be reconfigured, receives remote control commands, and determines the type of reconfiguration method to be used. When reconstructing the same software program in parallel, the FPGA is controlled to send erase commands to the corresponding business FPGA software storage location areas of the storage particle group. The FPGA simultaneously distributes erase commands to multiple storage particle groups for N groups of memory. After all the memory areas to be reconstructed have completed the fixed storage space erase operation, programming commands are sent to the N groups of memory particles simultaneously through the BPI bus. The data to be reconstructed is sent to multiple groups of memory particles byte by byte. The programming completion flag of each memory is read one by one, and it is determined whether the waiting timeout has occurred. If the timeout occurs, the waiting ends, and the specific location of the memory particle that timed out is marked. The word-by-word reconstruction of all the software data to be reconstructed is completed. When the software data reconstruction is completed, the data of the N groups of memory particles is read one by one and verified. The verification result is returned to the ground through the telemetry channel, completing this software reconstruction process. When reconstructing multiple software programs in parallel, the processor receives multiple software data to be reconstructed sequentially, parses and verifies the received data, caches it in different memory regions, parses and interprets multiple specific location information of the memory of multiple business FPGA software programs to be reconstructed, receives remote control commands, determines the reconstruction method type, controls the FPGA to send erase commands to the memory locations of multiple business FPGA software corresponding to the memory particle groups, controls the FPGA to distribute erase commands to multiple memory particle groups sequentially for N memory groups, waits for all memory regions to be reconstructed to complete the fixed memory space erase operation, sends programming commands to the N memory particles sequentially through the BPI bus, sends the data to be reconstructed to multiple memory particles byte by byte, reads the programming completion flag of each memory sequentially, and determines whether the wait has timed out. If the timeout occurs, the processor ends the wait and marks the specific location of the timeout waiting memory particle, completing the word-by-word reconstruction of all cached data. When the software data reconstruction is complete, the processor reads the data from the N memory particles sequentially and verifies it. The verification result is returned to the ground through the telemetry channel, completing this parallel reconstruction process of multiple software programs.

[0009] Furthermore, each business FPGA front end has an isolation interface circuit connected to it.

[0010] Compared with the prior art, the advantages of the present invention are as follows: 1. This invention adopts a centralized shared storage scheme to realize the centralized storage of multiple service FPGA program data on multiple service boards, which solves the problems of large storage capacity requirements and redundant storage resources for multiple service FPGAs on multiple different boards in complex satellite processing. 2. This invention employs a multi-bus approach to access the memory, enabling a parallel, fast read / write method for multiple memory chips, thus solving the problem of rapid reconfiguration. 3. For service FPGAs with the same function, this invention adopts a parallel loading / refreshing method to reduce system startup time, shorten the overall refresh cycle, effectively improve the anti-single-event upset capability during the operation of service FPGA programs, and increase the on-orbit stability of service FPGAs. Attached Figure Description

[0011] Figure 1 FPGA software rapid reconfiguration and loading / refresh system composition diagram.

[0012] Figure 2 The composition diagram of the first method of rapid reconstruction.

[0013] Figure 3 Parallelism refactors the flowchart of the same software program.

[0014] Figure 4 A diagram showing the composition of the shared BPI bus in the specific rapid reconfiguration method one.

[0015] Figure 5 Parallelism is used to refactor the flowcharts of multiple software programs.

[0016] Figure 6 A diagram illustrating the components for implementing parallel loading / refreshing functionality across multiple business FPGAs.

[0017] Figure 7 Flowchart for implementing parallel loading / refresh functionality across multiple service FPGAs. Detailed Implementation

[0018] The following is combined Figure 1 , Figure 2 , Figure 3 , Figure 4 , Figure 5 , Figure 6 , Figure 7 The present invention will be described in detail below.

[0019] Reference Figure 1This invention relates to a rapid FPGA software reconfiguration and loading / refreshing system. The system primarily consists of a storage management board 1, a standalone internal interconnect 2, and a service function board 3. The storage management board 1 mainly includes a processor, a storage chip group, and a control FPGA. The processor handles the uploading, receiving, parsing, verification, and caching of software data from the service FPGA, and accesses the storage chips via the FPGA using the BPI bus. The control FPGA is typically implemented using an antifuse FPGA or a Flash FPGA. As a co-controller of the processor, the control FPGA primarily performs control and management functions, including remote control command parsing, telemetry information framing and feedback processing, BPI bus data processing, and loading / refreshing functions. The storage chip group comprises a fixed version memory and an uploaded version memory, used to store the service FPGA software program. The number of uploaded memories is no less than two, and the memory type is BPI interface Nor Flash memory.

[0020] Internal interconnection within a single-machine system is typically implemented using a backplane to interconnect information between various boards within the system, including service information and load / refresh control information. Load / refresh control information interconnection is achieved using a Slave SelectMap bus. Multiple service FPGAs share the Slave SelectMap bus for loading and refreshing, reducing the number of signal lines on the backplane and simplifying implementation. Secondly, considering the limited number of pins on the service FPGA, it is not advisable to use separate SelectMap buses for each FPGA when using multiple FPGAs; instead, a shared Slave SelectMap bus significantly reduces the complexity of backplane implementation.

[0021] The business function board 3 mainly includes business FPGAs, which implement different business functions. They come in different forms, and the number of boards varies. Each board does not contain a business FPGA program storage chip. The loading / refresh function is implemented by centralized storage. An isolation interface circuit is added in front of each business FPGA that needs to be loaded to achieve signal isolation.

[0022] The existing single-machine system reconfiguration method is as follows: external reconfiguration data is transmitted to the local machine for caching via a link. After receiving the data, the processor performs a series of calculations and processes, and caches it in the local processor's CPU memory. The reconfiguration data is written byte by byte to the separate memory to be reconfigured, either directly or indirectly through the CPU bus via the FPGA. Only one memory is reconfigured at a time. Under this reconfiguration method, the reconfiguration rate is about 1.5MB / minute, which is inefficient. Especially when facing a large number of low-Earth orbit internet satellites and large-scale updates of on-orbit FPGA programs, rapid software upgrades are required, which cannot meet the needs of rapid updates of batch FPGA programs.

[0023] Reference Figure 2 The specific rapid reconfiguration diagram shows that multiple memory chip groups are connected to the business FPGA through multiple sets of signal lines, and are independent of each other, which facilitates simultaneous access to memory chips. The chip groups at the top position can use low-level devices, such as COTS memory devices, to reduce product costs. When using COTS memory devices, in order to improve reliability, multiple copies of the program can be stored in the memory to achieve triple redundancy. At this time, in order to improve the program reconfiguration speed, the data bit width needs to be expanded, and the data bit width becomes three times that of a single memory chip.

[0024] The rapid reconfiguration of business FPGA software is achieved as follows: The program software of the internal business FPGA of a single machine is classified and the number of business FPGA software types is counted as M. The storage space of the storage particle group is divided into M spaces, which store the M software programs of the business FPGA respectively. The space division of the upper position storage particle group and the fixed position memory group is carried out in the same way.

[0025] Furthermore, different types of rapid refactoring methods can be selected based on remote control commands. There are two types of refactoring methods: one is to refactor the same software program in parallel, and the other is to refactor multiple different software programs in parallel.

[0026] The first reconstruction scenario is described below. This reconstruction method allows simultaneous read and write access to multiple memory groups, writing the single piece of software data to be reconstructed byte by byte into the multiple memories being reconstructed. The processor sends the data to be reconstructed to the control FPGA via the BPI bus. The control FPGA internally distributes the data to multiple memory groups simultaneously, and multiple independent BPI buses write the data to the memory groups at the same time.

[0027] Reference Figure 3The detailed and rapid refactoring process implements the basic workflow. During refactoring, the processor receives the software data to be refactored, parses and verifies the received data, caches it in memory, parses and reads the memory location information of the business FPGA software to be refactored, receives remote control commands, determines the type of refactoring method to be used, and adopts rapid refactoring method one, which is to refactor the same software program in parallel. By controlling the FPGA to send erase commands to the corresponding business FPGA software storage location area of ​​the storage particle group, the FPGA simultaneously distributes erase commands to multiple storage particle groups for N groups of memories. After all the memory areas to be refactored have completed the fixed storage space erase operation, programming commands are sent to the N groups of memory particles simultaneously through the BPI bus. The data to be refactored is sent to multiple groups of memory particles in words (16 bits). The programming completion flag of each memory is read one by one, and it is determined whether the waiting timeout has occurred. If the timeout occurs, the waiting ends, and the specific location of the timeout storage particle is marked. Following the above process, the word-by-word reconstruction of all the software data to be refactored is completed. When the software data reconstruction is completed, the data of the N groups of memory particles is read one by one and verified. The verification result is returned to the ground through the telemetry channel, completing this software refactoring process.

[0028] Based on the characteristics of memory chips, the word programming time is approximately t = 100µs (microseconds), and the word read time is approximately 0.2µs (microseconds). When refactoring software, the read time is negligible compared to the memory programming time. For example, to complete the software program memory refactoring process of an SRAM-type FPGA (model V7-690T, software program size approximately 224Mb), the calculated time required to refactor the FPGA program is approximately 1400s (seconds). The calculation process is as follows: 224Mb / 16 = 14M words, 14M words * 100µs / word = 1400s. Using the general refactoring method, refactoring files in multiple memory locations on a single V7-690T FPGA takes a total of 1400s * N, where N represents the number of programs to be refactored. Using the fast refactoring method, the total refactoring time is theoretically reduced to approximately 1400s, shortening it to [a fraction of the original refactoring time]. .

[0029] refer to Figure 4 Another manifestation of this type of fast reconfiguration method is the shared BPI bus. The memory chip groups use the same BPI bus, achieving bus sharing. Only the memory chip select differs, allowing for the use of the same fast reconfiguration method. The advantage of this type of reconfiguration method is that it can significantly reduce the number of pins on the FPGA for control and management. However, it lacks flexibility in implementation and its reliability is reduced. A failure in any memory chip on the BPI bus may cause a BPI bus failure, affecting access to other memory chip groups. The implementation process is consistent with the aforementioned method.

[0030] The second reconstruction method, namely parallel reconstruction of multiple software programs, is described below. This method enables the parallel reconstruction of multiple different software data. It allows simultaneous read and write access to multiple sets of memory chips, writing multiple sets of software data to be reconstructed byte by byte into the multiple reconstructed memories. The processor receives multiple sets of software data to be reconstructed, parses, verifies, and caches them in memory. Different storage regions are planned for different software to be reconstructed, allowing different software data to be stored in different regions. The processor sends the data to be reconstructed to the control FPGA via the BPI bus. The control FPGA distributes the data sequentially to the memory chip groups in the reconstructed regions, and multiple independent BPI buses write the data to the memory chips in a time-division multiplexing manner. Compared to the memory word programming time cycle of approximately t: 100µs (microseconds), the time to send data into the memory (due to device characteristics, the maximum time is approximately 1µs (microseconds)), and the memory internal data read time cycle of approximately 0.2µs (microseconds), are essentially negligible.

[0031] Reference Figure 5 This process enables the parallel reconstruction of multiple software programs. The processor sequentially receives multiple software data to be reconstructed, parses and verifies the received data, caches it in different memory regions, parses and interprets multiple specific location information of the multiple FPGA software memory to be reconstructed, receives remote control commands, determines the reconstruction method type, and selects fast reconstruction method 2, i.e., parallel reconstruction of multiple different programs. The FPGA is controlled to send erase commands to multiple FPGA software memory location regions corresponding to the memory particle groups. Note that multiple memory location regions cannot be located within the same memory device; otherwise, parallel reconstruction of multiple different programs is not supported. The FPGA sequentially distributes erase commands to multiple memory particle groups for N memory groups, waits for all memory regions to be reconstructed to complete the fixed memory space erase operation, and sends programming commands to the N memory particles sequentially via the BPI bus, sending the data to be reconstructed to multiple memory particles in words (16 bits). The processor sequentially reads the programming completion flag of each memory and determines whether a timeout has occurred. If a timeout occurs, the processor ends the wait and marks the specific location of the timeout memory particle. Following the above process, the word-by-word reconstruction of all cached data is completed. When the software data reconstruction is complete, the data of N sets of memory chips is read one by one and verified. The verification results are returned to the ground through the telemetry channel, thus completing this parallel reconstruction process of multiple software.

[0032] The SRAM-type FPGA functions requiring loading / refreshing in the aforementioned business function board 3 utilize the SlaveSelectMap bus to implement the loading / refreshing function. Multiple FPGAs share the SlaveSelectMap bus for loading and refreshing. (Refer to...) Figure 6 This diagram illustrates the components that enable parallel loading / refreshing of multiple FPGAs.

[0033] The SelectMap bus signal definitions mainly include: Data[0:15], INIT_B, RDWR, DONE, CLK, PROGRAM, DIR, and CS[0:Z]. DIR controls the transmission direction of the isolation interface circuit, primarily for controlling the Data[0:15] direction. When reading back the FPGA program, it needs to be used in conjunction with the RDWR signal to control the Data[0:15] direction in the isolation interface circuit. The number of CS[0:Z] signals is the same as the number of FPGAs, used to select a specific FPGA for loading / refreshing.

[0034] The loading and refreshing circuits of the service FPGAs are designed, and an isolation interface circuit is added in front of each service FPGA that needs to be loaded. The purposes are as follows: first, to achieve fault isolation of the service FPGA and avoid the failure of the SelectMap bus function caused by the failure of the service FPGA; second, to improve signal quality by placing the isolation interface circuit close to the edge of the board and avoid signal integrity problems caused by connecting multiple service FPGAs; third, to reduce the number of pins used by the control FPGA, so as to increase the number of service FPGAs to be loaded / refreshed; and fourth, to achieve level matching between the signals of the control FPGA and the service FPGA.

[0035] The number of FPGAs on the business function boards is Z. These FPGAs are categorized by their functions. FPGAs with the same function store a shared program data and perform loading and refreshing operations simultaneously using the same program data. If a single business FPGA implements N functions, and the loading and refreshing time for a single business FPGA is t, theoretically, the total loading / refresh time for Z business FPGAs sequentially is Z*t. ​​After adopting parallel loading / refresh, the total FPGA loading / refresh time is reduced to N*t, shortening it to a fraction of the original sequential loading / refresh cycle. .

[0036] refer to Figure 7 This document describes the flowchart for implementing parallel loading / refreshing of multiple service FPGAs. Upon power-up, for all SRAM-type FPGAs to be loaded, the control FPGA simultaneously clears its program status and polls the initialization status of the service FPGAs. Once all service FPGAs have completed initialization, the loading operation begins. Service FPGAs are differentiated according to their functions, and parallel loading is implemented for FPGAs with the same function. After the program data is loaded, the CS signal is used to select service FPGAs sequentially, and the FPGAs return a "Done" signal, waiting for the service FPGA to complete its program startup. A timeout occurs, and the location of the timed-out service FPGA is marked.

[0037] After all service FPGAs have finished loading, the FPGA is controlled to start a refresh operation. During the refresh process, the program status of the service FPGAs is not read back. The refresh operation also adopts a parallel refresh operation. Service FPGAs are distinguished according to their functions, and service FPGAs with the same function are refreshed in parallel. The refresh operation of service FPGAs with different functions is completed in sequence. After the refresh is completed, the refresh operation is started again.

Claims

1. A rapid software reconfiguration and loading / refreshing system for FPGAs, characterized in that, It mainly includes a storage management board (1) and a business function board (3), of which the main body of the business function board (3) is a business FPGA; The storage management board (1) includes a processor, a storage particle group, and a control FPGA; the processor is used to receive, parse, verify, and cache the software data uploaded to the business FPGA, and to access the storage particles through the control FPGA, perform parallel reconstruction of the business FPGA, and realize on-orbit updates of program data; the control FPGA is used to implement the loading and refreshing functions of the business FPGA; the storage particle group is used to store the program data files of the business FPGA. The reconstruction process is as follows: The processor sends the data to be reconstructed to the control FPGA. When the same software program needs to be reconstructed in parallel, the control FPGA distributes it to multiple memory chip groups and writes it to the memory chips at the same time. When multiple software programs need to be reconstructed in parallel, the control FPGA distributes them to the corresponding memory chip groups one by one and writes them to the memory chips one by one in a time-sharing manner. The loading and refreshing process is as follows: The FPGA is controlled to clear the program status of the service FPGAs to be loaded in parallel, and the initialization completion status of the service FPGAs to be loaded is polled. After all service FPGAs have completed initialization, the service FPGAs are distinguished according to their functions, and the service FPGAs with the same function are loaded in parallel. After the service FPGAs have completed loading, the FPGA is controlled to refresh the service FPGAs with the same function in parallel, and the refresh operation of service FPGAs in different functional groups is completed in sequence.

2. The FPGA software rapid reconfiguration and loading / refresh system according to claim 1, characterized in that, The storage management board (1) and the service function board (3) are interconnected through the backplane. The interconnection of loading / refreshing control information is implemented by the Slave SelectMap bus, which realizes the loading and refreshing functions of multiple FPGAs. In the storage management board (1), the processor, multiple storage particle groups and the control FPGA are all connected through the BPI bus.

3. The FPGA software rapid reconfiguration and loading / refresh system according to claim 1, characterized in that, The software programs of the business FPGAs are classified, and the number of types of business FPGA software is counted as M. The storage space of the storage granular group is divided into M spaces, which store the M types of software programs of the business FPGAs respectively.

4. The FPGA software rapid reconfiguration and loading / refresh system according to claim 1, characterized in that, During the refactoring process, the processor receives the software data to be refactored, parses and verifies the received software data, caches it in memory, parses and reads the memory location information of the business FPGA software to be refactored, receives remote control commands, and determines the type of refactoring method to be used. When reconstructing the same software program in parallel, the FPGA is controlled to send erase commands to the corresponding business FPGA software storage location areas of the storage particle group. The FPGA simultaneously distributes erase commands to multiple storage particle groups for N groups of memory. After all the memory areas to be reconstructed have completed the fixed storage space erase operation, programming commands are sent to the N groups of memory particles simultaneously through the BPI bus. The data to be reconstructed is sent to multiple groups of memory particles byte by byte. The programming completion flag of each memory is read one by one, and it is determined whether the waiting timeout has occurred. If the timeout occurs, the waiting ends, and the specific location of the memory particle that timed out is marked. The word-by-word reconstruction of all the software data to be reconstructed is completed. When the software data reconstruction is completed, the data of the N groups of memory particles is read one by one and verified. The verification result is returned to the ground through the telemetry channel, completing this software reconstruction process. When reconstructing multiple software programs in parallel, the processor receives multiple software data to be reconstructed sequentially, parses and verifies the received data, caches it in different memory regions, parses and interprets multiple specific location information of the memory of multiple business FPGA software programs to be reconstructed, receives remote control commands, determines the reconstruction method type, controls the FPGA to send erase commands to the memory locations of multiple business FPGA software corresponding to the memory particle groups, controls the FPGA to distribute erase commands to multiple memory particle groups sequentially for N memory groups, waits for all memory regions to be reconstructed to complete the fixed memory space erase operation, sends programming commands to the N memory particles sequentially through the BPI bus, sends the data to be reconstructed to multiple memory particles byte by byte, reads the programming completion flag of each memory sequentially, and determines whether the wait has timed out. If the timeout occurs, the processor ends the wait and marks the specific location of the timeout waiting memory particle, completing the word-by-word reconstruction of all cached data. When the software data reconstruction is complete, the processor reads the data from the N memory particles sequentially and verifies it. The verification result is returned to the ground through the telemetry channel, completing this parallel reconstruction process of multiple software programs.

5. The FPGA software rapid reconfiguration and loading / refresh system according to claim 1, characterized in that, Each business FPGA front end has an isolation interface circuit connected to it.

Images