ACT and AHB eVC ARM's AMBA Compliance Testbench working with Verisity's AHB eVC

Abstract

Introduction

The AMBA Compliance Testbench (ACT) from ARM takes care of the compliance aspect. IP that is certified as being AMBA compliant offers the benefits of greater reuse between AMBA-based SoC designs, and offers higher confidence in system integration. At the system level, SoC developers can use the ACT to check for adherence to the AMBA protocols of their entire system.

However, IP and AMBA-based SoCs not only need to be compliant to the AMBA specification but also need to be functionally correct. The AHB e Verification Component (eVC) from Verisity can be used to verify all the other functionality aspects, both at the module level, and the system level. This is done by employing constraint-based random test generation, data and assertion checking and functional coverage analysis.

AMBA Compliance Testbench (ACT) from ARM

The AMBA Compliance Testbench (ACT)
The ACT enables the supplier of an IP component to demonstrate that the verification of the interface has achieved a predefined quality and compliance level and this, in turn, gives the SoC integrator confidence that the component functions correctly when integrated into the rest of the SoC design.

Key Benefits
The ACT measures compliance to the AMBA bus specification by providing a few critical verification components:

• Compliance coverage requirements
  - Defined as functional coverage points in the e Verification language
  - Configurable to different module types
  - Determine when adequate compliance has been achieved
  
  
• Complete assertion checking
  - Unambiguous definition of the AMBA 2.0 protocol and detection of protocol violations
  
  
• Trick-boxes and simple vector driving
  - Bus-functional models for basic driving of bus transfers
  - Allows control and observation of non-AMBA signals
  - User configurable

ACT Modes
The ACT has two modes of operation:

• Active Mode - the ACT reads vectors describing stimulus that should be injected, and response checking information from a user-supplied test sequence file and executes accordingly. This compliance test environment configuration comprises the assertion checker, and the coverage monitor.
  
  
• Passive mode - is a standalone AMBA environment, with the active ACT components disabled. In passive mode, a system environment is used to provide the stimulus and response checking for the devise under test. This environment still uses the coverage monitor and the assertion checker. The ACT is not responsible for compliance of any module other than the DUT in this mode.

AMBA compliance testing is performed using a simulation environment in which the IP component is exercised. The simulation environment also contains the following elements, all implemented in e:

• Assertion checkers - A cycle-by-cycle check to ensure that the device under test obeys the rules of the AMBA specification.
  
  
• Functional coverage monitor - A monitor observes the bus transactions, and reports which of the required scenarios are observed during the test sequences/simulations.

The assertion checks are a fixed set of rules from the AMBA specification. To claim AMBA compliance, a component must have full functional coverage without violating any of these rules. The protocol rules cannot be configured. An example of a protocol rule or assertion is: “A master must insert an IDLE transfer after receiving a SPLIT or RETRY response.”

The functional coverage points are a list of various scenarios of bus transactions that must be observed within the test environment before compliance can be claimed. The aim of the coverage points is to ensure that the tests have sufficiently exercised the component under test. An example of a coverage point is: “The bus slave must be accessed by a read transfer followed immediately by a write transfer to the same address.” The advantage of using functional coverage points, compared to a predefined test sequence of bus transactions, is that it is easily adapted to the specific needs of any IP component, which may require (and/or support) only certain sequences of inputs. The custom stimuli can then be created (or used from an existing testbench) and coverage measured on it. Using functional coverage metrics also allows for each test scenario to contribute to multiple coverage points, according to the actual sub-scenarios it comprised.

Compliance
The ACT can only certify a DUT is AMBA-compliant when it has recognized that the DUT correctly handles all of the different types of bus transactions that it claims to support. For example, a DUT master claiming to support SINGLE, INCR, WRAP4, and INCR4 burst types for both read and write transfer directions must be simulated performing transfers of every combination of burst type and transfer direction before the ACT can certify AMBA compliance. It is the task of the ACT to monitor which coverage points the DUT is hitting over the course of a simulation and to check that all the relevant coverage points have been covered. When the DUT simulation has achieved full coverage, and there have been no assertion errors generated in the process, the ACT certifies the DUT is AMBA-compliant.

Compliance report
The compliance report is produced as part of the coverage analysis carried out by the ACT. One of the main roles of the compliance report is to list any coverage holes (empty coverage points) that might remain at the end of the simulation. The compliance report generated by the ACT consists of several sections:

• Header - presents information on the simulation run time and date, the DUT name, and the current ACT and AMBA version numbers.
• Unsupported modes - if the DUT does not support any of the standard AMBA modes these are listed here.
• Coverage results - this section is a guide to what extra coverage points must be hit during the DUT simulation, to achieve sufficient coverage for AMBA compliance.
• DUT errors and warnings - if the simulation generated any DUT errors or warning this is indicated here. For a DUT to achieve AMBA compliance, there must be no errors or warnings.
• AMBA Compliance certificate or a noncompliance statement

ACT-d and ACT-e
There are two types of ACT packages, ACT-d and ACT-e. The ACT-d is for use by IP developers and customers of ARM developing AMBA-based SoC designs. When you have a full set of test vectors that demonstrate compliance, the ACT-d can be used to generate a checksum. These can then be used to create an ACT-e environment for shipping to IP integrators along with the design IP itself. The ACT-e then, is a powerful vehicle for IP developers to provide standalone testbenches for their IP integrators, showing the IP has been thoroughly verified, and certifies as AMBA compliant.

After running the simulation, a compliance report is generated. The RTL and the stimulus, configuration, and compliance report files are packaged together. These are delivered to the IP customer with the ACT-e package.

The IP customer then installs the ACT-e package enabling the stimulus vectors to be rerun on the IP in standalone mode. Running the stimulus allows the integrator to check that the compliance certificate is valid, and to observe the functionality of the IP.

AHB eVC from Verisity

Each eVC comprises a complete set of elements for stimulating, checking and collecting functional coverage information on your device under test (DUT) implementation of the given protocol or architecture. The eVC expedites creation of a more efficient testbench for your DUT. The eVC can work with both Verilog and VHDL devices and with all HDL simulators that are supported by Specman Elite. You can use an eVC as a full verification environment or add it to an existing environment – such as an SoC verification environment.

AHB eVC
The AHB eVC is a ready-made highly configurable e verification environment suitable for any DUT that contains an AHB bus interface.

The AHB eVC can:

• Generate constrained-random tests on an AHB bus (bursts and transfers)
• Execute traffic over the bus as an AHB master to a DUT slave
• Respond to traffic coming from a DUT master as an AHB slave
• Check that the DUT adheres to all AHB protocol rules (using assertions)
• Use scoreboard checking to keep track of outstanding transactions
• Collect functional coverage information on bus traffic and DUT behavior

In addition to these, the eVC provides hooks to allow users to add additional features, as required to verify the full functionality of their design. By using the built-in hooks, and employing the inherent extensibility of the e language, an eVC user can create a complete testbench to verify not only the AMBA interface of his design, but the complete functionality of the design.

Features of the AHB eVC

• Generating and driving bus traffic (bursts and transfers) as an AHB master
  The eVC emulates the full behavior of up to sixteen AHB bus masters capable of generating all types of AHB bursts and transfers. The eVC masters enable testing of interesting scenarios over the bus by generating sequences of bursts according to some defined scenarios. Both big endian and little endian protocols are supported.
  
  
• Responding to bursts and transfers as an AHB slave
  Thr eVC can emulate the full behavior of any number of AHB bus slaves. The slave behavior is fully configurable to control how they respond to bursts on the bus.
  
  
• AHB protocol checking
  The eVC monitors bus traffic and creates a set of events to represent the bus behavior. The eVC then uses these events in assertions to check that all bus devices (both DUT and eVC) adhere to the AHB protocol. The eVC also uses these events to collect coverage information on bus traffic. This coverage information includes burst and transfer attributes, bus performance etc.
  
  
• Scoreboard checking support
  The eVC provides a general scoreboard that matches data at the byte level. A scoreboard is a powerful approach to keep track of input and output transactions, finding mismatches and occurrences of dropped data. It allows for example matching the data written to an agent on the AHB bus, with the data it transmitted or received from another external interface (e.g. a serial communication interface). The eVC also provides hooks and events that be used to add other implementation specific input/output scoreboards.
  
  
• Emulating additional bus logic
  The eVC emulates the additional bus logic that is required for simulating a full AHB bus environment:
  
  

  -	Arbitration The eVC emulates an arbiter that can arbitrate all existing masters, both DUT and eVC, using a basic arbitration scheme that can be modified.
  -	Decoding The eVC emulates a decoder that supports address decoding and HSELx driving of all existing slaves, both DUT and eVC.

  
  
• Tracing
  The eVC supports tracing for debugging purposes on all its elements.
  
  
• Bus traffic logging
  The eVC supports logging of bus traffic for purposes of debugging the DUT devices.
  
  
• The AHB eVC is compliant to Verisity’s e Reuse Methodology (eRM). eRM is a complete reuse methodology that codifies the best practices of eVC development, delivers a common eVC usage model, and ensures that all eRM compliant eVCs will interoperate seamlessly regardless of origin.

Which of them do I need?

The ACT focuses on the bus protocols of the AMBA interfaces of the DUT, and allows you to prove compliance. It has only rudimentary stimuli driving, but features full protocol/assertion checking and complete compliance coverage requirements as developed by ARM. Only the ACT can certify compliance.

By combining both the ACT and AHB eVC in the same testbench, you are able to quickly have an intelligent testbench exercising your entire system, and the ability of providing an AMBA compliance certificate, and passing that certificate on to the IP integrator.

Summary

Verisity and the Verisity logo are registered trademarks of Verisity Design, Inc. Specman Elite, eVC, and eRM are trademarks of Verisity. All other trademarks are the exclusive property of their respective holders. ©2003 Verisity Design, Inc.