1 Introduction

This chapter includes a general introduction to this manual, to eRM, and to eVCs. It contains the
following sections:

• “About This Book” on page 1-1

• “About the eRM Release Library (erm_lib)” on page 1-2
• “About eVCs” on page 1-3
• “Conventions in This Manual” on page 1-6

1.1 About This Book

This manual is all about maximizing reusability of verification code written in e. eRM (e Reuse
Methodology) ensures code reusability by discussing the best known methods for designing, coding,
and packaging e code as reusable components.

Most of the guidelines herein apply to any scale or type of verification environment. Since e Verification
Components (eVCs) are an ultimate form of reusable verification environment, the majority of this book
relates to creating eVCs.

A key factor for reusing code is arranging it as an independent and easy-to-use code package. When
developing verification code in e, the reusable package is typically organized as an eVC (e Verification
Component). For this reason, eRM speaks a lot about eVCs: standardizing eVC development practices,
defining a common eVC user model, and ensuring that eRM-compliant eVCs are plug-and-play. In
short, this manual also explains how to develop verification components that will provide eVC users
with consistent and superior verification experiences.

The intended audience for this book includes eVC developers, verification environment developers, and
technical managers responsible for these environments.

Following is a brief description of each chapter in this manual.

e Reuse Methodology 1-1

Introduction
About the eRM Release Library (erm_lib)

Chapter 1 “Introduction” This chapter

Chapter 2 “Verification Packages”
Chapter 3 “eVC File Organization”
Chapter 4 “Typical eVC Architecture”
Chapter 5 “Sequences: Constructing Test
Scenarios”
Chapter 6 “Messaging”
Chapter 7 “eVC Standardization Using eRM
Compliance Checks”
Chapter 8 “The eRM Utility”
Chapter 9 “Reference”
Chapter 10 “Golden eVCs”
How to organize verification
components/utilities and how to ship them
How to organize eVC files and directories
How to model eVCs
How to use Specman sequences in a uniform and
efficient way
How to create standard messages
How to maintain a high standard and uniformity
for eVCs
How to use the eRM Utility, a graphical user
interface with tools that facilitate various
eRM-related tasks
Detailed discussion of specific topics
eVCs that serve as role models for e Reuse
Methodology

1.2 About the eRM Release Library (erm_lib)

The eRM library (erm_lib) contains all of the deliverables associated with eRM— infrastructure
utilities, examples, documentation, and more.

The library includes the following packages and subdirectories:

evc_util This package includes the infrastructure syntax, types, and utilities needed
for writing eVCs. It is the core module of the eRM library.
Documents This directory contains all of the main eRM documentation. It also contains
(in the erm_docs eRM presentations in PDF format.
directory)
Golden eVCs These are example eVC packages, constructed according to eRM guidelines.
They are designed to teach eRM methodology and concepts and to provide a
starting point for eVC development. Two examples are included. One
represents a bus-based environment (vr_xbus), and the other represents a
serial data stream environment (vr_xserial). You can find the two golden
eVCs in directories with their respective names (vr_xbus, vr_xserial).
Example These are minipackages that demonstrate use of some specific features
directories provided by the eRM library, such as sequences and packaging. They all have
an ex_ prefix (for example, ex_atm, ex_soc, ex_c_bus).

1-2 e Reuse Methodology

 Introduction
About eVCs

Labs This directory includes labs designed to teach eRM.

(in the lab directory)
vt_util This is the eRM Utility package.
Shareware These packages offer useful functionality. They are, however, often provided
packages at a lower level of productization and support than the official utilities. The
shareware packages are all marked with a shr_ prefix (for example,
shr_install).
Templates This directory contains templates for eVC user guides (in FrameMaker and
(in the templates MS Word formats) and for eVC training classes (in PowerPoint format).
directory)

Each of these packages and subdirectories has its own PACKAGE_README.txt or README.txt file
in it, giving details on the content.

1.3 About eVCs

This section includes:

• “What Are eVCs?” on page 1-3

• “eVCs vs. Regular Verification Environments (VEs)” on page 1-4
• “eVCs as Plug-and-Play Components” on page 1-5
• “eVC Reuse Requirements” on page 1-5

1.3.1 What Are eVCs?

An eVC™ is an e Verification Component. It is a ready-to-use, configurable verification environment,
typically focusing on a specific protocol or architecture (such as PCI Express, Ethernet, AHB, or USB).

Each eVC consists of a complete set of elements for stimulating, checking, and collecting coverage
information for a specific protocol or architecture. You can apply the eVC to your device under test
(DUT) to verify your implementation of the eVC protocol or architecture. eVCs expedite creation of a
more efficient test bench for your DUT. They can work with both Verilog and VHDL devices and with
all HDL simulators that are supported by Specman®.

You can use an eVC as a full verification environment or add it to a larger environment. The eVC
interface is viewable and thus can be the basis for user extensions. We recommend doing such
extensions in a separate file. Maintaining the eVC in its original form facilitates possible upgrades.

e Reuse Methodology 1-3

Introduction
eVCs vs. Regular Verification Environments (VEs)

eVC implementation is often partially encrypted, especially in commercial eVCs where authors want to
protect their intellectual property. Most commercial eVCs require a specific feature license to enable
them.

This manual takes a fairly liberal approach to the question of what is an eVC. For the purposes of this
manual, an eVC is a significant, productized, modular piece of e code that can be used to verify
something and that has a single owner who is responsible for it (supporting it and possibly selling it).

Notes
• An eVC can depend on another eVC. For example, there could be a TCP/IP eVC that uses (imports)
an Ethernet eVC. That TCP/IP eVC could still be developed and sold separately.
• An eVC must be significant and productized. These are not exact terms, but clearly a 200-line
scoreboard module does not qualify as an eVC. eVCs are usually 5,000 to 20,000 lines in size, and
they embody significant knowledge and work (so that people would be willing to pay money for them).

Following is a partial list of possible kinds of eVCs:

• Bus-based eVCs (such as PCI and AHB)

• Data-communication eVCs (for example, Ethernet, MAC, Datalink)
• CPU/DSP eVCs
• Higher-level protocol eVCs (TCP/IP, HTTP). These usually sit on top of other eVCs.
• Platform eVCs (that is, an eVC for a specific, reusable SoC platform, into which you plug eVCs of
various cores).
• Compliance test-suite eVCs. These are tests (and perhaps coverage definitions and more) that
demonstrate compliance to a protocol. For example, there could be a PCI compliance eVC in addition
to the basic PCI eVC.
• HW/SW co-verification eVCs, such as an eVC dedicated to verifying a HW/SW environment using
a particular RTOS/CPU combination.

1.3.2 eVCs vs. Regular Verification Environments (VEs)

The distinction between an eVC and a modular, well written verification environment (VE) is fuzzy. The
main difference is that an eVC is meant to be used in more than one setting.

Regardless of whether the combined VE is itself an eVC or not, when we integrate n eVCs into a VE, we
have n+1 pieces: the n eVCs and the explicitly added code for the VE. The plug-and-play considerations
described below relate to all n+1 items.

1-4 e Reuse Methodology

 Introduction
eVCs as Plug-and-Play Components

For example, there should be no name collisions between eVCs, but there should also be no name
collisions between any of the eVCs and the VE. Therefore names like pci_checks.e would not be
appropriate, because users might want them too.

Note The recommendations in this manual represent the best practices for those using Specman.
Therefore, they apply not just to eVCs but also to regular VEs. For example, unified tracing (as is
recommended for plug-and-play eVCs) is very useful when applied to blocks within a big VE, even if
neither the blocks nor the VE are ever meant to be reused.

1.3.3 eVCs as Plug-and-Play Components

Ideally, eVCs must be plug-and-play components in the sense that a new verification environment can be
constructed from eVCs that were not initially planned to work together. Not only that, it should be
possible to do this hierarchically. In other words, it should be relatively easy to construct the combined
VE also as an eVC, which in turn could be plugged into yet a bigger VE.

To enable this capability, eVCs (and indeed general VEs, which could potentially be turned into eVCs)
should be written as if they are part of a universal verification environment.

Following are the benefits of making eVCs plug-and-play:

• Promotes code sharing:

• Within companies
• Between companies
• Offers customers a convenient, ready-to-use product
• Makes eVC creation easier and faster

1.3.4 eVC Reuse Requirements

The following requirements are essential for eVC reuse. These requirements are all from the perspective
of the eVC user. They translate into recommendations for the eVC writer.

Note All of the following recommendations are described in much greater detail throughout the rest of
this manual.

e Reuse Methodology 1-5

Introduction
Conventions in This Manual
No interference between eVCs
Common look and feel, similar
activation, similar
documentation
Support for combining eVCs
(control, checking, layering, and
so on)
Support for modular debugging
Commonality in implementation
1.4 Conventions in This Manual
This manual uses variations in typefaces to help you locate and interpret information easily. These type
variations are explained in Table 1-1.
1-6
• No name space collision
• No complex SPECMAN_PATH or directory dependencies
• Handling dependencies on common modules
• No dependencies on different versions of Specman and
utilities
• No timing dependencies
• No dependencies on global settings
• Common way to install eVCs
• Common way to patch eVCs
• Common tracing and debugging
• Handling DUT errors
• Getting eVC identification
• Waveform viewer data
• Custom visualization
• Common way of specifying simulator-specific material
• Common way to do backdoor initialization
• Common programming interface to standard blocks
• Common eVC taxonomy
• Common style of documentation
• Common way to configure eVCs
• Common way to write tests
• Common way to create sequences
• Common way to do checking
• Combined determination of end of test
• Common way to do layering of protocols
• Common way to do combined coverage
• Understanding combined constraints
• Reconstructing the behavior of a single eVC in the
verification environment
• Common data structures
• Common eVC testing methodology
• Common way to use ports and packages
e Reuse Methodology
 Introduction
Conventions in This Manual

Table 1-1 Document Conventions

Typeface Represents
courier font Indicates code. For example:
do burst_response keeping {

courier bold Used to highlight important sections of code, like actions. For example:
do burst_response keeping {

bold The bold font indicates keywords in descriptive text. For example, the
following sentence contains keywords for the show ini command and
the get_symbol() routine:

You can display these settings with the show ini setting command
or retrieve them within e code with the get_symbol() routine.

italic The italic font represents user-defined variables that you must provide.
For example, the following line instructs you to type the “write cover”
as it appears, and then the actual name of a file:

write cover filename

[ ] square brackets Square brackets indicate optional parameters. For example, in the
following construct the keywords “list of” are optional:

var name: [list of] type

[ ] bold brackets Bold square brackets are required. For example, in the following
construct you must type the bold square brackets as they appear:

extend enum-type-name: [name,…]

construct, … An item, followed by a separator (usually a comma or a semicolon) and

an ellipsis is an abbreviation for a list of elements of the specified type.
For example, the following line means you can type a list of zero or
more names separated by commas.

extend enum-type-name: [name,…]

| The pipe character indicates alternative syntax or parameters. For

example, the following line indicates that either the bits or bytes
keyword should be used:

type scalar-type (bits | bytes: num)

e Reuse Methodology 1-7

Introduction
Conventions in This Manual

Table 1-1 Document Conventions (continued)

Typeface Represents

cmd-prompt> Denotes the prompt for the tool you are running, including
Specman Elite, vManager, SpeXsim, or SpeXtreme.

C1>, C2>, … Denotes the SpeXsim prompt (VHDL, Verilog or mixed-HDL designs).
Also denotes a third-party Verilog simulator prompt.

> Denotes a third-party VHDL simulator prompt.

% Denotes the UNIX prompt.

1-8 e Reuse Methodology