A PCIe receiving end ecrc parallel check system and method

Abstract

The application relates to the technical field of high-speed digital interface design, and discloses an ECRC parallel verification system and method of a PCIe receiving end, the system comprising a plurality of ECRC verification modules and a distribution control module; the plurality of ECRC verification modules are arranged in parallel, and the maximum processable bit width gradually decreases stage by stage; each ECRC verification module is used for performing ECRC verification of variable bit width; and the distribution control module is used for distributing at least two TLP data packets to different ECRC verification modules for parallel verification according to bit width information of the TLP data packets. The application reduces resource redundancy through dynamic bit width adjustment, can complete parallel verification of multiple TLPs in a single beat, supports processing of TLPs in multiple beats, can meet the performance requirement of high-speed communication, and can greatly reduce area overhead.

Description

Technical Field

[0001] This application relates to the field of high-speed digital interface design technology, specifically to an ECRC parallel verification system and method for a PCIe receiver. Background Technology

[0002] PCI Express (PCIe), as a high-speed serial bus standard, is widely used for data transmission between processors, GPUs, and storage devices. To ensure data integrity, the PCIe protocol requires end-to-end CRC verification of Transaction Layer Packets (TLPs). With PCIe Gen5 increasing the speed to 32GT / s and the data bit width per clock cycle to 512 bits, up to four ECRC fields of TLPs may be contained in a single clock cycle, posing a significant challenge to the design of the verification circuit.

[0003] Traditional verification schemes typically employ lookup table methods and block parallel methods. Lookup table methods accelerate verification by pre-compiling a CRC remainder table, but the lookup logic path is too long, failing to meet the performance requirements of high-speed communication, and also incurring excessive area overhead. Block parallel methods require independent CRC circuits for TLPs of different bit widths and must support multi-packet parallel verification, resulting in wasted area. Furthermore, TLPs spanning multiple clock cycles require recalculation of the CRC, making it impossible to reuse intermediate results and leading to additional latency.

[0004] Therefore, there is an urgent need for a CRC verification method for the PCIe protocol that can balance the requirements of high speed, low latency and low area overhead. Summary of the Invention

[0005] In view of this, this application provides a parallel ECRC verification system and method for PCIe receivers to solve the problem that traditional solutions are difficult to balance the requirements of high speed, low latency and low area overhead. The technical solution is as follows.

[0006] In one aspect, this application provides a parallel ECRC verification system for a PCIe receiver, which includes multiple ECRC verification modules and an allocation control module;

[0007] These multiple ECRC check modules are configured in parallel, with the maximum processable bit width decreasing progressively; each ECRC check module is used to perform ECRC checks with variable bit width.

[0008] This allocation control module is used to allocate at least two TLP data packets to different ECRC check modules for parallel verification based on the bit width information of the TLP data packets.

[0009] The ECRC parallel verification system for a PCIe receiver provided in this application has the following advantages:

[0010] This application's PCIe receiver ECRC parallel verification system achieves parallel processing of multiple TLPs within a single clock cycle through a dynamic bit-width hierarchical design of multiple ECRC verification modules, combined with a TLP bit-width matching strategy in the allocation control module. The hierarchical bit-width design directly addresses the actual TLP length distribution, avoiding the need to reserve redundant circuitry for low-frequency long packets. It solves the latency problem of traditional lookup table methods, optimizes the area overhead of block-based parallel processing, and can cover all TLP packet lengths defined by the PCIe protocol.

[0011] In one alternative implementation, the number of ECRC verification modules matches the maximum number of TLPs that the PCIe receiver needs to verify during the current clock cycle.

[0012] The PCIe receiver's ECRC parallel verification system in this application aligns the number of ECRC verification modules with the maximum number of TLPs per cycle specified in the protocol. By maximizing resource utilization, it avoids idle waste or contention conflicts, ensuring that hardware resources match business requirements.

[0013] In an optional implementation, the allocation control module is further configured to:

[0014] Parse the header fields of the received TLP data packet to obtain the length information of the TLP data packet;

[0015] Based on this length information, the bit width information of the TLP data packet can be confirmed.

[0016] The PCIe receiver's ECRC parallel verification system in this application dynamically parses TLP header fields (such as Length, TD, etc.) and calculates packet length to avoid module allocation errors and achieve on-demand allocation and load balancing.

[0017] In one alternative implementation, the system further includes:

[0018] The cross-clock cycle processing module is used to take the verification results of each ECRC verification module in the current clock cycle as the initial CRC value of the first ECRC verification module in the next clock cycle when the TLP data packet is detected to be transmitted across clock cycles.

[0019] The ECRC parallel verification system of the PCIe receiver in this application uses an intermediate result inheritance mechanism to merge the TLP fragment verification results across clock cycles, thus avoiding duplicate calculations.

[0020] In one optional implementation, the cross-shot processing module is further configured to:

[0021] Based on the start and end position markers of the received TLP data packet, determine whether the received TLP data packet is transmitted across clock cycles; and / or, compare the length information of the received TLP data packet with the capacity of the PCIe bus in the current clock cycle, and determine whether the received TLP data packet is transmitted across clock cycles based on the comparison result.

[0022] The ECRC parallel verification system for the PCIe receiver in this application implements a dual-insurance mechanism for cross-segment detection based on the start / end markers (STP / END) of the TLP and bus capacity comparison. By predicting the fragmentation boundary in advance based on the TLP length and remaining bus capacity, the risk of missed marker detection is reduced.

[0023] In one optional implementation, the cross-shot processing module is further configured to:

[0024] When a TLP data packet is detected to be transmitted across clock cycles, the TLP data packet is divided into several fragments.

[0025] The first verification result is obtained by verifying the current fragment data through each ECRC verification module in the current clock cycle;

[0026] The first verification result is used as the initial CRC value of the first ECRC verification module in the next clock cycle, and the next data segment is verified by each ECRC verification module in the next clock cycle.

[0027] The ECRC parallel verification system of the PCIe receiver in this application seamlessly connects fragmented data with intermediate results, ensuring the continuity of cross-segment TLP verification.

[0028] In an optional implementation, the allocation control module is further configured to:

[0029] Update the status of the target ECRC check module to occupied; the target ECRC check module is the one that is performing cross-clock cycle check.

[0030] In subsequent clock cycles, fragmented data of the same TLP data packet are continuously allocated to the target ECRC verification module until the TLP data packet verification is completed.

[0031] The ECRC parallel verification system for the PCIe receiver in this application ensures that fragmented data of the same TLP is processed by a fixed module through module occupancy status marking and a continuous allocation strategy. This avoids CRC misalignment caused by module switching of fragmented data (such as XOR errors caused by module 0 processing fragment 1 and module 1 processing fragment 2).

[0032] In an optional implementation, the allocation control module is further configured to:

[0033] If the target ECRC check module is detected to be occupied by other TLP data packets, then the current fragment data is cached;

[0034] Priority arbitration is performed to ensure that TLP data packets spanning multiple clock cycles have priority in occupying the target ECRC check module.

[0035] The ECRC parallel verification system of the PCIe receiver in this application uses a priority arbitration mechanism to ensure that the cross-phase TLP has priority to occupy the original module, and combines data buffering to prevent conflicts.

[0036] In an optional implementation, the allocation control module is further configured to:

[0037] If a fragment of a TLP data packet spanning a clock cycle is detected to have failed to arrive at the target ECRC verification module within the expected period, then the verification of that TLP data packet spanning a clock cycle is determined to have failed.

[0038] Discard all fragments of the TLP data packet spanning the clock cycle and re-verify the TLP data packet spanning the clock cycle.

[0039] The PCIe receiver's ECRC parallel verification system in this application includes a timeout fragment detection and discarding mechanism to prevent deadlock and resource consumption caused by fragment loss, and to ensure the final integrity of the data.

[0040] Secondly, this application provides a parallel ECRC verification method for a PCIe receiver, applied to a parallel ECRC verification system for a PCIe receiver as described in the second aspect or any corresponding embodiment. The method is executed by an allocation control module and includes:

[0041] Parse the header fields of multiple received TLP packets to obtain the length information of each TLP packet;

[0042] Based on this length information, the bit width information of each TLP data packet is confirmed;

[0043] Based on the bit width information of each TLP data packet, at least two TLP data packets are assigned to different ECRC verification modules for parallel verification to obtain the verification results of each TLP data packet.

[0044] Thirdly, this application provides a computer device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the ECRC parallel verification method of the PCIe receiver as described in the second aspect or any of its corresponding embodiments.

[0045] Fourthly, this application provides a computer-readable storage medium storing computer instructions for causing a computer to execute the ECRC parallel verification method of the PCIe receiver according to the first aspect or any corresponding embodiment described above.

[0046] Fifthly, this application provides a computer program product, including computer instructions for causing a computer to execute the ECRC parallel verification method of the PCIe receiver in the first aspect or any of its corresponding embodiments. Attached Figure Description

[0047] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0048] Figure 1 This is a schematic diagram illustrating the transmission of a TLP from a PCIe data source to a receiving end according to an embodiment of this application.

[0049] Figure 2 This is a schematic diagram of the ECRC field according to an embodiment of this application;

[0050] Figure 3 This is a schematic diagram of the lookup table method according to an embodiment of this application;

[0051] Figure 4 This is a schematic diagram of the block parallel method structure according to an embodiment of this application;

[0052] Figure 5 This is a schematic diagram of the structure of the ECRC parallel verification system of the PCIe receiver according to an embodiment of this application;

[0053] Figure 6 This is a flowchart illustrating the ECRC parallel verification method for a PCIe receiver according to an embodiment of this application.

[0054] Figure 7 This is a schematic diagram of the ECRC verification process according to an embodiment of this application;

[0055] Figure 8 This is a schematic diagram of a typical generator matrix according to an embodiment of this application;

[0056] Figure 9 This is a schematic diagram of zero padding at the beginning and end according to an embodiment of this application. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0058] First, let me introduce the terminology used in this application.

[0059] TLP: Transaction Layer Packet, a transaction layer message in the PCI Express protocol.

[0060] ECRC: end-to-end Cyclic Redundancy Check, can be regarded as a special extension of CRC, but its scalability is mainly reflected in the application scenarios and protection scope, rather than a fundamental change in the algorithm itself.

[0061] The data source in the PCI Express domain (such as the Endpoint or Root Complex) issues a TLP, which may be routed through an intermediate component (i.e., a switch) and used by the final PCI Express receiver, such as... Figure 1 As shown. Data may be corrupted inside the switch, and the LCRC regenerated for the corrupted data will mask the existence of the error.

[0062] In systems with high data reliability requirements, the data source places an end-to-end 32-bit CRC (ECRC) in the TLP Digest field at the end of the issued TLP, such as... Figure 2 As shown, ECRC covers all fields that will not change during TLP transmission, and intermediate components along the transmission path will not modify the ECRC field. Therefore, the final PCI Express receiver can ensure end-to-end data integrity through ECRC verification.

[0063] With the increase in PCIe speed, the bus width of gen5 has increased to 512 bits. Up to 4 TLPs need to be checked for ECRC at the same time in one clock cycle. The positions of the packet header and packet tail may be at any 32-bit aligned position, and the packet length of the TLP cannot be determined. Traditional verification schemes generally use the lookup table method and the block parallel method, but both of these methods have their own problems.

[0064] The structure of the lookup table method is as follows: Figure 3As shown, if the granularity is 8 bits, the input data width is 512 bits, which requires 64 table lookups. The logical path is too long and cannot meet the performance requirements of high-speed communication. If the granularity is 16 bits, the number of table entries to be stored is 216*16 bits, which is too large in area.

[0065] The block-parallel structure is as follows: Figure 4 As shown, 16 types of CRC calculation circuits are required, including 32-bit, 64-bit, 96-bit, 128-bit, ..., 512-bit CRC, with 32-bit granularity. At the same time, there may be two or more TLPs of the same length that need to be calculated for ECRC, resulting in excessive area overhead.

[0066] Therefore, in order to solve the above-mentioned technical problems, this application provides an ECRC parallel verification system for a PCIe receiver, which includes multiple ECRC verification modules and an allocation control module.

[0067] The system includes multiple ECRC check modules configured in parallel, with the maximum processable bit width decreasing progressively. Each ECRC check module is used to perform variable-width ECRC checks. The allocation control module is used to allocate at least two TLP data packets to different ECRC check modules for parallel checks based on the bit width information of the TLP data packets.

[0068] Specifically, each ECRC check module is used to adjust the CRC check parameters according to the bit width information of the TLP data packet, perform CRC check, and output the check result.

[0069] Adjusting the CRC check parameters specifically involves extracting the first N rows from a pre-stored generator matrix based on the bit width information of the current TLP data packet, where N is the bit width of the current TLP data packet. This is done to configure CRC calculation units with different fixed processing bit widths. The seed value is loaded from the seed value table based on the header position of the current TLP data packet, and CRC calculation is performed on the input TLP data packet. The expected value is selected from the expected value table based on the tail position of the current TLP data packet. The calculation result is compared with the pre-stored expected value, and the check result is output.

[0070] Implementing a variable-width ECRC checksum only requires padding the packet header and tail with zeros, adjusting the seed and expected values, and then performing a fixed-width CRC calculation. This allows each ECRC checksum module to dynamically adapt to the bit width of the input TLP data (e.g., 32 / 64 / 96…512 bits), eliminating the need for independent processing circuit structures for each bit width. Instead, bit width switching is achieved through mathematical transformations (such as generator matrix truncation and seed value adjustment), rather than relying on multiple independent circuits.

[0071] The number of ECRC check modules matches the maximum number of TLPs that the PCIe receiver needs to check within the current clock cycle. Taking PCIe Gen5 as an example, the input data bit width is 512 bits. A single 512-bit clock cycle of PCIe Gen5 can accommodate four 128-bit TLPs. Therefore, the number of ECRC check modules is set to four. The structure of the parallel ECRC check system at the PCIe receiver is as follows: Figure 5 As shown.

[0072] Each ECRC check module can perform ECRC calculations with a width no greater than the input data bit width. For example, u_ecrc_0 supports 0*32 to 16*32 bit checksums, u_ecrc_1 supports 416 bit checksums, u_ecrc_2 supports 256 bit checksums, and u_ecrc_3 supports 96 bit checksums. This avoids the design of 16 fixed-width circuits in traditional block-parallel structures, significantly reducing hardware area. Parallel processing of four TLPs results in shorter logic paths compared to lookup table methods (requiring 64 lookups) and block-based methods (multiple circuit redundancies), meeting the timing requirements of PCIe Gen5 high-speed transmission.

[0073] The allocation control module obtains the length information of the received TLP data packet by parsing its header field; and determines the bit width information of the TLP data packet based on this length information. Specifically, it parses the header length field of the TLP data packet, excluding fields such as STP, sequence number, LCRC, and END. A single TLP can have a maximum of four ECRC fields. The allocation control module distributes these four TLPs sequentially to four ECRC check modules: u_ecrc_0 checks the first TLP, u_ecrc_1 checks the second TLP, and so on. Based on the TLP header length field, the bit width requirement is accurately determined, avoiding resource waste caused by fixed allocation (such as a large module handling a small-width TLP), and dynamically allocating to adapt to the uncertain characteristics of TLP packet length, thus improving flexibility.

[0074] The PCIe receiver ECRC parallel verification system provided in this embodiment also includes a cross-clock cycle processing module. When a TLP data packet is detected to be transmitted across clock cycles, the verification results of each ECRC verification module in the current clock cycle are used as the initial CRC value (ICRC) of the first ECRC verification module in the next clock cycle. Moreover, only the first module (u_ecrc_0) needs to support ICRC input, simplifying the cross-clock cycle processing logic and reducing the area.

[0075] Specifically, the cross-cycle processing module utilizes the linear property of CRC. If a TLP data packet is transmitted across multiple clock cycles (i.e., fragmented transmission), traditional methods require storing the entire data packet before calculating the CRC, resulting in a large buffer area overhead. The cross-cycle TLP data packet is divided into multiple fragments (e.g., fragments D1, D2). In the first cycle, CRC(D1) is calculated, and the result is temporarily stored as an intermediate value C1. In the second cycle, using C1 as the initial value, CRC(D2) is calculated, ultimately obtaining the overall CRC value CRC(D1||D2). || indicates data concatenation, and the intermediate result of each calculation is used as the initial value for the next sub-block. This characteristic allows CRC calculation to be performed segmented, without processing the entire data at once; only intermediate CRC values ​​need to be transmitted, significantly reducing the buffer area.

[0076] Whether the aforementioned cross-clock cycle processing module needs to perform cross-clock cycle processing depends on whether the received TLP data packet is transmitted across clock cycles. Detection can be based on the start / end markers of the TLP data packet or on a comparison of the TLP data packet length with the bus capacity. Detection based on start / end markers uses the start marker (e.g., the STP field) and end marker (e.g., the END field) in the TLP header to locate data boundaries. If the start and end markers are not within the same clock cycle, it is determined to be a cross-clock cycle transmission. For example, if the STP is located at the 256-bit position of the current cycle, and the END is located at the 128-bit position of the next cycle, then the TLP is determined to be a cross-clock cycle transmission. Detection based on length and bus capacity comparison involves parsing the TLP header length field (Length field, in DW) and calculating the total bit width. The total TLP bit width is compared with the remaining bus capacity in the current clock cycle (e.g., 512 bits - start offset). If the TLP bit width exceeds the remaining capacity, it is determined to be a cross-clock cycle transmission. For example, if the TLP length is 1024 bits and the bus single-shot capacity is 512 bits, then cross-shot transmission is necessary. These two methods can be used independently or in combination to enhance detection reliability. For example, prioritize quick boundary location via markers, then use length verification to avoid false positives. In case of missing markers (e.g., data corruption), fall back to length comparison.

[0077] After confirming that the received TLP data packet needs to be processed across clock cycles, the aforementioned cross-clock cycle processing module divides the TLP data packet transmitted across clock cycles into multiple fragments (e.g., fragments D1 and D2) according to the bus width (e.g., 512 bits) and the TLP start position (e.g., 32-bit alignment). The size of each fragment does not exceed the single-clock-cycle bus capacity (e.g., 512 bits). In the first clock cycle, the currently available ECRC check module (e.g., u_ecrc_0) checks fragment D1, obtaining an intermediate result C1. C1 is passed as the initial CRC value (ICRC) to the first ECRC check module (still u_ecrc_0) in the next clock cycle. In the next clock cycle, u_ecrc_0 continues to check fragment D2 with C1 as the initial value, finally obtaining the CRC result of the complete TLP. The same ECRC check module (e.g., u_ecrc_0) processes different fragments of the same TLP in different clock cycles, while also supporting parallel checks of other TLPs.

[0078] The aforementioned cross-cycle processing module also incorporates a occupancy management and continuous allocation mechanism. Specifically, when an ECRC check module (e.g., u_ecrc_0) begins processing fragmented data from a cross-cycle TLP, the allocation control module marks its status as "occupied." In subsequent clock cycles, the remaining fragmented data of the same TLP must be allocated to the original module (e.g., u_ecrc_0) until the check is complete. For example, in the first cycle: u_ecrc_0 processes fragment D1 of cross-cycle TLP_A and marks it as occupied. In the second cycle: fragment D2 of TLP_A is forcibly allocated to u_ecrc_0, and other TLPs (e.g., TLP_B) are allocated to idle modules (e.g., u_ecrc_1). Furthermore, if the target module is occupied by another TLP (e.g., u_ecrc_0 is processing TLP_B), the current fragmented data is cached, waiting for the target module to release it. Priority arbitration is also performed, with requests from cross-cycle TLPs having higher priority than newly arrived TLPs, thus preempting the target module's usage rights.

[0079] In addition, the aforementioned cross-processing module also includes a timeout detection mechanism. Specifically, a timer is started for each cross-processing TLP. If its fragmented data does not arrive at the target module within a preset time, the verification is deemed to have failed. The preset time can be calculated based on the total length of the TLP and the link rate to estimate the theoretical arrival time (e.g., 1024 bits of data requires 2 clock cycles on a PCIe Gen5 x16 link, and the timeout threshold is set to 3 cycles). After confirming the verification failure, all received fragmented data of that TLP (including intermediate CRC values ​​and fragmented content in the buffer) is cleared, and the target ECRC verification module's occupied state is released. Subsequently, a retransmission request is sent to the sender (based on the PCIe link layer retransmission protocol) to retransmit the complete TLP. At this time, the PCIe link must prioritize retransmitting the failed TLP to avoid link congestion.

[0080] Based on the PCIe receiver's parallel ECRC verification system provided above, a PCIe receiver's parallel ECRC verification method will be provided below. The specific method flow is as follows: Figure 6 As shown, it includes the following steps.

[0081] S601. Parse the header fields of the received multiple TLP data packets to obtain the length information of each TLP data packet.

[0082] Specifically, taking an input data width of 512 bits as an example, please refer to... Figure 7 The system extracts multiple header fields (such as Fmt, Type, Length, etc.) from the received 512-bit bus data, excluding fields such as STP, sequence number, LCRC, and END, and parses the Length field (in units of DW, 1DW = 32 bits). For example, if the Length field value is 5, it means that the payload is 5 DWs (160 bits), plus the fixed length of the packet header (such as 3DW = 96 bits), the total bit width is 256 bits.

[0083] S602. Based on this length information, confirm the bit width information of each TLP data packet.

[0084] Specifically, according to the PCIe protocol rules, the TLP header (first 128 bits) is extracted from the 512-bit bus, and fields such as Length and Fmt (which determines the header type) are parsed. Based on the Length and Fmt values, the total bit width of the TLP data packet is calculated.

[0085] S603. Based on the bit width information of each TLP data packet, at least two TLP data packets are assigned to different ECRC verification modules for parallel verification to obtain the verification results of each TLP data packet.

[0086] Specifically, based on the obtained TLP bit width information, the TLPs are sorted in descending order of bit width (e.g., 512bit > 416bit > 256bit > 96bit). Larger bit width TLPs are preferentially allocated to high-capacity modules (e.g., a 512-bit TLP is allocated to u_ecrc_0). Remaining TLPs are allocated to the smallest available modules (e.g., a 256-bit TLP is allocated to u_ecrc_2).

[0087] In step S603 above, if it is detected that the received TLP data packet needs to be processed across clock cycles, the TLP data packet transmitted across clock cycles is divided into multiple fragments, the size of each fragment not exceeding the single-cycle bus capacity (e.g., 512 bits). (Reference) Figure 7In the first clock cycle, the currently available ECRC check module (such as u_ecrc_0) checks fragment D1, obtaining an intermediate result C1. C1 is then passed as the initial CRC value (ICRC) to the first ECRC check module (still u_ecrc_0) in the next clock cycle. In the next clock cycle, u_ecrc_0 continues to check fragment D2 using C1 as the initial value, ultimately obtaining the CRC result of the complete TLP. The same ECRC check module (such as u_ecrc_0) processes different fragments of the same TLP in different clock cycles, while simultaneously supporting parallel checks of other TLPs.

[0088] The following section will explain the specific implementation of variable-width ECRC check.

[0089] First, let me explain the parallel implementation logic, which includes the following process.

[0090] Parallel verification is based on the linear property of CRC. It achieves parallelization through matrix multiplication to obtain the CRC checksum R, expressed as:

[0091] R = MQ;

[0092] In the formula, Q is the equivalent transformation matrix (typical generator matrix) of the generator matrix G, and M is the input data vector (e.g., 512 bits).

[0093] The CRC generator matrix G can be written as:

[0094]

[0095] In the formula, g(x) is the generator polynomial of the cyclic redundancy check code.

[0096] The typical generating matrix can be obtained through the following expression:

[0097] G = [I k Q];

[0098] In the formula, I k This represents the k-order identity matrix.

[0099] The calculation of Q in a typical generating matrix is ​​as follows: Figure 8 As shown, row 0 represents the polynomial coefficient P[i] of g(x) after removing the highest term. As the row number increases, it's equivalent to left-shifting the polynomial coefficients, padding the lower bits with 0s. When the highest bit of the previous row is 1, the current row is the result of left-shifting the previous row and then subtracting the value from row 0. This subtraction can be implemented using XOR. A linear transformation ensures that the matrix before Q is I. k .like Figure 8 The 6th row is equal to the 5th row shifted left and the lower 32 bits are taken, and then XORed with the 0th row bitwise to ensure that Ik in the typical generator matrix is ​​guaranteed.

[0100] For example, for u_ecrc_0 with an input data width of 512 bits, the input data is represented as M = [m 511 m 510 ...m2m1m0],R=[r 31 r 30 ...r2r1r0]. G is transformed into a typical generator matrix using a linear transformation to obtain Q. Then, the 32-bit CRC checksum can be obtained using the checksum formula, expressed as: [r... 31 r 30 .....r2r1r0]=[m 511 m 510 ......m2m1m0]*Q.

[0101] Based on the parallel implementation described above, the logic of variable-width ECRC check will be explained in detail below.

[0102] The core of variable-width ECRC checksum is to convert the CRC checksum of a variable-width message into a fixed-width CRC checksum. Simply put, it involves adjusting the truncation range of the generated matrix (e.g., the first N rows of a 512-bit matrix, where N = the current data width), combined with pre-calculated seed and expected CRC values, enabling the same ECRC checksum module to process TLP data of different widths and supporting cross-clock-cycle segmentation processing. This is for configuring CRC calculation units with different fixed processing widths, and it is statically configured. Its technical basis is the linear superposition property of CRC. It aligns variable-width data to a fixed width by padding with zeros at the beginning and end, and quickly loads the seed and expected values ​​using pre-stored seed and expected value tables, adapting to different packet header / tail positions to achieve efficient, low-latency parallel checksum. The specific process includes the following steps.

[0103] Based on the linear property of CRC (CRC(A||B)=CRC(CRC(A)||B)), variable-width messages can be converted to fixed-width messages by padding with leading and trailing zeros. Specifically, padding can be done by first aligning the packet to 512 bits based on the header start position (e.g., the 3rd DW), with a zero-padding length of b×32 bits. Alternatively, padding can be done by first aligning the packet to 512 bits based on the actual message length (e.g., 352 bits), with a zero-padding length of t×32 bits. According to the IEEE CRC-32 standard, the input data needs to be bit-reversed before calculation, and the output result is then reversed and XORed to 0xFFFFFFFF. Because the packet header is padded with leading zeros, the seed value needs to be adjusted. This seed is derived from {32'hffff_ffff,{32*b{0}}} through rolling back, where b depends only on the packet header position and is independent of the input data. Due to the XOR value of the result and the padding with leading zeros at the end of the packet, the expected checksum is no longer 0, but rather the CRC checksum of {32'hffff_ffff,{32*t{0}}}, where t depends only on the end of the packet position. (See reference...) Figure 9 The second line, `input`, represents the data received by the receiver. `sot` represents the packet header, and `eot` represents the packet trailer. The current TLP length is 11DW (352 bits). The third line, `flip`, adds 3DW (96 bits) of zeros before `sot` and 2DW (64 bits) of zeros after `eot`, as required by the CRC32 algorithm. A suitable seed is selected based on the position of `sot`, and then a 512-bit CRC is calculated. Finally, the calculated result is compared with the expected value selected based on the position of `eot`. In this way, the CRC checksum of 11DW (352 bits) data is converted into a 512-bit CRC checksum.

[0104] After padding with zeros at the beginning and end, a seed value is generated based on the packet header position, and an expected CRC value is generated based on the packet tail position.

[0105] Specifically, based on the packet header's position in the bus (e.g., the 3rd double word), determine how many 32-bit zeros need to be padded before the header (e.g., 3 double words → 96 bits). For each possible padding length (e.g., 0-15 double words), pre-calculate the corresponding "adjusted initial value" (i.e., seed value) to ensure the CRC calculation after padding is equivalent to the standard initial value. Store the seed values ​​corresponding to all padding lengths in a seed table, which is used to retrieve the value based on the packet header position. For example, if the packet header is at the 3rd double word, the seed value is retrieved from the table and replaced with the standard initial value. Based on the packet tail position (e.g., data ends at the 14th double word), determine how many 32-bit zeros need to be padded after the packet tail (e.g., 2 double words → 64 bits). For each possible padding length, pre-calculate the "correct CRC result after padding" (i.e., expected value) and consider the XOR operation of the result. Store the expected values ​​corresponding to all padding lengths in an expected value table, which is used to retrieve the value based on the packet tail position. For example, two double characters are added to the end of the packet. The expected value is then retrieved from a table and compared with the actual CRC result. In simpler terms, the packet header is padded with zeros, the initial value is adjusted using the seed value, the CRC is calculated, and the CRC is appended to the end of the packet. The end of the packet is padded with zeros, the initial value is adjusted using the same seed value, the CRC is calculated, the result is XORed, and compared with the expected value (if the result is 0, the check passes).

[0106] Therefore, upon receiving a TLP data packet, the TLP header is first parsed to determine the effective data length w. The first w rows of the Q matrix are then selected based on the effective data length w. The corresponding bit-width XOR network is activated to complete the CRC calculation.

[0107] For a specific example, the original data is 11DW (352 bits), sot is located in the 3rd DW (96-bit offset), and eot is located in the 14th DW (448 bits). Lead-padding is performed: 3DW (96 bits) of zeros are added to the packet header, making the effective data start at the 512-bit starting position. Trail-padding is performed: 2DW (64 bits) of zeros are added to the packet tail, making the total length 512 bits. Then, checking the seed table, sot is found to be in the 3rd DW, so S3 is read. Checking the expected value table, eot is padded with 2DW, so E2 is read. The first 352 rows of the Q matrix are extracted, and the input data M[0:351] and Q[0:351] are XORed using a network of XOR gates. The output CRC result is XORed with E2; if the result is 0x00000000, the verification passes.

[0108] The parallel ECRC verification system for PCIe receivers provided in this application embodiment achieves efficient verification of variable bit-width ECRC through pre-calculated seed / expected value table, bit-width adaptive matrix multiplication, and zero-padding alignment logic.

[0109] In summary, the PCIe receiver ECRC parallel verification system provided in this application achieves efficient verification of multiple TLP data through a hierarchical adjustable bit width ECRC module dynamic allocation mechanism combined with cross-shot pipeline processing based on the linearity of CRC. Based on the real-time bit-width calculation and module allocation strategy of TLP header field parsing (e.g., allocating 512-bit TLP to u_ecrc_0 and 96-bit TLP to u_ecrc_3), multiple TLP data packets can be processed in parallel in a single cycle, significantly increasing throughput by 4 times to meet the rate requirements of PCIe Gen5. Utilizing the block superposition property of CRC, the intermediate results of cross-cycle TLP fragments are passed as the initial value for the next clock cycle, eliminating the need to cache complete data and reducing buffer area overhead. Simultaneously, fragment processing significantly shortens critical logic paths, resolving timing violations caused by multi-level serialization in traditional table lookup methods. Through priority arbitration and timeout retransmission mechanisms, fragment data is cached and resources are preempted when the target module is occupied, ensuring priority processing of cross-cycle TLPs. Combined with dynamic reconstruction of the generator matrix, computational logic is reused and adapted to variable bit widths, significantly reducing hardware area compared to traditional block parallel schemes. It also supports seamless compatibility with multiple PCIe protocol versions, balancing high reliability and low power consumption.

[0110] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A parallel ECRC verification system for a PCIe receiver, characterized in that, The system includes multiple ECRC verification modules and an allocation control module; The multiple ECRC verification modules are set up in parallel, and the maximum processable bit width decreases step by step; each ECRC verification module is used to perform ECRC verification with variable bit width. The allocation control module is used to allocate at least two TLP data packets to different ECRC verification modules for parallel verification based on the bit width information of the TLP data packets; The cross-clock cycle processing module is used to take the verification results of each ECRC verification module in the current clock cycle as the initial CRC value of the first ECRC verification module in the next clock cycle when the TLP data packet is detected to be transmitted across clock cycles. The allocation control module is also used for: Parse the header fields of the received TLP data packet to obtain the length information of the TLP data packet; Based on the length information, the bit width information of the TLP data packet is confirmed.

2. The system according to claim 1, characterized in that, The number of ECRC verification modules matches the maximum number of TLPs that the PCIe receiver needs to verify during the current clock cycle.

3. The system according to claim 1, characterized in that, The cross-shot processing module is also used for: Based on the start and end position markers of the received TLP data packets, determine whether the received TLP data packets are transmitted across clock cycles; And / or, The length of the received TLP data packet is compared with the capacity of the PCIe bus in the current clock cycle, and the result of the comparison determines whether the received TLP data packet is transmitted across clock cycles.

4. The system according to claim 3, characterized in that, The cross-shot processing module is also used for: When a TLP data packet is detected to be transmitted across clock cycles, the TLP data packet is divided into several fragments. The first verification result is obtained by verifying the current fragment data through each ECRC verification module in the current clock cycle; The first verification result is used as the initial CRC value of the first ECRC verification module in the next clock cycle, and the next data segment is verified by each ECRC verification module in the next clock cycle.

5. The system according to claim 4, characterized in that, The allocation control module is also used for: Update the status of the target ECRC check module to occupied; the target ECRC check module is the ECRC check module that is performing cross-clock cycle check. In subsequent clock cycles, fragmented data of the same TLP data packet are continuously allocated to the target ECRC verification module until the TLP data packet verification is completed.

6. The system according to claim 5, characterized in that, The allocation control module is also used for: If the target ECRC check module is detected to be occupied by other TLP data packets, then the current fragment data is cached; Priority arbitration is performed so that TLP data packets spanning clock cycles have priority in occupying the target ECRC verification module.

7. The system according to claim 6, characterized in that, The allocation control module is also used for: If a fragment of a TLP data packet spanning a clock cycle is detected to have failed to arrive at the target ECRC verification module within the expected period, then the TLP data packet spanning a clock cycle is determined to have failed verification. Discard all fragments of the TLP data packet that spans the clock cycle, and re-verify the TLP data packet that spans the clock cycle.

8. A parallel ECRC verification method for a PCIe receiver, characterized in that, The ECRC parallel verification system applied to the PCIe receiver as described in any one of claims 1 to 7, wherein the method is executed by the allocation control module, and the method includes: Parse the header fields of multiple received TLP packets to obtain the length information of each TLP packet; Based on the length information, confirm the bit width information of each TLP data packet; Based on the bit width information of each TLP data packet, at least two TLP data packets are assigned to different ECRC verification modules for parallel verification to obtain the verification results of each TLP data packet.

Images