Real-time transmission system and control method based on Zynq AXI4 bus

Abstract

The application relates to the technical field of direct-current motor servo drive control, and provides a real-time transmission system based on a Zynq AXI4 bus and a control method thereof, wherein the system comprises a Zynq system on chip, a DDR3 public data area, an AXI4 bus interconnection architecture and a dynamic partition manager. Through implementation of the scheme, first, the multi-channel characteristics of the AXI4 bus are utilized to allocate special transmission channels for different types of data, and parallel data interaction is realized; second, the dynamic partition manager is arranged at the PL end, so that the DDR3 public data area is dynamically and real-timely divided into a plurality of partitions according to requirements, and the real-time performance of the system is improved through multi-task parallelism; third, the read-write operation of the DDR3 in each control cycle is split into a plurality of state machines through state machine precise scheduling, the state machines are combined into a state loop and are hung to the AXI4 bus, so that the key task is ensured to be completed on time, and the determinacy of the system is improved; and fourth, the size and quantity of the partitions in the DDR3 are dynamically adjusted through the dynamic partition manager, so that the storage efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of DC motor servo drive control technology, specifically to a real-time transmission system and control method based on the Zynq AXI4 bus, which is particularly suitable for the storage and interaction of real-time tasks in DC motor servo drives. Through dynamic partition management and AXI4 bus optimization, it solves the problems of real-time performance, resource conflicts and reliability under multi-task concurrency. Background Technology

[0002] Zynq is an on-chip SoC that integrates a PS (ARM) and a PL (FPGA) section. The PL section, due to its fast parallel processing and flexible pin constraints, is frequently used in high-speed motion control and as an interface for ADC and DAC chips. The PS section, on the other hand, is better suited for multimedia display and interaction with PCs. The PL and PS sections communicate via the AXI4 bus. The AXI bus is a high-performance address-mapped communication interface within Zynq, allowing for up to 256 data bursts. The PS and PL can exchange data using a shared DDR data area via the AXI4 bus. When using DC motor servo drive control, specific command signals need to be injected and a series of feedback signals obtained during system identification and performance testing of the motor. Currently, most systems load command parameters offline and store the feedback signals during motion in RAM, DDR, or other memory units for subsequent data processing and analysis. This method results in slow data interaction, complex processes, and long response times for industrial software. In existing technologies, static partitioning of DDR3 is used for data transmission. However, due to the lack of flexibility of static partitioning, the current Zynq AXI4 bus protocol has difficulty in supporting static partitioning. The problems of slow data interaction speed, process repetition, and long response time have not been solved, and bus access conflicts are also prone to occur. Summary of the Invention

[0003] To address the aforementioned shortcomings of existing DC motor servo drive storage and data interaction schemes, this invention aims to provide a real-time transmission system and its control method based on the Zynq AXI4 bus. Through hardware-level dynamic partition management and AXI4 bus optimization, the common data area DDR3 is divided into data regions, making data interaction more convenient and simplifying the data interaction process. The AXI4 bus enables multi-channel, multi-mode real-time data transmission between the PL and PS parts, meeting the complex functions and rapid response requirements of the control software.

[0004] The technical solution adopted by this invention to solve its technical problem is as follows:

[0005] In a first aspect, the present invention provides a real-time transmission system based on the Zynq AXI4 bus, applied to DC motor servo drive, comprising: a Zynq system-on-a-chip, integrating a processing system PS and a programmable logic PL; the processing system PS runs DC motor servo drive control software, and the programmable logic PL realizes real-time data processing and dynamic partition management;

[0006] The DDR3 common data area, which serves as a shared storage medium for the processing system PS and programmable logic PL, is divided into a control command area, a sensor data area, a fault log area, and a parameter configuration area, which respectively store access tasks including control commands, sensor feedback, fault information, and system parameters.

[0007] The AXI4 bus interconnect architecture connects the processing system PS and programmable logic PL via the AXI4 bus, allowing them to jointly access the DDR3 common data area. The AXI4 bus interconnect architecture supports AXI4-Lite configuration access, AXI4-Full big data burst transmission, and AXI4-Stream data transmission, providing multi-channel parallel data interaction capabilities.

[0008] The dynamic partition manager, deployed on a programmable logic unit (PL), includes a partition control state machine, an address mapping unit, a partition management engine, and a priority arbiter. It dynamically adjusts the size of DDR3 partitions through a dynamic partition allocation algorithm and dynamically adjusts the number of DDR3 partitions through a dynamic partition granularity algorithm. It adapts to the real-time multi-task access requirements of control commands, sensor data, fault logs, and system parameters, improving the utilization of address space and simplifying the data interaction process.

[0009] Furthermore, the address mapping unit uses the dual-port BRAM storage of partition metadata built into the dynamic partition manager to directly map the virtual address requests of the processing system PS and programmable logic PL to the physical partition of the DDR3 common data area.

[0010] Furthermore, the partition management engine scans the address space of the DDR3 common data area in real time. When the total size of the free partitions exceeds the threshold, it automatically merges adjacent free partitions. When the system adds new access tasks or existing access tasks have insufficient resources, it divides new partitions according to the status of free partitions.

[0011] Furthermore, the priority arbitrator assigns access priorities to partitions based on a dynamic weighted algorithm, ensuring that high-priority tasks have priority in acquiring DDR3 public data area resources; the dynamic weighted algorithm weight calculation formula is: W i (t)=0.5⋅P i +0.3⋅L i +0.2⋅S i , where P i L is the priority coefficient. iSi is the normalized value for queue length and the normalized value for historical delay.

[0012] Furthermore, the dynamic partition manager classifies access tasks for DC motor servo drive scenarios and dynamically adjusts the DDR3 partition corresponding to each level.

[0013] The access task classification is as follows: DDR3 access tasks are divided into highest priority, high priority, medium priority, and low priority; the highest, high, medium, and low priority access tasks correspond to the corresponding highest, high, medium, and low priority partitions;

[0014] The dynamic adjustment method for DC motor servo drive scenarios is as follows:

[0015] a. During steady-state operation: the highest priority partition accounts for 10%, the high priority partition accounts for 40%, the medium priority instruction partition accounts for 40%, and the low priority instruction partition accounts for 10%;

[0016] b. During rapid acceleration: The highest priority instruction is dynamically expanded to 50%, while the high-priority and medium-priority instruction partitions are reduced to 30% to ensure that control instructions are written in real time;

[0017] c. During fault braking: The low priority instruction partition is temporarily expanded to 20% to ensure that fault data is stored completely.

[0018] Furthermore, the dynamic partition manager uses a dynamic partition allocation algorithm to dynamically adjust the size of the DDR3 partition;

[0019] Dynamic partitioning algorithms include first-fit, best-fit, and worst-fit algorithms;

[0020] The first-fit algorithm searches sequentially from the starting address of memory, and allocates the first free partition that meets the size requirement;

[0021] The best-fit algorithm iterates through all free partitions and selects the free partition with the smallest size that meets the requirements for allocation.

[0022] The worst-fit algorithm iterates through all free partitions and selects the largest free partition for allocation.

[0023] Furthermore, the dynamic partition manager flexibly adapts to data transmission needs under different operating conditions by merging partitions, dynamically adjusting partition sizes, and configuring access permissions.

[0024] Partition merging specifically means that when the total size of free partitions exceeds a threshold, they are automatically merged into larger contiguous partitions for batch storage of historical data or use by large tasks.

[0025] The dynamic adjustment of partition size is specifically as follows: dynamically expand or shrink the partition according to task requirements to ensure that resources are allocated on demand and avoid idleness;

[0026] The specific adjustment of the number of partitions is as follows: more partitions are dynamically created based on the mismatch between task requirements and existing partition resources, so as to achieve elastic resource scheduling of the public DDR3 data area.

[0027] Furthermore, the dynamic partition manager breaks down the access operations to the DDR3 memory within each control cycle into multiple independent read / write state machines; each read / write state machine is responsible for executing a specific read / write operation, and the data content and address range of its internal read / write operations can be customized; multiple read / write state machines are combined according to their execution order and dependencies to form a complete state loop; the state loop is connected to the AXI4 bus; through the AXI4 bus, instructions from the control software are received and the state loop is executed to achieve multi-channel, multi-mode real-time data transmission.

[0028] Furthermore, the state loop supports dynamic configuration and real-time switching, and can flexibly adjust the data transmission mode and channel priority according to the control software instructions, thereby balancing the flexibility of data transmission with its real-time performance.

[0029] Secondly, the present invention provides a control method for a real-time transmission system based on the Zynq AXI4 bus, comprising the following steps:

[0030] S1: Initialize the DDR3 common data area and divide it into the highest priority partition, high priority partition, medium priority partition and low priority partition;

[0031] S2: The processing system PS sends data interaction requests to the programmable logic PL via the AXI4 bus, including writing control instructions, reading sensor data, and storing fault logs;

[0032] S3: The dynamic partition manager dynamically adjusts the DDR3 partition boundaries based on the request type and current load, and maps virtual addresses to physical addresses through an address translation table;

[0033] S4: The AXI4 bus is based on adjusted partitions and transmits data in a multi-channel mode to ensure the real-time performance of high-priority tasks;

[0034] S5: Real-time monitoring of DDR3 access conflicts triggers partition remapping interrupts. The dynamic partition manager adjusts partition boundaries during the DDR3 precharge interval to ensure uninterrupted data interaction.

[0035] The beneficial effects of this invention include:

[0036] Firstly, this solution utilizes the multi-channel characteristics of the AXI4 bus (AXI4-Lite, AXI4-Full, AXI4-Stream) to allocate dedicated transmission channels for different types of data, thereby achieving true parallel data interaction.

[0037] Secondly, this solution deploys a dynamic partition manager on the PL end, which can dynamically divide the DDR3 common data area into several partitions as needed in real time. This management meets the stringent requirements of DC motor servo drives for microsecond-level control cycles and improves the real-time performance of the system.

[0038] Thirdly, this solution employs state machine precision scheduling to break down the read / write operations of DDR3 in each control cycle into multiple state machines. Each state machine is responsible for a specific read / write operation and can customize the internal data content and address range for reading and writing. These state machines are combined into a state loop and connected to the AXI4 bus, ensuring the timely completion of critical tasks and improving system determinism.

[0039] Fourthly, this solution uses a dynamic partition manager to dynamically adjust the size and number of partitions in DDR3, such as sensor data area and historical data area, according to the real-time needs of the task. This on-demand allocation mechanism reduces memory fragmentation and improves storage efficiency. Attached Figure Description

[0040] Figure 1 This is a structural block diagram of the real-time transmission system provided in an embodiment of the present invention.

[0041] Figure 2 This is a flowchart of the control method for a real-time transmission system provided in an embodiment of the present invention. Detailed Implementation

[0042] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0043] As a core actuator in industrial automation, robotics, and CNC machine tools, DC motor servo drive systems place extremely high demands on real-time control, reliable data interaction, and resource utilization. Traditional DC motor servo drive storage and data interaction solutions suffer from the following pain points: 1. Static partitioning is rigid and cannot adapt to dynamic operating conditions. Existing solutions mostly use static partitioned DDR3 storage, which cannot dynamically adjust partition size according to operating conditions. For example, during rapid acceleration, the surge in control commands requires a larger partition, while during steady-state operation, the partition remains idle, resulting in low memory utilization; or the fault log area is fixed at too small, unable to store a complete snapshot of sudden fault data. 2. High software scheduling latency makes real-time performance difficult to guarantee. The processing system (PS) and programmable logic (PL) access shared DDR3 memory through software scheduling, relying on task queue management by the operating system or driver. High-priority control commands must wait for low-priority logs to be written, causing closed-loop latency jitter and failing to meet the μs-level control cycle requirements of servo drives. 3. Frequent resource conflicts lead to high data consistency risks. When PS and PL concurrently access DDR3, cross-bank / row access can easily cause precharge delays, which are further increased by software locking mechanisms. Furthermore, the lack of hardware-level conflict detection means that data write conflicts may lead to control command errors or sensor data loss. 4. Insufficient multi-mode transmission adaptation and poor flexibility. Traditional solutions only support a single transmission mode, such as AXI4-Full burst transmission, which cannot adapt to the differentiated transmission needs of various data types such as control commands, sensor data, and fault logs. Additional hardware logic adaptation is required, increasing system complexity.

[0044] To address the aforementioned shortcomings of existing DC motor servo drive storage and data interaction solutions, please refer to... Figure 1 This application aims to provide a real-time transmission system based on the Zynq AXI4 bus, comprising:

[0045] The Zynq system-on-a-chip integrates a processing system (PS) and a programmable logic (PL). The processing system (PS) runs DC motor servo drive control software, while the programmable logic (PL) implements real-time data processing and dynamic partition management.

[0046] The DDR3 common data area, which serves as a shared storage medium for the processing system PS and programmable logic PL, is divided into a control command area, a sensor data area, a fault log area, and a parameter configuration area, which respectively store access tasks including control commands, sensor feedback, fault information, and system parameters.

[0047] The AXI4 bus interconnect architecture connects the processing system PS and programmable logic PL via the AXI4 bus, allowing them to jointly access the DDR3 common data area. The AXI4 bus interconnect architecture supports AXI4-Lite configuration access, AXI4-Full big data burst transmission, and AXI4-Stream data transmission, providing multi-channel parallel data interaction capabilities.

[0048] The dynamic partition manager, deployed on a programmable logic unit (PL), includes a partition control state machine, an address mapping unit, a partition management engine, and a priority arbiter. It dynamically adjusts the size of DDR3 partitions through a dynamic partition allocation algorithm and dynamically adjusts the number of DDR3 partitions through a dynamic partition granularity algorithm. It adapts to the real-time multi-task access requirements of control commands, sensor data, fault logs, and system parameters, improving the utilization of address space and simplifying the data interaction process.

[0049] Specifically, the system integrates the collaborative design of the processing system PS and the programmable logic PL, and achieves high-performance, low-latency data interaction in DC motor servo drive through the multi-channel architecture of AXI4 bus and dynamic partition management.

[0050] The processing system (PS) runs DC motor servo drive control software, such as PID control algorithms and motion planning, and is responsible for generating control commands, processing sensor feedback data, and managing fault logs. The PS accesses the PL-side hardware acceleration module and shared memory area via the AXI4 bus.

[0051] Programmable logic (PL) implementations enable real-time data processing hardware modules, such as encoder pulse counters, current sampling buffers, and dynamic partition managers. PLs directly handle high real-time tasks, such as current loop calculations, through hardware logic, reducing the load on the power supply (PS).

[0052] The DDR3 memory is divided into multiple dedicated areas, each corresponding to a specific type of data access requirement, including: a control command area, which stores real-time control commands issued by the PS, such as target torque and speed commands; a sensor data area, which caches real-time data such as encoder position and current and voltage sampling collected by the PL; a fault log area, which records system overcurrent, overtemperature and other fault events and timestamps; and a parameter configuration area, which stores dynamically updatable system configurations such as PID coefficients and filter parameters.

[0053] This system utilizes different sub-protocols of the AXI4 protocol to adapt heterogeneous data streams for multi-channel transmission on the AXI4 bus, including: AXI4-Lite, used for low-bandwidth configuration access of the PS to the PL registers, such as updating the PID coefficients in the parameter configuration area, with transmission characteristics of single read / write and no burst transmission required; AXI4-Full, which supports burst transmission and is used for large data volume interaction, improving throughput through out-of-order completion and priority arbitration; and AXI4-Stream, used for addressless stream data transmission, where the sensor interface IP on the PL side directly pushes data without PS intervention.

[0054] The dynamic partition manager is a hardware logic module in PL, and its core submodules work together to achieve efficient memory management. The functional descriptions and implementation mechanisms of the core modules are shown in the table below:

[0055] Module Function Description Implementation mechanism Partition control state machine Decompose complex dynamic partitioning operations into manageable state sequences. This includes state definition and coding, event triggering and handling, state transition logic, and hardware / software co-design. Address mapping unit Map the virtual address of the PS to the physical address of the DDR3 partition. Using a hardware lookup table method, the mapping latency is less than 3ns, ensuring low-latency writing of configuration commands. Partition Management Engine Reclaim and merge free partitions to reduce memory fragmentation; create new partitions. During idle periods, adjacent idle blocks are detected, merged, and added to the available resource pool; new partitions are created based on the idle partition situation. Priority Arbitrator Schedule access to the AXI4 bus from multiple master devices (such as PS, DMA, sensor IP). High-priority tasks occupy the channel first to avoid blocking low-priority tasks.

[0056] Dynamic partition managers are used to manage the flexible partitioning of DDR3 common data areas. Their deployment location—whether at the PL (Programmer) or PS (System-on-Platform) end—directly impacts the system's real-time performance, flexibility, resource consumption, and applicable scenarios. Deploying at the PS end, based on the ARM Cortex-A / R series processor's software runtime environment, supports operating systems such as Linux / RTOS, offering a rich software ecosystem suitable for running complex strategies, upper-level applications, and external interactions. Deploying at the PL end, based on FPGA logic units' hardware acceleration environment, through customized circuit implementation, provides nanosecond-level real-time performance, low-latency data paths, and hardware-level parallel processing capabilities, suitable for executing high-determinism, high-real-time low-level control. Therefore, for systems with extremely high real-time requirements or sufficient hardware resources, such as DC motor servo drive control, deploying the dynamic partition manager at the PL end is the preferred choice.

[0057] To ensure unblocked address translation for high-priority tasks and provide efficient hardware support for real-time data interaction of DC motor servo drives, the address mapping unit uses a dynamic partition manager with built-in dual-port BRAM to store partition metadata, directly mapping virtual address requests from the processing system PS and programmable logic PL to the physical partition of the DDR3 common data area.

[0058] Specifically, the dynamic partition manager integrates a dual-port BRAM on the PL side as the partition metadata storage medium. This BRAM has independent read and write ports, supporting simultaneous address mapping requests from both the PS and PL, ensuring the parallelism and real-time performance of the mapping operations. The partition metadata stored in the BRAM includes: the base address of each partition; the length of each partition; and the access permissions for each partition, marked as "PS read / write", "PL read / write", or "read-only".

[0059] The virtual address requests between the processing system PS and the programmable logic PL are mapped through the following steps: Request reception: The PS or PL initiates a virtual address access request, such as the PS reading the virtual address 0x0001_2000 of the sensor data area, or the PL writing the virtual address 0x0000_3000 of the control instruction area; Metadata lookup: The address mapping unit searches for the corresponding partition's metadata in the dual-port BRAM using the partition identifier field in the virtual address; Address translation: Based on the offset between the found base address and the virtual address, the target physical address is calculated. For example, virtual address 0x0001_2000 corresponds to the sensor data area base address 0x0001_0000, offset 0x2000, and the physical address is 0x0001_0000 + 0x2000 = 0x0001_2000; Access execution: The translated physical address is sent to the DDR3 controller to complete the data read or write operation.

[0060] The dual-port BRAM design supports concurrent address mapping requests from the PS and PL, including: when the PS initiates a configuration request, it updates metadata through the BRAM's write port; when the PL initiates a data read request, it queries metadata in real time through the BRAM's read port; the two ports work independently to avoid read / write conflicts and ensure that address translation latency depends only on the BRAM's access speed; for mapping consistency and reliability, when the soft core modifies partition metadata, it first writes the new configuration to the standby BRAM, and then uses AXI4 Lite to atomically switch between the primary and standby BRAMs to ensure that the mapping relationship remains consistent during the update process. After the address mapping unit is converted, it checks whether the physical address exceeds the partition length. If it exceeds the limit, it triggers an error interrupt to ensure the security of data access.

[0061] By using dual-port BRAM to store partition metadata, the mapping from PS / PL virtual addresses to DDR3 physical addresses is directly completed by hardware logic, eliminating the multi-level jump latency of software table lookups and compressing the mapping latency to the nanosecond level. Simultaneously, the dual-port design supports concurrent access, ensuring non-blocking address translation for high-priority tasks, and providing efficient hardware support for real-time data interaction in DC motor servo drives.

[0062] To improve storage space utilization and system performance, the partition management engine scans the address space of the DDR3 common data area in real time. When the total size of the free partitions exceeds the threshold, adjacent free partitions are automatically merged. When the system adds new access tasks or existing access tasks have insufficient resources, new partitions are created based on the status of the free partitions.

[0063] Specifically, the partition management engine includes a partition merging engine and a partition partitioning engine. The partition merging engine's built-in hardware state machine continuously scans the address mapping table of the DDR3 common data area, tracking the status of each partition in real time. When the total size of consecutive free partitions exceeds a preset threshold, a merge operation is triggered. The threshold can be dynamically configured via PS-side software to adapt to different task requirements, such as the need for larger contiguous space during rapid acceleration. The partition partitioning engine, when the number of running tasks increases or the resource requirements of a single task surge, will trigger "partition more" to allocate independent resource space if existing partitions cannot meet the demand. In multi-core / multi-tasking systems, new tasks need to request dedicated or shared storage resources upon startup. If existing partitions in the common data area are already occupied, or free partitions do not meet the new task's resource requirements (such as size and access permissions), the system will partition a new partition from the free resource pool. If the data volume surges during system task execution, the originally allocated partitions may be insufficient to accommodate the data. In this case, a new partition needs to be partitioned or an existing partition expanded. If there is no adjacent free space for expansion and the existing partition cannot be expanded, a new partition needs to be partitioned and the data migrated there.

[0064] The partition merging engine identifies adjacent free partitions through the address mapping unit and records their starting address and size. The hardware logic directly modifies the address mapping table to merge multiple adjacent free partitions into a larger contiguous free block. During the merging process, the partition control state machine ensures data consistency: it only merges completely free partitions to avoid accidental operations on already occupied areas. The merged free block is added to the global available resource pool for subsequent dynamic partition allocation algorithms to use.

[0065] Address scanning, threshold comparison, and merging operations are performed in parallel by dedicated hardware circuitry within the PL. The merging process requires no intervention from the PS, reducing software overhead. The entire process, from detecting a free block to completing the merging, has low latency, ensuring that real-time tasks are not affected by memory fragmentation. The address mapping table uses double buffering, allowing it to respond normally to access requests from the PS / PL during the merging process and avoiding system blocking.

[0066] The partition merging engine prioritizes merging adjacent free partitions of the highest priority tasks to ensure that critical tasks can quickly obtain contiguous memory. It also periodically initiates global defragmentation to merge non-adjacent free blocks, reducing fragmentation accumulation after long-term operation.

[0067] In scenarios involving partition merging, such as rapid event processing, if the initial 4KB free space adjacent to the sensor data area is occupied by a log task and then released, the engine detects that the total size of the free blocks has reached 4KB and immediately merges the sensor data area and the free space to form a 12KB contiguous space. The partition manager then expands the sensor data area to 12KB to meet the high-frequency data writing requirements during rapid acceleration. In another scenario, during multi-task switching, after the free blocks between the control command area and the parameter configuration area are merged, the PS can quickly write a large number of new parameters. Through hardware-level real-time scanning, threshold-triggered merging, and low-latency operations, efficient memory fragmentation reclamation is achieved, improving storage space utilization and avoiding performance degradation caused by fragmentation. Dynamic adaptation to task demands quickly provides contiguous memory space for sudden data demands, such as rapid acceleration. System reliability is enhanced; hardware management prevents software errors, and a double-buffering mechanism ensures a non-blocking merging process. This engine works in conjunction with the dynamic partition manager to optimize the real-time performance and resource management efficiency of the Zynq AXI4 bus system.

[0068] While the partition merging engine reduces fragmentation by merging adjacent free partitions, in some scenarios, the merged "large free block" or "fragmented free area" may actually require further partitioning to achieve finer resource utilization. If there are many small fragments in the DDR3 common data area, the merging engine can merge them into a large partition, but this may result in "resource waste." If the system needs to run multiple small tasks simultaneously, the partitioning engine will split the merged large partition or the original large free area into multiple smaller partitions to accommodate the parallel needs of small tasks. After the partition merging engine continues to work, the free resource pool may become unbalanced, with "too many large partitions and too few small partitions." In this case, the partitioning engine will proactively divide some large partitions into multiple medium and small partitions, forming a resource pool with a "mixed large and small partitions," improving its adaptability to diverse tasks. The dynamic partition manager monitors partition usage statistics through built-in dynamic partition allocation and dynamic partition granularity algorithms, determines if the current proportion of large partitions is too high, cuts out multiple medium and small partitions from free large partitions, updates the PMT, and marks them as "partitions dedicated to small tasks." The number of newly created partitions is not limited to a specific number and can be n, but the total capacity of all partitions must not exceed the capacity of the DDR3 chip.

[0069] In real-time or high-reliability systems, critical tasks require dedicated partitions to avoid resource contention with other tasks. In this case, a dedicated partition is created from the public data area. Real-time tasks, such as joint control in industrial robots, are sensitive to access latency. Sharing a partition with other tasks may lead to excessive latency due to bus contention. In this situation, the system creates a dedicated partition, assigns it a high-priority bus channel, and disables cache coherency protocols to ensure low latency. In safety-critical scenarios, such as the information security module of a vehicle-to-everything (V2X) T-BOX, sensitive data needs to be physically isolated from insecure data. In this case, a "security partition" is created from the public data area, allowing access only from the secure world and prohibiting access from the ordinary world, thus achieving isolation through partitioning.

[0070] The system can proactively optimize by predicting load and pre-allocating partitions to meet future demands, or by creating more partitions to improve overall performance. Based on historical load data, the system will pre-allocate spare partitions during low-load periods to prevent task blocking due to insufficient partitions during peak times. If the system detects increased latency in accessing public data areas or an increased task blocking rate, it determines that there is "insufficient number of partitions" and proactively creates more partitions to reduce contention.

[0071] During system startup or hardware reconfiguration, multiple partitions are also created based on the initial configuration. For example, during system initialization, fixed partitions are pre-allocated for the operating system kernel, device drivers, and file system. During hardware resource reconfiguration, when the DDR3 controller detects an external device connection, it allocates a dedicated partition for data interaction.

[0072] Therefore, when the system detects that "task requirements do not match existing partition resources", or predicts future requirements through strategies, it will dynamically divide more partitions through software strategy decisions, hardware execution of partitioning and data structure updates, and finally achieve elastic resource scheduling of public data areas.

[0073] To ensure that the highest priority access task always has priority access to the DDR3 public data area resources, and to flexibly adapt to different operating conditions, the priority arbitrator assigns access priorities to partitions based on a dynamic weighted algorithm, ensuring that the highest priority task has priority access to the DDR3 public data area resources; the formula for calculating the weight of the dynamic weighted algorithm is: W i (t)=0.5⋅P i +0.3⋅L i +0.2⋅S i , where P i L is the priority coefficient. i Si is the normalized value for queue length and the normalized value for historical delay.

[0074] To ensure that the highest priority tasks can access resources first, the dynamic partition manager classifies access tasks for DC motor servo drive scenarios and dynamically adjusts the DDR3 partitions corresponding to each level.

[0075] The access task classification is as follows: DDR3 access tasks are divided into highest priority, high priority, medium priority, and low priority; high, medium, and low priority access tasks correspond to the corresponding high, medium, and low priority partitions;

[0076] The dynamic adjustment method for DC motor servo drive scenarios is as follows:

[0077] a. During steady-state operation: the highest priority partition accounts for 10%, the high priority partition accounts for 40%, the medium priority instruction partition accounts for 40%, and the low priority instruction partition accounts for 10%;

[0078] b. During rapid acceleration: The highest priority instruction is dynamically expanded to 50%, while the high-priority and medium-priority instruction partitions are reduced to 30% to ensure that control instructions are written in real time;

[0079] c. During fault braking: The low priority instruction partition is temporarily expanded to 20% to ensure that fault data is stored completely.

[0080] Specifically, the priority arbiter is deployed on the programmable logic (PL) side. It is a hardware module composed of combinational logic and sequential logic. It is responsible for receiving access requests from the processing system (PS) and the programmable logic (PL) to each partition, calculating the access priority of each partition according to the dynamic weighting algorithm, and outputting an arbitration signal to schedule the resource allocation of the DDR3 common data area.

[0081] Arbitrator based on formula W i (t)=0.5⋅P i +0.3⋅L i +0.2⋅S i Dynamically calculate the weight W of each partition i (t), where the parameters are defined and calculated as follows:

[0082] Priority coefficient P i This represents the inherent priority of a partition, which is predetermined by the importance of system functions. For example, the P partition of the control command area... i Set the value to the highest level, followed by the sensor data area, and then the fault log area.

[0083] Queue length normalization value L i This reflects the congestion level of the current partition request queue, calculated by real-time statistics of the partition request queue length and normalization to the range [0,1]. For example, if the control command area request queue length is 10, then L... i=10 / 20=0.5; If the queue length increases to 15, then L i =15 / 20=0.75, indicating that the urgency of the task has increased.

[0084] Historical Delay Normalization Value S i This characterizes the cumulative latency of historical access to a partition, calculated by recording the average latency of the partition's most recent N accesses and normalizing it to the range [0,1]. For example, if the historical average latency of the control command area is 2μs, then S... i =2 / 5=0.4; If the latency rises to 4μs due to blocking by low-priority tasks, then S i =4 / 5=0.8, which needs to be prioritized for scheduling to avoid closed-loop timeout.

[0085] The arbitrator calculates W. i (t) Arbitrate access requests for each partition. Specific steps include: request reception and parameter acquisition, and real-time acquisition of P parameters for each partition. i Current queue length, historical latency data; weight calculation, using combinational logic circuits to calculate W for each partition in parallel. i (t); Priority sorting, W is processed by a priority encoder. i (t) Sort in descending order, and the request with the highest weight gets the arbitration pass signal first; resource scheduling, the arbitration pass request is sent to the DDR3 controller, and physical address and bus bandwidth are allocated first; lower weight requests enter the waiting queue until the high priority request is completed.

[0086] The arbitrator tracks the queue length and historical latency of each partition in real time through hardware logic, and dynamically updates L. i and S i Ensure weight W i (t) reflects the current working condition. If the two partitions have the same weight, they are sorted according to the order of request arrival time to avoid arbitration deadlock. The weight calculation and arbitration decision are both completed by hardware logic. The arbitration delay depends only on the propagation time of the combinational logic, which is much lower than the context switching delay of software scheduling.

[0087] A dynamic weighted algorithm is used to quantify the inherent importance of partitions, current congestion levels, and historical latency accumulation into weight values, ensuring that high-priority tasks can still obtain DDR3 resources preferentially even under high load. For example, during rapid acceleration, the queue length of the control command area increases synchronously with historical latency, and its weight is significantly higher than that of the sensor data area. The arbitrator prioritizes scheduling control command writing, avoiding closed-loop latency exceeding limits and ensuring the real-time performance of the DC motor servo drive.

[0088] To adapt to different task requirements and improve memory utilization and real-time data interaction, the dynamic partition manager uses a dynamic partition allocation algorithm to dynamically adjust the size of DDR3 partitions. The dynamic partitioning algorithm includes the first-fit algorithm, the best-fit algorithm, and the worst-fit algorithm. The first-fit algorithm searches sequentially from the starting address of memory and allocates the first free partition that meets the size requirement. The best-fit algorithm traverses all free partitions and selects the smallest free partition that meets the requirements for allocation. The worst-fit algorithm traverses all free partitions and selects the largest free partition for allocation.

[0089] Specifically, the dynamic partition manager triggers partition adjustments by monitoring the following events: the PS or PL initiates a new task request; the partition merging engine detects that the external fragmentation rate exceeds a preset threshold; and the soft core updates task priorities by sequentially scanning free partitions starting from the DDR3 memory start address, allocating the first free partition that meets the task's size requirements to the current task. This solution is suitable for high-frequency, short-cycle real-time control tasks in DC motor servo drives. The specific execution flow is as follows: receiving a task request, traversing the free partition list starting from the memory start address, finding the first free partition with a capacity ≥ 4KB, marking the partition as "allocated," updating the partition metadata of the address mapping unit, returning the allocation result, and the task directly uses the partition. This solution does not require traversing all free partitions; the allocation latency depends only on the address scan time, meeting the real-time task's requirement for fast allocation.

[0090] The optimal fit algorithm iterates through all free partitions, selects the smallest free partition that meets the task's size requirements, and allocates it to the current task. This is suitable for medium- to long-term tasks requiring large contiguous memory. The execution flow is as follows: receiving a task request, iterating through all free partitions, recording the capacity of each partition, selecting free partitions with a capacity ≥ 16KB, choosing the smallest partition (16KB) for allocation, updating the metadata to mark the partition as "allocated," and adding the remaining free space to the free list. This algorithm retains larger free blocks, reducing the probability of allocation failures for subsequent large tasks, and significantly reducing fragmentation.

[0091] Worst-fit algorithm: Iterates through all free partitions, selects the largest free partition that meets the task's size requirements, and allocates it to the current task. This algorithm is suitable for large memory allocations during the initialization phase or for non-real-time background tasks. The execution flow is as follows: receive the task request, iterate through all free partitions, record the capacity of each partition, filter out free partitions with a capacity ≥128KB, select the largest partition for allocation, update the metadata to mark the partition as "allocated", and add the remaining free space to the free list. This algorithm allocates a sufficiently large contiguous memory at once, avoiding data fragmentation due to small partitions, and improves initialization efficiency by 40%.

[0092] The three algorithms work together through the scheduling logic of the dynamic partition manager. When a high-priority task is triggered, the first-fit algorithm is used to quickly allocate memory; when tasks such as historical data storage are triggered, the best-fit algorithm is used to reduce fragmentation; and when the system starts up or the log is compressed, the worst-fit algorithm is used to allocate large blocks of memory.

[0093] Three dynamic partitioning allocation algorithms—first-fit, best-fit, and worst-fit—cover three core scenarios in DC motor servo drives: short-cycle real-time control, medium-to-long-cycle data storage, and initialization / background tasks. The first-fit algorithm ensures rapid allocation of real-time tasks, the best-fit algorithm reduces memory fragmentation to <5%, and the worst-fit algorithm meets the need for one-time allocation of large memory blocks. The synergistic effect of these three algorithms increases DDR3 memory utilization from 60%-70% in traditional solutions to over 90%, providing crucial support for the high real-time performance and high reliability control of servo drives.

[0094] To flexibly adapt to data transmission needs under different operating conditions and improve storage efficiency and system real-time performance, the dynamic partition manager flexibly adapts to data transmission needs under different operating conditions through partition merging, dynamic adjustment of partition size and number, and access permission configuration. Specifically, partition merging automatically merges partitions into larger contiguous partitions when the total size of idle partitions exceeds a threshold, for batch storage of historical data or use by large tasks. Dynamic partition size adjustment dynamically scales up or down according to task requirements, ensuring resources are allocated on demand and avoiding idleness. Partition number adjustment dynamically divides more partitions based on mismatches between task requirements and existing partition resources, achieving elastic resource scheduling of the shared DDR3 data area. Access permission configuration supports dynamic setting of partition permissions, including setting the control command area to "PS write / PL read" and the fault log area to "PS write / PS read," ensuring data security while improving access efficiency.

[0095] Specifically, the hardware state machine in the partition merging engine continuously scans the DDR3 address mapping table to monitor the status of each partition in real time. When the total size of adjacent free partitions exceeds a preset threshold, a merge operation is automatically triggered. The threshold can be dynamically adjusted by the PS-side software to adapt to different task requirements. The merging process involves identifying free partitions with contiguous physical addresses through the address mapping unit, merging multiple free partitions into a single contiguous large partition, and incorporating the merged partition into a global free resource pool for use in large tasks or batch storage of historical data. The merging operation is executed entirely by the PL hardware logic without PS intervention; the address mapping table uses a double buffering mechanism, continuing to respond to access requests normally during the merging process to avoid system blockage. When the data volume of a partition surges, the partition manager automatically allocates additional space from the free resource pool. After the task is completed, excess space is automatically released to the free pool to avoid resource idleness. An optimal adaptation algorithm is used to select the smallest available space from the free partition chain for allocation, reducing internal fragmentation, while also supporting priority scheduling, with high-priority tasks receiving resources first.

[0096] Each partition supports independent permission configuration, with access permissions controlled through the PL-side hardware registers. These include: "PS write / PL read" – the PS generates control commands and writes them, which the PL directly reads and executes; "PL write / PS read" – the PL writes collected data in real-time, and the PS reads and processes it as needed; "PS write / PS read" – only the PS can write and read logs, preventing accidental PL operations; "PS write / PS read / PL read" – the PS updates parameters, which the PL reads and uses. When access requests are transmitted via the AXI bus, the PL-side permission arbitrator verifies the master-slave device permissions. Unauthorized access triggers an error interrupt and is reported to the PS.

[0097] The following is an example of handling a rapid acceleration event. Initially, the sensor data area, control command area, and fault log area are all occupied; the free pool has two 2KB free blocks; during a rapid acceleration event, sensor data surges, the partition manager detects the demand, automatically merges the two free blocks and expands the sensor data area to 12KB, access control ensures that the PL continuously writes data, and the PS reads and processes it at high speed; after the event ends, the sensor data area shrinks to 8KB, releasing space back to the free pool; the fault log area records event information.

[0098] Through hardware-level dynamic partition management, adjacent idle partitions are merged to improve memory utilization; the scaling mechanism avoids resource idleness and adapts to changing task requirements; permission configuration ensures data integrity and takes into account the collaboration efficiency of PS and PL. This manager significantly optimizes the real-time performance, flexibility and reliability of the Zynq AXI4 bus system and is suitable for high-requirement industrial scenarios such as DC motor servo drives.

[0099] To achieve flexible and efficient real-time data interaction, the dynamic partition manager breaks down the access operations to the DDR3 memory within each control cycle into multiple independent read / write state machines. Each read / write state machine is responsible for executing a specific read / write operation, and the data content and address range for reading and writing within it can be customized. Multiple read / write state machines are combined according to their execution order and dependencies to form a complete state loop. The state loop is then connected to the AXI4 bus. Through the AXI4 bus, instructions from the control software are received and the state loop is executed, enabling multi-channel, multi-mode real-time data transmission.

[0100] Specifically, the dynamic partition manager breaks down access operations to the DDR3 common data area within each control cycle into multiple independent read / write state machines. Each state machine is a hardware-defined finite state automaton, focused on performing a specific read / write operation. For example, state machine A is responsible for reading encoder position data from the sensor data area; state machine B is responsible for writing control commands generated by the PS into the control command area; and state machine C is responsible for asynchronously writing fault log data into the fault log area.

[0101] The dynamic partition manager combines multiple read / write state machines into a complete state loop based on task execution order and data dependencies. The state loop defines the triggering conditions and execution order between state machines. For example, in sequential execution, state machine B is triggered after state machine A completes; in parallel execution, state machine C has no dependency on state machine A and can execute in parallel; if the fault log area is detected to be full, the process jumps to state machine D. The state loop implements state transition control through hardware logic, such as state registers and conditional judgment circuits, ensuring that each state machine works collaboratively according to a preset order and dependencies.

[0102] The dynamic partition manager attaches the constructed state loop to the AXI4 bus, receives instructions from the control software through the bus interface, and executes the state loop to complete real-time data transmission. The specific process is as follows: Instruction reception: The control software sends control instructions to the dynamic partition manager through the AXI4-Lite or AXI4-Full interface; Loop activation: The dynamic partition manager parses the instructions and activates the corresponding state loop; State execution: The state machines execute in loop order. State machine A reads data from the DDR3 sensor data area, and state machine B writes the control instructions generated by the PS into the DDR3 control instruction area; Result feedback: After completing the execution, the state machines return a status signal to the control software through the AXI4 bus.

[0103] Through the collaboration of the state loop and the AXI4 bus, the system supports real-time data transmission in multiple channels and multiple modes. In this multiple channel mode, different state machines corresponding to different data types transmit in parallel through different interfaces such as AXI4-Stream and AXI4-Full. In this multiple mode mode mode, the dynamic combination of the state loop supports flexible switching of transmission modes.

[0104] By breaking down DDR3 access operations into configurable read / write state machines and combining them into state loops connected to the AXI4 bus, the data content and address range of each state machine can be customized to adapt to different task requirements. The state loops control the execution order through hardware logic, avoiding software scheduling delays and ensuring μs-level transmission of real-time tasks such as control commands and sensor data. By switching state loops, the system can dynamically adapt to different scenarios such as steady-state operation and fault handling, improving the adaptability of data transmission. This solution provides core support for the high real-time performance and highly flexible data interaction of DC motor servo drives.

[0105] To enable flexible adjustment of data transmission modes and channel priorities, thereby balancing system flexibility and real-time performance, the state loop supports dynamic configuration and real-time switching. It can flexibly adjust data transmission modes and channel priorities according to control software instructions, thus balancing data transmission flexibility and ensuring real-time performance.

[0106] Specifically, the state loop includes three types of dynamically switchable state machines, which optimize data transmission requirements in different scenarios as shown in the table below:

[0107] Work mode Core Functions Applicable Scenarios Priority strategy High-speed real-time mode Minimizes transmission latency and supports AXI4-Stream data pass-through without address decoding. Tasks with extremely high timing requirements, such as current loop control and real-time PWM output. It has the highest priority and cannot be preempted. Batch transfer mode Maximize throughput, support AXI4-Full burst transmission, and enable out-of-order completion and cache prefetching. Large-volume data interactions, such as uploading historical data and updating parameters in batches. High or medium priority, can be interrupted by high-speed real-time mode. Security monitoring mode Double redundancy check + error retransmission ensures transmission reliability >99.999%, but increases latency by about 20%. Scenarios with extremely high reliability requirements, such as fault log recording and security verification data transmission. Low priority, triggered only when the system is idle.

[0108] The PS-side control software writes configuration registers via the AXI4-Lite bus, and the state loop completes mode switching within one clock cycle. For example, during rapid acceleration, it switches to high-speed real-time mode to ensure unblocked transmission of current loop data. The state loop provides a set of dynamically writable hardware registers, allowing the PS-side software to adjust behavioral parameters in real time, set transmission timeouts, configure priority weights for each channel, and dynamically adjust burst transmission lengths. The state loop monitors system events and automatically triggers configuration updates. When the sensor data volume exceeds a threshold, it automatically switches to batch transmission mode and increases the priority of that channel. When an overcurrent fault is detected, it forcibly switches to safety monitoring mode and enables dual redundancy check to record fault data.

[0109] By employing a multi-mode state machine, dynamic register configuration, and hardware-level rapid switching, and dynamically adjusting transmission modes and priorities via software instructions, this design balances real-time performance with throughput requirements. The hardware state machine supports mode switching within 20ns, ensuring uninterrupted execution of high-real-time tasks. Error retransmission, context backup, and validity verification ensure secure and reliable data transmission. This design is suitable for industrial scenarios such as DC motor servo drives, significantly improving the system's responsiveness and efficiency under varying operating conditions.

[0110] Please refer to Figure 2 This application provides a control method for a real-time transmission system based on the Zynq AXI4 bus, applied to the aforementioned system, comprising the following steps:

[0111] S1: Initialize the DDR3 common data area and divide it into high-priority partitions, medium-priority partitions, and low-priority partitions;

[0112] S2: The system PS sends data interaction requests to the programmable logic PL via the AXI4 bus, including writing control commands, reading sensor data, and storing fault logs;

[0113] S3: The dynamic partition manager dynamically adjusts the DDR3 partition boundaries based on the request type and current load, and maps virtual addresses to physical addresses through an address translation table;

[0114] S4: The AXI4 bus is based on adjusted partitions and transmits data in a multi-channel mode to ensure the real-time performance of high-priority tasks;

[0115] S5: Real-time monitoring of DDR3 access conflicts, triggering partition remapping interrupts, and dynamic partition manager completing partition boundary adjustments during DDR3 precharge intervals to ensure uninterrupted data interaction.

[0116] The following is a specific embodiment of a real-time transmission system and its control method based on the Zynq AXI4 bus. Addressing the limitations of existing methods, a multi-channel, multi-mode real-time transmission system is designed based on the AXI4 bus. The instruction signals required for each control cycle and the generated feedback signals are dynamically mounted on the AXI4 bus according to the host computer's motion mode, enabling read / write interaction with a designated data area of ​​DDR3. This solves the following problems: The common data area of ​​DDR3 is divided into data regions, making data interaction more convenient and simplifying the data interaction process. Multi-channel, multi-mode real-time data transmission between the PL and PS parts is achieved through the AXI4 bus, satisfying the complex functions and rapid response requirements of the control software.

[0117] The specific technical solution is as follows:

[0118] 1. Divide the common data area DDR3 of PS and PL, define the read and write permissions of the PL and PS parts of each area, and dynamically allocate data addresses for data in the specified area to improve the utilization of address space.

[0119] 2. The PL section reads and writes DDR3 through the following state switching to interact with the position, speed, current, voltage command signals and feedback signals required in DC motor servo control. In each state, one read operation and one write operation are performed. Up to nine channels of 32-bit data can be read and written at a control frequency of 100kHz.

[0120] 3. The architecture provided in this embodiment can be designed with multiple read and write states, and data interaction is carried out by mounting on the AXI4 bus. The whole process is described below.

[0121] (1) The PL part receives the PS instruction to load system parameters, and downloads the system parameters loaded in DDR3 by PS into the register of the PL part through the status loop Wait_for_PS, PL_load, and PL_config. The running status loop is determined according to the sys_mode parameter given by PS.

[0122] (2) In the state loop of sys_mode = 0, PL reads instruction data of a specified length from DD3R, performs related motion, and writes the instruction signal source data of the control cycle and the acquired feedback data such as position, speed, current, and voltage into DDR3 in each control cycle.

[0123] (3) In the state loop of sys_mode = 1, PL reads instruction data of a specified length from DDR, and updates the system parameters in the R_parameter state after PS sends the instruction to update the system parameters.

[0124] (4) The Wsig_Rctrl state exists in every state loop. The current state of the motor is displayed in real time at given intervals (e.g., 1ms) for real-time monitoring.

[0125] (5) The customizable control software can load the required states onto the AXI4 bus for data interaction and combine them into multiple different state loops.

[0126] The beneficial effects of this embodiment include: (1) Dividing the address space of DDR3 into regions is beneficial to improving the utilization rate of the address space and simplifying the data interaction process. (2) The read and write operation of DDR3 in each control cycle is divided into multiple state machines. Each state machine performs one read and write operation. The data to be read and written in each state machine can be customized and multiple state machines can be combined and mounted on the AXI4 bus to form a state loop to meet the instructions of the control software, realize multi-channel and multi-mode real-time data transmission, improve the flexibility of data transmission and ensure the real-time performance of the data.

[0127] It should be noted that, for the sake of clarity in explaining the technical solution, this application classifies DDR3 into high-priority, medium-priority, and low-priority partitions according to the access tasks in a conventional DC motor servo drive scenario. However, in actual implementation of this solution, the number of partition levels may be more or less than the above classification, depending on the actual system situation, and all such partitions are within the protection scope of this solution. After the system initializes and starts running the partitions, multiple partitions may be merged or new partitions may be created depending on the system operating conditions and the concentration of access tasks. The number of newly created partitions is not limited by the system's dynamic partitioning algorithm, but the total size of all partitions, including free partitions and allocated partitions, must be less than or equal to the actual capacity of the DDR3 chip.

[0128] For those skilled in the art, various other corresponding changes and modifications can be made based on the technical solutions and concepts described above, and all such changes and modifications should fall within the protection scope of the claims of this invention.

[0129] It should be noted that the embodiments described above are only some embodiments of the present invention, and not all embodiments. The singular forms "a," "described," and "it" used in the embodiments and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise.

Claims

1. A real-time transmission system based on the Zynq AXI4 bus, applied to DC motor servo drives, characterized in that, include: The Zynq system-on-a-chip integrates a processing system (PS) and a programmable logic (PL); the processing system (PS) runs DC motor servo drive control software. Programmable logic controllers (PLs) enable real-time data processing and dynamic partition management. The DDR3 common data area, which serves as a shared storage medium for the processing system PS and programmable logic PL, is divided into a control command area, a sensor data area, a fault log area, and a parameter configuration area, which respectively store access tasks including control commands, sensor data, fault logs, and system parameters. The AXI4 bus interconnect architecture connects the processing system PS and programmable logic PL via the AXI4 bus, allowing them to jointly access the DDR3 common data area. The AXI4 bus interconnect architecture supports AXI4-Lite configuration access, AXI4-Full big data burst transmission, and AXI4-Stream data transmission, providing multi-channel parallel data interaction capabilities. The dynamic partition manager, deployed on the programmable logic (PL), includes a partition control state machine, an address mapping unit, a partition management engine, and a priority arbiter. It dynamically adjusts the size of DDR3 partitions through a dynamic partition allocation algorithm and dynamically adjusts the number of DDR3 partitions through a dynamic partition granularity algorithm. It adapts to the real-time multi-task access requirements of control commands, sensor data, fault logs, and system parameters, improves the utilization of address space, and simplifies the data interaction process. The priority arbiter assigns access priorities to partitions based on a dynamic weighted algorithm, ensuring that high-priority tasks have priority in acquiring DDR3 public data area resources; the weight calculation formula for the dynamic weighted algorithm is: W i (t)=0.5⋅P i +0.3⋅L i +0.2⋅S i , where P i L is the priority coefficient. i S is the normalized value for the queue length. i This is a historical delay normalized value; The dynamic partition manager classifies access tasks for DC motor servo drive scenarios and dynamically adjusts the DDR3 partition corresponding to each level. The access task classification is specifically as follows: DDR3 access tasks are divided into highest priority, high priority, medium priority, and low priority. The highest, high, medium, and low priority access tasks correspond to the corresponding highest, high, medium, and low priority partitions, respectively; The dynamic adjustment method corresponding to the DC motor servo drive scenario is as follows: a. During steady-state operation: the highest priority partition accounts for 10%, the high priority partition accounts for 40%, the medium priority instruction partition accounts for 40%, and the low priority instruction partition accounts for 10%; b. During rapid acceleration: The highest priority instruction is dynamically expanded to 50%, while the high-priority and medium-priority instruction partitions are reduced to 30% to ensure that control instructions are written in real time; c. During fault braking: The low-priority instruction partition is temporarily expanded to 20% to ensure complete storage of fault data; The dynamic partition manager includes a partition control state machine, which breaks down the access operations to the DDR3 memory in each control cycle into multiple independent read / write state machines. Each read / write state machine is responsible for executing a specific read / write operation, and the data content and address range of its internal read / write operations can be customized. Multiple read / write state machines are combined according to their execution order and dependencies to form a complete state loop. The state loop is connected to the AXI4 bus. Through the AXI4 bus, instructions from the control software are received and the state loop is executed to achieve multi-channel, multi-mode real-time data transmission.

2. The system according to claim 1, characterized in that, The address mapping unit uses the dual-port BRAM built into the dynamic partition manager to store partition metadata and directly maps the virtual address requests of the processing system PS and programmable logic PL to the physical partition of the DDR3 common data area.

3. The system according to claim 1, characterized in that, The partition management engine scans the address space of the DDR3 common data area in real time, and automatically merges adjacent free partitions when the total size of free partitions exceeds the threshold. When the system adds new access tasks or the existing access task resources are insufficient, new partitions are created based on the availability of free partitions.

4. In the system according to claim 1, the dynamic partition manager dynamically adjusts the size of the DDR3 partition using a dynamic partition allocation algorithm; The dynamic partition allocation algorithm includes the first-fit algorithm, the best-fit algorithm, and the worst-fit algorithm; The first-fit algorithm searches sequentially starting from the memory's starting address, and allocates the first free partition that meets the size requirement. The optimal adaptation algorithm traverses all free partitions and selects the free partition with the smallest size that meets the requirements for allocation. The worst-fit algorithm iterates through all free partitions and selects the largest free partition for allocation.

5. The system according to claim 1, wherein the dynamic partition manager flexibly adapts to data transmission requirements under different working conditions by merging partitions, dynamically adjusting partition size and number, and configuring access permissions; The partition merging specifically refers to: when the total size of free partitions exceeds a threshold, automatically merging consecutive partitions into larger partitions for batch storage of historical data or use by large tasks; The dynamic adjustment of partition size specifically refers to: dynamically expanding or shrinking the partition according to task requirements to ensure that resources are allocated on demand and to avoid idleness; The adjustment of the number of partitions specifically involves dynamically dividing more partitions based on the mismatch between task requirements and existing partition resources, thereby achieving elastic resource scheduling of the DDR3 public data area.

6. The system according to claim 1, characterized in that, The state loop supports dynamic configuration and real-time switching, and can flexibly adjust the data transmission mode and channel priority according to the control software instructions, thereby taking into account the flexibility of data transmission and ensuring its real-time performance.

7. A control method for a real-time transmission system based on the Zynq AXI4 bus, applied to the system as described in any one of claims 1-6, characterized in that, Includes the following steps: S1: Initialize the DDR3 common data area and divide it into the highest priority partition, high priority partition, medium priority partition and low priority partition; S2: The processing system PS sends data interaction requests to the programmable logic PL via the AXI4 bus, including writing control instructions, reading sensor data, and storing fault logs; S3: The dynamic partition manager dynamically adjusts the DDR3 partition boundaries and number based on the request type and current load, and maps virtual addresses to physical addresses through an address translation table; S4: The AXI4 bus is based on adjusted partitions and transmits data in multiple channels and modes to ensure the real-time performance of the highest priority and high priority tasks. S5: Real-time monitoring of DDR3 access conflicts triggers partition remapping interrupts. The dynamic partition manager adjusts partition boundaries during the DDR3 precharge interval to ensure uninterrupted data interaction.

Images