In this paper, the verification platform and environment for SPI bus controller are built by applying advanced verification methodology of UVM, and the functional verification of data transmission in different modes is realized. A reusable and efficient verification method is provided, which is helpful to improve the verification efficiency and shorten the design cycle. With the continuous development of VLSI, verification has occupied 70% to 80% of the whole research and development cycle.
The efficiency of chip verification has become an important part of the chip development cycle. Therefore, the key to chip verification is to select a high efficiency and reusable verification methodology. UVM is the abbreviation of Universal Verification Methodology, full name is Universal Verification Methodology. This methodology is a validation methodology developed jointly by Cadence, Mentor and Synopsys, and originated from OVM (Open Verification Methodology) [1].
It uses many advantages of the current mainstream verification methodology, and can provide engineers with randomized incentive generation and reconfigurable verification components to improve the verification efficiency. This paper combines the development of SPI bus controller in a chip design, uses UVM to build simulation verification platform, completes the verification of SPI bus controller, and provides a reusable verification environment for the verification of SPI controller in chip development. SPI is a high-speed, full-duplex synchronous communication bus, using four communication lines, which greatly saves the number of pins on the chip, and also saves the layout space on the PCB version [2]. Because of its simplicity and ease of use, thermostatic element more chips begin to integrate SPI bus interface. In this mode, there is usually one master device and one or more slave devices, which can be connected by four-wire mode (two-way transmission) or three-wire mode (one-way transmission or one-master-one-slave mode). SPI is the structure of ring bus. The main control device initiates communication by generating shift clock. When communicating, the main device controls the input and output of data by sending clock signals. The data is output by MOSI on the bus, input by MISO, and the relationship between data and clock signals is configured by user autonomous gram. After several clock changes, the data transmission of corresponding digits is completed. In SPI transmission, data is sent and received synchronously. The clock of data transmission is based on the output clock of the bus controller generated by the clock pulse from the main processor. The clock specification of any universal SPI is not defined. However, the most commonly used clock settings are based on clock polarity (CPOL) and clock phase (CPHA). CPOL defines the active state of the SPI serial clock, while CPHA defines the clock phase relative to the data bit. The setting of CPOL and CPPA determines the clock edge of data sampling. The verification platform (testbench) is constructed by hardware verification language (3).
The verification engineer completes the verification platform construction outside the tested design in the functional verification. Verification usually involves applying different incentives to the design under test, then observing the output of the DUT, and comparing the structure with the expected value required to verify whether the DUT is correct. So generating various incentives is the most important function of a verification platform. The validation engineer improves the efficiency of validation by integrating various validation methods into the validation platform.
In order to integrate more advanced verification methods, a hierarchical verification platform is introduced. In this process, the degree of abstraction increases with the increase of the level. The signal layer is the lowest. DUT belongs to the signal layer, and the signal connecting the DUT and the verification platform belongs to the signal layer. The command layer mainly includes the excitation used to drive DUT and the output signal collected from DUT. The function layer is responsible for decomposing the upper transaction into data packets and sending them to the command layer. Another function layer is to predict the results and compare the predicted results with the output of DUT. The main role of the scene layer is to generate incentives. The verification environment is composed of the above levels. For different DUTs, the division of this level will be different. Although on the surface, it seems to improve the complexity of the verification platform, in fact, it divides the functions of each module, improves the clarity of the code function, and is conducive to the construction of the verification platform. A typical UVM verification platform [4], including driver (driver), monitor (monitor), sequencer (sequencer), agent (agent), scoreboard (scoreboard), reference model (reference model) and env (environment) and other universal verification components (UVC). UVM predefines a class of uvm_component. The main components of the UVM platform, driver, monitor, model, scoreboard, etc. are derived from this class. In the form of class derivation, each component is combined in a tree structure to make the verification platform clear and easy to perform operations and changes. Each part of the entire UVM verification platform is like an inverted tree, as shown in Figure 1 below. Driver in the UVM verification platform is derived from uvm_driver. Driver is the most basic verification component of the UVM verification platform and the most complex verification component besides reference_model. Driver converts transaction-level data randomly generated by sequence constraints into DUT port-level data, and then drives it to the interface associated with DUT. The sequencer in the UVM verification platform is derived from the uvm_sequencer and specifies the transaction-level data type to be generated when defined. The role of sequencer is very simple, which is to send the constrained random transaction-level data generated in sequence to driver. For a large project, it is unreliable and unrealistic to judge whether the function of DUT is correct only by waveform. The correct way is to introduce self-comparison mechanism in the verification platform, and determine whether the function of DUT is correct through errors in log files.
This requires introducing reference model, scoreboard and monitor into the verification platform. Monitor is a verification component to monitor DUT behavior, which is derived from uvm_monitor. In order to improve the portability of verification components, drivers, monitors and sequencers are usually encapsulated into an agent in UVM. So different agents represent different protocols. Agent is derived from uvm_agent. Because the UVM verification platform needs self-comparison mechanism, that is, the input data of DUT need to be compared with the output data of DUT, so reference model verification component needs to be introduced into the verification platform, and reference model is derived directly from uvm_component. There are two kinds of reference model, one is the same function as DUT, the other is the inverse operation of DUT. Screboard is derived from uvm_scoreboard. It is a uvm_component. The input or output data of DUT and the output data of reference model are self-contrasted in scoreboard. Success of comparison will print a mark, and failure of comparison will print a mark. This makes the validation engineer do not need to judge whether the function of DUT is correct according to waveform, and reduces the probability of error in validation work. Combined with the logical structure of the UVM verification platform and the working mode of SPI controller, a complete verification platform is built. Based on the above section, the block diagram of SPI bus controller UVM verification platform is shown in Figure 2. The platform mainly includes two SPI agents and reference model. SPI sequence is used to acquire SPI sequence. SPI driver will acquire event-level data from SPI sequence, i.
e. the timing requirement and data content of the expected data to be sent on the bus to the SPI bus controller, i.e. DUT. These transaction-level data include the configuration of control registers for SPI bus controllers and the value of the transmitted data. The SPI agent also sends the same data to the SPI reference model, where the data is sent to the bus. Out-agent has only one component of Out monitor, which is used to monitor the data output of SPI bus controller. Scoreboard receives data from SPI reference model and Out agent, compares them and outputs the result information. In the construction of verification platform, sequence is divided into two parts. On the one hand, it configures the cfg_sequence of registers, and on the other hand, it configures the sending data. Through the refinement of sequence, the data and configuration can be separated and the workload of actual verification can be reduced. When the platform input signal to DUT, DUT will respond to the input signal. This response needs to be judged on the scoreboard, where a comparison value is required, which is generated by the reference model.
The reference model output to the Scoreboard is the data to be sent by the SPI bus controller. In reference model, we do not need to consider the working mode of SPI bus controller, but only focus on the data that need to be sent. In rx_monitor, the working mode of sending data is judged by receiving serial data and clock signals from DUT. In tx_monitor, the proper transmission mode is determined by receiving the input configuration of DUT, and the correct transmission function of DUT is determined by comparison. The SPI bus controller is validated by the UVM verification platform.
The simulation results show that the functional coverage and code coverage meet the requirements, and the verification environment can be flexibly integrated into the system verification environment, so that the SPI module can be applied in the top-level verification and reusable verification.