A method and system for GTX Quad resource reuse based on Xilinx FPGA

Abstract

The application relates to a GTX Quad resource multiplexing method and system based on an Xilinx FPGA, wherein the method comprises the following steps: stripping a common configuration module of a GTX transceiver in a protocol IP core into an independent shared resource module; constructing a standardized interface bus connecting each protocol IP core and the independent shared resource module; dynamically distributing resource information of a four-phase phase-locked loop and a channel phase-locked loop according to protocol rate requirements; deploying a priority arbitration state machine in each channel in the Quad, monitoring protocol bandwidth requirements of each channel, and switching configuration snapshots based on the protocol bandwidth requirements, so that the GTX Quad resources are time-multiplexed. By decoupling the common configuration module into an independent shared resource, constructing a standardized interface bus, dynamically distributing clock resources and time-multiplexing configuration snapshots, the application solves the problems of resource exclusivity limitation and insufficient protocol compatibility in the prior art, improves the GTX Quad resource multiplexing rate, and can support multi-protocol dynamic switching.

Description

Technical Field

[0001] This application relates to the field of FPGA high-speed serial communication technology, and in particular to a GTXQuad resource reuse method and system based on Xilinx FPGA. Background Technology

[0002] In Xilinx FPGAs, the GTX Quad is the core unit for high-speed serial communication. Each Quad contains four GTX channels and shared GTX COMMON resources (such as PLL clock management and reset circuitry). In existing technologies, Xilinx's official protocol IP cores (such as PCIe, Aurora, and SRIO) typically bind the physical layer configuration of the GTX transceiver (including the GTX COMMON module) to the protocol logic, leading to the following problems:

[0003] First, there is a significant issue with resource exclusivity. Different protocol IP cores within the same GTX Quad need to independently access GTXCOMMON resources, but Xilinx's default IP core's Hardware Description Layer (HDL) does not enable interface reuse for the GTX COMMON module, preventing multiple protocol IP cores from sharing common resources within the same Quad. Second, protocol compatibility is insufficient. In traditional solutions, the clock domain and equalizer parameters of the GTX transceiver are statically configured by the protocol IP core, which cannot adapt to the dynamic rate requirements of different protocols. Summary of the Invention

[0004] The purpose of this application is to propose a GTX Quad resource reuse method and system based on Xilinx FPGA to achieve dynamic adaptation of multiple protocols and improve resource utilization.

[0005] To address the aforementioned technical problems, this application provides a GTX Quad resource reuse method based on Xilinx FPGA, comprising:

[0006] The common configuration module of the GTX transceiver in the protocol IP core is separated into an independent shared resource module;

[0007] Construct a standardized interface bus that connects each of the aforementioned protocol IP cores with the aforementioned independent shared resource modules;

[0008] Resource information for the quaternary phase-locked loop and the channel phase-locked loop is dynamically allocated according to the protocol rate requirements;

[0009] Priority arbitration state machines are deployed on each channel within the Quad, and the protocol bandwidth requirements of each channel are monitored. Based on the protocol bandwidth requirements, configuration snapshot switching is performed to enable time-sharing multiplexing of GTX Quad resources.

[0010] To address the aforementioned technical problems, embodiments of this application provide a GTX Quad resource reuse system based on a Xilinx FPGA, comprising:

[0011] The resource decoupling module is used to separate the common configuration module of the GTX transceiver in the protocol IP core into an independent shared resource module;

[0012] The interface bus standardization module is used to construct a standardized interface bus that connects each of the protocol IP cores and the independent shared resource modules;

[0013] The resource information allocation module is used to dynamically allocate resource information of the quaternary phase-locked loop and the channel phase-locked loop according to the protocol rate requirements.

[0014] The snapshot switching module is used to deploy priority arbitration state machines in each channel within the Quad and monitor the protocol bandwidth requirements of each channel. Based on the protocol bandwidth requirements, it configures snapshot switching to enable time-sharing multiplexing of GTX Quad resources.

[0015] This invention provides a method and system for GTX Quad resource reuse based on Xilinx FPGA. The method includes: decoupling the common configuration module of the GTX transceiver in the protocol IP core into independent shared resource modules; constructing a standardized interface bus connecting each protocol IP core and the independent shared resource modules; dynamically allocating resource information of the quaternary phase-locked loop and channel phase-locked loop according to protocol rate requirements; deploying a priority arbitration state machine in each channel within the Quad, monitoring the protocol bandwidth requirements of each channel, and performing configuration snapshot switching based on the protocol bandwidth requirements to achieve time-division multiplexing of GTX Quad resources. This invention solves the problems of resource exclusivity limitations and insufficient protocol compatibility in the prior art by decoupling the common configuration module into independent shared resources, constructing a standardized interface bus, dynamically allocating clock resources, and time-division multiplexing configuration snapshots. It has the advantages of improving GTX Quad resource reuse rate and supporting dynamic switching of multiple protocols. Attached Figure Description

[0016] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the implementation of the GTX Quad resource reuse method based on Xilinx FPGA provided in this application embodiment;

[0018] Figure 2 This is a block diagram of GTX Quad resource reuse based on Xilinx FPGA provided in another embodiment of this application;

[0019] Figure 3 This is a schematic diagram illustrating the implementation process of the GTX Quad resource reuse method based on Xilinx FPGA provided in the embodiments of this application;

[0020] Figure 4 This is a flowchart illustrating the implementation of the first sub-process in the Xilinx FPGA-based GTX Quad resource reuse method provided in this application embodiment.

[0021] Figure 5 This is a flowchart illustrating the implementation of the second sub-process in the Xilinx FPGA-based GTX Quad resource reuse method provided in this application embodiment.

[0022] Figure 6 This is a flowchart illustrating the implementation of the third sub-process in the Xilinx FPGA-based GTX Quad resource reuse method provided in this application embodiment.

[0023] Figure 7 This is a flowchart illustrating the implementation of the fourth sub-process in the Xilinx FPGA-based GTX Quad resource reuse method provided in this application embodiment.

[0024] Figure 8 This is a flowchart illustrating the implementation of the fifth sub-process in the Xilinx FPGA-based GTX Quad resource reuse method provided in this application embodiment.

[0025] Figure 9 This is a schematic diagram of a GTX Quad resource reuse system based on Xilinx FPGA provided in an embodiment of this application. Detailed Implementation

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0027] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0028] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

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

[0030] Please see Figures 1 to 3 , Figure 1 This paper illustrates a specific implementation of the GTX Quad resource reuse method based on Xilinx FPGA. Figure 2 This is a block diagram of GTX Quad resource reuse based on Xilinx FPGA provided in another embodiment of this application. Figure 3 This is a schematic diagram illustrating the implementation process of the GTX Quad resource reuse method based on Xilinx FPGA provided in the embodiments of this application.

[0031] The GTX Quad resource reuse method based on Xilinx FPGA provided in this application is applicable to FPGA chips from Xilinx 7 series to UltraScale+ architecture, and aims to improve the resource utilization of high-speed serial channels and the design flexibility of multi-service convergence scenarios.

[0032] It should be noted that if substantially the same result is obtained, the method of this invention is not based on... Figure 1 Limited to the order of the processes shown, this method includes the following steps:

[0033] S1: Separate the common configuration module of the GTX transceiver in the protocol IP core into an independent shared resource module.

[0034] This application embodiment utilizes Xilinx's open non-core IP Hardware Description Layer (HDL) modification permissions to physically reconstruct the common configuration modules (clock management, reset control) of the GTX transceiver. Specifically, the common configuration modules (such as PLL configuration, reset synchronization) of the GTX transceiver, originally integrated into each protocol IP core, are separated into independent shared resource modules, while retaining the original IP core's protocol logic layer.

[0035] Please see Figure 4 , Figure 4 A specific implementation of step S1 is shown below:

[0036] S11: The common configuration module of the GTX transceiver in the protocol IP core is stripped to generate the independent shared resource module, wherein the independent shared resource module includes a clock management PLL unit and a reset control unit.

[0037] S12: Retain the protocol logic layer in the protocol IP core, wherein the protocol logic layer includes the PCIe link training state machine and the Aurora frame parsing state machine.

[0038] The independent shared resource module (GTX COMMON module) refers to an independent functional entity formed by decoupling and reconstructing the physical layer common function modules originally embedded in the protocol IP core. Specifically, it can be implemented by modularly encapsulating the clock management PLL unit and reset control unit of the GTX transceiver using a hardware description language. This module provides clock allocation and reset control services through standardized interfaces. The clock management PLL unit is a phase-locked loop circuit that generates and synchronizes multiple clock signals. Specifically, it can be configured using the QPLL resource in the Xilinx GTXE2_COMMON primitive, dynamically adjusting the frequency division coefficient to generate reference clocks of different frequencies. The reset control unit is a timing control module that coordinates the global and local resets of the transceiver. Specifically, it can be implemented using a state machine-driven multi-level reset synchronization circuit to ensure the synchronous release of reset signals across clock domains. The protocol logic layer refers to the functional modules that implement protocol standard specifications, such as the link training state machine in the PCIe protocol and the frame parsing state machine in the Aurora protocol. Specifically, it can be implemented by retaining the logic circuits responsible for protocol negotiation and data encapsulation in the IP core. Among them, the IP core (Intellectual Property Core) is a pre-designed reusable functional module (such as PCIe, Ethernet protocol stack) that is directly integrated into the FPGA design.

[0039] Specifically, by reconstructing the hardware description layer, the physical layer and protocol layer of the protocol IP core are decoupled, and the GTX common resource configuration module, originally integrated within the IP core, is independently encapsulated as a shareable functional module. In practice, a modular design approach is used to separate the clock generation unit and reset control unit of the GTX transceiver from the IP core, forming independent hardware modules. This module connects to multiple protocol IP cores via a standardized interface bus, providing unified clock allocation and reset control services for different protocols. Simultaneously, the link training state machine and data frame parsing logic unique to each protocol IP core are retained, maintaining the complete functionality of the protocol layer. For example, in the PCIe protocol implementation, the link training state machine is retained for negotiating link rate and bandwidth, while in the Aurora protocol, the frame parsing state machine is retained for extracting payload data.

[0040] Traditional solutions rigidly bind the physical layer configuration module to the protocol logic layer, preventing different protocol IP cores within the same quad from sharing common resources. This application's embodiments, through a decoupling design of the physical and protocol layers, enable multiple protocol IP cores to share the same set of clock management and reset control resources, overcoming the architectural limitations of Xilinx's default IP cores. For example, in existing technologies, running PCIe and Aurora protocols requires separate QPLL resources, while this application's embodiments allow both protocols to share the QPLL module within the same quad. Therefore, this application's embodiments effectively eliminate the exclusive restriction of protocol IP cores on GTX common resources, enabling multiple protocol IP cores within the same quad to share and reuse clock management and reset control resources. Specifically, this reduces redundant configuration of physical layer resources while maintaining the integrity of protocol logic functions, improves quad resource reuse efficiency, and thus reduces the rigid requirements of multi-protocol systems on FPGA chip size. For example, in heterogeneous protocol co-operation scenarios, it avoids the hardware waste caused by allocating quad resources separately for each protocol.

[0041] S2: Construct a standardized interface bus that connects each of the protocol IP cores with the independent shared resource modules.

[0042] Specifically, a unified interface bus (such as a clock output interface and a dynamic reset request signal) is defined for the independent shared resource modules to enable the connection between each protocol IP core and the independent shared resource modules. The standardized interface bus refers to a hardware connection system using a unified timing specification, which can be implemented using a custom parallel bus structure. It includes clock allocation, reset synchronization, and configuration writing function modules to establish a physical layer interaction channel between the multi-protocol IP cores and the shared resources.

[0043] Please see Figure 5 , Figure 5 A specific implementation of step S2 is shown below:

[0044] S21: Divide the reference clock output by the quadrature phase-locked loop into multiple phase synchronization clock signals, and connect each clock signal to the target protocol IP core through an independent buffer;

[0045] S22: An asynchronous reset and synchronous release mechanism is adopted to distribute the global reset signal generated by the independent shared resource module to each of the protocol IP cores after synchronization processing;

[0046] S23: Write the PLL division coefficients, equalizer parameters and channel binding configurations of each protocol IP core through the programmable interface.

[0047] Specifically, after the reference clock is output through a quaternary phase-locked loop, multiple phase synchronization signals are generated through a clock distribution network. Each signal is driven by an independent buffer and then transmitted to the corresponding protocol IP core. This design maintains strict clock phase synchronization while isolating crosstalk between different protocols through buffers. After the global reset signal is generated in the independent shared resource module, it first triggers the asynchronous reset circuit, and then completes synchronous release within the local clock domain of the target protocol IP core through two-stage synchronization registers. This process ensures reliable transmission of the reset state across clock domains. Each protocol IP core accesses the configuration register of the shared resource module through the bus interface, dynamically writing PLL division coefficients, equalizer parameters, and channel binding configurations. This mechanism allows different protocols to adjust physical layer parameters according to real-time requirements, breaking through the limitations of traditional fixed configuration modes.

[0048] Among these, multi-channel phase-synchronized clock signals refer to dividing the same reference clock source into multiple strictly phase-aligned copies. This can be achieved using a digital delay-locked loop (DLL) combined with clock tree balancing technology to ensure that the clock signals received by each protocol IP core have a defined phase relationship. Independent buffers are signal isolation units placed on the clock transmission path, implemented using the BUFGCTRL primitive, used to eliminate mutual interference between clock networks of different protocol IP cores. The asynchronous reset synchronization release mechanism involves synchronizing the global reset signal with two or more registers within the target clock domain. This can be implemented using cross-clock domain synchronization circuits to eliminate metastability risks during reset signal transmission. The programmable interface refers to a register access channel that supports dynamic parameter configuration, implemented using the APB bus protocol, allowing different protocol IP cores to adjust transceiver operating parameters as needed.

[0049] Traditional solutions involve protocol IP cores directly calling the GTX transceiver hardware core, leading to inconsistent interface specifications, phase discrepancies in clock signals between different protocols, and potential logic conflicts arising from asynchronous reset signal operations. Furthermore, parameter configuration lacks dynamic adjustment capabilities. This application addresses this by establishing a unified resource access standard through a standardized interface bus, employing phase-synchronized clock allocation to eliminate clock discrepancies between multiple protocols, utilizing an asynchronous reset-synchronous release mechanism to ensure the reliability of the system reset state, and leveraging a programmable interface to enable runtime reconfiguration of transceiver parameters. This application effectively eliminates clock phase mismatch issues when multiple protocol IP cores share resources, avoids logic conflicts caused by asynchronous reset signals, and enables dynamic configuration of transceiver parameters for different protocols. This design allows multiple protocol IP cores within the same GTX Quad to work stably and collaboratively, maintaining clock synchronization accuracy while supporting online updates of hardware parameters, providing a fundamental architectural guarantee for multi-protocol time-sharing multiplexing.

[0050] S3: Dynamically allocate resource information for the quaternary phase-locked loop and the channel phase-locked loop according to the protocol rate requirements.

[0051] Specifically, based on the limited resources of one quad phase-locked ring (QL) and one channel phase-locked ring (CLR per channel) within the GTX Quad, a dynamic configuration strategy is designed to adjust the PLL division ratio, equalizer parameters, and transceiver operating mode in real time according to protocol rate requirements (e.g., 5Gbps for PCIe 2.0, 10Gbps for Aurora), thereby achieving time-division multiplexing of heterogeneous protocols. In other words, in this embodiment, the resource information of the QL and CLR is dynamically allocated according to protocol rate requirements.

[0052] The Quad PLL (QPLL) is a high-frequency phase-locked loop integrated into the GTX Quad, providing a reference clock for the entire Quad and supporting high-speed protocols (such as 10Gbps and above). The Channel PLL (CPLL) is a phase-locked loop independently configured for each GTX channel, supporting dynamic division ratio adjustment and adapting to medium- and low-speed protocols (such as 3-6Gbps).

[0053] Please see Figure 6 , Figure 6 A specific implementation of step S3 is shown below:

[0054] S31: If the protocol rate requirement is the first protocol rate, then allocate the resource information of the quaternary phase-locked loop.

[0055] S32: If the protocol rate requirement is the second protocol rate, then the frequency division ratio of the quaternary phase-locked loop and the channel phase-locked loop is dynamically adjusted so that a single channel phase-locked loop meets the second protocol rate.

[0056] Specifically, the PLL operating mode is divided according to the protocol rate requirements. When the protocol rate requirement is the first protocol rate (≥10Gbps, such as Aurora 10G), the QPLL dedicated mode is used, allocating QPLL resources and fixing the output high-precision clock. When the protocol rate requirement is the second protocol rate, which is a low-speed protocol (such as 5Gbps for PCIe 2.0, SRIO 3.125Gbps), the frequency division ratio of the quad phase-locked loop and the channel phase-locked loop is dynamically adjusted (e.g., 1:2 to 1:8) so that a single channel phase-locked loop meets the second protocol rate. The frequency division ratio refers to the ratio of the PLL output clock frequency to the input reference clock frequency, which can be achieved by modifying the frequency division coefficient parameter in the PLL register. This parameter determines the frequency accuracy and jitter characteristics of the output clock. This embodiment solves the protocol rate compatibility problem caused by the fixed PLL frequency division ratio, realizing time-division multiplexing of different rate protocols within the same GTX Quad. For example, when the system needs to switch from the 10Gbps Aurora protocol to the 2.5Gbps SATA protocol, there is no need to occupy additional quad phase-locked loop resources. The speed adaptation can be completed simply by adjusting the frequency division ratio of the channel phase-locked loop, thereby reducing the dependence on Quad resources and improving hardware utilization in multi-protocol scenarios.

[0057] S4: Deploy a priority arbitration state machine in each channel within the Quad and monitor the protocol bandwidth requirements of each channel. Configure snapshot switching based on the protocol bandwidth requirements to enable time-sharing multiplexing of GTX Quad resources.

[0058] Specifically, priority arbitration logic is deployed across the four channels within the Quad to monitor protocol bandwidth requirements in real time, and time-sharing multiplexing is achieved through snapshot switching. For example, when channel 1 is running the PCIe protocol, the QPLL occupancy of channel 2 is dynamically disabled, and its CPLL division ratio is switched to the matching rate, ensuring clock domain isolation and timing convergence when multiple protocols are running in parallel. Snapshot switching is a key technology for dynamically adjusting hardware parameters to support time-sharing multiplexing of multiple protocols. Its core is to pre-store the hardware configuration states (i.e., "snapshots") required by different protocols, and quickly switch these states during runtime according to protocol requirements, thereby efficiently reusing limited physical resources (such as PLLs, clock domains, etc.).

[0059] In one specific embodiment, QPLL supports high-speed protocols (10Gbps+), CPLL adapts to medium and low-speed protocols (3-6Gbps), and the channel state machine is used to dynamically switch configurations. In the actual test, a single Quad can stably run up to 4 protocols (such as PCIe+Aurora+SRIO) at the same time, achieving a 300% improvement in resource reuse rate.

[0060] Please see Figure 7 , Figure 7 A specific implementation of step S4 is shown below:

[0061] S41: Deploy the priority arbitration state machine in each channel within the Quad.

[0062] S42: Monitor changes in bandwidth requirements of each channel protocol, and when a new protocol access request is detected, suspend the current low-priority channel in the priority arbitration state machine.

[0063] S43: Pre-store multiple sets of hardware configuration snapshots in non-volatile memory, and switch the hardware configuration snapshots based on the new protocol to enable time-sharing multiplexing of GTX Quad resources.

[0064] Specifically, when the channel bandwidth monitoring module detects a new protocol access request, the arbitration state machine suspends the data transmission of the current low-priority channel according to preset priority rules, and freezes its physical layer configuration state. At this time, the system loads the hardware configuration snapshot corresponding to the target protocol from non-volatile memory, writes the pre-stored transceiver parameters into the control register in batches through the bus interface, and then initiates the clock link relocking and signal integrity verification process. After the receiving end eye diagram monitoring module confirms that the signal quality meets the standards, the arbitration state machine resumes the data transmission of the target protocol channel and updates the priority mapping table, thereby achieving dynamic switching of multiple protocols without increasing physical resources. The priority arbitration state machine refers to a channel priority dynamic management system established through a finite state machine model. Specifically, it can be implemented using state transition logic based on a weighted round-robin algorithm, used to evaluate the priority of each channel protocol in real time and execute resource allocation decisions. Protocol bandwidth requirement monitoring refers to the technical means of statistically analyzing channel data throughput using a hardware counter. Specifically, it can be implemented using the transceiver's built-in FIFO depth monitoring module, used to trigger configuration switching events. A hardware configuration snapshot refers to a set of physical layer parameters pre-stored in a storage medium. Specifically, it can be stored in the form of an FPGA configuration register image file, which includes key configuration parameters such as transceiver equalizer parameters and clock division ratio.

[0065] Traditional solutions require different protocols to exclusively occupy GTX Quad resources and cannot dynamically adjust configuration parameters, resulting in low physical layer resource utilization. This application's embodiment eliminates parameter reconfiguration latency during protocol switching through a hardware configuration snapshot pre-storage and dynamic loading mechanism. Simultaneously, a priority arbitration state machine ensures the quality of service for high-priority protocols, resolving resource contention issues in multi-protocol concurrent scenarios. This application's embodiment effectively solves the resource conflict problem during dynamic switching of multiple protocols within the same GTX Quad. By implementing a hardware-level configuration parameter fast switching mechanism, it achieves on-demand allocation of physical resources, significantly improving the reuse efficiency of high-speed serial interface resources and avoiding the increased hardware costs caused by resource exclusivity in traditional solutions.

[0066] Please see Figure 8 , Figure 8 A specific implementation of step S43 is shown below:

[0067] S431: The multiple sets of hardware configuration snapshots are pre-stored in the non-volatile memory, wherein each set of hardware configuration snapshots includes the QPLL / CPLL division ratio, transceiver equalizer parameters, and lockout threshold of the clock data recovery (CDR) module required by the target protocol.

[0068] S432: When a request for the new protocol is received, pause the data transmission of the current channel and save the current configuration state to a temporary buffer.

[0069] S433: Load the target protocol configuration parameters from the hardware configuration snapshot into the channel control register, and start the clock relocking and link training process.

[0070] S434: When the receiver's signal eye diagram quality monitor returns a lock success signal, channel data transmission is resumed and the protocol priority table is updated.

[0071] Specifically, a dynamically loadable physical layer parameter system is constructed by pre-storing configuration snapshots containing QPLL / CPLL division ratios, equalizer parameters, and CDR lockout thresholds. When a new protocol access request is detected, data transmission on the current low-priority channel is first paused, and the parameters of the running transceiver are saved to a temporary buffer to ensure that the original configuration information is not lost during protocol switching. Then, the target protocol configuration parameters are retrieved from non-volatile memory and quickly switched by directly writing them to the channel control register. After the parameters are loaded, the locking process of the clock data recovery module is initiated, and the clock domain of the new protocol is established through the clock calibration circuit built into the GTX. Simultaneously, the link training state machine is triggered to execute the negotiation and handshake process according to the target protocol specification. During this process, the signal quality monitoring unit at the receiver continuously monitors the eye diagram opening. When the bit error rate is lower than a preset threshold, a lockout success signal is fed back, triggering channel data transmission recovery and updating the protocol priority table, completing the full dynamic switching process.

[0072] The hardware configuration snapshot refers to a pre-stored complete set of configurations containing the physical layer parameters required for protocol operation. This can be implemented using Flash or EEPROM memory to save key parameters such as QPLL / CPLL division ratios, equalizer parameters, and CDR lockout thresholds for different protocols, enabling rapid retrieval of protocol parameters. The temporary buffer is a storage area used to temporarily store the current protocol's operating state. This can be implemented using the FPGA's internal Block RAM to maintain the integrity of the original configuration during protocol switching. The signal eye diagram quality monitor is a hardware module used to evaluate the integrity of the received signal. This can be implemented through a bit error rate test unit integrated into the GTX receiver, judging the link lockout status by monitoring indicators such as eye diagram opening and jitter tolerance. This application's embodiment solves the protocol switching obstacle caused by statically fixed physical layer parameters, realizing dynamic reuse of GTX Quad resources in multi-protocol scenarios. Through the pre-storage and retrieval mechanism of the hardware configuration snapshot, a single GTX channel can adapt to the physical layer parameter requirements of different protocols, avoiding hardware resource conflicts caused by protocol switching in traditional solutions. By employing a switching method that combines configuration state caching with direct register writing, the service interruption time during protocol switching is significantly reduced while ensuring the integrity of protocol data. Combined with a closed-loop feedback mechanism for signal quality monitoring, the stability and reliability of the link after dynamic switching are ensured, effectively improving system resource utilization in multi-protocol convergence scenarios.

[0073] In this embodiment, the common configuration module of the GTX transceiver in the protocol IP core is separated into an independent shared resource module; a standardized interface bus is constructed to connect each protocol IP core and the independent shared resource module; resource information of the quad phase-locked loop and the channel phase-locked loop is dynamically allocated according to protocol rate requirements; a priority arbitration state machine is deployed in each channel within the Quad, and the protocol bandwidth requirements of each channel are monitored. Configuration snapshot switching is performed based on the protocol bandwidth requirements to enable time-division multiplexing of GTX Quad resources. This embodiment of the invention solves the problems of resource exclusivity limitations and insufficient protocol compatibility in the prior art by decoupling the common configuration module into independent shared resources, constructing a standardized interface bus, dynamically allocating clock resources, and time-division multiplexing configuration snapshots. It has the advantages of improving GTX Quad resource reuse rate and supporting dynamic switching of multiple protocols.

[0074] This application's embodiments utilize resource decoupling and dynamic allocation mechanisms to enable different protocols to share common resources within the same quad, while also supporting dynamic adjustment of protocol rates. Existing technologies relying on statically configured PLL parameters cannot adapt to multi-protocol mixed scenarios, while this application achieves flexible protocol rate adaptation through dynamic adjustment of the frequency division ratio and configuration snapshot switching. Furthermore, traditional solutions require allocating an independent quad unit for each protocol; this application's embodiments significantly reduce hardware resource consumption through time-division multiplexing. Additionally, this application's embodiments enable the same GTX quad to support multiple heterogeneous protocols, improving hardware resource utilization; achieve multi-protocol rate compatibility through a dynamic clock allocation mechanism, expanding application scenario adaptability; and reduce link reconstruction time during protocol switching through rapid snapshot switching, improving system response efficiency.

[0075] Please refer to Figure 9 As a response to the above Figure 1 The implementation of the method shown in this application provides an embodiment of a GTX Quad resource reuse system based on Xilinx FPGA. This system embodiment is similar to... Figure 1 Corresponding to the method embodiments shown, the system can be specifically applied to various electronic devices.

[0076] like Figure 9 As shown, the Xilinx FPGA-based GTX Quad resource reuse system in this embodiment includes: a resource decoupling module 51, an interface bus standardization module 52, a resource information allocation module 53, and a snapshot switching module 54, wherein:

[0077] Resource decoupling module 51 is used to separate the common configuration module of the GTX transceiver in the protocol IP core into an independent shared resource module;

[0078] The interface bus standardization module 52 is used to construct a standardized interface bus connecting each of the protocol IP cores and the independent shared resource modules;

[0079] Resource information allocation module 53 is used to dynamically allocate resource information of quaternary phase-locked loop and channel phase-locked loop according to protocol rate requirements;

[0080] The snapshot switching module 54 is used to deploy a priority arbitration state machine in each channel within the Quad, monitor the protocol bandwidth requirements of each channel, and configure snapshot switching based on the protocol bandwidth requirements to enable time-sharing multiplexing of GTX Quad resources.

[0081] Furthermore, the resource decoupling module 51 includes:

[0082] The stripping unit is used to strip the common configuration module of the GTX transceiver in the protocol IP core to generate the independent shared resource module, wherein the independent shared resource module includes a clock management PLL unit and a reset control unit;

[0083] A protocol logic layer reservation unit is used to reserve the protocol logic layer in the protocol IP core, wherein the protocol logic layer includes a PCIe link training state machine and an Aurora frame parsing state machine.

[0084] Furthermore, the interface bus standardization module 52 includes:

[0085] The clock signal partitioning unit is used to divide the reference clock output by the quadrature phase-locked loop into multiple phase synchronization clock signals, and connect each clock signal to the target protocol IP core through an independent buffer;

[0086] A global reset signal generation unit is used to distribute the global reset signal generated by the independent shared resource module to each of the protocol IP cores after synchronization processing, using an asynchronous reset and synchronous release mechanism.

[0087] The parameter writing unit is used to write the PLL frequency division coefficients, equalizer parameters and channel binding configurations of each protocol IP core through a programmable interface.

[0088] Furthermore, the snapshot switching module 54 includes:

[0089] A state machine deployment unit is used to deploy the priority arbitration state machine in each channel of the Quad;

[0090] The state machine suspension unit is used to monitor changes in the bandwidth requirements of each channel protocol. When a new protocol access request is detected, the priority arbitration state machine is suspended for the current low-priority channel.

[0091] The snapshot switching implementation unit is used to pre-store multiple sets of hardware configuration snapshots in non-volatile memory and switch the hardware configuration snapshots based on the new protocol, so as to enable time-sharing multiplexing of GTX Quad resources.

[0092] Furthermore, the snapshot switching implementation unit includes:

[0093] The snapshot pre-storage subunit is used to pre-store the multiple sets of hardware configuration snapshots in the non-volatile memory, wherein each set of hardware configuration snapshots includes the QPLL / CPLL division ratio, transceiver equalizer parameters, and lockout threshold of the clock data recovery (CDR) module required by the target protocol.

[0094] The state saving subunit is used to pause the data transmission of the current channel and save the current configuration state to a temporary buffer when a request for the new protocol is received.

[0095] The parameter loading subunit is used to load the target protocol configuration parameters from the hardware configuration snapshot into the channel control register and start the clock relocking and link training process;

[0096] The priority table update subunit is used to resume channel data transmission and update the protocol priority table after the receiver signal eye diagram quality monitor returns a lock success signal.

[0097] Furthermore, the resource information allocation module 53 includes:

[0098] The first allocation unit is used to allocate the resource information of the quaternary phase-locked loop if the protocol rate requirement is the first protocol rate.

[0099] The second allocation unit is used to dynamically adjust the frequency division ratio of the quaternary phase-locked loop and the channel phase-locked loop if the protocol rate requirement is the second protocol rate, so that a single channel phase-locked loop can meet the second protocol rate.

[0100] In this embodiment, a resource decoupling module is used to separate the common configuration module of the GTX transceiver in the protocol IP core into an independent shared resource module; an interface bus standardization module is used to construct a standardized interface bus connecting each protocol IP core and the independent shared resource module; a resource information allocation module is used to dynamically allocate resource information of the quad phase-locked loop and the channel phase-locked loop according to the protocol rate requirements; and a snapshot switching module is used to deploy a priority arbitration state machine in each channel within the Quad, monitor the protocol bandwidth requirements of each channel, and perform configuration snapshot switching based on the protocol bandwidth requirements, so as to enable time-division multiplexing of GTX Quad resources. This embodiment of the invention solves the problems of resource exclusivity limitations and insufficient protocol compatibility in the prior art by decoupling the common configuration module into independent shared resources, constructing a standardized interface bus, dynamically allocating clock resources, and time-division multiplexing configuration snapshots. It has the advantages of improving the resource reuse rate of GTX Quad and supporting dynamic switching of multiple protocols.

[0101] Obviously, the embodiments described above are merely some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the scope of this application. This application can be implemented in many different forms; rather, these embodiments are provided to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of protection of this application.

Claims

1. A method for GTX Quad resource reuse based on Xilinx FPGA, characterized in that, include: The common configuration module of the GTX transceiver in the protocol IP core is separated into an independent shared resource module; Construct a standardized interface bus that connects each of the aforementioned protocol IP cores with the aforementioned independent shared resource modules; Resource information for the quaternary phase-locked loop and the channel phase-locked loop is dynamically allocated according to the protocol rate requirements; A priority arbitration state machine is deployed in each channel within the Quad, and the protocol bandwidth requirements of each channel are monitored. Based on the protocol bandwidth requirements, a configuration snapshot switch is performed to enable time-sharing multiplexing of GTX Quad resources. The step of separating the common configuration module of the GTX transceiver in the protocol IP core into an independent shared resource module includes: The common configuration module of the GTX transceiver in the protocol IP core is stripped to generate the independent shared resource module, wherein the independent shared resource module includes a clock management PLL unit and a reset control unit; The protocol logic layer in the protocol IP core is retained, wherein the protocol logic layer includes a PCIe link training state machine and an Aurora frame parsing state machine; The construction of a standardized interface bus connecting each of the protocol IP cores and the independent shared resource modules includes: The reference clock output by the quadrature phase-locked loop is divided into multiple phase synchronization clock signals, and each clock signal is connected to the target protocol IP core through an independent buffer. An asynchronous reset and synchronous release mechanism is adopted to distribute the global reset signal generated by the independent shared resource module to each protocol IP core after synchronization processing. Write the PLL division coefficients, equalizer parameters and channel binding configurations of each of the aforementioned protocol IP cores through the programmable interface; The step of deploying a priority arbitration state machine in each channel within the Quad and monitoring protocol bandwidth requirements, and configuring snapshot switching based on these requirements to enable time-sharing multiplexing of GTX Quad resources, includes: The priority arbitration state machine is deployed in each channel within the Quad; Monitor changes in bandwidth requirements of each channel protocol, and when a new protocol access request is detected, suspend the current low-priority channel in the priority arbitration state machine; Multiple sets of hardware configuration snapshots are pre-stored in non-volatile memory, and the hardware configuration snapshots are switched based on the new protocol to enable time-sharing multiplexing of GTX Quad resources. The resource information for dynamically allocating the quaternary phase-locked loop and the channel phase-locked loop according to the protocol rate requirements includes: If the required protocol rate is the first protocol rate, then allocate the resource information of the quaternary phase-locked loop; If the required protocol rate is the second protocol rate, the frequency division ratio of the quaternary phase-locked loop and the channel phase-locked loop is dynamically adjusted so that a single channel phase-locked loop meets the second protocol rate.

2. The GTX Quad resource reuse method based on Xilinx FPGA according to claim 1, characterized in that, The method of pre-storing multiple sets of hardware configuration snapshots in non-volatile memory and switching the hardware configuration snapshots based on the new protocol to enable time-sharing multiplexing of GTX Quad resources includes: The multiple sets of hardware configuration snapshots are pre-stored in the non-volatile memory, wherein each set of hardware configuration snapshots includes the QPLL / CPLL division ratio, transceiver equalizer parameters, and lockout threshold of the clock data recovery (CDR) module required by the target protocol. When a request for the new protocol is received, data transmission on the current channel is paused, and the current configuration state is saved to a temporary buffer. Load the target protocol configuration parameters from the hardware configuration snapshot into the channel control register, and initiate the clock relocking and link training process; Once the receiver's eye diagram quality monitor returns a lock success signal, channel data transmission resumes and the protocol priority table is updated.

3. A GTX Quad resource reuse system based on Xilinx FPGA, characterized in that, include: The resource decoupling module is used to separate the common configuration module of the GTX transceiver in the protocol IP core into an independent shared resource module; The interface bus standardization module is used to construct a standardized interface bus that connects each of the protocol IP cores and the independent shared resource modules; The resource information allocation module is used to dynamically allocate resource information of the quaternary phase-locked loop and the channel phase-locked loop according to the protocol rate requirements. The snapshot switching module is used to deploy priority arbitration state machines in each channel within the Quad and monitor the protocol bandwidth requirements of each channel. Based on the protocol bandwidth requirements, it configures snapshot switching to enable time-sharing multiplexing of GTX Quad resources. The resource decoupling module includes: The stripping unit is used to strip the common configuration module of the GTX transceiver in the protocol IP core to generate the independent shared resource module, wherein the independent shared resource module includes a clock management PLL unit and a reset control unit; A protocol logic layer retention unit is used to retain the protocol logic layer in the protocol IP core, wherein the protocol logic layer includes a PCIe link training state machine and an Aurora frame parsing state machine; The interface bus standardization module includes: The clock signal partitioning unit is used to divide the reference clock output by the quadrature phase-locked loop into multiple phase synchronization clock signals, and connect each clock signal to the target protocol IP core through an independent buffer; A global reset signal generation unit is used to distribute the global reset signal generated by the independent shared resource module to each of the protocol IP cores after synchronization processing, using an asynchronous reset and synchronous release mechanism. The parameter writing unit is used to write the PLL frequency division coefficient, equalizer parameters and channel binding configuration of each protocol IP core through a programmable interface. The snapshot switching module includes: A state machine deployment unit is used to deploy the priority arbitration state machine in each channel of the Quad; The state machine suspension unit is used to monitor changes in the bandwidth requirements of each channel protocol. When a new protocol access request is detected, the priority arbitration state machine is suspended for the current low-priority channel. The snapshot switching implementation unit is used to pre-store multiple sets of hardware configuration snapshots in non-volatile memory and switch the hardware configuration snapshots based on the new protocol, so as to enable time-sharing multiplexing of GTX Quad resources. The resource information allocation module includes: The first allocation unit is used to allocate the resource information of the quaternary phase-locked loop if the protocol rate requirement is the first protocol rate. The second allocation unit is used to dynamically adjust the frequency division ratio of the quaternary phase-locked loop and the channel phase-locked loop if the protocol rate requirement is the second protocol rate, so that a single channel phase-locked loop can meet the second protocol rate.

Images