Method for online upgrading of node device fpga configuration file based on fiber channel network

Abstract

The application provides a kind of node equipment fpga configuration file online upgrade method based on fibre channel network, comprising: the two pieces of flash of node equipment are configured, respectively configuration flash and program flash, for storing the default configuration file of register logic reading after power-on initialization and the program version loaded after fpga power-on;When the source end updates the flash configuration file of destination end, the fpga configuration file online upgrade process is started between source end and destination end, and the configuration flash and program flash of one or more destination ends are simultaneously online upgraded based on request and response, and after upgrading is completed, the destination end that completes configuration file online upgrade will load the updated updata version configuration file after next power-on;Online upgrade process does not suspend or interrupt normal data stream transceiving, improves fc data communication efficiency and integrity, simultaneously completes the synchronous online upgrade of flash configuration file, and loads the updated configuration file after next fpga power-on start.

Description

Technical Field

[0001] This invention relates to the field of Fibre Channel network technology, and in particular to configuration upgrade technology for node devices, specifically to an online upgrade method for FPGA configuration files of node devices based on Fibre Channel networks. Background Technology

[0002] Fibre Channel (FC) networking is a network communication standard proposed by the American Industrial Standards Institute (ANSI) in 1988. It aims to solve the problem of high-speed data communication within airborne data buses in applications such as aerospace. FC networks are standards-based network architectures that possess the advantages of both channel and network capabilities, allowing the operation of mainstream channel standards and network protocols on the same physical interface. Its massive data throughput enables large-scale data transmission between different systems and allows the use of the same equipment to establish any topology, satisfying different connection characteristics, such as point-to-point communication networks, arbitration ring communication networks, and switched networks, achieving high-speed communication between node devices.

[0003] In an FC communication topology, node devices are typically configured with one or more Fibre Channel ports (FC ports). Node devices connect to the host via PCIe interfaces, communicating with the host to send and receive messages, such as sending service messages to the host, receiving configuration information from the host for the node devices (including FPGAs, DDR storage, optical signal processing, etc.), and connecting the host to the FC switching network through the FC ports.

[0004] FPGAs in FC network node devices are typically programmed using SRAM. When the system loses power, all programming information is lost. Therefore, non-volatile FLASH memory is commonly used to store the FPGA configuration file. Upon system power-up, the configuration file is loaded into the FPGA chip, allowing the FPGA program to start normally. Taking the 7-series FPGA as an example, referring to the Xilinx manual (ug470_7Series_Config.pdf), the 7-series FPGA features MultiBoot and FallBack mechanisms. Specifically, after power-up, the configuration program executes from the FLASH base address. Configuring the corresponding parameters in the boot sector triggers the MultiBoot mechanism, allowing loading of the FPGA configuration file from a specified jump address; this version of the bitstream file is called the update version. If loading fails, the FallBack mechanism is triggered to return to the base address and load another FPGA configuration file; this version of the bitstream file is called the golden version.

[0005] With the continuous development of network and big data technologies, the amount of data in networks is growing exponentially. Networks based on the FC protocol, as a new type of high-speed data transmission network, are commonly used in data centers and wide area networks, offering advantages such as high bandwidth, low latency, and high reliability. However, as technology continues to evolve, network requirements are constantly changing, making flexible online upgrade methods a crucial issue. Traditional online upgrade methods may lead to network interruptions or service unavailability. Therefore, how to upgrade and update network devices and nodes without affecting normal network communication and the normal operation of individual nodes is a problem that needs to be solved in the current FC communication field.

[0006] Existing technologies attempt to perform remote upgrades via a host computer or online upgrades via a network. For example, in a network-wide remote upgrade method based on an FC switching network, a host computer is used for remote updates. An FC firmware update device (including the host computer, FPGA chip, and optoelectronic transceiver) updates the node devices in the FC switching network, allowing administrators to manage and upgrade devices across the entire network centrally via the host computer. Another example is a secure online upgrade method for FPGA configuration files in Fibre Channel network node devices. This method employs dual authentication to ensure a usable, complete version exists in flash memory, and utilizes multiple online configuration functions to ensure system flexibility.

[0007] Both of the above methods achieve online upgrades of node FPGA devices to some extent. The network-wide remote upgrade method based on FC switching networks, controlled remotely by a host computer, improves management efficiency. However, this method requires the device to pause operation during the online upgrade process, which can lead to network interruptions, especially when updating critical equipment, significantly impacting services. In the secure online upgrade method for FPGA configuration files in Fibre Channel network node devices, the FPGA cannot be stopped during the upgrade process, interrupting normal data transmission and affecting normal device operation. Furthermore, the upgrade efficiency is low, as each upgrade requires data to be sent from the host computer and written to a single daughter card via the PCIe port, making simultaneous online upgrades of multiple nodes in the network impossible. Summary of the Invention

[0008] In view of the defects and shortcomings of the existing technology, according to a first aspect of the present invention, a method for online upgrade of FPGA configuration files of node devices based on Fibre Channel networks is proposed, comprising the following steps:

[0009] The configuration node device has two flash memory modules: a configuration flash and a program flash. The configuration flash is used to store the default configuration file of the registers read after power-on initialization, and the program flash is used to store the program version loaded after the FPGA is powered on.

[0010] In an FC switching network, when the flash configuration file of the destination end of the FC switch is updated through a source end, the source end and the destination end initiate an online upgrade process for the FPGA configuration file, and the online upgrade process does not pause or interrupt normal data transmission and reception.

[0011] The source end is configured to send FC data frames to one or more destination ends simultaneously. Based on the request and response between the two ends, the configuration flash and program flash of one or more destination ends are upgraded online at the same time. After the upgrade is completed, the destination end that has completed the online upgrade of the configuration file will load the updated version of the configuration file after the next power-on.

[0012] As an optional implementation, the configuration flash and the program flash are each configured with different storage areas to store the golden version configuration file and the update version configuration file, respectively. The golden version configuration file is the default version file during power-on initialization, and the update version configuration file is the version file for online upgrades.

[0013] Specifically, when no online upgrade occurs, the storage areas of the corresponding update version configuration files in the configuration flash and program flash are empty; and when the FPGA configuration file is upgraded online from the source end to at least one or more destination ends, the configuration file version upgraded online is only written to the storage area of ​​the update version configuration file.

[0014] As an optional implementation, the request and response between the two refers to the request and response between the source and the destination, including:

[0015] The "Initiate Request" frame represents a request for a flash update from the source end.

[0016] The startup response represents the destination's response to the startup request, corresponding to the startup response els frame;

[0017] The execution request signifies that the source end has begun writing data, corresponding to the execution request els frame;

[0018] The run response represents the destination's response to the run request, corresponding to the run response els frame;

[0019] Stop requesting means that flash update requests are stopped, which corresponds to stopping the request for ELS frames;

[0020] "Stop responding" means that the flash update has stopped responding, corresponding to the "Stop responding els" frame.

[0021] As an optional implementation, the online upgrade process for the FPGA configuration file between the source and destination ends includes:

[0022] The source end sends an ELS data frame to initiate an update. The source ID and destination ID are written in the FC frame header, and the data content that matches the start request field is written in the ELS frame header. The data is sent out through the FC module of the source end and then sent to the destination end by the FC switch according to the destination ID.

[0023] The destination receives the data frame through the FC module, parses the frame content through its rx_top module, and after parsing, assembles the start response ELSE frame according to the actual local state of the destination. The tx_top module then packages it into a protocol frame that conforms to the FC protocol, sends it out through the destination's FC module, and sends it to the source end through the FC switch.

[0024] If the source end parses the content of the start response els frame and finds that it can operate on the destination end's flash, the source end further sends a run request els frame to the destination end, indicating that the source end has started writing data; after the destination end receives the data frame and parses the frame content in the rx_top module, it writes all the updated data into the destination end's flash, and after completing the operation, it assembles a run response els frame, packages it into a protocol frame conforming to the FC protocol through the tx_top module, sends it out through the destination end's FC module, and sends it to the source end through the FC switch;

[0025] When the source end can no longer update the flash configuration file or all update data has been written, the source end sends a stop request els frame to the destination end, indicating a stop update request. After receiving the data frame and parsing the frame content in the rx_top module, the destination end sends a stop response els frame, indicating a stop update response. The data frame is packaged into a protocol frame conforming to the FC protocol by the tx_top module, sent out through the destination end's FC module, and then sent to the source end through the FC switch.

[0026] As an optional implementation, when the source needs to write to the flash memory multiple times in a continuous cycle, the process of requesting and responding will be repeated.

[0027] As an optional implementation, the FC frame header defines the frame type, source ID, and destination ID information.

[0028] As an optional implementation, the els frame header defines the following field attributes:

[0029] The role field indicates whether the main port originates from the host computer or from a network node device;

[0030] The action field indicates whether this frame is a request or a response;

[0031] The offset field indicates how many 4-byte data bytes the current frame contains.

[0032] The verification field, where the user defines the password, performs a policy calculation with the password from the destination. Only if the passwords match will the operation continue.

[0033] The function ID field defines six different functional business operations: start request, start response, run request, run response, stop request, and stop response.

[0034] The four attribute fields represent different content defined according to the six different functional business requirements.

[0035] As an optional implementation, the relationship between the function id field and the four attribute fields is defined as follows:

[0036] a) Initiate request, representing the source end's request to update flash, where the configuration length represents the total length of data in flash to be updated, and the configuration mode represents whether to update the configuration flash or the program flash;

[0037] b) Startup Response: This represents the destination's response to the startup request. It defines an additional status field compared to the startup request, which indicates the current status of the selected flash memory, i.e., whether data has been written to it and the position information of the last write pointer.

[0038] c) Run request, indicating that the source end has started writing data. The end flag field indicates whether this frame is the last frame to be written. After writing this frame of data, all updated data will be sent. The data length field indicates the length of valid updated data in the current frame. The command field indicates whether the current operation is writing or reading data: when the operation is reading data, the data field will become a status field, indicating the pointer to read, that is, the address in flash. The data field represents the updated data.

[0039] d) Run Response: This represents the destination's response to the run request. The meanings of the end flag field, data length field, and command field are the same as those in the run request. The data / status field represents the data read or the position pointed to by the pointer after writing is complete.

[0040] e) Stop Request: This represents an update stop request initiated by the source. The cumulative length field represents the cumulative length of data written to flash up to the present, and the checksum field represents the checksum of all data that has been written.

[0041] f) Stop Response: This indicates that the destination has sent a stop response for the update. The cumulative length field and the check field have the same meaning as the fields in the stop request. The status field indicates the current position of the write flash pointer.

[0042] As an optional implementation, the online upgrade process also includes at least one of the following operations:

[0043] Upgrade paused;

[0044] Read data from any location and verify the flash configuration file;

[0045] The updated data is written to any location to update the flash configuration file.

[0046] It should be understood that all combinations of the foregoing concepts and the additional concepts described in more detail below may be considered part of the inventive subject matter of this disclosure, provided that such concepts do not contradict each other. Furthermore, all combinations of the claimed subject matter are considered part of the inventive subject matter of this disclosure.

[0047] The foregoing and other aspects, embodiments, and features of the teachings of the present invention will be more fully understood from the following description in conjunction with the accompanying drawings. Other additional aspects of the invention, such as features and / or beneficial effects of exemplary embodiments, will become apparent from the following description or may be learned through practice of specific embodiments according to the teachings of the present invention. Attached Figure Description

[0048] The accompanying drawings are not intended to be drawn to scale. In the drawings, each identical or nearly identical component shown in the various figures may be denoted by the same reference numeral. For clarity, not every component is labeled in each figure. Embodiments of various aspects of the invention will now be described by way of example and with reference to the accompanying drawings.

[0049] Figure 1 This is a schematic diagram of a system for upgrading the FPGA configuration file of an FC node device according to an embodiment of the present invention.

[0050] Figure 2 This is a connection topology diagram of FC switching network node devices according to an embodiment of the present invention.

[0051] Figure 3 This is a diagram of the FC frame header structure according to an embodiment of the present invention.

[0052] Figure 4 This is a diagram of the els frame header structure according to an embodiment of the present invention.

[0053] Figure 5 This is a frame structure diagram of the interaction frame according to an embodiment of the present invention. Detailed Implementation

[0054] To better understand the technical content of the present invention, specific embodiments are described below in conjunction with the accompanying drawings.

[0055] Various aspects of the invention are described in this disclosure with reference to the accompanying drawings, which illustrate numerous illustrative embodiments. The embodiments of this disclosure are not necessarily intended to encompass all aspects of the invention. It should be understood that the various concepts and embodiments described above, as well as those described in more detail below, can be implemented in any of many ways, because the concepts and embodiments disclosed herein are not limited to any particular implementation. Furthermore, some aspects of the invention disclosed may be used alone or in any suitable combination with other aspects of the invention disclosed.

[0056] Combination Figures 1-5 The example shown, according to the present invention, includes the following steps for online upgrade of FPGA configuration files for node devices based on Fibre Channel networks:

[0057] The configuration node device has two flash memory modules: a configuration flash and a program flash. The configuration flash is used to store the default configuration file of the registers read after power-on initialization, and the program flash is used to store the program version loaded after the FPGA is powered on.

[0058] In an FC switching network, when the flash configuration file of the destination end of the FC switch is updated through a source end, the source end and the destination end initiate an online upgrade process for the FPGA configuration file, and the online upgrade process does not pause or interrupt normal data transmission and reception.

[0059] The source end is configured to send FC data frames to one or more destination ends simultaneously. Based on the request and response between the two ends, the configuration flash and program flash of one or more destination ends are upgraded online at the same time. After the upgrade is completed, the destination end that has completed the online upgrade of the configuration file will load the updated version of the configuration file after the next power-on.

[0060] As an optional implementation, multiple source terminals connected to the FC switch are configured to perform online upgrades of FPGA configuration files to a single destination terminal connected to the FC switch, and only after one source terminal has completed the upgrade of a single destination terminal is another source terminal allowed to start operation.

[0061] As an optional implementation, two versions are stored in both flash memory blocks for backup purposes.

[0062] The configuration flash and program flash each have different storage areas, which store the golden version configuration file and the update version configuration file, respectively. The golden version configuration file is the default version file during power-on initialization, and the update version configuration file is the version file for online upgrades.

[0063] Specifically, when no online upgrade occurs, the storage areas of the corresponding update version configuration files in the configuration flash and program flash are empty; and when the FPGA configuration file is upgraded online from the source end to at least one or more destination ends, the configuration file version upgraded online is only written to the storage area of ​​the update version configuration file.

[0064] As an optional implementation, the aforementioned request and response between the two refers to the request and response between the source and the destination, including:

[0065] The "Initiate Request" frame represents a request for a flash update from the source end.

[0066] The startup response represents the destination's response to the startup request, corresponding to the startup response els frame;

[0067] The execution request signifies that the source end has begun writing data, corresponding to the execution request els frame;

[0068] The run response represents the destination's response to the run request, corresponding to the run response els frame;

[0069] Stop requesting means that flash update requests are stopped, which corresponds to stopping the request for ELS frames;

[0070] "Stop responding" means that the flash update has stopped responding, corresponding to the "Stop responding els" frame.

[0071] As an optional implementation, the online upgrade process for the FPGA configuration file between the source and destination ends includes:

[0072] The source end sends an ELS data frame to initiate an update. The source ID and destination ID are written in the FC frame header, and the data content that matches the start request field is written in the ELS frame header. The data is sent out through the FC module of the source end and then sent to the destination end by the FC switch according to the destination ID.

[0073] The destination receives the data frame through the FC module, parses the frame content through its rx_top module, and after parsing, assembles the start response ELSE frame according to the actual local state of the destination. The tx_top module then packages it into a protocol frame that conforms to the FC protocol, sends it out through the destination's FC module, and sends it to the source end through the FC switch.

[0074] If the source end parses the content of the start response els frame and finds that it can operate on the destination end's flash, the source end further sends a run request els frame to the destination end, indicating that the source end has started writing data; after the destination end receives the data frame and parses the frame content in the rx_top module, it writes all the updated data into the destination end's flash, and after completing the operation, it assembles a run response els frame, packages it into a protocol frame conforming to the FC protocol through the tx_top module, sends it out through the destination end's FC module, and sends it to the source end through the FC switch;

[0075] When the source end can no longer update the flash configuration file or all update data has been written, the source end sends a stop request els frame to the destination end, indicating a stop update request. After receiving the data frame and parsing the frame content in the rx_top module, the destination end sends a stop response els frame, indicating a stop update response. The data frame is packaged into a protocol frame conforming to the FC protocol by the tx_top module, sent out through the destination end's FC module, and then sent to the source end through the FC switch.

[0076] As an optional implementation, when the source needs to write to the flash memory multiple times in a continuous cycle, the process of requesting and responding will be repeated.

[0077] As an optional implementation method, combined with Figure 3 As shown, the FC frame header defines the frame type, source ID, and destination ID information.

[0078] As an optional implementation method, combined with Figure 4 As shown, the els frame header defines the following field attributes:

[0079] The role field indicates whether the main port originates from the host computer or from a network node device;

[0080] The action field indicates whether this frame is a request or a response;

[0081] The offset field indicates how many 4-byte data bytes the current frame contains.

[0082] The verification field, where the user defines the password, performs a policy calculation with the password from the destination. Only if the passwords match will the operation continue.

[0083] The function ID field defines six different functional business operations: start request, start response, run request, run response, stop request, and stop response.

[0084] The four attribute fields represent different content defined according to the six different functional business requirements.

[0085] Combination Figure 3 , 4 As shown in Figure 5, the relationship between the function id field and the four attribute fields is defined as follows:

[0086] a) Initiate request, representing the source end's request to update flash, where the configuration length represents the total length of data in flash to be updated, and the configuration mode represents whether to update the configuration flash or the program flash;

[0087] b) Startup Response: This represents the destination's response to the startup request. It defines an additional status field compared to the startup request, which indicates the current status of the selected flash memory, i.e., whether data has been written to it and the position information of the last write pointer.

[0088] c) Run request, indicating that the source end has started writing data. The end flag field indicates whether this frame is the last frame to be written. After writing this frame of data, all updated data will be sent. The data length field indicates the length of valid updated data in the current frame. The command field indicates whether the current operation is writing or reading data: when the operation is reading data, the data field will become a status field, indicating the pointer to read, that is, the address in flash. The data field represents the updated data.

[0089] d) Run Response: This represents the destination's response to the run request. The meanings of the end flag field, data length field, and command field are the same as those in the run request. The data / status field represents the data read or the position pointed to by the pointer after writing is complete.

[0090] e) Stop Request: This represents an update stop request initiated by the source. The cumulative length field represents the cumulative length of data written to flash up to the present, and the checksum field represents the checksum of all data that has been written.

[0091] f) Stop Response: This indicates that the update response sent by the destination has stopped. The cumulative length field and the check field have the same meaning as the fields in the stop request. The status field indicates the current position of the write flash pointer.

[0092] As an optional implementation, the online upgrade process also includes at least one of the following operations:

[0093] Upgrade paused;

[0094] Read data from any location and verify the flash configuration file;

[0095] The updated data is written to any location to update the flash configuration file.

[0096] Therefore, the online FPGA configuration file upgrade method proposed in this invention supports pausing the upgrade, reading verification from any position, and writing to any position for updating. Compared with the traditional method, it can ensure that the data frames of the online upgrade will not affect the normal data stream transmission and reception. At the same time, the upgrade process is more flexible, which is conducive to controlling the upgrade progress, update completion status and verification, and ensuring the integrity of the upgrade.

[0097] In conjunction with the implementation of the above aspects, the online upgrade method for FPGA configuration files of node devices based on Fibre Channel networks proposed in this invention enables simultaneous online upgrades of flash configuration files stored in the FPGA's flash memory by the source end in the FC network to one or more destination ends, and also supports multiple source ends upgrading the flash configuration files of a single destination end. Furthermore, the upgraded data frames do not affect normal data stream transmission and reception, improving the efficiency and integrity of FC data communication, while simultaneously completing the synchronous online upgrade of the flash configuration files. After the online upgrade is complete, the source end sends a message to the host computer to notify that the online upgrade is complete, and the update version file will be loaded on the next power-on.

[0098] In some embodiments, the method proposed in this invention, based on the definition of ELS frames and the request / response between the source and destination ends, supports both online upgrades of two flash chips by the source end in the FC switching network and online upgrades of two flash chips by the host computer. The process of updating the flash configuration file by the host computer is basically the same as the network update method. The difference is that when the host computer updates the flash configuration file, the ELS frame is directly sent by the host computer, parsed by the tx_top module inside the FPGA chip, and written to the configuration flash or the program flash accordingly to realize the configuration file update.

[0099] While the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the invention. Those skilled in the art can make various modifications and refinements without departing from the spirit and scope of the invention. Therefore, the scope of protection of the present invention shall be determined by the claims.

Claims

1. A method for online upgrade of FPGA configuration files for node devices based on a Fibre Channel network, characterized in that, Includes the following steps: The configuration node device has two flash memory modules: a configuration flash and a program flash. The configuration flash is used to store the default configuration file of the registers read after power-on initialization, and the program flash is used to store the program version loaded after the FPGA is powered on. In an FC switching network, when the flash configuration file of the destination end of the FC switch is updated through a source end, the source end and the destination end initiate an online upgrade process for the FPGA configuration file, and the online upgrade process does not pause or interrupt normal data transmission and reception. The source end is configured to send FC data frames to one or more destination ends simultaneously. Based on the request and response between the two ends, the configuration flash and program flash of one or more destination ends are upgraded online at the same time. After the upgrade is completed, the destination end that has completed the online upgrade of the configuration file will load the updated version of the configuration file after the next power-on.

2. The method for online upgrade of FPGA configuration files for node devices based on Fibre Channel networks according to claim 1, characterized in that, The multiple source terminals of the access FC switch are configured to perform online upgrades of the FPGA configuration file to a single destination terminal of the access FC switch, and only after one source terminal has completed the upgrade of a single destination terminal is another source terminal allowed to start operation.

3. The method for online upgrade of FPGA configuration files for node devices based on Fibre Channel networks according to claim 1, characterized in that, The configuration flash and program flash are each configured with different storage areas, which store the golden version configuration file and the update version configuration file respectively. The golden version configuration file is the default version file during power-on initialization, and the update version configuration file is the version file for online upgrades. Specifically, when no online upgrade occurs, the storage areas of the corresponding update version configuration files in the configuration flash and program flash are empty; and when the FPGA configuration file is upgraded online from the source end to at least one or more destination ends, the configuration file version upgraded online is only written to the storage area of ​​the update version configuration file.

4. The method for online upgrade of FPGA configuration files for node devices based on Fibre Channel networks according to claim 1, characterized in that, The request and response between the two refers to the request and response between the source and the destination, including: The "Initiate Request" frame represents a request for a flash update from the source end. The startup response represents the destination's response to the startup request, corresponding to the startup response els frame; The execution request signifies that the source end has begun writing data, corresponding to the execution request els frame; The run response represents the destination's response to the run request, corresponding to the run response els frame; Stop requesting means that flash update requests are stopped, which corresponds to stopping the request for ELS frames; "Stop responding" means that the flash update has stopped responding, corresponding to the "Stop responding els" frame.

5. The method for online upgrade of FPGA configuration files for node devices based on Fibre Channel networks according to any one of claims 1-4, characterized in that, The process of initiating an online upgrade of the FPGA configuration file between the source and destination ends includes: The source end sends an ELS data frame to initiate an update. The source ID and destination ID are written in the FC frame header, and the data content that matches the start request field is written in the ELS frame header. The data is sent out through the FC module of the source end and then sent to the destination end by the FC switch according to the destination ID. The destination receives the data frame through the FC module, parses the frame content through its rx_top module, and after parsing, assembles the start response ELSE frame according to the actual local state of the destination. The tx_top module then packages it into a protocol frame that conforms to the FC protocol, sends it out through the destination's FC module, and sends it to the source end through the FC switch. If the source end parses the content of the start response els frame and finds that it can operate on the destination end's flash, the source end further sends a run request els frame to the destination end, indicating that the source end has started writing data; after the destination end receives the data frame and parses the frame content in the rx_top module, it writes all the updated data into the destination end's flash, and after completing the operation, it assembles a run response els frame, packages it into a protocol frame conforming to the FC protocol through the tx_top module, sends it out through the destination end's FC module, and sends it to the source end through the FC switch; When the source end can no longer update the flash configuration file or all update data has been written, the source end sends a stop request els frame to the destination end, indicating a stop update request. After receiving the data frame and parsing the frame content in the rx_top module, the destination end sends a stop response els frame, indicating a stop update response. The data frame is packaged into a protocol frame conforming to the FC protocol by the tx_top module, sent out through the destination end's FC module, and then sent to the source end through the FC switch.

6. The method for online upgrade of FPGA configuration files for node devices based on Fibre Channel networks according to claim 5, characterized in that, When the source needs to write to the flash multiple times in a continuous cycle, the process of requesting and responding will be repeated.

7. The method for online upgrade of FPGA configuration files for node devices based on Fibre Channel networks according to claim 5, characterized in that, The FC frame header defines the frame type, source ID, and destination ID information.

8. The method for online upgrade of FPGA configuration files for node devices based on Fibre Channel networks according to claim 5, characterized in that, The els frame header defines the following attributes: The role field indicates whether the main port originates from the host computer or from a network node device; The action field indicates whether this frame is a request or a response; The offset field indicates how many 4-byte data bytes the current frame contains. The verification field, where the user defines the password, performs a policy calculation with the password from the destination. Only if the passwords match will the operation continue. The function ID field defines six different functional business operations: start request, start response, run request, run response, stop request, and stop response. The four attribute fields represent different content defined according to the six different functional business requirements.

9. The method for online upgrade of FPGA configuration files for node devices based on Fibre Channel networks according to claim 8, characterized in that, The relationship between the function ID field and the four attribute fields is defined as follows: a) Initiate request, representing the source end's request to update flash, where the configuration length represents the total length of data in flash to be updated, and the configuration mode represents whether to update the configuration flash or the program flash; b) Startup Response: This represents the destination's response to the startup request. It defines an additional status field compared to the startup request, which indicates the current status of the selected flash memory, i.e., whether data has been written to it and the position information of the last write pointer. c) Run request, which means that the source end has started writing data. The end flag field indicates whether this frame is the last frame to be written. After writing this frame of data, all update data will be sent. The data length field indicates the length of valid update data in the current frame. The command field indicates whether the current operation is writing or reading data: when the operation is reading data, the data field will become a status field, indicating the pointer to be read, that is, the address in flash; The data field represents the updated data; d) Run Response: This represents the destination's response to the run request. The meanings of the end flag field, data length field, and command field are the same as those in the run request. The data / status field represents the data read or the position pointed to by the pointer after writing is complete. e) Stop Request: This represents an update stop request initiated by the source. The cumulative length field represents the cumulative length of data written to flash up to the present, and the checksum field represents the checksum of all data that has been written. f) Stop Response: This indicates that the destination has sent a stop response for the update. The cumulative length field and the check field have the same meaning as the fields in the stop request. The status field indicates the current position of the write flash pointer.

10. The method for online upgrade of FPGA configuration files for node devices based on Fibre Channel networks according to claim 5, characterized in that, The upgrade process includes at least one of the following operations: Upgrade paused; Read data from any location and verify the flash configuration file; The updated data is written to any location to update the flash configuration file.

Images