Protocol verification method and device, computer program product, and machine-readable storage medium
By configuring the verification environment and using verification IP for data sending and receiving, the verification challenges of multi-port and multi-scenario switches are resolved, and a fast and flexible verification method is implemented, suitable for multi-port scenarios of PCIe and CXL protocols.
Patent Information
- Application Number
- CN202510918585.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-04
- Publication Date
- 2025-09-12
- Estimated Expiration
- 2045-07-04
AI Technical Summary
Existing verification schemes have difficulty in fully verifying multiple ports and multiple scenarios in switches, especially in PCIe and CXL protocols, especially when supporting bifurcated mode, where there are complex scenarios with different link widths and link speeds.
By configuring the port mode of the verification environment, dividing the sub-environment, instantiating the verification components, and sending and receiving data between the DUTs through the verification IP, selecting the data forwarding mode, setting the data format conversion, and using the credit management and data conversion modules, the verification of multi-port functions can be achieved.
It achieves rapid verification of multiple ports and multiple scenarios, reduces the workload of verification engineers, saves verification time, and can verify under different configurations, link widths and link speeds, and quickly switch verification environments.
Smart Images

Figure CN120416121B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of verification technology, and in particular to a protocol verification method and apparatus, a computer program product, and a machine-readable storage medium. Background Art
[0002] The Peripheral Component Interconnect Express (PCIe) and Cross-Link Express (CXL) protocols are characterized by extensive content and complex scenarios, making their verification extremely tedious. Within a switch, upstream ports (UP) and downstream ports (DP) are distinguished by their location, each with significantly different functions. Furthermore, ports supporting the high-speed serial link protocol must support not only the Peripheral Component Interconnect Express (PCIe) protocol but also the high-speed serial link protocol. Furthermore, when bifurcation mode is supported, ports with different link widths and speeds may coexist.
[0003] Existing verification solutions can only provide good support for single-host and single-function devices, but cannot fully verify the multi-port and multi-scenarios in switches. Summary of the Invention
[0004] The present application aims to provide a protocol verification method and apparatus, a computer program product, and a machine-readable storage medium that can simply and quickly instantiate multiple ports with different characteristics. Verification of different scenarios can be achieved by simply making corresponding changes to the configuration file.
[0005] A protocol verification method, comprising:
[0006] Configure the port mode to be selected for the verification environment, divide the verification environment into different sub-environments based on the port mode, and instantiate verification components in the sub-environments;
[0007] Configure the fork mode of the DUT and implement the routing logic of the DUT based on the fork mode;
[0008] Instantiate two sets of DUTs connected at the application layer interface. The two sets of DUTs send and receive data through the Verification IP (VIP). The two sets of DUTs share the same forking mode and select the data forwarding mode supported by the data.
[0009] Set the output data of the ingress DUT application layer to be converted into the format required by the egress DUT application layer and then output in sequence;
[0010] The two groups of DUTs send transaction layer data packets respectively, and compare the transaction layer data packets of the DUTs in the receiving direction with the transaction layer data packets of the simulated DUTs in the sending direction.
[0011] Optionally, the routing logic implemented based on the fork mode includes:
[0012] Instantiate 1 to 4 sets of port environment variables in fork mode;
[0013] Each group of port environment variables verifies the IP mode according to the port mode control;
[0014] Instantiate an interface between the connector and the verification IP, configure the interface to the bifurcation mode of the device under test according to the bifurcation mode, and transmit parameters through the interface.
[0015] Optionally, the connector controls a connection mode of a differential line connected to the device under test through polarity flipping, channel position flipping, and tilt parameters.
[0016] Optionally, select the data forwarding mode supported by the data, including:
[0017] Configure the target bandwidth of the two groups of DUTs to be consistent;
[0018] Configure the DUT to support store-and-forward mode, pass-through mode, and bypass mode.
[0019] Optionally, setting the output data of the ingress DUT application layer to be converted into the format required by the egress DUT application layer includes: setting the output data of the ingress DUT application layer to be re-encoded into transaction layer data packet format according to the Peripheral Component Interconnect Express channel and high-speed serial connection protocol specifications.
[0020] Optionally, the output data of the ingress DUT application layer is converted into the format required by the egress DUT application layer and outputted in sequence, including: setting a two-level first-in-first-out buffer to control credit management within the DUT, wherein the first-level first-in-first-out buffer caches the original signal received from the ingress DUT application layer, and the second-level first-in-first-out buffer caches the data converted into the transaction layer data packet format, and the data outputted to the egress DUT is arranged in the original sequence; each level of the first-in-first-out buffer includes: buffer parameters for messages not requiring return, buffer parameters for messages requiring return, buffer parameters for completed messages, and buffer parameters for message sorting.
[0021] A protocol verification device, for executing a protocol verification method as described in any one of the above, comprising: a verification module, a first device to be tested, a second device to be tested, and a credit management and data conversion module; a first end of the verification module is connected to the first end of the first device to be tested, a second end of the verification module is connected to the second end of the first device to be tested, a third end of the verification module is connected to the first end of the second device to be tested, and a fourth end of the verification module is connected to the second end of the second device to be tested; a third end of the first device to be tested is connected to the first end of the credit management and data conversion module, and a third end of the second device to be tested is connected to the second end of the credit management and data conversion module.
[0022] Optionally, the verification module includes: a first transmitter, a first driver, a first simulator, a first checker, a first collector, a first receiver, a second transmitter, a second driver, a second simulator, a second checker, a second collector, a second receiver, a first connector, and a second connector;
[0023] The first end of the first transmitter is connected to the first end of the first driver, the first simulator, the first checker, the first collector and the first receiver in sequence, the second end of the first transmitter is connected to the first end of the first connector, and the second end of the first receiver is connected to the first end of the second connector;
[0024] The first end of the second transmitter is connected to the first end of the second driver, the second simulator, the second checker, the second collector and the second receiver in sequence, the second end of the second transmitter is connected to the second end of the second connector, and the second end of the second receiver is connected to the second end of the first connector;
[0025] The third end of the first connector is the first end of the verification module, the third end of the second connector is the third end of the verification module; the third end of the first driver is the second end of the verification module, and the third end of the second driver is the fourth end of the verification module.
[0026] Optionally, the credit management and data conversion module includes: a data converter and a credit manager, the first end of the data converter is connected to the first end of the credit manager, the second end of the data converter is the first end of the credit management and data conversion module, and the third end of the data converter is the second end of the credit management and data conversion module.
[0027] Optionally, according to the configured port mode to be selected, the port modes of the first device under test and the second device under test divide the verification module into different port modes.
[0028] Optionally, the first DUT and the second DUT receive configuration parameters of the verification module to control a bifurcation mode of the DUT.
[0029] A computer program product includes a computer program, which implements any one of the above-mentioned protocol verification methods when executed by a processor.
[0030] A machine-readable storage medium stores a computer program, which, when executed by a processor, implements a protocol verification method as described in any one of the above.
[0031] The protocol verification method and device, computer program product, and machine-readable storage medium provided by this application use two verification IPs to receive or send data between two devices under test, and at the same time configure different port modes inside the two devices under test to achieve the effect of multi-port function, so that a complete data path is realized between the two verification IPs, and the receiving and sending functions of the two devices under test are verified respectively. By simply modifying the port mode configured in the verification environment and the bifurcation mode of the device under test, it is possible to flexibly build verification environments for different scenarios and quickly switch application scenarios with different numbers of devices. Verification using verification IP has the ability to automatically check and reply data, which can reduce a considerable amount of the workload of verification engineers in setting up the environment. The result of the verification comparison is only whether the sent data and the received data are consistent. Furthermore, the details of data reception and transmission are verified from the perspective of bus transactions (BT), and the data flows of different application scenarios at the system level are simulated to verify the functions of the DUT in different application scenarios such as fork mode, peripheral component interconnection fast channel protocol port, and high-speed serial connection protocol port. The DUT's processing capabilities for various bus transactions are verified from the perspective of system coordination. Verification can also be performed simultaneously for ports with different configurations, different link widths, and different link speeds, which greatly saves verification time and accelerates project progress.
[0032] In order to make the above features and advantages of the application more obvious and easy to understand, the following embodiments are given and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS
[0033] Figure 1 This is a flowchart of a protocol verification method provided by this application.
[0034] Figure 2 This is a module diagram of a protocol verification device provided in this application. DETAILED DESCRIPTION
[0035] To make the purpose and technical solutions of the embodiments of the present application clearer, the technical solutions of the embodiments of the present application will be clearly and completely described below in conjunction with the drawings of the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the described embodiments of the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0036] See also Figure 1 , Figure 1 This is a flowchart of a protocol verification method provided by this application. This application provides a protocol verification method, including: steps S1 to S5.
[0037] Step S1: configuring a port mode to be selected for the verification environment, dividing the verification environment into different sub-environments according to the port mode, and instantiating verification components in the sub-environments;
[0038] Step S2: configuring the bifurcation mode of the device under test, and implementing the routing logic of the device under test according to the bifurcation mode;
[0039] Step S3: Instantiate two groups of DUTs to connect at the application layer interface. The two groups of DUTs send and receive data through the verification IP. The two groups of DUTs share a bifurcation mode and select a data forwarding mode supported by the data.
[0040] Step S4: converting the output data of the inlet DUT application layer into the format required by the outlet DUT application layer and outputting the data in sequence;
[0041] Step S5: The two DUTs send transaction layer data packets (TLPs) respectively, and compare the transaction layer data packets of the DUT in the receiving direction with the transaction layer data packets of the simulated DUT in the sending direction.
[0042] In step S1, see Figure 1 In step S1, the port mode to be selected for the verification environment is configured, the verification environment is divided into different sub-environments according to the port mode, and the verification components are instantiated in the sub-environments.
[0043] As an example, the parameter port_type is defined to represent the port mode, and the port mode port_type includes the standard high-speed peripheral interconnect extension bus protocol port mode up_mode, the network port mode Fport_mode, and the high-speed link bus protocol port mode cxl_mode.
[0044] Specifically, in the standard high-speed peripheral interconnect extended bus protocol port mode (up_mode), DUT controller 0 is defined as the upstream port (UP), and DUT controller 1 is defined as the downstream port (DP). In the network port mode (fport_mode), DUT controllers 0 and 1 are both defined as downstream ports. In the high-speed link bus protocol port mode (cxl_mode), DUT controllers 0 and 1 are used to verify port scenarios supporting the CXL protocol. Both DUT controllers 0 and 1 can function as ingress and egress DUTs, receiving and transmitting data.
[0045] As an example, verification components include: a connector, a model, a monitor, and a checker.
[0046] Furthermore, the verification component also includes: a simulator (rm), a transmitter (TX) and a receiver (RX).
[0047] Specifically, the transmitter and receiver use verification IP to implement data transmission and reception.
[0048] In step S2, see Figure 1 In step S2, the bifurcation mode of the device under test is configured, and the routing logic of the device under test is implemented according to the bifurcation mode.
[0049] As an example, define the parameter sys_mode in the configuration file. The parameter sys_mode is used to control the bifurcation mode of the device under test. In bifurcation mode, instantiate 1 to 4 groups of port environment variables port_env. The port environment variables port_env include the following: parameters X16_PCle_controllor, X8_PCle_controllor, and X4_PCle_controllor, which are used to indicate the number of links the port is divided into.
[0050] Specifically, one group of port environment variables port_env can be instantiated, and the parameter X16_PCle_controllor can be used to indicate that the port is divided into one group of 16 links; two groups of port environment variables port_env can be instantiated, and the parameter X8_PCle_controllor can be used to indicate that the port is divided into two groups of 8 links; four groups of port environment variables port_env can be instantiated, and the parameter X4_PCle_controllor can be used to indicate that the port is divided into four groups of four links.
[0051] Each group of port environment variables port_env controls the mode of verifying IP according to the port mode port_type.
[0052] Specifically, the application scenarios for the verification IP include: host scenario (Host), high-speed link bus protocol scenario (CXL), and network port scenario (Fport). In the standard high-speed peripheral interconnect extended bus protocol port mode (up_mode), the verification IP selects the host scenario, the upstream port uses verification IP0 in root endpoint (RC) mode, and the downstream port uses verification IP1 in endpoint (EP) mode. In the network port mode (Fport_mode), the verification IP selects the host scenario or network port scenario, and randomly configures verification IP0 and verification IP1. In the high-speed link bus protocol port mode (cxl_mode), the verification IP selects the host scenario or high-speed link bus protocol scenario, and the verification IP is configured in CXL_VIP mode.
[0053] As an example, the bifurcation mode implements routing logic through the connector. Eight groups of interfaces pcie_vip_if are always instantiated between the connector and the verification IP. The default width of the interface pcie_vip_if is consistent with the width of the device under test. The interface pcie_vip_if is configured to the bifurcation mode of the device under test according to the parameter sys_mode. The device under test passes the appropriate pcie_vip_if parameters to the instantiated verification IP.
[0054] In a specific embodiment of the present application, the bifurcation mode of the device under test instantiates a set of port environment variables port_env, including: parameter X16_PCle_controllor, which divides the device under test into 16 links, and accordingly uses the parameter X16_PCle_controllor to configure the interface pcie_vip_if, and transmits the 16 links to a verification IP through a set of interfaces pcie_vip_if.
[0055] As an example, the connector controls the connection mode of the differential line connected to the device under test through polarity flipping, channel position (Lane) flipping, and skew parameters.
[0056] In step S3, see Figure 1 In step S3, two sets of DUTs are connected at the application layer interface. Data is sent and received between the two sets of DUTs through the verification IP. The two sets of DUTs share the forking mode and select the data forwarding mode supported by the data.
[0057] As an example, the port mode port_type of the verification environment is selected according to the port modes port_type of the two groups of instantiated DUTs, and the verification environment is divided into different sub-environments.
[0058] Furthermore, the target bandwidth target_width of the two groups of DUTs is always configured to be consistent. For example, the target bandwidth target_width is both configured to x4. The two groups of DUTs use four links for data transmission, and data can be transmitted at the corresponding bandwidth and rate. The ingress DUT sends data at a stable rate, and the egress DUT also receives data at the same rate. The ingress DUT does not send data too quickly, and the egress DUT is unable to process data in time, resulting in data backlog, thereby avoiding the problem of data interruption.
[0059] Furthermore, the DUT is configured to support store-and-forward (store_forward), cutthrough (cutthrough), and bypass (bypass) modes. During data forwarding, even if the target bandwidths of the two DUTs are consistent, protocol overhead, routing decisions, or buffer queuing may lead to instantaneous bandwidth mismatches during data transmission. Therefore, the cutthrough mode is preferred. When the bandwidth of the egress DUT is lower than the bandwidth of the ingress DUT, the cutthrough mode ensures that the ingress DUT does not experience data interruptions, ensuring the efficiency and stability of the data path in various situations, rather than relying solely on static bandwidth matching.
[0060] In step S4, see Figure 1 In step S4, the output data of the inlet DUT application layer is converted into the format required by the outlet DUT application layer and then output in sequence.
[0061] As an example, the output data of the application layer of the ingress DUT may be parallel, byte-organized data, while the egress DUT needs to comply with transaction layer data packets of the Peripheral Component Interconnect Express channel and high-speed serial connection protocols. The output data of the application layer of the ingress DUT is set to be re-encoded into data in the transaction layer data packet format according to the Peripheral Component Interconnect Express channel and high-speed serial connection protocol specifications.
[0062] Furthermore, a two-level first-in-first-out (FIFO) buffer is set up to control credit management within the DUT, ensuring smooth data flow between the two DUTs. Due to latency differences between different paths or parallel processing leading to different completion times, data forwarding may become out of order. The first-level FIFO buffer caches the original signals received from the ingress DUT's application layer to prevent data loss due to speed fluctuations. The second-level FIFO buffer caches data that has been converted to the transaction layer packet format, ensuring that data sent to the egress DUT is in its original order.
[0063] Specifically, each level of the FIFO buffer includes: a buffer parameter for messages not to be returned Ctrl0_P_fifoDepth ctrl, a buffer parameter for messages to be returned Ctrl0_NP_fifo Depth ctrl, a buffer parameter for completed messages Ctrl0_CPL_fifo Depth ctrl, and a buffer parameter for message sorting Ctrl0_order_fifo Depth ctrl.
[0064] In step S5, see Figure 1 In step S5, the two DUTs respectively send transaction layer data packets through the verification component, and compare the transaction layer data packets of the DUT in the receiving direction with the transaction layer data packets of the simulated DUT in the sending direction.
[0065] In one embodiment of the present application, two DUTs use a standard high-speed peripheral interconnect extension bus protocol port mode up_mode, wherein DUT controller 0 is an upstream port and DUT controller 1 is a downstream port.
[0066] As an example, in the verification environment, define the parameter VIP0_as_RC_TX to indicate the VIP signal that enables sending data to the upstream port, define the parameter VIP0_as_RC_RX to indicate the VIP signal that enables receiving data output from the upstream port, define the parameter VIP1_as_EP_TX to indicate the VIP signal that enables sending data to the downstream port, define the parameter VIP1_as_EP_RX to indicate the VIP signal that enables receiving data output from the downstream port, define the parameter cp_host_monitor to indicate the transaction layer data packet collected from the upstream port, define the parameter cp_ep_monitor to indicate the transaction layer data packet collected from the downstream port, and define the parameter cp_host_model is used to represent the stimulus signal generated to the upstream port, the parameter cp_ep_model is defined to represent the stimulus signal generated to the downstream port, the parameter cp_downstream_rm is defined to represent the transaction layer data packet sent in the direction of the simulated upstream port, the parameter cp_upstream_rm is defined to represent the transaction layer data packet sent in the direction of the simulated downstream port, the parameter cp_upstream_checker is defined to represent the comparison result between the upstream port output data and the simulated downstream port output data, and the parameter cp_downstream_checker is defined to represent the comparison result between the downstream port output data and the simulated upstream port output data.
[0067] As an example, after configuring the verification environment, use the VIP0_as_RC_TX, VIP0_as_RC_RX, VIP1_as_RC_TX, and VIP1_as_RC_RX parameters to send the desired transaction layer data packet. Compare the transaction layer data packet of the DUT in the receiving direction with the transaction layer data packet of the simulated DUT in the transmitting direction to complete data reception and transmission verification for the two DUTs.
[0068] The protocol verification method provided in this application receives or sends data between two devices under test through two verification IPs, and at the same time configures different port modes inside the two devices under test to achieve the effect of multi-port function, so that a complete data path is realized between the two verification IPs, and the receiving and sending functions of the two devices under test are verified respectively. Only by modifying the configured port mode port_type and parameter sys_mode, it is possible to flexibly build a verification environment for different scenarios.
[0069] This application also provides a protocol verification device for executing the above-mentioned protocol verification method, see Figure 2 , Figure 2 This is a module diagram of a protocol verification device provided in this application. The protocol verification device includes: a verification module 1, a first device under test 2, a second device under test 3, and a credit management and data conversion module 4.
[0070] As an example, the first end of the verification module 1 is connected to the first end of the first device to be tested 2, the second end of the verification module 1 is connected to the second end of the first device to be tested 2, the third end of the verification module 1 is connected to the first end of the second device to be tested 3, and the fourth end of the verification module 1 is connected to the second end of the second device to be tested 3; the third end of the first device to be tested 2 is connected to the first end of the credit management and data conversion module 4, and the third end of the second device to be tested 3 is connected to the second end of the credit management and data conversion module 4.
[0071] As an example, the verification module 1 includes: a first transmitter 11, a first driver 12, a first simulator 13, a first checker 14, a first collector 15, a first receiver 16, a second transmitter 17, a second driver 18, a second simulator 19, a second checker 110, a second collector 111, a second receiver 112, a first connector 113 and a second connector 114; the first end of the first transmitter 11 is connected to the first end of the first driver 12, the first simulator 13, the first checker 14, the first collector 15 and the first receiver 16 in sequence, the second end of the first transmitter 11 is connected to the first end of the first connector 113, and the first end of the first receiver 16 is connected to the first end of the first connector 113. The two ends are connected to the first end of the second connector 114; the first end of the second transmitter 17 is connected to the first end of the second driver 18, the second simulator 19, the second checker 110, the second collector 111 and the second receiver 112 in sequence, the second end of the second transmitter 17 is connected to the second end of the second connector 114, and the second end of the second receiver 112 is connected to the second end of the first connector 113; the third end of the first connector 113 is the first end of the verification module 1, and the third end of the second connector 114 is the third end of the verification module 1; the third end of the first driver 12 is the second end of the verification module 1, and the third end of the second driver 18 is the fourth end of the verification module 1.
[0072] As an example, the credit management and data conversion module 4 includes: a data converter 41 and a credit manager 42, the first end of the data converter 41 is connected to the first end of the credit manager 42, the second end of the data converter 41 is the first end of the credit management and data conversion module 4, and the third end of the data converter 41 is the second end of the credit management and data conversion module 4.
[0073] In one embodiment of the present application, the port mode to be selected by verification module 1, port_type, and the bifurcation mode parameter sys_mode of the DUT are configured. First DUT 2 and second DUT 3 adopt the standard high-speed peripheral interconnect extension bus protocol port mode up_mode. Based on the port modes of first DUT 2 and second DUT 3, verification module 1 is divided into the standard high-speed peripheral interconnect extension bus protocol port mode up_mode. Verification components are configured in verification module 1, with first DUT 2 as the upstream port and second DUT 3 as the downstream port. First DUT 2 and second DUT 3 receive the configuration parameter sys_mode of verification module 1 to control the bifurcation mode of the DUTs.
[0074] As an example, first transmitter 11 and second transmitter 17 are connected to first DUT 2 and second DUT 3 via differential lines via first connector 113 and second connector, respectively, for transmitting transaction layer data packets. First transmitter 11 generates verification parameter IP0_as_RC_TX, while second transmitter 17 generates verification parameter IP1_as_RC_TX. First receiver 16 and second receiver 112 are connected to differential lines of first DUT 2 and second DUT 3, respectively, for receiving transaction layer data packets. First receiver 16 generates parameter cp_host_monitor, while second receiver 112 generates parameter cp_ep_monitor.
[0075] As an example, the first driver 12 and the second driver 18 are connected to the differential lines of the first DUT 2 and the second DUT 3, respectively. The first driver 12 and the second driver 18 internally integrate CXL_VIP type verification IP, which is used to randomly send request messages P of the type that does not require a return and request messages NP of the type that requires a return, thereby stimulating the simulator and the transmitter. Among them, the first driver 12 generates the parameter cp_host_model, and the second driver 18 generates the parameter cp_ep_model.
[0076] As an example, the first simulator 13 and the second simulator 19 are used to simulate the behaviors of the first DUT 2 and the second DUT 3 respectively, and output simulated DUT transaction layer data packets; wherein the first simulator 13 generates the parameter cp_downstream_rm, and the second simulator 19 generates the parameter cp_upstream_checker.
[0077] As an example, the first collector 15 and the second collector 111 are used to collect transaction layer data packets output by the device under test; wherein the first collector 15 generates the parameter cp_ep_monitor, and the second collector 111 generates the parameter cp_host_monitor.
[0078] As an example, the first checker 14 and the second checker 110 are used to compare transaction layer data packets of the DUT in the receiving direction with transaction layer data packets of the simulated DUT in the sending direction. The transaction layer data packets are compared according to the pre-divided ID and address space to complete data reception and transmission verification of the first DUT 2 and the second DUT 3. The first checker 14 generates the parameter cp_downstream_checker, and the second checker 110 generates the parameter cp_upstream_checker.
[0079] As an example, the first connector 113 and the second connector 114 are used to implement routing logic according to the bifurcation mode of the first DUT 2 and the second DUT 3 , and control the connection mode of the differential lines connected to the first DUT 2 and the second DUT 3 through polarity flipping, channel position flipping and tilt parameters.
[0080] As an example, the data converter 41 is used to re-encode the output data of the ingress DUT application layer into data in the transaction layer data packet format according to the Peripheral Component Interconnect Express protocol and the High Speed Serial Link protocol specifications, and convert it into the format required by the egress DUT application layer.
[0081] As an example, the credit manager 42 is used to implement credit management between the first DUT 2 and the second DUT 3. By setting a two-level first-in-first-out buffer, the data sent to the inlet DUT and the outlet DUT are arranged in the original order. Among them, the parameters generated by the credit manager 42 include: the message buffer parameter not requiring return Ctrl0_P_fifo Depthctrl, the message buffer parameter requiring return Ctrl0_NP_fifo Depth ctrl, the message buffer parameter completed Ctrl0_CPL_fifo Depth ctrl, and the message sorting buffer parameter Ctrl0_order_fifo Depth ctrl.
[0082] The protocol verification device provided by this application mainly uses a connector to control the connection mode between the device under test and the verification IP, and uses a credit management and data conversion module to control the credit management between the two devices under test. The output data of the application layer of the inlet device under test is converted into the format required by the application layer of the outlet device under test and then arranged in sequence so that the two devices under test can flow normally. By using two verification IPs to receive or send data between the two devices under test, and configuring different port modes inside the two devices under test to achieve the effect of multi-port function, a complete data path is realized between the two verification IPs, and the receiving and sending functions of the two devices under test are verified respectively. By simply modifying the port mode port_type configured in the verification environment and the bifurcation mode of the device under test, it is possible to flexibly build verification environments for different scenarios and quickly switch application scenarios with different numbers of devices. Verification is performed using a verification IP with the ability to automatically check and reply data, which can reduce a considerable amount of the workload of verification engineers in setting up the environment. The result of the verification comparison is only whether the sent data and the received data are consistent. Furthermore, the details of data reception and transmission are verified from the perspective of bus transactions, and the data flow of different application scenarios at the system level is simulated to verify the functions of the DUT in different application scenarios such as fork mode, peripheral component interconnection fast channel protocol port, and high-speed serial connection protocol port. The processing ability of the DUT for various bus transactions is verified from the perspective of system coordination. It can also simultaneously verify ports with different configurations, different link widths and different link speeds, which greatly saves verification time and speeds up project progress.
[0083] The present application also provides a computer program product, including a computer program, which implements the above-mentioned protocol verification method when executed by a processor.
[0084] The present application also provides a machine-readable storage medium storing a computer program, which implements the above-mentioned protocol verification method when executed by a processor.
[0085] Although the present application has been disclosed above with reference to the embodiments, they are not intended to limit the present application. Anyone with ordinary knowledge in the technical field may make slight changes and modifications without departing from the spirit and scope of the present application. Therefore, the scope of protection of the present application shall be determined by the scope of the appended patent application.
Claims
1. A protocol verification method, characterized in that: include, Configure the port mode to be selected for the verification environment, divide the verification environment into different sub-environments based on the port mode, and instantiate verification components in the sub-environments; Configure the fork mode of the DUT and implement the routing logic of the DUT based on the fork mode; Instantiate two groups of DUTs to connect at the application layer interface. The two groups of DUTs send and receive data through the verification IP. The two groups of DUTs share the bifurcation mode and select the data forwarding mode supported by the data. Set the output data of the ingress DUT application layer to be converted into the format required by the egress DUT application layer and then output in sequence; The two groups of DUTs send transaction layer data packets respectively, and compare the transaction layer data packets of the DUTs in the receiving direction with the transaction layer data packets of the simulated DUTs in the sending direction.
2. The protocol verification method according to claim 1, wherein: Implementing routing logic based on the fork mode includes: Instantiate 1 to 4 sets of port environment variables in fork mode; Each group of port environment variables verifies the IP mode according to the port mode control; Instantiate an interface between the connector and the verification IP, configure the interface to the bifurcation mode of the device under test according to the bifurcation mode, and transmit parameters through the interface.
3. The protocol verification method according to claim 2, wherein: The connector controls the connection mode of the differential line connected to the device under test through polarity flipping, channel position flipping, and tilt parameters.
4. The protocol verification method according to claim 1, wherein: Select the data forwarding mode supported by the data, including: Configure the target bandwidth of the two groups of DUTs to be consistent; Configure the DUT to support store-and-forward mode, pass-through mode, and bypass mode.
5. The protocol verification method according to claim 1, wherein: The output data of the inlet device under test application layer is converted into the format required by the outlet device under test application layer, including: setting the output data of the inlet device under test application layer to be re-encoded into transaction layer data packet format according to the peripheral component interconnect express channel and high-speed serial connection protocol specifications.
6. The protocol verification method according to claim 5, wherein: The output data of the ingress DUT application layer is converted into the format required by the egress DUT application layer and outputted in sequence, including: setting a two-level FIFO buffer to control credit management within the DUT, wherein the first-level FIFO buffer caches the original signal received from the ingress DUT application layer, and the second-level FIFO buffer caches the data converted into the transaction layer data packet format, and the data outputted to the egress DUT is arranged in the original sequence; each level of the FIFO buffer includes: buffer parameters for messages not requiring return, buffer parameters for messages requiring return, buffer parameters for completed messages, and buffer parameters for message sorting.
7. A protocol verification device, configured to execute the protocol verification method according to any one of claims 1 to 6, characterized in that: include: Verification module, first piece to be tested, second piece to be tested, credit management and data conversion module; the first end of the verification module is connected to the first end of the first piece to be tested, the second end of the verification module is connected to the second end of the first piece to be tested, the third end of the verification module is connected to the first end of the second piece to be tested, and the fourth end of the verification module is connected to the second end of the second piece to be tested; the third end of the first piece to be tested is connected to the first end of the credit management and data conversion module, and the third end of the second piece to be tested is connected to the second end of the credit management and data conversion module.
8. The protocol verification device according to claim 7, wherein: The verification module includes: a first transmitter, a first driver, a first simulator, a first checker, a first collector, a first receiver, a second transmitter, a second driver, a second simulator, a second checker, a second collector, a second receiver, a first connector, and a second connector; The first end of the first transmitter is connected to the first end of the first driver, the first simulator, the first checker, the first collector and the first receiver in sequence, the second end of the first transmitter is connected to the first end of the first connector, and the second end of the first receiver is connected to the first end of the second connector; The first end of the second transmitter is connected to the first end of the second driver, the second simulator, the second checker, the second collector and the second receiver in sequence, the second end of the second transmitter is connected to the second end of the second connector, and the second end of the second receiver is connected to the second end of the first connector; The third end of the first connector is the first end of the verification module, the third end of the second connector is the third end of the verification module; the third end of the first driver is the second end of the verification module, and the third end of the second driver is the fourth end of the verification module.
9. The protocol verification device according to claim 7, wherein: The credit management and data conversion module includes: a data converter and a credit manager, the first end of the data converter is connected to the first end of the credit manager, the second end of the data converter is the first end of the credit management and data conversion module, and the third end of the data converter is the second end of the credit management and data conversion module.
10. The protocol verification device according to claim 7, wherein: According to the configured port mode to be selected, the port modes of the first DUT and the second DUT divide the verification module into different port modes.
11. The protocol verification device according to claim 7, wherein: The first DUT and the second DUT receive configuration parameters of the verification module to control the bifurcation mode of the DUT.
12. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, a protocol verification method according to any one of claims 1 to 6 is implemented.
13. A machine-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, a protocol verification method according to any one of claims 1 to 6 is implemented.
Citation Information
Patent Citations
PCIe Switch bifurcation characteristic verification system and method
CN120144514A
Elastic Multi-Directional Resource Augmentation in a Switched CXL Fabric
US20250202839A1