Extending Open Core Protocol (OCP) Functionality with VMM: Implementing a Slave Memory for Verification IP
Darrin Mossor, Corporate Applications Engineer
Paul Wyborny, R&D Engineer
Verification of an Open Core Protocol (OCP) based system can be a significant challenge, primarily due to the flexibility of the protocol, which provides a large number of configuration options. The need for shorter design cycles and faster time to market have produced solutions that leverage advanced features such as Constrained Random Verification (CRV) and methodologies like those outlined in the Verification Methodology Manual (VMM) for SystemVerilog. DesignWare Verification IP (VIP) for OCP has been designed to take full advantage of the techniques described in the Verification Methodology Manual and offers a powerful solution to address the challenge of OCP verification.
DesignWare OCP VIP
DesignWare VIP for OCP includes a master, slave and monitor. These components support the full range of OCP configurations and features outlined in OCP 2.1, including multi-threading, bursts and 2.1 tagging. It includes extensive examples to help engineers construct complex and powerful verification systems using the VMM methodology, including features like CRV, stimulus generation and response, and functional coverage. Note: While the DesignWare VIP for OCP also supports Verilog and VHDL control languages, the focus of this paper will be on techniques available with VMM.
Using Verification IP in a Testbench
By default, the Master and Slave VIP components represent an interface for an OCP system. The Master represents an Initiator, responsible for initiating a Read or a Write. The Slave represents a Responder and providing data or accepting the Write and the corresponding data.
The verification IP components represent an interface and not an entire DUT (see Figure 1).
This approach provides verification engineers the flexibility to insert the desired amount of functionality behind the Master and Slave. This might include extending existing functionality, creating complex transaction sequences, testing various configurations for the system and/or core. It gives the verification engineer maximum control to meet the verification goals of the system.
A good example of the flexibility and power of this solution is Slave memory. It would be unrealistic for the Verification IP to anticipate all Slave memory requirements that may exist for all users and all system configurations due to the variety of configuration options available in the OCP protocol. The current DesignWare VIP for OCP includes a default Slave memory implementation that while intended as a general solution, may not apply to all designs or implementations. Rather than force all users to use this exclusively, or provide a minimal solution that is unlikely to satisfy all users, a better solution is to leverage the extensibility inherent in the VMM methodology and the DesignWare Verification IP.
The approach discussed in this paper is included as part of the ocp_sys_vmm example included with the DesignWare Verification IP for OCP. It can be easily modified to support a wide range of memory implementations.
This approach demonstrates a simple method to implement a custom slave memory which can be easily tailored to the specific memory characteristics of a design. Simply download the latest version of the DesignWare Verification IP for OCP from the Synopsys DesignWare IP Directory, create the $DESIGNWARE_HOME as documented and installthe example using the provided tools:
$DESIGNWARE_HOME/bin/dw_vip_setup .e ocp_sys_vmm
Slave Memory Solution
There are two important considerations when constructing a solution to provide Slave memory.
The first relates to coordination of the storage of the memory with what is going on in the verification IP. This is important because it affects the mechanics of moving data in and out of memory. Accessing the information that is available as part of an OCP transaction, helps determine when to synchronize memory storage.
Using the available information, memory access can be implemented to write each word of data into memory immediately after its write phase completes, and to fetch read data from memory one word ahead of the current address (i.e. single-word pre-fetch). The latter is important so that the data is available when necessary for the transaction.
The second consideration that makes a configurable Slave memory solution a better approach has to do with the memory post/pre-fetch behavior that most accurately represents the system to be verified. This is relevant because it defines the ideal times for moving data in or out of memory.
Fortunately, VMM methodology and the DesignWare VIP for OCP are designed to make this kind of extension possible and consequently to provide the solution that best fits the environment.
OCP Slave Memory - Implementation
Implementation of a custom Slave memory solution requires an understanding and use of some basic VMM features as well as features of the OCP VIP such as Extended Classes, Callbacks and Slave Response Modes.
DesignWare OCP Verification IP uses base classes defined within the VMM and gives users access to extend the classes as necessary to add functionality. The definition of some classes and data structures is done in the implementation of the slave memory example and can also be further extended by the user as part of the creation of a custom memory.
Another part of a custom Slave memory solution is to create a callback to handle the new functionality. These are easily extended from the callbacks available with the DesignWare OCP
Slave. The DesignWare OCP VIP documentation contains a list and description of all callbacks available.
Slave Response Modes
The DesignWare VIP OCP Slave supports two mechanisms for controlling response behavior. These are referred to as 'Internal Responder' and 'External Responder'.
Both of these use a transaction object (created by the Slave) to define the response. In this case, .response' means control of all signals driven by the Slave. The strength in supporting both of these two approaches is that it allows the verification engineer to have as much control over the response as is necessary to meet the needs of the verification.
In Internal Responder mode, the Slave populates (via randomization) all of the response properties. This is the simplest and most straight forward approach. It also doesn.t require intervention in the testbench.
In the External Responder mode, the Slave sends the transaction object out to the testbench via a channel, and expects the testbench to send it back with response properties populated.
Since the Slave uses the response properties for the current phase of the transaction, it is possible in this mode for the testbench to populate the response properties incrementally, by keeping a handle to the transaction object, tracking its progress, and adding new response property values as necessary.
The response properties are controlled by adding constraints. Similar to the mechanism used to define Master delays in the scenarios, for each constraints may be added to the class which serves as the template for the Slave's internal or external response randomization in the examples shipped with the DesignWare VIP.
In this paper we.ve discussed the verification problems that face engineers today as well as how DesignWare Verification IP and VMM offer powerful tools to address those challenges. We have also outlined the basic steps necessary to build a custom Slave memory solution using DesignWare Verification IP for OCP using the VMM methodology. Synopsys DesignWare VIP and VMM provide a powerful set of tools which enable the creation of verification.
Read the detailed whitepaper of this article.