UVM-based UFCS protocol verification IP system and method thereof

Abstract

The embodiment of the invention discloses a UVM-based UFCS protocol verification IP system and method, and the system comprises a UVM protocol driving unit which is used for generating UFCS protocol verification excitation and comprises a Baud rate training controller and a protocol wrapper; the UVM protocol analysis unit is used for verifying the UFCS protocol message received from the equipment to be tested and comprises a version self-adaptive decoder and a verification engine; the UVM intelligent monitoring unit is used for monitoring a protocol interaction process and performing compliance analysis, and comprises a violation detector and a coverage rate statistical model; and the UVM reusable test library is used for providing a standardized test sequence and an industrial standard test scene for the to-be-tested equipment and adjusting the test grade and the test content in response to a test adjustment instruction received by the configuration interface. According to the embodiment of the invention, the technical problems of insufficient compatibility verification, limited abnormal scene coverage, low verification efficiency and the like in UFCS protocol verification can be solved, full-stack verification from a physical layer to a protocol layer is realized, and the efficiency and reliability of UFCS protocol verification are improved.

Description

TECHNICAL FIELD

[0001] The embodiment of the application relates to the field of protocol verification, in particular to a UFCS protocol verification IP system based on UVM and a method thereof. BACKGROUND

[0002] With the popularity of mobile terminal devices and the increasing demand of users for charging speed, fast charging technology has become a key requirement to improve user experience. In order to unify the fast charging protocols of different manufacturers and realize the compatible mutual recognition between devices and chargers, the China Communications Standards Association (CCSA) formulates the mobile terminal fusion fast charging technology specification (Universal Fast Charging Specification, UFCS), aiming to establish a unified fast charging standard.

[0003] The UFCS protocol involves complex physical layer signal interaction and protocol layer state machine management, including multi-version protocol support (such as V1.0 / V2.0), dynamic baud rate training, message number management, CRC check and other technical aspects, and its correctness and reliability directly affect the charging safety and efficiency.

[0004] At present, the verification of fast charging chips mainly relies on traditional directed testing or script-based verification methods, which have the following technical problems: first, the protocol compatibility verification is insufficient. The UFCS protocol supports multi-version dynamic switching, and the traditional verification method is difficult to cover the interaction scenarios between different versions, which is easy to cause compatibility problems. Second, the abnormal scene coverage is limited. In the actual charging process, abnormal situations such as signal interference, CRC check error, timing timeout may be encountered, and the existing verification means is difficult to systematically simulate such scenarios, which affects the comprehensive verification of the robustness of the protocol. Third, the verification efficiency is low. Manually writing test cases is time-consuming and difficult to reuse, which cannot meet the rapid iteration development requirements, affecting the chip listing time. Finally, it is difficult to verify the standard compliance. The UFCS protocol requires strict compliance with the physical layer timing, protocol layer state machine jump and other specifications, and the traditional verification method is difficult to fully cover the test points specified in the standard, which is easy to cause compliance risks. SUMMARY

[0005] The technical problem solved by the embodiment of the application is to provide a UFCS protocol verification IP system based on UVM and a method thereof, which can solve at least part of the defects in the existing UFCS protocol verification.

[0006] In a first aspect, the embodiments of the present application provide a UFCS protocol verification IP system based on UVM, comprising: a UVM protocol driving unit configured to generate and send UFCS protocol verification stimuli, including a baud rate training controller and a protocol encapsulator; a UVM protocol analysis unit configured to analyze and check UFCS protocol messages received from a device under test, including a version adaptive decoder and a checking engine; a UVM intelligent monitoring unit configured to monitor protocol interaction processes with the device under test and perform compliance analysis, including a violation detector and a coverage statistical model; and a UVM reusable test library configured to provide standardized test sequences and industry standard test scenarios for the device under test, and adjust test levels and test contents in response to test adjustment instructions received by a configuration interface.

[0007] Optionally, the baud rate training controller is configured to perform retries according to a preset three-stage fixed deceleration sequence, and send a hardware reset signal to exit the UFCS mode when all stages fail.

[0008] Optionally, the UVM protocol driving unit further comprises a violation injector configured to dynamically inject UFCS protocol specific abnormal scenarios through a uvm_config_db.

[0009] Optionally, the protocol encapsulator further comprises a loop message number counter MsgNumberCounter configured to be cleared when the system is powered on or reset, and incremented when an ACK confirmation is received or a maximum number of retransmissions is reached, and send a retry signal to the system.

[0010] Optionally, the version adaptive decoder is configured to switch analysis rules according to UFCS protocol version identifiers; and the checking engine is configured to perform real-time checking on the protocol messages using a polynomial 0x29, and trigger a uvm_error to record error context information when the checking fails.

[0011] Optionally, the violation detector is configured to monitor timeout violations and timing abnormalities; and the coverage statistical model is configured to collect verification data of the protocol driving unit and the protocol analysis unit for coverage analysis.

[0012] Optionally, the violation detector comprises a plurality of timers, each of which is provided with a timeout upper threshold and / or a timing lower threshold, and when the protocol response time exceeds the upper threshold or is lower than the lower threshold, the violation detector is triggered to report a timeout violation and a timing abnormality, respectively.

[0013] Optionally, the coverage statistics model comprises: a physical layer coverage statistics module for monitoring baud rate training success rate, signal handshake timing and data packet acknowledgement coverage; and a protocol layer coverage statistics module for monitoring message type coverage and state machine transition coverage.

[0014] In a second aspect, the embodiment of the present application provides a UFCS protocol verification IP method based on UVM, applied to the UFCS protocol verification IP system based on UVM as described in the first aspect, and comprising: selecting a preset test case or a custom test scenario through a UVM reusable test library; performing three-gear baud rate adaptive training, retrying in a descending speed sequence, and sending a hardware reset signal to exit the UFCS mode when all gears fail; establishing a cyclic message number counter MsgNumberCounter, which is cleared when the device is powered on or reset, and is incremented when an ACK confirmation is received or the upper limit of the number of retransmissions is reached; dynamically switching the parsing rules based on the UFCS protocol version identification, and generating a compatibility verification report in a version mixed test scenario; detecting protocol timing by using a double-threshold mechanism, while monitoring timeout violations and timing too short exceptions; dynamically injecting UFCS protocol specific exception scenarios through uvm_config_db; and generating a hierarchical coverage statistics report in real time.

[0015] Optionally, the three-gear baud rate adaptive training comprises: retrying in a sequence of 115200bps→57600bps→38400bps, and synchronously clearing the MsgNumberCounter between protocol units by using a uvm_event mechanism.

[0016] The embodiment of the present application has the following beneficial effects: Different from the prior art, the embodiment of the present application can solve the technical problems of insufficient compatibility verification, limited exception scenario coverage and low verification efficiency in UFCS protocol verification, and achieve full-stack verification from the physical layer to the protocol layer, thereby improving the efficiency and reliability of UFCS protocol verification. BRIEF DESCRIPTION OF DRAWINGS

[0017] One or more embodiments are illustrated by way of example with reference to the accompanying drawings, which are schematic and not intended to be limiting of the embodiments, and in which like reference numerals designate similar items in the figures and wherein: the drawings are not to scale.

[0018] Figure 1 is a structural schematic diagram of a UFCS protocol verification IP system based on UVM provided by the embodiment of the present application; Figure 2 is a flowchart of a UFCS protocol verification IP method based on UVM provided by the embodiment of the present application. DETAILED DESCRIPTION

[0019] For the purpose of promoting the understanding of the present application, the present application will be described in further detail below in conjunction with the accompanying drawings and specific embodiments. It should be noted that when an element is referred to as being "fixed to" another element, it can be directly on the other element or one or more intervening elements can be present therebetween. When an element is referred to as being "connected to" another element, it can be directly connected to the other element or one or more intervening elements can be present therebetween. The terms "upper", "lower", "inner", "outer", "bottom", and the like as used in the present specification refer to the orientation or positional relationship as shown in the drawings, and are merely used for the purpose of facilitating the description of the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore should not be construed as limiting the present application. In addition, the terms "first", "second", "third", and the like are used only for the purpose of description and should not be construed as indicating or implying relative importance.

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

[0021] In addition, the technical features involved in the different embodiments of the present application described below can be combined with each other as long as there is no conflict.

[0022] The technical solutions in the present application will be described below in conjunction with the accompanying drawings.

[0023] In some embodiments of the present application, as shown in Figure 1 A UFCS (Universal Fast Charging Specification) protocol verification IP (Verification IP) system 10 based on UVM (Universal Verification Methodology) is provided for UFCS protocol verification of a device under test 20.

[0024] Specifically, the UFCS protocol verification IP system 10 based on UVM includes a UVM protocol driving unit 110, a UVM protocol parsing unit 120, a UVM intelligent monitoring unit 130, and a UVM reusable test library 140.

[0025] In some embodiments of the present application, the UVM protocol driving unit 110 is configured to generate and send UFCS protocol verification stimuli to the DUT 20, and the UVM protocol driving unit 110 includes a baud rate training controller and a protocol encapsulator. By way of example but not limitation, the baud rate training controller is responsible for establishing a physical layer communication connection with the DUT 20, and the protocol encapsulator is responsible for encapsulating verification data into a message format conforming to the UFCS protocol specification.

[0026] In particular, the UVM protocol parsing unit 120 is configured to parse and verify the UFCS protocol messages received from the DUT 20, and the UVM protocol parsing unit 120 includes a version adaptive decoder and a verification engine. In some embodiments of the present application, the version adaptive decoder is capable of dynamically adjusting the parsing rules according to the protocol version information, and the verification engine is responsible for integrity verification of the received protocol messages.

[0027] In some embodiments of the present application, the UVM intelligent monitoring unit 130 is configured to monitor the protocol interaction process with the DUT 20 and perform compliance analysis. In particular, the UVM intelligent monitoring unit 130 includes a violation detector and a coverage statistical model. By way of example but not limitation, the violation detector monitors abnormal situations in real time during the protocol interaction, and the coverage statistical model collects and analyzes coverage data during the verification process.

[0028] The UVM reusable test library 140 is configured to provide standardized test sequences and industry standard test scenarios for the DUT 20. In some embodiments of the present application, the UVM reusable test library 140 further adjusts the test level and test content in response to the test adjustment instructions received by the configuration interface, to adapt to different verification requirements.

[0029] In particular, the UVM protocol driving unit 110 is configured to generate and send UFCS protocol verification stimuli to the DUT 20, and the UVM protocol driving unit 110 includes a baud rate training controller and a protocol encapsulator. By way of example but not limitation, the baud rate training controller is responsible for establishing a physical layer communication connection with the DUT 20, and the protocol encapsulator is responsible for encapsulating verification data into a message format conforming to the UFCS protocol specification. Figure 1 As can be seen, the UVM protocol driving unit 110 is connected with the DUT 20, the UVM reusable test library 140, and the UVM intelligent monitoring unit 130, to realize generation and distribution of verification stimuli. The UVM protocol parsing unit 120 is connected with the DUT 20 and the UVM intelligent monitoring unit 130, to complete parsing of protocol responses and transmission of monitoring data. The UVM reusable test library 140 cooperates with the UVM intelligent monitoring unit 130 to provide test sequences and collect verification results.

[0030] In some embodiments of the present application, the UVM-based UFCS protocol verification IP system 10 described in Embodiment One is further described in detail in terms of specific constitution and functions of each unit.

[0031] The UVM protocol driver unit 110 inherits from the uvm_driver base class to obtain standard stimulus generation and transmission capabilities. The baud rate training controller, the protocol encapsulator, and the violation injector are functional modules of the uvm_driver and collectively implement the stimulus driving of the device under test 20.

[0032] In some embodiments of the present application, the protocol encapsulator encapsulates the UFCS protocol message using the uvm_transaction class, which provides standard data packing and unpacking methods. As an example but not limitation, the MsgNumberCounter is registered through the uvm_field_int macro to realize automatic field management and debugging support.

[0033] Specifically, the baud rate training controller dynamically generates a single-byte training sequence 0xAA using the uvm_sequence (UVM sequence) to support adaptive switching of three speed grades of 115200bps, 57600bps, and 38400bps, ensuring stable connection in different communication environments. As an example but not limitation, the rate switching event is synchronized through the uvm_event (UVM event mechanism) during the training process to avoid data loss, while supporting an automatic retry mechanism for training failure, and the maximum number of retries is configurable.

[0034] When the speed is reduced in the order of 115200bps→57600bps→38400bps, if all baud rate gears fail to try, a hardware reset signal is sent to exit the UFCS mode. In some embodiments of the present application, the baud rate training controller also has a failure diagnosis function, which can record the failure reason and the number of retries for each gear.

[0035] Specifically, the protocol encapsulator encapsulates the UFCS protocol message header using the uvm_transaction (UVM transaction), including the device address (3 bits, supporting the uvm_field_int macro registration), the message number (4 bits), the protocol version (6 bits, supporting dynamic switching of V1.0-V2.0), and the like. As an example but not limitation, the protocol encapsulator automatically calculates and appends the check code CRC-8 conforming to the target UFCS protocol specification, and uses the polynomial 0x29 for calculation.

[0036] In some embodiments of the present application, the UVM protocol driver unit 110 further includes a violation injector, which dynamically sets abnormal scenarios such as timer timeout, CRC-8 error, illegal command, or message format error through the uvm_config_db. It is not difficult to understand that the violation injector can simulate various abnormal situations that may be encountered during the real charging process, including but not limited to signal interference, transmission error, timing violation, and the like.

[0037] The UVM protocol analysis unit 120 inherits from the uvm_monitor base class, with passive monitoring and data collection capabilities. The version adaptive decoder and check engine are the core components of the uvm_monitor, responsible for protocol message parsing and verification.

[0038] In some embodiments of the present application, the analysis result is output through a uvm_analysis_port, which provides a standard data broadcast mechanism, allowing multiple monitoring components to receive analysis data simultaneously. As an example but not limitation, version information is stored and shared through uvm_resource_db, realizing cross-component version state synchronization.

[0039] Specifically, the protocol encapsulator establishes a loop counter MsgNumberCounter, which loops from 0 to 15. In some embodiments of the present application, the sender takes the current value of MsgNumberCounter and assigns it to the message number in the message header for each message it sends. As an example but not limitation, after the power supply device and the charging device are powered on, hardware reset or software reset, MsgNumberCounter must be cleared.

[0040] When the ACK returned by the receiver of the correctly received message is returned, or the currently sent message exceeds the maximum number of retries nMsgRetryCount, the sender of the message increases MsgNumberCounter by 1. In some embodiments of the present application, MsgNumberCounter is synchronized across components through the uvm_event mechanism to ensure data consistency between verification units.

[0041] Specifically, the version adaptive decoder reads the protocol version identifier through uvm_resource_db (UVM resource database), automatically switches the V1.0 / V2.0 instruction set parsing rules, supports mixed testing scenarios of new and old versions, and can provide version compatibility reports. In some embodiments of the present application, the analysis result is published through a uvm_analysis_port (UVM analysis port), including device address, message number, message type, and other key fields, and supports user-defined filtering conditions.

[0042] The check engine completes the check in the uvm_transaction::do_unpack (transaction unpacking method) phase, and triggers uvm_error and records error context such as error location, expected value / actual value, and other detailed information when the check fails. As an example but not limitation, the check engine supports CRC check bypass mode, controlled through uvm_config_db, used for debugging or forcing specific test cases to pass.

[0043] The UVM smart monitor unit 130 inherits from the uvm_scoreboard base class, providing data comparison and result determination functions. The violation detector and coverage statistics model are extended components of the uvm_scoreboard, implementing protocol compliance analysis and coverage statistics.

[0044] In some embodiments of the present application, the monitor unit receives data from the protocol analysis unit 120 through the uvm_analysis_port and outputs analysis results to the verification report system. By way of example but not limitation, error detection triggers the standard error handling process through the uvm_error mechanism.

[0045] In some embodiments of the present application, the violation detector performs device address checking to verify whether the transmitted device address is consistent with the actual device address, and supports black / white list mode, with illegal addresses triggering uvm_error directly. Specifically, message number checking can detect abnormal conditions such as skipping numbers and repeated numbers, and is associated with uvm_event to enable continuous monitoring across test cases.

[0046] By way of example but not limitation, the violation detector also performs message type checking to verify whether the message type code matches the message sending end and whether the message payload data is reasonable. The violation detector includes multiple timers, with timer checking supporting both double threshold detection (upper limit and lower limit) and single threshold detection (upper limit or lower limit). The threshold is usually set according to the protocol specification, and can also be dynamically adjusted through uvm_config_db.

[0047] In some embodiments of the present application, the violation detector integrates six standard timers in the UFCS protocol according to the Mobile Terminal Fusion Fast Charging Technical Specification: ACKReceiveTimer timer, SenderResponseTimer timer, PowerSuppleyTimer timer, CableInfoTimer timer, RestartTransTimer timer, and CableTransTimer timer.

[0048] Specifically, ACKReceiveTimer timer monitors the maximum time a sender waits for an ACK confirmation after sending a message. In some embodiments of the application, ACKReceiveTimer is started when a sender sends a message, and a ACK receive timeout violation report is triggered if no ACK confirmation is received before the timer expires. ACKReceiveTimer works closely with the retransmission mechanism of MsgNumberCounter, and the system decides whether to retransmit a message or mark a communication failure after the timer expires. By way of example and not limitation, the timeout value of this timer is set according to the UFCS protocol specification and can be configured for testing through uvm_config_db.

[0049] In some embodiments of the application, SenderResponseTimer timer monitors the maximum allowed time for a sender to respond to a received message. Specifically, when a device receives a UFCS protocol message that requires a response, SenderResponseTimer is started to ensure that the corresponding response message is sent within a specified time. If SenderResponseTimer expires without the response message being sent, the violation detector triggers a sender response timeout report and records the timeout context information through the uvm_error mechanism.

[0050] PowerSupplyTimer timer monitors the timing compliance of power supply related operations, including key power supply timing such as power output setup time and power adjustment response time. In some embodiments of the application, this timer is started after a power control command is issued, and monitors whether the actual power supply parameter reaches the target value within the specified time. PowerSupplyTimer timeout indicates that the power supply system is slow to respond or has a fault, and the violation detector generates a power supply timing violation report to provide important data for charging safety analysis.

[0051] CableInfoTimer timer monitors the completion time of the cable information acquisition process. Specifically, when the system initiates cable detection or cable information query, CableInfoTimer timer is started to ensure that cable parameters such as impedance, carrying capacity, etc. can be acquired within a reasonable time. CableInfoTimer timeout may indicate that the cable connection is poor, the cable is incompatible, or the detection circuit is faulty, and the violation detector triggers a cable information acquisition timeout report accordingly.

[0052] The RestartTransTimer timer monitors the timing requirement of the transmission restart procedure. When a communication error occurs and the transmission needs to be restarted, the RestartTransTimer timer is started to monitor the total time from the restart command to the normal resumption of the transmission. The expiration of the RestartTransTimer indicates a problem in the system restart mechanism or an abnormal response of the hardware, and the violation detector generates a transmission restart timeout report and can trigger a higher-level error recovery process.

[0053] The CableTransTimer timer monitors the timing performance of data transmission through the cable. Specifically, the timer monitors the transmission delay of data in the cable to ensure that the transmission time meets the requirements of the UFCS protocol for the transmission performance of the cable. When the CableTransTimer detects that the transmission delay is too large, it may indicate that the cable quality is poor, the length is too long, or there is transmission interference, and the violation detector generates a cable transmission timeout report. Specifically, the coverage statistical model includes a physical layer coverage statistical module and a protocol layer coverage statistical module. In some embodiments of the present application, the physical layer coverage includes D+D- signal handshake timing, data packet sending response, data packet sending response, bus conflict, hardware reset response, hardware reset signal review, etc. As an example but not limitation, the protocol layer coverage includes type coverage of all control messages, data messages and custom messages, and state machine jump coverage.

[0054] The UVM reusable test library 140 is built based on the uvm_sequence class and provides hierarchical test sequence management. Standard test sequences and custom test scenarios are implemented as subclasses of uvm_sequence, supporting sequence nesting and reuse.

[0055] In some embodiments of the present application, the test library organizes multiple test sequences through the uvm_sequence_lib mechanism, and users can flexibly select and combine according to verification requirements. As an example but not limitation, the execution parameters of the test sequence are configured and passed through uvm_config_db.

[0056] The UVM reusable test library 140 has built-in test procedures for all UFCS messages, and users can call the required messages in uvm_sequence_lib to assemble them by themselves. In some embodiments of the present application, the test library has built-in all test cases of physical layer and protocol layer in 《Mobile Terminal Fusion Fast Charging Test Method》, and compares the DUT behavior with the standard expected results in real time through the predefined UVM checker (Checker), and outputs the pass / fail report.

[0057] In particular, the test library configures test levels, such as L1 basic test / L2 enhanced test, through uvm_config_db, and supports custom test case plug-in. By way of example but not limitation, the standard test sequence covers core function verification scenarios, such as physical layer training packet transmission verification, protocol layer voltage negotiation test, response time test, and the like.

[0058] In particular, data exchange and event synchronization are implemented between units through a standard UVM communication mechanism. In some embodiments of the present application, uvm_config_db serves as a global configuration database, storing shared information such as test parameters, protocol configurations, and the like; and uvm_resource_db is used for runtime resource sharing, such as dynamic information such as protocol version status.

[0059] The uvm_event mechanism provides cross-component event notification functions, ensuring timing synchronization of key operations. By way of example but not limitation, MsgNumberCounter clear event, baud rate switching event, error detection event, and the like are broadcast and processed through uvm_event.

[0060] In some embodiments of the present application, the entire verification environment is built based on uvm_env (UVM environment base class), forming a standard verification platform architecture. In particular, uvm_test serves as a top-level test class, responsible for initialization of the verification environment and execution control of test cases.

[0061] By way of example but not limitation, the verification environment also includes a uvm_agent (agent) component, encapsulating driver, monitor, sequencer, and the like related components, providing a reusable verification IP interface. It is not difficult to understand that through the standard UVM architecture, the UFCS protocol verification IP can be seamlessly integrated with other UVM-compatible verification components, forming a more complex verification platform.

[0062] In some embodiments of the present application, based on the system architecture shown in Figure 1 The four core modules operate in coordination according to the following workflow to implement the complete UFCS protocol verification process.

[0063] First stage: test configuration stage In particular, the user selects a preset test case through the UVM reusable test library 140, which conforms to the Mobile Terminal Fusion Fast Charging Test Method standard, or the user can customize the test scenario. By way of example but not limitation, test parameters are dynamically configured through uvm_config_db, including target protocol version (V1.0 or V2.0), expected baud rate sequence, exception injection type, timing threshold, and the like key verification parameters.

[0064] The UVM reusable test library 140 sends the configured test instructions to the UVM protocol driver unit 110, and registers the expected verification behaviors and coverage targets to the UVM intelligent monitoring unit 130. In some embodiments of the present application, the configuration information is shared among the units through a standard UVM configuration database, ensuring the consistency of the verification environment.

[0065] Second stage: protocol driving stage In some embodiments of the present application, after receiving the test instructions, the UVM protocol driver unit 110 first performs dynamic baud rate training. Specifically, the baud rate training controller generates 0xAA training bytes in the descending sequence of 115200bps→57600bps→38400bps, and synchronizes the rate switching state with other units through the uvm_event mechanism.

[0066] By way of example but not limitation, the protocol encapsulator encapsulates the protocol message to be tested into a data packet conforming to the UFCS protocol specification, including a 3-bit device address, a 4-bit message number (provided by MsgNumberCounter), a 6-bit protocol version identifier, and automatically calculates a CRC-8 check code (polynomial 0x29). It is not difficult to understand that if abnormal injection is configured, the violation injector injects timer timeout, CRC error or illegal command format through the parameters set by uvm_config_db.

[0067] Third stage: device under test interaction stage Specifically, the test stimulus sent by the UVM protocol driver unit 110 is transmitted to the device under test 20 through the IP interface. In some embodiments of the present application, the transmission process is realized through D+ / D- differential signal lines, supporting the physical layer signal interaction specified in the UFCS protocol. By way of example but not limitation, the device under test 20 processes the received stimulus according to its built-in UFCS protocol stack, and generates a corresponding protocol response.

[0068] The response message of the device under test 20 is actively uploaded to the UVM protocol analysis unit 120 through the monitoring channel. In some embodiments of the present application, the monitoring channel can capture the complete protocol interaction process, including the handshake sequence, data transmission, state transition and other key information.

[0069] Fourth stage: protocol analysis stage In some embodiments of the present application, the UVM protocol analysis unit 120 processes the UFCS protocol message from the device under test 20 in real time. Specifically, the version adaptive decoder first reads the protocol version identifier through uvm_resource_db, and automatically switches the corresponding instruction set analysis rules according to the detected V1.0 or V2.0 version.

[0070] As an example but not limitation, the decoder performs field-level parsing, extracting device address, message number, message type, and other key field information. It is appreciated that the check engine performs CRC-8 check in the uvm_transaction::do_unpack phase, using the same polynomial 0x29 as the sender, sending ACK confirmation message when the check passes, and sending NACK negative acknowledgement and triggering uvm_error with detailed error context information when the check fails.

[0071] In particular, the parsing results are published to the UVM smart monitoring unit 130 and the UVM protocol driver unit 110 through uvm_analysis_port. In some embodiments of the present application, when an ACK confirmation message is detected, the version-adaptive decoder feeds back the ACK status to the protocol encapsulator, triggering the increment operation of the MsgNumberCounter.

[0072] Fifth stage: smart monitoring stage The UVM smart monitoring unit 130 receives the parsing data from the UVM protocol parsing unit 120 and the sending data from the UVM protocol driver unit 110, implementing full-process verification monitoring. In some embodiments of the present application, the violation detector simultaneously performs multiple compliance checks.

[0073] In particular, the device address legality check verifies whether the sent and received device addresses conform to the UFCS protocol specification; the message continuity check monitors whether the increment of the MsgNumberCounter is correct, whether there is a number jump or repeated number; the timing constraint check uses a double-threshold mechanism to monitor whether the protocol response time is within the specified upper and lower limits.

[0074] As an example but not limitation, the coverage statistics module collects physical layer indicators (such as baud rate training success rate, D+D- signal handshake timing, data packet response coverage) and protocol layer indicators (such as message type coverage, state machine transition coverage). In some embodiments of the present application, the statistical results are output through uvm_analysis_port structured report, including error positioning information, coverage percentage, compliance analysis, and other detailed data.

[0075] In particular, the synchronization of key events among units is realized through uvm_event, including the MsgNumberCounter zero-clearing event, the baud rate switching event, the error detection event, and the like. It is appreciated that when the system detects a hardware reset or a software reset, the uvm_event mechanism ensures that all units perform the MsgNumberCounter zero-clearing operation synchronously.

[0076] In some embodiments of the present application, when the baud rate training controller switches the baud rate level, other units are notified to adjust the corresponding timing parameters through uvm_event. As an example but not limitation, when the violation detector detects a serious protocol violation, the UVM protocol driver unit 110 is notified to stop sending and start the error recovery process through the uvm_event mechanism.

[0077] Specifically, the state information of the entire verification process is shared among units through uvm_config_db, ensuring global consistency of the verification environment. It is not difficult to understand that through the above-mentioned cooperative working mechanism, the system 10 can realize comprehensive and in-depth verification of the UFCS protocol implementation of the device under test 20, covering various verification scenarios such as normal function, exception handling, boundary condition, etc.

[0078] Unlike the prior art, the embodiments of the present application can solve the technical problems of insufficient compatibility verification, limited exception scenario coverage, and low verification efficiency in UFCS protocol verification, realize full-stack verification from the physical layer to the protocol layer, and improve the efficiency and reliability of UFCS protocol verification.

[0079] In some embodiments of the present application, a UVM-based UFCS protocol verification IP method is provided, which is applied to the UVM-based UFCS protocol verification IP system 10 as described in Embodiment I and Embodiment II, and a flowchart thereof is shown in Figure 2 As shown in the figure, the method specifically comprises the following steps: Step S100: Select a preset test case or a custom test scenario through a UVM reusable test library.

[0080] In some embodiments of the present application, the preset test case conforms to the "Mobile Terminal Fusion Fast Charging Test Method" standard, and the selection of the test case determines the execution content and parameter configuration of all subsequent verification steps, including L1 basic compatibility testing, L2 enhanced stress testing, and different levels. As an example but not limitation, the user can also configure a custom test scenario according to specific verification requirements, and set the corresponding test parameters and verification targets through uvm_config_db.

[0081] Specifically, the selected test case distributes configuration information to each verification unit, providing a unified verification benchmark and parameter configuration for subsequent steps such as bit rate training, message management, protocol parsing, timing monitoring, and exception injection.

[0082] It should be noted that in this step, the test case generated by the preset test case and the custom test scenario specifically refers to a forward test case, which is used to verify the correctness of the function of the device under test under normal UFCS protocol interaction, to realize forward function verification testing.

[0083] Specific examples of forward test cases include, but are not limited to, the following examples: a standard protocol handshake test verifies whether the device can complete the complete process of device identification, capability negotiation, and connection establishment according to the UFCS protocol specification, and the expected result is that the handshake is successful and an effective communication link is established; a voltage negotiation function test verifies whether the charging device and the power supply device can correctly negotiate a safe and effective charging voltage, including steps such as voltage request sending, voltage capability query, and voltage adjustment confirmation, and the expected result is that the negotiated voltage value is within the support range of both parties and meets the safety standards; a cable detection function test verifies whether the system can correctly identify cable parameters, including cable impedance measurement, maximum carrying current detection, and maximum carrying voltage detection, and the expected result is to accurately obtain cable characteristic parameters and use them for subsequent power limitation; a message transmission integrity test verifies the correct sending and receiving of various UFCS protocol messages, including control messages, data messages, and status messages, and the expected result is that the message transmission has no loss, the CRC check passes, and the ACK / NACK response is correct.

[0084] Step S200: Perform three-gear baud rate adaptive training, retry in descending order, and send a hardware reset signal to exit the UFCS mode when all gears fail.

[0085] Specifically, three-gear baud rate adaptive training is performed, and retry is performed in the sequence of 115200 bps→57600 bps→38400 bps. When all gears fail, a hardware reset signal is sent to exit the UFCS mode.

[0086] In some embodiments of the present application, the baud rate training process is performed using a single-byte training sequence 0xAA. Specifically, the training sequence is first sent at a rate of 115200 bps, and if the training fails, the speed is automatically reduced to 57600 bps for retry, and if it still fails, the speed is further reduced to 38400 bps. As an example but not limitation, the maximum number of retries for each speed gear can be configured through uvm_config_db.

[0087] Specifically, when all three baud rate gears fail, the system sends a hardware reset signal to forcibly exit the UFCS mode. It is not difficult to understand that the rate switching event is synchronized through the uvm_event mechanism during the training process to avoid data loss, and the training results and failure reasons of each gear are recorded to provide a basis for subsequent analysis.

[0088] Step S300: Establish a cyclic message number counter MsgNumberCounter, which is cleared when the device is powered on or reset, and is incremented when an ACK confirmation is received or the upper limit of the number of retransmissions is reached.

[0089] Specifically, a cyclic message number counter, MsgNumberCounter, is established, which is cleared when the device is powered on or reset, and is incremented when an ACK confirmation is received or the maximum number of retransmissions is reached. In some embodiments of the present application, MsgNumberCounter is 4 bits wide, supporting a cyclic count mode of 0 to 15.

[0090] By way of example but not limitation, MsgNumberCounter must be automatically cleared when the power supply device and the charging device are powered on, hardware reset, or software reset. It is understood that the sender assigns the message number field in the message header with the current value of MsgNumberCounter for each message it sends.

[0091] Specifically, in some embodiments of the present application, the sender of the message increments MsgNumberCounter by 1 when the ACK confirmation returned by the receiver of the message is correctly received, or the maximum number of retransmissions nMsgRetryCount is exceeded. By way of example but not limitation, the cross-component synchronization clearing of MsgNumberCounter between protocol units is implemented through the uvm_event mechanism, ensuring that the counter state of all related components in the verification environment remains consistent.

[0092] Step S400: Based on the UFCS protocol version identifier, dynamically switch the parsing rules, and generate a compatibility verification report in a version mixed test scenario.

[0093] Specifically, the system reads the protocol version identifier through uvm_resource_db, and automatically identifies the protocol version of the current interaction.

[0094] By way of example but not limitation, when the V1.0 version identifier is detected, the system switches to the V1.0 instruction set parsing rule; when the V2.0 version identifier is detected, the system switches to the V2.0 instruction set parsing rule. It is understood that in the version mixed test scenario, the system can handle the interaction between V1.0 and V2.0 version devices, and verify the correctness of the downward compatibility and protocol migration.

[0095] Specifically, the parsing process includes message header field extraction, message type identification, payload data parsing, and other steps. In some embodiments of the present application, the system generates a version compatibility verification report in real time, recording key indicators such as interaction success rate, failure reason, performance difference, and the like between different versions.

[0096] Step S500: Adopt a double-threshold mechanism to detect protocol timing, while monitoring timeout violations and timing too short exceptions.

[0097] Specifically, the system sets an upper threshold of timeout and a lower threshold of timing, triggers a timeout violation report when the protocol response time exceeds the upper threshold, and triggers a timing anomaly report when the protocol response time is below the lower threshold.

[0098] In some embodiments of the present application, the upper threshold is used to detect response timeout conditions, ensuring that protocol interactions are completed within a specified time; the lower threshold is used to detect timing too short anomalies, preventing fast responses that do not meet protocol specifications. As an example but not limitation, the threshold parameters are set according to the UFCS protocol specification, and can also be dynamically adjusted by uvm_config_db to adapt to different test requirements.

[0099] Specifically, the timing detection covers key protocol links such as the handshake phase, data transmission phase, state transition phase, etc. It is not difficult to understand that when a timing violation is detected, the system records detailed timing information, including actual response time, expected time range, violation type, etc., providing accurate data for problem location.

[0100] Step S600: Dynamically inject UFCS protocol-specific exception scenarios through uvm_config_db.

[0101] Specifically, UFCS protocol-specific exception scenarios are dynamically injected through uvm_config_db, negative testing verification is implemented, and the abnormal handling capability of the device under test is verified to meet the protocol specification. The exception injection includes timer timeout, CRC-8 check error, illegal command format error, etc. Timer timeout exception is achieved by artificially prolonging or blocking the response time, including ACKReceiveTimer timeout, SenderResponseTimer timeout, PowerSupplyTimer timeout, CableInfoTimer timeout, RestartTransTimer timeout, and CableTransTimer timeout, etc. six standard timer timeout scenarios.

[0102] The CRC-8 check error exception is achieved by intentionally modifying the CRC-8 check code of the message. The violation injector replaces the correct CRC-8 value (based on the polynomial 0x29) with an error value in the protocol packaging stage, verifying whether the device under test 20 can correctly detect and return a NACK response.

[0103] In some embodiments of the present application, illegal command format error includes various protocol violation types. Specifically, it includes device address field error (out of 3bit range or using reserved address), message number field violation (skipping or repeated use), protocol version field error (unsupported version number), message type field violation (undefined message type), etc.

[0104] In some embodiments of the application, the abnormal scenario injection is aimed at generating positive test cases for verifying the processing capability of the device under test for normal protocol operation. When executing the positive test cases, the system sends normal UFCS protocol messages according to the test cases, and expects the device under test to correctly process the messages according to the UFCS protocol specification.

[0105] Specific examples of the positive test cases include, but are not limited to, the following examples: in the CRC check error processing test, the system intentionally sends UFCS protocol messages with correct CRC-8 check codes, and expects the device under test to correctly process the messages according to the UFCS protocol specification, such as sending ACK responses, starting error recovery mechanisms, etc.; in the timer timeout processing test, the system intentionally sends UFCS protocol messages with correct CRC-8 check codes, and expects the device under test to correctly process the messages according to the UFCS protocol specification, such as sending ACK responses, starting error recovery mechanisms, etc.

[0106] Step S700: Real-time generation of hierarchical coverage rate statistical report.

[0107] Specifically, the hierarchical coverage rate statistics include two dimensions of physical layer coverage rate and protocol layer coverage rate. In some embodiments of the application, the physical layer coverage rate statistics monitor the baud rate training success rate, signal handshake timing coverage, data packet response coverage, etc.; the protocol layer coverage rate statistics monitor the message type coverage, state machine transition coverage, abnormal processing path coverage, etc.

[0108] Specifically, the physical layer coverage rate statistics include bit rate training coverage rate analysis, which analyzes and counts the training success rate, failure rate, retry number distribution, etc. of the three gears of 115200bps, 57600bps, 38400bps, and the complete execution coverage of the speed-down sequence.

[0109] In some embodiments of the application, the signal handshake timing coverage rate monitors the handshake process of the D+D-differential signal, including signal setup time coverage, handshake sequence integrity coverage, handshake failure recovery coverage, etc. physical layer interaction indicators; the data packet response coverage rate counts the transmission-response pairing integrity of each UFCS protocol message type, records the distribution of ACK / NACK responses, response time delay distribution, packet loss retransmission coverage, etc. transmission layer indicators.

[0110] The protocol layer coverage statistics include message type coverage analysis. The analysis counts the sending and receiving coverage of all defined control messages, data messages, and status messages in the UFCS protocol, ensuring that each message type in the protocol specification is verified.

[0111] In some embodiments of the present application, the state machine transition coverage monitors all state transition paths of the UFCS protocol state machine, including normal state transitions (such as from the handshake state to the negotiation state), abnormal state transitions (such as from the negotiation state to the error recovery state), boundary state transitions, etc.; the protocol version coverage statistics count the test coverage of V1.0 and V2.0 versions, and the coverage of the compatibility test between versions, and record indicators such as version switching success rate and compatibility test pass rate.

[0112] It should be noted that the generation of the hierarchical coverage statistics report covers two dimensions of positive functional verification coverage and negative exception handling coverage. Specifically, the positive test coverage counts the verification integrity of the UFCS protocol function, including indicators such as protocol handshake success rate, message type coverage, and state machine normal transition coverage; the negative test coverage counts the verification integrity of the abnormal scenario, including indicators such as abnormal injection coverage, abnormal handling path coverage, and error recovery mechanism verification coverage.

[0113] The specific UFCS protocol verification process is as follows: In some embodiments of the present application, the pre-built UVM verification environment is first reused to establish a physical connection. Specifically, the device under test 20 (power supply device) and the UVM test environment (charging device) are interconnected through the D+ / D- interface to form a complete UFCS protocol verification topology.

[0114] As an example but not limitation, the UVM protocol driving unit 110 performs the UFCS handshake protocol according to the requirement of the device under test 20 to enter the DCP (Dedicated Charging Port) state. It is not difficult to understand that the handshake process includes key steps such as device identification, capability negotiation, and connection confirmation.

[0115] Specifically, the system performs the baud rate training of step S200, and determines the optimal communication rate using an adaptive speed reduction strategy. In some embodiments of the present application, the uvm_event is used to synchronize the optimal baud rate selection result, ensuring the stability of subsequent communication.

[0116] In some embodiments of the application, the "Start_Cable_Detect" test sequence is invoked from the test library, and the cable parameters parsed by the parsing unit include key parameters such as cable impedance, maximum bearing voltage, maximum bearing current, etc. As an example but not limitation, after the detection is completed, the "End_Cable_Detect" end detection process is sent.

[0117] Specifically, the "Get_Source_Info" test sequence is invoked from the test library, the drive unit sends an information request, and the parsing unit decodes the power supply capability information, including parameters such as maximum voltage and maximum current. It is not difficult to understand that the monitoring system records the power characteristic parameters, which provides the basis for subsequent power negotiation.

[0118] In some embodiments of the application, the "Request" test sequence is invoked from the test library, and the user configures the target voltage / current parameters through the uvm_config_db. Specifically, the drive unit generates a compliance request message containing CRC-8 check, and the monitoring system verifies the "Power_Ready" response timing of the device under test 20.

[0119] As an example but not limitation, the user-defined test scenario is executed, and all test cases of the "Mobile Terminal Fusion Fast Charging Test Method" physical layer and protocol layer are automatically run. It is not difficult to understand that the extended test phase can cover complex verification scenarios such as boundary conditions, exception handling, and long-time running.

[0120] Specifically, the monitoring system performs real-time protocol field compliance checks (address / message number), message type validity verification, timer constraint detection (response timeout window), and other analysis tasks. In some embodiments of the application, a multi-dimensional coverage report is generated, including detailed statistical data such as physical layer index coverage and protocol layer message type coverage (100%), state machine transition coverage, etc.

[0121] It is not difficult to understand that through the above method embodiments, the automation, standardization and systematization of UFCS protocol verification can be realized. In some embodiments of the application, the method has dynamic adaptability, and key parameters such as protocol version, baud rate, and exception injection can be configured at runtime to adapt to the needs of different fast charging chips.

[0122] Finally, it should be noted that: the above examples are only used to illustrate the technical solutions of the present application, but not to limit them; under the idea of the present application, the technical features in the above examples or different embodiments can also be combined, the steps can be implemented in any order, and there are many other changes of different aspects of the present application as described above. In order to be brief, they are not provided in detail; although the present application has been described in detail with reference to the foregoing examples, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing examples, or make equivalent replacement for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A UFCS protocol authentication IP system based on UVM, characterized in that, include: The UVM protocol driver unit is used to generate and send UFCS protocol verification stimuli, including a baud rate training controller and a protocol wrapper. The UVM protocol parsing unit is used to parse and verify UFCS protocol messages received from the device under test, including a version adaptive decoder and a verification engine. The UVM intelligent monitoring unit is used to monitor the protocol interaction process with the device under test and perform compliance analysis, including a violation detector and a coverage statistical model. The UVM reusable test library provides standardized test sequences and industry-standard test scenarios for the device under test, and adjusts the test level and test content in response to test adjustment commands received from the configuration interface.

2. The system according to claim 1, characterized in that, The baud rate training controller is used to perform retries according to a preset three-speed fixed deceleration sequence. When all speeds fail, a hardware reset signal is sent to exit UFCS mode. The protocol encapsulator is used to encapsulate the protocol message to be tested into a data packet conforming to the UFCS protocol specification, and automatically calculates and adds a checksum.

3. The system according to claim 1, characterized in that, The UVM protocol driver unit also includes a violation injector, which dynamically injects UFCS protocol-specific abnormal scenarios through uvm_config_db.

4. The system according to claim 1, characterized in that, The protocol encapsulator also establishes a cyclic message number counter MsgNumberCounter, which is cleared when the system is powered on or reset, incremented when an ACK confirmation is received or the maximum number of retransmissions is reached, and a retry signal is sent to the system.

5. The system according to claim 1, characterized in that, The version adaptive decoder is used to switch the parsing rules according to the UFCS protocol version identifier; The verification engine is used to perform real-time verification of the protocol message using polynomial 0x29. When the verification passes, an ACK confirmation message is sent through the protocol encapsulator. When the verification fails, a NACK negative response is sent and uvm_error is triggered to record error context information.

6. The system according to claim 1, characterized in that, The violation detector is used to monitor timeout violations and timing anomalies; The coverage statistical model is used to collect verification data from the protocol driver unit and the protocol parsing unit for coverage analysis.

7. The system according to claim 6, characterized in that, The violation detector includes multiple timers, each set with an upper timeout threshold and / or a lower timing threshold. When the protocol response time exceeds the upper limit or falls below the lower limit, the violation detector triggers a timeout violation report and a timing anomaly report, respectively.

8. The system according to claim 6, characterized in that, The coverage statistical model includes: The physical layer coverage statistics module is used to monitor baud rate training success rate, signal handshake timing, and data packet response coverage. The protocol layer coverage statistics module is used to monitor message type coverage and state machine transition coverage.

9. A UVM-based UFCS protocol verification IP method, applied to the UVM-based UFCS protocol verification IP system as described in any one of claims 1-8, characterized in that, include: The UVM reusable test library allows you to select preset test cases or custom test scenarios. Perform three-level baud rate adaptive training, retry according to the speed reduction sequence, and send a hardware reset signal to exit UFCS mode when all levels fail. Establish a circular message number counter MsgNumberCounter, which is cleared when the device is powered on or reset, and incremented when an ACK is received or the maximum number of retransmissions is reached. Based on the UFCS protocol version identifier dynamic switching resolution rules, a compatibility verification report is generated in mixed version testing scenarios; A dual-threshold mechanism is used to detect protocol timing, simultaneously monitoring for timeout violations and excessively short timing anomalies; Dynamically inject UFCS protocol-specific exception scenarios through uvm_config_db; Generates tiered coverage statistics reports in real time.

10. The method according to claim 9, characterized in that, The three-baud rate adaptive training includes: retrying at a reduced speed in sequence from 115200bps to 57600bps to 38400bps, and using the uvm_event mechanism to synchronize and clear the MsgNumberCounter across protocol units.

Images