This section provides an introduction to 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:
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 System-on-Chip (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.
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:
Promotes code sharing
Offers customers a convenient, ready-to-use product
Makes eVC creation easier and faster
Table 15-1 lists the requirements that are essential for eVC reuse. The eRM specifies in detail how to implement each requirement.
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 |
|