Previous Section Next Section

15.1 About eVCs

This section provides an introduction to eVCs.

15.1.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 Ethernet, AHB, PCI, or USB).

Each eVC consists of a complete set of elements for stimulating, checking, and measuring 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 testbench for your DUT. They can work with both Verilog and VHDL devices and with all HDL simulators that are supported by Specman Elite. eVCs can work with any simulator that supports the e language.

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

An 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.

Following is a partial list of possible kinds of eVCs:

15.1.2 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. It should also be possible to do this hierarchically.

Following are the benefits of making eVCs plug and play:

15.1.3 eVC Reuse Requirements

Table 15-1 lists the requirements that are essential for eVC reuse. The eRM specifies in detail how to implement each requirement.

Table 15-1. eVC Reuse Requirements

No interference between eVCs

  • No name space collision

  • No complex search path or directory dependencies

  • Handling dependencies on common modules

  • No dependencies on different versions of Specman Elite and its utilities

  • No timing dependencies

  • No dependencies on global settings

Common look and feel, similar activation, similar documentation

  • 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

Support for combining eVCs (control, checking, layering, and so on)

  • 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 simulation

  • Common way to do layering of protocols

  • Common way to do combined coverage

Support for modular debugging

  • Understanding combined constraints

  • Reconstructing the behavior of a single eVC in the verification environment

Commonality in implementation

  • Common data structures

  • Common eVC simulation testing methodology

  • Common way to use ports and packages

Previous Section Next Section