Multi-protocol industrial ethernet co-processing method and related apparatus

Abstract

The application is suitable for the technical field of industrial Ethernet communication, and provides a multi-protocol industrial Ethernet coprocessing method and related device, which comprises the following steps: field extraction is performed on an accessed first Ethernet frame, a first protocol type identifier is determined and reported, and a switching trigger signal is generated; a corresponding configuration bit stream is called, the configuration bit stream is written into a target reconfigurable partition, and a reconfiguration completion signal is generated; a second protocol analysis pipeline instance for completion state recovery is generated according to the reconfiguration completion signal, and the first Ethernet frame and the second Ethernet frame temporarily stored in an input frame buffer FIFO are sent into the second protocol analysis pipeline instance for continuous processing. The application realizes the effect of replacing multiple ASIC chips with a single FPGA chip to complete multi-protocol support, and solves the technical problems of state loss and communication interruption caused by local reconfiguration of the FPGA in the protocol switching process in the prior art.

Description

Technical Field

[0001] This invention relates to the field of industrial Ethernet communication technology, and in particular to a multi-protocol industrial Ethernet coprocessing method and related apparatus. Background Technology

[0002] To adapt to different customer and market demands, industrial automation equipment often needs to simultaneously support multiple industrial real-time Ethernet protocols such as EtherCAT, Profinet, EPA, and Ethernet / IP. Currently, ASIC-based dedicated chip solutions embed protocol parsing logic onto silicon wafers, requiring multiple chips to support multiple protocols, resulting in significant cost and board area overhead. Software protocol stack solutions consume main CPU processing resources, competing with real-time control tasks and failing to meet hardware-level forwarding latency requirements.

[0003] To balance hardware performance and protocol switching flexibility, existing technologies employ FPGA partial reconfiguration, which enables field switching of hardware logic by loading configuration bitstreams for different protocols during device operation. However, in existing technologies, FPGA partial reconfiguration operations clear the contents of all registers and distributed storage units within the reconfigured area. If operational status data such as address counts, phase counts, and message sequence numbers generated during protocol parsing are stored within the reconfigured area, this data will inevitably be lost after reconfiguration. Furthermore, if the reconfiguration operation occurs while a frame is being parsed or forwarded, it will directly cause that frame to be truncated or lost. This results in communication interruptions after protocol switching, requiring reconnection and resynchronization, and compromising the continuity of fieldbus communication. Summary of the Invention

[0004] This invention provides a multi-protocol industrial Ethernet coprocessing method and related apparatus, which solves the technical problem of state loss and communication interruption caused by FPGA local reconfiguration during protocol switching in the prior art.

[0005] In a first aspect, embodiments of this application provide a multi-protocol industrial Ethernet coprocessing method, including: S100: Extract fields from the first Ethernet frame that is received, determine the first protocol type identifier, and report it; S200: Compare the current count value of the global time base counter with the time slot start time in the protocol switching schedule table and generate a switching trigger signal by combining it with the first protocol type identifier; S300: Retrieve the corresponding configuration bit stream according to the switching trigger signal, write the configuration bit stream into the target reconfigurable partition and generate a reconfiguration completion signal; S400: Based on the reconfiguration completion signal, generate a second protocol parsing pipeline instance that has completed the state recovery, and send the first Ethernet frame and the second Ethernet frame temporarily stored in the input frame buffer FIFO into the second protocol parsing pipeline instance for further processing.

[0006] Optionally, in a first implementation of the first aspect of the present invention, S100: extracting fields from the accessed first Ethernet frame, determining the first protocol type identifier, and reporting it, including: S101: Extract fields from the first Ethernet frame that is received to obtain field data; S102: Perform bitwise mask comparison and priority encoding reduction processing on the field data and multiple sets of mask matching rules to determine the first protocol type identifier and determine whether the first protocol parsing pipeline instance corresponding to the first protocol type identifier has been loaded. S103: If loaded, the first Ethernet frame is distributed to the first protocol parsing pipeline instance; if not loaded, the first Ethernet frame is written into the input frame buffer FIFO and the first protocol type identifier is reported. A second Ethernet frame that arrives before the first protocol parsing pipeline instance is loaded and whose protocol type is the same as the first protocol type identifier is synchronously written into the input frame buffer FIFO.

[0007] Optionally, in a second implementation of the first aspect of the present invention, S200: comparing the current count value of the global time base counter with the time slot start time in the protocol handover scheduling table and combining it with the first protocol type identifier to generate a handover trigger signal, including: S201: Compare the current count value of the global time base counter with the time slot start time in the protocol switching schedule table and combine it with the first protocol type identifier to determine whether a protocol switch is required; S202: If a protocol switch is required, a freeze request is sent to the first protocol parsing pipeline instance, and after the frame in transit flag state machine returns an idle confirmation signal, a switch trigger signal is generated. The switch trigger signal carries a second protocol type identifier, a first number of the target reconfigurable partition, and a second number of the target state holding register group.

[0008] Optionally, in a third implementation of the first aspect of the present invention, S300: retrieving the corresponding configuration bitstream according to the switching trigger signal, writing the configuration bitstream into the target reconfigurable partition and generating a reconfiguration completion signal, including: S301: Based on the second protocol type identifier and the first number carried by the switching trigger signal, retrieve the configuration bit stream from the protocol configuration library that only covers the protocol parsing logic within the target reconfigurable partition; S302: Based on the configuration bitstream, drive the bus macro decoupling circuit at the boundary between the target reconfigurable partition and the static logic region and clamp the boundary signal to a predefined level; write the configuration bitstream into the target reconfigurable partition through the internal configuration access port. S303: When the configuration bit stream is written, determine that the target reconfigurable partition has completed local reconfiguration, release the boundary signal clamp, and generate a reconfiguration completion signal.

[0009] Optionally, in the fourth implementation of the first aspect of the present invention, S303: when the configuration bitstream is written, it is determined that the target reconfigurable partition has completed local reconfiguration, the boundary signal clamp is released and a reconfiguration completion signal is generated, including: When the configuration bitstream is written, the internal registers of the target reconfigurable partition are restored to their initial state, local reconfiguration is completed, and the boundary signal clamping is released. Based on the target reconfigurable partition that has completed partial reconfiguration, a reconfiguration completion signal is generated, carrying the second protocol type identifier and the second number of the target state holding register group.

[0010] Optionally, in a fifth implementation of the first aspect of the present invention, S400: The second protocol parsing pipeline instance is restored to its state based on the reconfiguration completion signal, and the first Ethernet frame and the second Ethernet frame temporarily stored in the input frame buffer FIFO are sent to the second protocol parsing pipeline instance for further processing, including: S401: Read the corresponding protocol operation status data according to the second number of the target state holding register group carried by the reconfiguration completion signal; S402: Write the protocol running status data into the corresponding status register position in the target reconfigurable partition after the local reconfiguration is completed, to obtain the second protocol parsing pipeline instance that has completed state recovery; S403: Read out the first Ethernet frame and the second Ethernet frame temporarily stored in the input frame buffer FIFO frame by frame in the order of arrival, and send them to the second protocol parsing pipeline instance for further processing. After all the temporarily stored Ethernet frames have been read out, return to step S100.

[0011] Secondly, embodiments of this application provide a multi-protocol industrial Ethernet coprocessing device, comprising: The identification and reporting module is used to extract fields from the first Ethernet frame that is accessed, determine the first protocol type identifier, and report it. The switching module is used to compare the current count value of the global time base counter with the time slot start time in the protocol switching schedule table and generate a switching trigger signal by combining the first protocol type identifier; The reconfiguration module is used to retrieve the corresponding configuration bit stream according to the switching trigger signal, write the configuration bit stream into the target reconfigurable partition, and generate a reconfiguration completion signal. The state recovery module is used to generate a second protocol parsing pipeline instance that has completed state recovery based on the reconfiguration completion signal, and to send the first Ethernet frame and the second Ethernet frame temporarily stored in the input frame buffer FIFO into the second protocol parsing pipeline instance for further processing.

[0012] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described multi-protocol industrial Ethernet coprocessing method.

[0013] Fourthly, embodiments of this application provide a readable storage medium storing a computer program that, when executed by a processor, implements the steps of the aforementioned multi-protocol industrial Ethernet coprocessing method.

[0014] Fifthly, embodiments of this application provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the above-described multi-protocol industrial Ethernet coprocessing method.

[0015] In one scheme provided by the aforementioned multi-protocol industrial Ethernet coprocessing method and related apparatus, the determination and distribution judgment of the first protocol type identifier are completed at the hardware level by performing parallel comparison and priority encoding reduction of the field data of the first Ethernet frame with multiple sets of mask matching rules, thus avoiding the occupation of main CPU resources by the software protocol stack's field-by-field serial parsing. Switching judgment is made by combining the comparison result of the global time base counter and the protocol switching schedule table with the first protocol type identifier. After determining that a switch is needed, reconfiguration is not directly triggered. Instead, a freeze request is first sent to the currently running first protocol parsing pipeline instance. A switching trigger signal is only generated after the frame in transit flag state machine returns an idle confirmation signal. This avoids the reconfiguration operation interrupting the transmission process of frames being processed, solving the frame loss problem caused by direct switching at time slot boundaries in existing FPGA reconfiguration schemes. This invention only retrieves the configuration bit stream of the protocol parsing logic within the reconfigurable partition of the coverage target and clamps the boundary signals with a bus macro decoupling circuit, ensuring that the local reconfiguration process does not affect the normal operation of other functional modules within the static logic area. This achieves the effect of using a single FPGA chip to replace multiple ASIC chips to support multiple protocols. By externally storing the protocol running status data in the status holding register group, and generating a second protocol parsing pipeline instance with completed status recovery based on the protocol running status data after reconfiguration, the first Ethernet frame and the second Ethernet frame temporarily stored in the input frame buffer FIFO are sent to the second protocol parsing pipeline instance in the order of arrival for further processing. This ensures that the running status before and after the protocol switch remains continuous and that frame data is not lost, thus solving the technical problem of status loss and communication interruption caused by partial reconfiguration of FPGA during protocol switching in the prior art. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. 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.

[0017] Figure 1 This is a schematic diagram of a multi-protocol industrial Ethernet coprocessing system according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a multi-protocol industrial Ethernet coprocessing method according to an embodiment of the present invention; Figure 3 yes Figure 2 A schematic diagram of the implementation process of step S100; Figure 4 yes Figure 2 A schematic diagram of the implementation process of step S200; Figure 5 yes Figure 2 A schematic diagram of the implementation process of step S300; Figure 6 yes Figure 2 A schematic diagram of the implementation process of step S400; Figure 7 This is a schematic diagram of a multi-protocol industrial Ethernet coprocessor in one embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. It should also be understood that, as used in this specification and the appended claims, the term "and / or" refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0020] Furthermore, in the description of this invention and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0021] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of the invention include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0022] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0023] To illustrate the technical solution of the present invention, specific embodiments are described below.

[0024] To address the problems mentioned above in the background technology, this application proposes a multi-protocol industrial Ethernet coprocessing method and related apparatus. The multi-protocol industrial Ethernet coprocessing method provided by this invention can be applied to applications such as... Figure 1 The multi-protocol industrial Ethernet coprocessing system shown includes a client and a server.

[0025] In one embodiment, such as Figure 2 As shown, a multi-protocol industrial Ethernet coprocessing method is provided, which is applied to... Figure 1 Taking a multi-protocol industrial Ethernet coprocessing system as an example, the following steps are included: S100: Extract fields from the first Ethernet frame that is received, determine the first protocol type identifier, and report it; S200: Compare the current count value of the global time base counter with the time slot start time in the protocol switching schedule table and generate a switching trigger signal by combining it with the first protocol type identifier; S300: Retrieves the corresponding configuration bit stream according to the switching trigger signal, writes the configuration bit stream to the target reconfigurable partition and generates a reconfiguration completion signal; S400: Generate a second protocol parsing pipeline instance that has completed state recovery based on the reconfiguration completion signal, and send the first Ethernet frame and the second Ethernet frame temporarily stored in the input frame buffer FIFO into the second protocol parsing pipeline instance for further processing.

[0026] In this embodiment, by performing parallel comparison and priority encoding reduction of the field data of the first Ethernet frame with multiple sets of mask matching rules, the determination and distribution judgment of the first protocol type identifier are completed at the hardware level, avoiding the occupation of main CPU resources by the software protocol stack's serial parsing of each field. Switching judgment is made by combining the comparison result of the global time base counter and the protocol switching schedule table with the first protocol type identifier. After determining that a switch is needed, reconfiguration is not directly triggered. Instead, a freeze request is first sent to the currently running first protocol parsing pipeline instance. A switching trigger signal is only generated after the frame in transit flag state machine returns an idle confirmation signal. This avoids the reconfiguration operation interrupting the transmission process of frames being processed, solving the frame loss problem caused by direct switching at time slot boundaries in existing FPGA reconfiguration schemes. This invention only retrieves the configuration bit stream of the protocol parsing logic within the reconfigurable partition of the coverage target and clamps the boundary signals using a bus macro decoupling circuit, ensuring that the local reconfiguration process does not affect the normal operation of other functional modules within the static logic area. This achieves the effect of using a single FPGA chip to replace multiple ASIC chips to support multiple protocols. By externally storing the protocol running status data in the status holding register group, and generating a second protocol parsing pipeline instance with completed status recovery based on the protocol running status data after reconfiguration, the first Ethernet frame and the second Ethernet frame temporarily stored in the input frame buffer FIFO are sent to the second protocol parsing pipeline instance in the order of arrival for further processing. This ensures that the running status before and after the protocol switch remains continuous and that frame data is not lost, thus solving the technical problem of status loss and communication interruption caused by partial reconfiguration of FPGA during protocol switching in the prior art.

[0027] In one embodiment, such as Figure 3 As shown, step S100: Extract fields from the first Ethernet frame that has been received, determine the first protocol type identifier, and report it, including: S101: Extract fields from the first Ethernet frame that is received to obtain field data; S102: Perform bitwise mask comparison and priority encoding reduction on the field data with multiple sets of mask matching rules to determine the first protocol type identifier and determine whether the first protocol parsing pipeline instance corresponding to the first protocol type identifier has been loaded; S103: If loaded, the first Ethernet frame is distributed to the first protocol parsing pipeline instance; if not loaded, the first Ethernet frame is written into the input frame buffer FIFO and the first protocol type identifier is reported. The second Ethernet frame that arrives before the first protocol parsing pipeline instance is loaded and whose protocol type is the same as the first protocol type identifier is synchronously written into the input frame buffer FIFO.

[0028] In this embodiment, after the first Ethernet frame enters the FPGA, the frame synchronization logic detects the preamble and start delimiter. After confirming that the frame boundary is valid, the destination MAC address, source MAC address, EtherType field, VLAN tag, and the first few bytes of the necessary payload in the frame header are latched in parallel into the field extraction register to form field data. The field extraction is completed within the hardware clock cycle through fixed offset data retrieval, shift alignment, and register concatenation to ensure that identification and distribution do not introduce software interrupt load. The field data is fed into a rule matching array formed by multiple sets of mask matching rules. Each set of rules includes at least a matching field, a mask field, a protocol type identifier, and a priority field. During matching, the field data is first processed by bitwise masking, and then compared with the expected value in the rule. If multiple rules match simultaneously, a unique first protocol type identifier is reduced according to a preset priority by a priority encoder. For example, a message with EtherType 0x88A4 can be identified as an EtherCAT message, a message with EtherType 0x8892 can be identified as a Profinet real-time message, and a message with EtherType 0x88F7 can be identified as a time synchronization message and sent to the synchronization auxiliary processing path. Messages that conform to the EPA protocol preset frame type field, vendor extension field, or payload characteristic field are identified as EPA messages. Messages with EtherType 0x0800 and IP protocol field, TCP or UDP port are identified as EPA messages. Packets that match both the Ethernet type field and the CIP packet feature field are identified as Ethernet / IP packets. If neither matches, the standard Ethernet default processing path is entered. When an EtherType match requires a secondary matching rule, the transport layer port field is located based on the VLAN tag length, IP header length field, and transport layer protocol field. The port field is then compared with the port matching rule to avoid misjudgment based solely on the Ethernet type field. To support online rule updates without interrupting ongoing comparisons, this embodiment stores multiple sets of mask matching rules in the currently active rule table and configures a shadow rule table with the same structure. When the main CPU sends rule update data through the high-speed bus interface, it first writes to the shadow rule table. After the current field comparison enters an idle period, the rule table selection signal is switched, making the shadow rule table the new currently active rule table, thus ensuring that rule updates do not disrupt the first Ethernet frame being processed. After determining the first protocol type identifier, the protocol parsing pipeline instance load status table is queried. This load status table is represented by the valid flag bits, reconfigurable partition number, and status holding register group number corresponding to each protocol type.

[0029] In this embodiment, if the first protocol parsing pipeline instance corresponding to the first protocol type identifier is already loaded and running effectively, the distribution router sends the complete first Ethernet frame along with the protocol type identifier, arrival timestamp, and port number to the pipeline instance, enabling it to continue performing frame header parsing, address matching, data extraction, FCS verification, status update, output buffering, and forwarding or reporting. If the loading status table shows that the pipeline instance corresponding to the protocol has not yet been loaded, the first Ethernet frame is written to the input frame buffer FIFO, and the first protocol type identifier is reported to the handover control logic, so that the protocol handover scheduling can retrieve the corresponding configuration bitstream and load the target reconfigurable partition based on the protocol type identifier. To ensure the continuity of the same protocol frame sequence, the frame preprocessing engine continues to identify subsequent incoming frames before the first protocol parsing pipeline instance is fully loaded. All second Ethernet frames with the same protocol type as the first protocol type identifier are synchronously written into the same input frame buffer FIFO, and their frame order is preserved according to arrival order, preventing later-arriving frames from bypassing earlier-arriving frames into the pipeline. For frames with different protocol types, immediate distribution, writing to other protocol buffer queues, or entering the default path can be performed depending on whether their corresponding pipeline is already loaded, thus avoiding mutual blocking between different protocols. In this embodiment, the FIFO works in conjunction with the switching window control. During protocol loading, newly arriving frames are absorbed. After loading is complete and the state is restored, the read controller outputs frames one by one to the newly generated protocol parsing pipeline instance in a first-in-first-out order. This avoids frame truncation or loss during FPGA local reconfiguration and ensures that the first Ethernet frame temporarily stored before switching and the second Ethernet frame arriving during switching can continue to be processed after the protocol operation state is restored.

[0030] In this embodiment, when the hit flag output by the bitmask comparison processing indicates that the EtherType field corresponding to the field data hits a preset secondary matching rule, the offset address of the target transport layer port field is calculated based on the IP header length field in the field data; deep field extraction processing is performed on the first Ethernet frame based on the offset address to obtain the target transport layer port field; the target transport layer port field is compared with the preset port matching rule to obtain the secondary hit flag; the first protocol type identifier is determined based on the secondary hit flag; when the secondary hit flag does not hit any port matching rule, the first protocol type identifier is determined to be the standard Ethernet protocol type according to the preset default rule, and the first protocol type identifier is passed to S103 for distribution judgment.

[0031] In this embodiment, multiple sets of mask matching rules are stored in the current active rule table formed by distributed RAM. S102 further includes: receiving rule update data sent by the main CPU, writing the rule update data into a shadow rule table with the same structure as the current active rule table, and the writing process of the shadow rule table does not occupy the read port of the current active rule table for bit-mask comparison processing; after the shadow rule table is written, it is determined whether the comparison processing is in an idle period based on whether there is field data currently performing bit-mask comparison processing; when it is determined to be in an idle period, the rule table selection signal is switched from pointing to the current active rule table to pointing to the shadow rule table, and the shadow rule table is determined as the new current active rule table for the field data of the subsequently accessed first Ethernet frame to perform bit-mask comparison processing.

[0032] In one embodiment, such as Figure 4 As shown, step S200: Compare the current count value of the global time base counter with the time slot start time in the protocol handover scheduling table and generate a handover trigger signal by combining it with the first protocol type identifier, including: S201: Compare the current count value of the global time base counter with the time slot start time in the protocol switching schedule table and combine it with the first protocol type identifier to determine whether a protocol switch is required; S202: If a protocol switch is required, a freeze request is sent to the first protocol parsing pipeline instance, and after the frame in transit flag state machine returns an idle confirmation signal, a switch trigger signal is generated. The switch trigger signal carries the second protocol type identifier, the first number of the target reconfigurable partition, and the second number of the target state holding register group.

[0033] In this embodiment, a global time base counter, a protocol switching schedule table, a protocol instance loading status table, a time slot arbiter, and a frame in-transit flag state machine are set within the static logic area of ​​the FPGA. This allows protocol switching decisions to be completed automatically under hardware clock ticks, without relying on the real-time participation of the main CPU. The global time base counter is calibrated by a distributed clock synchronization mechanism and is used to indicate the current communication cycle position of the coprocessor. The protocol switching schedule table is pre-configured by the main CPU according to the protocol combinations, port bandwidth requirements, and communication cycles that the device needs to support. Each entry includes the time slot start time, time slot end condition, target protocol type, target reconfigurable partition number, and target state holding register group number. The current count value of the global time base counter is compared with the time slot start time in the protocol switching schedule table. When the current count value reaches or exceeds the time slot boundary corresponding to a certain entry, the time slot arbitrator reads the target protocol type recorded in that entry and makes a joint judgment with the target protocol type, the first protocol type identifier, and the currently loaded protocol type. If the protocol parsing pipeline instance corresponding to the first protocol type identifier has been loaded and the current time slot still allows the protocol to continue processing, no switching request is generated, and the current pipeline operation is maintained. If the protocol parsing pipeline instance corresponding to the first protocol type identifier has not been loaded, or the protocol switching schedule table indicates that the next time slot should enter another protocol processing window, and the target protocol is inconsistent with the currently loaded protocol, then it is determined that a protocol switching is required, and the target protocol is identified as the second protocol type identifier. To avoid conflicts caused by multiple ports or multiple unloaded protocols simultaneously requesting the same target reconfigurable partition, this embodiment introduces a request queue and arbitration rules in the judgment phase. When multiple candidate target protocols simultaneously meet the switching conditions, the protocol that is uniquely qualified for switching is determined based on the remaining time limit, the real-time level of the protocol, and the port's preset arbitration priority. The remaining requests are temporarily stored in the waiting queue and will be processed according to priority after the current switching process is completed.

[0034] In this embodiment, if a protocol switch is required, a freeze request is sent to the currently running first protocol parsing pipeline instance. The freeze request prevents the pipeline from receiving new Ethernet frames and requires it to complete the frame header parsing, address matching, data extraction, FCS verification, output buffering, and forwarding processes that have already entered the pipeline. Simultaneously, newly arriving frames belonging to the protocol to be switched continue to be written into the input frame buffer FIFO, while frames belonging to other processable protocols enter the corresponding path according to their loading status, thus preventing frame order disorder before and after the switch. The frame in-transit flag state machine continuously monitors the input valid flag, the valid flags of each stage of the pipeline register, the output buffer occupancy flag, and the forwarding completion flag within the first protocol parsing pipeline instance. Only when all these flags indicate that there are no frames being parsed, verified, output, or waiting to be forwarded will an idle acknowledgment signal be returned. If there are still frames in the in-transit state, the freeze waiting state is maintained, ensuring that the output frame is transmitted completely without being truncated by partial reconfiguration. Upon receiving the idle confirmation signal, the time slot arbiter generates a switching trigger signal, which encapsulates a second protocol type identifier, a first number of the target reconfigurable partition, and a second number of the target state holding register group. The second protocol type identifier is used to retrieve the corresponding configuration bitstream from the protocol configuration library, the first number indicates the FPGA reconfigurable region that needs to be written to the configuration bitstream, and the second number indicates which group of state holding registers to read or write the protocol running status data from.

[0035] In this embodiment, S201 includes: when multiple candidate target protocol type identifiers corresponding to multiple time slot boundaries simultaneously meet the switching conditions, or when multiple protocol type identifiers of instances that have not been loaded with the corresponding protocol parsing pipeline reported in S100 exist simultaneously, priority weighting is assigned to each candidate target protocol type identifier according to the remaining time limit and preset protocol real-time level, to obtain the priority weight corresponding to each candidate target protocol type identifier; the candidate target protocol type identifiers are sorted according to the priority weight to obtain the candidate target protocol type identifier with the highest priority, which is determined as the second protocol type identifier to enter S202; the remaining candidate target protocol type identifiers with a priority lower than the second protocol type identifier in the sorting process are written into the switching request queue; after the protocol switching process corresponding to the switching trigger signal generated in S202 is completed, the next switching trigger signal is generated according to the priority order recorded in the switching request queue.

[0036] In this embodiment, when at least two ports in the multi-port industrial Ethernet physical layer interface receive synchronization messages from different network masters, frequency offset and phase offset corrections are performed on the local counters corresponding to each port according to the timestamp carried by the synchronization messages corresponding to each port, to obtain the current count value of the independent global time base counter corresponding to each port; the current count value of the independent global time base counter corresponding to each port is compared with the time slot start time in the protocol switching schedule table corresponding to each port to obtain the protocol switching demand signal corresponding to each port; when the protocol switching demand signals corresponding to at least two ports simultaneously point to the same target reconfigurable partition, the target port that uniquely obtains the right to use the target reconfigurable partition is determined according to the preset arbitration priority of the port corresponding to each protocol switching demand signal, and the protocol switching demand signal corresponding to the target port is transmitted to S202 to generate a switching trigger signal, while the protocol switching demand signals corresponding to the remaining ports are written into the waiting queue.

[0037] In one embodiment, such as Figure 5 As shown, step S300: Retrieve the corresponding configuration bitstream according to the switching trigger signal, write the configuration bitstream to the target reconfigurable partition, and generate a reconfiguration completion signal, including: S301: Based on the second protocol type identifier and the first number carried by the switching trigger signal, retrieve the configuration bit stream from the protocol configuration library that only covers the protocol parsing logic within the target reconfigurable partition; S302: Based on the configuration bit stream, drive the bus macro decoupling circuit at the boundary between the target reconfigurable partition and the static logic region and clamp the boundary signal to a predefined level. Write the configuration bit stream to the target reconfigurable partition through the internal configuration access port. S303: When the configuration bitstream is written, determine that the target reconfigurable partition has completed local reconfiguration, release the boundary signal clamp, and generate a reconfiguration completion signal.

[0038] In this embodiment, after receiving the switching trigger signal, the reconfiguration controller parses the fields of the switching trigger signal to obtain a second protocol type identifier and a first number of the target reconfigurable partition. The second protocol type identifier is used to determine the target industrial Ethernet protocol parsing logic to be loaded this time, and the first number is used to determine the reconfigurable partition inside the FPGA that needs to perform local reconfiguration. The protocol configuration library pre-stores configuration bitstreams corresponding to protocols such as EtherCAT, Profinet, EPA, and Ethernet / IP. Each configuration bitstream is bound to a protocol type identifier, a reconfigurable partition number, a configuration version identifier, and a configuration frame address range. Therefore, the reconfiguration controller uses the second protocol type identifier and the first number as a joint index to query the protocol configuration library, and only retrieves the configuration bitstream that matches both the target protocol and the target reconfigurable partition, without loading the complete configuration file covering the entire FPGA. To reduce the amount of data written and shorten the switching window, the configuration version identifier of the currently loaded protocol in the target reconfigurable partition is read before retrieval. This identifier is then compared with the target configuration version identifier corresponding to the second protocol type identifier to determine the configuration frame address. If only a portion of the configuration frames differ, the differential configuration bitstream covering only the differential configuration frame address range is retrieved first. If the versions are incompatible or the differential information is missing, the complete local configuration bitstream covering only the protocol parsing logic within the target reconfigurable partition is retrieved. This ensures that the reconfiguration scope is always limited to the target reconfigurable partition where the protocol parsing logic is located, without affecting static logic areas such as the multi-port physical layer interface, frame preprocessing engine, input frame buffer FIFO, global time base counter, state holding register group, and main CPU bus interface.

[0039] In this embodiment, the reconfiguration controller sends a decoupling enable signal to the bus macro decoupling circuit at the boundary of the target reconfigurable partition. This temporarily disconnects the logical coupling between the data bus, control bus, handshake signal, valid signal, and return status signal between the target reconfigurable partition and the static logic region. The boundary signal is clamped to a predefined level, which is set to logic low level 0. This ensures that the static logic region does not receive uncertain transition signals during local reconfiguration and does not misjudge invalid protocol processing results output by the target reconfigurable partition. Simultaneously, the input side of the target reconfigurable partition is kept in a write-prohibited or input-invalid state, while the output side is kept in an output-invalid, output-ready-not-set, or bus-idle state. This maintains the stability of the external interface timing during reconfiguration. After decoupling and clamping are completed, the internal configuration access port control unit initiates the write process according to the address sequence and data sequence of the configuration bit stream. The configuration frame address, configuration command, and configuration data are sequentially sent to the internal configuration access port. During the write process, the busy / idle status, write completion status, and error status are monitored. If the internal configuration access port is busy, the subsequent configuration data input is paused and the current address pointer is maintained. The write process continues after the port is restored to a writable state. If a configuration frame verification error, address out of bounds, or write timeout is detected, the reconfiguration is stopped and an abnormal status is returned to the switching control logic to prevent the target reconfigurable partition from continuing to participate in protocol processing after loading incomplete logic. To meet the continuity requirements of industrial real-time communication, the configuration writing process is incorporated into a preset switching window constraint and works in conjunction with the input frame buffer FIFO to ensure that target protocol frames arriving during the switching period first enter the buffer instead of directly entering the pipeline that has not yet been loaded. The preset switching window is determined based on the configuration bitstream data volume, the effective write bandwidth of the internal configuration access port, decoupling control overhead, local reset overhead, and configuration verification overhead. When the expected configuration writing duration does not meet the preset switching window constraint, the switching control logic is postponed to the next switchable time slot for reconfiguration, or a pre-generated and compatibility-verified differential local configuration bitstream is retrieved for writing. The reconfiguration status monitoring unit continuously monitors the last frame write flag of the configuration bitstream, the internal configuration access port completion flag, and the configuration verification result. When the entire configuration bitstream is written without errors, it determines that the target reconfigurable partition has completed partial reconfiguration and restores the internal registers of the target reconfigurable partition to their initial state. This puts the newly loaded protocol parsing logic in an acceptable state but not yet in a waiting state to process buffered frames. Subsequently, the reconfiguration controller removes the decoupling enable signal of the bus macro decoupling circuit, releases the boundary signal clamp, and allows the target reconfigurable partition to re-establish a stable connection with the static logic region. After the boundary signal is resynchronized, a reconfiguration completion signal is generated. The reconfiguration completion signal carries the second protocol type identifier and the second number of the target state holding register group.

[0040] In this embodiment, based on the current configuration version identifier corresponding to the currently loaded protocol of the target reconfigurable partition, the target configuration version identifier corresponding to the second protocol type identifier is subjected to configuration frame address comparison processing to obtain differential configuration frame address ranges with differences; based on the differential configuration frame address ranges, a differential configuration bitstream covering only the differential configuration frame address ranges is retrieved from the protocol configuration library as the configuration bitstream to be written to the target reconfigurable partition; the data volume corresponding to the differential configuration bitstream is compared with the preset complete configuration bitstream data volume to obtain the write data volume reduction result, and the differential configuration bitstream is passed to S302 for write processing.

[0041] In one embodiment, step S303: When the configuration bitstream writing is complete, determine that the target reconfigurable partition has completed local reconfiguration, release the boundary signal clamp, and generate a reconfiguration completion signal, including: When the configuration bitstream writing is complete, the internal registers of the target reconfigurable partition are restored to their initial state, local reconfiguration is completed, and the boundary signal clamping is released. Based on the target reconfigurable partition that has completed local reconfiguration, a reconfiguration completion signal is generated, carrying a second protocol type identifier and a target state holding register group number.

[0042] In this embodiment, when the configuration bitstream is written, the reconfiguration controller reads the write completion flag and configuration verification flag returned by the internal configuration access port to confirm that all configuration frames corresponding to the target reconfigurable partition have been written and no abnormalities such as address out of bounds, frame verification failure, or write timeout have occurred. Then, a partial reset control signal is sent to the target reconfigurable partition to restore the frame synchronization register, field parsing register, state machine register, address matching register, FCS verification register, output buffer control register, and handshake flag register in the newly loaded protocol parsing logic to the preset initial state. After the partial reset is maintained for several working clock cycles, the partial reset is released, allowing the target reconfigurable partition to enter a waiting state where it can receive protocol running status data but has not yet formally processed input frames. Meanwhile, the reconfiguration controller continues to clamp the boundary signals between the target reconfigurable partition and the static logic region until the internal clock of the target reconfigurable partition is stable, the reset release is completed, and the initialization completion flag is valid. Then, the decoupling enable signal of the bus macro decoupling circuit is removed, and the boundary connection is restored in the order of control signals, data signals, and handshake signals. This allows the input valid signals, output valid signals, ready signals, error flags, and status feedback signals at the boundary to smoothly switch from predefined levels to normal operating levels, thereby avoiding the static logic region from erroneously sampling uncertain signals before the target reconfigurable partition has stabilized.

[0043] In this embodiment, after completing local reconfiguration and boundary recovery, the reconfiguration controller updates the loading status table of the target reconfigurable partition based on the second protocol type identifier, the first number of the target reconfigurable partition, and the second number of the target state holding register group recorded in the current handover trigger signal. The target reconfigurable partition is marked as loaded, recoverable, and awaiting frame refeedback states, and a reconfiguration completion signal is generated. The reconfiguration completion signal carries the second protocol type identifier and the second number of the target state holding register group. The second protocol type identifier indicates that the current target reconfigurable partition has formed a parsing pipeline instance of the corresponding protocol, and the second number indicates that subsequent state recovery logic reads protocol runtime status data from the corresponding state holding register group.

[0044] In one embodiment, such as Figure 6 As shown, step S400: Based on the reconfiguration completion signal, a second protocol parsing pipeline instance for completing state recovery is generated, and the first Ethernet frame and the second Ethernet frame temporarily stored in the input frame buffer FIFO are sent to the second protocol parsing pipeline instance for further processing, including: S401: Read the corresponding protocol operation status data according to the second number of the target status holding register group carried by the reconfiguration completion signal; S402: Write the protocol running status data to the corresponding status register position in the target reconfigurable partition after local reconfiguration, and obtain the second protocol parsing pipeline instance after state recovery; S403: Read out the first and second Ethernet frames temporarily stored in the input frame buffer FIFO frame by frame in the order of arrival, and send them to the second protocol parsing pipeline instance for further processing. After all the temporarily stored Ethernet frames have been read out, return to step S100.

[0045] In this embodiment, after the reconfiguration completion signal enters the state recovery logic, the state recovery controller parses the second number of the target state holding register group carried therein, and uses the second number as the address index to access the state holding register group array. It then reads the protocol operation status data from the corresponding register group. This protocol operation status data includes the current state of the protocol state machine, frame sequence number, address count value, phase count value, synchronization cycle count value, input / output buffer read / write pointers, temporarily stored values ​​of parsed fields, error statistics status, and context flags related to continuous processing of the target protocol. To ensure consistency between the reading process and the newly loaded target reconfigurable partition clock domain, this embodiment sets a synchronization register and a valid flag bit at the output of the state holding register group. When the second number hits a valid register group, the state recovery controller reads the protocol type identifier and verification flag in the status data header and performs a consistency check with the second protocol type identifier in the reconfiguration completion signal. If they match and the check is valid, the controller continues reading the protocol operation status data. If they do not match or the check is invalid, the controller enters a preset abnormal recovery path, keeping the target reconfigurable partition in a waiting state and preventing it from immediately receiving buffered frames.

[0046] In this embodiment, after the read is completed, the state recovery controller writes the protocol running state data into the corresponding state register location within the target reconfigurable partition that has undergone partial reconfiguration, according to the state mapping table. For example, it writes the protocol state machine state into the state machine recovery register, the frame sequence number into the sequence number register, the address count value into the address count register, the phase count value into the synchronization phase register, and the buffer read / write pointer into the corresponding input / output pointer register. During the writing process, the valid input signal of the second protocol parsing pipeline instance is kept in an invalid state to prevent premature processing of Ethernet frames before the state is fully written. After all state registers are written, the state recovery controller triggers a state latch signal, causing each level of pipeline register within the target reconfigurable partition to be updated to the recovered state at the same working clock boundary. It then reads the state recovery completion flag returned by the target reconfigurable partition, thereby obtaining the second protocol parsing pipeline instance that has completed state recovery. The read controller of the input frame buffer FIFO reads the first and second Ethernet frames frame by frame according to the arrival order stored in the FIFO. Before each read, it checks the input ready signal of the second protocol parsing pipeline instance. Only when the input ready signal is valid and the state recovery completion flag remains valid will the current frame data, protocol type identifier, port identifier, and arrival timestamp be synchronously sent to the second protocol parsing pipeline instance. If the pipeline instance is temporarily unreceived, FIFO reading is paused and the current read pointer is maintained until the input is ready, thus preventing the loss or out-of-order delivery of buffered frames. After receiving the buffered frames, the second protocol parsing pipeline instance continues to perform frame synchronization, frame header parsing, address matching, data extraction, verification, output buffering, and forwarding processing according to the restored protocol operation state, so that the first Ethernet frame temporarily stored before the handover and the second Ethernet frame arriving during the handover can be continuously entered into the target protocol processing flow. Since the input frame buffer FIFO maintains the frame order in a first-in-first-out manner, the first and second Ethernet frames will not be reversed due to local reconfiguration or state recovery. After all the Ethernet frames temporarily stored in the FIFO are read out, the read controller clears the buffer occupancy flag, and the state recovery controller marks the second protocol parsing pipeline instance as being in normal operation. At the same time, it releases the distribution restrictions of the frame preprocessing engine, allowing subsequent newly accessed Ethernet frames to re-enter the field extraction, protocol identification, and loading status judgment process, that is, return to step S100 to continue the next round of protocol identification and distribution processing.

[0047] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0048] In one embodiment, a multi-protocol industrial Ethernet coprocessing device is provided, which corresponds one-to-one with the multi-protocol industrial Ethernet coprocessing methods described in the above embodiments. For example... Figure 7 As shown, the multi-protocol industrial Ethernet coprocessor includes: The identification and reporting module 701 is used to extract fields from the first Ethernet frame that is accessed, determine the first protocol type identifier, and report it. The switching module 702 is used to compare the current count value of the global time base counter with the time slot start time in the protocol switching schedule table and generate a switching trigger signal by combining the first protocol type identifier; The reconfiguration module 703 is used to retrieve the corresponding configuration bit stream according to the switching trigger signal, write the configuration bit stream into the target reconfigurable partition and generate a reconfiguration completion signal; The state recovery module 704 is used to generate a second protocol parsing pipeline instance that has completed state recovery based on the reconfiguration completion signal, and to send the first Ethernet frame and the second Ethernet frame temporarily stored in the input frame buffer FIFO into the second protocol parsing pipeline instance for further processing.

[0049] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0050] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0051] This application also provides a computer device, such as... Figure 8As shown, the computer device includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor. When the processor executes the computer program, it implements the steps in any of the above method embodiments, or when the processor executes the computer program, it implements the functions of each module / unit in the above device embodiments.

[0052] For example, the computer program may be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the computer device.

[0053] Those skilled in the art will understand that Figure 8 The computer device described is merely an example and does not constitute a limitation on the computer device. It may include more or fewer components than shown, or combine certain components, or different components. For example, the computer device may also include input / output devices, network access devices, buses, etc.

[0054] The aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0055] The memory can be an internal storage unit of the computer device, such as a hard drive or RAM. The memory can also be an external storage device of the computer device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory can include both internal and external storage units of the computer device.

[0056] This application also provides a readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the above-described method embodiments.

[0057] This application provides a computer program product that, when run on an electronic device, enables the electronic device to implement the steps described in the various method embodiments above.

[0058] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0059] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0060] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0061] In the embodiments provided in this application, it should be understood that the disclosed apparatus / devices and methods can be implemented in other ways. For example, the apparatus / device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0062] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0063] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A multi-protocol industrial Ethernet coprocessing method, characterized in that, include: S100: Extract fields from the first Ethernet frame that has been received. By performing parallel comparison and priority encoding reduction on the field data of the first Ethernet frame with multiple sets of mask matching rules, the determination and distribution judgment of the first protocol type identifier are completed at the hardware level. Specifically, this includes: S101: Extract fields from the first Ethernet frame that has been received to obtain field data; S102: Perform bitwise mask comparison and priority encoding reduction on the field data with multiple sets of mask matching rules to determine the first protocol type identifier and determine whether the first protocol parsing pipeline instance corresponding to the first protocol type identifier has been loaded; S103: If it has been loaded, distribute the first Ethernet frame to the first protocol parsing pipeline instance; if it has not been loaded, write the first Ethernet frame into the input frame buffer FIFO and report the first protocol type identifier. Simultaneously write the second Ethernet frame that arrives before the first protocol parsing pipeline instance is loaded and has the same protocol type as the first protocol type identifier into the input frame buffer FIFO. S200: Compare the current count value of the global time base counter with the time slot start time in the protocol switching schedule table and generate a switching trigger signal by combining it with the first protocol type identifier; S300: Retrieve the corresponding configuration bit stream according to the switching trigger signal, write the configuration bit stream into the target reconfigurable partition and generate a reconfiguration completion signal; S400: Generate a second protocol parsing pipeline instance that has completed state recovery based on the reconfiguration completion signal, and send the first Ethernet frame and the second Ethernet frame temporarily stored in the input frame buffer FIFO into the second protocol parsing pipeline instance for further processing.

2. The multi-protocol industrial Ethernet coprocessing method as described in claim 1, characterized in that, S2 00: Compare the current count value of the global time base counter with the time slot start time in the protocol handover scheduling table and combine it with the first protocol type identifier to generate a handover trigger signal, including: S201: Compare the current count value of the global time base counter with the time slot start time in the protocol switching schedule table and combine it with the first protocol type identifier to determine whether a protocol switch is required; S202: If a protocol switch is required, a freeze request is sent to the first protocol parsing pipeline instance, and after the frame in transit flag state machine returns an idle confirmation signal, a switch trigger signal is generated. The switch trigger signal carries a second protocol type identifier, a first number of the target reconfigurable partition, and a second number of the target state holding register group.

3. The multi-protocol industrial Ethernet coprocessing method as described in claim 2, characterized in that, S3 00: Retrieve the corresponding configuration bitstream according to the switching trigger signal, write the configuration bitstream into the target reconfigurable partition, and generate a reconfiguration completion signal, including: S301: Based on the second protocol type identifier and the first number carried by the switching trigger signal, retrieve the configuration bit stream from the protocol configuration library that only covers the protocol parsing logic within the target reconfigurable partition; S302: Based on the configuration bitstream, drive the bus macro decoupling circuit at the boundary between the target reconfigurable partition and the static logic region and clamp the boundary signal to a predefined level; write the configuration bitstream into the target reconfigurable partition through the internal configuration access port. S303: When the configuration bit stream is written, determine that the target reconfigurable partition has completed local reconfiguration, release the boundary signal clamp, and generate a reconfiguration completion signal.

4. The multi-protocol industrial Ethernet coprocessing method as described in claim 3, characterized in that, S303: When the configuration bitstream is written, determine that the target reconfigurable partition has completed local reconfiguration, release the boundary signal clamp, and generate a reconfiguration completion signal, including: When the configuration bitstream is written, the internal registers of the target reconfigurable partition are restored to their initial state, local reconfiguration is completed, and the boundary signal clamping is released. Based on the target reconfigurable partition that has completed partial reconfiguration, a reconfiguration completion signal is generated, carrying the second protocol type identifier and the second number of the target state holding register group.

5. The multi-protocol industrial Ethernet coprocessing method as described in claim 4, characterized in that, S400: Based on the reconfiguration completion signal, generate a second protocol parsing pipeline instance that has completed state recovery, and send the first Ethernet frame and the second Ethernet frame temporarily stored in the input frame buffer FIFO into the second protocol parsing pipeline instance for further processing, including: S401: Read the corresponding protocol operation status data according to the second number of the target state holding register group carried by the reconfiguration completion signal; S402: Write the protocol running status data into the corresponding status register position in the target reconfigurable partition after the local reconfiguration is completed, to obtain a second protocol parsing pipeline instance that has completed state recovery; S403: Read out the first Ethernet frame and the second Ethernet frame temporarily stored in the input frame buffer FIFO frame by frame in the order of arrival, and send them to the second protocol parsing pipeline instance for further processing. After all the temporarily stored Ethernet frames have been read out, return to step S100.

6. A multi-protocol industrial Ethernet coprocessor, characterized in that, The steps for implementing the multi-protocol industrial Ethernet coprocessing method as described in any one of claims 1 to 5 include: The identification reporting module is used to extract fields from the first Ethernet frame that is connected. By performing parallel comparison and priority encoding reduction of the field data of the first Ethernet frame with multiple sets of mask matching rules, the determination and distribution judgment of the first protocol type identifier is completed at the hardware level. The switching module is used to compare the current count value of the global time base counter with the time slot start time in the protocol switching schedule table and generate a switching trigger signal by combining the first protocol type identifier; The reconfiguration module is used to retrieve the corresponding configuration bit stream according to the switching trigger signal, write the configuration bit stream into the target reconfigurable partition, and generate a reconfiguration completion signal. The state recovery module is used to generate a second protocol parsing pipeline instance that has completed state recovery based on the reconfiguration completion signal, and to send the first Ethernet frame and the second Ethernet frame temporarily stored in the input frame buffer FIFO into the second protocol parsing pipeline instance for further processing.

7. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the multi-protocol industrial Ethernet coprocessing method as described in any one of claims 1 to 5.

8. A readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the multi-protocol industrial Ethernet coprocessing method as described in any one of claims 1 to 5.

9. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the multiprotocol industrial Ethernet coprocessing method as described in any one of claims 1 to 5.

Images