A USB PD protocol verification system and method based on UVM

Abstract

The application discloses a USB PD protocol verification system and method based on UVM. The system comprises a parameterized test control unit, a protocol analysis verification unit, a power parameter monitoring unit, a role switching management unit and an abnormal scene construction unit. The parameterized test control unit generates forward and negative test cases; the protocol analysis verification unit realizes deep protocol message analysis and real-time CRC check; the power parameter monitoring unit obtains actual output parameters and compares them with protocol request parameters in a closed loop; the role switching management unit supports dynamic switching of Source, Sink and DRP roles and maintains protocol state continuity; and the abnormal scene construction unit injects multiple types of abnormal states to verify the abnormal state processing capability of the device. The application solves the technical problems of insufficient protocol depth analysis, disconnection between electrical parameters and protocol verification and discontinuous role switching state in the prior art, realizes collaborative verification of the protocol layer and the power layer, and improves the USB PD protocol chip verification efficiency and coverage.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of protocol verification, and in particular to a USB PD protocol verification system and method based on UVM. Background Technology

[0002] With the rapid development of fast charging technology, the USB Power Delivery (PD) protocol has become a universal charging standard for modern electronic devices. Its core features include wide-range voltage regulation, dynamic switching of multiple device roles (Source / Sink / DRP), and a complex handshake protocol. These features significantly increase the complexity of chip verification. Currently, the verification technology for USB PD protocol chips mainly faces the following technical challenges: First, there is insufficient verification of protocol integrity and real-time performance. Existing verification schemes have limited ability to parse deep fields of the USB PD protocol (such as SOP type, message source in the Message Header, protocol version, etc.), and CRC check and protocol state machine verification are disconnected, making it difficult to fully cover edge scenarios required by the protocol specification. Although commercial verification IPs can handle basic communication processes, they are insufficient in ensuring protocol continuity during dynamic role switching and cannot effectively verify the consistency of protocol states when switching between the Source, Sink, and DRP roles.

[0003] Secondly, there is a lack of coordinated verification of electrical parameters and protocols. Traditional verification methods separate protocol testing from power output verification: the protocol simulation environment is not linked to the actual voltage / current output effect, while power output testing relies on offline instrument measurements. This disconnect leads to protocol violations during dynamic voltage regulation (such as voltage drift during response timeout, mismatch between protocol negotiation and actual output, etc.) becoming verification blind spots, making it impossible to achieve closed-loop verification of the protocol layer and the power layer.

[0004] Secondly, the coverage of abnormal scenarios and the efficiency of test reuse are low. Existing exception injection methods are too mechanical, mainly relying on predefined test scripts, making it difficult to automatically generate complex exception scenarios such as state machine violations and message conflict arbitration. At the same time, the verification environment requires a lot of adaptation work when porting it between different projects. The lack of modular and parameterized design leads to low test environment reuse efficiency and prolongs the product launch cycle. Summary of the Invention

[0005] The main technical problem solved by the embodiments of the present invention is to provide a USB PD protocol verification system and method based on UVM, which can solve at least some of the defects of existing verification technologies for USB PD protocol chips.

[0006] In a first aspect, embodiments of the present invention provide a USB PD protocol verification system based on UVM, used for comprehensive verification of USB PD protocol chips under normal and abnormal states, including: a parameterized test control unit, used to generate test cases in a configurable manner; the test case types include positive test cases and negative test cases; a protocol parsing and verification unit, used to parse USB PD protocol messages in real time and perform integrity verification; a power parameter monitoring unit, used to obtain the actual parameter values ​​of the power output and perform closed-loop comparison and verification with the protocol request parameters; a role switching management unit, used to dynamically switch the working role of the device and maintain the continuity of the protocol state during the verification process; and an abnormal scenario construction unit, used to generate and inject multiple types of abnormal states to verify the abnormal handling capability of the device under test when executing the negative test cases.

[0007] Optionally, the protocol parsing and verification unit includes an SOP type identifier, a message header parser, and a CRC checker. The SOP type identifier is used to identify and extract the SOP type of the USB PD protocol message and distinguish the message start mode. The message header parser is used to distinguish control messages and data messages from the message header of the USB PD protocol message and extract the message source, protocol version, and message type. The CRC checker is used to perform real-time CRC32 checksum calculation on the USB PD protocol message and compare the calculation result with the CRC field in the USB PD protocol message. When a CRC checksum error is detected, the UVM verification environment reports and records the checksum anomaly.

[0008] Optionally, the power parameter monitoring unit obtains the actual parameter value by sampling analog signals through an ADC or reading digital code output parameters, and sets a configurable error range to dynamically compare the actual parameter value with the protocol request parameter. When the actual parameter value is detected to exceed the error range, an alarm mechanism is triggered. The actual parameter value includes the actual voltage value and the actual current value output by the power supply.

[0009] Optionally, the role switching management unit responds to the role identifier in the test case switching between the power supply end, the power receiving end, and the dual-role device, and automatically caches the current protocol status information when switching roles, and updates the status synchronously through hardware signals after the switching is completed; The protocol status information includes the protocol request parameters and the protocol state machine position information; the protocol request parameters include the requested voltage parameters and the requested current parameters.

[0010] Optionally, the abnormal scenario construction unit includes a message format exception generator, a timing violation simulator, and a state machine violation injector; the message format exception generator is used to generate abnormal states with message format errors, including sending an invalid header and setting an incorrect CRC32 checksum; the timing violation simulator is used to generate abnormal states with timing violations, including response timeouts and message conflicts; the state machine violation injector is used to generate abnormal states with state machine violations, including out-of-order message sending.

[0011] Optionally, the parameterized test control unit generates corresponding test cases by configuring test parameters; the test parameters include message type, role identifier bit, test case type, and protocol request parameters.

[0012] Optionally, the parameterized test control unit generates a complete message frame according to the USB PD protocol specification based on the test parameters when generating the positive test case; and configures an exception mode parameter to trigger the exception state injection of the exception scenario construction unit when generating the negative test case.

[0013] Optionally, the parameterized test control unit adopts a templated design, which can be ported to a cross-project test environment by reusing the configuration method of the test parameters, the generation templates of the positive test cases and the negative test cases.

[0014] Secondly, embodiments of the present invention provide a UVM-based USB PD protocol verification method, applied to the UVM-based USB PD protocol verification system described in the first aspect, comprising: configuring test parameters and generating test cases through the parameterized test control unit; executing the test cases, parsing USB PD protocol messages in real time and performing integrity verification through the protocol parsing verification unit, and simultaneously obtaining the actual parameter values ​​of the power output through the power parameter monitoring unit and performing closed-loop comparison verification with the protocol request parameters; during the verification process, dynamically switching the device working role and maintaining the continuity of the protocol state through the role switching management unit in response to the role identifier bit in the test cases.

[0015] Optionally, the test cases include positive test cases and negative test cases, and the method further includes: when executing the negative test cases, generating and injecting multiple types of abnormal states through the abnormal scenario construction unit to verify the abnormal handling capability of the device under test.

[0016] The beneficial effects of the embodiments of the present invention are as follows: Unlike the prior art, the embodiments of the present invention solve the technical problems of insufficient deep parsing of existing verification technologies, disconnection between electrical parameters and protocol verification, and discontinuous role switching states, thereby realizing collaborative verification of the protocol layer and the power layer and improving the verification efficiency and coverage of USB PD protocol chips. Attached Figure Description

[0017] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0018] Figure 1 This is a schematic diagram of the structure of a USB PD protocol verification system based on UVM provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating a USB PD protocol verification method based on UVM provided in an embodiment of the present invention. Detailed Implementation

[0019] To facilitate understanding of this application, a more detailed description is provided below with reference to the accompanying drawings and specific embodiments. It should be noted that when an element is described as being "fixed to" another element, it can be directly on the other element, or one or more intermediate elements may exist between them. When an element is described as being "connected" to another element, it can be directly connected to the other element, or one or more intermediate elements may exist between them. The terms "upper," "lower," "inner," "outer," "bottom," etc., used in this specification indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. Furthermore, the terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0020] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0021] Furthermore, the technical features involved in the different embodiments of this application described below can be combined with each other as long as they do not conflict with each other.

[0022] The technical solutions in this application will be described below with reference to the accompanying drawings.

[0023] In some embodiments of this application, reference is made to Figure 1 As shown, a USB Power Delivery (USB PD) protocol verification system 10 based on the Universal Verification Methodology (UVM) is provided. This verification system 10 is used to comprehensively verify the USB PD protocol chip 20 under normal and abnormal conditions. By way of example and not limitation, the USB PD protocol chip 20 can be a fast charging chip, a Type-C interface controller, or other semiconductor device that supports the USB PD protocol.

[0024] Specifically, the UVM-based USB PD protocol verification system 10 includes a parameterized test control unit 110, a protocol parsing and verification unit 120, a power parameter monitoring unit 150, a role switching management unit 140, and an abnormal scenario construction unit 130.

[0025] In some embodiments of this application, the parameterized test control unit 110 is used to generate test cases in a configurable manner, wherein the test case types include positive test cases and negative test cases. Specifically, the parameterized test control unit 110 generates corresponding test cases by configuring test parameters, which include message type, role identifier bit, test case type, and protocol request parameters.

[0026] The parametric test control unit 110 operates on the principle of a parametric drive mode. As an example, and not a limitation, when testers need to verify the voltage regulation function of a USB PD chip, they only need to input basic parameters, including message type (such as a request message), voltage and current settings (such as 9V / 2A), and other core elements. Upon receiving these basic parameters, the parametric test control unit 110 can automatically generate a complete message frame conforming to the USB PD protocol specification.

[0027] Specifically, when generating positive test cases, the parameterized test control unit 110 generates complete message frames according to the USBPD protocol specification based on the test parameters. The process of generating a complete message frame includes: automatically adding a Start of Packet (SOP) synchronization header to identify the message start mode, generating a compliant message header to carry key information such as protocol version, message type, and message source, filling in the Data field to carry specific protocol data such as Power Data Object (PDO) parameters, and calculating and attaching a Cyclic Redundancy Check (CRC) 32 checksum to ensure data transmission integrity.

[0028] In some embodiments of this application, when generating negative test cases, the parameterized test control unit 110 configures exception mode parameters to trigger the exception state injection of the exception scenario construction unit 130. The exception mode parameters may include configuration information such as exception type identifier, exception severity level, and exception triggering timing.

[0029] As an example, not a limitation, the parameterized test control unit 110 adopts a template-based design. By reusing the configuration methods of test parameters and the generation templates of positive and negative test cases, it can be ported to cross-project testing environments. The core of the template-based design lies in separating the test case generation logic from the specific parameter values, so that different USB PD projects only need to adjust the specific parameter values ​​to quickly reuse the entire test framework.

[0030] The parameterized test control unit 110 interacts with the USB PD chip 20 via a protocol connection. Specifically, the parameterized test control unit 110 sends the generated complete message frame to the protocol interface of the USB PD chip 20 through the UVM driver to inject test stimuli.

[0031] In some embodiments of this application, the protocol parsing and verification unit 120 is used to parse USB PD protocol messages in real time and perform integrity verification. Specifically, the protocol parsing and verification unit 120 includes an SOP type recognizer, a message header parser, and a CRC checker.

[0032] Specifically, the SOP type identifier is used to identify and extract the SOP type of USB PD protocol messages, distinguishing the message start pattern. It's easy to understand that the SOP type identifier works based on pattern matching of the protocol message synchronization header. As an example, and not a limitation, the USB PD protocol defines several SOP types, including SOP, SOP', and SOP'', which are used to identify different communication objects and transmission paths, respectively. By detecting the start synchronization sequence of the protocol message, the SOP type identifier can accurately distinguish which SOP type the current message belongs to, thus providing the correct context information for subsequent message parsing.

[0033] In some embodiments of this application, a message header parser is used to distinguish between control messages and data messages from the message header of a USB PD protocol message, and to extract the message source, protocol version, and message type. Specifically, the message header parser's functionality is based on the parsing of bit fields in the Message Header. As an example and not a limitation, the USB PD protocol's Message Header contains several key fields: the Message Type field identifies the specific type of message, the DataRole and Power Role fields identify the role information of the message source, and the Spec Revision field identifies the protocol version information. The message header parser, through bitmasking and shift operations, can accurately extract the values ​​of each of the above fields and determine whether the current message is a control message or a data message based on the structure of the Message Header.

[0034] The CRC checksum reader performs real-time CRC32 checksum calculations on USB PD protocol messages and compares the result with the CRC field in the USB PD protocol message. Specifically, the CRC checksum reader operates based on the Cyclic Redundancy Check (CRC) algorithm. As an example, and not a limitation, the CRC checksum reader uses the CRC32 polynomial specified in the USB PD protocol to perform real-time checksum calculations on the received message data. The calculation process covers the message's SOP sequence, Message Header, and Data field (if present). When a CRC checksum error is detected, the CRC checksum reader reports the checksum anomaly and logs it through the UVM verification environment.

[0035] Specifically, the protocol parsing and verification unit 120 interacts with the USB PD chip 20 via a bus connection. The protocol parsing and verification unit 120 captures the protocol messages sent by the USB PD chip 20 through the protocol interface in real time using a UVM monitor, thereby achieving comprehensive monitoring and analysis of the chip's output behavior.

[0036] In some embodiments of this application, the power parameter monitoring unit 150 is used to acquire the actual parameter values ​​of the power output and perform closed-loop comparison and verification with the protocol request parameters. Specifically, the power parameter monitoring unit 150 obtains the actual parameter values ​​by sampling analog signals through an analog-to-digital converter (ADC) or by reading digital code output parameters, and sets a configurable error range to dynamically compare the actual parameter values ​​with the protocol request parameters.

[0037] The power parameter monitoring unit 150 operates on the principle of multiple parameter acquisition methods working together. As an example, and not a limitation, the first acquisition method is ADC sampling of analog signals. The power parameter monitoring unit 150 uses a high-precision ADC to sample the power output of the USB PD chip 20 in real time, converting the analog voltage and current signals into digital quantities for processing and analysis. The second acquisition method is reading digital code output. The power parameter monitoring unit 150 directly reads the register values ​​of the internal power management unit of the USB PD chip 20 through a digital interface to obtain the voltage and current values ​​calculated internally by the chip.

[0038] Specifically, the power parameter monitoring unit 150 sets a configurable error range to dynamically compare the actual parameter values ​​with the protocol request parameters. As an example, and not a limitation, the error range can be flexibly configured according to different testing needs; a common default setting is ±5%. The comparison process is performed in real-time and dynamically. That is, while the USB PD chip 20 adjusts its power output, the power parameter monitoring unit 150 continuously monitors changes in the actual output value and continuously compares it with the request value negotiated and determined by the protocol layer.

[0039] In some embodiments of this application, an alarm mechanism is triggered when the actual parameter value is detected to exceed the error range. Specifically, the actual parameter value includes the actual voltage value and the actual current value of the power supply output. The alarm mechanism may include various forms such as recording abnormal events, generating test reports, and sending notification information.

[0040] The power parameter monitoring unit 150 interacts with the USB PD chip 20 via a sampling connection. The power parameter monitoring unit 150 is directly connected to the power output terminal of the USB PD chip 20, achieving accurate measurement of the chip's actual output characteristics through a physical electrical connection.

[0041] In some embodiments of this application, the role switching management unit 140 is used to dynamically switch the working role of the device and maintain the continuity of the protocol state during the verification process. Specifically, the role switching management unit 140 switches between the power supply end (Source), the power receiving end (Sink), and the dual-role device (DRP) in response to the role identifier bit in the test case.

[0042] It's easy to understand that the function of the role switching management unit 140 is based on a protocol state caching and synchronization mechanism. As an example, and not a limitation, when a role switch is required, the role switching management unit 140 first reads the role identifier configured in the test case to determine the target role to switch to. Before executing the switch operation, the role switching management unit 140 automatically caches the current protocol state information to ensure that important protocol context is not lost during the switch process.

[0043] Specifically, the role switching management unit 140 automatically caches the current protocol status information during role switching, and updates the status synchronously via hardware signals after the switch is completed. The protocol status information includes protocol request parameters and protocol state machine position information. The protocol request parameters include requested voltage parameters and requested current parameters.

[0044] As an example, and not a limitation, the protocol state machine position information records the specific state node at which the current USB PD protocol interaction is taking place, such as different stages such as initiating Source_Capabilities announcement, waiting for Request response, or performing voltage switching. By caching the protocol state machine position information, the role switching management unit 140 can ensure that after a role switch is completed, the protocol interaction can continue from the correct state node, avoiding state confusion or protocol violations.

[0045] The hardware signal synchronization update mechanism ensures the consistency of state between the verification system and the USB PD chip 20. Specifically, the role switching management unit 140 communicates with the role management module of the USB PD chip 20 through a dedicated hardware signal line to achieve real-time synchronization of role states.

[0046] Specifically, the role switching management unit 140 and the USB PD chip 20 interact bidirectionally via a configuration connection. On one hand, the role switching management unit 140 sends role configuration commands to the role management module of the USB PD chip 20, controlling the chip to switch between the three roles of Source, Sink, and DRP. On the other hand, the role switching management unit 140 receives current role status and protocol status feedback from the USB PD chip 20, ensuring the accuracy and consistency of the status information.

[0047] In some embodiments of this application, the abnormal scenario construction unit 130 is used to generate and inject multiple types of abnormal states to verify the abnormal handling capability of the device under test when executing negative test cases. Specifically, the abnormal scenario construction unit 130 includes a message format abnormal generator, a timing violation simulator, and a state machine violation injector.

[0048] The message format error generator is used to generate abnormal states of message formatting errors. Specifically, the functionality of the message format error generator is based on the intentional disruption of standard protocol messages. As an example, and not a limitation, message formatting errors include sending headers with invalid formats and setting incorrect CRC32 checksums. Invalid header formats may include using undefined message types, setting incorrect protocol version numbers, configuring mismatched data lengths, etc. Incorrect CRC32 checksums are generated by intentionally modifying correctly calculated checksums and are used to test the USB PD chip 20's ability to handle data integrity errors.

[0049] In some embodiments of this application, a timing violation simulator is used to generate abnormal states of timing violations. Specifically, the timing violation simulator operates based on precise control of protocol timing requirements. By way of example and not limitation, timing violations include response timeouts and message collisions. Response timeouts can be simulated by delaying the sending of response messages. For example, after the USBPD chip 20 sends a Request message, the timing violation simulator intentionally delays sending an Accept response beyond the tSenderResponse time specified in the protocol to verify the chip's timeout handling and retransmission mechanisms. Message collisions are achieved by simulating a scenario where both ends send messages simultaneously, testing whether the USB PD chip 20 can correctly handle collisions according to the arbitration mechanism specified in the protocol.

[0050] The state machine violation injector is used to generate abnormal states that violate state machine rules. Specifically, the implementation principle of the state machine violation injector is based on the deliberate violation of the normal flow of the protocol state machine. As an example, and not a limitation, state machine violations include out-of-order message sending. Out-of-order message sending may include sending a Request message directly without receiving the Source_Capabilities message, or sending a data transmission message prematurely before the protocol handshake is completed. By injecting the above violation operations, it is possible to verify whether the USB PD chip 20 can correctly identify and handle protocol errors and perform error recovery according to the specification requirements.

[0051] The abnormal scenario construction unit 130 interacts with the USB PD chip 20 via an injection connection. When executing negative test cases, the abnormal scenario construction unit 130 injects various abnormal states into the state machine of the USB PD chip 20 through the protocol interface, observes and records the chip's response behavior to abnormal situations, thereby comprehensively evaluating the chip's abnormal handling capabilities and protocol compliance.

[0052] In some embodiments of this application, the parameterized test control unit 110, the protocol parsing and verification unit 120, the power parameter monitoring unit 150, the role switching management unit 140, and the abnormal scenario construction unit 130 work together through a modular integrated architecture to achieve comprehensive verification of the USB PD protocol chip 20.

[0053] Specifically, the collaborative work among the units is reflected in the following aspects: the test cases generated by the parameterized test control unit 110 provide the execution basis for other units; the protocol parsing and verification unit 120 provides the comparison benchmark for the power parameter monitoring unit 150; the status management of the role switching management unit 140 provides role consistency guarantee for the entire verification process; and the abnormal scenario construction unit 130 cooperates with other units to complete the abnormal verification during negative testing.

[0054] In some embodiments of this application, reference is made to Figure 2 As shown, a UVM-based USB PD protocol verification method is provided. This method is applied to the UVM-based USB PD protocol verification system described in the above embodiments, and specifically includes the following steps: Step S100: Configure test parameters and generate test cases through the parameterized test control unit.

[0055] In some embodiments of this application, the parameterized test control unit receives basic parameter configurations input by the tester. By way of example and not limitation, the basic parameters include message type, role identifier, test case type, and protocol request parameters. Message type may include standard message types defined by the USB PD protocol, such as Source_Capabilities, Request, Accept, Reject, and PS_RDY. The role identifier is used to specify the role the device under test should assume during the verification process, including Source, Sink, or DRP. The test case type explicitly specifies whether a positive or negative test case is being generated. The protocol request parameters contain specific voltage and current values, such as different power level configurations like 5V / 3A, 9V / 2A, and 12V / 1.5A.

[0056] The test case generation process employs a parameterized, driven approach. Specifically, the parameterized test control unit automatically generates complete message frames conforming to the USB PD protocol specification based on the input test parameters. The generation process includes: parsing the message type and determining the corresponding Message Header structure, filling the Data field content according to the protocol request parameters, automatically adding an SOP synchronization header to identify the message start mode, and calculating and appending a CRC32 checksum to ensure message integrity.

[0057] In some embodiments of this application, when the test case type is a positive test case, the parameterized test control unit generates a standard message that fully conforms to the protocol specification. As an example, and not a limitation, for the generation of the Request message, the parameterized test control unit constructs a compliant Request Data Object (RDO) based on the voltage and current values ​​in the protocol request parameters, and ensures that parameters such as the voltage range and current capability in the RDO match the PDO parameters in the previously received Source_Capabilities message.

[0058] Specifically, when the test case type is a negative test case, the parameterized test control unit configures exception mode parameters to trigger the exception state injection of the exception scenario construction unit. The configuration of exception mode parameters provides clear guidance for subsequent exception testing, ensuring the targeting and effectiveness of exception injection.

[0059] Step S200: Execute test cases. The USB PD protocol message is parsed in real time and its integrity is verified by the protocol parsing and verification unit. At the same time, the actual parameter value of the power output is obtained by the power parameter monitoring unit and compared with the protocol request parameter in a closed loop for verification.

[0060] In some embodiments of this application, the execution of test cases involves multiple parallel verification tasks. It is easy to understand that the parallel verification mechanism enables synchronous monitoring of the protocol layer and power layer, ensuring the comprehensiveness and accuracy of the verification results.

[0061] As an example and not a limitation, the working process of the protocol parsing and verification unit in step S200 includes: capturing protocol messages sent by the USB PD chip in real time through UVMMonitor; identifying and extracting the SOP type of the message to distinguish the message start mode by the SOP type identifier; parsing the message header by the Message Header parser to distinguish between control messages and data messages; extracting key information such as message source, protocol version and message type; and performing CRC32 verification on the protocol message in real time and comparing it with the CRC field in the message.

[0062] Specifically, when the CRC checker detects a check error, the system immediately reports and records the check anomaly through the UVM verification environment. As an example, and not a limitation, the handling of check anomalies includes recording detailed information such as the error timestamp, error type, and error data content, and triggering corresponding error recovery mechanisms, such as automatically sending a soft reset signal to reinitialize the protocol state.

[0063] In some embodiments of this application, the power parameter monitoring unit synchronously performs power output verification in step S200. It is easy to understand that the synchronous execution of power parameter verification and protocol parsing verification achieves closed-loop verification between protocol layer requests and physical layer outputs.

[0064] Specifically, the power parameter monitoring unit obtains the actual voltage and current values ​​of the USB PD chip's power output by sampling analog signals using an ADC or reading digital code output parameters. As an example, and not a limitation, the ADC sampling method uses a high-precision analog-to-digital converter to sample the chip's power output in real time, with a sampling frequency reaching thousands of times per second to ensure accurate capture of voltage and current changes. The digital code output method obtains the output parameter values ​​calculated by the chip by reading the register values ​​or digital output signals of the chip's internal power management unit.

[0065] The comparison process between actual parameter values ​​and protocol request parameters is conducted dynamically and in real-time. Specifically, the power parameter monitoring unit is configured with an error range, typically ±5% by default, and continuously compares the actual output value with the requested value determined through protocol negotiation. When an actual parameter value is detected to exceed the error range, the system immediately triggers an alarm mechanism (UVM_ERROR), records the deviation data, and generates an anomaly report.

[0066] Step S300: During the verification process, the role of the device is dynamically switched and the continuity of the protocol state is maintained by responding to the role identifier bit in the test case through the role switching management unit.

[0067] As an example, and not a limitation, when the role identifier in a test case indicates a switch from Source to Sink, the role switching management unit first caches the current protocol state information. This protocol state information includes key data such as the currently ongoing protocol interaction phase, negotiated voltage and current parameters, and the position information of the protocol state machine.

[0068] Specifically, the role switching process includes: sending a role switching command to the role management module of the USB PD chip, waiting for the chip to confirm the completion of the role switching, updating the role status in the verification system synchronously through hardware signals, restoring the previously cached protocol status information, and adjusting it to the status corresponding to the new role.

[0069] In some embodiments of this application, the maintenance of protocol state continuity is achieved through a state mapping and transition mechanism. It is easy to understand that there is a state correspondence between different roles, and the role switching management unit can correctly map the protocol state under the Source role to the corresponding state under the Sink role. As an example, and not a limitation, when switching from the Source role to the Sink role, the state that was originally waiting for a Request message will be transformed into a state ready to send a Request message. The negotiated voltage and current parameters remain unchanged, but the role responsibility changes. Through the state mapping mechanism, it is ensured that protocol interaction can continue seamlessly after the role switch.

[0070] In some embodiments of this application, the method further includes: Step S400: When executing negative test cases, generate and inject multiple types of abnormal states through the abnormal scenario construction unit to verify the abnormal handling capability of the device under test.

[0071] Step S400 is an exception verification step added based on steps S100-S300 above. As an example and not a limitation, step S400 can be executed during the protocol interaction process of step S200, or as an independent verification stage after step S300.

[0072] Specifically, the process of the abnormal scenario construction unit in executing negative test cases includes: the message format exception generator generates protocol messages with incorrect formats, including sending illegal format headers, setting incorrect CRC32 check values, and other abnormal situations; the timing violation simulator simulates protocol timing violation scenarios, including response timeouts, message conflicts, and other timing exceptions; and the state machine violation injector injects protocol state machine violations, including out-of-order message sending, illegal state transitions, and other state exceptions.

[0073] In some embodiments of this application, the verification process after anomaly injection includes monitoring the USB PD chip's ability to identify anomalies, recording the chip's anomaly handling response behavior, evaluating the effectiveness of the chip's error recovery mechanism, and verifying whether the chip handles anomalies according to protocol specifications. When an injected message format error occurs, the system monitors whether the USB PD chip can correctly identify CRC checksum errors, whether it sends the corresponding error response message as required by the protocol, and whether it can restore normal communication through retransmission or reset mechanisms. Through comprehensive anomaly verification, the reliability and protocol compliance of the USB PD chip under various anomaly conditions are ensured.

[0074] Unlike existing technologies, the embodiments of the present invention solve the technical problems of insufficient protocol depth analysis, disconnect between electrical parameters and protocol verification, and discontinuous role switching states in existing verification technologies. It realizes collaborative verification of the protocol layer and power layer, and improves the verification efficiency and coverage of USB PD protocol chips.

[0075] In some embodiments of this application, the practical application process of a UVM-based USB PD protocol verification system is described in detail, using the most basic Power Data Object (PDO) voltage regulation function in the USB PD protocol as an example. As an example and not a limitation, PDO voltage regulation verification is a core test scenario in USB PD protocol chip verification, capable of comprehensively verifying the chip's protocol parsing capabilities, power regulation capabilities, and anomaly handling capabilities. Specifically, the process includes the following: Step P100: Verify the environment setup and role configuration.

[0076] In some embodiments of this application, the PDO voltage regulation verification environment is constructed using the UVM verification methodology, mainly comprising two core components: the Device Under Test (DUT) layer and the UVM testbench layer. Specifically, the DUT layer is configured as a Source power supply, undertaking the functional responsibilities of a power supplier, responsible for sending power capability announcements, responding to power requests, and performing voltage and current regulation operations. The UVM Testbench layer integrates a protocol parsing and CRC check module, simulating the behavior of a Sink power receiving device, and is responsible for receiving power capability information, sending power requests, and verifying power output characteristics.

[0077] The separation of roles effectively simulates real-world USB PD protocol interaction scenarios. As an example, and not a limitation, the Source role (DUT) needs to have complete power management and protocol processing capabilities, while the Sink role (test platform) needs to have accurate protocol parsing and parameter verification capabilities.

[0078] Step P200: Source_Capabilities message reception, parsing and verification.

[0079] Specifically, the first stage of the PDO voltage regulation verification process is the reception and parsing verification of the Source_Capabilities message. In some embodiments of this application, the verification system first waits to receive the Source_Capabilities message sent by the DUT, which contains information on all power level options that the DUT can provide.

[0080] The parsing process of the Source_Capabilities message involves multiple levels of information extraction and verification. As an example, and not a limitation, when the protocol parsing and verification unit receives the Source_Capabilities message, the SOP type recognizer immediately performs SOP synchronization header type identification on the message, distinguishing between different synchronization header types such as SOP, SOP', and SOP'', and determining the message's transmission path and target object.

[0081] Specifically, the Message Header parser performs a detailed analysis of the message header, extracting key fields such as the protocol version (SpecRevision), message type (Message Type), data role, and power role. Parsing the Message Type field confirms that the current message is a data message of type Source_Capabilities. Extracting the protocol version field ensures version consistency in subsequent protocol interactions.

[0082] In some embodiments of this application, parsing the PDO parameters in the Data field is a core part of the Source_Capabilities message processing. Specifically, each PDO contains detailed parameter information for a specific power supply level, including key parameters such as minimum voltage (Vmin), maximum voltage (Vmax), and maximum current (Imax). As an example and not a limitation, for a fixed voltage PDO, the system extracts its voltage and current capability parameters; for a variable voltage PDO, the system extracts its voltage range and current capability parameters; and for a programmable power supply PDO, the system extracts its voltage range, current range, and power limit parameters.

[0083] The parsing results of PDO parameters directly affect the compliance verification of subsequent power requests. Specifically, the system categorizes and stores the parsed power supply level information, clearly defining the voltage range of each level (such as standard levels like 5V, 9V, 12V, 15V, 20V, etc.) and the corresponding current capacity (such as different current levels like 3A, 2A, 1.5A, etc.), providing an accurate reference benchmark for the subsequent generation of Request messages.

[0084] Step P300: CRC check and error handling mechanism.

[0085] In some embodiments of this application, the CRC checker performs real-time CRC32 check calculations on the received Source_Capabilities message. Specifically, the CRC check process covers the message's SOP sequence, Message Header, and complete Data field content, and is calculated using the CRC32 polynomial specified in the USB PD protocol.

[0086] It's easy to understand that the CRC check result processing mechanism directly affects the reliability of protocol interaction. As an example, and not a limitation, when the CRC check passes, the system marks the check status as "CRC_VALID" and stores the parsed PDO parameters in the register model, providing a data foundation for subsequent power negotiation. The stored procedure uses a structured data organization method, classifying and indexing different types of PDOs according to voltage levels, facilitating subsequent rapid retrieval and matching.

[0087] Specifically, when the CRC check fails, the system triggers the "CRC_ERROR" error handling procedure. The error handling procedure includes: immediately recording detailed information such as the timestamp of the error occurrence, the error type, and the error data content; automatically sending a Soft_Reset reset signal to reinitialize the protocol state; reporting the check anomaly to the verification environment through the UVM_ERROR mechanism; and triggering the error statistics and analysis mechanism to evaluate the data transmission reliability of the DUT.

[0088] Step P400: Execution process of the positive test scenario.

[0089] In some embodiments of this application, forward testing scenarios verify the functional correctness of the DUT under standard protocol interactions. Specifically, testers input voltage and current values ​​corresponding to the PDOs in Source_Capabilities into the test cases to verify the DUT's responsiveness to compliance requests.

[0090] As an example rather than a limitation, the PDO2 setting is selected for positive testing. It is assumed that the output voltage of PDO2 is 9V and the output current is 2A. It is easy to understand that the selection of the PDO2 setting is representative; it is neither the lowest nor the highest setting, and can effectively verify the DUT's medium power regulation capability.

[0091] Specifically, the parameterized test control unit automatically generates a Request message conforming to the USB PD protocol specification based on the 9V / 2A request value configured in the test case. The generation process of the Request message includes: constructing a Request Data Object (RDO), filling the RDO with parameters such as the location index of the target PDO, the requested operating current value, and the requested maximum current value, generating a compliant Message Header, setting the correct message type, data length, and other fields, and calculating and attaching a CRC32 checksum to ensure message integrity.

[0092] In some embodiments of this application, the UVM Driver sends the generated Request message to the DUT to initiate the power negotiation process. The sending process employs precise timing control to ensure that the message transmission timing conforms to the protocol specification requirements.

[0093] It's easy to understand that after receiving a Request message, the DUT needs to perform a request compliance check and make a response decision. Specifically, UVM Monitor continuously monitors the DUT's response behavior, capturing the Accept / Reject response messages sent by the DUT. In a forward testing scenario, since the requested 9V / 2A parameters perfectly match the PDO2's capability range, the DUT should send an Accept response message, indicating acceptance of the power request.

[0094] Specifically, receiving the Accept response confirms successful power negotiation at the protocol level. As an example, and not a limitation, the verification system immediately replies with a GoodCRC confirmation message after receiving the Accept message, completing the message-level handshake confirmation. Subsequently, the system waits to receive the PS_RDY (Power Supply Ready) message from the DUT. Receiving the PS_RDY message indicates that the DUT has completed power output adjustment and power parameter verification can begin.

[0095] Step P500: Closed-loop verification of power supply output parameters.

[0096] In some embodiments of this application, the receipt of the PS_RDY message triggers the power parameter monitoring unit to start operating. It is easy to understand that power parameter verification is a crucial step in PDO voltage regulation verification, directly verifying the power regulation accuracy and stability of the DUT.

[0097] Specifically, the power parameter monitoring unit acquires the actual voltage and current values ​​of the DUT power supply output through ADC sampling. The ADC sampling process employs a high-precision, high-sampling-rate configuration to ensure accurate capture of changes in power supply output parameters. As an example, and not a limitation, the ADC sampling accuracy reaches 12 bits or higher, and the sampling frequency is set to more than 1000 times per second, which can effectively capture the dynamic changes in the power supply output.

[0098] In some embodiments of this application, the UVM scoreboard implements comparison verification within a ±5% tolerance range. Specifically, the scoreboard compares the actual output value acquired by the ADC with the target value requested by the protocol in real time, calculating the percentage deviation of voltage and current. The comparison algorithm uses a moving average method to eliminate the influence of instantaneous fluctuations and ensure the reliability of the verification results.

[0099] It's easy to understand that setting a ±5% tolerance range aligns with the USB PD protocol specification's requirements for power output accuracy. As an example, and not a limitation, for a target voltage of 9V, the permissible output range is 8.55V-9.45V; for a target current of 2A, the permissible output range is 1.9A-2.1A. When the actual output value is within the tolerance range, the verification result is considered passed; when the actual output value exceeds the tolerance range, the system records the deviation data and marks the verification as failed.

[0100] Step P600: Execution process of abnormal test scenarios.

[0101] In some embodiments of this application, abnormal test scenarios verify the DUT's ability to handle non-compliant requests. Specifically, testers intentionally input voltage and current values ​​in test cases that do not correspond to the PDOs in Source_Capabilities to verify the DUT's anomaly detection and rejection capabilities.

[0102] As an example, not a limitation, we selected the PDO2 setting for anomaly testing and verification, intentionally inputting request parameters that did not match the PDO2's capabilities, such as an output voltage of 12V and an output current of 3A. It's easy to understand that the 12V / 3A request parameters clearly exceed the PDO2's 9V / 2A capability range, constituting a typical non-compliant power request.

[0103] Specifically, the parameterized test control unit generates a Request message containing erroneous parameters based on the 12V / 3A request value in the abnormal test case. Although the format and structure of the Request message conform to the protocol specification, the power request parameters it contains do not match the actual power supply capability of the DUT.

[0104] In some embodiments of this application, the UVM Driver sends a Request message containing abnormal parameters to the DUT to initiate abnormal request handling verification. It is easy to understand that after receiving an abnormal request, the DUT needs to perform a request compliance check to identify abnormal situations where the request parameters exceed its own power supply capacity.

[0105] Specifically, the UVM Monitor monitors abnormal response behavior of the DUT, expecting to capture Reject response messages sent by the DUT. In abnormal test scenarios, since the requested 12V / 3A parameter exceeds the capability range of the PDO2, the DUT should send a Reject response message to indicate that it refuses the current power request and maintains the original power output state.

[0106] As an example, not a limitation, the receipt of the Reject response confirms that the DUT possesses the correct anomaly detection and rejection handling capabilities. To further verify the DUT's recovery capabilities, the verification system subsequently sent a 9V / 2A request message matching the actual capabilities of PDO2 to verify whether the DUT could recover from the anomaly handling state to the normal power negotiation process.

[0107] Step P700: Verification of abnormal recovery of the protocol state machine.

[0108] In some embodiments of this application, post-anomaly testing recovery verification is an important component of anomaly handling capability assessment. Specifically, after receiving a Reject response from the DUT, the verification system resends a correct request message conforming to PDO2 capabilities to verify whether the DUT's protocol state machine can correctly recover to the normal negotiation state.

[0109] The recovery capability of the protocol state machine directly affects the reliability of the DUT in practical applications. As an example, and not a limitation, after sending a Reject response, the DUT's protocol state machine should return to the state of waiting for new requests, rather than remaining in the exception handling state or entering the error-locked state.

[0110] Specifically, the recovery verification process includes: sending the correct 9V / 2A power request, monitoring whether the DUT can correctly respond to the Accept message, verifying whether the DUT can send the PS_RDY message normally, and confirming whether the DUT's power output is adjusted to the correct 9V / 2A parameters. Successful recovery verification demonstrates that the DUT possesses good anomaly handling and state recovery capabilities.

[0111] Step P800: UVM environment reuse and extension mechanism.

[0112] In some embodiments of this application, the PDO voltage regulation verification environment adopts a modular design, supporting reuse and expansion across projects. Specifically, the basic UVM components in the verification environment (such as Monitor, Scoreboard, Driver, etc.) adopt a standardized interface design, which can be directly reused in different USB PD verification projects.

[0113] The UVM Factory overload mechanism provides flexible extensibility for protocol version adaptation. As an example, and not a limitation, when it is necessary to verify chips that support the USB PD 3.2 protocol, the protocol parsing component can be replaced by the Factory overload mechanism to achieve support for the new protocol version without rebuilding the entire verification environment.

[0114] Specifically, the environment reuse process includes: keeping the core verification logic unchanged, adjusting the range and number of PDO parameters through parameter configuration, updating the protocol parsing rules through Factory overload, and connecting to different DUT interfaces through interface adaptation. The implementation of this reuse mechanism significantly improves the development and maintenance efficiency of the verification environment.

[0115] In some embodiments of this application, the extension mechanism also supports verification of various PDO types, including fixed voltage PDO, variable voltage PDO, battery PDO, programmable power supply PDO, and other different types. Each PDO type has a corresponding parameter verification strategy and abnormal test scenarios, forming a complete PDO voltage regulation verification coverage matrix.

[0116] Step P900: Statistical analysis of verification results.

[0117] Specifically, after the PDO voltage regulation verification is completed, the system automatically generates a detailed verification report. The verification report includes analysis results from multiple dimensions, such as positive test result statistics, abnormal test result statistics, power output accuracy analysis, protocol interaction timing analysis, and anomaly handling capability assessment.

[0118] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above. For the sake of brevity, they are not provided in detail; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A UVM-based USB PD protocol verification system for comprehensive verification of USB PD protocol chips under normal and abnormal conditions, characterized in that, include: A parameterized test control unit is used to generate test cases in a configurable manner. Test case types include positive test cases and negative test cases; The protocol parsing and verification unit is used to parse USB PD protocol messages in real time and perform integrity verification. The power parameter monitoring unit is used to acquire the actual parameter values ​​of the power output and perform closed-loop comparison and verification with the protocol request parameters. The role switching management unit is used to dynamically switch the working roles of devices and maintain the continuity of protocol status during the verification process; The role switching management unit responds to the role identifier in the test case switching between the power supply end, the power receiving end, and the dual-role device, and automatically caches the current protocol status information when switching roles, and updates the status synchronously through hardware signals after the switch is completed; The protocol status information includes the protocol request parameters and the protocol state machine position information; the protocol request parameters include the requested voltage parameters and the requested current parameters. An abnormal scenario construction unit is used to generate and inject multiple types of abnormal states when executing the negative test cases to verify the abnormal handling capabilities of the device under test. The protocol parsing and verification unit includes an SOP type identifier, a message header parser, and a CRC checker. The SOP type identifier is used to identify and extract the SOP type of the USB PD protocol message and distinguish the message start mode. The message header parser is used to distinguish between control messages and data messages from the message header of the USB PD protocol message, and to extract the message source, protocol version and message type; The CRC checker is used to perform real-time CRC32 check calculation on the USB PD protocol message and compare the calculation result with the CRC field in the USB PD protocol message. When a CRC check error is detected, the UVM verification environment reports the check error and records it.

2. The system according to claim 1, characterized in that, The power parameter monitoring unit obtains the actual parameter value by sampling analog signals through an ADC or reading digital code output parameters, and sets a configurable error range to dynamically compare the actual parameter value with the protocol request parameter. When the actual parameter value is detected to exceed the error range, an alarm mechanism is triggered. The actual parameter value includes the actual voltage value and the actual current value output by the power supply.

3. The system according to claim 1, characterized in that, The abnormal scenario construction unit includes a message format exception generator, a timing violation simulator, and a state machine violation injector. The message format error generator is used to generate an error state of message format error, which includes sending an invalid header and setting an incorrect CRC32 checksum. The timing violation simulator is used to generate abnormal states of timing violations, including response timeouts and message conflicts. The state machine violation injector is used to generate abnormal states of state machine violations, including out-of-order message sending.

4. The system according to claim 1, characterized in that, The parameterized test control unit generates corresponding test cases by configuring test parameters; the test parameters include message type, role identifier bit, test case type, and protocol request parameters.

5. The system according to claim 4, characterized in that, When generating the positive test case, the parameterized test control unit generates a complete message frame according to the test parameters and the USB PD protocol specification. When generating the negative test case, the parameterized test control unit configures the abnormal mode parameter to trigger the abnormal state injection of the abnormal scenario construction unit.

6. The system according to claim 5, characterized in that, The parameterized test control unit adopts a templated design, which can be ported to a cross-project test environment by reusing the configuration method of the test parameters, the generation templates of the positive test cases and the negative test cases.

7. A UVM-based USB PD protocol verification method, applied to the UVM-based USB PD protocol verification system as described in any one of claims 1-6, characterized in that, include: Test parameters are configured and test cases are generated through the parameterized test control unit. The test cases are executed, and the USB PD protocol messages are parsed in real time and integrity is verified by the protocol parsing and verification unit. At the same time, the actual parameter values ​​of the power output are obtained by the power parameter monitoring unit and compared with the protocol request parameters in a closed loop for verification. During the verification process, the role switching management unit dynamically switches the device's working role and maintains the continuity of the protocol state by responding to the role identifier bit in the test case.

8. The method according to claim 7, wherein the test cases include positive test cases and negative test cases, characterized in that, Also includes: When executing the negative test cases, multiple types of abnormal states are generated and injected through the abnormal scenario construction unit to verify the abnormal handling capabilities of the device under test.

Images