4

Typical eVC Architecture

This chapter explains how typical eVCs should be constructed. Because each eVC relates to different protocols, architectures, and designs, one eVC can vary quite signicantly from another. Even so, there is commonality in the design of various eVCs. In this chapter, we discuss the commonality and some of the main differences between typical eVCs. The examples we look at relate to communication protocols, like a serial interface or an on-chip bus. Later, we will see that an eVC for an SoC is constructed according to similar guidelines. The end of this chapter lists extensive terminology denitions and a complete legend for the architecture diagrams presented in this book. This chapter includes the following sections:

Basic eVC Architecture on page 4-1 A Look at Agents on page 4-6 A More Complex eVC Example on page 4-12 Combining eVCs on page 4-14 Layering eVCs on page 4-15 Modeling FAQs on page 4-22 Terminology on page 4-23

4.1

Basic eVC Architecture

This section includes:

DUT and eVC on page 4-2 BFMs and Monitors on page 4-5
e Reuse Methodology 4-1

Typical eVC Architecture

DUT and eVC

Clocks and Events on page 4-6 DUT Signals on page 4-6

4.1.1

DUT and eVC

Figure 4-1 below shows a sample DUT that we use to demonstrate eVCs.

Figure 4-1 Example DUT

DUT
Bus Logic Serial Logic

This DUT has two external interfaces: a bus interface and a serial interface. Because each of these interfaces can interact externally, we can attach an eVC to exercise and interact with each of them. We start by looking at the serial interface. This interface is composed of a receive port and a transmit port. The eVC attached to this interface is the vr_xserial eVC. The dual-agent implementation for the XSerial eVC is shown in Figure 4-2 below. (The actual implementation of the XSerial eVC is slightly different. It is shown in Figure 4-3 on page 4-4.) Figure 4-2 XSerial eVCDual-Agent Implementation
xserial_env RX Agent
Cong:

TX Agent Cong Signal Map Sequence Driver

seq

...
Synchronizer

Cong Signal Map Sequence Driver

seq

...

Mon

BFM

Mon

BFM

DUT Bus Logic Serial Logic

4-2

e Reuse Methodology

Typical eVC Architecture

DUT and eVC

The XSerial eVC is encapsulated in the rectangle marked xserial_env. This rectangle represents an instance of a unit of type vr_xserial_env_u (which inherits from any_env, as described in any_env Unit on page 2-23). For each port of the interface, the eVC implements an agent. These agents can emulate the behavior of a legal device, and they have standard construction and functionality. Each env also has a group of elds, marked in Figure 4-2 as Cong. This allows for conguration of the envs attributes and behavior. The agents are units instantiated within the env. In this representation of the eVC, there are two types of agent: RX agent TX agent A receive agent that can collect data from the DUTs transmit port A transmit agent that can send data to the DUTs receive port

These agents are constructed in a standard manner. They have the following components: Cong Signal Map Synchronizer Sequence Driver A group of elds that allow conguration of the agents attributes and behavior. A unit that contains external ports for each of the HW signals that the agent must access as it interacts with the DUT. A unit that contains external ports for HW signals that are common to the whole design. Typically, this includes clock and reset signals. A unit instance that serves as a coordinator for running user-dened test scenarios (implemented as sequences). The sequence drivers are explained in detail in Chapter 5 Sequences: Constructing Test Scenarios. Bus Functional Model a unit instance that interacts with the DUT and both drives and samples the DUT signals. A unit instance that passively monitors (samples) the DUT signals and supplies interpretation of the monitored activity to the other components of the agent. Monitors can emit events when they notice interesting things happening in the DUT or on the DUT interface. They can also check for correct behavior or collect coverage.

BFM Monitor

In Figure 4-2, notice that the BFMs have bidirectional arrows to the DUT. This signies the fact that they can both drive and sample DUT signals. Monitors have unidirectional arrows pointing from the DUT to them. This signies that they can only sample data from the DUT. Monitors cannot drive DUT signals.

e Reuse Methodology

4-3

Typical eVC Architecture

DUT and eVC

The actual implementation of the XSerial eVC is slightly different than the architecture shown in Figure 4-2. Instead of a dual-agent architecture, a single-agent architecture was chosen (see Figure 4-3 below). Figure 4-3 XSerial eVCSingle-Agent Implementation
xserial_env
Cong:

TX_AND_RX Agent Cong Signal Map Sequence Driver seq

...
Synchronizer

...

RX Mon

TX Mon

TX BFM

DUT Bus Logic Serial Logic

Both the dual-agent and the single-agent architectures are valid implementations. Depending on the specics of the protocol the eVC deals with, you might prefer one over the other. In the XSerial protocol, the RX direction is completely passive and involves no driving of signals. Thus there is no need to have a BFM and a sequence driver in the RX agent. However, the TX agent behavior also depends on ow control frames received by the RX agent. This means that the RX agent must communicate frequently with the TX agent to tell it when it has received such frames. In the XSerial protocol, the XSerial eVC could have two agents an RX agent and a TX agent where the RX agent is signicantly more simple than the TX agent. If the ow control mechanism involves a high level of interaction between the two directions, implement a single-agent eVC to model the ow control mechanism efciently. The single agent covers both the TX and RX directions. The single agent contains all of the monitors, BFMs, and sequence drivers required for both directions.

4.1.1.1

Diagram Language

What has been described up to now is the typical, generic parts of an eVC environment. Before looking deeper into the construction of an agent or examining other variants of eVC architecture, the language used in the architecture diagrams should be understood.
Figure 4-4 gives a brief legend for architecture diagrams.

4-4

e Reuse Methodology

Typical eVC Architecture

BFMs and Monitors

Figure 4-4 Brief Legend for Architecture Diagrams

Unit Struct Data item Struct/unit pointer unit struct Subtype Unit instantiation
Enclosing unit Instantiated unit Enclosing unit Subtype struct unit

Field grouping

Topic: eld 1 ...

DUT access DUT

Most importantly, notice the difference between structs and units, and the difference between unit instantiation as opposed to pointers between structs and units. The fact that unit instantiation is depicted by enclosing one unit rectangle within another serves to express the important relations between the main entities in an eVC architecture. Notice also that in Figure 4-2 the DUT was drawn in gray at the bottom of the picture. This convention is maintained throughout the rest of this manual. A more complete legend is supplied at the end of this chapter in the gure Full Legend for Architecture Diagrams on page 4-26. The more complete legend will be helpful when examining the diagrams in Chapter 5 Sequences: Constructing Test Scenarios.

4.1.2

BFMs and Monitors

Monitors must be completely passive. The BFM does all of the activity of driving transactions. The BFM can make use of the monitor or duplicate some of the monitors logic. (Both are legitimate; developers must decide which ts their needs.) Generally, the monitor handles most passive activity, and the BFM handles all active interactions with the DUT. For example, the monitor might collect transactions and then emit an event for each transaction received. Upon this event, the BFM could be responsible for sending an acknowledgment back to the DUT. We recommend using the monitor rather than the BFM to collect transactions that come from the DUT. This can happen in the following ways:

In many protocols, each agent in the eVC has both a BFM and a monitor. (See the XBus golden eVC
for an example.)

In some protocols, the Receive side might not have any active components, so there is no BFM or
sequence driver at all. In such cases, the Receive monitor can be placed inside a single agent that combines Receive and Transmit activities. This is especially convenient if the Receive and Transmit sides interact. (See the XSerial golden eVC for an example.)

e Reuse Methodology

4-5

Typical eVC Architecture

Clocks and Events

4.1.3

Clocks and Events

One decision facing eVC developers is whether to have the clock(s) propagated down to each agent or to use a central clock in the env that all agents will refer to. Verisity recommends the following:

To the extent possible, one centralized clock should be used. (Similarly, any other frequently occurring
event, such as reset, should be centralized.) This should be placed in a special unit called a synchronizer. An instance of the synchronizer unit should normally be located in the env. The primary reason for this is to eliminate unnecessary performance overhead.

On the other hand, if the protocol denes that agents can have different clocks (for example, different
speeds), then each agent should have its own clock. Centralized clocks should be implemented by maintaining a pointer from the agents to the synchronizer instance in the env and referring to events as synch.clock. This approach provides more exibility over having the events dened in a static position within the eVC. Sequence drivers will always have their own clock. This is necessary to simplify the user interface by allowing a uniform way to extend the sequence body() TCMs without needing to know the specic clock name.

4.1.4

DUT Signals

Reference to DUT signals should be done using external ports. Verisity recommends that related signal ports are collected in units called signal maps. Signal map instances can be placed in any natural location, typically either the env unit (if it is a signal used by all agents) or in an agent (for agent-specic signals). Where multiple units must access the same signal map, each unit should have a pointer to the instance of the signal map.

4.2

A Look at Agents

This section includes:

What Are Agents? on page 4-7 Components of Agents on page 4-8 Some Important Guidelines for Agents on page 4-12

4-6

e Reuse Methodology

Typical eVC Architecture

What Are Agents?

4.2.1

What Are Agents?

Agents are the key to eVC architecture. In most eVCs, agents represent independent devices and have standard main elements. Some of the elds in the agents are also standard and should appear in all eVCs. Examples of this standard organization and these standard elds can be seen in the golden eVCs. Agents are either ACTIVE or PASSIVE. ACTIVE agents are agents that drive DUT signals. PASSIVE agents never do that, either because they just monitor an interface within the DUT or because, according to the protocol, no signals need to be driven. In addition to monitoring the activity of a corresponding DUT agent, PASSIVE agents can also add checks, scoreboards, and coverage on top of what is predened in the eVC. Typically, these should be used in verifying the DUT but should not be part of the active agent. This is coded by using a predened type:
erm_active_passive_t: [ACTIVE, PASSIVE]; // Predefined in evc_util

The user must dene the active_passive eld. For example:

extend vr_atm_agent_u { active_passive: erm_active_passive_t; };

In addition to the ACTIVE / PASSIVE attribute, agents are considered proactive if they initiate transactions, and reactive if they only respond to requests. These attributes are not reected as elds or eld values in code. Both ACTIVE and PASSIVE agents have a monitor. The monitor can be instantiated directly in the agent. A PASSIVE agent does not have a BFM or a sequence driver. Both are instantiated within the ACTIVE subclass (or when clause) of the agent. For example:
unit vr_atm_agent_u { active_passive: erm_active_passive_t ; monitor: vr_atm_monitor_u is instance; when ACTIVE vr_atm_agent_u { bfm: vr_atm_bfm_u is instance; seq_driver: vr_atm_sequence_driver is instance; }; };

When an agent cannot drive signals (because the protocol does not allow it), it does not have an active_passive eld (because it is always PASSIVE). Other standard elds include kind elds that allow specifying subtypes of agents and name/ID elds that allow identication of each agent (as described in Instance Names and IDs on page 9-6).

e Reuse Methodology

4-7

Typical eVC Architecture

Components of Agents

Any agent in an eVC can be used as a PASSIVE agent. PASSIVE agents represent DUT devices that are only monitored by the eVC. The PASSIVE agent collects information from the DUT and holds that information as a reference for the verication environment. This enables orderly monitoring of the DUT agent collecting information and checking its behavior from a well dened place in the eVC.

4.2.2

Components of Agents

Figure 4-5 Agent Internals

Cong:
active_passive name kind == TX

Agent ACTIVE Sequence Driver seq

Signal Map Passive Mon

has_coverage has_checker

BFM

DUT

All agents have a xed basic architecture with optional additions as required by the specic environment. The interface of an agent consists of a conguration unit, a sequence driver, and the signal map connecting it to the DUT. Agents should be designed to work as independently as possible, not relying on a specic type of env, because independent agents are more easily adapted to unforeseen needs that eVC users might have. Therefore, it is important that the agent conguration and signal map are internal to the agent and are passed to the agent by the enclosing unit. Note An agent can also have a pointer to its enclosing environment. Through the pointer, the agent can obtain the conguration parameters. In this case, the agent is dependent on a specic environment and can only be instantiated in that specic type of environment. For more detail on the agent components, see:

Agent Conguration and Signals on page 4-9

4-8

e Reuse Methodology

Typical eVC Architecture

Components of Agents

Sequence Drivers on page 4-9 Monitor on page 4-9 BFM on page 4-10 Checker on page 4-11 Coverage on page 4-11

4.2.2.1

Agent Configuration and Signals

The agent conguration species an agents interface with the rest of the verication environment. It contains the mode of operation (for example, active_passive, has_checker, has_coverage) and additional static information needed for the agents operation, such as the bus width, endianness, etc. We recommend encapsulating these parameters in a cong struct to present a well-dened interface for the agent. Some conguration elds like active_passive are used for subtyping. These elds must reside in the agent or be propagated from the cong struct to the agent. All other elds are dened in the cong struct. This struct can be constrained from the enclosing unit, thus eliminating the need for a parent pointer and allowing instantiation of the agent in different environments. For the sake of efciency, cong elds that are used frequently can be copied into a local eld.

4.2.2.2

Sequence Drivers

Sequences are the test writers interface to control the verication process. All test-specic control, including reset and error injection, should be available through sequences. The sequence driver is a unit instantiated in the active agent. By default, it is connected to the BFM in pull mode. (Push mode is not recommended.) Items generated in the sequence driver are sent to the BFM whenever an item is available and the BFM is ready to accept a new item. At any given time, the BFM and monitor provide the current DUT state to the sequence driver for generating sequence items. The sequence driver must support both standalone operation (generation of items independent of higher-level protocols) and layering of higher-level protocols (generation of items based on higher-level protocols).

4.2.2.3

Monitor

The monitor is responsible for extracting signal information from the DUT and translating it into meaningful events and status information. This information is available to other components of the agent and to the test writer. The monitor should never rely on information collected by other components such as the BFM.

e Reuse Methodology

4-9

Typical eVC Architecture

Components of Agents

The monitor is a unit that is always instantiated (regardless of subtypes). Its functionality should be limited to the basic monitoring that is always required. Additional high-level functionality that might be required should be implemented separately on top of the monitor. This includes protocol checkers, scoreboards, and coverage, used typically, but not only, in the passive agent. The events recognized by the monitor depend on the actual protocol. Typically, for the basic data item the monitor provides an item_started and an item_ended event (for example, packet_started and packet_ended). The monitor collects the item data from the signals and creates a current_item that has the complete item data, ready to be used when the item_ended event occurs. In addition to the raw data, the monitor should collect relevant timing information such as the duration of the transaction.

Monitor Checking and Coverage

Coverage and checkers should be implemented on top of the monitor in subtypes of the monitor such as has_checker and has_coverage. That minimizes performance overhead if those units are not used. The has_checker and has_coverage ags should be propagated to the monitor so that the monitor code can be optimized.

Global Monitor
Some eVCs require a system-level monitor in addition to the agent-level monitors. This is typically used in broadcast protocols. In point-to-point protocols, agent monitors are usually sufcient.

4.2.2.4

BFM

BFMs do all of the signal driving from agents. The BFM is a unit instantiated only in ACTIVE agents. Changing an ACTIVE agent to PASSIVE prevents that agent from driving signals. No generation is done in the BFM. The BFM receives a data item (from the sequence driver) and performs all operations required to send the data item to the DUT according to the protocol rules. The item should contain all necessary information to complete the transaction. To perform its task correctly, the BFM must know the current state of the DUT. The BFM can sense the DUT signals directly or use signal information extracted by the monitor.

Errors in the BFM

The BFM should never issue a dut_error. Errors such as unexpected BFM state should be caught by assertions. If possible, a message might be issued while the ow continues. Protocol errors should be caught and reported by the checker part of the monitor.

4-10

e Reuse Methodology

Typical eVC Architecture

Components of Agents

4.2.2.5

Checker

Typically, a checker is used to verify a DUT, but it can also be used to verify the correctness of the active eVC agent. The checker can be implemented either as a separate unit in the agent or in a has_checker subtype of the monitor. By default, the has_checker ag should be TRUE in passive mode and FALSE in active mode. The checker operates based on events and data collected by the monitor. If it is implemented as a separate unit, it has a pointer to the monitor that is set by the agent when the checker is instantiated. At a minimum, the checker should check the validity of the basic data item (for example, packet) and the related timing requirements according to the protocol.

4.2.2.6

Coverage

Typically, coverage is used to verify a DUT. It can also be used to verify the eVC active agents capabilities by covering sequence types. Coverage can be implemented either as a separate unit in the agent or in a has_coverage subtype of the monitor. By default, the has_coverage ag is TRUE in passive mode and FALSE in active mode. If an end user wants to verify the eVC active agents capabilities, the has_coverage ag can be set to TRUE. Coverage operates based on events and data collected by the monitor. If it is implemented as a separate unit, it has a pointer to the monitor that is set by the agent when the coverage unit is instantiated.

Default eVC Coverage

The default coverage denition of the eVC should be based on events and data collected in the monitor. The coverage group should be based on a monitor event that indicates the completion of a transaction (for example, packet_ended). The coverage denition includes:

Signicant elds of the data item (for example, packet) Related temporal data (for example, delay or transmission time) Cross-coverage items required for covering the interface specication Additional agent elds indicating the mode of operation

e Reuse Methodology

4-11

Typical eVC Architecture

Some Important Guidelines for Agents

4.2.3

Some Important Guidelines for Agents

Important agent guidelines:

It is very important to separate the BFM from the monitors. When agents are PASSIVE, they should
be able to use their monitors without interfering with the DUT operation.

There are many possible names for the main entities in the agent, and people tend to choose differently.
To eliminate unnecessary confusion, we propose the following names for these standard entities: Use Agent BFM Monitor Do Not Use Device Driver Collector

For more details, see Terminology on page 4-23.

4.3

A More Complex eVC Example

The rst example we looked at was an eVC for a very simple communication protocol, the XSerial interface. Now we examine a more complex eVC, an eVC for a bus. Figure 4-6 shows the vr_xbus eVC added to the DUT verication environment.

4-12

e Reuse Methodology

Typical eVC Architecture

A More Complex eVC Example

Figure 4-6 XBus eVC

xbus_env Cong
: name has_... ...

xserial_env MASTER Agent Cong SD

seq

SLAVE Agent Cong SD

seq

ARBITER Agent Cong SD

seq

Cong:
name

RX Agent Cong
Signal Map

TX Agent Cong
Signal Map

...

SD
seq

SD
seq

DUT

xbus xbus

xbus

At rst glance, you can see the architecture of the XBus eVC is very similar to the XSerial eVC. There is an env encapsulating conguration elds, signals, and several agents, and the agents are organized internally in a similar way to the XSerial agents. However, the XBus protocol is more complex than the XSerial, and this is reected in the various types of XBus agents. The agents here can play the roll of a bus master (initiating activity on the bus), a bus slave (responding to bus master requests but not initiating activity), and an arbiter (coordinating between the masters so that only one master initiates activity on the bus at a given time). The exact agents vary for different buses, but this is a very typical arrangement. The XBus eVC allows for a list of master agents and a list of slave agents. Thus the number of agents instantiated can vary when the eVC is used in different situations. In the XSerial eVC, there are usually exactly two agents, but one of them might be ignored. There are other differences we can notice. The XBus has a bus monitor in addition to the agent monitors, while the XSerial eVC has only agent monitors. The signals in the XBus are grouped under the env, while the signals in the XSerial eVC are grouped in the agents. From these differences, it is clear that a typical eVC architecture can have some variance and yet still be quite similar.

e Reuse Methodology

4-13

Typical eVC Architecture

Combining eVCs

4.4

Combining eVCs

The rst examples we looked at were standalone eVCs. We now look at an SoC example that combines several eVCs. Figure 4-7 shows such a verication environment. Figure 4-7 XSoC eVC
xsoc_env xbus_env
Cong: name has_...

MASTER Agent Cong SD

seq

SLAVE Agent Cong SD

seq

ARBITER Agent Cong SD

seq

...

xserial_env xserial_env TX Agent RX Agent Cong: RX Agent TX Agent name Cong: Cong ... name Cong Cong Cong ... Signal Signal
Signal Map Signal Map

Signal Map

Sequence driverSD
seq

SD
seq

DUT

xbus
xbus serial dev #2

xbus
serial dev #1

In this case, the SoC verication environment could be the end users full environment. Still, we choose to represent it as an eVC, because it highlights the fact that any verication environment today can turn into a verication component in a bigger verication environment tomorrow. This is the rst example we see where one eVC is making use of other eVCs. The XSerial and XBus eVCs are instantiated within the XSoC eVC. In fact, the XSoC eVC has no agents of its own, although it probably will have some conguration that is not shown here simply because the diagram is crowded. In this example, the DUT has two XSerial devices, and thus the XSoC eVC has a list of xserial_env instances. Not shown in Figure 4-7 are things like the scoreboards that check the data end-to-end between the two eVCs. All in all, we can see that the XSoc eVC makes thorough use of the lower-level eVCs. By integrating components, it creates a new and bigger verication component without adding much new code. You can nd more information about system eVCs in the sVM lib.

4-14

e Reuse Methodology

Typical eVC Architecture

Layering eVCs

4.5

Layering eVCs

Layering is a technique that lets generation and monitoring of trafc be split into distinct logical layers. This enables independent control over behavior at each layer during generation and independent observation of behavior at each layer during monitoring. Layering is normally used in eVCs for protocols that naturally split into layers, for example, ATM over Utopia (ATM and Utopia each being a layer) or Ethernet (as in Ethernet packets over XGMII over XSBI). Layered eVCs provide a exible, scalable, and reusable approach to implementation of verication solutions for multi-layer protocols. You can deliver a separate eVC for each layer or a combined eVC with functionality for all layers. Single-layer eVCs can be written without the need for prior knowledge of which other layer eVCs they might be used with. The protocol for interconnection can be separately encapsulated in connector code, which in turn can be delivered as a separate eRM package. Any eRM-compatible eVC can be used as a lowest-layer eVC. Higher-layer eVCs require a method-based API (but can optionally have an additional signal-based API). Throughout this section, the example is of ATM over XSerial. This section contains:

Typical Layering Applications on page 4-16 Requirements for Lower-Layer eVCs on page 4-16 Requirements for Higher-Layer eVCs on page 4-17 Inter-Layer Connection on page 4-18 Partitioning of Layers and Connections Between Packages on page 4-21 Separation of Control in Multi-Layer Sequences on page 4-21 See Also Verisity ATM eVC Overview (vr_atm_overview.pdf) in the erm_lib/vr_atm/docs directory Verisity XSerial eVC Overview (vr_xserial_overview.pdf) in the erm_lib/vr_xserial/docs directory

e Reuse Methodology

4-15

Typical eVC Architecture

Typical Layering Applications

4.5.1

Typical Layering Applications

There are two common forms of layered eVCs: single-layer eVCs and multi-layer eVCs.

Single-layer eVCs provide functionality relating to a single layer in a protocol, but they also provide
hooks to let other protocol layers be connected above or below as appropriate. Such eVCs enable a plug-and-play approach to building multi-layer solutions.

Multi-layer eVCs combine two or more protocol layers in a single eVC using a layered approach.
Such eVCs provide a single-package solution for a multi-layer protocol while letting the user get control and visibility at each protocol layer.

The decision about which approach to take (single-layer or multi-layer) depends on the specic protocol(s) in question. There may be both commercial and technical aspects to this decision. In this chapter, we describe the single-layer approach in detail and provide some discussion of how the same techniques can be applied to multi-layer eVCs. Example code is drawn from the Golden eVCs for demonstrating how to layer ATM over XSerial:

The code for the ATM eVC (an example of a higher-layer eVC) can be found in the erm_lib/vr_atm
directory.

The code for the XSerial eVC (an example of a lowest-layer eVC) can be found in the
erm_lib/vr_xserial directory.

Example code for the connection between the ATM and XSerial eVCs can be found at
erm_lib/vr_xserial/examples/layering_atm. Example code for the connection between the ATM and XBus eVCs can be found at erm_lib/vr_xbus/examples/layering_atm.

4.5.2

Requirements for Lower-Layer eVCs

Lower-layer eVCs must be able to communicate with the DUT in the normal way via some form of signal interface. They also must have sufcient hooks to allow connection to higher-layer eVCs. For data being generated by a higher-layer eVC and then driven into the DUT via the lower-layer eVC, the connection between the layers is achieved through the sequence interface. Lower-layer eVCs must have a standard sequence interface implemented using Pull Mode. The connection between the layers is then implemented as one or more special connector sequences. For data being collected from the DUT by the lower-layer eVC and passed to the higher layer eVC, the connection between the layers is achieved through the scoreboard hooks. Lower-layer eVCs must have sufcient scoreboard hooks that the higher-layer eVC can extend to extract the data that it requires. Any standard, eRM-compatible eVC can be used as a lowest-layer eVC in a layered solution without modication so long as its sequence drivers use Pull Mode.

4-16

e Reuse Methodology

Typical eVC Architecture

Requirements for Higher-Layer eVCs

4.5.3

Requirements for Higher-Layer eVCs

Higher-layer eVCs have one signicant difference from lowest-layer eVCs they normally do not have a mechanism for driving and sampling signals in the DUT. Instead, a higher-layer eVC provides a set of method calls that allow transfer of data to and from a lower-layer eVC. In some cases, an eVC might need to be capable of acting either as a higher-layer eVC or as a lowest-layer eVC. For example, an XGMII (Ethernet) eVC might be used to layer over an XSBI eVC to generate and collect XGMII layer data while connected to an XSBI protocol DUT. However, the same eVC might be connected directly to XGMII signals for a DUT that has an XGMII port. In such cases, Verisity recommends that the agent have method calls suitable for use in layering the eVC over lower-level eVCs. The env can then have an optional signal-based interface that calls the methods in the agent as appropriate. Typically, two method calls are provided, one for passing data in each direction. Normally, these are placed in the env unit of the higher-layer eVC. However, it is legal to place them either in the agent unit or the BFM unit (for the higher-to-lower-layer direction) and in the monitor unit (for the lower-to-higher-layer direction). When deciding where to locate these methods, bear in mind the likely use model for the higher-layer eVC, and try to choose an interface that is intuitive for users. Note These method calls are always called from the lower layer eVC. Hence, both eVCs are operated in Pull Mode. When designing the method interfaces, ensure that they are sufciently exible to support any possible lower-level protocol. For example, although it might seem sensible for a method call for an ATM eVC to work with data partitioned into bytes, this might not be suitably exible when layered over a lower-layer eVC that transfers data one bit at a time. Similarly, a lower-layer eVC that can transfer data 32 bits at a time should not have to call the ATM eVCs method interface four times for each transfer. As a general rule, method calls should pass a list of bits so that the lower-layer eVC can decide how much data to request or return at a time. The following code examples illustrate a typical method interface for an ATM eVC. Two methods are provided, one for each direction of data ow:

get_cell_data(n : uint, rst : *bool) : list of bit @sys.any is undened; collect_rx_cell_data(d : list of bit, rst : bool) is undened;
The get_cell_data() method should be called by a lower-layer eVC to obtain ATM cell data from the Tx path of the ATM eVC. The parameter n indicates how many bits of data should be supplied. The appropriate number of bits is returned as a list. If the rst bit of this list represents the start of an ATM cell then the rst parameter is returned as TRUE. If there is cell data left from a current cell and n is larger than the number of remaining bits, then the returned list of bits only contains the remainder of the current cell. To obtain the beginning of the next cell, this method must be called again. If no cell data is available, then an empty list is returned and the rst parameter will be FALSE.

e Reuse Methodology

4-17

Typical eVC Architecture

Inter-Layer Connection

The collect_rx_cell_data() method should be called each time some cell data is detected by a lower layer on the Rx Path. The d parameter should contain the latest fragment of the bit list for the cell, and rst should be TRUE if this is the beginning of a cell. The d parameter should consist only of data from a single cell. Any data that pushes the current cell over the 53-byte limit will be discarded.

4.5.4
1. 2. 3.

Inter-Layer Connection

To connect two layers: Create the necessary pointer(s) to the upper layer in the lower layer. Connect received trafc by extending the Rx monitors scoreboard hook in the lower layer to call the appropriate method in the higher layer. Create the connector sequence(s) for the lower layer sequence driver that takes appropriate data from the higher layer.

The rest of this section examines each of these steps in more detail:

Step 1: Pointers to the Upper Layer on page 4-18 Step 2: Rx Monitors Scoreboard Hook on page 4-19 Step 3: Connector Sequences on page 4-19

4.5.4.1

Step 1: Pointers to the Upper Layer

The upper layer does not need to know anything about the lower layer, but the lower layer must know about the upper layer. For that, a pointer is typically placed either in the env or the agent of the lower layer. A copy of this pointer might need to be propagated to other units within the lower layer (most notably the sequence driver). Note The addition of the pointer(s) must not compromise the standalone behavior of the lower layer.

Example
extend vr_xserial_tx_driver_u { atm_evc : vr_atm_env_u; }; extend vr_xserial_agent_u { atm_evc : vr_atm_env_u; keep soft atm_evc == NULL; when ACTIVE has_tx_path vr_xserial_agent_u { keep tx_driver.atm_evc == read_only(atm_evc); };
4-18 e Reuse Methodology

Typical eVC Architecture

Inter-Layer Connection

};

4.5.4.2

Step 2: Rx Monitors Scoreboard Hook

When extending the Rx monitors scoreboard hook, consider the granularity with which data is passed to the higher layer.

Example
extend vr_xserial_agent_u { rx_frame_completed(frame : vr_xserial_frame_s) is also { if atm_evc != NULL { if frame.payload is a ATM vr_xserial_frame_payload_s (d) { atm_evc.collect_rx_cell_data(pack(packing.low, d.data), d.first); }; }; }; };

4.5.4.3

Step 3: Connector Sequences

Creating a connector sequence for the lower layer sequence driver that takes data from the higher layer is potentially the most complex step in creating a layered eVC architecture. The underlying principle is to create a sequence that drives appropriate lower-layer data according to data acquired from the higher layer. There can be multiple valid ways of doing this. For example, when layering ATM over XSerial, the connector sequence might send a single XSerial frame containing a fragment of an ATM cell, or the connector sequence might send multiple XSerial frames making up a complete ATM cell. Often it makes sense to create a library of connector sequences that address different testing scenarios. In many cases, connector sequences embody protocol factors that are specic to the layering of the two protocols. For example, neither the XSerial nor the ATM specications specify how to layer ATM over XSerial. In this case a separate specication is required to indicate how ATM cells should be transported over an XSerial link. It is this method of transportation that is typically encoded by the connector sequence. An additional issue is that the higher-layer method that supplies data to the lower layer will, of necessity, be a TCM. At best, this TCM will consume Specman tick time. At worst, it can consume real simulator time. For example, a wait statement in a higher-layer sequence can cause a call to driver.get_next_item() in the higher-layer BFM to stall. That, in turn, might cause the higher-layer interface TCM to consume simulator time.

e Reuse Methodology

4-19

Typical eVC Architecture

Inter-Layer Connection

Constraints associated with a do action in the lower-layer sequence are not allowed to consume time. As such, a mechanism is required to delay the do pending the return of data from the higher layer. This is typically achieved using the connector sequences pre_do() TCM. This TCM gets called immediately before each do action in the sequence and can be used to delay the do while data is collected from the higher layer. Typically, the code in the pre_do() TCM calls the higher-layer TCM to obtain the higher-layer data and stores this locally within the sequence. The do action can then constrain the lower-layer data item according to this locally stored data. The following code illustrates a typical connector sequence. This sequence sends a single ATM XSerial frame containing ATM data if such data is available. If no ATM data is available, then the sequence sends an IDLE frame.
extend ATM_FRAME_CONNECTOR vr_xserial_tx_sequence { -- This is the ATM cell data in raw format. !raw_data : list of bit; -- This field is TRUE if raw_data contains the start of an ATM cell. !first : bool; -- This is the actual packed data as stored in the XSerial frame -- payload. !payload_data : uint(bits:7); pre_do(is_item : bool) @sys.any is also { if is_item { if driver.atm_evc == NULL { error("Attempting to do ATM sequence, but driver's atm_evc field is NULL"); }; raw_data = driver.atm_evc.get_cell_data(7, first); payload_data = pack(packing.low, raw_data); }; }; body() @driver.clock is only { do frame keeping { soft it.payload.frame_format == MESSAGE; raw_data.size() > 0 => it.payload.frame_format == ATM; it.payload is a MESSAGE vr_xserial_frame_payload_s (p) => p.message == IDLE; it.payload is a ATM vr_xserial_frame_payload_s (p) => (p.data == payload_data) and (p.first == first); }; }; };

4-20

e Reuse Methodology

Typical eVC Architecture

Partitioning of Layers and Connections Between Packages

4.5.5

Partitioning of Layers and Connections Between Packages

Following are three situations in which eVCs might be layered.

Independent eVCs
The most general case for layering is as follows:

Higher-layer eVC is supplied by vendor/developer 1. Lower-layer eVC is supplied by vendor/developer 2. Connection between layers is supplied by vendor/developer 3.
In this situation, the higher- and lower-layer eVCs provide the relevant hooks to enable layering. Normally, these eVCs would not contain any code relating to the connecting of the two specic protocols. As such, it is important that the layer eVCs provide all required hooks as part of their published APIs. It is also important that the connection code does not use anything other than the published APIs. In such cases, the inter-layer connection can be part of an end-user verication environment, or it can be delivered as a separate eRM package.

Dependent eVCs
Sometimes the layer eVCs can be written knowing that layering between them will take place. In such cases, it might be appropriate to build the layering code into one of the individual layer eVCs (typically the higher-layer eVC).

Layering within Single eVC

In certain cases, it might not make sense to deliver the individual layers as separate eVCs. In such cases, a multi-layer eVC might be the most appropriate vehicle for delivery. In a multi-layer eVC, each layer will be handled by one or more layer-specic agents, for example, layer_1_agent, layer_2_agent, etc. Each agent is essentially the same as in the multiple-eVC implementation. The only difference is that all agents for all layers would be contained in a single env. The developer might want to provide ags to allow selective enabling and disabling of layers.

4.5.6

Separation of Control in Multi-Layer Sequences

Once a protocol is divided so that there is a sequence driver at each layer, control over scenario generation becomes signicantly more exible. By default, a lower-layer eVC in a multi-layer environment is congured to perform continuous connector sequences. As such, scenarios can be written at higher layers and the lower layer data is automatically created.

e Reuse Methodology

4-21

Typical eVC Architecture

Modeling FAQs

Specic lower-layer behavior can be achieved by writing sequences that mix connector sequences with other required behavior (such as error conditions). For more coordinated testing, a virtual sequence driver can be used to regulate trafc injection at each layer. For example, a virtual sequence could be written to drive continuous ATM cells over an XSerial link while occasionally grabbing the XSerial sequence driver to override the default connector sequence with one that introduces XSerial-specic error conditions.

4.6

Modeling FAQs

Many of the differences between the two sub-eVCs (XSerial and XBus) and the way they are used raise interesting architecture questions. Q: If the DUT has N ports of same protocol, should we have 1 env with N agents, or N envs each with single instance agents? For example, if a DUT has two pairs of serial ports, which of the following arrangements is better?
xserial_env or RX Agent TX Agent xserial_env xserial_env RX TX Agent RX Agent

TX Agent

A: It depends on the protocol:

In case of serial interface, typically each pair of ports is independent and has 2 agents in it (RX/TX).
Therefore it is natural to have two envs (as shown on the right side of the above gure).

In buses, typically there are many agents on a bus. Thus if the DUT has one bus, it is natural to have
a single env for all N agents (as shown on the left side of the above gure). Q: If an env has a single agent, should env and agent be merged (that is, have only an env unit with no agent in it)?
x_env X Agent or x_env

A: They should be kept separate (as shown on the left side of the above gure).

It is okay to have a single agent in env. It will probably be more reusable this way. It is okay to have zero agents in an env. For example, SoC has envs in it but no agents.
Q: Must the Monitor and BFM be units under the env/agent? Might they be TCMs? A: It is better to have them as units, not as TCMs.

4-22

e Reuse Methodology

Typical eVC Architecture

Terminology

For small environments, having them as TCMs might make sense, but for big environments it can
create problems. Therefore, for uniformity, they should be units.

4.7

Terminology

The following sections provide denitions of terminology. These terms are used extensively in this book, and as many of these terms are used slightly differently by different people, be aware of the specic connotations we give to each of them. This section includes:

Main Entities on page 4-23 Sub-Entities on page 4-24 Agent Types on page 4-25 Data Item Naming Convention on page 4-25 Full Legend for Architecture Diagrams on page 4-26

4.7.1
DUT

Main Entities
Device Under Test, the device to be veried (typically an HDL design). In any given verication environment, there is only one DUT. (Even if the env is composed of several envs, each with its separate DUT block, still in the full env, the total of all blocks should be considered one DUT.)

Package Data Item

An independent and modular eVC, utility, or shareware. An e object that corresponds to a specic data structure in the eVC architecture. Data items are implemented as structs. Data item examples: packet, transaction, instruction, and so on.

e Reuse Methodology

4-23

Typical eVC Architecture

Sub-Entities

Env

The root unit for an independent verication environment, for a well dened protocol, interface, specication, or HW block. When combining HW blocks to HW systems, the envs can also be combined by nesting block envs into the system env. Each eVC denes an evc_env (child of any_env). Multiple bus instances in the DUT imply multiple eVC instances (envs).

Agent

An e object that represents a device or similar entity in a verication package (for example, master, slave, TX/RX machine). Agents are implemented as units and contain a BFM, sequence driver, sequences, and a monitor.

4.7.2
Monitor

Sub-Entities
A passive entity that samples the DUT signals (but does not change their values at any time). Functionality: Extracts events, prints traces, collects transaction and data items, does checking and coverage.

BFM

An active entity that emulates an auxiliary device for the DUT. Functionality: Samples and drives the DUT signals. Always instantiated inside agents (a unit)

Monitor-BFM Relations
BFMs and Monitors are typically built independently (even if they look at the same signals). Therefore each can work without the other.

Monitor-BFM Guidelines It is okay for eVC developers to duplicate or reuse some common code. Within an agent, monitors must not depend on the presence of a corresponding BFM. Within an agent, BFMs might depend on the presence of a corresponding monitor.

4-24

e Reuse Methodology

Typical eVC Architecture

Agent Types

4.7.3

Agent Types

Agents can be of two types (ACTIVE or PASSIVE): ACTIVE Drives signals into the DUT.

Proactive Initiates transactions and send them to the DUT Reactive Reacts to transactions as they come from the DUT
PASSIVE Looks at HW blocks internal to the DUT (often with no external interface). Can also collect transactions from the DUT, but it does not drive signals. BFM and sequence drivers are disabled.

Agent Examples
eVC AHB USB XSerial Proactive eVC master host TX (RX) Reactive eVC slave device (RX) PASSIVE

Note All agents in an eVC can be used as PASSIVE agents.

4.7.4

Data Item Naming Convention

Each communication protocol has a basic data item that is generated and sent by the BFM and collected by the monitor. Following is the recommended naming convention for the type of the basic data item: package-name_agent_[driven|monitor]_item-name For example, vr_xbus_master_driven_burst is the burst generated and sent by the master. vr_xbus_slave_monitor_burst is the burst reconstructed by the monitor in the slave. The types can be inherited from a common type using like inheritance. If the types are closely related, when inheritance might be more applicable.

e Reuse Methodology

4-25

Typical eVC Architecture

Full Legend for Architecture Diagrams

4.7.5

Full Legend for Architecture Diagrams

Figure 4-8 Full Legend for Architecture Diagrams

Struct Data item DUT access Unit
unit Enclosing unit Instantiated unit Enclosing unit Sequence Driver DUT struct

Data ow

Unit instantiation

Color

Monitor BFM DUT

Subtype Struct/unit pointer

Subtype struct Topic: eld 1 eld 2 unit

Sequence execution
seq Sequential: seq seq seq Parallel: seq seq

Field grouping Event

4-26

e Reuse Methodology