CN117873539A - MicroBlaze-based FPGA online upgrading method, system and medium - Google Patents
MicroBlaze-based FPGA online upgrading method, system and medium Download PDFInfo
- Publication number
- CN117873539A CN117873539A CN202311832586.3A CN202311832586A CN117873539A CN 117873539 A CN117873539 A CN 117873539A CN 202311832586 A CN202311832586 A CN 202311832586A CN 117873539 A CN117873539 A CN 117873539A
- Authority
- CN
- China
- Prior art keywords
- value
- field
- data
- checksum
- data packet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 86
- 238000012795 verification Methods 0.000 claims abstract description 50
- 238000012545 processing Methods 0.000 claims abstract description 26
- 238000004422 calculation algorithm Methods 0.000 claims description 12
- 238000004590 computer program Methods 0.000 claims description 9
- 238000004364 calculation method Methods 0.000 claims description 6
- 238000004806 packaging method and process Methods 0.000 claims description 3
- 230000001172 regenerating effect Effects 0.000 claims description 3
- 230000008569 process Effects 0.000 abstract description 16
- 238000005538 encapsulation Methods 0.000 abstract description 2
- 230000005540 biological transmission Effects 0.000 description 10
- 238000004891 communication Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 125000004122 cyclic group Chemical group 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Landscapes
- Detection And Correction Of Errors (AREA)
Abstract
The invention relates to the technical field of FPGA (field programmable gate array) upgrading, in particular to an FPGA online upgrading method, system and medium based on MicroBlaze, wherein MicroBlaze is embedded in an FPGA, and an upper computer converts firmware data into a TLV (time-limit value) format; the upper computer transmits the TLV data packet to MicroBlaze through a UART interface or an ETH interface; the MicroBlaze receives the data packet through an AXI UART LITE interface or an AXI ETH interface and processes the data packet; the MicroBlaze writes the analyzed data into FLASH through an AXI SPI interface; according to the invention, through the encapsulation and processing of the TLV format data and the verification before and after the writing of the data, the accuracy and the integrity of the data are ensured, so that the reliability of the upgrading process is improved.
Description
Technical Field
The invention relates to the technical field of FPGA (field programmable gate array) upgrading, in particular to an FPGA online upgrading method, system and medium based on MicroBlaze.
Background
In the field of Field Programmable Gate Arrays (FPGAs), FPGAs are an integrated circuit with high flexibility and reprogrammable features, and are widely used in digital circuit design. Because of the rapid development of technology, the updating and optimizing of the FPGA function becomes normal, so the importance of the online upgrading technology is increasingly highlighted. Conventional FPGA upgrade methods often involve shutdown or reconfiguration procedures, which can cause inconveniences in applications that require a system to run continuously.
In conventional FPGA upgrade techniques, the upgrade process tends to be complex and inefficient. These methods typically require physical access to the FPGA device or reconfiguration without optimization. This approach not only increases the time of the upgrade process, but may also affect the stability and reliability of the system in some cases.
In response to these challenges, the industry is continually exploring more efficient and reliable online upgrade methods. This includes optimizing memory and storage usage by improving data transfer and handling, and improving data security and error handling during upgrades. Through the development of the technologies, the aim is to realize faster and safer online upgrading of the FPGA and simultaneously reduce the interference to the system operation as much as possible.
Disclosure of Invention
The technical problem to be solved by the invention is that the traditional FPGA upgrading process is often complex and low in efficiency, and the invention aims to provide an FPGA online upgrading method, system and medium based on MicroBlaze, so that the online upgrading of the FPGA is realized efficiently and stably without shutdown.
The invention is realized by the following technical scheme:
an FPGA online upgrading method based on MicroBlaze is characterized in that a MicroBlaze processor soft core is embedded in an FPGA, and the MicroBlaze is connected with an upgrading interface of the FPGA by adopting an AXI UART LITE interface or an AXI ETH interface, and is communicated with a FLASH of the FPGA through an ASI SPI interface;
the online upgrading method comprises the following steps:
firstly, the upper computer packages firmware data into a data packet in a TLV format;
secondly, the upper computer transmits the TLV data packet to the MicroBlaze through an AXI UART LITE interface or an AXI ETH interface;
thirdly, receiving the data packet by the MicroBlaze through an AXI UART LITE interface or an AXI ETH interface, and processing the data packet;
and fourthly, writing the analyzed data into FLASH by the MicroBlaze through an AXI SPI interface.
Specifically, in the first step, the method for converting firmware data into TLV format by the upper computer includes:
determining the sizes of a Type field, a Length field and a Value field, wherein the Type is a Type identifier of a data block, the Length is the Length of the data block, the Value is the actual content of the data block, and the Value of the Length field represents the byte Length of the Value field data;
determining the data of each field according to the firmware data, and constructing a data structure through a structural body or class;
filling fields corresponding to the firmware data into a data structure;
serializing the Type field, the Length field and the Value field into a byte stream;
generating a checksum field, adding the checksum field at the tail end of the byte stream, and obtaining a TLV data packet after packaging;
carrying out hash calculation on the TLV data packet through a hash algorithm to generate a hash value with a fixed length, and taking the hash value as a secondary packet of the expansion data packet and the TLV data packet to obtain a final TLV data packet;
checking the TLV data packet, and regenerating and checking the TLV data packet if the checking fails; and if the verification is successful, the TLV data packet is sent.
Optionally, the method for checking the TLV data packet includes:
determining a CRC-32 polynomial for verification;
initializing a CRC register: CRC =0xFFFFFFFF;
the highest 8 bits of the CRC register are exclusive-ored with the current byte before processing the bytes of the TLV packet: CRC (cyclic redundancy check) high :＝CRC high B, wherein CRC high The highest 8 bits of the CRC register, B is the current byte of the data block;
shifting the CRC register one bit to the left, and performing exclusive OR operation on the CRC register and the binary representation of the CRC polynomial if the highest bit of the shifted CRC register is 1: if (CRC &0x 80000000. Noteq.0) the nCRC: =CRC 0x04C11DE7; if the highest bit of the CRC register after shifting is 0, not performing operation;
finishing the iterative processing of all bytes of the Value field in the TLV data packet;
exclusive or the CRC register with 0 xFFFFFFFF: CRC =CRC =0 xFFFFFFFF, resulting in a final CRC checksum;
comparing the CRC checksum field, and if the CRC checksum is equal to the checksum field, checking successfully; if the CRC checksum is not equal to the checksum field, the check fails.
Specifically, in the third step, the method for processing the data packet includes:
storing the received TLV data packet into a buffer area;
reading a Type field from the starting position of the buffer area, and verifying whether the Type field is a predefined valid Type;
reading a Length field after the Type field from the buffer area, and verifying whether the Length field is reasonable or not;
reading the Value field with the corresponding Length from the buffer area according to the Value of the Length field, and verifying the integrity of the Value field;
calculating a hash value and a checksum of the received TLV data packet, and verifying the hash value and the checksum;
if the Type field, the Length field, the Value field, the hash Value and the checksum are all verified to pass, the TLV data packet is determined to be complete; if either of the packets fails to check, the TLV packet is discarded and retransmission is requested.
Specifically, the method for verifying the Type field includes:
matching and judging the extracted Type field with an effective Type value list TypesList defined in the system;
if the Type E Type List, the verification is successful, the Type field in the TLV data packet is valid, and a Type valid Boolean value is returned;
if it isThe verification fails, the Type field in the TLV data packet is invalid, and the boolean value with the invalid Type is returned;
the method for verifying the Length field comprises the following steps:
determining the maximum data length MaxSize allowed by the TLV data packet;
determining the residual data size Sizeoff of the Type field and the Length field removed in the TLV data packet;
if (Length is more than or equal to 0 and less than or equal to MaxSize). Lambda. (Length is more than or equal to Sizeoff), the verification is successful, and a valid Boolean value of Length is returned;
otherwise, indicating that the verification fails, and returning a Boolean value with invalid Length;
the method for verifying the Value field comprises the following steps:
determining the length LengthOf (Value) of the actual received Value field;
judging whether the Length of the Value field actually received is matched with the expected Length designated by the Length field;
checking the Value field according to the Type field;
if (LengthOf (Value) =expectedlength) a CheckFormat (Value) a CheckContent (Value), the verification is successful, and a boolean Value valid for Value is returned; wherein, expectedLength represents the expected Length specified by the Length field, checkFormat (Value) represents the format of checking Value field according to the Type field definition, checkContent (Value) checks the content of Value field according to the Type field definition;
otherwise, the verification fails, and a Value invalid Boolean Value is returned;
the method for verifying the checksum comprises the following steps:
extracting a checksum field CalculateChecksum (Value) in the TLV data packet;
calculating to obtain CRC check sum received dCocksum in the TLV data packet;
if CalculateChecksum (Value) =receivedchecksum, the verification is successful, and the boolean value with the checksum valid is returned;
otherwise, the verification fails, and the Boolean value with invalid checksum is returned.
The method for verifying the hash value comprises the following steps:
extracting a hash value CalrulateHash in the expanded data packet;
calculating a hash value receivedsash of the received TLV data packet through the same hash algorithm;
if calcuatiehash=receivedhash, the verification is successful, and a boolean value with a valid hash value is returned;
otherwise, the verification fails, and the Boolean value with invalid hash value is returned.
Specifically, if the valid boolean Value of the Type, the valid boolean Value of the Length, the valid boolean Value of the Value, the valid boolean Value of the hash Value and the valid boolean Value of the checksum exist at the same time, determining that the TLV data packet is correct; if any Type invalid Boolean Value, length invalid Boolean Value, value invalid Boolean Value, hash Value invalid Boolean Value and checksum invalid Boolean Value exist, determining that the TLV data packet is wrong, discarding and requesting retransmission.
Specifically, in the fourth step, the method for writing the parsed data into the FLASH includes:
segmenting the analyzed data according to the page size or the programming unit of the FLASH memory to obtain a plurality of data segments;
before writing each data segment, calculating the checksum of the segment;
writing each data segment into a corresponding address of the FLASH memory;
reading back the written data segment, calculating the checksum again, and comparing the newly calculated checksum with the original checksum;
if the newly calculated checksum is equal to the original checksum, continuing to write the next data segment; if the newly calculated checksum is not equal to the original checksum, the data segment is rewritten and checksum verification is performed again;
until writing of all the data segments is completed.
Optionally, the method for calculating the checksum is as follows:wherein D represents a data segment to be written into FLASH, 2 n Representing the left shift of the data segment D by n bits, n representing the highest power of the polynomial, P representing the selected CRC polynomial and remainders representing the remainder of the polynomial division.
The FPGA online upgrading system based on MicroBlaze comprises an upper computer and a terminal module, wherein the upper computer sends firmware data for FPGA upgrading to the terminal module, and the terminal module writes the firmware data into a FLASH memory of the FPGA;
the upper computer comprises a memory, a processor and a computer program stored in the memory and capable of running on the processor, wherein the processor executes the computer program to realize the method as claimed in any one of claims 2 or 3;
the terminal module comprises MicroBlaze and a program which is stored in the MicroBlaze and can run, and the MicroBlaze realizes the FPGA online upgrading method based on the MicroBlaze when the MicroBlaze executes the program.
A computer readable storage medium storing a computer program which when executed by a processor implements a MicroBlaze-based FPGA online upgrade method as described above.
Compared with the prior art, the invention has the following advantages and beneficial effects:
according to the MicroBlaze-based FPGA online upgrading method, the MicroBlaze processor soft core is embedded in the FPGA, and the AXI UART LITE interface or the AXI ETH interface is used for communicating with the upper computer, and the steps of TLV format conversion, transmission, processing and writing of firmware data are carried out, so that the optimization of data processing and transmission flows is realized, the safety and stability of the upgraded data are improved, the deployment is rapid, and the reusability is high.
The invention improves the efficiency and the reliability of data transmission through the data encapsulation and the processing of the TLV format, utilizes the AXI UART LITE interface or the AXI ETH interface to carry out data communication, reduces the complexity of a hardware interface and ensures high-speed and stable data transmission.
By checking before and after writing data, the accuracy and the integrity of the data are ensured, thereby improving the reliability of the upgrading process. Finally, the whole online upgrading process can be completed without stopping, and the running efficiency and usability of the FPGA system are obviously improved.
The invention optimizes the online upgrading flow of the FPGA, improves the efficiency and the reliability of the upgrading process, reduces the interference to the system operation, and is particularly suitable for application occasions with higher requirements on the operation time and the system stability.
Drawings
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the invention and together with the description serve to explain the principles of the invention.
Fig. 1 is a schematic flow chart of an FPGA online upgrade based on MicroBlaze according to the present invention.
Fig. 2 is a flow chart illustrating a method for converting firmware data into TLV format according to the present invention.
Fig. 3 is a flow chart of a method of processing a final TLV packet according to the present invention.
Detailed Description
The present invention will be described in further detail with reference to the drawings and embodiments, for the purpose of making the objects, technical solutions and advantages of the present invention more apparent. It is to be understood that the specific embodiments described herein are merely illustrative of the substances, and not restrictive of the invention.
It should be further noted that, for convenience of description, only the portions related to the present invention are shown in the drawings.
Embodiments of the present invention and features of the embodiments may be combined with each other without conflict. The present invention will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.
Example 1
As shown in fig. 1, the embodiment provides an on-line FPGA upgrading method based on MicroBlaze, in which a soft core of a MicroBlaze processor is embedded in an FPGA, and the MicroBlaze is connected with an upgrading interface of the FPGA by adopting an AXI UART LITE interface or an AXI ETH interface, and the MicroBlaze is communicated with a FLASH of the FPGA through an ASI SPI interface; .
First, a MicroBlaze processor is embedded in the FPGA, and MicroBlaze is a soft core processor designed specifically for embedding in Xilinx FPGAs, and is capable of executing software instructions and processing data, just like an independent CPU.
The MicroBlaze is connected with an AXI UART LITE interface or an AXI ETH interface of the FPGA and used for data communication. The AXI UART LITE is a simple universal asynchronous receiving/transmitting interface, and is suitable for communication with low bandwidth requirements; axieth is the interface for ethernet communications. In addition, microBlaze communicates with a FLASH memory of the FPGA through an AXI SPI interface so as to realize reading and writing of data.
The online upgrading method comprises the following steps:
firstly, converting firmware data into a TLV format by an upper computer; the upper computer firstly converts the firmware data into a TLV (Type-Length-Value) format. This format divides the data into three parts: the Type (Type) identifies the kind of the data block, the Length (Length) indicates the size of the data block, and the Value (Value) is the actual content of the data block.
Secondly, the upper computer transmits the TLV data packet to MicroBlaze through a UART interface or an ETH interface; .
Thirdly, receiving the data packet by the MicroBlaze through an AXI UART LITE interface or an AXI ETH interface, and processing the data packet; the processing includes verifying the correctness of the type, length and value of the data packet, ensuring that the received data is complete and error free.
And fourthly, writing the analyzed data into FLASH by the MicroBlaze through an AXI SPI interface. And the MicroBlaze writes the analyzed data into a FLASH memory of the FPGA through an AXI SPI interface. FLASH memory is a non-volatile storage medium for persistent storage of firmware data. MicroBlaze can write data into FLASH efficiently through SPI (serial peripheral interface) protocol.
The method realizes the effective online upgrade of the FPGA firmware by combining the software processing capacity of the MicroBlaze processor and the hardware advantage of the FPGA. Data processing using TLV format improves the structuring and readability of the data, while data transmission over the AXI interface ensures the efficiency and reliability of the process. By the method, the FPGA can be updated on line without stopping, and the method is particularly suitable for application scenes requiring high availability and reliability.
Example two
As shown in fig. 2, a first step in the first embodiment is described in detail, and the method for converting firmware data into TLV format by the upper computer includes:
determining the sizes of a Type field, a Length field and a Value field, wherein the Type is a Type identifier of the data block and is used for identifying the Type or format of the data block; length is the Length of the data block, i.e., the Value of the Length field represents the byte Length of the Value field data; value is the actual content of the data block, including the firmware data that needs to be transferred.
Determining the data of each field according to the firmware data, and constructing a data structure through a structural body or class; from the firmware data, the specific data content of each field (Type, length, value) is determined. This step typically involves using a structure or class to construct an ordered data structure that helps organize and manage the various information in the TLV packets.
Filling fields corresponding to the firmware data into a data structure; the firmware data is populated into the data structure in a predetermined format. This process ensures that the Type, length, and Value fields contain the correct information in preparation for serialization.
Serializing the Type field, the Length field and the Value field into a byte stream; serialization refers to the process of converting a data structure into a series of bytes in order to facilitate transmission during communication.
Generating a checksum field, adding the checksum field at the tail end of the byte stream, and obtaining a TLV data packet after packaging; a checksum field is added at the end of the byte stream. Checksum is an error detection mechanism used to verify the integrity of data during transmission. This field is typically calculated from the content of the byte stream.
Carrying out hash calculation on the TLV data packet through a hash algorithm to generate a hash value with a fixed length, and taking the hash value as a secondary packet of the expansion data packet and the TLV data packet to obtain a final TLV data packet; the hash value calculation is carried out on the TLV data packet of the packet to obtain the corresponding hash value, so that two layers of error detection are provided, data tampering can be prevented to a certain extent, and the safety is improved.
Checking the TLV data packet, and regenerating and checking the TLV data packet if the checking fails; and if the verification is successful, the TLV data packet is sent. The verification of the encapsulated TLV packet is to ensure that no errors occur in the packet during the generation process. If the verification fails (i.e. the checksum does not match), the TLV data packet needs to be regenerated and verified; if the verification is successful, it indicates that the packet is ready for transmission to the MicroBlaze processor.
An embodiment of verification is provided. The method for verifying the TLV data packet comprises the following steps:
determining a CRC-32 polynomial for verification; the CRC-32 check is calculated using a specific polynomial (commonly denoted as 0x04C11DB 7). This polynomial is a standard for the CRC-32 algorithm to generate a 32-bit checksum.
Initializing a CRC register: CRC =0xFFFFFFFF; the CRC register is used to store intermediate and final checksum values during the calculation process.
The highest 8 bits of the CRC register are exclusive-ored with the current byte before processing the bytes of the TLV packet: CRC (cyclic redundancy check) high :＝CRC high B, wherein CRC high The highest 8 bits of the CRC register, B is the current byte of the data block; the exclusive-or operation is a basic bit operation, and when two compared bits are different, the result is 1; when the same, the result is0。
Shifting the CRC register one bit to the left, and performing exclusive OR operation on the CRC register and the binary representation of the CRC polynomial if the highest bit of the shifted CRC register is 1: if (CRC &0x 80000000. Noteq.0) the nCRC: =CRC 0x04C11DB7; if the highest bit of the CRC register after shifting is 0, not performing operation;
repeating the steps until the iteration processing of all bytes of the Value field in the TLV data packet is completed;
exclusive-or the processed CRC register with 0 xFFFFFFFF: CRC =CRC =0 xFFFFFFFF, resulting in a final CRC checksum;
comparing the CRC checksum field, and if the CRC checksum is equal to the checksum field, checking successfully; if the CRC checksum is not equal to the checksum field, the check fails.
In the verification process, the processing of each byte is sequentially carried out, so that the integrity and the accuracy of verification are ensured.
Example III
As shown in fig. 3, the third step of the present embodiment describes a method for processing a TLV packet, including:
storing the received final TLV data packet into a buffer area, and splitting to obtain the TLV data packet and an expansion data packet; from which the original TLV packet and the extended hash value portion are split.
Reading a Type field from the starting position of the buffer area, and verifying whether the Type field is a predefined valid Type;
reading a Length field after the Type field from the buffer area, and verifying whether the Length field is reasonable or not;
reading the Value field with the corresponding Length from the buffer area according to the Value of the Length field, and verifying the integrity of the Value field;
calculating a hash value and a checksum of the received TLV data packet, and verifying the hash value and the checksum; the same checksum hash algorithm is used by the sender and the receiver to ensure proper verification.
If the Type field, the Length field, the Value field, the hash Value and the checksum are all verified to pass, the TLV data packet is determined to be complete; if either of the packets fails to check, the TLV packet is discarded and retransmission is requested.
The Type field defines the data Type in the TLV packet, so its correctness is crucial for subsequent data processing, and the method for verifying the Type field includes:
matching and judging the extracted Type field with an effective Type value list TypesList defined in the system; the typelist should be updated periodically according to the application's requirements and changes in data format to ensure the accuracy of the verification, and the list contains all the Type values that are considered valid and acceptable.
If the Type E Type List, the verification is successful, the Type field in the TLV data packet is valid, and a Type valid Boolean value is returned;
if it isAnd indicating that the verification fails, wherein a Type field in the TLV data packet is invalid, and returning a boolean value with the invalid Type. If the Type field check fails, the packet is discarded, an error log is recorded, or the sender is notified.
The method for verifying the Length field comprises the following steps:
determining the maximum data length MaxSize allowed by the TLV data packet; in order to ensure that the size of the data packet is within acceptable and processing limits, the maximum data length allowed by the TLV data packet is preset by the system, and the value of MaxSize depends on the requirements of the application and the processing capacity of the system.
Determining the residual data size Sizeoff of the Type field and the Length field removed in the TLV data packet; after removing the Type field and the Length field, the remaining data size represents the actual Value field size.
If (Length is more than or equal to 0 and less than or equal to MaxSize). Lambda. (Length is more than or equal to Sizeoff), the verification is successful, and a valid Boolean value of Length is returned; if the value of the Length field is between 0 and MaxSize, and does not exceed sizeoff, this means that the declared Length is consistent with both the maximum Length limit and the actual data Length,
if the value of the Length field is out of the range or is inconsistent with the actual data Length, indicating that verification fails, returning a Boolean value invalid by the Length; if the Length field check fails, the packet is discarded, an error notification is sent, or a log is recorded, etc.
The method for verifying the Value field ensures that the Value part in the TLV (Type-Length-Value) data packet meets both the Length requirement and the content requirement, and the method for verifying the Value field comprises the following steps:
determining the length LengthOf (Value) of the actual received Value field; the length of the actual received Value field is determined by calculating the number of bytes of the received Value data.
And judging whether the Length of the Value field actually received is matched with the expected Length designated by the Length field.
Checking the Value field according to the Type field; according to the definition of the Type field, it is checked whether the format of the Value field is correct. For example, if the Type specifies that Value should be a digital Type, the receiving end checks whether Value is composed entirely of numbers. It is checked whether the specific contents of the Value field meet expectations. This may include verifying the accuracy, integrity, or compliance of the data with certain business rules.
If the actual Length of the Value field matches the expected Length specified in the Length field and both the format and content inspection pass, (LengthOf (Value) =expectedlength) ∈ CheckFormat (Value) ζ CheckContent (Value)), the verification is successful, and the valid boolean Value of the Value is returned; where ExpectedLength represents the expected Length specified by the Length field, checkFormat (Value) represents the format of checking Value field according to the Type field definition, checkContent (Value) checks the content of Value field according to the Type field definition.
If these conditions are not met, indicating that the verification failed, returning a Value invalid Boolean Value.
The method for verifying the checksum is used for ensuring the data integrity and the correctness of the TLV (Type-Length-Value) data packet in the transmission process, and comprises the following steps:
extracting a checksum field CalculateChecksum (Value) in the TLV data packet; the Value field is calculated according to the content of the Value field when the upper computer sends the Value field.
Calculating to obtain CRC check sum received dCocksum in the TLV data packet; the receiving end executes CRC calculation to the Value field in the received TLV data packet. The receiver and the sender must use the same CRC algorithm and parameters to ensure accurate alignment of the checksums.
If CalculateChecksum (Value) =receivedchecksum, the verification is successful, and the boolean value with the checksum valid is returned;
otherwise, the verification fails, and the Boolean value with invalid checksum is returned.
The method for verifying the hash Value is used for confirming the data consistency and untampered of the TLV (Type-Length-Value) data packet in the transmission process. A hash value is a fixed-length string generated from data by a hash function, which uniquely represents the content of the original data.
The method for verifying the hash value comprises the following steps:
extracting a hash value CalrulateHash in the expanded data packet; which is calculated by the sender from the contents of the TLV packet before sending the packet.
Calculating a hash value receivedsash of the received TLV data packet through the same hash algorithm; the receiving end uses the same hash algorithm as the sender to calculate the hash value of the received TLV data packet.
The sender and receiver must use exactly the same hash algorithm, including the same hash function and the same way of processing. And the hash algorithm chosen should be strong enough to prevent any form of collision (i.e. two different data produce the same hash value).
If calcuatiehash=receivedhash, the verification is successful, and a boolean value with a valid hash value is returned;
otherwise, the verification fails, and the Boolean value with invalid hash value is returned.
Finally, if the valid boolean Value of the Type, the valid boolean Value of the Length, the valid boolean Value of the Value and the valid boolean Value of the checksum exist at the same time, determining that the TLV data packet is correct; if any Type invalid Boolean Value, length invalid Boolean Value, value invalid Boolean Value and checksum invalid Boolean Value exist, determining that the TLV data packet is wrong, discarding and requesting retransmission.
Example IV
In the fourth step, the method for writing the parsed data into the FLASH memory involves ensuring the integrity and correctness of the data in the writing process, and the method comprises the following steps:
segmenting the analyzed data according to the page size or the programming unit of the FLASH memory to obtain a plurality of data segments; the parsed data is segmented according to the page size or programming unit of the FLASH memory, and the FLASH memory generally performs data read-write operation by taking the page as a unit. Dividing the data into segments that match the page size or programming unit can optimize the writing process and ensure compatibility with FLASH memory.
Before writing each data segment, calculating the checksum of the segment; before writing each data segment into FLASH, a checksum of the segment data is calculated. This checksum is a verification point of the integrity of the data segment for verification comparison after writing.
Writing each data segment into a corresponding address of the FLASH memory; ensuring that the data is properly stored in the physical location.
Reading back the written data segment, calculating the checksum again, and comparing the newly calculated checksum with the original checksum; after writing the data, the written data segment is read back from the FLASH memory, and the checksum is calculated again. This newly calculated checksum is then compared to the original checksum.
If the newly calculated checksum is equal to the original checksum, continuing to write the next data segment; indicating that the data segment was correctly written to FLASH memory.
If the newly calculated checksum is not equal to the original checksum, the data segment is rewritten and checksum verification is performed again;
until writing of all the data segments is completed.
A method of calculating a checksum is provided:wherein D represents a data segment to be written into FLASH, 2 n Representing the left shift of the data segment D by n bits, n representing the highest power of the polynomial, P representing the selected CRC polynomial and remainders representing the remainder of the polynomial division.
Example five
An FPGA online upgrading system based on MicroBlaze comprises an upper computer and a terminal module, wherein the upper computer sends firmware data for FPGA upgrading to the terminal module, and the terminal module writes the firmware data into FLASH of the FPGA;
the upper computer comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor implementing the method of any one of claims 2 or 3 when the computer program is executed;
the terminal module comprises MicroBlaze and a program which is stored in the MicroBlaze and can run, and the MicroBlaze realizes the FPGA online upgrading method based on the MicroBlaze when the MicroBlaze executes the program.
The memory may be used to store software programs and modules, and the processor executes various functional applications of the terminal and data processing by running the software programs and modules stored in the memory. The memory may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an execution program required for at least one function, and the like.
The storage data area may store data created according to the use of the terminal, etc. Further, the memory may include high-speed random access memory, and may also include non-volatile memory, such as at least one flash memory device, or other volatile solid-state storage device.
In the description of the present specification, reference to the terms "one embodiment/manner," "some embodiments/manner," "example," "specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment/manner or example is included in at least one embodiment/manner or example of the present application. In this specification, the schematic representations of the above terms are not necessarily for the same embodiment/manner or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments/modes or examples. Furthermore, the various embodiments/modes or examples described in this specification and the features of the various embodiments/modes or examples can be combined and combined by persons skilled in the art without contradiction.
Furthermore, the terms "first," "second," and the like, are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include at least one such feature. In the description of the present application, the meaning of "plurality" is at least two, such as two, three, etc., unless explicitly defined otherwise.
It will be appreciated by persons skilled in the art that the above embodiments are provided for clarity of illustration only and are not intended to limit the scope of the invention. Other variations or modifications of the above-described invention will be apparent to those of skill in the art, and are still within the scope of the invention.
Claims (10)
1. An FPGA online upgrading method based on MicroBlaze is characterized in that a MicroBlaze processor soft core is embedded in an FPGA, and the MicroBlaze is connected with an upgrading interface of the FPGA by adopting an AXI UART LITE interface or an AXI ETH interface, and is communicated with a FLASH of the FPGA through an ASI SPI interface;
the online upgrading method comprises the following steps:
firstly, the upper computer packages firmware data into a data packet in a TLV format;
secondly, the upper computer transmits the TLV data packet to MicroBlaze through a UART interface or an ETH interface;
thirdly, receiving the data packet by the MicroBlaze through an AXI UART LITE interface or an AXI ETH interface, and processing the data packet;
and fourthly, writing the analyzed data into FLASH by the MicroBlaze through an AXI SPI interface.
2. The method for online upgrading of an FPGA based on MicroBlaze according to claim 1, wherein in the first step, the method for converting firmware data into TLV format by the upper computer comprises:
determining the sizes of a Type field, a Length field and a Value field, wherein the Type is a Type identifier of a data block, the Length is the Length of the data block, the Value is the actual content of the data block, and the Value of the Length field represents the byte Length of the Value field data;
determining the data of each field according to the firmware data, and constructing a data structure through a structural body or class;
filling fields corresponding to the firmware data into a data structure;
serializing the Type field, the Length field and the Value field into a byte stream;
generating a checksum field, adding the checksum field at the tail end of the byte stream, and obtaining a TLV data packet after packaging;
carrying out hash calculation on the TLV data packet through a hash algorithm to generate a hash value with a fixed length, and taking the hash value as a secondary packet of the expansion data packet and the TLV data packet to obtain a final TLV data packet;
checking the final TLV data packet, and if the checking fails, regenerating and checking the TLV data packet; and if the verification is successful, the TLV data packet is sent.
3. The online upgrade method for the FPGA based on MicroBlaze according to claim 2, wherein the method for verifying the TLV data packet comprises the following steps:
determining a CRC-32 polynomial for verification;
initializing a CRC register: CRC =0xFFFFFFFF;
the highest 8 bits of the CRC register are exclusive-ored with the current byte before processing the bytes of the TLV packet:wherein CRC high The highest 8 bits of the CRC register, B is the current byte of the data block;
shifting the CRC register one bit to the left, and performing exclusive OR operation on the CRC register and the binary representation of the CRC polynomial if the highest bit of the shifted CRC register is 1: if the highest bit of the CRC register after shifting is 0, not performing operation;
finishing the iterative processing of all bytes of the Value field in the TLV data packet;
exclusive or the CRC register with 0 xFFFFFFFF:obtaining a final CRC checksum;
comparing the CRC checksum field, and if the CRC checksum is equal to the checksum field, checking successfully; if the CRC checksum is not equal to the checksum field, the check fails.
4. The online FPGA upgrade method based on MicroBlaze according to claim 2, wherein in the third step, the method for processing the data packet comprises:
storing the received final TLV data packet into a buffer area, and splitting to obtain the TLV data packet and an expansion data packet;
reading a Type field from the starting position of the buffer area, and verifying whether the Type field is a predefined valid Type;
and reading the Length field after the Type field from the buffer zone, and verifying whether the Length field is reasonable:
reading the Value field with the corresponding Length from the buffer area according to the Value of the Length field, and verifying the integrity of the Value field;
calculating a hash value and a checksum of the received TLV data packet, and verifying the hash value and the checksum;
if the Type field, the Length field, the Value field, the hash Value and the checksum are all verified to pass, the TLV data packet is determined to be complete; if either of the packets fails to check, the TLV packet is discarded and retransmission is requested.
5. The online upgrade method of the FPGA based on MicroBlaze according to claim 4, wherein the method for verifying the Type field comprises the following steps:
matching and judging the extracted Type field with an effective Type value list TypesList defined in the system;
if the Type E Type List, the verification is successful, the Type field in the TLV data packet is valid, and a Type valid Boolean value is returned;
if it isThe verification fails, the Type field in the TLV data packet is invalid, and the boolean value with the invalid Type is returned;
the method for verifying the Length field comprises the following steps:
determining the maximum data length MaxSize allowed by the TLV data packet;
determining the residual data size Sizeoff of the Type field and the Length field removed in the TLV data packet;
if (Length is more than or equal to 0 and less than or equal to MaxSize). Lambda. (Length is more than or equal to Sizeoff), the verification is successful, and a valid Boolean value of Length is returned;
otherwise, indicating that the verification fails, and returning a Boolean value with invalid Length;
the method for verifying the Value field comprises the following steps:
determining the length LengthOf (Value) of the actual received Value field;
judging whether the Length of the Value field actually received is matched with the expected Length designated by the Length field;
checking the Value field according to the Type field;
if (LengthOf (Value) =expectedlength) a CheckFormat (Value) a CheckContent (Value), the verification is successful, and a boolean Value valid for Value is returned; wherein, expectedLength represents the expected Length specified by the Length field, checkFormat (Value) represents the format of checking Value field according to the Type field definition, checkContent (Value) checks the content of Value field according to the Type field definition;
otherwise, the verification fails, and a Value invalid Boolean Value is returned;
the method for verifying the checksum comprises the following steps:
extracting a checksum field CalculateChecksum (Value) in the TLV data packet;
calculating to obtain CRC check sum received dCocksum in the TLV data packet;
if CalculateChecksum (Value) =receivedchecksum, the verification is successful, and the boolean value with the checksum valid is returned;
otherwise, indicating that the verification fails, and returning a Boolean value with invalid checksum;
the method for verifying the hash value comprises the following steps:
extracting a hash value CalrulateHash in the expanded data packet;
calculating a hash value receivedsash of the received TLV data packet through the same hash algorithm;
if calcuatiehash=receivedhash, the verification is successful, and a boolean value with a valid hash value is returned;
otherwise, the verification fails, and the Boolean value with invalid hash value is returned.
6. The online FPGA upgrading method based on MicroBlaze according to claim 5, wherein if the valid Boolean Value of Type, the valid Boolean Value of Length, the valid Boolean Value of Value, the valid Boolean Value of hash Value and the valid Boolean Value of checksum exist at the same time, determining that the TLV data packet is correct; if any Type invalid Boolean Value, length invalid Boolean Value, value invalid Boolean Value, hash Value invalid Boolean Value and checksum invalid Boolean Value exist, determining that the TLV data packet is wrong, discarding and requesting retransmission.
7. The online FPGA upgrading method based on MicroBlaze according to claim 5, wherein in the fourth step, the method for writing the parsed data into FLASH comprises:
segmenting the analyzed data according to the page size or the programming unit of the FLASH memory to obtain a plurality of data segments;
before writing each data segment, calculating the checksum of the segment;
writing each data segment into a corresponding address of the FLASH memory;
reading back the written data segment, calculating the checksum again, and comparing the newly calculated checksum with the original checksum;
if the newly calculated checksum is equal to the original checksum, continuing to write the next data segment; if the newly calculated checksum is not equal to the original checksum, the data segment is rewritten and checksum verification is performed again;
until writing of all the data segments is completed.
8. The online upgrade method of the FPGA based on MicroBlaze according to claim 7, wherein the method for calculating the checksum is as follows:where D represents the segment of data to be written into FLASH, 2n represents shifting the segment of data D left by n bits, n represents the highest power of the polynomial, P represents the selected CRC polynomial, and remainders represent the remainder of the polynomial division.
9. The FPGA online upgrading system based on MicroBlaze is characterized by comprising an upper computer and a terminal module, wherein the upper computer sends firmware data for FPGA upgrading to the terminal module, and the terminal module writes the firmware data into FLASH of the FPGA;
the upper computer comprises a memory, a processor and a computer program stored in the memory and capable of running on the processor, wherein the processor executes the computer program to realize the method as claimed in any one of claims 2 or 3;
the terminal module comprises MicroBlaze and a program which is stored in and can run in the MicroBlaze, and the method of any one of claims 4-8 is realized when the MicroBlaze executes the program.
10. A computer readable storage medium storing a computer program, characterized in that the computer program when executed by a processor implements the method according to any one of claims 1-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311832586.3A CN117873539B (en) | 2023-12-28 | MicroBlaze-based FPGA online upgrading method, system and medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311832586.3A CN117873539B (en) | 2023-12-28 | MicroBlaze-based FPGA online upgrading method, system and medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN117873539A true CN117873539A (en) | 2024-04-12 |
| CN117873539B CN117873539B (en) | 2024-07-02 |
Family
ID=
Citations (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070214453A1 (en) * | 2004-04-29 | 2007-09-13 | Symbian Software Limited | Installation of Software on Removable Media |
| US20100257345A1 (en) * | 2007-10-03 | 2010-10-07 | Davide Tazzari | Method and apparatus for reprogramming applications in embedded devices |
| US20130111455A1 (en) * | 2010-08-27 | 2013-05-02 | Huawei Device Co., Ltd. | Method for processing firmware based on firmware over the air technology, apparatus, and system |
| CN104049996A (en) * | 2014-05-29 | 2014-09-17 | 湖北三江航天红峰控制有限公司 | Method for carrying out software updating of missile-borne computer based on serial port |
| US8868796B1 (en) * | 2013-04-18 | 2014-10-21 | Otter Products, Llc | Device and method for updating firmware of a peripheral device |
| CN105320531A (en) * | 2014-07-15 | 2016-02-10 | 北京自动化控制设备研究所 | Online FPGA software upgrading method based on MicroBlaze soft core |
| EP3428811A1 (en) * | 2017-07-11 | 2019-01-16 | Sap Se | Database interface agent for a tenant-based upgrade system |
| CN112667320A (en) * | 2021-01-14 | 2021-04-16 | 中国电子科技集团公司第五十八研究所 | FPGA and DSP remote loading system based on MicroBlaze |
| WO2022116009A1 (en) * | 2020-12-01 | 2022-06-09 | Oppo广东移动通信有限公司 | Data transmission method and apparatus, and communication device |
| CN114721680A (en) * | 2021-01-05 | 2022-07-08 | 比亚迪股份有限公司 | Vehicle-mounted applet offline updating method and vehicle-mounted applet offline updating system |
| CN115543386A (en) * | 2022-10-21 | 2022-12-30 | 苏州国芯科技股份有限公司 | Firmware encryption method, decryption method, processing device and medium |
| CN116009923A (en) * | 2023-02-17 | 2023-04-25 | 山东云海国创云计算装备产业创新中心有限公司 | Control method, device and storage medium for firmware differential upgrade |
| CN116938710A (en) * | 2022-04-07 | 2023-10-24 | 中移物联网有限公司 | Terminal firmware upgrading method, device, equipment and storage medium |
| CN117041048A (en) * | 2023-07-31 | 2023-11-10 | 中国第一汽车股份有限公司 | Vehicle system upgrading method, OTA upgrading file cloud processing method and electronic equipment |
Patent Citations (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070214453A1 (en) * | 2004-04-29 | 2007-09-13 | Symbian Software Limited | Installation of Software on Removable Media |
| US20100257345A1 (en) * | 2007-10-03 | 2010-10-07 | Davide Tazzari | Method and apparatus for reprogramming applications in embedded devices |
| US20130111455A1 (en) * | 2010-08-27 | 2013-05-02 | Huawei Device Co., Ltd. | Method for processing firmware based on firmware over the air technology, apparatus, and system |
| US8868796B1 (en) * | 2013-04-18 | 2014-10-21 | Otter Products, Llc | Device and method for updating firmware of a peripheral device |
| CN104049996A (en) * | 2014-05-29 | 2014-09-17 | 湖北三江航天红峰控制有限公司 | Method for carrying out software updating of missile-borne computer based on serial port |
| CN105320531A (en) * | 2014-07-15 | 2016-02-10 | 北京自动化控制设备研究所 | Online FPGA software upgrading method based on MicroBlaze soft core |
| EP3428811A1 (en) * | 2017-07-11 | 2019-01-16 | Sap Se | Database interface agent for a tenant-based upgrade system |
| WO2022116009A1 (en) * | 2020-12-01 | 2022-06-09 | Oppo广东移动通信有限公司 | Data transmission method and apparatus, and communication device |
| CN114721680A (en) * | 2021-01-05 | 2022-07-08 | 比亚迪股份有限公司 | Vehicle-mounted applet offline updating method and vehicle-mounted applet offline updating system |
| CN112667320A (en) * | 2021-01-14 | 2021-04-16 | 中国电子科技集团公司第五十八研究所 | FPGA and DSP remote loading system based on MicroBlaze |
| CN116938710A (en) * | 2022-04-07 | 2023-10-24 | 中移物联网有限公司 | Terminal firmware upgrading method, device, equipment and storage medium |
| CN115543386A (en) * | 2022-10-21 | 2022-12-30 | 苏州国芯科技股份有限公司 | Firmware encryption method, decryption method, processing device and medium |
| CN116009923A (en) * | 2023-02-17 | 2023-04-25 | 山东云海国创云计算装备产业创新中心有限公司 | Control method, device and storage medium for firmware differential upgrade |
| CN117041048A (en) * | 2023-07-31 | 2023-11-10 | 中国第一汽车股份有限公司 | Vehicle system upgrading method, OTA upgrading file cloud processing method and electronic equipment |
Non-Patent Citations (1)
| Title |
|---|
| 刘杨，彭木根编著: "《物联网安全》", 30 April 2022, 北京：北京邮电大学出版社, pages: 135 - 138 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106843942B (en) | Wearable device and firmware upgrading method thereof | |
| US7631251B2 (en) | Method and apparatus for calculating checksums | |
| EP3542276B1 (en) | Flow control in remote direct memory access data communications with mirroring of ring buffers | |
| CN108563532B (en) | Data processing method and related device | |
| KR101919990B1 (en) | Data processing system and processing method for error correction code thereof | |
| CN114328316B (en) | DMA controller, SOC system and data carrying method based on DMA controller | |
| WO2008148278A1 (en) | Method for exchanging large-capacity data between mobile terminal and smart card | |
| KR100847560B1 (en) | Circuits and methods for correcting errors in downloading firmware | |
| KR100578080B1 (en) | Sending and Receiving Method of Command and Data in Serial Transmission Protocol | |
| EP3065323B1 (en) | Transmission method and device based on management data input/output multi-source agreements | |
| CN117873539B (en) | MicroBlaze-based FPGA online upgrading method, system and medium | |
| CN107239358A (en) | Startup method, mobile terminal and the device with store function of Android system | |
| JP4839364B2 (en) | Combined command and data code | |
| CN117873539A (en) | MicroBlaze-based FPGA online upgrading method, system and medium | |
| CN111611002B (en) | Data upgrading method, device, computer equipment and storage medium | |
| CN110381050B (en) | Multi-protocol conversion and verification method and device for data packet | |
| CN111464267A (en) | Communication data checking method and device, computer equipment and storage medium | |
| JP2021039672A (en) | Memory system, packet protection circuit, and crc calculation method | |
| CN115129509A (en) | Data transmission method, device and medium | |
| EP1198891B1 (en) | Data integrity management for data storage systems | |
| CN113885922B (en) | Software version updating and reconstructing method for LEO communication system | |
| JP7182373B2 (en) | Semiconductor integrated circuit, memory device and error correction method | |
| CN111506333B (en) | double-DSP program online upgrading method and system | |
| CN117170726A (en) | Differential upgrading method of low resources and embedded equipment | |
| CN116483755A (en) | Serial data writing method for embedded chip and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant |