A multi-path SRIO protocol network management system and method based on FPGA and AXI4

Abstract

The application belongs to the technical field of industrial high-speed communication, and particularly relates to a multi-path SRIO protocol network management system and method based on FPGA and AXI4. The system integrates an AXI_MAC module, a PSB_Engine module, an SRIO_MAC module and a network management module in the FPGA. The method comprises: the network management module performs initialization scanning and maintains node information; a CPU processor prepares a DMA descriptor; the FPGA pulls the descriptor and data to be converted; the AXI_MAC module analyzes the data; the PSB_Engine module controls the SRIO_MAC module to encapsulate the data into SRIO protocol packets according to the conversion type; and the network management module monitors the network state in real time and performs fault maintenance. The application realizes efficient protocol conversion and built-in network management through the FPGA, reduces the dependence on special chips, supports multi-path protocol conversion channels, replaces the special protocol chip and the external management unit in a single FPGA chip, reduces the hardware cost and design complexity, and improves the flexibility of system application through the configurable multi-channel architecture.

Description

Technical Field

[0001] This invention belongs to the field of industrial high-speed communication switching technology, specifically relating to a multi-channel SRIO protocol network management system and method based on FPGA and AXI4. Background Technology

[0002] SRIO, or Serial RapidIO bus, is widely used in industrial control / communication equipment as a high-speed inter-board interconnect protocol. Its function is to serve as a high-speed protocol for communication transmission and network switching. Therefore, industrial-grade CPUs typically include a built-in SRIO controller core, allowing the CPU to directly connect to the SRIO network.

[0003] FPGA, short for Field Programmable Gate Array, is the main hardware foundation for digital system design, suitable for handling high-speed data transmission, computation, and the implementation of various algorithms. It boasts advantages such as high efficiency and flexibility. Many functions can be implemented independently, saving system costs.

[0004] DMA technology, short for Direct Memory Access, is widely used in embedded systems. It copies data from one address space to another, enabling data transfer and sharing across multiple devices.

[0005] With the continuous advancement of domestic production, domestically produced CPU processors are gradually replacing various imported CPU processors in industrial systems. Domestically produced CPU processors typically lack a hard SRIO controller core, especially in System-on-Chip (SoC) systems, which lack not only an SRIO controller core but also DMA controller functionality. Therefore, in this replacement process, the traditional approach typically uses dedicated SRIO protocol conversion chips to enable SRIO network access for the CPU processor. These chips usually only support point-to-point communication and lack built-in network management functions, requiring the CPU processor to run additional software for network maintenance. This results in high system hardware costs, increased design complexity, and slow network fault response, hindering rapid domestic substitution. Summary of the Invention

[0006] The purpose of this invention is to provide a multi-channel SRIO protocol network management system and method based on FPGA and AXI4, which can realize seamless protocol conversion from AXI4 to SRIO, and realize node scanning, chain reconstruction and self-recovery on the FPGA side.

[0007] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A multi-channel SRIO protocol network management method based on FPGA and AXI4 is proposed. The method is executed by the FPGA and implemented in conjunction with the CPU processor. The FPGA internally includes an AXI_MAC module, a PSB_Engine module, an SRIO_MAC module, and a network management module. The method includes: Step 1: Network management initialization. After power-on, the network management module generates network management frames and writes them into the network management frame queue. After the system starts up, it multicasts network management frames to the SRIO network nodes and writes the node return information into the local RAM of the network management module. The CPU processor reads the local RAM of the network management module and establishes a node information table. Step 2, Descriptor preparation: The CPU processor determines the target device based on the node information table, stores the data to be converted in the storage space and records the starting address of the storage space and the size of the data to be converted, constructs a DMA descriptor containing the target device identifier, the starting address of the storage space, the size of the data to be converted and the conversion type, and writes it into the descriptor list; Step 3, Descriptor Retrieval: The CPU processor writes the starting address and size of the descriptor list to the descriptor pointer and notifies the FPGA that there is a task to be converted. The FPGA retrieves the starting address and size of the descriptor list from the descriptor pointer. The FPGA sends a read request to the AXI_MAC module. The AXI_MAC module generates a read request based on the starting address and size of the descriptor list, encapsulates it into an AXI4 read request message, and sends it to the CPU processor via the AXI4 bus. The CPU processor returns the descriptor data to the FPGA. Step 4, Data Retrieval and Parsing: The PSB_Engine module of the FPGA parses the descriptor data to obtain the storage location and size of the data to be converted, and sends a read request for the data to be converted to the AXI_MAC module. The AXI_MAC module encapsulates the read request into a read request message and sends it to the CPU processor via the AXI4 bus. The CPU processor returns the data to be converted to the FPGA. The FPGA forwards the data to be converted to the AXI_MAC module. After completing the AXI4 protocol parsing, the AXI_MAC module sends the parsing result to the PSB_Engine module. Step 5, Encapsulation and Sending and Status Writing: The PSB_Engine module outputs the data to be encapsulated to the SRIO_MAC module according to the conversion type in the DMA descriptor. The SRIO_MAC module encapsulates the data to be encapsulated into the corresponding SRIO protocol type and sends it to the target device via the SRIO bus. The PSB_Engine module writes the conversion status into the running status field of the DMA descriptor for the CPU processor to query. Step 6, Fault Maintenance: The network management module periodically sends status query frames to each node in the SRIO network. If no valid response is received from the target node within the preset timeout period, the node is determined to be faulty. The network management module generates a node fault maintenance frame, updates the local network topology information to logically delete the faulty node, and writes the fault record into the local RAM of the network management module.

[0008] Furthermore, the network management module manages network management frames through a network management frame queue. During the power-on and scanning phases, the network management module completes a full network node scan of the SRIO network through network management frames and writes the scan response information into the local RAM of the network management module. The CPU processor establishes a node information table based on the local RAM of the network management module.

[0009] Furthermore, the network management module manages the reconstruction of chain frames through the reconstruction chain queue, and realizes single-node power-on, single-node power-off and network recovery through the reconstruction of chain frames.

[0010] Specifically, the network management module manages the reconstruction of chain frames through the reconstruction chain queue (frame format: based on SRIOMessage type, the first 4 bytes of the payload are command words: 0x04 = single node power-on request, 0x05 = single node power-off request, 0x06 = network recovery request, and the following bytes are the node ID). Single node power-on: After a new node powers on, it actively sends a registration frame. Upon receiving the frame, the network management module replies with a reconstructed chain frame (command word 0x04), updates the network topology, and synchronizes it to the CPU. Single node power-off: Before the node is powered off, it sends a deregistration frame, the network management module sends an acknowledgment frame (command word 0x05), and the node is logically deleted; Network recovery: After the faulty node recovers, it sends a recovery frame. The network management module sends a reconnection frame (command word 0x06), and the node rejoins the network.

[0011] Furthermore, the PSB_Engine module supports multiple independent protocol conversion channels; the system assigns a unique channel ID (0~7) to each protocol conversion channel, and configures an independent descriptor list for each channel in the CPU processor memory. At the same time, an independent descriptor pointer register is mapped for each channel inside the FPGA (the address offset is channel ID × 8 bytes, and the base address is preset by the FPGA register configuration space); the network management module occupies the hardware resources of channel ID=0 as the network management endpoint, and its descriptor pointer register address is the base address + 0 × 8 bytes, and sends and receives network management frames on this channel in a time-division multiplexing manner.

[0012] Furthermore, the read request message is a memory read request message.

[0013] Furthermore, the AXI4 read request length satisfies the constraint of not crossing the 4K byte boundary. The AXI_MAC module breaks down the read request address to ensure that the length of a single read request does not cross the 4K byte boundary and the length of a single read request does not exceed 4K bytes.

[0014] Furthermore, the parsing and processing of the AXI_MAC module includes completing data reordering and data reassembly.

[0015] Specifically, the parsing and processing of the AXI_MAC module includes data reordering and reorganization: Sorting logic: The AXI4 read request message carries the fragment sequence number (0~N-1), and the AXI_MAC module caches the fragment data in ascending order of the sequence number; Reassembly logic: After receiving all fragments (with consecutive sequence numbers and no missing fragments), they are concatenated into a continuous data stream according to their sequence numbers; if a fragment is missing (timeout due to failure to receive), the PSB_Engine module is triggered to return a "data transmission error" status.

[0016] Furthermore, the conversion types in the DMA descriptor include DIO, Message, and doorbell. The PSB_Engine module outputs encapsulation control information to the SRIO_MAC module based on the conversion type.

[0017] Furthermore, the conversion status includes conversion complete, conversion timeout, and target device offline. The PSB_Engine module writes the conversion status to the DMA descriptor's running status field.

[0018] In addition, the present invention also discloses a multi-channel SRIO protocol network management system based on FPGA and AXI4, including FPGA, AXI4 bus interface and SRIO bus interface, wherein the FPGA integrates an AXI_MAC module, a PSB_Engine module, an SRIO_MAC module and a network management module. The AXI4 bus interface is used to connect the CPU processor to the AXI_MAC module. The AXI_MAC module is used to complete the AXI4 protocol parsing and initiate memory read request messages. The PSB_Engine module is located between the AXI_MAC module and the SRIO_MAC module. The PSB_Engine module is used to complete data interaction and write the conversion status to the DMA descriptor running status field. The SRIO_MAC module connects to the SRIO bus interface. The SRIO_MAC module is used to encapsulate service data into SRIO protocol type and send it to the target device. The network management module is used to generate network management frames and write them into the network management frame queue, multicast network management frames and write the return packet information into the local RAM of the network management module, periodically query node status, and generate fault maintenance frames to update the network topology in fault scenarios. The system is used to execute a multi-channel SRIO protocol network management method based on FPGA and AXI4 as described above.

[0019] Furthermore, the scheduling method of the PSB_Engine module also includes a dynamic priority scheduling step: S10a: The network management module periodically queries and obtains the real-time health status of each SRIO node, and writes it into the double-buffered status register group inside the FPGA. The health status includes three states: normal, delayed, and fault. S10b: For each ready protocol conversion channel, the PSB_Engine module calculates a dynamic priority score through hardware logic based on the preset static priority field in the DMA descriptor of the channel, the real-time health status of the target node read from the double-buffered status register group, and the service type of the data to be converted in the channel. ; S10c: The PSB_Engine module compares the dynamic priority scores of all ready channels. The channel with the highest score is selected for protocol conversion; at the same time, when the network management module issues an emergency scheduling request signal, the network management endpoint channel is unconditionally prioritized for scheduling.

[0020] Among them, the dynamic priority score Calculated using the following formula: ; in, It has a 3-bit static priority, with a value range of 0-7; The node health weight is 4 bits wide and is obtained by looking up a table based on the health status. This represents the maximum weight. The Doorbell type uses a 2-digit wide base score determined based on the business type. Message type DIO type ; This indicates the floor function.

[0021] Compared with the prior art, the present invention has the following beneficial effects: This invention integrates four core functional modules—AXI_MAC, PSB_Engine, SRIO_MAC, and network management—within a single FPGA chip. By integrating protocol conversion and network management core functions through FPGA hardware logic, it replaces the dedicated SRIO protocol chip and external logic or software components required for network management in traditional solutions. This reduces the number of board-level chips and interconnect design, significantly lowering the material cost and overall development cost of the system. It provides a low-cost, high-performance SRIO network access and management solution for domestic CPU processors lacking a hard SRIO controller core.

[0022] This invention provides built-in, automated full-lifecycle network management, significantly improving system reliability. The network management module is integrated into the FPGA, realizing fully automated hardware management from network initialization, automatic node discovery and information table establishment, periodic node status queries, to fault detection, node isolation, and network topology self-recovery. By offloading complex network maintenance functions from the CPU processor's software burden and having them executed in parallel by the FPGA hardware, the load on the CPU is greatly reduced. Furthermore, through the parallel and deterministic processing mechanism of the FPGA's internal hardware state machine, the latency for network node status queries and fault detection is significantly shortened compared to software polling, thereby comprehensively enhancing the robustness, stability, and long-term reliability of the entire SRIO network.

[0023] This invention constructs a highly efficient and flexible multi-task parallel processing architecture, improving system throughput and resource utilization: The PSB_Engine module supports up to eight independent protocol conversion channels, enabling parallel processing of transmission tasks from different services or different AXI4 master devices, greatly improving the overall data throughput and multi-task concurrent processing capability of the system. Simultaneously, the innovative design allows network management functions to flexibly reuse any one of the service channels as its network management endpoint, achieving time-division multiplexing of service data conversion and network control signaling on the same AXI_MAC and SRIO_MAC physical interfaces. The network management endpoint channel can be used for service data transmission when there are no management tasks, improving hardware interface utilization and significantly enhancing the utilization of FPGA internal logic resources and the flexibility of system design.

[0024] This invention ensures the efficiency and data integrity of the protocol conversion process, guaranteeing system compatibility: The AXI_MAC module intelligently processes AXI4 bus read requests, automatically performs address splitting to avoid crossing 4KB boundaries, and performs data reordering and reassembly, ensuring the efficiency and integrity of large-capacity data in fragmented transmission. The PSB_Engine module works closely with the SRIO_MAC module, strictly adhering to the SRIO protocol specifications for data encapsulation, slicing, and framing based on the conversion type specified in the DMA descriptor, ensuring that all generated SRIO packets fully comply with the standard protocol, achieving seamless and reliable interconnection with existing SRIO network devices.

[0025] This invention achieves substantial breakthroughs in several key dimensions, including cost reduction, design simplification, improved network management automation and system reliability, and enhanced processing power and flexibility, by innovatively integrating core functions of protocol conversion and network management on an FPGA platform. It has significant engineering application value and market prospects. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained from these drawings without creative effort.

[0027] Figure 1 This is a diagram of the conversion system of the present invention.

[0028] Figure 2 This is a flowchart of the conversion system of the present invention.

[0029] Figure 3 This is a flowchart of the network management process of the present invention. Detailed Implementation

[0030] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the spirit or scope of the embodiments of the invention. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0031] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0032] Example 1: This example describes the internal module structure and data path of the system. The FPGA integrates an AXI_MAC module, a PSB_Engine module, an SRIO_MAC module, and a network management module. The CPU interacts with the AXI_MAC module via the AXI4 bus interface, and the SRIO_MAC module connects to the SRIO network via the SRIO bus interface. The PSB_Engine module is located between the AXI_MAC and SRIO_MAC modules, used for data interaction between them and for writing the transition status to the DMA descriptor's running status field. The network management module is used for node scanning, chain reconstruction, and self-recovery, and writes node return packet information and fault information to the network management module's local RAM.

[0033] The PSB_Engine module supports multiple protocol conversion channels, with a maximum of 8 channels. These multiple channels are used to handle the protocol conversion of multiple tasks in parallel. The network management module can select any one of these channels as the network management endpoint, thus enabling both service data conversion and network management data transmission and reception within the same hardware architecture.

[0034] Specifically, the PSB_Engine module internally includes a multi-channel scheduler and multiple sets of task context registers corresponding to the number of channels. Each set of context registers is used to store key fields of the DMA descriptor (such as target address, data length, and conversion type) and processing status for each conversion task. The multi-channel scheduler uses a round-robin or priority arbitration algorithm to select the channel currently to be processed and load its context into the core protocol conversion pipeline for execution. The network management module is configured to occupy the context of one of the channels as a network management endpoint.

[0035] Furthermore, the protocol conversion process revolves around the descriptor list, descriptor pointers, memory read request messages, and the data to be converted. The descriptor list is stored in the CPU's memory space, and the descriptor pointer indicates the starting address and size of the descriptor list.

[0036] Step C1: Node Information Table Establishment. After power-on, the network management module assembles network management frames and writes them to the network management frame queue. After the system completes startup, the network management module multicasts network management frames to the SRIO network nodes and writes the node return information to the network management module's local RAM. The CPU processor accesses the network management module's local RAM mapped to its address space via the AXI4 bus, reads the node return information, and establishes the node information table. The node information table describes the current set of nodes and their status in the network, providing basic data for subsequent task sending and fault handling.

[0037] As an example, the network management frame is a custom message based on the SRIOMessage type. The first four bytes of its payload are command words, defining the frame type (e.g., 0x01 for node discovery request, 0x02 for status query, and 0x03 for response); subsequent bytes are data fields, which may contain information such as node ID, port status, and timestamp. The network management module parses and processes the received frame based on the command word fields.

[0038] Step C2, Descriptor Preparation. When initiating a transmission, the CPU processor determines the target SRIO device for this transmission based on the node information table, stores the data to be converted in the storage space, and records the starting address of the storage space and the size of the data to be converted. The CPU processor constructs a DMA descriptor and writes the DMA descriptor into the descriptor list. The data structure of the DMA descriptor includes: a target device ID field, a source data starting address field, a data length field, a conversion type field, and a status write-back address field. The target device ID field indicates the destination of the message sent by the SRIO_MAC module; the source data starting address and data length fields enable the FPGA to locate the data to be converted; the conversion type field indicates the SRIO protocol encapsulation type selected by the PSB_Engine module; the status write-back address field is used by the PSB_Engine module to write back the conversion status; and the running status field is located in the CPU processor's memory and is used to store the conversion status for the CPU processor to query.

[0039] Step C3, Descriptor Retrieval. The CPU writes the starting address and size of the descriptor list to the descriptor pointer and notifies the FPGA of a task to be converted. The FPGA retrieves the starting address and size of the descriptor list from the descriptor pointer and sends a read request to the AXI_MAC module. Upon receiving the read request, the AXI_MAC module encapsulates the starting address and size of the descriptor list into a memory read request message and sends it to the CPU via the AXI4 bus. The CPU retrieves the descriptor data of the corresponding length based on the memory read request message and returns the descriptor data to the FPGA via the AXI4 bus.

[0040] Step C4: Retrieving the data to be converted. The FPGA parses the descriptor data to obtain the storage location and size of the data to be converted, and sends a read request for the data to be converted to the AXI_MAC module again. The AXI_MAC module encapsulates the read request for the data to be converted into a memory read request message and sends it to the CPU processor via the AXI4 bus. The CPU processor retrieves the data to be converted from the storage space and sends it to the FPGA. The FPGA forwards the received data to be converted to the AXI_MAC module, which performs AXI4 protocol parsing on the data to be converted and outputs the parsing result to the PSB_Engine module after completion.

[0041] Step C5: 4K boundary splitting and multiple fetches. The amount of data to be converted at one time may be large. To balance resources and efficiency and fully utilize the AXI4 bus, this embodiment sets the length of a single read request to no more than 4K bytes, and follows the AXI4 protocol's constraint that the length of the read request does not cross the 4K byte boundary. The AXI_MAC module splits the read request address so that the length of a single read request does not cross the 4K byte boundary. For example, when the amount of data to be converted is 1M bytes, the PSB_Engine module for this task will initiate 256 read requests to the AXI_MAC module, each request being 4K bytes long, to complete the fetching of 1M bytes of data to be converted.

[0042] Step C6: Data Reordering and Reassembly. When the data to be converted is retrieved through multiple read requests, there may be scenarios where data is returned in fragments and the order of these fragments changes. The AXI_MAC module performs data reordering and reassembly during the parsing process: data reordering is used to arrange the fragmented data in logical order, and data reassembly is used to merge the fragmented data into a continuous data stream to be encapsulated, ensuring that the data received by the subsequent PSB_Engine module meets the continuity and consistency requirements for encapsulation.

[0043] Step C7: Conversion Type Selection and SRIO Encapsulation. The PSB_Engine module receives the parsing result from the AXI_MAC module, retrieves the conversion type from the DMA descriptor, and outputs encapsulation control information to the SRIO_MAC module. Conversion types include DIO, Message, and Doorbell. The SRIO_MAC module encapsulates the data to be encapsulated into the corresponding SRIO protocol type according to the conversion type and sends it to the target device via the SRIO bus.

[0044] Step C8: SRIO Payload Length and Slicing Rules. The SRIO protocol imposes constraints on the payload length for different service types. For Nwrite, NwriteR, and Nread type messages, the maximum payload length cannot exceed 256 bytes. When the payload length is greater than or equal to 8 bytes, only 8 bytes, 16 bytes, 32 bytes, 64 bytes, 128 bytes, and 256 bytes are supported. For Swrite type messages, only payload lengths that are multiples of 8 and do not exceed 256 bytes are supported. For Message type messages, except for the last slice, the payload lengths of the preceding slices are equal and powers of 2, and do not exceed 256 bytes. The payload length of the last slice is a multiple of 8 and does not exceed 256 bytes. The SRIO_MAC module slices and frames the data to be encapsulated according to the above rules during the encapsulation process to ensure that the generated SRIO messages meet the protocol constraints.

[0045] Step C9, Write the transition status. After the transition is complete, the PSB_Engine module generates a write request containing the address and transition status data based on the status write-back address field carried in the DMA descriptor. The AXI_MAC module encapsulates this write request into an AXI4 write transaction message and writes it to the corresponding location in the CPU processor's memory via the AXI4 bus. The transition status includes transition complete, transition timeout, and target device offline. The CPU processor determines the task execution result by reading this status field.

[0046] Furthermore, the PSB_Engine module supports up to 8-channel protocol conversion. The CPU processor can write DMA descriptors corresponding to different service tasks into different descriptor lists. The FPGA pulls different descriptor lists according to the descriptor pointers and performs data fetching, parsing, encapsulation, and transmission in the corresponding protocol conversion channel.

[0047] The network management module selects one of the protocol conversion channels as the network management endpoint. The network management endpoint is used to transmit and receive network management frames, reconstruction chain frames, and fault maintenance frames. The service data conversion channel and the network management endpoint channel share the basic capabilities of the AXI_MAC and SRIO_MAC modules. The PSB_Engine module is responsible for data interaction and encapsulating control information output at the channel level, thereby enabling parallel processing of multiple tasks.

[0048] Furthermore, the network management module manages network management frames through a network management frame queue and reconstruction chain frames through a reconstruction chain queue.

[0049] Step D1: Power-on and Scan. After power-on, the network management module assembles network management frames and writes them into the network management frame queue. After the system completes startup, the network management module multicasts network management frames to each SRIO node. The network management module writes node return information into its local RAM. The CPU processor accesses the network management module's local RAM mapped to its address space via the AXI4 bus, reads the node return information, and establishes a node information table.

[0050] Step D2, Periodic Status Query. The network management module periodically queries the status of each CPU processor node on the SRIO network. During the periodic query, the network management module generates a network management frame based on the node set recorded in the node information table and executes the query according to the node set. The query response information is written to the local RAM of the network management module and used to update the node status.

[0051] Step D3, Fault Handling. When the network management module detects a node that has timed out and is unresponsive during periodic queries, it determines that the node is faulty. The network management module generates a fault maintenance frame, updates the local network topology information to logically delete the faulty node, and writes the fault record to the network management module's local RAM. After the CPU processor reads the fault record from the network management module's local RAM, it synchronously updates the node information table and the network topology view.

[0052] Step D4, Rebuild the Chain. The network management module manages rebuild chain frames through the rebuild chain queue, and uses rebuild chain frames to realize single-node power-on, single-node power-off, and network recovery. When the node recovery conditions are met, the network management module sends a rebuild chain frame to the corresponding node. After the node successfully responds, it rejoins the network topology. The network management module writes the recovery information into its local RAM and makes it available for the CPU processor to read and update.

[0053] As an option, in practical use, the PSB_Engine module supports multiple independent protocol conversion channels, with the number of channels being N, where N is an integer greater than 1, such as 8 channels. To achieve multi-channel independent parallel processing, the system configures an independent descriptor list for each channel in the CPU processor memory, and simultaneously configures an independent descriptor pointer register for each channel inside the FPGA. The descriptor pointer register for each channel is used to store the starting address and size of the descriptor list corresponding to that channel in the CPU processor memory. The PSB_Engine module internally includes: a multi-channel scheduler, multiple sets of context registers corresponding to the number of channels N, and a core protocol conversion pipeline. Each set of context registers is uniquely bound to one channel and is used to cache the key fields of the DMA descriptor currently being processed by that channel. These key fields include the target device ID, source data address, data length, conversion type, and processing status. The multi-channel scheduler, based on a polling or fixed-priority arbitration mechanism, selects a current channel from all channels with pending tasks. It then loads the contents of the context registers bound to that current channel into the core protocol conversion pipeline to execute the current cycle's operations. The core protocol conversion pipeline is responsible for initiating AXI4 read requests for descriptors and data for the current channel, performing protocol conversion, and controlling the SRIO_MAC module for encapsulation and transmission.

[0054] The network management module permanently occupies the hardware resources of one channel as its network management endpoint. For example, this network management endpoint permanently occupies channel 0. The descriptor list and descriptor pointer register corresponding to channel 0 are configured specifically for network management tasks. The network management module triggers and utilizes the protocol conversion pipeline of the PSB_Engine module to complete the encapsulation and transmission of network management frames by writing specific network management DMA descriptors into the descriptor list corresponding to channel 0 and setting the descriptor pointer register of channel 0. It also receives and parses network response frames through the same pipeline. When no network management task needs to be executed, channel 0 can be reconfigured to carry ordinary service data conversion tasks.

[0055] Example 2: See Figures 1-3 This embodiment discloses a multi-channel SRIO protocol network management system and method based on FPGA and AXI4. This method achieves seamless conversion from AXI4 protocol to SRIO protocol on the FPGA and can manage the entire SRIO network. The method consists of four modules implemented on the FPGA: an AXI_MAC module, a PSB_Engine module, an SRIO_MAC module, and a network management module. Various processors (CPUs) are connected to the AXI_MAC module via the AXI4 bus, responsible for AXI4 protocol parsing; the PSB_Engine is located between AXI_MAC and SRIO_MAC, responsible for data interaction between the two; the SRIO_MAC is used to connect the SRIO bus, connecting the system to the SRIO network; the network management module manages the SRIO network, such as node scanning, chain reconstruction, and self-recovery.

[0056] The system and method in this invention achieve protocol conversion from AXI4 to SRIO, enabling various processors to access the SRIO network via the AXI4 bus. It also enables FPGA to manage the network, allowing each node in the network to manage the network without the need for additional external hardware, thus improving system flexibility and saving system costs.

[0057] Furthermore, the following conversion steps are included: Step S1: The CPU processor retrieves the node information stored in the local RAM of the network management module and establishes an information table for each node in the current network. Step S2: When initiating a transfer, the CPU processor stores the data to be converted in the storage space, records the starting address and size of the storage space, then constructs a DMA descriptor, and stores the constructed DMA descriptor in the descriptor list in the CPU processor's memory. In step S3, the CPU processor sets the starting address and size of the descriptor list storing DMA descriptors to the descriptor pointer and notifies the FPGA that there is new data to be converted. The FPGA obtains the starting address and size of the descriptor list from the descriptor pointer. The FPGA's PSB_Engine module sends a descriptor read request to the AXI_MAC module. After receiving the read request, the AXI_MAC module encapsulates the retrieved starting address and size of the descriptor list into a read request message and sends it to the CPU processor through the AXI4 bus. Step S4: After receiving the read request message, the CPU processor retrieves the descriptor data of the corresponding length according to the starting address and size of the descriptor list encapsulated in the read request message; and sends it to the FPGA through the AXI4 bus. Step S5, Data Retrieval. The FPGA parses the received descriptor data to obtain the starting address and data length of the data to be converted in the CPU processor's memory. The FPGA sends a read request for this starting address and data length to the AXI_MAC module. The AXI_MAC module encapsulates this read request into an AXI4 read transaction message and sends it to the CPU processor via the AXI4 bus; In step S6, after receiving the read request message, the CPU processor retrieves the data to be converted from memory and sends it to the FPGA. The FPGA forwards the received data to be converted to AXI_MAC. AXI_MAC receives the returned data to be converted, parses it, and then sends the parsed data to the PSB_Engine module. Step S7, Data Reassembly and Buffering. The AXI_MAC module reorders and reassembles the data returned by multiple read requests that may arrive out of order, forming a continuous data stream to be converted, which is then sent to the PSB_Engine module.

[0058] In step S8, after receiving the data to be converted, the PSB_Engine module retrieves the conversion type from the descriptor and sends it to SRIO_MAC. After receiving the data to be converted from PSB_Engine, SRIO_MAC encapsulates the data into the corresponding SRIO protocol type and sends it to the target device.

[0059] Specifically, the SRIO protocol specifies the transmission specifications for its service types. For Nwrite, NwriteR, and Nread type messages, the maximum payload length cannot exceed 256 bytes. Messages with a payload length greater than or equal to 8 bytes only support lengths of 8, 16, 32, 64, 128, and 256 bytes. For messages with a payload length less than 8 bytes, the combination of the lower three bits of the starting address and the length must meet the protocol requirements. For the Swrite type, only messages with a payload length that is an integer multiple of 8 are supported, and their payload length cannot exceed 256 bytes. For the Message type, except for the last slice, the payload lengths of the preceding slices must be equal and be powers of 2, and their payload length cannot exceed 256 bytes. The payload length of the last slice does not have to be a power of 2, but it must be an integer multiple of 8, and its payload length cannot exceed 256 bytes.

[0060] The network management module includes the following steps: Step S1: After power-on, the network management module begins to assemble network management frames and store them in the network management frame queue. After the system completes startup, it begins to multicast network management frames to each SRIO node and stores the return information in the local RAM. In step S2, the network management module periodically queries the status of each node on the SRIO network. When a node is found to be continuously unresponsive, the network management module marks it as faulty.

[0061] Step S3: When a faulty node times out and fails to respond, the network management module begins to assemble a fault maintenance frame, removes the node from the network topology, records the fault, and stores it in the local RAM of the network management module.

[0062] Example 3: This embodiment is a specific enhanced implementation of the PSB_Engine module scheduling function described in Embodiment 1. This enhanced function can be optionally enabled through the configuration register and is compatible with the original polling or fixed priority scheduling mode.

[0063] The specific plan is as follows: 3.1 Enhanced System Hardware Architecture: To support dynamic priority scheduling, the network management module and PSB_Engine module have been enhanced based on the hardware architecture described in Example 1, and a dedicated hardware logic unit for status information acquisition, storage and calculation has been added.

[0064] 3.1.1 Node Status Information Acquisition and Storage Unit: Within the network management module, a node status acquisition hardware unit has been added. This unit works in conjunction with the network management frame transmission and reception logic. When the network management module sends a status query frame and receives a node response: The raw latency value is obtained by precisely measuring the number of clock cycles from the time the query frame is sent to the time the response frame is received using a 32-bit hardware counter. .

[0065] Will It is compared with a preset threshold register, which includes , , These correspond to the boundary values ​​for the health statuses of "Normal," "Latency," and "Fault," respectively. The thresholds can be configured by the CPU processor based on the actual network environment; the default value is: Period (corresponding to 5µs@200MHz), Period (25µs) Period (100µs).

[0066] Based on the comparison results, a 2-bit node health status code is generated: like If so, the code is 00, which means "normal"; like If so, the code is 01, indicating "slight delay"; like If so, the code is 10, indicating "severe delay"; like If the response times out, it is coded as 11, indicating "fault".

[0067] The generated health status code and its corresponding 6-bit timestamp are written to the shadow register area of ​​the double-buffered status register group. The double-buffered status register group is implemented using two dual-port BlockRAMs with a depth of 16 (supporting 16 SRIO nodes), each unit being 32 bits. Its structure ensures that when the network management module writes a new status to the "shadow area," the PSB_Engine module can simultaneously read the old status from the "active area," without blocking each other. During clock intervals when the PSB_Engine module is not performing read operations, the control logic atomically switches the contents of the shadow area to the active area.

[0068] 3.1.2 PSB_Engine Module Dynamic Scheduling Enhancement Unit: The PSB_Engine module enhances the existing scheduler by adding the following hardware units: Dynamic priority calculation array: Instantiate an independent calculation unit for each protocol conversion channel (8 channels in total). Each calculation unit contains: Status information reading interface: Based on the target node ID cached in the context register of this channel, read the corresponding health status code from the active area of ​​the double-buffered status register group.

[0069] Health Weight Lookup Table (LUT): A 16×4-bit ROM that maps four possible 2-bit health status codes to 4-bit weight values. The default mapping is: 00 (Normal) → 1111 (15, i.e., 1.0), 01 (Slight Delay) → 1100 (12, i.e., 0.75), 10 (Severe Delay) → 1000 (8, i.e., 0.5), 11 (Fault) → 0010 (2, i.e., 0.125). This LUT content can be updated via the configuration register.

[0070] Business Type Base Score Mapper: Directly maps to a 2-digit score based on the conversion type field in the channel context. value.

[0071] Arithmetic logic unit: Executes formulas The calculation. Among them, It has a 3-bit static priority (from the DMA descriptor). The value is fixed at 15. Multiplication is implemented using an 8-bit unsigned multiplier, and division is performed by taking the high 3 bits of the product (equivalent to dividing by 16 and then rounding down). Finally, the result is ANDed with... Add them together and output a 5-bit dynamic priority score. .

[0072] Enhanced Arbitrator: Receives 5-bit dynamic priority scores from 8 computation units. The arbitrator employs a three-level comparison tree structure, performing a maximum value lookup once per clock cycle and outputting the channel ID with the highest score. Simultaneously, the arbitrator receives an emergency dispatch request hardware signal line from the network management module. When this signal is valid, the arbitrator immediately interrupts the current arbitration cycle, unconditionally outputs the preset network management endpoint channel ID (e.g., channel 0) in the next clock cycle, and sets an "emergency mode" flag until the signal is withdrawn.

[0073] Emergency Dispatch Interface: This is a separate, high-priority hardware connection. When the network management module detects a network event requiring immediate handling (such as a node failure or a chain rebuild request), it will raise this signal while preparing the corresponding management frame.

[0074] 3.2 Dynamic Priority Scheduling Workflow and Data Collaboration: The specific workflow of dynamic priority scheduling is as follows: Step F1, State awareness and real-time updates (accompanied by periodic network management); The network management module sends status query frames to all online nodes at a preset period (e.g., 100ms). The response from each node is as follows: At the software level: parse the response and update the node information table in local RAM.

[0075] At the hardware level (new addition): The status acquisition unit calculates the response latency in parallel and generates a health code, which is then written to a double-buffered status register set. This process is completed in hardware with a latency in the microsecond range, ensuring that the PSB_Engine module can perceive network status changes in near real-time.

[0076] Step F2: Task submission and parameter injection; When the CPU processor prepares the DMA descriptor, it needs to set the static priority of this transfer task in a newly added field of the descriptor structure. (Values ​​range from 0 to 7). This descriptor is written to the descriptor list of the corresponding channel. After the FPGA's PSB_Engine module pulls and parses the descriptor, it will... The target node ID, service type, and other parameters are stored in the hardware context register of the channel, and the channel is marked as "ready".

[0077] Step F3, dynamic scheduling decision (replacing the original scheduling logic); At each scheduling decision point (e.g., every 16 clock cycles), the enhanced scheduler performs the following operations: Parallel computing: Eight dynamically prioritized computation units work simultaneously, calculating based on the context of their respective channels. value.

[0078] Arbitration Options: Comparison of 8 Enhanced Arbitrators Value, select the channel corresponding to the maximum value. .

[0079] Emergency Decision: If the "Emergency Dispatch Request" signal is valid at this time, then regardless of... What value should be used to force the selection of the network management endpoint channel? (e.g., channel 0).

[0080] Context loading: Selected channel ( or The complete context (source address, length, target ID, etc.) is loaded into the core protocol conversion pipeline.

[0081] Step F4: Rapid hardware response for emergency situations; When the network management module determines that a node is faulty: Generate fault maintenance frame data and encapsulate it into a high-priority DMA descriptor, then submit it to the descriptor list of the network management endpoint channel.

[0082] Simultaneously (a crucial step), the hardware logic raises the "emergency dispatch request" signal.

[0083] Upon receiving the signal, the arbitrator of the PSB_Engine module will complete the switching of the network management endpoint channel within two clock cycles at the latest.

[0084] The fault maintenance frame is quickly encapsulated and sent. Once completed, the network management module lowers the emergency request signal.

[0085] 3.3 Specific calculation examples and parameter descriptions: Assuming the system parameters use default values: Health weighted LUT: Normal (15), Slight delay (12), Severe delay (8), Faulty (2); Business type base score: Doorbell(3), Message(2), DIO(0); ; The task attributes for the three ready channels are as follows: Channel A: (High), Target node health = slight delay ( ), Business type = Message( ); Channel B: (In the middle), the target node's health status = normal ( ), Business type = DIO( ); Channel C: (Highest), Target node health = Severe latency ( ), Business type = Doorbell( ).

[0086] Calculate the dynamic priority score: Channel A: ; Channel B: ; Channel C: ; Arbitration result: Channel A and Channel C have the same score. At this point, the arbitrator can use predefined tie-breaking rules, such as selecting the channel with the smaller channel ID, or referring to finer-grained status information (such as timestamps). This example illustrates the core of dynamic scheduling: although channel C has the highest static priority and urgent service type, its dynamic priority is significantly reduced due to severe delays in the target node; channel A, on the other hand, gets a scheduling opportunity due to its good overall score.

[0087] 3.4 Feasibility, resource consumption, and performance data Hardware resource consumption (based on Xilinx UltraScale+ FPGA evaluation): Double-buffered status register set: 2×16×32 bits ≈ 1Kb, using a small amount of BlockRAM.

[0088] Eight dynamic priority calculation units: approximately 8 × (120 LUTs + 1 DSP48E1 Slice) ≈ 960 LUTs, 8 DSP Slices.

[0089] Enhanced arbitrator and other control logic: approximately 300 LUTs.

[0090] Total incremental resources: <1500 LUTs + 8 DSPs + 2 BRAM, which is a very low percentage in a medium-sized FPGA (e.g., <0.3% for KU115), making implementation entirely feasible.

[0091] Timing performance: Total scheduling decision delay: approximately 7-10 clock cycles (35-50ns@200MHz) from reading the status to outputting the arbitration result.

[0092] Emergency dispatch response delay: ≤500ns from the time the request signal becomes valid to the time of switching to the management channel.

[0093] State update latency: ≤1µs from receiving a node response to updating the state register.

[0094] Expected technical effects (simulation and prototype verification data): In scenarios with mild network congestion (10% of nodes experiencing high latency), the overall system throughput is improved by 18-25% compared to polling scheduling.

[0095] High-priority services ( The end-to-end delay jitter is reduced by 40-60%.

[0096] The hardware response time for node fault detection and isolation is <100µs, which is an order of magnitude faster than pure software processing (typically >1ms).

[0097] The interrupt load on the CPU processor is reduced by more than 50% due to network polling and fault handling.

[0098] Those skilled in the art should understand that the above embodiments are merely preferred methods for implementing the dynamic priority scheduling concept of the present invention. Without departing from the core concept of the present invention—namely, dynamically adjusting the data transmission scheduling strategy using network status information collected in real time by FPGA hardware—various modifications and extensions are possible, including but not limited to: The classification of node health status can be more refined or simplified.

[0099] Dynamic priority calculation formula It can be adjusted to other mathematical forms, such as introducing weighted sums, exponential factors, etc.

[0100] Emergency dispatch requests can be designed with multiple priority levels, and together with business flow priorities, they can form a more complex arbitration strategy.

[0101] The double buffering mechanism described above can be replaced by other synchronization mechanisms that guarantee data consistency. These variations should all be considered within the scope of protection of this invention.

[0102] Example 3 addresses the core contradiction in traditional FPGA protocol conversion schemes: the mismatch between static scheduling strategies and dynamic industrial network environments. Existing polling or fixed-priority scheduling ignores real-time node health changes, leading to low bandwidth utilization and uncontrollable delays in critical services during network congestion. Simultaneously, network management functions only handle status monitoring, disconnected from data forwarding and scheduling decisions at the hardware level, creating a long-latency software path for perception and decision-making, resulting in slow fault response. Example 3 constructs a direct hardware connection between network status perception and data scheduling, directly feeding back microsecond-level updated node health information to the scheduler; a dynamic priority calculation model based on multi-dimensional weights (task importance, real-time link quality, service urgency) is implemented within the FPGA; and a hardware emergency preemption mechanism is created to achieve microsecond-level fault isolation. Throughput is increased by 18-25% in congested scenarios, high-priority service latency determinism is improved by 40-60%, and fault isolation response time is reduced from milliseconds to hundreds of microseconds, while completely freeing the CPU from complex scheduling decisions. This functional integration is upgraded to intelligent collaboration, providing adaptive and highly reliable core underlying support for industrial communication systems.

[0103] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the invention.

[0104] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. It should be noted that any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A multi-channel SRIO protocol network management method based on FPGA and AXI4, wherein the method is executed by the FPGA and implemented in cooperation with the CPU processor, and the FPGA internally includes an AXI_MAC module, a PSB_Engine module, an SRIO_MAC module, and a network management module, and the method includes: Step 1: Network management initialization. After power-on, the network management module generates network management frames and writes them into the network management frame queue. After the system starts up, it multicasts network management frames to the SRIO network nodes and writes the node return information into the local RAM of the network management module. The CPU processor reads the local RAM of the network management module and establishes a node information table. Step 2, Descriptor preparation: The CPU processor stores the data to be converted in the storage space and records the starting address of the storage space and the size of the data to be converted. It then constructs a DMA descriptor and writes it into the descriptor list. Step 3, Descriptor Retrieval: The CPU processor writes the starting address and size of the descriptor list to the descriptor pointer and notifies the FPGA that there is a task to be converted. The FPGA retrieves the starting address and size of the descriptor list from the descriptor pointer. The FPGA sends a read request to the AXI_MAC module. The AXI_MAC module generates a read request based on the starting address and size of the descriptor list, encapsulates it into an AXI4 read request message, and sends it to the CPU processor via the AXI4 bus. The CPU processor returns the descriptor data to the FPGA. Step 4, Data Retrieval and Parsing: The PSB_Engine module of the FPGA parses the descriptor data to obtain the storage location and size of the data to be converted, and sends a read request for the data to be converted to the AXI_MAC module. The AXI_MAC module encapsulates the read request into a read request message and sends it to the CPU processor via the AXI4 bus. The CPU processor returns the data to be converted to the FPGA. The FPGA forwards the data to be converted to the AXI_MAC module. After completing the AXI4 protocol parsing, the AXI_MAC module sends the parsing result to the PSB_Engine module. Step 5, Encapsulation and Sending and Status Writing: The PSB_Engine module outputs the data to be encapsulated to the SRIO_MAC module according to the conversion type in the DMA descriptor. The SRIO_MAC module encapsulates the data to be encapsulated into the corresponding SRIO protocol type and sends it to the target device via the SRIO bus. The PSB_Engine module writes the conversion status into the running status field of the DMA descriptor for the CPU processor to query. Step 6, Fault Maintenance: The network management module periodically sends status query frames to each node in the SRIO network. If no valid response is received from the target node within the preset timeout period, the node is determined to be faulty. The network management module generates a node fault maintenance frame, updates the local network topology information to logically delete the faulty node, and writes the fault record into the local RAM of the network management module.

2. The multi-channel SRIO protocol network management method based on FPGA and AXI4 according to claim 1, characterized in that: The network management module manages network management frames through the network management frame queue. During the power-on and scanning phases, the network management module completes a full network node scan of the SRIO network through the network management frames and writes the scan response information into the local RAM of the network management module. The CPU processor establishes a node information table based on the local RAM of the network management module.

3. The multi-channel SRIO protocol network management method based on FPGA and AXI4 according to claim 1, characterized in that: The network management module manages the reconstruction of chain frames through the reconstruction chain queue. The network management module realizes single-node power-on, single-node power-off and network recovery through the reconstruction of chain frames.

4. The multi-channel SRIO protocol network management method based on FPGA and AXI4 according to claim 1, characterized in that: The PSB_Engine module supports multiple independent protocol conversion channels; the network management module reuses one of the protocol conversion channels as a network management endpoint for sending and receiving network management frames.

5. The multi-channel SRIO protocol network management method based on FPGA and AXI4 according to claim 1, characterized in that: The read request message is a memory read request message.

6. The multi-channel SRIO protocol network management method based on FPGA and AXI4 according to claim 1, characterized in that: The AXI4 read request length meets the constraint of not crossing the 4K byte boundary. The AXI_MAC module breaks down the read request address to ensure that the length of a single read request does not cross the 4K byte boundary and the length of a single read request does not exceed 4K bytes.

7. A multi-channel SRIO protocol network management method based on FPGA and AXI4 according to claim 1, characterized in that: The parsing and processing of the AXI_MAC module includes reordering and reassembling the data.

8. A multi-channel SRIO protocol network management method based on FPGA and AXI4 according to claim 1, characterized in that: The conversion types in the DMA descriptor include DIO, Message, and doorbell. The PSB_Engine module outputs encapsulation control information to the SRIO_MAC module based on the conversion type.

9. A multi-channel SRIO protocol network management method based on FPGA and AXI4 according to claim 1, characterized in that: The conversion status includes conversion complete, conversion timeout, and target device offline. The PSB_Engine module writes the conversion status to the DMA descriptor's running status field.

10. A multi-channel SRIO protocol network management system based on FPGA and AXI4, including FPGA, AXI4 bus interface and SRIO bus interface, wherein the FPGA integrates an AXI_MAC module, a PSB_Engine module, an SRIO_MAC module and a network management module; The AXI4 bus interface is used to connect the CPU processor to the AXI_MAC module. The AXI_MAC module is used to complete the AXI4 protocol parsing and initiate memory read request messages. The PSB_Engine module is located between the AXI_MAC module and the SRIO_MAC module. The PSB_Engine module is used to complete data interaction and write the conversion status to the DMA descriptor running status field. The SRIO_MAC module connects to the SRIO bus interface. The SRIO_MAC module is used to encapsulate service data into SRIO protocol type and send it to the target device. The network management module is used to generate network management frames and write them into the network management frame queue, multicast network management frames and write the return packet information into the local RAM of the network management module, periodically query node status, and generate fault maintenance frames to update the network topology in fault scenarios. The hardware logic of the AXI_MAC module, PSB_Engine module, SRIO_MAC module, and network management module works in concert to implement the network management method as described in any one of claims 1 to 9.

Images