Programmable logic-based industrial protocol parsing hardware implementation system and method

Abstract

The application relates to the technical field of protocol analysis, and discloses an industrial protocol analysis hardware implementation system and method based on programmable logic, wherein corresponding data is loaded from preset protocol configuration data to a reconfigurable area according to a target protocol type, and a hardware parser adapted to the protocol is formed in the reconfigurable area; the bit width of a subsequent field extraction and the check calculation interval are adjusted according to the value of an analyzed field, complex scenes such as variable-length fields and conditional formats widely existing in industrial protocols are efficiently processed, and the determinacy of analysis delay is maintained; the analysis result of a source protocol is directly read from a hardware buffer, data transformation is performed according to a mapping relationship, and a target protocol frame is assembled; and in a single hardware architecture, general analysis of multiple protocols, parallel access and rapid identification of multiple source data, and low-delay protocol conversion are simultaneously realized.

Description

Technical Field

[0001] This application relates to the field of protocol parsing technology, specifically to a hardware implementation system and method for industrial protocol parsing based on programmable logic. Background Technology

[0002] In industrial automation environments, multiple communication protocols often coexist, such as Modbus TCP / RTU, Profinet RT / IRT, EtherCAT, and EtherNet / IP. These protocols differ in frame format, field structure, and verification mechanism. Equipment from different manufacturers and control systems at different levels may use different protocols. Protocol parsing and conversion are fundamental requirements in the field of industrial communication.

[0003] Existing industrial protocol parsing and conversion methods mainly fall into two categories: First, software-based protocol parsing schemes, which run protocol stack software on the CPU and parse data frames field by field. This scheme offers high flexibility, but software parsing is affected by factors such as operating system scheduling and interrupt response, and cannot meet the end-to-end latency requirements in scenarios such as industrial motion control. Second, a scheme that designs dedicated hardware parsing circuits for specific protocols, directly mapping the protocol format to hardware logic. This scheme offers fast parsing speed and deterministic latency, but each protocol requires an independent hardware module. Supporting new protocols necessitates modifying the hardware design and re-integrating the layout and wiring, resulting in a long development cycle. Furthermore, the system must be shut down during reprogramming.

[0004] The third approach is based on programmable logic devices. One approach is to pre-compile a complete hardware bitstream for each protocol and load the corresponding bitstream at runtime according to the protocol type. However, FPGA reconfiguration has a delay that is much greater than the frame interval of industrial protocols, making it impossible to switch protocols between adjacent frames. The second approach is to design a general parsing engine with a fixed structure, which can adapt to different protocols by modifying configuration parameters. However, the fixed pipeline structure cannot adjust the data path topology at runtime, resulting in low parsing efficiency when dealing with protocols with dynamic dependencies between fields. The only solution is to handle the dependencies by pausing the pipeline.

[0005] In view of the above-mentioned shortcomings of the prior art, the technical problem to be solved by this application is how to implement flexible hardware parsing of industrial protocols based on programmable logic. Summary of the Invention

[0006] To address the shortcomings of existing technologies, the purpose of this application is to provide a hardware implementation system and method for industrial protocol parsing based on programmable logic, which simultaneously achieves universal parsing of multiple protocols, parallel access and rapid identification of multi-source data, and low-latency protocol conversion in a single hardware architecture.

[0007] To achieve the above objectives, this application adopts the following technical solution:

[0008] In the first aspect, this application provides a hardware implementation method for parsing industrial protocols based on programmable logic, which receives industrial protocol data streams from multiple physical interfaces, performs clock domain isolation and convergence processing, and then performs parallel feature matching on the data streams to determine the target protocol type.

[0009] Based on the target protocol type, the corresponding configuration data is loaded from the preset protocol configuration data into the reconfigurable area, and a hardware parser adapted to the target protocol type is formed in the reconfigurable area.

[0010] The hardware parser parses the input message field by field, adjusts the field extraction bit width and check calculation range according to the values ​​of the parsed fields, and temporarily stores the parsing results in the hardware buffer.

[0011] If a protocol conversion is performed, the parsing result is read from the hardware buffer according to the protocol conversion rules, the data mapping and transformation from the source protocol to the target protocol is performed, the target protocol data frame is assembled and output.

[0012] Furthermore, determining the target protocol type includes:

[0013] The processed data stream is subjected to sliding slicing to generate continuous slice windows. The slice windows are matched in parallel with the preset frame start anchor point features. When an anchor point feature is matched, the current data position is marked as the start anchor point of the candidate frame, and relative offset counting is started based on the start anchor point.

[0014] Candidate protocols are selected based on the matched anchor point feature types. The feature fields of the candidate protocols at the corresponding relative offset positions are extracted and matched step by step according to the preset matching nodes with relative offsets from small to large.

[0015] The candidate protocols are determined as the target protocol type after successive pruning and convergence.

[0016] Furthermore, during the stepwise feature matching process, the feature matching pathways corresponding to the pruned candidate protocols are closed.

[0017] When the candidate protocol is pruned to a single protocol, the length field of the protocol frame format is extracted, the actual length is extracted from the data stream based on the corresponding relative offset position, and frame boundary verification is performed in combination with the protocol's frame length constraints.

[0018] After successful verification, the target protocol type is locked and the protocol identifier and corresponding frame header parameter set are output.

[0019] If the candidate protocol fails to converge within the preset offset window, or if the frame boundary check fails, the starting anchor point is determined to be an invalid anchor point, the relative offset count and feature matching path are reset, and feature matching is re-executed.

[0020] Furthermore, the hardware parser adapted to the target protocol type includes:

[0021] Load the configuration data corresponding to the target protocol type from the preset protocol configuration data into the reconfigurable area. The configuration data includes field processing rules, field dependencies, and processing parameters.

[0022] Based on the field processing rules, determine the processing steps to be executed during message parsing, and enable the hardware resources corresponding to the processing steps to be executed in the reconfigurable area to enter the working state, while the remaining hardware resources enter the closed state.

[0023] Based on the dependencies between fields, establish data transfer paths between hardware resources that have entered the working state;

[0024] The processing parameters are injected into the hardware resources that are already in operation and have established a data transmission path, forming a hardware parser that is compatible with the target protocol type.

[0025] Furthermore, the field processing rules include the relative offset position of the field in the protocol frame, the field extraction bit width, and the field verification conditions. The field verification conditions include a verification enable flag and a verification calculation range. The field dependency relationship includes the constraint relationship between the parsing result of the preceding field and the field extraction bit width. The processing parameters include the field identifier, the expected value, and the verification method.

[0026] Furthermore, the step of parsing the input message field by field includes:

[0027] The hardware parser extracts the original data of the field to be parsed from the relative offset position of the field to be parsed in the field processing rules and the field extraction bit width.

[0028] The original data of the field to be parsed is compared with its corresponding expected value, and the verification calculation within the corresponding verification calculation interval is started synchronously when the verification enable flag of the field to be parsed is valid.

[0029] Write the parsing result of the current field to be parsed into the hardware buffer and record the value of the parsed field.

[0030] Furthermore, the adjustment field extraction bit width and verification calculation range includes:

[0031] Calculate the adjusted field extraction bit width for the next field based on the values ​​of the currently parsed fields and their corresponding field dependencies.

[0032] Based on the adjusted field, extract the bit width and recalculate the next field and its relative offset position in the protocol frame;

[0033] Based on the updated relative offset position and the extracted bit width of the field, update the starting position and coverage of the field's verification calculation interval;

[0034] Extract the bit width, relative offset position, and verification calculation range from the updated fields, and continue parsing the fields.

[0035] Furthermore, the assembly of the target protocol data frame includes:

[0036] The mapping relationship between the source protocol fields and the target protocol fields is determined according to the protocol conversion rules, as well as the assembly order of the data fields, length fields and check fields in the target protocol data frame. In the assembly order, the length field and check field are placed after all the data fields.

[0037] According to the assembly order, the parsing results of the source protocol fields are read from the hardware buffer in turn. After data mapping and transformation according to the mapping relationship, the data is written to the relative offset position of the corresponding field in the target protocol data frame. At the same time, the frame length of the target protocol data frame is accumulated field by field and the accumulated verification value is updated synchronously.

[0038] After all data fields are assembled, the accumulated frame length is written to the position of the length field, and the accumulated check value is written to the position of the check field, thus completing the assembly and output of the target protocol data frame.

[0039] Furthermore, the data mapping and transformation based on the mapping relationship includes:

[0040] When the byte order of the source protocol field and the target protocol field are inconsistent, perform byte order transformation on the value of the parsed field;

[0041] When the numerical representation ranges of the source protocol field and the target protocol field are different, numerical scaling is performed on the values ​​of the parsed fields;

[0042] When multiple source protocol fields correspond to a single field in the target protocol, the values ​​of the multiple parsed fields are merged according to a preset merging rule;

[0043] When a source protocol field corresponds to multiple fields of the target protocol, the values ​​of the parsed fields are split according to a preset splitting rule.

[0044] Secondly, this application provides a hardware implementation system for industrial protocol parsing based on programmable logic, including: a sniffing module, a configuration module, a parsing module, and a conversion module;

[0045] The sniffing module is used to receive industrial protocol data streams from multiple physical interfaces. After clock domain isolation and aggregation processing, the data streams are subjected to parallel feature matching to determine the target protocol type.

[0046] The configuration module is used to load the corresponding configuration data from the preset protocol configuration data into the reconfigurable area according to the target protocol type, and form a hardware parser adapted to the target protocol type in the reconfigurable area.

[0047] The parsing module parses the input message field by field using a hardware parser, adjusts the field extraction bit width and check calculation range according to the values ​​of the parsed fields, and temporarily stores the parsing results in a hardware buffer.

[0048] The conversion module is used to read the parsing results from the hardware buffer according to the protocol conversion rules if protocol conversion is performed, perform data mapping and transformation from the source protocol to the target protocol, assemble the target protocol data frame and output it.

[0049] Compared with the prior art, the beneficial effects achieved by this application are as follows:

[0050] Based on the target protocol type, the corresponding data is loaded from the preset protocol configuration data into the reconfigurable area. Within the reconfigurable area, a hardware parser adapted to the protocol is formed. Different data path topologies and processing parameters can be presented for different protocols, combining the parsing efficiency of hardware with the flexibility of software configuration. The bit width of subsequent field extraction and the verification calculation range are adjusted according to the value of the parsed field, which can efficiently handle complex scenarios such as variable-length fields and conditional formats that are widely present in industrial protocols, and maintain the determinism of parsing latency.

[0051] The parsing results of the source protocol are read directly from the hardware buffer, and the data is transformed according to the mapping relationship and assembled into a target protocol data frame. In a single hardware architecture, multi-protocol general parsing, parallel access and fast identification of multi-source data, and low-latency protocol conversion are achieved simultaneously. Attached Figure Description

[0052] Figure 1 A flowchart illustrating the hardware implementation method for parsing industrial protocols based on programmable logic;

[0053] Figure 2 A flowchart for creating a hardware parser that is compatible with the target protocol type;

[0054] Figure 3 This is a system diagram of a hardware implementation system for industrial protocol parsing based on programmable logic. Detailed Implementation

[0055] The technical solution of this application will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments and specific features in the embodiments are detailed descriptions of the technical solution of this application, rather than limitations thereof.

[0056] Example 1:

[0057] like Figure 1 As shown, this embodiment provides a hardware implementation method for industrial protocol parsing based on programmable logic, including:

[0058] S1. Receive industrial protocol data streams from multiple physical interfaces, and after clock domain isolation and aggregation processing, perform parallel feature matching on the data streams to determine the target protocol type.

[0059] Specifically, determining the target protocol type includes:

[0060] Receive industrial protocol data streams from multiple physical interfaces and perform clock domain isolation and aggregation processing on the industrial protocol data streams;

[0061] The processed data stream is subjected to sliding slicing to generate continuous slice windows. The slice windows are matched in parallel with the preset frame start anchor point features. When an anchor point feature is matched, the current data position is marked as the start anchor point of the candidate frame, and relative offset counting is started based on the start anchor point.

[0062] Candidate protocols are selected based on the matched anchor point feature types. The feature fields of the candidate protocols at the corresponding relative offset positions are extracted and matched step by step according to the preset matching nodes with relative offsets from small to large.

[0063] The candidate protocols are determined as the target protocol type after successive pruning and convergence.

[0064] Specifically, in the stepwise feature matching process, the feature matching path corresponding to the pruned candidate protocol is closed;

[0065] When the candidate protocol is pruned to a single protocol, the length field of the protocol frame format is extracted, the actual length is extracted from the data stream based on the corresponding relative offset position, and frame boundary verification is performed in combination with the protocol's frame length constraints.

[0066] After successful verification, the target protocol type is locked and the protocol identifier and corresponding frame header parameter set are output.

[0067] If the candidate protocol fails to converge within the preset offset window, or if the frame boundary check fails, the starting anchor point is determined to be an invalid anchor point, the relative offset count and feature matching path are reset, and feature matching is re-executed.

[0068] Industrial environments employ a variety of physical interfaces, including common ones such as Gigabit Ethernet, 100Mbps Ethernet, RS-485 serial interfaces, and CAN bus interfaces. These interfaces operate at different clock frequencies. When signals from these different clock domains are directly sampled into a unified clock domain, the constraints of setup and hold times cannot be stably met. This can cause the output of the flip-flop to enter a metastable state, meaning the output oscillates between high and low levels or remains at the middle level, leading to subsequent logic sampling incorrect data values.

[0069] Clock domain isolation is specifically as follows: the receiving module of each physical interface sequentially writes the received raw bytes into an asynchronous first-in-first-out (AFIFO) queue under the interface-side clock domain. The write port of this asynchronous FIFO operates in the interface-side clock domain, while the read port operates in a unified clock domain. Gray code-encoded read and write pointers are used for cross-clock domain transfer to ensure that multiple bits do not flip simultaneously when the pointer is sampled by another clock domain, thus preventing intermediate state errors. The read port reads the data bytes in the clock domain in a first-in-first-out order, thereby completing the clock domain conversion. The depth of the FIFO is determined based on the rate differences of each interface and the maximum allowable processing delay of the system. The FIFO depth must be sufficient to accommodate the amount of data continuously received by the interface side during system-side processing pauses to prevent data overflow and loss.

[0070] Taking a gigabit Ethernet interface as an example, its effective data rate is about 125MB / s. If the maximum backpressure duration on the system side is 32 microseconds, then the FIFO depth should be at least 125×32=4000 bytes. In actual engineering, 4096 bytes are used to leave a safety margin. The speed of RS-485 interface is usually much lower than that of Ethernet, and its FIFO depth can be 256 bytes to meet the requirements.

[0071] The aggregation process is as follows: A polling scheduler is set up under a unified clock domain. This scheduler checks the non-empty flag of each interface FIFO in a fixed scanning order. When a FIFO is not empty, the scheduler continuously reads a frame of data from that FIFO and inserts a byte of source interface identifier information at the beginning of the frame before writing it into the aggregated data stream. Polling scheduling ensures that the data of each interface is served in the order of arrival, and there will be no situation where one interface occupies the processing channel for a long time while other interfaces cannot respond to the data in time. The value of the source interface identifier is determined by the configuration during initialization. For example, the identifier of interface A (Gigabit Ethernet) is 0x01, the identifier of interface B (100Mbps Ethernet) is 0x02, and the identifier of interface C (RS-485) is 0x03.

[0072] This step ensures bit-level integrity of the data during transmission, merging data from multiple heterogeneous physical interfaces into a byte stream with a unified clock reference and clear frame boundaries, providing the necessary context for subsequent diagnostic statistics and output routing; the data stream after clock domain isolation and aggregation is output byte by byte at the system clock frequency, with the source interface identifier carried at the front end of each frame of data as input for sliding slice processing.

[0073] When data frames of industrial protocols are transmitted over a physical medium, they are continuous byte sequences. The Ethernet MAC layer usually strips the preamble and start-of-frame delimiter before delivering the frame to the upper layer. Therefore, the upper-layer processing logic faces a continuous byte stream without an explicit start-of-frame marker. Different industrial protocols have their own unique byte patterns at fixed offset positions within the frame. These fixed byte patterns, located at specific offset positions within the frame and distinguishing the protocol type, are known as the frame start anchor point features.

[0074] The sliding slice processing specifically involves setting a sliding window with a width of N bytes. Each clock cycle, a new byte is read from the data stream into the least significant bit of the shift register, while all existing bytes in the shift register are shifted one position to the higher-order bits, and the most significant byte is shifted out and discarded. The window width N should not be less than the maximum byte span involved in the anchor feature in all known protocols. For industrial protocols carried by Ethernet, the anchor feature is usually located in the EtherType field, and the window width should at least cover the range from offset 12 bytes to the end of the anchor feature. If the longest anchor feature is 4 bytes, then N of 16 bytes can cover the range from offset 12 to 15 bytes, with appropriate alignment margin.

[0075] Each protocol corresponds to a set of anchor feature registers, which store the expected byte sequence and the corresponding matching mask. In the matching mask, a bit with a value of 1 indicates that the bit corresponding to that position must match the expected value exactly, and a bit with a value of 0 indicates that any value of that bit will not affect the matching result. This allows different variants of the same protocol to be covered by the same set of anchor features, that is, the mask for the transaction identifier byte position is set to all 0s, and the mask for the protocol identifier byte position is set to all 1s.

[0076] The output of the sliding window is simultaneously connected to the comparison channels of all protocols. Each comparison channel consists of a set of byte-aligned XOR gates and mask AND gates. Each byte in the sliding window is XORed with the expected value at the corresponding position to obtain the difference bit, which is then ANDed with the matching mask to retain only the difference in the bits that need to be precisely matched. If the difference in all byte positions is zero after being filtered by the mask, the channel outputs a match hit signal. When a comparison channel outputs a match hit signal, the current position of the sliding window is recorded, and the frame start position corresponding to the anchor point feature in the data stream is deduced from it.

[0077] Taking an Ethernet frame as an example, if EtherType is located at the frame offset of 12 bytes, when the byte at offset position 0 in the sliding window happens to correspond to the first byte of EtherType, the current data stream position minus 12 bytes is the starting position of the frame. A relative offset counter is started based on the starting position of the frame. The counter increments in each clock cycle, and subsequent stepwise feature matching will use the value of the counter as the byte offset from the frame start position to locate each feature field.

[0078] Assuming a Profinet RT data frame exists in the data stream, the first 14 bytes of its Ethernet frame header are: 0x01, 0x00, 0x5E, 0x00, 0x01, 0x01, 0x00, 0x0E, 0x02, 0x0A, 0x0B, 0x0C, 0x88, 0x92, representing a 6-byte destination MAC address, a 6-byte source MAC address, and a 2-byte EtherType, respectively. When the sliding window moves to offset 0, corresponding to the first byte of EtherType (0x88) in the data stream, the window content is: offset 0 = 0x88, offset 1 = 0x92, offset 2 = subsequent data bytes, offset 3 = subsequent data bytes; Profinet The expected value of the anchor point feature of RT is [0x88, 0x92], and the matching mask is [0xFF, 0xFF]. At offset 0, 0x88 is XORed with 0x88 = 0x00, and ANDed with the mask 0xFF to get 0x00. At offset 1, 0x92 is XORed with 0x92 = 0x00, and ANDed with the mask 0xFF to get 0x00. The difference between the two positions is zero, and the ProfinetRT comparison channel outputs a match hit. The frame start position is then calculated as the current data stream position minus 12, and the relative offset counter is started.

[0079] This step traverses the data stream byte by byte, ensuring that anchor features appearing at any position in the data stream can be detected. This allows anchor features of all protocols to be compared within the same clock cycle, without increasing with the number of supported protocols. This improves compatibility between different variants of the same protocol and reduces the number of anchor features that need to be maintained.

[0080] Based solely on the frame start anchor point feature, it is usually only possible to make coarse-grained distinctions at the level of broad protocol categories, and it is impossible to accurately determine the specific protocol type. Specifically, a set of matching nodes is pre-configured for each protocol. Each matching node includes three attributes: the byte offset relative to the frame start position, the expected byte value at that offset position, and the corresponding matching mask. All matching nodes of all protocols are globally sorted according to the offset from smallest to largest. Matching nodes with the same offset are grouped into the same order.

[0081] After anchor point matching is completed and candidate protocols are established, starting from the first level (the level with the smallest offset), the data is located in the data stream according to the relative offset, and the byte data at that position is read. The read byte is compared with the expected value and mask defined for each protocol in the current candidate protocol set at that level. The comparison method is to XOR the byte with the expected value and then AND it with the mask. If the result is zero, it is a match; otherwise, it is a non-match. After the comparison at a certain level is completed, all non-matching protocols are removed from the candidate protocols, i.e., pruning.

[0082] Each protocol maintains an active flag. During the anchor matching phase, the active flags of all protocols are set to valid. When a protocol is pruned at a certain stage, its active flag is set to invalid. In the matching process of subsequent stages, only protocols with valid active flags participate in the comparison. The comparison channel of protocols with invalid active flags is shut down by the gated clock or their comparison results are masked, and no matching signal is output. They do not participate in the update and determination of candidate protocols. After the pruning of each stage is completed, the number of remaining protocols in the candidate protocols is checked. If the number is 1, the candidate protocol has converged into a unique protocol, and the main process of protocol identification is completed. If the number is 0, or is always greater than 1 in subsequent stages and has reached the boundary of the preset offset window, the identification is determined to be a failure. The hardware implementation of the convergence determination is to sum the active flags of each protocol in the candidate protocols. When the summation result is equal to 1, a convergence signal is output.

[0083] For example, during the anchor matching phase, if EtherType is detected as 0x8892, the candidate protocols include protocol P1 (ProfinetRT) and protocol P2 (another protocol using EtherType 0x8892). In the first stage (offset 14 bytes), the expected value of protocol P1 is 0x01, and the mask is 0xF0, meaning that the high 4 bits of this byte must be the high nibble 0x0 in 0x0001, and the low 4 bits are irrelevant. The expected value of protocol P2 is 0xC0, and the mask is 0xF0, meaning that the high 4 bits of this byte must be the high nibble 0xC in 0x1100.

[0084] Assuming the byte value read from offset 14 bytes in the data stream is 0x01, for protocol P1, 0x01 XOR 0x01 = 0x00, ANDed with the mask 0xF0, resulting in 0x00, a match; for protocol P2, 0x01 XOR 0xC0 = 0xC1, ANDed with the mask 0xF0, resulting in 0xC0, which is non-zero, a mismatch; protocol P2 is pruned, its active flag position is invalid, and it will not participate in subsequent comparisons; in the second stage (offset 15 bytes), only protocol P1 participates in the matching, and the expected value of protocol P1 in this stage is not considered (mask 0x00), so it passes automatically; after the second stage, the candidate protocol set only contains protocol P1 (Profinet RT), with a quantity of 1, and the convergence signal is output.

[0085] This step breaks down the protocol identification process into multiple progressively deeper judgment stages. Each stage only requires reading a small number of bytes to eliminate irrelevant protocols, maximizing the determinism of identification while minimizing the amount of data stream read, reducing unnecessary comparison operations and signal toggling, and lowering dynamic power consumption.

[0086] Even after protocol feature matching has converged, there is still a possibility of misjudgment. If incorrect configuration data is loaded to form a hardware parser based on the misjudgment, subsequent field parsing will all be performed in the wrong format. Not only will the parsing result be invalid, but it will also cause out-of-bounds reading due to incorrect calculation of field width or offset, triggering hardware abnormalities. According to the frame format definition of the candidate protocol, the length field has a fixed relative offset position and a fixed byte width within the frame. Based on these parameters, the starting position of the length field is located from the data stream using the current value of the relative offset counter, and the original byte data of the specified width is read.

[0087] The raw byte data read is converted into a numerical value according to the byte order defined by the candidate protocol. The byte order refers to the arrangement order of the bytes in a multi-byte numerical value. In big-endian, the most significant byte is stored at the lowest address, and in little-endian, the least significant byte is stored at the lowest address. If the candidate protocol defines the length field as a 2-byte field in big-endian, and the raw bytes read from the data stream are 0x00 and 0x06 respectively, the interpretation process is to shift the most significant byte 0x00 left by 8 bits and then OR it with the least significant byte 0x06 to obtain the value 6.

[0088] The frame length constraint verification is as follows: Each protocol predefines its maximum and minimum frame length. The maximum frame length is usually determined by the protocol specification or link MTU, and the minimum frame length is usually determined by the number of bytes in the fixed part of the frame header plus the number of bytes in the shortest payload. The interpreted length value is compared with the constraint range: if the length value falls within the constraint range, the verification passes; otherwise, the verification fails.

[0089] For example, in the Modbus TCP frame format, the length field is located 4 bytes off the MBAP header, that is, 4 + 14 = 18 bytes off the start of the Ethernet frame. The 14 bytes represent the Ethernet frame header length, with a width of 2 bytes, and the byte order is big-endian. The Modbus TCP frame length constraints are defined as follows: the minimum frame length is the fixed 7 bytes of the MBAP header (2 bytes for transaction identifier + 2 bytes for protocol identifier + 2 bytes for length + 1 byte for unit identifier) ​​plus 1 byte for the function code, totaling 8 bytes; the maximum frame length is the 7 bytes of the MBAP header plus the maximum PDU length of 253 bytes, totaling 260 bytes. Assuming the original bytes of the length field read from the data stream are 0x00 and 0x06, after big-endian interpretation, the value is 6, representing a PDU length of 6 bytes. Adding the 7 bytes of the MBAP header, the total frame length is 13 bytes, falling within the constraints, and the frame boundary check passes.

[0090] For example, another candidate protocol converged to Profinet RT. The original bytes of the length field read from the data stream were 0x75 and 0x30. After big-endian interpretation, the value was 30000. The maximum frame length of Profinet RT is limited by the Ethernet frame payload, which is about 1496 bytes. 30000 far exceeds the maximum frame length, so the verification fails and the current anchor point is determined to be an invalid anchor point.

[0091] After successful verification, the candidate protocol identifier is output as the determined target protocol type. This identifier is a number assigned to each protocol during initialization, such as 0x01 for Modbus TCP, 0x02 for Profinet RT, and 0x03 for EtherCAT. This number will be used as the key for subsequent indexing of protocol configuration data. Next, the frame header parameter set is output. This parameter set summarizes the original values ​​of all fields read from the data stream during the protocol identification process, including but not limited to bytes read from anchor feature positions, bytes read from matching nodes at each level, and the original value of the length field. Finally, the target protocol type is locked, and protocol identification will not be re-executed for the frame until the parsing of the current frame is completed.

[0092] This step effectively reduces the probability of false hits, avoids repeated access to already read fields in the frame header during subsequent parsing stages, and reduces the total number of bytes read from the data stream and the number of accesses to the data buffer.

[0093] In actual industrial environments, data streams are not always composed of regular protocol frame sequences, which may lead to invalid anchor point matching. The preset offset window refers to the maximum matching depth threshold, expressed in relative offset bytes. This threshold is the maximum feature field depth required to distinguish all known protocols from each other, plus an appropriate safety margin. If the deepest feature field required to distinguish all supported protocols is located 32 bytes after the frame start, the preset offset window can be set to 40 bytes. When the value of the relative offset counter reaches the threshold of the preset offset window, if the candidate protocol set still contains more than one protocol, i.e., it fails to converge to a unique protocol, the current anchor point is determined to be an invalid anchor point.

[0094] The triggering conditions for invalid anchor point determination include: First, when the relative offset counter reaches the preset offset window, the number of candidate protocols is greater than 1, that is, convergence has not been completed within the allowed matching depth; Second, the size of the candidate protocol set is reduced to 0, that is, all candidate protocols are pruned at a certain level, meaning that the byte sequence at that position in the data stream does not match the characteristics of any known protocol; Third, the frame boundary check fails, that is, although the candidate protocol has converged, the length field value does not meet the frame length constraint.

[0095] The reset operation is as follows: the relative offset counter is reset to zero, returning it to the inactive state, and it will restart with a new reference position when the next anchor point is hit; the active flags of all protocols are reset to the valid state, enabling all comparison channels to resume participation in subsequent matching; candidate protocols are cleared, and the read matching results of each order and frame header parameter sets are cleared; after the reset is completed, the sliding window continues to slide forward in the data stream to search for the next frame start anchor point; the reset operation does not roll back the read position of the data stream, and the bytes that have been consumed will not be read again, and the search continues from the current data stream position.

[0096] For example, if an anchor feature of Ethernet type 0x8892 is detected at a certain position in the data stream, step-by-step matching is initiated; the candidate protocols include protocol P1 and protocol P2; after the first-order matching, both protocols P1 and P2 pass, and there are still 2 candidates; after the second-order matching, both still pass; when the relative offset counter reaches 40, the candidate size is still 2, and it is determined to be an invalid anchor; then a reset operation is performed, the relative offset counter is returned to zero, the active flags of protocols P1 and P2 are reset to valid, and the sliding slice search continues from the offset 41 bytes.

[0097] This step ensures that the protocol identification pipeline will not stall or deadlock when faced with abnormal data, noise, or an unconfigured protocol, ensuring the unidirectionality of data stream processing. After the frame boundary check passes, the target protocol type is determined, configuration data is loaded, and a hardware parser adapted to the protocol is formed in the reconfigurable area. The frame header parameter set is passed to the hardware parser as the parsing start condition.

[0098] S2. Based on the target protocol type, load the corresponding configuration data from the preset protocol configuration data into the reconfigurable area, and form a hardware parser adapted to the target protocol type in the reconfigurable area.

[0099] Specifically, such as Figure 2 As shown, forming a hardware parser adapted to the target protocol type includes:

[0100] Load the configuration data corresponding to the target protocol type from the preset protocol configuration data into the reconfigurable area. The configuration data includes field processing rules, field dependencies and processing parameters.

[0101] Based on the field processing rules, determine the processing steps that need to be performed during message parsing, so that the hardware resources corresponding to the required processing steps in the reconfigurable area enter the working state, and the remaining hardware resources enter the off state.

[0102] Based on the dependencies between fields, establish data transfer paths between hardware resources that have entered the working state;

[0103] The processing parameters are injected into the hardware resources that are already in operation and have established a data transmission path, forming a hardware parser that is compatible with the target protocol type.

[0104] The field processing rules include the relative offset position of the field in the protocol frame, the field extraction bit width, and the field verification conditions. The field verification conditions include the verification enable flag and the verification calculation range. The field dependency relationship includes the constraint relationship between the parsing result of the preceding field and the extraction bit width of the subsequent field. The processing parameters include the field identifier, the expected value, and the verification method.

[0105] Each industrial protocol's frame format has its own unique structural definition, including the number of fields, the position and width of each field, the logical relationship between fields, and verification rules. In a general hardware parsing framework, this format information cannot be hard-coded into the hardware logic; otherwise, whenever a new protocol needs to be supported, the hardware design must be modified and the layout and routing must be resynthesized, which is unacceptable in a continuous operating environment in an industrial field. A pre-stored configuration data index table is used, with the protocol identification signal as the key. Each key corresponds to the starting address and data length of a set of configuration data in the on-chip memory. When the protocol identification signal is output during the protocol identification phase, the corresponding starting address and data length are looked up in the index table using this signal as the key. Subsequently, the configuration data is read from the on-chip memory and transferred to the configuration register group in the reconfigurable area.

[0106] The field processing rules define the structural attributes of each field in the protocol. Taking Modbus TCP as an example, the relative offset of the first field (transaction identifier) ​​is 0 bytes, and the field extraction bit width is 2 bytes; the relative offset of the second field (protocol identifier) ​​is 2 bytes, and the field extraction bit width is 2 bytes; the relative offset of the third field (length) is 4 bytes, and the field extraction bit width is 2 bytes; the relative offset of the fourth field (unit identifier) ​​is 6 bytes, and the field extraction bit width is 1 byte; the relative offset of the fifth field (function code) is 7 bytes, and the field extraction bit width is 1 byte; the relative offset of the sixth field (data) is 8 bytes, and the field extraction bit width is variable.

[0107] The relative offset position refers to the byte offset of the first byte of the field from the starting position of the data to be parsed. The data to be parsed starts from the first byte of the MBAP header, so the relative offset position of the transaction identifier is 0, the relative offset position of the protocol identifier is 2, and so on. The field extraction bit width refers to the number of bytes that need to be read when extracting the field from the data stream. For fixed-length fields, this value is a constant. For variable-length fields, this value is unknown before parsing and needs to be dynamically determined based on the parsing results of other fields. In this case, the field processing rules mark this value as variable-length, and the specific calculation logic is defined by the dependency relationship between fields.

[0108] The field validation conditions define the validation attributes of each field. The validation enable flag is a Boolean value; 1 indicates that the field needs to be validated, and 0 indicates that validation is skipped. The validation calculation range defines the byte range covered by the validation operation, expressed as an offset relative to the starting position of the field and the coverage length. In this embodiment of Modbus TCP, the validation enable flag for the first field (transaction identifier) ​​is 0 because the transaction identifier is a sequence number assigned by the communication initiator and there is no fixed expected value or validation rule. The validation enable flag for the second field (protocol identifier) ​​is 1, and the validation calculation range covers the two bytes of this field itself because the Modbus TCP protocol stipulates that the protocol identifier field must be fixed at 0x0000, and these two bytes need to be precisely compared and validated. The validation enable flag for the third field (length) is 1, and the validation calculation range covers the two bytes of this field itself, requiring frame length constraint validation on the length value. The validation enable flag for the fourth field (unit identifier) ​​is 0. The validation enable flag for the fifth field (function code) is 0. The validation enable flag for the sixth field (data) is 0.

[0109] The dependencies between fields are stored in the form of rule entries. Each rule defines a constraint of a preceding field on subsequent fields. In the Modbus TCP of this embodiment, there is a dependency rule: the parsing result of the third field (length) constrains the extraction bit width of the sixth field (data). The specific value of the length field represents the number of bytes from the unit identifier to the end of the PDU, that is, the sum of the number of bytes of the unit identifier (1 byte) plus the function code (1 byte) plus the data field. Therefore, the extraction bit width of the data field = the value of the length field - 2, that is, the number of bytes of the unit identifier and the function code.

[0110] The processing parameters define the numerical values ​​and algorithm identifiers required for runtime for each field; the field identifier is a number assigned to each field, used to reference the parsing result of that field during the parsing process; the expected value is the comparison benchmark data in this verification operation, which is only valid when the verification enable flag is 1; the verification method is the algorithm type identifier of the verification operation; in the Modbus TCP of this embodiment, the field identifier of the second field (protocol identifier) ​​is F002, the expected value is 0x0000, and the verification method is exact match, that is, the extracted raw byte data is compared bit by bit with the expected value; the field identifier of the third field (length) is F003, the expected value is defined as the upper and lower bounds of the legal range (minimum value 2, maximum value 253, where 2 is the minimum PDU length, that is, 1 byte for the unit identifier plus 1 byte for the function code, and 253 is the maximum PDU length), and the verification method is range comparison, that is, the extracted value is greater than or equal to the minimum value and less than or equal to the maximum value; the remaining fields are not used because the verification enable flag is 0, and the expected value and verification method fields are not used, and can be filled with any default value.

[0111] For example, the frame format of Profinet RT is quite different from that of Modbus TCP. Its fields include FrameID (2 bytes, relative offset 0), CycleCounter (2 bytes, relative offset 2), and several time slot data fields (the relative offset and width change dynamically with the network topology). The dependencies between fields in Profinet RT involve multiple rules. For example, the value of FrameID determines the number and width of subsequent time slot data fields. Although the value of CycleCounter does not directly affect the field width, it may need to be compared with the CycleCounter of the previous frame to detect frame loss.

[0112] This step abstracts the protocol format information into structured configuration data, decoupling the hardware parser formation process from the specific protocol format.

[0113] The reconfigurable area is pre-configured with various hardware resource units with different functions. Each unit implements a certain type of processing operation in the parsing process. At any given time, not all hardware resource units need to be in working state, as keeping unnecessary hardware resources in working state will consume dynamic power consumption. Specifically, it iterates through all field entries of the field processing rules in the configuration data, checks the attribute characteristics of each field, and determines which types of processing operations are required during the message parsing process. If at least one field has a fixed extraction bit width or is marked as variable length, then the field extraction processing step is necessary. If at least one field has a verification enable flag of 1, then the verification calculation processing step is necessary. If the dependency relationship part between fields is not empty, that is, there is at least one dependency rule, then the dependency relationship processing step is necessary.

[0114] Taking Modbus TCP as an example, after traversing the processing rules of the six fields, the following judgments are made: five of the extracted bit widths of the six fields are fixed values ​​and one is variable length, therefore the field extraction processing step is necessary; two of the six fields (protocol identifier and length) have their verification enable flag set to 1, therefore the verification calculation processing step is necessary; there is a rule for the dependency relationship between the fields, therefore the dependency relationship processing step is necessary; based on the judgment results of the processing step, the resource units that need to be enabled are set to the working state, and the resource units that do not need to be enabled are set to the closed state; in Modbus TCP, the resource units for field extraction are enabled (because all six fields need to be extracted), the resource units for verification calculation are enabled (because there are fields that need to be verified), and the resource units for dependency processing are enabled (because there are dependencies between the fields).

[0115] The number of hardware resources enabled is directly related to the number of fields in the target protocol. Modbus TCP requires six hardware resource units for its six fields; if the target protocol contains twenty fields, then twenty hardware resource units are required. The number of pre-configured hardware resources in the reconfigurable area should not be less than the maximum number of fields in all protocols. Unused resource units are kept off and do not consume dynamic power.

[0116] This step makes the system's dynamic power consumption proportional to the actual needs of the current parsing protocol. For simple protocols with few fields or no need for verification, a large number of hardware resources are kept off, while dynamic power consumption and static leakage power consumption are eliminated. This is suitable for power-sensitive industrial field equipment.

[0117] Each activated resource unit is physically an independent functional block, and there is no data connection between them in the default state. The dependencies between fields of different protocols are different, so the topology of the forward value transmission path is also different. The establishment of the data transmission path depends on the programmable interconnect resources in the reconfigurable area. The resource units in the reconfigurable area are connected by a set of programmable multiplexers and interconnect segments. The selection input of each multiplexer is controlled by the path configuration bit in the configuration register group. By writing specific values ​​to these path configuration bits, the data path between any two hardware resources can be selectively connected or disconnected.

[0118] Based on the relative offset positions of each field in the field processing rules, the resource units are connected in series to establish a data transmission path. Specifically, the input of the first resource unit is connected to the input data stream port, and its output is connected to the subsequent processing path of the first field. The verification enable flag determines whether the data is sent to the verification calculation unit or directly to the output buffer. At the same time, the output of the first resource unit is also connected to the input control terminal of the second resource unit, so that the second resource unit can know the extraction completion status and extraction end position of the first field. This process is repeated to form a field extraction chain. The data stream flows through each resource unit in sequence on this chain. Each resource extracts the data of the corresponding field from the data stream according to its own relative offset position and extraction bit width, and then passes the remaining data stream and the updated offset reference to the next hardware resource.

[0119] Based on the dependencies between fields, a path is established between the output of the resource unit triggering the source field and the parameter input of the resource unit of the target field. In Modbus TCP, there is a dependency rule that the parsing result of the third field (length) constrains the extraction bit width of the sixth field (data). Therefore, the output of the third field resource unit is connected to the bit width parameter input of the sixth field resource unit. Specifically, the output of the third field resource unit is connected to the input of a path selector via an interconnecting line segment. The output of this selector is connected to the bit width parameter register of the sixth field resource unit. The selection input of the path selector is controlled by the corresponding path configuration bit in the configuration register group. After the path configuration bit is set to the connected state, the extraction result of the third field can be transmitted to the bit width parameter input of the sixth field resource unit in real time.

[0120] For protocols without inter-field dependencies, such as simple protocols where all fields are of fixed length and there are no logical constraints between fields, no transmission path needs to be established. Although the resource unit for dependency processing may have been enabled (as a preventative measure), its internal prevalue catcher and parameter calculation logic will not be connected to any resource unit and will remain in standby mode.

[0121] This step enables the same set of hardware resource units to form different data flow topologies based on the relationships between fields in different protocols, ensuring that each field is extracted sequentially according to the physical order within the frame. The starting position of each field extraction is naturally determined by the ending position of the previous field extraction. The target field's parameter input is reached within the next clock cycle after extraction, with a constant transmission delay of one clock cycle's interconnection delay. It does not go through any intermediate buffer or bus arbitration, thus meeting the real-time requirements of protocol parsing.

[0122] The aforementioned hardware resource units are enabled and data transmission paths are established, but the specific operating parameters of each resource unit are still undefined. The processing parameters are organized in field order, with each field's parameter occupying one or more register positions. The injection process proceeds sequentially according to the field order, that is, the processing parameter of the first field is read from the configuration register group and written to the parameter register of the first resource unit via the parameter write bus; then the processing parameter of the second field is read and written to the parameter register of the second resource unit; and so on, until the parameters of all fields are injected.

[0123] Taking Modbus TCP as an example, in the first field (transaction identifier), field identifier F001 is written to the identifier register of the first resource unit, relative offset position 0 is written to the offset register of the first resource unit, and extracted bit width 2 is written to the bit width register of the first resource unit. The verification enable flag is 0, and no valid values ​​are written to the expected value register and the verification mode register (keeping the default). The verification calculation unit is not configured to perform verification operations on this field. In the second field (protocol identifier), field identifier F002 is written to the identifier register of the second resource unit, relative offset position 2 is written to the offset register, and extracted bit width 2 is written to the bit width register. The verification enable flag is 1, the expected value 0x0000 is written to the expected value register of the verification calculation unit, the encoded value of the verification mode "exact match" is written to the mode selection register of the verification calculation unit, and the verification calculation range (covering the 2 bytes of this field itself) is written to the range register of the verification calculation unit.

[0124] In the third field (length), the field identifier F003 is written to the identifier register of the third resource unit, the relative offset position 4 is written to the offset register, the extracted bit width 2 is written to the bit width register, the verification enable flag is set to 1, the upper and lower bounds of the expected value range (minimum value 8, maximum value 260) are written to the range register of the verification calculation unit, and the encoded value of the verification method "range comparison" is written to the mode selection register. The injection process of the fourth field (unit identifier) ​​and the fifth field (function code) is similar to that of the first field, only the field identifier, offset position and extracted bit width are injected, and no verification parameters are configured.

[0125] In the sixth field (data), the field identifier F006 is written to the identifier register of the sixth resource unit, and the relative offset position 8 is written to the offset register. The extracted bit width is marked as variable length. Therefore, the value of the bit width register is not statically injected by the configuration data, but is obtained in real time from the output of the third field resource unit by the data transmission path. That is, after the third field resource unit parses the actual value of the length field at runtime, it subtracts the constant 2 (determined by the constraints in the field dependency relationship) from the value and writes the result to the bit width register of the sixth resource unit through the data transmission path. The verification enable flag is 0, and no verification parameters are configured.

[0126] After all parameters are injected, each hardware resource obtains its working parameters in the current protocol parsing, ultimately forming a hardware parser; this achieves the binding of hardware resource functions with protocol parameters, giving hardware resource units a clear working objective; once the hardware parser is formed, it can begin to receive input messages and parse them field by field.

[0127] S3. The input message is parsed field by field by the formed hardware parser. The bit width of the subsequent field extraction and the verification calculation range are adjusted according to the value of the parsed field. The parsing result is temporarily stored in the hardware buffer.

[0128] Furthermore, parsing the input message field by field includes:

[0129] The hardware parser extracts the original data of the field to be parsed from the relative offset position of the field to be parsed in the field processing rules and the field extraction bit width.

[0130] The original data of the field to be parsed is compared with its corresponding expected value, and the verification calculation within the corresponding verification calculation interval is started synchronously when the verification enable flag of the field to be parsed is valid.

[0131] Write the parsing result of the current field to be parsed into the hardware buffer and record the value of the parsed field.

[0132] Protocol frame parsing involves extracting a specified length of byte sequence from a specified position in the input message as the raw data for that field. The input message arrives at the hardware parser as a continuous byte stream, with each field arranged sequentially according to its physical order within the frame. Resource units in the hardware parser are connected in series according to the field order to form a data path. The byte data of the input message first enters the first resource unit. Each hardware resource maintains a byte counter, which starts from zero when the resource unit is activated and increments by 1 every clock cycle until the counter value equals the extraction bit width of the field, at which point the raw data of that field has been read.

[0133] Extraction from the relative offset position of the input message is specifically as follows: the relative offset position of the first field is zero, so the first resource unit immediately starts reading from the first byte of the input message after being activated; the relative offset position of subsequent fields is equal to the relative offset position of the previous field plus the extraction bit width of the previous field; when the resource unit completes processing, it passes the extraction completion signal and the start position information of the next byte to the next resource unit; the extracted raw data is temporarily stored in the field data register inside the resource unit in the form of a byte sequence, and is simultaneously sent to the verification calculation unit and the dependency processing unit.

[0134] Taking a Modbus TCP packet as an example, the parsing process starts from the first field, which is the transaction identifier. The first resource unit is activated, and the byte counter starts counting from zero. In the first clock cycle, the first byte 0x00 is read from the input packet, and the counter increments to 1. In the second clock cycle, the second byte 0x01 is read, and the counter increments to 2. The extraction bit width is 2, and the counter value equals the extraction bit width, indicating extraction is complete. At this time, the field data register of the first resource unit stores 2 bytes of original data 0x00 and 0x01. The first resource unit then sends an extraction completion signal and the starting position information of the next byte, i.e., offset position 2, to the second resource unit. The second resource unit is activated and begins to extract the second field (protocol identifier). In the first clock cycle, the byte 0x00 at offset 2 is read, and in the second clock cycle, the byte 0x00 at offset 3 is read, indicating extraction is complete. The field data register stores 2 bytes of original data 0x00 and 0x00.

[0135] The third field (length) is extracted by the third resource unit in the same way. After extraction, the field data register stores 2 bytes of original data 0x00 and 0x06. The extraction process of the fourth field (unit identifier, 1 byte) and the fifth field (function code, 1 byte) is similar, each taking one clock cycle to complete. The extraction bit width of the sixth field (data) is variable. Before the previous fields are parsed, its bit width register has not been assigned a value. Therefore, during the extraction of the first five fields in sequence, the sixth resource unit is in a waiting state, waiting for the data transmission path to inject a dynamically determined extraction bit width. When the parsing result of the third field (length) is transmitted to the sixth resource unit through the adjustment mechanism, the unit is activated and reads 0x00, 0x00, 0x00, and 0x06 in sequence according to the dynamically determined bit width of 4 bytes, starting from offset 8.

[0136] This step ensures that the extraction order of each field is consistent with the physical arrangement order of the fields in the protocol frame. The starting position of the extraction of each field is determined by the ending position of the extraction of the previous field, while ensuring that an incorrect extraction operation is not started prematurely when the extraction bit width is unknown.

[0137] Some fields in the protocol frame have fixed values ​​or legal value range constraints. Performing verification on these fields can detect messages with abnormal format or transmission errors during the frame parsing stage, avoiding the transmission of invalid messages to subsequent application layer processing logic. The condition for performing the verification operation is that the verification enable flag of the field is valid. When the original data extraction is completed and the verification enable flag is valid, the resource unit sends the original data to the verification calculation unit, and at the same time provides the expected value and verification method identifier corresponding to the field to the verification calculation unit.

[0138] Comparing the original data with the expected value means that the verification calculation unit selects the corresponding comparison algorithm according to the verification method identifier, uses the original data as the input data for comparison, uses the expected value as the benchmark data for comparison, performs the comparison operation, and outputs the verification result. The verification result is a Boolean value: pass or fail.

[0139] The verification calculation unit supports two basic comparison modes. The first is the exact matching mode, which performs a bitwise XOR operation on each byte of the original data and the corresponding byte of the expected value. If the XOR result of all bits is zero, the verification passes; otherwise, the verification fails. The second is the range comparison mode, which interprets the original data into a numerical value according to a predefined byte order and compares the numerical value with the upper and lower bounds of the range stored in the expected value. If the numerical value is within both the upper and lower bounds of the range, the verification passes; otherwise, the verification fails.

[0140] Synchronous startup of the corresponding verification calculation interval means that the verification calculation is not executed uniformly after all fields have been extracted, but rather it starts in the next clock cycle after the original data of each field has been extracted. When the verification calculation unit is performing the verification of the current field, the resource unit of the next field starts the extraction operation at the same time. The two are executed in parallel on the hardware and do not block each other. This ensures that the verification operation does not increase the overall parsing latency, and the clock cycle required for verification is covered by the clock cycle required for field extraction.

[0141] Taking a Modbus TCP packet as an example, the first field (transaction identifier) ​​is marked as invalid (0), so no verification operation is performed. The extraction of the second field begins in the next clock cycle after the extraction of the first field is completed. The second field (protocol identifier) ​​is marked as valid (1), the verification method is exact match, the expected value is 0x0000, the original data 0x00 and 0x00 are sent to the verification calculation unit, the verification calculation unit performs bitwise XOR to obtain the first byte as 0x00 and the second byte as 0x00, and the verification passes. The third field (length) is marked as valid. Valid (1), the verification method is range comparison, the upper and lower bounds of the range stored in the expected value are the minimum value 2 and the maximum value 253. The original data 0x00 and 0x06 are sent to the verification calculation unit. The verification calculation unit interprets the original data into a value in big-endian order: 0x00 is shifted left by 8 bits and then ORed with 0x06 to get the value 6. This value falls within the range of [2,253], and the verification passes. The verification enable flags of the fourth field (unit identifier) ​​and the fifth field (function code) are both invalid, and no verification operation is executed. The verification enable flag of the sixth field (data) is invalid, and no verification operation is executed.

[0142] If the verification passes, the parsing process seamlessly continues to the extraction of the next field; if the verification fails, exception handling begins while the extraction of the current field is still in progress, without waiting for all fields to be extracted before checking the verification results; the hardware implementation of the two comparison modes shares the same set of comparison logic resources, and the operation mode is distinguished only by the mode selection signal, avoiding the waste of resources to design hardware circuits for each verification mode.

[0143] The value of a parsed field refers to the specific numerical value interpreted from the original data according to the byte order and numerical encoding defined by the field. The resource unit combines the original data stored in the field data register, the verification result output by the verification calculation unit, and the field identifier into a parsed record and writes it into the hardware buffer at the position indexed by the field identifier. The hardware buffer adopts an organization method of addressing by field identifier. Each field occupies a fixed-size storage area in the buffer, and the area size is aligned with the maximum field width in all protocols.

[0144] For a field that is a source of inter-field dependency, the resource unit writes the original data to the hardware buffer and interprets the original data into a value according to the byte order defined by the field. The value is then written into the parsed value register inside the extraction unit. The parsed value register is connected to the target field resource unit through the data transmission path, so that the target field resource unit can obtain the value in the next clock cycle.

[0145] Taking a Modbus TCP packet as an example, the original data in the first field (transaction identifier) ​​is 0x00 and 0x01. The verification result is "not verified", the field identifier is F001, and the parsed record is {F001, 0x0001, not verified}. It is written to the position corresponding to F001 in the hardware buffer. This field is not the trigger source for any dependency relationship, and the operation of recording the parsed value is not executed. The original data in the second field (protocol identifier) ​​is 0x00 and 0x00. The verification result is "passed", the field identifier is F002, and the parsed record is {F002, 0x0000, passed}. It is written to the position corresponding to F002 in the hardware buffer. This field is not the trigger source for any dependency relationship, and the operation of recording the parsed value is not executed.

[0146] The original data in the third field (length) is 0x00 and 0x06. The verification result is "passed". The field identifier is F003, and the parsed record is {F003, 0x0006, pass}. It is written to the position corresponding to F003 in the hardware buffer. This field is the trigger source of the inter-field dependency relationship. Its parsing result constrains the extraction bit width of the sixth field (data). Therefore, the resource unit interprets the original data into a value in big-endian order: 0x00 is left-shifted by 8 bits and ORed with 0x06 to get the value 6. This value 6 is written into the parsed value register. The parsed value register is connected to the bit width parameter input terminal of the sixth resource unit through the data transmission path. The value 6 will be read by the sixth resource unit in the next clock cycle.

[0147] The parsing process for the fourth field (unit identifier) ​​and the fifth field (function code) is similar to that of the first field. After the parsed record is written to the hardware buffer, the operation of recording the parsed value is not executed. In the sixth field (data), the original data is 0x00, 0x00, 0x00, 0x06. The verification result is unverified. The field identifier is F006. The parsed record is {F006, 0x00000006, unverified}. It is written to the position corresponding to F006 in the hardware buffer. This field is not the trigger source for any dependency relationship. The operation of recording the parsed value is not executed.

[0148] This step enables the protocol conversion logic to directly locate the corresponding position in the hardware buffer and read the parsing result through the field identifier. The design of writing the verification result and the original data into the hardware buffer together allows the verification status of the field to be obtained at the same time when reading the parsing result, which is convenient for special handling of fields that fail verification during the protocol conversion stage. It realizes the single clock cycle value transfer from the source field to the target field triggered by the dependency relationship, so that the adjustment step starts immediately in the next clock cycle after the source field is parsed.

[0149] Specifically, adjusting the subsequent field extraction bit width and verification calculation range includes:

[0150] Calculate the adjusted field extraction bit width for the next field based on the values ​​of the currently parsed fields and their corresponding field dependencies.

[0151] Based on the adjusted field width, recalculate the relative offset positions of the next field and its subsequent fields in the protocol frame;

[0152] Based on the updated relative offset position and field extraction bit width, update the starting position and coverage of the verification calculation interval for subsequent fields;

[0153] Extract the bit width, relative offset position, and verification calculation range from the updated fields, and continue parsing subsequent fields.

[0154] Industrial protocols contain numerous inter-field dependencies, meaning that the extraction bit width of data fields cannot be statically determined before parsing begins. Instead, it can be dynamically calculated after the actual value of the length field is parsed. If the extraction bit width of subsequent fields is not adjusted, the hardware parser can only use the default values ​​in the configuration data to extract data fields, resulting in a mismatch between the number of extracted bytes and the actual data field length. Once the parsed value of a field is recorded, the adjustment logic checks whether the field is a trigger source in the inter-field dependency relationship. This is done by comparing the field identifier of the field with the trigger source field identifiers of all rule entries in the inter-field dependency relationship in the configuration data. If a match is found, the constraint type and parameters in the rule entry are read, and the corresponding arithmetic operations are performed based on the constraint type to calculate the adjusted extraction bit width of the target field.

[0155] In Modbus TCP, the parsed value of the third field is 6. The adjustment logic finds a matching dependency rule: the triggering source field is the third field (length), the target field is the sixth field (data), the constraint type is "extract bit width = source field value - constant", and the constant value is 2. The adjustment logic performs the arithmetic operation 6-2=4, and the result 4 is the extracted bit width of the sixth field after adjustment.

[0156] The data transmission path sends the parsed value 6 to the bit width parameter input of the sixth resource unit. Simultaneously, the constraint type code and constant value 2 in the dependency rule also reach the parameter calculation logic inside the sixth resource unit through the parameter path established during the configuration data injection phase. The parameter calculation logic selects the corresponding operation (subtraction in this case) based on the constraint type code, using the parsed value 6 as the minuend and the constant 2 as the subtrahend, performing the operation 6 minus 2 equals 4, and writing the result 4 into the bit width register of the sixth resource unit. This operation is completed within one clock cycle. After the bit width register is assigned a value, the waiting state of the sixth resource unit ends, and it begins reading data from the current data stream position according to a bit width of 4 bytes. For protocols without inter-field dependencies, or where the currently parsed field is not a trigger source for any dependency, this step does not perform any operation, and the parsing process directly proceeds to the extraction of the next field.

[0157] This step ensures that the transmission delay of the parsed value from the trigger source field extraction unit to the target field extraction unit is an interconnection delay of one clock cycle, thus minimizing the impact of dependency processing on the overall parsing delay.

[0158] In the protocol frame, the relative offset position of each field is equal to the sum of the relative offset position of the previous field and the extraction bit width of the previous field. When the extraction bit width of a certain field is adjusted due to dependencies, the relative offset positions of all subsequent fields will be affected. If the offset positions of subsequent fields are not recalculated, the subsequent fields will start extraction from the wrong position, resulting in the extracted data not being the expected field content but rather adjacent fields or padding data from outside the frame. When the extraction bit width of a certain field is adjusted, the adjustment logic updates the offset register of each field after that field in the field order. The update formula is: relative offset position of the (N+1)th field = relative offset position of the Nth field + adjusted extraction bit width of the Nth field. This formula is recursively executed level by level for the entire chain of subsequent fields from the adjusted field to the last field.

[0159] In Modbus TCP, the sixth field (data) is the last field, and there are no more fields after it. Therefore, adjusting the extraction bit width will not trigger the recalculation of the offset position of subsequent fields. This is a simplified case in scenarios with only a single dependency and the target field is the last field.

[0160] For example, a protocol's frame format includes field A (fixed 2 bytes, relative offset 0), field B (variable length, relative offset 2), field C (fixed 1 byte, offset depends on the width of field B), and field D (variable length, offset depends on the position of field C). The dependencies between fields are: the value of field A determines the extracted bit width of field B, the extracted bit width of field B determines the relative offset position of field C, and the value of field C determines the extracted bit width of field D. Suppose that the parsed value of field A causes the extracted bit width of field B to be adjusted from the default 4 bytes to 8 bytes; specifically, the relative offset of field B... The shift position remains unchanged (still 2, because the extraction bit width of field A remains the same), but the extraction bit width of field B changes from 4 to 8; the relative offset position of field C needs to be recalculated, that is, the offset of field A 0 + the bit width of field A 2 + the original bit width of field B 4 = 6, after adjustment it is 0 + 2 + 8 = 10, the offset increases by 4 bytes; the relative offset position of field D also needs to be recalculated, the original value is 6 + the bit width of field C 1 = 7, after adjustment it is 10 + 1 = 11, the offset also increases by 4 bytes; it can be seen that the change in the bit width of field B causes a cascading offset of 4 bytes in the offset positions of fields C and D.

[0161] After updating the bit width register of field B, the adjustment logic immediately triggers a cascading update pipeline. This pipeline accesses the offset registers of fields C and D sequentially according to field order, updating the offset register value of each field to the offset register value of the previous field plus the bit width register value of the previous field. Since the bit width register has just been updated, the offset register uses the adjusted bit width value. The cascading update pipeline completes the offset update of all subsequent fields within one clock cycle.

[0162] This step ensures that after any field's extraction bit width changes, the offset positions of all subsequent fields can correctly reflect the actual frame structure, so that the update delay does not increase with the number of subsequent fields, and the offset registers of all fields are updated in parallel within the same clock cycle.

[0163] When the relative offset position or extraction bit width of a field changes due to dependency adjustments, if the verification calculation interval of the field marked as valid covers the range of the changed field, or if the field itself is the changed field, the verification calculation interval needs to be updated synchronously to reflect the new position and range. If the verification calculation interval is not updated accordingly, the verification operation will be performed on an incorrect byte range, resulting in an incorrect verification result. For each field marked as valid, the adjustment logic checks whether its verification calculation interval is affected by the offset or bit width change of the preceding field. If the byte range covered by the verification calculation interval intersects with the range of any field whose offset has changed, the verification calculation interval needs to be updated. The update method is to add the sum of the offset changes of all fields located before the verification interval to the starting position of the verification calculation interval. The coverage of the verification calculation interval remains unchanged or is adjusted proportionally according to the change in extraction bit width.

[0164] In Modbus TCP, the fields that need to be checked are the second field (protocol identifier, exact match check, covering itself by 2 bytes) and the third field (length, range comparison check, covering itself by 2 bytes). Both of these fields are located before the adjusted sixth field (data), and their offset position and extraction bit width have not changed due to the adjustment, so their check calculation range does not need to be updated.

[0165] The hardware implementation of the update is similar to the cascaded update of the offset position. After the offset position update is completed, the adjustment logic traverses all the check interval registers of the fields marked as valid and performs the update operation on the interval registers affected by the offset change. This traversal and update is completed within one clock cycle.

[0166] This step ensures that the validation operation is always performed within the correct byte range in scenarios where the field width changes dynamically, without introducing additional clock cycle delay, and is completed within the same clock cycle as the offset position update.

[0167] After the adjustment is completed, the extraction bit width of the affected fields, the relative offset position of subsequent fields, and the verification calculation interval have all been updated to the correct values ​​reflecting the actual structure of the current frame. The hardware parser needs to continue parsing the unprocessed fields with the updated parameters until all fields are parsed. The updated register values ​​(bit width register and offset register of the extraction unit, and interval register of the verification calculation unit) are sampled by the extraction unit and the verification calculation unit on the rising edge of the next clock cycle as working parameters for subsequent parsing operations. The resource unit uses the new offset position to locate the starting byte of the field from the input data stream and uses the new bit width to control the termination value of the byte counter. The verification calculation unit uses the new verification calculation interval to determine the byte range covered by the comparison operation.

[0168] Taking a Modbus TCP packet as an example, after the third field (length) is parsed, its parsed value 6 reaches the sixth resource unit through the previous value transmission path; the adjustment logic calculates that the extraction bit width of the sixth field is 4 bytes; since the sixth field is the last field, there is no need to update any offset position or check calculation range; within the same clock cycle of the above adjustment steps, the extraction operations of the fourth field (unit identifier) ​​and the fifth field (function code) have been started and completed in sequence according to the serial link structure of the main data path, and their offset positions and extraction bit widths have not changed due to the adjustment, and the extraction process is the same as described above; 1 byte (0x01) is extracted from the fourth field, and 1 byte (0x03) is extracted from the fifth field. The check enable flags of both are invalid, no check operation is performed, and the parsed record is written to the hardware buffer.

[0169] When the bit width register of the sixth field (data) is assigned a value of 4, the sixth resource unit is activated. In the timing arrangement of this embodiment, the activation time of the sixth resource unit may overlap with or be slightly delayed from the extraction completion time of the fifth field. After the sixth resource unit is activated, it immediately starts reading data from offset 8. The first clock cycle reads 0x00, the second reads 0x00, the third reads 0x00, and the fourth reads 0x06. After the bit width counter reaches 4, the extraction is completed, the verification enable is marked as invalid, and no verification operation is performed. The parsed record {F006, 0x00000006, unverified} is written to the hardware buffer. At this point, all six fields of the Modbus TCP packet have been parsed, and the complete parsing result is stored in the hardware buffer.

[0170] This step reduces the design complexity of the hardware control logic and makes the timing behavior of the parsing process highly predictable. After all fields are parsed, the hardware buffer stores the original data, verification results and field identifiers of each field; the verification results recorded in the hardware buffer provide data quality information for subsequent processing.

[0171] S4. If protocol conversion is to be performed, the parsing result is read from the hardware buffer according to the protocol conversion rules, the data mapping and transformation from the source protocol to the target protocol is performed, the target protocol data frame is assembled and output.

[0172] Furthermore, assembling the target protocol data frame includes:

[0173] If protocol conversion is performed, the parsed input message is taken as the source protocol. The mapping relationship between the source protocol fields and the target protocol fields is determined according to the protocol conversion rules, as well as the assembly order of the data fields, length fields and check fields in the target protocol data frame. In the assembly order, the length field and check field are placed after all the data fields.

[0174] According to the assembly order, the parsing results of the source protocol fields are read from the hardware buffer in turn. After data mapping and transformation according to the mapping relationship, the data is written to the relative offset position of the corresponding field in the target protocol data frame. At the same time, the frame length of the target protocol data frame is accumulated field by field and the accumulated verification value is updated synchronously.

[0175] After all data fields are assembled, the accumulated frame length is written to the position of the length field, and the accumulated check value is written to the position of the check field, thus completing the assembly and output of the target protocol data frame.

[0176] Specifically, data mapping and transformation based on mapping relationships include:

[0177] When the byte order of the source protocol field and the target protocol field are inconsistent, perform byte order transformation on the value of the parsed field;

[0178] When the numerical representation ranges of the source protocol field and the target protocol field are different, numerical scaling is performed on the values ​​of the parsed fields;

[0179] When multiple source protocol fields correspond to a single field in the target protocol, the values ​​of the multiple parsed fields are merged according to a preset merging rule;

[0180] When a source protocol field corresponds to multiple fields of the target protocol, the values ​​of the parsed fields are split according to a preset splitting rule.

[0181] The frame structures of the source protocol and the target protocol usually differ significantly. Using the parsed input message as the source protocol means that the parsing results of each field are stored in the hardware buffer. Each field in the hardware buffer is stored with a field identifier as an index, containing the original data and verification result of that field. The parsing results are read from the hardware buffer field by field through the field identifier, without backtracking to the input data stream to read the original message repeatedly. Determining the mapping relationship between the source protocol fields and the target protocol fields according to the protocol conversion rules means that a set of mapping entries is configured by the user or the host computer. Each mapping entry defines the correspondence between a field in the source protocol (specified by a field identifier) ​​and a field in the target protocol (specified by the relative offset position and byte width within the target frame), as well as the data transformation types and transformation parameters that may need to be performed between the two.

[0182] Taking the conversion from Modbus TCP to Profinet RT as an example, after the Modbus TCP fields are parsed, they are stored in the hardware buffer. The field identifiers and semantics of each field are as follows: F001 is the transaction identifier (2 bytes), F002 is the protocol identifier (2 bytes), F003 is the length (2 bytes), F004 is the unit identifier (1 byte), F005 is the function code (1 byte), and F006 is the data field (variable length, 4 bytes in this embodiment). The fields that need to be assembled in the Profinet RT frame structure include FrameID (2 bytes, relative offset 0), CycleCounter (2 bytes, relative offset 2), data payload (variable length, relative offset 4), frame-level length field (2 bytes, located at a fixed position at the end of the frame or the beginning of the frame, depending on the specific Profinet RT frame subtype), and frame-level check field (4 bytes CRC-32, located at the end of the frame).

[0183] The first mapping maps the source field F001 (Modbus TCP transaction identifier) ​​to the target field FrameID (Profinet RT), with a pass-through transformation type, meaning the value is not changed and it is written directly. The second mapping maps the source field F006 (Modbus TCP data field) to the target field data payload (Profinet RT), with a pass-through transformation type. Among them, F002 (protocol identifier), F003 (length), F004 (unit identifier), and F005 (function code) in the source protocol are control fields specific to the Modbus TCP protocol. There are no semantically equivalent fields in the Profinet RT frame format, so these fields do not participate in the mapping.

[0184] Determining the assembly order of data fields, length fields, and check fields in a target protocol data frame means arranging all fields that need to be assembled into an ordered sequence based on the computational dependencies between the fields in the target protocol frame. The basic principle of the arrangement is to assemble all data fields first, i.e., the fields that carry the actual application data, then assemble the length field, and finally assemble the check field.

[0185] For example, the assembly order of the target protocol Profinet RT is determined as follows: first assemble FrameID (one of the data fields), second assemble CycleCounter (one of the data fields), third assemble data payload (one of the data fields), fourth assemble the length field (after all data fields), and fifth assemble the check field (after the length field).

[0186] This step enables the protocol conversion rules to be dynamically configured and updated by the user or host computer during system operation. When the equipment configuration changes in the industrial field, only the content of the mapping entries needs to be updated to adapt to the new conversion requirements. The assembly order ensures that the fields of the overall content of the two dependent frames have a data basis during assembly.

[0187] Each field of the target protocol data frame needs to be filled in sequentially according to the assembly order. For data fields with corresponding source fields, the filling content comes from the parsing result of the source field after data transformation. For length fields and check fields without corresponding source fields, the filling content comes from the intermediate results accumulated during the assembly process. Reading the parsing result of the source protocol fields from the hardware buffer sequentially means that the assembly logic obtains the source field identifier corresponding to the target field from the mapping entry for each field with a corresponding source field in the assembly order, and then reads the parsing record from the hardware buffer using the source field identifier as the address. The read operation obtains the complete parsing record written to the hardware buffer, which includes the original data and the check result.

[0188] Data mapping and transformation based on mapping relationships refers to performing corresponding transformation operations on the raw data read from the hardware buffer according to the transformation type and transformation parameters defined in the mapping entry. The first is byte order transformation. When the byte order of the source protocol field and the target protocol field are inconsistent, byte order swapping is performed on the raw data. Byte order refers to the order in which multi-byte values ​​are arranged in memory or during transmission. The Modbus TCP protocol uses big-endian (the most significant byte is at the lowest address), while the Profinet RT protocol also uses big-endian for some fields and may use little-endian for others.

[0189] Taking the first mapping as an example, the source field F001 (Modbus TCP transaction identifier, 2 bytes, big-endian) is mapped to the target field FrameID (Profinet RT). If the target protocol's FrameID field is defined as big-endian, the byte order of the source and target fields is consistent, and no byte order conversion is required. The original data 0x00 and 0x01 are directly written to the target frame offset 0. If the target protocol's FrameID field is defined as little-endian, the two bytes of the original data need to be swapped before writing. The original data 0x00 and 0x01 become 0x01 and 0x00 after byte order conversion and are written to the target frame offset 0.

[0190] The second is numerical scaling. When the numerical representation ranges of the source protocol field and the target protocol field are different, the numerical values ​​of the original data are linearly scaled; that is, target value = source value × scaling factor + offset. The scaling factor and offset are stored as transformation parameters in the mapping entry. For example, in Modbus TCP, the temperature data represented by a certain register value is in units of 0.1 degrees Celsius (the numerical range is 0 to 10000, corresponding to 0 to 1000 degrees Celsius), while the corresponding process data in Profinet RT is in units of 0.01 degrees Celsius (the numerical range is 0 to 100000, corresponding to 0 to 1000 degrees Celsius). In this case, the scaling factor is 10 and the offset is 0. For mapping entries that do not require numerical scaling, the scaling factor is set to 1 and the offset is set to 0.

[0191] Third is many-to-one merging. When multiple source protocol fields correspond to a single field in the target protocol, the values ​​of the multiple source fields are merged according to a preset merging rule and then written to the target field. The merging rule can be byte concatenation, which concatenates the original data of multiple fields into a longer byte sequence in sequence, or arithmetic operations, including performing addition, bitwise OR, or other operations on the values ​​of multiple fields. For example, in Modbus TCP, there are two consecutive register value fields F010 (2 bytes, representing the high 16 bits of the process variable) and F011 (2 bytes, representing the low 16 bits of the process variable), which correspond to a 4-byte process variable field in the target protocol. The merging rule is byte concatenation, where the 2 bytes of F010 are used as the high 2 bytes of the target field, and the 2 bytes of F011 are used as the low 2 bytes of the target field, concatenated into 4 bytes and written to the target frame.

[0192] Fourth is one-to-many splitting. When a source protocol field corresponds to multiple fields of the target protocol, the source field value is split according to a preset splitting rule and written to multiple target fields respectively. The splitting rule includes byte segmentation, that is, splitting the byte sequence of the source field into multiple subsequences according to fixed positions, or bit field extraction, that is, extracting multiple subfields from the value of the source field according to bit positions. For example, in Modbus TCP, a 4-byte register value field contains two process variables, the high 2 bytes represent temperature and the low 2 bytes represent pressure. The target protocol needs to write these two process variables into two 2-byte fields respectively. The splitting rule is byte segmentation, the first 2 bytes of the source field are written into the temperature field of the target protocol, and the last 2 bytes are written into the pressure field of the target protocol.

[0193] In the Modbus TCP to Profinet RT conversion of this embodiment, the first mapping (F001 to FrameID) is a byte order conversion (assuming a big-endian to little-endian conversion is required); the second mapping (F006 to data payload) is a pass-through (no conversion is performed), and the 4 bytes of original data 0x00, 0x00, 0x00, 0x06 in the data field are directly written to the target frame offset 4.

[0194] Simultaneously accumulating the frame length of the target protocol data frame field by field and synchronously updating the check accumulation value means that when assembling each field, the assembly logic performs two parallel accumulation operations. The first accumulation operation is frame length accumulation, which adds the byte width of the currently assembled field to the frame length accumulation register. Initially, the frame length accumulation register is zero. After assembling each field, the register increments, and the value of the register after all fields are assembled is the total number of bytes in the entire target frame. The second accumulation operation is check accumulation value update, which sends the original byte data of the currently assembled field byte by byte into the accumulation calculation logic of the check algorithm, updating the value of the check accumulation register. The check algorithm is determined according to the check specification of the target protocol, such as the CRC-32 algorithm in Profinet RT. The CRC-32 accumulation calculation logic performs a polynomial division intermediate step on each input byte and outputs the updated 32-bit CRC value. Initially, the check accumulation register is set to the initial value of the CRC-32 algorithm (usually 0xFFFFFFFF), and is updated once after each input byte. After all the byte data of all fields have been input, the value in the check accumulation register is the CRC-32 check result of the entire frame.

[0195] Taking the Modbus TCP to Profinet RT conversion as an example, assume the parsing result of the source protocol Modbus TCP is F001 transaction identifier 0x00, 0x01, and F006 data field 0x00, 0x00, 0x00, 0x06. First, assemble the first field FrameID, and find the source field identifier corresponding to FrameID from the mapping entry, which is F001. Read the original data 0x00, 0x01 from the F001 position in the hardware buffer, and transform it into byte order (big-endian to little-endian). The transformed data is 0x01, 0x00. Write 0x01, 0x00 to the target frame offset 0 position, and increment the frame length accumulation register from 0 to 2 (FrameID width is 2 bytes). The check accumulation register starts from the initial value 0xFFFFFFFF, and after inputting byte 0x01, it is updated to a new intermediate CRC value. After inputting byte 0x00, it is updated to another new intermediate CRC value.

[0196] Then, the second field, CycleCounter, is assembled. In this embodiment, the Profinet RT CycleCounter field does not have a directly corresponding source protocol field; its value is generated based on the specific conversion strategy, i.e., it is automatically generated by the internal frame counter, incrementing once for each assembled target protocol frame. Assuming the current CycleCounter value is 0x00 and 0x0A, 0x00 and 0x0A are written to the target frame offset 2. The frame length accumulation register increments from 2 to 4 (CycleCounter width is 2 bytes). After verifying the accumulation register input with 0x00 and 0x0A, the process continues. Update; then assemble the third field data payload. Find the source field identifier corresponding to the data payload in the mapping entry, which is F006. Read the original data 0x00, 0x00, 0x00, 0x06 from the hardware buffer at position F006. The transformation type is pass-through, and the data remains unchanged. Write 0x00, 0x00, 0x00, 0x06 to the target frame offset 4. The frame length accumulation register is incremented from 4 to 8 (data payload width is 4 bytes). After inputting 0x00, 0x00, 0x00, 0x06 into the verification accumulation register in sequence, continue updating.

[0197] At this point, all data fields are assembled, and the frame length accumulation register has a value of 8, representing the total number of bytes in all data fields of the target frame. The check accumulation register stores the intermediate value of the CRC-32 algorithm after processing all data field bytes. This ensures that the values ​​of the length field and the check field are naturally generated after all data fields are assembled, eliminating the time overhead of the last two traversals and the extra reading operations on the frame buffer.

[0198] The values ​​of the length field and the check field depend on the content of the entire frame, so they cannot be determined before the data fields are assembled. After all the data fields are assembled, the frame length accumulation register and the check accumulation register already contain all the information needed to calculate these two fields. The position where the accumulated frame length is written to the length field refers to the relative offset position of the frame length accumulation register value in the length field of the target frame according to the byte order and byte width defined by the target protocol.

[0199] Taking a Profinet RT real-time data frame as an example, the length information is usually contained in a fixed field in the frame header, and its value represents the number of bytes of the data payload. Assuming that in this embodiment, the length field is located at offset 8 in the target frame (immediately after the data payload), with a width of 2 bytes and big-endian byte order; the frame length accumulation register has a value of 8 after the data field is assembled (representing 4 bytes of data payload plus 2 bytes of FrameID plus 2 bytes of CycleCounter, depending on the number of bytes of which fields are included in the semantic definition of the length field); if the semantics of the length field only refers to the length of the data payload, then the number of bytes of the data payload, 4, should be written instead of the cumulative total length of 8; this embodiment assumes that the semantics of the length field is the length of the data payload, so the value 4 is encoded as 0x00, 0x04 in big-endian byte order and written to offset 8 in the target frame; the write operation consumes one clock cycle; after the frame length accumulation value is written, the content of the frame length register no longer changes.

[0200] It should be noted that the bytes of the length field itself also need to participate in the calculation of the check accumulation value; therefore, while writing the length value into the target frame, the two bytes of data 0x00 and 0x04 of the length field are also sent into the CRC-32 accumulation calculation logic, and the check accumulation register continues to be updated based on the original intermediate value.

[0201] The position where the accumulated check value is written to the check field refers to the final processing step of the CRC-32 algorithm after the check accumulation register has received all the bytes of the length field. The value in the register is XORed bit by bit with the final XOR value 0xFFFFFFFF to obtain the final CRC-32 check result. This result is encoded into 4 bytes of data according to the byte order defined by the target protocol (usually little-endian) and written to the end of the target frame. In this embodiment, it is assumed that the final CRC-32 value after the accumulation calculation of all bytes is 0x12345678, which is encoded into 0x78, 0x56, 0x34, and 0x12 in little-endian order and written to the target frame offset 10 (assuming that the target frame is immediately after the length field and then the check field). The write operation consumes one clock cycle.

[0202] The assembled Profinet RT target frame contains the following: Offsets 0 to 1 are FrameID, with values ​​of 0x01 and 0x00 (Modbus TCP transaction identifier after byte order conversion); Offsets 2 to 3 are CycleCounter, with values ​​of 0x00 and 0x0A (frame counter generation); Offsets 4 to 7 are data payload, with values ​​of 0x00, 0x00, 0x00, and 0x06 (Modbus TCP data field pass-through mapping); Offsets 8 to 9 are length fields, with values ​​of 0x00 and 0x04 (data payload length); Offsets 10 to 13 are check fields, with values ​​of 0x78, 0x56, 0x34, and 0x12 (CRC-32 check result), and the total frame length is 14 bytes.

[0203] The assembly and output of the target protocol data frame means that after the assembly logic writes the last byte (the last byte of the check field) into the target frame buffer, it sends a frame assembly completion signal to the output control logic. Upon receiving the signal, the 14 bytes of data in the target frame buffer are output to the target protocol's transmission channel in the form of a continuous byte stream. During the output process, the assembly logic immediately begins to process the assembly of the next frame (if new parsing results are available in the hardware buffer), realizing a pipelined continuous conversion.

[0204] This step integrates the three independent processes of frame assembly, length calculation, and checksum calculation into a unified pipeline operation, eliminating two additional frame content traversals. The time saved is particularly significant in scenarios with long frame lengths. It ensures high processing throughput when receiving multiple frames continuously. The end-to-end conversion delay of each frame is equal to the sum of the delays of each step, and the output interval between consecutive frames can be less than the end-to-end delay of a single frame.

[0205] Example 2:

[0206] like Figure 3 As shown, this embodiment provides a hardware implementation system for industrial protocol parsing based on programmable logic, including a sniffing module, a configuration module, a parsing module, and a conversion module.

[0207] The sniffing module is used to receive industrial protocol data streams from multiple physical interfaces. After clock domain isolation and aggregation processing, the data streams are subjected to parallel feature matching to determine the target protocol type.

[0208] The configuration module is used to load the corresponding configuration data from the preset protocol configuration data into the reconfigurable area according to the target protocol type, and form a hardware parser adapted to the target protocol type in the reconfigurable area.

[0209] The parsing module parses the input message field by field using a hardware parser, adjusts the bit width of subsequent fields and the check calculation range based on the values ​​of the parsed fields, and temporarily stores the parsing results in a hardware buffer.

[0210] The conversion module is used to read the parsing results from the hardware buffer according to the protocol conversion rules if protocol conversion is performed, perform data mapping and transformation from the source protocol to the target protocol, assemble the target protocol data frame and output it.

[0211] The above description is merely a preferred embodiment of this application. The scope of protection of this application is not limited to the above embodiments. All technical solutions falling within the scope of this application's concept are within the scope of protection of this application. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of this application should also be considered within the scope of protection of this application.

Claims

1. A hardware implementation method for industrial protocol parsing based on programmable logic, characterized in that, include: Industrial protocol data streams are received from multiple physical interfaces, and after clock domain isolation and aggregation processing, parallel feature matching is performed on the data streams to determine the target protocol type. Based on the target protocol type, the corresponding configuration data is loaded from the preset protocol configuration data into the reconfigurable area, and a hardware parser adapted to the target protocol type is formed in the reconfigurable area. The hardware parser parses the input message field by field, adjusts the field extraction bit width and check calculation range according to the values ​​of the parsed fields, and temporarily stores the parsing results in the hardware buffer. If a protocol conversion is performed, the parsing result is read from the hardware buffer according to the protocol conversion rules, the data mapping and transformation from the source protocol to the target protocol is performed, the target protocol data frame is assembled and output.

2. The hardware implementation method for industrial protocol parsing based on programmable logic according to claim 1, characterized in that, The determination of the target protocol type includes: The processed data stream is subjected to sliding slicing to generate continuous slice windows. The slice windows are matched in parallel with the preset frame start anchor point features. When an anchor point feature is matched, the current data position is marked as the start anchor point of the candidate frame, and relative offset counting is started based on the start anchor point. Candidate protocols are selected based on the matched anchor point feature types. The feature fields of the candidate protocols at the corresponding relative offset positions are extracted and matched step by step according to the preset matching nodes with relative offsets from small to large. The candidate protocols are determined as the target protocol type after successive pruning and convergence.

3. The hardware implementation method for industrial protocol parsing based on programmable logic according to claim 2, characterized in that, During the stepwise feature matching process, the feature matching path corresponding to the pruned candidate protocol is closed. When the candidate protocol is pruned to a single protocol, the length field of the protocol frame format is extracted, the actual length is extracted from the data stream based on the corresponding relative offset position, and frame boundary verification is performed in combination with the protocol's frame length constraints. After successful verification, the target protocol type is locked and the protocol identifier and corresponding frame header parameter set are output. If the candidate protocol fails to converge within the preset offset window, or if the frame boundary check fails, the starting anchor point is determined to be an invalid anchor point, the relative offset count and feature matching path are reset, and feature matching is re-executed.

4. The hardware implementation method for industrial protocol parsing based on programmable logic according to claim 1, characterized in that, The hardware parser adapted to the target protocol type includes: Load the configuration data corresponding to the target protocol type from the preset protocol configuration data into the reconfigurable area. The configuration data includes field processing rules, field dependencies, and processing parameters. Based on the field processing rules, determine the processing steps to be executed during message parsing, and enable the hardware resources corresponding to the processing steps to be executed in the reconfigurable area to enter the working state, while the remaining hardware resources enter the closed state. Based on the dependencies between fields, establish data transfer paths between hardware resources that have entered the working state; The processing parameters are injected into the hardware resources that are already in operation and have established a data transmission path, forming a hardware parser that is compatible with the target protocol type.

5. The hardware implementation method for industrial protocol parsing based on programmable logic according to claim 4, characterized in that, The field processing rules include the relative offset position of the field in the protocol frame, the field extraction bit width, and the field verification conditions. The field verification conditions include the verification enable flag and the verification calculation range. The inter-field dependencies include the constraint relationship between the parsing results of the preceding fields and the bit width of the extracted fields; the processing parameters include field identifier, expected value, and verification method.

6. The hardware implementation method for industrial protocol parsing based on programmable logic according to claim 5, characterized in that, The step-by-field parsing of the input message includes: The hardware parser extracts the original data of the field to be parsed from the relative offset position of the field to be parsed in the field processing rules and the field extraction bit width. The original data of the field to be parsed is compared with its corresponding expected value, and the verification calculation within the corresponding verification calculation interval is started synchronously when the verification enable flag of the field to be parsed is valid. Write the parsing result of the current field to be parsed into the hardware buffer and record the value of the parsed field.

7. The hardware implementation method for industrial protocol parsing based on programmable logic according to claim 6, characterized in that, The adjusted field extraction bit width and verification calculation range include: Calculate the adjusted field extraction bit width for the next field based on the values ​​of the currently parsed fields and their corresponding field dependencies. Based on the adjusted field, extract the bit width and recalculate the next field and its relative offset position in the protocol frame; Based on the updated relative offset position and the extracted bit width of the field, update the starting position and coverage of the field's verification calculation interval; Extract the bit width, relative offset position, and verification calculation range from the updated fields, and continue parsing the fields.

8. The hardware implementation method for industrial protocol parsing based on programmable logic according to claim 7, characterized in that, The assembly target protocol data frame includes: The mapping relationship between the source protocol fields and the target protocol fields is determined according to the protocol conversion rules, as well as the assembly order of the data fields, length fields and check fields in the target protocol data frame. In the assembly order, the length field and check field are placed after all the data fields. According to the assembly order, the parsing results of the source protocol fields are read from the hardware buffer in turn. After data mapping and transformation according to the mapping relationship, the data is written to the relative offset position of the corresponding field in the target protocol data frame. At the same time, the frame length of the target protocol data frame is accumulated field by field and the accumulated verification value is updated synchronously. After all data fields are assembled, the accumulated frame length is written to the position of the length field, and the accumulated check value is written to the position of the check field, thus completing the assembly and output of the target protocol data frame.

9. The hardware implementation method for industrial protocol parsing based on programmable logic according to claim 8, characterized in that, The data mapping and transformation based on the mapping relationship includes: When the byte order of the source protocol field and the target protocol field are inconsistent, perform byte order transformation on the value of the parsed field; When the numerical representation ranges of the source protocol field and the target protocol field are different, numerical scaling is performed on the values ​​of the parsed fields; When multiple source protocol fields correspond to a single field in the target protocol, the values ​​of the multiple parsed fields are merged according to a preset merging rule; When a source protocol field corresponds to multiple fields of the target protocol, the values ​​of the parsed fields are split according to a preset splitting rule.

10. A hardware implementation system for industrial protocol parsing based on programmable logic, used to implement the hardware implementation method for industrial protocol parsing based on programmable logic as described in any one of claims 1-9, characterized in that, include: The module consists of a sniffing module, a configuration module, a parsing module, and a conversion module. The sniffing module is used to receive industrial protocol data streams from multiple physical interfaces. After clock domain isolation and aggregation processing, the data streams are subjected to parallel feature matching to determine the target protocol type. The configuration module is used to load the corresponding configuration data from the preset protocol configuration data into the reconfigurable area according to the target protocol type, and form a hardware parser adapted to the target protocol type in the reconfigurable area. The parsing module parses the input message field by field using a hardware parser, adjusts the field extraction bit width and check calculation range according to the values ​​of the parsed fields, and temporarily stores the parsing results in a hardware buffer. The conversion module is used to read the parsing results from the hardware buffer according to the protocol conversion rules if protocol conversion is performed, perform data mapping and transformation from the source protocol to the target protocol, assemble the target protocol data frame and output it.

Images