Verifying Configurable Verification Interfaces Using OCP

Naturally, along with the advantages of flexibility come many variants of the implementation that fall under the official protocol specification. While this makes it easy to adapt the protocol to the individual requirements of a specific design implementation, it does present a challenge for the verification team. Verifying protocol interfaces is a challenging exercise for any verification group. Formal verification of protocols has become far more prevalent in recent years because of its ability to exhaustively remove all doubt of incorrect interface behavior prior to tape-out. This article presents a basic overview of OCP covering both the basic operation and configuration files. It then introduces a configurable OCP formal verification IP generator that automatically creates appropriate OCP properties for a specific to design implementation of the protocol. These concepts are used to demonstrate a silicon-tested method of developing a verification plan for OCP designs.

OCP Overview

OCP uses a simple master/slave configuration. All signals are synchronized on the rising-edge clock. It uses a very simple read/write command structure to pass information between components. It supports both blocking and non-blocking forms, along with basic pipelined operations. The specification is completely bus-independent, with device selection and arbitration performed outside the OCP logic. Figure 1 shows a basic OCP representation.

1. This implementation is a basic example of OCP.

Multiple read and write commands make up the basic command structure of the protocol. Read (non-blocking), ReadLinked (blocking), and ReadExclusive (blocking) are some of the more common read commands. The write command also contains several forms, including Write (non-blocking), WriteNonPost (blocking), WriteConditional (blocking), and Broadcast (linked multi-device). OCP signals are divided into three main groups: dataflow, sideband, and test. Basic operation requires only a small subset of the dataflow signals. The sideband and test signals are optional in this configuration.

Because of the many possible configurations for OCP, the specification requires the protocol interface to be defined within a text-based configuration file. This file identifies the design-specific parameters such as data command subsets and modes, data and address widths, burst sequence and alignment, data handshaking, and optional signals. The parameters can be explicitly declared in the file or loaded from default settings. Figure 2 shows a sample configuration file.

2. The OCP configuration file is reasonably straightforward.

Click here to read more ...