OCP IP OpenCoreProtocolSpecification 1.0

Open Core ProtocolSpecification

Release 1.0

��

© 2001 OCP-IP Association, All Rights Reserved.

Open Core Protocol ReferenceDocument Revision 002

This document, including all software described in it, is furnished under the terms of the Open Core Protocol Specification License Agreement (the "License") and may only be used or copied in accordance with the terms of the License. The information in this document is a work in progress, jointly developed by the members of OCP-IP Association ("OCP-IP") and is furnished for informational use only.

The technology disclosed herein may be protected by one or more patents, copyrights, trademarks and/or trade secrets owned by or licensed to OCP-IP. OCP-IP reserves all rights with respect to such technology and related materials. Any use of the protected technology and related material beyond the terms of the License without the prior written consent of OCP-IP is prohibited.

This document contains material that is confidential to OCP-IP and its members and licensors. The user should assume that all materials contained and/or referenced in this document are confidential and proprietary unless otherwise indicated or apparent from the nature of such materials (for example, references to publicly available forms or documents). Disclosure or use of this document or any material contained herein, other than as expressly permitted, is prohibited without the prior written consent of OCP-IP or such other party that may grant permission to use its proprietary material.

The trademarks, logos, and service marks displayed in this document are the registered and unregistered trademarks of OCP-IP, its members and its licensors. The following trademarks of Sonics, Inc. have been licensed to OCP-IP: FastForward, SonicsIA, CoreCreator, SiliconBackplane, SiliconBackplane Agent, MultiChip Backplane, InitiatorAgent Module, TargetAgent Module, ServiceAgent Module, SOCCreator, and Open Core Protocol.

The copyright and trademarks owned by OCP-IP, whether registered or unregistered, may not be used in connection with any product or service that is not owned, approved or distributed by OCP-IP, and may not be used in any manner that is likely to cause customer confusion or that disparages OCP-IP. Nothing contained in this document should be construed as granting by implication, estoppel, or otherwise, any license or right to use any copyright without the express written consent of OCP-IP, its licensors or a third party owner of any such trademark.

Printed in the United States of America.

Part number: 161-000125-0001

EXCEPT AS OTHERWISE EXPRESSLY PROVIDED, THE OPEN CORE PROTOCOL (OCP) SPECIFICATION IS PROVIDED BY OCP-IP TO MEMBERS "AS IS" WITHOUT WARRANTY OF ANY KIND, EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS.

OCP-IP SHALL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL OR CONSEQUENTIAL DAMAGES OF ANY KIND OR NATURE WHATSOEVER (INCLUDING, WITHOUT LIMITATION, ANY DAMAGES ARISING FROM LOSS OF USE OR LOST BUSINESS, REVENUE, PROFITS, DATA OR GOODWILL) ARISING IN CONNECTION WITH ANY INFRINGEMENT CLAIMS BY THIRD PARTIES OR THE SPECIFICATION, WHETHER IN AN ACTION IN CONTRACT, TORT, STRICT LIABILITY, NEGLIGENCE, OR ANY OTHER THEORY, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Contents

1 Overview 1

OCP Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Part I Specification 5

2 Theory of Operation 7

3 Signals and Encoding 11

Dataflow Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Basic Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Simple Extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Complex Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Sideband Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Reset, Interrupt, Error, and Core-specific Flag Signals. . . . . . . . . . 17

Control and Status Signals . . . . . . . . . . . . . . . . . . . . . . . 18

Test Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Scan Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Clock Control Interface . . . . . . . . . . . . . . . . . . . . . . . . . 20

Debug and Test Interface . . . . . . . . . . . . . . . . . . . . . . . . 20

Signal Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Signal Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Protocol Semantics 25

Signal Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Combinational Dependencies . . . . . . . . . . . . . . . . . . . . . . . 26

Signal Timing and Protocol Phases . . . . . . . . . . . . . . . . . . . . 27

Dataflow Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Sideband and Test Signals . . . . . . . . . . . . . . . . . . . . . . . 29

Transfer Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Burst Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Packing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Burst Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Threads and Connections . . . . . . . . . . . . . . . . . . . . . . . . . 34

OCP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

viii Open Core Protocol Specification

Signal Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Protocol Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Minimum Implementation . . . . . . . . . . . . . . . . . . . . . . . . 36

OCP Interface Compatibility . . . . . . . . . . . . . . . . . . . . . . . 36

5 Timing Diagrams 41

Simple Write and Read Transfer . . . . . . . . . . . . . . . . . . . . . . 42

Request Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Request Handshake and Separate Response . . . . . . . . . . . . . . . 44

Pipelined Request and Response . . . . . . . . . . . . . . . . . . . . . 45

Non-Pipelined Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Burst Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Response Accept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Datahandshake Extension . . . . . . . . . . . . . . . . . . . . . . . . 50

Threaded Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6 Timing Specification 55

Timing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Minimum Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Hold-time Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Physical Design Parameters . . . . . . . . . . . . . . . . . . . . . . . 57

Connecting Two OCP Cores . . . . . . . . . . . . . . . . . . . . . . . 58

7 Core Performance 61

Report Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Sample Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Performance Report Template . . . . . . . . . . . . . . . . . . . . . . . 66

8 Behavioral Models 69

Q-Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Configuration Settings. . . . . . . . . . . . . . . . . . . . . . . . . . 70

Q-Slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Configuration Settings. . . . . . . . . . . . . . . . . . . . . . . . . . 72

OCP Merger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Configuration Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 80

Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Contents ix

OCP Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

OCP Monitor Task Interface . . . . . . . . . . . . . . . . . . . . . . . 82

9 Socket Transaction Language 85

Basic Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Macro Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Behavioral Statements . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Part II File Formats 95

10 Core RTL Configuration File 97

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Sample RTL Configuration File . . . . . . . . . . . . . . . . . . . . . 103

11 Testbench RTL Configuration File 107

Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Chip Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Syntax Specification . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Sample Chip RTL Configuration File . . . . . . . . . . . . . . . . . . 112

12 Interface Configuration File 115

13 Chip Synthesis Configuration File 119

Configuration File Sections . . . . . . . . . . . . . . . . . . . . . . . 120

Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Technology Section . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Chip Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Instance Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Technology Variable Syntax . . . . . . . . . . . . . . . . . . . . . . 134

Chip Section Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Instance Section Syntax . . . . . . . . . . . . . . . . . . . . . . . . 137

Sample Chip Synthesis Configuration File . . . . . . . . . . . . . . . . 138

14 Core Synthesis Configuration File 141

Configuration File Sections . . . . . . . . . . . . . . . . . . . . . . . 142

Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 142

x Open Core Protocol Specification

Version Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Clock Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Area Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Port Constraints Section. . . . . . . . . . . . . . . . . . . . . . . . 145

Max Delay Constraints . . . . . . . . . . . . . . . . . . . . . . . . 150

False Path Constraints . . . . . . . . . . . . . . . . . . . . . . . . 151

Sample Core Synthesis Configuration File . . . . . . . . . . . . . . . 151

15 Package File 153

Part III Guidelines 155

16 Developer’s Guidelines 157

Signal Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Multi-threaded OCP Implementation . . . . . . . . . . . . . . . . . 161

Slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Master. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

State Machine Examples . . . . . . . . . . . . . . . . . . . . . . . . 163

Simple OCP Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 168

Complex OCP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 168

Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Sideband Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Debug and Test Interface . . . . . . . . . . . . . . . . . . . . . . . . 171

Scan Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Clock Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

17 Timing Guidelines 173

Level0 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Level1 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Level2 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Index 177

Introduction

The Open Core Protocol™ (OCP™) delivers the first openly licensed, core-centric protocol that comprehensively describes the system-level integration requirements of intellectual property (IP) cores.

While other bus and component interfaces address only the data flow aspects of core communications, the OCP unifies all inter-core communications, including sideband control and test harness signals. The OCP's synchronous unidirectional signaling produces simplified core implementation, integra-tion, and timing analysis.

OCP eliminates the task of repeatedly defining, verifying, documenting and supporting proprietary interface protocols. The OCP readily adapts to support new core capabilities while limiting test suite modifications for core upgrades.

Clearly delineated design boundaries enable cores to be designed indepen-dently of other system cores yielding definitive, reusable IP cores with reusable verification and test suites.

Any on-chip interconnect can be interfaced to the OCP rendering it appro-priate for many forms of on-chip communications:

• Dedicated peer-to-peer communications, as in many pipelined signal processing applications such as MPEG2 decoding.

• Simple slave-only applications such as slow peripheral interfaces.

• High-performance, latency-sensitive, multi-threaded applications, such as multi-bank DRAM architectures.

The OCP supports very high performance data transfer models ranging from simple request-grants through pipelined and multi-threaded objects. Higher complexity SOC communication models are supported using thread identi-fiers to manage out-of-order completion of multiple concurrent transfer sequences.

xii Open Core Protocol Specification

The OCP-IP CoreCreator™ tool automates the tasks of building, simulating, verifying and packaging OCP-compatible cores. IP core products can be fully "componentized" by consolidating core models, timing parameters, synthesis scripts, verification suites and test vectors in accordance with the OCP specification.

Library OverviewThe Open Core Protocol Specification provides technical details for working with the Open Core Protocol™ Interface. It is the hardware companion to the CoreCreator Guide. This document also includes information on the Socket Transaction Language (STL), behavioral models, and chip file formats.

The CoreCreator Guide is for design engineers preparing cores with CoreCreator™. The document is a reference for using the GUI and the command line interface tools. It is the tools companion to the Open Core Protocol Specification.

The CoreCreator Tutorials step through the CoreCreator tools flow, from core creation through core packaging.

1 Overview

The Open Core Protocol™ (OCP) defines a high-performance, bus-indepen-dent interface between IP cores that reduces design time, design risk, and manufacturing costs for SOC designs.

An IP core can be a simple peripheral core, a high-performance micropro-cessor, or an on-chip communication subsystem such as a wrapped on-chip bus. The Open Core Protocol:

• Achieves the goal of IP design reuse. The OCP transforms IP cores making them independent of the architecture and design of the systems in which they are used

• Optimizes die area by configuring into the OCP only those features needed by the communicating cores

• Simplifies system verification and testing by providing a firm boundary around each IP core that can be observed, controlled, and validated

The approach adopted by the Virtual Socket Interface Alliance’s (VSIA) Design Working Group on On-Chip Buses (DWGOCB) is to specify a “bus wrapper” to provide a bus-independent Transaction Protocol-level interface to IP cores.

The OCP is equivalent to VSIA’s proposed Virtual Component Interface (VCI). While the VCI addresses only data flow aspects of core communications, the OCP is a superset of VCI that also supports configurable sideband control signaling and test harness signals. Only the OCP defines protocols to unify all of the inter-core communication.

2 Open Core Protocol Specification

OCP CharacteristicsThe OCP defines a point-to-point interface between two communicating enti-ties such as IP cores and bus interface modules (bus wrappers). One entity acts as the master of the OCP instance, and the other as the slave. Only the master can present commands and is the controlling entity. The slave responds to commands presented to it, either by accepting data from the master, or presenting data to the master. For two entities to communicate in a peer-to-peer fashion, there need to be two instances of the OCP connecting them - one where the first entity is a master, and one where the first entity is a slave.

Figure 1 shows a simple system containing a wrapped bus and three IP core entities: one that is a system target, one that is a system initiator, and an entity that is both.

Figure 1 System Showing Wrapped Bus and OCP Instances

The characteristics of the IP core determine whether the core needs master, slave, or both sides of the OCP; the wrapper interface modules must act as the complementary side of the OCP for each connected entity. A transfer across this system occurs as follows. A system initiator (as the OCP master) presents command, control, and possibly data to its connected slave (a bus wrapper interface module). The interface module plays the request across the on-chip bus system. The OCP does not specify the embedded bus function-ality. Instead, the interface designer converts the OCP request into an embedded bus transfer. The receiving bus wrapper interface module (as the OCP master) converts the embedded bus operation into a legal OCP command. The system target (OCP slave) receives the command and takes the requested action.

Each instance of the OCP is configured (by choosing signals or bit widths of a particular signal) based on the requirements of the connected entities and is independent of the others. For instance, system initiators may require more

Core Core Core

On-Chip Bus

Master Master

MasterSlave Slave Master

Slave Slave

OCP RequestResponse

System Initiator/Target System TargetSystem Initiator

Bus Initiator Bus Initiator/Target Bus Target

Bus wrapperinterfacemodule

{

Overview 3

address bits in their OCP instances than do the system targets; the extra address bits might be used by the embedded bus to select which bus target is addressed by the system initiator.

The OCP is flexible. There are several useful models for how existing IP cores communicate with one another. Some employ pipelining to improve band-width and latency characteristics. Others use multiple-cycle access models, where signals are held static for several clock cycles to simplify timing anal-ysis and reduce implementation area. Support for this wide range of behavior is possible through the use of synchronous handshaking signals that allow both the master and slave to control when signals are allowed to change.

ComplianceFor a core to be considered OCP compliant, it must satisfy the following conditions:

1. Each OCP interface on the core must:

• Contain at least the basic OCP signals described in “Basic Signals” on page 12.

• Comply with the protocol semantics for the OCP defined in Chapter 4 that are required to support the minimum command and response set defined in “Minimum Implementation” on page 36.

• Specify the timing of each signal using the terminology defined in Chapter 6 on page 55.

2. The core and its interfaces must be described using the syntax defined in Chapter 10 on page 97.

• The interfaces must have their timing defined as described in Chapter 6 on page 55.

• Any non-OCP interfaces must be further described using the interface configuration file described in Chapter 12 on page 115.

3. The core’s performance must be described as defined in Chapter 7 on page 61.

Part I Specification

2 Theory of Operation

The Open Core Protocol interface addresses communications between the functional units (or IP cores) that comprise a system on a chip. The OCP provides independence from bus protocols without having to sacrifice high-performance access to on-chip interconnects. By designing to the interface boundary defined by the OCP, you can develop reusable IP cores without regard for the ultimate target system.

Given the wide range of IP core functionality, performance and interface requirements, a fixed definition interface protocol cannot address the full spectrum of requirements. The need to support verification and test require-ments increases the complexity of the interface. To address this spectrum of interface definitions, the OCP defines a highly configurable interface. The OCP’s structured methodology includes all of the signals required to describe an IP cores’ communications including data flow, control, and verification and test signals.

This chapter provides an overview of the concepts behind the Open Core Protocol, introduces the terminology used to describe the interface and offers a high-level view of the protocol.


Point-to-Point Synchronous InterfaceTo simplify timing analysis, physical design, and general comprehension, the OCP is composed of uni-directional signals driven with respect to, and sampled by the rising edge of the OCP clock. The OCP is fully synchronous and contains no multi-cycle timing paths. All signals other than the clock and reset are strictly point-to-point.

Bus IndependenceA core utilizing the OCP can be interfaced to any bus. A test of any bus-inde-pendent interface is to connect a master to a slave without an intervening on-chip bus. This test not only drives the specification towards a fully symmetric interface but helps to clarify other issues. For instance, device selection tech-niques vary greatly among on-chip buses. Some use address decoders. Others generate independent device select signals (analogous to a board level chip select). This complexity should be hidden from IP cores, especially since in the directly-connected case there is no decode/selection logic. OCP-compliant slaves receive device selection information integrated into the basic command field.

Arbitration schemes vary widely. Since there is virtually no arbitration in the directly-connected case, arbitration for any shared resource is the sole responsibility of the logic on the bus side of the OCP. This permits OCP-compliant masters to pass a command field across the OCP that the bus inter-face logic converts into an arbitration request sequence.

CommandsThere are two basic commands, Read and Write and two command exten-sions. The Broadcast command has the same protocol semantics as Write; the difference is that the master indicates that it is attempting to write to several or all remote target devices that are connected on the other side of the slave. As such, Broadcast is typically useful only for slaves that are in turn a master on another communication medium (such as an attached bus).

The second command extension, Read Exclusive (ReadEx), has protocol semantics that are similar to Read, but guarantees sufficient resource locking to support atomic read-modify-write or swap semantics. On receiving a ReadEx command, the slave attempts to acquire exclusive access to the addressed resource. Once the slave returns data from that address, the master can assume that it has obtained exclusive access and issue a Write command. The Write command notifies the slave to update the address (which must match the ReadEx address), and then to release exclusive access to the memory location.

Theory of Operation 9

Address/DataWide widths, characteristic of shared on-chip address and data buses, make tuning the OCP address and data widths essential for area-efficient imple-mentation. Only those address bits that are significant to the IP core should cross the OCP to the slave. The OCP address space is flat and composed of 8-bit bytes (octets).

To increase transfer efficiencies, many IP cores have data field widths signifi-cantly greater than an octet. The OCP directly supports up to 128-bit data fields, allowing it to transfer 16 bytes simultaneously. The OCP refers to the chosen data field width as the word size of the OCP. The term word is used in the traditional computer system context; that is, a word is the natural transfer unit of the block. OCP masters or slaves with natural word sizes, that are not directly supported, are zero-extended to the next power-of-two boundary. For instance, a 12-bit DSP core would typically employ a 16-bit OCP and provide zeros on the upper nibble.

Transfers of less than a full word of data are supported by providing byte enable information that specifies which octets are to be transferred. Assem-bling octets into larger aggregates follows the rule that the aggregate is addressed at the OCP word-aligned address of the lowest octet in the aggre-gate. The lowest octet in the aggregate is also the least significant octet in the aggregate making the OCP little-endian.

PipeliningThe OCP allows pipelining of transfers. To support this feature, the return of read data and the provision of write data may be delayed after the presenta-tion of the associated request.

ResponseThe OCP separates requests from responses. A slave can accept a command request from a master on one cycle and respond in a later cycle. The division of request from response permits pipelining. The OCP provides the option of having responses for Write commands, or completing them immediately without a response (posted write model).

BurstTo provide high transfer efficiency, burst support is essential for many IP cores. The extended OCP supports annotation of transfers with burst infor-mation but requires that appropriately sequenced addresses accompany each successive command in the burst. This simplifies the requirements for address sequencing/burst count processing in the slave.

Threads and ConnectionsTo support concurrency and out-of-order processing of transfers, the extended OCP supports the notion of multiple threads. Transactions within different threads have no ordering requirements, and so can be processed out of order. Within a single thread of data flow, all OCP transfers must remain ordered.


While the notion of a thread is a local concept between a master and a slave communicating over an OCP, it is possible to globally pass information from initiator to target using connection identifiers. Connection information helps to identify the initiator and determine priorities at the target.

Interrupts, Errors, and other Sideband SignalingWhile moving data between devices is a central requirement of on-chip communication systems, other types of communications are also important. Different types of control signaling are required to coordinate data transfers (for instance, high-level flow control) or signal system events (such as inter-rupts). Dedicated point-to-point data communication is sometimes required. Many devices also require the ability to notify the system of errors that may be unrelated to address/data transfers.

The OCP refers to all such communication as sideband (or out-of-band) signaling, since it is not directly related to the protocol state machines of the dataflow portion of the OCP. The OCP provides support for such signals through sideband signaling extensions.

Errors are reported across the OCP using two mechanisms. The error response code in the response field describes errors resulting from OCP trans-fers that provide responses. Posted write-type commands do not generate a response and cannot use the in-band reporting mechanism. The second method for reporting errors across the OCP is an out-of band error field. This signal reports more generic sideband errors, including those associated with posted write commands.

3 Signals and Encoding

OCP interface signals are grouped into dataflow, sideband, and test signals. A small set of the signals from the dataflow group called the basic OCP, is required in all OCP configurations. Optional signals can be configured to support additional core communication requirements. The optional dataflow signals are divided into simple and complex extensions. All sideband and test signals are optional.

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 OCP clock. Except for clock and reset, OCP signals are strictly point-to-point and uni-directional. The complete set of OCP signals is shown in Figure 2 on page 24.


Dataflow SignalsThe dataflow signals consist of a small set of required signals called the basic OCP and optional signals that can be configured to support additional core communication requirements. The optional dataflow signals are grouped into simple and complex extensions.

The naming conventions for dataflow signals use the prefix M for signals driven by the OCP master and S for signals driven by the OCP slave.

Basic SignalsTable 1 lists the basic OCP signals that must be present in any OCP interface.

Table 1 Basic OCP Signals

ClkClock signal for the OCP. All interface signals are synchronous to the rising edge of Clk.

MAddrThe Transfer address, MAddr specifies the slave-dependent address of the resource targeted by the current transfer. To configure this field, use the addr_wdth parameter.

MAddr is a byte address that must be aligned to the OCP word size (data_wdth). If the OCP word size is larger than a single byte, the aggregate is addressed at the OCP word-aligned address of the lowest byte in the OCP word, and the lowest order address bits are hardwired to 0.

MCmdTransfer command. This signal indicates the type of transfer at the OCP. Commands are encoded as follows.

Name Width Driver Function

Clk 1 varies OCP clock

MAddr 1−32 master Transfer address

MCmd 3 master Transfer command

MData 8/16/32/64/128 master Write data

SCmdAccept 1 slave Slave accepts transfer

SData 8/16/32/64/128 slave Read data

SResp 2 slave Transfer response

Signals and Encoding 13

Table 2 Command Encoding

The set of allowable commands can be limited using the readex_enable and broadcast_enable parameters as described in “Protocol Options” on page 35.

MDataWrite data. This field carries data from the master to the slave. The data width is configured using the data_wdth parameter. If the OCP word size is larger than a single byte, the lowest addressed byte is also the least significant in the aggregate. Together with the previously described addressing rule, this makes the OCP little-endian.

SCmdAcceptSlave accepts transfer. A value of 1 on the SCmdAccept signal indicates that the slave accepts the master’s transfer request.

SDataRead data. This field carries data from the slave to the master. The field width is configured using the data_wdth parameter. If the OCP word size is larger than a single byte, the lowest addressed byte is also the least significant in the aggregate.

SRespResponse field from the slave to a transfer request from the master. Response encoding is as follows.

Table 3 Response Encoding

MCmd[2:0] Transaction Type Mnemonic

0 0 0 Idle IDLE

0 0 1 Write WR

0 1 0 Read RD

0 1 1 ReadEx RDEX

1 0 0 Reserved

1 0 1 Reserved

1 1 0 Reserved

1 1 1 Broadcast BCST

SResp[1:0] Response Mnemonic

0 0 No response NULL

0 1 Data valid / accept DVA

1 0 Reserved

1 1 Response error ERR


Simple ExtensionsTable 4 lists the simple OCP extensions. The extensions add address spaces, byte enables, burst support, datahandshake, and response flow control.

Table 4 Simple OCP Extensions

MAddrSpaceAddress Space. This field is an extension of the MAddr field and is used to indicate the address region of a transfer. Examples of address regions are the register space versus the regular memory space of a target core or the user versus supervisor space for an initiator core.

The MAddrSpace field is configured into the OCP using the addrspace parameter. The width of the MAddrSpace field is configured using the addrspace_wdth parameter. While the encoding of the MAddrSpace field is core-specific, it is recommended that target cores use 0 to indicate the internal register space.

MBurstBurst type. This signal allows linking related transfers into a burst transaction. It is configured into the OCP using the burst parameter. It encodes both the burst type and the burst code, as shown in Table 5.

Table 5 Burst Encoding


MAddrSpace 1-8 master Address space

MBurst 3 master Burst code

MByteEn 1/2/4/8/16 master Byte enables

MDataValid 1 master Write data valid

MRespAccept 1 master Master accepts response

SDataAccept 1 slave Slave accepts write data

MBurst[2:0] Burst Type Burst Code

0 0 0 All LAST

0 1 0 Incrementing TWO

1 0 0 Incrementing FOUR

1 1 0 Incrementing EIGHT

0 0 1 Custom (packed) DFLT1

0 1 1 Custom (not packed) DFLT2

1 0 1 Streaming STRM

1 1 1 Incrementing CONT


MByteEnByte enables. This field indicates which bytes within the OCP word are part of the current transfer. There is one bit in MByteEn for each byte in the OCP word. Setting MByteEn[n] to 1 indicates that the byte associated with data wires [(8n + 7):8n] should be transferred. The MByteEn field is configured into the OCP using the byteen parameter.

The allowable patterns on MByteEn can be limited using the force_aligned parameter as described on page 35.

MDataValidWrite data valid. When set to 1, this bit indicates that the data on the MData field is valid. Use the datahandshake parameter to configure this field into the OCP.

MRespAcceptMaster response accept. The master indicates that it accepts the current response from the slave with a value of 1 on the MRespAccept signal. Use the respaccept parameter to enable this field into the OCP.

SDataAcceptSlave accepts write data. The slave indicates that it accepts pipelined write data from the master with a value of 1 on SDataAccept. Use the datahandshake parameter to configure this field into the OCP.

Complex ExtensionsTable 6 shows a list of complex OCP extensions. The extensions add support for threads and connections.

Table 6 Complex OCP Signal Extensions

MConnIDConnection identifier. This variable-width field provides the binary encoded connection identifier associated with the current transfer request.

To configure this field use the connid parameter. The field width is configured with the connid_wdth parameter.


MConnID 1-8 master Connection identifier

MDataThreadID 1-4 master Write data thread identifier

MThreadBusy 1-16 master Master thread busy

MThreadID 1-4 master Request thread identifier

SThreadBusy 1-16 slave Slave thread busy

SThreadID 1-4 slave Response thread identifier


MDataThreadIDWrite data thread identifier. This variable-width field provides the thread identifier associated with the current write data. The field carries the binary-encoded value of the thread identifier.

MDataThreadID is required if threads is greater than 1 and the datahandshake parameter is included. MDataThreadID has the same width as MThreadID and SThreadID.

MThreadBusyMaster thread busy. The master notifies the slave that it cannot accept any responses associated with certain threads. The MThreadBusy field is a vector (one bit per thread). A value of 1 on any given bit indicates that the thread associated with that bit is busy. Bit 0 corresponds to thread 0, and so on. The width of the field is set using the threads parameter. It is legal to enable a one-bit MThreadBusy interface for a single-threaded OCP. To configure this field, use the mthreadbusy parameter.

MThreadIDRequest thread identifier. This variable-width field provides the thread identifier associated with the current transfer request. If threads is greater than 1, this field is enabled. The field width is the next whole integer of log2(threads).

SThreadIDResponse thread identifier. This variable-width field provides the thread identifier associated with the current transfer response. If threads is greater than 1, this field is enabled. The field width is the next whole integer of log2(threads).

SThreadBusySlave thread busy. The slave notifies the master that it cannot accept any new requests associated with certain threads. The SThreadBusy field is a vector, one bit per thread. A value of 1 on any given bit indicates that the thread associated with that bit is busy. Bit 0 corresponds to thread 0, and so on. The width of the field is set using the threads parameter. It is legal to enable a one-bit SThreadBusy interface for a single-threaded OCP. To configure this field, use the sthreadbusy parameter.


Sideband SignalsSideband signals are OCP signals that are not part of the dataflow phases, and so can change asynchronously with the request/response flow. 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.

Table 7 shows a list of the sideband extensions to the OCP.

Table 7 Sideband OCP Signals

Reset, Interrupt, Error, and Core-specific Flag SignalsMFlag

Master flags. This variable-width set of signals allows the master to communicate out-of-band information to the slave. Encoding is completely core-specific.

To configure this field into the OCP, use the mflag parameter. To configure the width of this field, use the mflag_wdth parameter.

Reset_nSynchronous reset. A system device asserts Reset_n to reset the master and slave portions of the OCP interface. The Reset_n signal is active low, as shown in Table 8. The Reset_n field is enabled by the reset parameter.

Table 8 Reset Signal


MFlag 1-8 master Master flags

Reset_n 1 varies Synchronous reset

SError 1 slave Slave error

SFlag 1-8 slave Slave flags

SInterrupt 1 slave Slave interrupt

Control 1−16 system Core control information

ControlBusy 1 core Hold control information

ControlWr 1 system Control information has been written

Status 1−16 core Core status information

StatusBusy 1 core Status information is not consistent

StatusRd 1 system Status information has been read

Reset_n Function

0 Reset Active

1 Reset Disabled


SErrorSlave error. With a value of 1 on the SError signal the slave indicates an error condition to the master. The SError field is configured with the serror parameter.

SFlagSlave flags. This variable-width set of signals allows the slave to communicate out-of-band information to the master. Encoding is completely core-specific.

To configure this field into the OCP, use the sflag parameter. To configure the width of this field, use the sflag_wdth parameter.

SInterruptSlave interrupt. The slave may generate an interrupt with a value of 1 on the SInterrupt signal. The SInterrupt field is configured with the interrupt parameter.

Control and Status SignalsThe remaining sideband signals are designed for the exchange of control and status information between an IP core and the rest of the system. They make sense only in this environment, regardless of whether the IP core acts as a master or slave across the OCP interface.

ControlCore control information. This variable-width field allows the system to drive control information into the IP core. Encoding is core-specific.

Use the control parameter to configure this field into the OCP. Use the control_wdth parameter to configure the width of this field.

ControlBusyCore control busy. When this signal is set to 1, the core tells the system to hold the control field value constant. Use the controlbusy parameter to configure this field into the OCP.

ControlWrCore control event. This signal is set to 1 by the system to indicate that control information is written by the system. Use the controlwr parameter to configure this field into the OCP.

StatusCore status information. This variable-width field allows the IP core to report status information to the system. Encoding is core-specific.

Use the status parameter to configure this field into the OCP. Use the status_wdth parameter to configure the width of this field.

StatusBusyCore status busy. When this signal is set to 1, the core tells the system to disregard the status field because it may be inconsistent. Use the statusbusy parameter to configure this field into the OCP.


StatusRdCore status event. This signal is set to 1 by the system to indicate that status information is read by the system. To configure this field into the OCP, use the statusrd parameter.

Test SignalsThe test signals add support for scan, clock control, and IEEE 1149.1 (JTAG). All test signals are optional.

Table 9 Test OCP Signals

Scan InterfaceThe Scanctrl, Scanin, and Scanout signals together form a scan interface into a given IP core.

ScanctrlScan mode control signals. Use this variable width field to control the scan mode of the core. A scanport_wdth >0 configures this field into the OCP interface. Use the scancrtl_wdth parameter to configure the width of this field.

ScaninScan data in for a core’s scan chains. Use the scanport_wdth parameter, to configure this field into the OCP interface and control its width.

ScanoutScan data out from the core’s scan chains. Use the scanport_wdth parameter to configure this field into the OCP interface and control its width.


Scanctrl 1-256 system Scan control signals

Scanin 0-256 system Scan data in

Scanout 0-256 core Scan data out

ClkByp 1 system Enable clock bypass mode

TestClk 1 system Test clock

TCK 1 system Test clock

TDI 1 system Test data in

TDO 1 core Test data out

TMS 1 system Test mode select

TRST_N 1 system Test reset


Clock Control InterfaceThe ClkByp and TestClk signals together form the clock control interface into a given IP core. This interface is used to control the core’s clocks during scan operation.

ClkBypEnable clock bypass signal. When set to 1, this signal instructs the core to bypass the external clock source and use TestClk instead. Use the clkctrl_enable parameter to configure this signal into the OCP interface.

TestClkA gated test clock. This clock becomes the source clock when ClkByp is asserted during scan operations. Use the clkctrl_enable parameter to configure this signal into the OCP interface.

Debug and Test InterfaceThe TCK, TDI, TDO, TMS, and TRST_N signals together form an IEEE 1149 debug and test interface for the OCP.

TCKTest clock as defined by IEEE 1149.1. Use the jtag_enable parameter to add this signal to the OCP interface.

TDITest data in as defined by IEEE 1149.1. Use the jtag_enable parameter to add this signal to the OCP interface.

TDOTest data out as defined by IEEE 1149.1. Use the jtag_enable parameter to add this signal to the OCP interface.

TMSTest mode select as defined by IEEE 1149.1. Use the jtag_enable parameter to add this signal to the OCP interface.

TRST_NTest logic reset signal. This is an asynchronous active low reset as defined by IEEE 1149.1. Use the jtagtrst_enable parameter to add this signal to the OCP interface.


Signal ConfigurationThe set of signals making up the OCP interface is configurable to match the characteristics of the IP core. Throughout this chapter, configuration param-eters were mentioned that control the existence and width of various OCP fields. Table 10 on page 21 summarizes the configuration parameters, sorted by interface signal group.

Table 10 OCP Signal Configuration Parameters

Group SignalParameter to add signal to interface

Parameter tocontrol width

Basic Clk Required Fixed

MAddr Required addr_wdth

MCmd Required Fixed

MData Required data_wdth

SCmdAccept Required Fixed

SData Required data_wdth

SResp Required Fixed

Simple MBurst burst Fixed

MAddrSpace addrspace addrspace_wdth

MByteEn1 byteen data_wdth

MDataValid2 datahandshake Fixed

MRespAccept respaccept Fixed

SDataAccept datahandshake Fixed

Complex MConnID connid connid_wdth

MDataThreadID3 threads>1 and datahandshake

threads

MThreadBusy4 mthreadbusy threads

MThreadID5 threads>1 threads

SThreadBusy6 sthreadbusy threads

SThreadID5 threads>1 threads

Sideband Control control control_wdth

ControlBusy7 controlbusy Fixed

ControlWr8 controlwr Fixed

MFlag mflag mflag_wdth

Reset_n reset Fixed

SError serror Fixed


SFlag sflag sflag_wdth

SInterrupt interrupt Fixed

Status status status_wdth

StatusBusy9 statusbusy Fixed

StatusRd10 statusrd Fixed

Test ClkByp clkctrl_enable Fixed

Scanctrl scanport_wdth >0 scanctrl_wdth

Scanin scanport_wdth >0 scanport_wdth

Scanout scanport_wdth >0 scanport_wdth

TCK jtag_enable Fixed

TDI jtag_enable Fixed

TDO jtag_enable Fixed

TestClk clkctrl_enable Fixed

TMS jtag_enable Fixed

TRST_N jtagtrst_enable Fixed

1 MByteen has a width of data_wdth/8.

2 MDataValid and SDataAccept are both configured by the same parameter (datahandshake); either both exist or neither.

3 MDataThreadID is included if threads is greater than 1 and the datahandshake parameter is set.

4 MThreadBusy has a width equal to threads. It may be included for single-threaded OCP interfaces.

5 MThreadID and SThreadID are both configured by the same parameter (threads); either both exist or neither.

6 SThreadBusy has a width equal to threads. It may be included for single-threaded OCP interfaces.

7 ControlBusy can only be included if both Control and ControlWr exist.

8 ControlWr can only be included if Control exists.

9 StatusBusy can only be included if Status exists.

10 StatusRd can only be included if Status exists.

Group SignalParameter to add signal to interface

Parameter tocontrol width


Signal DirectionsFigure 2 on page 24 summarizes all OCP signals. The direction of some signals (for example, MCmd) depends on whether the module acts as a master or slave, while the direction of other signals (for example, Control) depends on whether the module acts as a system or a core. The combination of these two choices gives a possibility of six different module configurations as shown in Table 11.

Table 11 Module Configuration Based on Signal Directions

For example, if a module acts as OCP master and also as system, it is desig-nated a system master.

There are two special signals, Clk and Reset_n, that are typically either supplied by the system module (if one of the two modules acts as a system), or alternatively can be supplied by a third (external) entity that is neither of the two modules connected through the OCP interface.

No System Signals Acts as System Acts as Core

Acts as OCP Master Master System Master Core Master

Acts as OCP Slave Slave System Slave Core Slave


Figure 2 OCP Signal Summary

ClkSlaveMaster

MCmd

MAddr

MBurst

SResp

SData

SCmdAccept

Request

MThreadID

MConnID

MByteEn

SThreadID

MRespAccept

Response

Reset_n

SInterrupt

SError

SFlag

MFlag

Control

ControlWr

ControlBusy

Status

StatusRd

StatusBusy

Sideband

ScanctrlScanin

Scanout

TestClk

ClkByp

TCK

TDI

TDO

TMS

TRST_N

Test

Data Handshake

MDataValid

MData

MDataThreadID

SDataAccept

Required

Optional

System Core

DataFlow

MThreadBusy

SThreadBusy

MAddrSpace

4 Protocol Semantics

This chapter defines the semantics of the OCP protocol by assigning meanings to the signal encodings described in the preceding chapter. Figure 3 provides a graphic view of the hierarchy of elements that compose the OCP.

Figure 3 Hierarchy of Elements

Signal

Group

Phase Phase Phase...

Transfer

Transaction

Timing information

Transfer Transfer...

Signal Signal...


Signal GroupsSome OCP fields are grouped together because they must be active at the same time. The data flow signals are divided into three signal groups: request signals, response signals, and datahandshake signals. A list of the signals that belong to each group is shown in Table 12.

Table 12 OCP Signal Groups

*MData belongs to the request group, unless the datahandshake configuration parameter is enabled. In that case it belongs to the datahandshake group.

Combinational DependenciesIt is legal for some signal or signal group outputs to be derived from inputs without an intervening latch point, that is combinationally. To avoid combi-national loops, other outputs cannot be derived in this manner. Figure 4 describes a partial order of combinational dependency. For any arrow shown, the signal or signal group that is pointed to can be derived combinationally from the signal at the point of origin of the arrow or another signal earlier in the dependency chain. No other combinational dependencies are allowed.

Group Signal Condition

Request MAddr always

MAddrSpace always

MBurst always

MByteEn always

MCmd always

MConnID always

MData* datahandshake = 0

MThreadID always

Response SData always

SResp always

SThreadID always

Datahandshake MData* datahandshake = 1

MDataValid always

MDataThreadID always

Protocol Semantics 27

Figure 4 Legal Combinational Dependencies Between Signals and Signal Groups

Combinational paths are not allowed within the sideband and test signals, or between those signals and the data flow signals. The only legal combinational dependencies are within the data flow signals. Data flow signals, however, may be combinationally derived from Reset_n.

For timing purposes, some of the allowed combinational paths are designated as preferred paths and are described in “Allowed Combinational Paths for Level2 Timing” on page 175.

Signal Timing and Protocol PhasesThis section specifies when a signal can or must be valid.

Dataflow SignalsSignals in a signal group must all be valid at the same time.

• The request group is valid whenever a command other than Idle is presented on the MCmd field.

• The response group is valid whenever a response other than Null is presented on the SResp field.

• The datahandshake group is valid whenever a 1 is presented on the MDataValid field.

The accept signal associated with a signal group is valid only when that group is valid.

• The SCmdAccept signal is valid whenever a command other than Idle is presented on the MCmd field.

• The MRespAccept signal is valid whenever a response other than Null is presented on the SResp field.

• The SDataAccept signal is valid whenever a 1 is presented on the MDataValid field.

Request group

SCmdAcceptResponse group

MRespAccept

Datahandshake

SDataAccept

MThreadBusy

SThreadBusy

Master

Slave

group


The signal groups map on a one-to-one basis to protocol phases. All signals in the group must be held steady from the beginning of a protocol phase until the end of that phase. Outside of a protocol phase, all signals in the corre-sponding group (except for the signal that defines the beginning of the phase) are “don’t care”. In addition, the MData field is a "don't care" during read-type requests, and the SData field is a "don't care" for responses to write-type requests.

• A request phase begins whenever the request group becomes active. It ends when the SCmdAccept signal is sampled by Clk as 1 during a request phase.

• A response phase begins whenever the response group becomes active. It ends when the MRespAccept signal is sampled by Clk as 1 during a response phase.

If MRespAccept is not configured into the OCP interface (respaccept = 0) then MRespAccept is assumed to be on; that is the response phase is exactly one cycle long.

• A datahandshake phase begins whenever the datahandshake signal group becomes active. It ends when the SDataAccept signal is sampled by Clk as 1 during a datahandshake phase.

For all phases, it is legal to assert the corresponding accept signal in the cycle that the phase begins, allowing the phase to complete in a single cycle.

Phases in a TransferAn OCP transfer consists of several phases as shown in Table 13. Every transfer has a request phase. Depending on the type of transfer and the OCP configuration, the datahandshake or response phase is optional.

Table 13 OCP Phases in an OCP Transfer

Phase Ordering Within a TransferThe OCP is causal: within each transfer a request phase must precede the associated datahandshake phase which in turn, must precede the associated response phase. The specific constraints are:

• A datahandshake phase cannot begin before the associated request phase begins, but can begin in the same Clk cycle.

• A datahandshake phase cannot end before the associated request phase ends, but can end in the same Clk cycle.

MCmd Phases Condition

Read, ReadEx Request, response always

Write, Broadcast Request datahandshake = 0

Write, Broadcast Request, datahandshake datahandshake = 1


• A response phase cannot begin before the associated request phase begins, but can begin in the same Clk cycle.

• A response phase cannot end before the associated request phase ends, but can end in the same Clk cycle.

Phase Ordering Between TransfersThe ordering of transfers is determined by the ordering of their request phases.

• Since two phases of the same type belonging to different transfers both use the same signal wires, the phase of a subsequent transfer cannot begin before the phase of the previous transfer has ended. If the first phase ends in cycle x, the second phase can begin in cycle x + 1.

• The ordering of datahandshake phases must follow the order set by the request phases.

• The ordering of response phases must follow the order set by the request phases.

• Where no phase ordering is specified, the effect of two transfers that are addressing the same location must be the same as if the two transfers were executed in the same order but without any phase overlap. This ensures that read/write hazards yield predictable results.

Ungrouped SignalsSignals not covered in the description of signal groups and phases are MThreadBusy and SThreadBusy. The timing cycle of the transition of each bit that makes up each of these two fields is not specified relative to the other dataflow signals. This means that there is no specific time for an OCP master or slave to drive these signals, nor a specific time for the signals to have the desired flow-control effect. It follows that MThreadBusy and SThreadBusy can only be treated as a hint.

To prevent blocking of multi-threaded OCP interfaces, the sender of a Thread-Busy signal needs to produce the signal in the cycle after the last accepted request or response phase. The receiver must take the signal into account for the thread selection of the current cycle. For a further description, see Figure 22 on page 162.

Sideband and Test Signals

ResetA system device asserts Reset_n to reset the master and slave portions of the OCP interface. Once Reset_n is sampled asserted by the rising edge of Clk, both master and slave must transition to a state where there are no pending OCP requests or responses.


Reset_n must be asserted for at least 16 cycles of Clk to ensure that the master and slave reach a consistent internal state. The master and slave must each be able to reach their reset state regardless of the values presented on the OCP signals. If the master or slave require more than 16 cycles of Reset_n assertion, the requirement must be documented in the IP core specifications.

At the same clock edge that Reset_n is sampled deasserted, all OCP interface signals must be valid. In particular, it is legal for the master to begin its first request phase in the same clock cycle that Reset_n is deasserted.

Interrupt, Error, and Core FlagsThere is no specific timing associated with SInterrupt, SError, MFlag and SFlag. The timing of these signals is core-specific.

Status and ControlThe following rules assure that control and status information can be exchanged across the OCP without any combinational paths from inputs to outputs and at the pace of a slow core.

• Control must be held steady for a full cycle after the cycle in which it has transitioned, which means it cannot transition more frequently than every other cycle. If ControlBusy was sampled active at the end of the previous cycle, Control must not transition in the current cycle. In addition, Control must be held steady the first cycle after reset is deasserted.

• If Control transitions in a cycle, ControlWr (if present) must be driven active for that cycle. ControlWr following the rules for Control, cannot be asserted in two consecutive cycles.

• ControlBusy allows a core to force the system to hold Control steady. ControlBusy may only start to be asserted immediately after reset, or in the cycle after ControlWr is asserted, but can be left asserted for any number of cycles.

• While StatusBusy is active, Status is a “don’t care”. StatusBusy enables a core to prevent the system from reading the current status information. While StatusBusy is active the core may not read Status. StatusBusy can be asserted at any time and be left asserted for any number of cycles.

• StatusRd is active for a single cycle every time the status register is read by the system. If StatusRd was asserted in the previous cycle, it must not be asserted in the current cycle, so it cannot transition more frequently than every other cycle.

Test SignalsScanin and Scanout are “don’t care” while Scanctrl is inactive (but the encoding of inactive for Scanctrl is core-specific).

TestClk is “don’t care” while ClkByp is 0.

The timing of TRST_N, TCK, TMS, TDI, and TDO is specified in the IEEE 1149 standard.


Transfer EffectsA successful transfer is one that completes without error. For write-type requests (Write and Broadcast command), there is no response and therefore no in-band error indication. For read-type requests (Read and ReadEx commands), a DVA response indicates a successful transfer. This section defines the effect that a successful transfer has on a slave. The request acts on the location addressed by the value passed over the MAddr and MAddrSpace fields (if present) during the request phase. The transfer effects of each command type are:

IdleNone.

ReadReturns the latest value of the addressed location on the SData field.

ReadExReturns the latest value of the addressed location on the SData field. Sets a lock for the initiating thread on at least that location. The next request on the thread that issued a ReadEx must be a Write to the same address (and with the same byte enables, if applicable). Competing requests of any type from other threads to a locked location are blocked from proceeding until the lock is unset. If the ReadEx request returns an ERR response, it is target-specific whether the lock is actually set or not.

WritePlaces the value on the MData field in the addressed location. Unlocks access to the location if locked by a ReadEx.

BroadcastPlaces the value on the MData field in the addressed location that may map to more than one target in a system-dependent way.

If a transfer is unsuccessful, the effect of the transfer is unspecified. It is up to higher-level protocols to determine what happened and handle any clean-up.

Burst DefinitionA burst is a set of transfers that are linked together into a transaction by applying a burst code to each transfer. The burst code specifies the type of burst and can also specify some information about the number of transfers left in the burst. Each individual transfer in the burst has complete request information. The burst code itself is only a hint to improve system perfor-mance and can be ignored by the slave.

OCP burst codes are described in Table 14. MBurst field burst codes are spec-ified in Table 5 on page 14. The OCP protocol places few restrictions on the values in the burst field because the information is only advisory. The main requirement is that a burst of one type must be completed (by issuing at least one command with the burst code LAST) before a burst of another type can begin. Single (non-burst) transfers always use a burst code of LAST.


Table 14 Burst Codes

PackingThe concept of packing must be defined before discussing burst types. When a transfer is issued across an OCP, there are two related concepts, OCP data width (or OCP word size) and natural transfer size. The natural transfer size is the size of the data units being transferred, and is not necessarily the same as the OCP word size. For example, it is possible to simultaneously transfer two, two-byte data units over a four-byte wide OCP. Packing refers to the aggregation of multiple data units of the natural transfer size into a single OCP transfer.

Packing allows the system to make use of the burst attributes to improve the overall data transfer efficiency in the face of multiple OCP interfaces of different data widths. For example, if a bridge is translating a narrow OCP to a wide OCP, it can aggregate (or pack) the incoming narrow transfers into a smaller number of outgoing wide transfers.

Burst types support either maximal packing, or no packing. Maximal packing means that as many natural transfer units as are available and as can fit into the OCP data word must be aggregated each time. No packing means that only one natural transfer unit is passed across the OCP at a time, even if the OCP word size is larger than the natural transfer size of the data.

Burst TypesOf the different burst types, two are very specific and two are left largely unspecified for core-specific customization:

• Incrementing bursts

• Streaming bursts

• Custom burst patterns that can be packed

• Custom burst patterns that cannot be packed

Table 15 summarizes the attributes of the burst types. All transfers in a given burst must use the same MCmd, MAddrSpace, MThreadID, and MConnID.

Name Type Transfers Remaining

LAST (any) 1 (end burst)

TWO incrementing at least 2 (burst length known)

FOUR incrementing at least 4 (burst length known)

EIGHT incrementing at least 8 (burst length known)

CONT incrementing at least 2 (burst length unknown)

STRM streaming at least 2

DFLT1 custom (packed) at least 2

DFLT2 custom (not packed) at least 2


Table 15 Burst Types*

* All transfers in a given burst must use the same MCmd, MAddrSpace, MThreadID, and MConnID for all burst types.

Incrementing BurstsIncrementing bursts are read or write bursts that are characterized by an address that increases by the data width of the OCP on every transfer; that is, the word-aligned address increments by the word size. A typical use for an incrementing burst is a DMA transfer from DRAM. For incrementing bursts the burst codes give a hint of how many total transfers remain (including the current one). Since not all transfer lengths are supported, the master rounds down to the nearest power of two. If the burst length is not known by the master (as in PCI bursts, for example), the burst code CONT (continue) is used.

Incrementing bursts are governed by the following rules:

• The address of every transfer in the burst is incremented by the OCP data width. Bursts must not wrap around the OCP address size.

• Within a given burst, incrementing burst codes (that is, TWO, FOUR, EIGHT, and CONT) can be freely intermixed. This makes it legal to issue a read with a burst code of EIGHT and then immediately follow that with another read (with an appropriately-incremented address) that specifies a burst code LAST to end the burst.

• Incrementing bursts have no byte enable restrictions; each transfer in the burst can have any byte enable pattern.

• Incrementing bursts must be maximally packed. This means that if the natural transfer width of the burst is smaller than the OCP word size, the transfers are packed together to match the OCP word size. The packed burst of narrow transfers must be indistinguishable from a burst with a natural transfer width that matches the OCP word size. This satisfies the requirement that addresses in incrementing bursts always increase by the OCP word size.

Attribute Incrementing Burst Streaming BurstCustom Burst packed

Custom Burst unpacked

Command read or write read or write not specified not specified

Addresssequence

incremented by OCP data width on every transfer

same on every transfer

not specified not specified

Burst codes any combination of TWO, FOUR, EIGHT, CONT

STRM DFLT1 DFLT2

Byte enables no restrictions fixed pattern, no holes in pattern

no restrictions not specified

Packing maximally packed cannot be packed maximally packed

cannot be packed


Streaming BurstsStreaming bursts are characterized by the same address for all transfers within the burst. They are used to support clients such as networking and communications cores where the address identifies the port – the transfers tend to be data-only. Examples include modem, Ethernet, and A/D converters.

A streaming burst can be either a read or a write burst. The address must remain constant during a streaming burst transaction. Burst code STRM is used for every transfer except the last.

The byte enables representing the natural data width for a given transfer in the streaming burst must all be enabled. This means that the byte enable pattern is the same for every transfer in the transaction, and that there are no holes in the byte enable pattern. A streaming burst cannot be packed and cannot be wider than the OCP word size, so if a streaming burst with a natural transfer width of two bytes is sent over a 32-bit wide OCP, not all OCP byte enables are enabled.

Custom BurstsCustom burst types apply to bursts with different command, address sequence, or byte enable attributes than the pre-defined incrementing and streaming burst types. The difference between the two custom burst types is that one is packed and the other is not. Packing allows for efficient transfer of bursts over OCPs of varying width. To allow packing, the address behavior of a burst is restricted according to the maximally packed guidelines described in “Incrementing Bursts” on page 33. As a result, the address sequencing behavior for transfers smaller than the OCP word size must be incrementing. A typical use of packed custom bursts is to support behavior such as critical-word-first cache line refill.

The burst type is thread and connection specific. By using multiple threads or connections, a slave can support many different burst styles, such as different cache line sizes for different processors.

Threads and ConnectionsAll transfers within a single thread must remain ordered. (See “Phase Ordering Between Transfers” on page 29.)

Using multiple threads, it is possible to support concurrent activity, and out-of-order completion of transfers. All transfers within a given thread must remain strictly ordered, but there are no ordering rules for transfers that are in different threads. Mapping of individual requests and responses to threads is handled through the MThreadID and SThreadID fields respectively. If datahandshake has been enabled when thread ID has been enabled, there must also be an MDataThreadID field to annotate the datahandshake phase.

The use of thread IDs allows two entities that are communicating over an OCP interface to assign transfers to particular threads. If one of the communi-cating entities is itself a bridge to another OCP interface, the information


about which transfers are part of which thread must be maintained by the bridge, but the actual assignment of thread IDs is done on a per-OCP-inter-face basis. There is no way for a slave on the far side of a bridge to extract the original thread ID unless the slave design comprehends the characteristics of the bridge.

Use connections whenever information about a request must be sent end-to-end from master to slave. Any bridges in the path between the end-to-end partners preserve the connection ID, even as thread IDs are re-assigned on each OCP interface in the path. The MConnID field transfers the connection ID during the request phase. Since this establishes the mapping onto a thread ID, the other phases do not require a connection ID but are unambiguous with only a thread ID.

The SThreadBusy and MThreadBusy signals are used to indicate that a partic-ular thread is busy. If another request (or response) is issued on a busy thread, it is unlikely that the request (or response) will be accepted. These signals provide hints that allow the master or slave to avoid having the inter-face blocked until the thread becomes non-busy. For more information, see “Ungrouped Signals” on page 29.

OCP Configuration

Signal OptionsThe configuration parameters described in “Signal Configuration” on page 21, not only configure the corresponding signal into the OCP interface, but also enable the function. For example, if the burst parameter is enabled the MBurst field is added and the interface also supports burst extensions as described in “Burst Definition” on page 31.

Protocol OptionsNot all devices support all allowable byte enable patterns. The force_aligned parameter limits byte enable patterns on the OCP to be power-of-two in size and aligned to that size.

• A master with this option set must not generate any byte enable patterns that are not force aligned.

• A slave with this option set cannot handle any byte enable patterns that are not force aligned.

Not all devices support the optional commands ReadEx and Broadcast. The readex_enable and broadcast_enable parameters indicate whether an optional command is supported.

• A master with one of these options not set must not generate the corresponding command.

• A slave with one of these options not set cannot handle the corresponding command.


The burst_aligned parameter provides information about the size and align-ment of bursts issued by an attached master core and can be used to optimize the system. Setting burst_aligned requires all incrementing bursts to:

• Have exactly a power of two transfers, even if error responses are received.

• Use only burst codes EIGHT, FOUR, TWO, and LAST in the appropriate sequence. For example, a burst of size 8 has the following sequence of burst codes: EIGHT, FOUR, FOUR, FOUR, FOUR, TWO, TWO, LAST.

• Have all byte enables turned on in every transfer (or to use an OCP without byte enables).

• Have their starting address aligned with their total burst size.

• Bursts of sizes larger than 8 are allowed, however, the target cannot immediately tell the burst size, since OCP burst codes top out at EIGHT.

Minimum ImplementationA minimal OCP implementation must support at least the basic OCP dataflow signals.

OCP-compatible masters and slaves must support the command types Idle, Read, and Write. Support for ReadEx, and Broadcast is optional.

OCP-compatible masters and slaves must support response types NULL and DVA. The ERR response type is optional and should only be included if the OCP-compatible slave has the ability to report errors. All OCP masters must be able to accept the ERR response.

OCP Interface CompatibilityTwo units being connected together each have their own OCP configuration. The two interfaces are only compatible (allowing the two units to be connected together and communicate using the OCP protocol semantics) if they are compatible at the module, protocol, and signal levels.

1. At the module level, one interface must act as master and the other as slave. If system signals are present, one interface must act as core and the other as system. Finally, only one of them can drive Clk and Reset_n, or they must both receive these signals from a third entity.

2. At the protocol level, the interfaces are compatible if:

• The slave has readex_enable if the master has readex_enable.

• The slave has broadcast_enable if the master has broadcast_enable.

• The master has force_aligned if the slave has force_aligned.

• The master has burst_aligned if the slave has burst_aligned.


3. At the signal level, two interfaces are compatible if the tie-off rules, described in the next section are observed for any mismatch at the signal level. Unless otherwise specified, all tied-off inputs are tied to logical zero.

Signal Mismatch Tie-off RulesMCmd

Always matches in width.

MAddrIf the master is wider than the slave, extra address bits are lost. If the master is narrower than the slave, missing address bits are generated by tying the slave inputs to zero.

Only transfer addresses that fall within the smaller of the two address space sizes can be used.

MAddrSpaceIf the master includes the field but the slave does not or the master field is wider than the slave field, the additional master output bits are lost.

If the master does not include the field but the slave does or if the master field is narrower than the slave field, the additional slave input bits are tied to zero. In this case, only the lower- numbered address spaces can be accessed by the master.

MDataMust be configured to match.

SCmdAcceptAlways matches.

SRespAlways matches.

SDataMust be configured to match.

MBurstIf the master includes the field but the slave does not, bits are lost. If the master does not include the field but the slave does, slave input bits are tied to represent burst code LAST. In either case no meaningful burst information can be transferred.

MByteEnMust match in width (follows from data width matching).

MDataValidMust be configured to match.

MRespAcceptIf the master includes the field but the slave does not, the bit is lost. If the master does not include the field but the slave does, the slave input is tied to one. In either case, no response flow control exists on the OCP interface and the master must be able to immediately accept all responses presented by the slave.


SDataAcceptMust be configured to match (follows from MDataValid).

MConnIDIf the master includes the field but the slave does not (or if the master is wider than the slave), bits are lost. If the master does not include the field but the slave does (or the master is narrower than the slave), any missing slave input bits are tied to zero. Only the smaller set of connection IDs can be used.

MThreadIDIf the master includes the field but the slave does not (or the master is wider than the slave), bits are lost. If the master does not include the field but the slave does (or the master is narrower than the slave), any missing slave input bits are tied to zero. Only the smaller set of thread IDs can be used.

MDataThreadIDSame as MThreadID.

MThreadBusyIf the master includes the field but the slave does not (or the master is wider than the slave), bits are lost. If the master does not include the field but the slave does (or the master is narrower than the slave), missing slave input bits are tied to zero. No useful information can be passed on the non-matching signals, so on the corresponding threads the interface may become blocked.

SThreadIDSame as MThreadID, except that the master and slave are reversed.

SThreadBusySame as MThreadBusy, except that the master and slave are reversed.

Reset_nNeed not match. If master or slave does not include Reset_n, it must present a valid OCP encoding on all its OCP outputs at all times.

SInterruptIf the master enables the field but the slave does not, the master input is tied to zero. If the master does not enable the field but the slave does, the bit is lost. In either case no interrupt can be communicated over the OCP.

SErrorIf the master includes the field but the slave does not, the master input is tied to zero. If the master does not include the field but the slave does, the bit is lost. In either case no out-of-band error can be communicated from slave to master over the OCP.

SFlagIf the master includes the field but the slave does not (or the master is wider than the slave), the missing master input bits are tied to zero. If the master does not include the field but the slave does (or the master is narrower than the slave) any extra bits are lost. In either case no information can be passed on the non-matching flag signals.


MFlagSame as SFlag, except that master and slave are reversed.

The remaining sideband signals and all the test signals must be configured to match exactly.

Width MismatchFor signals that allow a connection with a width mismatch and that use a binary encoding (MAddr, MAddrSpace, MConnID, MThreadID, MDataTh-readID, SThreadID), it is always the most significant bits that are lost. This is also the case for the MThreadBusy and SThreadBusy signals.

For the SFlag and MFlag signals any arbitrary bits can be dropped and these must be specified explicitly.

5 Timing Diagrams

The timing diagrams within this chapter look at signals at strategic points and are not intended to provide full explanations but rather, highlight specific areas of interest. The diagrams are provided solely as examples. For related information about phases, see “Signal Timing and Protocol Phases” on page 27.

Most fields are unspecified whenever their corresponding phase is not asserted. This is indicated by the striped pattern in the waveforms. For example, when MCmd is IDLE the request phase is not asserted, so the values of MAddr, MData, and SCmdAccept are unspecified.

Subscripts on labels in the timing diagrams denote transfer numbers that can be helpful in tracking a transfer across protocol phases.

For a description of timing diagram mnemonics, see Tables 2 and 3 on page 13.


Simple Write and Read TransferFigure 5 illustrates a simple write and read transfer on a basic OCP interface. This diagram shows typical behavior for a synchronous SRAM or for the control and status registers of a core.

Figure 5 Simple Write and Read Transfer

SequenceA. The master starts a request phase on clock 1 by switching the MCmd field

from IDLE to WR. At the same time, it presents a valid address (A1) on MAddr and valid data (D1) on MData. The slave asserts SCmdAccept in the same cycle, making this a 0-latency transfer.

B. The slave captures the values from MAddr and MData and uses them internally to perform the write. Since SCmdAccept is asserted, the request phase ends.

C. The master starts a read request by driving RD on MCmd. At the same time, it presents a valid address on MAddr. The slave asserts SCmdAccept in the same cycle for a request accept latency of 0.

D. The slave captures the value from MAddr and uses it internally to determine what data to present. The slave starts the response phase by switching SResp from NULL to DVA. The slave also drives the selected data on SData. Since SCmdAccept is asserted, the request phase ends.

E. The master recognizes that SResp indicates data valid and captures the read data from SData, completing the response phase. This transfer has a request-to-response latency of 1.

Clk

MAddr

MCmd

MData

SCmdAccept

SResp

SData

IDLE

A1

WR1

D1

NULL

A2

RD2

DVA2

D2

IDLEIDLE

NULL

2 3 4 5 6 71

Req

uest

Pha

seR

espo

nse

Pha

se

A B C D E

Timing Diagrams 43

Request HandshakeFigure 6 illustrates the basic flow-control mechanism for the request phase using SCmdAccept. There are three write transfers, each with a different request accept latency.

Figure 6 Request Handshake

SequenceA. The master starts a write request by driving WR on MCmd and valid address

and data on MAddr and MData, respectively. The slave asserts SCmdAccept in the same cycle, for a request accept latency of 0.

B. The master starts a new transfer in the next cycle. The slave captures the write address and data. It deasserts SCmdAccept, indicating that it is not yet ready for a new request.

C. Recognizing that SCmdAccept is not asserted, the master holds all request phase signals (MCmd, MAddr, and MData). The slave asserts SCmdAccept in the next cycle, for a request accept latency of 1.

D. The slave captures the write address and data.

E. After 1 idle cycle, the master starts a new write request. The slave deasserts SCmdAccept.

F. Since SCmdAccept is asserted, the request phase ends. SCmdAccept was low for 2 cycles, so the request accept latency for this transfer is 2. The slave captures the write address and data.

Clk

MAddr

MCmd

MData

SCmdAccept

SResp

SData

IDLE

NULL

A1

WR1

D1

IDLEWR2

A2

D2

A3

IDLEWR3

D3

NULL

2 3 4 5 6 71 8

A B C D E F

Req

uest

Pha

seR

espo

nse

Pha

se


Request Handshake and Separate ResponseFigure 7 illustrates a single read transfer in which a slave introduces delays in the request and response phases. The request accept latency 2, corre-sponds to the number of clock cycles that SCmdAccept was deasserted. The request to response latency 3, corresponds to the number of clock cycles from the end of the request phase (D) to the end of the response phase (F).

Figure 7 Request Handshake and Separate Response

SequenceA. The master starts a request phase by issuing the RD command on the

MCmd field. At the same time, it presents a valid address on MAddr. The slave is not ready to accept the command yet, so it deasserts SCmdAccept.

B. The master sees that SCmdAccept is not asserted, so it keeps all request phase signals steady. The slave may be using this information for a long decode operation, and it expects the master to hold everything steady until it asserts SCmdAccept.

C. The slave asserts SCmdAccept. The master continues to hold the request phase signals.

D. Since SCmdAccept is asserted, the request phase ends. The slave captures the address, and although the request phase is complete, it is not ready to provide the response, so it continues to drive NULL on the SResp field. For example, the slave may be waiting for data to come back from an off-chip memory device.

E. The slave is ready to present the response, so it issues DVA on the SResp field, and drives the read data on SData.

F. The master sees the DVA response and captures the read data.

Clk

MAddr

MCmd

MData

SCmdAccept

SResp

SData

IDLE

A1

RD1

NULLDVA1NULL

D1

IDLE

Req

uest

Pha

seR

espo

nse

Pha

se

A B C D E

2 3 4 5 6 71

F

Timing Diagrams 45

Pipelined Request and ResponseFigure 8 shows three read transfers using pipelined request and response semantics. In each case, the request is accepted immediately, while the response is returned in the same or a later cycle.

Figure 8 Pipelined Request and Response

SequenceA. The master starts the first read request, driving RD on MCmd and a valid

address on MAddr. The slave asserts SCmdAccept, for a request accept latency of 0. When the slave sees the read command, it responds with DVA on SResp and valid data on SData. This requires a combinational path in the slave from MCmd, and possibly other request phase fields, to SResp, and possibly other response phase fields.

B. Since SCmdAccept is asserted, the request phase ends. The master sees that SResp is DVA and captures the read data from SData. Because the request was accepted and the response was presented in the same cycle, the request-to-response latency is 0.

C. The master launches a read request, and the slave asserts SCmdAccept.

D. The master sees that SCmdAccept is asserted, so it can launch a third read even though the response to the previous read has not been received. The slave captures the address of the second read and begins driving DVA on SResp and the read data on SData.

E. Since SCmdAccept is asserted, the third request ends. The master sees that the slave has produced a valid response to the second read and captures the data from SData. The request-to-response latency for this transfer is 1.

Clk

MAddr

MCmd

MData

SCmdAccept

SResp

SData

IDLE

NULL

A1

RD1 IDLE

NULL

A3

RD3

DVA3 NULL

D3

IDLE

DVA1

D1

A2

RD2

DVA2

D2

NULL

2 3 4 5 6 71

Req

uest

Pha

seR

espo

nse

Pha

se

A B C D E F G


F. The slave has the data for the third read, so it drives DVA on SResp and the data on SData.

G. The master captures the data for the third read from SData. The request-to-response latency for this transfer is 2.

Non-Pipelined ReadFigure 9 shows three read transfers to a slave that cannot pipeline responses after requests. This is the typical behavior of legacy computer bus protocols with a single WAIT or ACK signal. In each transfer, SCmdAccept is asserted in the same cycle that SResp is DVA. Therefore, the request-to-response latency is always 0, but the request accept latency varies from 0 to 2.

Figure 9 Non-Pipelined Read


address on MAddr. The slave asserts SCmdAccept, for a request accept latency of 0. When the slave sees the read command, it responds with DVA on SResp and valid data on SData. (This requires a combinational path in the slave from MCmd, and possibly other request phase fields, to SResp, and possibly other response phase fields.)

B. The master launches another read request. It also sees that SResp is DVA and captures the read data from SData. The slave is not ready to respond to the new request, so it deasserts SCmdAccept.

Clk

MAddr

MCmd

MData

SCmdAccept

SResp

SData

IDLE

NULL

A1

RD1 IDLERD2

A2 A3

IDLERD3

DVA1 NULL NULLDVA2 DVA3NULL

D1 D2 D3

Req

uest

Pha

seR

espo

nse

Pha

se

2 3 4 5 6 71 8

A B C D E F G

Timing Diagrams 47

C. The master sees that SCmdAccept is low and extends the request phase. The slave is now ready to respond in the next cycle, so it simultaneously asserts SCmdAccept and drives DVA on SResp and the selected data on SData. The request accept latency is 1.

D. Since SCmdAccept is asserted, the phase ends. The master sees that SResp is now DVA and captures the data.

E. The master launches a third read request. The slave deasserts SCmdAccept.

F. The slave asserts SCmdAccept after 2 cycles, so the request accept latency is 2. It also drives DVA on SResp and the read data on SData.

G. The master sees that SCmdAccept is asserted, ending the phase. It also sees that SResp is now DVA and captures the data.

Burst ReadFigure 10 illustrates a burst read transaction that is composed of four pipe-lined burst read transfers. An additional field, MBurst, is added to the request phase, indicating the type of the burst and the number of transfers that the master expects. In this diagram, MData and SData are assumed to be 32 bits.

Figure 10 Burst Read

Clk

MAddr

MCmd

MData

SCmdAccept

SResp

SData

IDLE

0x01

RD1 RD2

0x83 0xC4

RD4

DVA4 NULL

D4

IDLE

DVA1

D1

0x42

RD3

DVA2

D2 D3

DVA3

MBurst FOUR1 TWO3 LAST4TWO2

NULL

A B C D E F G

Req

uest

Pha

seR

espo

nse

Pha

se

2 3 4 5 6 71


SequenceA. The master starts the burst read by driving RD on MCmd, the first address

of the burst on MAddr, and the burst code FOUR on MBurst. The burst code indicates that this is an incrementing burst and that four or more transfers are expected. The slave is ready for anything, so it asserts SCmdAccept.

B. The master issues the next read in the burst. MAddr is set to the next word-aligned address. For 32-bit words, the address is incremented by 4. The master also changes MBurst to TWO, meaning that two or more transfers remain in the transaction.

C. The master issues the next read in the burst, incrementing MAddr and leaving MBurst set to TWO, because there are still two or more transfers remaining. The slave is now ready to respond to the first read in the burst, so it drives DVA on SResp and valid data on SData. The request-to-response latency for this transfer is 2.

D. The master issues the final read in the burst, incrementing MAddr and setting MBurst to LAST. The master also captures the data for the first read from the slave. The slave responds to the second transfer. The request-to-response latency for this transfer is 2, although it is possible for the slave to introduce more latency for each response in a burst transaction. (In OCP, bursts do not impose any additional constraints on protocol timing.)

E. The master captures the data for the second read from the slave. The slave responds to the third transfer.

F. The master captures the data for the third read from the slave. The slave responds to the fourth and last transfer.

G. The master captures the data for the last read from the slave.

Response AcceptFigure 11 shows examples of the response accept extension used with two read transfers. An additional field, MRespAccept, is added to the response phase. This signal may be used by the master to flow-control the response phase.

Timing Diagrams 49

Figure 11 Response Accept

SequenceA. The master starts a read request by driving RD on MCmd and a valid

address on MAddr. The slave asserts SCmdAccept immediately, and it drives DVA on SResp as soon as it sees the read request. The master is not ready to receive the response for the request it just issued, so it deasserts MRespAccept.

B. Since SCmdAccept is asserted, the request phase ends. The master continues to deassert MRespAccept, however. The slave holds SResp and SData steady.

C. The master starts a second read request. It is finally ready for the response from its first request, so it asserts MRespAccept. This corresponds to a response accept latency of 2.

D. Since SCmdAccept is asserted, the request phase ends. The master captures the data for the first read from the slave. Since MRespAccept is asserted, the response phase ends. The slave is not ready to respond to the second read, so it drives NULL on SResp.

E. The slave responds to the second read by driving DVA on SResp and the read data on SData. The master is not ready for the response, however, so it deasserts MRespAccept.

F. The master asserts MRespAccept, for a request accept latency of 1.

G. The master captures the data for the second read from the slave. Since MRespAccept is asserted, the response phase ends.

Clk

MAddr

MCmd

MData

SCmdAccept

SResp

SData

IDLE

NULL

A1

RD1 IDLE

NULL

IDLE

A2

RD2

MRespAccept

D1

DVA1 DVA2

D2

Req

uest

Pha

seR

espo

nse

Pha

se2 3 4 5 6 71

A B C D E F G

NULL


Datahandshake ExtensionFigure 12 shows three write transfers using the datahandshake extension. This extension adds the datahandshake phase which is completely indepen-dent of the request and response phases. Two new signals, MDataValid and SDataAccept, are added, and MData is moved from the request phase to the datahandshake phase.

Figure 12 Datahandshake Extension

SequenceA. The master starts a write request by driving WR on MCmd and a valid

address on MAddr. It does not yet have the write data, however, so it deasserts MDataValid. The slave asserts SCmdAccept. It does not need to assert or deassert SDataAccept yet, because MDataValid is still deasserted.

B. The slave captures the write address from the master. The master is now ready to transfer the write data, so it asserts MDataValid and drives the data on MData, starting the datahandshake phase. The slave is ready to accept the data immediately, so it asserts SDataAccept. This corresponds to a data accept latency of 0.

C. The master deasserts MDataValid since it has no more data to transfer,. (Like MCmd and SResp, MDataValid must always be in a valid, specified state.) The slave captures the write data from MData, completing the transfer. The master starts a second write request by driving WR on MCmd and a valid address on MAddr.

Clk

MAddr

MCmd

MData

SCmdAccept

IDLE

A1

WR1 IDLE

A3

WR3 IDLE

D2

A2

SDataAccept

MDataValid

WR2

D1 D3

Req

uest

Pha

se

2 3 4 5 6 71

A B C D E F G

Dat

aH

ands

hake

Pha

se

Timing Diagrams 51

D. Since SCmdAccept is asserted, the master immediately starts a third write request. It also asserts MDataValid and presents the write data of the second write on MData. The slave is not ready for the data yet, so it deasserts SDataAccept.

E. The master sees that SDataAccept is deasserted, so it holds the values of MDataValid and MData. The slave asserts SDataAccept, for a data accept latency of 1.

F. Since SDataAccept is asserted, the datahandshake phase ends. The master is ready to deliver the write data for the third request, so it keeps MDataValid asserted and presents the data on MData. The slave captures the data for the second write from MData, and keeps SDataAccept asserted, for a data accept latency of 0 for the third write.

G. Since SDataAccept is asserted, the datahandshake phase ends. The slave captures the data for the third write from MData.


Threaded ReadFigure 13 illustrates out-of-order completion of read transfers using OCP’s thread extension. This diagram is developed from Figure 8 on page 45. The thread IDs, MThreadID and SThreadID, have been added, and the order of two of the responses has been changed.

Figure 13 Threaded Read


address on MAddr. It also drives a 0 on MThreadID, indicating that this read request is for thread 0. The slave asserts SCmdAccept, for a request accept latency of 0. When the slave sees the read command, it responds with DVA on SResp and valid data on SData. The slave also drives a 0 on SThreadID, indicating that this response is for thread 0.

B. Since SCmdAccept is asserted, the phase ends. The master sees that SResp is DVA and captures the read data from SData. Because the request was accepted and the response was presented in the same cycle, the request-to-response latency is 0.

C. The master launches a new read request, but this time it is for thread 1. The slave asserts SCmdAccept, however, it is not ready to respond.

Clk

MAddr

MCmd

MData

SCmdAccept

SResp

SData

IDLE

NULL

A1

RD1 IDLE

NULL

A3

RD3

DVA2 NULL

D2

IDLE

DVA1

D1

A2

RD2

DVA3

D3

NULL

MThreadID 01 0312

SThreadID 1201 03

A B C D E F G

2 3 4 5 6 71

Req

uest

Pha

seR

espo

nse

Pha

se

Timing Diagrams 53

D. Since SCmdAccept is asserted, the master can launch another read request. This request is for thread 0, so MThreadID is switched back to 0. The slave captures the address of the second read for thread 1, but it begins driving DVA on SResp, data on SData, and a 0 on SThreadID. This means that it is responding to the third read, before the second read.

E. Since SCmdAccept is asserted, the third request ends. The master sees that the slave has produced a valid response to the third read and captures the data from SData. The request-to-response latency for this transfer is 0.

F. The slave has the data for the second read, so it drives DVA on SResp, data on SData, and a 1 on SThreadID.

G. The master captures the data for the second read from SData. The request-to-response latency for this transfer is 3.

6 Timing Specification

To enable two entities to be connected together and communicate over an OCP interface, the protocols, signals, and pin-level timing must be compat-ible. This chapter describes how to define interface timing for a core. This process can be applied to OCP and non-OCP interfaces.

When implementing IP cores in a technology independent manner it is diffi-cult to specify only one timing number for the interface signals, since timing is dependent on technology, library and design tools. The methodology spec-ified in this chapter allows the timing of interface signals to be specified in a technology independent way.

A core’s timing parameters are collected into the core synthesis configuration file described in Chapter 14 on page 141.


Timing ParametersThere is a set of minimum timing parameters that must be specified for a core interface. Additional optional parameters supply more information to help the system designer integrate the core. Hold-time parameters allow hold time checking. Physical-design parameters provide details on the assumptions used for deriving pin-level timing.

Minimum ParametersAt a minimum, the timing of an OCP interface is specified in terms of two parameters:

• setuptime is the latest time an input signal is allowed to change before the rising edge of the clock.

• c2qtime is the latest time an output signal is guaranteed to become stable after the rising edge of the clock.

Figure 14 shows the definition of setuptime and c2qtime.

Figure 14 OCP Timing Parameters

Hold-time ParametersHold-time parameters are needed to allow the system integrator to check hold time requirements. On the output side, c2qtimemin specifies the minimum time for a signal to propagate from a flip-flop to the given output pin. On the input side, holdtime specifies the minimum time for a signal to propagate from the input pin to a flip-flop.

1 clock cycle

c2qtime setuptime

logic logic

Timing Specification 57

Physical Design ParametersTo give meaning to the timing values, timing requirements on input and output pins must be accompanied by information on the assumed environ-ment for which these numbers are determined. This information also adds detail on the expected connection of the pin.

For an input signal, the parameter drivingcellpin indicates the cell library name for a cell representative of the strength of the driver that needs to be used to drive the signal. This is shown in Figure 15.

Figure 15 Driver Strength

For an output signal, the variable loadcellpin indicates the input load of the gate that the signal is expected to drive. The variable loads indicates how many loadcellpins the signal is expected to drive. Additionally, information on the capacitive load of the wire must be included. There are two options. Either the variable wireloaddelay can be specified, as shown in Figure 16. Or, the combination wireloadcapacitance/wireloadresistance must be speci-fied, as shown in Figure 17.

Figure 16 Variable Loads - wireloaddelay

For instructions on calculating a delay, refer to the Synopsys Design Compiler Reference.

logic

drivingcellpin core

loadslogic

wireloaddelay

loadcellpin


Figure 17 Variable Loads - wireloadresistance/wireloadcapacitance

Connecting Two OCP CoresFigure 18 shows the timing model for interconnecting two OCP compliant cores.

The sum of setuptime, c2qtime and wire delay must be less than the clock period or cycle time minus the clock-skew. Similarly, the minimum clock-cycle for two cores to interoperate is determined by the maximum of the sum of c2qtime, setuptime, wire delay and clock-skew over all interface signals.

The wireload delay is defined by either the variable wireloaddelay or the set wireloadcapacitance/wireloadresistance.

Figure 18 Connecting Two OCP Compliant Cores

logic

loadcellpin

loads

wireloadresistance

wireloadcapacitance

logic

loads * loadcellpin

wireloadresistance

wireloadcapacitance

drivingcellpin

logic logic

c2qtime wireloaddelay setuptime clock skew

1 clock cycle

Timing Specification 59

Max DelayIn addition to the setup and c2qtime paths for a core, there may also be combinational paths between input and output ports. Use maxdelay to specify the timing for these paths.

Figure 19 Max Delay Timing

False PathsIt is possible to identify a path between two ports as being logically impossible. Such paths can be specified using the falsepath constraint syntax.

For instructions on specifying the core’s timing parameters, see Chapter 14 on page 141.

max delay

logicinput output

7 Core Performance

To make it easier for the system integrator to choose cores and architect the system, an IP core provider must document a core’s performance character-istics. This chapter supplies a template for a core performance report on page 66, and directions on how to fill out the template.

Report InstructionsTo document the core, you will need to provide the following information:

1. Core name. Identify the core by the name you assigned.

2. Core ID. Specify the precise identification of the core inside the system-on-chip. The information consists of the vendor code, core code, and revision code.

3. Core is/is not process dependent. Specify whether the core is process-dependent or not. This is important for the frequency, area, and power estimates that follow.

If multiple processes are supported, name them here and specify corresponding frequency/area/power numbers separately for each core if they are known.

4. Frequency range for this core. Specify the frequency range that the core can run at. If there are conditions attached, state them clearly.

5. Area. Specify the area that the core occupies. State how the number was derived and be precise about the units used.

6. Power estimate. Specify an estimate of the power that the core consumes. This naturally depends on many factors, including the operations being processed by the core. State all those conditions clearly, and if possible, supply a file of vectors that was used to stimulate the core when the power estimate was made.


7. Special reset requirements. If the core needs Reset_n asserted for more than the default (16 OCP clock cycles) list the requirement.

8. Number of interfaces.

9. Interface information. For each OCP interface that the core provides, list the name and type.

The remaining sections focus on the characteristics and performance of these OCP interfaces.

• For master OCP interfaces:

a. Operations issued. State the types of operations issued (i.e. reads, writes, etc.)

b. Issue rate (per OCP cycle for sequences of reads, writes, and interleaved reads/writes). State the maximum issue rate. Specify issue rates for sequences of reads, writes, and interleaved reads and writes.

c. Maximum number of operations outstanding (pipelining support). State the number of outstanding operations that the core can support; is there support for pipelining.

d. Burst support and effect on issue rates. State whether the core has burst support, how it makes use of bursts, and how the use of bursts affects the issue rates.

e. High level flow-control. If the core makes use of high-level flow control, such as full/empty bits, state what these mechanisms are and how they affect performance.

f. Number of threads supported and use of those threads. State the number of threads supported. If more than one, explain the use of threads.

g. Connection ID support. Explain the use and meaning of connection information.

h. Use of side-band signals. For each sideband signal (such as SInterrupt, MFlag) explain the use of the signal.

i. If the OCP interface has any implementation restrictions, they need to be clearly documented.

• For slave OCP interfaces:

a. Operations supported. For slave interfaces, state the types of operations supported.

b. Unloaded latency for each operation (in OCP cycles). Describe the unloaded latency of each type of operation.

c. Throughput of operations (per OCP cycle for sequences of reads, writes, and interleaved reads/writes). State the maximum throughput of the operations for sequences of reads, writes, and interleaved reads and writes.

Core Performance 63

d. Maximum number of operations outstanding (pipelining support). State the number of outstanding operations that the core can support, i.e. is there support for pipelining.

e. Burst support and effect on latency and throughput numbers. State whether the core has burst support, how it makes use of bursts, and how the use of bursts affects the latency and throughput numbers stated above.

f. High level flow-control. If the core makes use of high-level flow control, such as full/empty bits, state what these mechanisms are and how they affect performance.

g. Number of threads supported and use of those threads. State the number of threads supported. If more than one, explain the use of threads.

h. Connection ID support. Explain the use and meaning of connection information.

i. Use of side-band signals. For each sideband signal (such as SInterrupt, MFlag) explain the use of the signal.

j. If the OCP interface has any implementation restrictions, they need to be clearly documented.

• For every non-OCP interface, you will need to provide all of the same information as for OCP interfaces wherever it is applicable.


Sample Report

1. Core name flashctrl

2. Core identity Vendor codeCore codeRevision code

0x50c50x0020x1

3. Core is/is not process dependent

Not

4. Frequency range for this core <100Mhz with NECCBC9-VX library

5. Area 4400 gates2input NAND equivalent gates

6. Power estimate not available

7. Special reset requirements

8. Number of interfaces 2

9. Interface information:NameType

ipslave

For master OCP interfaces:

a. Operations issued

b. Issue rate (per OCP cycle for sequences of reads, writes, and interleaved reads/writes)

c. Maximum number of operations outstanding (pipelining support)

d. Burst support and effect on issue rates

e. High level flow-control

f. Number of threads supported and use of those threads

g. Connection ID and use of connection information

h. Use of side-band signals

i. Implementation restrictions

Core Performance 65

For slave OCP interfaces:

a. Operations supported read, write

b. Unloaded latency for each operation (in OCP cycles)

Register read or write: 1 cycle. The flash read takes SBFL_TAA (read access time). Can be changed by writing corresponding register field of emem configuration register.The flash write operation takes about 2000 cycles since it has to go through the sequence of operations - writing command register, reading the status register twice.

c. Throughput of operations (per OCP cycle for sequences of reads, writes, and interleaved reads/writes)

No overlap of operations therefore reciprocal of latency.

d. Maximum number of operations outstanding (pipelining support)

No pipelining support.

e. Burst support and effect on latency and throughput numbers

No burst support.

f. High level flow-control No high-level flow-control support.

g. Number of threads supported and use of those threads

No thread support.

h. Connection ID and use of connection information

No connection information support.

i. Use of side-band signals Reset_n, Control, SError. Control is used to provide additional write protection to critical blocks of flash memory.SError is used when an illegal width of write is performed. Only 16 bit writes are allowed to flash memory.

j. Implementation restrictions

For every non-OCP interfaceProvide all of the same information as for OCP interfaces wherever it is applicable.

Hitachi flash card HN29WT800Only 1 flash ROM part is supported, therefore the CE_N is hardwired on the board.The ready signal RDY_N, is not used since not all parts support it.For the BYTE_N signal, only 16-bit word transfers are supported


Performance Report TemplateUse the following template to document a core.

1. Core name

2. Core identity Vendor codeCore codeRevision code

3. Core is/is not process dependent

4. Frequency range for this core

5. Area

6. Power estimate

7. Special reset requirements

8. Number of interfaces

9. Interface information:NameType

For master OCP interfaces:

a. Operations issued

b. Issue rate (per OCP cycle for sequences of reads, writes, and interleaved reads/writes)

c. Maximum number of operations outstanding (pipelining support)

d. Burst support and effect on issue rates

e. High level flow-control

f. Number of threads supported and use of those threads

g. Connection ID and use of connection information

h. Use of side-band signals

i. Implementation restrictions

Core Performance 67

For slave OCP interfaces:

a. Operations supported

b. Unloaded latency for each operation (in OCP cycles)

c. Throughput of operations (per OCP cycle for sequences of reads, writes, and interleaved reads/writes)

d. Maximum number of operations outstanding (pipelining support)

e. Burst support and effect on latency and throughput numbers

f. High level flow-control

g. Number of threads supported and use of those threads

h. Connection ID and use of connection information

i. Use of side-band signals

j. Implementation restrictions

For every non-OCP interfaceProvide all of the same information as for OCP interfaces wherever it is applicable.

8 Behavioral Models

Behavioral models can be used to validate OCP-compatible IP cores or for performance analysis of systems. The components in the behavioral library are:

• Q-Master

• Q-Slave

• OCP Merger

• OCP Monitor

Q-MasterUse Q-Master (Quick Master) behavioral models to stimulate cores while checking for OCP compliance and verifying core functionality and perfor-mance. Q-Master models drive the master side of an OCP interface. The models take in an assembled Socket Transaction Language (STL) script, and drive the OCP signals accordingly during system simulation.

There are two types of Q-Master models. Quick System Master (QSMaster) is a behavioral OCP master used to model a system. Quick Core Master (QCMaster) is a behavioral OCP master used to model a core. The primary difference between these two behavioral models is their interaction with the OCP status and control signals. The differences are only visible in the STL statements supported by the different models (see “Socket Transaction Language” on page 85).


FeaturesQ-Master inherits the OCP features from the interface it is connected to, and configures itself accordingly. For example, if burst is enabled on the OCP, Q-Master drives burst codes on the interface. If burst is not enabled, no burst information is driven. All legal OCP configurations except those with reset disabled are supported.

Q-Master reads test vectors from a memory image file that is produced by the STL assembler, ocpasm. Q-Master drives OCP requests to and waits for OCP responses from the attached slave. Upon reaching the end of the test vector file, Q-Master sends Idle commands.

While Q-Master has the ability to drive different MThreadID values onto the OCP interface, it is not a truly multi-threaded model. To build a multi-threaded master with independent STL scripts, use multiple Q-Master models and merge their OCP interfaces into a single OCP interface using the OCP Merger model.

Configuration SettingsThe following settings control Q-Master functionality.

Test LengthMaxtest_size controls the maximum test vector size that can be loaded into the Q-Master memory. The setting is specified in units of commands.

Table 10 Q-Master Test Memory Size

Time StampWhen timestamp_enable is on, cycle directives in the input Socket Transaction Language are obeyed; that is, the Q-Master model waits for the specified time to arrive until it issues the command. If timestamp_enable is off, cycle direc-tives are ignored and the commands are issued as soon as possible. This latter mode is useful in some debugging situations, but the most common use is with timestamp_enable on.

Table 11 Q-Master Time Stamp

Name Default Function

maxtest_size 10000 maximum test size


timestamp_enable 1 obey cycle directives (timestamps)

Behavioral Models 71

MRespAccept DelayIf an OCP with MRespAccept extension is used, Q-Master models can delay the driving of MRespAccept upon receiving a response from the slave. The delay value (in OCP cycles) is specified by mrespaccept_delay. A value of 0 for mrespaccept_delay means that the response is accepted in the same cycle that it is received by Q-Master. If an OCP without the MRespAccept extension is used this setting is ignored.

Table 12 Q-Master Delay for MRespAccept

MThreadBusy ControlWhen MThreadBusy is configured to be part of the OCP, the MThreadBusy signal associated with a thread goes active (high) for a number of cycles equal to mthreadbusy_delay after a response has been accepted on that thread. When mthreadbusy_delay is 0, the MThreadBusy signals never go active. If an OCP without the MThreadBusy extension is used this setting is ignored.

Table 13 Q-Master MThreadBusy Control

MData DelayWhen the OCP has the handshake option turned on, write data is sent mdata_delay cycles after the request is sent. A value of 0 for mdata_delay means that the write data is sent in the same cycle as the write command. If an OCP without datahandshake extension is used this setting is ignored.

Table 14 Q-Master Delay for MData


mrespaccept_delay 0 MRespAccept delay in OCP cycles


mthreadbusy_delay 0 MThreadBusy delay in OCP cycles


mdata_delay 0 MData delay in OCP cycles


Q-SlaveQ-Slave (Quick Slave) models are used to model simple OCP slaves such as memories and I/O devices. You can configure them to mimic common types of behavior such as SRAM, DRAM, etc.

Quick System Slave (QSSlave) is a behavioral OCP slave used to model a system. Quick Core Slave (QCSlave) is a behavioral OCP slave used to model a core. The primary difference between these two behavioral models is their interaction with the OCP status and control signals. Because the two models are so similar, they are described together in this section, and only differences between the models are explicitly pointed out.

FeaturesQ-Slave inherits an OCP configuration from the interface to which it is connected. All legal OCP configurations are supported, except those with reset disabled.

Q-Slave waits for OCP requests from, and drives OCP responses to the attached master. Q-Slave can behave as a simple memory model, with user-defined response latency and burst behavior, as well as the ability to pre-load memory data at the start of simulation. Q-Slave can also model read and write FIFOs. You can assign specific memory addresses inside Q-Slave to trigger changes on the OCP sideband signals.

When the MAddrSpace extension is present on the OCP, QSlave supports multiple address spaces in the memory area. All address spaces are completely independent of one another in terms of the storage accessed.

Q-Slave supports multiple threads. With independent threads, it is possible that two or more threads are ready to return a response to the OCP interface in the same cycle. Q-Slave resolves this contention with a simple round-robin response arbitration.

Q-Slave supports the OCP ReadEx command, but with slightly looser seman-tics than described in “Protocol Semantics” on page 25. Instead of locking out all competing commands, only competing ReadEx commands are locked out. The implementation aliases all addresses together, permitting only one lock to be active at any moment in time.

Configuration SettingsThe following settings control Q-Slave functionality.

Memory SizeThe size of the target memory is set with mem_2size. The memory size is in units of address bits and doesn’t include MAddrsSpace (if present).


Table 15 Q-Slave Memory Size

Fixed Data Memory InitializationThe internal memory can be initialized at the beginning of the simulation using several different methods. If not initialized, all bits in the memory are initialized to unknown. All initialization methods treat the memory as a byte-wide memory. Setting meminit_fixed to 1 causes each byte in the memory to be initialized with the value meminit_fixeddata.

Table 16 Q-Slave Fixed Data Memory Initialization

Memory Initialization from a FileThe memory can also be initialized by reading a file called <instance>_q[c|s]slave.mem. <instance> is the name of the core instance that is to be preloaded. The format of this file can be binary or hex.

If using meminit_preloadb then each line contains 8 binary digits. If using meminit_preloadh then each line contains 2 hex digits (1 byte). The first line corresponds to address 0, the next line is address 1, etc. For additional infor-mation about the syntax see the Verilog readmemh syntax. For example:

@<address> <byte in hex or binary>

Table 17 Q-Slave Memory Initialization from a File

LatencyThe delay in OCP cycles from request acceptance to response is controlled by the latency variable. The minimum value for latency is 0. The maximum value is 255. If latency is set to 0, SResp can occur in the same cycle as SCmdAc-cept. The latency parameter can be annotated with a thread identifier to specify the latency for a particular thread. For example latency2 sets the response latency for thread 2.


mem_2size 14 memory size (address bits)


meminit_fixed 0 initialize memory with fixed data

meminit_fixeddata 0 data to initialize memory


meminit_preloadb 0 preload memory from binary file

meminit_preloadh 0 preload memory from hex file


Table 18 Q-Slave Latency

Burst LatencySetting burstlat_enable to 1 puts the Q-Slave in burst mode. Non-burst transactions and the first transfers in a burst have a latency equal to latency. Subsequent transfers in a burst have a latency of burstlat_cycles, which must be smaller than or equal to latency. If the burst extension is not used this setting is ignored.

When burstlat_1thread is set to 0, multiple bursts can be outstanding and the performance of a burst on one thread is not affected by a burst on another thread. When burstlat_1thread is 1, the core is modelled as a single threaded core that can only have one burst outstanding over all threads. If a new burst is started while there is an ongoing burst on a different thread, the outstanding burst is interrupted. The next request on that interrupted thread once again sees latency rather than the shorter burstlat_cycles.

All of these parameters can also be annotated with a thread ID to allow settings for specific threads. For example, burstlat_enable1 enables burst latency behavior on thread 1.

Table 19 Q-Slave Burst Latency

Random Latency ModeQ-Slave can be configured to use random latencies instead of fixed values. By turning on randmode_enable, the following parameters are randomized for each access: scmdaccept_delay, sdataaccept_delay, latency(n), and burstlat_cycles(n). The random value chosen is between 0 and 2 times the value defined for each parameter.

Table 20 Q-Slave Random Latency


latency[n]* 3 (QCSlave) response latency [on thread n]

6 (QSSlave)

* If specified, the per-thread value is always used. If a per-thread value is not specified, the global, thread independent value is used. If neither value is specified, the per-thread default value is used.


burstlat_enable[n]* 0 enable special latency for bursts [on thread n]

burstlat_cycles[n]* 1 latency for burst transactions [on thread n]

burstlat_1thread 0 single-threaded burst behavior


randmode_enable 0 enable random latency mode


Limiting Outstanding RequestsTo limit the number of outstanding requests per thread, set limitreq_enable to 1 and limitreq_max to the number of allowed outstanding requests. If limitreq_enable is set to 0, there is no limitation on the number of outstanding requests the target core can handle. The minimum number of outstanding requests is 1, the maximum is 255. When the maximum is reached for a thread, the target core does not accept any new requests on that thread until earlier requests have been completed. In addition, SThreadBusy signals are driven as appropriate when they are enabled in the OCP interface.

Table 21 Q-Slave Limiting Requests

SCmdAccept DelayQ-Slave models can delay the driving of SCmdAccept upon receiving a request from the master. The delay value (in OCP cycles) is specified by scmdaccept_delay. A value of 0 for scmdaccept_delay means that if it can be, the request is accepted in the same cycle that it is received by Q-Slave.

Table 22 Q-Slave Delay for SCmdAccept

SDataAccept DelayIf datahandshake is enabled, Q-Slave models can delay the driving of SDataAc-cept upon receiving write data from the master. The delay value (in OCP cycles) is specified by sdataaccept_delay. A value of 0 for sdataaccept_delay means that the write data is accepted in the same cycle that it is received by Q-Slave. This setting is ignored if the datahandshake extension is not used.

Table 23 Q-Slave Delay for SDataAccept

SInterrupt, SError, and SFlag Signal ControlThe SInterrupt, SError, and SFlag signals can be independently controlled from the system as side-effects of writes to special memory locations. The positioning of these memory locations is configurable. SInterrupt uses interrupt_setaddr and interrupt_resetaddr. Writing any data to the


limitreq_enable 0 limit outstanding requests per thread

limitreq_max 4 maximum number of outstanding requests per thread


scmdaccept_delay 0 SCmdAccept delay in OCP cycles


sdataaccept_delay 0 SDataAccept delay in OCP cycles


interrupt_setaddr location causes the SInterrupt signal to go high. Writing any data to the interrupt_resetaddr location causes the SInterrupt signal to go low again. The two addresses must be different.

The number of cycles of delay between writing of the memory location and the setting or resetting of the SInterrupt signal is configured using interrupt_delay. The same applies for the SError signal.

Table 24 Q-Slave SInterrupt Control

Table 25 Q-Slave SError Control

SFlag signals are set using the SFlag and SFlagMask registers. Reading the SFlag register retrieves the current value of the SFlag signals. Bit 0 contains the value of SFlag0 and so on. Setting of SFlags is accomplished by writing to the SFlag register, but is subject to the SFlagMask register. Only SFlags that have their bit set in the SFlagMask register are subject to change when the SFlag register is written. Use sflag_delay to configure the number of cycles of delay between writing to the sflag_addr memory location and setting or reset-ting of the SFlag signals.

The default value of the SFlag register is to have all flag bits set to 0. The default value of the SFlagMask register is to have all bits corresponding to SFlags set to 1, that is, the setting of all flags is enabled. The addresses of the SFlag register and SFlagMask register are determined by the parameters sflag_addr and sflagmask_addr respectively. Separate the SFlag and SFlag-Mask registers by the width of an OCP word. In the case of a write, leaving insufficient space between the registers will produce unpredictable results.

The current values of the MFlag signals can be retrieved by reading the MFlag register. The location of this register is set with the mflag_addr parameter.


interrupt_setaddr x3fd0 address to set SInterrupt

interrupt_resetaddr x3fc0 address to reset SInterrupt

interrupt_delay 1 delay cycles from write to set/reset SInterrupt signal


error_setaddr x3fb0 address to set SError signal

error_resetaddr x3fa0 address to reset SError signal

error_delay 1 delay cycles from write to set/reset SError signal


Table 26 Q-Slave SFlag Control

SThreadBusy ControlControl over the behavior of SThreadBusy signals is through the sthreadbusy_enable parameter. When set to 1, the OCP SThreadBusy signals are asserted when no further requests can be accepted on a given thread. When set to 0, the SThreadBusy signals are never asserted, allowing the OCP interface to block any requests that are sent on a thread that cannot accept any more requests. This setting is ignored if the SThreadBusy extension is not used.

Table 27 Q-Slave SThreadBusy Control

Error ResponseRandom error responses on the SResp field can be generated by setting the resperr_enable variable to 1. The resperr_rate value determines at what rate error responses are generated. Error responses are generated on average every resperr_rate Read or ReadEx command.

Table 28 Q-Slave Error Response

Read/Write FIFO ModeStreaming input and output devices are modeled by Q-Slave using the read and write FIFO modes respectively. The read FIFO mode periodically fills an internal data FIFO with incrementing data values (starting from 0 at reset), and so can be used to model an input device. The write FIFO mode periodi-cally drains an internal data FIFO (throwing away the data), and is used to model an output device. Watermarks on the internal data FIFO can be set to cause interrupts.


sflag_addr 0x3d00 address of SFlag register

sflagmask_addr 0x3d80 address of SFlagMask register

sflag_delay 1 delay cycles form write to SFlag register

mflag_addr 0x3e00 address of MFlag register


sthreadbusy_enable 1 enable SThreadBusy behavior


resperr_enable 0 generate response errors

resperr_rate 100 average response error interval


To turn on write FIFO mode, set wrfifo_enable. The address of the FIFO is configured with wrfifo_addr, and the drain rate with wrfifo_rate. The write FIFO is filled with data by writing to the specified address, and a data word is drained once every wrfifo_rate OCP cycles. The write FIFO size is specified using wrfifo_size. If too many words are written into the write FIFO too quickly, it fills up and causes the OCP interface to stop accepting requests.

The write FIFO can be configured to give a warning of impending emptying using an interrupt. For this mode to work, SInterrupt must be configured into the OCP. The high and low marks for this warning interrupt are set with wrfifo_high and wrfifo_low respectively. SInterrupt is set when the FIFO reaches the low mark (that is, it is about to go empty) and is reset when the FIFO reaches the high mark.

The read FIFO has very similar behavior except that it is filled automatically and is drained by reading the FIFO. The read FIFO sends an interrupt when it reaches the high mark indicating that it is about to overflow.

Table 29 Q-Slave Read/Write FIFO Mode Parameters

Control/Status Register VariablesUnlike the OCP dataflow signals, the direction of the control and status signals (and related ControlWr, ControlBusy, StatusRd, and StatusBusy signals) depends not on whether the entity is a master or slave, but rather whether it is a core or a system. QSSlave acts like a system, and QCSlave acts like a core.

For QSSlave, the control and status information of the OCP interface can be set and read respectively using special registers. The location of these regis-ters is controlled with controlreg_addr and statusreg_addr. Whatever is written into the control register shows up on the control signals. The status signals can be observed by reading the status register.


wrfifo_enable 0 enable write FIFO mode

wrfifo_addr 0x0 write FIFO address

wrfifo_size 20 write FIFO size

wrfifo_high 10 write FIFO high mark: reset interrupt

wrfifo_low 3 write FIFO low mark: set interrupt

wrfifo_rate 10.0 write FIFO drain rate (cycles to drain one word)

rdfifo_enable 0 enable read FIFO mode

rdfifo_addr 0x0 read FIFO address

rdfifo_size 20 read FIFO size

rdfifo_high 10 read FIFO high mark: set interrupt

rdfifo_low 3 read FIFO low mark: reset interrupt

rdfifo_rate 10.0 read FIFO fill rate (cycles to fill one word)


Table 30 QSSlave Control/Status Registers

For QCSlave, a set of special registers exists to drive the status signals and observe the control signals. The location of these registers is controlled by statusdrive_addr and controlobserve_addr respectively.

Table 31 QCSlave Control/Status Registers

In addition to interacting with the OCP control and status signals, QCSlave can also drive ControlBusy and StatusBusy. When controlbusye_enable is set, QCSlave drives the ControlBusy signal active for controlbusy_cycles for every control write (that is, for every assertion of the ControlWr signal). When statusbusye_enable is set, QCSlave drives the StatusBusy signal active for statusbusy_cycles for every status read (that is, for every assertion of the StatusRd signal).

Table 32 QCSlave ControlBusy and StatusBusy Behavior

OCP MergerThe OCP Merger behavioral model merges two or more OCP interfaces into a single OCP interface to provide an environment for multi-threaded Socket Transaction Language tests. OCP Merger allows multiple QCMasters (each with their own single-threaded STL script) to be connected together using OCP Merger, yielding a multi-threaded OCP interface as shown in Figure 20. Besides merging the incoming requests and distributing the responses, OCP Merger allows the masters connected to it to communicate using core flags.


controlreg_addr x3fe0 address of control register

statusreg_addr x3ff0 address of status register


controlobserve_addr x3fe0 address to observe Control signals

statusdrive_addr x3ff0 address to drive Status signals


controlbusye_enable 0 causes QCSlave to assert ControlBusy when ControlWr is seen asserted

controlbusy_cycles 2 number of cycles to assert ControlBusy after ControlWr is seen asserted

statusbusye_enable 0 causes QCSlave to assert StatusBusy when StatusRd is seen asserted

statusbusy_cycles 2 number of cycles to assert StatusBusy after StatusRd is seen asserted


Figure 20 OCP Merger Block Diagram

Configuration RestrictionsTwo or more OCP masters and a single OCP slave can be connected to OCP Merger. The slave interfaces act as OCP system interfaces and must be connected to cores. The master interface acts as an OCP core interface and must be connected to a system. Observe the following rules:

1. Masters must be connected to OCP slave interfaces 0 through n, with no unconnected slave interface in the 0-n range.

2. All OCP interfaces must be identically configured with the following exceptions:

• The OCP master interface must include reset, the OCP slave interfaces need not.

• The OCP slave interfaces must be single-threaded, while the OCP master interface has as many threads as there are slave interfaces.

• SThreadBusy is not required on the OCP slave interfaces, even if it is on the OCP master interface.

• The OCP slave interfaces can have wider MFlag or SFlag fields than the OCP master interface to allow communication between the attached masters.

mflag_wdth must be the same on all slave interfaces. sflag_wdth must be the same on all slave interfaces. The difference between mflag_wdth on the slave interfaces and mflag_wdth on the master interface must be identical to the difference between the sflag_wdth on the slave interfaces and sflag_wdth on the master interface.

• No OCP interface can have any test signals enabled.

3. To avoid blocking the shared master interface, use SThreadBusy on the master interface and either disable MRespAccept or enable MThreadBusy on all of the master and slave interfaces.

MasterInterface

Slave 0Interface

Slave 1Interface

Slave nInterface

OCP

OCP

O CP OCP...

...

MasterInterface

Slave 0Interface

Slave 1Interface

Slave nInterface

OCP

OCP

O CP OCP...

...


FunctionalityOCP Merger has no storage. Any request received on one of the slave inter-faces is either immediately forwarded to the master interface, or not accepted at the slave. If multiple masters send a request at the same time, round-robin arbitration is used to access the master interface.

All sideband signals coming from the OCP slave interfaces (except surplus MFlag signals) are individually ORed together and passed to the corre-sponding OCP master interface sideband signals. All sideband signals coming from the OCP master interface are fanned out to the corresponding OCP slave interface sideband signals. Surplus OCP slave interface MFlag signals are individually ORed together and fanned out to the corresponding surplus SFlag signals on the OCP slave interfaces as shown in Figure 21.

Figure 21 Merger Signal Processing

OCP MonitorThe OCP monitor (OCPMON) tracks the data on the OCP interface and writes it out on a per cycle basis. The output of OCPMON can be post-processed by the ocpdis, ocpperf and ocpcheck tools to view and validate OCP performance and correctness. For more information, see the CoreCreator Guide.

The OCP monitor supports the full functionality and configurability of the OCP interface. While the OCP monitor supports test signals, it does not monitor them.

The following settings control the behavior of the OCP monitor.

MFlag SFlag

MFlags SFlags MFlags SFlags MFlags SFlags

slv0 slv1 slv2

master


Simulation TerminationThe OCP monitor terminates simulation once a specified number of consecu-tive idle request cycles is seen on the corresponding OCP. This feature is turned on using watch_enable and the number of idles to watch for can be specified using watch_maxidles.

Table 33 OCPMON Simulation Termination

If the monitor detects Xs after initialization has completed, simulation stops and the monitor issues an error message.

WGL FormatThe OCP monitor can also output a trace of the monitored signals in WGL format. wgl_enable turns on this mode, and wgl_slave controls whether the WGL is generated from the master or the slave point of view.

Table 34 OCPMON WGL Format

OCP Monitor Task Interface OCP monitor tasks can be called from the testbench to control the monitor’s behavior. For example, in the case of a long performance simulation where trace information is only needed for specific OCPs, you could call dumpOff for the OCPs that do not need analysis.

setMaxIdles( <integer newMaxIdles> ) setMaxIdles can be used to increase the maximum number of idles for an OCP that is not being used in a particular test. This overrides the default value for watch_maxidles. If newMaxIdles is -1, max idle detection is disabled.

To avoid a race with the default setting that takes place during internal initialization, make sure that the testbench task call occurs after time 0. One way to accomplish this is to use the #0 construct as shown in the following example. Another method is to wait until reset is deasserted and then call setMaxIdles.


watch_enable 1 enable watching for idle request cycles

watch_maxidles 1000 maximum number of consecutive idles before simulation is stopped


wgl_enable 0 generate WGL output file

wgl_slave 1 generate WGL from slave point of view


initial begin

#0; stim.chip0.ocp0.setMaxIdles(100);

end

dumpOff This disables the creation of the OCP trace file, <OCPNAME>.ocp. If one is currently being produced, it is closed, but not deleted. There is no way to re-enable a trace file, because information needed to align requests and responses cannot be recalled.

If you do not want an OCP trace file to be created, specify the dumpOff task before the first posedge of the OCP clock.

9 Socket Transaction Language

The Socket Transaction Language (STL) generates test vectors. An STL script is assembled by the ocpasm tool. The output is an executable format that is read by the Q-Master behavioral models to generate the desired stimulus on the OCP master interface of the behavioral model. This chapter describes STL syntax.

The three components of the Socket Transaction Language are basic commands, and macro and behavioral statements.

• Basic commands are transfer-oriented and enable control of the OCP signals on a per-cycle basis.

• Macro statements provide a quick method of generating one or more basic commands.

• Behavioral statements allow you to set and observe sideband signals or control the simulation run.

Commands appearing in bold must be typed as shown.

Basic CommandsBasic commands correspond on a one-for-one basis to the OCP commands. See Chapter 4 “Protocol Semantics” on page 25 for a definition of OCP command semantics. The format for a basic command is:

[cycle:] [tid[/cid]] cmd [as/]address [(be)][data [(mask)]]

Items in brackets [ ] are optional. If an optional field has parenthesis ( ), the parenthesis must be included. Only the cmd and address fields are required.

The simplest possible command is:

read 0x0


which consists of a command (read) and an address (0x0 = 0 in hex). This command reads from address 0.

The following sections describe the fields of a basic command and how they are used.

CycleThe first OCP cycle that this command can be executed. If the STL command is processed before time specified by cycle, then the command is held until time cycle before being issued to the OCP. This also delays all of the commands that follow. If the STL command is processed after time cycle, it is issued immediately.

A cycle must be specified as a decimal number and must be followed by a colon.

TID: Thread IdentifierThe thread ID to use for this command. If a thread ID is not supplied, the default is 0. The TID must be specified as a decimal number.

CID: Connection IdentifierThe connection ID to use for this command. If a connection ID is not supplied, the thread identifier is used by default. The CID must be specified as a decimal number.

CMDAll basic commands except Idle require an address and may also have addi-tional required fields. For example the Write command requires the data to be written. Table 35 lists the options for the cmd field. The Read and Write commands can also be annotated with a specific burst code.

Table 35 cmd Field Options

Command DescriptionExtra required fields

Idle Send Idle command over the OCP (See also the “Idle Macro” on page 91)

Read Read from the specified address

Write Write the data to the specified address data

Broadcast Broadcast the data to everyone at the specified address

data

Readex Exclusive read from the specified address

Socket Transaction Language 87

A command can have a size suffix of 8, 16, 32, 64, 128, or 256, that describes the data size to be read or written. Tests written with the size suffix perform the same transfers on OCPs with different data widths, thereby improving the reusability of the test. If a size is not specified it is assumed to be the size of the OCP.

If the OCP data width is smaller than the size suffix, the command is trans-lated into several burst transfers. For example, the command to write to address 0 is:

write 64 0 0x0123456789abcdef

would be translated to a burst of 2, 32 bit writes on a 32 bit OCP:

2xwrite 0 0x89abcdefwrite 4 0x01234567

AddressThe address to read from or write to. The address can be specified as decimal or hexadecimal (using the prefix 0x) number. An address is zero-extended or truncated to the width of the OCP address field.

For basic commands, the address must be aligned with the OCP data width. If the OCP has 8 bit wide data, then addresses can be 0, 1, 2, 3, etc. If the data width is 16 bits, then addresses must be 0, 2, 4, etc. And if the data width is 32 bits, then the addresses must be 0, 4, 8, etc.

AS: Address SpaceThe address space to read from or write to. The address space can be specified as a decimal or hexadecimal (using the prefix 0x) number. The specified address space is zero-extended or truncated to the width of the OCP address space field.

{burst_code}xread Read from the specified address, using the specified burst code. For example, the command 4xread produces a read command with a burst code of 4

0xread is exactly equivalent to read

{burst_code}xwrite Write the data to the specified address, using the specified burst code. For example, the command 2xwrite produces a write command with a burst code of 2

0xwrite is exactly equivalent to write

data

Command DescriptionExtra required fields


BE: Byte EnableThe byte enable field specifies which of the bytes of a read or readex should be read and which of the bytes of a write or broadcast should be written. The default is all ones, which means use all of the bytes. The byte enable field can be either decimal or hexadecimal (using the prefix 0x) number. The byte enable field is zero-extended to the width of the OCP byte enable field.

The field can contain an explicit byte enable value (which is then applied to every command in a burst) or when it contains the keyword rbe, generate random byte enables.

DataThe data to be written for a write command. Data can be specified as decimal or hexadecimal (using the prefix 0x) number. Data is zero-extended to the OCP data width. When an optional data field is used in a read, readex, or xread command, it specifies the expected response data of the read. The QMaster checks that the result of the read is the specified data.

MaskWhen a mask value is present with the data in a read, readex, or xread command, only the data bits set to one in the mask field are used to test the read response data. For example:

read 0x4 0x3 (0x1)

has a data field of 3 and a mask of 1. This mask means that only the right-most bit is checked when the result of the read is known.

Macro StatementsMacro statements result in the issuing of one or more basic commands reducing the need to specify long sequences of commands such as for burst reads and writes.

Macro statements, except for burst write random and burst write numeric, employ the format:

[cycle:] [tid[/cid] macro_cmd [as/]address [count] [(be)] [data [mask]]

Burst FillThis set of macro statements perform a block of write transfers starting at the specified address using the designated data.

bfill [as/]address count datacfill [as/]address count datanfill [as/]address count data


When this statement is processed it is converted into a number of individual xwrite commands. The address parameter specifies the starting address of the burst and must be aligned with the OCP data width. The parameter count determines the number of xwrite commands needed and the parameter data is the data to be written.

• bfill results in an incrementing burst write so only the commands 6xwrite, 4xwrite, 2xwrite, and 0xwrite are generated.

• cfill results in a continuous burst write. It generates the commands 7xwrite and 0xwrite as these are the legal write commands for continuous burst.

• nfill results in a streaming burst write (no increment). It generates the commands 5xwrite and 0xwrite. Unlike bfill and cfill, the nfill macro does not cause the address to be incremented for every transfer so all writes are to the same address.

Burst Fill ZeroThe burst fill zero macro is like the burst fill macro, except that zero is used for the fill data.

bzero [as/]address countczero [as/]address countnzero [as/]address count

Burst Write RandomThese macros are like the burst fill macros except the data written is random.

bwrite [as/]address count rdata [seed]cwrite [as/]address count rdata [seed]nwrite [as/]address count rdata [seed]

The optional parameter seed is used as the seed to the random number generator. The string rdata is required.

For example:

bwrite 0x0 10 rdata

This statement creates a burst write of 10 words of random data starting at address 0.

Burst Write NumericBurst write numeric macros are like the burst fill macros except the data written is a numeric sequence starting at 0.

bwrite [as/]address count ndatacwrite [as/]address count ndatanwrite [as/]address count ndata

The first word is written with the value 0, the second with 1, etc. The string ndata is required at the end of the statement.


For example, the macro:

bwrite 0x0 2 ndata

results in a write of 0 at address 0, and a write of 1 at the next address (depending on the OCP data width).

Assuming a data width of 8 bytes, the preceding macro produces the following basic commands:

2xwrite 0x0 0x00xwrite 0x8 0x1

Burst ReadBurst read macros produce a block of read transfers starting at the specified address. When this macro is processed, it is converted into a number of indi-vidual xread commands. The parameter count determines the number of generated xread commands. Unlike basic read commands, expected data and mask values are not supported for these macros.

bread [as/]address count (byteenable)cread [as/]address countnread [as/]address count

• bread results in an incrementing burst read so only the commands 6xread, 4xread, 2xread, and 0xread are generated.

• cread results in a a continuous burst read. It generates the commands 7xread and 0xread as these are the legal read commands for continuous bursts.

• nread results in a streaming burst read (no increment). It generates the commands 5xread and 0xread. Because the nread macro does not cause the address to be incremented for every transfer, all reads are from the same address.

Explicit Width MacrosExplicit width macros are a way to write tests independently of the OCP data width. Explicit width macros duplicate the basic command but attach a data width number to the end of the command. The macro address must be aligned with the data width specified in the macro. If the explicit width is larger than the data width of the OCP, the macro produces more than one command. If byte enables are not enabled, then the explicit width must be at least as large as the OCP data width. If the explicit width is less than the OCP data width, the explicit width macro is converted into the regular command with the address and byte enable fields set so that data is correctly written or read.

For an OCP with a 16 bit data width, to write a single byte value of 0x7 to address 0x1, use the following statement:

write8 0x1 0x7

This macro is converted to the following basic command:


write 0x0 (2) 0x70

That is, a write to address 0x0 with byte enable set to 2 and data of 0x70.

If the explicit width is larger than the data width of the OCP, the macro produces more than one command.

Explicit width macros work with other macro statements and basic commands. nfill only works if explicit width > the data width of the OCP. For the same 16-bit OCP, the explicit width macro statement:

bfill8 0x1 4 0xfe

results in:

2xwrite 0x0 (2) 0xfe002xwrite 0x2 (3) 0xfefexwrite 0x4 (1) 0x00fe

Idle MacroThe Idle command can be issued multiple times using the idle macro.

idle count

The parameter count specifies the number of idle commands to issue. If count is not specified, it defaults to one. Each Idle command takes a single OCP cycle to complete.

Behavioral StatementsBehavioral statements allow you to set and observe sideband signals and control the execution of the STL trace.

SignalThe signal statement sets OCP sideband signals (MFlag) to specified values. The syntax is:

signal flags[=value[(mask)]]|[controlwr=value] [statusrd=value] [controlbusy=value][statusbusy=value]

The optional value parameter specifies the pattern to set on MFlag. If no value is given, all MFlag bits are set to 1. The mask parameter specifies which MFlag bits to modify. It defaults to affect all flags.

For example:

signal flags=0x2

sets MFlag[1] and clears all other MFlag bits. The statement:

signal flags=0x2(0x2)


sets MFlag[1] and leaves all other Mflag bits unchanged.

WaitThe wait statement waits until some conditions are true. There are two types of wait statements. The wait or statement waits until at least one of the conditions is true, while the wait and statement waits until all of the condi-tions are true. If and or or are not specified the default is wait and. The syntax is:

wait [and|or] [response=value] [flags=value[(mask)]][interrupt=value] [threadbusy=value[(mask)]][controlwr=value] [statusrd=value] [controlbusy=value][statusbusy=value]

A response condition waits for the response to an earlier statement. For example:

wait response=-3

waits for the response to the statement issued three statements before.

The flags condition waits for the OCP SFlag field to contain the specified value. A mask is optionally applied to look only at some specified bits (as described for the signal statement).

wait flags=0x0310

waits for Sflag bits 9, 8, and 4 to be set.

While other conditions are similar to the flags condition, each looks at a different signal field in the OCP interface as shown in Table 36.

Table 36 Behavioral Statement Conditions.

The controlwr and statusrd conditions can only be used for a core (for instance for QCMaster) while the controlbusy and statusbusy conditions can only be used for a system (for instance, for QSMaster).

Condition OCP signal Restrictions

flags SFlag

interrupt SInterrupt

threadbusy SThreadBusy

controlwr ControlWr core only

statusrd StatusRd core only

controlbusy ControlBusy system only

statusbusy StatusBusy system only


Control/Status StatementsThis set of statements is used to set and observe the OCP Control and Status signals.

The following statements are for cores (for instance, QCMaster):

readcontrol [data]writestatus data

The readcontrol statement reads the values on the OCP control field. The optional data parameter specifies expected data. The writestatus statement sends the specified data to the OCP status field.

The following statements are for a system (for instance, QSMaster):

writecontrol datareadstatus [data]

The writecontrol statement writes the specified data to the OCP control field. The readstatus statement reads the OCP status field. The optional data parameter specifies expected data.

Part II File Formats

10 Core RTL Configuration File

The required core RTL configuration file provides a description of the core and its interfaces. The name of the file needs to be <corename>_rtl.conf, where corename is the name of the module to be used. For example, the file defining a core named uart must be called uart_rtl.conf.

The core RTL configuration file is written using standard Tcl syntax. Syntax is described using the following conventions:

[ ] optional construct| or, alternate constructs* zero or more repetitions+ one or more repetitions<> enclose names of syntactic units() are used for grouping{ } are part of the format and are required

SyntaxThe syntax for the core RTL configuration file is:

version <version_string>module <core_name> {<core_stmt>*}

core_name is the name of the core being described and:

<core_stmt>: core_language verilog|vhdl | icon <file_name>| core_id <vendor_code> <core_code> <revision_code> [<comment>]| interface <interface_name> bundle <bundle_name> [{<interface_body>*}]| addr_region <name> {<addr_region_body>*}


ComponentsThis section describes the core RTL configuration file components.

Version StatementThe version statement identifies the version of the core RTL configuration file format. The version string consists of major and minor version numbers separated by a period. The current version of the file is 2.1.

Core_language StatementThis construct specifies the core description language and uses the syntax:

core_language verilog|vhdl

Icon StatementThis statement specifies the icon to display on a core. The syntax is:

icon <file_name>

file_name is the name of the graphic file, without any directory names. Store the file in the design directory of the core. For example:

icon "myCore.ppm"

The supported graphic formats are GIF, PPM, and PGM. Graphics should be no larger than 80x80 pixels. Since the text used for the core is white, use a dark background for your icon, otherwise it will be difficult to read.

Core_id StatementThe core_id statement provides identifying information to the tools about the core. This information is required. Syntax of the core_id statement is:

core_id <vendor_code> <core_code> <revision_code> [<comment>]

where:

vendor_code An OCP/IP-assigned vendor code that uniquely identifies the core developer. OCP/IP maintains a registry of assigned vendor codes. The allowed range is 0x0000 - 0xFFFF.

core_code A developer-assigned core code that (in combination with the vendor code) uniquely identifies the core. OCP/IP provides suggested values for common cores. Refer to “Defined Core Code Values”. The allowed range is 0x000 - 0xFFF.

revision_code A developer-assigned revision code that can provide core revision information. The allowed range is 0x0 - 0xF.

comment An optional Tcl string that provides a short description of the core.

Core RTL Configuration File 99

Defined Core Code Values0x000 - 0x7FF: Pre-defined 0x000 - 0x0FF: Memory

Sum values from following choices: ROM:

0x0: None0x1: ROM/EPROM0x2: Flash (writable)0x3: Reserved

SRAM:0x0: None0x4: Non-pipelined SRAM0x8: Pipelined SRAM0xC: Reserved

DRAM:0x00: None0x10: DRAM (trad., page mode, EDO, etc.)0x20: SDRAM (all flavors)0x30: RDRAM (all flavors)0x40: Several0x50: Reserved0x60: Reserved0x70: Reserved

Built-in DMA:0x00: No0x80: Yes

Values from 0x000 - 0x0FF are defined/reservedExample: Memory controller supporting only SDRAM & Flash would have <cc> = 0x2 + 0x20 = 0x022

0x100 - 0x1FF: General-purpose processorsSum values from following choices plus offset 0x100: Word size:

0x0: 8-bit0x1: 16-bit0x2: 32-bit0x3: 64-bit0x4 - 0x7: Reserved

Embedded cache:0x0: No cache0x8: Cache (Instruction, Data, combined, or both)

Processor Type:0x00: CPU0x10: DSP0x20: Hybrid0x30: Reserved

Only values from 0x100 - 0x13F are defined/reservedExample: 32-bit CPU with embedded cache would have <cc> = 0x100 + 0x2 + 0x8 + 0x00 = 0x10A


0x200 - 0x2FF: BridgesSum values from following choices plus offset 0x200: Domain:

0x00 - 0x7F: Computing0x00 - 0x3F: PC’s0x00: ISA (inc. EISA)0x01 - 0x0F: Reserved0x10: PCI (33MHz/32b)0x11: PCI (66MHz/32b)0x12: PCI (33MHz/64b)0x13: PCI (66MHz/64b)0x14 - 0x1F: AGP, etc.0x40 - 0x7F: Reserved

0x80 - 0xBF: Telecom0xA0 - 0xAF: ATM0xA0: Utopia Level 10xA1: Utopia Level 2...

0xC0 - 0xFF: Datacom

0x300 - 0x3FF: Reserved

0x400 - 0x5FF: Other processors(enumerate types: MPEG audio, MPEG video, 2D Graphics, 3D Graphics, packet, cell, QAM, Vitterbi, Huffman, QPSK, etc.)

0x600 - 0x7FF: I/O(enumerate types: Serial UART, Parallel, keyboard, mouse, gameport, USB, 1394, Ethernet 10/100/1000, ATM PHY, NTSC, audio in/out, A/D, D/A, I2C, PCI, AGP, ISA, etc.)

0x800 - 0xFFF: Vendor-defined(explicitly left up to vendor)

Interface StatementThe interface statement defines and names the interfaces of a core. The inter-face name is required so that cores with multiple interfaces can specify to which interface a particular connection should be made. Syntax for the inter-face statement is:

interface <interface_name> bundle <bundle_name> [{<interface_body>*}]

The <bundle_name> must be a defined bundle such as OCP or a bundle spec-ified in an interface configuration file as described on page 115.


In the following example, an interface named xyz is defined as an OCP bundle.

interface "xyz" bundle ocp

<interface_body>: interface_type <type_name>| port <port_name> net <net_name> | prefix <name>| param <name> <value> | location (n|e|w|s|) <number>

Interface_type StatementThe interface_type statement defines characteristics of the bundle. Typically, the different types specify whether the core drives or receives a particular signal within the bundle. Syntax for the interface_type statement is:

interface_type <type_name>

The type_name must be a type defined in the bundle definition. If the bundle is OCP, the allowed types are: master, system_master, system_master_clkout, slave, system_slave, system_slave_clkout, and monitor. To define a type, specify it in the interface configuration file (described on page 115).

Port StatementUse the port statement to rename the ports corresponding to nets within the bundle. Syntax for the port statement is:

port <port_name> net <net_name>

All nets within the bundle must be enumerated. If any nets are left out, it is assumed that the port_name is the same as the net_name. The port name is formed by prepending the interface name and appending a port direction, _i or _o. For example tpMCmdi. Net_name is the signal name as defined in “Signals and Encoding” on page 11.

Prefix CommandThe prefix command lets you prepend a string to signal names defined in the bundle to generate module port names that appear on the chip interface. Syntax for the prefix command is:

prefix <name>

For example, the statement prefix “external” adds external to the front of all port names of that interface, taking the body of the name from the bundle or from a port statement.


Configurable Interfaces ParametersFor configurable interfaces, parameters specify configurations. All parame-ters must be specified, otherwise the tools assume that the unspecified parameters can still be configured at a later time. The syntax for setting a parameter is:

param <name> <value><value>: <number>

For example, an OCP might be configured to include an interrupt signal as follows.

param interrupt 1

Location StatementThe location statement provides a way for the core to indicate where to place this interface when drawing the core. The location is specified by indicating a compass direction of north(n), south(s), east(e), west(w) and a number. The number indicates a percentage from the top or left edge of the block. Syntax for the location statement is:

location (n|e|w|s) <number>

To place an interface on the bottom (south-side) in the middle (50% from the left edge) of the block, for example, use this definition:

location s 50

Address Region StatementThe address region statement specifies address regions within the complete address space of a core. It allows you to give a symbolic name to a region, and to specify its base, size, and behavior.

addr_region <name> {<addr_region_body>*}

where:

<addr_region_body>: addr_base <integer> | addr_size <integer> | addr_space <integer>

• The addr_base statement specifies the base address of the region being defined and is specified as an integer.

• The addr_size statement similarly specifies the size of the region.

• The addr_space statement specifies to which OCP address space the region belongs. If the addr_space statement is omitted, the region belongs to all address spaces.


Sample RTL Configuration FileThe format for a core RTL configuration file for a core is shown in Example 1.

Example 1 Sample flashctrl_rtl.conf File

# define the moduleversion 2.1

module flashctrl {core_id 0xBBBB 0x001 0x1 “Flash/Rom Controller”

# This core is written in VHDLcore_language vhdl

# Use the Vista iconicon “vista.ppm”

addr_region “FLASHCTRL0” {addr_base 0x0addr_size 0x100000}

# one of the interfaces is an OCP slave using the pre-defined OCP bundleinterface tp bundle ocp {

# this is a slave type ocp interfaceinterface_type slave

# this OCP is a basic interface with byteen support plus the SError# and Reset_n signalsparam reset 1param byteen 1param force_aligned 0param burst 0param datahandshake 0param threadid 0param respaccept 0param connid 0param interrupt 0param mthreadbusy 0param sthreadbusy 0param mflag 0param sflag 0param serror 1param control 0param controlwr 0param controlbusy 0param status 0param statusrd 0


param statusbusy 0param addr_wdth 32param data_wdth 64param scanport_wdth 0

prefix tp# since the signal names do not exactly match the signal# names within the bundle, they must be explicitly linkedport Reset_ni net Reset_n port Clk_i net Clk port TMCmd_i net MCmd port TMAddr_i net MAddr port TMBurst_i net MBurst port TMByteEn_i net MByteEn port TMData_i net MData port TCCmdAccept_o net SCmdAccept port TCResp_o net SResp port TCData_o net SData port TCError_o net SError

# stick this interface in the middle of the top of the modulelocation n 50

} # close interface tp defininition

# The other interface is to the flash device defined in an interface file#Define the interface for the Flash controlinterface emem bundle flash {

# the type here indicates direction and drive of the control signals interface_type controller

# since this module has direction indication on some of the signals# (’_o’,’_b’) and is missing assertion level indicators ’_n’ on# some of the signals, the names must again be directly linked to# the signal names within the bundle

port Addr_o net addr port Data_b net data port OE net oe_n port WE net we_n port RP net rp_n port WP net wp_n

# all of the signals on this port have the prefix ’emem_’ prefix "emem_"

# stick this interface in the middle of the bottom of the module location s 50


} # close interface emem defininition

} # close module definition

The flash bundle is defined in the following interface file.

bundle flash {#types of flash interfaces#controller: flash controller; flash: flash device itself.interface_types controller flashnet addr { #Address to the Flash device direction output input width 19}net data { #Read or Write Data direction inout inout width 16}net oe_n { # Output Enable, active low. direction output input}net we_n { # Write Enable, active low. direction output input}net rp_n { # Reset, active low. direction output input}net wp_n { # Write protect bit, Active low. direction output input}

}

11 Testbench RTL Configuration File

The testbench typically consists of a core and behavioral models. The testbench RTL configuration file uses the same format as the chip RTL config-uration file.

The testbench RTL configuration file is written using standard Tcl syntax and is described using the following conventions:

[ ] optional construct| or, alternate constructs* zero or more repetitions+ one or more repetitions{ } are part of the format and are required

The file contains the following elements:

version <version_string>chip <chip_name> { <chip_stmt>* }<chip_stmt>:

| connection <name> bundle <bundle_type> [{<connection_body>*}]| instance <inst_name> module <mod_name> [{<instance_body>*}]| interface <name> bundle <bundle_type> [{<interface_body>*}]

The version statement is generated by the tools to identify the version of the file format and should not be modified.


ConnectionsThe components of a chip are joined together using connections. A connection statement instantiates a bundle, which is a group of signals. Bundles have a type that describes the bundle. For example, the OCP is a bundle consisting of the signals of the OCP. Bundles can have optional characteristics that refine the description.

OCP is a bundle type that is pre-defined. Cores that have non-OCP interfaces need to define a bundle type that describes that interface. See page 101 for a description of how bundles are defined and for the options available to OCP bundles.

A bundle requires a name so that it can be referenced from other parts of the file to make a connection. The syntax is:

connection <name> bundle <bundle_type> [{<connection_body>*}]<connection_body>: <param> | <location>

Param StatementA param statement configures a component. The syntax is:

param <param_name> <param_value><param_value>: <number>

In the following example, an OCP bundle is configured to be 64-bits wide and to contain the burst option.

connection ocp0 bundle ocp { param data_wdth 64param burst 1

}

Location StatementSpecifies the location of a connection, interface, and instance in the design. This is where these graphical objects are displayed in the design view. Specified as an (x, y) coordinate pair for instances and connections, or anchor direction (north, east, west, south) and offset for interfaces. It is recommended that you change these settings using the GUI and not the text editor. The syntax is:

location (n|e|w|s| <number>) <number>

Connection ExampleThe following example shows a connection containing burst and interrupt options:

connection ocp1 bundle ocp {

Testbench RTL Configuration File 109

param data_wdth 16param burst 1param interrupt 1

}

InstancesThe instance statement is used to instantiate a component and contains the following elements:

instance <inst_name> module <mod_name> [{ <instance_body>*}]

An instance name identifies a particular component. The module name indicates the kind of component that is being instantiated. The following example instantiates a QCMaster model, qcmaster.

instance qcmaster0 module qcmaster

The instance body describes a component by using param statements to configure the features. The following example shows the elements and syntax for an instance body.

<instance_body>: | param <name> <value>| location <number> <number>| interface <name> connection <name> [{<interface_body>*}]

Param StatementA param statement configures an entity. The syntax is:



connection ocp0 bundle ocp { param data_wdth 64param burst 1

}

Location StatementSpecifies the location of a connection, interface, and instance in the design. This is where these graphical objects are displayed in the design view. Specified as an (x, y) coordinate pair for instances and connections, or anchor direction (north, east, west, south) and offset for interfaces. It is recommended that you change these settings using the GUI and not the text editor. The syntax is:


location (n|e|w|s| <number>) <number>

Interface StatementThe interface statement within an instance body makes connections to a particular interface on a component. The interface being connected to is the interface name as defined by the module, typically in the core’s rtl.conf file. The syntax of an interface statement within an instance is:

interface <name> connection <name> [{<interface_body>*}]

The bundle is specified using the connection name. The optional body of an interface further describes the core instance’s interface and has the following syntax:

<interface_body>: | param <param_name> <param_value>| location <number> <number>

The following code is an example of an interface statement:

interface ip connection ocp0 {}

Chip InterfacesAn interface statement indicates that the signals in the bundle are external to the chip. The syntax is:

interface <interface_name> bundle <bundle_name> [{<interface_body>*}]<interface_body>:

| param <name> <param_value>| location (n|e|w|s| <number>) <number>| port <port_name> net <net_name> | interface_type <intf_type_name> | prefix <name>

Param StatementA param statement configures the interface. The syntax is:



interface ocp0 bundle ocp {


param data_wdth 64param burst 1

}

Location StatementSpecifies the location of a connection, interface, and instance in the design. This is where these graphical objects are displayed in the design view. Specified as an (x, y) coordinate pair for instances and connections, or anchor direction (north, east, west, south) and offset for interfaces. It is recommended that you change these settings using the GUI and not the text editor.

Port StatementThe port statement allows you to rename the nets within a bundle. All nets within the bundle should be enumerated, if any are left out, it is assumed that the <port_name> and the <net_name> are the same. The syntax of a port statement is:

port <port_name> net <net_name>

The following code provides examples of port statements:

port "Clock" net "Clk"port "Command" net "MCmd"port "Address" net "MAddr"port "WriteData" net "MData"port "Command" net "MCmd"port "Accept" net "SCmdAccept"port "Resp" net "SResp"port "ReadData" net "SData"

Interface_type StatementUse the interface_type statement to define the type of interface that is instan-tiated. The syntax of an interface_type statement is:

interface_type <intf_type_name>

For example:

interface_type master

Prefix StatementThe prefix statement allows you to prepend a string to signal names that appear on the chip interface. The syntax is:

prefix <name>


For example:

prefix "external"

Syntax SpecificationThe syntax for an entire chip RTL configuration file is shown below. A # symbol marks the text as a comment until the next new line.

version <value>chip <chip_name> { <chip_stmt>* }

<chip_stmt>:| connection <connection_name> bundle <bundle_name>

[{<connection_body>*}]| instance <inst_name> module <module_name> [{<inst_body>*}]| interface <interface_name> bundle <bundle_name>

[{<interface_body>*}]

<connection_body>: <param> | <location>

<inst_body>: | param <param_name> <param_value>| location <number> <number>| interface <name> connection <name> [{<interface_body>*}]

<interface_body>: | param <name> <value>| location n|e|w|s| <number> <number>| port <port_name> net <net_name> Chip interface only| interface_type <name> Chip interface only| prefix <name> Chip interface only

Sample Chip RTL Configuration FileThe sample chip RTL configuration file is shown with the defaults stripped out.

version 2.1chip "testbench" { interface "mii_" bundle "testbench_mii" { interface_type "controller" location 310 210 } interface "ip_" bundle "ocp" { interface_type "master"


location 280 380 param byteen 1 param burst 1 param data_wdth 32 } interface "tp_" bundle "ocp" { interface_type "slave" location 335 380 param byteen 1 param burst 1 param sflag 1 param addr_wdth 16 param data_wdth 32 } instance "testbench0" module testbench { location 280 255 interface "ip" connection "ip_" { location s 13 } interface "tp" connection "tp_" { location s 81 } interface "mii" connection "mii_" { location n 50 } } instance "testbench_ip" module ocpmon { param watch_enable 0 param wgl_slave 0 location 285 353 interface "ip" connection "ip_" { } } instance "testbench_tp" module ocpmon { param watch_enable 0 location 340 353 interface "ip" connection "tp_" { } }}

12 Interface Configuration File

If you are using an interface other than OCP, the interface configuration file is required. The file describes a group of signals, called a bundle.

The interface configuration file is written using standard Tcl syntax. Syntax is described using the following conventions:

[ ] optional construct| or, alternate constructs* zero or more repetitions+ one or more repetitions<> enclose names of syntactic units() are used for grouping{ } are part of the format and are required

Name the file <bundle-name>_intfc.conf where bundle-name is the name given to the bundle that is being defined in the file.

The syntax of the interface configuration file is:

version <version_string>bundle <bundle_name> {<bundle_stmt>+}

where:

<bundle_stmt>: interface_types <interface_type-name>+| net <net_name> {<net_stmt>*}

<net_stmt>: direction (input|output|inout)+| width <number-of-bits>| vhdl_type <type-string>


versionThe version statement identifies the version of the interface configuration file format. The version string consists of major and minor version numbers separated by a decimal, for example 2.1.

bundle This statement is required and indicates that a bundle is being defined instead of a core or a chip. Make the bundle-name the same name as the one used in the file name.

interface_typesThe interface_types statement lists the legal values for the interface types listed in Table 37. Interface types are used by the toolset in conjunction with the direction statement to determine whether an interface uses a net as an input or output signal. This statement is required and must have at least one type defined.

Table 37 Interface Types

netThe net statement defines the signals that comprise the bundle. There should be one net statement for each signal that is part of the bundle. A net can also represent a bus of signals. In this case the net width is specified using the width statement. If no width statement is provided, the

��

Master System_slave System_slave_clkoutSlave*

*Clk and Reset_n signals cannot be enabled or conflicting control, status or test sig-nals.

MasterSystem_master System_master_clkout

Slave System_master System_master_clkoutMaster*

SlaveSystem_slave System_slave_clkout

System_master SlaveSystem_slave*System_slave_clkout*

MasterSystem_master System_master_clkout

System_master_clkout SlaveSystem_slave*

MasterSystem_master Clkout type

System_slave MasterSystem_master*System_master_clkout*

SlaveSystem_slave System_slave_clkout

System_slave_clkout MasterSystem_master*

SlaveSystem_slave Clkout type

Monitor Any except monitor Monitor

Interface Configuration File 117

net width defaults to one. A bundle is required to contain at least one net. The net-name field is the same as the one used in the net-name field of the port statements in the core rtl and chip rtl configuration files.

directionThe direction statement indicates whether the net is an input, output, or inout. This field is required and must have as many direction-values as there are interface types. The order of the values must duplicate the order of the interface types in the interface_types statement. The legal values are input, output, and inout.

By default VHDL signals and ports are assumed to be std_logic and std_logic_vector, but if you have ports on a core that are of a different type, the vhdl_type command can be used on a net. This type will be used only when soccomp is run with the design_top=vhdl option to produce a VHDL top-level netlist.

The following example defines an SRAM interface. The bundle being defined is called sram16.

bundle "sram16" {

# Two interface types are defined, one is labeled # "controller" and the other is labeled "memory" interface_types controller memory

# A net named Address is defined to be part of this bundle. net "Address" { # The direction of the "Address" net is defined to be # "output" for interfaces of type "controller" and "input" # for interfaces of type "memory". direction output input

# The width statement indicates that there are 14 bits in # the "Address" net. width 14 } net "WData" { direction output input width 16 } net "RData" { # The direction of the "RData" net is defined to be # "input" for bundle of type "controller" and "output" for # bundles of type "memory". direction input output width 16 } net "We_n" { direction output input }


net "Oe_n" { direction output input }

# close the bundle}

13 Chip Synthesis Configuration File

The chip synthesis configuration file defines technology specific parameters and allows overrides of the default timing values specified for the IP blocks used in the design. The IP block constraints are defined in the core synthesis configuration files, which are described in Chapter 14 “Core Synthesis Con-figuration File” on page 141.

CoreCreator (see the CoreCreator Guide) provides a constraints editor that allows you to view the default settings and modify them on an instance by instance basis. The results of any edits are stored in the chip synthesis con-figuration file. You can create a chip synthesis configuration file using the template generated by the CoreCreator menu selection File->Save Synthe-sis Configuration.


Configuration File SectionsThe chip synthesis configuration file must contain version, clock, and tech-nology information. The file can also contain overrides of any instances of the port constraints specified in the core synthesis configuration file described in Chapter 14 “Core Synthesis Configuration File” on page 141. The sections consist of:

VersionSpecify the current version of the synthesis configuration file format. The current version is 1.1.

Technology To make timing constraints portable across a wide variety of processes and synthesis libraries, store the constraints in a technology-independent format. The technology section provides a definition of the technology variables.

Chip Define clock attributes to provide details about clocks brought into each design. You can also provide timing values for chip ports. The chip section also defines which technology section is used.

Instance Override many of the settings described in the core synthesis configuration file.

VersionThe version of synthesis configuration file is required. Specify the version with the version command, for example: version 1.1.

Technology Section The synthesis configuration files use values called technology variables. The values of these variables must be supplied so that the underlying configura-tion files can be evaluated.

To help you determine appropriate settings for these variables, a program has been developed, the Technology Compiler (techcomp). The Technology Com-piler extracts as much of the information as possible from a cell library. Details on running the Technology Compiler are provided in the Man Pages or the CoreCreator Guide.

The following set of descriptions provide details on the technology variables. (TC) identifies values that can be derived using the Technology Compiler from a specific library.

capacitancescaleDefault units of capacitance in the technology files are assumed to be in picofarads. This variable allows constraints that need to be specified in li-

Chip Synthesis Configuration File 121

brary units access to the correct multiplier for conversion in the synthesis library being used. Most libraries are specified in picofarads so this value is typically 1.0. (TC)

For example:

param capacitancescale .001

A capacitancescale of .001 would mean that the library units are in femto-Farads.

defaultc2qtimeThe clock-to-output time is the worst case timing value from a register or input port to an output port. The default value is assigned to any output port that is not specifically constrained. It should not be used in a core constraint file as it does not show core capabilities. The Technology Com-piler provides a default of 1/8 of a clock period. This particular value is not derived but is a recommended synthesis guideline.

For example:

param defaultc2qtime {[expr $clockperiod * .125]} param defaultc2qtime {[expr $timescale * 1000]}

Constant values are specified in nanoseconds. For consistency, use ex-pressions that can be interpreted in nanoseconds.

defaultc2qtimeminThe minimum clock-to-output time is the best-case timing value from a register or input port to the output port. The default value is assigned to any output port that is not specifically constrained. It should not be used in a core constraint file as it does not show core capabilities. The Technol-ogy Compiler provides a default of 0, the most conservative value. This particular value is not derived but is a recommended synthesis guideline.

For example:

param defaultc2qtimemin {[expr $clockperiod * .01]} param defaultc2qtimemin {[expr $timescale * 100]}


defaultcriticalrangeThe critical range value specifies the paths to be worked on by the synthe-sis tool during optimization. Typically, the tool will work on the most crit-ical paths optimizing them to meet timing requirements and then proceed to the next most critical path. By specifying a critical range, it will work on all paths from the most critical to those within the specified value. (TC)

A larger value takes longer for synthesis to run. A default value of 10% of the clock period is provided by the Technology Compiler. This value is not derived but is a recommended synthesis guideline described in Synopsys documentation.

For example:


param defaultcriticalrange {[expr $clockperiod * .1]} param defaultcriticalrange {[expr $timescale * 1000]}


defaultfalldelaymindefaultfalldelaymax

Default values to use for the best/worst case clock fall time. This is the time it takes from the source of the clock to reach the shortest/furthest endpoint of the clock tree (falling edge on the endpoint). These value de-pend on the clock tree layout methodology being used and cannot be de-rived or defaulted by the Technology Compiler. The values are set by those responsible for clock tree layout.

For example:

param defaultfalldelaymax {[expr $timescale * 1000]}


defaultfalltime See defaultrisetime

defaultfanoutloadThis variable specifies the value of one fanout in the synthesis library fanout units. It is used to limit the fanout of input ports of a core or agent. This is done using the maxfanout keyword for the port and specifying it in terms of the number of defaultfanoutloads. (TC)

For example:

param defaultfanoutload 1

defaultholdtimeThe default hold time is the hold time value from an input port to a regis-ter or an output port. The default is assigned to any input port that is not specifically constrained. The Technology Compiler provides a default of 0, the most conservative value. This value is not derived but is a recom-mended synthesis guideline.

For example:

param defaultholdtime {[expr $clockperiod * .01]} param defaultholdtime {[expr $timescale * 100]}


defaultloadcellpinName of the load library/cell/pin that represents a typical gate that would be on the fanout for a net. This value is specified to the synthesis tool as the gate to use in load calculations for output ports of a module. (TC)


Values must be a string that specifies the logical name of the synthesis library, the cell from the library, and the pin from which the load calcula-tion is derived. The pin is optional.

For example:

param defaultloadcellpin "pt25u/nand2/I1"

defaultloadsNumber of defaultloadcellpins that a net would drive. This value will be specified to the synthesis tool as the number of loads to use in calcula-tions for output ports of a module. The Technology Compiler default is 4. This value is not derived but is a recommended synthesis guideline.

For example:

param defaultloads 4

defaultminusuncertaintyDefault value to use for the worst case clock skew between two endpoints of a clock network when checking setup time. This value is dependent on the clock tree layout methodology being used and cannot be derived or de-faulted by the Technology Compiler. The value is set by those responsible for clock tree layout.

For example:

param defaultminusuncertainty {[expr $timescale * 500]}


defaultplusuncertaintyDefault value to use for the best case (using best case delay) clock skew between two endpoints of a clock network when checking hold time. This value is dependent on the clock tree layout methodology being used and cannot be derived or defaulted by the Technology Compiler. The value is set by those responsible for clock tree layout.

For example:

param defaultplusuncertainty {[expr $timescale * 500]}


defaultrisedelaymindefaultrisedelaymax

Default values to use for the best/worst case clock rise time. This is the time it takes from the source of the clock to reach the shortest/furthest endpoint of the clock tree (rising edge on the endpoint). These values are dependent on the clock tree layout methodology being used and cannot be derived or defaulted by the Technology Compiler. The values are set by those responsible for clock tree layout.

For example:


param defaultrisedelaymax {[expr $timescale * 1000]}


defaultrisetimedefaultfalltime

Default rise/fall time to use for a clock waveform. Typically rise time is 0 and fall time is clockperiod/2 so this is what the Technology Compiler pro-duces. The values or expressions specified for this variable define when the clock first rises and first falls during the clock period. More complex waveform specifications are currently not supported. If required, the re-sulting constraints file for the block being synthesized must be edited to supply the correct waveform.

For example:

param defaultrisetime 0param defaultfalltime {[expr $clockperiod / 2.0]}


defaultsetuptimeThe default setup specifies the setup time that is assigned to any input port that is not specifically constrained. Use a worst-case number to end up with a conservative design. Do not use this variable in a core constraint file as it does not show core capabilities. The Technology Compiler pro-vides a default of 3/8 of a clock period. This value is not derived but is a recommended synthesis guideline.

For example:

param defaultsetuptime {[expr $clockperiod * .375]} param defaultsetuptime {[expr $timescale * 3000]}


gatedelaygatedelaymin

The maximum and minimum delay of a typically loaded gate in nanosec-onds. Some cores may have setup/c2q times specified as the number of gate delays instead of as a percentage of the clock period although it is not the preferred unit. (TC)

For example:

param gatedelay {[expr $timescale * 200]}



gatesizeSpecifies the size of a standard two input NAND gate (normally accepted as a size of one gate) in the area units of the technology library. This value can be used for conversion between the number of gates and area. (TC)

For example:

param gatesize 9.7

This would mean that the size of a two input NAND gate in the current technology is 9.7 cell units.

highdrivegatepinmediumdrivegatepinlowdrivegatepin

Name of the driving library/cell/pin from the current library that is capa-ble of driving a large, average, or small load. This variable is used to spec-ify the driving cell of an input port to a core.

• Use highdrivegatepin for a large buffer or inverter that is capable of handling the largest loads that are anticipated in a design. This is typ-ically used on cells driving signals that fan out to a large number of modules in the design.

• Use mediumdrivegatepin for a gate that could drive the defaultloads number of loads for a typical size module in the design. This is the default used when generating constraint files for synthesis.

• Use lowdrivegatepin to specify drivers for connections that are meant to be close together and require the fastest possible timing or lowest power.

Values must be a string that specifies the logical name of the synthesis library, the cell from the library, and the output pin that will be driving an input to the core. The pin is optional. (TC)

For example:

param highdrivegatepin "pt25u/buf10/O"param mediumdrivegatepin "pt25u/buf1/O"param lowdrivegatepin "pt25u/buflow/O"

longnetdelaymediumnetdelayshortnetdelay

Replaces capacitance/resistance as a way to specify expected delays caused by interconnect. These values are referenced by the core synthesis constraints files in their wireloaddelay expressions. If specified, the result-ing values get added to the worst case clock-to-output times of the ports to take into account the anticipated net delays of connections to the ports. Cores should use the resistance and capacitance settings to ensure great-er accuracy when calculating the delay. (TC)

For example:

param longnetdelay {[expr $clockperiod * .25]}


param longnetdelay {[expr $timescale * 5000]}


longnetrcresistancelongnetrccapacitancemediumnetrcresistancemediumnetrccapacitanceshortnetrcresistanceshortnetrccapacitance

This is the recommended way to specify expected delays caused by inter-connect. Specify values to use for resistance/capacitance of nets of these types. Both resistance and capacitance should be specified if available.

• Use the longnet values to specify the resistance and capacitance expected on the longest nets in the design.

• Use the mediumnet values to specify nets that are typical. These are the default.

• Use the shortnet values to specify nets that are expected for the clos-est/fastest connections in the design.

If constraints are specified using these values they will show up as addi-tional loads and resistances on output ports of a module. (TC)

For example:

param longnetrcresistance {[expr $resistancescale * .09]} param longnerccapacitance {[expr $capacitancescale *.12]}

Constant values are specified in picofarads or kOhms. For consistency, use expressions that can be interpreted in picofarads or kOhms.

lowdrivegatepin See highdrivegatepin

maxoperatingconditionsminoperatingconditions

Operating conditions specify the appropriate scaling or tables to use when calculating timing values during the synthesis process. The maxoperat-ingconditions variable should match the string used in the synthesis li-brary for the worst case timing condition. The minoperatingconditions variable should match the string used in the synthesis library for the best case timing condition. If neither variable is specified, synthesis will be run with the library's default operating condition. (TC)

For example

param maxoperatingconditions "slow"param minoperatingconditions "fast"

mediumnetdelay See longnetdelaymediumnetrcresistance See longnetrcresistancemediumnetrccapacitance See longnetrcresistancemediumdrivegatepin See highdrivegatepin


resistancescale Default units of resistance in the technology files are assumed to be in kOhms. This variable allows constraints that need to be specified in library units access to the correct multiplier for conversion in whatever synthesis library is being used.

Most libraries are specified in kOhms so this value is typically 1.0. (TC)

For example:

param resistancescale .001

A resistancescale of .001 would mean that the library units are in Ohms.

shortnetdelay See longnetdelayshortnetrcresistance See longnetrcresistanceshortnetrccapacitance See longnetrcresistance

technologyvalueSpecifies which timing values should be selected for the agent timing. The current choices are 15u, 18u, or 25u which correlate to .15, .18, and .25 micron respectively. These strings are used to form the name of the timing file that will be loaded when running socmap, SOCCreator, or CoreCre-ator. The default value is 18u. This value is not derived by the technology compiler but is a built-in default.

For example:

param technologyvalue "18u"

timescaleDefault units of time in the technology files are assumed to be in nanosec-onds. This variable allows constraints that need to be specified in library units access to the correct multiplier for conversion in whatever synthesis library is being used.

Most libraries are specified in nanoseconds so the value is typically 1.0. (TC)

For example:

param timescale .001

A timescale of .001 would mean that the library units are in picoseconds.

timingtabledefaultfactortimingtableglobalfactor

Not needed in CoreCreator environment. Provided for compatibility with other tools that support this format.

wireloadmodeThis variable specifies the mode of the synthesis tool for applying wire load models. This value is not derived by the technology compiler but is a built-in default. The modes are:


enclosed Calculates the wire capacitance of each net using the wire load model set on the smallest subdesign that completely encloses that net. To use the set_wire_load_selection_group and set_wire_load_min_block_size commands, you must specify this mode. Enclosed is the default.

top Calculates the wire capacitance of all nets using the wire load model set on the top-level design.

segmented Calculates the wire capacitance for each segment of a net that crosses hierarchical subdesigns. Calculations are based on the wire load mod-el set on the subdesign containing that segment. The total wire capac-itance of the net is equal to the sum of the wire capacitances of the segments.

For example:

param wireloadmode "enclosed"

Chip SectionThe chip section of the file allows you to define clock variables and specify which technology is being used.

Defining ClocksYou must specify details about the clocks that are being brought into each design. This information includes the clock period, rise/fall time, delay or latency, and clock skew. Clock periods can only be defined in the chip syn-thesis configuration file.

Clock VariablesThe variables that can be used to specify information about a clock are:

falldelayminfalldelaymax

Values to use for the best/worst case clock fall time. This is the time it takes from the source of the clock to reach the shortest/furthest endpoint of the clock tree (falling edge on the endpoint). The technology defaults of defaultfalldelaymin/defaultfalldelaymax are used. For recom-mended values, check with the designer of the clock tree layout. For ex-ample:

falldelaymax {[expr $timescale * 1000]}falldelaymax {$defaultfalldelaymax}



minusuncertaintyThe value to use for the worst case clock skew between two endpoints of a clock network when checking setup time. The technology default of de-faultminusuncertainty is used if this value is not specified. For recom-mended values, check with the designer of the clock tree layout. For ex-ample:

minusuncertainty {[expr $timescale * 500]}minusuncertainty {$defaultminusuncertainty}


periodThe period of the clock. The period should only be specified for the primary clocks, asynchronous clocks, or non-OCP core clocks. For example:

period {[expr $timescale * 10000]}


plusuncertaintyThe value to use for the best case (using best case delay) clock skew be-tween two endpoints of a clock network when checking hold time. The technology default of defaultplusuncertainty is used if this value is not specified. For recommended values, check with the designer of the clock tree layout. For example:

plusuncertainty {[expr $timescale * 500]}plusuncertainty {$defaultplusuncertainty}


risedelayminrisedelaymax

Values to use for the best/worst case clock rise time. This is the time it takes from the source of the clock to reach the shortest/furthest endpoint of the clock tree (rising edge on the endpoint). The technology defaults of defaultrisedelaymin/defaultrisedelaymax is used if this value is not specified. For recommended values, check with the designer of the clock tree. For example:

risedelaymax {[expr $timescale * 1000]}risedelaymax {$defaultrisedelaymax}


risetimefalltime

The rise/fall time to use for the clock waveform. Typically rise time is 0 and fall time is clockperiod/2. The technology defaults of defaultrise-time/defaultfalltime is used if this value is not specified. The values


or expressions specified for this variable define when the clock first rises and first falls during the clock period. More complex waveform specifica-tions are currently not supported. If required, the resulting constraints file for the block being synthesized must be edited to supply the correct waveform.

risetime 0falltime {[expr $clockperiod / 2.0]}


Instance SectionThe ports of the IP blocks all have default constraints defined in the core_syn configuration file. To override any of these on an instance by instance basis, use the instance section. You can also specify overrides for the max delay and false paths constraints.

Port Constraints VariablesThe variables that can be used to specify information about port constraints are:

c2qtimeThe c2q (clock to q or clock to output) time is the longest path using worst case timing from a starting point in the core (register or input port) to the output port. This includes the c2qtime of the register. To maintain port-ability, most cores specify this as a percentage of the fastest clock period used while synthesizing the core.

For example:

c2qtime {[expr $timescale * 3500]}c2qtime {[expr $clockperiod * 0.25]}


c2qtimeminThe c2q (clock to q or clock to output) time min is the shortest path using best case timing from a starting point in the core (register or input port) to the output port. Currently most cores just use the default from the technology section, defaultc2qtimemin.

For example:

c2qtimemin {[expr $timescale * 100]}c2qtimemin {$defaultc2qtimemin}Constant values are specified in nanoseconds. For consistency, use ex-pressions that can be interpreted in nanoseconds.


drivingcellpinThis variable describes which cell in the synthesis library is expected to be driving the input. To maintain portability set this variable to one of the technology values of high/medium/lowdrivegatepin.

Values are a string that specifies the logical name of the synthesis library, the cell from the library, and the pin that will be driving an input for the core. The pin is optional.

For example:

drivingcellpin {$mediumdrivegatepin}drivingcellpin "pt25u/nand2/O"

holdtimeThe hold time is the shortest path using best case timing from an input port to any endpoint in the core. Currently most cores just use the default from the technology section, defaultholdtime.

holdtime {[expr $timescale * 100]}holdtime {$defaultholdtime}


loadcellpinThe name of the load library/cell/pin that this output port is expected to drive. This value will be specified to the synthesis tool as the gate that it should use (along with the number of loads) in its load calculations for output ports of a module. For portability use the default.

Values are a string that specifies the logical name of the synthesis library, the cell from the library, and the pin that the load calculation is derived from. The pin is optional.

For example:

loadcellpin "pt25u/nand2/I1"loadcellpin {$defaultloadcellpin}

loadsNumber of loadcellpins that this output port is expected to drive. This val-ue is specified to the synthesis tool as the number of loads to use in its load calculations for output ports of a module. The typical setting is the technology value of defaultloads.

Values are assumed to be an expression that evaluates to an integer.

For example:

loads 5loads {$defaultloads}


maxfanout This keyword limits the fanout of an input port to a specific number of fanouts. To maintain portability the setting of this variable should be ex-pressed in terms of the technology variable defaultfanoutloadConstant values are specified in library units.

For example:

maxfanout {[expr $defaultfanoutload * 1]}

setuptimeThe longest path using worst case timing from an input port to any end-point in the core. To maintain portability, most cores specify this as a per-centage of the fastest clock period used during synthesis of the core.

For example:

setuptime {[expr $timescale * 2500]}setuptime {[expr $clockperiod * 0.25]}


wireloaddelayReplaces capacitance/resistance as a way to specify expected delays caused by the interconnect connected to an output. To maintain portabil-ity, set this variable to use one of the technology values of long/medium/shortnetdelay.

The resulting values get added to the worst case clock to output times of the ports to anticipate net delays of connections to these ports. To improve the accuracy of the delay calculation, cores should use the resistance and capacitance settings.

You cannot specify both wireloaddelay and wireloadresistance/ca-pacitance for the same port.

For example:

wireloaddelay {[expr $clockperiod * .25]} wireloaddelay {$mediumnetdelay}

Constant values are specified in library units. For consistency, use ex-pressions that can be interpreted in nanoseconds.

wireloadresistancewireloadcapacitance

Specify expected loading and resistance caused by the interconnect con-nected to an output. If available, specify both resistance and capacitance. To maintain portability the setting of this variable should use one of the technology values of long/medium/shortnetrcresistance/capaci-tance.

If these constraints are specified they show up as additional loads and re-sistances on output ports of a module. You cannot use both wireloaddelay and wireloadresistance/capacitance for the same port.


Specify constant values in expressions that result in kOhms for resistance and picofarads (pf) for capacitance. For example:

wireloadresistance {[expr $resistancescale * .09]} wireloadcapacitance {[expr $capacitancescale *.12]}wireloadresistance {$mediumnetrcresistance} wireloadcapacitance {$mediumnetrccapacitance}

SyntaxParameter values are specified using Tcl syntax. Observe the following syntax conventions:

• Enclose all “expr” statements within braces, { } to differentiate between expressions that are to be evaluated while the file is being parsed and those that are to be evaluated during synthesis constraint file generation.

• Although not required by Tcl, enclose strings within quotation marks, ““, to show that they are different than keywords.

• Specify keywords using lower case.

Expressions can use any of the technology or environment variables, and any of the following:

clockperiodThis variable should only be used in calculations of timing values for ports. When evaluating expressions that use $clockperiod, the program will determine which clock the port is relative to, determine its period (in nanoseconds), and apply that value to the equation. For example:

port "in" { setuptime {[expr $clockperiod * .5]}}

sbclockperiod This variable is set to the period of the main system clock typically referred to as the primary system clock. It is typically used when a value needs to be some multiple of the sbclock, such as for non-OCP clocks. For example:

clock "myClock" { period {[expr $sbclockperiod * 4]}}

The chip_syn.conf file can also use conditional settings of the parameters in the design as outlined by the following arrays. These variables are only used at the time the file is read into the tools.

paramThis array is indexed by the configuration parameters that can be found on a particular instance. Only use param for core_syn.conf files since it is only applicable to the instance being processed. For example:


if { $param("dma_fd") == 1 } { port "T12_ipReset_no" { c2qtime {[expr $clockperiod * 0.7]} }}

chipparamThis array is indexed by the configuration parameters that are defined at the chip level. These variables can be used in both the chip_syn.conf and core_syn.conf files as they are more global in nature than those specified by param. For example:

if { $chipparam("full") == 1 } { instance "bigcore" { port "in" { setuptime {[expr $clockperiod * 0.7]} } }}

interfaceparam This array is indexed by the interface name and the configuration param-eters that are on an interface. It should only be used for core_syn.conf files since it is only applicable to the interfaces on the instance being pro-cessed. In the following example the interface name is ip.

if { $interfaceparam("ip_respaccept") == 1 } { port "ipMRespAccept_o" { c2qtime {[expr $clockperiod * 21/25]} }}

Technology Variable SyntaxThere can be multiple technology sections in a chip synthesis configuration file. For the program to know which technology to use, specify the name in the chip section of the file with the usetechnology keyword. The syntax is:

chip "chip" {usetechnology <technology name>

}

A technology section is introduced using the technology keyword as in the fol-lowing example:

technology "pt25uLibrary" {param highdrivegatepin "pt25u/buf10/O"param defaultloadcellpin "pt25u/nand2/I1"

}


Each entry within the technology section is specified by the keyword param followed by the name of the variable and its setting. The following example shows a sample technology section of the chip synthesis configuration file:

technology "foo”param highdrivegatepin "foo/invtr_10x/x"param mediumdrivegatepin "foo/invtr_2x/x"param lowdrivegatepin "foo/invtr/x"param defaultloadcellpin "foo/invtr/i0"param defaultloads 4param longnetdelay 5param mediumnetdelay 3param shortnetdelay 1param longnetrcresistance 1param longnetrccapacitance 2param mediumnetrcresistance 0.5param mediumnetrccapacitance 1param shortnetrcresistance 0.1param shortnetrccapacitance 0.5param defaultsetuptime {[expr $clockperiod * .375]}param defaultholdtime 0param defaultc2qtime {[expr $clockperiod * .125]}param defaultc2qtimemin 0param timescale 1param capacitancescale 1param resistancescale 1param defaultminusuncertainty 0.5param defaultplusuncertainty 0.2param defaultrisetime 0.0param defaultfalltime {[expr $clockperiod / 2.0]}param defaultrisedelaymin 0.2param defaultrisedelaymax 1.0param defaultfalldelaymin 0.2param defaultfalldelaymax 1.0param defaultcriticalrange 1.0param gatedelay 0.33param gatedelaymin 0.29timingtabledefaultfactor 1.2timingtableglobalfactor 1.1

}


Chip Section SyntaxSpecify chip information using the following syntax:

chip <chipName> {clock <clockName> {

period <Value>risetime <Value>falltime <Value>plusuncertainty <Value>minusuncertainty <Value>risedelaymin <Value>risedelaymax <Value>falldelaymin <Value>falldelaymax <Value>

}usetechnology <technology name>

}

The clockName is the name of the top level port or signal associated with the clock. The technology name is the name of the technology section to be used with this chip.

At the start of the file create a description of all of the clocks in the design. For example:

chip "chip" {clock "sbClk_i" {

period 10.0}

}

In the preceding example there is only one clock, the primary clock and its period is 10 nanoseconds. The following example shows all values specified using either fixed values or technology variables.

chip “myChip” {clock “sbClk” {

period 10.0risetime {$defaultrisetime}falltime {$defaultfalltime}minusuncertainty 0.5plusuncertainty 0.3risedelaymax 1.2risedelaymin 0.4falldelaymax{$defaultfalldelaymax}falldelaymin{$defaultfalldelaymin

}}


Instance Section SyntaxSpecify an instance using the following syntax:

instance <instanceName> {port <portName> {

drivingcellpin <drivingCellName>setuptime <Value>holdtime <Value>maxfanout <Value>

}port <portName> {

loadcellpin <loadCellPinName>loads <Value>wireloadresistance <Value>wireloadcapacitance <Value>c2qtime <Value>c2qtimemin <Value>

}maxdelay {

delay <delayValue> fromport <portName> toport <portName>}falsepath {

fromport “myInPort1” toport “myOutPort1”}

}

For example:

instance “foo” {port "myPort" {

setuptime {[expr $clockperiod * 0.25]}}

}

In the example, port myPort has a setup time defined that is 25% of the clock period (for the clock associated with this port). When specifying a constraint with a value that must be evaluated because it is dependent on a value being defined, the use of {} is required. In this case, the clock period is not a static value and must be evaluated when the socmap program is run.


Sample Chip Synthesis Configuration FileThe following example shows a complete chip synthesis configuration file.

version 1.1technology "foo”

param highdrivegatepin "foo/invtr_10x/x"param mediumdrivegatepin "foo/invtr_2x/x"param lowdrivegatepin "foo/invtr/x"param defaultloadcellpin "foo/invtr/i0"param defaultloads 4param longnetdelay 5param mediumnetdelay 3param shortnetdelay 1param longnetrcresistance 1param longnetrccapacitance 2param mediumnetrcresistance 0.5param mediumnetrccapacitance 1param shortnetrcresistance 0.1param shortnetrccapacitance 0.5param defaultsetuptime {[expr $clockperiod * .375]}param defaultholdtime 0param defaultc2qtime {[expr $clockperiod * .125]}param defaultc2qtimemin 0param timescale 1param capacitancescale 1param lengthscale 1param resistancescale 1param defaultminusuncertainty 0.5param defaultplusuncertainty 0.2param defaultrisetime 0.0param defaultfalltime {[expr $clockperiod / 2.0]}param defaultrisedelaymin 0.2param defaultrisedelaymax 1.0param defaultfalldelaymin 0.2param defaultfalldelaymax 1.0param defaultcriticalrange 1.0param gatedelay 0.33param gatedelaymin 0.29timingtabledefaultfactor 1.2timingtableglobalfactor 1.1

}

chip "chip" {clock "sbClk" {

period 10plusuncertainty 0.3minusuncertainty 0.6risedelaymin 0.2risedelaymax 0.4


}usetechnology “foo”

}

instance "read_regs" {port "ipReset_ni" {setuptime 2}port "ipMCmd_i" {setuptime 2}port "ipMAddr_i" {setuptime 2}port "ipMWidth_i" {setuptime 2}port "ipMData_i" {setuptime 2}port "ipSCmdAccept_o" {c2qtime 2}port "ipSResp_o" {c2qtime 2}port "ipSData_o" {c2qtime 2}

maxdelay {

delay 2 fromport “MData_i” toport “SResp_o”

}falsepath {

fromport “MData_i” toport “SData_o”}

}

14 Core Synthesis Configuration File

Use the core synthesis configuration file to set timing constraints for ports in the core. The file consists of any of the constraint sections: port, max delay, and false path. If the core has additional non-OCP clocks, the file should contain their definitions.

To make your core description technology independent, use the technology variables defined in the chip synthesis configuration file. See Chapter 13 “Chip Synthesis Configuration File” on page 119 for a description. The tech-nology variables range from describing the default setup and clock-to-output times for a port to defining a high drive cell in the library.


Configuration File SectionsThe core synthesis configuration file contains the following sections:

VersionSpecifies the current version of the synthesis configuration file format. The current version is 1.1.

Clock Describes clocks brought into the core.

AreaDefines the area in gates of the core.

Port Defines the timing of IP block ports.

Max DelaySpecifies the delay between two ports on a combinational path.

False PathSpecifies that a path between input and output ports is logically impossible.

Syntax ConventionsObserve the following syntax conventions:

• Enclose all expr statements within braces, { } to differentiate between expressions that are to be evaluated while the file is being parsed and those that are to be evaluated during synthesis constraint file generation.

• Although not required by Tcl, enclose strings within quotation marks, ““, to show that they are different than keywords.

• Specify keywords using lower case.

Parameter values are specified using Tcl syntax. Expressions can use any of the technology or environment variables, and any of the following:

clockperiodThis variable should only be used in calculations of timing values for ports. When evaluating expressions that use $clockperiod, the program will determine which clock the port is relative to, determine its period (in nanoseconds), and apply that value to the equation. For example:

port "in" { setuptime {[expr $clockperiod * .5]}}

Core Synthesis Configuration File 143

sbclockperiod This variable is set to the period of the main system clock typically referred to as the SB clock. It is typically used when a value needs to be some mul-tiple of the sbclock, such as for non-OCP clocks. For example:

clock "myClock" { period {[expr $sbclockperiod * 4]}}

The chip_syn.conf file can also use conditional settings of the parameters in the design as outlined by the following arrays. These variables are only used at the time the file is read into the tools.

paramThis array is indexed by the configuration parameters that can be found on a particular instance. Only use param for core_syn.conf files since it is only applicable to the instance being processed. For example:

if { $param("dma_fd") == 1 } { port "T12_ipReset_no" { c2qtime {[expr $clockperiod * 0.7]} }}

chipparamThis array is indexed by the configuration parameters that are defined at the chip level. These variables can be used in both the chip_syn.conf and core_syn.conf files as they are more global in nature than those specified by param. For example:

if { $chipparam("full") == 1 } { instance "bigcore" { port "in" { setuptime {[expr $clockperiod * 0.7]} } }}

interfaceparam This array is indexed by the interface name and the configuration param-eters that are on an interface. It should only be used for core_syn.conf files since it is only applicable to the interfaces on the instance being pro-cessed. In the following example the interface name is ip.

if { $interfaceparam("ip_respaccept") == 1 } { port "ipMRespAccept_o" { c2qtime {[expr $clockperiod * 21/25]} }}


Version SectionThe version of the core synthesis configuration file is required. Specify the version with the version command, for example: version 1.1

Clock SectionIf you have non-OCP clocks for an IP block or want to specify the worst-casedelay of any clock used in the core, specify the names of the clocks in the core synthesis configuration file. Use the following syntax to specify the name of the clock and its worstcasedelay:

clock <clockName> {worstcasedelay <delay Value>

}

clockName refers to the name of the port that brings the clock into the core for the core synthesis configuration file. For example:

clock “myClock”

worstcasedelayThe worst case delay value is the longest path through the core or instance for a particular clock. The value is used to check that the core can meet the timing requirements of the current design. To help make this value more portable, you may want to use the technology variable gatedelay.

For example:

clock "myClock" { worstcasedelay {[10.5 * $gatedelay]}}

clock "otherClock" { worstcasedelay 5}

Constant values are specified in nanoseconds. For consistency, use expressions that can be interpreted in nanoseconds.

Area SectionThe area is the size in gates of the core or instance. By specifying the size in gates the area can be calculated based on the size of a typical two input nand gate in a particular synthesis library.

For example:

area {[expr 20500 / $gatesize]}area 5000


Constant values are specified in two input nand gate equivalents. For consis-tency, use expression that can be interpreted in gates.

Port Constraints SectionUse the port constraints section to specify the timing parameters. Input port information that can be specified includes the setup time, related clock (non-OCP ports), and driving cell. For output ports, the clock to output times, related clock (non-OCP ports), as well as the loading information needs to be supplied.

Port Constraint VariablesThe variables that can be used to specify information about port constraints are:

c2qtimeThe c2q (clock to q or clock to output) time is the longest path using worst case timing from a starting point in the core (register or input port) to the output port. This includes the c2qtime of the register. To maintain port-ability, most cores specify this as a percentage of the fastest clock period used while synthesizing the core.

For example:

c2qtime {[expr $timescale * 3500]}c2qtime {[expr $clockperiod * 0.25]}


c2qtimeminThe c2q (clock to q or clock to output) time min is the shortest path using best case timing from a starting point in the core (register or input port) to the output port. This includes the c2qtime of the register. Most cores use the default from the technology section, defaultc2qtimemin.

For example:

c2qtimemin {[expr $timescale * 100]}c2qtimemin {$defaultc2qtimemin}


clocknameThis is an optional field for all OCP ports and is a string specifying the associated clock portname. For input ports, input delays use this clock as the reference clock. For output ports, output delays use this clock as the reference clock.

For example:

clockname “myClock”


drivingcellpinThis variable describes which cell in the synthesis library is expected to be driving the input. To maintain portability set this variable to use one of the technology values of high/medium/lowdrivegatepin.

Values are a string that specifies the logical name of the synthesis library, the cell from the library, and the pin that will be driving an input for the core. The pin is optional.

For example:

drivingcellpin {$mediumdrivegatepin}drivingcellpin "pt25u/nand2/O"

holdtimeThe hold time is the shortest path using best case timing from an input port to any endpoint in the core. Most cores use the default from the tech-nology section, defaultholdtime.

holdtime {[expr $timescale * 100]}holdtime {$defaultholdtime}


loadcellpinThe name of the load library/cell/pin that this output port is expected to drive. The value is specified to the synthesis tool as the gate to use (along with the number of loads) in its load calculations for output ports of a module. For portability use the default.

Values are a string that specifies the logical name of the synthesis library, the cell from the library, and the pin that the load calculation is derived from. The pin is optional.

For example:

loadcellpin "pt25u/nand2/I1"loadcellpin {$defaultloadcellpin}

loadsThe number of loadcellpins that this output port is expected to drive. The value is communicated to the synthesis tool as the number of loads to use in load calculations for output ports of a module. The typical setting for this is the technology value of defaultloads.

Values are an expression that evaluates to an integer.

For example:

loads 5loads {$defaultloads}


maxfanout This keyword limits the fanout of an input port to a specified number of fanouts. To maintain portability set this variable in terms of the technology variable defaultfanoutload.Constant values are specified in library units.

For example:

maxfanout {[expr $defaultfanoutload * 1]}

setuptimeThe longest path using worst case timing from an input port to any end-point in the core. To maintain portability, most cores specify this as a per-centage of the fastest clock period used during synthesis of the core.

For example:

setuptime {[expr $timescale * 2500]}setuptime {[expr $clockperiod * 0.25]}


wireloaddelayReplaces capacitance/resistance as a way to specify expected delays caused by the interconnect connected to an output. To maintain portabil-ity set this variable to use a technology value of long/medium/shortnet-delay.

The resulting values get added to the worst case clock-to-output times of the ports to anticipate net delays of connections to these ports. To improve the accuracy of the delay calculation cores should use the resistance and capacitance settings.

You cannot specify both wireloaddelay and wireloadresistance/ca-pacitance for the same port.

For example:

wireloaddelay {[expr $clockperiod * .25]} wireloaddelay {$mediumnetdelay}


wireloadresistancewireloadcapacitance

Specify expected loading and resistance caused by the interconnect con-nected to an output. If available, specify both resistance and capacitance. To maintain portability set this variable to use one of the technology val-ues of long/medium/shortnetrcresistance/capacitance.

If these constraints are specified they show up as additional loads and re-sistances on output ports of a module. You cannot use both wireloaddelay and wireloadresistance/capacitance for the same port.


Specify constant values as expressions that result in kOhms for resis-tance and picofarads (pf) for capacitance.

For example:

wireloadresistance {[expr $resistancescale * .09]} wireloadcapacitance {[expr $capacitancescale * .12]}wireloadresistance {$mediumnetrcresistance} wireloadcapacitance {$mediumnetrccapacitance}

Input Port SyntaxFor input and inout ports (inout ports have both an input and an output defi-nition) use the following syntax:

port <portName> {clockname <clockName>drivingcellpin <drivingCellName>setuptime <Value>holdtime <Value>maxfanout <Value>

}

Examples In the following example, the clock is not specified since this is an OCP port and is known to be controlled by the OCP clock. If a clock were specified as something other than the OCP clock, an error would result.

port “MCmd_i” {drivingcellpin {$mediumdrivegatepin}setuptime {[expr $clockperiod * 0.2]}

}

In the following example, the setup time is required to be 2ns. Time constants are assumed to be in nanoseconds. Use the timescale variable to convert library units to nanoseconds.

port “MAddr_i” {drivingcellpin {$mediumdrivegatepin}setuptime 2

}

The following example shows how to associate a non OCP clock to a port. The example uses maxfanout to limit the fanout of myInPort to 1. If the logic for myInPort required it to fanout to more than one connection, the synthesis tool would add a buffer to satisfy the maxfanout requirement.

port “myInPort” {clockname “myClock”drivingcellpin {$mediumdrivegatepin}setuptime 2


maxfanout {[expr $defaultfanoutload * 1]}}

Output Port SyntaxFor output and inout ports (inout ports have both an input and an output definition) use the following syntax:

port <portName> {clockname <clockName>loadcellpin <loadCellPinName>loads <Value>wireloadresistance <Value>wireloadcapacitance <Value>wireloaddelay <Value>c2qtime <Value>c2qtimemin <Value>

}

You cannot specify both wireloaddelay and wireloadresistance/capac-itance for the same port.

Examples In the following example, the clock is not specified since this is an OCP port and is known to be controlled by the OCP clock.

port “SCmdaccept_o”loadcellpin {$defaultloadcellpin}loads {$defaultloads}wireloadresistance {$mediumnetrcresistance}wireloadcapacitance {$mediumnetrccapacitance}c2qtime {[expr $clockperiod * 0.2]}

}

In the following example, the clock to output time is required to be 2 ns. Time constants are assumed to be in nanoseconds. Use the timescale variable to convert library units to nanoseconds.

port “SResp_o”loadcellpin {$defaultloadcellpin}loads {$defaultloads}wireloadresistance {$mediumnetrcresistance}wireloadcapacitance {$mediumnetrccapacitance}c2qtime 2

}

The following example shows how to associate a clock to an output port.

port “myOutPort”clockname “myClock”


loadcellpin {$defaultloadcellpin}loads 10wireloaddelay {$longnetdelay}c2qtime {[expr $clockperiod * .2]}

}

InOut Port Exampleport “Signal_io”

drivingcellpin {$mediumdrivegatepin}setuptime {[expr $clockperiod * 0.2]}

}port “Signal_io”

loadcellpin {$defaultloadcellpin}loads {$defaultloads}wireloadresistance {$mediumnetrcresistance}wireloadresistance {$mediumnetrccapacitance}c2qtime {[expr $clockperiod * 0.2]}

}

Max Delay ConstraintsUsing the max delay constraints you can specify the delay between two ports on a combinational path. This is useful when synthesizing two communi-cating OCP interfaces. The syntax for maxdelay is:

maxdelay {delay <delayValue> fromport <portName> toport <portName>...

}

where: <delayValue> can be a constant or a Tcl expression.

In the following example, a maxdelay of 3 ns is specified for the combinational path between myInPort1 and myOutPort1. A maxdelay of 50% of the clockpe-riod is specified for the path between myInPort2 and myOutPort2. The braces around the expression delay evaluation until the expression is used by the mapping program.

maxdelay {delay 3 fromport “myInPort1” toport “myOutPort1delay {[expr $clockperiod *.5]} fromport “myInPort2” toport “myOutPort2”

}


False Path ConstraintsUsing the false path constraints you can specify that a path between certain input and output ports is logically impossible.

The syntax for falsepath is:

falsepath{fromport <portName> toport <portName>

.

.

.}

In the following example, a falsepath is set up between myInPort1 and myOutPort1 as well as myInPort2 and myOutPort2. This tells the synthesis tool that the path is not logically possible and so it will not try to optimize this path to meet timing.

falsepath {fromport “myInPort1” toport “myOutPort1”fromport “myInPort2” toport “myOutPort2”

}

Sample Core Synthesis Configuration File The following example shows a complete core synthesis configuration file.

version 1.1port “Reset_ni” {

drivingcellpin {$mediumgatedrivepin}setuptime {[expr $clockperiod * .5]}

}port “MCmd_i” {


}port “MAddr_i” {


}port “MWidth_i” {


}port “MData_i” {


}port “SCmdAccept_o” {

loadcellpin {$defaultloadcellpin}


loads {$defaultloads}wireloaddelay {$mediumnetdelay}c2qtime {[expr $clockperiod * .9]}

}port “SResp_o” {

loadcellpin {$defaultloadcellpin}loads {$defaultloads}wireloaddelay {$mediumnetdelay}c2qtime {[expr $clockperiod * .8]}

}port “SData_o” {

loadcellpin {$defaultloadcellpin}loads {$defaultloads}wireloaddelay {$mediumnetdelay}c2qtime {[expr $clockperiod * .8]}

}maxdelay {

delay 2 fromport “MData_i” toport “SResp_o”

}falsepath {

fromport “MData_i” toport “SData_o”}

15 Package File

The package file, written in Tcl format, contains information about the name of the core and the files that are to be packaged in an archive file. In the package file, specify the name of the core using the syntax:

set corename “<CORENAME>”

Identify files for inclusion using the following syntax:

set files(<FILETYPE>) "file file file"

where <FILETYPE> specifies the type of the file, and “file file file” are one or more filenames of that type to be included.

Supported <FILETYPE> values include the following (always in lowercase):

billofmaterials List of the files that belong to a core

chiprtlconf Chip RTL configuration file

chipsynconf Chip synthesis configuration file

corertlconf Core RTL configuration file

coresynconf Core synthesis configuration file

configurablertlconf RTL configuration file for configurable cores

configurablertl RTL for a configurable core

devicedriver Software to run on core

doc Documentation

interfaceconf Interface configuration file

method Test script


model ibis, spice, trace generator, etc.

report Reports about the core

scanscript Scan generation scripts

scanvector Scan vectors

synscript DC shell script to run synthesis

synshellscript Shell script to invoke synthesis program

test Test file

rtl RTL source file

wgl Wgl format test vector file

icon Core icon file

The following example shows a sample package file:

set corename “core”set files(billofmaterials) "core.pkg"set files(chiprtlconf) "core_rtl.conf"set files(chipsynconf) "core_syn.conf"set files(corertlconf) "synek/synek_rtl.conf"set files(coresynconf) "synek/synek_syn.conf"set files(devicedriver) "software/synek.asm"set files(doc) "myDocs/synekInstall.doc myDocs/synekDataSheet.doc"set files(interfaceconf) "myInterfaces/myBundle_intfc.conf"set files(method) "mytools/ocpanalyze mytools/ocpsimulate"set files(model) "myModels/synek.ibis myModels/synek.tgen"set files(report) "myReport/synek_syn.log myReport/synek_scantest.log"set files(scanvector) "scanTest/synek.vec"set files(scanscript) "scanTest/synek.scan"set files(synscript) "synek/synek.scr"set files(synshellscript) "synek/synek.sh"set files(test)"mytest/master/config/test1.S mytest/slave/io/iorw1.PMDL"set files(rtl) "synek/synek.v"set files(wgl) "scanTest/synek.wgl"set files(icon) "mips.gif"

Part III Guidelines

16 Developer’s Guidelines

This chapter collects examples and implementation tips to help you make effective use of the Open Core Protocol and does not provide any additional specification material.

Signal TimingThe Open Core Protocol data transfer model allows many different types of existing legacy IP cores to be bridged to the OCP without adding expensive glue logic structures that include address or data storage. As such, it is possible to draw many state machine diagrams that are compliant with the OCP protocol. This section describes some common state machine models that can be used with the OCP, together with guidance on the use of those models.

Two-way handshaking is the general principle of the dataflow signals in the OCP interface. A group of signals is asserted and must be held steady until the corresponding accept signal is asserted. This allows the receiver of a signal to force the sender to hold the signals steady until it has completely processed them. This principle produces implementations with fewer latches for temporary storage.

Request PhaseThe request phase begins when the master drives MCmd to a value other than Idle. When MCmd != Idle, MCmd is referred to as asserted. All of the other request phase outputs of the master must become valid during the same clock cycle as MCmd asserted, and be held steady until the request phase ends. The request phase ends when SCmdAccept is sampled asserted (true) by the rising edge of Clk. The slave can assert SCmdAccept in the same cycle that MCmd is asserted, or stay negated for several Clk cycles. The latter choice allows the slave to force the master to hold its request phase outputs until the slave can accomplish its access without latching address or data signals.


The slave designer chooses the delay between MCmd asserted and SCmdAccept asserted based on the desired area, timing, and throughput characteristics of the slave.

As the request phase does not begin until MCmd is asserted, SCmdAccept is a “don’t care” while MCmd is not asserted so SCmdAccept can be asserted before MCmd. This allows some area-sensitive, low frequency slaves to tie SCmdAccept asserted, as long as they can always complete their transfer responsibilities in the same cycle that MCmd is asserted. Since an MCmd value of Idle specifies the absence of a valid command, the master can assert MCmd independently of the current setting of SCmdAccept.

The highest throughput that can be achieved with the OCP is one data transfer per Clk cycle. High-throughput slaves can approach this rate by providing sufficient internal resources to end most request phases in the same Clk cycle that they start. This implies a combinational path from the master’s MCmd output into slave logic, then back out the slaves SCmdAccept output and back into a state machine in the master. If the master has addi-tional requests to present, it can start a new request phase on the next Clk cycle. Achieving such high throughput in high-frequency systems requires careful design including cycle time budgeting as described in “Level2 Timing” on page 174.

Response PhaseThe response phase begins when the slave drives SResp to a value other than NULL. When SResp != NULL, SResp is referred to as asserted. All of the other response phase outputs of the slave must become valid during the same Clk cycle as SResp asserted, and be held steady until the response phase ends. The response phase ends when MRespAccept is sampled asserted (true) by the rising edge of Clk; if MRespAccept is not configured into a particular OCP, MRespAccept is assumed to be always asserted (that is, the response phase always ends in the same cycle it begins). If present, the master can assert MRespAccept in the same cycle that MResp is asserted, or it may stay negated for several Clk cycles. The latter choice allows the master to force the slave to hold its response phase outputs so the master can finish the transfer without latching the data signals.

Since the response phase does not begin until SResp is asserted, MRespAc-cept is a “don’t care” while SResp is not asserted so MRespAccept can be asserted before SResp. Since an SResp value of NULL specifies the absence of a valid response, the slave can assert SResp independently of the current setting of MRespAccept.

In high-throughput systems, careful use of MRespAccept can result in signif-icant area savings. To maintain high throughput, systems traditionally introduce pipelining, where later requests begin before earlier requests have finished. Pipelining is particularly important to optimize Read accesses to main memory.

The OCP supports pipelining with its basic request/response protocol, since a master is free to start the second request phase as soon as the first has finished (before the first response phase, in many cases). However, without MRespAccept, the master must have sufficient storage resources to receive all

Developer’s Guidelines 159

of the data it has requested. This is not an issue for some masters, but can be expensive when the master is part of a bridge between subsystems such as computer buses. While the original system initiator may have enough storage, the intermediate bridge may not. If the slave has storage resources (or the ability to flow control data that it is requesting), then allowing the master to de-assert MRespAccept enables the system to operate at high throughput without duplicating worst-case storage requirements across the die.

Most simple or low-throughput slave IP cores need not implement MRespAc-cept. Misuse of MRespAccept makes the slave’s job more difficult, because it adds extra conditions (and states) to the slave’s logic.

Since the OCP is a point-to-point interface, Write commands can be consid-ered complete as soon as the data has been accepted by the slave (at the end of the request or datahandshake phases, depending on the configuration of the OCP). As a result, only Read commands require a response phase on the OCP. A common term for this type of write behavior is write posting.

Datahandshake PhaseThe datahandshake phase offers throughput advantages for high-perfor-mance subsystems (particularly memory). When the datahandshake phase is not present in a configured OCP, MData becomes a request phase signal.

The datahandshake phase begins when the master asserts MDataValid. The other datahandshake phase outputs of the master must become valid during the same Clk cycle while MDataValid is asserted, and be held steady until the datahandshake phase ends. The datahandshake phase ends when SDataAccept is sampled asserted (true) by the rising edge of Clk. The slave can assert SDataAccept in the same cycle that MDataValid is asserted, or it can stay negated for several Clk cycles. The latter choice allows the slave to force the master to hold its datahandshake phase outputs so the slave can accomplish its access without latching data signals.

The datahandshake phase does not begin until MDataValid is asserted. While MDataValid is not asserted, SDataAccept is a “don’t care”. SDataAccept can be asserted before MDataValid. Since MDataValid not being asserted speci-fies the absence of valid data, the master can assert MDataValid independently of the current setting of SDataAccept.

Intra-Phase Signal RelationshipsThe ordering and timing relationships between the signals within an OCP phase are designed to be flexible. As described in “Request Phase”, it is legal for SCmdAccept to be driven either combinationally, dependent upon the current cycle’s MCmd or independently from MCmd, based on the characteristics of the OCP slave. Some restrictions are required to ensure that independently-created OCP masters and slaves will work together. For instance, the MCmd cannot respond to the current state of SCmdAccept; otherwise, a combina-tional cycle could occur.


Request PhaseIf enabled, a slave’s SThreadBusy request phase output should not depend upon the current state of any other OCP signal. SThreadBusy should be stable early enough in the cycle so that the master can factor the current SThreadBusy into the decision of which thread to present a request; that is, all of the master’s request phase outputs may depend upon the current SThreadBusy. SThreadBusy is a hint so the master is not required to include a combinational path from SThreadBusy into MCmd, but such paths would be typical. The slave should guarantee that SThreadBusy becomes stable early in the OCP cycle. A common goal is that SThreadBusy be driven directly from a flip-flop in the slave.

A master’s request phase outputs should not depend upon any current slave output other then SThreadBusy. This ensures that there is no combinational loop in the case where the slave’s SCmdAccept depends upon the current MCmd.

If a slave’s SCmdAccept request phase output is based upon the master’s request phase outputs from the current cycle, there is a combinational path from MCmd to SCmdAccept. Otherwise, SCmdAccept may be driven directly from a flip-flop, or based upon some other OCP signals. It is legal for SCmdAccept to be derived from MRespAccept. This case arises when the slave delays SCmdAccept to force the master to hold the request fields for a multi-cycle access. Once read data is available, the slave attempts to return it by asserting SResp. If the OCP has MRespAccept enabled, the slave then must wait for MRespAccept before negating SResp, so it may need to continue to hold off SCmdAccept until it sees MRespAccept asserted.

While the phase relationships of the OCP specification do not allow the response phase to end before the request phase, it is legal for both phases to complete in the same OCP cycle.

The worst-case combinational path for the request phase could be:

Clk -> SThreadBusy -> MCmd -> SResp -> MRespAccept -> SCmdAccept -> Clk

The preceding path has too much latency at typical clock frequencies. Fortu-nately, a multi-threaded slave (with SThreadBusy enabled) is not likely to exhibit non-pipelined read behavior, so this path is unlikely to prove useful. Slave designers need to limit the combinational paths visible at the OCP. By pipelining the read request, the previous path could be:

Clk -> SThreadBusy -> MCmd -> ClkClk -> SCmdAccept -> Clk # Slave accepts if pipeline reg empty

Clk -> SResp -> ClkClk -> MRespAccept -> Clk # Master accepts independent of SResp

Response PhaseIf enabled, a master's MThreadBusy response phase output should not be dependent upon the current state of any other OCP signal. From the perspec-tive of the OCP, MThreadBusy should become stable early enough in the cycle


that the slave can factor the current MThreadBusy into the decision on which thread to present a response; that is, all of the slave’s response phase outputs may depend upon the current MThreadBusy. MThreadBusy is a hint so the slave is not required to include a combinational path from MThreadBusy into SResp, but such paths would be typical. Therefore, the master should guar-antee that MThreadBusy becomes stable early in the OCP cycle. A common goal is that MThreadBusy be driven directly from a flip-flop in the master.

The slave’s response phase outputs should not depend upon any current master output other than MThreadBusy. This ensures that there is no combi-national loop in the case where the master’s MRespAccept depends upon the current SResp.

The master’s MRespAccept response phase output may be based upon the slave’s response phase outputs from the current cycle or not. If this is true, there is a combinational path from SResp to MRespAccept. Otherwise, MRespAccept can be driven directly from a flip-flop; MRespAccept should not be dependent upon other master outputs.

Datahandshake PhaseThe master’s datahandshake phase outputs should not depend upon any current slave output other than SThreadBusy. This ensures that there is no combinational loop in the case where the slave’s SDataAccept depends upon the current MDataValid. The slave’s SDataAccept output may or may not be based upon the master’s datahandshake phase outputs from the current cycle. In the former case, there is a combinational path from MDataValid to SDataAccept. In the latter case, SDataAccept should be driven directly from a flip-flop; SDataAccept should not be dependent upon other master outputs.

Multi-threaded OCP ImplementationFigure 22 on page 162 shows the typical implementation of the combinational paths required to make a multi-threaded OCP work within the framework set by Level-2 timing. While the figure shows a request phase, similar logic can be used for the response and datahandshake phases. The top half of the figure shows logic in the master; the bottom half shows logic in the slave. The width of the figure represents a single OCP cycle.


Figure 22 Typical Multithreaded OCP Interface Implementation

SlaveInformation about space available on the per-port buffers comes out of a latch and is used to generate SThreadBusy information, which must be generated within the initial 10% of the OCP cycle (as described in “Level2 Timing” on page 174). These signals are also used to generate SCmdAccept: if a particular port has room, a command on the corresponding thread is accepted. The correct port information is selected through a mux driven by MThreadID at 50% of the clock cycle, making it easy to produce SCmdAccept by 75% of the OCP cycle. When the request group arrives at 60% of the OCP cycle, it is used to update the buffer status, which in turn becomes the SThreadBusy information for the next cycle.

MasterThe master keeps information on what threads have commands ready to be presented (thread valid bits). When SThreadBusy arrives at 10% of the OCP clock, it is used to mask off requests, that is any thread that has its SThreadBusy signal set is not allowed to participate in arbitration for the OCP. The remaining thread valid bits are fed to thread arbitration, the result of which is the winning thread identifier, MThreadId. This is passed to the slave at 50% of the OCP clock period. It is also used to select the winning thread’s request group, which is then passed to the slave at 60% of the clock period. When the SCmdAccept signal arrives from the slave, it is used to compute the new thread valid bits for the next cycle.

Mas

ter

Sla

ve

ThreadArbitration

10%50%

ValidThreads

MThreadID

RequestGroup

BufferUpdate

SThreadBusy

Buffer has Room

60%

BufferUpdate

Request Group

75%

New ThreadValid Info

NewBufferStatus

SCmdAccept


State Machine ExamplesThis section describes state machine master and slave implementations that are compliant with the OCP. Each example uses only the features of the Basic OCP (that is, the required signals). The examples highlight the flexibility of the Basic OCP.

Sequential MasterThe first example is a medium-throughput, high-frequency master design. To achieve high frequency, the implementation is a completely sequential (that is, Moore state machine) design. Figure 23 shows the state machine associ-ated with the master’s OCP.

Figure 23 Sequential Master

Not shown is the internal circuitry of the master. It is assumed that the master provides the state machine with two control wire inputs, WrReq and RdReq, which ask the state machine to initiate a write transfer and a read transfer, respectively. The state machine indicates back to the master the completion of a transfer as it transitions to its Idle state.

Since this is a Moore state machine, the outputs are only a function of the current state. The master cannot begin a request phase by asserting MCmd until it has entered a requesting state (either write or read), based upon the WrReq and RdReq inputs. In the requesting states, the master begins a request phase that continues until the slave asserts SCmdAccept. At this point, a Write command is complete, so the master transitions back to the idle state. In case of a Read command, the next state is dependent upon whether the slave has begun the response phase or not. Since MRespAccept is not avail-

Idle

Write Read

MCmd=Idle

MCmd=Write MCmd=Read

Legend:

State

Input/output

Required Arc

Optional Arc

SResp == NULL

~SCmdAccept ~SCmdAccept

~(WrReq | RdReq)

WrReq RdReq

SCmdAccept

SCmdAccept

SResp != NULL

&(SResp != NULL)

SCmdAccept&(SResp == NULL)

WaitResp

MCmd=Idle


able in the Basic OCP, the response phase always ends in the cycle it begins, so the master may transition back to the idle state if SResp is asserted. If the response phase has not begun, then the next state is wait resp, where the master waits until the response phase begins.

The maximum throughput of this design is one transfer every other cycle, since each transfer ends with at least one cycle of idle. The designer could improve the throughput (given a cooperative slave) by adding the state tran-sitions marked with dashed lines. This would skip the idle state when there are more pending transfers by initiating a new request phase on the cycle after the previous request or response phase. Also, the Moore state machine adds up to a cycle of latency onto the idle to request transition, depending on the arrival time of WrReq and RdReq. This cost is addressed in “Combinational Master” on page 165.

The benefits of this design style include very simple timing, since the master request phase outputs deliver a full cycle of setup time, and minimal logic depth associated with SResp.

Sequential SlaveAn analogous design point on the slave side is shown in Figure 24. This slave’s OCP logic is a Moore state machine. The slave is capable of servicing an OCP read with one Clk cycle latency. On an OCP write, the slave needs the master to hold MData and the associated control fields steady for a complete cycle so the slave’s write pulse generator will store the desired data into the desired location. The state machine reacts only to the OCP (the internal operation of the slave never prevents it from servicing a request), and the only non-OCP output of the state machine is the enable (WE) for the write pulse generator.

Figure 24 Sequential OCP Slave

Write ReadSCmdAccept SCmdAccept

Legend:

State

Input/output

Required Arc

(MCmd == Idle)

(MCmd == Write) (MCmd == Read)

SResp=NULLWE

SResp=DVA~WE

Idle~SCmdAcceptSResp=NULL

~WE


The state machine begins in an idle state, where it de-asserts SCmdAccept and SResp. When it detects the start of a request phase, it transitions to either a read or a write state, based upon MCmd. Since the slave will always complete its task in one cycle, both active states end the request phase (by asserting SCmdAccept), and the read state also begins the response phase. Since there is no MRespAccept in the Basic OCP, the response phase will end in the same cycle it begins. Finally, the state machine triggers the write pulse generator in its write state, since the request phase outputs of the master will be held steady until the state machine transitions back to idle.

As in the sequential master shown in Figure 23 on page 163, this state machine limits the maximum throughput of the OCP to one transfer every other cycle. There is no simple way to modify this design to achieve one transfer per cycle, since the underlying slave is only capable of one write every other cycle. With a Moore machine representation, the only way to achieve one transfer per cycle is to assert SCmdAccept unconditionally (since it cannot react to the current request phase signals until the next Clk cycle). Solving this performance issue requires a combinational state machine.

Since the outputs depend upon the state machine, the sequential OCP slave has attractive timing properties. It will operate at very high frequencies (providing the internal logic of the slave can run that quickly).

This state machine can be extended to accommodate slaves with internal latency of more than one cycle by adding a counting state between idle and one or both of the active states.

Combinational Master“Sequential Master” on page 163 describes the transfer latency penalty asso-ciated with a Moore state machine implementation of an OCP master. An attractive approach to improving overall performance while reducing circuit area is to consider a combinational Mealy state machine representation. Assuming that the internal master logic is clocked from Clk, it is acceptable for the master's outputs to be dependent on both the current state, the internal RdReq and WrReq signals, and the slave's outputs, since all of these are synchronous to Clk. Figure 25 shows a Mealy state machine for the OCP master. The assumptions about the internal master logic are the same as in “Sequential Master” on page 163, except that there is an additional acknowl-edge (Ack) signal output from the state machine to the internal master logic to indicate the completion of a transfer.

This state machine asserts MCmd in the same cycle that the request arrives from the internal master logic, so transfer latency is improved. In addition, the state machine is simpler than the Moore machine, requiring only two states instead of four. The request state is responsible for beginning and waiting for the end of the request phase. The wait resp state is only used on Read commands where the slave does not assert SResp in the same cycle it asserts SCmdAccept. The arcs described by dashed lines are optional features that allow a transition directly from the end of the response phase into the begin-ning of the request phase, which can reduce the turn-around delay on multi-cycle Read commands.


Figure 25 Combinational OCP Master

The cost of this approach is in timing. Since the master request phase outputs become valid a combinational logic delay after RdReq and WrReq, there is less setup time available to the slave. Furthermore, if the slave is capable of asserting SCmdAccept on the first cycle of the request phase, then the total path is:

Clk -> (RdReq WrReq) -> MCmd -> SCmdAccept -> Clk.

To successfully implement this path at high frequency requires careful anal-ysis. The effort is appropriate for highly latency-sensitive masters such as CPU cores. At much lower frequencies, where area is often at a premium, the Mealy OCP master is attractive because it has fewer states and the timing constraints are much simpler to meet. This style of master design is appro-priate for both the highest-performance and lowest-performance ends of the spectrum. A Moore state machine implementation may be more appropriate at medium performance.

Combinational SlaveAchieving peak OCP data throughput of one transfer per cycle is most commonly implemented using a combinational Mealy state machine imple-mentation. If a slave can satisfy the request phase in the cycle it begins and deliver read data in the same cycle, the Mealy state machine representation is degenerate - there is only one state in the machine. The state machine always asserts SCmdAccept in the first request phase cycle, and asserts SResp in the same cycle for Read commands.

RequestWait

Legend:

State

Input/output

Required Arc

Optional Arc

RdReq & SCmdAccept &

Resp(SResp != NULL)/MCmd = Idle, Ack

(SResp == NULL)/(MCmd = Read), ~Ack

(SResp == NULL)/(MCmd = Read), ~Ack

~(WrReq | RdReq) /MCmd=Idle, ~Ack

WrReq/MCmd=Write, Ack=SCmdAcceptRdReq & ~SCmdAccept/MCmd=Read, ~AckRdReq & SCmdAccept &(SResp != NULL) /MCmd=Read, Ack


Figure 26 Combinational OCP Slave

The implementation shown in Figure 26, offers the ideal throughput of one transfer per cycle. This approach typically works best for low-speed I/O devices with FIFOs, medium-frequency but low-latency asynchronous SRAM controllers, and fast register files. This is because the timing path looks like:

Clk -> (master Logic) -> MCmd -> (Access internal slave resource) -> SResp -> Clk.

This path is simplest to make when:

• Clk frequency is low

• Internal slave access time is small

• SResp can be determined based only on MCmd assertion (and not other request phase fields nor internal slave conditions)

To satisfy the access time and operating frequency constraints of higher-performance slaves such as main memory controllers, the OCP supports transfer pipelining. From the state machine perspective, pipelining splits the slave state machine into two loosely-coupled machines: one that accepts requests, and one that produces responses. Such machines are particularly useful with the burst extensions to the OCP.

Legend:

State

Input/output

Required Arc

Optional Arc

(MCmd == Write)/SCmdAccept,SResp=NULL

Idle

(MCmd == Idle)/SCmdAccept,SResp=NULL

(MCmd == Read)/SCmdAccept,SResp=DVA


Simple OCP ExtensionsThe simple extensions to the OCP signals add support for higher-performance master and slave devices. The MBurst signal provides information for linking together otherwise-independent OCP transfers. This is important because it allows various parts of a system to optimize transfer performance using such techniques as DRAM page-mode operation, burst transfers, and pre-fetching. The data handshaking extension (MDataValid and SDataAccept) allows pipelining of address ahead of data for write transfers. This extension supports higher performance for multiplexed address/data bus bridges (such as PCI). The MRespAccept signal allows a master to pre-fetch read data before it has buffers in which to store the result. This signal may also be used in situ-ations where the OCP data width is wider (for performance reasons) than the natural word width of the master.

The MAddrSpace signal permits the explicit addressing of different address spaces in the target. Often, they are address spaces with unique properties or behavior that tend to get located in different places in the system address map.

Burst ExtensionThe burst extension is typically used along with pipelined master and slave devices. For a pipelined OCP device, the request phase is de-coupled from the response phase - that is, the request phase may begin and end several cycles before the associated response phase begins and ends. As such, it is useful to think of separate, loosely-coupled state machines to support either the master or the slave.

Datahandshake ExtensionThe datahandshake extension allows the de-coupling of a write address from write data. It is typically only useful for master and slave devices that require the throughput advantages available through transfer pipelining.

Complex OCP ExtensionsThe complex extensions add support for concurrency. Without these exten-sions, the OCP protocol enforces strict ordering constraints; each transfer request must be completed by the slave in the same order presented by the master. This restriction is important both to ensure proper system function-ality (that is, an OCP read that occurs after a write to the same address will return the new data) and to simplify the transfer tracking requirements of implementing pipelining. The complex extensions enhance the basic transfer capability by introducing the concept of threads.


ThreadsThe thread capability relies on a thread ID to identify and separate indepen-dent transfer streams (threads). The master labels each request with the thread ID that it has assigned to the thread. The thread ID is passed to the slave on MThreadID together with the request (MCmd). When the slave returns a response, it also provides the thread ID (on SThreadID) so the master knows which request is now complete.

The transfers in each thread must remain in-order with respect to each other (as in the basic OCP), but the order between threads can change between request and response.

The thread capability allows a slave device to optimize its operations. For instance, a multi-bank SDRAM controller could respond to a second read request referencing an open page before opening a new page in a different bank to service a first read on a different thread.

In multi-threaded, multi-initiator systems, it is frequently useful to associate a transfer request with a thread operating on a particular initiator. Initiator identification enables busy targets (such as multi-bank SDRAM controllers) to prioritize requests. For instance, a memory controller that is completing a first burst transaction needs to determine which of several pending requests to service next. In many systems, the decision should be based upon priority; for example, real-time frame buffer transfers have higher priority than polygon data transfers. The priority is typically associated with the requesting initiator. In some cases, the initiator has several assigned priorities based upon the type of request. If different request types are assigned to different system initiator threads, the priority is dependent upon a thread within a particular initiator.

For devices where these concerns are important, the OCP complex extensions support connections.

ConnectionsConnections are closely related to threads, but can have end-to-end meaning in the system, rather than the local meaning (that is, master to slave) of a thread.

The connection ID and thread ID seem to provide similar functionality, so it is useful to consider why the OCP needs both. A thread ID is an identifier of local scope that simply identifies transfers between the master and slave. In contrast, the connection ID is an identifier of global scope that identifies trans-fers between a system initiator and a system target. A thread ID must be small enough (that is, a few bits) to efficiently index tables or state machines within the master and slave. There are usually more connection IDs in the system than any one slave is prepared to simultaneously accept. Using a connection ID in place of a thread ID requires expensive matching logic in the master to associate the returned connection ID (from the slave) with specific requests or buffer entries.


Using a networking analogy, the thread ID is a level-2 (data link layer) concept, whereas the connection ID is more like a level-3 (transport/session layer) concept. Some OCP slaves only operate at level-2, so it doesn’t make sense to burden them or their masters with the expense of dealing with level-3 resources. Alternatively, some slaves need the features of level-3 connec-tions, so in this case it makes sense to pass the connection ID through to them.

From a state machine perspective, multi-threaded behavior is most frequently implemented using one state machine per thread. The only added complexity is the arbitration scheme between threads. This is unavoidable, since the entire purpose for building a multi-threaded OCP is to support concurrency, which directly implies contention for any shared resources, such as the OCP wires.

The MDataThreadID signal simplifies the implementation of the datahand-shake extension along with threading, by providing the thread ID associated with the current write data transfer. Without this signal, the slave state machines must cooperate to track the Write command order (among threads).

The thread busy signals provide status information that allows the master's arbiter to determine which threads will not accept requests. That information also allows the slave's arbiter to determine which threads will not accept responses. These signals provide for cooperation between the master and the slave to ensure that requests do not get presented on busy threads.

Sideband SignalsThe sideband signals provide a means of transmitting control-oriented infor-mation. Since the signals are rarely performance sensitive, implementors are strongly encouraged to ensure that all sideband signals are driven stable very early in the OCP clock cycle; that is, that sideband outputs come directly out of core flip-flops. Sideband inputs should similarly be allowed to arrive very late in the OCP clock cycle; that is, sideband inputs should be registered almost immediately by the receiving core.

Cores that do not implement this conservative timing may require modifica-tion to achieve timing convergence.


Debug and Test InterfaceThere are three debug and test interface extensions predefined for the OCP: scan, clock control, and IEEE 1149. The scan extension enables internal scan techniques, either in a pre-designed hard-core or end user inserted into a soft-core. Clock Control extensions assist in scan testing and debug when the IP core has at least one other clock domain that is not derived from Clk. The IEEE 1149 extension is for interfacing to cores that have an IEEE 1149.1 test access port built-in and accessible. This is primarily the case with cores, such as microprocessors, that were derived from standalone products.

These three extensions along with sideband signals (flags) can yield a highly debuggable and testable IP core and device.

Scan ControlThe width and meaning of the Scanctrl field is user-defined. At a minimum this field carries a signal to specify when the device is in scan chain shifting mode. The signal can be used for the scan clock if scan-clock style flip-flops are being used. When this is a multi-bit field, another common signal to carry would be one specifying the scan mode. This signal can be used to put the IP core into any special test mode that is necessary before scanning and appli-cation of ATPG vectors can begin.

Clock ControlThe clock control test extensions are included to ease the integration of IP cores into full or partial scan test environments and support of debug scan operations in designs that use clock sources other than Clk.

When an external clock source exists (for example, non-Clk derived clock), the ClkByp signal specifies a bypass of the external clock. In that case the TestClk signal usually becomes the clock source. The TestClk toggles in the correct sequence for applying ATPG vectors, stopping the internal clocks, and doing scan dumps as required by the user.

17 Timing Guidelines

To provide core timing information to system designers, characterize each core into one of the following timing categories:

• Level0 identifies the core interface as having been designed without adhering to any specific timing guidelines.

• Level1 timing represents conservative interface timing.

• Level2 represents high performance interface timing.

One category is not necessarily better than another. The timing categories are an indication of the timing characteristics of the core that allow core designers to communicate at a very high level about the interface timing of the core. Table 38 represents the inter-operability of two OCP interfaces.

Table 38 Core Interface Compatibility

X no guarantee

V guaranteed inter-operability with possible performance loss (extra latency)

V* high performance inter-operability but some minor changes may be required

The timing guidelines apply to dataflow and sideband signals only. There is no timing guideline for the scan and test related signals.

Level0 Level1 Level2

Level0 X X X

Level1 X V V

Level2 X V V*


Timing numbers are specified as a percentage of the minimum supported clock-cycle (at maximum operating frequency). If a core is specified at 100MHz and the c2qtime is given as 30%, the actual c2qtime is 3ns.

Level0 Timing Level0 timing indicates that the core developer has not followed any specific guideline in designing the core interface. There is no guarantee that the inter-face can operate with any other core interface. Inter-operability for the core will need to be determined by comparing timing specifications for two inter-faces on a per-signal basis.

Level1 Timing Level1 timing indicates that a core has been developed for minimum timing work during system integration. The core uses no more than 25% of the clock period for any of its signals, either at the input (setuptime) or at the output (outputtime). A core interface in this category must not use any of the combi-national paths allowed in the OCP interface.

Since inputs and outputs each only use 25%, 50% of the cycle remains avail-able. This means that a Level1 core can always connect to other Level1 and Level2 cores without requiring any additional modification.

Level2 Timing Level2 timing indicates that a core interface has been developed for high performance timing. A Level2 compliant core provides or uses signals according to the timing values shown in Table 39. There are separate values for single-threaded and multi-threaded OCP interfaces. The number for each signal indicates the percentage of the minimum cycle time at which the signal is available, that is the outputtime at the output. Setuptime at the input is calculated by subtracting the number given from the minimum cycle time. For example, a time of 30% indicates that the outputtime is 30% and the setup-time is 70% of the minimum clock period.

In addition to meeting the timing indicated in Table 39, a Level2 compliant core must not use any combinational paths other than the preferred paths listed in Table 40.

There is no margin between outputtime and setuptime. When using Level2 cores, extra work may be required during the physical design phase of the chip to meet timing requirements for a given technology/library.

Timing Guidelines 175

Table 39 Level2 Signal Timing

Table 40 Allowed Combinational Paths for Level2 Timing

SignalSingle-threaded Interface %

Multi-threaded Interface %

Control, Status 25 25

ControlBusy, StatusBusy 10 10

ControlWr, StatusRd 25 25

Datahandshake Group(excluding MDataThreadID)

30 60

MDataThreadID n/a 50

MRespAccept 50 75

MThreadBusy 10 10

MThreadID n/a 50

Request Group(excluding MThreadID)

30 60

Reset_n 10 10

Response Group (excluding SThreadID) 30 60

SCmdAccept 50 75

SDataAccept 50 75

SError, SFlag, SInterrupt, MFlag 40 40

SThreadBusy 10 10

SThreadID n/a 50

Core From To

Master SThreadBusy Request Group

SThreadBusy Datahandshake Group

Response Group MRespAccept

Slave MThreadBusy Response Group

Request Group SCmdAccept andSDataAccept

Datahandshake Group SCmdAccept andSDataAccept

Index

Aaddr_base statement 102

addr_size statement 102

addr_wdth parameter 12

addressbus bridges 168pipelining 168region statement 102space 9STL 87transfer 14

addrspace 14

addrspace_wdth 14

arbitration, shared resource 8

area savings 158, 165

ATPG vectors 171

Bbasic OCP signals 12

BCST 13

be field 88

behavioral modelmulti-threaded 79OCP Merger 79OCPMON 81QCMaster 69QCSlave 72QSMaster 69QSSlave 72stimulus 85

behavioral statements 91

bfill 88

bread 90

Broadcast commanddescription 8device support 35transfer affects 31

broadcast_enable parameter 35

buffer, large load 125

bundlecharacteristics 101configuring 108, 109defining

core 101non-OCP interface 115testbench 108

external signals 110name 100

nets 101, 111signals 116statement 116type 108

burstalignment 36burst_aligned parameter 36code 14, 31configuration parameters 74custom 34custom patterns 32definition 31extension 168field values 31fill 88fill zero 89incrementing 32latency 74linking transfers 14maximal packing 32MBurst signal 14option

coding 110param statement 108, 109

packing 32parameter 14read macro 90sequenced address 9size 36state machine 167streaming 32, 34support

reporting instructions 62, 63signals 14

transfers 168type 14, 32write

numeric 89random 89

burst_aligned parameter 36

burstlat_1thread 74

burstlat_cycles 74

burstlat_enable 74

busbridges 168independence 8of signals 116wrapper interface module 2

bwrite 89

byte enablefield 15MByteEn signal 15STL 88


supported patterns 35

byteen parameter 15

bzero 89

Cc2qtime

default 121port constraints 145timing 56variable description 130

c2qtimemin 130, 145

capacitancenets 126units 120wireload 132, 147wireloaddelay 132, 147

capacitancescale variable 120

capacitive load 57

cell library name 57

cfill 88

chip synthesis configuration fileclocks 128creating 119parts 120ports 130sample 138specifying technology variables 134technology variables 120

chip_stmt 107

chipparam variable 134, 143

CID connection ID 86

Clk signalfunction 12summary 21

ClkByp signalfunction 19summary 22test extensions 171timing 30

clkctrl_enable parameter 20

clockattributes 120bypass signal 20control test extensions 171description syntax 136fall time 122, 124gated test 20name 136non-OCP 144period

chip synconf file 128rise/fall time 129variable 129

portname 145rise time 123, 129signal 12skew

best case 123hold time 129setup time 129worst case 123

test 20to output time 130variables 128waveform

editing 130rise/fall time 124, 129

clockName 144

clockname field 145

clockperiod variable 133, 142

cmd field 86

combinationaldependencies 26, 175Mealy state machine 165paths 59, 150slave state machine 166

commandsbasic 8extensions 8mnemonic 13required 36

comments 112

compatibility rules 36

complex OCP signals 15, 168

concurrency 168

configurable interfaces 102

connectiondescription 169identifier

CID 86definition 169field 15support 62, 63transfer handling 35uses 10

location 108, 109statement 108transfers 35width mismatch 39

connid parameter 15

connid_wdth parameter 15

controlevent signal 18field 18information

specifying 18timing 30

parameter 18

Index 179

statement 93timing 30

Control signalemulation 78function 17summary 21timing 30

control_wdth parameter 18

controlbusy parameter 18

ControlBusy signalemulation 79function 17summary 21timing 30

controlobserve_addr 79

controlreg_addr 78

controlwr parameter 18

ControlWr signal 30emulation 79function 17summary 21

corearea 61, 144code 98compliance 3control

busy 18event 18information 18

delay calculation 125description language 98documentation 61documentation template 66frequency range 61hold time 131ID 61interconnecting 58interface

defining 100description 110timing parameters 56

name 61non-OCP interfaces 108power consumption 61process dependent 61revision 98RTL configuration file 97status

busy 18event 19information 18

synthesis configuration filedefining 141overriding 120

timing 55, 173

core_id statement 98

core_language statement 98

core_name 97

core_stmt 97

cread 90

custom burstsattributes 32types 34

cwrite 89

cycle command 86

czero 89

Ddata field 88

data width 9

data_wdth parameter 13

dataflow signalsdefinitions 12naming 12timing 27

datahandshakeextension 168intra-phase output 161parameter 15phase

active 28order 28timing 159

QMaster emulation 71sequence 159signal group 26signals 14throughput 159

ddr_space statement 102

debug and test interface 20, 171

defaultc2qtime variable 121

defaultc2qtimemin variable 121

defaultcriticalrange variable 121

defaultfalldelaymax variable 122

defaultfalldelaymin variable 122

defaultfalltime variable 124

defaultfanoutload variable 122

defaultholdtime variable 122

defaultloadcellpin variable 122

defaultloads variable 123

defaultminusuncertainty variable 123

defaultplusuncertainty variable 123

defaultrisedelaymax variable 123

defaultrisedelaymin variable 123

defaultrisetime variable 124

defaultsetuptime variable 124


direction statement 117

DRAM page-mode operation 168

driver strength 57

drivingcellpin parameterdescription 131timing requirements 57values 146

dumpOff 83

DVA 13

EERR 13

errorreport mechanisms 10response emulation 77signal 17signal emulation 75slave 18

error_delay 76

error_resetaddr 76

error_setaddr 76

exclusive access 8

explicit width macro 90

extended OCP signals 14, 168

Ffalldelaymax variable 128

falldelaymin variable 128

falltime variable 129

false path constraints 59, 151

falsepath parameter 59, 137, 151

fanoutmaximum 147net 122port 132value 122

FIFOmodeling 72

flagscore-specific 17master 17slave 18

flow-control 62, 63

force_aligned parameter 35

Ggate

delay 124load calculations 122specifying 131

gatedelay variable 124

gatedelaymin variable 124

gatesize variable 125

Hhighdrivegatepin variable 125

high-frequency design 163

hold timechecking 56clock skew 129input port 131value 122

holdtimedescription 131, 146timing 56

Iicon statement 98

idlemacro 91request cycles 82

implementation restrictions 62, 63

incrementing burstsattributes 32rules 33

inout ports 148, 149

inputload 57port syntax 148signal timing 56

instancebody 109location 108, 109name 109size 144statement 109

interconnect delays 125, 126

interfacecharacteristics 62clock control 20compatibility 36configurable 102configuration file 115connections 110core RTL description 97debug and test 20defining 110location 102, 108, 109multiple 100parameters 102scan 19statement 100, 110type statement 101

Index 181

types 116

interface_type statement 111

interface_types statement 116

interfaceparam variable 134, 143

internalmemory 73scan techniques 171

interruptparameter 18processing 10signal 17, 75slave 18

interrupt_delay 76

interrupt_resetaddr 75

interrupt_setaddr 75

Jjtag_enable parameter 20

jtagtrst_enable 20

Llatency

bursts 74QCSlave 73QSSlave 73random 74sensitive master 166variable 74

least significant byte 13

level0 timing 173, 174



limitreq_enable 75

limitreq_max 75

little-endian 9, 13

loadcellpindescription 131, 146timing 57

loads parameterdescription 131, 146timing 57

location statement 102, 108, 109

longest path 145

longnetdelay variable 125

longnetrccapacitance variable 126

longnetrcresistance variable 126

lowdrivegatepin variable 125

Mmacro statement 88

MAddr signalfunction 12signal mismatch 37summary 21

MAddrSpace signalfunction 14signal mismatch 37summary 21uses 168

mask value 88

masterflags 17interface documentation 62reset 17, 29response accept 15signal compatibility 36slave interaction 159thread busy 16

maxdelay parameterdescription 150syntax 137timing 59

maxfanout variable 132, 147

maximal packing 32

maxoperatingconditions variable 126

maxtest_size 70

MBurst signalfunction 14linking OCP transfers 168summary 21

MByteEn signalfunction 14signal mismatch 37summary 21

MCmd signalfunction 12signal mismatch 37summary 21

MConnID signalfunction 15signal mismatch 38summary 21

MData signaldata valid 15description 12request phase 159signal mismatch 37summary 21

mdata_delay 71

MDataThreadID signaldatahandshake 170


function 15signal mismatch 38summary 21

MDataValid signaldatahandshake 159function 14signal mismatch 37summary 21timing 159

mediumdrivegatepin variable 125

mediumnetdelay variable 125

mediumnetrccapacitance variable 126

mediumnetrcresistance variable 126

mem_2size 72

meminit_fixed 73

meminit_fixeddata 73

meminit_preloadb 73

meminit_preloadh 73

memoryexclusive access 8initialization 73initialization file 73model 72size 72special locations 75target 72

mflag parameter 17

MFlag signal 17signal mismatch 39summary 21

mflag_addr 76

mflag_wdth parameter 17

minoperatingconditions variable 126

minusuncertainty variable 129

module name 109

MRespAccept signaldefinition 14delay values 71QMaster emulation 71response phase 158response phase output 161saving area 158signal mismatch 37summary 21uses 168

mrespaccept_delay 71

mthreadbusy parameter 16

MThreadBusy signalcontrol 71definition 15information 35intra-phase output 160QMaster emulation 71

summary 21timing cycle 29

mthreadbusy_delay 71

MThreadID signalfunction 15signal mismatch 38summary 21

multiplexed bus bridges 168

multi-threaded behavioral model 79

Nnatural transfer size 32

ndata 89

netsbundle 111capacitance 126characterizing 117closest 126delays 125fanout 122load 123longest 126renaming 111resistance 126statement 116

nfill 88

nread 90

NULL 13

nwrite 89

nzero 89

OOCP

trace file 83

OCP Merger 79

ocpasm 70

OCPMON 81

optimization paths 121

out-of-band information 17

outputport syntax 149signal timing 56

Ppackage file 153

packing 32, 34

param statementchip interface 110instance 109RTL chip 108

Index 183

param variable 133, 143

pathlongest 130, 132, 145optimization 121shortest 130, 131, 145

period variable 129

phasedatahandshake 159intra-phase 159ordering

between transfers 29request 157within transfer 28

protocol 27timing 157transfer 28

physical design parameters 57

pindriving

input 131output 131

level timing 56load 122

pipelinedecoupling request phase 168request/response protocol 158support 62, 63transfer 167without MRespAccept 158write data, slave 15

plusuncertainty variable 129

point-to-point signals 8

portconstraint variables 145delay 150fanout 132inout 148, 149input, syntax 148longest path 130module names 101net delay 132output

load calculations 123, 131number of loadcellpins 131syntax 149

renaming 101setup time 124shortest path 130statement 101, 111timing constraints 141timing value

best-case 121worst case 121, 125

posted write 9

powerconsumption estimates 61

low 125

pre-fetching 168

prefix command 101

prefix statement 111

protocolphases

mapping 28order 28rules 28

QQCMaster

configuration 70features 69instantiating 109memory 70multiple 79multi-threaded model 70test vectors 70

QCSlaveconfiguration 72features 72memory modeling 72multiple threads 72

QSMasterconfiguration 70features 69memory 70multi-threaded model 70test vectors 70

QSSlaveconfiguration 72description 72error 76flag 77interrupt 76memory modeling 72multiple threads 72

Rrandmode_enable 74

rdata 89

RDEX 13

rdfifo_addr 78enable 78high 78low 78rate 78size 78

readdata field 13FIFO 77optimizing access 158


pre-fetch 168

Read commandresponse phase 159transfer affects 31

readcontrol statement 93

ReadEx commanddescription 8device support 35emulation 72transfer affects 31

readex_enable parameter 35

requestidle cycles 82number 75phase

decoupling 168intra-phase 160order 28outputs 157, 160signal group 28timing 157transfer ordering 29worst-case combinational path 160

prioritize 169signals

active 27group 26

thread identifier 16

resetOCP 29parameter 17signal 17special requirements 62

Reset_n signalfunction 17required cycles 30signal mismatch 38summary 21timing 29

resistancenets 126units 127wireload 132, 147wireloaddelay 132, 147

resistancescale variable 127

respaccept parameter 15

resperr_enable 77

resperr_rate 77

responseaccept 15encoding 13field 13flow control signals 14mnemonics 13phase

active 28intra-phase 160order 29slave 161timing 158

required types 36signal group 26thread identifier 16

revision_code 98

risedelaymax variable 129

risedelaymin variable 129

risetime variable 129

Ssbclockperiod variable 133, 143

scanclock 171control 171data

in 19out 19

interface signals 19mode control 19Scanctrl signal 19Scanin signal 19Scanout signal 19test environments 171test mode 171

scancrtl_wdth parameter 19

Scanctrl signalfunction 19summary 22uses 171

Scanin signalfunction 19summary 22timing 30

Scanout signalfunction 19summary 22timing 30

scanport_wdth parameter 19

SCmdAccept signaldefinition 12emulation 75request phase 157request phase output 160signal mismatch 37summary 21

scmdaccept_delay 75

SData signalfunction 12signal mismatch 37summary 21

Index 185

SDataAccept signaldatahandshake 159emulation 75function 14signal mismatch 38summary 21

sdataaccept_delay 75

serror parameter 18

SError signal 17signal mismatch 38summary 21

setMaxIdles 82

setuptimedescription 132, 147timing 56

sflag parameter 18

SFlag signalbehavioral models 75function 17signal mismatch 38summary 22

sflag_addr 76

sflag_wdth 18

sflagmask_addr 76

shared resource arbitration 8

shortest path 145

shortnetdelay variable 125

shortnetrccapacitance variable 126

shortnetrcresistance variable 126

sideband signalsdefinitions 17timing 29, 170

signalbasic OCP 12configuration 21control 85dataflow 12driver strength 57extensions

complex 15simple 14

external 110group

division 26mapping 28

interface compatibility 37name 101ordering 159requirements 35sideband 17statement 91test 19tie-off rules 37timing

input 56output 56requirements 27restrictions 159

ungrouped 29

SInterrupt signal 17signal mismatch 38summary 22

slavecombinational paths 160error 18flag

description 18signal emulation 75

interface documentation 62interrupt 18optimizing 169pipelined write data 15quick system 72reset 17, 29response field 13response phase 161signal compatibility 36successful transfer 31thread busy 16transfer accept 13write accept 15

Socket Transaction Languagebehavioral statements 91command syntax 85commands 85cycle directives 70macro statements 88trace 91

SResp signalbehavioral models 77function 12signal mismatch 37summary 21

state machinecombinational

master 165Mealy 165slave 166

diagrams 157multi-threaded behavior 170sequential master 163sequential slave 164

statusbusy 18core 18event 19information

emulation 78signals 18

parameter 18statement 93


timing 30

Status signalemulation 78function 17summary 22

status_wdth parameter 18

statusbusy parameter 18

StatusBusy signalemulation 79function 17summary 22timing 30

statusbusy_cycles 79

statusbusye_enable 79

statusdrive_addr 79

statusrd parameter 19

StatusRd signalemulation 79function 17summary 22timing 30

statusreg_addr 78

sthreadbusy parameter 16

SThreadBusy signaldefinition 15emulation 75, 77information 35signal mismatch 38slave request phase 160summary 21timing cycle 29

sthreadbusy_enable 77

SThreadID signalfunction 15signal mismatch 38summary 21

streamingbursts

attributes 32rules 34

device modeling 77

synchronoushandshaking signals 3interface 8reset 17

systeminitiator 2modeling 72target 2

Ttarget memory 72

TCK signal

function 19summary 22

TDI signalfunction 19summary 22

TDO signalfunction 19summary 22

technologysection 120variables 120

Technology Compiler 120

technologyvalue variable 127

testclock 20clock control extensions 171data

in 20out 20

logic reset 20mode 20signals

definitions 19timing 29, 30

size 70vector generation 85

testbenchRTL configuration file 107

TestClk signalfunction 19summary 22timing 30

threadbusy

master 16signals 35slave 16

busy signals 170description 169end-to-end identification 35identifier

binary-encoded value 16definition 169request 16response 16TID 86uses 34

mapping 34multiple 34number supported 62ordering 9state machine implementation 170support 63transfer order 169

throughputdocumenting 62

Index 187

maximum 158peak data 166

TID thread ID 86

timescale variable 127

timestamp_enable 70

timingbest case 121, 126calculating values 126categories

definitions 173level0 174level1 174level2 174

chip port values 120combinational path 27combinational paths 59constraints

portable 120ports 141

core 55connecting 58interface parameters 56

dataflow signals 27default units 127defaults, overriding 119fast 125IP blocks 119max delay 59parameters 145pin-level 56pins 57sideband signals 29signals 27, 159test signals 29worst case 121, 126

TMS signalfunction 19summary 22

transferaccept 13address 12address region 14affects on commands 31assigning 34burst

linking 31, 168requirements 32, 33type 14

byte enable 15command 12concurrent activity 34connection ID 15data widths 9efficiency 9, 32linking 14, 168natural size 32optimizing performance 168

order 9, 29out-of-order 34phases 28pipelining 9successful 31type 12

TRST_N signalfunction 19summary 22

Vvendor code 98

version 144command 120statement 98, 107, 116

VHDLlanguage specification 98ports 117signals 117

vhdl_type command 117

Virtual Socket Interface Alliance 1

Wwait statement 92

watch_enable 82

watch_maxidles 82

waveform, clock 124, 129

WGL format control 82

wgl_enable 82

wgl_slave 82

widthdata 9mismatch 39

wireloadcapacitancedescription 132, 147See also wireloaddelaytiming 57

wireloaddelaydescription 132, 147timing 57

wireloadmode variable 127

wireloadresistancedescription 132, 147See also wireloaddelaytiming 57

wordsize 9, 12transfer 9

worstcasedelay 144

wrapper interface modules 2

wrfifo_


addr 78enable 78high 78low 78rate 78size 78

writeaddress, decoupling 168data

master to slave 13

slave accept 15thread ID 16valid 15

FIFO 77posted 9, 159

Write commandcompletion 159transfer affects 31

writestatus statement 93

OCP-IP Association5440 SW Westgate Drive, Suite 217Portland, OR 97221Ph: 503-291-2560Fax: [email protected]

Part Number: 161-000125-0001

Date post:	28-Apr-2015
Category:	Documents
Upload:	darkknight1432
View:	66 times
Download:	16 times

OCP IP OpenCoreProtocolSpecification 1.0

Documents