A data transmission method for low-level control

Abstract

This invention provides a data transmission method for low-level control, comprising: performing low-level initialization on the PS side; mapping all registers of the DMA controller and the physical addresses of the DMA buffer to user-space virtual addresses based on the UIO framework, with the physical addresses of the DMA buffer becoming shared memory; directly writing waveform data into the mapped DMA buffer; before each transmission, writing transmission parameters to the mapped DMA controller and initiating DMA transmission, so that the waveform data is transmitted to the PL side; the DAC control module reading waveform data from memory and outputting analog radio frequency signals; and after transmission is completed, confirming successful transmission in user space. This invention, through the advantages of the Zynq architecture and the memory mapping of the UIO framework, allows direct control of the PL hardware by writing simple user-space code on the PS side, greatly reducing development difficulty and maintenance costs, while maintaining kernel simplicity and stability.

Description

Technical Field

[0001] This invention pertains to low-level systems in the field of particle accelerators. Specifically, it relates to a data transmission method for low-level control, wherein the radio frequency signal is based on real-time control of ZYNQ hardware devices. Background Technology

[0002] The low-level radio frequency (LLRF) system is responsible for measuring, regulating, and stabilizing the radio frequency field used for beam acceleration. The LLRF system uses a high-speed digital-to-analog converter (DAC) to convert the generated digital signal into an analog signal. Then, an in-phase / quadrature modulator (I / Q modulator) modulates the baseband signal to the radio frequency, generating the cavity drive signal. An analog-to-digital converter (ADC) acquires the radio frequency signal to monitor the radio frequency field inside the cavity.

[0003] The LLRF system must support fully automated operation, including real-time monitoring, anomaly diagnosis, open / closed-loop configuration, and RF signal adjustment. Due to users' higher precision requirements for experiments, the LLRF system must also be capable of transmitting large volumes of data from user space to the underlying logic.

[0004] The LLRF system comprises a processing system (CPU) and programmable logic array (FPGA). The processing system is used for functions such as adjusting setting parameters, viewing monitoring data, and diagnosing anomalies. The programmable logic array is used for real-time data acquisition, modulation, and demodulation.

[0005] Currently, data transmission schemes between processing systems and programmable logic can be mainly classified into the following categories:

[0006] 1) CPU+FPGA heterogeneous architecture based on PCIe interface.

[0007] Modern LLRF systems commonly employ a heterogeneous computing architecture that combines a CPU (processor system) and an FPGA (programmable logic device). In standard servers or dedicated hardware platforms, the two typically communicate via a PCIe interface. Although PCIe offers high bandwidth, its protocol is complex, hardware design and driver implementation are challenging, system integration is low, and it presents certain challenges in terms of power consumption and cost.

[0008] Currently, the UIO framework boasts advantages such as high real-time performance, high determinism, and high development efficiency, but it cannot yet be used for CPU+FPGA heterogeneous architectures. The reasons are as follows: 1. Lack of hardware abstraction layer adaptation: The UIO framework is natively designed for single-architecture devices (such as PCIe devices and industrial I / O cards). Its general drivers (such as uio_pci_generic and uio_hv_generic) are not adapted to multi-core heterogeneous architectures of heterogeneous chips (such as FPGA+CPU and Zynq MPSoC). The on-chip buses (such as AXI-Lite) and memory mapping rules of heterogeneous chips differ significantly from standard PCIe devices, causing UIO to be unable to automatically identify heterogeneous hardware resources. Manual modification of the device tree to bind hardware addresses is required, resulting in extremely high configuration complexity. 2. This framework is the first to achieve automatic adaptation to heterogeneous chips, solving the pain point of manual configuration in traditional UIO; secondly, it integrates real-time kernel and signal processing technologies, filling the gap in UIO's low-level hard real-time control.

[0009] 2) Handling data transfer methods using system kernel drivers in conjunction with DMA.

[0010] This approach is based on a heterogeneous architecture and relies on dedicated drivers written in the operating system kernel. Data needs to be copied from the user space buffer to the kernel space of the processing system. Then, the driver configures the DMA controller on the programmable logic side and transfers the data to the memory area of ​​the programmable logic side via the system bus (such as AXI). Although this method can achieve high throughput, the context switching between kernel mode and user mode and the memory copying operations result in uncertain transmission latency and high CPU resource utilization, making it difficult to meet the requirements of high real-time control.

[0011] 3) Pre-stored in programmable logic terminal memory.

[0012] Another common practice is to pre-program the waveform or parameter data into the on-chip memory of the programmable logic device (FPGA) or an external configuration ROM. While this method offers extremely low latency during operation, it is extremely inflexible. Any modification to the parameters or waveform requires resynthesis, placement and routing, and generation of a bitstream file, a process that can take hours to days, making it unsuitable for the dynamic waveform adjustment needs of experiments.

[0013] In summary, existing solutions present significant contradictions between flexibility, real-time performance, and system complexity. Therefore, there is an urgent need for a data interaction mechanism that can balance high transmission efficiency, low-latency determinism, and hardware-software decoupling to support the advanced requirements of next-generation LLRF systems in terms of accuracy, reliability, and reconfigurability. Summary of the Invention

[0014] The purpose of this invention is to provide a data transmission method for low-level control, which solves the technical bottlenecks in existing low-level radio frequency control systems, such as delay uncertainty, high system complexity, and insufficient flexibility in large-capacity data transmission between the processing system and programmable logic.

[0015] To achieve the above objectives, the present invention provides a data transmission method for low-level control, comprising:

[0016] S1: The heterogeneous chip of the Zynq series with PS and PL terminals is used as the hardware platform for the low-level system. The PS terminal is initialized at the bottom level. The PS terminal has user space and kernel space, and the PL terminal has various registers of the DMA controller.

[0017] S2: The user space is based on the UIO framework. The mmap() system call maps all registers of the DMA controller and the physical address of the DMA buffer to the virtual address of the user space, so that the physical address of the DMA buffer becomes the shared memory between the PS and PL sides.

[0018] S3: User-space applications write waveform data directly to the mapped DMA buffer;

[0019] S4: Before each transfer, the user-space application writes DMA transfer parameters to each register of the mapped DMA controller and starts the DMA transfer, so that the waveform data is transferred from the DMA buffer to the FIFO memory at the PL end.

[0020] S5: The DAC control module at the PL end reads waveform data from the FIFO memory and drives the DAC chip to output the corresponding analog radio frequency signal.

[0021] S6: After the DMA transfer is completed, the UIO framework captures the interrupt control request sent to the interrupt controller GIC and forwards it to the user space on the PS side, so that the user space confirms that the transfer was successful.

[0022] In step S1, the low-level initialization of the PS terminal is performed through the kernel space of the PS terminal, including:

[0023] S11: Kernel space resolves device tree configuration to reserve a physical address in the external DDR memory of the PS as the physical address of the DMA buffer, maps all registers of the DMA controller on the PL to the physical address space of the PS and associates the UIO driver and the interrupt controller GIC, and configures the AXI bus parameters between PS and PL.

[0024] S12: The kernel space allocates kernel virtual addresses to the physical address space of the PS side, including: establishing a mapping from the physical address of the DMA buffer to the kernel virtual address; and establishing a mapping from the hardware physical address of the DMA control register of the PL side to the kernel virtual address.

[0025] The device tree includes UIO device nodes configured with interrupt attributes, and regions reserved as DMA buffers with fixed physical addresses, declared through the device tree's reserved-memory nodes.

[0026] In step S2, the physical address space of the PS is mapped to the user space virtual address through the mmap() system call. The mapped objects include all registers of the DMA controller on the PL side and the physical address of the DMA buffer reserved on the PS side.

[0027] Step S3 specifically includes: the user-space application running the waveform generation algorithm required for the low-level system to generate waveform data that meets the RF control requirements of the accelerator's low-level system; subsequently, the waveform data is directly written to the mapped DMA buffer through the user virtual address of the mapped DMA buffer.

[0028] DMA transfer parameters are written to all registers of the DMA controller using the user-space virtual address of the mapped DMA controller registers. The DMA transfer parameters include source address, destination address, transfer length, and interrupt configuration.

[0029] Writing DMA transfer parameters to the registers of the mapped DMA controller is achieved using device files in kernel space via the UIO framework.

[0030] The status register of the DMA controller has an exception type bit; during the DMA transfer in step S4, the exception type bit of the status register of the DMA controller is monitored based on the UIO framework and matched with the self-recovery measures in the exception feature library. Then, the corresponding self-recovery measures are executed through the address mapped by the UIO framework.

[0031] After DMA transfer is initiated, the DMA controller performs DMA transfer according to the DMA transfer parameters, so that waveform data is read from the DMA buffer through the AXI bus, transferred to the DMA controller at the PL end, and then transferred to the FIFO memory at the PL end.

[0032] The DMA controller initiated by starting a DMA transfer is a Zynq PL-side DMAip core defined at the hardware design level; the DMA controller's AXI bus interface module receives the DMA transfer parameters and passes them to the DMA controller's registers; subsequently, the DMA controller's burst transfer control module controls the data path, reads waveform data from the DMA buffer at the PS end, and transmits it via the AXI bus; subsequently, the data is written to the FIFO memory at the PL end via the DMA controller's dedicated FIFO interface module.

[0033] In step S6, the user space reads the device file of the UIO framework corresponding to the UIO device file descriptor in the kernel space, waits for and receives the hardware interrupt request forwarded by the kernel space to the interrupt controller GIC, and uses it as a DMA transfer completion interrupt notification.

[0034] This invention's data transmission method for low-level control leverages the advantages of the Zynq architecture and the memory mapping of the UIO framework. Users do not need to develop kernel drivers; they can directly control the hardware on the PL side by writing simple user-space code on the PS side. This significantly reduces development difficulty and maintenance costs while maintaining kernel simplicity and stability. It enables users to accurately control complex waveforms of low-level outputs, bypassing kernel space, achieving low latency, and simplifying operation. Furthermore, it achieves low-latency interrupt handling in user space, direct access to hardware registers, and zero-copy memory management, avoiding the uncertainties introduced by kernel scheduling. Therefore, this invention solves the technical bottlenecks in existing low-level RF control systems, such as latency uncertainties, high system complexity, and insufficient flexibility in large-capacity data transmission between the processing system and programmable logic. It successfully combines hardware-level real-time performance with the development convenience of a standard Linux system, perfectly meeting the needs of high-precision, high-real-time scenarios such as low-level experiments. Attached Figure Description

[0035] Figure 1 This is a signal flow diagram of a data transmission method for low-level control according to the present invention. Detailed Implementation

[0036] like Figure 1The illustration shows a data transmission method for low-level control according to an embodiment of the present invention, which is implemented based on a Zynq series heterogeneous chip and the UIO framework deployed on it. Specifically, the Zynq series heterogeneous chip is built on the Xilinx Zynq UltraScale chip series + MPSoC (Multi-core System-on-Chip, specific model: xczu19eg-ffvc1760-2-i). This Zynq series heterogeneous chip, through its multi-core heterogeneous architecture, integrates the processing system (PS) and programmable logic (PL) components onto a single chip, thus providing an ideal hardware foundation for system function partitioning.

[0037] Traditional methods of controlling PL-side hardware negate the advantages of heterogeneous chips: for example, complex kernel drivers need to be written for each peripheral (such as DMA) on the PL side, which is difficult to develop, prone to kernel instability, and the switching between kernel mode and user mode will cause latency jitter, which violates the hard real-time requirements of the PL side.

[0038] In this invention, to address the pain points of complex development and heavy kernel burden in traditional DMA driver development, the solution innovatively adopts the UIO (Userspace I / O) framework. The UIO framework is deployed on the PS side of a heterogeneous chip, enabling the PS side to establish a direct mapping from user space to hardware resources via the mmap() system call. User space can directly access the mapped hardware resources. Users can write simple user space code on the PS side to directly control the hardware on the PL side, greatly reducing development difficulty and maintenance costs while maintaining kernel simplicity and stability. Therefore, the low-level control-oriented data transmission method of this invention directly maps the control registers of the DMA controller soft core on the PL side and the physical address of the PS-PL shared memory to the user space on the PS side through the UIO framework. The user space directly accesses and controls the DMA controller soft core on the PL side and the DMA buffer on the PS side through the UIO framework, realizing direct hardware control from user space.

[0039] The Processing System (PS) runs a standard Linux operating system and is responsible for handling complex upper-level business logic such as user interaction, network communication, and system management. The PS includes a CPU, external DDR memory, an on-chip integrated interrupt controller (GIC), an MMU memory management unit, an AXI bus interface, and general-purpose interfaces, and has both user space and kernel space. The external DDR memory (reserved as shared memory between the PS and PL sides, serving as a DMA buffer) is the core for storing waveform data. It supports direct reading and writing by the PS user program and can also be directly accessed by the PL side via the AXI bus, enabling zero-copy data exchange. The GIC receives interrupt signals from the PL side and forwards them through the UIO framework, while the MMU memory management unit implements the mapping from physical addresses to virtual addresses.

[0040] User space is the layer where developers implement specific applications. Its core is responsible for interactive control and waveform generation algorithms. It includes waveform generation applications, user-level drivers, DMA control programs (used to define core functions such as dma_tx_buffer and XAxiDmaMM2S_Start), and human-computer interaction / network management programs. The mmap() system call can establish a direct mapping from user space to hardware resources, allowing user space to directly access mapped hardware resources. This is crucial for the UIO framework to enable direct hardware control from user space. Kernel space is the intermediate layer between hardware and user space. Its core is responsible for parsing hardware configurations, reserving DMA buffers, establishing mappings between physical and virtual addresses, and forwarding PL interrupt signals. It includes kernel drivers.

[0041] The Programmable Logic (PL) side is a customized hardware logic module implemented through hardware programming of the FPGA. It is responsible for tasks with extremely high timing determinism, such as real-time data acquisition and transmission, and demodulation and modulation of high-frequency signals. The PL side includes a DMA controller (i.e., an AXI DMA controller), a FIFO memory, a DAC controller, an AXI bus interface, an SPI interface, and an SMA analog output interface. The DAC controller communicates with the DAC chip via the SPI interface and outputs the analog RF signals generated by the DAC chip to the accelerator's low-level system via the SMA analog output interface. The PL side's DMA controller is a soft core, serving as the core of data transfer within the PL side. It is responsible for reading waveform data from the PS side DMA buffer and transmitting it to subsequent modules via the AXI bus, supporting hardware-level interrupt triggering (i.e., the interrupt controller GIC sends a signal after the transmission is completed).

[0042] The PS and PL ends are interconnected via a high-performance AXI bus, ensuring high bandwidth and low latency in the data path between them.

[0043] It should be noted that the physical address allocation of the DMA controller (PL end / PS end) is essentially determined by the hardware deployment location of the DMA controller—the physical address of the control register of the DMA controller soft core deployed on the PL end is on the PL end; the physical address of the control register of the DMA controller hard core integrated on the PS end is on the PS end, and both are exposed to the CPU access on the PS end through memory mapping (MMIO). However, the DMA controllers described below in this invention are only those deployed on the PL end. The DMA buffer is located in the PS-PL shared memory on the PS end. The rest of the DMA controller consists of programmable hardware logic modules and is carried on the PL end of the Zynq hardware platform.

[0044] The data transmission method for low-level control according to the present invention specifically includes the following steps:

[0045] Step S1: Use the Zynq series heterogeneous chip with PS and PL terminals as the hardware platform for the low-level system, and perform low-level initialization on the PS terminal;

[0046] In this embodiment, the heterogeneous chip of the Zynq series is the xczu19eg-ffvc1760-2-i chip, which serves as the hardware platform for the low-level system.

[0047] The low-level initialization of the PS side is implemented through the kernel space of the PS side, including:

[0048] Step S11: Configure the kernel space device tree to reserve a physical address in the external DDR memory on the PS side as the physical address of the DMA buffer, map all registers of the DMA controller on the PL side to the physical address space on the PS side and associate them with the UIO driver and the interrupt controller GIC, and configure the AXI bus parameters between PS and PL; in addition, it may also include the configuration of basic hardware such as clock, reset, and GPIO on the PL side to achieve the matching of the UIO framework with the hardware device.

[0049] Specifically, the kernel space is informed that a segment of physical addresses in the external DDR memory of the PS (such as 0x10000000~0x18000000) will be reserved as the physical address of the DMA buffer in the physical address space of the PS.

[0050] The device tree includes UIO device nodes configured with interrupt attributes, and regions reserved as DMA buffers with fixed physical addresses, declared through the reserved-memory nodes of the device tree. In this embodiment, the device tree fragment written according to the defined physical addresses is as follows:

[0051] uio@1 { label = "uio-irq-0"; # Device debugging, used for debugging and identification compatible = "generic-uio"; # Driver matching string, tells the kernel that the device uses the generic UIO driver, eliminating the need to write a custom kernel driver status = "okay"; # Device status interrupt-parent = <&gic>; # Specifies the interrupt controller GIC (the interrupt controller GIC is located on the PS side of the Zynq chip) interrupts = <0 90 1>; # Interrupt description: <interrupt type, interrupt number, trigger type>};

[0052] reserved-memory { # Reserved memory definition nodes # address-cells = <2> # The address is represented by two 32-bit numbers (64-bit address) # size-cells= <2> ; # Size is represented by two 32-bit numbers (64-bit size) ranges; # Address mapping relationship

[0053] reserved: buffer@0 { reg = <0 0x10000000 00x08000000>; # Address mapping};};

[0054] The device tree configuration described above provides a complete hardware description for the UIO framework, enabling user-space programs to directly control hardware interrupts and access DMA buffers, making it very suitable for applications with high real-time requirements.

[0055] Step S12: The kernel space allocates kernel virtual addresses to the physical address space of the PS side, including: establishing a mapping from the physical address of the DMA buffer to the kernel virtual address; establishing a mapping from the hardware physical address of the DMA control register of the PL side to the kernel virtual address.

[0056] Step S13 (optional): Kernel space performs interrupt management cache consistency assurance, security and access control.

[0057] Zynq's PS side has a global, unique physical address space. Part of the address space is allocated to PS side native resources such as external DDR memory, while another part is reserved for PL side peripheral mappings such as DMA controller registers and PL side custom peripherals.

[0058] Step S2: The user space, based on the UIO framework, uses the mmap() system call to map all registers of the DMA controller and the physical addresses of the DMA buffer to virtual addresses in the user space. The physical address of the DMA buffer becomes the shared memory between the PS and PL sides.

[0059] The mmap() system call maps the physical address space of the PS to the virtual address space of the user space. The mapped objects include:

[0060] All registers of the DMA controller on the PL side (control register, source / destination address register, transfer length register, status register, interrupt enable register, etc.).

[0061] The physical address of the DMA buffer reserved on the PS side.

[0062] Therefore, the UIO framework maps two different address ranges in the PS's physical address space to virtual addresses in the PS's user space via the UIO framework's mmap() system call. This allows user programs to operate on various registers of the DMA controller and read / write DMA buffers within the same user space. Specifically, the kernel space portion of the UIO framework maps the physical addresses of the DMA registers to kernel virtual addresses, creating the device file / dev / uioX; the user space portion of the UIO framework maps the kernel virtual addresses to user virtual addresses via mmap(), enabling user programs to access them. Ultimately, the mmap() system call maps the PS's physical address space to user space virtual addresses. After mapping, users can directly read and write hardware resources in user space via virtual addresses without needing to manipulate the kernel.

[0063] The physical address of the DMA buffer is mapped to a virtual address by the Linux kernel through the MMU in two layers: first, it is mapped to a kernel virtual address for use by the kernel driver and the kernel part of UIO; then, through the mmap() system call of the UIO framework, it is mapped to a user space virtual address for direct access by the application. In addition, the physical address of the DMA buffer is also directly accessed by the AXI bus on the PL side (without going through the MMU and without a virtual address) for the DMA controller on the PL side to read and write, thereby realizing shared memory between the PS side and the PL side.

[0064] In this embodiment, the user space defines the function dma_tx_buffer. The function is to establish the user space virtual address of the DMA buffer mapped by mmap, including the kernel automatically selecting an appropriate virtual address, defining the mapping length, defining protection permissions to allow user space to read and write the DMA buffer, modifying it to be visible to other processes, synchronizing with the hardware, and resolving the physical address of the DMA buffer in reverse.

[0065] Step S3: The user-space application writes the waveform data directly to the mapped DMA buffer;

[0066] Step S3 specifically includes: the user space application runs the waveform generation algorithm (such as triangular wave, sine wave) required by the low-level system to generate waveform data that meets the RF control requirements of the accelerator's low-level system; then, the waveform data is directly written to the mapped DMA buffer through the user virtual address of the mapped DMA buffer.

[0067] The user space virtual address of the DMA buffer is mapped to the physical address of the DMA buffer. Therefore, data written to the user space virtual address of the DMA buffer will be directly converted into read and write to the shared memory between the PS and PL sides. This allows it to be accessed by the CPU on the PS side (through the kernel / user space) and by the AXI DMA controller soft core on the PL side directly through the AXI bus, without the need for data copying, thus adapting to the high frequency and high bandwidth requirements of waveform transmission.

[0068] Step S4: Before each transfer, the user-space application writes DMA transfer parameters to each register of the mapped DMA controller and starts DMA transfer, so that waveform data is transferred from the DMA buffer to the PL end.

[0069] Specifically, DMA transfer parameters are written to all registers of the DMA controller (control register, source / destination address register, transfer length register, status register, and interrupt enable register) through the user-space virtual address of the mapped DMA controller registers. DMA transfer parameters include source address (i.e., the physical address of the DMA buffer), destination address (i.e., the hardware physical address of the FIFO memory at the PL end), transfer length, and interrupt configuration (writing instructions to the DMA interrupt enable register to ensure that feedback can be sent to user space to enable interrupts after the transfer is completed).

[0070] Writing DMA transfer parameters to the various registers of the mapped DMA controller is implemented by the user-space application through the kernel space, specifically using the UIO framework's device file / dev / uioX in the kernel space. The UIO framework's / dev / uioX is a device file (where X is a number, such as / dev / uio1, corresponding to uio@1 in the device tree) created by the UIO framework in the / dev directory of the kernel space in the Linux system. It is the only software interface between user space and hardware resources (PL-side DMA, interrupts, etc.). User space can access and configure the DMA controller's registers through the mapping capabilities of this device file without writing a kernel driver.

[0071] Initiating a DMA transfer is achieved by the user-space application writing a start transfer instruction to the DMA controller's control register. After initiating the DMA transfer, the DMA controller performs the DMA transfer according to the DMA transfer parameters, causing waveform data to be read from the DMA buffer via the AXI bus, transferred to the DMA controller at the PL end, and then transferred to the FIFO memory at the PL end.

[0072] In this embodiment, a core startup function `XAxiDmaMM2S_Start` is defined in user space. Its function is to write DMA transfer parameters to the DMA controller's registers and to write a start transfer instruction to the DMA controller's control register to initiate DMA transfer. In this embodiment, a 32-bit wide, 1024-point triangular wave is defined in user space as a template for waveform data. First, the DMA is initialized using the DMA initialization function `XAxiDmaInit`, then the DMA is reset using the DMA reset function `XAxiDmaReset`. Subsequently, the core startup function `XAxiDmaMM2S_Start` is used to write DMA transfer parameters to the various registers of the DMA controller and initiate DMA transfer.

[0073] In this embodiment, the DMA controller initiated to start the DMA transfer is a Zynq PL-side DMA IP core (i.e., a soft core) defined at the hardware design level. It is configured, instantiated, and bound to the AXI bus by the developer in Vivado. The DMA IP core is configured with a 32-bit width, a maximum burst length of 16, and its AXI_Slave offset address is defined as 0x8000_0000. The DMA controller's AXI bus interface module receives the DMA transfer parameters and passes them to the DMA controller's registers. Subsequently, the DMA controller's burst transfer control module controls the data path, reading waveform data from the source address (the DMA buffer at the PS end) and transferring it via the AXI bus with a burst length of 16. Finally, the data is written to the FIFO memory at the PL end via the DMA controller's dedicated FIFO interface module.

[0074] Step S5: The DAC control module at the PL end reads waveform data from the FIFO memory and drives the DAC chip to output the corresponding analog radio frequency signal;

[0075] The DAC controller connects to a DAC chip, such as the ad9783, via an SPI interface. The DAC chip converts digital waveform data into analog radio frequency signals and outputs these signals to the low-level system of the particle accelerator via an SMA analog output interface.

[0076] Step S6: After the DMA transfer is completed, the UIO framework captures the interrupt control request sent to the interrupt controller GIC and forwards it to the user space on the PS side, so that the user space confirms that the transfer was successful.

[0077] During DMA transfer, the DMA controller's transfer length counter counts in real time. When the count reaches zero, it indicates that the DMA transfer is complete. The DMA controller's status register sets the transfer completion flag, causing the interrupt control module of the DMA controller on the PL side to send a hardware interrupt request to the interrupt controller GIC on the PS side.

[0078] In this process, user space reads the device file ( / dev / uioX) in kernel space corresponding to the UIO device file descriptor, waits for and receives hardware interrupt requests forwarded by kernel space to the interrupt controller GIC, and uses this as a DMA transfer completion interrupt notification. Therefore, user space only receives an "interrupt notification (soft signal)" forwarded by the device file in kernel space to confirm the transfer's completion, allowing for the execution of other business logic.

[0079] Furthermore, the DMA controller's status register can be expanded by adding "exception type bits" (e.g., 0x04 = FIFO overflow, 0x08 = bus timeout, 0x10 = data verification error). During the DMA transfer in step S4, the exception type bits in the DMA controller's status register are monitored using the UIO framework and matched against the self-recovery measures in the exception signature library. Subsequently, the corresponding self-recovery measures are executed through the address mapped by the UIO framework. The exception signature library includes matching exception types and self-recovery measures. For example, for FIFO overflow, the matching self-recovery measures are reducing the burst length, clearing the FIFO, and rewriting the data; for a single transfer error, the matching self-recovery measures are resetting the DMA controller, reconfiguring parameters, and retrying the transfer; for bus timeout, the matching self-recovery measures are switching to a backup DMA channel and reporting the exception log. All self-recovery measures are completed through the address mapped by the UIO framework and are executed entirely in user space without kernel intervention.

[0080] This invention's data transmission method for low-level control leverages the advantages of the Zynq architecture and the memory mapping of the UIO framework. Users do not need to develop kernel drivers; they can directly control the hardware on the PL side by writing simple user-space code on the PS side. This significantly reduces development difficulty and maintenance costs while maintaining kernel simplicity and stability. It enables users to accurately control complex waveforms of low-level outputs, bypassing kernel space, achieving low latency, and simplifying operation. Furthermore, it achieves low-latency interrupt handling in user space, direct access to hardware registers, and zero-copy memory management, avoiding the uncertainties introduced by kernel scheduling. Therefore, this invention solves the technical bottlenecks in existing low-level RF control systems, such as latency uncertainties, high system complexity, and insufficient flexibility in large-capacity data transmission between the processing system and programmable logic. It successfully combines hardware-level real-time performance with the development convenience of a standard Linux system, perfectly meeting the needs of high-precision, high-real-time scenarios such as low-level experiments.

[0081] The method of the present invention has the following advantages:

[0082] High real-time performance: User space directly operates on the hardware, avoiding kernel context switching and data copying, reducing latency from hundreds of microseconds to microseconds.

[0083] High determinism: Interrupt and handling logic are both completed in user space, which greatly reduces timing jitter caused by kernel scheduling.

[0084] High development efficiency: The vast majority of the code is developed in user space, making debugging convenient and allowing full use of the toolchain and library functions in the Linux ecosystem.

[0085] High reliability: Failures in user-space programs will not cause the entire system kernel to crash, thus improving system stability.

[0086] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of the invention. Various variations can be made to the above embodiments of the present invention. All simple and equivalent changes and modifications made in accordance with the claims and description of this application fall within the protection scope of the claims of this patent. All aspects not described in detail in this invention are conventional technical content.

Claims

1. A data transmission method oriented to low-level control, characterized in that, include: Step S1: Use the Zynq series heterogeneous chip with PS and PL terminals as the hardware platform for the low-level system. Perform low-level initialization on the PS terminal. The PS terminal has user space and kernel space, and the PL terminal has various registers of the DMA controller. Step S2: Based on the UIO framework, the user space uses the mmap() system call to map all registers of the DMA controller and the physical addresses of the DMA buffer to virtual addresses in the user space, making the physical address of the DMA buffer a shared memory between the PS and PL ends. Step S3: The user-space application writes the waveform data directly to the mapped DMA buffer; Step S4: Before each transfer, the user-space application writes DMA transfer parameters to each register of the mapped DMA controller and starts DMA transfer, so that waveform data is transferred from the DMA buffer to the FIFO memory at the PL end. Step S5: The DAC control module at the PL end reads waveform data from the FIFO memory and drives the DAC chip to output the corresponding analog radio frequency signal; Step S6: After the DMA transfer is completed, the UIO framework captures the interrupt control request sent to the interrupt controller GIC and forwards it to the user space on the PS side, so that the user space confirms that the transfer was successful.

2. The data transmission method for low-level control according to claim 1, characterized in that, In step S1, the low-level initialization of the PS terminal is performed through the kernel space of the PS terminal, including: Step S11: Configure the kernel space device tree to reserve a physical address in the external DDR memory of the PS as the physical address of the DMA buffer, map all registers of the DMA controller on the PL to the physical address space of the PS and associate them with the UIO driver and the interrupt controller GIC, and configure the AXI bus parameters between PS and PL. Step S12: The kernel space allocates kernel virtual addresses to the physical address space of the PS side, including: establishing a mapping from the physical address of the DMA buffer to the kernel virtual address; establishing a mapping from the hardware physical address of the DMA control register of the PL side to the kernel virtual address.

3. The data transmission method for low-level control according to claim 2, characterized in that, The device tree includes UIO device nodes configured with interrupt attributes, and regions reserved as DMA buffers with fixed physical addresses, declared through the device tree's reserved-memory nodes.

4. The data transmission method for low-level control according to claim 1, characterized in that, In step S2, the physical address space of the PS is mapped to the user space virtual address through the mmap() system call. The mapped objects include all registers of the DMA controller on the PL side and the physical address of the DMA buffer reserved on the PS side.

5. The data transmission method for low-level control according to claim 1, characterized in that, Step S3 specifically includes: the user-space application running the waveform generation algorithm required for the low-level system to generate waveform data that meets the RF control requirements of the accelerator's low-level system; subsequently, the waveform data is directly written to the mapped DMA buffer through the user virtual address of the mapped DMA buffer.

6. The data transmission method for low-level control according to claim 1, characterized in that, DMA transfer parameters are written to all registers of the DMA controller using the user-space virtual address of the mapped DMA controller registers. The DMA transfer parameters include source address, destination address, transfer length, and interrupt configuration. Writing DMA transfer parameters to each register of the mapped DMA controller is implemented using the device file in kernel space by the UIO framework.

7. The data transmission method for low-level control according to claim 1, characterized in that, The status register of the DMA controller has an exception type bit; during the DMA transfer in step S4, the exception type bit of the status register of the DMA controller is monitored based on the UIO framework and matched with the self-recovery measures in the exception feature library. Then, the corresponding self-recovery measures are executed through the address mapped by the UIO framework.

8. The data transmission method for low-level control according to claim 1, characterized in that, After DMA transfer is initiated, the DMA controller performs DMA transfer according to the DMA transfer parameters, so that waveform data is read from the DMA buffer through the AXI bus, transferred to the DMA controller at the PL end, and then transferred to the FIFO memory at the PL end.

9. The data transmission method for low-level control according to claim 8, characterized in that, The DMA controller initiated by starting a DMA transfer is a Zynq PL-side DMA IP core defined at the hardware design level. The DMA controller's AXI bus interface module receives the DMA transfer parameters and passes them to the DMA controller's registers. Subsequently, the DMA controller's burst transfer control module controls the data path, reads waveform data from the DMA buffer at the PS end, and transmits it via the AXI bus. Then, the data is written to the FIFO memory at the PL end via the DMA controller's dedicated FIFO interface module.

10. The data transmission method for low-level control according to claim 1, characterized in that, In step S6, the user space reads the device file of the UIO framework corresponding to the UIO device file descriptor in the kernel space, waits for and receives the hardware interrupt request forwarded by the kernel space to the interrupt controller GIC, and uses it as a DMA transfer completion interrupt notification.

Images