Verification platform, method and system for verifying I2C protocol based on UVM environment

Abstract

The embodiment of the invention discloses a verification platform, method and system for verifying an I2C protocol based on a UVM environment, and relates to the field of function verification. The UVM environment has comprehensive parameterization configuration capability, various test scenes are dynamically matched, and all-directional coverage and deep insight of verification are ensured. And an intelligent mode switching mechanism is adopted, and the role change of the DUT is seamlessly jointed, so that the automation and efficiency of the verification process are improved. And a randomized test strategy is introduced, so that the randomness and robustness of verification are remarkably enhanced, and potential problems are effectively revealed. As standard I2C device simulation, time sequence verification is independently executed in an environment, communication abnormity is accurately captured and analyzed, and fault positioning is accelerated. Through the fusion application of the SystemVerilog and the UVM, the verification complexity is simplified, the simulation process is optimized, and the iteration period is shortened.

Description

Technical Field

[0001] The present application relates to the field of functional verification, and in particular to a verification platform, method and system for verifying an I2C protocol based on a UVM environment. Background Art

[0002] I 2 C (Inter-Integrated Circuit), as a highly integrated synchronous serial communication bus technology, has been created by Philips since the 1980s. With its unique architecture that relies only on the clock line (SCL) and the data line (SDA), it has achieved flexible communication between multiple hosts and multiple slaves, and has a built-in efficient arbitration mechanism. These two bidirectional IO lines - the clock line and the data line - are designed as open drain interfaces and need to be connected to the power supply with the help of external pull-up resistors to ensure that they maintain a high level state when inactive. When I 2 When any device on the C bus actively pulls the signal to a low level, the bus state changes accordingly. This feature ensures precise control of data transmission.

[0003] Given that I 2 C bus is widely used in contemporary integrated circuit design, and many chips need to follow the I 2 C protocol to exchange data. To this end, the industry has developed an efficient verification tool - I 2 C VIP (Verification Intellectual Property), which can abstract and simplify at the behavioral level and realize accurate simulation at the signal level, ensuring I 2 Data sent and received under the C protocol is accurate.

[0004] In the early practice, I 2 C model module or directly utilize two independent I 2 A common verification method involves testing the transmission and reception of C hardware description language (HDL) modules (one acting as the master and one as the slave). However, these traditional methods have limitations: for example, the master_model and slave_model are typically separated into two Verilog files, where configuration parameters such as the slave address and baud rate are often defined using parameters. While this approach facilitates targeted testing, it struggles to meet the widespread needs of random verification, limiting the comprehensiveness and flexibility of testing.

[0005] On the other hand, when two I 2When testing C HDL modules directly, if the transmitting and receiving logic are designed by the same digital design engineer, there is a potential risk: identical errors hidden in the transmitting and receiving logic may go undetected due to internal consistency, causing the errors to cancel each other (allowing communication), thus masking the actual problem. This situation highlights the importance of incorporating independent and diverse test strategies into the verification process to ensure design robustness and reliability. Summary of the Invention

[0006] The embodiments of the present application provide a verification platform, method, and system for verifying the I2C protocol based on the UVM environment, which can solve the problems of only partially implementing verification functions and low randomness in the existing technology. The technical solution is as follows:

[0007] In a first aspect, an embodiment of the present application provides a verification platform for verifying the I2C protocol based on a UVM environment, including:

[0008] The UVM environment includes: a host agent, a slave agent, and a scoreboard, the host agent includes: a host sequencer, a host monitor and a host driver, the slave agent includes: a slave sequencer, a slave monitor and a slave driver, the host agent and the slave agent respectively communicate with the scoreboard, and the UVM environment communicates with the DUT through a virtual intf;

[0009] Wherein, the host sequencer is used to transmit the randomly generated items from the sequence library to the host driver;

[0010] The host driver is used to generate and drive the clock line SCL and data line SDA signals on the I2C bus according to the item from the host sequencer, including: a start signal start, a stop signal stop, the SCL clock for read and write operations, and the corresponding SDA data;

[0011] The host monitor is used to monitor the signals on the I2C bus, sample the data on the SDA, and package the sampling results into items and send them to the scoreboard;

[0012] The slave sequencer is used to send a random test sequence item related to the slave to the slave driver;

[0013] The slave driver is used to generate SDA data in the slave sending phase according to the received item;

[0014] The slave monitor is used to monitor the signal on the I2C bus and pack the received data or sent data samples into items and send them to the scoreboard;

[0015] The scoreboard is used for items from the master monitor and the slave monitor, and outputs statistical results after comparing and analyzing the data in the items to verify whether the data transmission on the I2C bus is carried out as expected.

[0016] In a second aspect, an embodiment of the present application provides a verification method for verifying the I2C protocol based on a UVM environment, comprising:

[0017] The host sequencer transmits the randomly generated items from the sequence library to the host driver;

[0018] The host driver generates and drives the clock line SCL and data line SDA signals on the I2C bus according to the item from the host sequencer, including: a start signal start, a stop signal stop, the SCL clock for read and write operations, and the corresponding SDA data;

[0019] The host monitor monitors the signals on the I2C bus and samples the data on SDA, and packages the sampling results into items and sends them to the scoreboard;

[0020] The slave sequencer sends the slave-related random test sequence item to the slave driver;

[0021] The item received by the slave driver generates SDA data in the slave sending phase;

[0022] The slave monitor monitors the signal on the I2C bus and packages the received data or the sent data samples into items and sends them to the scoreboard;

[0023] The scoreboard is derived from the items of the master monitor and the slave monitor, and outputs statistical results after comparing and analyzing the data in the items to verify whether the data transmission on the I2C bus is performed as expected.

[0024] The beneficial effects of the technical solutions provided by some embodiments of the present application include at least:

[0025] When the DUT acts as both an I2C slave and a host, the UVM verification environment intelligently identifies and automatically adjusts its internal mechanisms, enabling a transition from a fixed mode to dynamic adaptation. By parameterizing the specific properties of the DUT (such as the slave address and address width), the verification environment seamlessly switches to the corresponding slave or host mode, executing the corresponding communication protocol and timing checks, significantly improving verification flexibility and efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0027] Figure 1 Schematic diagram of the network architecture of the UVM environment provided in the embodiment of the present application;

[0028] Figure 2 This is a flow chart of a verification method for verifying the I2C protocol based on a UVM environment provided in an embodiment of the present application. DETAILED DESCRIPTION

[0029] In order to make the objectives, technical solutions and advantages of the present application clearer, the embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

[0030] Figure 1 An exemplary system architecture of a UVM environment that can be applied to the present application is shown.

[0031] like Figure 1 As shown, the UVM environment and Figure 1 The I2C-env UVM environment includes the host agent Mst and the slave agent Slv. Each of these agents includes multiple instantiated components: the host agent Mst includes the host sequencer Mst-Sqr, the host monitor Mst-Mon, and the host driver Mst-Drv; the slave agent Slv includes the slave sequencer Slv-Sqr, the slave monitor Slv-Mon, and the slave driver. The I2C-env communicates with the DUT via the virtual interface intf. The host agent and slave agent each communicate with the scoreboard Scb.

[0032] The host sequencer is used to transfer the randomly generated items from the sequence library to the host drive;

[0033] The host driver is used to generate and drive the clock line SCL and data line SDA signals on the I2C bus according to the item from the host sequencer, including: start signal start, stop signal stop, SCL clock for read and write operations, and corresponding SDA data;

[0034] The host monitor is used to monitor the signals on the I2C bus, sample the data on SDA, and package the sampling results into items and send them to the scoreboard;

[0035] The slave sequencer is used to send slave-related random test sequence items to the slave driver;

[0036] The slave driver is used to generate SDA data during the slave sending phase according to the received item;

[0037] The slave monitor is used to monitor the signals on the I2C bus and package the received or sent data samples into items and send them to the scoreboard;

[0038] Scoreboard for items from the master monitor and slave monitor, comparing and analyzing data from the items to verify that data transfer on the I2C bus is proceeding as expected.

[0039] The above components work together to form the UVM environment for I2C bus communication, ensuring the accuracy and reliability of communication.

[0040] In an embodiment of the present application, the host driver, as the core driver component in I2C communication, is responsible for accurately controlling the behavior of the clock line (SCL) and the data line (SDA). It is based on the parameter instructions from the configuration source (cfg) and the sequence library (seq), constructs and sends a start (start), stop (stop) signal, and according to the timing requirements of the I2C protocol, drives SCL to generate a clock pulse, and transmits address information, data (txdata) and an acknowledgement signal (txack) through SDA. Inside Mst-Drv, the driver_ctrl task plays the role of the commander-in-chief, not only obtaining the test item (item) from the sequence library, but also activating the three key tasks of driver_clk, driver_data and err_det in parallel. The first two tasks focus on the clock drive of SCL and the data drive of SDA, respectively, to ensure the accuracy of read and write operations; and the err_det task is responsible for monitoring and handling any abnormal conditions that may occur, to ensure the robustness of the test.

[0041] The host monitor is a key monitoring component for ensuring the quality of I2C communication. It closely monitors signal activity on the bus, particularly the correctness of special signals such as start, restart, stop, and ack. Through its built-in perform_check, start_det, stop_det, and err_det tasks, which run in parallel, the host monitor accurately captures SDA data and packages the sampled data into test items based on I2C timing and configuration (cfg) requirements. These items are then transferred to the scoreboard for further analysis. The err_det task is also responsible for timely intervention when specific errors or abnormal scenarios are detected, ensuring the continuity of the test process.

[0042] The slave driver focuses on driving the SDA signal in the slave role, ensuring that during the transmit phase (e.g., when the slave sends data (txdata) and acknowledges (txack), the data on SDA is accurately presented according to the timing requirements of the I2C protocol. Its internal get_and_drive task precisely controls the SDA level changes based on the current state of the SCL clock and the parameters in the test item to transmit the correct data or acknowledgement signal. Furthermore, the err_det task enables slv_drv to respond quickly to abnormal situations, ensuring the robustness and controllability of the test.

[0043] Similar to the master monitor, the slave monitor is a key component responsible for signal sampling and data packaging. However, the focus is on signal activity from the slave's perspective, including correctness verification of special signals such as start, restart, stop, and acknowledge. Through the coordinated operation of tasks such as perform_check, start_det, stop_det, and err_det, the slave monitor accurately captures data on SDA, packages it into test items, and then passes these items to the scoreboard for subsequent analysis and comparison.

[0044] Throughout the verification platform, items serve as the fundamental unit of data transmission, carrying all the parameter information required for each transmission, including the slave address, data array, address mode, and checksum (PEC) switches. These items are generated by the Seq library based on preset random constraints and accurately delivered to the corresponding drivers via the Sqr sequencer (either the master or slave sequencer). Ultimately, the Scb (scoreboard) serves as the ultimate referee of the verification process, comparing the actual data transmitted on the bus with the expected value and generating a detailed comparison report. After the simulation is complete, the statistical results in these reports (such as the number of errors and pass rate) become important criteria for judging the success of the verification simulation.

[0045] In the UVM (Universal Verification Methodology) verification environment (also known as Verification Intellectual Property (VIP), when the VIP acts as the I2C master and the DUT (Design Under Test) acts as the slave, the entire verification process is carefully designed to ensure accurate communication and comprehensive verification. The following is a detailed description of the process:

[0046] The verification process begins with a top-level sequence library, which utilizes random constraints to generate the configuration parameters required for each I2C transfer. These parameters include, but are not limited to, address width (7 or 10 bits), specific address value, transfer type (write or read), and data size. These configurations are designed to simulate a wide range of real-world scenarios, enhancing the breadth and depth of verification.

[0047] To ensure smooth communication, the SCL (serial clock line) and SDA (serial data line) signals between the UVM environment and the DUT are directly connected to the same I2C bus. This connection method ensures that the signals between the two can be transmitted and received accurately.

[0048] Configuration of the DUT is performed via the Advanced Peripheral Bus (APB) interface. Specifically, the APB sequence library generates APB-items that conform to the APB protocol. These items are then passed to the APB host (apb_mst). The APB host driver issues write and read commands to the DUT's configuration bus (APB) interface according to the APB protocol's timing specifications, enabling precise configuration of the DUT's internal registers.

[0049] The UVM environment itself is configured using the I2C serial library. I2C-items are passed to the I2C master (I2C_mst) to specify specific I2C operations. Additionally, some non-item environment parameter configurations are transmitted via the cfg (configuration object). The I2C master driver combines the configuration information in the cfg and item to generate and send a round of corresponding I2C master commands to the I2C bus. The DUT, acting as a slave, should respond correctly to these commands to demonstrate the functionality of its I2C interface.

[0050] When the UVM environment, acting as the host, sends a write command, the Verification IP (VIP) host monitor detects the ACK signals returned by the DUT during the address and data phases. If the ACK signals are correct, the monitor samples the data sent by the host driver according to the timing requirements of the I2C protocol, packages it, and sends it to the scoreboard (SCB) as the expected data. Simultaneously, the data actually received from the DUT is extracted and sent to the SCB as the actual data. The SCB then compares the expected data with the actual data. The comparison results are printed in real time and included in statistical analysis to assess the success of verification.

[0051] To verify a read command, the DUT is first configured with the data to be transmitted (txdata) in the seq field and sent to the SCB as expected data. After the VIP host driver sends the address, the DUT must respond with an ACK or NACK. The host monitor detects the ACK signal returned by the DUT during the address phase and correctly samples the data sent by the DUT, also sending it to the SCB as the actual data. The SCB again compares the expected data with the actual data and generates the corresponding comparison results and statistical information.

[0052] Through the above process, the UVM environment can comprehensively and accurately verify whether the behavior of the DUT as an I2C slave is as expected, thereby ensuring the correctness and reliability of the design.

[0053] In a UVM verification environment, when the UVM environment plays the role of a slave and the DUT (Design Under Test) acts as the master, the entire verification process is carefully planned to ensure accurate communication and comprehensive verification. The following is an introduction to the verification process:

[0054] The verification process begins with a top-level sequence library (seq), which applies random constraints to generate the configuration parameters required for each I2C transfer. These parameters include, but are not limited to, address width (7 or 10 bits), address value, transfer type (write or read), and data size. These parameters are designed to simulate a variety of real-world scenarios, enhancing the breadth and depth of verification.

[0055] To ensure smooth communication, the SCL (serial clock) and SDA (serial data) signals between the DUT and the I2C-VIP (Verification IP) are connected to the same I2C bus. This direct signal connection ensures that information can be exchanged accurately between the two.

[0056] The verification environment operates through the Advanced Peripheral Bus (APB) interface to configure the DUT. The APB sequence library generates APB items that conform to the APB protocol. These items are then passed to the APB master (apb_mst). The APB master driver issues write and read commands to the DUT's configuration bus (APB) interface according to the APB protocol's timing specifications to accurately configure the DUT's internal registers.

[0057] For the UVM environment itself, its configuration information is transmitted directly through the cfg (configuration object). The slave driver and slave monitor work together based on the configuration information in the cfg to receive and respond to I2C commands issued by the device under test (DUT). As a slave, the UVM environment must ensure that it can correctly respond to commands from the DUT, thereby verifying the functionality and reliability of its I2C interface.

[0058] When the DUT sends a write command, the data to be transmitted (txdata) must be configured for the DUT in the sequence library and sent to the SCB (scoreboard) as expected data. The slave monitor verifies that the address and data sent by the DUT are correct, and also checks that the ACK signal returned by the slave driver (slv_drv) is accurate. The slave monitor also samples the data sent by the DUT according to the timing requirements of the I2C protocol, packages it, and sends it to the SCB as the actual data. The slave driver is responsible for returning ACK or NACK signals during the address and data phases. The SCB then compares the expected data with the actual data. The comparison results are printed in real time and included in statistical analysis to assess the success of the verification.

[0059] To verify a read command, the slave monitor first checks the address and ACK / NACK signals sent by the DUT for correctness. The slave monitor then samples the data sent by the slave, packages it according to the timing requirements of the I2C protocol, and sends it to the SCB as the expected data. The slave driver is responsible for returning an ACK or NACK signal during the address phase and sending data to the DUT during the data phase. The data actually received from the DUT is also sent to the SCB as the actual data. The SCB compares the expected data with the actual data and generates statistics and printouts based on the comparison results.

[0060] Through the above process, the UVM environment can comprehensively and accurately verify whether the behavior of the DUT as an I2C host is as expected, thereby ensuring the correctness and reliability of the design.

[0061] See also Figure 2 , is a flow chart of a verification method for verifying the I2C protocol based on a UVM environment provided in an embodiment of the present application, including:

[0062] S201. The host sequencer transmits a randomly generated item from a sequence library to a host driver.

[0063] S202: The host driver generates and drives the clock line SCL and data line SDA signals on the I2C bus based on the items from the host sequencer. The signals include: start signal, stop signal, SCL clock for read and write operations, and corresponding SDA data.

[0064] S203: The host monitor monitors the signals on the I2C bus and samples the data on the SDA, and packages the sampling results into items and sends them to the scoreboard.

[0065] S204 , the slave sequencer sends the slave-related random test sequence item to the slave driver.

[0066] S205: The slave driver receives the item and generates SDA data in the slave sending phase.

[0067] S206 , the slave monitor monitors the signal on the I2C bus and packages the received data or the sent data samples into an item and sends it to the scoreboard.

[0068] S207 , the scoreboard collects items from the master monitor and the slave monitor, compares and analyzes the data in the items, and outputs statistical results to verify whether the data transmission on the I2C bus is performed as expected.

[0069] The above method embodiments and Figure 1 The embodiments in the present invention are based on the same concept and have the same technical effects. For the specific process, please refer to Figure 1 The description of the embodiments will not be repeated here.

[0070] The embodiments of the present application specifically include the following beneficial effects:

[0071] The UVM environment innovatively integrates both master and slave agents, creating a flexible and adaptable test platform specifically designed for evaluating DUTs (designs under test) that integrate I2C master and slave functionality. By fully parameterizing I2C communication configurations, such as clock waveforms, data timing parameters, data transfer rates, and command combinations, this framework dynamically adapts to the needs of diverse test scenarios, ensuring comprehensive and in-depth verification.

[0072] When the DUT acts as both an I2C slave and a master, the verification environment intelligently identifies and automatically adjusts its internal mechanisms, enabling a transition from a fixed mode to a dynamic one. By parameterizing specific DUT attributes (such as slave address and address width), the verification environment seamlessly switches to the corresponding slave or master mode, executing the corresponding communication protocol and timing checks, significantly improving verification flexibility and efficiency.

[0073] To fully address potential DUT issues, the verification environment employs a randomized configuration strategy, ensuring that test parameters are randomly generated during each simulation run, simulating a diverse range of operating environments and boundary conditions. This randomized testing approach not only improves the randomness and automation of verification, but also significantly enhances its robustness and problem-finding capabilities.

[0074] As a simulation implementation of a standard I2C device, the UVM environment is tightly integrated with the I2C bus. It not only sends and receives data but also independently verifies the timing of the bus signals. By accurately sampling and analyzing the signal waveforms when the DUT functions as a master or slave, the verification environment instantly captures and reports any timing violations or communication errors, enabling rapid problem location and repair.

[0075] By combining SystemVerilog (SV) and UVM, the VIP core's implementation effectively reduces the complexity and barriers of cross-language compilation. Furthermore, by avoiding encryption, the simulation process is further simplified, making the entire compile-to-simulation process smoother and more efficient. This optimization not only shortens simulation cycles but also improves fault location accuracy and accelerates verification iterations.

[0076] The verification environment was designed with the needs and skill levels of diverse user groups in mind. By pre-encapsulating foundational methods, simplifying parameter configuration, and providing a high-level abstract interface, casual users can easily get started and focus on developing and executing verification strategies without delving into technical details. For experienced users, the verification environment offers a highly cohesive and low-coupling code architecture and functional integration solution, reducing learning costs and improving development efficiency. This user-friendly design philosophy has made the UVM environment a popular, efficient, and reliable verification tool.

[0077] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware through a computer program. The program can be stored in a computer-readable storage medium, and when executed, the program can include the processes in the above-described method embodiments. The storage medium can be a magnetic disk, an optical disk, a read-only memory, or a random access memory.

[0078] The above disclosure is only a preferred embodiment of the present application, and certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A verification platform for verifying the I2C protocol based on a UVM environment, characterized in that: include: The UVM environment includes: a host agent, a slave agent, and a scoreboard, the host agent includes: a host sequencer, a host monitor and a host driver, the slave agent includes: a slave sequencer, a slave monitor and a slave driver, the host agent and the slave agent communicate with the scoreboard respectively, and the UVM environment communicates with the DUT through a virtual intf; Wherein, the host sequencer is used to transmit the randomly generated items from the sequence library to the host driver; The host driver is used to generate and drive the clock line SCL and data line SDA signals on the I2C bus according to the item from the host sequencer, including: a start signal start, a stop signal stop, the SCL clock of the read and write operations and the corresponding SDA data; The host monitor is used to monitor the signal on the I2C bus, and to sample the data on the SDA, and to package the sampling result into an item and send it to the scoreboard; The slave sequencer is used to send a random test sequence item related to the slave to the slave driver; The slave driver is used to generate SDA data in the slave sending phase according to the received item; The slave monitor is used to monitor the signal on the I2C bus and pack the received data or the sent data samples into items and send them to the scoreboard; The scoreboard is used for items from the host monitor and the slave monitor, and outputs statistical results after comparing and analyzing the data in the items to verify whether the data transmission on the I2C bus is performed as expected.

2. The method according to claim 1, characterized in that The host driver runs the following tasks in parallel: driver_ctrl task, driver_clk task, driver_data task and err_det task; The driver_ctrl task is used to control specific behaviors or parameters in the driving process, the driver_clk task is related to the driving of the clock signal, the driver_data task converts transaction-level data into timing signals and drives them to the interface of the DUT, and the err_det task is used to perform error detection; The host detector runs the following tasks in parallel: perform_check task, start_det task, stop_det task and err_det task.

3. The method according to claim 1, characterized in that The sequence library generates the configuration parameters required for each I2C transmission using a random constraint mechanism, and the configuration parameters include address width, address value, transmission type and data volume.

4. The method according to claim 1, characterized in that: The statistical results include: number of errors and pass rate.

5. The method according to claim 1, characterized in that The configuration of DUT is operated through the APB interface.

6. A verification method for verifying the I2C protocol based on a UVM environment, characterized in that, include: The host sequencer transmits the randomly generated items from the sequence library to the host driver; The host driver generates and drives the clock line SCL and data line SDA signals on the I2C bus according to the item from the host sequencer, including: a start signal start, a stop signal stop, the SCL clock of the read and write operations and the corresponding SDA data; The host monitor monitors the signals on the I2C bus and samples the data on SDA, and packages the sampling results into items and sends them to the scoreboard; The slave sequencer sends a random test sequence item related to the slave to the slave driver; The item received by the slave driver generates SDA data in the slave sending phase; The slave monitor monitors the signal on the I2C bus and packages the received data or the sent data samples into items and sends them to the scoreboard; The scoreboard comes from the items of the host monitor and the slave monitor, and outputs statistical results after comparing and analyzing the data in the items to verify whether the data transmission on the I2C bus is performed as expected.

7. A verification platform, characterized in that: include: A verification system as claimed in any one of claims 1 to 5.

Images