ZynqMP non-blocking partial reconfiguration method based on Linux system collaboration

Abstract

The invention discloses a ZynqMP non-blocking part reconfiguration method based on Linux system collaboration, and the method comprises the steps: constructing a static ICAP control module on a hardware layer as a shell layer of a reconfigurable region, and integrating an AXI4-Stream DMA receiving interface, an ICAP primitive control unit and finite-state machine coordination logic; in an operating system layer, zero-copy memory sharing of a user space and DMA is achieved through Udmabuf drive, and a PR daemon process of a kernel space coordinates AXIDMA to transmit part of bit streams to a PL end bit stream buffer area at a high speed; in an application interface layer, a non-blocking API based on a file system is provided, a user application initiates a reconfiguration request through write operation and then returns the reconfiguration request immediately, and a CPU does not need to be blocked. After the PL end finite-state machine receives the instruction, microsecond-level hardware reconstruction is directly executed through ICAP primitives, and interruption is triggered to inform the PS end after the microsecond-level hardware reconstruction is completed. Automation, low delay (microsecond level) and non-blocking operation of the whole reconfiguration process of the FPGA part are achieved, and the method is suitable for communication and embedded systems with high requirements for real-time performance and flexibility.

Description

Technical Field

[0001] This invention relates to the field of communication technology, specifically to an automated method for partial reconfiguration (PR) of Field-Programmable Gate Arrays (FPGAs) based on the Xilinx Zynq UltraScale+MPSoC (ZynqMP) platform. More specifically, this invention provides a dynamic FPGA reconfiguration technology integrated into the Linux operating system environment, particularly suitable for scenarios in communication systems requiring high real-time performance and low latency switching between different hardware functional modules (such as modems, encoders, encryption units, signal processing accelerators, etc.). This invention achieves efficient and flexible scheduling and management of FPGA resources in communication devices by combining an automated construction process with a user-space non-blocking API. Background Technology

[0002] With the development of technologies such as 5G and edge computing, communication systems are placing higher demands on the real-time performance and flexibility of hardware platforms. Partial reconfiguration (PR) technology of Field Programmable Gate Arrays (FPGAs) can dynamically switch hardware functional modules (such as modulators and encryption engines) at runtime, enabling on-demand resource allocation.

[0003] Currently, the main PR reconfiguration technologies on Xilinx Zynq series system-on-a-chip (SoC) include the following solutions:

[0004] (1) PCAP-based Linux FPGA Manager: This solution integrates the reconfiguration operation into the Linux kernel and controls it through the standard / dev / fpga-mgr interface. However, its reconfiguration process completely blocks the processor (PS), resulting in system latency of up to milliseconds. During this period, the processor cannot process any communication tasks, which seriously affects the real-time performance and quality of service (QoS) of the communication system and cannot meet the requirements of high-throughput, low-latency communication applications.

[0005] (2) Based on Axi_hwicap IP core: The Xilinx-provided axi_hwicap IP core runs by accessing the ICAP internal configuration access port through the AXI bus, which can theoretically shorten the reconfiguration time to the microsecond level. However, the IP core relies on the AXI-Lite bus to write bitstream data byte by byte, which has low transmission efficiency and occupies the bus during processing, resulting in a real-time bottleneck.

[0006] (3) Direct operation of ICAP in bare metal environment: In an environment without operating system support, ICAP is directly controlled through the PL terminal to complete bit switching. Although this solution has the best performance and the lowest latency, it lacks operating system support, making it difficult to implement complex communication protocol switching, file system, and network management functions. Moreover, the development and maintenance costs are high, and it cannot be integrated with the Linux software ecosystem, resulting in limited functionality.

[0007] In summary, existing technologies for FPGA reconfiguration on the Zynq platform generally suffer from a trade-off between performance and ease of use: FPGA-mgr-based solutions completely block the processor, resulting in millisecond-level reconfiguration latency, which cannot meet the QoS requirements of high real-time communication scenarios; while axi_hwicap, based on ICAP, is limited by the AXI-Lite bus bandwidth, leading to low data transmission efficiency; and while bare-metal solutions offer performance comparable to ICAP, they are also limited by the AXI-Lite bus bandwidth, resulting in low data transmission efficiency; and while bare-metal solutions offer the best performance, they lack key capabilities provided by the operating system, such as network, file system, and multi-task management, making it difficult to support complex communication protocols and product deployment.

[0008] Currently, no solution can simultaneously meet all three requirements mentioned above. Therefore, there is an urgent need for an automated solution that can achieve microsecond-level high-speed reconfiguration using ICAP, deeply integrate with the Linux operating system, and provide simple, non-blocking call interfaces for upper-layer applications. Summary of the Invention

[0009] To address the aforementioned issues, this invention provides a ZynqMP non-blocking partial reconfiguration method based on Linux system collaboration. Its core lies in: deploying a static ICAP control module and a finite state machine at the PL end; utilizing Udmabuf and AXI DMA at the PS end to achieve zero-copy high-speed transmission; and having the PR daemon coordinate the non-blocking reconfiguration process. This allows for microsecond-level, non-blocking FPGA partial reconfiguration while preserving the complete Linux system.

[0010] To achieve the above objectives, the present invention provides the following technical solution: a ZynqMP non-blocking partial reconfiguration method based on Linux system collaboration, comprising a hardware layer, an operating system layer, and an application interface layer.

[0011] The hardware layer of this invention is based on the Xilinx Zynq UltraScale+MPSoC platform and adopts a hybrid architecture of "Static Shell + Reconfigurable Region (RR)" to build a high-performance hardware execution environment that supports microsecond-level, non-blocking partial reconfiguration. This layer achieves end-to-end acceleration from bitstream transmission to hardware reconfiguration through deep collaboration with the intelligent control state machine built into the PL via dedicated high-speed interconnects. Its core structure and working mechanism are as follows:

[0012] High-speed on-chip interconnect and data transfer mechanism: A high-speed connection is established between the processing system (PS) and the programmable logic (PL) through the AXI-HPC (High-Performance Coherent) master bus. High-bandwidth data transmission between the PS and PL is realized through the high-speed on-chip interconnect path, providing a physical channel for the rapid transmission of some bit streams.

[0013] Two dedicated DMA channels are configured for efficient, low-overhead data transfer: The PS-PL's AXI-DMA channel transfers a portion of the bitstream file stored in the PS-side DDR memory to the bitstream buffer within the PL at high speed via the AXI4-Stream protocol. This channel features both interrupt-triggered and polling modes, allowing for flexible selection based on application scenarios. It ensures the transfer process is completely transparent to the CPU, achieving true non-blocking operation. A zero-copy DMA channel within the PS: In conjunction with the Udmabuf driver, a physically contiguous memory region supporting DMA is created on the PS side and directly mapped to user space. This channel enables zero-copy access to the same physical memory by user applications, the PR daemon, and the DMA engine, completely avoiding redundant data copying between user space and kernel space, significantly improving overall system efficiency.

[0014] Static ICAP Control Module and Finite State Machine (FSM) Coordination Unit: A static ICAP control module (PR Shell) is deployed in the FPGA programmable logic (PL). This module is located in a fixed position outside the reconfigurable region (RR) and serves as the common hardware infrastructure for all dynamically switching functional modules. Its physical layout remains unchanged during system operation. The core of this module is a Finite State Machine (FSM) coordination unit, responsible for precise timing control throughout the entire process. The FSM receives instructions from the PS end through a dedicated control register interface mapped by the UIO driver, including configuration start commands and the address offset of the target bit stream in the buffer, ensuring low-latency delivery of control instructions. The FSM's state machine includes four key states: IDLE, READY, CONFIG, and DONE, strictly following a preset process to advance the reconfiguration operation. The FSM coordinates AXIDMA to write the bitstream data transmitted by the PS into the BRAM buffer. This design bypasses the slow AXI-Lite bus, allowing the reconfiguration process to directly act on the FPGA's configuration engine, compressing the reconfiguration latency to the microsecond level. This performance far exceeds that of the traditional FPGA-MGR solution (millisecond level) that relies on the processor to write registers byte by byte.

[0015] Static isolation and status feedback mechanism: An isolation unit is integrated at the boundary between the reconfigurable region (RR) and the static region (SR). When the FSM is in the CONFIG state, this unit automatically disconnects the user data path and automatically isolates the signal paths of the reconfigurable region and static logic during reconstruction, effectively isolating electrical noise during the reconstruction process, preventing interference to critical static logic such as communication and control, and ensuring stable system operation. When the FSM successfully completes reconstruction and enters the DONE state, it immediately sends a configuration completion interrupt signal to the PS's interrupt controller (GIC) via a dedicated interrupt line, realizing real-time status feedback at the hardware level. The PR daemon on the PS side responds to this signal in the interrupt service routine, confirming successful hardware reconstruction and completing seamless synchronization of software and hardware.

[0016] The operating system layer, deployed in the Linux operating system kernel space, acts as a bridge between the hardware execution layer and the user application interface layer, responsible for runtime resource scheduling and process control. This layer mainly includes:

[0017] The Udmabuf driver creates a physical contiguous memory buffer that supports DMA in kernel space and maps it to user space. This enables zero-copy access to the same physical memory by user space applications, kernel services, and the DMA controller, avoiding multiple copies of data in memory and greatly improving data transfer efficiency.

[0018] Xilinx AXI DMA driver: Used to configure and manage the AXI DMA controller, coordinating the transfer of a portion of the bitstream data stored in the udmabuf buffer directly from the PS's DDR memory to the bitstream buffer in the PL via a high-speed DMA channel. The entire process requires no CPU intervention, freeing up processor resources.

[0019] UIO driver: Maps the control registers and interrupt lines of the ICAP control module in PL to user space, enabling the PR daemon running in kernel space to send commands to the ICAP control module and receive interrupt notifications through the standard ioctl interface, thus achieving efficient communication between hardware and software.

[0020] The PR daemon, a core service running in kernel space, is responsible for coordinating the entire reconfiguration process. It receives reconfiguration requests from user space, loads a specified portion of the bitstream file from the file system into the DMA buffer via the Udmabuf driver, configures the AXIDMA driver to initiate high-speed data transfer, and triggers the ICAP control module to perform hardware reconfiguration via the UIO driver after DMA completion.

[0021] The application interface layer, geared towards end users and application developers, provides a simple, intuitive, and non-blocking calling interface, hiding the complexity of the underlying hardware and operating system. This layer mainly includes:

[0022] Standard file system integration: Partial bitstream files (.bin format) of all reconfigurable modules are pre-stored in the Linux root file system (e.g., / lib / firmware / pr-modules / ). The PR daemon can load them directly through the standard file I / O interface without the need for special tools. Hot updates of hardware functions are supported by replacing files in this directory, greatly improving the convenience of system maintenance and upgrades.

[0023] Non-blocking API: Provides a lightweight API library for developers of high-level languages ​​such as C / C++, encapsulating read and write operations on virtual device files and providing functions such as reconfiguration requests to further simplify the development process. Attached Figure Description

[0024] Figure 1 : Overall architecture diagram of the invention

[0025] Figure 2 ICAP Module Workflow Diagram

[0026] Figure 3 This is a flowchart illustrating the entire build and deployment process for a partial reconfiguration (PR), showcasing the steps from hardware extraction, generating board-level designs, generating bitstreams, building and deploying the Linux system and operating system. Detailed Implementation

[0027] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. These embodiments are based on the technical solution of the present invention and provide detailed implementation methods and specific operating procedures. However, the scope of protection of the present invention is not limited to the following embodiments.

[0028] To make the objectives, technical solutions, and advantages of this invention clearer, the following description is provided in conjunction with the appendix. Figure 1 The technical solution of the present invention will be further described in detail below with specific embodiments. This embodiment takes the construction of a communication system supporting dynamic modem switching on the Xilinx Zynq UltraScale+ MPSoC platform as an example for illustration.

[0029] s1: In the Vivado design environment, first identify and extract the static regions that will not change in the FPGA design, which will serve as the basis for all subsequent PR designs.

[0030] s2: For modem function modules that require dynamic switching, extract them from the main design to form independent IP or sub-designs.

[0031] s3: Encapsulate the extracted PR module into a black box and define its interface signals.

[0032] s4: Synthesize each individual PR module and export the corresponding DCP file. The DCP file contains the logic synthesis result of that module and is the foundation for subsequent board-level design.

[0033] s5: Determine whether all DCP files for all PR modules have been generated. If not, return to s2 and repeat the above steps until all DCP files have been generated.

[0034] s6: Create a new empty project in Vivado as the top-level board design for the entire system. In this new project, you need to extract and add basic modules such as AXI Direct Memory Access, dynamic reconfiguration module based on ICAP primitives, and ZynqUltraScale+MPSoc.

[0035] s7: Import the static regions extracted in s1 into the current board design, specify their physical location on the FPGA, and plan their resource usage (the actual physical location planned for each static region is the reconfigurable region).

[0036] s8: Synthesize and instantiate the complete board-level design, including the static region and all black-box modules.

[0037] s9: Perform placement and routing to generate the physical implementation scheme.

[0038] s10: Load the completed wiring design, ready for subsequent bitstream generation.

[0039] s11: In Vivado, load the DCP file of a PR module generated in stage S5 into the board-level design generated in stage S10, replacing the corresponding black box.

[0040] s12: Synthesize and implement the complete board-level design that includes the PR module.

[0041] s13: Perform place-and-route to generate the physical implementation containing the PR module.

[0042] s14: Export the overall design bitstream file (.bit) and the corresponding hardware description file HDF / XSA file.

[0043] s15: Determine if the generation of partial bitstream files for all PR modules has been completed. If not, select the next DCP file, return to step s12, and repeat the above process until the partial bitstream files for all PR modules have been generated.

[0044] s16: A project directory created using the petalinux tool. The HDF / XSA files generated by s14 are added to this directory to extract information for configuring the Linux kernel.

[0045] s17: Use the petalinux tool to create a corresponding project based on the hardware configuration information extracted from the hardware description file.

[0046] s18: Configure the Device Tree File (DTC) in the project to define reconfigurable region addresses, interrupts, and other hardware information for subsequent drivers to recognize.

[0047] s19: Integrates the necessary Yocto layers and package recipes to support the drivers and userspace tools required by the PR.

[0048] s20: Add custom ICAP driver, DMA driver, and PR daemon code to the PetaLinux project.

[0049] s21: Configure project parameters, start the build process, and generate a complete Linux system image including the kernel image (image.ub), boot file (BOOT.bin), root file system (rootfs), etc.

[0050] s22: Prepare storage devices such as SD cards or eMMCs, which will be used to store the operating system image after storage partitioning.

[0051] s23: Deploy the Linux system image file generated by s21 to the corresponding partition of the storage medium to complete the deployment of the Linux system.

[0052] s24: Convert the bitstream files of each PR module generated by s15 into .bin format files using the bootgen tool and copy them to the specified path under the rootfs directory ( / lib / firmware / pr-modules / ) for the running PR daemon to read and load.

[0053] s25: Runs the application layer server application, receives control information from the host computer, performs dynamic reconstruction, reads part of the bitstream file into the Udmabuf buffer through file I / O operations, and enables AXI-DMA transfer.

[0054] s26: The PR daemon writes a configuration start command to the control register of the ICAP control module on the PL side through the UIO driver, along with the address offset information of the target bit stream in the Udmabuf buffer, triggering the finite state machine (FSM) to enter the READY state.

[0055] s27: The AXI DMA controller detects a transfer request, automatically reads a portion of the bitstream data from the Udmabuf buffer, and transfers the data in batches to the bitstream buffer at the PL end through the AXI4-Stream high-speed channel; after the transfer is completed, the DMA controller generates an interrupt signal to notify the PR daemon.

[0056] s28: The PR daemon responds to the DMA interrupt, confirms that the data transfer is complete, and sends an execution instruction to the ICAP control module again through the UIO driver, causing the FSM to switch from the READY state to the CONFIG state and start hardware reconfiguration.

[0057] s29: In the CONFIG state, the FSM of the ICAP control module drives the ICAP primitive control unit to read data sequentially from the bit stream buffer and write it into the ICAP_VUPLUS primitive, performing dynamic reconstruction of the reconfigurable region; at the same time, the multiplexing and isolation unit disconnects the user data path to ensure system stability.

[0058] s30: When all bitstream data has been written, the FSM of the ICAP control module automatically enters the DONE state and sends a configuration completion interrupt signal to the PS-side GIC via a dedicated interrupt line.

[0059] s31: The PR daemon catches the configuration completion interrupt, confirms the successful hardware refactoring, and dynamically loads the device tree overlay file (DTO) corresponding to the new module through the device tree management interface (such as / sys / kernel / config / device-tree / overlays / ), enabling the Linux kernel to recognize the new hardware function and create the corresponding device node (such as / dev / modem_qpsk).

[0060] s32: The PR daemon returns a "reconstruction successful" status code to the host computer TCP client and opens the device node of the new hardware module for user applications to access, completing a complete non-blocking dynamic reconstruction process.

[0061] In summary, S1 to S24 constitute the automated construction and deployment phase of this invention, completing the setup of the system's static environment; while S25 to S32 constitute the runtime execution phase of this invention, enabling low-latency, non-blocking, and automated dynamic switching of the FPGA's reconfigurable regions during system operation. These two phases work together to achieve the core objective of this invention: seamlessly integrating high-performance hardware reconfiguration capabilities into the Linux operating system, providing a flexible and efficient hardware resource scheduling solution for communication systems.

Claims

1. A non-blocking partial reconfiguration method for ZynqMP based on Linux system collaboration, characterized in that, Includes the following steps: In user space, the application sends a reconfiguration request for a specified reconfigurable module to the PR daemon in kernel space via a non-blocking API and returns immediately without blocking the current thread; The PR daemon responds to the reconfiguration request by loading the corresponding target bitstream file from a pre-defined directory in the root file system into a physical contiguous memory buffer created by the Udmabuf driver. Configure the Xilinx AXIDMA controller to transfer the target portion of the bitstream from the physical contiguous memory buffer to the bitstream buffer in the ZynqMP programmable logic (PL) via the AXI4-Stream high-speed channel; The configuration startup command is written to the control register of the static ICAP control module deployed in the PL via the UIO driver. The finite state machine (FSM) in the static ICAP control module receives the configuration start instruction, reads data sequentially from the bit stream buffer, and drives the ICAP_VUPLUS primitive through the ICAP primitive control unit to perform microsecond-level hardware reconfiguration on the predefined reconfigurable region. After the hardware reconfiguration is completed, the finite state machine enters the DONE state and sends a configuration completion interrupt signal to the processor system (PS) via a dedicated interrupt line; The PR daemon responds to the configuration completion interrupt signal, confirms successful refactoring, and reports the refactoring status to the upper-layer application. The PR daemon dynamically loads the corresponding device tree overlay file based on the module type corresponding to the target bitstream, so that the Linux kernel can recognize the new hardware function and create the corresponding device node.

2. The method according to claim 1, characterized in that, The static ICAP control module serves as a static shell of the reconfigurable region, and its internal states include IDLE, READY, CONFIG, and DONE. In the CONFIG state, the finite state machine coordinates the reading of data from the bitstream buffer and drives the ICAP primitive control unit to perform a write operation.

3. The method according to claim 1, characterized in that, During the hardware reconfiguration process, the multiplexing and isolation unit in the static ICAP control module automatically disconnects the user data path between the reconfigurable area and the static area; after the reconfiguration is completed, the hardware interface connection between the static area and the reconfigurable area is automatically switched according to the type of the newly loaded module.

4. The method according to claim 1, characterized in that, Upon receiving a reconfiguration request, the PR daemon directly loads a portion of the target module's bitstream file from a pre-defined directory in the root file system via the Linux standard file I / O interface. When the reconfigurable module functionality needs to be updated, simply replace the corresponding file in the directory to achieve seamless hot updates on the next load request.

5. The method according to claim 1, characterized in that, The physical contiguous memory buffer created by the Udmabuf driver is simultaneously mapped to both user space and kernel space, enabling zero-copy access to the same physical memory by user applications, the PR daemon, and the AXIDMA controller.

6. An electronic device for performing the method according to any one of claims 1-5, characterized in that, include: The Zynq UltraScale+ MPSoC chip has a static ICAP control module deployed on its programmable logic (PL) side. The static ICAP control module includes an AXI4-Stream DMA receive interface unit, an ICAP primitive control unit, a finite state machine (FSM) coordination unit, and a multiplexing and isolation unit. An embedded Linux operating system running on the Zynq UltraScale+ MPSoC chip processor system (PS) includes the kernel space Udmabuf driver, Xilinx AXIDMA driver, UIO driver, and PR daemon. The storage unit has a root file system pre-configured with partial bitstream files of multiple reconfigurable modules; User-space application programming interfaces (APIs) are used by applications to initiate non-blocking reconfiguration requests.

7. The electronic device according to claim 6, characterized in that, The finite state machine (FSM) in the static ICAP control module receives the configuration start instruction from the PS end through the control register mapped by the UIO driver, and sends a configuration completion interrupt signal to the general interrupt controller (GIC) on the PS end through a dedicated interrupt line after the reconstruction is completed.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the Linux system-cooperative ZynqMP non-blocking partial reconfiguration method as described in any one of claims 1-5.

Images