A Methodology for Verifying OCP Interfaces

OCP is an efficient point-to-point connection standard, widely used for wireless and multimedia applications. Developers can design their IP in a bus-independent manner, allowing immediate reusability of the IP for any application. Validation tasks must follow the same trend. Recently, there has been a growing demand for effective verification methodology. Object-oriented languages for reference are the only way to achieve quality products; nevertheless, IP validation might be time consuming and lack functional coverage if not supported by powerful and effective verification tools. This article focuses on the adoption of Specman Elite® from Verisity and the OCP eVC from YogiTech as a powerful verification methodology for any IP core using the OCP socket.

Introduction
Open Core Protocol is a configurable protocol set completely interface-independent and well suited for any hardware communication between two agents, both synchronous and asynchronous. OCP interfaces are highly configurable and can replace proprietary bus interfaces, allowing easy IP reuse and general abstract model adoption. It is possible to have one interface family that satisfies the needs of any peripheral or core. In other words, OCP represents one protocol for the whole system, and it ensures dramatic time reduction of functional verification and benchmarking for any future releases of the system. Such a universal interface creates a real need for a reference module and a strategy for verification at both the module and system level.

OCP flexibility and configurability are the real challenges for verification in such an interface. In fact these properties create the need for corresponding complexity in a reference model that might integrate any possible aspect or feature of the protocol. Object-oriented languages are a good solution for creating exhaustive models because many abstraction layers can be defined and implemented to operate at any level, from the general scenario description to the single transaction or signal behavior.

Problems can be divided into many simple pieces with relationships between them. So, it is intuitive to describe and organize all these pieces by type and then to define objects. Together with the object structure there is also its behavior, or, in other words, the whole set of relationships between itself, the rest of the system and other objects and the corresponding rules that need to be respected.

An OCP reference model can guarantee correct driving of or listening to signals in the system, but they are also bricks (object instances) for an upper layer that can be used to create high-level scenarios and for development of exhaustive tests. This is a key point for OCP-based systems; in fact, the goal of the protocol is not to "solve" interconnection problems when moving between module, subsystem and system levels. So, if it is possible to guarantee reusability of what has been done at module level in the next steps of the development, the verification effort is automatically drastically reduced.

In a general OCP-based application, the immediate result of such an approach can be a general (highly reusable) OCP verification platform that can be used for any OCP-based system.

Modeling and module verification platform
A great example of an object-oriented language for modeling, verification and interactive debugging is the e language for Specman Elite from Verisity. Models obtained using this language are called e Verification Components (eVC) and they can be seen as extensible atomic blocks for complex verification environment construction. Time and hardware-like concepts make this language particularly well suited for high quality modeling.

An eVC comprises both active and passive parts. The former generates and injects transactions or can respond to transaction requests following the OCP specifications, while the latter observes and logs traffic information to collect items for test functional coverage and also check protocol consistency.

The eVC is based on a very generic transaction structure definition, wherein fields can model any aspect or behavior of transactions on an OCP interface. By default, when this structure is generated, values of its fields are random; this structure is sent to the configurable Bus Functional Model (BFM) that will drive it across the OCP socket.

In the test program creation phase, designers can constrain fields to assume only specified values or range of values, in order to obtain a desired transaction or sequence of transactions. The eVC also reacts to any transaction on the interface, driving handshakes and responses to act as a slave module. All the transactions are monitored, stored into Specman for interactive viewing, and/or logged into a text file summarizing the traffic watched during the simulation and providing the most interesting details.

YogiTech's OCP eVC gives the user the ability to inject any kind of transaction, characterized by random or pseudo random parameters (e.g., request or response delays, latencies, addresses and data), and to organize them into sequences and nested sequences.




The final basic aspect is the support for sequence definition and the eRM compliancy that is the methodology for maximum reusability.

These are the main characteristics of the eVC, and they fit any kind of OCP interface. YogiTech's OCP eVC is even more than a model; important aspects for validation are self-checking procedures and functional coverage metrics.

The eVC includes simple and complex checking rules on OCP specifications and some metric definitions for functional coverage. An embedded protocol checker is a runtime extensible tool that applies defined OCP rules to the current bus traffic. If discrepancies are detected during simulation, the checker will prompt the user about the error, and provide a message about the violation and a link for the user to browse all available information for the current transaction.

Coverage is an important Specman Elite feature. OCP rules knowledge and expertise in verification methodologies are joined into functional concepts that summarize all the possible aspects of the protocol. Particular events in the simulation induce the eVC coverage unit to collect information on the conceptual items that are defined as coverage groups. These represent the functional coverage to be used for test program and sequence ranking or to help with new test creations. Information provided by the coverage suite is organized into functional items, making it evident if something has not been tested. In the system-like verification, coverage from each eVC provides a complete evaluation for all the interfaces so that the user may extend test programs to cover what was not tested.

Past experience shows that time requirements for medium complexity module verifications are around two man weeks when a reusable environment is available (eVC, test sequences and documentation), versus five to six man weeks when starting from scratch and with lower functional coverage.

System verification
System-level verification is a very important task. With OCP-based systems the validation is much easier because a model is already available with many tests and the environment already complete.



Interaction between OCP interfaces can be easily described as system-level routines using OCP eVC objects (transactions) that are already well known. All these routines must be very general and independent from the system under test in order to also achieve high reusability. Test sequences may also be created for the system-level view, but module-level sequences can be reused to check system reaction to that particular qualifying test. The most pleasing result of the methodology described is its simplicity and the inherent significant reduction of verification time needed for all future releases of the design.

Gap reduction when moving from module-level to system-level simulation is an additional benefit relative to the limited performance of traditional approaches. Flexible and complete models (such as the YogiTech's OCP eVC) described using a HDL fully compatible language (e) produce very interesting scenarios around the module, in the sense that they are very similar to system behavior. So, when a module has been verified in a system-like way, unexpected faults cannot emerge later during the real system-level verification.

For more information about YogiTech, visit www.yogitech.com.