GPMC-based dual-mode adaptive transmission method and system for ARM and FPGA

Abstract

The application discloses a dual-mode adaptive transmission method for ARM and FPGA based on GPMC, and comprises the following steps: S1, system initialization; S2, data transmission preparation; S3, threshold calculation and mode selection; S4, data transmission; and S5, frequency feedback and closed-loop control. A dual-mode adaptive transmission system for ARM and FPGA based on GPMC comprises an ARM processor module, an FPGA module, a GPMC interface module and a driver program module. The ARM processor module is integrated with a dual-core Cortex-A53 architecture core, a 133MHz efficient GPMC controller, a uDMA controller and a PRUSS real-time unit, and is internally provided with a data volume intelligent identification unit, a threshold dynamic calculation unit, a mode selection unit and an instruction interaction unit. The FPGA module is integrated with a timing detection unit, a BRAM data storage unit, a double-counter unit and a frequency measurement unit. The application has the advantages of being capable of dynamically and adaptively switching transmission modes according to data volume, low cost, plug-and-play and strong ease of use through the cooperation of the above steps.

Description

Technical Field

[0001] This invention relates to the field of embedded and heterogeneous computing technology, specifically to a dual-mode adaptive transmission method and system for ARM and FPGA based on GPMC. Background Technology

[0002] The heterogeneous architecture of ARM processors and FPGAs is widely used in embedded systems because it combines the versatility of CPUs with the parallel processing capabilities of FPGAs. High-speed data transmission between the two is a core element to ensure system performance. As the standard parallel interface of TI series ARM processors, the GPMC interface has become the mainstream choice for communication between ARM and FPGA due to its high bandwidth and multi-timing adaptation features.

[0003] In existing technologies, ARM and FPGA transmission solutions based on GPMC have the following core defects: 1. Fixed transmission modes, unable to dynamically adapt to data volume: Existing solutions only support two isolated fixed modes—CPU register read / write mode (low latency but bandwidth only 10~30MB / s) and UDMA block transmission mode (peak bandwidth 70~80MB / s but high startup overhead). They lack a dynamic switching mechanism. In scenarios with small data volumes (e.g., single frame data <1KB), the startup overhead of UDMA mode (approximately 50~100μs) significantly increases the actual latency. In scenarios with large data volumes (e.g., single frame data >10KB), the bandwidth of CPU register read / write mode is insufficient to meet high-speed transmission requirements. 2. High mode switching costs and risk of data loss: Mode switching in existing solutions requires explicit interface calls from upper-layer software and reconfiguration. Setting GPMC timing parameters or generating interrupt signals can result in switching delays of hundreds of microseconds, and data frame loss is prone to occur during switching, failing to meet the reliability requirements of real-time control scenarios; 3. Poor FPGA portability and high maintenance costs: The FPGA side requires dedicated logic design and synthesis programming for the specific GPMC timing parameters (such as address setup time and data hold time) of the ARM platform. When the ARM platform is changed (such as upgrading from AM335x to AM62L), the FPGA logic needs to be redeveloped and repeatedly debugged. The porting cycle is usually 3 to 7 days, resulting in extremely high maintenance costs; 4. High software development complexity and poor usability: Upper-layer applications need to manually determine the data volume, select the transmission mode, and call the corresponding interface. They also need to pay attention to low-level details such as GPMC timing configuration and DMA controller parameter settings, making development difficult and subsequent maintenance costs high.

[0004] The aforementioned defects mean that in mixed-load scenarios such as industrial measurement and control and data acquisition, the system cannot simultaneously achieve both real-time performance and throughput, making it difficult to fully realize the performance potential of the ARM+FPGA heterogeneous platform. Therefore, it is necessary to invent a dual-mode adaptive transmission method and system based on GPMC for ARM and FPGA to solve the above problems. Summary of the Invention

[0005] The purpose of this invention is to provide a dual-mode adaptive transmission method and system for ARM and FPGA based on GPMC, which has the advantages of being able to dynamically and adaptively switch transmission modes according to the amount of data, low overhead, plug-and-play, and easy to use. It solves the problems of fixed transmission modes, high switching costs, poor portability, and complex software development in existing ARM and FPGA transmission systems based on GPMC.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a dual-mode adaptive transmission method for ARM and FPGA based on GPMC, comprising the following steps: S1: System initialization; S2: Data transmission preparation; S3: Threshold calculation and mode selection; S4: Data transmission; S5: Frequency feedback and closed-loop control.

[0007] The GPMC-based ARM and FPGA dual-mode adaptive transmission system includes an ARM processor module, an FPGA module, a GPMC interface module, and a driver module. The ARM processor module uses a TIAM62L chip, integrating a dual-core Cortex-A53 architecture core, a 133MHz high-efficiency GPMC controller, a uDMA controller, and a PRUSS real-time unit. It also incorporates a data volume intelligent identification unit, a threshold dynamic calculation unit, a mode selection unit, and an instruction interaction unit. The FPGA module integrates a timing detection unit, a BRAM data storage unit, a dual counter unit, and a frequency measurement unit. The GPMC interface module adopts an address / data multiplexed transmission architecture, and the driver module runs on the Linux kernel layer of the ARM processor module.

[0008] Preferably, in step S1, the ARM processor starts the Linux system, and the kernel automatically loads the GPMC driver, uDMA driver, and frequency statistics driver. After the GPMC driver is loaded, it automatically sends a probe command to the FPGA module. After receiving the command, the timing probe unit of the FPGA module starts the timing capture and self-calibration process to complete the adaptive matching of GPMC timing parameters, which takes ≤10ms. After the ARM receives the timing matching completion signal from the FPGA, it sends a driver initialization command, and the FPGA internal state machine switches to the "waiting for IO command" state, while clearing the transmission counter, frequency counter, and error status register. After the frequency statistics driver starts, it initializes the ring buffer and timestamp register and enters the frequency statistics ready state.

[0009] Preferably, in step S2, the upper-layer application calls the unified API function gpmc_trans_write, passing in the pointer to the data buffer to be transmitted, the data size, and the frequency output pointer; the driver calls ioctl, and the frequency statistics driver calculates the average transmission frequency in the first 3 seconds using a sliding window algorithm and returns it to the driver; if there is no transmission record in the first 3 seconds (frequency is 0), the driver uses the default frequency value (100 packets / second) to participate in subsequent calculations.

[0010] Preferably, in step S3, the data volume intelligent identification unit collects three core parameters: the size of the data, the average transmission frequency in the first 3 seconds, and the priority passed in by the application layer; the threshold dynamic calculation unit substitutes the data into the formula S=(size / 1024×0.6)+(1 / freq_avg×0.2)+(priority / 10×0.2) to calculate the threshold S; the mode selection unit determines the final transmission mode according to the S value and the priority intervention logic, and notifies the corresponding driver.

[0011] Preferably, step S4 is divided into CPU direct access mode and UDMA mode; in step S5, the driver calls ioctl to read the actual signal frequency measured by the FPGA and the average transmission frequency of the first 3 seconds; the frequency data is written to the freq pointer passed by the application layer to complete the frequency return; the upper layer application adjusts the priority of subsequent transmissions or the data packet strategy according to the frequency data to realize the integrated closed-loop control of "high-speed transmission + frequency measurement + automatic result return".

[0012] Preferably, the data volume intelligent identification unit collects key parameters of the data to be transmitted in real time, including single frame data size, transmission frequency and task priority, and transmits the collected parameters to the threshold dynamic calculation unit; the threshold dynamic calculation unit calculates the threshold S in real time using a preset formula, the formula being: S=(data size / 1kb×0.6)+(1 / transmission frequency×0.2)+(priority / 10×0.2); the mode selection unit adopts a dual logic decision-making mechanism of "threshold determination + priority intervention".

[0013] Preferably, the instruction interaction unit supports the generation, transmission and parsing of four types of core instructions, including probe instructions, driver initialization instructions, SET_TRAN_TIMES transmission count instructions and GET_FREQ frequency feedback instructions; the timing detection unit of the FPGA module adopts the "signal edge capture + timing parameter self-calibration" mechanism.

[0014] Preferably, the dual-counter unit includes a transmission counter and a frequency counter, and the driver module includes a GPMC driver, a uDMA driver, and a frequency statistics driver, providing a unified API interface to upper-layer applications in a "character device + ioctl" manner. The unified API interface provides user-mode function encapsulation, including transmission functions, frequency query functions, and transmission count setting functions.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: Extremely optimized transmission performance: Through dual-mode adaptive switching, the transmission latency of small data volume is ≤1μs (hundred nanoseconds level), and the continuous bandwidth of large data volume is ≥80MB / s, which is close to the theoretical transmission limit of the GPMC interface (133MHz×16 bits=266MB / s). The overall performance is 3 to 5 times higher than the traditional fixed mode, while meeting the performance requirements of real-time control and big data backhaul.

[0016] 2. Low-overhead and seamless mode switching: Adopting the "same address space + trigger address write" mechanism, the switching time is ≤10ns. There is no need to reconfigure GPMC parameters, reset the system, or generate interrupts, avoiding the risk of data loss during the switching process. The upper layer application does not need to be aware of the mode switching, achieving seamless connection. 3. FPGA is plug-and-play and highly portable: The FPGA side automatically captures and adapts the GPMC timing parameters of different ARM platforms through the timing probe unit, without the need for resynthesis and reprogramming. The porting time is shortened from 3 to 7 days in the traditional solution to 5 to 10 minutes, which significantly reduces maintenance costs.

[0017] 4. Significantly reduced software development complexity: Provides a unified user-space API interface, and upper-layer applications only need to call the gpmc_trans_write() function to achieve fully adaptive transmission and frequency backhaul, without having to worry about details such as underlying transmission mode, GPMC timing configuration, and DMA parameter settings, shortening the development cycle by more than 50%.

[0018] 5. Extremely low system resource consumption: The adaptive decision logic is all placed on the ARM software side, and the FPGA only passively responds to instructions, reducing logic resource consumption by 30%~50% (taking Xilinx Artix-7 as an example, the number of logic units is reduced from about 2000 to 1000~1400), and power consumption is reduced by more than 20%, making it more suitable for resource-constrained embedded platforms. Attached Figure Description

[0019] Figure 1 This is a flowchart of the dual-mode adaptive transmission method for GPMC interface communication between ARM and FPGA according to the present invention. Figure 2 This is a structural block diagram of the overall ARM-side framework of the present invention; Figure 3 This is a schematic diagram illustrating the communication process between the ARM and FPGA sides of this invention. Detailed Implementation

[0020] The ARM and FPGA dual-mode adaptive transmission method and system based on GPMC includes the following steps: S1: System initialization; S2: Data transmission preparation; S3: Threshold calculation and mode selection; S4: Data transmission; S5: Frequency feedback and closed-loop control.

[0021] The GPMC-based dual-mode adaptive transmission system for ARM and FPGA includes an ARM processor module, an FPGA module, a GPMC interface module, and a driver module. The ARM processor module uses a TIAM62L chip, integrating a dual-core Cortex-A53 architecture core, a 133MHz high-efficiency GPMC controller, a uDMA controller, and a PRUSS real-time unit. It also incorporates a data volume intelligent identification unit, a threshold dynamic calculation unit, a mode selection unit, and an instruction interaction unit. The FPGA module integrates a timing detection unit, a BRAM data storage unit, a dual counter unit, and a frequency measurement unit. The GPMC interface module adopts an address / data multiplexed transmission architecture, and the driver module runs on the Linux kernel layer of the ARM processor module.

[0022] In step S1, the ARM processor starts the Linux system, and the kernel automatically loads the GPMC driver, uDMA driver, and frequency statistics driver. After the GPMC driver is loaded, it automatically sends a probe command to the FPGA module. After receiving the command, the timing probe unit of the FPGA module starts the timing capture and self-calibration process to complete the adaptive matching of GPMC timing parameters, which takes ≤10ms. After the ARM receives the timing matching completion signal from the FPGA, it sends a driver initialization command, and the FPGA's internal state machine switches to the "waiting for IO command" state, while clearing the transmission counter, frequency counter, and error status register. After the frequency statistics driver starts, it initializes the ring buffer and timestamp register and enters the frequency statistics ready state.

[0023] In step S2, the upper-layer application calls the unified API function gpmc_trans_write, passing in the pointer to the data buffer to be transmitted (data), the data size (size), and the frequency output pointer (freq); the driver calls ioctl(gpmc_data_gpmc_fd, GET_AVG_FREQ, 0), and the frequency statistics driver calculates the average transmission frequency in the first 3 seconds using a sliding window algorithm and returns it to the driver; if there are no transmission records in the first 3 seconds (frequency is 0), the driver uses the default frequency value (100 packets / second) for subsequent calculations.

[0024] In step S3, the data volume intelligent identification unit collects three core parameters: the size of the data (size), the average transmission frequency of the first 3 seconds (freq_avg), and the priority passed in by the application layer (priority); the threshold dynamic calculation unit substitutes the data into the formula S=(size / 1024×0.6)+(1 / freq_avg×0.2)+(priority / 10×0.2) to calculate the threshold S; Example 1: size=512 bytes, freq_avg=200 packets / second, priority=3 → S=(0.5×0.6)+(1 / 200×0.2)+(3 / 10×0.2)=0.3+0.001+0.06=0.361≤1→CPU direct access mode; Example 2: size=10KB, freq_avg=50 packets / second, priority=5→S=(10×0.6)+(1 / 50×0.2)+(5 / 10×0.2)=6+0.004+0.1=6.104>1→UDMA mode; The mode selection unit determines the final transmission mode based on the S value and priority intervention logic, and notifies the corresponding driver.

[0025] Step S4 is divided into CPU direct access mode and UDMA mode; If it is in CPU direct access mode: (1) The GPMC driver uses the virtual address mapped by ioremap to call the writel() function to write the data in data byte by byte into the FPGA's BRAM; (2) The writing process is not affected by the Linux system scheduling, and the single transmission latency is ≤1μs, supporting low latency transmission at the level of hundreds of nanoseconds; (3) After the transmission is completed, the driver calls ioctl to notify the frequency statistics driver to record the timestamp and number of transmissions for this transmission; If it is in UDMA mode: (1) The application layer writes any 32-bit data to the GPMC trigger address (0x40000008) and the uDMA driver is started instantly; (2) Configure the source address, destination address, and data length of the DMA controller in the uDMA driver, and start DMA data transfer; (3) The FPGA module’s transmission counter automatically increments by 1 after each fixed-length data packet transmission is completed, until the count value equals N (the number of transmissions specified by the SET_TRAN_TIMES instruction). (4) After the transmission is completed, the FPGA outputs a transmission completion signal, the DMA controller generates an interrupt, the driver responds to the interrupt and records the transmission information; In step S5, the driver calls ioctl(freq_counter_fd, GET_FREQ, 0) to read the actual signal frequency measured by the FPGA and the average transmission frequency of the previous 3 seconds; writes the frequency data to the freq pointer passed by the application layer to complete the frequency return; the upper layer application adjusts the priority of subsequent transmissions or the data packetization strategy according to the frequency data to realize the integrated closed-loop control of "high-speed transmission + frequency measurement + automatic result return".

[0026] The data volume intelligent identification unit collects key parameters of the data to be transmitted in real time, including the size of a single frame of data, transmission frequency, and task priority; Single frame data size: obtained by parsing the buffer length parameter passed in from the application layer, with a minimum identification granularity of 1 byte and a maximum support of 64MB; Transmission frequency: The number of valid transmissions completed within the first 3 seconds is obtained through frequency statistics, and the average transmission frequency (packets / second) is calculated with a statistical precision of 1 packet / second; Task priority: Passed by the application layer through the API interface, with a value range of 1~10 (1 is the highest priority), supports dynamic adjustment, adjustment response time ≤1μs, and transmits the collected parameters to the threshold dynamic calculation unit; The threshold dynamic calculation unit calculates the threshold S in real time based on the three collected parameters using a preset formula: S = (data size / 1kb × 0.6) + (1 / transmission frequency × 0.2) + (priority / 10 × 0.2), where: "Data size / 1024" normalizes the data size to KB units, with a weight of 0.6 reflecting the dominant influence of data size on the transmission mode; "1 / Transmission Frequency" reflects the intensity of transmission. The more frequent the transmission (the higher the frequency), the smaller this value is. The weight of 0.2 balances the impact of transmission frequency on mode selection. "Priority / 10" normalizes the priority to the range of 0 to 1, and the weight of 0.2 ensures the low latency requirement of high priority tasks; The computation time of this unit is ≤5μs, ensuring the real-time nature of transmission mode decisions; The mode selection unit adopts a dual-logic decision-making mechanism of "threshold judgment + priority intervention". The specific decision-making process is as follows: 1. Receive the S-value output by the threshold dynamic calculation unit; 2. Detect whether the application layer has passed a priority intervention command (0~2 or 8~10): (1) If the priority is 0~2, the S value is forcibly corrected to 0.8 (≤1), triggering the CPU direct access mode; (2) If the priority is 8~10, the S value is forcibly corrected to 1.2 (>1), triggering UDMA mode; 3. Without intervention, the S value is used to determine the mode: S≤1→CPU direct access mode, S>1→UDMA mode.

[0027] The instruction interaction unit supports the generation, transmission, and parsing of four types of core instructions, using a synchronous serial transmission method. The instruction transmission rate is consistent with the GPMC clock rate, including: probe command: actively sent after power-on or reset, used to trigger the timing probe process of the FPGA; Driver initialization command: Sent after probe is completed, used to initialize the FPGA's internal state and registers; SET_TRAN_TIMES transmission count command: sent before UDMA mode starts, specifying the number of packet transmissions N (1~65535); GET_FREQ frequency feedback command: sent after transmission is complete, used to read frequency data and realize closed-loop control.

[0028] The timing detection unit of the FPGA module adopts the "signal edge capture + timing parameter self-calibration" mechanism. The FPGA module uses Xilinx Artix-7 or equivalent FPGA chip, which integrates four major functional units. It has no adaptive decision logic and only passively responds to ARM instructions, minimizing the occupation of logic resources. 1. Timing Probe Unit: The core consists of a high-speed edge capture circuit and timing self-calibration logic. Its workflow is as follows: (1) After receiving the probe command from the ARM terminal, start the signal capture mode; (2) Capture the rising and falling edges of the ADVn, CSn, and WEN signals of the GPMC interface using a high-speed trigger (response time ≤ 1ns), and record the timestamp of each signal (accuracy is 1 / 8 of the GPMC clock cycle). (3) Calculate core timing parameters such as address setup time (t_adv), address hold time (t_advh), data setup time (t_ds), and data hold time (t_dh) based on timestamps; (4) Compare the calculated timing parameters with the preset fault tolerance range (±10%), and achieve timing matching by adjusting the internal delay chain (step size of 50ps) to adapt to the timing differences of GPMC on different ARM platforms.

[0029] 2. BRAM Data Storage Unit: Employs a dual-port BRAM design with a storage depth of 64KB and a data width of 16 bits, consistent with the data width of the GPMC interface, supporting simultaneous read and write operations. (1) In CPU direct access mode, the ARM processor directly addresses the BRAM through the GPMC address bus to realize random data reading and writing; (2) In UDMA mode, BRAM serves as a data buffer, receiving and temporarily storing data acquired from outside the FPGA for batch reading by the uDMA controller.

[0030] 3. Dual counter unit: including a 16-bit transfer counter and a 32-bit frequency counter. (1) Transmission counter: In UDMA mode, the counter automatically increments by 1 for each data packet of fixed length (configurable as 1KB, 2KB, or 4KB via the device tree) that is transmitted. When the count value equals N, the transmission completion signal is output and the FPGA state machine switches to the "idle state". (2) Frequency counter: During transmission, the counter increments by 1 for each valid data transmission (WEn or REn signal is valid) detected in a GPMC clock cycle. After transmission is completed, the count value is latched for use by the frequency measurement unit.

[0031] 4. Frequency Measurement Unit: The actual signal frequency is calculated based on the latch value of the frequency counter and the transmission time. The calculation logic is: actual signal frequency = frequency counter latch value / transmission time (the transmission time is derived from the GPMC clock cycle and the number of transmissions). The measurement accuracy is ≤ ±0.1%.

[0032] The driver module runs on the Linux kernel layer of the ARM processor (supports Linux 4.14 and above), and consists of three dedicated drivers. It provides a unified API interface to the upper layer using a "character device + ioctl" approach, as detailed below: 1. GPMC driver: (1) Initialization function: When loading, automatically parse the GPMC configuration parameters (clock rate, data bit width, timing parameters) in the device tree and initialize the GPMC controller register; (2) Address mapping function: The physical address of FPGABRAM (0x40000000~0x400FFFFF) is mapped to the virtual address of ARM through the ioremap function, so that the application layer can access it directly; (3) Data read / write function: Provides writel() / readl() interface functions, which internally implement continuous data writing / reading through a for loop, which is not affected by Linux system scheduling, and the single transmission delay is ≤1μs. 2. uDMA driver: (1) Configuration function: After receiving the UDMA start command from the application layer, automatically configure the source address (FPGA asynchronous FIFO physical address), destination address (ARMDDR memory virtual address), and data length (size parameter passed in from the application layer) of the DMA controller. (2) Data transfer function: After the DMA controller is started, the data batch transfer is completed autonomously through the DMA channel. The transfer process does not require CPU intervention and the continuous bandwidth is ≥80MB / s; (3) Interrupt notification function: After the data transfer is completed, the DMA controller generates an interrupt signal, the driver responds to the interrupt and notifies the application layer that the transfer is complete. 3. Frequency statistics drive: (1) Counter initialization function: Automatically initializes the transmission count counter and timestamp register when loading, and enters the waiting state; (2) Data recording function: Receive the SET_TRAN_TIMES command through the ioctl interface, record the completion timestamp and number of transmissions for each transmission, and store them in a circular buffer (depth 1024). (3) Frequency calculation function: After receiving the GET_AVG_FREQ command, the average transmission frequency in the first 3 seconds is calculated by the sliding window algorithm (average frequency = total number of transmissions in 3 seconds / 3), with a calculation accuracy of 1 packet / second.

[0033] The unified API interface provides user-space function encapsulation, including transmission functions, frequency query functions, and transmission count setting functions.

[0034] Example, Hardware Configuration ARM processor: TIAM62L (dual-core Cortex-A53, 1.4GHz clock speed, integrated 133MHz GPMC controller, uDMA controller, PRUSS real-time unit); FPGA chip: Xilinx Artix-735T (52K logic cells, 200KB BRAM). GPMC interface: 16-bit data width, address / data multiplexing mode, clock rate 133MHz; Storage media: 2GB DDR4 memory on the ARM side, and 64KB BRAM built into the FPGA side.

[0035] Drivers and System Configuration Operating system: Linux 5.10 kernel; Device tree configuration: Specify GPMC clock rate 133MHz, data bit width 16 bits, address setup time 10ns, address hold time 5ns, data setup time 10ns, and data hold time 5ns; Driver loading: The three driver modules pl353-smc.ko, dma_memcpy.ko, and freq_counter.ko are loaded using the insmod command. Example 1: Real-time control with small data volume (512 bytes of data per frame, priority 3) 1. The application layer calls gpmc_trans_write(data, 512, &freq), passing in the data buffer, data size of 512 bytes, and priority of 3; 2. The driver obtains an average transmission frequency of 200 packets / second for the first 3 seconds; 3. Threshold calculation: S = 0.3 + 0.001 + 0.06 = 0.361 ≤ 1, triggering CPU direct access mode; 4. Data transmission: The GPMC driver maps virtual addresses through ioremap and calls the writel() function to write 512 bytes of data into the FPGABRAM, with a single transmission delay of 0.8μs; 5. Frequency return: After the transmission is completed, the driver calls the GET_FREQ instruction to return the average transmission frequency of 200 packets / second for the previous 3 seconds, and the actual signal frequency of 133MHz.

[0036] Example 2: Large data volume backhaul (10KB per frame, priority 8) 1. The application layer calls gpmc_trans_write(data, 10240, &freq), passing in the data buffer, data size of 10KB, and priority of 8; 2. The driver obtains an average transmission frequency of 50 packets / second for the first 3 seconds; 3. Threshold calculation: S = 6 + 0.004 + 0.16 = 6.164 > 1, triggering UDMA mode; 4. The application layer writes 0x12345678 to the trigger address 0x40000008 to start UDMA mode; 5. Data transmission: The uDMA driver configures the DMA controller with a source address of 0x40001000 (FPGA asynchronous FIFO), a destination address of 0x80000000 (ARM DDR memory), and a data length of 10KB. The DMA controller handles data autonomously, with a transmission time of 0.128ms (10KB / 80MB / s). 6. Transmission complete: The FPGA transmission counter counts to 1 (N=1), outputs a transmission complete signal, the DMA generates an interrupt, and the driver notifies the application layer; 7. Frequency return: The average transmission frequency in the first 3 seconds is 50 packets / second, and the actual signal frequency is 133MHz.

[0037] Example 3: Priority Intervention (8KB of data per frame, priority 1) 1. Data size passed in from the application layer is 8KB, priority 1 (very high level); 2. Threshold calculation: The basic S value = 4.8 + 0.002 + 0.02 = 4.822. Since the priority is 1, the forced correction S = 0.8 ≤ 1 is triggered, thus triggering the CPU direct access mode. 3. Data transmission: 8KB of data is written using the writel() function with a transmission latency of 6.4μs, which meets the low latency requirements of high-priority tasks.

[0038] In summary, the GPMC-based dual-mode adaptive transmission method and system for ARM and FPGA solves the problems of fixed transmission modes, high switching costs, poor portability, and complex software development in existing GPMC-based ARM and FPGA transmission systems through the above steps.

Claims

1. A dual-mode adaptive transmission method for ARM and FPGA based on GPMC, characterized in that: Includes the following steps: S1: System initialization; S2: Data transmission preparation; S3: Threshold calculation and mode selection; S4: Data transmission; S5: Frequency feedback and closed-loop control; The GPMC-based dual-mode adaptive transmission system for ARM and FPGA is characterized by comprising an ARM processor module, an FPGA module, a GPMC interface module, and a driver module. The ARM processor module uses a TIAM62L chip and integrates a dual-core Cortex-A53 architecture core, a 133MHz high-efficiency GPMC controller, a uDMA controller, and a PRUSS real-time unit. It also includes a built-in intelligent data volume identification unit, a dynamic threshold calculation unit, a mode selection unit, and an instruction interaction unit. The FPGA module integrates a timing detection unit, a BRAM data storage unit, a dual counter unit, and a frequency measurement unit. The GPMC interface module adopts an address / data multiplexing transmission architecture, and the driver module runs on the Linux kernel layer of the ARM processor module.

2. The dual-mode adaptive transmission method for ARM and FPGA based on GPMC according to claim 1, characterized in that: In step S1, the ARM processor starts the Linux system, and the kernel automatically loads the GPMC driver, uDMA driver, and frequency statistics driver. After the GPMC driver is loaded, it automatically sends a probe command to the FPGA module. After receiving the command, the timing probe unit of the FPGA module starts the timing capture and self-calibration process to complete the adaptive matching of GPMC timing parameters, which takes ≤10ms. After the ARM receives the timing matching completion signal from the FPGA, it sends a driver initialization command, and the FPGA internal state machine switches to the "waiting for IO command" state, while clearing the transmission counter, frequency counter, and error status register. After the frequency statistics driver starts, it initializes the ring buffer and timestamp register and enters the frequency statistics ready state.

3. The dual-mode adaptive transmission method for ARM and FPGA based on GPMC according to claim 1, characterized in that: In step S2, the upper-layer application calls the unified API function gpmc_trans_write, passing in the pointer to the data buffer to be transmitted, the data size, and the frequency output pointer; the driver calls ioctl, and the frequency statistics driver calculates the average transmission frequency in the first 3 seconds using the sliding window algorithm and returns it to the driver; if there is no transmission record in the first 3 seconds (frequency is 0), the driver uses the default frequency value (100 packets / second) to participate in subsequent calculations.

4. The dual-mode adaptive transmission method for ARM and FPGA based on GPMC according to claim 1, characterized in that: In step S3, the data volume intelligent identification unit collects three core parameters: the size of the data, the average transmission frequency in the first 3 seconds, and the priority passed in by the application layer; the threshold dynamic calculation unit substitutes the data into the formula S=(size / 1024×0.6)+(1 / freq_avg×0.2)+(priority / 10×0.2) to calculate the threshold S; the mode selection unit determines the final transmission mode based on the S value and the priority intervention logic, and notifies the corresponding driver.

5. The dual-mode adaptive transmission method for ARM and FPGA based on GPMC according to claim 1, characterized in that: In step S4, there are two modes: CPU direct access mode and UDMA mode. In step S5, the driver calls ioctl to read the actual signal frequency measured by the FPGA and the average transmission frequency of the first 3 seconds. The frequency data is written to the freq pointer passed from the application layer to complete the frequency return. The upper layer application adjusts the priority of subsequent transmissions or the data packet strategy according to the frequency data to realize the integrated closed-loop control of "high-speed transmission + frequency measurement + automatic result return".

6. The ARM and FPGA dual-mode adaptive transmission system based on GPMC according to claim 1, characterized in that: The intelligent data volume identification unit collects key parameters of the data to be transmitted in real time, including single-frame data size, transmission frequency, and task priority, and transmits the collected parameters to the threshold dynamic calculation unit. The threshold dynamic calculation unit calculates the threshold S in real time using a preset formula, which is: S=(data size / 1kb×0.6)+(1 / transmission frequency×0.2)+(priority / 10×0.2). The mode selection unit adopts a dual-logic decision-making mechanism of "threshold determination + priority intervention".

7. The ARM and FPGA dual-mode adaptive transmission system based on GPMC according to claim 1, characterized in that: The instruction interaction unit supports the generation, transmission, and parsing of four types of core instructions, including probe instructions, driver initialization instructions, SET_TRAN_TIMES transmission count instructions, and GET_FREQ frequency feedback instructions; the timing detection unit of the FPGA module adopts a "signal edge capture + timing parameter self-calibration" mechanism.

8. The ARM and FPGA dual-mode adaptive transmission system based on GPMC according to claim 1, characterized in that: The dual-counter unit includes a transmission counter and a frequency counter. The driver module includes a GPMC driver, a uDMA driver, and a frequency statistics driver. It provides a unified API interface to upper-layer applications in a "character device + ioctl" manner. The unified API interface provides user-space function encapsulation, including transmission functions, frequency query functions, and transmission count setting functions.

Images