10 steve holloway

7/29/2019 10 Steve Holloway

1/15

Adopting a Methodology:Experiences of OVM Deployment at Dialog

Steve Holloway Senior Verification Engineer

Dialog Semiconductor

1


2/15

Overview

2


3/15

Why Choose OVM?

OVM is a standard methodology Built on SystemVerilog (IEEE 1800)

Long heritage of best practise (AVM + URM)

Cross tool compatibility Switch tools & vendors more easily

Availability of 3rd party VIP Higher quality verification of (standard) interfaces Rapid development of complex testbenches

Reduced team ramp-up time Rapid familiarity with company verification environment Easier to find resources with appropriate skills

Sensible choice for new adopter of Metric Driven verification

3


4/15

What are we trying to achieve?

4

Constrained-random stimulus vectors Automatically checked DUT response

Functional Coverage = verification completeness

Modular, reusable coding strategy

DUTDUT

0110110110

0000100000

1000101001

0110110101

0110101000

0110101011

randomlygenerated

stimulus0110110110

0000100000

1000101001

0110110101

0110101000

0110101011

response0110110110

0000100000

1000101001

0110110101

0110101000

0110101011

0110110110

0000100000

1000101001

0110110101

0110101000

0110101011

0110110110

0000100000

1000101001

0110110101

0110101000

0110101011

0110110110

0000100000

1000101001

0110110101

0110101000

0110101011FunctionalCoverage

FunctionalCoverage

CheckerChecker

Automated Test-bench


5/15

The OVM Class Library

The OVM package contains three main types of class:

ovm_component

A structural component used in an OVM testbench

It can be built in a hierarchy

It can have configurable items which are set as it gets built

Is synchronised with other ovm_components with a well-defined flow of

simulation phases Facilitates a modular reuse strategy

ovm_object

A generalised data structure

Can hold testbench configuration information

ovm_transaction

A data structure for stimulus generation, monitoring and analysis

5


6/15

The OVM Factory

Based on the concept of the OOP Factory Pattern

It can create objects at runtime, whose type are dynamically selected by overrides

6

I2C transaction

7-bit I2C transaction

10-bit I2C transaction

Error I2C transaction

set_type_override_by_type(i2c_trans::get_type(), i2c_error_trans::get_type())


7/15

VerificationPlan

VerificationPlan

The Importance of a Plan

7

VerificationEnvironmentDevelopment

VerificationEnvironmentDevelopment

Project ManagerTracking status

Project ManagerTracking status

Execute SessionsExecute Sessions

ArchitectEnsure intent is realised

in design

ArchitectEnsure intent is realised

in design

Verification EngineerCommon status

document & buy-in

Verification EngineerCommon status

document & buy-in

Design EngineerEnsure implementation is

in line with spec

Design EngineerEnsure implementation is

in line with spec

Coverage MetricsCoverage Metrics

DebugDebug

Plan completion


8/15

Guaranteed Success?

OVM = Kit of standard parts & user guide

SystemVerilog = Feature-rich HVL

Theres More Than One Way To Do It

Inconsistent look & feel

Non reusable code

Using the wrong level of abstraction

Boilerplate getting in the way of the real work

Coverage closure & debug

Recreating in-house class libraries & macros

8


9/15

Rollout Steps

External training courses & workshops

Internal seminars & knowledge sharing Best practise guidelines Wiki knowledge base Code examples

External OVM resources OVM Forum Verification Academy External consultants

Introduction on live projects Code review sessions

Library OVC components

9

Capability

Novice

Expert


10/15

Problems in Execution

RTL-centric engineers learning OOP concepts

Stimulus not constrained appropriately

Checking at the wrong level of abstraction Reference model in module-based helper code + assertions

Dangerous use of configuration settings set_config_int(*, num_agents, ); No encapsulation of configuration

Slippage between Vplan & coverage model

Derivative projects could not reuse agents easily Tightly coupled to interface

Module chip reuse is non-trivial

10


11/15

Solutions

Encapsulate VIP settings in configuration objects

Encapsulation of BFM tasks in interface

Better reuse model for derivative DUTs with changing i/f

Structure of Scoreboard for reuse & decoupled checks

E.g. MVC pattern

Leverage common sequence API (e.g. register-based)

Review process essential to ensure consistent verification approach

Multi-layered approach to verification

Infrastructure & VIP development

Project specific stimulus, checks and coverage11


12/15

Reviews throughout

12

Vplan CreationVplan Creation

Vplan ReviewVplan Review

Vplan

stakeholders

EnvironmentCreation

EnvironmentCreation

Code ReviewCode ReviewVerification

team

Coverage &Checks Creation

Coverage &Checks Creation

MetricsReview

MetricsReview

Designteam


13/15

Leveraging Reuse

13

Vplanning & Environment Coding Debug & Closure

Initial rolloutproject

Derivativeproject


14/15

Conclusions

OVM constrained-random approach resulted in:

High rates of bug discovery

Easier tracking of real progress

Managed verification closure

OVM wont initially reduce your verification effort

Until reuse is leveraged

Legacy directed tests can still add value

OVM checking in passive mode

Engineers were able to get running quickly

Application-specific examples & knowledge sharing

UVM roll-out in progress!

14


15/15

15

Energy Management Excellence

10 steve holloway

Documents