A method for resisting single event upsets in an FPGA program online upgrade process

Abstract

The present application relates to a kind of methods of resisting single event upset in FPGA program online upgrading process, belong to online upgrading field.The method of the present application includes: starting online upgrading: MCU receives online upgrading instruction, starts online upgrading program;The lower half area of FPGA external program memory is set as upgrade partition;FPGA loads partition as upper half area;Upgrade lower half area program;After lower half area program upgrading is completed, switch upgrade and load partition;The upper half area of FPGA external program memory is set as upgrade partition;FPGA default load partition changes to lower half area;Upgrade upper half area program;Complete online upgrading.The present application is stored redundantly to FPGA program and is upgraded by partition, cooperate with the flexible switching strategy of hardware dial switch, MCU, hardware two alternative circuit composition, so that upgrade area and load area are separated, completely eliminate the problem that FPGA cannot normally work due to incomplete update during FPGA program online upgrading process.

Description

Technical Field

[0001] This invention belongs to the field of online upgrades, and specifically relates to a method for resisting single-event upsets during online FPGA program upgrades. Background Technology

[0002] With the development of information technology, FPGAs are capable of increasingly diverse functions and applications. In applications requiring high algorithm flexibility or periodic algorithm changes, it is necessary to upgrade or modify the FPGA program periodically. For applications that are inaccessible or unattended, remote online upgrades are also required.

[0003] Most mainstream FPGA chips have remote program loading interfaces. Remote FPGA upgrades primarily involve reloading the program from the FPGA's external program memory using an external processor. However, since the external program memory itself is located outside the FPGA, a SEU (Search Engine Unit) failure during the upgrade process can easily lead to incomplete or incorrect FPGA program updates, FPGA chip failure to boot, and sometimes even device failure. The main reason for potential failures during remote upgrades is that the new program may not be fully loaded after the original program has been completely or partially erased.

[0004] A common solution to this problem is to set a portion of the external program memory (usually the lower address area) as the program boot area (or boot image, etc.) (see patent CN112148341B). After the FPGA powers on, it first enters the program boot area and then, based on the pointer in the program boot area, enters the designated algorithm program area (working image). During online upgrades, only the program in the algorithm program area is refreshed. Because the program boot area remains unchanged, even if the online upgrade of the algorithm program area fails, the program will not fail to start.

[0005] While these methods address the issue of FPGA startup failures due to online program upgrades and provide remedial measures, they cannot fundamentally solve the problem of forced interruption of normal functions during online upgrade failures. Furthermore, if the reliability of the FPGA's storage devices is low, the boot sector program is also susceptible to single-event upsets (SEUs). Applications with high reliability and security requirements typically cannot tolerate prolonged forced interruptions of normal functions caused by such issues.

[0006] Therefore, there is an urgent need for a reliable method for online FPGA program upgrades that also considers single-event upset resistance at the system level. This invention was developed to meet this practical need. Summary of the Invention

[0007] (a) Technical problems to be solved

[0008] The technical problem to be solved by this invention is how to provide a method to resist single-event upsets (SEUs) during online FPGA program upgrades, so as to solve the problem that normal functions are forced to be interrupted when online upgrade failures occur and that the boot sector program is also affected by single-event upsets (SEUs).

[0009] (II) Technical Solution

[0010] To address the aforementioned technical problems, this invention proposes a method for resisting single-event upsets during online FPGA program upgrades. This method includes the following steps:

[0011] S1. Start Online Upgrade: The MCU receives the online upgrade command and starts the online upgrade program;

[0012] S2. Set the lower half of the FPGA external program memory as the upgrade partition; set the FPGA loading partition as the upper half.

[0013] S3. Upgrade the lower half of the program; The MCU receives and caches the FPGA program file sent by the remote server, and erases and updates the program stored in the lower half of the external program memory through the FPGA; Since the FPGA's default loading partition is still the upper half, if the update fails, report the fault and upgrade again. This will not affect the normal loading of the FPGA program from the upper half.

[0014] S4. After the lower half of the program upgrade is completed, switch the upgrade and loading partitions; set the upper half of the FPGA external program memory as the upgrade partition; change the FPGA default loading partition to the lower half.

[0015] S5. Upgrade the upper half-zone program; at this time, the lower half-zone program has completed the online upgrade. If the update is interrupted or fails due to SEU during the communication process or at the device terminal, load the latest FPGA program from the lower half-zone.

[0016] S6. Complete online upgrade; After both upper and lower halves have completed the online upgrade, close the FPGA program online upgrade channel and restore the FPGA program's default loading partition settings.

[0017] (III) Beneficial Effects

[0018] This invention proposes a method to resist single-event upsets during online FPGA program upgrades. By redundantly storing and partitioning the FPGA program for upgrades, and combining this with a flexible switching strategy consisting of hardware DIP switches, an MCU, and a hardware two-to-one selector circuit, the upgrade area and the loading area are separated, completely eliminating the problem of FPGA malfunction due to incomplete updates during online FPGA program upgrades. Attached Figure Description

[0019] Figure 1 This is a system hardware architecture diagram of the present invention;

[0020] Figure 2 This is a flowchart of the online upgrade process of the present invention. Detailed Implementation

[0021] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0022] This invention pertains to high-reliability FPGA design technology in the fields of aviation, aerospace and nuclear energy, and relates to a method for resisting single-event upsets (SEUs) during online FPGA program upgrades.

[0023] This invention discloses a method to resist single-event upsets (SEUs) during online program upgrades of FPGAs (Programmable Gate Arrays). By partitioning the FPGA program for storage, alternating updates, integrity verification, fault retransmission, and multi-path switching, reliable online program upgrades and SEU resistance are achieved. The method includes: (1) dividing the FPGA external program memory into two equal partitions. Two identical FPGA programs are placed in the upper and lower partitions of the external program memory, respectively; (2) flexibly switching the storage partitions of the FPGA external memory in various ways to separate the upgrade area and the loading area; (3) when the MCU (Microcontroller Unit) performs an online upgrade of the FPGA program, the upper partition is first used as the FPGA program loading partition, and the lower partition is upgraded; after the lower partition program is successfully updated, the lower partition is used as the FPGA program loading partition, and the upper partition is upgraded. After each upgrade, the program's correctness and integrity are verified. If the upgrade fails, it can be performed again without affecting the FPGA program loading.

[0024] To maximize system reliability and ensure uninterrupted functionality during online upgrades, this invention proposes dividing the FPGA external program memory into two equal halves. Two identical FPGA programs and their corresponding checksums are placed in the upper and lower halves of the external program memory, respectively. By flexibly switching the FPGA external memory partitions in various ways, program redundancy is achieved, thereby mitigating single-event upsets (SEUs) caused by harsh external environments or storage device quality issues during online upgrades.

[0025] The principle of this invention is based on the low probability and sporadic nature of single-event upsets (SEORs). If an SEOR occurs during an online FPGA program upgrade, the FPGA program can first use the program from another partition, and then perform an online upgrade to repair the faulty partition.

[0026] The specific steps of this invention include:

[0027] S1. Start Online Upgrade: The MCU receives the online upgrade command and starts the online upgrade program.

[0028] S2. Set the lower half of the FPGA external program memory as the upgrade partition. The FPGA loading partition remains unchanged as the upper half.

[0029] S3. Upgrade the lower half of the program. The MCU receives and caches the FPGA program file sent from the remote server, and erases and updates the program stored in the lower half of the external program memory through the FPGA. Since the FPGA's default loading partition remains unchanged as the upper half, if the update fails, a fault is reported, and the upgrade can be performed again. This does not affect the normal loading of the FPGA program from the upper half.

[0030] S4. After the lower half of the program upgrade is complete, switch the upgrade and load partitions. Set the upper half of the FPGA external program memory as the upgrade partition. Change the FPGA's default load partition to the lower half.

[0031] S5. Upgrade the upper half of the program. The method for upgrading the upper half is the same as step S3. Since the lower half of the program has already been upgraded online, if the update is interrupted or fails due to a SEU during the communication process or on the device terminal, the latest FPGA program can be loaded from the lower half.

[0032] S6. Complete online upgrade. After both the upper and lower partitions have completed the online upgrade, close the FPGA program online upgrade channel and restore the FPGA program's default loading partition settings.

[0033] Example 1:

[0034] To facilitate understanding of the technical solutions of the present invention by those skilled in the art, the technical solutions of the present invention will now be further described in conjunction with the accompanying drawings. It should be understood that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the invention.

[0035] (1) Hardware Architecture. The MCU connects to a remote server to receive FPGA programs and control the upper and lower halves of the FPGA's external program memory. A data bus is also configured between the FPGA and the MCU for transferring FPGA program files. See [link to documentation]. Figure 1 The hardware architecture diagram is shown below. The FPGA is connected to the external program memory via an address bus and a data bus. The highest bit of the address bus is isolated and controlled by the MCU and a hardware DIP switch. The "software / hardware control switch" key of the hardware DIP switch controls the hardware two-way selector circuit. When the "software / hardware control switch" key is 1, the highest bit of the address bus is controlled by the MCU; when the "software / hardware control switch" key is 0, the highest bit of the address bus is controlled by the hardware DIP switch.

[0036] In specific implementation, taking an external program memory capacity of 16Mb as an example, the original address bus width between the FPGA and the FPGA external program memory was 24 bits, namely addr[0] to addr

[23] . The highest bit of the address bus, addr

[23] , was separated and adjusted to be controlled by the external MCU and the hardware DIP switch. The "software / hardware control switch" key of the hardware DIP switch controls the hardware two-way circuit. When the "software / hardware control switch" key is 1, addr

[23] is controlled by the MCU. When the "software / hardware control switch" key is 0, addr

[23] is controlled by the hardware DIP switch. In this way, the FPGA external program memory is divided into two equal areas, upper and lower. The remaining address lines (addr[0] to addr

[22] ) are still connected to the FPGA and the FPGA external program memory. When the FPGA loads the program from the FPGA external program memory, there is no need to consider the partitioning of the external program memory. When the most significant bit of the address bus, addr

[23] , is 0, its addressable address space is the lower 8Mb (i.e., 0x7fffff to 0x000000); when the most significant bit of the address bus, addr

[23] , is 1, its addressable address space is the upper 8Mb (i.e., 0xffffff to 0x800000). Two identical FPGA programs are placed in the upper and lower halves of the external program memory, respectively. The following description, along with the accompanying drawings, details the specific online upgrade steps.

[0037] (2) Start online upgrade. The MCU receives the online upgrade command from the remote server and starts the online upgrade program.

[0038] In practice, the MCU receives and parses instructions from the remote server in real time. If the received instruction is an online upgrade command for the FPGA program, the subsequent online upgrade program is initiated.

[0039] (3) Control upgrade and load partition. Switch the partition via MCU or hardware DIP switch to change the default access memory area between the FPGA external program memory and the FPGA from the upper half to the lower half. The FPGA default load partition remains unchanged as the upper half.

[0040] In practice, there are two switching methods:

[0041] 1. MCU switching. The "software / hardware control switching" key of the hardware DIP switch controls the hardware two-to-one circuit, so that the corresponding control pin of the MCU is directly connected to the highest bit (addr

[23] ) of the address bus of the FPGA external program memory. At this time, the MCU can control the highest bit (addr

[23] ) level of the address bus when the FPGA is working normally to change from 1 to 0.

[0042] 2. Hardware Switching. The "Software / Hardware Control Switch" key of the hardware DIP switch controls the hardware two-way selector circuit, making the "Hardware Partition Control" key of the hardware DIP switch directly connected to the highest bit (addr

[23] ) of the FPGA external program memory address bus. By toggling the "Hardware Partition Control" key of the hardware DIP switch, the default level of the highest bit (addr

[23] ) of the address bus when the FPGA is working normally is changed from 1 to 0. The default loading partition setting of the FPGA inside the MCU remains unchanged as the upper half.

[0043] (4) Upgrade the lower half of the program. The MCU receives and caches the FPGA program file sent by the remote server, and erases and upgrades the program stored in the lower half of the external program memory through the FPGA. Since the default loading partition of the FPGA is still the upper half at this time, if the lower half update fails due to the communication process or the SEU of the device terminal, it will not affect the normal loading of the FPGA program.

[0044] In practice, firstly, the MCU sends a program request command to the remote server. The remote server then issues an updated FPGA program, which the MCU caches locally. Next, the MCU sends a bus access request to the FPGA, directly accessing the FPGA's external program memory via the bus data path provided by the FPGA. After gaining access, the MCU first erases all original programs located in the lower half of the FPGA's external program memory. Then, it writes the new program cached inside the MCU and its corresponding checksum to the corresponding location in the lower half. Finally, it reads back the newly written program and verifies it against the locally stored checksum. If the verification is successful, it reports a successful lower half program upgrade; if the verification fails, it reports an upgrade failure to the remote server, terminates the upgrade, and requests a re-upgrade. Since the FPGA's default program loading partition remains the upper half when the lower half program upgrade fails (i.e., when loading the program, the FPGA reads the program from the upper half of the FPGA's external program memory), a failure to update the lower half due to a SEU (Search Engine Unlocked) during communication or at the device terminal does not affect the normal loading of the FPGA program from the upper half.

[0045] (5) Switch upgrade and load partition. Switch the default direct-connect memory area between the FPGA external program memory and the FPGA from the lower half back to the upper half via the MCU or hardware DIP switch. At the same time, set the default FPGA program load partition to the lower half.

[0046] In specific implementation, first determine whether the lower half of the program upgrade is complete. If it is complete, start the second memory partition switching operation. Switch the partition enable by MCU or hardware DIP switch, and switch the default access memory area between the FPGA external program memory and the FPGA from the lower half to the upper half. That is, change the level of the highest bit (addr

[23] ) of the FPGA external program memory address bus from 0 to 1. At this time, the default loading partition of the FPGA program is set to the lower half inside the MCU.

[0047] (6) Upgrade the upper half of the program. The MCU receives and caches the FPGA program file sent by the remote server, and erases and upgrades the program stored in the upper half of the external program memory through the FPGA. Since the default loading partition of the FPGA is the lower half at this time, and the program in the lower half has been upgraded online, if the upper half update is interrupted or fails due to communication or equipment reasons, the latest FPGA program can be loaded from the lower half.

[0048] In practice, firstly, the MCU sends a program request command to the remote server. The remote server then issues an updated FPGA program, which the MCU caches locally. Next, the MCU sends a bus access request to the FPGA, directly accessing the FPGA's external program memory via the bus data path provided by the FPGA. After gaining access, the MCU first erases all original programs located in the upper half of the FPGA's external program memory. Then, it writes the new program cached inside the MCU and its corresponding checksum to the corresponding location in the upper half. Finally, it reads back the newly written program and verifies it against the locally stored checksum. If the verification is successful, it reports a successful upgrade of the upper half program; if the verification fails, it reports an upgrade failure to the remote server, terminates the upgrade, and requests a re-upgrade. Since the FPGA's default program loading partition remains the lower half when the upper half program upgrade fails (i.e., when loading the program, the FPGA reads the program from the lower half of the FPGA's external program memory), if the upper half update fails due to a SEU (Search Engine Unlocked) during communication or at the device terminal, it does not affect the normal loading of the FPGA program from the lower half.

[0049] (7) Complete the online upgrade. Close the FPGA program online upgrade channel and restore the FPGA program to the upper half of the default loading partition.

[0050] In practice, the first step is to determine whether both the upper and lower half of the program have been loaded and verified to be error-free. If the verification is successful, the FPGA program upgrade is complete. The MCU sends a bus shutdown command to the FPGA, closing the data path between the MCU and the FPGA's external program memory to prevent subsequent program malfunctions. The MCU then changes the default loading partition of the FPGA program back to the upper half.

[0051] Example 2:

[0052] A method for resisting single-event upsets during online FPGA program upgrades includes the following methods and steps:

[0053] (1) FPGA External Program Memory Partitioning. The FPGA external program memory is divided into two equal parts, upper and lower. Two identical FPGA programs and their corresponding checksums are placed in the upper and lower halves of the external program memory, respectively.

[0054] (2) Switching between the upgrade area and the loading area. The storage partitions of the FPGA's external memory can be flexibly switched in various ways to separate the upgrade area and the loading area. The upper and lower halves of the FPGA program loading and storage are switched by controlling the high and low levels of the most significant bit of the address bus. Hardware and software control can be switched via hardware DIP switches or jumpers. By default, the most significant bit of the address line is controlled by the MCU, but manual switching is also possible when necessary; (see...) Figure 1 )

[0055] (3) Online Upgrade Process. Upon receiving the online upgrade command, the lower half of the FPGA external program memory is first set as the upgrade area, and the upper half as the loading area. After the lower half is upgraded, the upper half of the FPGA external program memory is set as the upgrade area, and the lower half as the loading area. This ensures that the FPGA program will not fail to load properly due to upgrade failure; see [link to relevant documentation]. Figure 2 .

[0056] Furthermore, the original single FPGA program is copied into two copies and placed in the upper and lower partitions of the FPGA's external program memory, respectively. The upper and lower partitions are defined as the upgrade area and the storage area to achieve program redundancy and serve as backups for each other.

[0057] Furthermore, the partitioning method of the FPGA's external program memory is not entirely based on the original address bus, but rather uses the external MCU software to control the highest bit of the address bus to achieve the conversion of loading and upgrading functions for the upper and lower halves.

[0058] Furthermore, if the MCU software does not perform partition switching in a timely manner, manual switching can be performed via a hardware DIP switch to further improve reliability.

[0059] Furthermore, the upper and lower halves of the FPGA's external program memory are upgraded alternately. When one half is being upgraded, the other half is used as the FPGA program loading partition. This separates program upgrade from program loading. If the upgrade fails, a re-upgrade request can be submitted to the remote server, and the current FPGA program is unaffected by the risks of online upgrades.

[0060] This invention uses redundant storage and partitioned upgrades of FPGA programs, combined with a flexible switching strategy consisting of hardware DIP switches, MCUs, and hardware two-to-one selector circuits, to separate the upgrade area from the loading area, thus completely eliminating the problem of FPGA malfunction due to incomplete updates during online FPGA program upgrades.

[0061] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for resisting single-event upsets during online FPGA program upgrades, characterized in that, The method includes the following steps: S1. Start Online Upgrade: The MCU receives the online upgrade command and starts the online upgrade program; S2. Set the lower half of the FPGA external program memory as the upgrade partition; set the FPGA loading partition as the upper half. S3. Upgrade the lower half of the program; The MCU receives and caches the FPGA program file sent by the remote server, and erases and updates the program stored in the lower half of the external program memory through the FPGA; Since the FPGA's default loading partition is still the upper half, if the update fails, report the fault and upgrade again. This will not affect the normal loading of the FPGA program from the upper half. S4. After the lower half of the program upgrade is completed, switch the upgrade and loading partitions; set the upper half of the FPGA external program memory as the upgrade partition; change the FPGA default loading partition to the lower half. S5. Upgrade the upper half-zone program; at this time, the lower half-zone program has completed the online upgrade. If the update is interrupted or fails due to SEU during the communication process or at the device terminal, load the latest FPGA program from the lower half-zone. S6. Complete online upgrade; After both the upper and lower halves of the FPGA program have completed the online upgrade, close the FPGA program online upgrade channel and restore the FPGA program's default loading partition settings. in, The MCU connects to a remote server to receive FPGA programs and control the upper and lower halves of the FPGA's external program memory for partitioning and enabling. A data bus is also configured between the FPGA and the MCU for transmitting FPGA program files. The FPGA and the FPGA's external program memory are connected via an address bus and a data bus. The highest bit of the address bus is isolated and controlled by the MCU and a hardware DIP switch. The "software / hardware control switch" key of the hardware DIP switch controls a hardware two-way selector circuit. When the "software / hardware control switch" key is 1, the highest bit of the address bus is controlled by the MCU; when the "software / hardware control switch" key is 0, the highest bit of the address bus is controlled by the hardware DIP switch.

2. The method of claim 1, wherein, The FPGA external program memory is divided into two equal halves, and two identical FPGA programs and corresponding check codes are placed in the upper and lower halves of the external program memory, respectively.

3. The method of claim 1, wherein, When the external program memory capacity is 16Mb, the address bus width between the FPGA and the FPGA external program memory is 24 bits, namely addr[0]~addr[23]. The highest bit of the address bus, addr[23], is isolated and adjusted to be controlled by the external MCU and the hardware DIP switch. The "software / hardware control switch" key of the hardware DIP switch controls the hardware two-way circuit. When the "software / hardware control switch" key is 1, addr[23] is controlled by the MCU. When the "software / hardware control switch" key is 0, addr[23] is controlled by the hardware DIP switch, thereby controlling the FPGA external program memory. The address bus is divided into two sections, upper and lower. The remaining address lines addr[0] to addr[22] are still connected to the FPGA and the external program memory of the FPGA. When the FPGA loads the program from the external program memory of the FPGA, when the highest bit of the address bus addr[23] is 0, its addressable address space is the lower 8Mb, i.e., 0x7fffff~0x000000; when the highest bit of the address bus addr[23] is 1, its addressable address space is the upper 8Mb, i.e., 0xffffff~0x800000. The two identical FPGA programs are placed in the upper and lower half of the external program memory, respectively.

4. The method of claim 1, wherein, In step S1, the MCU receives instructions from the remote server in real time and parses the instructions. If the received instruction is an online upgrade command for the FPGA program, the subsequent online upgrade program is started.

5. The method of claim 1, wherein, In S2, the partition is switched by the MCU or hardware DIP switch, and the default access storage area between the FPGA external program memory and the FPGA is switched from the upper half to the lower half. The FPGA default loading partition remains unchanged as the upper half.

6. The method of claim 5, wherein, There are two ways to switch partitions: MCU switching: The "software / hardware control switch" key of the hardware DIP switch controls the hardware two-to-one circuit, so that the corresponding control pin of the MCU is directly connected to the highest bit of the address bus of the FPGA external program memory. At this time, the highest bit level of the address bus, which is the default when the FPGA is working normally, can be changed from 1 to 0 through the control of the MCU. Hardware switching: The "software / hardware control switch" key of the hardware DIP switch controls the hardware two-in-one circuit, making the "hardware partition control" key of the hardware DIP switch directly connected to the highest bit of the address bus of the FPGA external program memory. By toggling the "hardware partition control" key of the hardware DIP switch, the highest bit level of the address bus during normal FPGA operation is changed from 1 to 0, while the default FPGA loading partition setting inside the MCU remains unchanged as the upper half.

7. The method of claim 6, wherein, If the MCU software does not perform partition switching in a timely manner, manual switching can be performed using a hardware DIP switch.

8. The method of any of claims 3-7, wherein, S3 specifically includes: First, after the MCU sends a program request instruction to the remote server, the remote server issues an updated FPGA program, and the MCU caches the updated FPGA program locally; then, the MCU sends a bus occupancy request to the FPGA, and directly accesses the FPGA's external program memory through the bus data path provided by the FPGA; after obtaining access rights, the MCU first erases all the original programs located in the lower half of the FPGA's external program memory, then writes the new program cached inside the MCU and the corresponding checksum into the corresponding position in the lower half, and finally reads back the newly written program and verifies it with the locally stored checksum; if the verification is correct, it reports that the lower half program upgrade is successful; if the verification fails, it reports the upgrade failure to the remote server, terminates the upgrade, and requests a new online upgrade; since the FPGA's default program loading partition is still the upper half when the lower half program upgrade fails, if the lower half update fails due to a SEU during the communication process or on the device terminal, it does not affect the normal loading of the FPGA program from the upper half.

9. The method of any of claims 3-7, wherein, S5 specifically includes: First, after the MCU sends a program request instruction to the remote server, the remote server issues an updated FPGA program, and the MCU caches the updated FPGA program locally; then, the MCU sends a bus occupancy request to the FPGA, and directly accesses the FPGA's external program memory through the bus data path provided by the FPGA; after obtaining access rights, the MCU first erases all the original programs located in the upper half of the FPGA's external program memory, then writes the new program cached inside the MCU and the corresponding checksum into the corresponding position in the upper half, and finally reads back the newly written program and verifies it with the locally stored checksum; if the verification is correct, it reports that the upper half program upgrade is successful; if the verification fails, it reports the upgrade failure to the remote server, terminates the upgrade, and requests a new online upgrade; since the FPGA's default program loading partition is still the lower half when the upper half program upgrade fails, if the upper half update fails due to a SEU during the communication process or on the device terminal, it does not affect the normal loading of the FPGA program from the lower half.

Images