Previous Section Next Section

15.2 eVC Architecture

Each eVC relates to different protocols, architectures, and designs. Therefore, one eVC can vary a lot from another eVC. Still, there is a lot of commonality in the design of various eVCs. In this section, we will investigate the commonality and some of the main differences between typical eVCs.

In this section, we take a sample XSerial eVC to show how a typical eVC should be constructed. The XSerial eVC is an example of how to code a general-purpose eVC for a point-to-point protocol. The chosen protocol is deliberately simple so that attention is focused on the eVC methodology rather than the difficulties in coding complex BFMs. The protocol is a synchronous, full-duplex serial protocol with a frame consisting of 8-bit data, 2-bit address, and 2-bit frame-kind. This chapter does not focus on the details of the protocol, but instead elaborates the structure of the XSerial eVC.

15.2.1 DUT and eVC

Figure 15-1 below shows a sample DUT that we will use to demonstrate some eVCs. This DUT has two external interfaces: a bus interface, and a serial interface. Each of these interfaces can interact with the external world, and therefore we attach an eVC to exercise and interact with each of them.

Figure 15-1. Example DUT

graphics/15fig01.gif

We will 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 Xserial eVC. A dual-agent implementation for the XSerial eVC is shown in Figure 15-2 below.

Figure 15-2. XSerial eVC—Dual-Agent Implementation

graphics/15fig02.gif

The XSerial eVC is encapsulated in the rectangle marked xserial_env. 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 fields, marked in Figure 15-2 as Config. This allows configuration of the env's attributes and behavior. The agents are units instantiated within the env.

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

In this representation of the eVC, there are two types of agents as shown in Table 15-2 below.

Table 15-2. Types of Agents in an eVC

RX agent

A receive agent that can collect data from the DUT's transmit port

TX agent

A transmit agent that can send data to the DUT's receive port

These agents are constructed in a standard way. The components of an eVC agent are described in Table 15-3 below.

Table 15-3. Components of an eVC Agent

Config

A group of fields that allow configuration of the agent's attributes and behavior.

Signals

A group of unit members that represent the hardware (HW) signals that the agent must access as it interacts with the DUT. Currently, the signals are implemented as string fields, all prefixed with "sig_".

Sequence Driver

This is a unit instance that serves as a coordinator for running user-defined test scenarios (implemented as sequences).

BFM

Bus Functional Model—a unit instance that interacts with the DUT and drives or samples the DUT signals.

Monitor

A unit instance that passively monitors (looks at) 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.

The XSerial eVC could also be implemented using a single-agent architecture as shown in Figure 15-3 below.

Figure 15-3. XSerial eVC—Single-Agent Implementation

graphics/15fig03.gif

Both the dual-agent and the single-agent architectures are good implementations. Depending on the specifics of the protocol with which the eVC deals, you might prefer one over the other.

In the case of the single-agent XSerial protocol, the Receive (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, in the single-agent XSerial protocol, the Transfer (TX) agent behavior also depends on flow 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 single-agent XSerial eVC, the RX agent is significantly simpler than the TX agent. Therefore, it is better to implement a single-agent eVC to efficiently model the flow control mechanism, given that the flow control involves a high level of interaction between the two directions. The single agent covers both the TX and RX directions. This single agent contains all of the monitors, BFMs, and sequence drivers required for both directions.

15.2.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 monitor's logic.

In general, most passive activity should be done by the monitor, while all active interactions with the DUT are done by the BFM. 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.

In addition, the monitor rather than the BFM is used to collect transactions that come from the DUT. Some ways this can happen are as follows:

15.2.3 Clocks and Events

An eVC developer must decide whether to have the clock(s) propagated down to each agent or to use a central clock in the env to which all agents will refer.

The following guidelines are recommended:

One should implement centralized clocks by maintaining a backpointer from the agents to the enclosing env unit and referring to events in the env as env.clock.

15.2.4 DUT Signals

It is important to differentiate DUT signals from other identifiers. References to DUT signals may be made by use of fields of type string. The names of these fields should have a sig_ prefix. A separate prefix makes it simpler to distinguish these signals. The sig_ fields should be placed in a natural location, typically either the env unit (if it is a signal used by all agents) or in an agent (for agent-specific signals).

15.2.5 Agent Details

Agents are the key to eVC architecture. In most eVCs, agents represent independent devices and have standard main elements. Some of the fields in the agents are also standard and should appear in all eVCs.

Agents are either active or passive. Active agents are agents that drive DUT signals. Passive agents never drive signals, either because they just monitor an interface within the DUT or because, according to the protocol, no signals need to be driven. Figure 15-4 shows the internals of a TX agent.

Figure 15-4. Agent Internals

graphics/15fig04.gif

Passive agents represent DUT devices that are only monitored by the eVC. The passive agent therefore allows the projection of information inside the DUT onto the passive agent, which is a container of the information collected. Any of the agents in an eVC can be used as a passive agent. This allows for orderly monitoring of the DUT agent—collecting information and checking its behavior from a well-defined place in the eVC.

15.2.6 Combining eVCs

The earlier examples we looked at were standalone eVCs. We now look at a System-on-Chip (XSoC) example that combines several eVCs. Figure 15-5 shows such a verification environment.

Figure 15-5. XSoC eVC

graphics/15fig05.gif

In this case, the XSoC verification environment could be the end user's full environment. Still, the XSoC verification environment can be represented as an eVC, because it highlights the fact that any current verification environment can turn into a verification component in a bigger verification environment in a future project. Designing a verification environment as an eVC helps create a consistent structure across different verification environments and projects.

In Figure 15-5, the XSoC eVC makes use of other eVCs. The XSerial and XBus eVCs are instantiated within the XSoC eVC. The XSoC eVC has no agents of its own. The DUT has two XSerial devices and one XBus device. Thus, the XSoC eVC has a list of xserial_env instances. The XSoC eVC integrates sub-eVC components to create a new and bigger verification component without adding much new code.

15.2.7 Typical Files in an eVC

Certain standard files are typically available with an eVC. Some files may be missing depending on the architecture of the eVC. The prefix evc for each file should be replaced by the name of the eVC.

Table 15-4. eVC Files

File Name

Description

evc_types.e

Global constants and types belonging to the eVC

evc_data_item.e

Definition of the data item struct evc_data_item

evc_agent_h.e

Header file: definition of an agent unit (optional)

evc_agent.e

Implementation of an agent unit

evc_env.e

Definition of the top-level unit evc_env

evc_monitor.e

Definition of central monitor unit, when relevant (for example, buses)

evc_agent_monitor.e

Definition of agent monitor unit, when relevant (for example, serial interface)

evc_agent_sequence.e

Predefined sequences / API methods

evc_checker.e

Protocol and data checks. Can be divided into agent/topic files

evc_agent_checker.e

Specific checks for each agent

evc_cover.e

Coverage definitions

evc_agent_cover.e

Coverage definitions

evc_wave.e

Definitions of wave commands for the eVC

evc_top.e

Imports all files

Instantiates eVC entities

Passed to sn_compile.sh (see Chapter 16 for details)

Previous Section Next Section