Verification method for PCIE sorting and resorting

Abstract

The invention discloses a PCIE sorting and resorting verification method, relates to the technical field of computer bus protocol verification, and discloses a PCIE sorting and resorting verification method which comprises the steps of generating an expected data stream with a sequence label through a reference model, combining dynamic comparison of output streams of tested equipment, and introducing a credit management module to simulate a physical layer blocking scene. The problems that in the prior art, reference model time sequence precision is insufficient and manual verification efficiency is low are solved, verification accuracy and efficiency can be improved, and dynamic reordering behaviors are effectively captured.

Description

Technical Field

[0001] The present application relates to the technical field of computer bus protocol verification, and in particular to a method for verifying PCIE sorting and reordering. Background Art

[0002] PCIe (Peripheral Component Interconnect Express), the third-generation I / O bus following ISA and PCI, has become a core interconnect standard for connecting central processing units (CPUs) with external devices. Its high-speed serial point-to-point architecture offers significant advantages over traditional parallel buses: it supports multi-channel concurrent data transmission, providing unidirectional link rates up to 16GT / s; it employs a packet switching mechanism to reduce transmission latency; and its differential signaling design enables reliable long-distance transmission. PCIe has become an indispensable infrastructure for bandwidth-sensitive applications such as storage devices, graphics accelerators, and high-speed network cards.

[0003] The protocol specification clearly defines transaction ordering rules, a key mechanism for ensuring backward compatibility with legacy PCI / PCI-X devices. These ordering rules require that non-posted requests of the same traffic type be completed in the order they were initiated, while completion packets can be reordered under certain conditions to optimize system performance. This complex ordering mechanism requires precise coordination of the timing between request and completion messages while avoiding deadlock.

[0004] Existing verification technologies face two major bottlenecks: First, reference models typically employ transaction-level abstraction and lack precise clock-based timing simulation capabilities, making it impossible to capture dynamic reordering behaviors within the device under test (DUT) triggered by physical layer factors such as credit control and port congestion. Second, traditional verification methods rely on manual inspection of message order, making it difficult to systematically verify that the tens of thousands of possible message combinations in reordering scenarios meet the protocol's Relaxed Ordering (RO) property constraints. These issues severely restrict the verification completeness of high-performance PCIe devices, such as NVMe controllers and GPU interconnect modules.

[0005] The above content is only used to assist in understanding the technical solution of this application and does not constitute an admission that the above content is prior art. Summary of the Invention

[0006] The main purpose of this application is to provide a PCIE sorting and reordering verification method, aiming to improve verification accuracy and efficiency and effectively capture dynamic reordering behavior.

[0007] To achieve the above objectives, the present application proposes a method for verifying PCIE sorting and reordering, the method comprising:

[0008] receiving input request messages from the model module through the reference model, generating label data for each output message in sequence, and outputting the label data and the output message as a first verification data stream to the comparator;

[0009] receiving an input request message of the model module through the device under test, generating an actual output message, and outputting the actual output message as a second verification data stream to the comparator;

[0010] Creating a first queue in the comparer to store the first verification data stream, and creating a second queue to store the second verification data stream;

[0011] Based on the actual output messages in the second queue, traverse the label data of the first queue to match the sequence position information of the corresponding messages;

[0012] According to the matching position information, the expected message type of the first queue is compared with the actual message type of the second queue, and the verification result is output according to the PCIe protocol sorting rules.

[0013] In one embodiment, the step of receiving an input request message from a model module through a reference model, sequentially generating label data for each output message, and outputting the label data and the output message as a first verification data stream to a comparator includes:

[0014] Sending a randomly generated request message to the reference model through the model module, wherein the request message types include P type, NP type and CPL type;

[0015] Generating an increasing sequence number label for each output message in the reference model according to the generation order;

[0016] The increasing sequence number label and the corresponding output message are bound to form a labeled data packet, and output to the comparator as the first verification data stream.

[0017] In one embodiment, the step of traversing the label data of the first queue to match the sequence position information of the corresponding message based on the actual output message in the second queue includes:

[0018] Extracting the first actual output message from the second queue;

[0019] Traversing all labeled data packets in the first queue, searching for label data that is identical to the actual output message content;

[0020] The sequence number value corresponding to the tag data is obtained as the position information of the current message in the expected sequence.

[0021] In one embodiment, the step of comparing the expected message type of the first queue with the actual message type of the second queue based on the matching location information, and outputting a verification result according to a PCIe protocol sorting rule includes:

[0022] Based on the position information, obtaining an expected message type at the same position from the first queue;

[0023] Comparing the expected message type with the type of the actual output message;

[0024] If the types are consistent, the sorting is determined to be correct; if not, the re-sorting verification logic is executed.

[0025] In one embodiment, the reordering verification logic includes:

[0026] When the actual output message is of CPL type and the expected message is of P type, checking the RO attribute value of the CPL message;

[0027] If the RO attribute value is 1, the reordering is determined to be legal;

[0028] If the RO attribute value is not 1 or the actual output message is of type P but is expected to be of type CPL, the verification is considered to have failed.

[0029] In one embodiment, the RO attribute value is obtained as follows:

[0030] Parsing the header control field of the CPL message;

[0031] The value of the Nth bit in the header control field is extracted as the RO attribute flag.

[0032] In one embodiment, the method further comprises:

[0033] The initial credit value and credit update delay parameters of the device under test are configured through the credit management module to simulate a port blocking scenario to trigger reordering behavior.

[0034] In one embodiment, the step of configuring the initial credit value and credit update delay parameters of the device under test through the credit management module and simulating a port blocking scenario to trigger a reordering behavior includes:

[0035] Setting an initial credit value to limit the number of concurrent message processing of the device under test;

[0036] The credit recovery response time is controlled by a delay parameter, forcing the device under test to perform a reordering operation according to the PCIe protocol.

[0037] In one embodiment, the tag data includes an incremented unique serial number value, a type identifier of the corresponding message, and source and destination address information of the message.

[0038] In one embodiment, the verification result includes a correct sorting flag, a legal re-sorting event record, and information on the location and type of error messages that violate the sorting rules.

[0039] The present application provides a PCIE sorting and reordering verification method, which generates an expected data stream with sequence tags through a reference model, combines dynamic comparison of the output stream of the device under test, and introduces a credit management module to simulate the physical layer blocking scenario. It solves the problems of insufficient timing accuracy of the reference model and low efficiency of manual verification in the existing technology, can improve verification accuracy and efficiency, and effectively capture dynamic reordering behavior. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0041] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0042] Figure 1 A flowchart illustrating an embodiment of a method for verifying PCIE sorting and reordering according to the present application is provided.

[0043] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0044] The technical solutions in this application will be clearly and completely described below in conjunction with the drawings in this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all of the embodiments. The components of the present application generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application for which protection is claimed, but merely represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of this application.

[0045] It should be understood that similar reference numerals and letters in the following drawings represent similar items. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and should not be understood as indicating or implying relative importance.

[0046] In existing technologies, the PCIe bus serves as a critical data transmission channel in computer systems, and the verification of its transaction ordering rules directly impacts the reliability of inter-device communication. Traditional verification methods rely on reference models for transaction simulation. However, because reference models lack a concept of timing, they cannot accurately reflect the actual order of message processing within the device under test. When message reordering occurs in the device under test, traditional methods are unable to automatically determine whether the reordering complies with protocol rules. This necessitates manual intervention to analyze the message order during the verification process, significantly reducing verification efficiency and accuracy.

[0047] To address the aforementioned issues, the inventors conducted an in-depth analysis of the contradiction between the PCIe protocol sequencing rules and the characteristics of the verification environment. Traditional reference models can only simulate transaction logic but cannot record the timing of message generation, making it impossible for the verifier to establish a timing correlation between expected output and actual output. By studying the protocol specifications, it was discovered that the message processing order can be tracked using a unique identifier, while legal reordering behaviors are marked with specific attributes. Based on this, the inventors proposed establishing a verification data stream with timing tags, and using an independent queue storage mechanism to achieve dynamic matching of expected sequences with actual outputs, thereby constructing an automated verification framework.

[0048] Based on this, the embodiment of the present application provides a method for verifying PCIE sorting and reordering, referring to Figure 1 The PCIE sorting and reordering verification method includes steps S100 to S500, wherein:

[0049] Step S100, receiving an input request message from a model module through a reference model, generating tag data for each output message in sequence, and outputting the tag data and the output message as a first verification data stream to a comparator;

[0050] Step S200, receiving the input request message of the model module through the device under test, generating an actual output message, and outputting the actual output message as a second verification data stream to the comparator;

[0051] Step S300: creating a first queue in the comparer to store the first verification data stream, and creating a second queue to store the second verification data stream;

[0052] Step S400: Based on the actual output message in the second queue, traverse the label data of the first queue to match the sequence position information of the corresponding message;

[0053] Step S500: Compare the expected message type of the first queue with the actual message type of the second queue according to the matching position information, and output a verification result according to the PCIe protocol sorting rule.

[0054] In this embodiment, the reference model refers to a standardized transaction processing module that is independent of the device under test. Specifically, it can be implemented by a simulation model constructed using a hardware description language, and its function is to generate an expected output sequence containing timing information. Label data refers to the unique identification information attached to the message, and can be implemented by combining an increasing sequence number with a message type identifier to establish a mapping relationship between the message generation order and the protocol rules. A comparator refers to a verification component with data storage and logic analysis functions, and can be implemented by a dual-queue cache structure combined with state machine control logic. Its function is to achieve dynamic alignment and rule verification of expected data streams and actual data streams. Sequential position information refers to the legal position of a message in the sequence allowed by the protocol, and can be obtained by traversing the label sequence number and the message content matching algorithm, and is used to determine whether the actual output complies with the sorting or reordering rules.

[0055] In this embodiment, when the model module sends the same request message to the reference model and the device under test, the reference model adds an increasing serial number to each output message through the built-in label generator to form a first verification data stream containing a timing mark. The message generated by the device under test after processing the same request enters the comparator as the second verification data stream. After the comparator caches the two types of data streams separately through independent queues, it uses a sequential matching algorithm to extract features from the actual output message and searches for the corresponding label data in the expected sequence queue to determine its theoretical position. When it is detected that the actual message type does not match the expected position, a secondary verification is performed according to the reordering exception clause specified in the protocol, such as checking the reordering attribute flag of the completed message. Through this dynamic matching mechanism, the system can automatically identify legal reordering and illegal disorder behavior.

[0056] In this embodiment, by introducing a verification data stream with timing tags and a dual-queue comparison mechanism, a fully automatic verification system covering sorting and reordering is constructed. Compared with the passive verification method that simply relies on the protocol checker, this method can actively track the message processing order and accurately identify the behavioral compliance of the device under test in complex scenarios such as credit control and port blocking. In this way, the present application realizes the automated verification of the transaction processing order of PCIe devices, effectively solving the problems of low efficiency of manual verification and insufficient coverage of reordering scenarios in traditional methods. Through the combination of label data and the dual-queue comparison mechanism, it is possible to accurately distinguish between legal reordering and protocol violations, improve the scenario coverage and result credibility of the verification environment, and provide an effective verification means for device behavior analysis in complex credit control scenarios.

[0057] In a feasible embodiment, the steps of receiving input request messages from the model module through the reference model, generating label data for each output message in sequence, and outputting the label data and the output message as the first verification data stream to the comparator include: sending a randomly generated request message to the reference model through the model module, the request message types including P type, NP type and CPL type; generating an increasing sequence number label for each output message in the reference model in the order of generation; binding the increasing sequence number label and the corresponding output message into a labeled data packet, and outputting the label data and the output message as the first verification data stream to the comparator.

[0058] In this embodiment, the randomly generated request message refers to a transaction request data unit dynamically generated by the model module. Specifically, a pseudo-random algorithm can be used to generate different message type combinations, such as alternately generating P-type, NP-type and CPL-type messages within a preset ratio range, to simulate mixed transaction requests in real scenarios. An ascending sequence number label refers to a continuous unique identifier assigned in the order of message generation, which can be specifically implemented using a counter module. Each time an output message is generated, the count value is automatically accumulated to establish a benchmark reference for the message sequence. A labeled data packet refers to a data structure that associates and encapsulates a sequence number label with the original message. Specifically, it can be implemented using a data packet header extension field or an independent metadata file. For example, a 32-bit sequence number field is inserted into the message header to form a parsable verification data unit.

[0059] In this embodiment, during the verification process, the model module uses a randomization engine to generate a mixed request message sequence containing P-type, NP-type, and CPL-type messages, and inputs these messages into the reference model. The reference model assigns an increasing sequence number label to each output message based on the order of receipt. For example, the first output message is labeled 1, and subsequent output messages are labeled 2, 3, and so on. The label and message are bound together through a data structure to form a labeled data packet, which is transmitted to the aligner as the first verification data stream. This process dynamically generates a diverse combination of message types to cover different transaction scenarios, and uses sequential labels to establish the expected output sequence, providing a clear sequence benchmark for subsequent comparisons.

[0060] In this embodiment, by embedding an incremental sequence number label generation mechanism in the reference model, each output message carries a clear sequence identifier, providing the comparator with resolvable sequence benchmark data, thereby supporting automated verification of whether the output of the device under test complies with the sorting and reordering rules specified in the protocol. In this way, the present application can generate an expected data stream containing sequence marks, provide the comparator with an accurate sequence reference benchmark, and solve the problem of automated comparison failure caused by the lack of timing marks in traditional verification environments. By dynamically generating mixed-type messages and binding incremental labels, it is ensured that the verification process covers a variety of transaction scenarios, while achieving reliable tracking and matching of message sequences, thereby improving the accuracy and efficiency of sorting and reordering verification.

[0061] In a feasible embodiment, the step of traversing the label data of the first queue based on the actual output message in the second queue to match the sequential position information of the corresponding message includes: extracting the first actual output message from the second queue; traversing all labeled data packets in the first queue to query the label data with the same content as the actual output message; and obtaining the sequence number value corresponding to the label data as the position information of the current message in the expected sequence.

[0062] In this embodiment, the actual output message refers to the data to be verified generated by the device under test in response to the input request message. This can be achieved by parsing the data stream at the output port of the device under test and used to compare it with the expected results of the reference model. Label data refers to the unique identification information generated by the reference model for each output message. This can be achieved by binding an ascending sequence number to the message content and used to record the order of the message in the expected sequence. Traversing the first queue refers to sequentially scanning all labeled data packets output by the reference model. This can be achieved by storing data packets in a linked list or array structure and implemented through a circular matching mechanism to locate the corresponding position of the output message of the device under test in the expected sequence.

[0063] In this embodiment, after the comparator completes data storage in the first and second queues, it first extracts the first actual output message to be verified from the second queue. It then iterates through all labeled packets in the first queue, comparing their contents one by one. If the message content in the labeled packet is found to be identical to the actual output message, the comparator extracts the incrementing sequence number recorded in the labeled packet. This sequence number represents the original position of the message in the expected output sequence of the reference model. In this way, a mapping relationship is established between the out-of-order messages output by the device under test and the sequential labels generated by the reference model.

[0064] In this embodiment, by introducing tag data with increasing sequence numbers and combining it with a traversal matching mechanism, the comparator can dynamically locate the correct position of the device under test's output message within the expected sequence, providing an accurate basis for subsequent sorting rule verification. This also enables automated positional matching of the device under test's output message with the reference model's expected sequence, resolving the difficulty of sorting verification caused by the lack of timing information in traditional verification environments. It effectively identifies whether reordering operations comply with protocol rules, avoiding the inefficiencies and error risks associated with manual inspection.

[0065] In a feasible embodiment, the step of comparing the expected message type of the first queue with the actual message type of the second queue based on the matching position information, and outputting the verification result according to the PCIe protocol sorting rules includes: based on the position information, obtaining the expected message type at the same position from the first queue; comparing the expected message type with the type of the actual output message; if the types are consistent, determining that the sorting is correct; if not, executing the reordering verification logic.

[0066] In this embodiment, the position information refers to the sequence identifier of the actual output message in the expected sequence, which can be specifically implemented by the value of the incremental sequence number tag. This information is used to locate the corresponding position of the output message of the device under test in the sequence generated by the reference model. The expected message type refers to the compliance message classification identifier generated by the reference model according to the input request, which can be specifically implemented by using the P-type, NP-type or CPL-type protocol field. This classification is used to determine whether the device under test follows the message sequence specified by the protocol. The actual message type refers to the real message classification identifier output by the device under test after responding to the input request. It can be specifically implemented by parsing the traffic type code of the message header field. This classification is used to compare the consistency with the expected type. The reordering verification logic refers to the transaction legitimacy check mechanism triggered when the type is inconsistent. It can be specifically implemented by analyzing the RO attribute value of the CPL-type message. This mechanism is used to determine whether the reordering behavior of the device under test complies with the PCIe protocol exception rules.

[0067] In this embodiment, after the comparator completes the position matching, the expected message type is obtained by reading the type identifier bound to the corresponding sequence number tag in the first queue. The actual message type is obtained by parsing the header field of the message in the second queue. When the two types are consistent, it is directly determined that the sorting behavior of the device under test meets the protocol requirements. When a type difference occurs, for example, a CPL-type message output by the device under test appears in the position where a P-type message is expected, the reordering verification logic is activated. At this time, by checking the RO attribute value of a specific bit in the CPL message header, it is determined whether the reordering is an exception allowed by the protocol. If the RO attribute value is 1, it is confirmed that the device under test has legally executed the reordering operation specified by the protocol.

[0068] This embodiment introduces a hierarchical processing mechanism combining type comparison and reordering logic verification, ensuring both strict verification of regular reordering and intelligent identification of legitimate reordering behaviors. This prevents misjudging permitted protocol exceptions as errors and accurately distinguishes between normal reordering operations and illegal reordering behaviors in the device under test. By automating the verification of protocol exception rules, the integrity and accuracy of PCIe device reordering verification are significantly improved, while reducing the workload of manual analysis.

[0069] In a feasible implementation, the reordering verification logic includes: when the actual output message is of CPL type and the expected message is of P type, checking the RO attribute value of the CPL message; if the RO attribute value is 1, the reordering is determined to be legal; if the RO attribute value is not 1 or the actual output message is of P type and the expected message is of CPL type, the verification is determined to have failed.

[0070] In this embodiment, a CPL-type message refers to a completion-type transaction message, which is used to indicate that the requested transaction has been completed. Specifically, it can be implemented using a message format with a TLP header type field value of 0x4A or 0x5A as specified in the protocol. This type of message needs to follow specific reordering rules during sorting verification. A P-type message refers to a prefetchable non-posted request message, which can be implemented using a read / write request message format defined in the TLP header type field value range of 0x00 to 0x3F. This type of message has a higher priority in the sorting rules. The RO attribute value refers to a reordering permission flag, which can be implemented by parsing specific bits of the CPL message header control field. This attribute value is used to identify whether the current message is allowed to be reordered within the range allowed by the protocol.

[0071] In this embodiment, when the comparer detects a discrepancy between the actual output message type and the expected message type—for example, when the actual output is CPL type and the expected is P type—the reordering verification logic is triggered. By extracting the RO attribute value of the CPL message, if the value is 1, the current reordering behavior complies with the protocol's exceptions, such as when the target device returns a completion message, triggering a legitimate reordering due to insufficient credit. If the RO attribute value is not 1, or the actual output is P type and the expected is CPL type, the device under test violates the protocol's reordering priority rules, and verification is directly determined to have failed. This logic combines the protocol's exception conditions with attribute flags to accurately verify the legitimacy of reordering behavior.

[0072] In this embodiment, by introducing a parsing and determination mechanism for RO attribute values, it is possible to accurately distinguish between legitimate reordering and illegal behavior, avoiding false positives caused by protocol exceptions not being covered. Furthermore, this application can effectively verify whether reordering operations performed by the device under test in credit control or port blocking scenarios comply with protocol exceptions, ensuring that the automated verification system accurately identifies and records reordering behaviors permitted by the protocol.

[0073] In a feasible implementation manner, the RO attribute value is obtained by: parsing a header control field of the CPL message; and extracting a value of the Nth bit in the header control field as the RO attribute flag.

[0074] In this embodiment, the header control field refers to a specific data area in the CPL message format used to store transaction control information. Specifically, this can be achieved using the protocol-specified field parsing method, by parsing the message header structure byte by byte to obtain the target control information. The Nth bit refers to a flag bit predefined in the protocol specification for indicating the reordering permission state. This can be achieved through a binary bit mask operation, such as extracting the logical value of a specified bit at a fixed offset address in the header control field. The location of this bit is determined by the technical documentation corresponding to the PCIe protocol version.

[0075] In this embodiment, during the verification process, when determining the legitimacy of a CPL message's reordering, protocol parsing is first performed on the actual CPL message output by the device under test. The control field data in the message header structure is read, and the storage area containing the RO attribute flag is located according to the protocol-defined format. Furthermore, a bitwise operation function is used to extract the binary value of the Nth bit in this area. If this bit is a logical 1, the current CPL message is deemed to have valid reordering permission. For example, in the PCIe Gen4 protocol, this flag may be located in the 5th bit of the header's control field. A shift operation is performed to shift the target bit to the least significant bit before performing a value check.

[0076] In this embodiment, a protocol-specification-driven bit extraction mechanism accurately adapts to various PCIe protocol variants, ensuring consistency between attribute parsing and actual device behavior, avoiding verification logic failures caused by protocol version upgrades, and accurately identifying CPL message reordering attributes. A protocol-compliant field parsing method ensures that the RO attribute value acquisition process strictly corresponds to actual device behavior, providing a reliable basis for judgment by the automated verification system and effectively reducing the probability of false alarms caused by attribute misjudgment.

[0077] In a feasible implementation manner, the method further includes: configuring an initial credit value and a credit update delay parameter of the device under test through a credit management module, and simulating a port blocking scenario to trigger a reordering behavior.

[0078] In this embodiment, the initial credit value refers to the upper limit of the number of messages that the device under test can process simultaneously in the initial state. Specifically, it can be achieved by setting a credit counter and configuring an initial threshold. This parameter is used to limit the concurrent processing capability of the device under test. The credit update delay parameter refers to the delay time required for credit value recovery. Specifically, a timer module can be used to simulate the delay of the credit recovery response time. This parameter is used to control the timing of credit recovery. The port blocking scenario refers to the state where the device under test is blocked from processing messages due to insufficient resources. Specifically, it can be triggered by dynamically adjusting the credit value to be lower than the actual demand. This scenario is used to simulate congestion in a real network environment. Reordering behavior refers to the operation of the device under test to dynamically adjust the message order according to the PCIe protocol rules. Specifically, it can be forcibly triggered by combining the credit value limit with the delay parameter. This behavior is used to verify the protocol compliance of the device when resources are limited.

[0079] In this embodiment, the credit management module sets the initial credit value to a lower value, for example, the initial credit value is set to 2, so that the device under test can only process two messages at the same time. After the device under test has processed the current message, it needs to wait for the credit value to be restored before it can continue to process subsequent messages. The credit update delay parameter is configured to a specific time interval, for example, set to 100 milliseconds, which is used to control the response delay of credit recovery. When the device under test cannot process new messages due to depletion of credit value, according to the PCIe protocol rules, the device needs to perform reordering operations on subsequent messages to optimize resource utilization. At this time, the credit management module continuously monitors the credit status, updates the credit value after the delay, and triggers the device under test to adjust the message order according to the protocol requirements.

[0080] In this embodiment, by actively controlling the resource allocation of the device under test through credit parameters, it is possible to systematically simulate port blocking conditions and accurately trigger the reordering mechanism specified by the protocol, thereby improving the coverage and controllability of verification scenarios. Specifically, this application can effectively verify the correctness of the protocol implementation of the device under test in scenarios with limited credit resources, ensuring that its reordering behavior complies with PCIe specifications. Through configurable credit parameter combinations, test scenarios with varying degrees of port blocking can be covered.

[0081] In one feasible implementation, the step of configuring the initial credit value and credit update delay parameters of the device under test through a credit management module and simulating a port blocking scenario to trigger reordering behavior includes: setting an initial credit value to limit the number of concurrent message processing by the device under test; controlling the credit recovery response time through a delay parameter, and forcing the device under test to perform a reordering operation according to the PCIe protocol.

[0082] In this embodiment, the initial credit value refers to the upper limit of the number of outstanding transactions that the device under test can process in its initial state. This can be achieved by configuring a credit counter threshold. For example, setting the initial credit value to a value below the normal operating range can quickly trigger a credit exhaustion state. The credit update delay parameter refers to the time interval between the generation and effectiveness of a credit recovery signal. This can be achieved using a programmable timer module. For example, setting the credit update response delay to the maximum value allowed by the protocol can extend the port blocking duration.

[0083] In this embodiment, during the verification process, the initial credit value is set to a lower value to limit the concurrent processing capability of the device under test. When the number of messages processed by the device under test reaches the credit upper limit, the credit management module suspends new message processing requests. At this time, the credit recovery signal is imposed with a preset delay parameter, so that the device under test cannot immediately restore its processing capability after the credit is exhausted. This artificially created port blocking scenario forces the device under test to reorder subsequent messages according to the PCIe protocol rules, such as giving priority to completion messages or adjusting the order of non-posted messages. By dynamically adjusting the combination of the initial credit value and the delay parameter, the reordering trigger conditions specified by various protocols can be covered.

[0084] In this embodiment, the credit management module can actively trigger the reordering behavior of the device under test through precise control of the credit value and recovery timing, thereby reproducing the timing-related anomalies that may occur in real hardware in the verification environment, so that the verification environment can actively generate reordering scenarios that comply with protocol constraints, and detect the protocol compliance of the device under test under credit-restricted conditions through an automated comparison mechanism.

[0085] In a feasible implementation, the tag data includes an increasing unique serial number value, a type identifier of the corresponding message, and source address and destination address information of the message.

[0086] In this embodiment, the incrementing unique serial number value refers to a numerical identifier that increases continuously in the order of message generation, which can be implemented by a counter accumulation method to track the sequential position of the message in the expected sequence. The type identifier refers to a classification mark used to distinguish the message type, which can be implemented by the type coding field specified in the protocol, such as the binary encoding corresponding to the P type, NP type, and CPL type, which is used to identify whether the message type meets expectations during the comparison process. The source address and target address information refers to the transmission path identification data carried in the message, which can be implemented by the address field parsing method defined by the PCIe protocol to verify the correctness of the message transmission path.

[0087] In this embodiment, when output messages are generated in the reference model, each message is assigned tag data containing an increasing sequence number, a type identifier, and address information. When the comparator receives the first verification data stream from the reference model, the unique sequence number in the tag data is used to determine the order of the message in the expected sequence, the type identifier is used to verify whether the message type meets the protocol requirements, and the source address and destination address information are used to verify whether the message transmission path is consistent with the model settings. For example, when the actual message output by the device under test enters the comparator, the system can quickly locate the transmission path of the expected message by traversing the address information in the tag data, and determine whether there is a path error or type conflict in combination with the type identifier.

[0088] In some specific embodiments, the source and destination address information may be generated based on routing rules specified by the PCIe protocol. For example, when using ID-based routing, the address information may include the bus number, device number, and function number. When using address routing, the address information may include a memory address range or an I / O space address. The type identifier may be generated based on the TLP header format specified by the protocol, for example, by extracting the Fmt and Type fields from the header and combining them to generate the type code.

[0089] In this embodiment, by integrating type identifiers and address information, the tag data can simultaneously cover sorting rule verification, type matching verification and path correctness check, thereby realizing multi-dimensional message verification, ensuring that the device under test not only meets the sequence requirements, but also complies with the type constraints and path rules specified in the protocol, effectively identifying type dislocations or path anomalies caused by reordering operations, and improving the comprehensiveness and accuracy of the verification results.

[0090] In a feasible implementation manner, the verification result includes a correct sorting flag, a legal re-sorting event record, and information on the location and type of error messages that violate the sorting rules.

[0091] In this embodiment, the correct sorting flag refers to a Boolean judgment result used to identify whether the output message sequence of the tested device complies with the PCIe protocol sorting rules. Specifically, it can be implemented by a binary flag bit, and is set to a valid state when all message types and sequences are consistent with expectations. Legal reordering event records refer to structured storage of message position change behaviors that comply with the PCIe protocol reordering rules. Specifically, it can be implemented by an event log with a timestamp, and the record content includes the original message label, the adjusted position, and the corresponding RO attribute verification status. The position and type information of the erroneous message that violates the sorting rules refers to feature extraction of messages that have not passed the sorting verification. Specifically, it can be implemented by combining the message hash value and the queue index, and the error location data is generated by capturing the storage position of the message in the second queue and its type identifier.

[0092] In this embodiment, after the comparer completes message type matching, the correct sequence flag is updated in real time to reflect the current verification status. When a discrepancy between the actual message sequence and the expected sequence is detected, the reordering verification logic is activated and generates a legal reordering event record, which contains the CPL message tag that triggered the reordering and its RO attribute verification result. For message sequence deviations that cannot be explained by the protocol rules, the position index, type identifier, and expected type difference of the erroneous message are written to the error information set, forming traceable verification result data.

[0093] In this embodiment, by structured recording of key events in the verification process, not only can the reordering operations that comply with the protocol be accurately identified, but the specific characteristics of the illegal messages can also be precisely located, providing multi-dimensional data support for debugging, and realizing refined verification of the sorting behavior of PCIe devices, effectively distinguishing between legal reordering and protocol violation scenarios. The generated verification results can be directly used for automated test report generation, significantly shortening the error location time, and providing a quantifiable data basis for protocol consistency analysis.

[0094] The PCIE sorting and reordering verification method provided in this application generates an expected data stream with sequence tags through a reference model, combines it with a dynamic comparison of the output stream of the device under test, and introduces a credit management module to simulate the physical layer blocking scenario. It solves the problems of insufficient timing accuracy of the reference model and low efficiency of manual verification in the existing technology, can improve verification accuracy and efficiency, and effectively capture dynamic reordering behavior.

[0095] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A method for verifying PCIE sorting and reordering, characterized in that: The method includes: receiving input request messages from the model module through the reference model, generating label data for each output message in sequence, and outputting the label data and the output message as a first verification data stream to the comparator; receiving an input request message of the model module through the device under test, generating an actual output message, and outputting the actual output message as a second verification data stream to the comparator; Creating a first queue in the comparer to store the first verification data stream, and creating a second queue to store the second verification data stream; Based on the actual output messages in the second queue, traverse the label data of the first queue to match the sequence position information of the corresponding messages; According to the matching position information, the expected message type of the first queue is compared with the actual message type of the second queue, and the verification result is output according to the PCIe protocol sorting rules.

2. The PCIE sorting and reordering verification method according to claim 1, wherein: The steps of receiving an input request message from a model module through a reference model, generating label data for each output message in sequence, and outputting the label data and the output message as a first verification data stream to a comparator include: Sending a randomly generated request message to the reference model through the model module, wherein the request message types include P type, NP type and CPL type; Generating an increasing sequence number label for each output message in the reference model according to the generation order; The increasing sequence number label and the corresponding output message are bound to form a labeled data packet, and output to the comparator as the first verification data stream.

3. The PCIE sorting and re-sorting verification method according to claim 1, wherein: The step of traversing the label data of the first queue to match the sequence position information of the corresponding messages based on the actual output messages in the second queue includes: Extracting the first actual output message from the second queue; Traversing all labeled data packets in the first queue, searching for label data that is identical to the actual output message content; The sequence number value corresponding to the tag data is obtained as the position information of the current message in the expected sequence.

4. The PCIE sorting and reordering verification method according to claim 3, wherein: The step of comparing the expected message type of the first queue with the actual message type of the second queue based on the matched position information, and outputting a verification result according to the PCIe protocol sorting rule includes: Based on the position information, obtaining an expected message type at the same position from the first queue; Comparing the expected message type with the type of the actual output message; If the types are consistent, the sorting is determined to be correct; if not, the re-sorting verification logic is executed.

5. The PCIE sorting and re-sorting verification method according to claim 4, wherein: The reordering verification logic includes: When the actual output message is of CPL type and the expected message is of P type, checking the RO attribute value of the CPL message; If the RO attribute value is 1, the reordering is determined to be legal; If the RO attribute value is not 1 or the actual output message is of type P but is expected to be of type CPL, the verification is considered to have failed.

6. The PCIE sorting and re-sorting verification method according to claim 5, wherein: The method for obtaining the RO attribute value is: Parsing the header control field of the CPL message; The value of the Nth bit in the header control field is extracted as the RO attribute flag.

7. The PCIE sorting and re-sorting verification method according to claim 1, wherein: The method further comprises: The initial credit value and credit update delay parameters of the device under test are configured through the credit management module to simulate a port blocking scenario to trigger reordering behavior.

8. The PCIE sorting and re-sorting verification method according to claim 7, wherein: The step of configuring the initial credit value and credit update delay parameters of the device under test through the credit management module and simulating a port blocking scenario to trigger a reordering behavior includes: Setting an initial credit value to limit the number of concurrent message processing of the device under test; The credit recovery response time is controlled by a delay parameter, forcing the device under test to perform a reordering operation according to the PCIe protocol.

9. The PCIE sorting and re-sorting verification method according to claim 1, wherein: The tag data includes an incrementing unique serial number value, a type identifier of the corresponding message, and the source and destination address information of the message.

10. The PCIE sorting and re-sorting verification method according to claim 1, wherein: The verification result includes a correct sorting flag, a legal re-sorting event record, and the position and type information of the error message that violates the sorting rules.

Images