UVM verification system and method based on SPI protocol and multichannel PD protocol conversion

Abstract

The invention discloses a UVM verification system and method based on SPI protocol and multi-channel PD protocol conversion, and belongs to the technical field of digital verification. The UVM verification system comprises a configuration management module, an SPI agent module, a PD agent module and a protocol conversion module; the configuration management module is used for generating a transaction data packet through the configured constraint parameters; the SPI agent module is used for receiving the SPI transaction data packet, performing ordered analysis, generating a time sequence excitation signal, issuing the time sequence excitation signal, obtaining an SPI side signal, and generating an SPI decoded data packet through decoding and reduction; the PD agent module is used for receiving the PD transaction data packet, orderly analyzing the PD transaction data packet, generating a physical waveform signal, issuing the physical waveform signal, obtaining a PD side signal, and generating a PD decoding data packet through decoding reduction; the protocol conversion module comprises a reference unit and a scoreboard; the reference unit is used for generating an expected data packet by simulating a bidirectional protocol conversion behavior; and the scoreboard is used for receiving the decoded data packet and the expected data packet, performing field-by-field consistency comparison and recording a verification result.

Description

Technical Field

[0001] This invention relates to a UVM verification system and method based on SPI protocol and multi-channel PD protocol conversion, belonging to the field of digital verification technology. Background Technology

[0002] With the increasing integration of System-on-Chip (SoC) and Power Management Chip (PMIC), the number and complexity of on-chip and off-chip communication interfaces are also growing rapidly. Existing serial communication protocols and the emerging PD protocol are widely used in terminal devices. SPI, due to its simple structure, flexible timing, and ability to support high data rates, is often used for data exchange between MCUs and peripherals. As a core component of the USB Type-C interface, the USB PD protocol uses BMC physical layer encoding and features a fixed rate, a strict header structure, CRC checksum, and a complex control / data message system. In applications such as multi-port fast charging, laptop adapters, and power management ICs, multi-channel PD has become the mainstream configuration.

[0003] Because SPI and PD differ significantly at both the physical and protocol layers, the main control MCU cannot directly perform real-time parsing and protocol stack management of multi-channel PDs. Therefore, a dedicated SPI-PD protocol conversion circuit is usually required. However, most existing UVM verification architectures are built around a single protocol and lack the ability to compare data across protocols, making it difficult to jointly model and verify the bidirectional conversion link between SPI and PD. Summary of the Invention

[0004] To address the shortcomings of existing technologies, the present invention aims to provide a UVM verification system and method based on SPI protocol and multi-channel PD protocol conversion. By generating data packets through bidirectional configuration of SPI / PD, scheduling, encoding and decoding to drive the device under test, synchronously acquiring the decoding output, and combining a unified transaction configuration class to simulate conversion to generate the expected data packets and compare them field by field, bidirectional joint modeling and cross-protocol comparison are achieved, thus overcoming the limitations of existing architectures.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A UVM verification system based on SPI protocol and multi-channel PD protocol conversion includes: a configuration management module, an SPI proxy module, a PD proxy module, a protocol conversion module, and an interface adaptation module;

[0007] The configuration management module is used to generate transaction data packets, including SPI transaction data packets and PD transaction data packets, based on the configured constraint parameters.

[0008] The SPI proxy module parses the SPI transaction data packets in an orderly manner, generates timing excitation signals, and sends them to the SPI signal domain of the device under test. This allows it to obtain the SPI side signals generated by the device under test, decode and restore them, and generate SPI decoded data packets containing PD information.

[0009] The PD proxy module is used to receive PD transaction data packets and perform ordered parsing to generate physical waveform signals. Combined with the corresponding channel allocation results, the signals are sent to the corresponding PD channels of the device under test. At the same time, the module acquires the PD-side signals generated by the device under test and decodes and restores them to generate PD decoded data packets.

[0010] The protocol conversion module includes a reference unit and a scoring board;

[0011] The reference unit is used to receive SPI transaction data packets and PD transaction data packets, and, in conjunction with constraint parameters, simulate bidirectional protocol conversion behavior and generate expected data packets, including SPI expected data packets and PD expected data packets.

[0012] The scoring board is used to receive decoded data packets and expected data packets, perform field-by-field consistency comparisons, and record the verification results.

[0013] The interface adapter module is used to provide signal connection channels.

[0014] Specifically, the SIP proxy module includes an SPI sequence scheduling unit, an SPI driver unit, and an SPI monitoring unit;

[0015] The SPI sequence scheduling unit is used to receive SPI transaction data packets, configure transaction priorities for each transaction data packet through queue management to distinguish between normal transactions and special time-series transactions, and forward the SPI transaction data packets to the SPI driver unit in an orderly manner according to the divided transaction priorities.

[0016] The SPI driver unit is used to receive SPI transaction data packets in sequence, parse the transaction data packets, generate timing excitation signals, and drive the timing excitation signals to the SPI signal domain of the device under test through the interface adapter module.

[0017] The SPI monitoring unit is used to acquire the SPI side signals generated by the device under test, and generate SPI decoded data packets containing PD information by decoding and restoring them.

[0018] Specifically, the PD agent module includes a PD sequence scheduling unit, a PD driving unit, and a PD monitoring unit;

[0019] The PD sequence scheduling unit is used to receive PD transaction data packets, allocate channels for PD transaction data packets through multi-channel selection, and send them to the PD driver unit through the channels;

[0020] The PD driver unit is used to encode the received PD transaction data packets through the physical layer, generate physical waveform signals, and drive the physical waveform signals to the corresponding PD channel of the device under test through the interface adapter module.

[0021] The PD monitoring unit is used to acquire the PD-side signal generated by the device under test, and generate a PD decoded data packet by decoding and restoring it.

[0022] Specifically, queue management includes:

[0023] Based on the received SPI transaction data packets, a first-in-first-out master queue is constructed to store data packets to be scheduled;

[0024] Obtain priority rules, iterate through the data packets to be scheduled in the main queue, and assign priority labels based on the scenario identifier;

[0025] Based on priority labels, the data packets to be scheduled are classified into normal transaction data packets and special time-series transaction data packets, and stored in corresponding queues, including high priority queues and ordinary queues.

[0026] Real-time query of the SPI driver unit's operating status, including idle and busy status;

[0027] If the system is busy, forwarding will be paused; if the system is idle, data packets to be scheduled will be extracted and forwarded according to the principle of priority for high-priority queues and first-in-first-out for queues of the same priority.

[0028] Specifically, the steps for allocating channels for PD transaction data packets include:

[0029] For PD transaction data packets, an independent sub-master queue is configured for each PD channel based on the PD channel dimension;

[0030] Build multi-channel configuration rules, including the usage status of each PD channel, the default distribution channel, the multi-channel switching strategy, and the maximum concurrency of each channel;

[0031] Iterate through all the data packets to be scheduled in the channel sub-master queues, configure priority labels for each data packet to be scheduled according to priority rules, and allocate channels in combination with multi-channel configuration rules;

[0032] Based on priority labels and channel allocation results, the data packets to be scheduled in each channel sub-master queue are divided into special and normal transaction data packets, and stored in the corresponding dedicated sub-queues based on channel and priority dimensions.

[0033] Real-time query of the working status of the PD driver unit corresponding to each PD channel; if the PD driver unit of a channel is busy, then pause the distribution operation of all sub-queues of the corresponding channel.

[0034] If the device is in an idle state, data packets are extracted from the hierarchical sub-queues and sent to the PD driver unit of the corresponding channel, based on the principles of prioritizing high-priority queues, first-in-first-out for the same channel and scheduling multiple channels on demand.

[0035] Specifically, the steps for simulating bidirectional protocol conversion behavior and generating the desired data packets include:

[0036] The system receives SPI transaction data packets and PD transaction data packets through the standardized UVM transaction-level interface and constructs the original stimulus copy.

[0037] Retrieve global parameters and initialize the preset global configuration database;

[0038] Extract key fields from the original stimulus copy, including SPI-side fields and PD-side fields, and input the extracted key fields and global parameters into the unified transaction configuration class of the global configuration database.

[0039] Based on the updated unified transaction configuration class instance, read the transformation direction field to determine the transformation direction of the current transaction;

[0040] If the conversion direction field corresponds to the enumerated format label for the SPI to PD direction, execute the SPI to PD conversion process to obtain the expected PD data packet;

[0041] If the conversion direction field corresponds to the enumerated format label for the PD to SPI direction, execute the PD to SPI conversion process to obtain the expected SPI data packet.

[0042] Specifically, the steps for performing the SPI to PD conversion process include:

[0043] Based on a unified transaction configuration class instance, key fields on the SPI side and USB-PD protocol version parameters are extracted, and a PD preamble is added before the SPI side data.

[0044] Add the PD side frame start identifier preset in the unified transaction configuration class after the PD preamble;

[0045] The instruction type and access address in the key fields of the SPI side are converted into control fields that can be recognized by the PD protocol. The data payload of the SPI side is used as the effective data payload of the PD side. The control fields and the effective data payload are integrated into the PD protocol layer data and added after the frame start identifier.

[0046] Perform cyclic redundancy check calculation on the PD protocol layer data, generate a cyclic redundancy check value, and add it after the PD protocol layer data;

[0047] After the cyclic redundancy check value, a PD side frame end identifier preset in the unified transaction configuration class is added to complete the full encapsulation of the PD frame and generate the PD expected data packet.

[0048] Specifically, the steps for performing the PD to SPI conversion process include:

[0049] Based on a unified transaction configuration class instance, extract PD-side fields and USB-PD protocol version parameters;

[0050] According to the frame structure specification of the USB-PD protocol version corresponding to the USB-PD protocol version parameters, the PD side fields are structurally verified to confirm the standardization of the frame start identifier and frame end identifier;

[0051] Perform cyclic redundancy check verification on the PD-side data payload, and compare the calculated check value with the cyclic redundancy check value extracted from the unified transaction configuration class.

[0052] After the comparison and verification are passed, the PD-side data load is analyzed, and the PD-side control information and PD-side valid data are extracted.

[0053] The preset PD-SPI mapping table is invoked to convert the parsed PD-side control information into the corresponding SPI-side instruction type, and the SPI-side access address and data content to be transmitted are obtained based on the valid PD-side data.

[0054] Based on the custom SPI data packet format of the design under test, the converted SPI side instruction type, access address, and data content to be transmitted are integrated and encapsulated to generate the expected SPI data packet.

[0055] Specifically, the steps for field-by-field consistency comparison include:

[0056] Based on the unique identifier of each data packet, the decoded data packet is paired with the corresponding expected data packet and stored in the association mapping table;

[0057] The paired end data packets are preprocessed, including integrity verification, format compliance verification, and conversion direction consistency verification; the paired end data packets are the decoded data packets and the expected data packets after pairing.

[0058] For the SPI to PD conversion scenario, the core fields in the PD dual-end data packets are extracted, and the core fields are compared one by one with the unified transaction configuration class and PD protocol specification to record the comparison consistency results, including comparison consistency and comparison anomalies.

[0059] For the PD to SPI conversion scenario, the core fields in the SPI dual-end data packets are extracted, and the core fields are compared one by one with the unified transaction configuration class and SPI protocol specification to record the comparison consistency results.

[0060] For each conversion scenario, the consistency results within the scenario are counted as the number of consistent comparisons and the total number of comparisons. The scenario pass rate is calculated by the ratio of the number of consistent comparisons to the total number of comparisons.

[0061] Set a secondary segmentation threshold. By comparing the scenario pass rate with the secondary segmentation threshold, determine the pass type of this conversion scenario, including comparison pass, basic pass, and comparison failure.

[0062] For conversion scenarios where comparison fails, retrieve relevant logs and mark the possible sources of differences;

[0063] The comparison data from various conversion scenarios are aggregated to construct a verification log.

[0064] A UVM verification method based on SPI protocol and multi-channel PD protocol conversion includes:

[0065] The configuration framework is divided into two categories: SPI direction and PD direction. Through parameter configuration, SPI transaction data packets and PD transaction data packets are generated and stored in temporary buffer queues respectively.

[0066] For SPI transaction data packets, they are distributed in an orderly manner based on the configured priority tags and the SPI stimulus transmission status. For PD transaction data packets, they are distributed in an orderly manner based on the allocated channels, the configured priority tags, and the transmission status of each PD channel.

[0067] Receive transaction data packets, parse the fields, generate timing excitation signals and physical layer waveform signals respectively, and send them down to the SPI signal domain or corresponding PD channel of the device under test through a standardized interface;

[0068] The SPI and PD signals in the device under test are acquired, and the SPI decoded data packets and PD decoded data packets are generated by decoding and reconstruction.

[0069] For SPI / PD transaction data packets, extract key fields from the SPI side and the PD side, and generate PD expected data packets and SPI expected data packets through a transformation process.

[0070] The decoded data packet is paired with the corresponding expected data packet according to the unique identifier, and a field-by-field consistency comparison is performed on the paired data packet.

[0071] The beneficial effects of this invention are:

[0072] Based on generating transaction data packets adapted to the characteristics of SPI and PD protocols through bidirectional configuration, and combining priority scheduling and multi-channel orderly distribution, this method ensures that the excitation signal is accurately transmitted according to the verification requirements, avoiding the problem of incomplete scenario coverage under a single protocol architecture. Through standardized signal encoding and decoding and the acquisition and restoration of the output of the device under test, it achieves full-process coverage of the bidirectional conversion link from SPI to PD and from PD to SPI, breaking the barrier of traditional architecture's difficulty in joint modeling. By integrating key fields of both ends through the UVM transaction-level interface, it achieves accurate simulation of protocol conversion through a unified transaction configuration class, generates the expected data packets, and fills the gap in cross-protocol data comparison capabilities with field-by-field consistency comparison and difference tracing, ensuring the protocol consistency and functional correctness of bidirectional conversion. This not only guarantees the comprehensiveness and accuracy of the verification scenario, but also improves the verification efficiency and reliability, effectively reducing the tape-out risk of dedicated SPI-PD protocol conversion circuits, and provides stable verification support for application scenarios such as multi-port fast charging and power management ICs, with significant engineering practicality and promotional value. Attached Figure Description

[0073] Figure 1 This is a structural diagram of a UVM verification system based on SPI protocol and multi-channel PD protocol conversion;

[0074] Figure 2 This is a schematic diagram of the dedicated SPI protocol and multi-channel PD protocol conversion circuit structure in this invention;

[0075] Figure 3 This is a flowchart of the field-by-field consistency comparison in this invention;

[0076] Figure 4 This is a flowchart of a UVM verification method based on SPI protocol and multi-channel PD protocol conversion. Detailed Implementation

[0077] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments of the present invention and the specific features in the embodiments are detailed descriptions of the technical solution of the present invention, rather than limitations thereof. In the absence of conflict, the embodiments of the present invention and the technical features in the embodiments can be combined with each other.

[0078] Example 1

[0079] refer to Figures 1 to 3 As shown in the figure, this embodiment introduces a UVM verification system based on SPI protocol and multi-channel PD protocol conversion, including: a configuration management module, an SPI proxy module, a PD proxy module, a protocol conversion module and an interface adaptation module;

[0080] The configuration management module is used to configure constraint parameters in different directions and generate transaction data packets that conform to the SPI / PD protocol specifications based on the verification scenario requirements and protocol specifications.

[0081] In this embodiment, the directions include the SPI direction and the PD direction;

[0082] The SPI direction refers to the SPI transaction data packets to be converted, ultimately used in SPI→PD conversion verification scenarios. Constraint parameters include basic protocol parameters, transaction constraint types, and test scenario parameters. SPI transaction data packets include SPI instruction packets, SPI write packets, special boundary timing packets, and PD mapping verification packets. For example, basic protocol parameters include SPI clock mode (CPOL / CPHA, e.g., mode 0 / 1 / 2 / 3), data bit width (8 / 16 bits), transmission rate (e.g., 1MHz / 10MHz), and chip select active level (active low / active high). Transaction constraint parameters include transmission direction identifier (SPI→PD), transaction type (instruction, write data, special boundary timing, PD mapping verification), and PD mapping verification data. The test scenarios include: SPI verification packets (data length range (minimum 1 byte / maximum 256 bytes), CRC check enable / type, and whether to inject timing anomalies (such as clock jitter, signal delay) and anomaly injection ratio (such as adding jitter to 10% of transactions). SPI instruction packets include read instruction 0x01, write instruction 0x02, and mode configuration instruction 0x03. SPI write data packets include device address and test service data, such as address 0x0008 + data 0x11-0x18. Special boundary timing data packets include extreme scenario packets with a minimum data length of 1 byte and a maximum data length of 256 bytes. PD mapping verification data packets include PD protocol associated fields, such as PD channel identifier and frame type pre-identifier, used to verify the accuracy of protocol mapping.

[0083] The PD direction refers to the PD transaction data packets to be converted, ultimately used for PD→SPI conversion verification scenarios. Constraint parameters include basic protocol parameters, transaction constraint types, and test scenario parameters. PD transaction data packets include control message packets, data message packets, reset packets, and error injection packets. For example, basic protocol parameters include the PD channel number (CC1 / CC2…CCn), start-of-frame identifier (SOP / SOP' / SOP''), end-of-frame identifier (EOP), CRC32 checksum, BMC encoding format, and preamble length (e.g., 5 bytes). Transaction constraint parameters include the transmission direction identifier (PD→SPI), transaction type (control message, data message, reset, error...). The test scenario parameters include error injection type (CRC error, BMC encoding error, bit flip error), reset type (soft reset / hard reset), multi-channel switching rules (such as sequential switching CC1→CC2→CC3, control message packets include PD protocol standard control instructions 0x04 and channel configuration instructions 0x05), data message packets include PD protocol layer data, such as service data 0xAA-0xDD+PD frame header fields, reset type data packets include soft reset frames and hard reset frames, used to verify the DUT reset processing capability, and error injection type data packets include CRC error frames and BMC abnormal frames, used to verify the DUT fault tolerance capability.

[0084] The SIP proxy module parses the SPI transaction data packets in an orderly manner, generates timing stimulus signals, and sends the timing stimulus signals to the SPI signal domain of the device under test through the interface adapter module. At the same time, it acquires the SPI side signals generated by the device under test, decodes and restores them, and generates SPI decoded data packets containing PD information.

[0085] The PD proxy module is used to receive PD transaction data packets and parse them in an orderly manner to generate physical waveform signals. Combined with the corresponding channel allocation results, the physical waveform signals are sent to the corresponding PD channel of the device under test. At the same time, the module acquires the PD-side signals generated by the device under test and decodes and restores them to generate PD decoded data packets.

[0086] The protocol conversion module is used to construct the expected data packet, and combine it with the decoded data packet to perform behavior prediction and result comparison;

[0087] The interface adapter module is used to build a physical signal connection channel between the verification system and the device under test. It includes providing standardized interfaces for clock, reset, SPI signals (SCLK, CSN, MOSI, MISO) and multi-channel PD signals (CC1, CC2…CCn) to realize signal docking between the SPI driver unit, the PD driver unit and the device under test.

[0088] Furthermore, the SIP proxy module includes an SPI sequence scheduling unit, an SPI driver unit, and an SPI monitoring unit;

[0089] The SPI sequence scheduling unit is used to receive SPI transaction data packets, configure transaction priorities for each transaction data packet through queue management to distinguish between normal transactions and special time-series transactions, avoid transaction conflicts, and forward SPI transaction data packets to the SPI driver unit in an orderly manner according to the divided transaction priorities.

[0090] The SPI driver unit is used to receive SPI transaction data packets in sequence. By parsing the transaction data packets, it extracts the instruction fields, device address, CRC check value and scenario identifier in the transaction data packets, thereby generating parsed data of the transaction data packets. Combined with the basic protocol parameters of the SPI direction in the configuration management module, it constructs timing excitation signals that conform to the SPI protocol specification, including clock signal, chip select signal, master output slave input signal, master input slave output signal and timing control signal. The timing excitation signals are driven to the SPI signal domain of the device under test through the interface adapter module.

[0091] The SPI monitoring unit is used to acquire the SPI side signals generated by the device under test, including clock signals, chip select signals, master-output / slave-in signals, and master-in / slave-output signals. It performs timing synchronization and preprocessing on the acquired SPI side signals, and decodes and restores the SPI side signals in combination with the constraint parameters of the SPI direction. The effective to invalid switch of the chip select signal is used as the frame boundary of the complete transmission, and independent SPI transmission frames are divided. In each transmission frame, data is extracted bit by bit according to the clock beat, including instruction fields, address fields, data service fields, and CRC check fields. The data is encapsulated in a preset format to generate standardized SPI decoded data packets, and the SPI decoded data packets are transmitted to the scoring board through the interface adapter module. The SPI side signals are the signals after PD→SPI conversion.

[0092] Furthermore, queue management includes:

[0093] For the received SPI transaction data packets, it is initialized as a first-in-first-out main queue. The main queue serves as a temporary buffer, storing all SPI transaction data packets in the order of receipt to await scheduling and forwarding. At this time, the SPI transaction data packets stored in the main queue are defined as data packets to be scheduled.

[0094] Obtain the priority rules preset by the verification engineer, clarify the priority level of different types of data packets, such as reset class > error injection class > normal read and write class > special boundary timing class, to ensure that high-priority verification scenarios are not blocked by low-priority scenarios;

[0095] Iterate through all the data packets to be scheduled in the main queue. Based on the scenario identifier of each data packet, such as reset, CRC error injection, normal write, and special boundary timing, add a priority label to each data packet to be scheduled by matching the corresponding priority rules. For example, high priority is 3, medium priority is 2, and low priority is 1.

[0096] Based on the assigned priority tags, the data packets to be scheduled in the main queue are classified into normal transaction data packets and special timing transaction data packets to achieve scenario-based management. Among them, normal transaction data packets are ordinary read and write data packets with priority tag 1, without special timing / error configurations, and are used to verify the normal conversion function of the device under test. Special timing transaction data packets include error injection packets, reset packets, and boundary timing packets with priorities of 2-3, carrying special clock configurations (such as jitter), error parameters (such as error CRC), or extreme scenario parameters (such as maximum data length), and are used to verify the fault tolerance and boundary handling capabilities of the device under test.

[0097] After classification, special time-series transaction data packets are stored in the high-priority queue, and normal transaction data packets are stored in the ordinary queue to achieve classified management. The main queue is cleared after classification.

[0098] The system queries the working status of the SPI driver unit in real time, including whether it is idle or busy. If the SPI driver unit is busy, that is, it is processing the timing conversion and transmission of the previous SPI transaction data packet, then forwarding is paused, and the data packet to be scheduled is kept in the corresponding queue, while the status of the SPI driver unit is continuously monitored. If the SPI driver unit is idle, the system extracts the SPI transaction data packet from the queue and forwards it to the SPI driver unit according to the principle of priority of high-priority queues and first-in-first-out of queues of the same priority.

[0099] Furthermore, the PD agent module includes a PD sequence scheduling unit, a PD driving unit, and a PD monitoring unit;

[0100] The PD sequence scheduling unit is used to receive PD transaction data packets, allocate channels for PD transaction data packets through multi-channel selection, and send them to the PD driver unit through the channels;

[0101] The PD driver unit is used to receive PD transaction data packets in sequence and parse them to extract scene identifiers, protocol layer data, and special parameters. Combined with the constraint parameters of the PD direction, physical layer encoding is performed to construct PD data frames. This includes adding preambles, frame start identifiers, protocol layer data, CRC32 check values, frame end identifiers, and BMC encoding. Through timing calibration, level matching, and special scene signal optimization of the PD data frames, physical waveform signals are generated. The physical waveform signals are then driven to the corresponding PD channel of the device under test through the interface adapter module to ensure encoding compliance and signal transmission reliability.

[0102] The PD monitoring unit is used to acquire PD-side signals generated by each PD channel in the device under test through multi-channel acquisition, preprocess and synchronize the acquired PD-side signals, decode and restore the PD-side signals in combination with the constraint parameters of the PD direction, generate standardized PD decoding data packets, and transmit the PD decoding data packets to the scoring board through the interface adapter module; wherein, the PD-side signals are the signals after SPI→PD conversion.

[0103] Furthermore, the steps for allocating channels for PD transaction packets include:

[0104] For received PD transaction data packets, an independent sub-master queue is configured for each PD channel according to the PD channel dimension. The PD transaction data packets are stored in the corresponding channel's sub-master queue based on the receiving order. If the data packet does not specify a channel identifier, it is stored in the configured base channel's sub-master queue by default.

[0105] Build multi-channel configuration rules, including the usage status of each PD channel, the default distribution channel, multi-channel switching strategies (such as round-robin switching, priority-specified switching), and the maximum number of concurrent channels (such as activating 2 channels at the same time).

[0106] The system iterates through all the data packets to be scheduled in the sub-master queues of all channels, configures a priority label for each data packet according to the priority rules, and identifies the channel identifier. If a channel identifier exists in the data packet to be scheduled, the corresponding channel is directly matched. If no channel identifier exists in the data packet to be scheduled, channel allocation is performed based on the multi-channel switching test column. For example, the data packet is allocated to CC1, CC2, CC1 in a round-robin fashion or allocated to an idle channel with priority. For data packets to be scheduled that exceed the maximum concurrency of the channel, they are marked as pending allocation and cached, and reallocated when the target channel becomes idle.

[0107] Based on priority labels and channel allocation results, the data packets to be scheduled in each channel sub-master queue are divided into special transaction data packets and normal transaction data packets, and stored in the corresponding dedicated sub-queues based on channel and priority dimensions, such as CC1 high priority queue, CC2 high priority queue, CC1 normal queue, and CC2 normal queue.

[0108] The system queries the working status of the PD driver unit corresponding to each PD channel in real time, including whether it is idle or busy. If the PD driver unit of a certain channel is busy, it means that it is processing the physical layer encoding and transmission of the previous data packet. At this time, the distribution operation of all sub-queues of the corresponding channel is paused, and the data packets to be scheduled are kept in the queue. The status is continuously polled and monitored. If the PD driver unit of a certain channel is idle, the distribution process of the corresponding sub-queue of that channel is started. According to the principles of high priority queue priority, first-in-first-out for the same priority of the same channel, and on-demand scheduling of multiple channels, data packets are extracted from the hierarchical sub-queues and distributed to the PD driver unit of the corresponding channel to ensure that there are no concurrent data packets in the same channel and that different channels are independently scheduled on demand.

[0109] Furthermore, the protocol conversion module includes a reference unit and a scoring board;

[0110] The reference unit is used to receive SPI transaction data packets and PD transaction data packets, and, in conjunction with the constraint parameters of the configuration management module, simulate bidirectional protocol conversion behavior and generate expected data packets, including SPI expected data packets and PD expected data packets.

[0111] The scoring board is used to receive decoded data packets and expected data packets, perform field-by-field consistency comparisons, and record the verification results.

[0112] Furthermore, the steps for simulating bidirectional protocol conversion behavior and generating the desired data packets include:

[0113] Through the standardized UVM transaction-level interface, it receives SPI transaction data packets and PD transaction data packets from the SPI driver unit and PD driver unit, and constructs the original stimulus replica, including the SPI stimulus replica and the PD stimulus replica.

[0114] Obtain global parameters, such as USB-PD protocol version parameters, SPI / PD protocol basic parameters, and PD-SPI mapping table, and initialize the preset global configuration database;

[0115] Key fields, including SPI-side fields and PD-side fields, are extracted from the original stimulus copy. These extracted key fields, along with global parameters, are then entered into a unified transaction configuration class instance in the global configuration database to form a complete conversion basis containing protocol parameters, core data, and scenario configuration. For the SPI stimulus copy, the instruction type, access address, and data payload are extracted to generate the SPI-side fields. For the PD stimulus copy, the frame start identifier, data payload, frame end identifier, cyclic redundancy check value, and channel selection information are extracted to generate the PD-side fields.

[0116] Based on the updated unified transaction configuration class instance, read the transformation direction field to determine the transformation direction of the current transaction;

[0117] If the conversion direction field corresponds to the enumerated format label for the SPI to PD direction, such as SPI2PD, the SPI to PD conversion process is executed to obtain the expected PD data packet;

[0118] If the conversion direction field corresponds to the enumeration format label for the PD to SPI direction, such as PD2SPI, the PD to SPI conversion process is executed to obtain the expected SPI data packet.

[0119] Furthermore, the steps for performing the SPI to PD conversion process include:

[0120] Extract key fields from the unified transaction configuration class instance in the global configuration database, and USB-PD protocol version parameters (such as PD3.0 / 2.0). Combined with the corresponding protocol specifications, add a PD preamble, such as 5 bytes of 0xFF, before the SPI side data.

[0121] Add the PD side frame start identifier, such as SOP / SOP', preset in the unified transaction configuration class after the PD preamble;

[0122] The instruction type and access address in the key fields of the SPI side are converted into control fields that can be recognized by the PD protocol. For example, the SPI write instruction 0x02 is mapped to the PD data transmission control field 0x04. The data payload of the SPI side is used as the effective data payload of the PD side. The control fields and the effective data payload are integrated into the PD protocol layer data and added after the frame start identifier.

[0123] Perform cyclic redundancy check calculation on the PD protocol layer data, generate a cyclic redundancy check value, and add it after the PD protocol layer data;

[0124] After the cyclic redundancy check value, a PD side frame end identifier preset in the unified transaction configuration class is added to complete the full encapsulation of the PD frame and generate the PD expected data packet.

[0125] Furthermore, the steps for performing the PD to SPI conversion process include:

[0126] Retrieve a unified transaction configuration class instance from the global configuration database, and extract the PD-side fields and USB-PD protocol version parameters;

[0127] According to the frame structure specification of the USB-PD protocol version corresponding to the USB-PD protocol version parameters, the PD side fields are structurally verified to check the standardization of the frame start identifier and frame end identifier, so as to ensure that the PD frame has not been tampered with or damaged.

[0128] Cyclic redundancy check verification is performed on the PD-side data payload. The calculated check value is compared with the cyclic redundancy check value extracted from the unified transaction configuration class to confirm the integrity of PD data transmission.

[0129] After the comparison and verification are passed, the PD-side data load is analyzed, and the PD-side control information and PD-side valid data are extracted.

[0130] The preset PD-SPI mapping table is invoked to convert the parsed PD-side control information into the corresponding SPI-side instruction type, and the SPI-side access address and data content to be transmitted are obtained based on the valid PD-side data.

[0131] Based on the custom SPI data packet format of the design under test, the converted SPI side instruction type, access address, and data content to be transmitted are integrated and encapsulated to generate the expected SPI data packet.

[0132] Furthermore, the steps for field-by-field consistency comparison include:

[0133] Based on the unique identifier of each data packet, such as the data packet ID and conversion direction, the decoded data packet is paired with the corresponding expected data packet and stored in the association mapping table. Data packets for which no matching is found are temporarily stored in the buffer queue. If no match is found after a timeout, it is marked as a data mismatch exception and logged.

[0134] Check whether the core fields of the decoded data packet and the expected data packet are complete. For example, the SPI data packet must contain the instruction type, address, and data payload, and the PD data packet must contain SOP, protocol layer data, CRC32, and EOP. If the key fields are missing, mark the data as incomplete and skip the subsequent comparison.

[0135] Based on the protocol basic parameters of the configuration management module, verify whether the data packet format is compliant, such as whether the SPI data bit width is 8 / 16 bits and whether the PD frame SOP type is within the allowed range. If the format is illegal, mark it as abnormal and record the details.

[0136] Verify that the conversion direction labels of the decoded data packet and the expected data packet are consistent. If both are SPI→PD or PD→SPI, and the direction comparison fails, mark the direction mismatch and re-pair.

[0137] Based on the paired decoded data packets and corresponding expected data packets in the association mapping table, for the SPI→PD conversion scenario, the core fields in the PD decoded data packets and PD expected data packets are extracted, including the preamble, frame start identifier, PD protocol layer data, CRC32 check value, frame end identifier, and channel identifier. These core fields are then compared one by one with the unified transaction configuration class and the PD protocol specification to record the comparison consistency results, including matching and anomalies. The comparison of each core field includes: for the preamble, whether the comparison length and value match the configuration parameters; for the frame start identifier, whether the comparison type (SOP / SOP' / Hard Reset) matches; for the PD protocol layer data, whether the comparison control field (after SPI command / address conversion) and the effective data payload (SPI data payload) pass the comparison; for the CRC32 check value, whether the CRC value of the actual data packet matches the CRC value of the expected data packet (or the value calculated by the model unit); for the frame end identifier, whether the comparison format meets the configuration requirements; and for the channel identifier, whether the channel to which the actual data packet belongs matches the channel selection information of the expected data packet.

[0138] For PD→SPI conversion scenarios, core fields are extracted from the SPI decoded data packets and the expected SPI data packets, including instruction type, access address, data payload, and format compatibility. These core fields are then compared one by one with the unified transaction configuration class and the SPI protocol specification to record the consistency results. Specifically, the comparison of each core field includes: for instruction type, comparing whether the SPI instruction in the actual data packet matches the instruction type in the expected data packet (after PD control information conversion); for access address, comparing whether the SPI address in the actual data packet matches the access address in the expected data packet; for data payload, comparing whether the data to be transmitted in the actual data packet matches the valid data in the expected data packet; and for format compatibility, comparing whether the format of the actual data packet conforms to the DUT's custom SPI data packet specification and is compatible with the expected data packet format.

[0139] For each conversion scenario, the consistency results within the scenario are counted as the number of consistent comparisons and the total number of comparisons. The scenario pass rate is calculated by the ratio of the number of consistent comparisons to the total number of comparisons.

[0140] A secondary classification threshold is set. The pass type of the conversion scenario is determined by comparing the scenario pass rate with the secondary classification threshold. The pass types include comparison pass, basic pass, and comparison failure. The secondary classification threshold includes a first classification threshold and a second classification threshold. The first classification threshold is greater than the second classification threshold. When the scenario pass rate is greater than the first classification threshold, the pass type of the conversion scenario is comparison pass. When the scenario pass rate is between the second classification threshold and the first classification threshold, it is basic pass. When the scenario pass rate is less than the second classification threshold, it is comparison failure.

[0141] For conversion scenarios where the comparison fails, retrieve relevant logs, such as the reference unit conversion log, the monitoring unit acquisition log, and the driver unit transmission log, and mark the possible sources of the differences, such as DUT conversion logic errors, monitoring unit decoding anomalies, and excitation signal distortion.

[0142] The comparison data from various conversion scenarios is aggregated to build a verification log, enabling engineers to monitor the verification progress in real time.

[0143] Example 2

[0144] Please see Figure 4 Another embodiment of the present invention provides a UVM verification method based on SPI protocol and multi-channel PD protocol conversion, comprising the following steps:

[0145] Based on the verification scenario requirements and the SPI / PD protocol specifications, two configuration frameworks are divided into SPI and PD directions. Specific parameters are configured for the SPI direction, including SPI clock mode, data bit width, transmission rate, and transaction type constraints, thereby generating multiple types of SPI transaction data packets. Specific parameters are configured for the PD direction, including PD channel number, frame identifier type, CRC32 check rule, and BMC encoding standard, thereby generating multiple types of PD transaction data packets. The generated SPI and PD transaction data packets are stored in temporary buffer queues as verification stimulus data sources to be scheduled. Specifically, the SPI direction refers to scenarios where the content to be converted is SPI protocol data packets used for SPI-to-PD conversion verification, and the PD direction refers to scenarios where the content to be converted is PD protocol data packets used for PD-to-SPI conversion verification.

[0146] For SPI transaction data packets, the first-in-first-out main queue is initialized as a temporary buffer, the preset priority rules are loaded, and priority tags are added to the SPI transaction data packets so that they can be included in the normal queue and the high-priority queue respectively. The SPI excitation transmission status is monitored in real time. If the transmission link is idle, the SPI transaction data packets are distributed to the next level of transmission process in an orderly manner according to the principle of high-priority queue priority and first-in-first-out for the same priority.

[0147] For PD transaction data packets, the sub-master queue is initialized based on the channel dimension, multi-channel configuration rules and priority rules are loaded, channels are allocated to PD transaction data packets and priority tags are added so that they are included in the corresponding channel high priority queue and the corresponding channel ordinary queue respectively. The transmission status of each PD channel is monitored in real time, and the PD transaction data packets are distributed to the corresponding channel in an orderly manner according to the channel and priority rules.

[0148] The system receives the distributed SPI transaction data packets, parses the fields, generates timing stimulus signals, and transmits them to the SPI signal domain of the device under test through a standardized interface. At the same time, it copies the original SPI transaction data packets as stimulus copies and stores them synchronously.

[0149] The system receives and distributes PD transaction data packets, parses the fields and encodes them in the physical layer to generate physical layer waveform signals, which are then driven to the corresponding PD channel of the device under test through a standardized interface. At the same time, the original PD transaction data packets are copied as an excitation copy and stored synchronously.

[0150] For the device under test, acquire the SPI side signal and PD side signal, and generate SPI decoded data packets and PD decoded data packets by decoding and restoring them;

[0151] The retained SPI / PD stimulus copy is read through the UVM transaction-level interface. Key fields on the SPI and PD sides are extracted. These extracted key fields, along with the USB-PD protocol version parameters and conversion direction enumeration tags, are integrated into a unified transaction configuration class instance and stored in the global configuration database. The conversion direction field of the unified transaction configuration class instance is then read. If it is an SPI to PD enumeration tag, the SPI to PD conversion process is executed to generate the expected PD data packet. If the conversion direction field is a PD to SPI enumeration tag, the PD to SPI conversion process is executed to generate the expected SPI data packet.

[0152] The SPI / PD decoded data packet is paired with the corresponding expected data packet according to the unique identifier, and a field-by-field consistency comparison is performed on the paired data packet.

[0153] Working principle and effects:

[0154] By configuring parameters in different directions using the SPI / PD protocol features and generating transaction data packets, and after priority scheduling and orderly distribution through multiple channels, the data packets are converted into compliant physical layer excitations to drive the device under test (DUT). The converted output signals of the DUT are simultaneously acquired, decoded, and restored into standardized data packets. Then, key fields from both ends are integrated through the UVM transaction-level interface. Based on a unified transaction configuration class, the ideal protocol conversion is simulated to generate the expected data packets. Finally, the data packets are compared field by field with the actual decoded data packets. This effectively solves the problems of single-protocol limitations and lack of cross-protocol comparison in traditional architectures. The directional configuration and scheduling ensure comprehensive coverage of verification scenarios, and the unified simulation and accurate comparison achieve bidirectional conversion joint modeling. The closed-loop process ensures protocol consistency and functional correctness, improves verification efficiency, reduces tape-out risks, and provides stable support for scenarios such as multi-port fast charging, demonstrating strong engineering practicality.

[0155] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A UVM verification system based on SPI protocol and multi-channel PD protocol conversion, characterized in that, include: Configuration management module, SPI proxy module, PD proxy module, protocol conversion module, and interface adaptation module; The configuration management module is used to generate transaction data packets, including SPI transaction data packets and PD transaction data packets, based on the configured constraint parameters. The SPI proxy module parses the SPI transaction data packets in an orderly manner, generates timing excitation signals, and sends them to the SPI signal domain of the device under test. This allows it to obtain the SPI side signals generated by the device under test, decode and restore them, and generate SPI decoded data packets containing PD information. The PD proxy module is used to receive PD transaction data packets and perform ordered parsing to generate physical waveform signals. Combined with the corresponding channel allocation results, the signals are sent to the corresponding PD channels of the device under test. At the same time, the module acquires the PD-side signals generated by the device under test and decodes and restores them to generate PD decoded data packets. The protocol conversion module includes a reference unit and a scoring board; The reference unit is used to receive SPI transaction data packets and PD transaction data packets, and, in conjunction with constraint parameters, simulate bidirectional protocol conversion behavior and generate expected data packets, including SPI expected data packets and PD expected data packets. The scoring board is used to receive decoded data packets and expected data packets, perform field-by-field consistency comparisons, and record the verification results. The interface adapter module is used to provide signal connection channels.

2. The UVM verification system based on SPI protocol and multi-channel PD protocol conversion according to claim 1, characterized in that: The SIP proxy module includes an SPI sequence scheduling unit, an SPI driver unit, and an SPI monitoring unit; The SPI sequence scheduling unit is used to receive SPI transaction data packets, configure transaction priorities for each transaction data packet through queue management to distinguish between normal transactions and special time-series transactions, and forward the SPI transaction data packets to the SPI driver unit in an orderly manner according to the divided transaction priorities. The SPI driver unit is used to receive SPI transaction data packets in sequence, parse the transaction data packets, generate timing excitation signals, and drive the timing excitation signals to the SPI signal domain of the device under test through the interface adapter module. The SPI monitoring unit is used to acquire the SPI side signals generated by the device under test, and generate SPI decoded data packets containing PD information by decoding and restoring them.

3. The UVM verification system based on SPI protocol and multi-channel PD protocol conversion according to claim 2, characterized in that: The PD agent module includes a PD sequence scheduling unit, a PD driver unit, and a PD monitoring unit; The PD sequence scheduling unit is used to receive PD transaction data packets, allocate channels for PD transaction data packets through multi-channel selection, and send them to the PD driver unit through the channels; The PD driver unit is used to encode the received PD transaction data packets through the physical layer, generate physical waveform signals, and drive the physical waveform signals to the corresponding PD channel of the device under test through the interface adapter module. The PD monitoring unit is used to acquire the PD-side signal generated by the device under test, and generate a PD decoded data packet by decoding and restoring it.

4. The UVM verification system based on SPI protocol and multi-channel PD protocol conversion according to claim 3, characterized in that, Queue management includes: Based on the received SPI transaction data packets, a first-in-first-out master queue is constructed to store data packets to be scheduled; Obtain priority rules, iterate through the data packets to be scheduled in the main queue, and assign priority labels based on the scenario identifier; Based on priority labels, the data packets to be scheduled are classified into normal transaction data packets and special time-series transaction data packets, and stored in corresponding queues, including high priority queues and ordinary queues. Real-time query of the SPI driver unit's operating status, including idle and busy status; If the system is busy, forwarding will be paused; if the system is idle, data packets to be scheduled will be extracted and forwarded according to the principle of priority for high-priority queues and first-in-first-out for queues of the same priority.

5. The UVM verification system based on SPI protocol and multi-channel PD protocol conversion according to claim 4, characterized in that, The steps for allocating a channel for PD transaction packets include: For PD transaction data packets, an independent sub-master queue is configured for each PD channel based on the PD channel dimension; Build multi-channel configuration rules, including the usage status of each PD channel, the default distribution channel, the multi-channel switching strategy, and the maximum concurrency of each channel; Iterate through all the data packets to be scheduled in the channel sub-master queues, configure priority labels for each data packet to be scheduled according to priority rules, and allocate channels in combination with multi-channel configuration rules; Based on priority labels and channel allocation results, the data packets to be scheduled in each channel sub-master queue are divided into special and normal transaction data packets, and stored in the corresponding dedicated sub-queues based on channel and priority dimensions. Real-time query of the working status of the PD driver unit corresponding to each PD channel; if the PD driver unit of a channel is busy, then pause the distribution operation of all sub-queues of the corresponding channel. If the device is in an idle state, data packets are extracted from the hierarchical sub-queues and sent to the PD driver unit of the corresponding channel, based on the principles of prioritizing high-priority queues, first-in-first-out for the same channel and scheduling multiple channels on demand.

6. The UVM verification system based on SPI protocol and multi-channel PD protocol conversion according to claim 5, characterized in that, The steps for simulating bidirectional protocol conversion behavior and generating the desired data packets include: The system receives SPI transaction data packets and PD transaction data packets through the standardized UVM transaction-level interface and constructs the original stimulus copy. Retrieve global parameters and initialize the preset global configuration database; Extract key fields from the original stimulus copy, including SPI-side fields and PD-side fields, and input the extracted key fields and global parameters into the unified transaction configuration class of the global configuration database. Based on the updated unified transaction configuration class instance, read the transformation direction field to determine the transformation direction of the current transaction; If the conversion direction field corresponds to the enumerated format label for the SPI to PD direction, execute the SPI to PD conversion process to obtain the expected PD data packet; If the conversion direction field corresponds to the enumeration format label for the PD to SPI direction, execute the PD to SPI conversion process to obtain the expected SPI data packet.

7. The UVM verification system based on SPI protocol and multi-channel PD protocol conversion according to claim 6, characterized in that, The steps involved in performing the SPI to PD conversion process include: Based on a unified transaction configuration class instance, key fields on the SPI side and USB-PD protocol version parameters are extracted, and a PD preamble is added before the SPI side data. Add the PD side frame start identifier preset in the unified transaction configuration class after the PD preamble; The instruction type and access address in the key fields of the SPI side are converted into control fields that can be recognized by the PD protocol. The data payload of the SPI side is used as the effective data payload of the PD side. The control fields and the effective data payload are integrated into the PD protocol layer data and added after the frame start identifier. Perform cyclic redundancy check calculation on the PD protocol layer data, generate a cyclic redundancy check value, and add it after the PD protocol layer data; After the cyclic redundancy check value, a PD side frame end identifier preset in the unified transaction configuration class is added to complete the full encapsulation of the PD frame and generate the PD expected data packet.

8. The UVM verification system based on SPI protocol and multi-channel PD protocol conversion according to claim 7, characterized in that, The steps involved in performing the PD to SPI conversion process include: Based on a unified transaction configuration class instance, extract PD-side fields and USB-PD protocol version parameters; According to the frame structure specification of the USB-PD protocol version corresponding to the USB-PD protocol version parameters, the PD side fields are structurally verified to confirm the standardization of the frame start identifier and frame end identifier; Perform cyclic redundancy check verification on the PD-side data payload, and compare the calculated check value with the cyclic redundancy check value extracted from the unified transaction configuration class. After the comparison and verification are passed, the PD-side data load is analyzed, and the PD-side control information and PD-side valid data are extracted. The preset PD-SPI mapping table is invoked to convert the parsed PD-side control information into the corresponding SPI-side instruction type, and the SPI-side access address and data content to be transmitted are obtained based on the valid PD-side data. Based on the custom SPI data packet format of the design under test, the converted SPI side instruction type, access address, and data content to be transmitted are integrated and encapsulated to generate the expected SPI data packet.

9. The UVM verification method based on SPI protocol and multi-channel PD protocol conversion according to claim 8, characterized in that, The steps for field-by-field consistency comparison include: Based on the unique identifier of each data packet, the decoded data packet is paired with the corresponding expected data packet and stored in the association mapping table; The paired end data packets are preprocessed, including integrity verification, format compliance verification, and conversion direction consistency verification; the paired end data packets are the decoded data packets and the expected data packets after pairing. For the SPI to PD conversion scenario, the core fields in the PD dual-end data packets are extracted, and the core fields are compared one by one with the unified transaction configuration class and PD protocol specification to record the comparison consistency results, including comparison consistency and comparison anomalies. For the PD to SPI conversion scenario, the core fields in the SPI dual-end data packets are extracted, and the core fields are compared one by one with the unified transaction configuration class and SPI protocol specification to record the comparison consistency results. For each conversion scenario, the consistency results within the scenario are counted as the number of consistent comparisons and the total number of comparisons. The scenario pass rate is calculated by the ratio of the number of consistent comparisons to the total number of comparisons. Set a secondary segmentation threshold. By comparing the scenario pass rate with the secondary segmentation threshold, determine the pass type of this conversion scenario, including comparison pass, basic pass, and comparison failure. For conversion scenarios where comparison fails, retrieve relevant logs and mark the possible sources of differences; The comparison data from various conversion scenarios are aggregated to construct a verification log.

10. A UVM verification method based on SPI protocol and multi-channel PD protocol conversion, used to implement the UVM verification system based on SPI protocol and multi-channel PD protocol conversion as described in any one of claims 1-9, characterized in that, include: The configuration framework is divided into two categories: SPI direction and PD direction. Through parameter configuration, SPI transaction data packets and PD transaction data packets are generated and stored in temporary buffer queues respectively. For SPI transaction data packets, they are distributed in an orderly manner based on the configured priority tags and the SPI stimulus transmission status. For PD transaction data packets, they are distributed in an orderly manner based on the allocated channels, the configured priority tags, and the transmission status of each PD channel. Receive transaction data packets, parse the fields, generate timing excitation signals and physical layer waveform signals respectively, and send them down to the SPI signal domain or corresponding PD channel of the device under test through a standardized interface; The SPI and PD signals in the device under test are acquired, and the SPI decoded data packets and PD decoded data packets are generated by decoding and reconstruction. For SPI / PD transaction data packets, extract key fields from the SPI side and the PD side, and generate PD expected data packets and SPI expected data packets through a transformation process. The decoded data packet is paired with the corresponding expected data packet according to the unique identifier, and a field-by-field consistency comparison is performed on the paired data packet.

Images