Introduction to and Regression Test for OCP SystemC Channel Models

In recent years the Electronic System Level (ESL) design methodology has been proposed to solve SoC design problems. SystemC, the main ESL hardware description language, is C++ based with hardware constructs such as modules, ports and clocks. SystemC allows users to model components and systems at higher abstraction levels than Verilog and VHDL. One key feature of SystemC is the Transaction Level Modeling (TLM) [3][4] that models components and systems at a level higher than the functional level in the sense that the data passing is modeled as transactions instead of signals. By raising the abstraction level we can perform: (1) algorithm/architecture codesign, (2) design space exploration, (3) system level verification, (4) hardware/software co-simulation, and (5) whole-system performance analysis and optimization [5][6].

The Open Core Protocol"International Partnership (OCP-IP) [7] Consortium has defined a high-performance and bus-independent interface protocol between IPs, usually referred to as the OCP Protocol, which provides a standard for a system designer such that the design time of the core interface can be greatly reduced and possible interface errors can be discovered at the early design stage. OCP defines a point-to-point socket interface specification that enables comprehensive and standardized definitions of a semiconductor IP core's on-chip interface. The IP cores can be a simple peripheral core, a high-performance microprocessor, or an on-chip communication system. Rather than defining rigid signal protocols that a core must implement, the OCP protocol provides a consistent framework for the identification of all kinds of on-chip data, test and control signals for IP cores.

Using OCP, IP designers can make their cores independent of some specific bus protocols, and hence the IP cores will be suitable for any particular design implementation. This makes it easier to reuse OCP-compliant cores across multiple SOC designs. Traditionally designers have to support different bus protocols by modifying a core's interface, the verification suite, the test bench, the documentation, and all other interface-related design issues of the core. OCP eliminates the need to repeatedly modify the core itself, and preserves the verification and test benches by defining all the core's natural interface capabilities in an unchanging, universally understood manner. As a result, significantly improved IP core reusability can be achieved, which leads directly to more predictable and productive SoC designs.

In the next two sections we shall describe the various abstraction levels for data communication (called layers) and the signals defined in OCP interface, respectively. In addition, as the channel models of OCP protocol are still under development, some changes on the protocol or the channel models are expected in the future releases. For the users of the OCP-IP SLD kit that has been provided by the OCP-IP System Level Design (SLD) Working Group to help design OCP-compatible interface, one critical feature of the kit is its stability, i.e., the properties that have been verified in previous release must be maintained in later releases. In order to do so, a regression test method has to be developed to help ensure the functionality that the many users of the OCP-IP SLD kit have come to rely upon is maintained release after release. We have developed a suite of test cases for this purpose, which will be detailed in Section 4.

Communication Abstraction Layers
Both communication and computation can be modelled at different abstraction levels according to the information they contain [8]. This section describes the modeling of communication in various layers of abstractions defined in the OCP Protocol [9].

Layer-3: Message Layer
Figure 1 shows a system modelled at the message layer. At this layer the model is un-timed and is operated in an event-driven way. The communication between two computational modules (one initiator and one target) is carried out through a channel, which involves the transfer of data that have a very abstract data type.
Due to its higher abstraction level than other layers, the system modelled in this layer is usually adopted for system concept proof, executable specification modeling, preliminary functional partition and high level trade-off.

1. A system with Layer-3 communication channels.

Layer-2: Transaction Layer
Figure 2 shows the system of layer-2, i.e., the transaction layer. At this layer, the model is timed, but not cycle-accurate. A module is employed to model the system-interconnect, such as a bus. The communication between computational modules is through this system-interconnect. However, the layer-2 models are independent of bus protocols since these protocols can only be implemented with cycle-accurate systems.

Layer-2 systems are usually adopted to describe the behavior of hardware architectures and to estimate the performance of these architectures. Frequently, HW/SW partition and co-development are implemented in layer-2 systems.

2. A system with Layer-2 communication channels.

Layer-1: Transfer Layer
The main concept of layer-1 systems is shown in Figure 3. Layer-1 systems are characterized by cycle-accurate behaviour as clock signals are provided in this layer. It means that layer-1 systems behave the same as the corresponding RTL systems every cycle, and hence at this layer a design must follow a specific cycle-accurate communication protocol. However, to model a system at layer-1 does not mean to write synthesizable codes of the system. A layer-1 system just provides a fully-cycle and protocol accurate models for fast-simulation that allows for the development of cycle accurate test benches.

3. A system with Layer-1 communication channels.

Layer-0: RTL Layer
Figure 4 shows the layer-0 communication system, which is at the commonly used RTL. It is not only cycle-accurate, but also pin/bit accurate when compared with other layers.

4. A system with Layer-0 communication channels.

Signals in OCP
OCP interface signals are grouped into dataflow signals, sideband signals, and test signals [10]. The OCP is a synchronous interface with a single clock signal. All OCP signals are driven with respect to and sampled by the rising edge of the clock signal.

A small set of the signals from the dataflow group is required in all OCP configurations, and optional signals can be configured to support additional core communication requirements, such as burst transaction and multi-threading supporting. The following will give an overview of the signals defined in OCP.

Dataflow Signals
The dataflow signals consist of a small set of required signals and a number of optional core signals that support additional requirements. The dataflow signals are grouped into basic signals, simple extensions (options such as byte enables), burst extension (support for bursting), tag extensions (re-ordering support), and thread extensions (multi-threading support).
Table 1 describes the basic signals. Other dataflow signals can be found in the specification document [7].

Sideband Signals
Sideband signals are OCP signals that do not belong to part of the data flow phases. Sideband signals convey control information such as reset, interrupt, error, and core-specific flags. They also exchange control and status information between a core and an attached system. All sideband signals are optional.

Test Signals
The test signals add support for scan, clock control, and IEEE 1149.1 (JTAG). Scanctrl, Scanin, and Scanout form a scan interface for a given IP core. The ClkByp and Test Clk signals together form the clock control interface. The TCK, TDI, TDO, TMS, and TRST_N signals form an IEEE 1149.1 debug and test interface. All test signals are also optional.