• No results found

DEVELOPMENT OF OPEN VERIFICATION IP FOR I2C CONTROLLER

N/A
N/A
Protected

Academic year: 2023

Share "DEVELOPMENT OF OPEN VERIFICATION IP FOR I2C CONTROLLER "

Copied!
34
0
0

Loading.... (view fulltext now)

Full text

Otherwise, it can lead to a big loss for the company if an error occurs during the design/coding phase. Simulation-based testing is faster and also offers the opportunity to check all signals hidden beneath the design. But the increasing complexity of the design and the concurrency behavior of the design have made it very difficult to verify functionality using traditional test benches.

Our work introduces an automated stimulus generating test environment for the design and checks the functionality of the I2C bus controller. Verification is a process used to ensure that design device properties are preserved prior to mapping in silicon. All the desired features of the design that need to be verified are listed to ensure that the design works correctly.

Random stimulation is automatically generated by the test environment depending on design specifications and requirements. In general, it is better if the coverage block is broken down based on the logic blocks of the design. A processor-driven test panel generates the desired stimulus for designing and monitoring the DUT signals using the fully functional processor model.

The test instructions boost the design when executed and monitor the DUT signals, but through a different set of instructions.

Introduction To OVM

OVM Testbenches And environment

The OVM Library

Components Of OVM

  • Design Under Test
  • Inte rface
  • Transactions
  • Sequence And Sequence
  • Driver
  • Monitor
  • Scoreboard
  • Environment
  • Testcases

And as the design features change, the pin connection on the interface is also required to change. Virtual interfaces provide a mechanism for separating abstract patterns from actual design cues. A virtual interface allows the same instance or subroutine to run in different parts of the design.

In general, data item fields are randomized using System Verilog constraints, so a large number of tests can be generated. An instance of the driver class is created in the environment class and a sequencer is connected to it. It is implemented by extending the ovm_monitor class and an instance is created in the environment to connect it to the DUT signals.

One is used for receiving packets from the driver and the other from the receiver (extended class of the ovm_component class). The virtual interface is created in the environment and extends all other virtual functions of the environment class. The ovm_test class defines the test scenario for the testbench for the DUT and is specified in the test.

These virtual interfaces are referenced to the physical interfaces declared in the top module. The test name can be passed implicitly or can be passed as a command line argument during simulation. In transaction-based verification (TBV) at each stage of the verification cycle, the desired functionalities of the design are specified and checked.

Using the SystemVerilog implementation of TLM in OVM, a component can connect via its interface to other components that implement that interface. Thus, a component can be connected to other components implemented at many levels of abstraction using TLM at the transaction level [15]. Virtual sequences are used to coordinate the execution of multiple sequences on different interfaces; this allows for more sophisticated tests to exercise more complex design under test (DUT) cases [15].

Figure 2.8: Verification Components (All of them are inside the Testclass)  2.5 Advantage Of Transaction Based Verification
Figure 2.8: Verification Components (All of them are inside the Testclass) 2.5 Advantage Of Transaction Based Verification

Introduction

I2c bus protocol

I2C Bus Te rminology [11],[12]

Multi-master – to include multiple masters that can coexist on the bus at the same time without collision or data loss [11]. Arbitration - a process for deciding which device will act as master in a multi-master system [11]. The data on the data wire (SDA) must be valid at the moment the clock wire (SCL) switches from 'low' to 'high' voltage [11].

Only two chips are involved in a communication - the Master initiating the signals and the Slave responding when addressed.

I2c protocol diagram

I2c bus controller

Features to be verified

Stimulus Generation Plan

Designing individual open verification components .1 DUT

  • Inte rface
  • Transaction
  • Sequence
  • Sequencer
  • Driver
  • Monitor
  • Environment
  • Test
  • Scoreboard
  • Top module

The i2c bus monitor collects i2c_transfers seen on the i2c signal level interface and sends out status updates via a status transaction, indicating various activities on the bus. The i2c bus monitor has class checks and collects coverage if checks and coverage collection are enabled. The i2c_env build() function has a control field called has_bus_monitor, which determines whether the i2c_bus_monitor is created or not.

The bus monitor is created by default, as the default value for this control field is a [1]. The virtual interface is passed as a parameter to the constructor through which all OVCs are connected. The build() function of i2c_env creates the master agents, slave agents and the i2c bus monitor.

An instance of the environment class is created and registered with the ovm factory in the build function using the type_id::create function. One is used to get packets from i2c_master_driver and the other from salve_driver or slave_receiver (extended class of ovm_component class). The i2c test environment (i2c_demo_tb) is instantiated in the top-level module to create a class-based simulation environment.

The i2c bus environment (i2c_env) within the testbench (i2c_demo_tb) uses a virtual interface variable to refer to the real interface [1]. The DUT instance signals are connected to the interface variable xi0 in i2c_top.sv file. Argument to run_test () method is passed in the command line by +OVM_TESTANAME= enc_base_test.

OVM_INFO @ 2000: ovm_test_top [test_read_modify_write] Call global_stop_request() to end the run phase.

ANALYSIS OF RESULT OBTAINED FROM OVM OUTPUT

For further implementation, this controller can be interfaced with any microprocessor or microcontroller that can generate data, addresses, and other signals in real-time or SOC designs. OVM can be used to verify system operation as test cases are easier to create in OVM and can be verified for system response to real-time data through scoreboard. Any data mismatch will be considered as an error and the position of the error can be determined.

Figure

Figure 2.2 OVM class hierarchies [1]
Figure 2.8: Verification Components (All of them are inside the Testclass)  2.5 Advantage Of Transaction Based Verification
Figure 3.1: I2C protocol [17]
Figure 3.2: I2C signals  3.4 Verification plan
+2

References

Related documents