Protocol verification method and device, computer program product and machine readable storage medium

Abstract

The invention discloses a protocol verification method and device, a computer program product and a machine readable storage medium, and belongs to the technical field of verification, and the method comprises the steps: configuring a port mode of a verification environment, dividing the verification environment into different sub-environments according to the port mode, and instantiating a verification component in the sub-environments; configuring a bifurcation mode of the to-be-tested piece, and realizing routing logic of the to-be-tested piece; the method comprises the following steps: instantiating two groups of pieces to be tested, sending and receiving data by verifying an IP, sharing a bifurcation mode, and selecting a data forwarding mode supported by the data; converting the data of the two groups of to-be-tested pieces into required formats and then outputting the data in sequence; and the two groups of pieces to be tested send transaction layer data packets respectively, and data comparison is carried out in the receiving direction and the sending direction. According to the invention, application scenes of different numbers of devices can be quickly switched, and verification is carried out for ports, link widths and link speeds of different configurations, so that verification time is greatly saved.

Description

Technical Field

[0001] The present application relates to the field of verification technologies, 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 Compute Express Link (CXL) protocols have the characteristics of a large amount of content and complex scenarios, and the verification work for them is extremely cumbersome. In a switch, according to different positions, it is divided into an upstream port (UP) and a downstream port (DP). The functions of different ports are significantly different. In addition, ports that support the High-Speed Serial Link protocol need to support the characteristics of the Peripheral Component Interconnect Express protocol in addition to the characteristics of the High-Speed Serial Link protocol. At the same time, in the case of supporting bifurcation mode, there will be ports with different link widths and link speeds at the same time.

[0003] Existing verification solutions can mainly support single-host and single-function devices well, but cannot fully verify multiple ports and multiple scenarios in a switch. 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, and only need to make corresponding changes to the configuration file to achieve verification of different scenarios.

[0005] A protocol verification method includes: Configuring the port mode to be selected in the verification environment, dividing the verification environment into different sub-environments according to the port mode, and instantiating verification components in the sub-environments; Configuring the bifurcation mode of the device under test, and implementing the routing logic of the device under test according to the bifurcation mode; Instantiating two groups of devices under test to dock at the application layer interface, sending and receiving data between the two groups of devices under test through a Verification IP (VIP), sharing the bifurcation mode by the two groups of devices under test, and selecting the data forwarding mode supported by the data; Setting the output data of the application layer of the ingress device under test to be converted into the format required by the application layer of the egress device under test and output in sequence; The two groups of devices under test respectively send transaction layer packets, and compare the transaction layer packets of the device under test in the receiving direction with the simulated transaction layer packets of the device under test in the sending direction.

[0006] Optionally, implementing the routing logic according to the bifurcation mode includes: Instantiate 1 to 4 groups of port environment variables in the forking mode; Each group of port environment variables controls the verification IP mode according to the port mode; Instantiate an interface between the connector and the verification IP, configure the interface correspondingly to the forking mode of the device under test according to the forking mode, and perform parameter transmission through the interface.

[0007] Optionally, the connector controls the connection mode of the differential lines connected to the device under test through polarity inversion, channel position inversion, and tilt parameter control.

[0008] Optionally, select the data forwarding mode supported by the data, including: Configure the target bandwidths of two groups of devices under test to be the same; Configure the device under test to support the store-and-forward mode, the through mode, and the bypass mode.

[0009] Optionally, set the output data of the application layer of the input device under test to be converted into the format required by the application layer of the output device under test, including: setting the output data of the application layer of the input device under test to be re-encoded into the data in the format of the transaction layer packet according to the Peripheral Component Interconnect Express and High-Speed Serial Link protocol specifications.

[0010] Optionally, set the output data of the application layer of the input device under test to be converted into the format required by the application layer of the output device under test and output in sequence, including: setting two-level first-in-first-out buffers to control the credit management inside the device under test. The first-level first-in-first-out buffer caches the original signals received from the application layer of the input device under test, and the second-level first-in-first-out buffer caches the data that has been converted into the format of the transaction layer packet. The data output and sent to the output device under test is arranged in the original order; each level of the first-in-first-out buffer includes: the buffer parameters for non-return messages, the buffer parameters for messages that need to be returned, the buffer parameters for completion messages, and the buffer parameters for message sorting.

[0011] A protocol verification device for performing the protocol verification method described in any one of the above, including: a verification module, a first device under test, a second device under test, a credit management and data conversion module; the first end of the verification module is connected to the first end of the first device under test, the second end of the verification module is connected to the second end of the first device under test, the third end of the verification module is connected to the first end of the second device under test, and the fourth end of the verification module is connected to the second end of the second device under test; the third end of the first device under test is connected to the first end of the credit management and data conversion module, and the third end of the second device under test is connected to the second end of the credit management and data conversion module.

[0012] 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; The first end of the first transmitter is sequentially connected to the first ends of the first driver, the first simulator, the first checker, the first collector, and the first receiver. The second end of the first transmitter is connected to the first end of the first connector. 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 sequentially connected to the first ends of the second driver, the second simulator, the second checker, the second collector, and the second receiver. The second end of the second transmitter is connected to the second end of the second connector. 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. The third end of the second driver is the fourth end of the verification module.

[0013] 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. The third end of the data converter is the second end of the credit management and data conversion module.

[0014] 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.

[0015] Optionally, the first device under test and the second device under test receive the configuration parameters of the verification module to control the bifurcation mode of the device under test.

[0016] A computer program product includes a computer program which, when executed by a processor, implements a protocol verification method as described in any one of the above.

[0017] 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.

[0018] The protocol verification method, device, computer program product, and machine-readable storage medium provided by this application receive or send data between two devices under test by using two verification IPs, and at the same time configure different port modes inside the two devices under test to achieve the effect of multi-port functions, enabling a complete data path to be established between the two verification IPs, respectively verifying the receiving and sending functions of the two devices under test. By simply modifying the port mode configured in the verification environment and the forking mode of the device under test, a verification environment for different scenarios can be flexibly built, and the application scenarios of different numbers of devices can be quickly switched. Verifying by using verification IP has the ability of automatic data verification and reply, which can reduce the workload of verification engineers in building the environment to a considerable extent. The result of the verification comparison is only whether the sent data and the received data are consistent. Further, from the perspective of bus transactions (BT), the details of data reception and transmission are verified, the data flow of different application scenarios at the system level is simulated to verify the functions of the device under test in different application scenarios such as forking mode, Peripheral Component Interconnect Express (PCIe) protocol ports, and Serial ATA (SATA) protocol ports. The processing ability of the device under test for various bus transactions is verified from the perspective of system cooperation, and at the same time, verification can be performed for different configured ports, different link widths, and different link speeds, greatly saving verification time and accelerating the project progress.

[0019] To make the above features and advantages of the application more obvious and understandable, specific embodiments are given below and will be described in detail in conjunction with the accompanying drawings as follows. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 It is a flowchart of a protocol verification method provided by this application.

[0021] Figure 2 It is a block diagram of a protocol verification device provided by this application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0022] To make the objectives and technical solutions of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below in conjunction with the drawings of the embodiments of this application. Obviously, the described embodiments are some but not all of the embodiments of this application. All other embodiments obtained by those of ordinary skill in the art based on the described embodiments of this application without creative efforts shall fall within the scope of protection of this application.

[0023] Please refer to Figure 1 , Figure 1 It is a flowchart of a protocol verification method provided by this application. This application provides a protocol verification method, including: steps S1 to S5.

[0024] Step S1: Configure the port mode to be selected for the verification environment. Divide the verification environment into different sub-environments according to the port mode, and instantiate the verification components in the sub-environments. Step S2: Configure the forking mode of the device under test. Implement the routing logic of the device under test according to the forking mode. Step S3: Instantiate two groups of devices under test to dock at the application layer interface. Send and receive data between the two groups of devices under test through the verification IP. The two groups of devices under test share the forking mode and select the data forwarding mode supported by the data. Step S4: Set the output data of the application layer of the input device under test to be converted into the format required by the application layer of the output device under test and output in sequence. Step S5: The two devices under test respectively send transaction layer packets (TLP), and compare the data of the transaction layer packets of the device under test in the receiving direction with the simulated transaction layer packets of the device under test in the sending direction.

[0025] In step S1, please refer to Figure 1 step S1 in, configure the port mode to be selected for the verification environment. Divide the verification environment into different sub-environments according to the port mode, and instantiate the verification components in the sub-environments.

[0026] As an example, define the parameter port_type to represent the port mode. The port mode port_type includes the Universal Serial Bus (USB) port mode up_mode, the network port mode Fport_mode, and the Compute Express Link (CXL) port mode cxl_mode.

[0027] Specifically, in the Universal Serial Bus (USB) port mode up_mode, define the device under test controllor 0 as the upstream port (UP), and the device under test controllor 1 as the downstream port (DP); in the network port mode Fport_mode, define both the device under test controllor 0 and the device under test controllor 1 as downstream ports; in the Compute Express Link (CXL) port mode cxl_mode, the device under test controllor0 and the device under test controllor 1 are used to verify the port scenarios that support the CXL protocol. Among them, both the device under test controllor 0 and the device under test controllor 1 can be used as the input device under test and the output device under test to receive and send data.

[0028] As an example, the verification components include: a connector, a driver, a monitor, and a checker.

[0029] Further, the verification component further includes: a simulator (rm), a transmitter (TX), and a receiver (RX).

[0030] Specifically, the transmitter and the receiver use verification IP to implement data transmission and reception.

[0031] In step S2, refer to Figure 1 step S2 in, configure the bifurcation mode of the device under test, and implement the routing logic of the device under test according to the bifurcation mode.

[0032] As an example, define a parameter sys_mode in the configuration file, and the parameter sys_mode is used to control the bifurcation mode of the device under test. In the bifurcation mode, instantiate 1 to 4 groups of port environment variables port_env. The port environment variable port_env includes: parameter X16_PCle_controllor, parameter X8_PCle_controllor, and parameter X4_PCle_controllor, which are used to represent how many links the port is divided into; Specifically, 1 group of port environment variables port_env can be instantiated, and the parameter X16_PCle_controllor is used to represent that the port is divided into 1 group of 16 links; 2 groups of port environment variables port_env can also be instantiated, and the parameter X8_PCle_controllor is used to represent that the port is divided into 2 groups of 8 links; 4 groups of port environment variables port_env can also be instantiated, and the parameter X4_PCle_controllor is used to represent that the port is divided into 4 groups of 4 links.

[0033] In each group of port environment variables port_env, the mode of the verification IP is controlled according to the port mode port_type.

[0034] Specifically, the application scenarios of 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, and the verification IP0 in the root complex (RC) mode is used for the upstream port, and the verification IP1 in the endpoint (EP) mode is used for the downstream port; in the network port mode Fport_mode, the verification IP selects the host scenario or the network port scenario, and the verification IP0 and verification IP1 are randomly configured; in the high-speed link bus protocol port mode cxl_mode, the verification IP selects the host scenario or the high-speed link bus protocol scenario, and the verification IP is configured as the CXL_VIP mode.

[0035] As an example, the routing logic is implemented by the connector in the forking mode. A total of 8 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 kept consistent with the width of the device under test. According to the parameter sys_mode, the interface pcie_vip_if is correspondingly configured as the forking mode of the device under test, and the device under test passes parameters to the instantiated verification IP through the appropriate pcie_vip_if.

[0036] In a specific embodiment of the present application, a group of port environment variables port_env is instantiated for the forking mode of the device under test, including: the parameter X16_PCle_controllor, which divides the device under test into 16 links. Correspondingly, the interface pcie_vip_if is configured with the parameter X16_PCle_controllor, and 16 links are passed as parameters to a verification IP through a group of interfaces pcie_vip_if.

[0037] As an example, the connector controls the connection mode of the differential lines connected to the device under test through polarity inversion, channel position (Lane) inversion, and skew parameter control.

[0038] In step S3, please refer to Figure 1 Step S3 in, instantiate two groups of devices under test for interface docking at the application layer. Data is sent and received between the two groups of devices under test through the verification IP. The two groups of devices under test share the forking mode and select the data forwarding mode supported by the data.

[0039] As an example, the port mode port_type of the verification environment is selected according to the port mode port_type of the two instantiated groups of devices under test, and the verification environment is divided into different sub-environments.

[0040] Furthermore, the target bandwidth target_width of the two groups of devices under test is configured to be always consistent. For example, the target bandwidth target_width is configured as x4 for both groups. The two groups of devices under test use 4 links for data transmission, and the data can be transmitted at the corresponding bandwidth and rate. The ingress device under test sends data at a stable rate, and the egress device under test also receives data at the same rate, without the situation that the ingress device under test sends data too fast and the egress device under test cannot process it in time, resulting in data backlog, thus avoiding the disconnection problem.

[0041] Further, configure the device under test to support the store_forward mode, cutthrough mode, and bypass mode. During data forwarding, even if the target bandwidth target_width of the two devices under test remains the same, the instantaneous bandwidth may not match due to protocol overhead, routing decisions, or buffer queuing during data transmission. Therefore, the cutthrough mode is preferred. When the bandwidth of the egress device under test is less than that of the ingress device under test, the cutthrough mode ensures that the ingress device under test will not experience a data stream interruption, ensuring the efficiency and stability of the data path in various situations, rather than relying solely on static bandwidth matching.

[0042] In step S4, refer to Figure 1 step S4 in, and set the output data of the application layer of the ingress device under test to be converted into the format required by the application layer of the egress device under test and output in sequence.

[0043] As an example, the output data of the application layer of the ingress device under test may be parallel, byte-organized data, while the egress device under test requires a transaction layer packet that conforms to the Peripheral Component Interconnect Express and High-Speed Serial Link protocols. Set the output data of the application layer of the ingress device under test to be re-encoded into a transaction layer packet format according to the Peripheral Component Interconnect Express and High-Speed Serial Link protocol specifications.

[0044] Further, set up two levels of first-in-first-out buffers (FIFOs) to control the credit management inside the device under test and enable normal data flow between the two devices under test. Due to differences in delays of different paths or parallel processing resulting in different completion times, data may be out of order during data forwarding. Set the first-level first-in-first-out buffer to cache the original signals received from the application layer of the ingress device under test to prevent data loss caused by speed fluctuations of the ingress device under test; the second-level first-in-first-out buffer caches the data that has been converted into the transaction layer packet format to ensure that the data sent to the egress device under test is arranged in the original order.

[0045] Specifically, each level of the first-in-first-out buffer includes: the cache parameter Ctrl0_P_fifoDepth ctrl for non-return messages, the cache parameter Ctrl0_NP_fifo Depth ctrl for messages that need to be returned, the cache parameter Ctrl0_CPL_fifo Depth ctrl for completed messages, and the cache parameter Ctrl0_order_fifo Depth ctrl for message sorting.

[0046] In step S5, refer to Figure 1 step S5 in, and the two devices under test respectively send transaction layer packets through the verification component, and compare the transaction layer packets of the receiving device under test with the simulated transaction layer packets of the sending device under test.

[0047] In an embodiment of the present application, two DUTs adopt the standard high-speed peripheral component interconnect express (PCIe) port mode up_mode, where DUT controllor 0 is an upstream port and DUT controllor 1 is a downstream port.

[0048] As an example, in the verification environment, the parameter VIP0_as_RC_TX is defined to represent the enable VIP signal for sending data to the upstream port, the parameter VIP0_as_RC_RX is defined to represent the enable VIP signal for receiving data output from the upstream port, the parameter VIP1_as_EP_TX is defined to represent the enable VIP signal for sending data to the downstream port, the parameter VIP1_as_EP_RX is defined to represent the enable VIP signal for receiving data output from the downstream port, the parameter cp_host_monitor is defined to represent collecting the transaction layer packets output from the upstream port, the parameter cp_ep_monitor is defined to represent collecting the transaction layer packets output from the downstream port, the parameter cp_host_model is defined to represent the stimulus signal generated for the upstream port, the parameter cp_ep_model is defined to represent the stimulus signal generated for the downstream port, the parameter cp_downstream_rm is defined to represent simulating the transaction layer packets in the sending direction of the upstream port, the parameter cp_upstream_rm is defined to represent simulating the transaction layer packets in the sending direction of the downstream port, the parameter cp_upstream_checker is defined to represent the comparison result between the data output from the upstream port and the data output from the simulated downstream port, and the parameter cp_downstream_checker is defined to represent the comparison result between the data output from the downstream port and the data output from the simulated upstream port.

[0049] As an example, after configuring the verification environment, the transaction layer packets to be sent are sent using the parameters VIP0_as_RC_TX, VIP0_as_RC_RX, VIP1_as_RC_TX, and VIP1_as_RC_RX, and the data of the transaction layer packets of the DUT in the receiving direction and the simulated DUT transaction layer packets in the sending direction are compared to complete the data reception and transmission verification of the two DUTs.

[0050] The protocol verification method provided by the present application receives or sends data between two DUTs through two verification IPs, and at the same time configures different port modes inside the two DUTs to achieve the effect of multi-port functions, enabling a complete data path to be established between the two verification IPs, respectively verifying the reception and transmission functions of the two DUTs, and only by modifying the configured port mode port_type and parameter sys_mode, a verification environment for different scenarios can be flexibly built.

[0051] The present application further provides a protocol verification device for executing the above-mentioned protocol verification method. Please refer to Figure 2 , Figure 2 FIG. is a block diagram of a protocol verification device provided by the present 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.

[0052] As an example, the first end of the verification module 1 is connected to the first end of the first device under test 2, the second end of the verification module 1 is connected to the second end of the first device under test 2, the third end of the verification module 1 is connected to the first end of the second device under test 3, and the fourth end of the verification module 1 is connected to the second end of the second device under test 3; the third end of the first device under test 2 is connected to the first end of the credit management and data conversion module 4, and the third end of the second device under test 3 is connected to the second end of the credit management and data conversion module 4.

[0053] 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 sequentially connected to the first ends of the first driver 12, the first simulator 13, the first checker 14, the first collector 15, and the first receiver 16, the second end of the first transmitter 11 is connected to the first end of the first connector 113, and the second end of the first receiver 16 is connected to the first end of the second connector 114; the first end of the second transmitter 17 is sequentially connected to the first ends of the second driver 18, the second simulator 19, the second checker 110, the second collector 111, and the second receiver 112, 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.

[0054] 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.

[0055] In an embodiment of the present application, the configuration verification module configures the port mode port_type to be selected and the bifurcation mode parameter sys_mode of the device under test. The first device under test 2 and the second device under test 3 adopt the port mode up_mode of the standard high-speed peripheral interconnect extended bus protocol. According to the port modes of the first device under test 2 and the second device under test 3, the verification module 1 is divided into the port mode up_mode of the standard high-speed peripheral interconnect extended bus protocol, and verification components are configured in the verification module 1; the first device under test 2 is used as the upstream port, and the second device under test 3 is used as the downstream port; the first device under test 2 and the second device under test 3 receive the configuration parameter sys_mode of the verification module 1 to control the bifurcation mode of the device under test.

[0056] As an example, the first transmitter 11 and the second transmitter 17 are respectively connected to the first device under test 2 and the second device under test 3 through the first connector 113 and the second connector via differential lines for transmitting transaction layer data packets; wherein, the first transmitter 11 generates the parameter verification IP0_as_RC_TX, and the second transmitter 17 generates the parameter verification IP1_as_RC_TX. The first receiver 16 and the second receiver 112 are respectively connected to the differential lines of the first device under test 2 and the second device under test 3 for receiving transaction layer data packets; wherein, the first receiver 16 generates the parameter cp_host_monitor, and the second receiver 112 generates the parameter cp_ep_monitor.

[0057] As an example, the first driver 12 and the second driver 18 are respectively connected to the differential lines of the first device under test 2 and the second device under test 3. The first driver 12 and the second driver 18 internally integrate verification IP of the CXL_VIP type for randomly sending request messages P of the non-return type and request messages NP of the return-required type to generate incentives for the simulator and the transmitter; wherein, the first driver 12 generates the parameter cp_host_model, and the second driver 18 generates the parameter cp_ep_model.

[0058] As an example, the first simulator 13 and the second simulator 19 are respectively used to simulate the behaviors of the first device under test 2 and the second device under test 3 and output simulated device under test 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.

[0059] As an example, the first collector 15 and the second collector 111 are used to collect the 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.

[0060] As an example, the first checker 14 and the second checker 110 are used to compare the data of the device under test (DUT) transaction layer data packet in the receiving direction and the simulated DUT transaction layer data packet in the transmitting direction. The transaction layer data packets are compared according to the pre-divided ID and address space to complete the data reception and transmission verification of the first DUT 2 and the second DUT 3. Among them, the first checker 14 generates the parameter cp_downstream_checker, and the second checker 110 generates the parameter cp_upstream_checker.

[0061] As an example, the first connector 113 and the second connector 114 are used to implement the 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 inversion, channel position inversion and tilt parameter control.

[0062] As an example, the data converter 41 is used to re-encode the output data of the incoming DUT application layer into the data in the format of the transaction layer data packet according to the Peripheral Component Interconnect Express (PCIe) protocol and the High-Speed Serial Link (HSSI) protocol specification, and convert it into the format required by the outgoing DUT application layer.

[0063] As an example, the credit manager 42 is used to implement credit management between the first DUT 2 and the second DUT 3, and make the data sent from the incoming DUT to the outgoing DUT arranged in the original order by setting two-level first-in first-out (FIFO) buffers. Among them, the parameters generated by the credit manager 42 include: the buffer parameter Ctrl0_P_fifo Depthctrl for non-return messages, the buffer parameter Ctrl0_NP_fifo Depth ctrl for messages that need to be returned, the buffer parameter Ctrl0_CPL_fifo Depth ctrl for completed messages, and the buffer parameter Ctrl0_order_fifo Depth ctrl for message sorting.

[0064] 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 two devices under test. The output data of the application layer of the input device under test is converted into the format required by the application layer of the output device under test and then in sequence, so that normal data flow can be achieved between the two devices under test. By using two verification IPs to receive or send data between the two devices under test, and at the same time configuring different port modes inside the two devices under test to achieve the effect of multi-port functions, a complete data path is realized between the two verification IPs, and the receiving and sending functions of the two devices under test are respectively verified. Only by modifying the port mode port_type of the verification environment configuration and the fork mode of the device under test can a verification environment for different scenarios be flexibly built, and the application scenarios of different numbers of devices can be quickly switched. Using the verification IP for verification has the ability of automatic data verification and reply, which can reduce the workload of verification engineers in setting up the environment to a considerable extent. The result of its verification comparison is only whether the sent data and the received data are consistent. Further, from the perspective of bus transactions, the details of data reception and transmission are verified, and the data flow of different application scenarios at the system level is simulated to verify the functions of the device under test in different application scenarios such as the fork mode, the Peripheral Component Interconnect Express (PCIe) protocol port, and the Serial ATA (SATA) protocol port. From the perspective of system cooperation, the processing ability of the device under test for various bus transactions is verified, and it can also verify different configurations of ports, different link widths, and different link speeds at the same time, greatly saving verification time and accelerating the project progress.

[0065] This application also provides a computer program product, including a computer program, which when executed by a processor, implements a protocol verification method as described above.

[0066] This application also provides a machine-readable storage medium, storing a computer program, which when executed by a processor, implements a protocol verification method as described above.

[0067] Although this application has been disclosed as above with embodiments, it is not intended to limit this application. Any person with ordinary knowledge in the technical field to which this application pertains, without departing from the spirit and scope of this application, may make some modifications and refinements. Therefore, the protection scope of this application shall be subject to that defined by the appended patent application scope.

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 according to the port mode, and instantiate verification components in the sub-environments Configure the forking mode of the device under test, and implement the routing logic of the device under test according to the forking mode Instantiate two sets of devices under test for docking at the application layer interface. Data is sent and received between the two sets of devices under test through verification IP. The two sets of devices under test share the forking mode and select the data forwarding mode supported by the data Set the output data of the application layer of the input device under test to be converted into the format required by the application layer of the output device under test and output in sequence The two sets of devices under test respectively send transaction layer data packets, and compare the data of the transaction layer data packets of the device under test in the receiving direction and the simulated transaction layer data packets of the device under test in the sending direction 2. The protocol verification method according to claim 1, wherein Implementing the routing logic according to the forking mode includes Instantiating 1 to 4 sets of port environment variables in the forking mode Each set of port environment variables controls the verification IP mode according to the port mode Instantiate an interface between the connector and the verification IP, configure the interface to the forking mode of the device under test according to the forking mode, and transmit parameters through the interface 3. The protocol verification method according to claim 2, characterized in that, The connector controls the connection mode of the differential line connected to the device under test through polarity inversion, channel position inversion 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 sets of devices under test to be the same Configure the device under test to support the store-and-forward mode, cut-through mode and bypass mode 5. The protocol verification method according to claim 1, wherein, Set the output data of the application layer of the input device under test to be converted into the format required by the application layer of the output device under test, including: setting the output data of the application layer of the input device under test to be re-encoded into the data packet format of the transaction layer according to the Peripheral Component Interconnect Express and High-Speed Serial Link protocol specifications 6. The protocol verification method according to claim 5, wherein Set the output data of the application layer of the input device under test to be converted into the format required by the application layer of the output device under test and output in sequence, including: setting two levels of first-in-first-out buffers to control the credit management inside the device under test. The first-level first-in-first-out buffer caches the original signals received from the application layer of the input device under test, and the second-level first-in-first-out buffer caches the data that has been converted into the transaction layer data packet format. The data output to the output device under test is arranged in the original order; each level of first-in-first-out buffer includes: no-return message cache parameters, return-required message cache parameters, completion message cache parameters and message sorting cache parameters 7. A protocol verification device for performing the protocol verification method according to any one of claims 1 to 6, characterized in that, Include Verification module, first device under test, second device under test, credit management and data conversion module; the first end of the verification module is connected to the first end of the first device under test, the second end of the verification module is connected to the second end of the first device under test, the third end of the verification module is connected to the first end of the second device under test, and the fourth end of the verification module is connected to the second end of the second device under test; the third end of the first device under test is connected to the first end of the credit management and data conversion module, and the third end of the second device under test 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: first transmitter, first driver, first simulator, first checker, first collector, first receiver, second transmitter, second driver, second simulator, second checker, second collector, second receiver, first connector and second connector The first end of the first transmitter is sequentially connected to the first ends of the first driver, the first simulator, the first checker, the first collector, and the first receiver. The second end of the first transmitter is connected to the first end of the first connector. 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 sequentially connected to the first ends of the second driver, the second simulator, the second checker, the second collector, and the second receiver. The second end of the second transmitter is connected to the second end of the second connector. 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. The third end of the second driver is the fourth end of the verification module.

9. The protocol verification device according to claim 7, characterized in that 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. 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, characterized in that, 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.

11. The protocol verification device according to claim 7, characterized in that The first device under test and the second device under test receive the configuration parameters of the verification module to control the bifurcation mode of the device under test.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements a protocol verification method according to any one of claims 1-6.

13. A machine-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements a protocol verification method according to any one of claims 1-6.

Images