High-efficiency FPGA (Field Programmable Gate Array) online upgrading method based on hardware implementation

Abstract

The invention discloses an efficient FPGA online upgrading method based on hardware implementation. The method comprises the steps that S1, parameter information issued by an upper computer is upgraded and analyzed; s2, receiving upgrading data issued by the upper computer monitor of which the parameters are modified in the step S1, and performing serial-parallel analysis processing; s3, carrying out upgrading Chinese-English processing on the data; and S4, carrying out upgrading processing on the SPI. According to the scheme, the online upgrading efficiency is high, the resource consumption is low, the reliability is high, the matched hardware cost is low, the problems of resource consumption and upgrading time are solved by setting the upgrading data baud rate and the data byte subpackage parameters, different hardware can be flexibly configured, the engineering application flexibility is high, and the implementation is easy. And the security and the reliability of online upgrading are greatly improved.

Description

Technical Field

[0001] The present invention relates to the technical field of FPGA firmware upgrade, and particularly to an efficient FPGA online upgrade method implemented based on hardware. Background Art

[0002] A Field-Programmable Gate Array (FPGA) is a chip whose internal structure can be programmatically changed. The development of FPGAs has gone through multiple stages, and the number of logic gates in the latest FPGAs has exceeded hundreds of millions. Compared with traditional integrated circuit chips, FPGAs have very prominent advantages. Due to the characteristics of their programmable and parallel processing structures, FPGAs are widely used in fields such as network communication, aerospace, mathematical computing, autonomous driving, image processing, satellite communication, and satellite navigation. With the massive application of FPGAs, the application scenarios are also diverse, and the problem of flexible configuration of FPGAs has emerged accordingly.

[0003] There are mainly two traditional configurations for FPGAs (Field-Programmable Gate Arrays). One is JTAG online download configuration, where the configuration file is downloaded to the volatile storage RAM of the FPGA through JTAG. Its disadvantage is that the configuration information is lost after power-off and needs to be reloaded after power-on for program debugging. The other is active configuration, where the configuration file is burned into the non-volatile storage FLASH supporting the FPGA board through JTAG, and it will not be lost after power-off. The FPGA chip actively reads the configuration file in the FLASH and places it in the internal configuration memory of the FPGA, which is a commonly used firmware method.

[0004] The traditional methods for firmware upgrading of FPGA programs mainly include two modes: firmware upgrade in JTAG mode and FPGA online upgrade. In the JTAG mode firmware upgrade, although the time consumption is short and the upgrade time is fast, the usage scenario is very limited. It is generally used for single-board debugging, and the driving distance of the connection line is very limited, making it difficult to achieve in the application scenario of the whole machine device. FPGA online upgrade is very convenient for whole machine upgrade. It does not require opening the case or a debugging interface, and ordinary serial ports can meet the requirements of program upgrade.

[0005] However, the online upgrade of traditional FPGAs generally takes a very long time, wasting a large amount of time and increasing the time cost, which poses a huge challenge to on-site upgrades. At the same time, the online upgrade of traditional FPGAs generally requires a large amount of hardware resources and high hardware costs. A large amount of data needs to be cached, consuming a large amount of RAM resources or using an external DDR to implement writing after storage. Generally, the storage program divides the flash memory program into two equal parts, namely the golden partition and the update partition, resulting in the need for twice the storage flash of the program size, increasing the hardware cost. Generally, a fixed upgrade baud rate and byte length are used, and the usage scenario is very limited and not flexible enough. There is a situation of accidentally overwriting other programs in traditional upgrades, and there are problems with low security and reliability. Summary of the Invention

[0006] Aiming at the problems of slow upgrade time, poor flexibility, poor stability, low security, low reliability, large resource consumption, and high hardware cost in the above-mentioned existing technologies, the present invention provides an efficient FPGA online upgrade method based on hardware implementation.

[0007] The present invention is implemented by the following technical solutions: An efficient FPGA online upgrade method based on hardware implementation, including the following steps: Step S1: Upgrade and parse the parameter information sent by the host computer; Step S2: Receive the upgrade data sent by the host computer monitoring that modifies the parameters in Step S1, and perform serial-to-parallel parsing processing; Step S3: Perform upgrade Chinese-English processing on the data; Step S4: Perform SPI upgrade processing.

[0008] Specifically, the said Step S1 includes the following sub-steps: Step S11: Deserialize the serial port data; Step S12: Parse the deserialized serial port data according to the host computer transmission protocol; Step S13: Extract parameter information according to the protocol parsing, including the serial port baud rate and data packet byte data information; Step S14: After extracting the parameters, frame according to the protocol to shake hands with the host computer. If the parameter extraction is successful, proceed to Step S15; Step S15: Serialize the returned byte data and transfer it to Step S2.

[0009] Specifically, the said Step S2 includes the following sub-steps: Step S21: Configure the baud rate parameter and data packet byte number parameter of the upgrade data; Step S22: Perform data deserialization processing; Step S23: Extract the upgrade data bytes and transfer to Step S3; Step S24: After the upgrade data is extracted, frame the data according to the protocol and handshake with the host computer. If the extraction of the backhaul upgrade data is successful, go to Step S25; Step S25: Byte-stringify the backhaul upgrade data and return to Step S21.

[0010] Specifically, the said Step S3 includes the following sub-steps: Step S31: Parse the host computer monitoring protocol and analyze the data according to the protocol; Step S32: Judge the upgrade program identification code; Step S33: Control the distribution of data caching; Step S34: The host computer shakes hands, reports whether the data reception is successful or failed, whether the program burning is successful or failed, and the current number of pages being burned according to the reported status, and requests the next packet of data.

[0011] Specifically, the said Step S31 further includes the following sub-steps: Step S3101: Receive the data frame header according to the protocol. When receiving the data 24’H EB_90_87, generate a data frame header valid enable, generate a byte counter, count the parsed bytes and perform data parsing; Step S3102: Receive the frame length of 2 bytes according to the byte counter; Step S3103: Receive 1 byte of the frame data ID according to the byte counter. If the received byte is 8’H 55, it means that the host computer issues the program identification code. If the received byte is 8’H AA, it means that the FPGA is being burned. Judge the received data parsing according to the identification code; Step S3104: Receive 4 bytes of the total number of packets according to the byte counter, indicating the total number of data packets transmitted; Step S3105: Receive 4 bytes of the current packet number according to the byte counter, indicating the current data packet number being transmitted; Step S3106: Receive 2 bytes of the data length according to the byte counter, indicating the number of valid bytes of the upgrade data in this data packet. If it is insufficient, pad with zeros and issue data for frame parsing; Step S3107: Receive 4096 bytes of upgrade and solidification data according to the byte counter. According to the number of bytes per sub-packet in Step S1 and the number of valid bytes per packet transmitted in Step S3106, parse the valid upgrade data; Step S3108: Receive 2 bytes of data verification according to the byte counter; Step S3109: Receive the data frame tail 16’H ED_03 according to the byte counter; Step S3110: Calculate the received data verification; Step S3111: Compare the received data checksum with the calculated received data checksum. When the checksums are consistent, give a check passed flag and go to step S3112; when the checksums are inconsistent, give a check failed flag and go to step S34; Step S3112: Parse the received data according to the check passed flag; Step S3113: Make a conditional judgment on the received data frame ID. If FRAME_ID = 8'H 55, go to step S32; if FRAME_ID = 8'H AA, go to step S33; if FRAME_ID is any other value, give an illegal frame data flag and go to step S34.

[0012] Specifically, the step S32 further includes the following sub-steps: Step S3201: According to the data FRAME_ID parsed in step S3103, judge whether FRAME_ID = 8'H 55. If so, give a program identification code judgment and extraction flag, extract the program identification code, and go to step S3202; if not, give a program error flag and go to step S34; Step S3202: Extract the program identification code BIN_MARK according to the parsed data; Step S3203: Judge whether BIN_MARK = 32'H 5555. If so, give a program identification code judgment correct flag and go to step S33; if not, give a program error flag and go to step S34.

[0013] Specifically, the step S33 further includes the following sub-steps: Step S3301: Concatenate the received upgrade data. Four consecutive bytes of data are concatenated into 32-bit data; Step S3302: Cache the concatenated data in the RAM, distribute it page by page according to the request. Each page has 256 bytes of data, and generate a cache completion flag according to the write address; Step S3303: Generate a data packet counter cnt_bytes according to the cache completion flag; Step S3304: Make a conditional judgment on the data packet counter cnt_bytes. When cnt_bytes < 4, perform flash paged programming, go to step S4, wait for the page programming success flag, and go to step S3305; when cnt_bytes >= 4, give a cache RAM full flag and go to step S3307; Step S3305: Generate a page programming distribution counter cnt_pages according to the page programming success flag; Step S3306: Conditional judgment of the page programming distribution counter cnt_pages. When cnt_pages < 16, request the distribution of the next page of data and go to Step S3302; when cnt_pages >= 16, generate a cache data distribution completion flag and go to Step S3307; Step S3307: Comprehensive processing of the distributed data. When it is requested to proceed with the next packet of data when the cache RAM flag, the cache data distribution completion flag, and the sub-sector programming completion flag are all valid, go to Step S34.

[0014] Specifically, Step S34 further includes the following sub-steps: Step S3401: Send a 3-byte data frame header 24’H EB_90_88 according to the host computer handshake protocol; Step S3402: Send a byte of the status of the previous packet of data. When the verification is successful, report that the transmission data is successful and the status word is set to 8’H01; when the verification fails, report that the transmission data fails and the status word is set to 8’H00; when the data is illegal, report that the transmission data fails and the status word is set to 8’H 00; when the programming failure flag is pulled high, report that the programming data fails and the status word is set to 8’H AA; when the page programming success flag is pulled high, report that the programming data is successful and the status word is set to 8’H10; when the programming completion is pulled high, report that the programming data is completed and the status word is set to 8’H55; Step S3403: Send 4 bytes of the current packet count, and report the current number of packets sent according to the programming success flag; Step S3404: Calculate the verification of the sent data and send the data verification value; Step S3405: Send the data frame tail 16’HEB_03 and go to Step S24.

[0015] Specifically, Step S4 includes: Step S41: SPI upgrade programming logic control; specifically includes the following sub-steps: Step S4101: Initialization operation, go to Step S42 to perform initialization processing on the flash, wait until the initialization status, and go to Step S4102; Step S4102: Conditional judgment of the initialization status; when intial_ok = 1, the initialization is successful, go to Step S4103; when intial_ok = 0, the initialization fails, go to Step S4113; Step S4103: Device ID detection, go to Step S42 to read the flash device ID. After the flash is successfully read, compare it with the program-built-in ID, and report the verification success flag if they are the same; Step S4104: Condition judgment for device ID detection. When id_check_ok = 1, the device ID verification is successful, and go to step S4105; when id_check_ok = 0, the device ID verification fails, and go to step S4113; Step S4105: Erase the key switch word, and go to step S42 to erase the flash address 32'h00000FFC, read the status register value. If the lower two bits are 2'b00, it means the erasure is successful, and report the erasure success flag; Step S4106: Condition judgment for erasing the key switch word. When erase_switch_word_ok = 1, the key switch word is successfully erased, and go to step S4107; when erase_switch_word_ok = 0, the key switch word erasure fails, and go to step S4113; Step S4107: Update the alternate control of partition sub-sector erasure and page programming; Step S4108: Update the partition verification, and go to step S42 to start the program of reading and writing to the flash address 32'h00200000, perform CRC verification, go to step S43, wait for the verification to be successful, and report the success of the verification partition verification; Step S4109: Condition judgment for updating the partition verification. When check_update_area_ok = 1, the update of the partition verification is successful, and go to step S4110; when check_update_area_ok = 0, the update of the partition verification fails, and go to step S4113; Step S4110: Program the switch key word, and go to step S42 to program the flash address 32'h00000FFC, write its value as 32'hAA995566, read the status register value. If the lower two bits are 2'b00, it means the erasure is successful, and report the programming success flag; Step S4111: Condition judgment for programming the switch key word. When program_switch_word_ok = 1, the switch key word is successfully programmed, and go to step S4112; when program_switch_word_ok_ok = 0, the switch key word programming fails, and go to step S4113; Step S4112: Give the write completion flag, set program_ok to 1, and go to step S34; Step S4113: Combine the failure flags of each step, give the write failure flag, set program_failure to 1, and go to step S34; Step S42: Serialize one byte of data controlled by the SPI upgrade logic through SPI, and send it to the flash through the SPI interface for flash read and write operations; read the flash status through the SPI interface, byteify the serial data, and send it to the SPI upgrade logic control processing module; go to step S41; Step S43: Perform CRC check according to the look-up table. After the check is completed, give a check success flag and go to step S4108.

[0016] Specifically, step S4107 specifically includes the following sub-steps: Step A1: Update the partition sub-sector erasure. Go to step S42 to perform sub-sector erasure starting from the flash address 32'h00200000. Each sector size is 4KB. Read the status register value. The lower two bits being 2’b00 indicates successful erasure, and report the erasure success flag; Step A2: Condition judgment for updating the partition sub-sector erasure. When erase_update_area_ok = 1, the update of the partition sub-sector erasure is successful, go to step A3; when erase_update_area_ok = 0, the update of the partition sub-sector erasure fails, go to step S4113; Step A3: Update the partition page programming. Go to step S42 to perform page programming starting from the flash address 32'h00200000. Each page size is 256 bytes. Read the status register value. The lower two bits being 2’b00 indicates successful programming; Step A4: Condition judgment for updating the partition page programming. When program_update_area_ok = 1, the update of the partition page programming is successful, go to step A5; when program_update_area_ok = 0, the update of the partition page programming fails, go to step S4113; Step A5: Page programming success count. When the page programming success flag is received, cnt_p_pages = cnt_p_pages + 1; Step A6: Condition judgment for page programming success count. When cnt_p_pages < 16, the update of the partition page programming is successful, go to step A3; when cnt_p_pages >= 16, the update of the partition page programming fails; Step A7: Condition judgment for burning the last packet of data. When flag_data_last = 1, it means the upgrade data burning is completed, update the data burning completion, and go to step S4108; when flag_data_last = 0, it means the upgrade data is not the last packet, and it is necessary to continue to request burning, and return to step A1.

[0017] The beneficial effects of the present invention are as follows: The present invention adopts an efficient FPGA online upgrade method based on hardware implementation. In terms of flexible processing, the upgrade baud rate and the variable number of bytes per packet are used. In terms of security and reliability, program identification codes and device ID identifications are set. In terms of reducing hardware costs, a design of large and small partitions (a small golden partition and a large update partition) is adopted. In terms of improving efficiency, an alternating control process of erasing 4K bytes of sub-sectors in the update partition and page writing is adopted, and flexible configuration is achieved in terms of calculation time and resources, making engineering applications efficient and reasonable.

[0018] This solution adopts an FPGA online upgrade strategy with variable upgrade baud rate and number of bytes per packet, setting program identification codes and device ID identifications, a design of large and small partitions (a small golden partition and a large update partition), and an alternating operation of erasing 4K bytes of sub-sectors in the update partition and writing. By using a variable upgrade baud rate and number of bytes per packet, a suitable baud rate and number of bytes per packet can be selected according to the actual application scenario, making the usage scenario more flexible and changeable, with adjustable space and better adaptation to more systems. By setting program identification codes and device ID identifications, the matching error of incorrect program burning in the device is prevented, greatly improving the security and reliability of online upgrade. The upgrade adopts a design of large and small partitions to reduce the program storage space and lower the hardware flash cost. By adopting an alternating operation design of erasing 4K bytes of sub-sectors and writing, the time interval is fully utilized, the waiting time is reduced, the erasing time for unused flash areas is saved, the upgrade efficiency is improved, and the upgrade time is reduced. Brief Description of the Drawings

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on the structures shown in these drawings.

[0020] Figure 1 It is the flowchart of FPGA online upgrade in the embodiment of the present invention; Figure 2 It is the flowchart of upgrade parameter parsing and processing in the embodiment of the present invention; Figure 3 It is the flowchart of serial data serial-to-parallel processing in the embodiment of the present invention; Figure 4 It is the flowchart of Chinese-English processing during upgrade in the embodiment of the present invention; Figure 5 It is the flowchart of host computer monitoring protocol parsing in the embodiment of the present invention; Figure 6 It is the flowchart of judging the program identification code during upgrade in the embodiment of the present invention; Figure 7 It is the data cache distribution control flow chart in the embodiment of the present invention; Figure 8 It is the host computer handshake flow chart in the embodiment of the present invention; Figure 9 It is the SPI upgrade processing flow chart in the embodiment of the present invention; Figure 10 It is the SPI upgrade programming logic control flow chart in the embodiment of the present invention; Figure 11 It is the update partition sub-sector erasure and page programming alternating control flow chart in the embodiment of the present invention. Detailed implementation manners

[0021] To make the objectives, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. Components of the embodiments of the present invention generally described and illustrated in the figures herein may be arranged and designed in a variety of different configurations.

[0022] It should be noted that: like reference numerals and letters denote like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.

[0023] The following will be described in detail in conjunction with the attached Figures 1 to 11 , some implementation manners of the present invention will be described in detail. Without conflict, the following embodiments and the features in the embodiments may be combined with each other.

[0024] The present invention provides an efficient FPGA online upgrade method based on hardware implementation. In a specific embodiment, the online upgrade specifically includes the following basic steps: Upgrade parameter parsing processing; Serial port data serial-to-parallel reception processing; Upgrade Chinese-English processing; SPI upgrade processing.

[0025] In this embodiment, the specific process is as Figure 1 shown, and the following will describe the entire implementation steps in detail.

[0026] Step 1: Parse the parameter information sent by the host computer, as shown in Figure 2 . Go to Step 1.1.

[0027] Step 1.1: Deserialize the serial port data, go to Step 1.2; Step 1.2: Parse the deserialized serial port data according to the host computer transmission protocol, go to Step 1.3; Step 1.3: Parse and extract parameter information according to the protocol, including information such as the serial port baud rate and the data packet byte data, and proceed to Step 1.4; Step 1.4: After extracting the parameters, frame according to the protocol to handshake with the host computer, return that the parameter extraction is successful, and proceed to Step 1.5; Step 1.5: Serialize the returned byte data string and proceed to Step 2.

[0028] Step 2: Receive the upgrade data sent by the host computer monitoring for modifying parameters, and perform serial-to-parallel parsing, as shown in Figure 3 shown. Proceed to Step 2.1.

[0029] Step 2.1: Configure the baud rate parameter and the packet data byte count parameter of the upgrade data, and proceed to Step 2.2; Step 2.2: Perform data deserialization processing and proceed to Step 2.3; Step 2.3: Extract the upgrade data bytes and proceed to Step 3; Step 2.4: After extracting the upgrade data, frame according to the protocol to handshake with the host computer, return that the upgrade data extraction is successful, and proceed to Step 2.5; Step 2.5: Serialize the returned upgrade data bytes and proceed to Step 2.1.

[0030] Step 3: Perform upgrade Chinese-English processing, as shown in Figure 4 shown. Proceed to Step 3.1.

[0031] Step 3.1: Parse the host computer monitoring protocol, and parse the data according to the protocol, as shown in Figure 5 shown. Proceed to Step 3.1.1; Step 3.1.1: Receive the data frame header according to the protocol. When receiving the data 24’H EB_90_87, generate a valid enable for the data frame header, generate a byte counter, count the parsed bytes and perform data parsing, and proceed to Step 3.1.2; Step 3.1.2: Receive the frame length of 2 bytes according to the byte counter and proceed to Step 3.1.3; Step 3.1.3: Receive 1 byte of the frame data ID according to the byte counter. If the received byte is 8’H 55, it means the program identification code sent by the host computer. If the received byte is 8’H AA, it means FPGA programming. Judge and parse the received data according to the identification code, and proceed to Step 3.1.4; Step 3.1.4: Receive 4 bytes of the total packet count according to the byte counter, indicating the total number of data packets transmitted, and proceed to Step 3.1.5; Step 3.1.5: Receive 4 bytes of the current packet count according to the byte counter, indicating the current data packet number being transmitted, and proceed to Step 3.1.6; Step 3.1.6: According to the byte counter, receive 2 bytes of data length, indicating the number of valid bytes of the upgrade data in this data packet. Pad with zeros for insufficient data and perform framing parsing on the sent data, then go to Step 3.1.7; Step 3.1.7: According to the byte counter, receive 4096 bytes of upgrade solidification data. Parse the valid upgrade data based on the number of bytes per sub-packet in Step 1 and the number of valid bytes per packet transmitted in Step 3.1.6, then go to Step 3.1.8; Step 3.1.8: According to the byte counter, receive 2 bytes of data checksum, then go to Step 3.1.9; Step 3.1.9: According to the byte counter, receive the data frame tail 16’H ED_03, then go to Step 3.1.10; Step 3.1.10: Calculate the received data checksum, then go to Step 3.1.11; Step 3.1.11: Compare the received data checksum with the calculated received data checksum. When the checksums are consistent, give a checksum passed flag and go to Step 3.1.12; when the checksums are inconsistent, give a checksum failed flag and go to Step 3.4 Step 3.1.12: Parse the received data according to the checksum passed flag, then go to Step 3.1.13; Step 3.1.13: Perform conditional judgment on the received data frame ID. If FRAME_ID = 8’H 55, go to Step 3.2; if FRAME_ID = 8’H AA, go to Step 3.3; if FRAME_ID is other values, give an illegal frame data flag and go to Step 3.4.

[0032] Step 3.2: Judge the upgrade program identification code, as shown in Figure 6 shown, then go to Step 3.2.1; Step 3.2.1: Based on the frame data FRAME_ID parsed in Step 3.1.3, judge whether FRAME_ID = 8’H 55. If so, give a program identification code judgment extraction flag, extract the program identification code, and go to Step 3.2.2; if not, give a program error flag and go to Step 3.4; Step 3.2.2: Extract the program identification code BIN_MARK according to the parsed data, then go to Step 3.2.3; Step 3.2.3: Judge whether BIN_MARK = 32’H 5555. If so, give a program identification code judgment correct flag and go to Step 3.3; if not, give a program error flag and go to Step 3.4.

[0033] Step 3.3: Control the data cache distribution, as shown in Figure 7 shown, then go to Step 3.3.1; Step 3.3.1: Concatenate the received upgrade data. Continuously receive 4 bytes of upgrade data and concatenate them into a 32-bit data, then go to Step 3.3.2; Step 3.3.2: Cache the concatenated data in the RAM. Distribute it page by page according to the request. Each page has 256 bytes of data. Generate a flag indicating that the caching is complete based on the write address, then go to Step 3.3.3; Step 3.3.3: Generate a packet counter cnt_bytes based on the flag indicating that the caching is complete, then go to Step 3.3.4; Step 3.3.4: Make a conditional judgment on the packet counter cnt_bytes. When cnt_bytes < 4, go to Step 3.3.4.1; when cnt_bytes >= 4, go to Step 3.3.4.2; Step 3.3.4.1: Perform flash paged programming, then go to Step 4. Wait for the flag indicating successful page programming, then go to Step 3.3.5; Step 3.3.4.2: Give a flag indicating that the cache RAM is full, then go to Step 3.3.7; Step 3.3.5: Generate a page programming distribution counter cnt_pages based on the flag indicating successful page programming, then go to Step 3.3.6; Step 3.3.6: Make a conditional judgment on the page programming distribution counter cnt_pages. When cnt_pages < 16, request the distribution of the next page of data and go to Step 3.3.2. When cnt_pages >= 16, generate a flag indicating that the caching data distribution is complete and go to Step 3.3.7; Step 3.3.7: Conduct comprehensive processing of the distributed data. When the flags of the cache RAM, the caching data distribution completion flag, and the sub-sector programming completion flag are all valid, request the next packet of data and go to Step 3.4.

[0034] Step 3.4: Perform handshake with the host computer. Report whether the data reception is successful or failed, whether the program programming is successful or failed, and the current number of programmed pages, etc., according to the reported status, and request the next packet of data, etc. See Figure 8 as shown, then go to Step 3.4.1; Step 3.4.1: Send a 3-byte data frame header 24’H EB_90_88 according to the host computer handshake protocol. Then go to Step 3.4.2; Step 3.4.2: Send the status of the previous packet of data in one byte. When the verification is successful, report that the transmission data is successful, and set the status word to 8'H 01; when the verification fails, report that the transmission data fails, and set the status word to 8'H 00; when the data is illegal, report that the transmission data fails, and set the status word to 8'H 00; when the burn failure flag is pulled high, report that the burn data fails, and set the status word to 8'H AA; when the page burn success flag is pulled high, report that the burn data is successful, and set the status word to 8'H 10; when the burn is completed and the flag is pulled high, report that the burn data is completed, and set the status word to 8'H 55. Go to Step 3.4.3; Step 3.4.3: Send the current packet count in 4 bytes, and report the current packet number sent according to the burn success flag. Go to Step 3.4.4; Step 3.4.4: Calculate the verification of the data to be sent and send the data verification value. Go to Step 3.4.5; Step 3.4.5: Send the data frame tail 16'H EB_03 according to the host computer handshake protocol. Go to Step 2.4.

[0035] Step 4: SPI upgrade processing. The SPI upgrade processing flow chart is shown in Figure 9 as follows. Go to Step 4.1.

[0036] Step 4.1: SPI upgrade programming logic control. The processing flow chart is shown in Figure 10 as follows. Go to Step 4.1.1; Step 4.1.1: Initialization operation. Go to Step 4.2 to initialize the flash. Wait until the initialization status is reached, and then go to Step 4.1.2; Step 4.1.2: Initialization status condition judgment. When intial_ok = 1, the initialization is successful, and go to Step 4.1.3; when intial_ok = 0, the initialization fails, and go to Step 4.1.13; Step 4.1.3: Device ID detection. Go to Step 4.2 to read the flash device ID. After the flash is successfully read, compare it with the built-in ID in the program. If they are the same, report the verification success flag. Go to Step 4.1.4; Step 4.1.4: Condition judgment for device ID detection. When id_check_ok = 1, the device ID verification is successful, and go to Step 4.1.5; when id_check_ok = 0, the device ID verification fails, and go to Step 4.1.13; Step 4.1.5: Erase the key switch word. Go to Step 4.2 to erase the flash address 32'h00000FFC. Read the status register value. If the low two bits are 2'b00, it means the erasure is successful, and report the erasure success flag. Go to Step 4.1.6; Step 4.1.6: Conditional judgment for erasing critical switch words. When erase_switch_word_ok = 1, the critical switch words are successfully erased, and proceed to Step 4.1.7; when erase_switch_word_ok = 0, the erasure of critical switch words fails, and proceed to Step 4.1.13; Step 4.1.7: Update the alternate control of partition sub-sector erasure and page programming. The processing flow is shown in Figure 11 the following figure. Proceed to Step 4.1.7.1.

[0037] Step 4.1.7.1: Update the partition sub-sector erasure. Proceed to Step 4.2 to perform sub-sector erasure starting from the flash address 32'h00200000. Each sector size is 4KB. Read the status register value. If the lower two bits are 2'b00, it indicates successful erasure, and report the erasure success flag. Proceed to Step 4.1.7.2; Step 4.1.7.2: Conditional judgment for updating the partition sub-sector erasure. When erase_update_area_ok = 1, the update of the partition sub-sector erasure is successful, and proceed to Step 4.1.7.3; when erase_update_area_ok = 0, the update of the partition sub-sector erasure fails, and proceed to Step 4.1.13; Step 4.1.7.3: Update the partition page programming. Proceed to Step 4.2 to perform page programming starting from the flash address 32'h00200000. Each page size is 256 bytes. Read the status register value. If the lower two bits are 2'b00, it indicates successful programming. Proceed to Step 4.1.7.4; Step 4.1.7.4: Conditional judgment for updating the partition page programming. When program_update_area_ok = 1, the update of the partition page programming is successful, and proceed to Step 4.1.7.5; when program_update_area_ok = 0, the update of the partition page programming fails, and proceed to Step 4.1.13; Step 4.1.7.5: Page programming success count. When the page programming success flag is received, cnt_p_pages = cnt_p_pages + 1, and proceed to Step 4.1.7.6; Step 4.1.7.6: Conditional judgment for page programming success count. When cnt_p_pages < 16, the update of the partition page programming is successful, and proceed to Step 4.1.7.3; when cnt_p_pages >= 16, the update of the partition page programming fails, and proceed to Step 4.1.7.7; Step 4.1.7.7: Judgment on the condition for burning the last packet of data. When flag_data_last = 1, the upgrade data burning is completed and the update data burning is completed. Proceed to Step 4.1.8. When flag_data_last = 0, the upgrade data is not the last packet and it is necessary to continue to request burning. Proceed to Step 4.1.7.1.

[0038] Step 4.1.8: Update the partition verification. Proceed to Step 4.2 to start the program for reading and writing from the flash address 32'h00200000, perform CRC verification, proceed to Step 4.3, wait for the verification to succeed, report that the verification of the partition is successful, and proceed to Step 4.1.9. Step 4.1.9: Judgment on the condition for updating the partition verification. When check_update_area_ok = 1, the update of the partition verification is successful. Proceed to Step 4.1.10. When check_update_area_ok = 0, the update of the partition verification fails. Proceed to Step 4.1.13. Step 4.1.10: Program the switch keyword. Proceed to Step 4.2 to program the flash address 32'h00000FFC and write its value as 32'hAA995566. Read the value of the status register. If the lower two bits are 2’b00, it indicates that the erasure is successful. Report the programming success flag. Proceed to Step 4.1.11. Step 4.1.11: Judgment on the condition for programming the switch keyword. When program_switch_word_ok = 1, the programming of the switch keyword is successful. Proceed to Step 4.1.12. When program_switch_word_ok_ok = 0, the programming of the switch keyword fails. Proceed to Step 4.1.13. Step 4.1.12: Give the burning completion flag and set program_ok to 1. Proceed to Step 3.4.

[0039] Step 4.1.13: Combine the failure flags of each step, give the burning failure flag, and set program_failure to 1. Proceed to Step 3.4. Step 4.2: Serialize one byte of data controlled by the SPI upgrade logic through the SPI, send it to the flash through the SPI interface for flash reading and writing operations; read the flash status through the SPI interface, byteify the serial data, and send it to the SPI upgrade logic control processing module. Proceed to Step 4.1. Step 4.3: Perform CRC verification according to the look-up table. After the verification is completed, give the verification success flag and proceed to Step 4.1.8.

[0040] In this embodiment, the main technical points of this solution include the following: 1. Upgrade parameter parsing and processing. Through the default baud rate of 115200 of the host computer, the upgrade baud rate and the parameter of the upgrade sub-packet byte count are sent down. After receiving the data parameter, the host computer is sent back a successful flag for receiving the parameter. 2. For the data sent down by the host computer to modify the parameter, the parameter is adjusted to modify the baud rate and the sub-packet byte count. The serial data received by the host computer is byteified, and the byte data for the handshake between the upgrade and the host computer is serialized.

[0041] 3. Upgrade Chinese-English processing module. After parsing the monitoring protocol of the host computer, it is sent for judging the upgrade program identification code to determine whether it is a program to be burned. If the verification fails, the upgrade program is terminated. After the verification passes, the program is burned; data cache distribution control is carried out, 4K bytes of data are cached, and 256 bytes are burned each time by page, and 16 burns are completed to complete one data cache; the status during the upgrade shakes hands with the host computer to send back the upgrade status and request the upgrade data.

[0042] 4. SPI upgrade processing. Through the SPI upgrade programming logic control, the on-line upgrade of the FPGA is realized. The interaction with the flash during the upgrade is realized through the SPI interface. After the SPI serial-parallel processing of the data, it interacts with the SPI upgrade writing logic control. After the upgrade is completed, the upgrade data in the flash is subjected to CRC verification. After the comparison is successful, a burn completion flag is given, otherwise a burn failure is sent back to the host computer.

[0043] The following is a detailed description of each attached figure: Figure 2 It is the flowchart of the upgrade parameter parsing and processing. It can be seen from the figure that first, the serial port data is deserialized, secondly, the data is parsed according to the protocol, thirdly, the parameter is extracted, then the parameter extraction is successful according to the protocol framing and the data is sent back, and finally, the byte data is serialized and the sent-back information is sent to the host computer.

[0044] Figure 3 It is the flowchart of the serial port data serial-parallel processing. It can be seen from the figure that first, the serial port upgrade baud rate parameter is configured, secondly, the serial port data is deserialized, thirdly, the byte upgrade data is obtained, then the deserialized byte data is sent to the upgrade Chinese-English processing module for upgrade processing, waiting for the handshake signal to be sent back and then the handshake information of the host computer is sent back, and finally, the sent-back information is serialized and sent to the host computer.

[0045] Figure 4 It is the flowchart of the upgrade Chinese-English processing. It can be seen from the figure that first, the host computer protocol is parsed, secondly, the upgrade program identification code is judged, then the data cache distribution control is carried out, and finally, the host computer shakes hands.

[0046] Figure 5 It is the implementation flowchart of the host computer monitoring protocol parsing. This figure describes the entire processing flow. Specifically, there are the following processing flows: 1. Parse the frame header, frame length, frame ID, total number of data packets, current packet, upgrade data, checksum, and frame tail according to the protocol; 2. Calculate the checksum value based on the parsed data; 3. Compare the calculated checksum value with the received checksum value. If they are inconsistent, indicate checksum failure and return a transmission failure to the host computer; if they are consistent, give a checksum success flag and return a successful transmission to the host computer; 4. Extract the valid upgrade data and parameters based on the checksum success flag; 5. Judge according to the frame ID. When the frame ID is 8'H55, perform program identification code judgment; when the frame ID is 8'HAA, perform upgrade data parsing; when the frame ID is other values, return an illegal data flag to the host computer and return a data transmission failure according to the flag.

[0047] Figure 6 It is the implementation flow chart for upgrade identification code judgment. As can be seen from the figure, first judge according to the frame ID. When the frame ID is 8'H55, extract the program identification code, otherwise report a program error and return an upgrade failure to the host computer; secondly, extract the program identification code; then perform program identification code judgment. If they are consistent, proceed to the next step of the upgrade, otherwise report a program error and return an upgrade failure to the host computer; finally, give a program correct flag and return a request for the next data packet to the host computer.

[0048] Figure 7 It is the implementation flow chart for data cache distribution control. This figure describes the entire processing flow, and specifically has the following processing flows: 1. Concatenate one packet of byte data of the upgrade data, 4 bytes into 32-bit data, and cache it in the RAM; 2. For the upgrade data cache, control the reading and writing of data from the RAM through the read and write addresses. The RAM has a bit width of 32 bits and a depth of 1024; 3. After caching 4 packets of data, perform data split and flash writing. Each page is flashed with 256 bytes, and 16 pages are flashed. After the cached data is flashed, request the next data distribution; the key steps include: data packet counting, data packet judgment, paged flash writing, and distribution page counting; 4. Comprehensive processing of the distributed data. Combine the RAM full flag, the cached data distribution completion flag, and the sub-sector flash writing completion flag for comprehensive judgment to give a request for the next data packet distribution.

[0049] Figure 8 It is the implementation flow chart for host computer handshake. This figure describes the entire processing flow, and specifically has the following processing flows: 1. Frame the data according to the protocol and send the frame header, status of the previous data packet, count of the last successfully written packet, checksum, and frame tail; 2. Report the status of the previous packet of data according to the external status information.

[0050] Figure 9 It is the flow chart of SPI upgrade processing. It can be seen from the figure that first, the SPI upgrade programming logic is controlled, then the SPI serial-parallel reception is processed, and finally the programming program is read from the flash for CRC verification.

[0051] Figure 10 It is the implementation flow chart of data cache distribution control, which describes the entire processing flow. There are the following specific processing flows: 1. Initialize, then judge the initialization completion flag. If successful, proceed to the next device ID detection; otherwise, the upgrade fails. 2. Detect the device ID, then judge the device ID detection success flag. If the detection is successful, proceed to the next step of erasing the key switch word; otherwise, the upgrade fails. 3. Erase the key switch word, then judge the erasure success flag of the key switch word. If the erasure is successful, proceed to the next step of alternately controlling the erasure of the update partition sub-sector and page programming; otherwise, the upgrade fails. 4. Alternately control the erasure of the update partition sub-sector and page programming. After completion, check the update partition. 5. Check the update partition, then judge the check update partition success flag. If the verification is successful, proceed to the next step of programming the key switch word; otherwise, the upgrade fails. 6. Program the key switch word, then judge the programming success flag of the key switch word. If the programming is successful, proceed to the next step of upper write completion; otherwise, the upgrade fails. 7. Shake hands with the host computer according to the status information, program upgrade failure, and upgrade completion flag.

[0052] Figure 11 It is the implementation flow chart of alternately controlling the erasure of the update partition sub-sector and page programming, which describes the entire processing flow. There are the following specific processing flows: 1. Erase the update partition sub-sector, then judge the erasure success flag of the update partition sub-sector. If the erasure is successful, proceed to the next step of update partition page programming; otherwise, the upgrade fails. 2. Perform update partition page programming, then judge the update partition page programming success flag. If the page programming is successful, proceed to the next step of page programming counting; otherwise, the upgrade fails. 3. Count the successful page programming. According to the page programming success flag, perform cumulative counting, and then judge whether the cumulative number of pages is less than 16 pages. If so, request the next page distribution; if the cumulative number of pages is greater than or equal to 16 pages, perform comprehensive analysis. 4. Comprehensively analyze and judge whether the data is the last packet of data. If so, raise the write completion flag and shake hands with the host computer to report the write completion; otherwise, request the erasure of the next sub-sector.

[0053] The present invention adopts a design with dynamically controllable upgraded data baud rate, which can flexibly configure the upgraded baud rate according to requirements and the resource situation of the FPGA. The baud rate satisfies 115200 <= Bad <= 312500, and all are valid configurations of the parameter Bad. The closer the Bad value is to 3125000, the faster the processing speed, but the greater the resource consumption. Therefore, the parameter Bad can be flexibly configured according to the resource situation of the hardware to achieve a trade-off between resources and speed.

[0054] The upgraded data packet byte length can be optionally designed, and the upgraded data packet byte length can be flexibly configured according to requirements and the resource situation of the FPGA. The data packet byte length satisfies 128 <= data_Bytes_len <= 4096, and all are valid configurations. The closer the data_Bytes_len is to 4096, the shorter the waiting time for upgraded packets and the faster the upgrade time, but the more cache RAM resources are required for the upgraded data. Therefore, this scheme can flexibly configure the value of data_Bytes_len according to the resource situation of the hardware to achieve a trade-off between resource consumption and upgrade speed.

[0055] The sampling upgrade program identification code BIN_MARK is designed. By adding a program identification code to the BIN file, when the program identification codes are inconsistent, the upgrade process is terminated to prevent program errors caused by accidentally burning the program of other models into this hardware. Therefore, setting the program identification code improves the security and reliability of online upgrade.

[0056] The design of device ID identification is adopted. The ID of the FLASH is read for ID comparison. After the ID passes, flash programming is performed. When they are inconsistent, the upgrade process is terminated to prevent matching errors caused by accidentally burning the program into other hardware devices. Therefore, setting the design of device ID identification improves the security and reliability of online upgrade. The design of flash size partitioning is adopted. The golden partition of the flash is made smaller, which can be set to 2MB and can be even smaller according to the actual situation. This partition runs the online upgrade golden upgrade applet to ensure that when the update partition has an error, the golden upgrade applet can continue to be loaded for online upgrade. The flash size partitioning design can ensure that FPGA configuration programs of the same size can be stored in a smaller flash. Therefore, this design can use a smaller flash according to the selection to reduce the hardware cost.

[0057] Adopt the design of alternating erasure and programming operations for 4K-byte sub-sectors. This design performs ping-pong operations. First, erase the 4K-byte sub-sector, perform page programming on the first sub-sector, then erase the 4K-byte sub-sector again, and complete page programming on the second sub-sector. This process continues until the program is completely written. This design realizes the alternating operation of sub-sector erasure and page programming, makes full use of the time interval, reduces the waiting time, saves the erasure time for unused flash areas, improves the upgrade efficiency and reduces the upgrade time.

[0058] Based on the above points, the FPGA online upgrade method implemented by hardware breaks through the problems of slow upgrade time, insecure upgrade program, and excessive flash resources in traditional FPGA online upgrade engineering applications, achieving the results of fast upgrade time and reduced hardware cost (using flash with smaller storage). Therefore, this solution can achieve high online upgrade efficiency, low resource consumption, high reliability, and low supporting hardware cost. In the design, setting the upgrade data baud rate and data byte packet parameters is used to solve the problems of resource consumption and upgrade time, enabling flexible configuration for different hardware and high flexibility in engineering applications. Secondly, in the implementation, program identification code upgrade is adopted to prevent program errors caused by accidentally burning the programs of other models into this hardware; the design of device ID identification is adopted to prevent matching errors caused by accidentally burning the program into other hardware devices, greatly improving the security and reliability of online upgrade. Thirdly, the upgrade adopts the design of large and small partitions to make up for the problem that the flash size required for traditional upgrade is twice the size of the program, which requires a larger storage space. The design of large and small partitions reduces the program storage space and lowers the hardware flash cost. Finally, adopt the design of alternating erasure and programming operations for 4K-byte sub-sectors, make full use of the time interval, reduce the waiting time, save the erasure time for unused flash areas, improve the upgrade efficiency and reduce the upgrade time.

[0059] Therefore, this solution is optimal in terms of upgrade efficiency, resource consumption, upgrade time, and hardware cost, and its implementation is closer to the actual application requirements of the project. The high-efficiency FPGA online upgrade method implemented by hardware can be applied to similar or other products, and this technical means cannot be circumvented.

[0060] For the foregoing embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that this application is not limited by the described action sequence, because according to this application, some steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential for this application.

[0061] In the above embodiments, the basic principles, main features and advantages of the present invention are described. Those skilled in the art should understand that the present invention is not limited by the above embodiments. What is described in the above embodiments and the specification only illustrates the principles of the present invention. Without departing from the spirit and scope of the present invention, any modifications and changes made by those skilled in the art should fall within the protection scope of the appended claims of the present invention.

Claims

1. An efficient FPGA online upgrade method based on hardware implementation, characterized in that: The following steps are involved: Step S1: Upgrade and parse the parameter information sent by the host computer; Step S2: receiving the upgrade data sent by the upper computer monitoring of the parameters modified in step S1, and performing serial-to-parallel parsing processing; Step S3: Upgrade the data into Chinese and English; Step S4: Process the SPI upgrade.

2. The method for efficiently upgrading FPGA online based on hardware implementation as claimed in claim 1, characterized in that: The step S1 comprises the following sub-steps: Step S11: deserializing serial port data; Step S12: parsing the deserialized data of the serial port according to the upper computer transmission protocol; Step S13: extracting parameter information including serial port baud rate and data packet byte data information according to protocol analysis; Step S14: After the parameters are extracted, the upper computer is handshaked according to the protocol frame, and if the parameter extraction is successful, step S15 is performed; Step S15: Serialize the returned byte data and go to step S2.

3. The method for efficiently upgrading FPGA online based on hardware implementation as claimed in claim 1, characterized in that: The step S2 comprises the following sub-steps: Step S21: configuring the baud rate parameter of the upgraded data and the number of bytes of the sub-packetized data; Step S22: data deserialization processing; Step S23: extract the upgrade data bytes and go to step S3; Step S24: After the upgrade data is extracted, the host computer is shaken according to the protocol frame. If the upgrade data is successfully extracted, the process goes to step S25; Step S25: Byte-string the returned upgrade data, and return to step S21.

4. The method for efficiently upgrading FPGA online based on hardware implementation as claimed in claim 2, characterized in that: The step S3 comprises the following sub-steps: Step S31: The host computer monitors the protocol analysis and analyzes the data according to the protocol; Step S32: Determine the upgrade program identification code; Step S33: data cache distribution control; Step S34: The host computer shakes hands and requests the next packet of data based on the reported status reporting data reception success or failure, program burning success or failure and the current number of pages to be burned.

5. The method for efficiently upgrading FPGA online based on hardware implementation as claimed in claim 4, characterized in that: The step S31 further includes the following sub-steps: Step S3101: receiving the data frame header according to the protocol, receiving the 24'H EB_90_87 data, generating a valid enable for the data frame header, generating a byte counter, counting the parsed bytes and performing data parsing; Step S3102: Receive a 2-byte frame length according to the byte counter; Step S3103: According to the byte counter, a 1-byte frame data ID is received. If the received byte is 8'H 55, it means that the host computer sends a program identification code. If the received byte is 8'H AA, it means that the FPGA is being programmed. The received data is analyzed according to the identification code. Step S3104: According to the byte counter, a total packet number of 4 bytes is received, indicating the total number of data packets transmitted; Step S3105: According to the byte counter, a 4-byte current packet number is received, indicating the current number of data packets transmitted; Step S3106: According to the byte counter, a 2-byte data length is received, which indicates the number of valid bytes of the upgrade data in the data packet. If the number is insufficient, zero is added and the data is sent for framing and parsing; Step S3107: according to the byte counter, 4096 bytes of upgrade and curing data are received, and according to the number of bytes of the sub-packets in step S1 and the number of valid bytes of each packet transmitted in step S3106, the valid upgrade data is parsed; Step S3108: receiving 2 bytes of data verification according to the byte counter; Step S3109: according to the byte counter, receive the data frame tail 16'H ED_03; Step S3110: Calculate received data check; Step S3111: Compare the received data checksum and calculate the received data checksum. When the checksums are consistent, a checksum pass flag is given and the process goes to step S3112. When the checksums are inconsistent, a checksum fail flag is given and the process goes to step S34. Step S3112: parsing the received data according to the verification pass flag; Step S3113: Receive data frame ID condition judgment, if FRAME_ID=8'H 55, go to step S32; if FRAME_ID=8'H AA, go to step S33; if FRAME_ID is other values, give a data illegal flag, go to step S34.

6. The method for efficiently upgrading FPGA online based on hardware implementation as claimed in claim 5, characterized in that: The step S32 further comprises the following sub-steps: Step S3201: According to the FRAME_ID parsed in step S3103, determine whether FRAME_ID=8'H 55. If yes, give a program identification code to determine the extraction flag, extract the program identification code, and go to step S3202; if no, give a program error flag, and go to step S34; Step S3202: extracting the program identification code BIN_MARK according to the parsed data; Step S3203: determine if BIN_MARK=32'H 5555. If so, give a program identification code judgment correct flag and go to step S33; if not, give a program error flag and go to step S34.

7. The method for efficiently upgrading FPGA online based on hardware implementation as claimed in claim 6, characterized in that: The step S33 also includes the following sub-steps: Step S3301: splice the received upgrade data, and splice 4 consecutive bytes of data into 32-bit data; Step S3302: Cache the spliced ​​data in the RAM, distribute it by page according to the request, each page has 256 bytes of data, and generate a cache completion flag according to the write address; Step S3303: Generate a data packet counter cnt_bytes according to the cache completion flag; Step S3304: Data packet counter cnt_bytes conditional judgment, when cnt_bytes<4, flash paging is performed, and step S4 is turned to wait for the page programming success flag, and step S3305 is turned to; when cnt_bytes>=4, a cache RAM full flag is given, and step S3307 is turned to; Step S3305: Generate a page burning distribution counter cnt_pages according to the page burning success flag; Step S3306: the page burning distribution counter cnt_pages is judged. When cnt_pages<16, the next page data distribution is requested, and the process goes to step S3302; when cnt_pages>=16, a cache data distribution completion flag is generated, and the process goes to step S3307; Step S3307: Comprehensively process the distributed data, comprehensively analyze the cache RAM flag, cache data distribution completion flag and sub-sector burning completion flag, and when they are all valid, request the next packet of data to proceed, and go to step S34.

8. The method for efficiently upgrading FPGA online based on hardware implementation as claimed in claim 4, characterized in that: The step S34 also includes the following sub-steps: Step S3401: Send a 3-byte data frame header 24'H EB_90_88 according to the host computer handshake protocol; Step S3402: Send a byte of the previous data packet status. When the verification is successful, the data transmission is reported as successful, and the status word is set to 8'H01; when the verification fails, the data transmission is reported as failed, and the status word is set to 8'H00; when the data is illegal, the data transmission is reported as failed, and the status word is set to 8'H 00; when the burning is a failure mark and the high speed is pulled, the burning data failure is reported, and the status word is set to 8'H AA; when the page burning is a success mark and the high speed is pulled, the burning data is reported as successful, and the status word is set to 8'H10; when the burning is completed and the high speed is pulled, the burning data is reported as completed, and the status word is set to 8'H55; Step S3403: Send 4 bytes of current data packet count, and report the current number of packets sent according to the programming success flag; Step S3404: Calculate the checksum of the sent data and send the checksum value of the data; Step S3405: ​​Send the data frame tail 16'HEB_03, and go to step S24.

9. The method for efficiently upgrading FPGA online based on hardware implementation as claimed in claim 8, characterized in that: The step S4 comprises: Step S41: SPI upgrade programming logic control; specifically includes the following sub-steps: Step S4101: Initialization operation, go to step S42 to initialize the flash, wait until the initialization state, and go to step S4102; Step S4102: Initialization status condition judgment; when intial_ok=1, initialization is successful, and go to step S4103; when intial_ok=0, initialization fails, and go to step S4113; Step S4103: Device ID detection, go to step S42 to read the flash device ID, after the flash is read successfully, compare the program built-in ID, and report the verification success flag if they are consistent; Step S4104: Conditional judgment of device ID detection, when id_check_ok=1, the device ID verification is successful, and go to step S4105; when id_check_ok=0, the device ID verification fails, and go to step S4113; Step S4105: Erase the key switch word, go to step S42 to erase the flash address 32'h00000FFC, read the status register value, the lower two bits are 2'b00 indicating a successful erasure, and report an erase success flag; Step S4106: Conditional judgment of erasing the key switch word. When erase_switch_word_ok=1, erasing the key switch word is successful, and the process goes to step S4107; when erase_switch_word_ok=0, erasing the key switch word fails, and the process goes to step S4113; Step S4107: Update the partition sub-sector erasing and page programming alternating control; Step S4108: Update the partition check, go to step S42 to start the read and write program for the flash address 32'h00200000, perform CRC check, go to step S43, wait for the check to succeed, and report the check partition check success; Step S4109: Update partition verification condition judgment, when check_update_area_ok=1, update partition verification is successful, go to step S4110; when check_update_area_ok=0, update partition verification fails, go to step S4113; Step S4110: Program switch keyword, go to step S42 to program the flash address 32'h00000FFC, write its value to 32'hAA995566, read the status register value, the lower two bits are 2'b00 indicating a successful erase, and report a programming success flag; Step S4111: Conditional judgment of programming switch keyword, when program_switch_word_ok=1, the switch keyword programming is successful, and go to step S4112; when program_switch_word_ok_ok=0, the switch keyword programming fails, and go to step S4113; Step S4112: Give a programming completion flag, set program_ok to 1, and go to step S34; Step S4113: synthesize the failure flags of each step, give a programming failure flag, set program_failure to 1, and go to step S34; Step S42: Serialize one byte of data controlled by the SPI upgrade logic through the SPI, and send it to the flash through the SPI interface for flash read and write operations; read the flash status through the SPI interface, byte-process the serial data, and send it to the SPI upgrade logic control processing module; go to step S41; Step S43: Perform CRC check according to the table lookup. After the check is completed, a check success flag is given and go to step S4108.

10. The method for efficiently upgrading FPGA online based on hardware implementation as claimed in claim 9, characterized in that: The step S4107 specifically includes the following sub-steps: Step A1: Update the sub-sector erasing of the partition, go to step S42 to start erasing the sub-sectors at flash address 32'h00200000, each sector size is 4KB, read the status register value, the lower two bits are 2'b00 indicating a successful erasure, and report an erase success flag; Step A2: Update the condition of sub-sector erasing of the partition. When erase_update_area_ok=1, the sub-sector erasing of the partition is successful, and the process goes to step A3. When erase_update_area_ok=0, the sub-sector erasing of the partition fails, and the process goes to step S4113. Step A3: Update the partition page programming, go to step S42 to start page programming at flash address 32'h00200000, each page size is 256 bytes, read the status register value, the lower two bits are 2'b00, indicating successful programming; Step A4: Conditional judgment of updating the partition page programming. When program_update_area_ok=1, the updating of the partition page programming is successful, and the process goes to step A5; when program_update_area_ok=0, the updating of the partition page programming fails, and the process goes to step S4113; Step A5: Page programming success count, when receiving the page programming success flag, cnt_p_pages= cnt_p_pages+1; Step A6: Conditional judgment of page programming success count, when cnt_p_pages<16, the update partition page programming is successful, and go to step A3; When cnt_p_pages>=16, update partition page programming fails; Step A7: Determine the condition for burning the last data packet. When flag_data_last=1, it indicates that the upgrade data burning is completed and the update data burning is completed, and then go to step S4108; when flag_data_last=0, it indicates that the upgrade data is not the last packet and needs to continue to request burning, and then go back to step A1.

Images