FPGA firmware online updating method and system
By dynamically dividing the FLASH storage blocks into active areas, isolation areas and abandoned areas, combining edge servers and ping-pong buffer mechanisms, the FPGA firmware update strategy is optimized, and the problem of short life of FLASH storage media in the existing technology is solved, achieving more efficient and secure firmware updates.
Patent Information
- Application Number
- CN202510441542.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-09
- Publication Date
- 2025-07-25
AI Technical Summary
The existing FPGA firmware update methods lack dynamic perception of the real-time health status of FLASH storage blocks, resulting in frequent rewritten operations focusing on high-wear blocks, shortening the life of the storage medium and increasing the probability of burst bad blocks.
By obtaining the historical rewritten data of FLASH, the pre-trained classification model is used to dynamically divide the storage blocks into active areas, isolation areas and abandoned areas, generate partition mapping tables, and generate incremental firmware files through edge servers, optimize the write strategy according to the block health status, and firmware updates are performed in combination with ping-pong buffers and real-time verification mechanisms.
It significantly extends the service life of FLASH storage media, reduces the probability of bursts of bad blocks caused by local aging or environmental coupling, and improves the security and efficiency of firmware updates.
Smart Images

Figure CN120371344A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of FPGA firmware update, and particularly to an FPGA firmware online update method and system. Background Art
[0002] With the continuous development of technology, infrared cameras are increasingly widely used in fields such as aerospace, security, medical treatment, and environmental monitoring. The FPGA (Field-Programmable Gate Array) used in infrared cameras, as a flexible and configurable hardware platform, plays a key role in image processing, data acquisition, signal conditioning, etc.
[0003] During the operation of infrared cameras, it is often necessary to update the firmware of the FPGA. Currently, there are mainly two types of firmware update methods in the existing technology: One is to write the program file into the FPGA chip using the JTAG (Joint Test Action Group) interface. This method is simple and convenient to operate, but for the packaged products, especially for infrared cameras in special states such as field tests or environmental simulation tests, this method has extremely high costs and risks, and requires high requirements for operators. Another method is to perform online update with the help of a host computer or other microprocessors. Although it can avoid the risk of physical contact, it still faces significant challenges in practical applications.
[0004] The existing online update methods rely on a wear leveling strategy based on static rules to manage the FLASH (Flash Memory) storage medium in the FPGA. Although it can achieve the balance of the basic number of erase operations, it lacks the ability to dynamically perceive the real-time health status of the storage blocks, resulting in frequent erase operations continuously concentrating on the blocks with a higher historical number of erasures or potential degradation risks; thus, not only will it accelerate the aging of local blocks, but also the probability of sudden bad blocks will rapidly increase due to the coupling of environmental factors (such as temperature, voltage). Summary of the Invention
[0005] To solve the problems existing in the prior art, the present invention provides an FPGA firmware online update method and system, which can dynamically perceive the health status of each storage block of the FLASH, thereby optimizing the firmware writing scheme and extending the service life of the FLASH storage medium.
[0006] To achieve the above object, the present invention provides an FPGA firmware online update method, which is applied to an FPGA and includes:
[0007] Obtain the historical erase data of the FLASH; the historical erase data includes the number of erase operations and the read / write error rate;
[0008] Based on the historical erase and write data, use a pre-trained classification model to dynamically partition the storage blocks of the FLASH, and generate a partition mapping table including an active area, an isolation area, and a discarded area; the active area is the block with the highest write priority; the isolation area is the block that opens temporary write permissions within a preset error rate threshold range; the discarded area is the block where writing is prohibited;
[0009] Send the partition mapping table to the edge server; the edge server receives the updated firmware sent by the cloud or the host computer, generates an incremental firmware file by comparing it with the original firmware in the FPGA, and splits the incremental firmware file into data blocks that match the target addresses according to the partition mapping table; the target addresses are the addresses of the active area and the isolation area in the partition mapping table;
[0010] According to the partition mapping table, write the received data blocks into the FLASH to complete the firmware update.
[0011] Optionally, when the edge server receives the updated firmware sent by the cloud or the host computer, it sends an update instruction to the FPGA, and the method further includes:
[0012] In response to the update instruction, send task load information to the edge server; the edge server determines the download priority according to the task load information and sends the data blocks based on the download priority.
[0013] Optionally, the method further includes:
[0014] Before receiving the data blocks, if the change range of the current task load exceeds a preset threshold, send load change information to the edge server; the edge server adjusts the download priority according to the load change information and sends the data blocks according to the adjusted download priority.
[0015] Optionally, when the edge server receives the updated firmware sent by the cloud or the host computer, it sends an update instruction with a digital signature to the FPGA; the method further includes:
[0016] Verify the validity of the digital signature of the received update instruction;
[0017] If it is valid, send task load information to the edge server; the edge server determines the download priority according to the task load information and sends the data blocks based on the download priority;
[0018] If it is invalid, reject the update operation and send a rejection message to the edge server.
[0019] Optionally, writing the received data block into the FLASH according to the partition mapping table includes:
[0020] After receiving the data block, determining the firmware update condition according to the current task load status;
[0021] When the firmware update condition is satisfied, writing the data block into the FLASH according to the partition mapping table.
[0022] Optionally, writing the received data block into the FLASH according to the partition mapping table includes:
[0023] Receiving the data block and storing it in a target memory; the target memory is either one of the two memories of the ping-pong buffer;
[0024] Erasing the target page in the FLASH associated with the target memory to write the data block in the target memory; the target page address is determined based on the active area and isolation area addresses in the partition mapping table;
[0025] When the target memory is full, switching to another memory as the new target memory, and clearing the data block in the memory that has been full after all the data blocks in it are written into the target page of the FLASH;
[0026] If the other memory is full when switching, pausing the storage of data blocks until the data blocks in at least one memory are written into the FLASH and cleared;
[0027] Looping through the above operations until all data blocks are received and written into the FLASH.
[0028] Optionally, after writing the received data block into the FLASH, the method further includes:
[0029] Performing comparison verification on each data block written into the FLASH;
[0030] If the verification fails, marking the current FLASH page as the isolation area and rewriting the corresponding data block to the alternate address.
[0031] The present invention also provides an FPGA firmware online update system applied to an FPGA, including:
[0032] A data acquisition unit for acquiring historical erase / write data of the FLASH; the historical erase / write data includes the number of erase / write times and the read / write error rate;
[0033] A data processing unit for:
[0034] Based on the historical erase-write data, use a pre-trained classification model to dynamically partition the storage blocks of the FLASH, and generate a partition mapping table including an active area, an isolation area, and a discarded area; the active area is the block with the highest write priority; the isolation area is the block that opens temporary write permission within a preset error rate threshold range; the discarded area is the block that prohibits writing.
[0035] Send the partition mapping table to the edge server; the edge server receives the updated firmware sent from the cloud or the host computer, generates an incremental firmware file by comparing it with the original firmware in the FPGA, and splits the incremental firmware file into data blocks that match the target addresses according to the partition mapping table; the target addresses are the addresses of the active area and the isolation area in the partition mapping table.
[0036] An update unit is configured to write the received data block into the FLASH according to the partition mapping table to complete the firmware update.
[0037] According to the specific embodiments provided by the present invention, the following technical effects are disclosed:
[0038] The FPGA firmware online update method and system provided by the present invention can accurately identify the blocks with potential deterioration risks by collecting the historical erase-write data of the FLASH and dynamically analyzing the health status of each storage block of the FLASH in combination with a pre-trained classification model, and based on the dynamically partitioned active area, isolation area, and discarded area, preferentially allocate the active area with low erase-write times and low error rate for firmware writing, while restricting the writing of the isolation area and prohibiting writing to the discarded area; in this way, it can actively avoid the blocks with frequent historical erase-writes or performance decline, significantly reduce the probability of sudden bad blocks caused by local aging or environmental coupling effects, and extend the overall life of the FLASH storage medium. Description of the Drawings
[0039] By describing the exemplary embodiments of the present invention in more detail in conjunction with the drawings, the above and other objects, features, and advantages of the present invention will become more obvious, wherein, in the exemplary embodiments of the present invention, the same reference numerals generally represent the same components.
[0040] Figure 1 It is a schematic flowchart of the FPGA firmware online update method shown in the embodiments of the present invention;
[0041] Figure 2 It is a schematic diagram of data writing based on a ping-pong buffer shown in the embodiments of the present invention;
[0042] Figure 3 It is a schematic diagram of the module structure of the FPGA firmware online update system shown in the embodiments of the present invention. Detailed Description of the Invention
[0043] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.
[0044] The object of the present invention is to provide an FPGA firmware online update method and system, which is applied to an FPGA and can dynamically sense the health status of each storage block of the FLASH during firmware update, thereby prolonging the service life of the FLASH storage medium.
[0045] Please refer to Figure 1 , Figure 1 which is a schematic flowchart of the method for the FPGA firmware online update method. The above update method includes:
[0046] Step 101: Obtain the historical erase-write data of the FLASH.
[0047] As a non-volatile storage medium, the FLASH memory can be used to permanently store the firmware program of the FPGA. Its storage unit consists of multiple blocks, and each block may experience performance degradation or physical damage after multiple erase-write operations. The historical erase-write data is an important indicator reflecting the health status of its physical storage unit, including two key parameters: the number of erase-write cycles and the read-write error rate. Among them, the number of erase-write cycles refers to the cumulative number of times a specific storage block is completely erased and rewritten with data during its life cycle; due to the physical wear characteristics of the FLASH storage medium, the upper limit of the number of erase-write cycles of each storage block is limited by semiconductor technology, and frequent erase-write will increase the risk of oxide layer breakdown. The read-write error rate characterizes the probability of bit errors occurring during data access of the storage unit, which can be calculated by counting the error frequency through a verification algorithm (such as ECC, CRC). An increase in the error rate usually indicates a decrease in the reliability of the storage unit or approaching failure.
[0048] In the application, to implement data acquisition, a dynamic record table can be maintained inside the FPGA to track the erase-write operations of each storage block in real time. Each time an erase or write command is executed, the counter of the corresponding block automatically increments. For the statistical calculation of the read-write error rate, the hardware verification mechanism (such as CRC verification) can be used to detect the integrity of data transmission, and record the error type and occurrence location when an error is detected. The historical erase-write data can be stored in the register or dedicated storage area of the FPGA in a structured form for subsequent analysis and call.
[0049] By analyzing historical erase-write data, storage blocks with high erase-write counts or high error rates can be identified. For example, blocks that are frequently erased may experience aging of storage cells due to electron migration, while blocks with high error rates pose a potential risk of failure. This data provides a basis for dynamically partitioning the storage area, thereby avoiding writing new firmware data to unreliable areas and reducing the risk of update failure caused by storage medium failure.
[0050] Step 102: Based on the historical erase-write data, use a pre-trained classification model to dynamically partition the storage blocks of the FLASH, generating a partition mapping table that includes an active area, an isolation area, and a discarded area.
[0051] Among them, the active area is the block with the highest write priority; the isolation area is the block that grants temporary write permissions within a preset error rate threshold range; the discarded area is the block that prohibits writing.
[0052] In the application, the historical erase-write data can be intelligently analyzed through a pre-trained classification model to dynamically evaluate the health status of each storage block. The classification model can be constructed based on machine learning algorithms (such as decision trees or neural networks), with the input being the erase-write count statistics, error rate, and environmental parameters (such as temperature fluctuation records) of the block, and the output being the reliability score of the block.
[0053] The goal of dynamic partitioning is to classify the storage blocks of the FLASH into three functional areas according to the scoring results. The active area consists of blocks with the best health status, characterized by an erase-write count far lower than the design threshold and a read-write error rate approaching zero. Such blocks are given the highest write priority and are used to carry the main part of the incremental firmware data to ensure the stability and efficiency of the writing process. The isolation area contains blocks with potential risks. Although their read-write error rates do not reach the complete failure standard, they have exceeded the preset temporary write threshold (for example, the single-page error rate exceeds 0.1%). Such blocks can be granted limited write permissions when the capacity of the active area is insufficient, and additional verification needs to be performed after writing to monitor data integrity. The discarded area consists of severely deteriorated blocks, whose erase-write counts are close to the upper limit of the chip's nominal life, or whose read-write error rates continuously exceed the allowable range. Writing data to such blocks is prohibited through hardware locks or software policies to avoid firmware damage caused by storage medium failure.
[0054] During firmware update, the active area can adopt an wear leveling algorithm to dynamically allocate write addresses, and ensure uniform growth of the erase-write counts of each block through a polling mechanism; the isolation area implements a write frequency limit strategy, for example, the maximum number of writes per day does not exceed 50% of the active area, and it will be automatically upgraded to the discarded area when the error rate is found to be continuously rising in two consecutive inspections;
[0055] In the application, before the start of each firmware update, the latest collected historical rewrite data can be input into the classification model to recalculate the scores of each block and update the partition status. For example, if a block in an active area has multiple parity errors suddenly in the previous cycle, it may be downgraded to an isolation area; while a block in the isolation area with a normal error rate can be reclassified into the active area. This dynamic adjustment mechanism can adapt to the progressive degradation characteristics of the FLASH storage medium and balance the storage resource utilization rate and reliability.
[0056] Exemplarily, the classification model can adopt a multi-layer perceptron (MLP) structure, including an input layer, two fully connected hidden layers, and an output layer. The input layer receives feature data in three dimensions: the historical rewrite count of the storage block, the real-time read / write error rate, and environmental parameters (such as temperature fluctuation records). Among them, the rewrite count and error rate can be dynamically collected through the internal counters and parity mechanisms of the FPGA, and the temperature data can be periodically monitored by an integrated sensor. The output layer generates a normalized reliability score (in the range of 0 to 1) through the Sigmoid activation function. The higher the score, the better the health status of the block. During the model training process, the model can be constructed based on a historical dataset, which includes the rewrite count, error rate, temperature records of a large number of storage blocks, and manually labeled reliability labels (such as "active", "isolated", "abandoned"). The label generation rules can combine the physical characteristics of the FLASH chip and expert experience. For example, a block with a rewrite count exceeding 80% of the nominal life or an error rate continuously higher than 0.5% is labeled as "abandoned". During training, the backpropagation algorithm can be used to optimize the network weights, the cross-entropy loss is selected as the loss function, and the early stopping method is introduced to prevent overfitting. After training, the model evaluates its generalization ability through cross-validation to ensure its robustness under different FLASH models and environmental conditions. In practical applications, the model can be deployed in a lightweight form in the embedded processor of the FPGA to support real-time classification inference and the update of the dynamic partition mapping table.
[0057] Step 103: Send the partition mapping table to the edge server.
[0058] The edge server receives the updated firmware sent by the cloud or the host computer, generates an incremental firmware file by comparing it with the original firmware in the FPGA, and splits the incremental firmware file into data blocks that match the target addresses according to the partition mapping table; the target addresses are the addresses of the active area and the isolation area in the partition mapping table.
[0059] In the application, after the dynamic partitioning of the FLASH storage block is completed, the FPGA can transmit the partition mapping table to the edge server to coordinate the subsequent operations of the firmware update process. The partition mapping table records the specific address ranges and their health status identifiers of the active area, isolation area, and discarded area in the FLASH memory, and is the key basis for guiding the writing of firmware data. The edge server, as an intermediate node connecting the cloud or host computer and the FPGA, undertakes the preprocessing task of firmware update.
[0060] Exemplarily, the hardware architecture of the edge server may include a multi-core processor, a high-speed communication interface, and a dedicated storage module; among them, the communication interface supports Ethernet, Wi-Fi, and industrial bus protocols (such as CAN, RS485) for receiving the updated firmware from the cloud / host computer and establishing a low-latency data link with the FPGA. At the software level, the edge server may include four core modules: a security verification module, a differential analysis engine, a dynamic scheduler, and a transmission controller; among them, the security verification module realizes the authentication of the firmware source through a digital certificate management unit and a hash verification unit to prevent malicious code injection; the differential analysis engine uses a sliding window algorithm to compare the binary differences between the updated firmware and the original firmware, and generates an incremental file containing only the changed bytes; the dynamic scheduler can build a priority queue according to the task load information and the partition mapping table fed back by the FPGA, split the incremental file hierarchically according to the high-priority data in the active area (such as the firmware core function module) and the low-priority data in the isolation area (such as redundant configuration or log information), and adaptively adjust the data block sending rate in combination with network bandwidth fluctuations. The transmission controller can manage the packet encapsulation and transmission timing through a ping-pong buffering mechanism to ensure that high-priority data blocks preferentially occupy the communication link, and adopts a retransmission mechanism to cope with channel interference.
[0061] It should be noted that when the FPGA sends the partition mapping table to the edge server, it can be sent in response to the update instruction of the edge server or sent regularly according to a preset time window.
[0062] When the cloud or host computer issues an updated firmware, the edge server can confirm the firmware legality through a multi-source verification mechanism. For example, it first verifies the validity of the digital certificate, and then calls the hash calculation module to generate the hash algorithm digest value of the firmware file and compares it with the reference value provided by the cloud / host computer. After passing the verification, the differential analysis engine is started to perform a binary comparison between the updated firmware and the original firmware stored in the FPGA, and the difference byte segments are identified through a sliding window algorithm to generate an incremental firmware file containing only the changed data. Among them, the original firmware of the FPGA can be obtained by the edge server from the FPGA in real time or the previous updated firmware pre-stored by the edge server.
[0063] After the incremental firmware file is generated, the edge server splits the data blocks according to the received partition mapping table. The splitting logic needs to match the physical distribution of the target address. The active area is used as the preferred writing area, and the data blocks within its address range are preferentially allocated with the core function code of the firmware. The address of the isolation area can be used to store non-critical data or redundant backup information, such as log files or configuration parameters. During the splitting process, it is necessary to ensure that the size of each data block is aligned with the FLASH storage page to avoid operation delays or verification errors caused by cross-page writing. For example, if the single-page capacity of the FLASH is 4KB, the incremental file will be cut into multiple 4KB data blocks, and the corresponding page addresses of the active area or isolation area will be marked. After the data block splitting is completed, the edge server encapsulates it into a format supported by the transmission protocol (such as a data packet with an address label) and waits to be sent to the FPGA.
[0064] Most existing online update solutions centrally process the firmware file distribution and write address allocation through the remote cloud or the host computer. When a large number of devices (such as a group of infrared cameras) are updated concurrently, it is easy to cause network congestion in the cloud, reducing the update timeliness. Moreover, the global optimization algorithm adopted by the cloud (such as global wear leveling calculation) needs to coordinate the storage status of all devices, and its processing delay increases non-linearly with the increase in the number of devices, further exacerbating the deterioration of timeliness.
[0065] The present invention introduces an edge server as an intermediate processing node to replace the existing direct communication mode between the host computer and the FPGA. This communication method not only reduces the computing load of the host computer but also avoids the redundant transmission of the original updated firmware through edge-side preprocessing, reducing error interference in the communication link. At the same time, the collaborative working mode of the edge server and the FPGA can also enhance the system robustness, ensuring the security and reliability of the firmware update process in a complex outdoor environment.
[0066] Step 104: Write the received data blocks into the FLASH according to the partition mapping table to complete the firmware update.
[0067] In the final execution stage of the firmware update, the FPGA writes the received data blocks into the FLASH memory in an orderly manner according to the target addresses of the data blocks indicated by the partition mapping table. The address ranges of the active area and the isolation area defined in the partition mapping table directly determine the writing priority and storage location allocation of the data blocks. The active area, as the storage block with the best health status, preferentially bears the core function code or frequently accessed data. The isolation area can be used as a backup area to temporarily allocate non-critical data, such as redundant configuration information, when the capacity of the active area is insufficient.
[0068] After the data block is transferred to the FPGA, the corresponding FLASH storage page can be locked according to the target address, and the page erasure operation can be performed to clear the original data. The erasure process must strictly follow the electrical characteristic requirements of the FLASH chip. For example, the voltage rise and fall and charge release should be completed within the specified time to ensure that the storage unit is in a programmable state. After the erasure is completed, the received data block is written into the target page in the address order. During the writing process, the accurate latching of data bits can be achieved through timing control. For example, the binary data is solidified into the storage unit by adjusting the level bit by bit.
[0069] After each page of data is written, the verification mechanism can be immediately triggered to read the content written in the FLASH back to the temporary register and compare it byte by byte with the original data block. If the verification result is completely matched, the page is marked as a valid update area, and the address pointer is updated to point to the next page to be written. If the verification fails, it is determined that there are potential defects in the current page, and it is marked as an isolation area. At the same time, the abnormal state is marked in the partition mapping table, and a spare address (such as an adjacent active area page) is reselected for data rewriting. This mechanism can effectively avoid the risk of data corruption caused by local deterioration of the storage medium.
[0070] A hierarchical strategy can also be implemented during the data writing process. For the target address in the active area, the single programming mode is used to quickly write data. For example, only one write verification is performed for each 512-byte data packet. For the address in the isolation area, the multiple programming mode is enabled. For example, the data is divided into 128-byte units and written in three times, and a preset interval (such as 10 ms) is inserted after each write for charge stabilization, and the data integrity is ensured through three independent read verifications. In addition, the temperature data of the FLASH chip can be collected in real time through the environmental monitoring module. When the chip temperature is detected to exceed the preset value (such as 85 °C), a preset cooling waiting period is automatically inserted to prevent the charge leakage caused by high temperature from affecting the writing quality.
[0071] Furthermore, an error handling mechanism can be constructed. When a single write fails, the operation can be first attempted to be retried at the original address, and the upper limit of the retry times can be dynamically set according to the block type. For example, three retries are allowed in the active area, and only one retry is allowed in the isolation area. If the failure occurs continuously, the address remapping process is triggered, a new physical address is allocated from the spare block pool, the partition mapping table is updated synchronously, and the original address is marked as a temporary isolation state.
[0072] The present invention dynamically senses the number of erase / write cycles and read / write error rates of FLASH storage blocks, combines a classification model to divide active areas, isolation areas, and discarded areas, implements a differential writing strategy, can effectively avoid the repeated use of high-loss blocks, and significantly extends the life of FLASH media; by generating incremental firmware files on the edge server and splitting data blocks according to the partition mapping table, it can also reduce redundant transmission and cloud dependence, and improve the update efficiency. Further, combined with dynamic address allocation, real-time verification, and error handling mechanisms, the risk of sudden bad blocks can be reduced in a complex field environment, ensuring the stability and security of the firmware update process, while reducing the device maintenance cost and operation complexity.
[0073] In one embodiment, when the edge server receives the updated firmware sent by the cloud or the host computer, it sends an update instruction to the FPGA. The above update method further includes:
[0074] In response to the update instruction, send task load information to the edge server; the edge server determines the download priority according to the task load information and sends data blocks based on the download priority.
[0075] In the application, after the edge server receives the updated firmware sent by the cloud or the host computer, it sends an update instruction to the FPGA through the communication link to trigger the start of the firmware update process. The update instruction includes an operation type identifier (such as a firmware upgrade request) and necessary initialization parameters (such as an update session identifier) to notify the FPGA to enter the update preparation state. After receiving the instruction, the FPGA immediately collects the task load information in the current running state, including indicators reflecting resource utilization such as processor occupancy, memory usage, and real-time task queue depth, and encapsulates them into a structured data packet and feeds it back to the edge server.
[0076] In the scenario of multi-FPGA concurrent update, when the edge server parses the task load information fed back by each FPGA, it needs to consider both the resource margin of a single device and the global priority coordination among multiple devices. The task load information reflects the real-time computing power of each FPGA, such as processor occupancy, memory usage, and the urgency of the currently executing tasks. If a certain FPGA is executing a high-priority image processing task (such as real-time target tracking in field tests), its processor occupancy may exceed the preset value. At this time, the transmission rate of the firmware update data block of this device needs to be reduced to avoid system overload; for an FPGA in a low-load state (such as standby or executing background calibration tasks), its update priority can be increased to speed up the overall progress.
[0077] Furthermore, the edge server can also determine the sending priority of different data blocks based on the task load information; high-priority data blocks (such as firmware startup code or core functional modules) are transmitted first to ensure the rapid update of key functions; low-priority data blocks (such as auxiliary configuration files or redundant check data) are flexibly scheduled according to resource margin.
[0078] For example, an infrared camera FPGA that is in a critical mission stage (such as a device that continuously collects data in aerospace thermal vacuum testing) will be given the highest transmission priority for its core data blocks (such as firmware startup code) due to the non-interruptibility of its mission, ensuring that the update process does not interfere with the real-time tasks when they are executed in parallel.
[0079] In addition, when sending data blocks, the stability of the network link and the operating status of the FPGA can also be taken into account. For example, when the logic resources and / or storage resources of the FPGA are under high load, the edge server can reduce the amount of data transmitted at a time, use fragmented progressive transmission, and add heartbeat detection in the transmission interval to monitor the load changes of the FPGA and obtain the latest task load information; if the task load information shows that the resource utilization rate has dropped significantly (such as the queue of pending tasks is cleared), the edge server will automatically increase the transmission rate or resume sending the full amount of data blocks. This dynamic adjustment mechanism not only ensures the timeliness of firmware updates, but also avoids system performance fluctuations caused by resource competition. It is especially suitable for embedded scenarios such as infrared cameras that need to take into account real-time tasks and background updates.
[0080] In one embodiment, when the edge server receives the updated firmware sent by the cloud or the host computer, it sends an update instruction to the FPGA. The above update method also includes:
[0081] In response to the update instruction, the task load information is sent to the edge server; the edge server determines the sending priority according to the task load information, and sends the data block based on the sending priority;
[0082] Before receiving the data block, if the change range of the current task load exceeds the preset threshold, the load change information is sent to the edge server; the edge server adjusts the sending priority according to the load change information, and sends the data block according to the adjusted sending priority.
[0083] In an application, the FPGA can continuously monitor the dynamic changes in its own task load. The amplitude of the task load change can be calculated by collecting key metrics such as the processor occupancy rate, storage resource utilization rate, and communication interface bandwidth occupancy in real time, which reflects the fluctuations in the current computing power and resource allocation of the system. The preset threshold is a pre-set critical value (for example, the processor occupancy rate suddenly increases by more than 20%), which is used to judge the significance of the load change. When it is detected that the amplitude of the load change exceeds the threshold, the FPGA immediately encapsulates the load change information containing specific load parameters (such as the current occupancy rate difference and the type of resource shortage) into a data packet and sends it to the edge server through the communication link.
[0084] After receiving the load change information, the edge server parses its content and evaluates the impact on the firmware update process, thereby dynamically adjusting the transmission strategy. For example, if the occupancy rate of the logic resources of a certain FPGA suddenly increases due to a sudden high-priority task, the edge server can lower the transmission priority of its non-critical data blocks (such as redundant check data), and at the same time delay or split the transmission of large-capacity data blocks to reduce the resource competition between real-time tasks and update operations. On the contrary, if the load change information shows that the resources of the FPGA are restored to be abundant (such as the task queue is emptied), the data block transmission rate of the FPGA is automatically increased to give priority to the update of the core function module.
[0085] The adjusted transmission priority can take effect in real time through a dynamic scheduling algorithm; the edge server reorders the queue of data blocks to be transmitted according to the adjusted priority. For example, it inserts the active area data blocks of high-priority FPGAs into the front of the transmission queue, while the isolation area data blocks of low-priority FPGAs are processed later; at the same time, it continuously monitors the latest load status of the FPGA to form a closed-loop control mechanism of "monitoring - feedback - adjustment". This process ensures that the firmware update task can adapt to the real-time working state of the FPGA, maximizes the use of available resources on the premise of avoiding system overload or task conflicts, and ensures the balance between the stability of key functions and the update efficiency.
[0086] In one embodiment, when the edge server receives the updated firmware sent from the cloud or the upper computer, it sends an update instruction with a digital signature to the FPGA; the above update method further includes:
[0087] Verify the validity of the digital signature of the received update instruction;
[0088] If it is valid, send the task load information to the edge server; the edge server determines the transmission priority according to the task load information and sends the data block based on the transmission priority;
[0089] If it is invalid, reject the execution of the update operation and send a rejection message to the edge server.
[0090] In the application, when the edge server sends an update instruction to the FPGA, a digital signature can be attached to ensure the legality and security of the instruction. The digital signature can be generated based on an asymmetric encryption algorithm (such as RSA or ECC), which is obtained by encrypting the instruction content with the private key of the cloud or the host computer, and is used to verify the authenticity and integrity of the instruction source. After receiving the update instruction, the FPGA first calls the pre-set public key to decrypt the digital signature and compares it with the hash value of the original instruction. If the decrypted hash value is consistent with the actual hash value of the instruction, the signature is determined to be valid, confirming that the instruction has not been tampered with and the source is trustworthy.
[0091] After the verification passes, the FPGA sends the task load information to the edge server. If the digital signature verification fails (such as hash value mismatch or abnormal public key decryption), the FPGA will terminate the update process, refuse to perform any write operation, and send a rejection message to the edge server through the communication link. The rejection message includes an error type identifier (such as invalid signature, instruction tampering) and a timestamp, which are used by the edge server to record abnormal events and trigger an alarm mechanism.
[0092] In this way, the security and controllability of the firmware update process can be ensured. For example, in the field test scenario of an infrared camera, illegal or forged update instructions will be intercepted immediately to avoid device out-of-control caused by malicious firmware injection.
[0093] Furthermore, after sending the task load information to the edge server, the above update method may further include:
[0094] Before receiving the data block, if the change range of the current task load exceeds the preset threshold, the load change information is sent to the edge server; the edge server adjusts the download priority according to the load change information and sends the data block according to the adjusted download priority.
[0095] In one embodiment, writing the received data block into the FLASH according to the partition mapping table includes:
[0096] After receiving the data block, determine the firmware update condition according to the current task load status;
[0097] When the firmware update condition is met, write the data block into the FLASH according to the partition mapping table.
[0098] During the firmware update execution phase, after the FPGA receives a data block, it needs to evaluate the current task load status to determine whether the write condition is met. The task load status is comprehensively determined by dynamically monitoring parameters such as the computing power of the processor, the remaining storage resources, and the occupancy rate of the communication interface bandwidth, which reflects the remaining resources that can be called by the system during the update process. For example, if the FPGA is executing a high-priority real-time task (such as infrared image acquisition and processing), the occupancy rate of its processor may exceed the preset safety threshold (such as 85%), and at this time, the firmware write operation needs to be postponed to avoid task interruption or timing disorder.
[0099] The determination basis for the firmware update condition can include the remaining logical resources, the free capacity of the storage buffer, and the stability of the communication link. For example, when the processor occupancy rate is lower than the preset value, the storage buffer (such as two dual-port BRAMs) has sufficient space, and the communication link is congestion-free, it is determined that the update condition is met, and the data write process is allowed to start. At this time, according to the address allocation rules of the active area and the isolation area in the partition mapping table, the FPGA preferentially writes the data block corresponding to the core function module to the highly reliable storage page in the active area; the non-critical data block (such as auxiliary parameters or log information) is allocated to the temporary writable page in the isolation area.
[0100] In addition, during the writing process, the dynamic changes in the task load status can be continuously monitored. If a sudden task causes resource tension (such as a sharp increase in memory usage), the FPGA immediately suspends the current writing operation and feeds back the load change information to the edge server to trigger a dynamic adjustment of the issued priority; after the resources are restored to abundance, the writing process is reactivated. In this way, through the closed-loop control of load perception and condition determination, it can be ensured that the firmware update operation is efficiently executed without disturbing real-time tasks and can adapt to the resource fluctuation characteristics in complex outfield environments.
[0101] In one embodiment, writing the received data block to the FLASH according to the partition mapping table includes:
[0102] Receiving the data block and storing it in the target memory; the target memory is either one of the two memories in the ping-pong buffer;
[0103] Erasing the target page in the FLASH associated with the target memory to write the data block in the target memory; the target page address is determined based on the addresses of the active area and the isolation area in the partition mapping table;
[0104] When the target memory is full, switch to the other memory as the new target memory, and clear the data block in the memory that has been filled after all the data blocks in the memory are written to the target page in the FLASH;
[0105] If the other memory is full when switching, suspend storing the data block until the data block in at least one memory is written to the FLASH and cleared;
[0106] Execute the above operations in a loop until all data blocks are received and written to the FLASH.
[0107] See Figure 2 , Figure 2 which is a schematic diagram of data writing based on a ping-pong buffer.
[0108] During the data writing phase, the FPGA can implement parallel execution of the reception and writing operations through the ping-pong buffer mechanism. The ping-pong buffer includes two physically isolated memories, and the capacity of each memory is strictly aligned with the FLASH single-page size (such as 4KB). When a data block is transmitted to the FPGA through the communication link, it is first stored in the currently selected target memory (i.e., any idle memory in the ping-pong buffer). The selection of the target memory is dynamically switched according to the writing status. For example, in the initial state, memory A is default selected as the first writing target.
[0109] After the target memory is full of data, a FLASH page erasure operation is triggered; the target page address is dynamically allocated according to the address ranges of the active area and the isolated area in the partition mapping table - preferably select a page address with a low write-erase count and high reliability from the active area; if the capacity of the active area is insufficient, then call the temporarily writable page address in the isolated area. The erasure operation needs to follow the timing specification of the FLASH chip, for example, complete the charge release of the storage unit under a specific voltage to ensure that the target page is in a programmable state.
[0110] After the erasure is completed, the data block in the target memory is written to the corresponding FLASH page. The writing process can be implemented through the FLASH controller inside the FPGA, such as adjusting the bit level one by one and latching the data, to ensure that the binary information is accurately solidified into the storage unit. When the target memory is full, immediately switch to another memory in the ping-pong buffer (such as switching from memory A to memory B) as the new target memory to continue receiving subsequent data blocks; while the original target memory, that is, the memory that has been full, is emptied after all the stored data blocks are written to the target page of the FLASH and enters the idle state waiting for the next filling. If the other memory is full at the time of switching, suspend the data block storage until at least one memory has completed the data clearing, and use the cleared memory as the new target memory. When suspending the data block storage in the target memory, the received data block can be temporarily stored in the temporary memory and then transferred to the target memory later; or it can also be to send feedback information to the edge server, and the edge server suspends the data block distribution or reduces the distribution rate until the target memory is cleared and then resumes the transmission.
[0111] The above receiving, erasing, writing, and switching operations are executed in a loop until all data blocks are transferred. For example, during continuous updates, when Memory A is responsible for receiving new data blocks, the FLASH pages associated with Memory B are performing erasing and writing operations. The two work alternately to form a pipeline, minimizing the waiting time. Finally, all data blocks are written to the FLASH according to the address allocation rules of the partition mapping table, completing the firmware update process; the FPGA can read the updated firmware from the FLASH and start executing a new application program.
[0112] In one embodiment, after writing the received data block to the FLASH, the method further includes:
[0113] Performing a comparison check on each data block written to the FLASH;
[0114] If the check fails, mark the current FLASH page as an isolation area and rewrite the corresponding data block to a spare address.
[0115] In an application, after a data block is successfully written to the FLASH, a comparison check can be performed to ensure the integrity and accuracy of the data. The comparison check detects abnormalities such as bit flips and data loss caused by storage medium degradation or write interference by comparing the content of the data block written in the FLASH with the original received data byte by byte. For example, if the binary value at a specific address in a page of data changes from '0' to '1', it is determined that the page check fails.
[0116] If the check fails, the current FLASH page can be immediately marked as an isolation area, and the partition mapping table can be updated to prohibit subsequent data from being written to this page. The isolation operation is achieved by modifying the status flag of the corresponding page in the mapping table (such as changing the health status from 'active' to 'isolated'), ensuring that subsequent update processes avoid this defective area. At the same time, a spare address is selected for data rewriting. The spare address is preferably selected from the free pages in the active area; if the capacity of the active area is insufficient, available pages in the isolation area that meet the temporary writing conditions are called.
[0117] During the rewrite process, a secondary write is performed and the check is triggered again; if the check still fails, the page at the spare address is upgraded to a discarded area, and the next spare address is continuously selected until the write is successful. In this way, the problem of local degradation of the FLASH medium can be effectively addressed, while ensuring data reliability, maximizing the utilization of available storage resources, especially suitable for embedded scenarios such as infrared cameras that have strict requirements for firmware stability.
[0118] It can be understood that the above comparison check can be performed either during the firmware update process or as a supplementary check after the global update is completed.
[0119] It should be noted that the technical solutions provided in the above embodiments can be combined with each other to form new embodiments when there is no logical conflict.
[0120] Corresponding to the foregoing method embodiments for implementing application functions, the present invention also provides an FPGA firmware online update system and corresponding embodiments.
[0121] Please refer to Figure 3 , Figure 3 which is a schematic diagram of the module structure of the FPGA firmware online update system. The update system is applied to the FPGA and includes:
[0122] A data acquisition unit 31, configured to acquire historical erasure data of the FLASH; the historical erasure data includes the number of erasures and the read / write error rate;
[0123] A data processing unit 32, configured to:
[0124] Based on the historical erasure data, dynamically divide the storage blocks of the FLASH by using a pre-trained classification model to generate a partition mapping table including an active area, an isolation area, and a discarded area; the active area is the block with the highest write priority; the isolation area is the block that opens temporary write permission within a preset error rate threshold range; the discarded area is the block that prohibits writing;
[0125] Send the partition mapping table to the edge server; the edge server receives the updated firmware sent by the cloud or the host computer, generates an incremental firmware file by comparing it with the original firmware in the FPGA, and splits the incremental firmware file into data blocks matching the target addresses according to the partition mapping table; the target addresses are the addresses of the active area and the isolation area in the partition mapping table;
[0126] An update unit 33, configured to write the received data blocks into the FLASH according to the partition mapping table to complete the firmware update.
[0127] In one embodiment, when the edge server receives the updated firmware sent by the cloud or the host computer, it sends an update instruction to the FPGA, and the above data processing unit 32 is further configured to:
[0128] In response to the update instruction, send task load information to the edge server; the edge server determines the download priority according to the task load information and sends the data blocks based on the download priority.
[0129] Furthermore, the above data processing unit 32 is further configured to:
[0130] Before receiving the data blocks, if the change range of the current task load exceeds a preset threshold, send load change information to the edge server; the edge server adjusts the download priority according to the load change information and sends the data blocks according to the adjusted download priority.
[0131] In one embodiment, when the edge server receives the updated firmware sent by the cloud or the host computer, it sends an update instruction with a digital signature to the FPGA. The data processing unit 32 is further configured to:
[0132] Verify the validity of the digital signature of the received update instruction;
[0133] If it is valid, send the task load information to the edge server; the edge server determines the download priority based on the task load information and sends the data block based on the download priority;
[0134] If it is invalid, reject the update operation and send a rejection message to the edge server.
[0135] Further, after sending the task load information to the edge server, the data processing unit 32 may also be configured to:
[0136] Before receiving the data block, if the change range of the current task load exceeds a preset threshold, send the load change information to the edge server; the edge server adjusts the download priority according to the load change information and sends the data block according to the adjusted download priority.
[0137] In one embodiment, in terms of writing the received data block into the FLASH according to the partition mapping table, the update unit 33 is specifically configured to:
[0138] After receiving the data block, determine the firmware update condition according to the current task load status;
[0139] When the firmware update condition is satisfied, write the data block into the FLASH according to the partition mapping table.
[0140] In one embodiment, in terms of writing the received data block into the FLASH according to the partition mapping table, the update unit 33 is specifically configured to:
[0141] Receive the data block and store it in the target memory; the target memory is any one of the two memories of the ping-pong buffer;
[0142] Erase the target page in the FLASH associated with the target memory to write the data block in the target memory; the target page address is determined based on the active area and the isolation area address in the partition mapping table;
[0143] When the target memory is full, switch to another memory as the new target memory and clear the data block in the memory that has been filled after all the data blocks in it are written into the target page of the FLASH;
[0144] If another memory is full at the time of switching, the data block storage is paused until the data blocks of at least one memory are written to the FLASH and cleared;
[0145] The above operations are repeatedly executed until all data blocks are received and written to the FLASH.
[0146] In one embodiment, after writing the received data block to the FLASH, the above update unit 33 is further configured to:
[0147] Perform comparison verification on each data block written to the FLASH;
[0148] If the verification fails, mark the current FLASH page as an isolation area and rewrite the corresponding data block to the spare address.
[0149] Regarding the system in the above embodiment, the specific manner in which each unit performs operations has been described in detail in the embodiment related to the method, and will not be elaborated here.
[0150] The above has described the embodiments of the present invention. The above description is exemplary and not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations are obvious to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The choice of terms used herein is intended to best explain the principles of the embodiments, the practical application, or the improvement of the technology in the market, or to enable other ordinary skill in the art in this technical field to understand the disclosed embodiments.
Claims
1. An FPGA firmware online update method, characterized in that, Applied to an FPGA, the method includes: Obtain the historical erase and write data of the FLASH; the historical erase and write data includes the number of erase and write cycles and the read and write error rate; Based on the historical erase and write data, use a pre-trained classification model to dynamically partition the storage blocks of the FLASH to generate a partition mapping table including an active area, an isolation area, and a discarded area; the active area is the block with the highest write priority; the isolation area is the block that opens temporary write permissions within a preset error rate threshold range; the discarded area is the block where writing is prohibited; Send the partition mapping table to the edge server; the edge server receives the updated firmware sent by the cloud or the host computer, generates an incremental firmware file by comparing it with the original firmware in the FPGA, and splits the incremental firmware file into data blocks that match the target addresses according to the partition mapping table; the target addresses are the addresses of the active area and the isolation area in the partition mapping table; According to the partition mapping table, write the received data blocks into the FLASH to complete the firmware update.
2. The FPGA firmware online update method according to claim 1, wherein, When the edge server receives the updated firmware sent by the cloud or the host computer, it sends an update instruction to the FPGA. The method further includes: In response to the update instruction, send task load information to the edge server; the edge server determines the download priority according to the task load information and sends the data blocks based on the download priority.
3. The FPGA firmware online update method according to claim 2, wherein, The method further includes: Before receiving the data blocks, if the change range of the current task load exceeds a preset threshold, send load change information to the edge server; the edge server adjusts the download priority according to the load change information and sends the data blocks according to the adjusted download priority.
4. The FPGA firmware online update method according to claim 1, wherein When the edge server receives the updated firmware sent by the cloud or the host computer, it sends an update instruction with a digital signature to the FPGA; The method further includes: Verify the validity of the digital signature of the received update instruction; If it is valid, send task load information to the edge server; the edge server determines the download priority according to the task load information and sends the data blocks based on the download priority; If it is invalid, reject the update operation and send a rejection message to the edge server.
5. The FPGA firmware online update method according to claim 1, wherein According to the partition mapping table, writing the received data blocks into the FLASH includes: After receiving the data blocks, determine the firmware update condition according to the current task load status; When the firmware update condition is met, write the data blocks into the FLASH according to the partition mapping table.
6. The FPGA firmware online update method according to claim 1, wherein According to the partition mapping table, writing the received data blocks into the FLASH includes: Receive the data blocks and store them in the target memory; the target memory is any one of the two memories of the ping-pong buffer; Erase the target page in the FLASH associated with the target memory to write the data blocks in the target memory; the target page address is determined based on the addresses of the active area and the isolation area in the partition mapping table; When the target memory is full, switch to another memory as the new target memory, and clear the data blocks in the full memory after all of them are written to the target page of the FLASH; If the other memory is full during the switch, suspend the data block storage until the data blocks in at least one memory are written to the FLASH and cleared; Loop through the above operations until all data blocks are received and written to the FLASH.
7. The FPGA firmware online update method according to claim 1, wherein Write the received data blocks to the FLASH. After that, the method further includes: Perform comparison verification on each data block written to the FLASH; If the verification fails, mark the current FLASH page as an isolation area and rewrite the corresponding data block to the backup address.
8. An FPGA firmware online update system, characterized in that, Applied to the FPGA, it includes: A data acquisition unit for acquiring the historical erase / write data of the FLASH; the historical erase / write data includes the number of erase / write times and the read / write error rate; A data processing unit for: Based on the historical erase / write data, dynamically divide the storage blocks of the FLASH using a pre-trained classification model to generate a partition mapping table including an active area, an isolation area, and a discarded area; the active area is the block with the highest write priority; the isolation area is the block with temporary write permission within the preset error rate threshold range; the discarded area is the block where writing is prohibited; Send the partition mapping table to the edge server; the edge server receives the updated firmware sent from the cloud or the host computer, generates an incremental firmware file by comparing it with the original firmware in the FPGA, and splits the incremental firmware file into data blocks that match the target addresses according to the partition mapping table; the target addresses are the addresses of the active area and the isolation area in the partition mapping table; An update unit for writing the received data blocks to the FLASH according to the partition mapping table to complete the firmware update.