A verification platform, a verification method, an electronic device and a medium

Abstract

The application relates to the technical field of integrated circuits and provides a verification platform, a verification method, electronic equipment and a medium. The verification platform comprises: an application layer bus function level model, which comprises a customized interface for a design under test for interaction with the design under test, wherein the design under test is a PCIe protocol interface and protocol compliance test suite, the PCIe protocol interface and protocol compliance test suite supports verification requirements of a physical layer intellectual property core and supports verification requirements of PCIe controller plus physical layer subsystem level protocol consistency; and the design under test interacts with the application layer bus function level model through the customized interface. In this way, the integration and through-flow debugging cost of subsystem protocol consistency verification is reduced, the verification period of PCIe subsystem protocol standardization interface testing is shortened, and the completeness of PCIe subsystem full-quantization protocol interface verification and the platform reuse efficiency are improved.

Description

Technical Field

[0001] This application relates to the field of integrated circuit technology, and in particular to a verification platform, verification method, electronic device and medium. Background Technology

[0002] With the evolution of the PCIe (PCI Express) protocol, the modulation and encoding methods of transmission signals have changed, for example, adopting 4-Level Pulse Amplitude Modulation (PAM4). The signal transmission rate has also increased rapidly. Therefore, the evolution of the PCIe protocol version and the increase in high-speed transmission rates have brought challenges to the development of PCIe physical layer intellectual property cores (IPs), especially in achieving subsystem-level functional verification completeness and standardized protocol conformance verification at the physical layer. Furthermore, the PCIe protocol specifies two device modes: Root Complex (RC) mode and End-Point (EP) mode. These two different device modes may lead to different verification requirements. This necessitates that the verification platform can simultaneously support two different control flow paths and data flow paths, and may need to provide different protocol processing and data conversion procedures, thus increasing the complexity and duration of the verification scheme. In the prior art, Chinese patent application CN120144514A discloses that two basic test units, consisting of a first protocol comparator and a second protocol comparator, can perform fork characteristic verification relatively independently. The test unit, composed of the first protocol comparator, a first EP verification proxy component, a first PHY verification proxy component, and a first RC verification proxy component, can verify the fork characteristic of the uplink port; while the test unit, composed of the second protocol comparator, a second EP verification proxy component, a second PHY verification proxy component, and a second RC verification proxy component, can simultaneously verify the fork characteristic of the downlink port. Chinese patent application CN105975427A discloses an interface card that bidirectionally converts between PCIe and SAS interfaces, implementing a PCIe dual-mode system based on a SAS interface. Chinese patent application CN114328329A discloses that one side of a PCIe interface module can be a PCIe physical interface, through which it can be connected to another PCIe device. However, existing technical solutions cannot simultaneously meet the testing requirements of both device modes in the PCIe protocol specification, as well as the testing requirements of different control flow paths and data flow paths.

[0003] To address these technical challenges, this application provides a verification platform, verification method, electronic device, and medium. Summary of the Invention

[0004] Firstly, this application provides a verification platform. The verification platform includes: an application layer bus functional level model, including customized interfaces for the design under test (DUT) to interact with the DUT, wherein the DUT is a PCIe protocol interface and compliance test suite, the PCIe protocol interface and compliance test suite supporting verification requirements for physical layer intellectual property cores and supporting verification requirements for protocol conformance at the PCIe controller plus physical layer subsystem level; and

[0005] The design under test interacts with the application layer bus functional level model through the customized interface. The application layer bus functional level model has application layer and transaction layer protocol and data type conversion functions, multi-type interface driving functions, multi-type interface sampling functions, and transaction layer handle processing functions, thereby supporting inbound direction verification of the PCIe protocol interface and protocol compliance test suite in root device mode and outbound direction verification of the PCIe protocol interface and protocol compliance test suite in endpoint device mode.

[0006] The first aspect of this application provides a dual-mode verification component and stimulus sequence that is easy for users to extend hierarchically and supports both root device mode and endpoint device mode. It has the advantages of diversified device modes and high configuration flexibility, supports flexible configuration of dual device modes and control interface, and also supports subsystem protocol docking verification at the subsystem level. It can be used to build rich stimulus modes and test vector sets, and supports the verification of protocol consistency at the PCIe controller and physical layer subsystem level with higher integration efficiency and lower learning cost. It can effectively reduce the integration and debugging cost of subsystem protocol consistency verification, shorten the verification cycle of PCIe subsystem protocol standardization docking test, and improve the completeness of PCIe subsystem full-scale protocol docking verification and platform reuse efficiency.

[0007] In one possible implementation of the first aspect of this application, the inbound direction verification defines a first data flow path and a control flow path from the PCIe root device to the PCIe controller and physical layer subsystem and then to the serial port PCIe verification component, and the outbound direction verification defines a second data flow path and a control flow path from the serial port PCIe verification component to the PCIe controller and physical layer subsystem and then to the PCIe endpoint device.

[0008] In one possible implementation of the first aspect of this application, the application layer bus functional level model provides application layer and transaction layer protocol and data type conversion functions during the inbound direction verification for converting transactions from Advanced Extensible Bus Protocol to PCIe transaction layer packets, and provides application layer and transaction layer protocol and data type conversion functions during the outbound direction verification for converting transactions from PCIe transaction layer packets to Advanced Extensible Bus Protocol, thereby supporting bidirectional data flow paths and control flow paths composed of the first data flow path and control flow path and the second data flow path and control flow path.

[0009] In one possible implementation of the first aspect of this application, the verification platform further includes a first PCIe verification component. Both the application layer bus functional level model and the design under test can be communicatively connected to the first PCIe verification component. The first PCIe verification component is configured to switch between a root device verification mode and an endpoint device verification mode. When the application layer bus functional level model performs inbound verification of the PCIe protocol interfacing and protocol compliance test suite in the root device mode, the first PCIe verification component is switched to the root device verification mode. And when the application layer bus functional level model performs outbound verification of the PCIe protocol interfacing and protocol compliance test suite in the endpoint device mode, the first PCIe verification component is switched to the endpoint device verification mode.

[0010] In one possible implementation of the first aspect of this application, the first PCIe verification component includes a transaction layer interface and a serial port interface. The application layer bus functional level model can be communicatively connected to the first PCIe verification component through the transaction layer interface of the first PCIe verification component, and the design under test can be communicatively connected to the first PCIe verification component through the serial port interface of the first PCIe verification component.

[0011] In one possible implementation of the first aspect of this application, the verification platform further includes a second PCIe verification component and a third PCIe verification component. The application layer bus functional level model is communicatively connected to the second PCIe verification component, and the design under test is communicatively connected to the third PCIe verification component. The second PCIe verification component is used to send and receive transaction layer packets and to perform root device verification in cooperation with the application layer bus functional level model and the design under test. The third PCIe verification component is used to send and receive serial port data and to perform endpoint device verification in cooperation with the application layer bus functional level model and the design under test.

[0012] In one possible implementation of the first aspect of this application, the customized interface includes an advanced easily expandable bus protocol interface, a data bus interface, and a power management interface.

[0013] In one possible implementation of the first aspect of this application, the application layer bus functional level model further includes a register abstraction layer model for a configuration interface to support register read and write operations.

[0014] In one possible implementation of the first aspect of this application, the application layer bus functional level model further includes an advanced scalable bus protocol proxy handle for handling advanced scalable bus protocol transmission transactions, a register abstraction layer model handle for configuring register read and write operations, and a design-under-test (DUT) state global handle for maintaining the hierarchical global state information of the DUT, wherein the hierarchical global state information of the DUT includes the data link layer connection establishment state, the physical layer connection establishment state, and the state of the link training state machine.

[0015] In one possible implementation of the first aspect of this application, the application layer bus functional level model supports user-customizable stimulus signal patterns and test vector types by instantiating the state object of the design under test and by globalizing the advanced extensible bus protocol proxy handle and the global handle of the state of the design under test.

[0016] Secondly, this application provides a verification method. The verification method includes: determining whether the interfacing test requirement of the design under test (DUT) is a root device mode corresponding to the application layer bus functional level model or an endpoint device mode corresponding to the application layer bus functional level model, wherein the application layer bus functional level model includes a customized interface for the DUT to interact with the DUT, the DUT is a PCIe protocol interfacing and protocol compliance test suite, the PCIe protocol interfacing and protocol compliance test suite supports verification requirements for physical layer intellectual property cores and verification requirements for protocol consistency at the PCIe controller plus physical layer subsystem level, and the DUT interacts with the application layer bus functional level model through the customized interface; when the interfacing test requirement of the DUT is a root device mode corresponding to the application layer bus functional level model... In the root device mode of the model, the application layer bus functional level model is used to perform inbound direction verification of the PCIe protocol interface and protocol compliance test suite by utilizing the application layer and transaction layer protocol and data type conversion functions, multi-type interface driver functions, multi-type interface sampling functions, and transaction layer handle processing functions of the application layer bus functional level model. When the interface test requirement of the design under test corresponds to the endpoint device mode of the application layer bus functional level model, the application layer and transaction layer protocol and data type conversion functions, multi-type interface driver functions, multi-type interface sampling functions, and transaction layer handle processing functions of the application layer bus functional level model are used to perform outbound direction verification of the PCIe protocol interface and protocol compliance test suite by utilizing the endpoint device mode.

[0017] The second aspect of this application provides a dual-mode verification component and stimulus sequence that is easy for users to extend hierarchically and supports both root device mode and endpoint device mode. It has the advantages of diversified device modes and high configuration flexibility, supports flexible configuration of dual device modes and control interface, and also supports subsystem protocol docking verification at the subsystem level. It can be used to build rich stimulus modes and test vector sets, and supports the verification of protocol consistency at the PCIe controller and physical layer subsystem level with higher integration efficiency and lower learning cost. It can effectively reduce the integration and debugging cost of subsystem protocol consistency verification, shorten the verification cycle of PCIe subsystem protocol standardization docking test, and improve the completeness of PCIe subsystem full-scale protocol docking verification and platform reuse efficiency.

[0018] In one possible implementation of the second aspect of this application, the inbound direction verification defines a first data flow path and a control flow path from the PCIe root device to the PCIe controller and physical layer subsystem and then to the serial port PCIe verification component, and the outbound direction verification defines a second data flow path and a control flow path from the serial port PCIe verification component to the PCIe controller and physical layer subsystem and then to the PCIe endpoint device.

[0019] In one possible implementation of the second aspect of this application, the application layer bus functional level model provides application layer and transaction layer protocol and data type conversion functions during the inbound direction verification for the conversion of transactions transmitted from the Advanced Extensible Bus Protocol to PCIe transaction layer packets, and provides application layer and transaction layer protocol and data type conversion functions during the outbound direction verification for the conversion of transactions transmitted from PCIe transaction layer packets to the Advanced Extensible Bus Protocol, thereby supporting bidirectional data flow paths and control flow paths composed of the first data flow path and control flow path and the second data flow path and control flow path.

[0020] Thirdly, embodiments of this application also provide a computer device, the computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a method according to any of the above-mentioned implementations.

[0021] Fourthly, embodiments of this application also provide a computer-readable storage medium storing computer instructions that, when executed on a computer device, cause the computer device to perform a method according to any of the above-described implementations.

[0022] Fifthly, embodiments of this application also provide a computer program product, the computer program product including instructions stored on a computer-readable storage medium, which, when executed on a computer device, cause the computer device to perform a method according to any of the above-described aspects. Attached Figure Description

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

[0024] Figure 1 A schematic diagram of a verification platform for a first embodiment provided in this application;

[0025] Figure 2 A schematic diagram of a verification platform for a second embodiment provided in this application;

[0026] Figure 3 A schematic diagram of a verification platform for a third embodiment provided in this application;

[0027] Figure 4 A flowchart illustrating a verification method provided in an embodiment of this application;

[0028] Figure 5 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0029] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0030] It should be understood that in the description of this application, "at least one" means one or more, and "multiple" means two or more. In addition, the words "first," "second," etc., unless otherwise stated, are used only for the purpose of distinguishing descriptions and should not be construed as indicating or implying relative importance or order.

[0031] Figure 1 A schematic diagram of a verification platform for a first embodiment provided in this application. Figure 1 The verification platform shown, as well as the verification platform and verification methods mentioned in other figures and embodiments of this application, are applicable to high-speed serial peripheral interconnect bus (PCI Express, PCIe) bus protocols, such as PCI Express Generation 5 (PCIe5) and PCI Express Generation 6 (PCIe6). They can be used for PCIe physical layer intellectual property cores (IPs) under the PCIe protocol specification, such as verifying the completeness of functions and conformity with standardized protocols at the subsystem level of the PCIe physical layer. Figure 1As shown, the verification platform includes: an Application Bus Function Model (Application BFM) A120, including a specific interface A130 for interacting with the design under test (A110), wherein the design under test A110 is a PCIe Test Suite, which supports the verification requirements of the physical layer intellectual property core and the verification requirements of protocol conformance at the PCIe controller plus physical layer subsystem level; and the design under test A110 interacts with the Application Bus Function Model A120 through the specific interface A130. The application layer bus functional level model A120 has application layer and transaction layer protocol and data type conversion functions, multi-type interface driving functions, multi-type interface sampling functions, and transaction layer handle processing functions, thereby supporting inbound direction verification of the PCIe protocol interface and protocol compliance test suite in root device mode and outbound direction verification of the PCIe protocol interface and protocol compliance test suite in endpoint device mode.

[0032] See Figure 1 The PCIe protocol specifies two device modes: Root Complex (RC) mode and End-Point (EP) mode. These two different device modes may lead to different verification requirements. This necessitates that the verification platform simultaneously support two different control flow paths and data flow paths, and may also require different protocol processing and data conversion procedures, thus increasing the complexity and duration of the verification scheme. For example, RC mode is generally used to connect to the central processing unit, memory subsystem, or input / output devices, while EP mode is generally used for read and write operations in local memory space. Depending on the specific topology and application scenario requirements, a PCIe device can be configured with a master mode corresponding to RC mode and a slave mode corresponding to EP mode. To simultaneously meet the testing requirements of both device modes specified in the PCIe protocol and support different control flow paths and data flow paths, Figure 1The verification platform presented offers the following improvements and beneficial technical effects: 1. It provides a PCIe protocol interface and protocol compliance test suite, which can simultaneously support the verification requirements of the physical layer intellectual property core and the verification requirements of protocol consistency at the PCIe controller and physical layer subsystem levels. Furthermore, it supports multi-device modes including RC and EP modes, and also supports the Register Abstraction Layer (RAL) model. 2. It proposes a testbench, a set of verification components for application layer bus functional level models with interface universality and consistency for bridging and conversion. 3. To support dual-device mode (RC and EP modes), and to simultaneously handle two different data flow paths and control flow paths, the following two different data flow paths and control flow paths are defined: One is in-bound direction (IB) verification of the PCIe protocol interface and compliance test suite in root device mode, i.e., from the PCIe RC device to the PCIe controller plus physical layer subsystem and then to the serial port (Serdes Side) PCIe verification component (PCIeVerification IP, PCIe VIP). The other is out-bound direction (OB) verification of the PCIe protocol interface and compliance test suite in endpoint device mode, i.e., from the serial port PCIe verification component to the PCIe controller plus physical layer subsystem and then to the PCIe EP device. 4. Furthermore, to handle bidirectional data flow paths and control flow paths, a conversion process between protocols and data types is proposed, and a global handle is provided to uniformly maintain the data link layer and physical layer.

[0033] Continue reading Figure 1Utilizing the Application Layer Bus Functional Level Model A120 and its included customized interface A130, the Design Under Test (DUT) A110 shares the customized interface A130 for both inbound and outbound verification, and regardless of root device mode or endpoint device mode. It also implements protocol and data type conversion processes through the Application Layer Bus Functional Level Model A120, and maintains the data link layer and physical layer uniformly through global handles. Therefore, the Application Layer Bus Functional Level Model A120 provides bridging and conversion functions with interface universality and consistency, and supports driving or sampling different types of application layer interfaces, as well as transaction-level handle processing. This allows it to meet the bus conversion and adaptation needs of different types of Advanced Extended Interface (AXI) or native basic interfaces. Furthermore, because the same test architecture is used, supporting the verification requirements of PCIe protocol interfacing and protocol compliance test suites according to two different data flow paths and control flow paths, the switching between RC mode and EP mode can be achieved by configuring the application layer bus functional level model A120. This avoids the hardware overhead caused by additional protocol comparators and verification agent components, which is beneficial for controlling chip area and improving chip integration. In addition, the application layer bus functional level model A120 provides application layer and transaction layer protocol and data type conversion functions, multi-type interface driver functions, multi-type interface sampling functions, and transaction layer handle processing functions. It can support rich interface functions such as AXI interface, power management (PM) interface, and data bus interface (DBI) on the customized interface A130. It can also support flexible configuration based on the register abstraction layer model in the control plane (e.g., providing various addressing modes for register read and write operations), and support finite state machine state traversal and link training and status state machine (LTSSM) enumeration, which helps to provide rich stimulus sequence patterns and rich test vector test cases. In addition, it not only supports IP verification requirements at the physical layer level, but also supports protocol consistency verification requirements at the PCIe controller and physical layer subsystem levels.

[0034] In short, Figure 1The verification platform shown provides dual-mode verification components and stimulus sequences that are easy for users to extend hierarchically and support both root device mode and endpoint device mode. It has the advantages of diversified device modes and high configuration flexibility, supports flexible configuration of dual device modes and control interface, and also supports subsystem-level subsystem protocol interface verification. It can be used to build rich stimulus modes and test vector sets, and supports the verification of protocol consistency at the PCIe controller and physical layer subsystem level with higher integration efficiency and lower learning cost. It can effectively reduce the integration and debugging costs of subsystem protocol consistency verification, shorten the verification cycle of PCIe subsystem protocol standardization interface testing, and improve the completeness of PCIe subsystem full-scale protocol interface verification and platform reuse efficiency.

[0035] See Figure 1 In one possible implementation, the inbound direction verification defines a first data flow path and a control flow path from the PCIe root device to the PCIe controller and physical layer subsystem, and then to the serial port PCIe verification component. The outbound direction verification defines a second data flow path and a control flow path from the serial port PCIe verification component to the PCIe controller and physical layer subsystem, and then to the PCIe endpoint device. This supports dual-device modes of RC and EP, enabling the subsystem-level verification platform to process bidirectional data flow and control flow path information. Specifically, it can handle flows from the PCIe RC device to the PCIe controller and physical layer subsystem, then to the serial port (Serdes Side) PCIe verification component (PCIe Verification IP, PCIe VIP), and from the serial port PCIe verification component to the PCIe controller and physical layer subsystem, and then to the PCIe EP device. Here, taking the outbound direction as an example, the device mode is EP mode, i.e., endpoint device mode. The protocol and data type conversion is from transaction layer packets to Advanced Extensible Bus Protocol (AXI) transactions. Furthermore, it can convert between different protocols and data types between transaction layer packets (TLPs) sent or received by the PCIe authentication component and AXI transactions received or returned by the application layer authentication component. Taking the inbound direction as an example, the device mode is RC mode, i.e., root device mode. The protocol and data type conversion is from AXI transactions to transaction layer packets. Furthermore, it can convert between different protocols and data types between AXI transactions sent / received by the application layer authentication component and transaction layer packets received or returned by the PCIe authentication component.

[0036] In one possible implementation, the application layer bus functional level model provides application layer and transaction layer protocol and data type conversion functions during the inbound direction verification to convert transactions from the Advanced Extensible Bus Protocol (AXI) to PCIe transaction layer packets. Similarly, during the outbound direction verification, the application layer and transaction layer protocol and data type conversion functions are used to convert transactions from PCIe transaction layer packets to the Advanced Extensible Bus Protocol (AXI) for transmission. This supports bidirectional data flow paths and control flow paths composed of the first data flow path and control flow path, and the second data flow path and control flow path. Thus, a dual-mode verification component and stimulus sequence are provided, which are easily expandable by users and support both root device mode and endpoint device mode. This offers advantages such as diversified device modes and high configuration flexibility, supporting flexible configuration of dual device modes and control interfaces, and also supporting subsystem-level subsystem protocol interfacing verification. Furthermore, the PCIe verification component can uniformly maintain data link layer or physical layer link-up and link training and status state machine (LTSSM) state information through global handles, such as a global design-under-test state handle. Additionally, by instantiating a design state object under test and providing it to the user via a global handle, users can extend rich stimulus sequence patterns and provide diverse test vectors of various classes.

[0037] Figure 2 This is a schematic diagram of a verification platform for a second embodiment provided in this application. (See attached diagram.) Figure 2As shown, the verification platform includes: an application layer bus functional level model B220, including a customized interface B230 for interacting with the design under test (DUT) B210, wherein the DUT B210 is a PCIe protocol interface and compliance test suite, which supports the verification requirements of the physical layer intellectual property core and the verification requirements of protocol consistency at the PCIe controller and physical layer subsystem levels; and the DUT B210 interacts with the application layer bus functional level model B220 through the customized interface B230. The application layer bus functional level model B220 has application layer and transaction layer protocol and data type conversion functions, multi-type interface driving functions, multi-type interface sampling functions, and transaction layer handle processing functions, thereby supporting inbound verification of the PCIe protocol interface and compliance test suite in root device mode and outbound verification of the PCIe protocol interface and compliance test suite in endpoint device mode. Furthermore, the verification platform also includes a first PCIe verification component A280. Both the application layer bus functional level model B220 and the design under test B210 can be communicatively connected to the first PCIe verification component A280. The first PCIe verification component A280 is configured to switch between root device verification mode and endpoint device verification mode. When the application layer bus functional level model B220 performs inbound verification of the PCIe protocol interfacing and protocol compliance test suite in the root device mode, the first PCIe verification component A280 is switched to the root device verification mode. And when the application layer bus functional level model B220 performs outbound verification of the PCIe protocol interfacing and protocol compliance test suite in the endpoint device mode, the first PCIe verification component A280 is switched to the endpoint device verification mode.

[0038] See Figure 2The Application Layer Bus Functional Level Model B220 provides bridging and conversion functions with interface universality and consistency. It supports driving or sampling different types of application layer interfaces and handling handles at the transaction level, meeting the bus conversion and adaptation needs of different types of Advanced Extended Interface (AXI) or native basic interfaces. Furthermore, because it uses the same test architecture and two different data flow paths and control flow paths to support the verification requirements of PCIe protocol interfacing and protocol compliance test suites, switching between RC and EP modes can be achieved by configuring the Application Layer Bus Functional Level Model B220. This avoids the hardware overhead of additional protocol comparators and verification proxy components, which is beneficial for controlling chip area and improving chip integration. Furthermore, the B220 application layer bus functional level model provides application layer and transaction layer protocol and data type conversion functions, multi-type interface driver functions, multi-type interface sampling functions, and transaction layer handle processing functions. It supports rich interface functions on the customized interface B230, such as AXI interface, Power Management (PM) interface, and Data Bus Interface (DBI). It also supports flexible configuration based on the register abstraction layer model in the control plane (e.g., providing various addressing modes for register read / write operations), and supports finite state machine state traversal and link training and status state machine (LTSSM) enumeration, which helps provide rich stimulus sequence patterns and rich test vector test cases. In addition, it supports not only IP verification requirements at the physical layer level but also protocol conformance verification requirements at the PCIe controller and physical layer subsystem levels. Furthermore, not only can the same application layer bus functional level model B220 be used to simulate both uplink and downlink application scenario verification for PCIe devices, but the same application layer bus functional level model B220 can also be used to achieve protocol and data conversion, saving space and improving efficiency. Moreover, the same first PCIe verification component A280 provides a protocol comparison interface, further improving efficiency. Thus, when the device mode is EP mode, both the first PCIe verification component A280 and the application layer bus functional level model B220 switch to an EP mode-supporting configuration. The first PCIe verification component A280 provides transaction layer packets, and then the application layer bus functional level model B220 converts these transaction layer packets to the Advanced Extensible Bus Protocol for transaction transmission.When the device mode is RC mode, both the first PCIe authentication component A280 and the application layer bus function level model B220 switch to a configuration supporting RC mode. In this way, the first PCIe authentication component A280 provides Advanced Extensible Bus Protocol (AEP) transactions, and then the application layer bus function level model B220 converts the AEP transactions to transaction layer packets. Thus, the integrated first PCIe authentication component A280 can better synchronize various status information using global handles, and compared to a discrete design, it has higher resource utilization.

[0039] See Figure 2 In one possible implementation, the first PCIe verification component A280 includes a transaction layer interface and a serial port interface. The application layer bus functional level model B220 can communicatively connect to the first PCIe verification component A280 through the transaction layer interface, and the design under test B210 can communicatively connect to the first PCIe verification component A280 through the serial port interface. Thus, by integrating the first PCIe verification component A280, dual-device mode and flexible configuration of the control interface are supported. This allows for verification of protocol consistency at the PCIe controller and physical layer subsystem levels with higher integration efficiency and lower learning costs, thereby improving verification efficiency.

[0040] Figure 3 This is a schematic diagram of a verification platform according to a third embodiment of this application. Figure 3As shown, the verification platform includes: an application layer bus functional level model C320, including a customized interface C330 for the design under test (DUT) C310 to interact with the DUT C310, wherein the DUT C310 is a PCIe protocol interface and compliance test suite, which supports the verification requirements of physical layer intellectual property cores and the verification requirements of protocol consistency at the PCIe controller and physical layer subsystem levels; and the DUT C310 interacts with the application layer bus functional level model C320 through the customized interface C330. The application layer bus functional level model C320 has application layer and transaction layer protocol and data type conversion functions, multi-type interface driving functions, multi-type interface sampling functions, and transaction layer handle processing functions, thereby supporting inbound verification of the PCIe protocol interface and compliance test suite in root device mode and outbound verification of the PCIe protocol interface and compliance test suite in endpoint device mode. Furthermore, the verification platform also includes a second PCIe verification component B382 and a third PCIe verification component C384. The application layer bus functional level model C320 is communicatively connected to the second PCIe verification component B382, and the design under test C310 is communicatively connected to the third PCIe verification component C384. The second PCIe verification component B382 is used to send and receive transaction layer packets and cooperate with the application layer bus functional level model C320 and the design under test C310 to perform root device verification. The third PCIe verification component C384 is used to send and receive serial port data and cooperate with the application layer bus functional level model C320 and the design under test C310 to perform endpoint device verification.

[0041] See Figure 3The C320 application layer bus functional level model provides bridging and conversion functions with interface universality and consistency. It supports driving or sampling different types of application layer interfaces and handling handles at the transaction level, meeting the bus conversion and adaptation needs of different types of Advanced Extended Interface (AXI) or native basic interfaces. Furthermore, because it uses the same test architecture and two different data flow paths and control flow paths to support the verification requirements of PCIe protocol interfacing and protocol compliance test suites, switching between RC and EP modes can be achieved by configuring the C320 application layer bus functional level model. This avoids the hardware overhead of additional protocol comparators and verification proxy components, which is beneficial for controlling chip area and improving chip integration. Furthermore, the C320 application layer bus functional level model provides application layer and transaction layer protocol and data type conversion functions, multi-type interface driver functions, multi-type interface sampling functions, and transaction layer handle processing functions. It can support rich interface functions on the customized C330 interface, such as AXI interface, Power Management (PM) interface, and Data Bus Interface (DBI). It also supports flexible configuration based on the register abstraction layer model in the control plane (e.g., providing various addressing modes for register read / write operations), and supports finite state machine state traversal and link training and status state machine (LTSSM) enumeration, which helps provide rich stimulus sequence patterns and rich test vector test cases. In addition, it not only supports IP verification requirements at the physical layer level, but also supports protocol conformance verification requirements at the PCIe controller and physical layer subsystem levels. Furthermore, not only can the verification of both uplink and downlink application scenarios of PCIe devices be simulated using the same application layer bus functional level model C320, but protocol and data conversion can also be achieved through the same application layer bus functional level model C320, saving space and improving efficiency. Furthermore, through the second PCIe verification component B382 and the third PCIe verification component C384, the inbound and outbound verification can be implemented, supporting dual-device mode and flexible configuration of the control interface, as well as subsystem-level subsystem protocol interfacing verification.

[0042] See Figure 1 , Figure 2 and Figure 3In one possible implementation, the customized interface includes an Advanced Extended Interface (AXI), a Data Bus Interface (DBI), and a Power Management (PM) interface. This provides a set of verification components for bridging and converting application-layer bus functional-level models with interface universality and consistency. It supports driving or sampling different types of application-layer interfaces and performing transaction-level handle processing, thus satisfying bus conversion and adaptation for different types of Advanced Extended Interface (AXI) or native basic interfaces.

[0043] In one possible implementation, the application layer bus functional level model also includes a register abstraction layer model (RAL) for a configuration interface to support register read / write operations. This provides rich interface functions such as AXI interfaces, power management (PM) interfaces, and data bus interfaces (DBI). It also supports flexible configuration based on the register abstraction layer model in the control plane (e.g., providing various addressing modes for register read / write operations), and supports state traversal of finite state machines and enumeration of link training and status state machines (LTSSMs), which helps to provide rich stimulus sequence patterns and rich test vector test cases.

[0044] In one possible implementation, the application layer bus functional level model further includes an advanced scalable bus protocol proxy handle for handling advanced scalable bus protocol transmission transactions, a register abstraction layer model handle for configuring register read and write operations, and a design-under-test (DUT) state global handle for maintaining hierarchical global state information of the DUT, wherein the hierarchical global state information of the DUT includes the data link layer connection establishment state, the physical layer connection establishment state, and the state of the link training state machine. Thus, it provides a dual-mode verification component and stimulus sequence that is easy for users to extend hierarchically and supports both root device mode and endpoint device mode. It has the advantages of diversified device modes and strong configuration flexibility, supports flexible configuration of dual device modes and control interface, and also supports subsystem protocol docking verification at the subsystem level. It can be used to build rich stimulus modes and test vector sets, and supports the verification of protocol consistency at the PCIe controller and physical layer subsystem level with higher integration efficiency and lower learning cost. It can effectively reduce the integration and debugging cost of subsystem protocol consistency verification, shorten the verification cycle of PCIe subsystem protocol standardization docking test, and improve the completeness of PCIe subsystem full-scale protocol docking verification and platform reuse efficiency.

[0045] In some embodiments, the application layer bus functional level model supports user-customizable stimulus signal patterns and test vector types by instantiating the state object of the design under test (DUT) and by globalizing the advanced extensible bus protocol proxy handle and the global handle of the DUT state. Thus, by instantiating the DUT state object and providing it to the user through a global handle, the user can extend rich stimulus sequence patterns and provide a variety of test vectors of different types.

[0046] Figure 4 This is a flowchart illustrating a verification method provided in an embodiment of this application. Figure 4 As shown, the verification method includes the following steps.

[0047] Step S401: Determine whether the interfacing test requirement of the design under test is the root device mode of the corresponding application layer bus functional level model or the endpoint device mode of the corresponding application layer bus functional level model. The application layer bus functional level model includes a customized interface for the design under test to interact with the design under test. The design under test is a PCIe protocol interfacing and protocol compliance test suite. The PCIe protocol interfacing and protocol compliance test suite supports the verification requirements of the physical layer intellectual property core and the verification requirements of protocol conformance at the PCIe controller plus physical layer subsystem level. The design under test interacts with the application layer bus functional level model through the customized interface.

[0048] Step S403: When the interoperability test requirement of the design under test is the root device mode corresponding to the application layer bus functional level model, the application layer and transaction layer protocol and data type conversion function, multi-type interface driver function, multi-type interface sampling function and transaction layer handle processing function of the application layer bus functional level model are used to verify the inbound direction of the PCIe protocol interoperability and protocol compliance test suite in the root device mode.

[0049] Step S405: When the interoperability test requirement of the design under test is the endpoint device mode corresponding to the application layer bus functional level model, the application layer and transaction layer protocol and data type conversion function, multi-type interface driver function, multi-type interface sampling function and transaction layer handle processing function of the application layer bus functional level model are used to verify the outbound direction of the PCIe protocol interoperability and protocol compliance test suite in the endpoint device mode.

[0050] Figure 4The verification method described provides a dual-mode verification component and stimulus sequence that is easy for users to extend hierarchically and supports both root device mode and endpoint device mode. It has the advantages of diversified device modes and high configuration flexibility, supports flexible configuration of dual device modes and control interface, and also supports subsystem-level subsystem protocol interface verification. It can be used to build rich stimulus modes and test vector sets, and supports the verification of protocol consistency at the PCIe controller and physical layer subsystem level with higher integration efficiency and lower learning cost. It can effectively reduce the integration and debugging costs of subsystem protocol consistency verification, shorten the verification cycle of PCIe subsystem protocol standardization interface testing, and improve the completeness of PCIe subsystem full-scale protocol interface verification and platform reuse efficiency.

[0051] See Figure 4 In one possible implementation, the inbound direction verification defines a first data flow path and a control flow path from the PCIe root device to the PCIe controller and physical layer subsystem, and then to the serial port PCIe verification component. The outbound direction verification defines a second data flow path and a control flow path from the serial port PCIe verification component to the PCIe controller and physical layer subsystem, and then to the PCIe endpoint device. This supports dual-device mode (RC and EP modes) and provides the ability to process bidirectional data flow path and control flow path information.

[0052] See Figure 4 In one possible implementation, the application layer bus functional level model provides application layer and transaction layer protocol and data type conversion functions during the inbound direction verification to convert transactions transmitted from the Advanced Extensible Bus Protocol (AEP) to PCIe transaction layer packets. Similarly, during the outbound direction verification, the application layer and transaction layer protocol and data type conversion functions are used to convert transactions transmitted from PCIe transaction layer packets to the AEP, thereby supporting bidirectional data flow paths and control flow paths composed of the first data flow path and control flow path, and the second data flow path and control flow path. This provides a dual-mode verification component and stimulus sequence that is easy for users to hierarchically extend and supports both root device mode and endpoint device mode. It offers advantages such as diversified device modes and high configuration flexibility, supports flexible configuration of dual device modes and control interfaces, and also supports subsystem-level subsystem protocol interfacing verification.

[0053] Figure 5This is a schematic diagram of a computing device 500 provided in an embodiment of this application. The computing device 500 includes one or more processors 510, a communication interface 520, and a memory 530. The processors 510, communication interface 520, and memory 530 are interconnected via a bus 540. Optionally, the computing device 500 may further include an input / output interface 550, which is connected to input / output devices for receiving user-set parameters, etc. The computing device 500 can be used to implement some or all of the functions of the device embodiment or system embodiment in the above-described embodiments of this application; the processor 510 can also be used to implement some or all of the operation steps of the method embodiment in the above-described embodiments of this application. For example, the specific implementation of various operations performed by the computing device 500 can be referred to the specific details in the above embodiments, such as the processor 510 being used to execute some or all of the steps or operations in the above-described method embodiments. For example, in the embodiments of this application, the computing device 500 can be used to implement some or all of the functions of one or more components in the above-described device embodiments. In addition, the communication interface 520 can be used for communication functions necessary to implement the functions of these devices and components, and the processor 510 can be used for processing functions necessary to implement the functions of these devices and components.

[0054] It should be understood that, Figure 5 The computing device 500 may include one or more processors 510, and the multiple processors 510 may collaboratively provide processing power in a parallel connection mode, a serial connection mode, a serial-parallel connection mode, or an arbitrary connection mode; or the multiple processors 510 may form a processor sequence or a processor array; or the multiple processors 510 may be divided into a main processor and an auxiliary processor; or the multiple processors 510 may have different architectures, such as adopting a heterogeneous computing architecture. Furthermore, Figure 5 The structural and functional descriptions of the computing device 500 shown are exemplary and non-limiting. In some exemplary embodiments, the computing device 500 may include... Figure 5 The diagram shows more or fewer components, or combinations of some components, or splitting of some components, or different arrangements of components.

[0055] The processor 510 can have various specific implementations. For example, the processor 510 may include one or more combinations of a central processing unit (CPU), a graphics processing unit (GPU), a neural network processing unit (NPU), a tensor processing unit (TPU), or a data processing unit (DPU), etc. This application embodiment does not impose specific limitations. The processor 510 can also be a single-core processor or a multi-core processor. The processor 510 can be a combination of a CPU and hardware chips. The aforementioned hardware chips can be application-specific integrated circuits (ASICs), programmable logic devices (PLDs), or combinations thereof. The aforementioned PLDs can be complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), generic array logic (GALs), or any combination thereof. The processor 510 can also be implemented solely using logic devices with built-in processing logic, such as FPGAs or digital signal processors (DSPs). The communication interface 520 can be a wired interface or a wireless interface, used to communicate with other modules or devices. The wired interface can be an Ethernet interface, a local interconnect network (LIN), etc., and the wireless interface can be a cellular network interface or a wireless LAN interface, etc.

[0056] Memory 530 may be non-volatile memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Memory 530 may also be volatile memory, which may be random access memory (RAM) used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM). The memory 530 can also be used to store program code and data, so that the processor 510 can call the program code stored in the memory 530 to execute some or all of the operation steps in the above method embodiments, or to execute the corresponding functions in the above device embodiments. Furthermore, the computing device 500 may include, compared to... Figure 5 The number of components displayed may be more or less, or there may be different component configurations.

[0057] Bus 540 can be a Peripheral Component Interconnect Express (PCIe) bus, or an Extended Industry Standard Architecture (EISA) bus, a Unified Bus (Ubus or UB), a Compute Express Link (CXL) bus, a Cache Coherent Interconnect for Accelerators (CCIX) bus, etc. Bus 540 can be divided into address bus, data bus, control bus, etc. In addition to the data bus, bus 540 can also include a power bus, control bus, and status signal bus. However, for clarity, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0058] The methods and devices provided in this application are based on the same inventive concept. Since the principles by which the methods and devices solve problems are similar, the embodiments, implementation methods, examples, or methods of implementation of the methods and devices can be referred to each other, and repeated details will not be repeated. This application also provides a system comprising multiple computing devices, the structure of each computing device of which can refer to the structure of the computing devices described above. The functions or operations achievable by this system can refer to the specific implementation steps in the above method embodiments and / or the specific functions described in the above device embodiments, and will not be repeated here.

[0059] This application also provides a computer-readable storage medium storing computer instructions. When these computer instructions are executed on a computer device (such as one or more processors), they can implement the method steps described in the above method embodiments. The specific implementation of the above method steps by the processor of the computer-readable storage medium can refer to the specific operations described in the above method embodiments and / or the specific functions described in the above device embodiments, and will not be repeated here.

[0060] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. This application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Embodiments of this application can be implemented wholly or partially by software, hardware, firmware, or any other combination. When implemented in software, the above embodiments can be implemented wholly or partially as a computer program product. This application can take the form of a computer program product embodied on one or more computer-usable storage media containing computer-usable program code. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless network communication, microwave, etc.) means. Computer-readable storage media can be any available medium that a computer can access, or a data storage device such as a server or data center that contains one or more sets of available media. Available media can be magnetic media (such as floppy disks, hard disks, and magnetic tapes), optical media, or semiconductor media. Semiconductor media can be solid-state drives, random access memory, flash memory, read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, registers, or any other suitable form of storage medium.

[0061] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. Each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0062] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. The steps in the methods of the embodiments of this application can be adjusted in order, combined, or deleted according to actual needs; the modules in the systems of the embodiments of this application can be divided, combined, or deleted according to actual needs. If these modifications and variations of the embodiments of this application fall within the scope of the claims of this application and their equivalents, then this application also intends to include these modifications and variations.

Claims

1. A verification platform, characterized in that, The verification platform includes: The application layer bus functional level model includes customized interfaces for the design under test (DUT) to interact with the DUT, wherein the DUT is a PCIe protocol interface and compliance test suite. This PCIe protocol interface and compliance test suite supports verification requirements for the physical layer intellectual property core and verification requirements for protocol conformance at the PCIe controller and physical layer subsystem levels. The design under test interacts with the application layer bus functional level model through the customized interface. The application layer bus functional level model includes application layer and transaction layer protocol and data type conversion functions, multi-type interface driver functions, multi-type interface sampling functions, and transaction layer handle processing functions. This supports inbound verification of the PCIe protocol interfacing and compliance test suite in root device mode and outbound verification of the PCIe protocol interfacing and compliance test suite in endpoint device mode. The application layer bus functional level model is configured to switch between the root device mode and the endpoint device mode. The inbound direction verification defines the first data flow path and control flow path from the PCIe root device to the PCIe controller and physical layer subsystem, and then to the serial port PCIe verification component. The outbound direction verification defines the second data flow path and control flow path from the serial port PCIe verification component to the PCIe controller and physical layer subsystem, and then to the PCIe endpoint device. The application layer bus functional level model provides application layer and transaction layer protocol and data type conversion functions during the inbound direction verification for converting transactions from Advanced Extensible Bus Protocol to PCIe transaction layer packets. Similarly, the application layer and transaction layer protocol and data type conversion functions provided during the outbound direction verification are used to convert transactions from PCIe transaction layer packets to Advanced Extensible Bus Protocol, thereby supporting bidirectional data flow paths and control flow paths composed of the first data flow path and control flow path and the second data flow path and control flow path.

2. The verification platform according to claim 1, characterized in that, The verification platform further includes a first PCIe verification component. Both the application layer bus functional level model and the design under test can be communicatively connected to the first PCIe verification component. The first PCIe verification component is configured to switch between root device verification mode and endpoint device verification mode. When the application layer bus functional level model performs inbound verification of the PCIe protocol interface and protocol compliance test suite in the root device mode, the first PCIe verification component is switched to the root device verification mode. And when the application layer bus functional level model performs outbound verification of the PCIe protocol interface and protocol compliance test suite in the endpoint device mode, the first PCIe verification component is switched to the endpoint device verification mode.

3. The verification platform according to claim 2, characterized in that, The first PCIe verification component includes a transaction layer interface and a serial port interface. The application layer bus functional level model can be communicatively connected to the first PCIe verification component through the transaction layer interface of the first PCIe verification component. The design under test can be communicatively connected to the first PCIe verification component through the serial port interface of the first PCIe verification component.

4. The verification platform according to claim 1, characterized in that, The verification platform further includes a second PCIe verification component and a third PCIe verification component. The application layer bus functional level model is communicatively connected to the second PCIe verification component, and the design under test is communicatively connected to the third PCIe verification component. The second PCIe verification component is used to send and receive transaction layer packets and to perform root device verification in conjunction with the application layer bus functional level model and the design under test. The third PCIe verification component is used to send and receive serial port data and to perform endpoint device verification in conjunction with the application layer bus functional level model and the design under test.

5. The verification platform according to claim 1, characterized in that, The customized interfaces include an advanced, easily expandable bus protocol interface, a data bus interface, and a power management interface.

6. The verification platform according to claim 1, characterized in that, The application layer bus functional level model also includes a register abstraction layer model for a configuration interface that supports register read and write operations.

7. The verification platform according to claim 1, characterized in that, The application layer bus functional level model also includes an advanced extensible bus protocol proxy handle for handling advanced extensible bus protocol transmission transactions, a register abstraction layer model handle for configuring register read and write operations, and a global handle for the design under test state for maintaining the hierarchical global state information of the design under test, wherein the hierarchical global state information of the design under test includes the data link layer connection establishment state, the physical layer connection establishment state, and the state of the link training state machine.

8. The verification platform according to claim 7, characterized in that, The application layer bus functional level model supports user-customizable stimulus signal patterns and test vector types by instantiating the state object of the design under test and by globalizing the advanced extensible bus protocol proxy handle and the global handle of the state of the design under test.

9. A verification method, characterized in that, The verification method includes: The interfacing test requirements of the design under test (DUT) are determined to be either the root device mode of the application layer bus functional level model or the endpoint device mode of the application layer bus functional level model. The application layer bus functional level model includes a customized interface for interacting with the DUT. The DUT is a PCIe protocol interfacing and compliance test suite. This PCIe protocol interfacing and compliance test suite supports verification requirements for physical layer intellectual property cores and verification requirements for protocol consistency at the PCIe controller and physical layer subsystem levels. The DUT interacts with the application layer bus functional level model through the customized interface. When the interoperability test requirement of the design under test is the root device mode corresponding to the application layer bus functional level model, the application layer and transaction layer protocol and data type conversion function, multi-type interface driver function, multi-type interface sampling function and transaction layer handle processing function of the application layer bus functional level model are used to verify the inbound direction of the PCIe protocol interoperability and protocol compliance test suite in the root device mode. When the interoperability test requirement of the design under test corresponds to the endpoint device mode of the application layer bus functional level model, the application layer and transaction layer protocol and data type conversion functions, multi-type interface driver functions, multi-type interface sampling functions, and transaction layer handle processing functions of the application layer bus functional level model are utilized to perform outbound direction verification of the PCIe protocol interoperability and protocol compliance test suite in the endpoint device mode. The application layer bus functional level model is configured to switch between the root device mode and the endpoint device mode. The inbound direction verification defines the first data flow path and control flow path from the PCIe root device to the PCIe controller and physical layer subsystem, and then to the serial port PCIe verification component. The outbound direction verification defines the second data flow path and control flow path from the serial port PCIe verification component to the PCIe controller and physical layer subsystem, and then to the PCIe endpoint device. The application layer bus functional level model provides application layer and transaction layer protocol and data type conversion functions during the inbound direction verification for converting transactions from Advanced Extensible Bus Protocol to PCIe transaction layer packets. Similarly, the application layer and transaction layer protocol and data type conversion functions provided during the outbound direction verification are used to convert transactions from PCIe transaction layer packets to Advanced Extensible Bus Protocol, thereby supporting bidirectional data flow paths and control flow paths composed of the first data flow path and control flow path and the second data flow path and control flow path.

10. An electronic device, characterized in that, The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method according to claim 9.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed on a computer device, cause the computer device to perform the method according to claim 9.

Images