UVM Framework

Advanced verification methodologies like UVM (Universal Verification Methodology) enable higher level efficiency and re-usable structure. However many product teams do not take such productivity and quality benefits because they overestimate the ramp-up time required to introduce UVM. In order to increase the time-to-productivity Mentor Graphics created a framework. The so called UVM Framework provides a set of common UVM based testbench building blocks that are ready to use without the necessity of detailed UVM knowledge.

                                              Fig 1: UVM Framework     

Motivation for using UVMF

1. UVM Jumpstart The UVM Framework (UVMF) provides a jump-­‐start for learning UVM and building UVM verification environments. It defines an architecture and reuse methodology upon UVM, enabling teams new to UVM to be productive from the beginning while coming up the UVM learning curve. The python scripts provided automate the creation of the files, infrastructure and interconnect for interface packages, environment packages and project benches. Once generated, developers can promptly focus on adding functionality specific to the design and interfaces used.

2. Reuse Methodology

The UVM Framework is a model reuse methodology that verification teams can leverage. It supports component level verification reuse across projects and environment reuse from block through chip to system level simulation. The UVM Framework is an established verification reuse methodology that is in use at many companies in multiple industries across North America and Europe.

3. Single Architecture for Simulation and Emulation

The UVM Framework provides an architecture that supports pure simulation and accelerated simulation using emulation. This enables the creation of a single unified environment that supports block, chip and system level tests, and with the choice of running on a pure simulation platform (e.g. Questa) or a hardware-­‐assisted acceleration platform using emulation (e.g. Veloce).

4. Coverage Within UVMF

UVMF provides a mechanism for rapid creation of reusable simulation infrastructure. Coverage collection components can be defined and connected in the environment using the UVMF code generators. The list below identifies components where functional coverage can be collected and how to add coverage to these components:

• Coverage component: Create this component using the define Analysis Component API and connect to other components in the environment generator. It will likely have all analysis exports and no analysis ports.

• Predictor: Manually add required cover groups to the predictor that was generated using define Analysis Component.

• Scoreboard: Extend UVMF scoreboards on a per-­‐environment basis to define cover groups and sample coverage based on DUT output transactions.

Major Divisions of Functionality Within UVMF

• UVMF Base Package

The UVMF base package, uvmf_base_pkg, is a library of base classes that implement core functionality of components found in all simulation benches. This includes base classes for transactions, sequences, drivers, monitors, predictors, scoreboards, environments and tests. All classes in the UVMF base package are derived from UVM classes.

• Interface Packages

UVMF interface packages and their associated BFMs provide all of the functionality required to monitor and optionally drive a design interface. Interface packages and BFMs are reusable across projects. An interface package is composed of three pieces: a signal bundle interface, BFM interfaces and the package declaration. The signal bundle contains all signals used in the protocol. The BFMs implement the protocol signaling to drive and monitor transactions at the pin level. The package declaration includes all class definitions and type definitions used by the interface agent.

• Environment Packages

The environment package is a key aspect that enables vertical reuse of environments within the UVMF. The environment package contains the environment class definition, its configuration class definition and any environment level sequences that could be used in higher level simulations. Block level environments contain agents, predictors, scoreboards, coverage collectors and other components.

• Verification IP

The verification_ip folder contains all packages that are reused across projects and from block to top. This folder contains environment packages, interface packages, utility packages, etc.

• Project Benches

The simulation bench is composed of top level elements that are not generally intended to be reusable horizontally nor vertically. It defines test level parameters, the top level modules, top level sequence and top level UVM test.

YAML

Rules for Creating YAML file

When you are creating a file in YAML, you should remember the following basic rules −

• YAML is case sensitive

• The files should have .yaml as the extension

• YAML does not allow the use of tabs while creating YAML files; spaces are allowed instead

Basic Components of YAML File

The basic components of YAML are described below −

• Conventional Block Format

This block format uses hyphen+space to begin a new item in a specified list. Observe the example shown below −

• Inline Format

Inline format is delimited with comma and space and the items are enclosed in JSON.

• Maps

A map is a collection of key->value pairings. You may be familiar with these if you’ve ever worked with Python dictionaries or HashMaps in other languages. Each key must be unique, values can be anything, and ordering does not matter.

                                              Fig 2: Maps  

This is a simple map that represents a person’s name and age. There are two keys (name and age), and each maps to a particular value.

• Lists

A list is a sequence of ordered values. Arrays in many programming languages are implementations of lists.

                                               Fig 3: Lists  

• Indentation

Indentation is used in YAML to create nesting, or parent/child relationships. This is similar to how scoping works in Python. For example we can define a complex “user” data structure using indentation to neatly organize each field:

                                                Fig 4: Indentation     

JTAG INTERFACE

JTAG (named after the Joint Test Action Group which codified it) is an industry standard for verifying designs and testing printed circuit boards after manufacture.

It specifies the use of a dedicated debug port implementing a serial communications interface for low-overhead access without requiring direct external access to the system address and data buses.
The interface connects to an on-chip Test Access Port (TAP) that implements a stateful protocol to access a set of test registers that present chip logic levels and device capabilities of various parts.

The connector pins are:

1. TDI (Test Data In):This signal represents the data shifted into the device’s test or programming logic. It is sampled at the rising edge of TCK when the internal state machine is in the correct state.As with any clocked signal, data presented to TDI must be valid for some chip-specific Setup time before and Hold time after the relevant (here, rising) clock edge.

2. TDO (Test Data Out):This signal represents the data shifted out of the device’s test or programming logic and is valid on the falling edge of TCK when the internal state machine is in the correct state. TDO data is valid for some chip-specific time after the falling edge of TCK.

3. TCK (Test Clock): This signal synchronizes the internal state machine operations.

4. TMS(Test Mode Select): This signal is sampled at the rising edge of TCK to determine the next state.

5. TRST (Test Reset) (optional): The TRST pin is an optional active-low reset to the test logic, usually asynchronous, but sometimes synchronous, depending on the chip. If the pin is not available, the test logic can be reset by switching to the reset state synchronously, using TCK and TMS. Note that resetting test logic doesn't necessarily imply resetting anything else. There are generally some processor-specific JTAG operations which can reset all or part of the chip being debugged.