Functional verification of QSPI module based on UVM implementation

This article presents a novel functional verification methodology based on the Universal Verification Methodology (UVM) to validate the functionality of the Quick Serial Peripheral Interface (QSPI) module. QSPI serves as a prevalent serial communication protocol widely employed for high-speed data exchange with external flash devices. By using the code coverage and functional coverage reports provided by UVM, we were able to assess how well the test cases covered the design code, identifying the parts of the design that had been adequately tested and those that needed more test coverage. This verification method based on UVM provides powerful tools and technical support for the design and development of the QSPI module and effectively ensures its reliability and stability. This study is of great significance for further improving the design quality and verification efficiency of the QSPI module.


Introduction UVM (Universal Verification Methodology
) is a verification platform development framework introduced by Accellera in February 2011, using the SystemVerilog class library as the core.It inherits the advantages of VMM and OVM and builds a verification environment with reusable components, standardization, and hierarchical features.It is supported by Synopsys, Mentor, and Cadence to form a complete EDA environment.Currently, UVM has been validated in the market and is widely used in many IC design companies [7] [8].
QSPI (Quad Serial Peripheral Interface) is a common serial communication protocol used for high-speed data exchange with external flash devices in embedded systems.It has four data lines and supports bi-directional communication and high-speed data transfer.QSPI is commonly used to connect microcontrollers, microprocessors, and external flash memory to provide fast memory access and data exchange capabilities [1][2].

UVM verification platform structure
Almost all components in UVM's basic class library are implemented through classes.When building a verification platform, all verification components should derive from these basic classes in UVM [10].A typical UVM validation platform includes components such as a sequencer, driver, monitor, agent, environment, scoreboard/checker, etc., as shown in Figure 1.

Introduction of the QSPI module
QSPI is the abbreviation of Queued SPI, which is an extension of the SPI interface introduced by Motorola and is more widely used than SPI.Based on the SPI protocol, Motorola enhanced its function by adding a queue transfer mechanism and introduced the Queued Serial Peripheral Interface Protocol (i.e., QSPI protocol.)[3].QSPI is a specialized communication interface that connects to a single, dual, or quad (one data line) SPI Flash storage media [4].The interface can operate in the following three modes: 1. Indirect Mode: All operations are performed using the QSPI registers 2. Status Polling Mode: The external Flash status register is read periodically, and an interrupt is generated when flag position 1 is reached (an interrupt is generated when erasing or writing is completed, for example) 3. Memory Mapped Mode: External Flash is mapped to the micro-controller address space so that the system treats it as internal memory [6].
With Dual Flash mode, two Quad-SPI Flashes will be accessed at the same time, increasing throughput and capacity by a factor of two.The module division scheme and structure of the top level of the QSPI controller are shown in Figure 2. In practical engineering, the core function of QSPI is to realize the communication between the APB host and Flash.Since the APB bus supports 32-bit data bit width and the QSPI interface can only transfer up to 4 lines at the same time, a FIFO can be designed as a buffer to ensure the continuity of data transfer.As a master mode, QSPI needs to provide synchronized clock and chip select signals to Flash for data transfer.The clock management module is responsible for the clock frequency division, chip selecting control, and other functions to support the demand of different Flash on the transmission frequency, providing a variety of different frequency clock outputs.In practical engineering, to realize the communication between APB host and Flash, a series of modules need to be designed and implemented, including the APB slave interface resolution module, FIFO buffer, clock management module, and communication control module, etc., to realize the core functions of QSPI and ensure the reliability and efficiency of data transmission [5].

UVM-based verification platform design and implementation
The verification platform is built as shown in Figure 3.

Figure 3. QSPI verification platform
Interface: apb_if and QSPI_if.apb_if are the interface used to communicate with the APB bus, while QSPI_if is the interface used to communicate with the QSPI module.By instantiating these two interfaces, the verification platform can connect with the corresponding interfaces of the DUT to realize the driving and sampling of the design module.By defining and instantiating the interfaces, the verification platform can interact with the DUT to send control signals, read data, and monitor signal status.
Driver: apb_Driver waits for the reset signal to reset the port on the one hand and sends the address and data on the other hand.According to the APB bus protocol, the Driver sends the address and control signals when the first clock rising edge comes and sends the data when the second clock rising edge comes.The data cycle can be prolonged with a low-level Pready signal, so the apb_Driver must be triggered with a high-level Pready event [7].
Monitor: In apb_Monitor, there are two types of sampling, one is to sample the APB bus when apb sends data, and the other is to sample the APB bus when apb receives data.Because the AHB bus is half-duplex, sending and receiving cannot be done at the same time, so only need to establish a Monitor can realize the sampling task.QSPI_Monitor samples the data on QSPI_Interface, and then these two monitors send the sampled values to QSPI_Scoreboard for comparison and coverage analysis.
Agent: The number of agents is determined by the Monitor.No driver tasks need to be set to Passive mode, and those with driver tasks must be set to Active.
Register model: The main purpose of establishing a register model is to complete the configuration of DUT (QSPI) registers.General register model access operations can be divided into front-door access and back-door access.In the front door access, it must be instantiated registers into the Default_map.Default_map's role is to store all the addresses of the registers, otherwise, it cannot be accessed from the front door operation.
QSPI_Virtual_sequencer: Virtual_sequencer is used to realize the synchronization between Sequence, it doesn't send Transaction, it just controls Sequence and plays the role of scheduling.In this verification platform, there are three main Sequences, one controls the data transfer of the register model, one controls the data generation from APB to QSPI, and one controls the data generation from QSPI to APB.
Adapter: In front door access operation, no matter whether read or write, the register model will generate a UVM_reg_bus_op variable through Sequence.If it is a write operation, the information in this variable will be converted by a converter and handed over to apb_sequencer, and then to apb_Driver to realize the final front door access read/write operation by apb_Driver.In the case of a read operation, the converter converts the collected transaction into a form that is acceptable to the register model so that the register model can update the value of the corresponding register.
There are many test scenarios used to simulate the real working situation in the test, Table 1 lists the test cases used and their descriptions.The QSPI interrupt enable is set, the QSPI interrupt threshold is set, and the QSPI is read QSPI_send_addr_data_test In four-wire mode, the QSPI is set to different widths of cmd, data, addr and dummy QSPI_nquad_addr_data_test In single-wire mode, the process is as above QSPI_rand_case_test The QSPI is randomly set to different widths of cmd, data, addr and dummy QSPI_nquad_mode_test Single-wire SPI operation mode is set, and then the QSPI is written and read

Coverage statistics and analysis of results
By operating the QSPI with different test cases, the signal timing waveforms of each interface of the QSPI can be seen with the Verdi Waveform Viewer tool as shown in Figure 4 (one test case is randomly selected).

Conclusions
The QSPI module, which has 100% coverage, is used in many SOCs with AMBA buses.Secondly, for other verification projects that use the QSPI module, it is only necessary to simply modify the Agent

Figure 1 .
Figure 1.Typical UVM verification platform In the verification platform, the driver gets the transaction from the sequencer and drives it to the DUT (Device Under Test) interface according to the corresponding interface protocol.The transaction is generated in the sequence and sent to the sequencer.The monitor is used to monitor the DUT interface signals in real time and sample the signals, and finally send the sampled signals to the reference model or scoreboard.The reference model simulates the DUT's working behavior and determines the desired results based on the signals sampled by the monitor and sends them to the scoreboard.Scoreboard's main function is to send the sampled signals to the reference model or scoreboard.The main function of the scoreboard is to compare and analyze the expected results of the reference model with the actual results of the DUT and arrive at the final verification results [9].

Figure 4 .
Figure 4.The timing diagram of each interface of QSPI under a random test case This test utilizes Synopsys VCS tool for simulation verification after constantly adding test cases and test sequences, modifying constraints, as well as modifying random seeds, running regression tests, checking coverage, and adding some direct test cases for places that are not covered.And in doing the above work through the use of Makefile script, simulation, test selection, coverage collection, and other functions designed to automate the operation, this design finally gets 100% functional coverage.The data matching in the Scoreboard is also 100%, and the expected functional verification goals are all achieved.The coverage statistics for the test are shown in Figure 5.