Method for managing verification platform, electronic device, medium, verification method and platform

Abstract

The application relates to the technical field of integrated circuits and provides a management method of a verification platform, an electronic device, a medium, a verification method and a platform. The method comprises determining a test requirement associated with a design under test, setting configurable parameters of a plurality of function modules of the verification platform based on the requirement, and setting verification rules included in a layered verifier of the verification platform, so that adaptation for the design under test is realized. Not only can customized service support be provided for specific interface test requirements, but also the complexity and workload of maintenance of the verification stage of the full life cycle of chip development from the early stage to the middle and late stages are effectively reduced. In addition, the verification efficiency is improved and the verification time is shortened, and quick response and cost reduction are supported, for complex and changeable chip IP verification requirements in different development stages, different communication protocols and interface standards, different interface test requirements and different customized requirements.

Description

Technical Field

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

[0002] With the development of technologies such as artificial intelligence, data centers, connected vehicles, the Internet of Things, and androids, various types of communication protocols and interface standards have emerged, and these protocols and standards are constantly being upgraded and evolved. This presents challenges to the quality and completeness of the delivery of intellectual property (IP) for chip designs. IP delivery requires rigorous and meticulous verification. As a crucial quality step in standardized protocol verification, the verification methods used to verify protocol consistency must also evolve in line with changes in communication protocols and interface standards. However, considering the complex and ever-changing specific interfacing test requirements proposed by customers, developing an entire verification platform from scratch to complete interfacing tests would face problems of high manpower consumption and long verification cycles. For example, specific interfacing test requirements from customers might be based on the Peripheral Component Interconnect Express (PCIe) protocol, the Serializer / DeSerializer (Serdes) protocol, or other protocols such as Transmission Control Protocol / Internet Protocol (TCP / IP), Serial Advanced Technology Attachment (SATA) protocol, High Definition Multimedia Interface (HDMI) protocol, Universal Serial Bus (USB) protocol, and Universal Chiplet Interconnect Express (UCIe). Furthermore, customer requirements may change during chip IP development, such as requiring a switch to a different communication protocol or interfacing with different protocol versions. These changes all contribute to the complexity and workload of the verification phase.

[0003] In the prior art, the protocol for communicating with the Design Under Test (DUT) is reconfigured through configurable integrated circuits or programmable communication protocol engines. For example, Chinese Patent Application Publication No. CN105008943A discloses that the communication protocol engine can be programmed on a Field Programmable Gate Array (FPGA) device, making the protocol used for communicating with the DUT reconfigurable. As another example, Chinese Patent Application Publication No. CN103038751B discloses that a configurable integrated circuit includes a configurable interface core, which is programmable to provide one or more protocol-based interfaces to the DUT and is also programmable to interface with the DUT. For example, Chinese patent CN105144114B discloses that each protocol engine module within an FPGA device can be configured with different communication protocols; the FPGA device can be connected to test multiple DUTs, each supporting different communication protocols simultaneously; the FPGA device can be connected to a single DUT supporting multiple protocols and test all modules running on the device simultaneously; if the FPGA is configured to run both PCIe and SATA protocols, it can be connected to test DUTs supporting both PCIe and SATA protocols; or, it can be connected to test two different DUTs, one supporting PCIe and the other supporting SATA. For another example, Chinese patent CN116324438A discloses that a reprogrammable processor includes reprogrammable standards and protocols for any one or both of the DUT and the programmed device. Existing solutions for DUT verification rely on programmable hardware such as FPGAs or similar configurable integrated circuits; therefore, if testing requires interfacing with new protocols or modifying existing protocols, software needs to be downloaded and installed on the FPGA. While FPGAs inherently support power-on reconfiguration—that is, reconfiguring the hardware by changing the data selection unit configuration and logic resources on the FPGA without powering down, thereby supporting new or modified protocols—it is difficult to effectively control the workload and time cost required to build new verification platforms using the reprogrammable nature of FPGAs. This is because FPGAs, and similar programmable hardware, achieve hardware reconfiguration by providing a large amount of redundant logic resources and data selection units. The architecture of FPGAs may limit the time efficiency and resource utilization of supporting new or modified protocols through their reprogrammability.User-submitted customization requests, such as changing data bit width or clock frequency, adding or removing support for specific protocols or versions, or increasing or decreasing power consumption, can lead to varying FPGA adaptation costs. This is because FPGAs are designed to meet a wider range of integrated circuit design needs, and their architecture itself becomes a constraint on efficiency and time savings. Furthermore, even if new interfacing test requirements are supported through hardware reprogramming of the FPGA, the chip IP verification phase requires running numerous test cases, some of which may run continuously for a day or even weeks. The FPGA's architecture and reprogrammability limit its ability to provide end-to-end optimized design, and it's difficult to optimize designs for a large number of highly similar or long-duration test cases to shorten verification time. This means that existing solutions for DUT verification, which rely on programmable hardware such as FPGAs or similar configurable integrated circuits, struggle to meet the complex and ever-changing verification needs of chip IPs across different R&D stages, communication protocols and interface standards, interfacing testing requirements, and customization needs. They also hinder verification efficiency and time reduction, making it difficult to support rapid response and cost reduction. Furthermore, FPGA-based verification platforms are limited by the static timing constraints of FPGA synthesizable architectures, with the supported clock frequency restricted by rigid physical constraints. For example, the synthesizable clock frequency typically only supports a maximum of 500 MHz, failing to meet the evolving and upgrading requirements of different communication protocols and interface standards, such as not supporting high-speed interface testing like PCIe 5.0 and PCIe 6.0, USB 4.0 and UCIe 2.0.

[0004] To this end, this application provides a management method, electronic device, medium, verification method, and platform for a verification platform, which can be applied to the verification needs of subsystems under various communication protocols, such as PCIe, SerDes, TCP / IP, SATA, HDMI, USB, and UCIe protocols. It not only provides customized service support for specific interfacing testing needs, but also effectively reduces the complexity and workload of maintenance during the verification phase of the entire chip development lifecycle, from early to late stages. Furthermore, it improves verification efficiency and shortens verification time, supports rapid response, and reduces costs, addressing the complex and ever-changing verification needs of chip IPs at different R&D stages, with different communication protocols and interface standards, different interfacing testing requirements, and different customization needs. Summary of the Invention

[0005] Firstly, this application provides a management method for a verification platform. The management method includes: determining test requirements associated with the design under test (DUT), wherein the test requirements at least include the data bit width, interface standard, clock mode, and operating mode of the DUT's external interface, and the communication protocol associated with the DUT defines the communication specifications between the DUT and its external environment; and based on the test requirements, setting configurable parameters for each of multiple functional modules of the verification platform, and setting verification rules included in the layered verifier of the verification platform, thereby achieving adaptation of the verification platform to the DUT, wherein the multiple functional modules correspond one-to-one with the layered protocols defined by the communication protocol, the configurable parameters for each of the multiple functional modules are determined based on parameter tables for various selection combinations, and the various selection combinations are all possible combinations between the controller selection and the physical layer subsystem selection determined based on the associated version of the communication protocol, and the verification platform is used to perform simulation verification for the DUT.

[0006] Through the first aspect of this application, multiple functional modules designed with parameterization and polymorphism are used to address different versions and customization needs. By setting configurable parameters for each functional module and defining the verification rules included in the layered verifier, incremental coverage of newly added features is supported. Furthermore, the selection of controllers and physical layer subsystems customized through parameters can be combined. This not only provides customized services for specific interfacing testing needs but also effectively reduces the complexity and workload of maintenance during the verification phase of the entire chip development lifecycle, from early to late stages. Moreover, it improves verification efficiency and shortens verification time, supporting rapid response and cost reduction, in response to the complex and ever-changing verification needs of chip IPs at different R&D stages, with different communication protocols and interface standards, different interfacing testing requirements, and different customization needs.

[0007] In one possible implementation of the first aspect of this application, the design under test is a physical layer intellectual property core.

[0008] In one possible implementation of the first aspect of this application, the communication protocol is the PCIe protocol, the layered protocol includes a transaction layer, a data link layer and a physical layer, and the plurality of functional modules include a transaction layer functional module corresponding to the transaction layer, a data link layer functional module corresponding to the data link layer and a physical layer functional module corresponding to the physical layer.

[0009] In one possible implementation of the first aspect of this application, the communication protocol is a four-layer network protocol, which includes a transport layer, a network layer, a data link layer, and a physical layer. The plurality of functional modules include a transport layer functional module corresponding to the transport layer, a network layer functional module corresponding to the network layer, a data link layer functional module corresponding to the data link layer, and a physical layer functional module corresponding to the physical layer.

[0010] In one possible implementation of the first aspect of this application, the associated versions of the communication protocol include PCIe 1.0, PCIe 2.0, PCIe 3.0, PCIe 4.0, and PCIe 5.0.

[0011] In one possible implementation of the first aspect of this application, the configurable parameters of each of the plurality of functional modules include a first parameter, wherein the first parameter is used to set whether to perform independent maintenance of the data path and the control path, respectively. When the communication protocol is PCIe 3.0, the first parameter is set to not perform independent maintenance of the data path and the control path, respectively, and when the communication protocol is PCIe 5.0, the first parameter is set to perform independent maintenance of the data path and the control path, respectively.

[0012] In one possible implementation of the first aspect of this application, the configurable parameters of each of the plurality of functional modules include a second parameter of the transaction layer functional module, wherein the second parameter is used to set the number of bits in the tag field of the transaction layer identifier. When the communication protocol is PCIe 3.0, the second parameter is set to 8 bits, and when the communication protocol is PCIe 5.0, the second parameter is set to 12 bits.

[0013] In one possible implementation of the first aspect of this application, the configurable parameters of each of the plurality of functional modules include a third parameter and a fourth parameter of the data link layer functional module, wherein the third parameter is used to set the size of the base address register address space, and the fourth parameter is used to set whether to increase the receiving-side channel margin. When the communication protocol is PCIe 3.0, the third parameter is set to 64 bits, and when the communication protocol is PCIe 5.0, the fourth parameter is set to increase the receiving-side channel margin.

[0014] In one possible implementation of the first aspect of this application, the configurable parameters of each of the plurality of functional modules include a fifth parameter, a sixth parameter, a seventh parameter, and an eighth parameter of the physical layer functional module, wherein the fifth parameter is used to set the PIPE standard supported by the physical layer functional module, the sixth parameter is used to set the data bit width supported by the physical layer functional module, the seventh parameter is used to set the PIPE interface mode supported by the physical layer functional module, and the eighth parameter is used to set the clock mode supported by the physical layer functional module.

[0015] In one possible implementation of the first aspect of this application, when the communication protocol is PCIe 3.0, the fifth parameter is set to support PIPE 3.0 and higher-order versions of the PIPE 3.0 standard, the sixth parameter is set to support 16-bit or 32-bit data width, the seventh parameter is set to support native PIPE interface mode, and the eighth parameter is set to support clock physical layer output clock mode.

[0016] In one possible implementation of the first aspect of this application, when the communication protocol is PCIe 5.0, the fifth parameter is set to support PIPE 5.0 and PIPE 6.0, as well as higher-order versions of PIPE 5.0 and PIPE 6.0 standards; the sixth parameter is set to support 16-bit, 32-bit, 20-bit, 40-bit, or 64-bit data bit widths; the seventh parameter is set to support native PIPE interface mode and Serdes PIPE interface mode; and the eighth parameter is set to support physical layer output clock mode and physical layer input clock mode.

[0017] In one possible implementation of the first aspect of this application, the multiple selection combinations include a physical layer subsystem that adopts the Serdes PIPE interface mode and supports PIPE 5.0 and higher-order versions of the PIPE 5.0 standard, a physical layer subsystem that adopts the native PIPE interface mode and supports PIPE 4.0 and higher-order versions of the PIPE 4.0 standard and a clock physical layer input clock mode, and a physical layer subsystem that adopts the native PIPE interface mode and supports the PIPE 4.3 standard and a clock physical layer output clock mode.

[0018] In one possible implementation of the first aspect of this application, the layered verifier is used to verify the transaction layer, the data link layer and the physical layer respectively, and the layered verifier includes verification rules corresponding to register transfer level code verification in the front-end design stage, netlist verification in the back-end design stage and silicon verification before delivery.

[0019] In one possible implementation of the first aspect of this application, the management method further includes, when the test requirements include performance under extreme application environments, performing incremental modifications to the verification rules included in the hierarchical verifier to add verification rules corresponding to process voltage and temperature conditions, and modifying the configurable parameters of the transaction layer functional module to simulate variables sensitive to the process voltage and temperature conditions.

[0020] In one possible implementation of the first aspect of this application, the management method further includes, when the test requirements include system-level testing, modifying the configurable parameters of the transaction layer functional module to simulate the interruption mechanism, link failure, and link blockage of the host computer.

[0021] In one possible implementation of the first aspect of this application, the verification platform includes a verification environment and a verification sub-environment based on the transaction layer functional module, wherein the verification environment is used for the initialization configuration of the verification platform, and the verification sub-environment is used for on-chip system-level compatibility.

[0022] In one possible implementation of the first aspect of this application, the verification platform further includes a design under test integrator based on the data link layer functional module and the physical layer functional module, wherein the design under test integrator includes a parameterized controller module, a clock reset module supporting multiple clock modes and multiple reset operations, a connector module supporting multiple interface bit widths and frequency conversions, and a parameterized physical layer region integrator.

[0023] In one possible implementation of the first aspect of this application, at least before performing the adaptation of the verification platform for the design under test, the verification platform has completed a parametric design based on the associated version of the communication protocol to be compatible with the multiple selection combinations.

[0024] In one possible implementation of the first aspect of this application, the verification platform has completed a randomized design to support multi-scenario combination testing and functional coverage testing, at least before performing the adaptation of the verification platform for the design under test.

[0025] In one possible implementation of the first aspect of this application, the communication protocol is the USB protocol, the layered protocol includes a transaction layer, a data link layer and a physical layer, and the plurality of functional modules include a transaction layer functional module corresponding to the transaction layer, a data link layer functional module corresponding to the data link layer and a physical layer functional module corresponding to the physical layer.

[0026] In one possible implementation of the first aspect of this application, the associated versions of the communication protocol include USB 3.0, USB 3.1, and USB 4.0.

[0027] In one possible implementation of the first aspect of this application, the configurable parameters of each of the plurality of functional modules include a ninth parameter, wherein the ninth parameter is used to set the maximum rate supported by the data path, and when the communication protocol is USB 3.0, USB 3.1 or USB 4.0, the ninth parameter is set to 5 gigabits per second, 10 gigabits per second and 40 gigabits per second respectively.

[0028] In one possible implementation of the first aspect of this application, the configurable parameters of each of the plurality of functional modules include a tenth parameter, wherein the tenth parameter is used to set whether the data path and the control path support multiple physical links. When the communication protocol is USB 3.0 or USB 3.1, the tenth parameter is set to support only a single physical link for the data path and the control path. When the communication protocol is USB 4.0, the tenth parameter is set to support two physical links for the data path and the control path.

[0029] In one possible implementation of the first aspect of this application, the configurable parameters of each of the plurality of functional modules include an eleventh parameter of the data link layer functional module. The eleventh parameter is used to set the encoding and decoding standards and speed modes supported by the data link layer functional module. Specifically, when the communication protocol is USB 3.0, the eleventh parameter is set to support 8b / 10b encoding and decoding standards and support low-speed and medium-speed modes; when the communication protocol is USB 3.1, the eleventh parameter is set to support 128b / 132b encoding and decoding standards and support medium-speed and high-speed modes; and when the communication protocol is USB 4.0, the eleventh parameter is set to support 64b / 66b encoding and decoding standards and 128b / 132b encoding and decoding standards and support high-speed mode.

[0030] In one possible implementation of the first aspect of this application, the configurable parameters of each of the plurality of functional modules include a twelfth parameter of the physical layer functional module, wherein the twelfth parameter is used to set the maximum transmission power supported by the physical layer functional module, and when the communication protocol is USB 3.0, the twelfth parameter is set to a maximum transmission power of 5 watts supported by the physical layer functional module; when the communication protocol is USB 3.1, the twelfth parameter is set to a maximum transmission power of 100 watts supported by the physical layer functional module; and when the communication protocol is USB 4.0, the twelfth parameter is set to a maximum transmission power of 240 watts supported by the physical layer functional module.

[0031] In one possible implementation of the first aspect of this application, the configurable parameters of each of the plurality of functional modules include a thirteenth parameter of the physical layer functional module. The thirteenth parameter is used to set whether the physical layer functional module supports a Type-C interface and whether it supports a fast charging working mode. When the communication protocol is USB 3.0, the thirteenth parameter is set to indicate that the physical layer functional module does not support a Type-C interface and does not support a fast charging working mode. When the communication protocol is USB 3.1 or USB 4.0, the thirteenth parameter is set to indicate that the physical layer functional module supports a Type-C interface and supports a fast charging working mode.

[0032] In one possible implementation of the first aspect of this application, the management method further includes, when the test requirement indicates that incremental changes be made to the configurable parameters of the plurality of functional modules to introduce new features, performing incremental changes to the verification rules included in the hierarchical verifier to cover the new features.

[0033] In one possible implementation of the first aspect of this application, the management method further includes, when the test requirement instructs to perform a reduction modification on the configurable parameters of the plurality of functional modules to remove existing features, performing a reduction modification on the verification rules included in the hierarchical verifier to no longer cover the existing features.

[0034] In one possible implementation of the first aspect of this application, the management method further includes, when the test requirements include user customization requirements, performing incremental modifications to the configurable parameters of each of the plurality of functional modules and to the verification rules included in the hierarchical validator to support the user customization requirements.

[0035] In one possible implementation of the first aspect of this application, the user customization requirement is low-power fine-grained management, which involves incrementally modifying the configurable parameters of the plurality of functional modules, including adding new energy levels, adding new power consumption levels, adding new operating voltage levels, setting new data transmission rates, setting new link bit widths, setting load balancing at the data link layer, setting active switching of redundant links at the data link layer, and setting the maximum length and format of message packets at the transaction layer. Furthermore, incremental modifications are made to the verification rules included in the layered verifier to verify the incremental modifications made to the configurable parameters of the plurality of functional modules.

[0036] In one possible implementation of the first aspect of this application, the plurality of functional modules are respectively pooled into multiple callable resource pools, and the verification platform achieves full-link configurability by calling the multiple resource pools.

[0037] In one possible implementation of the first aspect of this application, the communication protocol is the UCIe protocol, the layered protocol includes a protocol layer, a chip-to-chip adapter layer and a physical layer, and the plurality of functional modules include a protocol layer functional module corresponding to the protocol layer, a chip-to-chip adapter layer functional module corresponding to the chip-to-chip adapter layer and a physical layer functional module corresponding to the physical layer.

[0038] In one possible implementation of the first aspect of this application, the associated versions of the communication protocol include UCIe 1.0, UCIe 1.1, UCIe 2.0, and UCIe 3.0.

[0039] In one possible implementation of the first aspect of this application, the configurable parameters of each of the plurality of functional modules include a fourteenth parameter, wherein the fourteenth parameter is used to set a maximum rate, and when the associated version of the communication protocol is UCIe 1.1, the fourteenth parameter is set to a maximum rate of 32 gigabits per second, and when the associated version of the communication protocol is UCIe 3.0, the fourteenth parameter is set to a maximum rate of 64 gigabits per second.

[0040] In one possible implementation of the first aspect of this application, the configurable parameters of each of the plurality of functional modules include a fifteenth parameter, which is used to set whether the last bit of valid transmitted data needs to be retained when the data link is idle in the receiver impedance matching mode. When the associated version of the communication protocol is UCIe 1.1, the fifteenth parameter is set to retain the last bit of valid transmitted data when the data link is idle in the receiver impedance matching mode and is prohibited from flipping. When the associated version of the communication protocol is UCIe 3.0, the fifteenth parameter is set to not need to retain the last bit of valid transmitted data when the data link is idle in the receiver impedance matching mode and is allowed to maintain flipping when the transmission is idle.

[0041] In one possible implementation of the first aspect of this application, the configurable parameters of each of the plurality of functional modules include a sixteenth parameter, which is used to set whether to support the management transport protocol. When the associated version of the communication protocol is UCIe 1.1, the sixteenth parameter is set to not support the management transport protocol, and when the associated version of the communication protocol is UCIe 3.0, the sixteenth parameter is set to support the management transport protocol.

[0042] In one possible implementation of the first aspect of this application, the configurable parameters of each of the plurality of functional modules include a seventeenth parameter. The seventeenth parameter is used to set whether the UCIe physical layer clock receive path calibration module supports phase and amplitude calibration on the receiving side by adjusting the clock delay on the transmitting side when executing the clock receive path. When the associated version of the communication protocol is UCIe 1.1, the seventeenth parameter is set so that the UCIe physical layer clock receive path calibration module does not support phase and amplitude calibration on the receiving side by adjusting the clock delay on the transmitting side when executing the clock receive path. When the associated version of the communication protocol is UCIe 3.0, the seventeenth parameter is set so that the UCIe physical layer clock receive path calibration module supports phase and amplitude calibration on the receiving side by adjusting the clock delay on the transmitting side when executing the clock receive path.

[0043] In one possible implementation of the first aspect of this application, the configurable parameters of each of the plurality of functional modules include an eighteenth parameter, which is used to set whether sideband power-down is supported in low power mode. When the associated version of the communication protocol is UCIe 1.1, the eighteenth parameter is set to not support sideband power-down, and when the associated version of the communication protocol is UCIe 3.0, the eighteenth parameter is set to support both sideband power-down and sideband wake-up.

[0044] In one possible implementation of the first aspect of this application, the configurable parameters of each of the plurality of functional modules include a nineteenth parameter, which is used to set whether sideband performance mode is supported. When the associated version of the communication protocol is UCIe 1.1, the nineteenth parameter is set to not support sideband performance mode and specifies that there is a packet gap between consecutively sent sideband data packets. When the associated version of the communication protocol is UCIe 3.0, the nineteenth parameter is set to support sideband performance mode.

[0045] Secondly, 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.

[0046] Thirdly, 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.

[0047] Fourthly, 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.

[0048] Fifthly, this application provides a verification method. The verification method includes: determining the test requirements associated with the design under test (DUT), wherein the test requirements include at least the data bit width, interface standard, clock mode, and working mode of the external interface of the DUT, and the communication protocol associated with the DUT defines the communication specifications between the DUT and its external environment; based on the test requirements, setting the configurable parameters of multiple functional modules of the verification platform, and setting the verification rules included in the layered verifier of the verification platform, thereby achieving the adaptation of the verification platform to the DUT, wherein the multiple functional modules correspond one-to-one with the layered protocol defined by the communication protocol, the configurable parameters of each of the multiple functional modules are determined based on parameter tables of various selection combinations, the various selection combinations are all possible combinations between the controller selection and the physical layer subsystem selection determined based on the associated version of the communication protocol, and the multiple functional modules are respectively pooled as multiple callable resource pools; and using the verification platform, by calling the multiple resource pools, simulating a configurable full-link interaction with the DUT as the external environment of the DUT, thereby performing simulation verification of the DUT.

[0049] Through the fifth aspect of this application, multiple functional modules designed with parameterization and polymorphism are used to address different versions and customization needs. By setting configurable parameters for each functional module and defining the verification rules included in the layered verifier, incremental coverage of newly added features is supported. Furthermore, the selection and combination of controller and physical layer subsystems customized through parameters can be achieved. This not only provides customized services for specific interfacing testing needs but also effectively reduces the complexity and workload of maintenance during the verification phase of the entire chip development lifecycle, from early to late stages. Moreover, it improves verification efficiency and shortens verification time, supporting rapid response and cost reduction, in response to the complex and ever-changing verification needs of chip IPs at different R&D stages, with different communication protocols and interface standards, different interfacing testing requirements, and different customization needs.

[0050] Sixthly, this application provides a verification platform. The verification platform includes: a verification environment, wherein the verification environment is used for the initial configuration of the verification platform; a verification sub-environment, wherein the verification sub-environment is used for on-chip system-level compatibility; and a design-under-test (DUT) integrator. The verification environment, the verification sub-environment, and the DUT integrator are based on multiple functional modules, each corresponding one-to-one with a layered protocol defined by a communication protocol. The configurable parameters of each functional module are determined based on parameter tables for various selection combinations. These various selection combinations are all possible combinations between the controller selection and the physical layer subsystem selection, determined based on the associated version of the communication protocol. The communication protocol defines the communication specifications between the DUT and its external environment. The test requirements for the DUT include at least the data bit width, interface standard, clock mode, and operating mode of the DUT's external interface. The configurable parameters of each functional module and the verification rules included in the layered verifier of the verification platform are all set based on the test requirements. The verification platform is used to perform simulation verification for the DUT.

[0051] Through the sixth aspect of this application, multiple functional modules designed with parameterization and polymorphism are used to address different versions and customization needs. By setting configurable parameters for each functional module and defining the verification rules included in the layered verifier, incremental coverage of newly added features is supported. Furthermore, the selection of controllers and physical layer subsystems customized through parameters can be combined. This not only provides customized services for specific interfacing testing needs but also effectively reduces the complexity and workload of maintenance during the verification phase of the entire chip development lifecycle, from early to late stages. Moreover, it improves verification efficiency and shortens verification time, supporting rapid response and cost reduction, in response to the complex and ever-changing verification needs of chip IPs at different R&D stages, with different communication protocols and interface standards, different interfacing testing requirements, and different customization needs. Attached Figure Description

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

[0053] Figure 1 A flowchart illustrating a management method for a verification platform provided in an embodiment of this application;

[0054] Figure 2A schematic diagram of the communication protocol and functional modules of the first embodiment provided in this application;

[0055] Figure 3 A schematic diagram of the communication protocol and functional modules for a second embodiment provided in this application;

[0056] Figure 4 A schematic diagram of the communication protocol and functional modules of the third embodiment provided in this application;

[0057] Figure 5 A schematic diagram of the communication protocol and functional modules of the fourth embodiment provided in this application;

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

[0059] Figure 7 A schematic diagram of a verification platform provided in an embodiment of this application;

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

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

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

[0063] Figure 1 This is a flowchart illustrating a management method for a verification platform provided in an embodiment of this application. Figure 1 As shown, the management method includes the following steps.

[0064] Step S101: Determine the test requirements associated with the design under test, wherein the test requirements include at least the data bit width, interface standard, clock mode and working mode of the external interface of the design under test, and the communication protocol associated with the design under test defines the communication specifications between the design under test and its external environment.

[0065] Step S103: Based on the test requirements, set the configurable parameters of each of the multiple functional modules of the verification platform, and set the verification rules included in the layered verifier of the verification platform, thereby realizing the adaptation of the verification platform to the design under test. The multiple functional modules correspond one-to-one with the layered protocols defined by the communication protocol. The configurable parameters of each of the multiple functional modules are determined based on the parameter tables of various selection combinations. The various selection combinations are all possible combinations between the selection of the controller and the selection of the physical layer subsystem determined based on the associated version of the communication protocol. The verification platform is used to perform simulation verification for the design under test.

[0066] Figure 1 The verification platform management method shown is used to build a verification platform to deliver the intellectual property (IP) core of chip design. It supports verification throughout the entire chip development lifecycle and can meet the complex and ever-changing verification needs of chip IP at different R&D stages, with different communication protocols and interface standards, different interfacing test requirements, and different customization needs. Supported communication protocols include, but are not limited to, Peripheral Component Interconnect Express (PCIe), Serializer / Deserializer (Serdes) protocol, Transmission Control Protocol / Internet Protocol (TCP / IP), Serial Advanced Technology Attachment (SATA) protocol, High Definition Multimedia Interface (HDMI) protocol, Universal Serial Bus (USB) protocol, and Universal Chip Interconnect (UCH) protocol. Express (UCIe), and other technologies can be applied to fields such as artificial intelligence, data centers, connected vehicles, the Internet of Things, and androids. They help meet the high-quality requirements of standardized protocol verification resulting from the continuous upgrading and evolution of various communication protocols and interface standards. Furthermore, in addition to providing customized services to meet specific interfacing testing needs, they offer end-to-end optimized design to improve verification efficiency and shorten verification time, supporting rapid response and cost reduction.

[0067] See Figure 1In step S101, the test requirements associated with the Design Under Test (DUT) are determined. These test requirements include at least the data bit width, interface standard, clock mode, and operating mode of the DUT's external interface. Furthermore, the communication protocol associated with the DUT defines the communication specifications between the DUT and its external environment. Here, the Design Under Test (DUT) refers to the chip IP used in chip development. The DUT can refer to a specific IP, such as a physical layer (PHY) IP or a physical layer subsystem, also known as a physical layer intellectual property core. Taking the PCIe protocol as an example, the DUT is a physical layer intellectual property core under the PCIe protocol that needs to be verified. The PCIe controller (CTRL) implements efficient data transmission under the PCIe protocol specification. Therefore, for the verification of the physical layer intellectual property core (PCIe PHY IP) under the PCIe protocol, interfacing tests must be performed between the PCIe controller and the subsystem on the PCIe physical layer. Specifically, interfacing tests need to be conducted according to requirements such as interface width (i.e., data width of the external interface), operating mode, physical layer interface specifications, and the selected combinations between the controller and the physical layer subsystem. With the development of the PCIe protocol, from version 1.0 to 5.0 to 6.0, a wealth of physical layer IP has been accumulated. Therefore, there may be diverse physical layer subsystems under the PCIe protocol. Consequently, the verification phase may need to accommodate multiple data widths, interface specifications, clock modes, and operating modes. This means that building a verification platform for subsystem interfacing tests for each selection combination would result in a large workload and significant time consumption. For example, the first combination is a PCIe controller and a PCIe physical layer subsystem, using SerDes mode and PCIe Physical Layer Interface for the PCIe (PIPE) version 5.2, specifically the SerDes PIPE interface mode of PIPE 5.2. The second combination is a PCIe controller and a PCIe physical layer subsystem, using the native PIPE interface mode of PIPE 4.4.1 and the physical layer input clock mode (PCLK AS PHY INPUT). The third combination is a PCIe controller and a PCIe physical layer subsystem, using the native PIPE interface mode of PIPE 4.3 and the physical layer output clock mode (PCLK AS PHY OUTPUT). These three combinations are merely examples to illustrate the diverse requirements for interfacing and testing between a PCIe controller and a PCIe physical layer subsystem, or more specifically, the physical layer intellectual property core under the PCIe protocol.Here, different interface specifications and clock modes may involve modifications to the entire chain, from the host computer to protocol parsing and input / output ports. They also involve top-level integration verification of the design under test (DUT), and the focus may differ depending on the stage of the chip development cycle. For example, the front-end design stage may emphasize Register Transfer Level (RTL) code verification, the back-end design stage may emphasize netlist verification, and the packaging stage may emphasize sign-off verification. Therefore, if traditional manual methods are used or programmable hardware such as FPGAs or similar configurable integrated circuits are relied upon, only a single combination of PCIe controller and PCIe physical layer subsystem can be integrated each time, and top-level integration verification of the DUT must be performed according to the corresponding operating mode, PIPE version, and clock mode. This increases the complexity and workload of the verification phase, and the complexity and workload of the verification phase will increase synchronously with the increase in the number of selection combinations, thereby increasing costs and extending the verification cycle. As the integration and scale of chip IPs increase during chip development, and the richness and diversity of the surrounding environments that chips need to adapt to in practical applications, the types and number of combinations of physical layer intellectual property cores under the PCIe protocol will also increase significantly. Furthermore, FPGA-based verification platforms are limited by the static timing constraints of FPGA synthesizable capabilities, and the supported clock frequency is restricted by rigid physical constraints. For example, the synthesizable clock frequency typically only supports a maximum of 500 MHz, which cannot meet the evolution and upgrade of the highest transmission rates of different communication protocols and interface standards, such as not supporting high-speed interface testing like PCIe 5.0 and PCIe 6.0, USB 4.0 and UCIe 2.0. Therefore, in step S101, the test requirements associated with the design under test are determined, including at least the data bit width, interface standard, clock mode, and operating mode of the external interface of the design under test. Thus, considering that the communication protocol associated with the design under test defines the communication specifications between the design under test and its external environment, the test requirements determined in step S101 are used to combine with subsequent processes, thereby providing a subsystem verification platform, which is equivalent to a selection combination of a PCIe controller and a PCIe physical layer subsystem that is versatile and can be customized by parameters.

[0068] Continue reading Figure 1In step S103, based on the test requirements, configurable parameters for each of the multiple functional modules of the verification platform are set, as well as verification rules included in the layered verifier of the verification platform, thereby achieving the adaptation of the verification platform to the design under test. The multiple functional modules correspond one-to-one with the layered protocols defined by the communication protocol. The configurable parameters for each of the multiple functional modules are determined based on parameter tables for various selection combinations. The various selection combinations are all possible combinations between the controller selection and the physical layer subsystem selection, determined based on the associated version of the communication protocol. The verification platform is used to perform simulation verification for the design under test. In this way, various potential requirements in subsystem docking tests, including various possible selection combinations, are transformed into parametric and polymorphic designs. This allows different subsystem docking test requirements to be met by configuring parameters and states. Furthermore, through modular and generalized design, a general subsystem verification platform is used to carry out parameter configuration and state setting operations. Utilizing reusable core modules and limited components, users can flexibly achieve different selection combinations by configuring parameters through the interface. Taking the PCIe protocol as an example, the subsystem verification platform is equivalent to a versatile and customizable combination of a PCIe controller and a PCIe physical layer subsystem. The chip design to be verified, or DUT, refers to the IP on the PCIe physical layer, such as a customer-developed PCIe physical layer subsystem. The subsystem verification platform can provide a complete interface environment from the transaction layer to the data link layer and then to the physical layer based on customer needs, thereby simulating the operating environment of the customer's IP in real-world applications. Furthermore, the subsystem verification platform can provide the core functions of the PCIe controller, such as protocol parsing and encapsulation, converting upper-layer data into data packets conforming to the PCIe protocol or vice versa; data transmission control, managing data sending, receiving, flow control, and error handling; link management initialization and maintenance of the PCIe link connection status (such as rate and number of channels); and resource allocation coordination of bandwidth allocation and transaction priorities among multiple devices.

[0069] Continue reading Figure 1 , Figure 1The management method of the verification platform shown has the following improvements: 1) Based on the layered structure of communication protocols, it provides corresponding functional modules, such as three functional modules for the PCIe protocol: transaction layer, data link layer, and physical layer, as well as corresponding layered rule verifiers. 2) The functional modules are designed to be generalized and parameterized, adaptable to different versions of the PCIe protocol, different communication protocols, and different application scenarios and user needs. For example, data bit width, data transmission rate, and clock frequency can be set. Resource pooling technology is used to make each functional module into a resource pool that is easy to call, providing full-chain configurability and customizability. 3) It can meet customer customization needs, such as providing corresponding modifications to the transaction layer, data link layer, and physical layer for low-power designs, and adding, deleting, and replacing verification rules in the layered rule verifier. 4) It can meet the verification needs of extreme application environments, such as adding process voltage temperature (PVT) factors as verification rules to meet the aging test requirements under high and low temperature conditions. 5) It can provide corresponding verification environments for different physical layer IPs to be tested. Users can configure parameterized functional modules and set verification rules, thereby realizing different combinations between the PCIe controller and the PCIe physical layer subsystem. 6) It supports RTL code verification in the front-end design stage, netlist verification in the back-end design stage, and delivery verification in the packaging stage. Thus, Figure 1 The management method of the verification platform shown is used to build a verification platform to deliver the intellectual property core of chip design. It supports the verification stage throughout the entire life cycle of chip development and can meet the complex and ever-changing chip IP verification needs of different R&D stages, different communication protocols and interface standards, different interfacing test requirements, and different customization requirements. It realizes a normalized subsystem verification platform solution that supports the combination of various types of PCIe controllers and PCIe physical layer subsystems.

[0070] Continue reading Figure 1The verification platform comprises multiple functional modules, each corresponding one-to-one with the layered protocols defined by the communication protocol. Therefore, based on the layered structure of the communication protocol, corresponding functional modules are provided, such as transaction layer, data link layer, and physical layer modules for the PCIe protocol, along with corresponding layered rule validators, thus implementing a pooled design. This facilitates decoupling, allowing each functional module to focus solely on its own resource optimization without considering its impact on other modules. Furthermore, it facilitates efficient resource allocation; for example, resources can be scheduled to simultaneously verify both PCIe 3.0 and PCIe 6.0, aligning with the trend of heterogeneous chip design. A chip's physical layer can integrate subsystems corresponding to different protocol standards, such as chips employing different architectures. Providing multiple functional modules based on the layered protocols defined by the aforementioned communication protocol naturally aligns with the message parsing function of the protocol stack, the message packing function of the message forwarding engine, and the control mechanism of the host computer. Therefore, it facilitates optimized design of the entire chain from the host computer to the protocol engine and then to the input / output ports. For example, it allows for optimized design based on the characteristics of the PCIe layered protocol, i.e., the characteristics of a three-layer protocol. Thus, Figure 1The management method of the verification platform shown can adapt not only to standardized protocol IPs, such as the physical layer IP design of standardized PCIe, but also to customer customizations, such as IP designs that offload some protocol processing functions to the physical layer. Furthermore, it can be used to verify the performance of the DUT under different extreme application environments; for example, PVT factors can be taken into account as new verification rules. Because the three functional modules—transaction layer, data link layer, and physical layer—are designed using parameterization and polymorphism to simulate the data and control paths of the three-layer protocol of PCIe, new verification rules can be added, including generating new test signal stimuli to simulate sensitive variables such as PVT. In addition, the transaction layer functional module can be used to simulate the interrupt mechanism of the host computer, as well as system-level tests such as link failures and link blocking. The following explanation uses a customer's customized requirements, including power consumption requirements, as an example. In chip design, three indicators need to be considered: power consumption, performance, and area. These are key elements for evaluating and optimizing semiconductor designs, referred to as PPA indicators, which together determine the efficiency, functionality, and cost-effectiveness of integrated circuits. For example, customized customer requirements may place high demands on the power consumption of the PPA, such as requiring low-power address management. Assume the standard protocol specifies four power levels: P0, P0s, P1, and P2, leaving room for user customization. Users can add low-power examples, such as energy levels or levels, for example, adding user-defined power sub-states, such as setting different energy levels like P1.1, P1.2, and P2.1, thus providing finer-grained low-power sub-states for low-power management. Furthermore, setting low-power sub-states may involve data transfer rates and operating voltages (e.g., core operating voltages for different levels like 0.75V, 0.9V, 1.2V, and 1.8V), requiring corresponding physical layer modifications. This can be achieved through physical layer functional modules and layered verifiers. Furthermore, setting up low-power sub-states may involve adjusting the link width, actively switching to redundant links, and configuring load balancing (which involves changes to the data link layer). It may also involve changing the maximum packet length and packet format (which involves changes to the transaction layer). Therefore, this can be achieved through data link layer functional modules, transaction layer functional modules, and a hierarchical validator. Thus, the aforementioned low-power optimization design can ultimately be reflected in modifications to these three functional modules and the rules of the hierarchical validator. This means that customized requirements can be added and removed at any time during the verification process, which improves verification efficiency.

[0071] Continue reading Figure 1 Furthermore, based on the layered protocol defined by the communication protocol, multiple functional modules are determined. Based on the test requirements, configurable parameters for each of the multiple functional modules of the verification platform are set, and verification rules included in the layered verifier of the verification platform are set, thereby achieving the adaptation of the verification platform for the design under test. Therefore, as long as the communication protocol associated with the design under test remains unchanged, for example, remaining a PCIe protocol, the verification platform can be easily adapted for the design under test by setting configurable parameters and verification rules. This allows for support for different versions or modifications to existing communication protocols, as well as various customized operations, such as changing the data bit width or clock frequency, adding or removing support for specific versions, or increasing or decreasing power consumption. Additionally, for different communication protocols, such as PCIe, SerDes, TCP / IP, SATA, HDMI, USB, and UCIe, refer to... Figure 1 The management method of the verification platform shown provides a set of multiple functional modules for each communication protocol. In other words, Figure 1 The management method of the verification platform shown can be easily extended to application scenarios with multiple communication protocols. For each communication protocol, it provides multiple corresponding functional modules based on the layered protocol defined by that protocol, and determines the configurable parameters of each functional module based on the parameter tables of various selection combinations. Furthermore, the various selection combinations are all possible combinations between the controller selection and the physical layer subsystem selection, determined based on the associated version of the communication protocol. The following detailed explanation, in conjunction with the accompanying drawings and specific embodiments, illustrates how to provide communication protocols and functional modules for various implementations. Additionally, FPGA-dependent verification platforms are limited by the static timing constraints of FPGA synthesizable capabilities, and the supported operating clock frequency is restricted by rigid physical constraints. For example, the synthesizable clock frequency typically only supports a maximum of 500 MHz, which cannot meet the evolution and upgrade of the highest transmission rates of different communication protocols and interface standards, such as not supporting high-speed interface testing such as PCIe 5.0 and PCIe 6.0, USB 4.0 and UCIe 2.0. Figure 1 The management method of the verification platform shown is different from the technical solution that relies on FPGA. It is not subject to the static timing constraints of FPGA synthesizable, so it can support a wider frequency range. This is conducive to meeting the evolution and upgrade requirements of the highest transmission rate of different communication protocols and interface standards. It can also support various high-speed interface tests, such as PCIe 5.0 and PCIe 6.0, as well as USB 4.0 and UCIe 2.0.

[0072] See Figure 1 and Figure 2 , Figure 2 This is a schematic diagram of the communication protocol and functional modules according to the first embodiment of this application. Figure 2 As shown, the communication protocol is PCIe protocol A200, and the layered protocol includes a transaction layer A201, a data link layer A203, and a physical layer A205. The multiple functional modules include a transaction layer functional module A211 corresponding to the transaction layer A201, a data link layer functional module A213 corresponding to the data link layer A203, and a physical layer functional module A215 corresponding to the physical layer A205. Thus, for application scenarios where the communication protocol is PCIe protocol A200, multiple functional modules are provided based on the layered protocol defined by this communication protocol. The configurable parameters of each functional module are determined based on parameter tables for various selection combinations. Furthermore, the various selection combinations represent all possible combinations between the controller selection and the physical layer subsystem selection, determined based on the associated version of this communication protocol. As long as the communication protocol remains PCIe protocol A200, different versions can be supported, or existing versions can be customized. Version rollback and upgrades are also easily performed. This is because, while the communication protocol remains unchanged, different versions of the same communication protocol may modify interface specifications, data bit width, and clock mode, but will not alter the structure of the layered protocol defined by that communication protocol. Therefore, by providing multiple functional modules that correspond one-to-one with the layered protocol defined by the communication protocol, the fixed structural characteristics are grasped during the continuous upgrade and evolution of the same communication protocol. This allows for the combination of parameterized and polymorphic design. By setting configurable parameters for each functional module, the data bit width, interface standard, clock mode, and working mode of the external interface of the design under test can be adapted to the specific requirements of the test. Incremental coverage can be achieved by setting the verification rules included in the layered verifier of the verification platform, and the selection combination between the controller selection and the physical layer subsystem selection limited by the interface test requirements can be adapted. Tables 1 and 2 below illustrate the differences between different versions of the communication protocol and how the verification platform can be adapted to the design under test by setting configurable parameters and verification rules.

[0073] Table 1

[0074]

[0075] Table 2 is below:

[0076] Table 2

[0077]

[0078] Referring to Tables 1 and 2, taking PCIe 3.0 and PCIe 5.0 as examples, it can be seen that through parameterized and polymorphic design of multiple functional modules, facing different versions and customized needs, by setting the configurable parameters of each functional module and the verification rules included in the layered validator, it supports incremental coverage of newly added features and supports the selection combination between controller selection and physical layer subsystem selection customized through parameters. For example, the layered validator can verify the transaction layer, data link layer, and physical layer separately, and provide corresponding verification rules from front-end design to back-end design and pre-shipment testing. Furthermore, the layered validator can incrementally cover the new features of PCIe 3.0, such as the newly added extended tag field and extended base address register addressing space, and can also support PIPE 3.0 and higher-order versions of the PIPE 3.0 standard, as well as corresponding data bit widths and interface modes. Furthermore, the tiered verifier can incrementally cover the new features of PCIe 5.0, such as the separation of data and control paths, the expanded extended tag field, and new data bit widths, interface modes, and clock modes. This allows for verification throughout the entire chip development lifecycle, meeting the complex and ever-changing verification needs of chip IPs at different R&D stages, with varying interfacing testing requirements and customization needs.

[0079] See Figure 1 and Figure 3 , Figure 3 This is a schematic diagram of the communication protocol and functional modules according to a second embodiment provided in this application. (See attached diagram.) Figure 3As shown, the communication protocol is a four-layer network protocol B300, which includes a transport layer B301, a network layer B303, a data link layer B305, and a physical layer B307. The multiple functional modules include a transport layer functional module B311 corresponding to the transport layer B301, a network layer functional module B313 corresponding to the network layer B303, a data link layer functional module B315 corresponding to the data link layer B305, and a physical layer functional module B317 corresponding to the physical layer B307. Thus, for application scenarios where the communication protocol is a four-layer network protocol B300, multiple functional modules are provided based on the layered protocol defined by this communication protocol. The configurable parameters of each functional module are determined based on parameter tables for various selection combinations. Furthermore, the various selection combinations represent all possible combinations between the controller selection and the physical layer subsystem selection, determined based on the associated version of this communication protocol. As long as the communication protocol remains the four-layer network protocol B300, it can support different versions or customize existing versions, and facilitate version rollback and upgrades. This is because, while different versions of the same communication protocol may modify interface specifications, data bit width, and clock mode, the structure of the layered protocol defined by the communication protocol will not change. Therefore, by providing multiple functional modules that correspond one-to-one with the layered protocol defined by the communication protocol, the fixed structural characteristics are grasped during the continuous upgrade and evolution of the same communication protocol. This allows for the combination of parameterized and polymorphic design. By setting configurable parameters for each functional module, the data bit width, interface standard, clock mode, and working mode of the external interface of the design under test can be adapted to the specific requirements of the test. Incremental coverage can be achieved by setting the verification rules included in the layered verifier of the verification platform, and the selection combination between the controller selection and the physical layer subsystem selection limited by the interface test requirements can be adapted. In some embodiments, the exemplary four-layer network protocol B300 may be a Transmission Control Protocol / Internet Protocol (TCP / IP).

[0080] See Figure 1 and Figure 4 , Figure 4 This is a schematic diagram of the communication protocol and functional modules according to a third embodiment of this application. Figure 4As shown, the communication protocol is USB protocol C400, and the layered protocol includes a transaction layer C401, a data link layer C403, and a physical layer C405. The multiple functional modules include a transaction layer functional module C411 corresponding to the transaction layer C401, a data link layer functional module C413 corresponding to the data link layer C403, and a physical layer functional module C415 corresponding to the physical layer C405. Thus, for application scenarios where the communication protocol is USB protocol C400, multiple functional modules are provided based on the layered protocol defined by this communication protocol. The configurable parameters of each functional module are determined based on parameter tables for various selection combinations. Furthermore, the various selection combinations represent all possible combinations between the controller selection and the physical layer subsystem selection, determined based on the associated version of this communication protocol. As long as the communication protocol remains USB protocol C400, different versions can be supported, or existing versions can be customized. Version rollback and upgrades are also easily performed. This is because, while the communication protocol remains unchanged, different versions of the same communication protocol may modify interface specifications, data bit width, and clock mode, but will not alter the structure of the layered protocol defined by that communication protocol. Therefore, by providing multiple functional modules that correspond one-to-one with the layered protocol defined by the communication protocol, the fixed structural characteristics are grasped during the continuous upgrade and evolution of the same communication protocol. This allows for the combination of parameterized and polymorphic design. By setting configurable parameters for each functional module, the data bit width, interface standard, clock mode, and working mode of the external interface of the design under test can be adapted to the specific requirements of the test. Incremental coverage can be achieved by setting the verification rules included in the layered verifier of the verification platform, and the selection combination between the controller selection and the physical layer subsystem selection limited by the interface test requirements can be adapted. Tables 3 and 4 below illustrate the differences between different versions of the communication protocol and how the verification platform can be adapted to the design under test by setting configurable parameters and verification rules.

[0081] Table 3

[0082]

[0083] Table 4 is below:

[0084] Table 4

[0085]

[0086] Referring to Tables 3 and 4, taking USB 3.0, USB 3.1, and USB 4.0 as examples, it can be seen that through parameterized and polymorphically designed multiple functional modules, facing different versions and customization requirements, by setting the configurable parameters of each functional module and the verification rules included in the layered verifier, it supports incremental coverage of newly added features and supports the selection combination between controller selection and physical layer subsystem selection customized through parameters. For example, the layered verifier can verify the transaction layer, data link layer, and physical layer separately, and provide corresponding verification rules from front-end design to back-end design and pre-shipment testing. Furthermore, the layered verifier can incrementally cover new features and key parameter changes between different versions of the USB protocol. In this way, it supports verification throughout the entire lifecycle of chip development, meeting the complex and ever-changing verification needs of chip IP at different R&D stages, with different interfacing testing requirements and different customization needs.

[0087] See Figure 1 and Figure 5 , Figure 5 This is a schematic diagram of the communication protocol and functional modules according to the fourth embodiment provided in this application. Figure 5As shown, the communication protocol is UCIe protocol D500, and the layered protocol includes a protocol layer D501, a chip-to-chip adapter layer D503, and a physical layer D505. The multiple functional modules include a protocol layer functional module D511 corresponding to protocol layer D501, a chip-to-chip adapter layer functional module D513 corresponding to chip-to-chip adapter layer D503, and a physical layer functional module D515 corresponding to physical layer D505. Thus, for application scenarios where the communication protocol is UCIe protocol D500, multiple functional modules are provided based on the layered protocol defined by this communication protocol. The configurable parameters of each functional module are determined based on parameter tables for various selection combinations. Furthermore, the various selection combinations represent all possible combinations between the controller selection and the physical layer subsystem selection, determined based on the associated version of this communication protocol. As long as the communication protocol remains UCIe protocol D500, different versions can be supported, or existing versions can be customized. Version rollback and upgrades are also easily performed. This is because, while the communication protocol remains unchanged, different versions of the same communication protocol may modify interface specifications, data bit width, and clock mode, but will not alter the structure of the layered protocol defined by that communication protocol. Therefore, by providing multiple functional modules that correspond one-to-one with the layered protocol defined by the communication protocol, the fixed structural characteristics are grasped during the continuous upgrade and evolution of the same communication protocol. This allows for the combination of parameterized and polymorphic design. By setting configurable parameters for each functional module, the data bit width, interface standard, clock mode, and working mode of the external interface of the design under test can be adapted to the specific requirements of the test. Incremental coverage can be achieved by setting the verification rules included in the layered verifier of the verification platform, and the selection combination between the controller selection and the physical layer subsystem selection limited by the interface test requirements can be adapted. Tables 5 and 6 below illustrate the differences between different versions of the communication protocol and how the verification platform can be adapted to the design under test by setting configurable parameters and verification rules.

[0088] Table 5

[0089]

[0090] Table 6 is below:

[0091] Table 6

[0092]

[0093] Referring to Tables 5 and 6, taking UCIe 1.1 and UCIe 3.0 as examples, it can be seen that through parameterized and polymorphic design of multiple functional modules, facing different versions and customized needs, by setting the configurable parameters of each functional module and the verification rules included in the layered verifier, it supports incremental coverage of newly added features and supports the selection combination between controller selection and physical layer subsystem selection customized through parameters. For example, the layered verifier can verify the protocol layer, chip-to-chip adapter layer, and physical layer separately, and provide corresponding verification rules from front-end design to back-end design and pre-shipment testing. Furthermore, the layered verifier can incrementally cover new features and key parameter changes between different versions of the UCIe protocol. In this way, it supports verification throughout the entire chip development lifecycle, meeting the complex and ever-changing verification needs of chip IP at different R&D stages, with different interfacing testing requirements and different customization needs.

[0094] See Figures 1 to 5 and Tables 1 to 6, Figure 1The management method of the verification platform shown can be easily extended to application scenarios of various communication protocols. For each communication protocol, it provides multiple corresponding functional modules based on the layered protocols defined by that communication protocol, and determines the configurable parameters of each functional module based on the parameter tables of various selection combinations. Furthermore, the various selection combinations are all possible combinations between the controller selection and the physical layer subsystem selection, determined based on the associated version of the communication protocol. By providing multiple functional modules that correspond one-to-one with the layered protocols defined by the communication protocol, the fixed structural characteristics are grasped during the continuous upgrade and evolution of the same communication protocol. Thus, by combining parameterized and polymorphic design, the configurable parameters of each functional module can be set to adapt to the data bit width, interface standard, clock mode, and working mode of the external interface of the design under test as specifically specified by the test requirements. Incremental coverage can also be achieved by setting the verification rules included in the layered verifier of the verification platform, and the selection combinations between the controller selection and the physical layer subsystem selection limited by the interface test requirements can be adapted. When the communication protocol is PCIe, taking PCIe 3.0 and PCIe 5.0 as examples; or when the communication protocol is USB, taking USB 3.0, USB 3.1, and USB 4.0 as examples; or when the communication protocol is UCIe, taking UCIe 1.1 and UCIe 3.0 as examples, this means that through parameterized and polymorphic design of multiple functional modules, facing different versions and customized needs, by setting the configurable parameters of each of the multiple functional modules and setting the verification rules included in the layered validator, it supports incremental coverage of newly added features, and supports the selection combination between the controller selection and the physical layer subsystem selection customized through parameters. Furthermore, unlike traditional manual methods or reliance on programmable hardware such as FPGAs or similar configurable integrated circuits (which integrate a single PCIe controller and PCIe physical layer subsystem selection combination each time, and perform top-level integration verification of the design under test according to the corresponding working mode, PIPE version, and clock mode), this approach uses modular and universal design to carry out parameter configuration and status setting operations with a general subsystem verification platform. Utilizing reusable core modules and a limited number of components, users can flexibly achieve different selection combinations by configuring parameters through the interface. For example, upgrading from PCIe 3.0 to PCIe 5.0 does not require rebuilding the entire verification platform or re-downloading configurations from the host computer. Instead, users can refer to the first to eighth parameters listed in Tables 1 and 2, that is, based on the test requirements, to set the configurable parameters of each of the multiple functional modules of the verification platform, as well as the verification rules included in the layered verifier of the verification platform, thereby achieving the adaptation of the verification platform for the design under test.Furthermore, to meet the testing needs of different communication protocols, various functional modules and configurable parameters corresponding to each communication protocol can be provided in advance. For example, configurable parameters (parameters 9 to 13) from Tables 3 and 4 can be provided for the USB protocol, and configurable parameters (parameters 14 to 19) from Tables 5 and 6 can be provided for the UCIe protocol. This allows for convenient addition or removal of functional modules (including corresponding configurable parameters) and verification rules of the layered verifier on the verification platform when support for specific communication protocols needs to be added or removed. This supports the complex and varied verification needs of chip IPs at different R&D stages, with different communication protocols and interface standards, different interfacing test requirements, and different customization requirements. Moreover, various potential requirements in subsystem interfacing tests, including various possible selection combinations, are transformed into parametric and polymorphic designs. This allows for the fulfillment of different subsystem interfacing test requirements through parameter and state configuration. Additionally, through modular and generalized design, a universal subsystem verification platform is used to handle parameter configuration and state setting operations. Utilizing reusable core modules and limited components, users can flexibly achieve different selection combinations by configuring parameters through the interface. Furthermore, to address customer-customized needs and verification requirements in extreme application environments, modifications to functional modules and the rules of the layered verifier can support the addition of user-defined power consumption sub-states for low-power management. Process corner voltage and temperature factors can also be added as verification rules to meet aging test requirements under high and low temperature conditions. Furthermore, providing multiple functional modules based on the layered protocol defined by the aforementioned communication protocol naturally aligns with the packet parsing function of the protocol stack, the packet packaging function of the packet forwarding engine, and the control mechanism of the host computer. This facilitates optimized design of the entire chain from the host computer to the protocol engine and then to the input / output ports. For example, optimizations can be made based on the characteristics of the PCIe layered protocol, i.e., the characteristics of a three-layer protocol. Utilizing resource pooling technology to create an easily accessible resource pool for each functional module provides configurable and customizable features across the entire chain. In addition to providing customized services for specific interfacing test requirements, this optimized design across the entire chain improves verification efficiency, shortens verification time, supports rapid response, and reduces costs.In this way, it can be applied to the verification needs of subsystems under various communication protocols, such as PCIe, SerDes, TCP / IP, SATA, HDMI, USB, and UCIe. It can not only provide customized service support for specific interfacing test requirements, but also effectively reduce the complexity and workload of maintenance in the verification phase of the entire chip development lifecycle from early to late stages. Furthermore, it can improve verification efficiency and shorten verification time, support rapid response and reduce costs, in the face of complex and ever-changing chip IP verification needs at different R&D stages, with different communication protocols and interface standards, different interfacing test requirements and different customization requirements.

[0095] In short, Figure 1 The management method of the verification platform shown, through multiple functional modules designed with parameterization and polymorphism, addresses different versions and customized needs. By setting configurable parameters for each functional module and defining the verification rules included in the layered verifier, it supports incremental coverage of newly added features and allows for the selection and combination of controller and physical layer subsystems customized through parameters. This not only provides customized services for specific interfacing testing needs but also effectively reduces the complexity and workload of maintenance throughout the verification phase of the entire chip development lifecycle, from early to late stages. Furthermore, it improves verification efficiency and shortens verification time, supporting rapid response and cost reduction, in response to the complex and ever-changing verification needs of chip IPs at different R&D stages, with different communication protocols and interface standards, different interfacing testing requirements, and different customization needs.

[0096] See Figure 1 In one possible implementation, the design under test (DUT) is a physical layer intellectual property core. This supports the verification of the physical layer subsystem and introduces key design features such as parameterization, modularization, and polymorphism. It can support and be compatible with different interface widths, different operating modes, and different selection combinations, supporting a series of diverse product forms. Furthermore, it can meet the interfacing testing needs of multiple subsystems with various modes, providing a universal and normalized multi-model integrated subsystem verification platform. It also possesses the advantages of specialization and customization, which helps shorten project cycles and save manpower.

[0097] See Figure 1 and Figure 2In one possible implementation, the communication protocol is the PCIe protocol, and the layered protocol includes a transaction layer, a data link layer, and a physical layer. The multiple functional modules include a transaction layer functional module corresponding to the transaction layer, a data link layer functional module corresponding to the data link layer, and a physical layer functional module corresponding to the physical layer. This enables support for various optional combinations of PCIe subsystems and a selection parameter table. For example, the first combination is a PCIe controller and a PCIe physical layer subsystem, using SerDes mode and PCIe Physical Layer Interface for the PCIe (PIPE) version 5.2, specifically the SerDes PIPE interface mode of PIPE 5.2. The second combination is a PCIe controller and a PCIe physical layer subsystem, using the native PIPE interface mode of PIPE 4.4.1 and the physical layer input clock mode (PCLK AS PHY INPUT). The third combination is a PCIe controller and a PCIe physical layer subsystem, using the native PIPE interface mode of PIPE 4.3 and the physical layer output clock mode (PCLK AS PHY OUTPUT). These three combinations are merely examples to illustrate the diverse requirements for interfacing and testing between a PCIe controller and a PCIe physical layer subsystem, or more specifically, the physical layer intellectual property core under the PCIe protocol.

[0098] See Figure 1 and Figure 3 In one possible implementation, the communication protocol is a four-layer network protocol, comprising a transport layer, a network layer, a data link layer, and a physical layer. The multiple functional modules include transport layer functional modules corresponding to the transport layer, network layer functional modules corresponding to the network layer, data link layer functional modules corresponding to the data link layer, and physical layer functional modules corresponding to the physical layer. Thus, for application scenarios where the communication protocol is a four-layer network protocol B, multiple functional modules are provided based on the layered protocol defined by this communication protocol. Furthermore, the configurable parameters of each of these functional modules are determined based on parameter tables for various selection combinations. The various selection combinations represent all possible combinations between the controller selection and the physical layer subsystem selection, determined based on the associated version of this communication protocol.

[0099] See Figure 1 and Figure 2 In one possible implementation, the associated versions of the communication protocol include PCIe 1.0, PCIe 2.0, PCIe 3.0, PCIe 4.0, and PCIe 5.0. This achieves support for different versions of the PCIe protocol.

[0100] See Figure 1 and Figure 2In one possible implementation, the configurable parameters of each of the plurality of functional modules include a first parameter, wherein the first parameter is used to set whether to perform independent maintenance of the data path and the control path, respectively. When the communication protocol is PCIe 3.0, the first parameter is set to not perform independent maintenance of the data path and the control path, and when the communication protocol is PCIe 5.0, the first parameter is set to perform independent maintenance of the data path and the control path. In another possible implementation, the configurable parameters of each of the plurality of functional modules include a second parameter of the transaction layer functional module, wherein the second parameter is used to set the number of bits in the tag field of the transaction layer identifier. When the communication protocol is PCIe 3.0, the second parameter is set to 8 bits, and when the communication protocol is PCIe 5.0, the second parameter is set to 12 bits. In one possible implementation, the configurable parameters of each of the plurality of functional modules include a third parameter and a fourth parameter of the data link layer functional module. The third parameter is used to set the size of the base address register address space, and the fourth parameter is used to set whether to increase the receiver-side channel margin. When the communication protocol is PCIe 3.0, the third parameter is set to 64 bits, and when the communication protocol is PCIe 5.0, the fourth parameter is set to increase the receiver-side channel margin. In another possible implementation, the configurable parameters of each of the plurality of functional modules include a fifth parameter, a sixth parameter, a seventh parameter, and an eighth parameter of the physical layer functional module. The fifth parameter is used to set the PIPE standard supported by the physical layer functional module, the sixth parameter is used to set the data bit width supported by the physical layer functional module, the seventh parameter is used to set the PIPE interface mode supported by the physical layer functional module, and the eighth parameter is used to set the clock mode supported by the physical layer functional module. In one possible implementation, when the communication protocol is PCIe 3.0, the fifth parameter is set to support PIPE 3.0 and higher-order versions of the PIPE 3.0 standard, the sixth parameter is set to support 16-bit or 32-bit data width, the seventh parameter is set to support native PIPE interface mode, and the eighth parameter is set to support clock physical layer output clock mode.In one possible implementation, when the communication protocol is PCIe 5.0, the fifth parameter is set to support PIPE 5.0 and PIPE 6.0, as well as higher-order versions of PIPE 5.0 and PIPE 6.0 standards; the sixth parameter is set to support 16-bit, 32-bit, 20-bit, 40-bit, or 64-bit data widths; the seventh parameter is set to support native PIPE interface mode and Serdes PIPE interface mode; and the eighth parameter is set to support physical layer output clock mode and physical layer input clock mode. In another possible implementation, the various selection combinations include a physical layer subsystem employing the Serdes PIPE interface mode and supporting PIPE 5.0 and higher-order versions of PIPE 5.0 standards; a physical layer subsystem employing the native PIPE interface mode and supporting PIPE 4.0 and higher-order versions of PIPE 4.0 standards and a physical layer input clock mode; and a physical layer subsystem employing the native PIPE interface mode and supporting the PIPE 4.3 standard and a physical layer output clock mode. Thus, for application scenarios using the PCIe communication protocol, multiple functional modules are provided based on the layered protocol defined by this communication protocol. The configurable parameters of each functional module are determined based on parameter tables for various selection combinations. Furthermore, these various selection combinations represent all possible combinations between the controller selection and the physical layer subsystem selection, determined by the associated version of this communication protocol. As long as the communication protocol remains PCIe, different versions can be supported, or existing versions can be customized. Version rollback and upgrades are also easily achievable. This is because, while the communication protocol remains unchanged, different versions of the same communication protocol may modify interface specifications, data bit width, and clock mode, but will not change the structure of the layered protocol defined by the communication protocol. Therefore, by providing multiple functional modules that correspond one-to-one with the layered protocol defined by the communication protocol, the fixed structural characteristics are grasped in the continuous upgrade and evolution of the same communication protocol. Thus, by combining parameterized and polymorphic design, the data bit width, interface standard, clock mode, and working mode of the external interface of the design under test can be adapted to the specific test requirements by setting the configurable parameters of each functional module. Incremental coverage can also be achieved by setting the verification rules included in the layered verifier of the verification platform, and the selection combination between the controller selection and the physical layer subsystem selection limited by the interface test requirements can be adapted. Furthermore, through the parameterized and polymorphic design of multiple functional modules, in response to different versions and customization requirements, by setting the configurable parameters of each functional module and the verification rules included in the layered validator, it supports incremental coverage of newly added features, as well as the selection combination between the controller selection and the physical layer subsystem selection that can be customized through parameters.For example, a layered verifier can verify the transaction layer, data link layer, and physical layer separately, providing corresponding verification rules from front-end design to back-end design and pre-shipment testing. Furthermore, the layered verifier can incrementally cover new features of PCIe 3.0, such as the new extended tag field and extended base address register addressing space, and also supports PIPE 3.0 and its higher-order versions, along with corresponding data widths and interface modes. Additionally, the layered verifier can incrementally cover new features of PCIe 5.0, such as separate data and control paths, extended tag fields, and new data widths, interface modes, and clock modes. Thus, it supports verification throughout the entire chip development lifecycle, meeting the complex and ever-changing verification needs of chip IPs at different R&D stages, with varying interfacing testing requirements and customization needs.

[0101] See Figure 1 and Figure 2 In one possible implementation, the layered verifier is used to verify the transaction layer, the data link layer, and the physical layer separately. The layered verifier includes verification rules corresponding to register transfer level (RTL) code verification in the front-end design phase, netlist verification in the back-end design phase, and pre-shipment silicon verification. Different interface specifications and clock modes may involve changes to the entire chain from the host computer to protocol parsing to input / output ports, as well as top-level integration verification of the design under test. Furthermore, depending on the stage of the chip development cycle, there may be different emphases. For example, the front-end design phase may focus on register transfer level (RTL) code verification, the back-end design phase on netlist verification, and the packaging phase on sign-off verification. This achieves support for RTL code verification in the front-end design phase, netlist verification in the back-end design phase, and sign-off verification in the packaging phase, supporting verification throughout the entire chip development lifecycle. It can meet the complex and varied verification needs of chip IPs at different R&D stages, with different interfacing testing requirements and different customization needs.

[0102] See Figure 1 and Figure 2In one possible implementation, the management method further includes, when the test requirements include performance under extreme application environments, incrementally modifying the verification rules included in the hierarchical verifier to add verification rules corresponding to process voltage and temperature conditions, and modifying the configurable parameters of the transaction layer functional modules to simulate variables sensitive to the process voltage and temperature conditions. Thus, by modifying functional modules and hierarchical verifier rules to meet customer customization needs and verification requirements under extreme application environments, low-power management can be achieved by adding user-defined power consumption sub-states, and process corner voltage and temperature factors can be added as verification rules to meet aging test requirements under high and low temperature conditions.

[0103] See Figure 1 and Figure 2 In one possible implementation, the management method further includes modifying the configurable parameters of the transaction layer functional module to simulate the interruption mechanism, link failure, and link blocking of the host computer when the test requirements include system-level testing. Thus, the transaction layer functional module can simulate the interruption mechanism of the host computer, as well as system-level tests such as link failure and link blocking.

[0104] See Figure 1 and Figure 2In one possible implementation, the verification platform includes a verification environment and a verification sub-environment based on the transaction layer functional modules. The verification environment is used for the initial configuration of the verification platform, and the verification sub-environment is used for on-chip system-level compatibility. This provides a general-purpose, normalized, and multi-type integrated subsystem verification platform. Through the core modules and key components of the verification platform, it provides a verification environment (Env Wrapper) for the initial configuration of the subsystem itself, such as configuration associations across different dimensions and automated verification. It also provides a verification sub-environment (Sub-env) for overall reuse by upper layers, for example, integrating a PCIe subsystem at the system-on-chip level. This not only meets the requirement for subsystem compatibility at the system level but also allows for flexible selection of general-purpose bus interfaces such as Control Register (CR), Joint Test Action Group (JTAG), Advanced Peripheral Bus (APB), and Advanced eXtensible Interface (Advanced eXtensible Interface) at the system-level configuration interface. These can all be made compatible through parameterized settings, improving the flexibility of system-level design. Furthermore, the verification environment can also provide a variety of incentive-based virtual sequence generators, support parameterized and master-servant bidirectional verification components (Verification IP, VIP), parameterized physical layer PCIe verification components, support parameterized and polymorphic transaction layer verification components, and provide type conversion components supporting AXI to TLP as well as receiving components, further enhancing the flexibility and richness of system-level design.

[0105] See Figure 1 and Figure 2In one possible implementation, the verification platform further includes a Design-Under-Test (DUT) integrator based on the data link layer functional module and the physical layer functional module. The DUT integrator includes a parameterized controller module, a clock reset module supporting multiple clock modes and multiple reset operations, a connector module supporting multiple interface widths and frequency conversions, and a parameterized physical layer region integrator. This provides a general-purpose and normalized physical layer and data link layer-level DUT wrapper. Here, the parameterized controller module (CTRLblock) can be used to support and implement the integration requirements of multiple controller types, for example, it can support and implement multi-mode use of multiple clock and reset domains. Utilizing the clock reset module supporting multiple clock modes and multiple reset operations, it can support physical layer input clock mode (PCLK AS PHY INPUT) and physical layer output clock mode (PCLK AS PHYOUTPUT), and can also support reset operations of different dimensions. The connector module supports multiple interface widths and frequency conversions to support and implement different PIPE data widths. It can adapt to the logic processing of different PIPE interface widths from the controller to the physical layer, and also supports general conversion processing in different frequency directions, such as fast to slow or slow to fast. The parameterized physical layer area integrator (PHY Block Wrapper) supports and implements the integration requirements of multiple physical layer subsystems. Through configurable parameters, it can support various typical PIPE versions such as PIPE 4.3 / 4.4.1 / 5.2 / 6.2.1; different PCLK modes; data widths of various PIPEs at typical rates from PCIe Generation 1 to Generation 5; and SerDes PIPE operating mode or Original PIPE operating mode. Thus, by reusing verification components and parameterizing key components and environment variables, it can be compatible with different external interface data widths, interface standards, clock modes, and operating modes, and supports different combinations of controller and physical layer subsystem selections. Furthermore, the parameterized configuration interface allows for flexible user settings.

[0106] See Figure 1 and Figure 2In one possible implementation, at least before performing the adaptation of the verification platform for the design under test, the verification platform has already completed parametric design based on the associated version of the communication protocol to ensure compatibility with the various selection combinations. This achieves a general-purpose, normalized subsystem verification platform that supports modular and flexible combinations of multiple types and modes of controllers and physical layer subsystems, providing flexible selection and free assembly. It enables users to conduct more general, efficient, lower-learning-cost, and less manpower-intensive subsystem integration testing. Furthermore, based on this multi-type, multi-mode integrated subsystem verification platform, practical applications can effectively reduce the integration and debugging costs of subsystem verification, and shorten the verification cycle for subsystem protocol consistency and standardized interface testing. Facing the verification needs of multiple subsystem design service projects, this verification platform can significantly improve the portability and reusability of standardized interface testing between subsystems with different customization requirements and different types of controllers and subsystems, exhibiting high output efficiency and platform benefits.

[0107] See Figure 1 and Figure 2 In one possible implementation, at least before performing the adaptation of the verification platform for the design under test, the verification platform has completed randomization design to support multi-scenario combination testing and functional coverage testing. Thus, multiple randomization designs are incorporated into the verification platform to achieve multi-scenario combination testing, and the completeness of the tests is ensured by collecting functional coverage data. Optionally, the verification platform may incorporate assertion checks for the PIPE interface to ensure the correct behavior of the general PIPE interface connecting CTRL and PHY, effectively screening for interface issues.

[0108] See Figure 1 and Figure 4 In one possible implementation, the communication protocol is the USB protocol, and the layered protocol includes a transaction layer, a data link layer, and a physical layer. The multiple functional modules include transaction layer functional modules corresponding to the transaction layer, data link layer functional modules corresponding to the data link layer, and physical layer functional modules corresponding to the physical layer. Thus, for application scenarios where the communication protocol is USB, multiple functional modules are provided based on the layered protocol defined by this communication protocol, and the configurable parameters of each of the multiple functional modules are determined based on parameter tables for various selection combinations. Furthermore, the various selection combinations are all possible combinations between the controller selection and the physical layer subsystem selection, determined based on the associated version of this communication protocol.

[0109] See Figure 1 and Figure 4In one possible implementation, the associated versions of the communication protocol include USB 3.0, USB 3.1, and USB 4.0. Thus, various versions of the USB protocol are supported.

[0110] See Figure 1 and Figure 4In one possible implementation, the configurable parameters of each of the plurality of functional modules include a ninth parameter, wherein the ninth parameter is used to set the maximum speed supported by the data path, and when the communication protocol is USB 3.0, USB 3.1, or USB 4.0, the ninth parameter is set to 5 gigabits per second, 10 gigabits per second, and 40 gigabits per second, respectively. In another possible implementation, the configurable parameters of each of the plurality of functional modules include a tenth parameter, wherein the tenth parameter is used to set whether the data path and control path support multiple physical links. When the communication protocol is USB 3.0 or USB 3.1, the tenth parameter is set to allow the data path and control path to support only a single physical link; when the communication protocol is USB 4.0, the tenth parameter is set to allow the data path and control path to support two physical links. In one possible implementation, the configurable parameters of each of the plurality of functional modules include an eleventh parameter of the data link layer functional module. This eleventh parameter is used to set the encoding and decoding standards and speed modes supported by the data link layer functional module. Specifically, when the communication protocol is USB 3.0, the eleventh parameter is set to support 8b / 10b encoding and decoding standards and low-speed and medium-speed modes; when the communication protocol is USB 3.1, the eleventh parameter is set to support 128b / 132b encoding and decoding standards and medium-speed and high-speed modes; and when the communication protocol is USB 4.0, the eleventh parameter is set to support 64b / 66b encoding and decoding standards and 128b / 132b encoding and decoding standards and high-speed mode. In one possible implementation, the configurable parameters of each of the plurality of functional modules include a twelfth parameter of the physical layer functional module, wherein the twelfth parameter is used to set the maximum transmission power supported by the physical layer functional module, and when the communication protocol is USB 3.0, the twelfth parameter is set to a maximum transmission power of 5 watts supported by the physical layer functional module; when the communication protocol is USB 3.1, the twelfth parameter is set to a maximum transmission power of 100 watts supported by the physical layer functional module; and when the communication protocol is USB 4.0, the twelfth parameter is set to a maximum transmission power of 240 watts supported by the physical layer functional module.In one possible implementation, the configurable parameters of each of the plurality of functional modules include a thirteenth parameter of the physical layer functional module. This thirteenth parameter is used to set whether the physical layer functional module supports a Type-C interface and whether it supports a fast charging operating mode. Specifically, when the communication protocol is USB 3.0, the thirteenth parameter is set so that the physical layer functional module does not support a Type-C interface and fast charging operating mode; when the communication protocol is USB 3.1 or USB 4.0, the thirteenth parameter is set so that the physical layer functional module supports a Type-C interface and fast charging operating mode. Thus, through parameterized and polymorphically designed multiple functional modules, facing different versions and customization needs, by setting the configurable parameters of each functional module and the verification rules included in the layered validator, it supports incremental coverage of newly added features and supports the selection combination between the controller selection customized through parameters and the physical layer subsystem selection. For example, the layered validator can verify the transaction layer, data link layer, and physical layer separately, and provide corresponding verification rules from front-end design to back-end design and pre-shipment testing. Furthermore, the layered verifier can incrementally cover new features and key parameter changes between different versions of the USB protocol. This supports verification throughout the entire chip development lifecycle, meeting the complex and ever-changing verification needs of chip IPs at different R&D stages, with varying interfacing testing requirements and customization needs.

[0111] See Figure 1 In one possible implementation, the management method further includes, when the test requirements indicate that incremental modifications are made to the configurable parameters of the plurality of functional modules to introduce new features, incremental modifications are made to the verification rules included in the hierarchical verifier to cover the new features. Thus, by combining parameterized and polymorphic design, the data bit width, interface standard, clock mode, and operating mode of the external interface of the design under test specifically specified by the test requirements can be adapted by setting the configurable parameters of each functional module. Incremental coverage can also be achieved by setting the verification rules included in the hierarchical verifier of the verification platform, and the selection combination between the controller selection and the physical layer subsystem selection limited by the interface test requirements can be adapted.

[0112] See Figure 1 In one possible implementation, the management method further includes, when the test requirement indicates that a reductionist modification be performed on the configurable parameters of the plurality of functional modules to remove existing features, a reductionist modification be performed on the verification rules included in the hierarchical verifier so that the existing features are no longer covered. Thus, adding and deleting corresponding customized requirements at any time during the verification process improves verification efficiency.

[0113] See Figure 1 In one possible implementation, the management method further includes, when the test requirements include user-customized needs, performing incremental modifications to the configurable parameters of each of the multiple functional modules and to the verification rules included in the hierarchical validator to support the user-customized needs. This allows for meeting customer customization needs, such as providing corresponding modifications to the transaction layer, data link layer, and physical layer for low-power designs, and also allows for adding, deleting, and replacing verification rules in the hierarchical rule validator.

[0114] See Figure 1In one possible implementation, the user customization requirement is low-power fine-grained management. Incremental modifications are made to the configurable parameters of each of the multiple functional modules, including adding new energy levels, adding new power consumption levels, adding new operating voltage levels, setting new data transmission rates, setting new link bit widths, setting load balancing at the data link layer, setting active switching of redundant links at the data link layer, and setting the maximum packet length and packet format at the transaction layer. Furthermore, incremental modifications are made to the verification rules included in the layered verifier to verify the incremental modifications to the configurable parameters of each of the multiple functional modules. In chip design, three metrics—Power, Performance, and Area—need to be considered as key elements for evaluating and optimizing semiconductor design, collectively known as PPA metrics. These metrics jointly determine the efficiency, functionality, and cost-effectiveness of integrated circuits. For example, customer customization requirements may have high power consumption requirements in PPA, such as requiring low-power address management functionality. Assume that the standard protocol specifies four power consumption levels: P0, P0s, P1, and P2, and leaves room for user customization. Users can add low-power examples, such as energy levels and power levels. For instance, they can add user-defined power sub-states, such as setting different energy levels like P1.1, P1.2, and P2.1, thus providing finer-grained low-power sub-states for low-power management. Furthermore, setting low-power sub-states may involve data transmission rates and operating voltages (e.g., core operating voltages for different power levels like 0.75V, 0.9V, 1.2V, and 1.8V), requiring corresponding physical layer modifications. This can be achieved through physical layer functional modules and layered validators. Additionally, setting low-power sub-states may also involve link bandwidth, active switching to redundant links, load balancing configuration (which involves data link layer modifications), and changes to maximum packet length and packet format (which involves transaction layer modifications). Therefore, this can also be achieved through data link layer functional modules, transaction layer functional modules, and layered validators. Thus, the aforementioned low-power optimization design can ultimately be reflected in the modification of the three functional modules and the rule modification of the hierarchical verifier. This means that corresponding customized requirements can be added and deleted at any time during the verification process, which helps to improve verification efficiency.

[0115] See Figure 1In one possible implementation, the multiple functional modules are respectively pooled into multiple callable resource pools, and the verification platform achieves end-to-end configurability by calling these resource pools. Thus, based on the layered structure of the communication protocol, corresponding functional modules are provided, such as transaction layer, data link layer, and physical layer functional modules for the PCIe protocol, along with corresponding layered rule validators, realizing a pooled design. This facilitates decoupling, meaning each functional module only considers its own resource optimization design without considering the impact on other functional modules; it also facilitates invocation, for example, resources can be scheduled to simultaneously perform PCIe 3.0 and PCIe 6.0 verification, which aligns with the trend of heterogeneous chip design. Subsystems corresponding to different protocol standards can be integrated on the physical layer of a chip, for example, chips using different architectures. Based on the layered protocol defined by the communication protocol, multiple functional modules are provided, which naturally conform to the message parsing function of the protocol stack, the message packing function of the message forwarding engine, and the control mechanism of the host computer. Therefore, it helps to realize the optimized design of the whole chain from the host computer to the protocol engine and then to the input and output ports. For example, the optimized design can be made for the characteristics of the PCIe layered protocol, that is, the characteristics of the three-layer protocol.

[0116] See Figure 1 and Figure 5 In one possible implementation, the communication protocol is the UCIe protocol, and the layered protocol includes a protocol layer, a chip-to-chip adapter layer, and a physical layer. The multiple functional modules include protocol layer functional modules corresponding to the protocol layer, chip-to-chip adapter layer functional modules corresponding to the chip-to-chip adapter layer, and physical layer functional modules corresponding to the physical layer. Thus, for application scenarios where the communication protocol is UCIe, multiple functional modules are provided based on the layered protocol defined by this communication protocol, and the configurable parameters of each of the multiple functional modules are determined based on parameter tables for various selection combinations. Furthermore, the various selection combinations are all possible combinations between the controller selection and the physical layer subsystem selection determined based on the associated version of this communication protocol.

[0117] See Figure 1 and Figure 5 In one possible implementation, the associated versions of the communication protocol include UCIe 1.0, UCIe 1.1, UCIe 2.0, and UCIe 3.0. This allows for support of different versions of the UCIe protocol.

[0118] See Figure 1 and Figure 5In one possible implementation, the configurable parameters of each of the plurality of functional modules include a fourteenth parameter, wherein the fourteenth parameter is used to set the maximum rate, and when the associated version of the communication protocol is UCIe 1.1, the fourteenth parameter is set to a maximum rate of 32 gigabits per second, and when the associated version of the communication protocol is UCIe 3.0, the fourteenth parameter is set to a maximum rate of 64 gigabits per second. In another possible implementation, the configurable parameters of each of the plurality of functional modules include a fifteenth parameter, which is used to set whether the last bit of valid transmitted data needs to be retained when the data link is idle in receiver impedance matching mode, and when the associated version of the communication protocol is UCIe 1.1, the fifteenth parameter is set to retain the last bit of valid transmitted data and prohibit its flipping when the data link is idle in receiver impedance matching mode, and when the associated version of the communication protocol is UCIe 3.0, the fifteenth parameter is set to not need to retain the last bit of valid transmitted data and allow its flipping to be maintained when the transmission is idle. In one possible implementation, the configurable parameters of each of the plurality of functional modules include a sixteenth parameter, which is used to set whether to support the management transport protocol. When the associated version of the communication protocol is UCIe 1.1, the sixteenth parameter is set to not support the management transport protocol, and when the associated version of the communication protocol is UCIe 3.0, the sixteenth parameter is set to support the management transport protocol. In one possible implementation, the configurable parameters of each of the plurality of functional modules include a seventeenth parameter. The seventeenth parameter is used to set whether the UCIe physical layer clock receive path calibration module supports phase and amplitude calibration on the receiving side by adjusting the clock delay on the transmitting side when executing the clock receive path. When the associated version of the communication protocol is UCIe 1.1, the seventeenth parameter is set so that the UCIe physical layer clock receive path calibration module does not support phase and amplitude calibration on the receiving side by adjusting the clock delay on the transmitting side when executing the clock receive path. When the associated version of the communication protocol is UCIe 3.0, the seventeenth parameter is set so that the UCIe physical layer clock receive path calibration module supports phase and amplitude calibration on the receiving side by adjusting the clock delay on the transmitting side when executing the clock receive path.In one possible implementation, the configurable parameters of each of the plurality of functional modules include an eighteenth parameter, which is used to set whether sideband power-down is supported in low-power mode. When the associated version of the communication protocol is UCIe 1.1, the eighteenth parameter is set to not support sideband power-down; when the associated version of the communication protocol is UCIe 3.0, the eighteenth parameter is set to support both sideband power-down and sideband wake-up. In another possible implementation, the configurable parameters of each of the plurality of functional modules include a nineteenth parameter, which is used to set whether sideband performance mode is supported. When the associated version of the communication protocol is UCIe 1.1, the nineteenth parameter is set to not support sideband performance mode and specifies the packet gap between consecutively transmitted sideband data packets; when the associated version of the communication protocol is UCIe 3.0, the nineteenth parameter is set to support sideband performance mode. Thus, through parameterized and polymorphically designed multiple functional modules, and addressing different versions and customization needs, the layered verifier supports incremental coverage of newly added features and allows for parameter-customizable combinations of controller and physical layer subsystem selections. For example, the layered verifier can verify the protocol layer, chip-to-chip adapter layer, and physical layer separately, providing corresponding verification rules from front-end design to back-end design and pre-shipment testing. Furthermore, the layered verifier can incrementally cover new features and key parameter changes between different versions of the UCIe protocol. This supports verification throughout the entire chip development lifecycle, meeting the complex and ever-changing verification needs of chip IPs at different R&D stages, with varying interfacing testing requirements and customization needs.

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

[0120] Step S601: Determine the test requirements associated with the design under test, wherein the test requirements include at least the data bit width, interface standard, clock mode and working mode of the external interface of the design under test, and the communication protocol associated with the design under test defines the communication specifications between the design under test and the external environment of the design under test.

[0121] Step S603: Based on the test requirements, set the configurable parameters of each of the multiple functional modules of the verification platform, and set the verification rules included in the layered verifier of the verification platform, thereby realizing the adaptation of the verification platform to the design under test. The multiple functional modules correspond one-to-one with the layered protocol defined by the communication protocol. The configurable parameters of each of the multiple functional modules are determined based on the parameter tables of various selection combinations. The various selection combinations are all possible combinations between the selection of the controller and the selection of the physical layer subsystem determined based on the associated version of the communication protocol. Furthermore, the multiple functional modules are respectively used as multiple callable resource pools through resource pooling.

[0122] Step S605: Using the verification platform, the configurable end-to-end interaction with the design under test is simulated by calling the multiple resource pools as the external environment of the design under test, and then the simulation verification of the design under test is performed.

[0123] Figure 6 The verification method shown has the following improvements: 1) Based on the layered structure of communication protocols, it provides corresponding functional modules, such as transaction layer, data link layer, and physical layer functional modules for the PCIe protocol, as well as corresponding layered rule verifiers. 2) The functional modules are generalized and parameterized, adaptable to different versions of the PCIe protocol, different communication protocols, different application scenarios, and user needs. For example, data bit width, data transmission rate, and clock frequency can be set. Resource pooling technology is used to make each functional module into an easily accessible resource pool, providing full-chain configurability and customizability. 3) It can meet customer customization needs, such as providing corresponding modifications to the transaction layer, data link layer, and physical layer for low-power designs, and adding, deleting, and replacing verification rules in the layered rule verifier. 4) It can meet verification needs in extreme application environments, such as adding process voltage temperature (PVT) factors as verification rules to meet aging test requirements under high and low temperature conditions. 5) It can provide corresponding verification environments for different physical layer IPs to be tested. Users can configure parameterized functional modules and set verification rules, thereby realizing different combinations between the PCIe controller and the PCIe physical layer subsystem. 6) It supports RTL code verification in the front-end design stage, netlist verification in the back-end design stage, and delivery verification in the packaging stage. Thus, Figure 1The management method of the verification platform shown is used to build a verification platform to deliver the intellectual property core of chip design. It supports the verification stage throughout the entire life cycle of chip development and can meet the complex and ever-changing chip IP verification needs of different R&D stages, different communication protocols and interface standards, different interfacing test requirements, and different customization requirements. It realizes a normalized subsystem verification platform solution that supports the combination of various types of PCIe controllers and PCIe physical layer subsystems.

[0124] In short, Figure 6 The verification method described herein, through parameterized and polymorphically designed multiple functional modules, addresses different versions and customization requirements. By setting configurable parameters for each functional module and defining verification rules included in the layered verifier, it supports incremental coverage of newly added features and allows for the selection and combination of controller and physical layer subsystems customized through parameters. This not only provides customized services for specific interfacing testing needs but also effectively reduces the complexity and workload of maintenance during the verification phase of the entire chip development lifecycle, from early to late stages. Furthermore, it improves verification efficiency and shortens verification time, supporting rapid response and cost reduction, in response to the complex and ever-changing verification needs of chip IPs at different R&D stages, with different communication protocols and interface standards, different interfacing testing requirements, and different customization requirements.

[0125] Figure 7 This is a schematic diagram of a verification platform provided in an embodiment of this application. Figure 7 As shown, the verification platform 700 includes: a verification environment 701 (wherein, the verification environment 701 is used for the initial configuration of the verification platform 700), a verification sub-environment 710 (wherein, the verification sub-environment 710 is used for on-chip system-level compatibility), and a design-under-test (DUT) integrator 750. The verification environment 701, the verification sub-environment 710, and the DUT integrator 750 are based on multiple functional modules. These multiple functional modules correspond one-to-one with the layered protocols defined by the communication protocol. The configurable parameters of each of the multiple functional modules are determined based on parameter tables for various selection combinations. The various selection combinations are all possible combinations between the controller selection and the physical layer subsystem selection, determined based on the associated version of the communication protocol. The communication protocol defines the communication specifications between the DUT and its external environment. The test requirements for the DUT include at least the data bit width, interface standard, clock mode, and operating mode of the DUT's external interface. The configurable parameters of each of the multiple functional modules and the verification rules included in the hierarchical verifier of the verification platform 700 are all set based on the test requirements. The verification platform 700 is used to perform simulation verification for the design under test.

[0126] See Figure 7The verification platform 700 further includes a design-under-test (DUT) integrator 750 based on the data link layer functional module and the physical layer functional module. The DUT integrator 750 includes a parameterized controller module 752, a clock reset module 754 supporting multiple clock modes and multiple reset operations, a connector module 756 supporting multiple interface widths and frequency conversions, and a parameterized physical layer region integrator 758. The verification sub-environment 710 includes a converter module 720, a verifier module 724, and a transceiver module 722. Verification environment 701 includes a virtual sequence generator A703, and verification sub-environment 710 includes a virtual sequence generator B713. Verification environment 701 also includes an active first-type general-purpose bus interface verification component 705. Verification sub-environment 710 also includes a passive second-type general-purpose bus interface verification component 715 and a second-type general-purpose bus interface verification component 725. This not only satisfies the requirement for subsystem compatibility with the system level, but also allows for flexible selection of general-purpose bus interfaces such as the Control Register (CR), Joint Test Action Group (JTAG), Advanced Peripheral Bus (APB), and Advanced deXtensible Interface (ADI) at the system level configuration interface. These can all be made compatible through parameterized settings, improving the flexibility of the system-level design. Furthermore, the verification environment 701 can also provide a virtual sequencer with diverse stimuli, a verification IP (VIP) supporting parameterized and master-slave bidirectional verification, a parameterized physical layer PCIe verification component, a parameterized and polymorphic transaction layer verification component, and a type conversion component supporting AXI to TLP, as well as a receiving component, further enhancing the flexibility and richness of the system-level design. In addition, a general-purpose and normalized physical layer and data link layer DUT wrapper 750 is provided. Here, the parameterized controller module (CTRL block) 752 can be used to support and implement the integration requirements of multiple controller types, such as supporting and implementing multi-mode use of multiple clocks and reset domains. Utilizing the clock reset module 754, which supports multiple clock modes and multiple reset operations, it can support physical layer input clock mode (PCLK AS PHY INPUT) and physical layer output clock mode (PCLK AS PHY OUTPUT), and can also support reset operations in different dimensions.The connector module 756, supporting multiple interface widths and frequency conversions, is used to support and implement different PIPE data widths. It can adapt to the logic processing of different PIPE interface widths from the controller to the physical layer, and can also support general conversion processing in different frequency directions, such as fast to slow or slow to fast. The parameterized physical layer area integrator (PHY Block Wrapper) 758 is used to support and implement the integration requirements of multiple physical layer subsystems. Through configurable parameters, it can support multiple typical PIPE versions such as PIPE 4.3 / 4.4.1 / 5.2 / 6.2.1; support different PCLK modes; support multiple PIPE data widths at typical rates from PCIe Generation 1 to Generation 5; and support SerdesPIPE working mode or Original PIPE working mode. In this way, by reusing verification components and parameterized key components and parameterized environment variables, it can be compatible with different external interfaces in terms of data bit width, interface standard, clock mode and working mode, as well as support different combinations of controllers and physical layer subsystems. Furthermore, through parameterization of the configuration interface, it supports flexible settings by users.

[0127] Figure 7 The verification platform shown has the following improvements: 1) Based on a layered structure of communication protocols, it provides corresponding functional modules, such as transaction layer, data link layer, and physical layer functional modules for the PCIe protocol, as well as corresponding layered rule verifiers. 2) The functional modules are designed to be generalized and parameterized, adaptable to different versions of the PCIe protocol, different communication protocols, and different application scenarios and user needs. For example, data bit width, data transmission rate, and clock frequency can be set. Resource pooling technology is used to make each functional module into an easily accessible resource pool, providing full-chain configurability and customizability. 3) It can meet customer customization needs, such as providing corresponding modifications to the transaction layer, data link layer, and physical layer for low-power designs, and adding, deleting, and replacing verification rules in the layered rule verifier. 4) It can meet verification needs in extreme application environments, such as adding process voltage temperature (PVT) factors as verification rules to meet aging test requirements under high and low temperature conditions. 5) It can provide corresponding verification environments for different physical layer IPs to be tested. Users can configure parameterized functional modules and set verification rules, thereby realizing different combinations between the PCIe controller and the PCIe physical layer subsystem. 6) It supports RTL code verification in the front-end design stage, netlist verification in the back-end design stage, and delivery verification in the packaging stage. Thus, Figure 1The management method of the verification platform shown is used to build a verification platform to deliver the intellectual property core of chip design. It supports the verification stage throughout the entire life cycle of chip development and can meet the complex and ever-changing chip IP verification needs of different R&D stages, different communication protocols and interface standards, different interfacing test requirements, and different customization requirements. It realizes a normalized subsystem verification platform solution that supports the combination of various types of PCIe controllers and PCIe physical layer subsystems.

[0128] In short, Figure 7 The verification platform shown, through its parameterized and polymorphic design of multiple functional modules, caters to different versions and customized needs. By setting configurable parameters for each functional module and defining the verification rules included in the layered verifier, it supports incremental coverage of newly added features and allows for the selection and combination of controllers and physical layer subsystems customized through parameters. This not only provides customized services for specific interfacing testing needs but also effectively reduces the complexity and workload of maintenance throughout the verification phase of the entire chip development lifecycle, from early to late stages. Furthermore, it improves verification efficiency and shortens verification time, supporting rapid response and cost reduction, in response to the complex and ever-changing verification needs of chip IPs at different R&D stages, with different communication protocols and interface standards, different interfacing testing requirements, and different customization needs.

[0129] Figure 8 This is a schematic diagram of a computing device 800 provided in an embodiment of this application. The computing device 800 includes one or more processors 810, a communication interface 820, and a memory 830. The processors 810, the communication interface 820, and the memory 830 are interconnected via a bus 840. Optionally, the computing device 800 may further include an input / output interface 850, which is connected to input / output devices for receiving user-set parameters, etc. The computing device 800 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 810 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 800 can be referred to the specific details in the above embodiments, such as the processor 810 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 800 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 820 can be used for communication functions necessary to implement the functions of these devices and components, and the processor 810 can be used for processing functions necessary to implement the functions of these devices and components.

[0130] It should be understood that, Figure 8 The computing device 800 may include one or more processors 810, and the multiple processors 810 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 810 may form a processor sequence or a processor array; or the multiple processors 810 may be divided into a main processor and an auxiliary processor; or the multiple processors 810 may have different architectures, such as adopting a heterogeneous computing architecture. Furthermore, Figure 8 The structural and functional descriptions of the computing device 800 shown are exemplary and non-limiting. In some exemplary embodiments, the computing device 800 may include... Figure 8 The diagram shows more or fewer components, or combinations of some components, or splitting of some components, or different arrangements of components.

[0131] The processor 810 can have various specific implementations. For example, the processor 810 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 810 can also be a single-core processor or a multi-core processor. The processor 810 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 810 can also be implemented solely using logic devices with built-in processing logic, such as FPGAs or digital signal processors (DSPs). The communication interface 820 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.

[0132] Memory 830 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 830 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 830 can also be used to store program code and data, so that the processor 810 can call the program code stored in the memory 830 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 800 may include, compared to... Figure 8 The number of components displayed may be more or less, or there may be different component configurations.

[0133] Bus 840 can be a high-speed 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), a cache coherent interconnect for accelerators (CCIX), etc. Bus 840 can be divided into address bus, data bus, control bus, etc. In addition to the data bus, bus 840 can also include a power bus, control bus, and status signal bus. However, for clarity, Figure 8 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.

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

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

[0136] 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, 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.

[0137] 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 1One 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.

[0138] 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 management method for a verification platform, characterized in that, The management method includes: The test requirements associated with the design under test (DUT) are determined, wherein the test requirements include at least the data bit width, interface standard, clock mode, and operating mode of the DUT's external interface, and the communication protocol associated with the DUT defines the communication specifications between the DUT and its external environment; and Based on the test requirements, configurable parameters are set for each of the multiple functional modules of the verification platform, and verification rules are set for the layered verifier of the verification platform, thereby achieving the adaptation of the verification platform to the design under test. The multiple functional modules correspond one-to-one with the layered protocols defined by the communication protocol. The configurable parameters of each functional module are determined based on parameter tables for various selection combinations. These various selection combinations are all possible combinations between the selection of the controller and the physical layer subsystem of the communication protocol, determined based on the associated version of the communication protocol. The verification platform is used to perform simulation verification for the design under test, and the layered verifier is used to verify the layered protocols separately.

2. The management method according to claim 1, characterized in that, The design under test is a physical layer intellectual property core.

3. The management method according to claim 2, characterized in that, The communication protocol is the PCIe protocol, and the layered protocol includes a transaction layer, a data link layer, and a physical layer. The multiple functional modules include a transaction layer functional module corresponding to the transaction layer, a data link layer functional module corresponding to the data link layer, and a physical layer functional module corresponding to the physical layer.

4. The management method according to claim 2, characterized in that, The communication protocol is a four-layer network protocol, which includes a transport layer, a network layer, a data link layer, and a physical layer. The multiple functional modules include a transport layer functional module corresponding to the transport layer, a network layer functional module corresponding to the network layer, a data link layer functional module corresponding to the data link layer, and a physical layer functional module corresponding to the physical layer.

5. The management method according to claim 3, characterized in that, The associated versions of the communication protocol include PCIe 1.0, PCIe 2.0, PCIe 3.0, PCIe 4.0, and PCIe 5.

0.

6. The management method according to claim 3, characterized in that, Each of the multiple functional modules has configurable parameters including a first parameter, wherein the first parameter is used to set whether to perform independent maintenance of the data path and the control path. When the communication protocol is PCIe 3.0, the first parameter is set to not perform independent maintenance of the data path and the control path. And when the communication protocol is PCIe 5.0, the first parameter is set to perform independent maintenance of the data path and the control path.

7. The management method according to claim 3, characterized in that, The configurable parameters of each of the multiple functional modules include the second parameter of the transaction layer functional module, wherein the second parameter is used to set the number of bits in the tag field of the transaction layer identifier. When the communication protocol is PCIe 3.0, the second parameter is set to 8 bits, and when the communication protocol is PCIe 5.0, the second parameter is set to 12 bits.

8. The management method according to claim 3, characterized in that, The configurable parameters of each of the multiple functional modules include the third parameter and the fourth parameter of the data link layer functional module. The third parameter is used to set the size of the base address register address space, and the fourth parameter is used to set whether to increase the receiving-side channel margin. When the communication protocol is PCIe 3.0, the third parameter is set to 64 bits, and when the communication protocol is PCIe 5.0, the fourth parameter is set to increase the receiving-side channel margin.

9. The management method according to claim 3, characterized in that, The configurable parameters of each of the multiple functional modules include the fifth parameter, the sixth parameter, the seventh parameter, and the eighth parameter of the physical layer functional module. The fifth parameter is used to set the PIPE standard supported by the physical layer functional module, the sixth parameter is used to set the data bit width supported by the physical layer functional module, the seventh parameter is used to set the PIPE interface mode supported by the physical layer functional module, and the eighth parameter is used to set the clock mode supported by the physical layer functional module.

10. The management method according to claim 9, characterized in that, When the communication protocol is PCIe 3.0, the fifth parameter is set to support PIPE 3.0 and PIPE 3.0 higher-order versions of the standard, the sixth parameter is set to support 16-bit or 32-bit data width, the seventh parameter is set to support native PIPE interface mode, and the eighth parameter is set to support clock physical layer output clock mode.

11. The management method according to claim 9, characterized in that, When the communication protocol is PCIe 5.0, the fifth parameter is set to support PIPE 5.0 and PIPE 6.0, as well as higher-order versions of PIPE 5.0 and PIPE 6.0 standards; the sixth parameter is set to support 16-bit, 32-bit, 20-bit, 40-bit, or 64-bit data bit widths; the seventh parameter is set to support native PIPE interface mode and Serdes PIPE interface mode; and the eighth parameter is set to support physical layer output clock mode and physical layer input clock mode.

12. The management method according to claim 3, characterized in that, The various selection combinations include a physical layer subsystem that adopts the Serdes PIPE interface mode and supports PIPE 5.0 and higher-order versions of the PIPE 5.0 standard; a physical layer subsystem that adopts the native PIPE interface mode and supports PIPE 4.0 and higher-order versions of the PIPE 4.0 standard and clock physical layer input clock mode; and a physical layer subsystem that adopts the native PIPE interface mode and supports the PIPE 4.3 standard and clock physical layer output clock mode.

13. The management method according to claim 3, characterized in that, The layered verifier is used to verify the transaction layer, the data link layer, and the physical layer respectively. The layered verifier includes verification rules corresponding to register-transfer level code verification in the front-end design stage, netlist verification in the back-end design stage, and silicon verification before delivery.

14. The management method according to claim 3, characterized in that, The management method further includes, when the test requirements include performance under extreme application environments, incrementally modifying the verification rules included in the hierarchical verifier to add verification rules corresponding to process voltage and temperature conditions, and modifying the configurable parameters of the transaction layer functional modules to simulate variables sensitive to the process voltage and temperature conditions.

15. The management method according to claim 3, characterized in that, The management method also includes, when the test requirements include system-level testing, modifying the configurable parameters of the transaction layer functional module to simulate the interruption mechanism, link failure, and link blockage of the host computer.

16. The management method according to claim 3, characterized in that, The verification platform includes a verification environment and a verification sub-environment based on the transaction layer functional module. The verification environment is used for the initial configuration of the verification platform, and the verification sub-environment is used for on-chip system-level compatibility.

17. The management method according to claim 16, characterized in that, The verification platform also includes a design under test integrator based on the data link layer functional module and the physical layer functional module. The design under test integrator includes a parameterized controller module, a clock reset module that supports multiple clock modes and multiple reset operations, a connector module that supports multiple interface bit widths and frequency conversions, and a parameterized physical layer area integrator.

18. The management method according to claim 17, characterized in that, At least before performing the adaptation of the verification platform for the design under test, the verification platform has completed the parametric design based on the associated version of the communication protocol to be compatible with the various selection combinations.

19. The management method according to claim 18, characterized in that, At least before performing the adaptation of the verification platform for the design under test, the verification platform has completed randomization design to support multi-scenario combination testing and functional coverage testing.

20. The management method according to claim 2, characterized in that, The communication protocol is the USB protocol, and the layered protocol includes a transaction layer, a data link layer, and a physical layer. The multiple functional modules include a transaction layer functional module corresponding to the transaction layer, a data link layer functional module corresponding to the data link layer, and a physical layer functional module corresponding to the physical layer.

21. The management method according to claim 20, characterized in that, The associated versions of the communication protocol include USB 3.0, USB 3.1, and USB 4.

0.

22. The management method according to claim 21, characterized in that, Each of the multiple functional modules has a configurable parameter including a ninth parameter, which is used to set the maximum speed supported by the data path. When the communication protocol is USB 3.0, USB 3.1 or USB 4.0, the ninth parameter is set to 5 gigabits per second, 10 gigabits per second and 40 gigabits per second, respectively.

23. The management method according to claim 21, characterized in that, Each of the multiple functional modules has a configurable parameter including a tenth parameter, which is used to set whether the data path and control path support multiple physical links. When the communication protocol is USB 3.0 or USB 3.1, the tenth parameter is set to support only a single physical link for the data path and control path. When the communication protocol is USB 4.0, the tenth parameter is set to support two physical links for the data path and control path.

24. The management method according to claim 21, characterized in that, The configurable parameters of each of the multiple functional modules include the eleventh parameter of the data link layer functional module. The eleventh parameter is used to set the encoding and decoding standards and the speed modes supported by the data link layer functional module. When the communication protocol is USB 3.0, the eleventh parameter is set to support 8b / 10b encoding and decoding standards and support low-speed and medium-speed modes. When the communication protocol is USB 3.1, the eleventh parameter is set to support 128b / 132b encoding and decoding standards and support medium-speed and high-speed modes. When the communication protocol is USB 4.0, the eleventh parameter is set to support 64b / 66b encoding and decoding standards and 128b / 132b encoding and decoding standards and support high-speed mode.

25. The management method according to claim 21, characterized in that, The configurable parameters of each of the plurality of functional modules include a twelfth parameter of the physical layer functional module, wherein the twelfth parameter is used to set the maximum transmission power supported by the physical layer functional module, and when the communication protocol is USB 3.0, the twelfth parameter is set to a maximum transmission power of 5 watts supported by the physical layer functional module; when the communication protocol is USB 3.1, the twelfth parameter is set to a maximum transmission power of 100 watts supported by the physical layer functional module; and when the communication protocol is USB 4.0, the twelfth parameter is set to a maximum transmission power of 240 watts supported by the physical layer functional module.

26. The management method according to claim 21, characterized in that, The configurable parameters of each of the multiple functional modules include the thirteenth parameter of the physical layer functional module. The thirteenth parameter is used to set whether the physical layer functional module supports a Type-C interface and whether it supports a fast charging working mode. When the communication protocol is USB 3.0, the thirteenth parameter is set to indicate that the physical layer functional module does not support a Type-C interface and does not support a fast charging working mode. When the communication protocol is USB 3.1 or USB 4.0, the thirteenth parameter is set to indicate that the physical layer functional module supports a Type-C interface and supports a fast charging working mode.

27. The management method according to claim 1, characterized in that, The management method further includes, when the test requirements indicate that incremental changes are made to the configurable parameters of the plurality of functional modules to introduce new features, incremental changes are made to the verification rules included in the hierarchical verifier to cover the new features.

28. The management method according to claim 1, characterized in that, The management method further includes, when the test requirements indicate that a reduction modification is performed on the configurable parameters of the plurality of functional modules to remove existing features, a reduction modification is performed on the verification rules included in the hierarchical verifier so that the existing features are no longer covered.

29. The management method according to claim 1, characterized in that, The management method further includes, when the test requirements include user customization needs, performing incremental modifications to the configurable parameters of each of the multiple functional modules and to the verification rules included in the hierarchical validator to support the user customization needs.

30. The management method according to claim 29, characterized in that, The user customization requirement is low-power fine-grained management, which involves incrementally modifying the configurable parameters of the multiple functional modules, including adding new energy levels, adding new power consumption levels, adding new operating voltage levels, setting new data transmission rates, setting new link bit widths, setting load balancing at the data link layer, setting active switching of redundant links at the data link layer, and setting the maximum packet length and packet format at the transaction layer. In addition, incremental modifications are made to the verification rules included in the layered verifier to verify the incremental modifications made to the configurable parameters of the multiple functional modules.

31. The management method according to claim 1, characterized in that, The multiple functional modules are respectively pooled into multiple callable resource pools, and the verification platform achieves full-link configurability by calling the multiple resource pools.

32. The management method according to claim 2, characterized in that, The communication protocol is the UCIe protocol. The layered protocol includes a protocol layer, a chip-to-chip adapter layer, and a physical layer. The multiple functional modules include a protocol layer functional module corresponding to the protocol layer, a chip-to-chip adapter layer functional module corresponding to the chip-to-chip adapter layer, and a physical layer functional module corresponding to the physical layer.

33. The management method according to claim 32, characterized in that, The associated versions of the communication protocol include UCIe 1.0, UCIe 1.1, UCIe 2.0, and UCIe 3.

0.

34. The management method according to claim 33, characterized in that, Each of the multiple functional modules has a configurable parameter including a fourteenth parameter, wherein the fourteenth parameter is used to set the maximum rate, and when the associated version of the communication protocol is UCIe 1.1, the fourteenth parameter is set to a maximum rate of 32 gigabits per second, and when the associated version of the communication protocol is UCIe 3.0, the fourteenth parameter is set to a maximum rate of 64 gigabits per second.

35. The management method according to claim 33, characterized in that, Each of the multiple functional modules has a configurable parameter including a fifteenth parameter. The fifteenth parameter is used to set whether the last bit of valid transmitted data needs to be retained when the data link is idle in the receiver impedance matching mode. When the associated version of the communication protocol is UCIe 1.1, the fifteenth parameter is set to retain the last bit of valid transmitted data when the data link is idle in the receiver impedance matching mode and is prohibited from being flipped. When the associated version of the communication protocol is UCIe 3.0, the fifteenth parameter is set to not need to retain the last bit of valid transmitted data when the data link is idle in the receiver impedance matching mode and is allowed to maintain flipping when the transmission is idle.

36. The management method according to claim 33, characterized in that, Each of the multiple functional modules has a configurable parameter including a sixteenth parameter, which is used to set whether the management transport protocol is supported. When the associated version of the communication protocol is UCIe 1.1, the sixteenth parameter is set to not support the management transport protocol, and when the associated version of the communication protocol is UCIe 3.0, the sixteenth parameter is set to support the management transport protocol.

37. The management method according to claim 33, characterized in that, Each of the multiple functional modules has a configurable parameter including a seventeenth parameter. This seventeenth parameter is used to set whether the UCIe physical layer clock receive path calibration module supports phase and amplitude calibration on the receiving side by adjusting the clock delay on the transmitting side when executing the clock receive path. When the associated version of the communication protocol is UCIe 1.1, the seventeenth parameter is set so that the UCIe physical layer clock receive path calibration module does not support phase and amplitude calibration on the receiving side by adjusting the clock delay on the transmitting side when executing the clock receive path. When the associated version of the communication protocol is UCIe 3.0, the seventeenth parameter is set so that the UCIe physical layer clock receive path calibration module supports phase and amplitude calibration on the receiving side by adjusting the clock delay on the transmitting side when executing the clock receive path.

38. The management method according to claim 33, characterized in that, Each of the multiple functional modules has an eighteenth parameter, which is used to set whether sideband power-down is supported in low power mode. When the associated version of the communication protocol is UCIe 1.1, the eighteenth parameter is set to not support sideband power-down, and when the associated version of the communication protocol is UCIe 3.0, the eighteenth parameter is set to support both sideband power-down and sideband wake-up.

39. The management method according to claim 33, characterized in that, Each of the multiple functional modules has a configurable parameter including a nineteenth parameter, which is used to set whether sideband performance mode is supported. When the associated version of the communication protocol is UCIe 1.1, the nineteenth parameter is set to not support sideband performance mode and specifies that there is a packet gap between consecutively sent sideband data packets. When the associated version of the communication protocol is UCIe 3.0, the nineteenth parameter is set to support sideband performance mode.

40. An electronic device, characterized in that, The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method according to any one of claims 1 to 39.

41. 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 1 to 39.

42. A verification method, characterized in that, The verification method includes: The test requirements associated with the design under test are determined, wherein the test requirements include at least the data bit width, interface standard, clock mode and working mode of the external interface of the design under test, and the communication protocol associated with the design under test defines the communication specifications between the design under test and the external environment of the design under test; Based on the test requirements, configurable parameters are set for each of the multiple functional modules of the verification platform, and verification rules are set for the layered verifier of the verification platform, thereby achieving the adaptation of the verification platform to the design under test. The multiple functional modules correspond one-to-one with the layered protocols defined by the communication protocol. The configurable parameters of each functional module are determined based on parameter tables for various selection combinations. These various selection combinations are all possible combinations between the selection of the controller and the physical layer subsystem of the communication protocol, determined based on the associated version of the communication protocol. Furthermore, each of the multiple functional modules is respectively pooled as multiple callable resource pools. Using the verification platform, a configurable end-to-end link simulating interaction with the design under test is used as the external environment of the design under test by calling the multiple resource pools, thereby performing simulation verification of the design under test. The layered verifier is used to verify the layered protocols separately.

43. A verification platform, characterized in that, The verification platform includes: A verification environment, wherein the verification environment is used for the initialization configuration of the verification platform; A verification sub-environment, wherein the verification sub-environment is used for on-chip system-level compatibility; and Design under test integrator, The verification environment, the verification sub-environment, and the design-under-test (DUT) integrator are based on multiple functional modules. These functional modules correspond one-to-one with the layered protocols defined by the communication protocol. The configurable parameters of each functional module are determined based on parameter tables for various selection combinations. These various selection combinations are all possible combinations between the controller selection and the physical layer subsystem selection of the communication protocol, determined based on the associated version of the communication protocol. The communication protocol defines the communication specifications between the DUT and its external environment. The test requirements for the DUT include at least the data bit width, interface standard, clock mode, and operating mode of its external interface. The configurable parameters of each of the multiple functional modules and the verification rules included in the layered verifier of the verification platform are all set based on the test requirements. The verification platform is used to perform simulation verification for the design under test, and the layered verifier is used to verify the layered protocol separately.

Images