Physical IP verification device, verification method, computer equipment and media

Abstract

This application relates to the field of integrated circuit technology and provides a physical IP verification device, verification method, computer equipment, and medium. The physical IP verification device includes: a first reusable multi-mode test sequence generator, a verification component physical interface, a second reusable multi-mode test sequence generator, and a verification component serial interface. This allows for the consideration of different simulation needs and scenarios, such as accelerating simulation efficiency and integrating verification. It supports protocol consistency verification, physical layer subsystem-level functional verification completeness, and standardized protocol verification. It provides a rich set of test vectors to meet the interfacing test scenarios and completeness verification needs of different layers, including the transaction layer, data link layer, and physical layer. It supports richly layered debugging interfaces and debugging methods, different physical interface versions and interface data bus widths, and also supports hierarchical and fine-grained low-power management.

Description

Technical Field

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

[0002] With the upgrade and development of the PCIe (PCI Express) protocol, the signal modulation and encoding methods transmitted via the PCIe bus have also changed. This has increased the maximum transmission rate and adopted more complex encoding methods, such as evolving from Non-Return-to-Zero (NRZ) to Four-Level Pulse Amplitude Modulation (PAM4). As the PCIe protocol evolves, there is a need to provide physical layer intellectual property cores (PHY IPs) that can meet higher transmission rates and adapt to newer versions—that is, PCIe physical layer subsystems that conform to the PCIe protocol specifications. This presents challenges to chip verification during the chip design and development process. It is necessary to ensure that the new features and design optimizations added with the evolution of the PCIe protocol can be accurately and without deviation implemented in PHY IP series products that conform to the latest PCIe protocol, such as PCIe6. Furthermore, not only the PCIe protocol, but other communication protocols such as Serializer / DeSerializer (SERDES), Serial Advanced Technology Attachment (SATA), Universal Serial Bus (USB), Ethernet Physical IP, DisplayPort (DP), and High Definition Multimedia Interface (HDMI) also have similar requirements. That is, how to ensure that physical layer subsystems developed based on these communication protocols and interface standards not only reflect new features and design optimizations, but also meet requirements for protocol conformance verification, physical layer subsystem-level functional completeness verification, and standardized protocol verification. Moreover, considering the different stages of chip design and development—from front-end Register Transfer Level (RTL) verification to mid-end netlist verification and back-end silicon verification—different verification schemes may have different focuses, and chip design schemes may face frequent front-end and back-end coordination and modifications. Existing chip verification technologies lack sufficient flexibility and inclusiveness, making it difficult to meet the above verification requirements while improving verification efficiency and shortening the chip development cycle.

[0003] To address these technical challenges, this application provides a physical IP verification device, verification method, computer equipment, and medium. Summary of the Invention

[0004] Firstly, this application provides a physical IP verification device. The physical IP verification device includes: a first reusable multi-mode test sequence generator, used to provide a multi-mode and multi-level first test vector set, wherein the multi-mode and multi-level first test vector set supports root device single mode, endpoint device single mode, or root device and endpoint device dual mode, and the multi-mode and multi-level first test vector set also supports multiple layers of a communication protocol stack including a transaction layer, a data link layer, and a physical layer, wherein the communication protocol stack is a PCIe protocol stack, a SerDes protocol stack, a SATA protocol stack, a USB protocol stack, an Ethernet physical IP protocol stack, a display interface protocol stack, or an HDMI protocol stack; and a verification component physical interface, interacting with the first reusable multi-mode test sequence generator and providing a parameterized physical interface interface for configuring the interface working mode, interface version, and interface data bit width of the physical interface, thereby supporting the physical layer docking requirements of the dual-mode docking configuration of the design under test. The physical layer docking requirements of the dual-mode docking configuration of the design under test include physical layer docking requirements based on physical models and physical layer docking requirements based on actual physical designs; a second reusable multi-mode test sequence generator is used to provide a multi-mode and multi-level second test vector set, wherein the multi-mode and multi-level second test vector set supports root device single mode, endpoint device single mode, or root device and endpoint device dual mode, and the multi-mode and multi-level second test vector set also supports multiple levels of the communication protocol stack; and a verification component serial interface, which interacts with the second reusable multi-mode test sequence generator and provides a parameterized serial interface interface for configuring the serial interface to support the serial port docking requirements of the dual-mode docking configuration of the design under test, wherein the serial port docking requirements of the dual-mode docking configuration of the design under test include serial port docking requirements based on physical models and serial port docking requirements based on actual physical designs.

[0005] The first aspect of this application has the following improvements and beneficial technical effects: It supports two docking modes for the design under test (DUT), one based on a physical model and the other based on a real physical intellectual property core, which can take into account different simulation needs and scenarios such as accelerating simulation efficiency and integration verification; it supports single-mode root device, single-mode endpoint device, or dual-mode root device and endpoint device, and supports customized settings, thereby simulating uplink and downlink scenarios and device characteristics; a single test suite verification device integrates first and second test vector sets supporting multiple modes and multiple levels, as well as first and second reusable multi-mode test sequence generators, and also integrates physical interfaces and serial interfaces supporting dual-mode docking of the DUT, which is equivalent to one test suite achieving the effect of multiple test suites, with high flexibility and inclusiveness; it supports protocol consistency verification, completeness verification of physical layer subsystem-level functions, and standardized protocol verification, provides rich test vector sets, and can meet the docking test scenarios and completeness verification needs of different levels such as transaction layer, data link layer, and physical layer; it supports rich debugging interaction interfaces and debugging methods, supports different physical interface versions and interface data bus widths, and also supports hierarchical and fine-grained low-power management.

[0006] In one possible implementation of the first aspect of this application, the design under test may optionally be interfaced between the physical interface of the verification component and the serial interface of the verification component in either a physical model form or a real physical design form, and at least before the physical IP verification device initiates the protocol conformance verification of the design under test, the physical model form or the real physical design form of the design under test is selected for use in the protocol conformance verification of the design under test.

[0007] In one possible implementation of the first aspect of this application, when the development completion level of the design under test is not higher than a first preset threshold, the feature function table covered by the first test vector set and the second test vector set includes basic data path rate current flow test and control path handshake test. The physical interface of the verification component cooperates with the serial interface of the verification component to support setting the impedance matching resistance value of the physical link transceiver end and skipping the calibration circuit and adaptive adjustment circuit.

[0008] In one possible implementation of the first aspect of this application, when the development completion level of the design under test is higher than the first preset threshold and not higher than the second preset threshold, the feature function table covered by the first test vector set and the second test vector set includes full-rate data path current flow test, power management test and loopback path test. The physical interface of the verification component cooperates with the serial interface of the verification component to support setting the power consumption status of circuit units under multi-level power management, loopback path bypass branch circuit and hardware logic processing, and built-in self-test.

[0009] In one possible implementation of the first aspect of this application, when the development completion level of the design under test is higher than the second preset threshold and not higher than the third preset threshold, the feature function table covered by the first test vector set and the second test vector set includes low-power sub-state testing across the full power spectrum, the calibration circuit and adaptive adjustment circuit, and eye... Figure 2 The verification component physical interface cooperates with the verification component serial interface to support physical initialization accelerated mode and non-accelerated mode, modeling of the calibration circuit and adaptive adjustment circuit, modeling of the receiver-side channel margin circuit, and modeling of the transmitter-side equalization circuit.

[0010] In one possible implementation of the first aspect of this application, when the development completion level of the design under test is higher than the third preset threshold, the feature function table covered by the first test vector set and the second test vector set includes multi-protocol type maximum rate test, multi-interface bus width test, debugging and diagnostic circuit test, and abnormal protection circuit test. The physical interface of the verification component cooperates with the serial interface of the verification component to support calibration and optimization based on post-simulation data and the setting of impedance matching resistor value range at the physical link transceiver end.

[0011] In one possible implementation of the first aspect of this application, the selection of the physical model form of the design under test or the selection of the actual physical design form of the design under test for protocol consistency verification of the design under test is determined based on the development completion degree of the design under test, and the test results of the test cases for protocol consistency verification of the physical model form of the design under test can optionally be reused for protocol consistency verification of the actual physical design form of the design under test.

[0012] In one possible implementation of the first aspect of this application, when the actual physical design form of the design under test changes the impedance matching resistor value, the step size of the calibration circuit and the adaptive adjustment circuit, or the lateral eye width / vertical eye height / eye diagram boundary of the two-dimensional eye diagram of the channel margin circuit relative to the physical model form of the design under test, the test cases for protocol conformance verification against the physical model form of the design under test are rerun or incrementally tested.

[0013] In one possible implementation of the first aspect of this application, when the actual physical design form of the design under test changes the operating voltage, operating current, peak power, or circuit unit area associated with power integrity and signal integrity relative to the physical model form of the design under test, the test cases for protocol conformance verification strongly related to the electrical characteristics of the physical circuit for the physical model form of the design under test are rerun.

[0014] In one possible implementation of the first aspect of this application, the actual physical design form of the design under test includes a physical coding sublayer, a physical layer soft core logic, and a physical layer hard core logic.

[0015] In one possible implementation of the first aspect of this application, the first reusable multimode test sequence generator cooperates with the second reusable multimode test sequence generator to: initiate a root device and endpoint device dual-mode protocol conformance verification process when the design under test is a root device and endpoint device dual-mode, or initiate a root device single-mode protocol conformance verification process when the design under test is a root device single-mode, or initiate an endpoint device single-mode protocol conformance verification process.

[0016] In one possible implementation of the first aspect of this application, the physical interface of the verification component cooperates with the serial interface of the verification component to set the interface working mode of the physical interface associated with the design under test to be either native PIPE working mode or Serdes PIPE working mode, set the interface version associated with the design under test, and set the interface data bit width associated with the design under test.

[0017] In one possible implementation of the first aspect of this application, the physical interface of the verification component cooperates with the serial interface of the verification component to support the design under test operating in various docking test scenarios and completeness test scenarios at multiple layers of the communication protocol stack.

[0018] In one possible implementation of the first aspect of this application, the physical interface of the verification component cooperates with the serial interface of the verification component to support PCIe 1.0, PCIe 2.0, PCIe 3.0, PCIe 4.0, PCIe 5.0 and PCIe 6.0.

[0019] In one possible implementation of the first aspect of this application, the physical interface of the verification component cooperates with the serial interface of the verification component to support interface data bit widths of 1 symbol, 2 symbols, 4 symbols, and 8 symbols, wherein 1 symbol is 8 bits.

[0020] In one possible implementation of the first aspect of this application, the physical IP verification device supports hierarchical and fine-grained low-power management, supports a debug interactive interface for transaction layer recording interaction, and supports a four-level pulse amplitude modulation mode with four-level encoding.

[0021] Secondly, this application provides a physical IP verification method. The physical IP verification method includes: selecting a physical model form of the design under test (DUT) or a real physical design form of the DUT; selecting whether the DUT is a root device single-mode, an endpoint device single-mode, or a root device / endpoint device dual-mode; determining the physical layer interfacing requirements of the dual-mode DUT and the serial port layer interfacing requirements of the dual-mode DUT, wherein the physical layer interfacing requirements of the dual-mode DUT include physical layer interfacing requirements based on the physical model and physical layer interfacing requirements based on the real physical design, and the serial port layer interfacing requirements of the dual-mode DUT include serial port layer interfacing requirements based on the physical model and serial port layer interfacing requirements based on the real physical design; and performing protocol conformance verification of the DUT using a first reusable multi-mode test sequence generator, a verification component physical interface, a second reusable multi-mode test sequence generator, and a verification component serial interface. The first reusable multi-mode test sequence generator provides a multi-mode and multi-level first test vector set. This multi-mode and multi-level first test vector set supports root device single-mode, endpoint device single-mode, or root device / endpoint device dual-mode. It also supports multiple layers of a communication protocol stack including transaction layer, data link layer, and physical layer. The communication protocol stack is a PCIe protocol stack, SerDes protocol stack, SATA protocol stack, USB protocol stack, Ethernet physical IP protocol stack, display interface protocol stack, or HDMI protocol stack. The verification component physical interface interacts with the first reusable multi-mode test sequence generator and provides a parameterized physical interface. The interface operating mode, interface version, and interface data bit width of the physical interface are configured to support the physical layer docking requirements of the dual-mode docking form of the design under test. The second reusable multi-mode test sequence generator is used to provide a multi-mode and multi-level second test vector set. The multi-mode and multi-level second test vector set supports root device single mode, endpoint device single mode, or root device and endpoint device dual mode. The multi-mode and multi-level second test vector set also supports multiple layers of the communication protocol stack. The verification component serial interface interacts with the second reusable multi-mode test sequence generator and provides a parameterized serial interface interface for configuring the serial interface to support the serial port layer docking requirements of the dual-mode docking form of the design under test.

[0022] The second aspect of this application achieves the following improvements and beneficial technical effects: It supports two interface configurations for the design under test (DUT): one based on a physical model and the other based on a real physical intellectual property core, accommodating different simulation needs and scenarios such as accelerated simulation efficiency and integrated verification; it supports single-mode root device, single-mode endpoint device, or dual-mode root device / endpoint device, with customizable settings to simulate uplink / downlink scenarios and device characteristics; a single test suite integrates first and second test vector sets supporting multiple modes and levels, as well as first and second reusable multi-mode test sequence generators, and also integrates physical interfaces and serial interfaces supporting dual-mode DUT interface configurations, effectively achieving the effect of multiple test suites in one suite, offering high flexibility and inclusiveness; it supports protocol consistency verification, physical layer subsystem-level functional verification completeness, and standardized protocol verification, providing rich test vector sets to meet the interface testing scenarios and completeness verification needs of different levels such as transaction layer, data link layer, and physical layer; it supports richly layered debugging interfaces and debugging methods; it supports different physical interface versions and interface data bus widths; and it supports hierarchical and fine-grained low-power management.

[0023] In one possible implementation of the second aspect of this application, the design under test may optionally be interfaced between the physical interface of the verification component and the serial interface of the verification component in the form of a physical model or a real physical design, and at least before performing protocol conformance verification of the design under test, the physical model or the real physical design of the design under test is selected for use in the protocol conformance verification of the design under test.

[0024] In one possible implementation of the second aspect of this application, the selection of the physical model form of the design under test or the selection of the actual physical design form of the design under test for protocol conformance verification of the design under test is determined based on the development completion degree of the design under test, and the test results of the test cases for protocol conformance verification of the physical model form of the design under test can optionally be reused for protocol conformance verification of the actual physical design form of the design under test.

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

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

[0027] 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

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

[0029] Figure 1 A schematic diagram of a physical IP verification device provided in an embodiment of this application;

[0030] Figure 2 This is a flowchart illustrating a process for configuring test vector sets and interfaces based on the development completion level of the design under test, as provided in an embodiment of this application.

[0031] Figure 3 A method based on the embodiments of this application is provided. Figure 1 The diagram shows the process flow of the physical IP verification device for automated verification of the PCIe6 physical layer level test suite.

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

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

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

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

[0036] Figure 1This is a schematic diagram of a physical IP verification device provided in an embodiment of this application. Figure 1As shown, the physical IP verification device includes: a first reusable multi-mode test sequence generator A110, a verification component physical interface 130, a second reusable multi-mode test sequence generator A120, and a verification component serial interface 132. The first reusable multi-mode test sequence generator A110 is used to provide a multi-mode and multi-level first test vector set A112. The multi-mode and multi-level first test vector set A112 supports root complex (RC), endpoint point (EP), or dual mode of RC and endpoint (DM). The multi-mode and multi-level first test vector set A112 also supports multiple layers of a communication protocol stack including the transaction layer, data link layer, and physical layer. The communication protocol stack is a high-speed serial peripheral interconnect bus (PCI Express, PCIe) protocol stack, a serializer / deserializer (SERDES) protocol stack, a Serial Advanced Technology Attachment (SATA) protocol stack, a Universal Serial Bus (USB) protocol stack, an Ethernet physical IP protocol stack, a DisplayPort (DP) protocol stack, or a High Definition Multimedia Interface (HDMI) protocol stack. The verification component physical interface 130 interacts with the first reusable multimode test sequence generator A110 and provides a parameterized physical interface interface for configuring the physical interface's operating mode, interface version, and interface data bit width, thereby supporting the physical layer docking requirements of the dual-mode docking form of the Design Under Test (DUT) 150. The physical layer docking requirements of the dual-mode docking form of the DUT 150 include physical layer docking requirements based on physical models and physical layer docking requirements based on actual physical designs. A second reusable multi-mode test sequence generator A120 provides a multi-mode and multi-level second test vector set A122. The multi-mode and multi-level second test vector set A122 supports root device single-mode, endpoint device single-mode, or root device / endpoint device dual-mode. The multi-mode and multi-level second test vector set A122 also supports multiple layers of the communication protocol stack. A verification component serial interface 132 interacts with the second reusable multi-mode test sequence generator A120 and provides a parameterized serial interface for configuring the serial interface to support the serial port-level interfacing requirements of the dual-mode interfacing configuration of the design under test 150.The serial port level interfacing requirements of the dual-mode interfacing design 150 include serial port level interfacing requirements based on the physical model and serial port level interfacing requirements based on the actual physical design. Figure 1 The diagram also shows that the design under test 150 may optionally be interfaced between the verification component physical interface 130 and the verification component serial interface 132 in either the physical model form 152 of the design under test 150 or the actual physical design form 154 of the design under test 150.

[0037] See Figure 1The first test vector set A112, which is multi-mode and multi-level, also supports multiple layers of the communication protocol stack, including the transaction layer, data link layer, and physical layer. The second test vector set A122, which is also multi-mode and multi-level, also supports multiple layers of the communication protocol stack. Furthermore, the physical interface 130 of the verification component supports the physical layer interface requirements of the dual-mode interface of the design under test 150, and the serial interface 132 of the verification component supports the serial port layer interface requirements of the dual-mode interface of the design under test 150. Thus, it can adapt to various communication protocols and interface standards, as long as they conform to the hierarchical structure design of the communication protocol stack, including but not limited to PCIe protocols (such as PCIe6), SerDes protocols, SATA protocols, USB protocols, Ethernet physical IP protocols, display interface protocols, and HDMI protocols. Furthermore, the docking requirements of the dual-mode interface of the design under test (DUT) 150 are broken down into physical-level docking requirements and serial-level docking requirements. This facilitates meeting the physical-level docking requirements of the dual-mode interface of DUT 150 by configuring the physical interface 130 of the verification component (interface working mode, interface version, and interface data bit width), and meeting the serial-level docking requirements of the dual-mode interface of DUT 150 by configuring the serial interface 132 of the verification component. Thus, two docking modes supporting DUT 150 are achieved: physical model form 152 based on the physical model of DUT 150 and real physical design form 154 based on the actual physical design of DUT 150. This means that different docking modes of DUT 150 can be integrated according to simulation and scenario requirements, thereby balancing accelerated simulation efficiency and integrated verification needs. It also facilitates coverage of all new features of communication protocols and interface standards, and allows for flexible configuration and user-friendly interaction through a parameterized interface. For example, at different stages of chip design and development, from front-end Register Transfer Level (RTL) verification to mid-end netlist verification and back-end silicon verification, there may be different focuses of verification schemes, and chip design schemes may face frequent front-end and back-end coordination and modifications. Thus, by simultaneously supporting physical model-based verification of early-stage designs and real physical design-based verification of later-stage designs, the appropriate interface form of the design under test can be selected at different iterative development nodes, based on the development level of the physical intellectual property core (PHY IP), which is conducive to improving the overall simulation verification efficiency.For example, the upgrades and development of the PCIe protocol have led to changes in the signal modulation and encoding methods transmitted via the PCIe bus. This has increased the maximum transmission rate and adopted more complex encoding methods, such as evolving from Non-Return-to-Zero (NRZ) to Four-Level Pulse Amplitude Modulation (PAM4). With the evolution of the PCIe protocol, there is a need to provide physical layer intellectual property cores (PIPs) that can meet higher transmission rates and adapt to newer versions—that is, PCIe physical layer subsystems that conform to the PCIe protocol specification. Generally, depending on the development progress of the physical layer PIP, typical iterative development nodes typically include: digital / analog design circuit functions reaching 30%, 50%, and 85% completion, respectively. Here, when the completion rate is low, such as 30%, the focus of chip verification is on testing the basic flow of the data path and the basic request-to-response handshake interaction of the control path, and electrical characteristic parameters may not yet be completed during testing. Typically, in the early stages of chip development, defining the outermost interface specification of the physical layer first facilitates the integration of the physical layer wrapper and connections between different IPs / subsystems at the top level of the system-on-a-chip (SoC). Meanwhile, the single-point functional circuits within the physical layer intellectual property core can be gradually improved according to an iterative plan, for example, by first determining the electrical characteristics of the interface. Therefore, in the early stages of chip development, circuit design usually begins with handshake testing to ensure correct interaction with the host computer and system application layer. Taking the PCIe protocol as an example, through flexible interface configuration, different versions of the Physical Interface for the PCIe (PIPE), such as PIPE5 or PIPE6, can be supported. Additionally... Figure 1 The physical IP verification device shown, through multi-mode and multi-level test vector sets, a reusable multi-mode test sequence generator, and parameterized configurable interfaces, supports different interface data bus widths, making it compatible with different data bus widths and application requirements. It also supports easily expandable sequence patterns, rich test cases, and the highest transmission rate compliant with the PCIe6 protocol specification. Furthermore, it supports hierarchical and fine-grained low-power management and rich debugging methods, such as supporting debugging through simulation recording text analysis, graphical interfaces, and a protocol analyzer (PA). The following section will combine... Figure 2 To further elaborate on how to configure test vector sets and interfaces based on the development completion status of the design under test.

[0038] Figure 2 This is a flowchart illustrating a process for configuring test vector sets and interfaces based on the development completion level of the design under test, as provided in an embodiment of this application. Figure 2As shown, in step S201, the configuration process is initiated. Then, in step S210, it is determined whether the development completion rate of the design under test is higher than the first preset threshold of 30%. If not, step S212 is executed to configure the test vector set and interface according to the first configuration. If the development completion rate of the design under test is higher than the first preset threshold of 30%, step S220 is executed to determine whether the development completion rate of the design under test is higher than the second preset threshold of 50%. If not, step S222 is executed to configure the test vector set and interface according to the second configuration. If the development completion rate of the design under test is higher than the second preset threshold of 50%, step S230 is executed to determine whether the development completion rate of the design under test is higher than the third preset threshold of 85%. If not, step S232 is executed to configure the test vector set and interface according to the third configuration. If the development completion rate of the design under test is higher than the third preset threshold of 85%, step S242 is executed to configure the test vector set and interface according to the fourth configuration. In this way, test vector sets and interfaces can be configured according to the development completion level of the design under test. This is achieved by setting specific comparison values, i.e., first, second, and third preset thresholds, and corresponding first, second, and third configurations. Combined with the ability to flexibly select whether the interface form of the design under test is based on a physical model or a real physical design, and the rich and diverse configuration and debugging functions provided by the aforementioned test suites and verification devices, these configuration and debugging functions are based on a parametrically selectable, multi-mode, and configurable general-purpose verification device framework, verification components, and configuration interfaces (e.g., PCIe6PHY IP Test Suite), supporting integrated verification requirements for various types of standard protocol conformance (e.g., PCIe6 PHYIP). These configuration and debugging functions include, but are not limited to: support for parameterization, allowing users to flexibly select and configure the required modes and bus widths; based on a general verification methodology, possessing strong scalability and polymorphism; support for dual-mode interface configurations of the design under test, with flexible user selection; support for both physical initialization accelerated mode (PHY FAST SIM Mode) and non-accelerated mode (Normal Mode); support for different versions of the PIPE interface, with configurable parameters; support for typical rates under different versions of the PCIe protocol and different PIPE interface bus widths, with configurable parameters; and support for either the original PIPE working mode or the Serdes PIPE working mode, with configurable parameters. Thus, a general-purpose verification device and method are provided, applicable to the physical layer intellectual property core verification of PAM4 PCIe6 and other communication protocols and interface standards. It effectively integrates and expands the rich underlying library of the verification component (based on both the physical interface and serial interface of the verification component), providing a dual-mode verification component that is easily expandable by users in a hierarchical manner, and a rich set of test suite sequence modes. It features highly flexible configuration interfaces and diverse device operating modes.Furthermore, this general-purpose verification device and method support single-mode endpoint device or dual-mode root device / endpoint device, flexible configuration of the control interface, and rich sequence modes and test suite test vector sets. It enables users to integrate the protocol verification device and test suite for physical layer intellectual property core protocols with higher integration efficiency, lower learning costs, and less manpower investment, achieving protocol conformance interfacing verification. Moreover, based on this general-purpose verification device, in actual project development, it can effectively reduce the integration cost of physical layer subsystem protocol conformance verification and the debugging cost of basic flow test vectors, shorten the verification cycle of protocol standardization interfacing tests, and effectively improve the completeness of full-scale protocol interfacing verification at the PCIe6 PHY IP dimension and the efficiency of verification device reusability. Table 1 below further details how to configure the test vector set and interface based on the development completion level of the design under test.

[0039] Table 1

[0040]

[0041] See Figure 1 , Figure 2Table 1 uses the PCIe protocol and the physical interface for high-speed serial peripheral interconnect bus, i.e., the PIPE interface, as an example for ease of explanation. It should be understood that this can also be applied to other protocols, such as the design and verification of the physical layer IP of SERDES-related protocols. Here, the verification component physical interface cooperates with the verification component serial interface to set the interface operating mode of the physical interface associated with the design under test (DUT) to either native PIPE operating mode or SERDES PIPE operating mode, to set the interface version associated with the DUT, and to set the interface data bit width associated with the DUT. It can be seen that as the completion rate of the DUT development gradually increases, at multiple iterative development nodes, such as from 30% to 50% and then to 85%, the feature function tables covered by the first and second test vector sets, the features supported by the PIPE interface, and the features supported by the verification component physical interface and the verification component serial interface, all undergo corresponding changes or remain unchanged. For example, when the development completion rate of the design under test (DUT) is low, such as not exceeding the first preset threshold (30%), the impedance matching resistance of the physical link transceiver can be set to an ideal value, such as 50 ohms, and the corresponding impedance selection level can be set. The calibration circuit and self-adjustment circuit can be skipped. This helps improve simulation verification efficiency and better adapts to the verification focus of the early circuit design stage, that is, to match the feature function table covered by the first and second test vector sets, namely, full-rate current flow test of the data path, power management test, and loopback path test. As the development completion rate of the DUT increases, and the electrical characteristic parameters are completed, for example, exceeding the first preset threshold (30%) but not exceeding the second preset threshold (50%), it supports setting the power consumption status of circuit units under multi-level power management, loopback path bypass branch circuits and hardware logic processing, as well as built-in self-tests. This allows for fine-grained control of the power consumption status of each circuit unit, better adapting to tests such as power management. When the development completion rate of the design under test is already relatively high, such as higher than the second preset threshold (50%) and not higher than the third preset threshold (85%), it is necessary to further enhance the circuits with strong electrical characteristics and the setting of tuning parameters according to the design of the digital and analog circuits. At this time, it is supported to model the physical initialization acceleration mode and non-acceleration mode, the calibration circuit and the adaptive adjustment circuit, the receiver side channel margin (RX lane margin) circuit and the transmitter side equalization circuit.Thus, by modeling the calibration circuit and the adaptive adjustment circuit, it is possible to accurately simulate the adjustment of different step amounts during algorithm execution. Furthermore, by modeling the receiver-side channel margin circuit, it is possible to accurately simulate the boundary adjustments in the two dimensions of the eye diagram: the horizontal time eye width and the vertical voltage amplitude eye height. In addition, by modeling the transmitter-side equalization circuit, it is possible to accurately simulate different voltage amplitudes, channel insertion losses, and corresponding level setting indices. When the development completion rate of the design under test is sufficiently high (above 85%) or even reaches the maximum value of 100%, it means that the form of the actual physical design is used as the interface form of the design under test. Therefore, it is necessary to cover a complete set of test vectors. At this time, it is necessary to consider the electrical characteristics under the form of the actual physical design, support calibration and optimization based on simulation data, and set the impedance matching resistance value level at the physical link transceiver end. This allows the phase-locked loop circuit to generate more refined, hierarchical clocks across different frequency bands. It also allows for matching resistor values ​​and corresponding range settings, thus better adapting to the feature function tables covered by the first and second test vector sets, namely, multi-protocol type maximum speed testing, multi-interface bus width testing, debugging and diagnostic circuit testing, and anomaly protection circuit testing. Figure 1 The physical IP verification device shown provides a general verification device and method with strong protocol universality and application versatility. In addition to being suitable for short-cycle, multi-round, continuous agile iterative development and testing of PAM4 PCIe6 PHY, it can also be applied to the design and development of other protocol types and PHY IP circuits, such as SATA / USB / ETH PHY IP, etc. The appropriate test suite test vector can be selected according to different PHY types and development stage nodes.

[0042] Continue reading Figure 1 , Figure 1The physical IP verification device shown has the following improvements and beneficial technical effects: 1) It supports two docking modes for the design under test (DUT): one based on a physical model and the other based on a real physical IP core, which can take into account different simulation needs and scenarios such as accelerating simulation efficiency and integrating verification. 2) It supports single-mode root device, single-mode endpoint device, or dual-mode root device / endpoint device, and supports customized settings, thereby simulating uplink and downlink scenarios and device characteristics. 3) The verification device of a single test suite integrates first and second test vector sets supporting multiple modes and multiple levels, as well as first and second reusable multi-mode test sequence generators. It also integrates physical interfaces and serial interfaces supporting dual-mode docking modes of the DUT, thus achieving the effect of multiple test suites with one test suite, which is highly flexible and inclusive. 4) Supports protocol consistency verification, physical layer subsystem level functional verification completeness and standardized protocol verification, provides rich test vector sets, can meet the docking test scenarios and completeness verification requirements of different layers such as transaction layer, data link layer, physical layer, etc., supports rich debugging interaction interface and debugging methods, supports different physical interface versions and interface data bus width, and also supports hierarchical and fine-grained low power management.

[0043] Figure 3 A method based on the embodiments of this application is provided. Figure 1 The diagram shows the workflow of the physical IP verification device for automated verification of the PCIe6 physical layer level test suite. Figure 3 As shown, in step S301, the verification process is initiated. Then, in step S310, it is determined whether to select the actual physical design form of the design under test. If not, step S312 is executed to use the physical model form of the design under test; if yes, step S314 is executed to use the actual physical design form of the design under test. After step S312 or step S314, step S320 is executed to determine whether to select the root device / endpoint device dual mode. If not, step S330 is executed to determine whether to enable the root device single mode. If still no, step S334 is executed to enable the endpoint device single mode. If the determination in step S330 is yes, step S332 is executed to enable the root device single mode. If the determination in step S320 is yes, step S322 is executed to enable the root device / endpoint device dual mode. After step S322, step S332, or step S334, step S340 is executed to determine whether to select PIPE6 version. If not, step S344 is executed to enable PIPE5 version; if yes, step S342 is executed to enable PIPE6 version. After step S342 or S344, step S350 is executed to send the test suite stimulus sequence and perform PCIe6 protocol verification.

[0044] See Figure 1, Figure 2 besides Figure 3 This invention provides a general-purpose verification device and method for verifying the physical layer intellectual property core of PAM4 PCIe6, as well as other communication protocols and interface standards. It effectively integrates and expands the rich underlying library of verification components (based on both the physical interface and serial interface of the verification components), providing a dual-mode verification component that is easily extended hierarchically by users, and a rich set of test suite sequence modes. It features highly flexible configuration interfaces and diverse device operating modes. Furthermore, this general-purpose verification device and method support single-mode endpoint devices or dual-mode root devices / endpoint devices, support flexible configuration of the control interface, and provide rich sequence modes and test suite test vector sets. This allows users to complete the integration of the physical layer intellectual property core protocol verification device and the protocol conformance interfacing verification of the test suite with higher integration efficiency, lower learning costs, and less manpower investment. Moreover, based on this general-purpose verification device, in actual project development, it can effectively reduce the integration cost of physical layer subsystem protocol conformance verification and the debugging cost of basic flow test vectors, shorten the verification cycle of protocol standardization interfacing tests, and effectively improve the completeness of full-scale protocol interfacing verification at the PCIe6 PHY IP dimension and the efficiency of verification device reusability.

[0045] See Figure 1 , Figure 2 , Figure 3 Table 1 also indicates that, in one possible implementation, the design under test (DUT) can optionally interface between the physical interface and the serial interface of the verification component in either a physical model form or a real physical design form. Furthermore, at least before the physical IP verification device initiates protocol conformance verification of the DUT, either the physical model form or the real physical design form of the DUT is selected for protocol conformance verification. This supports two DUT interface forms: one based on a physical model and the other based on a real physical IP core, thus accommodating different simulation needs and scenarios, such as accelerating simulation efficiency and integrating verification.

[0046] In one possible implementation, when the development completion rate of the design under test (DUT) is not higher than a first preset threshold, the feature function tables covered by the first and second test vector sets include basic data path rate current-through testing and control path handshake testing. The physical interface of the verification component cooperates with the serial interface of the verification component to support setting the impedance matching resistance value of the physical link transceiver and skipping the calibration circuit and self-adaptation circuit. Thus, by configuring the test vector sets and interfaces based on the development completion rate of the DUT, when the development completion rate is low, for example, not higher than the first preset threshold (30%), the impedance matching resistance value of the physical link transceiver can be set to an ideal value, such as 50 ohms, and a corresponding impedance selection level can be set. Furthermore, the calibration circuit and self-adaptation circuit can be skipped. This helps improve simulation verification efficiency and better adapts to the verification focus of the early circuit design stage, that is, to cooperate with the feature function tables covered by the first and second test vector sets, namely, full-rate data path current-through testing, power management testing, and loopback path testing.

[0047] In one possible implementation, when the development completion rate of the design under test (DUT) is higher than the first preset threshold but not higher than the second preset threshold, the feature function table covered by the first and second test vector sets includes full-rate data path current flow testing, power management testing, and loopback path testing. The physical interface of the verification component cooperates with the serial interface of the verification component to support setting the power consumption state of circuit units under multi-level power management, loopback path bypass branch circuits and hardware logic processing, and built-in self-test. Thus, by configuring the test vector set and interface based on the development completion rate of the DUT, as the development completion rate of the DUT increases, and the electrical characteristic parameters are completed, for example, higher than the first preset threshold (30%) but not higher than the second preset threshold (50%), it supports setting the power consumption state of circuit units under multi-level power management, loopback path bypass branch circuits and hardware logic processing, and built-in self-test. This allows for fine-grained control of the power consumption state of each circuit unit, better adapting to tests such as power management.

[0048] In one possible implementation, when the development completion level of the design under test is higher than the second preset threshold and not higher than the third preset threshold, the feature function table covered by the first test vector set and the second test vector set includes low-power sub-state testing across the entire power spectrum, the calibration circuit and adaptive adjustment circuit, and eye... Figure 2The test includes boundary testing and equalization circuit testing. The physical interface of the verification component cooperates with the serial interface of the verification component to support physical initialization accelerated and non-accelerated modes, modeling of the calibration circuit and adaptive adjustment circuit, modeling of the receiver-side channel margin circuit, and modeling of the transmitter-side equalization circuit. Thus, the test vector set and interface are configured based on the development completion rate of the design under test (DUT). When the DUT's development completion rate is high, for example, above the second preset threshold (50%) and not higher than the third preset threshold (85%), it is necessary to further enhance the circuits with strong electrical characteristics and optimize the parameter settings according to the design of the digital-analog circuit. At this point, it supports physical initialization accelerated and non-accelerated modes, modeling of the calibration circuit and adaptive adjustment circuit, modeling of the receiver-side channel margin (RX lane margin) circuit, and modeling of the transmitter-side equalization circuit. Thus, by modeling the calibration circuit and the adaptive adjustment circuit, it is possible to accurately simulate the adjustment of different step amounts during the algorithm execution process. Furthermore, by modeling the receiver-side channel margin circuit, it is possible to accurately simulate the boundary adjustment of the two dimensions of eye diagram: horizontal time eye width and vertical voltage amplitude eye height. In addition, by modeling the transmitter-side equalization circuit, it is possible to accurately simulate different voltage amplitudes, channel insertion loss, and corresponding level setting indices.

[0049] In one possible implementation, when the development completion rate of the design under test (DUT) exceeds the third preset threshold, the feature function table covered by the first and second test vector sets includes multi-protocol type maximum rate testing, multi-interface bus width testing, debugging and diagnostic circuit testing, and anomaly protection circuit testing. The physical interface of the verification component cooperates with the serial interface of the verification component to support calibration and optimization based on post-simulation data and the setting of impedance matching resistor values ​​at the physical link transceiver ends. Thus, the test vector set and interface are configured based on the development completion rate of the DUT. When the development completion rate of the DUT is sufficiently high (above 85%) or even reaches the maximum value of 100%, it means that the form of the actual physical design is used as the interface form of the DUT. Therefore, a complete set of test vectors needs to be covered. At this point, the electrical characteristics under the form of the actual physical design need to be considered, supporting calibration and optimization based on post-simulation data and the setting of impedance matching resistor values ​​at the physical link transceiver ends. In this way, the phase-locked loop circuit can generate more refined, hierarchical clocks with different frequency bands, and can also match resistor values ​​and corresponding range settings, thereby better adapting to the feature function tables covered by the first and second test vector sets, namely, multi-protocol type maximum speed test, multi-interface bus width test, debugging and diagnostic circuit test, and abnormal protection circuit test.

[0050] In one possible implementation, the selection of either the physical model form of the design under test (DUT) or the actual physical design form of the DUT for protocol conformance verification is determined based on the development completion level of the DUT. Furthermore, the test results of test cases for protocol conformance verification of the physical model form of the DUT can optionally be reused for protocol conformance verification of the actual physical design form of the DUT. See also... Figure 1 , Figure 2 , Figure 3 As shown in Table 1, with the gradual improvement of the completion rate of the design under test (DUT) at multiple iterative development nodes, such as from 30% to 50% and then to 85%, the feature function tables covered by the first and second test vector sets, the features supported by the PIPE interface, and the features supported by the physical interface and serial interface of the verification component all changed or remained unchanged. When the completion rate is low, such as 30%, the focus of chip verification is on testing the basic flow of the data path and the basic request-to-response handshake interaction of the control path, and the electrical characteristic parameters may not have been completed at the time of testing. Typically, in the early stages of chip development, clarifying the outermost interface specification of the physical layer first is beneficial for the top-level chip of the system-on-a-chip to start integrating the physical layer periphery (PHY Wrapper) and the connections between different IPs / subsystems. The single-point functional circuits inside the physical layer intellectual property core can be gradually improved according to the iterative plan, for example, by first determining the electrical characteristics of the interface. Therefore, in the early stages of chip development, circuit design typically begins with testing the handshake mechanism to ensure correct interaction with the host computer and system application layer. However, as chip development progresses, some parameters set based on the physical model in the early circuit design may deviate significantly. Consequently, early test results may be limited compared to the current chip design. For example, the handshake protocol is based on feedback time, and significant changes in circuit delays or timing paths may necessitate re-verifying the handshake test results or test cases from earlier tests. To address this, the test results of early test cases—specifically, those verifying protocol conformance for the physical model of the design under test—can be selectively reused by examining changes in certain key parameters. Alternatively, past test cases can be rerun. Therefore, the test results of protocol conformance verification for the physical model of the design under test can be optionally reused for protocol conformance verification of the actual physical design of the design under test. This improves overall verification efficiency while ensuring the completeness and correctness of the verification results.

[0051] In one possible implementation, when the actual physical design of the design under test (DUT) changes the impedance matching resistor value, the step size of the calibration circuit and adaptive adjustment circuit, or the lateral eye width / vertical eye height / eye diagram boundary of the two-dimensional eye diagram of the channel margin circuit relative to the physical model of the DUT, the test cases for protocol conformance verification against the physical model of the DUT are rerun or incrementally tested. Thus, as the chip development completion rate increases, by examining changes in certain key parameters, an incremental increase in test vectors can be achieved, i.e., selectively reusing earlier test results. Changes in key parameters, such as electrical characteristics, latency, operating voltage, operating current, peak power, etc., may deviate from the initial design during development; therefore, some test vectors can still be reused, while others must be retested. This helps optimize verification efficiency. Here, by examining whether the impedance matching resistor value, the step size of the calibration circuit and the adaptive adjustment circuit have been changed, or the horizontal eye width / vertical eye height / eye diagram boundary of the two-dimensional eye diagram of the channel margin circuit, combined with the change list compiled in the positive direction during the circuit design phase and the feature list supported by the version iteration, we can selectively rerun the test cases that have already been tested, or selectively reuse, that is, continue to use the test results developed earlier. This helps to improve the overall verification efficiency.

[0052] In one possible implementation, when the actual physical design of the design under test (DUT) changes the operating voltage, operating current, peak power, or circuit cell area associated with Signal Integrity and Power Integrity (SIPI) compared to the physical model of the DUT, the test cases for protocol conformance verification strongly correlated with the electrical characteristics of the physical circuit are rerun. Thus, considering the reuse of test vector results and the possibility of reruns, for example, handshake protocols are based on end-to-end feedback time from response to request. Assuming that internal pipeline delay tacks typically increase with the functionality and complexity of the circuit, the increased circuit latency may mean that early handshake success test results need to be re-verified. Therefore, incremental test vectors are used, adding new test vectors as development progresses, which helps shorten the overall verification time. Here, by examining certain key changes, such as electrical characteristics, latency, signal integrity (SI), and power integrity (PI), also known as power consumption integrity, as well as related operating voltage / current, peak power, and circuit cell area, we can see that there may be deviations from the initial design during development. Based on simulation data, we continuously adjust and optimize the circuit microarchitecture and core units. Therefore, some test vectors can still be reused, while others must be retested. This helps optimize verification efficiency.

[0053] In one possible implementation, the actual physical design form of the design under test (DUT) includes a Physical Layer Code Sub-Layer (PCS), a Physical Layer Process Unit (PPU), and a Physical Layer Media Attachment (PMA). This supports two DUT interface forms: one based on a physical model and the other based on a real physical intellectual property core, thus accommodating different simulation needs and scenarios, such as accelerating simulation efficiency and integrating verification.

[0054] In one possible implementation, the first reusable multi-mode test sequence generator cooperates with the second reusable multi-mode test sequence generator to: initiate a root device / endpoint device dual-mode protocol conformance verification process when the design under test is in root device / endpoint device dual-mode; or initiate a root device / single-mode protocol conformance verification process when the design under test is in root device single-mode; or initiate an endpoint device / single-mode protocol conformance verification process. Thus, it supports root device single-mode, endpoint device single-mode, or root device / endpoint device dual-mode, supports customized settings, and can simulate uplink / downlink scenarios and device characteristics.

[0055] In one possible implementation, the physical interface of the verification component cooperates with the serial interface of the verification component to set the interface operating mode of the physical interface associated with the design under test (DUT) to either native PIPE or Serdes PIPE mode, set the interface version associated with the DUT, and set the interface data bus width associated with the DUT. This supports protocol consistency verification, physical layer subsystem-level functional completeness verification, and standardized protocol verification. It provides a rich set of test vectors to meet the interfacing test scenarios and completeness verification requirements of different layers such as the transaction layer, data link layer, and physical layer. It supports richly layered debugging interfaces and debugging methods, different physical interface versions and interface data bus widths, and also supports hierarchical and fine-grained low-power management.

[0056] In one possible implementation, the physical interface of the verification component cooperates with the serial interface of the verification component to support the interfacing and completeness testing scenarios of the design under test (DUT) at multiple layers of the communication protocol stack. This provides a general-purpose verification device and method with strong protocol universality and application versatility. Besides being suitable for short-cycle, multi-round, continuous agile iterative development and testing of PAM4 PCIe6 PHYs, it is also applicable to the design and development of other protocol types and PHY IP circuits, such as SATA / USB / ETH PHY IPs, by selecting appropriate test suite test vectors according to different PHY types and development stage nodes.

[0057] In one possible implementation, the verification component physical interface cooperates with the verification component serial interface to support PCIe 1.0, PCIe 2.0, PCIe 3.0, PCIe 4.0, PCIe 5.0, and PCIe 6.0. This supports the verification requirements of various versions of the PCIe protocol.

[0058] In one possible implementation, the physical interface of the verification component cooperates with the serial interface of the verification component to support interface data bit widths of 1 symbol, 2 symbols, 4 symbols, and 8 symbols, where 1 symbol is 8 bits. This supports compatibility with various interface data bit widths.

[0059] In one possible implementation, the physical IP verification device supports hierarchical and fine-grained low-power management, supports a debug interface for transaction layer recording, and supports a four-level pulse amplitude modulation mode with four-level encoding. Thus, it is suitable for short-cycle, multi-round, continuous agile iterative development and testing of PAM4 PCIe6 PHY, supports a richly layered debug interface and debugging methods, supports different physical interface versions and interface data bus widths, and also supports hierarchical and fine-grained low-power management.

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

[0061] Step S401: Select the physical model form of the design under test or the actual physical design form of the design under test.

[0062] Step S403: Select whether the design under test is a root device single mode, an endpoint device single mode, or a root device and endpoint device dual mode.

[0063] Step S405: Determine the physical layer docking requirements of the dual-mode docking form of the design under test and the serial port layer docking requirements of the dual-mode docking form of the design under test. The physical layer docking requirements of the dual-mode docking form of the design under test include physical layer docking requirements based on the physical model and physical layer docking requirements based on the actual physical design. The serial port layer docking requirements of the dual-mode docking form of the design under test include serial port layer docking requirements based on the physical model and serial port layer docking requirements based on the actual physical design.

[0064] Step S407: Utilize the first reusable multi-mode test sequence generator, the verification component physical interface, the second reusable multi-mode test sequence generator, and the verification component serial interface to perform protocol conformance verification of the design under test.

[0065] See Figure 4The first reusable multi-mode test sequence generator provides a multi-mode and multi-level first test vector set. This multi-mode and multi-level first test vector set supports root device single-mode, endpoint device single-mode, or root device / endpoint device dual-mode. It also supports multiple layers of a communication protocol stack, including transaction layer, data link layer, and physical layer. The communication protocol stack can be a PCIe protocol stack, SerDes protocol stack, SATA protocol stack, USB protocol stack, Ethernet physical IP protocol stack, display interface protocol stack, or HDMI protocol stack. The verification component physical interface interacts with the first reusable multi-mode test sequence generator and provides a parameterized physical interface interface for configuring the physical interface's working mode, interface version, and interface data bit width, thereby supporting the physical layer docking requirements of the dual-mode docking configuration of the design under test. The second reusable multi-mode test sequence generator provides a multi-mode and multi-level second test vector set, which supports root device single mode, endpoint device single mode, or root device / endpoint device dual mode. The multi-mode and multi-level second test vector set also supports multiple layers of the communication protocol stack. The verification component serial interface interacts with the second reusable multi-mode test sequence generator and provides a parameterized serial interface for configuring the serial interface to support the serial port-level interfacing requirements of the dual-mode interfacing configuration of the design under test.

[0066] Figure 4 The physical IP verification method shown has the following improvements and beneficial technical effects: 1) It supports two docking modes for the design under test (DUT): one based on a physical model and the other based on a real physical IP core, which can take into account different simulation needs and scenarios such as accelerating simulation efficiency and integrating verification. 2) It supports single-mode root device, single-mode endpoint device, or dual-mode root device / endpoint device, and supports customized settings, thereby simulating uplink and downlink scenarios and device characteristics. 3) A single test suite verification device integrates first and second test vector sets supporting multiple modes and multiple levels, as well as first and second reusable multi-mode test sequence generators. It also integrates physical interfaces and serial interfaces supporting dual-mode docking modes of the DUT, thus achieving the effect of multiple test suites with one test suite, offering high flexibility and inclusiveness. 4) Supports protocol consistency verification, physical layer subsystem level functional verification completeness and standardized protocol verification, provides rich test vector sets, can meet the docking test scenarios and completeness verification requirements of different layers such as transaction layer, data link layer, physical layer, etc., supports rich debugging interaction interface and debugging methods, supports different physical interface versions and interface data bus width, and also supports hierarchical and fine-grained low power management.

[0067] See Figure 4In one possible implementation, the design under test (DUT) can optionally interface between the physical interface and the serial interface of the verification component in either a physical model form or a real physical design form. Furthermore, at least before performing protocol conformance verification of the DUT, either the physical model form or the real physical design form of the DUT is selected for use in the protocol conformance verification. This supports two interface forms for the DUT: one based on a physical model and the other based on a real physical intellectual property core, thus accommodating different simulation needs and scenarios, such as accelerating simulation efficiency and integrating verification.

[0068] In one possible implementation, the selection of either the physical model form of the design under test (DUT) or the actual physical design form of the DUT for protocol conformance verification is determined based on the development completion level of the DUT. Furthermore, the test results of test cases for protocol conformance verification of the physical model form of the DUT can optionally be reused for protocol conformance verification of the actual physical design form of the DUT. As the development completion level of the DUT gradually increases, at multiple iterative development nodes, for example from 30% to 50% and then to 85%, the feature function tables covered by the first and second test vector sets, the features supported by the PIPE interface, and the features supported by the physical interface and serial interface of the verification component in conjunction with each other all change accordingly or remain unchanged. When the completion level is low, such as 30%, the focus of chip verification is on testing the basic flow of the data path and the basic request-to-response handshake interaction of the control path, and electrical characteristic parameters may not yet be completed during testing. Typically, in the early stages of chip development, defining the outermost interface specifications of the physical layer first facilitates the integration of the physical layer periphery (PHY wrapper) and the connections between different IPs / subsystems at the top level of the system-on-a-chip (SoC). Meanwhile, the single-point functional circuits within the physical layer intellectual property core can be gradually improved according to an iterative plan, for example, by first determining the electrical characteristics of the interface. Therefore, in the early stages of chip development, circuit design usually begins with handshake testing to ensure correct interaction with the host computer and system application layer. However, as the chip development project progresses, some parameters set based on the physical model in the early circuit design may deviate significantly. Therefore, early test results may have limitations compared to the current chip design. For example, the handshake protocol is based on feedback time, and when circuit delays or timing paths change significantly, it may be necessary to re-verify the handshake test results or test cases from the early tests. Therefore, for early test results—that is, the test results of test cases verifying protocol conformance of the physical model of the design under test—the changes in certain key parameters can be examined to selectively reuse the early test results, or the test cases can be rerun. Thus, the test results of test cases verifying protocol conformance of the physical model of the design under test can optionally be reused for protocol conformance verification of the actual physical design of the design under test. This improves overall verification efficiency while ensuring the completeness and correctness of the verification results.

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

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

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

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

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

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

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

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

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

[0078] 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 physical IP verification device, characterized in that, The physical IP verification device includes: A first reusable multi-mode test sequence generator is used to provide a multi-mode and multi-level first test vector set, wherein the multi-mode and multi-level first test vector set supports root device single mode, endpoint device single mode, or root device and endpoint device dual mode, and the multi-mode and multi-level first test vector set also supports multiple layers of communication protocol stacks including transaction layer, data link layer and physical layer, wherein the communication protocol stack is PCIe protocol stack, SerDes protocol stack, SATA protocol stack, USB protocol stack, Ethernet physical IP protocol stack, display interface protocol stack or HDMI protocol stack; Verify the physical interface of the component, interact with the first reusable multi-mode test sequence generator and provide a parameterized physical interface interface for configuring the interface working mode, interface version and interface data bit width of the physical interface, thereby supporting the physical layer docking requirements of the dual-mode docking form of the design under test. The physical layer docking requirements of the dual-mode docking form of the design under test include physical layer docking requirements based on physical models and physical layer docking requirements based on real physical designs. A second reusable multi-mode test sequence generator is used to provide a multi-mode and multi-level second test vector set, wherein the multi-mode and multi-level second test vector set supports root device single mode, endpoint device single mode, or root device and endpoint device dual mode, and the multi-mode and multi-level second test vector set also supports multiple levels of the communication protocol stack; and The verification component has a serial interface that interacts with the second reusable multimode test sequence generator and provides a parameterized serial interface for configuring the serial interface to support the serial port level docking requirements of the dual-mode docking form of the design under test. The serial port level docking requirements of the dual-mode docking form of the design under test include serial port level docking requirements based on physical models and serial port level docking requirements based on actual physical designs.

2. The physical IP verification device according to claim 1, characterized in that, The design under test (DUT) is connected between the physical interface and the serial interface of the verification component in either a physical model form or a real physical design form. Furthermore, at least before the physical IP verification device initiates the protocol conformance verification of the DUT, the physical model form or the real physical design form of the DUT is selected for use in the protocol conformance verification of the DUT.

3. The physical IP verification device according to claim 2, characterized in that, When the development completion rate of the design under test is not higher than the first preset threshold, the feature function table covered by the first test vector set and the second test vector set includes basic data path rate current flow test and control path handshake test. The physical interface of the verification component cooperates with the serial interface of the verification component to support setting the impedance matching resistance value of the physical link transceiver end and skipping the calibration circuit and adaptive adjustment circuit.

4. The physical IP verification device according to claim 3, characterized in that, When the development completion rate of the design under test is higher than the first preset threshold and not higher than the second preset threshold, the feature function table covered by the first test vector set and the second test vector set includes full-rate data path current flow test, power management test and loopback path test. The physical interface of the verification component cooperates with the serial interface of the verification component to support setting the power consumption status of circuit units under multi-level power management, loopback path bypass branch circuit and hardware logic processing, and built-in self-test.

5. The physical IP verification device according to claim 4, characterized in that, When the development completion rate of the design under test is higher than the second preset threshold and not higher than the third preset threshold, the feature function table covered by the first test vector set and the second test vector set includes low-power sub-state testing of the full power spectrum, the calibration circuit and adaptive adjustment circuit, eye diagram two-dimensional boundary testing, and equalization circuit testing. The physical interface of the verification component cooperates with the serial interface of the verification component to support physical initialization accelerated mode and non-accelerated mode, modeling of the calibration circuit and adaptive adjustment circuit, modeling of the receiver-side channel margin circuit, and modeling of the transmitter-side equalization circuit.

6. The physical IP verification device according to claim 5, characterized in that, When the development completion rate of the design under test is higher than the third preset threshold, the feature function table covered by the first test vector set and the second test vector set includes multi-protocol type maximum rate test, multi-interface bus width test, debugging and diagnostic circuit test, and abnormal protection circuit test. The physical interface of the verification component cooperates with the serial interface of the verification component to support calibration and optimization based on post-simulation data and the setting of impedance matching resistor value at the physical link transceiver end.

7. The physical IP verification device according to claim 2, characterized in that, The selection of either the physical model form of the design under test or the actual physical design form of the design under test for protocol consistency verification is determined based on the development completion level of the design under test. Furthermore, the test results of the test cases for protocol consistency verification of the physical model form of the design under test are reused for protocol consistency verification of the actual physical design form of the design under test.

8. The physical IP verification device according to claim 7, characterized in that, When the actual physical design of the design under test changes the impedance matching resistor value, the step size of the calibration circuit and the adaptive adjustment circuit, or the horizontal eye width / vertical eye height / eye diagram boundary of the two-dimensional eye diagram of the channel margin circuit relative to the physical model of the design under test, the test cases for protocol conformance verification of the physical model of the design under test are rerun or incrementally tested.

9. The physical IP verification device according to claim 7, characterized in that, When the actual physical design of the design under test changes the operating voltage, operating current, peak power, or circuit unit area associated with power integrity and signal integrity compared to the physical model of the design under test, the test cases for protocol conformance verification that are strongly related to the electrical characteristics of the physical circuit for the physical model of the design under test shall be rerun.

10. The physical IP verification device according to claim 2, characterized in that, in, The actual physical design form of the design under test includes the physical coding sublayer, the physical layer soft core logic, and the physical layer hard core logic.

11. The physical IP verification device according to claim 2, characterized in that, The first reusable multimode test sequence generator cooperates with the second reusable multimode test sequence generator to: initiate a root device and endpoint device dual-mode protocol conformance verification process when the design under test is a root device and endpoint device dual-mode, or initiate a root device single-mode protocol conformance verification process when the design under test is a root device single-mode, or initiate an endpoint device single-mode protocol conformance verification process.

12. The physical IP verification device according to claim 2, characterized in that, The physical interface of the verification component cooperates with the serial interface of the verification component to set the interface working mode of the physical interface associated with the design under test to be either native PIPE working mode or Serdes PIPE working mode, set the interface version associated with the design under test, and set the interface data bit width associated with the design under test.

13. The physical IP verification device according to claim 2, characterized in that, The physical interface of the verification component works in conjunction with the serial interface of the verification component to support the design under test in various docking test scenarios and completeness test scenarios at multiple layers of the communication protocol stack.

14. The physical IP verification device according to claim 2, characterized in that, The physical interface of the verification component works in conjunction with the serial interface of the verification component to support PCIe 1.0, PCIe 2.0, PCIe 3.0, PCIe 4.0, PCIe 5.0 and PCIe 6.

0.

15. The physical IP verification device according to claim 2, characterized in that, The physical interface of the verification component works in conjunction with the serial interface of the verification component to support interface data bit widths of 1 symbol, 2 symbols, 4 symbols and 8 symbols, where 1 symbol is 8 bits.

16. The physical IP verification device according to claim 2, characterized in that, The physical IP verification device supports hierarchical and fine-grained low-power management, supports a debugging interface for transaction layer recording, and supports a four-level pulse amplitude modulation mode with four-level encoding.

17. A physical IP verification method, characterized in that, The physical IP verification method includes: Select the physical model form of the design to be tested or the actual physical design form of the design to be tested; Select whether the design under test is root device single mode, endpoint device single mode, or root device and endpoint device dual mode. The physical layer docking requirements of the dual-mode docking form of the design under test and the serial port layer docking requirements of the dual-mode docking form of the design under test are determined. The physical layer docking requirements of the dual-mode docking form of the design under test include physical layer docking requirements based on physical models and physical layer docking requirements based on actual physical designs. The serial port layer docking requirements of the dual-mode docking form of the design under test include serial port layer docking requirements based on physical models and serial port layer docking requirements based on actual physical designs. The protocol conformance verification of the design under test is performed using a first reusable multi-mode test sequence generator, a verification component physical interface, a second reusable multi-mode test sequence generator, and a verification component serial interface. The first reusable multi-mode test sequence generator is used to provide a multi-mode and multi-level first test vector set. This multi-mode and multi-level first test vector set supports root device single-mode, endpoint device single-mode, or root device / endpoint device dual-mode. Furthermore, the multi-mode and multi-level first test vector set supports multiple layers of a communication protocol stack, including the transaction layer, data link layer, and physical layer. The communication protocol stack can be a PCIe protocol stack, a SerDes protocol stack, a SATA protocol stack, a USB protocol stack, an Ethernet physical IP protocol stack, a display interface protocol stack, or an HDMI protocol stack. The verification component's physical interface interacts with the first reusable multi-mode test sequence generator and provides a parameterized physical interface for configuring the physical interface's operating mode, version, and data bit width, thereby supporting the physical-level docking requirements of the dual-mode docking configuration of the design under test. The second reusable multi-mode test sequence generator is used to provide a multi-mode and multi-level second test vector set. The multi-mode and multi-level second test vector set supports root device single mode, endpoint device single mode, or root device and endpoint device dual mode. The multi-mode and multi-level second test vector set also supports multiple levels of the communication protocol stack. The verification component's serial interface interacts with the second reusable multimode test sequence generator and provides a parameterized serial interface for configuring the serial interface to support the serial port-level docking requirements of the dual-mode docking configuration of the design under test.

18. The physical IP verification method according to claim 17, characterized in that, The design under test (DUT) is interfaced between the physical interface and the serial interface of the verification component in either a physical model form or a real physical design form. Furthermore, at least before performing protocol conformance verification of the DUT, the physical model form or the real physical design form of the DUT is selected for use in the protocol conformance verification of the DUT.

19. The physical IP verification method according to claim 17, characterized in that, The selection of either the physical model form of the design under test or the actual physical design form of the design under test for protocol consistency verification is determined based on the development completion level of the design under test. Furthermore, the test results of the test cases for protocol consistency verification of the physical model form of the design under test are reused for protocol consistency verification of the actual physical design form of the design under test.

20. A computer device, characterized in that, The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method according to any one of claims 17 to 19.

21. 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 any one of claims 17 to 19.

Images