Millisecond-level FPGA distributed management and control method and system

Abstract

The application discloses a millisecond-level FPGA distributed management and control method and system, relates to the technical field of intelligent management of server hardware, and comprises the following steps: receiving a management and control instruction from a BMC through a hard core processor built in an FPGA, and extracting a target SoC identifier from the management and control instruction; activating a target communication channel through a multiplexing matrix integrated in the FPGA, and transmitting the management and control instruction to a corresponding target SoC node; obtaining an execution state of the target SoC node, and returning the execution state to the BMC. The application realizes intelligent perception of a physical link state and dynamic matching of a verification strength by performing hierarchical signal quality determination and adaptive verification mode generation on a target communication channel through a CRC (Cyclic Redundancy Check) verification circuit.

Description

Technical Field

[0001] This invention relates to the field of intelligent management technology for server hardware, and in particular to a millisecond-level FPGA distributed control method and system. Background Technology

[0002] Millisecond-level FPGA distributed management and control technology plays a crucial role in today's data center field. With the popularization of heterogeneous computing architectures and the continuous expansion of SoC node scale, the demand for refined and low-latency collaborative management and control of underlying hardware resources is becoming increasingly prominent. Such solutions generally rely on BMC and multi-level intermediate controllers to build instruction distribution links, and use standardized bus protocols to achieve parameter configuration and status acquisition of target nodes. This architecture has good compatibility and engineering maturity in small and medium-scale deployments.

[0003] In the field of millisecond-level FPGA distributed management and control, traditional distributed management and control methods are prone to accumulated instruction link delays due to their inherent software stack dependencies and multi-level forwarding mechanisms when dealing with concurrent instruction delivery from ultra-large-scale nodes, making it difficult to meet the timeliness requirements of millisecond-level accurate synchronization. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a millisecond-level distributed management and control method for FPGAs to solve the problem of millisecond-level synchronization failure caused by the accumulation of instruction link latency in ultra-large-scale SoC node concurrent scenarios.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0007] In a first aspect, the present invention provides a millisecond-level distributed management and control method for FPGAs, which includes receiving management and control instructions from the BMC through the hard core processor built into the FPGA, and extracting the target SoC identifier from the management and control instructions;

[0008] The target communication channel is determined by looking up the corresponding physical channel address in the address mapping table integrated in the FPGA based on the target SoC identifier.

[0009] The target communication channel is activated by the multiplexing matrix integrated in the FPGA, and the control command is transparently transmitted to the corresponding target SoC node;

[0010] The execution status of the target SoC node is obtained and the execution status is sent back to the BMC.

[0011] As a preferred embodiment of the millisecond-level FPGA distributed management and control method of the present invention, the FPGA's built-in hard core processor includes a PCIe hard core IP core and a RISC-V hard core processor. The FPGA also integrates an AXI bus interface, a DMA buffer, and a CRC check circuit. After receiving management and control instructions from the BMC through the FPGA's built-in hard core processor, the method further includes...

[0012] The PCIe hard core IP core parses the data link layer protocol of the control command, and the AXI bus interface writes the parsed control command into the DMA buffer.

[0013] If the write handshake signal of the AXI bus interface is detected as successful, a DMA buffer write complete status is generated; if the write handshake signal of the AXI bus interface is detected as unsuccessful, a DMA buffer write failure status is generated.

[0014] When the DMA buffer is written, the CRC verification circuit performs a CRC integrity check on the parsed control command in the DMA buffer, and generates a control command that has passed the check if the CRC integrity check passes.

[0015] As a preferred embodiment of the millisecond-level FPGA distributed management and control method of the present invention, the steps for extracting the target SoC identifier from the management and control command are as follows:

[0016] The RISC-V hard core processor parses and verifies the control instructions that have passed verification, and then disassembles the verified control instructions using the hardware bit field operation instructions of the RISC-V hard core processor to extract the target SoC identifier.

[0017] As a preferred embodiment of the millisecond-level FPGA distributed management and control method of the present invention, the address mapping table includes a storage interface and address decoding logic; the step of finding the corresponding physical channel address in the address mapping table integrated in the FPGA according to the target SoC identifier to determine the target communication channel includes,

[0018] The RISC-V hard core processor accesses the address mapping table based on the target SoC identifier and generates an address mapping table query request.

[0019] The storage interface of the address mapping table reads the mapping relationship between the target SoC identifier and the storage location of the address mapping table according to the address mapping table query request, and generates the physical channel address;

[0020] The address decoding logic of the address mapping table determines the target communication channel by parsing the correspondence between the target SoC identifier and the storage location of the address mapping table based on the physical channel address.

[0021] As a preferred embodiment of the millisecond-level FPGA distributed management and control method of the present invention, the multiplexing matrix includes a multiplexing matrix controller and a CRC check circuit; the activation of the target communication channel through the multiplexing matrix integrated in the FPGA includes,

[0022] The multiplexing matrix controller switches to the target communication channel according to the physical channel address;

[0023] The CRC verification circuit performs CRC signal integrity verification on the target communication channel and generates the target communication channel activation state.

[0024] As a preferred embodiment of the millisecond-level FPGA distributed management and control method of the present invention, wherein: the target communication channel activation state is the activated target communication channel, including,

[0025] The CRC check circuit detects the signal amplitude of the target communication channel and generates a signal identifier by comparing the signal amplitude with the classification result of the preset signal timing jitter threshold.

[0026] The CRC check circuit performs a secondary judgment based on the signal identifier. When the signal identifier is a high signal identifier, it generates a fast check mode and a standard check mode respectively based on whether the stability parameter exceeds the signal timing jitter threshold. When the signal identifier is a medium or low signal identifier, it directly generates a deep check mode.

[0027] In the deep verification mode, the CRC verification circuit performs enhanced signal sampling and dual redundancy verification on the target communication channel. If the verification is successful, a secure activation state is generated; if the verification fails, an activation failure state is generated, and the secure activation state is used as the activation state of the target communication channel.

[0028] As a preferred embodiment of the millisecond-level FPGA distributed management and control method of the present invention, the step of transparently transmitting the management and control command to the corresponding target SoC node is as follows:

[0029] When the target communication channel is in a secure active state, the CRC check circuit is encapsulated and converted according to the protocol of the target communication channel through control commands;

[0030] The control command after packaging and conversion is passed through to the target SoC node corresponding to the physical channel address.

[0031] As a preferred embodiment of the millisecond-level FPGA distributed management and control method of the present invention, the steps for obtaining the execution status of the target SoC node are as follows:

[0032] After executing the control command, the target SoC node returns status response data through the target communication channel;

[0033] The RISC-V hard-core processor parses the status response data of the target SoC node, obtains key status fields, and writes them into the status register group.

[0034] After the data writing is completed and the ECC verification is passed, the status register group generates a valid write flag, and the RISC-V hard core processor generates the execution status of the target SoC node.

[0035] As a preferred embodiment of the millisecond-level FPGA distributed management and control method of the present invention, the step of transmitting the execution status back to the BMC is as follows:

[0036] The PCIe hard core IP core integrates a data link layer; it encapsulates the execution status data of the target SoC node into PCIe TLP format data packets, which are then injected into the transmission queue by the DMA controller;

[0037] The TLP data packet is transmitted from the PCIe Gen3 x4 physical link to the memory-mapped area of ​​the BMC through the PCIe hard core IP core, and a CRC-32 checksum is added at the data link layer.

[0038] The TLP data packet is subjected to CRC-32 verification. After the verification is successful, the status data field in the TLP data packet is parsed to generate a BMC confirmation response, so as to complete the backhaul of the execution status of the target SoC node to the BMC.

[0039] Secondly, the present invention provides a millisecond-level FPGA distributed management and control system, comprising: an instruction parsing module, used to receive management and control instructions from the BMC through the FPGA's built-in hard core processor, and extract a target SoC identifier from the management and control instructions; an address mapping module, used to look up the corresponding physical channel address in the address mapping table integrated in the FPGA according to the target SoC identifier, and determine the target communication channel; a channel switching module, used to activate the target communication channel through the multiplexing matrix integrated in the FPGA, and pass through the management and control instructions to the corresponding target SoC node; and a feedback module, used to obtain the execution status of the target SoC node, and send the execution status back to the BMC.

[0040] The beneficial effects of this invention are as follows: This invention performs graded signal quality judgment and adaptive verification mode generation on the target communication channel through CRC verification circuit, so as to realize intelligent perception of physical link status and dynamic matching of verification strength, ensuring safe activation even under inferior channels, and greatly improving the communication robustness of large-scale SoC arrays in complex electromagnetic environments. Attached Figure Description

[0041] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 This is a flowchart of a millisecond-level FPGA distributed management and control method.

[0043] Figure 2 This is a schematic diagram of a millisecond-level FPGA distributed management and control system.

[0044] Figure 3 A flowchart for instruction processing.

[0045] Figure 4 This is a flowchart of the status feedback process. Detailed Implementation

[0046] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0047] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0048] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0049] Reference Figures 1-4 As one embodiment of the present invention, this embodiment provides a millisecond-level FPGA distributed management and control method, including the following steps:

[0050] This embodiment also provides a millisecond-level FPGA distributed management and control system, including:

[0051] S1. Receive control instructions from BMC through the FPGA's built-in hard core processor, and extract the target SoC identifier from the control instructions;

[0052] In this invention, step S1, which extracts the target SoC identifier, includes the following steps A1 to A4:

[0053] Step A1: The PCIe hard core IP core parses the data link layer protocol of the control instructions, and the AXI bus interface writes the parsed control instructions into the DMA buffer;

[0054] Specifically, the data link layer performs protocol parsing on the control commands, stripping the PCIe transaction layer header, data link layer sequence number, and LCRC checksum tail, and extracting the payload containing the target SoC identifier and opcode. Subsequently, the PCIe hard IP core initiates a write operation through the AXI bus interface, sending the parsed control command data to initiate a write transaction according to the AXI4 protocol format, using the AWADDR address signal, AWLEN length signal, and WVALID write data valid signal. After the AXI bus interface detects the WREADY write response signal going high, it completes the handshake and writes the parsed control commands into the DMA buffer.

[0055] It should be noted that the AXI4 write transaction initiated by the AXI bus interface includes the AWADDR address signal, the AWLEN length signal, and the WVALID write data valid signal.

[0056] Step A2: If the write handshake signal of the AXI bus interface is detected as successful, generate a DMA buffer write complete status; if the write handshake signal of the AXI bus interface is detected as unsuccessful, generate a DMA buffer write failure status.

[0057] Specifically, the AXI bus interface continuously monitors the WVALID write data valid signal driven by the PCIe hard core IP core and the WREADY signal fed back by the DMA buffer controller within a global synchronous clock domain. When the WVALID write data valid signal and the WREADY signal are both high in the same clock cycle, it is determined that the write handshake is successful and a DMA buffer write complete state is generated. If the WVALID write data valid signal and the WREADY signal fail to go high simultaneously within a preset timeout clock cycle (e.g., 1000 clock cycles), it is determined that the write handshake is failed and a DMA buffer write failure state is generated.

[0058] Step A3: After the DMA buffer is written, the CRC check circuit performs a CRC integrity check on the parsed control command in the DMA buffer. If the CRC integrity check passes, a control command that has passed the check is generated.

[0059] Specifically, after the DMA buffer write completion status is confirmed, the CRC check circuit is immediately activated. It reads the stored parsed control command data from the DMA buffer and performs bitwise XOR and shift operations on the control command data according to the preset CRC polynomial (e.g., CRC-16-CCITT) to generate a 16-bit check result. Subsequently, the CRC check circuit compares the check result bitwise with the preset CRC check code field in the control command data. If the calculated 16-bit check result is completely consistent with the preset CRC check code field in the control command data, the CRC integrity check is deemed to have passed, and a control command that has passed the check is generated.

[0060] Step A4: The RISC-V hard core processor parses the verified control instructions and disassembles the verified control instructions using the hardware bit field operation instructions of the RISC-V hard core processor to extract the target SoC identifier;

[0061] Specifically, the control instruction data is loaded from the DMA buffer into the internal register group. Then, according to the predefined binary protocol format of the control instruction, the hardware bit field operation instructions built into the RISC-V hard core processor are called to perform precise isolation and alignment operations on the specific bit segment data carrying the target SoC identifier in the control instruction byte stream that has passed the verification. The specific bit segment data of the target SoC identifier is written into the dedicated target register, and finally the target SoC identifier is extracted.

[0062] It should be noted that the predefined binary protocol format refers to the fixed bit layout and encoding rules agreed upon by the BMC and FPGA during the system initialization or firmware design phase. These rules are used to carry the target SoC identifier and opcode and are pre-fixed in the instruction parsing logic of the RISC-V hard core processor through hardware design documents or configuration registers.

[0063] The FPGA's built-in hard processors include PCIe hard core IP cores and RISC-V hard core processors. The FPGA also integrates an AXI bus interface, DMA buffer, and CRC check circuit.

[0064] S2. Based on the target SoC identifier, search for the corresponding physical channel address in the address mapping table integrated in the FPGA to determine the target communication channel;

[0065] In this invention, determining the target communication channel in step S2 includes the following steps B1 to B3:

[0066] Step B1: The RISC-V hard core processor accesses the address mapping table based on the target SoC identifier and generates an address mapping table lookup request;

[0067] Specifically, after the RISC-V hard-core processor extracts the target SoC identifier, it uses the extracted target SoC identifier as an index key value and initiates a read operation to the address mapping table integrated in the FPGA through the AXI bus interface. It constructs a 32-bit address mapping table query request packet containing the logical ID field of the target SoC identifier. The address field in this query request packet points to the base address offset position of the address mapping table in the FPGA on-chip Flash. The query request packet is sent to the address mapping table storage interface through the address channel and address valid signal of the AXI bus interface, and finally the address mapping table query request is generated.

[0068] It should be noted that the address mapping table lookup request packet refers to a standardized hardware data packet constructed and issued by the RISC-V hard core processor for querying the address mapping table integrated in the FPGA. The core content is to convert the target SoC identifier into a 32-bit physical memory access address that conforms to the AXI bus protocol. The 32-bit physical memory access address points to the specific location in the address mapping table where the corresponding SoC physical channel information is stored in the FPGA on-chip Flash or BRAM, and triggers a memory interface read operation.

[0069] Step B2: The address mapping table storage interface reads the mapping relationship between the target SoC identifier and the storage location of the address mapping table according to the address mapping table query request, and generates the physical channel address;

[0070] Specifically, after receiving an address mapping table query request initiated by the RISC-V hard core processor, the address mapping table storage interface parses the 32-bit physical address field contained in the address mapping table query request. Using the 32-bit physical address as a read pointer, it locates and reads 8 bytes of continuous data corresponding to the target SoC identifier from the on-chip Flash memory unit of the FPGA. The storage interface combines the Bank number and Channel number in a high-order alignment manner to form a 32-bit integer physical channel address value, and returns it to the RISC-V hard core processor through the RDATA bus of the AXI bus interface, finally generating the physical channel address.

[0071] It should be noted that the 32-bit physical address field is calculated from the target SoC identifier, the base address of the address mapping table, and the entry offset; the 8-byte mapping entry structure contains three fields: logical ID, physical bank number, and channel number, as well as a 5-byte reserved field.

[0072] Step B3: The address decoding logic of the address mapping table parses the correspondence between the target SoC identifier and the storage location of the address mapping table based on the physical channel address to determine the target communication channel;

[0073] Specifically, after receiving the 32-bit physical channel address output from the storage interface, the address decoding logic of the address mapping table splits the 32-bit physical channel address into a high 16-bit physical bank number and a low 16-bit channel number. Based on the physical bank number and channel number, it reverse-indexes the address mapping table pre-stored in the on-chip Flash memory of the FPGA to locate the 8-byte mapping entry corresponding to the physical channel address, and extracts the target SoC identifier and its storage location in the address mapping table. Finally, by establishing a bidirectional mapping relationship between the physical channel address and the target SoC identifier and its storage location, the logical affiliation and physical location of the target communication channel are determined, thereby identifying the target communication channel.

[0074] It should be noted that the address mapping table includes the storage interface and address decoding logic.

[0075] S3. Activate the target communication channel through the multiplexing matrix integrated in the FPGA, set the target communication channel to the activated target communication channel, and pass the control command to the corresponding target SoC node;

[0076] In this invention, step S3, which involves transparently transmitting the control command to the corresponding target SoC node, includes the following steps C1 to C7:

[0077] Step C1: The multiplexing matrix controller switches to the target communication channel based on the physical channel address;

[0078] Specifically, after receiving the 32-bit physical channel address output from the address mapping table, the multiplexing matrix controller first splits the 32-bit physical channel address into a high 16-bit physical bank number and a low 16-bit channel number. Then, it activates the corresponding bank area control bus inside the FPGA according to the physical bank number, and selects the corresponding multiplexer channel control bit in the activated bank area according to the channel number. Finally, it drives the enable terminal of the level conversion chip through hardware connection to complete the hardware switching from logical address to physical link, thereby switching to the target communication channel.

[0079] Step C2: The CRC check circuit performs CRC signal integrity check on the target communication channel and generates the target communication channel activation state;

[0080] Specifically, the CRC check circuit samples the signal amplitude of the target communication channel using an ADC sampling unit. It then compares the sampled value with a preset first amplitude threshold (e.g., 3.0V) and a second amplitude threshold (e.g., 2.0V). If the signal amplitude is higher than 3.0V, a high signal identifier is generated; if it is between 2.0V and 3.3V, a medium signal identifier is generated; and if it is lower than 2.0V, a low signal identifier is generated. Subsequently, the CRC check circuit performs a second judgment based on the signal identifier. Under the high signal identifier condition, it calculates the signal jitter rate to generate a stability parameter. If the stability parameter is higher than the signal timing jitter threshold (e.g., 0.1UI), a fast check mode is generated; otherwise, a standard check mode is generated. The mode is as follows: Under medium or low signal identification, a deep check mode is directly generated; finally, the CRC check circuit performs a CRC check operation on the digital instruction data transmitted on the target communication channel according to the check mode. The sampled data is XORed with a polynomial through a shift register to generate a 16-bit check code and compare it with the pre-stored check value. If the check passes, the corresponding activation state is generated (fast check mode generates fast activation state (e.g., delay ≤ 10ns), standard check mode generates standard activation state (e.g., delay ≤ 20ns), and deep check mode generates secure activation state (e.g., delay ≤ 50ns). Finally, the generated activation state is used as the activation state of the target communication channel.

[0081] It should be noted that the first amplitude threshold and the second amplitude threshold are defined by the electrical specifications of the target communication channel. The first amplitude threshold is usually in the range of 2.0V to 3.3V (e.g., RS-232 differential voltage), and the second amplitude threshold is usually in the range of 1.5V to 2.0V (e.g., I2C high-level minimum threshold).

[0082] Step C3: The CRC check circuit detects the signal amplitude of the target communication channel, and generates a signal identifier by comparing the signal amplitude with the classification result of the preset signal timing jitter threshold.

[0083] Specifically, after the target communication channel is switched and activated by the multiplexing matrix controller, the CRC check circuit immediately starts the internal high-speed ADC sampling unit to continuously sample the voltage amplitude of the TX or SDA signal line of the target communication channel at a sampling rate of 100MHz to obtain the current steady-state level value. Then, the steady-state level value is compared with the preset first amplitude threshold and second amplitude threshold to generate a signal identifier.

[0084] Step C4: The CRC check circuit performs a secondary judgment based on the signal identifier. When the signal identifier is a high signal identifier, it generates a fast check mode and a standard check mode based on whether the stability parameter exceeds the threshold. When the signal identifier is a medium or low signal identifier, it directly generates a deep check mode.

[0085] Specifically, the CRC check circuit uses a three-layer progressive judgment logic to analyze the signal identifiers, thereby accurately selecting the check mode. The CRC check circuit performs preliminary screening on the signal identifiers generated in step C3, designating high signal identifiers as candidate signal quality state A, and marking medium and low signal identifiers as medium quality state A and low quality state A, respectively, forming the first layer of judgment results.

[0086] When the first-level judgment result is a high signal identifier, the CRC check circuit immediately activates the stability detection unit. This unit performs quantitative analysis on the signal jitter characteristics of the target communication channel within a continuous time window, calculates the standard deviation of the voltage difference between adjacent sampling points within a continuous clock cycle (e.g., 10 consecutive clock cycles), and generates stability parameter values.

[0087] The stability detection unit compares the stability parameter value with a preset stability threshold, which is typically set to 0.1 UI. UI represents a unit interval, a standard quantization unit for measuring signal timing accuracy in digital communication systems. If the stability parameter value is below 0.1 UI, it indicates that the signal has small jitter amplitude on the time axis and stable transmission quality, thus generating a stable signal verification state. If the stability parameter value is higher than or equal to 0.1 UI, it indicates that the signal has significant time-domain jitter, posing a potential threat to transmission reliability, thus generating an unstable signal verification state, thereby completing the second layer of judgment. It should be noted that the stability detection unit is a dedicated hardware analysis module integrated within the CRC check circuit. It consists of a high-precision ADC sampler, a digital signal processor, and statistical calculation logic, specifically responsible for real-time monitoring and quantification evaluation of the time-domain stability of communication signals.

[0088] After completing the first and second layer judgments, the comprehensive decision module of the CRC check circuit initiates the third layer check mode generation logic based on the combination of the first layer judgment result and the second layer verification status (unstable signal verification status or stable signal verification status). Specifically, when the first layer judgment result is a high signal identifier and the second layer judgment verification status is a stable signal verification status, the comprehensive decision module determines that the target communication channel has high-quality and stable transmission conditions and generates a fast check mode. In the fast check mode, the CRC check circuit uses a simplified 16-bit CRC algorithm, and the check processing delay is controlled within 10 nanoseconds, which is suitable for high-speed data transmission scenarios. When the first layer judgment result A is a high signal identifier but the second layer judgment verification status is an unstable signal verification status, the comprehensive decision module believes that although the signal amplitude meets the requirements, there is a risk to the transmission stability. Therefore, it generates a standard check mode, using the standard CRC-16-CCITT algorithm, which balances transmission efficiency while ensuring check accuracy. When the first layer judgment result is a medium-quality or low-quality status, the comprehensive decision module directly skips the second layer stability judgment and generates a deep check mode, enabling the enhanced CRC-32 algorithm and adding a parity check mechanism to ensure data integrity under poor-quality channels. The hardware decision unit is responsible for receiving and integrating the judgment results of the first two layers, and outputting the final verification mode selection according to the preset logical rules.

[0089] The integrated decision-making module, during the target communication channel activation process, automatically selects the most suitable CRC check strategy for the current channel conditions based on the combination of the first-layer judgment result and the second-layer verification status (unstable signal verification status or stable signal verification status), ensuring reliable transmission of control commands across different quality channels. The parity check mechanism, in the context of poor communication channels in the SoC array, adds a check bit to each byte of control command data transmitted to the target SoC node. This, combined with the CRC-32 algorithm, forms a dual data integrity verification, preventing electromagnetic interference-induced command errors from affecting the correct execution of the SoC node. Specifically, the enhanced CRC-32 algorithm addresses multi-bit transmission errors that may occur in the electromagnetic environment of large-scale SoC arrays. It optimizes the polynomial parameters and increases the number of error detection bits on the standard CRC-32, ensuring data integrity and execution accuracy of BMC control commands during forwarding through the FPGA hardware to the target SoC node.

[0090] It should be explained that the three-layer progressive judgment logic of the CRC check circuit realizes the selection of check strategy from coarse-grained to fine-grained through basic screening of signal amplitude, in-depth verification of stability parameters, and mode decision of comprehensive state.

[0091] Step C5: In deep verification mode, the CRC verification circuit performs enhanced signal sampling and double redundancy verification on the target communication channel. If the verification is successful, a secure activation state is generated. If the verification fails, an activation failure state is generated, and the secure activation state is used as the activation state of the target communication channel.

[0092] Specifically, in deep verification mode, the CRC check circuit performs 5 high-density voltage samples on the target communication channel (e.g., sampling rate 200MHz), uses a 3-to-2 majority voting mechanism to determine the final valid level value, and performs dual redundancy check on the instruction data stream at the data link layer. First, a 32-bit cyclic redundancy calculation is performed using the CRC-32C polynomial. Second, a parity check bit is added to each data byte for auxiliary verification. If both the CRC-32C check and the parity check pass, a secure active state is generated. If either check fails, a retransmission mechanism of up to 3 times is initiated (e.g., each retransmission interval is 500 microseconds). If all retransmissions still fail, an activation failure state is generated. Finally, the secure active state is used as the active state of the target communication channel.

[0093] Step C6: With the target communication channel in a secure active state, the CRC check circuit is encapsulated and converted according to the protocol of the target communication channel using control commands;

[0094] Specifically, if the target communication channel is a UART type, the FPGA-integrated hardware instruction forwarding engine adds a start bit, configurable data bits, no parity bit, and stop bit before the control instruction data, and generates precise bit timing according to the target SoC's preset baud rate. If the target communication channel is an I2C type, a start condition and a 7-bit slave address are inserted before the instruction data, an ACK acknowledgement placeholder is inserted after the data byte, and a stop condition is added at the end. The encapsulated and converted bit stream is pushed to the physical layer transceiver's transmit FIFO buffer as the final hardware-ready data subsequently passed through to the target SoC node.

[0095] Step C7: Transmit the packaged and converted control instructions to the target SoC node corresponding to the physical channel address;

[0096] Specifically, after the encapsulated and converted control command data is pushed to the transmit FIFO buffer of the physical layer transceiver, the physical layer transceiver drives the corresponding UART or I2C physical interface level conversion chip according to the hardware routing information bound to the physical channel address of the target communication channel. The encapsulated bit stream is output to the RX or SDA pin of the target SoC node in a hardware pipeline manner without software intervention, completing the physical layer pass-through of the command and finally passing the control command to the target SoC node corresponding to the physical channel address.

[0097] It should be noted that the multiplexing matrix includes a multiplexing matrix controller and a CRC check circuit.

[0098] S4. Obtain the execution status of the target SoC node and send the execution status back to the BMC.

[0099] In this invention, step S4, which involves sending the execution status back to the BMC, includes the following steps D1 to D6:

[0100] Step D1: After executing the control command, the target SoC node returns status response data through the target communication channel;

[0101] Specifically, after receiving the packaged and converted control command passed through the physical layer transceiver, the target SoC node first parses the command content and executes the corresponding operation by its internal firmware. Then, according to the communication protocol (UART or I2C) specified in the control command, it encodes the execution result into a predefined format status response data. The status response data is then returned to the corresponding target communication channel on the FPGA side according to the protocol timing through the TX pin (UART) or SDA pin (I2C) of the target communication channel, thus completing the return of status response data by the target communication channel.

[0102] Step D2: The RISC-V hard-core processor performs instruction parsing on the target SoC node status response data, obtains key status fields, and writes them into the status register group;

[0103] Specifically, after the RISC-V hard-core processor captures the status response data returned by the target SoC node from the physical layer transceiver, it loads the raw byte stream from the receive FIFO buffer into the internal general-purpose register through the AXI bus interface. Then, according to the predefined binary protocol format, it calls hardware bit field operation instructions to mask and align the bit segments at specified offset positions in the raw byte stream, accurately separating the key status fields of power status, heartbeat signal, and error code. Subsequently, the RISC-V hard-core processor writes the data into the status register group with ECC verification according to the preset address mapping of each key status field, and monitors the feedback signal of the ECC verification logic after each write to ensure that the data is written to the status register group completely and without error.

[0104] Step D3: After the data writing is completed and the ECC verification is passed, the status register group generates a valid write flag, and the RISC-V hard core processor generates the execution status of the target SoC node;

[0105] Specifically, after receiving the critical status fields written by the RISC-V hard-core processor, the status register group first performs real-time bit-level verification on the data bits and parity bits of each write address through the built-in ECC verification logic. If a single-bit error is detected, it is automatically corrected; if a multi-bit error or verification failure is detected, the write remains invalid. When all fields have been written and all ECC verifications have passed, the status register group pulls the valid write flag high on the next rising edge of the global clock. The RISC-V hard-core processor continuously monitors the valid write flag. When it detects that the flag has transitioned from low to high, it immediately reads all the verified critical status fields from the status register group and packages them into 32-bit aligned structured data blocks according to a predefined structure, ultimately generating the execution status of the target SoC node.

[0106] Step D4: Encapsulate the execution status data of the target SoC node into a PCIe TLP format data packet and inject it into the send queue by the DMA controller;

[0107] Specifically, after receiving the execution status of the target SoC node generated by the RISC-V hard core processor, the DMA controller first reads the structured status data from the status register group with ECC check according to the predefined memory address (e.g., starting address 0x5000_0000, length 16 bytes). Then, according to the PCIe transaction layer protocol specification, the DMA controller adds a 12-byte TLP packet header to the structured status data to generate a complete PCIe TLP data packet. Finally, the DMA controller writes the PCIe TLP data packet to the start address of the PCIe hard core IP core's transmit queue through the AXI bus interface and updates the transmit queue tail pointer register, triggering the hardware transmit state machine of the PCIe hard core IP core to complete the injection operation and allow the TLP data packet to enter the hardware transmit pipeline of the PCIe hard core IP core.

[0108] It should be noted that the structured status data includes the target SoC identifier, power status, heartbeat signal, and error code fields; the 12-byte TLP header includes the transaction type Memory Write, the target address BMC memory mapping region base address 0xF000_0000, the data length 16 bytes, and the TLP sequence number.

[0109] Step D5: Transmit TLP packets from the PCIe Gen3 x4 physical link to the memory-mapped area of ​​the BMC via the PCIe hard IP core, and attach a CRC-32 checksum at the data link layer;

[0110] Specifically, after receiving a complete PCIe TLP data packet injected by the DMA controller, the PCIe hard core IP core first calculates and adds a 32-bit link layer cyclic redundancy check code to the complete PCIe TLP data packet at the data link layer, generating a complete transaction packet that can be transmitted at the physical layer. Through the physical layer logic integrated in the PCIe hard core IP core, the complete transaction packet is scrambled and serialized according to the 128b / 130b encoding rules, and the serialized differential data stream corresponding to the complete transaction packet is transmitted to the memory-mapped area of ​​the BMC without software intervention through the PCIe Gen3 x4 physical link, ensuring that the TLP data packet has complete CRC-32 check protection before physical link transmission.

[0111] Step D6: Perform CRC-32 verification on the TLP data packet. After the verification is successful, parse the status data field in the TLP data packet and generate a BMC confirmation response to complete the return of the execution status of the target SoC node to the BMC.

[0112] Specifically, after receiving a TLP data packet transmitted via the PCIe Gen3 x4 physical link, the BMC management engine first extracts the 32-bit LCRC checksum at the data link layer. Then, it recalculates the CRC-32 checksum for the TLP data packet header and payload according to the PCIe protocol standard polynomial. If the calculated result is completely consistent with the received LCRC, it is determined that no bit errors occurred during the physical link transmission of the TLP data packet, and the checksum passes. The BMC management engine parses the target address field and length field in the TLP packet header to locate the start position of the data payload. It then extracts the status data field according to a predefined binary structure (e.g., the first 4 bytes are the SoC identifier, the next 4 bytes are the power status, the following 4 bytes are the heartbeat signal, and the last 4 bytes are the error code). Finally, the BMC management engine generates a BMC acknowledgment response data packet containing the ACK_SUCCESS status code, a timestamp, and the SoC identifier. This data is then written to the status acknowledgment register in the BMC memory-mapped area via the internal management bus, completing the return of the target SoC node's execution status to the BMC.

[0113] It should be noted that the PCIe hard core IP core integrates the data link layer.

[0114] This embodiment also provides a computer device applicable to the millisecond-level FPGA distributed management and control method, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the millisecond-level FPGA distributed management and control method proposed in the above embodiment.

[0115] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0116] This embodiment also provides a storage medium storing a computer program, which, when executed by a processor, implements the millisecond-level FPGA distributed control method proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0117] In summary, this invention achieves intelligent perception of physical link status and dynamic matching of verification strength by performing graded signal quality judgment and adaptive verification mode generation on the target communication channel through a CRC verification circuit, ensuring safe activation even under inferior channels, and greatly improving the communication robustness of large-scale SoC arrays in complex electromagnetic environments.

[0118] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A millisecond-level FPGA distributed management and control method, characterized in that: include, The FPGA receives control commands from the BMC via its built-in hard processor and extracts the target SoC identifier from the control commands. The target communication channel is determined by looking up the corresponding physical channel address in the address mapping table integrated in the FPGA based on the target SoC identifier. The target communication channel is activated by the multiplexing matrix integrated in the FPGA, and the control command is transparently transmitted to the corresponding target SoC node; Obtain the execution status of the target SoC node and send the execution status back to the BMC; The multiplexing matrix includes a multiplexing matrix controller and a CRC check circuit; The activation of the target communication channel via the FPGA-integrated multiplexing matrix includes, The multiplexing matrix controller switches to the target communication channel according to the physical channel address; The CRC check circuit performs CRC signal integrity check on the target communication channel and generates the target communication channel activation state. The target communication channel activation status is an activated target communication channel, including: The CRC check circuit detects the signal amplitude of the target communication channel and generates a signal identifier by comparing the signal amplitude with the classification result of the preset signal timing jitter threshold. The CRC check circuit performs a secondary judgment based on the signal identifier. When the signal identifier is a high signal identifier, it generates a fast check mode and a standard check mode respectively based on whether the stability parameter exceeds the signal timing jitter threshold. When the signal identifier is a medium or low signal identifier, it directly generates a deep check mode. In the deep verification mode, the CRC verification circuit performs enhanced signal sampling and dual redundancy verification on the target communication channel. If the verification is successful, a secure activation state is generated; if the verification fails, an activation failure state is generated, and the secure activation state is used as the activation state of the target communication channel.

2. The millisecond-level FPGA distributed management and control method as described in claim 1, characterized in that: The FPGA's built-in hard processor includes a PCIe hard core IP core and a RISC-V hard core processor. The FPGA also integrates an AXI bus interface, a DMA buffer, and a CRC check circuit. After receiving control commands from the BMC through the FPGA's built-in hard core processor, the process further includes... The PCIe hard core IP core parses the data link layer protocol of the control command, and the AXI bus interface writes the parsed control command into the DMA buffer. If the write handshake signal of the AXI bus interface is detected as successful, a DMA buffer write completion status is generated; If the write handshake signal of the AXI bus interface fails to be detected, a DMA buffer write failure status is generated. When the DMA buffer is written, the CRC verification circuit performs a CRC integrity check on the parsed control command in the DMA buffer, and generates a control command that has passed the check if the CRC integrity check passes.

3. The millisecond-level FPGA distributed management and control method as described in claim 2, characterized in that: The steps for extracting the target SoC identifier from the control command are as follows: The RISC-V hard core processor parses and verifies the control instructions that have passed verification, and then disassembles the verified control instructions using the hardware bit field operation instructions of the RISC-V hard core processor to extract the target SoC identifier.

4. The millisecond-level FPGA distributed management and control method as described in claim 3, characterized in that: The address mapping table includes a storage interface and address decoding logic; the step of finding the corresponding physical channel address in the address mapping table integrated in the FPGA based on the target SoC identifier to determine the target communication channel includes, The RISC-V hard core processor accesses the address mapping table based on the target SoC identifier and generates an address mapping table query request. The storage interface of the address mapping table reads the mapping relationship between the target SoC identifier and the storage location of the address mapping table according to the address mapping table query request, and generates the physical channel address; The address decoding logic of the address mapping table determines the target communication channel by parsing the correspondence between the target SoC identifier and the storage location of the address mapping table based on the physical channel address.

5. The millisecond-level FPGA distributed management and control method as described in claim 4, characterized in that: The steps for transmitting the control command to the corresponding target SoC node are as follows: When the target communication channel is in a secure active state, the CRC check circuit is encapsulated and converted according to the protocol of the target communication channel through control commands; The control command, after being packaged and converted, is passed through to the target SoC node corresponding to the physical channel address.

6. The millisecond-level FPGA distributed management and control method as described in claim 5, characterized in that: The steps for obtaining the execution status of the target SoC node are as follows: After executing the control command, the target SoC node returns status response data through the target communication channel; The RISC-V hard-core processor parses the status response data of the target SoC node, obtains key status fields, and writes them into the status register group. After the data writing is completed and the ECC verification is passed, the status register group generates a valid write flag, and the RISC-V hard core processor generates the execution status of the target SoC node.

7. The millisecond-level FPGA distributed management and control method as described in claim 6, characterized in that: The steps for sending the execution status back to the BMC are as follows: The PCIe hard core IP core integrates a data link layer; it encapsulates the execution status data of the target SoC node into PCIeTLP format data packets, which are then injected into the transmission queue by the DMA controller; The TLP format data packet is transmitted from the PCIe Gen3 x4 physical link to the memory-mapped area of ​​the BMC via the PCIe hard core IP core, and a CRC-32 checksum is added at the data link layer. The TLP format data packet is subjected to CRC-32 verification. After the verification is successful, the status data field in the TLP format data packet is parsed to generate a BMC confirmation response, so as to complete the backhaul of the execution status of the target SoC node to the BMC.

8. A millisecond-level FPGA distributed management and control system, based on the millisecond-level FPGA distributed management and control method according to any one of claims 1 to 7, characterized in that: include, The instruction parsing module is used to receive control instructions from the BMC through the FPGA's built-in hard core processor and extract the target SoC identifier from the control instructions; The address mapping module is used to look up the corresponding physical channel address in the address mapping table integrated in the FPGA based on the target SoC identifier, and determine the target communication channel; The channel switching module is used to activate the target communication channel through the multiplexing matrix integrated in the FPGA and to transmit the control command to the corresponding target SoC node. The feedback module is used to obtain the execution status of the target SoC node and feedback the execution status to the BMC.

Images