Open Core Protocol Specification 3.0
Open Core Protocol Specification 3.0
2000-2009 OCP-IP Association, All Rights Reserved. Open Core Protocol Specification 3.0 Document Revision 1.0 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, CoreCreator, SiliconBackplane, SiliconBackplane Agent, 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.
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 1.1 OCP Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Part I 2 3 Specification Theory of Operation Signals and Encoding 5 7 13
3.1 Dataflow Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.1 Basic Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.2 Simple Extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1.3 Burst Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.4 Tag Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.1.5 Thread Extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2 Sideband Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.1 Connection, Reset, Interrupt, Error, and Core-Specific Flag Signals . . . . . . . . . 26 3.2.2 Control and Status Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.3 Test Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.1 Scan Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.2 Clock Control Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.3 Debug and Test Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.4 Signal Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.4.1 Signal Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4 Protocol Semantics 37
4.1 Signal Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.2 Combinational Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.3 Signal Timing and Protocol Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.3.1 OCP Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.3.2 Dataflow Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3.3 Sideband and Test Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.4 Transfer Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.4.1 Partial Word Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.4.2 Posting Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
viii
4.4.3 Transaction Completion, Transaction Commitment . . . . . . . . . . . . . . . . . 51 4.5 Endianness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.6 Burst Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.6.1 Burst Address Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.6.2 Burst Length, Precise and Imprecise Bursts . . . . . . . . . . . . . . . . . . . . . 54 4.6.3 Constant Fields in Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.6.4 Atomicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.6.5 Single Request / Multiple Data Bursts (Packets) . . . . . . . . . . . . . . . . . . . 55 4.6.6 MReqLast, MDataLast, SRespLast . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.6.7 MReqRowLast, MDataRowLast, SRespRowLast . . . . . . . . . . . . . . . . . . 56 4.7 Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.7.1 Ordering Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.8 Threads and Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.9 OCP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.9.1 Protocol Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.9.2 Phase Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.9.3 Signal Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.9.4 Minimum Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.9.5 OCP Interface Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.9.6 Configuration Parameter Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5 OCP Coherence Extensions: Theory of Operation 73
5.1 Cache Coherence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.2 Local View vs. System View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.3 Coherent System Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.3.1 Cache Line and Cache States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.3.2 Three Hop and Four Hop Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.4 Address Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.5 Entities and Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.6 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.7 Self Intervention and Serialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 5.8 Interconnect or Bridge Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.9 Port Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.10 Master Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.10.1 Coherent Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.10.2 Coherence-Aware Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.10.3 Legacy Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Contents
ix
5.11 Slave Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.11.1 Coherent Slave: Directory Based . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.11.2 Coherent Slave: Snoop Based . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.11.3 Legacy Slave. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.12 Multi-threading and Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.13 Burst Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.14 Memory Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.15 Race Condition, Deadlock, Livelock, and Starvation . . . . . . . . . . . . . . . . . . 90 5.16 Heterogeneous Coherence System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 6 OCP Coherence Extensions: Signals and Encodings 93
6.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 6.1.1 New Transaction Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 6.2 Main Port: Parameters, Signals, and Encodings . . . . . . . . . . . . . . . . . . . . . 94 6.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 6.2.2 Main Port Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 6.2.3 Signals and Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 6.2.4 Transfer Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.2.5 Transfer Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 6.3 Intervention Port: Parameters, Signals, and Encodings . . . . . . . . . . . . . . . . . 110 6.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 6.3.2 Port Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 6.3.3 Signals and Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 6.3.4 Signal Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.3.5 Transfer Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.3.6 Phase Ordering within a Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.3.7 Transfer Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 7 Interface Configuration File 123
7.1 Lexical Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 7.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 8 Core RTL Configuration File 129
8.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 8.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 8.3 Sample RTL Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Core Timing
141
9.1 Timing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 9.1.1 Minimum Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 9.1.2 Hold-time Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 9.1.3 Technology Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 9.1.4 Connecting Two OCP Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 9.2 Core Synthesis Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 9.2.1 Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 9.2.2 Version Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 9.2.3 Clock Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 9.2.4 Area Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 9.2.5 Port Constraints Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 9.2.6 Max Delay Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 9.2.7 False Path Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 9.2.8 Sample Core Synthesis Configuration File . . . . . . . . . . . . . . . . . . . . . 155 Part II Guidelines 157 159
10 Timing Diagrams
10.1 Simple Write and Read Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 10.2 Request Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 10.3 Request Handshake and Separate Response . . . . . . . . . . . . . . . . . . . . . . 162 10.4 Write with Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 10.5 Non-Posted Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 10.6 Burst Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 10.7 Non-Pipelined Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 10.8 Pipelined Request and Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 10.9 Response Accept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 10.10 Incrementing Precise Burst Read . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 10.11 Incrementing Imprecise Burst Read . . . . . . . . . . . . . . . . . . . . . . . . . 172 10.12 Wrapping Burst Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 10.13 Incrementing Burst Read with IDLE Request Cycle . . . . . . . . . . . . . . . . . 175 10.14 Incrementing Burst Read with NULL Response Cycle . . . . . . . . . . . . . . . 177 10.15 Single Request Burst Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 10.16 Datahandshake Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 10.17 Burst Write with Combined Request and Data . . . . . . . . . . . . . . . . . . . . 181 10.18 2-Dimensional Block Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 10.19 Tagged Reads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Contents
xi
10.20 Tagged Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 10.21 Threaded Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 10.22 Threaded Read with Thread Busy . . . . . . . . . . . . . . . . . . . . . . . . . . 190 10.23 Threaded Read with Thread Busy Exact . . . . . . . . . . . . . . . . . . . . . . . 192 10.24 Threaded Read with Pipelined Thread Busy . . . . . . . . . . . . . . . . . . . . . 193 10.25 Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 10.26 Reset with Clock Enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 10.27 Basic Read with Clock Enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 10.28 Slave Disconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 10.29 Connection Transitions with Slave Pacing . . . . . . . . . . . . . . . . . . . . . . 198 11 OCP Coherence Extensions: Timing Diagrams 12 Developers Guidelines 201 213
12.1 Basic OCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 12.1.1 Divided Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 12.1.2 Signal Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 12.1.3 State Machine Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 12.1.4 OCP Subsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 12.2 Simple OCP Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 12.2.1 Byte Enables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 12.2.2 Multiple Address Spaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 12.2.3 In-Band Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 12.3 Burst Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 12.3.1 OCP Burst Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 12.3.2 Compatibility with the OCP 1.0 Burst Model . . . . . . . . . . . . . . . . . . . 230 12.4 Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 12.5 Threads and Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 12.5.1 Threads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 12.5.2 Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 12.6 OCP Specific Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 12.6.1 Write Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 12.6.2 Lazy Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 12.6.3 OCP and Endianness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 12.6.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 12.7 Sideband Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 12.7.1 Reset Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 12.7.2 Connection Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
xii
12.8 Debug and Test Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 12.8.1 Scan Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 12.8.2 Clock Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 13 Developers Guidelines: OCP Coherent System Architecture Examples 255
13.1 Snoop-Based Coherent Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 255 13.2 Directory-Based Coherent System . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 13.2.1 Legal Coherence Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 13.3 OCP Coherence Models for Directory-Based Designs . . . . . . . . . . . . . . . . 260 13.3.1 A Directory-Based OCP Coherent System . . . . . . . . . . . . . . . . . . . . 261 13.3.2 Port Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 13.3.3 Master Implementation Models . . . . . . . . . . . . . . . . . . . . . . . . . . 272 13.3.4 Slave Implementation Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 13.3.5 Directory-Based Interconnect System-Level Model . . . . . . . . . . . . . . . 281 13.3.6 Coherent and Coherent-Non-Cached Transaction Flows . . . . . . . . . . . . . 282 13.3.7 Three-Way Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 13.3.8 Handling Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 13.4 Implementation Models for Snoop-Bus-Based Designs . . . . . . . . . . . . . . . . 290 13.4.1 Snoop-Bus-Based OCP Coherent Master Model . . . . . . . . . . . . . . . . . 290 13.4.2 Snoop-Bus-Based OCP Coherence Interconnect Model . . . . . . . . . . . . . 290 13.4.3 Snoop-Bus-Based OCP Coherence Slave Model . . . . . . . . . . . . . . . . . 291 13.4.4 Coherence Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 13.4.5 Snoop-Bus-Based CC_WB Race Conditions . . . . . . . . . . . . . . . . . . . 295 14 Timing Guidelines 315
14.1 Level0 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 14.2 Level1 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 14.3 Level2 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 15 OCP Profiles 319
15.1 Consensus Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 15.1.1 Simple Slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 15.1.2 High Speed Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 15.1.3 Advanced High-Speed Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 15.1.4 Optional Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 15.1.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 15.1.6 Additional Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 15.1.7 Sequential Undefined Length Data Flow Profile . . . . . . . . . . . . . . . . . 335
Contents
xiii
15.1.8 Register Access Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 15.2 Bridging Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 15.2.1 Simple H-bus Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 15.2.2 X-Bus Packet Write Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 15.2.3 X-Bus Packet Read Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 16 Core Performance 349
16.1 Report Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 16.2 Sample Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 16.3 Performance Report Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 Part III Protocol Compliance 357 359
17 Compliance
17.1 Configuration Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 17.1.1 Interface Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 17.1.2 Configuration Parameter Extraction . . . . . . . . . . . . . . . . . . . . . . . . 360 17.2 Protocol Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 17.2.1 Select the Relevant Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 17.3 Verification Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 17.3.1 Dynamic Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 17.3.2 Static Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 18 Protocol Compliance Checks 365
18.1 Activation Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 18.2 Compliance Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 18.2.1 Dataflow Signals Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 18.2.2 DataFlow Phase Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 18.2.3 Dataflow Burst Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 18.2.4 DataFlow Transfer Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 18.2.5 DataFlow ReadEx Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 18.3 Sideband Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 18.4 Connection Protocol Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 19 Configuration Compliance Checks 415
19.1 Request Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 19.2 Datahandshake Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 19.3 Response Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 19.4 Sideband Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
xiv
19.5 Test Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 19.6 Interface Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 20 Functional Coverage 443
20.1 Signal Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 20.2 Transfer Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 20.3 Transaction Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 20.4 Mapping Signals into Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 20.4.1 Cross Coverage of One Category . . . . . . . . . . . . . . . . . . . . . . . . . 451 20.4.2 Cross Coverage on Multiple Categories . . . . . . . . . . . . . . . . . . . . . . 451 20.5 Meta Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 20.6 Sideband Signals Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 20.7 Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 A.1 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 A.2 Trace Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 Index 461
Introduction
The Open Core Protocol (OCP) delivers the only non-proprietary, openly licensed, core-centric protocol that comprehensively describes the systemlevel 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. OCPs synchronous unidirectional signaling produces simplified core implementation, integration, 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 independently 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 appropriate 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 identifiers to manage out-of-order completion of multiple concurrent transfer sequences.
OCP-IP Confidential
xvi
The 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. CoreCreator does not constrain the user to either a specific methodology or design tool.
Support
The OCP Specification is maintained by the Open Core Protocol International Partnership (OCP-IP), a trade organization solely dedicated to OCP, supporting products and services. For all technical support inquiries, please contact techsupport@ocpip.org. For any other information or comments, please contact admin@ocpip.org.
OCP-IP Confidential
xvii
Acknowledgments
The following companies were instrumental in the development of the Open Core Protocol Specification, Release 3.0. All OCP-IP Specification Working Group members, including participants from: MIPS Technologies Inc. Nokia Sonics Inc. Texas Instruments Incorporated Toshiba Corporation Semiconductor Company Cadence
OCP-IP Confidential
Overview
The Open Core Protocol (OCP) defines a high-performance, busindependent 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 microprocessor, 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 interfaces 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 Alliances (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 VSIAs Virtual Component Interface (VCI). While the VCI addresses only data flow aspects of core communications, the OCP is a superset of VCI that additionally supports configurable sideband control signaling and test harness signals. The OCP is the only standard that defines protocols to unify all of the inter-core communication.
1.1
OCP Characteristics
The OCP defines a point-to-point interface between two communicating entities, 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
OCP-IP Confidential
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 themone 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
module
On-Chip Bus
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 functionality. 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 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 bandwidth and latency characteristics. Others use multiple-cycle access models, where signals are held static for several clock cycles to simplify timing
OCP-IP Confidential
Overview
analysis 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.
1.2
Compliance
1. The core must include at least one OCP interface. 2. The core and OCP interfaces must be described using an RTL configuration file with the syntax specified in Chapter 8 on page 129. 3. Each OCP interface on the core must: Comply with all aspects of the OCP interface specification Have its timing described using a synthesis configuration file following the syntax specified in Chapter 9 on page 141.
4. The following practices are recommended but not required: a. Each non-OCP interface on the core should: Be described using an interface configuration file with the syntax specified in Chapter 7 on page 123. Have its timing described using a synthesis configuration file with the syntax specified in Chapter 9 on page 141. b. A performance report as specified in Chapter 16 on page 349 (or an equivalent report) should be included for the core.
OCP-IP Confidential
Part I Specification
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 highperformance 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 requirements adds an even higher level of complexity to the interface. To address this spectrum of interface definitions, the OCP defines a highly configurable interface. The OCPs 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.
OCP-IP Confidential
Bus Independence
A core utilizing the OCP can be interfaced to any bus. A test of any busindependent 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 techniques vary greatly among on-chip buses. Some use address decoders, while 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 OCPcompliant masters to pass a command field across the OCP that the bus interface logic converts into an arbitration request sequence.
Commands
There are two basic commandsRead and Writeand five command extensions: WriteNonPost, Broadcast, ReadExclusive, ReadLinked, and WriteConditional. The WriteNonPost and Broadcast commands have semantics that are similar to the Write command. A WriteNonPost command explicitly instructs the slave not to post a write. For the Broadcast command, 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 other command extensionsReadExclusive, ReadLinked and WriteConditionalare used for synchronization between system initiators. ReadExclusive is paired with Write or WriteNonPost, and has blocking semantics. ReadLinked, used in conjunction with WriteConditional has nonblocking (lazy) semantics. These synchronization primitives correspond to those available natively in the instruction sets of different processors.
OCP-IP Confidential
Theory of Operation
Address/Data
Wide widths, characteristic of shared on-chip address and data buses, make tuning the OCP address and data widths essential for area-efficient implementation. 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 significantly greater than an octet. The OCP supports a configurable data width to allow multiple bytes to be transferred 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 supports word sizes of power-of-two and nonpower-of-two (as would be needed for a 12-bit DSP core). The OCP address is a byte address that is word aligned. Transfers of less than a full word of data are supported by providing byte enable information that specifies which octets are to be transferred. Byte enables are linked to specific data bits (byte lanes). Byte lanes are not associated with particular byte addresses. This makes the OCP endianneutral, able to support both big and little-endian cores.
Pipelining
The 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 presentation of the associated request.
Response
The 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 an explicit response.
Burst
Burst support is essential for many IP cores, to provide high transfer efficiency. The extended OCP supports annotation of transfers with burst information. Bursts can either include addressing information for each successive command (which simplifies the requirements for address sequencing/burst count processing in the slave), or include addressing information only once for the entire burst.
In-Band Information
Cores can pass core-specific information in-band in company with the other information being exchanged. In-band extensions exist for requests and responses, as well as read and write data. A typical use of in-band extensions is to pass cacheable information or data parity.
OCP-IP Confidential
10
Tags
Tags are available in the OCP interface to control the ordering of responses. Without tags, a slave must return responses in the order that the requests were issued by the master. Similarly, writes must be committed in order. With the addition of tags, responses can be returned out-of-order, and write data can be committed out-of-order with respect to requests, as long as the transactions target different addresses. (Refer to Section 4.7.1 on page 57 for the case when requests from different tags of a thread target overlapping addresses.) The tag links the response back to the original request. Tagging is useful when a master core, such as a processor, can handle outof-order return, because it allows a slave core such as a DRAM controller to service requests in the order that is most convenient, rather than the order in which requests were sent by the master. Out-of-order request and response delivery can also be enabled using multiple threads. The major differences between threads and tags are that threads can have independent flow control for each thread and have no ordering rules for transactions on different threads. Tags, on the other hand, exist within a single thread and are restricted to shared flow control. Tagged transactions to overlapping addresses have to be committed in order but their responses may be reordered if the transactions have different tag IDs (see Section 4.7.1 on page 57). Implementing independent flow control requires independent buffering for each thread, leading to more complex implementations. Tags enable lower overhead implementations for out-of-order return of responses at the expense of some concurrency.
OCP-IP Confidential
Theory of Operation
11
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 transfers that provide responses. Write-type commands without responses cannot use the in-band reporting mechanism. The second method for reporting errors across the OCP uses out-of band error fields. These signals report more generic sideband errors, including those associated with posted write commands. Two additional groups of sideband signalsthe reset signal group and the connection signal groupare used to control the state of the interface itself. The reset signals enable the master and/or slave to immediately transition the interface from normal operation into a reset state, independently from any activity on the dataflow signals. The connection signals allow the master and slave to cooperate to cleanly achieve quiescence before putting the interface into a disconnected state where none of the other in-band nor sideband signals have meaning, except for the OCP clock.
OCP-IP Confidential
OCP-IP Confidential
14
Table 1
Name
Clk EnableClk MAddr MCmd MData MDataValid MRespAccept SCmdAccept SData SDataAccept SResp
Width
1 1 configurable 3 configurable 1 1 1 configurable 1 2
Driver
varies varies master master master master master slave slave slave slave
Function
Clock input Enable OCP clock Transfer address Transfer command Write data Write data valid Master accepts response Slave accepts transfer Read data Slave accepts write data Transfer response
Clk Input clock signal for the OCP clock. The rising edge of the OCP clock is defined as a rising edge of Clk that samples the asserted EnableClk. Falling edges of Clk and any rising edge of Clk that does not sample EnableClk asserted do not constitute rising edges of the OCP clock. EnableClk EnableClk indicates which rising edges of Clk are the rising edges of the OCP clock, that is. which rising edges of Clk should sample and advance interface state. Use the enableclk parameter to configure this signal. EnableClk is driven by a third entity and serves as an input to both the master and the slave. When enableclk is set to 0 (the default), the EnableClk signal is not present and the OCP behaves as if EnableClk is constantly asserted. In that case all rising edges of Clk are rising edges of the OCP clock. MAddr The Transfer address, MAddr, specifies the slave-dependent address of the resource targeted by the current transfer. To configure this field into the OCP, use the addr parameter. To configure the width of this field, use the addr_wdth parameter. MAddr is a byte address that must be aligned to the OCP word size (data_wdth). The parameter data_wdth defines a minimum addr_wdth value that is based on the data bus byte width, and is defined as: min_addr_wdth = max(1, floor(log2(data_wdth)) - 2)
OCP-IP Confidential
15
If the OCP word size is larger than a single byte, the aggregate is addressed at the OCP word-aligned address and the lowest order address bits are hardwired to 0. If the OCP word size is not a power-of-two, the address is the same as it would be for an OCP interface with a word size equal to the next larger power-of-two. MCmd Transfer command. This signal indicates the type of OCP transfer the master is requesting. Each non-idle command is either a read or write type request, depending on the direction of data flow. Commands are encoded as follows.
Table 2 Command Encoding
MCmd[2:0]
0 0 0 0 1 1 1 1 0 0 1 1 0 0 1 1 0 1 0 1 0 1 0 1
Command
Idle Write Read ReadEx ReadLinked WriteNonPost WriteConditional Broadcast
Mnemonic
IDLE WR RD RDEX RDL WRNP WRC BCST
Request Type
(none) write read read read write write write
The set of allowable commands can be limited using the write_enable, read_enable, readex_enable, writenonpost_enable, rdlwrc_enable, and broadcast_enable parameters as described in Section 4.9.1 on page 59. MData Write data. This field carries the write data from the master to the slave. The field is configured into the OCP using the mdata parameter and its width is configured using the data_wdth parameter. The width is not restricted to multiples of 8. MDataValid Write 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. MRespAccept Master 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. SCmdAccept Slave accepts transfer. A value of 1 on the SCmdAccept signal indicates that the slave accepts the masters transfer request. To configure this field into the OCP, use the cmdaccept parameter.
OCP-IP Confidential
16
SData This field carries the requested read data from the slave to the master. The field is configured into the OCP using the sdata parameter and its width is configured using the data_wdth parameter. The width is not restricted to multiples of eight. SDataAccept Slave accepts write data. The slave indicates that it accepts pipelined write data from the master with a value of 1 on SDataAccept. This signal is meaningful only when datahandshake is in use. Use the dataaccept parameter to configure this field into the OCP. SResp Response field from the slave to a transfer request from the master. The field is configured into the OCP using the resp parameter. Response encoding is as follows.
Table 3 Response Encoding
SResp[1:0]
0 0 1 1 0 1 0 1
Response
No response Data valid / accept Request failed Response error
Mnemonic
NULL DVA FAIL ERR
The use of responses is explained in Section 4.4 on page 49. FAIL is a nonerror response that indicates a successful transfer and is reserved for a response to a WriteConditional command for which the write is not performed, as described in Section 4.4 on page 49.
Name
MAddrSpace MByteEn MDataByteEn MDataInfo
Width
configurable configurable configurable configurable
Driver
master master master master
Function
Address space Request phase byte enables Datahandshake phase write byte enables Additional information transferred with the write data
OCP-IP Confidential
17
Name
MReqInfo SDataInfo SRespInfo
Width
configurable configurable configurable
Driver
master slave slave
Function
Additional information transferred with the request Additional information transferred with the read data Additional information transferred with the response
MAddrSpace This field specifies the address space and is an extension of the MAddr field that 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 slave or the user versus supervisor space for a master. The MAddrSpace field is configured into the OCP using the addrspace parameter. The width of the MAddrSpace field is configured with the addrspace_wdth parameter. While the encoding of the MAddrSpace field is core-specific, it is recommended that slaves use 0 to indicate the internal register space. MByteEn Byte enables. This field indicates which bytes within the OCP word are part of the current transfer. See Section 4.4.1 on page 50 for more detail on request and datahandshake phase byte enables and their relationship. 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 and is allowed only if data_wdth is a multiple of 8 (that is, the data width is an integer number of bytes). The allowable patterns on MByteEn can be limited using the force_aligned parameter as described on page 60. MDataByteEn Write byte enables. This field indicates which bytes within the OCP word are part of the current write transfer. See Section 4.4.1 on page 50 for more detail on request and datahandshake phase byte enables and their relationship. There is one bit in MDataByteEn for each byte in the OCP word. Setting MDataByteEn[n] to 1 indicates that the byte associated with MData wires [(8n + 7):8n] should be transferred. The MDataByteEn field is configured into the OCP using the mdatabyteen parameter. Setting mdatabyteen to 1 is only allowed if datahandshake is 1, and only if data_wdth is a multiple of 8 (that is, the data width is an integer number of bytes). The allowable patterns on MDataByteEn can be limited using the force_aligned parameter as described on page 60. MDataInfo Extra information sent with the write data. The master uses this field to send additional information sequenced with the write data. The encoding of the information is core-specific. To be interoperable with masters that
OCP-IP Confidential
18
do not provide this signal, design slaves to be operable in a normal mode when the signal is tied off to its default tie-off value as specified in Table 16 on page 31. Sample uses are data byte parity or error correction code values. Use the mdatainfo parameter to configure this field into the OCP, and the mdatainfo_wdth parameter to configure its width. This field is divided in two: the low-order bits are associated with each data byte, while the high-order bits are associated with the entire write data transfer. The number of bits to associate with each data byte is configured using the mdatainfobyte_wdth parameter. The low-order mdatainfobyte_wdth bits of MDataInfo are associated with the MData[7:0] byte, and so on.
Figure 2 MDataInfo Field
Associated with MData [(8n+7):8n] Associated with MData [15:8] Associated with MData [7:0]
...
mdatainfobyte_wdth
mdatainfo_wdth
MReqInfo Extra information sent with the request. The master uses this field to send additional information sequenced with the request. The encoding of the information is core-specific. To be interoperable with masters that do not provide this signal, design slaves to be operable in a normal mode when the signal is tied off to its default tie-off value as specified in Table 16 on page 31. Sample uses are cacheable storage attributes or other access mode information. Use the reqinfo parameter to configure this field into the OCP, and the reqinfo_wdth parameter to configure its width. SDataInfo Extra information sent with the read data. The slave uses this field to send additional information sequenced with the read data. The encoding of the information is core-specific. To be interoperable with slaves that do not provide this signal, design masters to be operable in a normal mode when the signal is tied off to its default tie-off value as specified in Table 16 on page 31. Sample uses are data byte parity or error correction code values. Use the sdatainfo parameter to configure this field into the OCP, and the sdatainfo_wdth parameter to configure its width. This field is divided into two pieces: the low-order bits are associated with each data byte, while the high-order bits are associated with the entire read data transfer. The number of bits to associate with each data byte is
OCP-IP Confidential
19
configured using the sdatainfobyte_wdth parameter. The low-order sdatainfobyte_wdth bits of SDataInfo are associated with the SData[7:0] byte, and so on.
Figure 3 SDataInfo Field
Associated with SData [(8n+7):8n] Associated with SData [15:8] Associated with SData [7:0]
...
sdatainfobyte_wdth
sdatainfo_wdth
SRespInfo Extra information sent with the response. The slave uses this field to send additional information sequenced with the response. The encoding of the information is core-specific. To be interoperable with slaves that do not provide this signal, design masters to be operable in a normal mode when the signal is tied off to its default tie-off value as specified in Table 16 on page 31. Sample uses are status or error information such as FIFO full or empty indications. Use the respinfo parameter to configure this field into the OCP, and the respinfo_wdth parameter to configure its width.
Name
Width
Driver
master master master master master master
Function
Length of atomic burst Height of 2D block burst Address offset between 2D block rows Burst length Given burst length is precise Address sequence of burst
MAtomicLength configurable
MBlockHeight MBlockStride configurable configurable configurable 1 3
OCP-IP Confidential
20
Name
Width
Driver
master master master master master slave slave
Function
Burst uses single request/ multiple data protocol Last write data in burst Last write data in row Last request in burst Last request in row Last response in burst Last response in row
MBurstSingleReq 1 MDataLast
MDataRowLast MReqLast MReqRowLast SRespLast SRespRowLast 1 1 1 1 1 1
MAtomicLength This field indicates the minimum number of transfers within a burst that are to be kept together as an atomic unit when interleaving requests from different initiators onto a single thread at the target. To configure this field into the OCP, use the atomiclength parameter. To configure the width of this field, use the atomiclength_wdth parameter. A binary encoding of the number of transfers is used. A 0 value is not legal for MAtomicLength. MBlockHeight This field indicates the number of rows of data to be transferred in a twodimensional block burst (the height of the block of data). A binary encoding of the height is used. To configure this field into the OCP, use the blockheight parameter. To configure the width of this field, use the blockheight_wdth parameter. MBlockStride This field indicates the address difference between the first data word in each consecutive row in a two-dimensional block burst. The stride value is a binary encoded byte address offset and must be aligned to the OCP word size (data_wdth). To configure this field into the OCP, use the blockstride parameter. To configure the width of this field, use the blockstride_wdth parameter. MBurstLength For a BLCK burst (see Table 6), this field indicates the number of transfers for a row of the burst and stays constant throughout the burst. A BLCK burst is always precise. For a precise non-BLCK burst, this field indicates the number of transfers for the entire burst and stays constant throughout the burst. For imprecise bursts, the value indicates the best guess of the number of transfers remaining (including the current request), and may change with every request. To configure this field into the OCP, use the burstlength parameter. To configure the width of this field, use the burstlength_wdth parameter. A binary encoding of the number of transfers is used. 0 is not a legal encoding for MBurstLength. MBurstPrecise This field indicates whether the precise length of a burst is known at the start of the burst or not. When set to 1, MBurstLength indicates the precise length of the burst during the first request of the burst. To
OCP-IP Confidential
21
configure this field into the OCP, use the burstprecise parameter. If set to 0, MBurstLength for each request is a hint of the remaining burst length. MBurstSeq This field indicates the sequence of addresses for requests in a burst. To configure this field into the OCP, use the burstseq parameter. The encodings of the MBurstSeq field are shown in Table 6. The definition of the address sequences is described in Section 4.6.1 on page 53.
Table 6 MBurstSeq Encoding
MBurstSeq[2:0]
0 0 0 0 1 1 1 1 0 0 1 1 0 0 1 1 0 1 0 1 0 1 0 1
Burst Sequence
Incrementing Custom (packed) Wrapping Custom (not packed) Exclusive OR Streaming Unknown 2-dimensional Block
Mnemonic
INCR DFLT1 WRAP DFLT2 XOR STRM UNKN BLCK
MBurstSingleReq The burst has a single request with multiple data transfers. This field indicates whether the burst has a request per data transfer, or a single request for all data transfers. To configure this field into the OCP, use the burstsinglereq parameter. When this field is set to 0, there is a one-toone association of requests to data transfers; when set to 1, there is a single request for all data transfers in the burst. MDataLast Last write data in a burst. This field indicates whether the current write data transfer is the last in a burst. To configure this field into the OCP, use the datalast parameter with datahandshake set to 1. When this field is set to 0, more write data transfers are coming for the burst; when set to 1, the current write data transfer is the last in the burst. MDataRowLast Last write data in a row. This field identifies the last transfer in a row. The last data transfer in a burst is always considered the last in a row, and BLCK burst sequences also have a last in a row transfer after every MBurstLength transfers. To configure this field into the OCP, use the datarowlast parameter. If this field is set to 0, additional write data transfers can be expected for the current row; when set to 1, the current write data transfer is the last in the row.
OCP-IP Confidential
22
MReqLast Last request in a burst. This field indicates whether the current request is the last in this burst. To configure this field into the OCP, use the reqlast parameter. When this field is set to 0, more requests are coming for this burst; when set to 1, the current request is the last in the burst. MReqRowLast Last request in a row. This field identifies the last request in a row. The last request in a burst is always considered the last in a row, and BLCK burst sequences also have a last-in-a-row request after every MBurstLength requests. To configure this field into the OCP, use the reqrowlast parameter. When this field is set to 0, more requests can be expected for the current row; when set to 1, the current request is the last in the row. SRespLast Last response in a burst. This field indicates whether the current response is the last in this burst. To configure this field into the OCP, use the resplast parameter. When the field is set to 0, more responses are coming for this burst; when set to 1, the current response is the last in the burst. SRespRowLast Last response in a row. This field identifies the last response in a row. The last response in a burst is always considered the last in a row, and BLCK burst sequences also have a last in a row response after every MBurstLength responses. Use the resprowlast parameter to configure this field. When this field is set to 0, more can be expected for the current row; when set to 1, the current response is the last in the row.
Name
MDataTagID MTagID MTagInOrder STagID STagInOrder
Width
configurable configurable 1 configurable 1
Driver
master master master slave slave
Function
Ordering tag for write data Ordering tag for request Do not reorder this request Ordering tag for response This response is not reordered
OCP-IP Confidential
23
MDataTagID Write data tag. This variable-width field provides the tag associated with the current write data. The field carries the binary-encoded tag value. MDataTagID is required if tags is greater than 1 and the datahandshake parameter is 1. The field width is log 2 ( tags ) . MTagID Request tag. This variable-width field provides the tag associated with the current transfer request. If tags is greater than 1, this field is enabled. The field width is log2 ( tags ) . MTagInOrder Assertion of this single-bit field indicates that the current request should not be reordered with respect to other requests that had this field asserted. This field is enabled by the taginorder parameter. Both MTagInOrder and STagInOrder are present in the interface, or else neither may be present. STagID Response tag. This variable-width field provides the tag associated with the current transfer response. This field is enabled if tags is greater than 1, and the resp parameter is set to 1. The field width is log 2 ( tags ) . STagInOrder Assertion of this single-bit field indicates that the current response is associated with an in-order request and was not reordered with respect to other requests that had MTagInOrder asserted. This field is enabled if both the taginorder and the resp parameters are set to 1.
Name
MConnID MDataThreadID MThreadBusy MThreadID SDataThreadBusy SThreadBusy SThreadID
Width
configurable configurable configurable configurable configurable configurable configurable
Driver
master master master master slave slave slave
Function
Connection identifier Write data thread identifier Master thread busy Request thread identifier Slave write data thread busy Slave request thread busy Response thread identifier
OCP-IP Confidential
24
MConnID Connection 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. MDataThreadID Write 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 set to 1. MDataThreadID has the same width as MThreadID and SThreadID. MThreadBusy Master 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. See Section 4.3.2.4 on page 44 for a description of the flow control options associated with MThreadBusy. MThreadID Request 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 ) . SDataThreadBusy Slave write data thread busy. The slave notifies the master that it cannot accept any new datahandshake phases associated with certain threads. The SDataThreadBusy 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 SDataThreadBusy interface for a single-threaded OCP. To configure this field, use the sdatathreadbusy parameter. See Section 4.3.2.4 on page 44 for a description of the flow control options associated with SDataThreadBusy. SThreadID Response thread identifier. This variable-width field provides the thread identifier associated with the current transfer response. This field is enabled if threads is greater than 1 and the resp parameter is set to 1. The field width is log2 ( threads ) . SThreadBusy Slave 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
OCP-IP Confidential
25
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. See Section 4.3.2.4 on page 44 for a description of the flow control options associated with SThreadBusy.
Name
MConnect MError MFlag MReset_n SConnect SError SFlag SInterrupt SReset_n SWait ConnectCap Control ControlBusy ControlWr Status StatusBusy StatusRd
Width
2 1 configurable 1 1 1 configurable 1 1 1 1 configurable 1 1 configurable 1 1
Driver
master master master master slave slave slave slave slave slave tie-off system core system core core system
Function
Master connection state Master Error Master flags Master reset Slave connection vote Slave error Slave flags Slave interrupt Slave reset Slave delays connection change Connection capability tie-off Core control information Hold control information Control information has been written Core status information Status information is not consistent Status information has been read
OCP-IP Confidential
26
MConnect[1:0] State
0 0 1 1 0 1 0 1 Disconnected by master Waiting to transition Disconnected by slave Connected
Mnemonic
M_OFF M_WAIT M_DISC M_CON
Connected?
No Matches prior state No Yes
The M_WAIT state is transient. When the master is changing the connection state between any two of the other states, it must enter M_WAIT if the slave is asserting SWait (S_WAIT). The connection status of the interface does not change while in M_WAIT. The master can only transition to a non-transient connection state once it samples SWait negated (S_OK). The MConnect signal is configured by the connection parameter and must maintain the value M_CON if the ConnectCap tie-off is 0. If ConnectCap is 1, the reset value of MConnect is M_OFF. SConnect Slave connection vote. This signal indicates the slaves willingness to have the master in the M_CON state. The slaves vote is encoded as follows.
Table 11 Slave Connection Vote Encoding
SConnect
0 1
Connection Vote
Mnemonic
The SConnect signal is configured by the connection parameter and must maintain the value S_CON if the ConnectCap tie-off is 0. If ConnectCap is 1, the reset value of SConnect is S_DISC. SWait Slave delays connection change. This signal allows the slave to force the master to transition through the M_WAIT state before changing the connection state to M_OFF, M_DISC, or M_CON. This signal is encoded as follows:
OCP-IP Confidential
27
Table 12
SWait
0 1
Function
Allow connection status change Delay connection status change
Mnemonic
S_OK S_WAIT
The SWait signal is configured by the connection parameter and must maintain the value S_OK if the ConnectCap tie-off is 0. If ConnectCap is 1, the reset value of SWait is S_OK. ConnectCap Connection capability tie-off. This signal is tied off at component instantiation to indicate whether the interface supports the connection state machine. Tie ConnectCap to logic 0 on a master or slave if the connected slave or master, respectively, does not implement the connection protocol. In such case, the interface is always connected (i.e. it behaves as if in the M_CON state). If ConnectCap is tied to logic 1, then both master and slave must support the connection protocol. The ConnectCap tie-off signal is configured by the connection parameter and has no default value. MError Master error. When the MError signal is set to 1, the master notifies the slave of an error condition. The MError field is configured with the merror parameter. MFlag 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. MReset_n Master reset. The MReset_n signal is active low, as shown in Table 13. The MReset_n field is enabled by the mreset parameter.
Table 13 MReset Signal
MReset_n
0 1
Function
Reset Active Reset Inactive
SError Slave 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.
OCP-IP Confidential
28
SFlag Slave 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. SInterrupt Slave 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. SReset_n Slave reset. The SReset_n signal is active low, as shown in Table 14. The SReset_n field is enabled by the sreset parameter.
Table 14 SReset Signal
SReset_n
0 1
Function
Reset Active Reset Inactive
OCP-IP Confidential
29
StatusBusy Core 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. StatusRd Core 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.
Name
Scanctrl Scanin Scanout ClkByp TestClk TCK TDI TDO TMS TRST_N
Width
configurable configurable configurable 1 1 1 1 1 1 1
Driver
system system core system system system system core system system
Function
Scan control signals Scan data in Scan data out Enable clock bypass mode Test clock Test clock Test data in Test data out Test mode select Test reset
OCP-IP Confidential
30
Scanout Scan data out from the cores scan chains. Use the scanport parameter to configure this field into the OCP interface and scanport_wdth to control its width.
OCP-IP Confidential
31
Group
Basic
Signal
Clk EnableClk MAddr MCmd MData MDataValid MRespAccept1 SCmdAccept SData1 SDataAccept2 SResp
Default Tie-off
n/a 1 0 n/a 0 n/a 1 1 0 1 n/a 0 all 1s all 1s 0 0 0 0
Simple
OCP-IP Confidential
32
Group
Burst
Signal
MAtomicLength7 MBlockHeight7,8 MBlockStride7,8 MBurstLength MBurstPrecise7, 11 MBurstSeq7 MBurstSingleReq7, 12 MDataLast7, 13
Default Tie-off
atomiclength_wdth 1 blockheight_wdth9 blockstride_wdth burstlength_wdth10 Fixed Fixed Fixed Fixed Fixed Fixed Fixed Fixed Fixed tags tags Fixed tags Fixed connid_wdth 1 0 1 1 INCR 0 n/a n/a n/a n/a n/a n/a 0 0 0 0 0 0 0 0 0 0 0 0
MDataRowLast7, 8, 13, 14 datarowlast MReqLast7 MReqRowLast7, 8, 15 SRespLast1, 7 SRespRowLast1, 7, 8, 16 Tag MDataTagID17 MTagID MTagInOrder18 STagID STagInOrder19 Thread MConnID MDataThreadID MThreadBusy1, 20 MThreadID SDataThreadBusy21 SThreadBusy22 SThreadID reqlast reqrowlast resplast resprowlast tags>1 and datahandshake tags>1 taginorder tags>1 and resp taginorder and resp connid
threads>1 and datahandshake threads mthreadbusy threads>1 sdatathreadbusy sthreadbusy threads>1 and resp threads threads threads threads threads
OCP-IP Confidential
33
Group
Signal
Default Tie-off
n/a 0 0 n/a M_CON 0 0 1 S_CON 0 0 0 1 0 0 n/a S_OK
Sideband ConnectCap Control ControlBusy23 ControlWr24 MConnect25 MError MFlag MReset_n SConnect25 SError SFlag SInterrupt SReset_n Status StatusBusy26 StatusRd27 SWait25
OCP-IP Confidential
34
Group
Test
Signal
ClkByp Scanctrl Scanin Scanout TCK TDI TDO TestClk TMS TRST_N28
Default Tie-off
n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a
1 2 3 4 5 6 7
MRespAccept, MThreadBusy, SData, SDataInfo, SRespInfo, SRespLast, and SRespRowLast may be included only if the resp parameter is set to 1. SDataAccept can be included only if datahandshake is set to 1. MByteEn has a width of data_wdth/8 and can only be included when either mdata or sdata is set to 1 and data_wdth is an integer multiple of 8. MDataByteEn has a width of data_wdth/8 and can only be included when mdata is set to 1, datahandshake is set to 1, and data_wdth is an integer multiple of 8. mdatainfo_wdth must be > mdatainfobyte_wdth * data_wdth/8 and can be used only if data_wdth is a multiple of 8. mdatainfobyte_wdth specifies the partitioning of MDataInfo into transfer-specific and per-byte fields. sdatainfo_wdth must be > sdatainfobyte_wdth * data_wdth/8 and can be used only if data_wdth is a multiple of 8. sdatainfobyte_wdth specifies the partitioning of SDataInfo into transfer-specific and per-byte fields. MAtomicLength, MBlockHeight, MBlockStride, MBurstPrecise, MBurstSeq, MBurstSingleReq, MDataLast, MDataRowLast, MReqLast, MReqRowLast, SRespLast, and SRespRowLast may be included in the interface or tied off to non-default values only if MBurstLength is included or tied off to a value other than 1. MBlockHeight, MBlockStride, MDataRowLast, MReqRowLast, and SRespRowLast may be included or tied off to non-default values only if burstseq_blck_enable is set to 1 and MBurstPrecise is included or tied off to a value of 1. blockheight_wdth can never be 1.
8 9
10 burstlength_wdth can never be 1. 11 If no sequences other than WRAP, XOR, or BLCK are enabled, MBurstPrecise must be tied off to 1. 12 If any write-type commands are enabled, MBurstSingleReq can only be included when datahandshake is set to 1. If the only enabled burst address sequence is UNKN, MBurstSingleReq cannot be included or tied off to a non-default value. 13 MDataLast and MDataRowLast can be included only if the datahandshake parameter is set to 1. 14 MDataRowLast can only be included if MDataLast is included. 15 MReqRowLast can only be included if MReqLast is included. 16 SRespRowLast can only be included if SRespLast is included. 17 MDataTagID is included if tags is greater than 1 and the datahandshake parameter is set to 1. 18 MTagInOrder can only be included if tags is greater than 1. 19 STagInOrder can only be included if tags is greater than 1. 20 MThreadBusy has a width equal to threads. It may be included for single-threaded OCP interfaces. 21 SDataThreadBusy has a width equal to threads. It may be included for single-threaded OCP interfaces and may only be included if datahandshake is 1. 22 SThreadBusy has a width equal to threads. It may be included for single-threaded OCP interfaces. 23 ControlBusy can only be included if both Control and ControlWr exist. 24 ControlWr can only be included if Control exists. 25 The default tie-off values for MConnect, SConnect and SWait are the only allowed tie-off values. 26 StatusBusy can only be included if Status exists. 27 StatusRd can only be included if Status exists.
OCP-IP Confidential
35
Acts as System
System master System slave
For example, if a module acts as OCP master and also as system, it is designated a system master. In addition to the notion of modules, it is useful to introduce an interface type. All modules have interfaces. Also, there is a monitor interface type which observes all OCP signals. The permitted connectivity between interface types is shown in Table 18.
Table 18 Interface Types
Type
Master Slave System master System slave Monitor
Connects To
System slave, Slave, Monitor
Cannot Connect To
Master, System master
System master, Master, Monitor Slave, System slave Slave, Monitor Master, Monitor Master, System master, Slave, System slave Master, System Master, System slave Slave, System slave, System master Monitor
The Clk, EnableClk, and ConnectCap signals are special in that they are supplied by a third (external) entity that is neither of the two modules connected through the OCP interface.
OCP-IP Confidential
36
Figure 4
Master
Request
Data Handshake
Sideband
Core
System
Control ControlWr ControlBusy Status StatusRd StatusBusy Scanctrl Scanin Scanout ClkByp TestClk TCK TDI TDO TMS TRST_N
Test
OCP-IP Confidential
Protocol Semantics
This chapter defines the semantics of the OCP protocol by assigning meanings to the signal encodings described in the preceding chapter. Figure 5 provides a graphic view of the hierarchy of elements that compose the OCP.
Figure 5 Hierarchy of Elements
Transaction
Transfer
Transfer
...
Transfer
Phase
Phase
...
Phase
Group
Timing information
Signal
Signal
...
Signal
OCP-IP Confidential
38
Group
Request
Signal
MAddr MAddrSpace MAtomicLength MBlockHeight MBlockStride MBurstLength MBurstPrecise MBurstSeq MBurstSingleReq MByteEn MCmd MConnID MData* MDataInfo* MReqInfo MReqLast MReqRowLast MTagID MTagInOrder MThreadID
Condition
always always always always always always always always always always always always datahandshake = 0 datahandshake = 0 always always always always always always
OCP-IP Confidential
Protocol Semantics
39
Group
Response
Signal
SData SDataInfo SResp SRespInfo SRespLast SRespRowLast STagID STagInOrder SThreadID
Condition
always always always always always always always always always datahandshake = 1 always datahandshake = 1 always always always always always
Datahandshake
MData and MDataInfo belong to the request group, unless the datahandshake configuration parameter is enabled. In that case they belong to the datahandshake group.
OCP-IP Confidential
40
Figure 6
SThreadBusy SDataThreadBusy
sthreadbusy_pipelined
Slave
SThreadBusy SDataThreadBusy
!sthreadbusy_pipelined
Response group
SCmdAccept SDataAccept
!mthreadbusy_pipelined !sthreadbusy_pipelined
Master
MThreadBusy
Request group
MRespAccept
Datahandshake group
MThreadBusy
mthreadbusy_pipelined
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 MReset_n and SReset_n. For timing purposes, some of the allowed combinational paths are designated as preferred paths and are described in Table 65 on page 317.
OCP-IP Confidential
Protocol Semantics
41
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.
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 corresponding group (except for the signal that defines the beginning of the phase) are dont care. In addition, the MData and MDataInfo fields are a dont care during readtype requests, and the SData and SDataInfo fields are a dont care for responses to write-type requests. Non-enabled data bytes in MData and bits in MDataInfo as well as non-enabled bytes in SData and bits in SDataInfo are a dont care. The MDataByteEn field is dont care during read-type transfers. If MDataByteEn is present, the MByteEn field is dont care during write-type transfers. MTagID is a dont care if MTagInOrder is asserted and MDataTagID is a dont care for the corresponding datahandshake phase. Similarly, STagID is a dont care if STagInOrder is asserted. A request phase begins whenever the request group becomes active. It ends when the SCmdAccept signal is sampled by the rising edge of the OCP clock 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 the rising edge of the OCP clock 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 the rising edge of the OCP clock as 1 during a datahandshake phase.
OCP-IP Confidential
42
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.
MCmd
Read, ReadEx, ReadLinked Write, Broadcast Write, Broadcast WriteNonPost, WriteConditional Write, Broadcast Write, Broadcast WriteNonPost, WriteConditional
Phases
Request, response Request Request, response Request, response Request, datahandshake Request, datahandshake, response Request, datahandshake, response
Condition
always datahandshake = 0 writeresp_enable = 0 datahandshake = 0 writeresp_enable = 1 datahandshake = 0 datahandshake = 1 writeresp_enable = 0 datahandshake = 1 writeresp_enable = 1 datahandshake = 1
Single request, multiple data (SRMD) bursts, described in Section 4.6.5 on page 55, have a single request phase and multiple data transfer phases, as shown in Table 21.
Table 21 Phases in a Transaction for MBurstSinqleReq set to 1
MCmd
Read Write, Broadcast Write, Broadcast WriteNonPost
*
Phases
Request, H*L* response Request, H*L datahandshake Request, H*L datahandshake, response Request, H*L datahandshake, response
Condition
always datahandshake = 1 writeresp_enable = 0 datahandshake = 1 writeresp_enable = 1 datahandshake = 1
H refers to the burst height (MBlockHeight), and is 1 for all burst sequences other than BLCK. L refers to the burst length (MBurstLength).
OCP-IP Confidential
Protocol Semantics
43
OCP-IP Confidential
44
For example, on an OCP interface with datahandshake enabled, a read following a write to the same location cannot start its response phase until the write has started its datahandshake phase, otherwise the latest write data cannot be returned for the read. If tags are in use, the preceding rules are partially relaxed. Refer to Section 4.7.1 on page 57 for a more detailed explanation.
The notation *_pipelined means the set of all parameter names ending in _pipelined.
OCP-IP Confidential
Protocol Semantics
45
Combinational paths may still be present to enable the phase receiver to consider interface activity in the current cycle before signaling the ThreadBusy signal that affects the next cycle. This corresponds to the timing arcs in Figure 6 where ThreadBusy appears at the end of the OCP cycle. When a _pipelined parameter is enabled, exact flow control is not possible for the first cycle after reset is de-asserted, since the associated ThreadBusy would have to be provided while reset was asserted. When sthreadbusy_pipelined is enabled the master may not assert the request phase in the first cycle after reset. The effect of these parameters is as follows: If mthreadbusy_exact is enabled, mthreadbusy_pipelined is disabled, and the master cannot accept a response on a thread, it must set the MThreadBusy bit for that thread to 1 in that cycle. The slave must not present a response on a thread when the corresponding MThreadBusy bit is set to 1. Any response presented by the slave on a thread that is not busy is accepted by the master in that cycle. If mthreadbusy_exact and mthreadbusy_pipelined are enabled and the master cannot accept a response on a thread in the next cycle, it must set the MThreadBusy bit for that thread to 1 in the current cycle. If an MThreadBusy bit was set to 1 in the prior cycle, the slave cannot present a response on a thread in the current cycle. Any response presented by the slave on a thread that was not busy in the prior cycle is accepted by the master in that cycle. If sdatathreadbusy_exact is enabled, sdatathreadbusy_piplelined is disabled, and the slave cannot accept a datahandshake phase on a thread, the slave must set the SDataThreadBusy bit for that thread to 1 in that cycle. The master must not present a datahandshake phase on a thread when the corresponding SDataThreadBusy bit is set to 1. Any datahandshake phase presented by the master on a thread that is not busy is accepted by the slave in that cycle. If sdatathreadbusy_exact and sdatathreadbusy_piplelined are enabled and the slave cannot accept a datahandshake phase on a thread in the next cycle, the slave must set the SDataThreadBusy bit for that thread to 1 in the current cycle. If an SDataThreadBusy bit was set to 1 in the prior cycle, the master cannot present a datahandshake on the corresponding thread in the current cycle. Any datahandshake presented by the master on a thread that was not busy in the prior cycle is accepted by the slave in that cycle. If sthreadbusy_exact is enabled, sthreadbusy_piplelined is disabled, and the slave cannot accept a command on a thread, the slave must set the SThreadBusy bit for that thread to 1 in that cycle. The master must not present a request on a thread when the corresponding SThreadBusy bit is set to 1. Any request presented by the master on a thread that is not busy is accepted by the slave in that cycle. If sthreadbusy_exact and sthreadbusy_piplelined are enabled and the slave cannot accept a request on a thread in the next cycle, the slave must set the SThreadBusy bit for that thread to 1 in the current cycle. If an SThreadBusy bit was set to 1 in the prior cycle, the master cannot
OCP-IP Confidential
46
present a request on the corresponding thread in the current cycle. Any request presented by the master on a thread that was not busy in the prior cycle is accepted by the slave in that cycle.
OCP-IP Confidential
Protocol Semantics
47
(M_OFF state). It has a single connected state (M_CON) and a transient state (M_WAIT) that allows the slave to control how quickly the master may transition from one stable state to another. The connection protocol is implemented using fully synchronous signals sampled by the rising edge of the OCP clock and no combinational paths are allowed between the connection signals. Since any transitions between the stable connection states requires that the interface be quiescent, the interface reset is not needed explicitly by the connection protocol and connection state transitions may occur independently from the reset state of the interface. Neither data flow nor sideband communication (other than the connection signals) is allowed in a disconnected state. However, the connection signals (MConnect, SConnect and SWait) are always valid to enable proper operation of the connection protocol. Since sideband communication is only reliable in the connected state (M_CON), the 16 cycle reset assertion requirement can only be reliably met in the connected state. MConnect[1:0] provides the OCP socket connection state and is driven by the master. The master must ensure a minimum duration of 2 cycles in a stable state (M_CON, M_OFF or M_DISC) to permit the slave to sample a new stable state and then assert SWait (to S_WAIT) to influence the next potential connection state transition. This is a side effect of the timing requirements of the connection protocol. MConnect[1:0] does not convey the masters vote on the OCP connection state. This vote information is not explicitly visible at the interface. The four valid connection states follow. The M_OFF state is a stable state where the interface is disconnected due to the masters vote, independently from any concurrent vote from the slave. It is likely required that the interface reach the M_OFF state before performing specific power reduction techniques such as powering down the master. The M_DISC state is a stable state where the interface is disconnected resulting solely from the slaves vote on SConnect. Since the master is voting for connection, but prevented by the slave, the master may implement an alternate behavior for upstream traffic intended for the disconnected slave. This alternate behavior is out of the scope of the connection protocol, but may be addressed in a future extension.Transitions to M_DISC are only allowed after the master has sampled the slaves vote to disconnect (SConnect is S_DISC). The M_CON state is a stable state where the interface is fully connected. It is the only state in which the master is allowed to begin any transactions, and the master may not leave M_CON unless all transactions are complete. Transitions to M_CON are only allowed after the master has sampled the slaves vote for a connection (SConnect is S_CON). The master may not present the first transaction on the interface until the cycle after transitioning to M_CON. The M_WAIT state is a transient state where the master is indicating to the slave that it is in the process of changing the connection state. The master can change between stable connection states without entering M_WAIT only if the SWait signal is negated. M_WAIT is disconnected for dataflow communication but sideband communication is allowed in
OCP-IP Confidential
48
M_WAIT only if the prior state was M_CON. The master and slave must cooperate to ensure that all sideband communication is complete before exiting M_WAIT for a disconnected state. SConnect provides the slaves vote on the OCP connection state. The slave may change its vote at any time, but must be ready to support the connected state (M_CON) when driving SConnect to S_CON. SWait allows the slave to control how the master transitions between the stable connection states. By asserting SWait (S_WAIT) in a stable state, the slave forces the master to transition through the M_WAIT state and the master may not leave M_WAIT until it has sampled SWait negated (S_OK). The slave must assert SWait in situations where the master could otherwise transition from M_CON to a disconnected state without allowing the slave to become quiescent. SWait can be tied-off to logic 0 (S_OK) in case the slave can accept immediate transitions by the master between the stable connection states.
OCP-IP Confidential
Protocol Semantics
49
For all commands except those following a posted write model, a DVA response also indicates that the transfer is committed.
OCP-IP Confidential
50
WriteConditional If a reservation is set for the matching address and for the corresponding thread, the write is performed as it would be for a Write or WriteNonPost. Simultaneously, the reservation is cleared for all threads on any conflicting address. If no reservation is set for the corresponding thread, the write is not performed, a FAIL response is returned, and no reservations are cleared. Broadcast Places the value on the MData field in the addressed location that may map to more than one slave in a system-dependent way. Broadcast clears the reservations on any conflicting addresses set by other threads. If a transfer is unsuccessful, the effect of the transfer is unspecified. Higherlevel protocols must determine what happened and handle any clean-up. The synchronization commands ReadEx / Write, ReadEx / WriteNonPost, and ReadLinked / WriteConditional have special restrictions with regard to data width conversion and partial words. In systems where these commands are sent through a bridge or interconnect that performs wide-to-narrow data width conversion between two OCP interfaces, the initiator must issue only commands within the subset of partial words that can be expressed as a single word of the narrow OCP interface. For maximum portability, singlebyte synchronization operations are recommended.
It is legal to use a request with all byte enables deasserted. Such requests must follow all the protocol rules, except that they are treated as no-ops by the slave: the response phase signals SData and SDataInfo are dont care for read-type commands, and nothing is written for write-type commands.
OCP-IP Confidential
Protocol Semantics
51
1
Posted or Non-posted Non-posted
4.5 Endianness
An OCP interface by itself is inherently endian-neutral. Data widths must match between master and slave, addressing is on an OCP word granularity, and byte enables are tied to byte lanes (data bits) without tying the byte lanes to specific byte addresses. The issue of endianness arises in the context of multiple OCP interfaces, where the data widths of the initiator of a request and the final target of that request do not match. Examples are a bridge or a more general interconnect used to connect OCP-based cores.
OCP-IP Confidential
52
When the OCP interfaces differ in data width, the interconnect must associate an endianness with each transfer. It does so by associating byte lanes and byte enables of the wider OCP with least-significant word address bits of the narrower OCP. Packing rules, described in Section 4.6.1.2 on page 54 must also be obeyed for bursts. OCP interfaces can be designated as little, big, both, or neutral with respect to endianness. This is specified using the protocol parameter endian described in Section 4.9.1.6 on page 62. A core that is designated as both typically represents a device that can change endianness based upon either an internal configuration register or an external input. A core that is designated as neutral typically represents a device that has no inherent endianness. This indicates that either the association of an endianness is arbitrary (as with a memory, which traditionally has no inherent endianness) or that the device only works with full-word quantities (when byteen and mdatabyteen are set to 0). When all cores have the same endianness, an interconnect should match the endianness of the attached cores. The details of any conversion between cores of different endianness is implementation-specific.
OCP-IP Confidential
Protocol Semantics
53
Mnemonic
BLCK DFLT1 DFLT2 INCR
Name
2D block custom (packed)
Address Sequence
see below for definition user-specified
Packing
yes yes no
incremented by OCP word size yes each transfer* constant each transfer none specified no implementation specific
like INCR, except wrap at yes address boundary aligned with MBurstLength * OCP word size see below for definition yes
XOR
*
exclusive OR
The address sequence for two-dimensional block bursts is as follows. The address sequence begins at the provided address and proceeds through a set of MBlockHeight subsequences, each of which follows the normal INCR address sequence for MBurstLength transfers. The starting address for each following subsequence is the starting address of the prior subsequence plus MBlockStride. The address sequence for exclusive OR bursts is as follows. Let BASE be the lowest byte address in the burst, which must be aligned with the total burst size. Let FIRST_OFFSET be the byte offset (from BASE) of the first transfer in the burst. Let CURRENT_COUNT be the count of the current transfer in the burst, starting at 0. Let WORD_SHIFT be the logarithm base-two of the OCP word size in bytes. Then the current address of the transfer is BASE | (FIRST_OFFSET ^ (CURRENT_COUNT << WORD_SHIFT)). The burst address sequence UNKN is used if the address sequence is not statically known for the burst. Single request/multiple data bursts (described on page 55) with a burst address sequence of UNKN are illegal. In contrast, the DFLT1 and DFLT2 address sequences are known, but are core or system specific. The burst address sequences BLCK, WRAP, and XOR can only be used for precise bursts. Additionally, the burst sequences WRAP and XOR can only have a power-of-two burst length and a data width that is a power-of-two number of bytes.
OCP-IP Confidential
54
Not all masters and slaves need to support all burst sequences. A separate protocol parameter described in Section 4.9.1.2 on page 59 is provided for each burst sequence to indicate support for that burst sequence.
4.6.1.2 Packing
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 address sequences are classified as either packing or not packing. For burst address sequences that are packing, the conversion between different OCP data widths is achieved through aggregation or splitting. Narrow OCP words are collected together to form a wide OCP word. A wide OCP word is split into several narrow OCP words. The byte-specific portion of MDataInfo and SDataInfo is aggregated or split with the data. The transferspecific portion of MDataInfo and SDataInfo is unaffected. The packing and unpacking order depends on endianness as described on page 51. For burst address sequences that are not packing, conversion between different OCP data widths is achieved using padding and stripping. A narrow OCP word is padded to form a wide OCP word with only the relevant byte enables turned on. A wide OCP word is stripped to form a narrow OCP word. The byte-specific portion of MDataInfo and SDataInfo is zero-padded or stripped with the data. The transfer-specific portion of MDataInfo and SDataInfo is unaffected. Width conversion can be performed reliably only if the wide OCP interface has byte enables associated with it. For wide to narrow conversion the byte enables are restricted to a subset that can be expressed within a single word of the narrow OCP interface. Since the address sequence of DFLT1 is user-specified, the behavior of DFLT1 bursts through data width conversion is implementation-specific.
OCP-IP Confidential
Protocol Semantics
55
Imprecise bursts (MBurstPrecise set to 0) MBurstLength can change throughout the burst and indicates the current best guess of the number of transfers left in the burst (including the current one). An imprecise burst is completed by an MBurstLength of 1.
4.6.4 Atomicity
When interleaving requests from different initiators on the way to or at the target, the master uses MAtomicLength to indicate the number of OCP words within a burst that must be kept together as an atomic quantity. If MAtomicLength is greater than the actual length of the burst, the atomicity requirement ends with the end of the burst. Specifying atomicity requirements explicitly is especially useful when multiple OCP interfaces are involved that have different data widths. For master cores, it is best to make the atomic size as small as required and, if possible, to keep the groups of atomic words address-aligned with the group size.
Additionally, there is a single response phase for WRNP write type while the WR and BCST types have this phase only if writeresp_enable is set to 1. Note that WRC write type is not allowed in a burst.
OCP-IP Confidential
56
For read type transfers when MBurstSingleReq is set to 1, the MByteEn field specifies the byte enable pattern that is applied to all data transfers in the burst.
Every request phase in a BLCK burst sequence that is an integer multiple of MBurstLength
For all datahandshake phases in a non-BLCK burst except the last one, MDataRowLast is 0. MDataRowLast is 0 for every datahandshake phase in a BLCK burst sequence that is not an integer multiple of MBurstLength. MDataRowLast is 1 for:
OCP-IP Confidential
Protocol Semantics
57
The last datahandshake phase in a burst including the only datahandshake phase of a single word request Every datahandshake phase in a BLCK burst sequence that is an integer multiple of MBurstLength
For all response phases in a non-BLCK burst except the last one, SRespRowLast is 0. SRespRowLast is 0 for every response phase in a BLCK burst sequence that is not an integer multiple of MBurstLength. SRespRowLast is 1 for: The last response phase in a burst including: The only response phase in a write-type single request/multiple data burst The only response phase in a single word request
Every response phase in a BLCK burst sequence that is an integer multiple of MBurstLength
4.7 Tags
Tags allow out-of-order return of responses and out-of-order commit of write data. A master drives a tag on MTagID during the request phase. The value of the tag is determined by the master and may or may not convey meaning beyond ordering to the slave. For write transactions with data handshake enabled, the master repeats the same tag on MDataTagID during the datahandshake phase. For read transactions and writes with responses the slave returns the tag of the corresponding request on STagID while supplying the response. The same tag must be used for an entire transaction.
OCP-IP Confidential
58
Responses with different tags can be returned in any order for all commands that have responses. Responses with the same tag must remain in order with respect to one another. Responses to requests that are issued with MTagInOrder asserted are also never reordered with respect to one another. The value returned on STagInOrder with the slaves response must match the value provided on MTagInOrder with the masters request. Commitment of transactions with overlapping addresses (as determined by MAddrSpace, MAddr, MByteEn [or MDataByteEn, if applicable]) on different (or the same) tags within a thread is always in order. Note, however, that the completion responses for such transactions with different tag ids may be reordered.
OCP-IP Confidential
Protocol Semantics
59
Command
Broadcast Read ReadEx ReadLinked and WriteConditional Write WriteNonPost
Parameter
broadcast_enable read_enable readex_enable rdlwrc_enable write_enable writenonpost_enable
The following conditions apply to command support: A master with one of these options set to 0 must not generate the corresponding command. A slave with one of these options set to 0 cannot service the corresponding command. At least one of the command enables must be set to 1. If any read-type command is enabled, or if WRNP is enabled, or if writeresp_enable is set to 1, resp must be set to 1. If readex_enable is set to 1, write_enable or writenonpost_enable must be set to 1.
OCP-IP Confidential
60
Table 25
Burst Sequence
BLCK DFLT1 DFLT2 INCR STRM UNKN WRAP XOR
Parameter
burstseq_blck_enable burstseq_dflt1_enable burstseq_dflt2_enable burstseq_incr_enable burstseq_strm_enable burstseq_unkn_enable burstseq_wrap_enable burstseq_xor_enable
The BLCK burst sequence can only be enabled if both MBlockHeight and MBlockStride are included in the interface or tied off to non-default values. For additional burst information, see Section 4.6 on page 52.
The burst_aligned parameter does not apply to the INCR subsequences within BLCK burst sequences.
OCP-IP Confidential
Protocol Semantics
61
cmdaccept
0 0 0 0 1 1 1 1
sthreadbusy
0 0 1 1 0 0 1 1
sthreadbusy_exact
0 1 0 1 0 1 0 1
Explanation
Legal: no flow control Illegal: sthreadbusy_exact must be 0 when sthreadbusy is 0 Illegal: no real flow control Legal: non-blocking flow control Legal: blocking flow control Illegal: sthreadbusy_exact must be 0 when sthreadbusy is 0 Legal: blocking flow control with hints Illegal: since SCmdAccept is present flow control cannot be exact
When datahandshake is set to 1, the preceding rules for cmdaccept, sthreadbusy, and sthreadbusy_exact also apply to dataaccept, sdatathreadbusy, and sdatathreadbusy_exact. In addition, blocking and nonblocking flow control must not be mixed for the request and datahandshake phase. A phase using no flow control can be mixed with phases using either blocking or non-blocking type flow control. The legal combinations are shown in Table 27.
Table 27 Request Phase with Datahandshake
Only legal if reqdata_together is set to 0. In addition the master must not assert the datahandshake phase until after the associated request phase has been accepted. 3 Only legal if sthreadbusy_pipelined and sdatathreadbusy_pipelined are both set to the same value.
The preceding rules for the request phase using cmdaccept, sthreadbusy, and sthreadbusy_exact also apply to the response phase for respaccept, mthreadbusy, and mthreadbusy_exact.
OCP-IP Confidential
62
4.9.1.6 Endianness
The endian parameter specifies the endianness of a core. The behavior of each endianness choice is summarized in Table 28.
Table 28 Endianness
Endianness
little big both neutral
Description
core is little-endian core is big-endian core can be either big or little endian, depending on its static or dynamic configuration (e.g. CPUs) core has no inherent endianness (e.g. memories, cores that deal only in OCP words)
As far as OCP is concerned, little endian means that lower addresses are associated with lower numbered data bits (byte lanes), while big endian means that higher addresses are associated with lower numbered data bits (byte lanes). This becomes significant when packing is concerned (see Section 4.6.1.2 on page 54). In addition, for non-power-of-2 data widths, tieoff padding is always added at the most significant end of the OCP word. See Section 4.5 on page 51 for additional information.
OCP-IP Confidential
Protocol Semantics
63
Datahandshake
If datahandshake is set to 1, the MDataValid and optionally the SDataAccept signals are added to the OCP interface, a separate datahandshake phase is added, and the MData and MDataInfo fields are moved from the request group to the datahandshake group. Datahandshake can be set to 1 only if at least one write-type command is enabled.
Write Responses
Writes which follow a non-posted model, i.e., WRNP and WRC, always have a write response. For this case, resp must be set to 1. For writes which follow a posted model, i.e., WR and BCST: if responses are not enabled on writes (writeresp_enable set to 0), then they complete on command acceptance.
OCP-IP Confidential
64
2. At the protocol level, the following conditions determine interface interoperability: If the slave has read_enable set to 0, the master must have read_enable set to 0, or it must not issue Read commands. If the slave has readex_enable set to 0, the master must have readex_enable set to 0, or it must not issue ReadEx commands. If the slave has rdlwrc_enable set to 0, the master must have rdlwrc_enable set to 0, or it must not issue either ReadLinked or WriteConditional commands. If the slave has write_enable set to 0, the master must have write_enable set to 0, or it must not issue Write commands. If the slave has writenonpost_enable set to 0, the master must have writenonpost_enable set to 0, or it must not issue WriteNonPost commands.
OCP-IP Confidential
Protocol Semantics
65
If the slave has broadcast_enable set to 0, the master must have broadcast_enable set to 0, or it must not issue Broadcast commands. If the slave has burstseq_blck_enable set to 0, the master must have burstseq_blck_enable set to 0, or it must not issue BLCK bursts. If the slave has burstseq_incr_enable set to 0, the master must have burstseq_incr_enable set to 0, or it must not issue INCR bursts. If the slave has burstseq_strm_enable set to 0, the master must have burstseq_strm_enable set to 0, or it must not issue STRM bursts. If the slave has burstseq_dflt1_enable set to 0, the master must have burstseq_dflt1_enable set to 0, or it must not issue DFLT1 bursts. If the slave has burstseq_dflt2_enable set to 0, the master must have burstseq_dflt2_enable set to 0, or it must not issue DFLT2 bursts. If the slave has burstseq_wrap_enable set to 0, the master must have burstseq_wrap_enable set to 0, or it must not issue WRAP bursts. If the slave has burstseq_xor_enable set to 0, the master must have burstseq_xor_enable set to 0, or it must not issue XOR bursts. If the slave has burstseq_unkn_enable set to 0, the master must have burstseq_unkn_enable set to 0, or it must not issue UNKN bursts. If the slave has force_aligned, the master has force_aligned or it must limit itself to aligned byte enable patterns. Configuration of the mdatabyteen parameter is identical between master and slave. If the slave has burst_aligned, the master has burst_aligned or it must limit itself to issue all INCR bursts using burst_aligned rules. If the interface includes SThreadBusy, the sthreadbusy_exact and sthreadbusy_pipelined parameters are identical between master and slave. If the interface includes MThreadBusy, the mthreadbusy_exact and mthreadbusy_pipelined parameter are identical between master and slave. If the interface includes SDataThreadBusy, the sdatathreadbusy_exact and sdatathreadbusy_pipelined parameters are identical between master and slave.
OCP-IP Confidential
66
All combinations of the endian parameter between master and slave are interoperable as far as the OCP interface is concerned. There may be core-specific issues if the endianness is mismatched. If tags > 1, the masters tag_interleave_size is smaller than or equal to the slaves tag_interleave_size.
3. At the phase level the two interfaces are interoperable if: Configuration of the datahandshake parameter is identical between master and slave. Configuration of the writeresp_enable parameter is identical between master and slave. Otherwise, the master only issues the write commands WriteNonPost and WriteConditional. Configuration of the reqdata_together parameter is identical between master and slave.
4. At the signal level, two interfaces are interoperable if: data_wdth is identical for master and slave, or if one or both data_wdth configurations are not a power-of-two, if that data_wdth rounded up to the next power-of-two is identical for master and slave. The master and slave both have mreset or sreset set to 1. If the master has mreset set to 1, the slave has mreset set to 1. If the slave has sreset set to 1, the master has sreset set to 1. The value of connection is identical for master and slave, or if ConnectCap is tied off to logic 0 on the side with connection set to 1. Both master and slave have tags set to >1 or if only one cores tags parameter is set to 1, the other core behaves as though MTagInOrder were asserted for every request. The tie-off rules, described in the next section are observed for any mismatch at the signal level for fields other than MData and SData.
OCP-IP Confidential
Protocol Semantics
67
If there are more outputs than inputs (the driver of the field has a wider configuration than the receiver of the field) the low-order output bits are connected to the input bits, and the high-order output bits are lost. The interfaces are interoperable if the sender of the field explicitly limits itself to encodings that only make use of the bits that are within the configuration of the receiver of the field. If there are more inputs than outputs (the driver of field has a narrower configuration than the receiver of the field) the low-order input bits are connected to the output bits, and the high-order input bits are tied to logical 0. The interfaces are always interoperable, but only a portion of the legal encodings are used on that field.
If one of the cores has a signal configured and the other does not, the following rules apply: If the core that would be the driver of the field does not have the field configured, the input is tied off to the constant specified in the driving cores configuration, or if no constant tie-off is specified, to the default tieoff constant (see Table 16 on page 31). The interfaces are interoperable if the encodings supported by the receivers configuration of the field include the tie-off constant. If the core that would be the receiver of the field does not have the field configured, the output is lost. The receiver of the signal must behave as though in every phase it were receiving the tie-off constant specified in its configuration, or lacking a constant tie-off, the default tie-off constant (see Table 16 on page 31). The interfaces are interoperable if the driver of the signal can limit itself to only driving the tie-off constant of the receiver. If only one core has the EnableClk signal configured, the interfaces are interoperable only when the EnableClk signal is asserted, matching the tie-off value of the core that has enableclk=0.
If neither core has a signal configured, the interfaces are interoperable if both cores have the same tie-off constant, where the tie-off constant is either explicitly specified, or if no constant tie-off is specified explicitly, is the default tie-off (see Table 16 on page 31). While the tie-off rules allow two mismatched cores to be connected, this may not be enough to guarantee meaningful communication, especially when core-specific encodings are used for signals such as MReqInfo. As the previous rules suggest, specifying core specific tie-off constants that are different than the default tie-offs for a signal (see Table 16 on page 31) makes it less likely that the core will be interoperable with other cores.
OCP-IP Confidential
68
Table 29 lists all configuration parameters. For parameters that do not need to be specified, a default value is listed, which is used whenever an explicit parameter value is not specified. Certain parameters are always required in certain configurations, and for these no default is specified.
Table 29 Configuration Parameter Defaults
Type
Protocol
Parameter
broadcast_enable burst_aligned burstseq_blck_enable burstseq_dflt1_enable burstseq_dflt2_enable burstseq_incr_enable burstseq_strm_enable burstseq_unkn_enable burstseq_wrap_enable burstseq_xor_enable endian force_aligned mthreadbusy_exact rdlwrc_enable read_enable readex_enable sdatathreadbusy_exact sthreadbusy_exact tag_interleave_size write_enable writenonpost_enable
Default
0 0 0 0 0 1 0 0 0 0 little 0 0 0 1 0 0 0 1 1 0 0 0 0
Phase
OCP-IP Confidential
Protocol Semantics
69
Type
Signal (Dataflow)
Parameter
addr addr_wdth addrspace addrspace_wdth atomiclength atomiclength_wdth blockheight blockheight_wdth blockstride blockstride_wdth burstlength burstlength_wdth burstprecise burstseq burstsinglereq byteen cmdaccept connid connid_wdth dataaccept datalast datrowalast data_wdth enableclk mdata mdatabyteen mdatainfo
Default
1 No default - must be explicitly specified if addr is set to 1 0 No default - must be explicitly specified if addrspace is set to 1 0 No default - must be explicitly specified if atomiclength is set to 1 0 No default - must be explicitly specified if blockheight is set to 1 0 No default - must be explicitly specified if blockstride is set to 1 0 No default - must be explicitly specified if burstlength is set to 1 0 0 0 0 1 0 No default - must be explicitly specified if connid is set to 1 0 0 0 No default - must be explicitly specified if mdata or sdata is set to 1 0 1 0 0
OCP-IP Confidential
Type
Signal (Dataflow)
Parameter
mdatainfo_wdth mdatainfobyte_wdth mthreadbusy mthreadbusy_pipelined reqinfo reqinfo_wdth reqlast reqrowlast resp respaccept respinfo respinfo_wdth resplast resprowlast sdata sdatainfo sdatainfo_wdth sdatainfobyte_wdth sdatathreadbusy
Default
No default - must be explicitly specified if mdatainfo is set to 1 0 0 0 No default - must be explicitly specified if reqinfo is set to 1 0 0 1 0 0 No default - must be explicitly specified if respinfo is set to 1 0 0 1 0 No default - must be explicitly specified if sdatainfo is set to 1 0
Protocol Semantics
71
Type
Signal (Sideband)
Parameter
connection control controlbusy control_wdth controlwr interrupt merror mflag mflag_wdth mreset serror sflag sflag_wdth sreset status statusbusy statusrd status_wdth
Default
0 0 0 No defaultmust be explicitly specified if control is set to 1 0 0 0 0 No defaultmust be explicitly specified if mflag is set to 1 No defaultmust be explicitly specified 0 0 No default - must be explicitly specified if sflag is set to 1 No default - must be explicitly specified 0 0 0 No default - must be explicitly specified if status is set to 1 0 0 0 0 0 No default - must be explicitly specified if scanport is set to 1
Signal (Test)
OCP-IP Confidential
72
OCP-IP Confidential
OCP-IP Confidential
74
Multiple coherence domains may coexist in a single architecture. However, only one cache line size is permitted in each coherence domain, and a coherence domain cannot share its coherence address space with any other coherence domain.
Note that an OCP coherent system permits the existence of subsystem coherence, where a subsystem will maintain its own coherence framework and can act as a single OCP coherent agent to the system at the next hierarchical level. In fact, the subsystem coherence framework at the lower level could itself be composed of OCP agents. Hierarchical coherent subsystems are built in this manner.
See, for example, S. Adve and K. Gharachorloo, Shared Memory Consistency Models: A Tutorial, IEEE Computer, vol. 29, no. 12, pp. 66-76, December 1996.
OCP-IP Confidential
75
Only the bridge or interconnect agent maintains a system view. This is a very convenient abstraction in SoC architectures that are loosely coupled with agents that are really hard or soft IPs. With OCP 3.0 and the introduction of cache coherence, the local view is maintained for all master agents and all non-coherent slave agents. Only the home agent (introduced on page 79), which is a slave coherent agent, and the bridge agent need to maintain the system view abstraction. In this context, the system view refers to the explicit encoding of the master, slave, and forwarding agent identifiers (IDs) and the encoding of the address regions on an agents interface.
OCP-IP Confidential
76
Note that if a master with coherent cache supports the critical word first feature, addresses of commands from the master may not be aligned to multiple of the cache line size, but the cache line boundaries should be aligned to the multiple of the cache line size by using WRAP or XOR burst address sequences. A cache line in a masters coherent cache is always in one of several known states; the set of available states are summarized in Table 30. Some states are required and some are optional depending on the type of coherence protocol chosen.
Table 30 Cache Line State Definitions
Mnemonic Description I S M Cache line not present in caching entity. Cache line is read only.
Cache line owned exclusively by Required1 caching entity and modified by it. Memory copy is stale. All other caching entities have this line in I state. Optional Cache line is exclusively owned. Memory copy matches value. All other caching entities have this line in I state. This entity has latest copy. Memory copy is stale. Other caching agents may have (latest) copy. Optional
Exclusive E
Owned
OCP-IP Confidential
77
Three hop protocols have better latency characteristics, but are more complicated to implement than four-hop protocols since they give rise to additional race conditions, deadlock, and starvation scenarios. The transfer of a modified cache line to a requester takes three protocol steps: 1. masters request to coherent slave; 2. slaves probe of other masters (which have coherent caches); and, 3. response from a master which has a cache line in the modified state directly to the requester (and a possible writeback of this data to the slave) with concurrent responses from all masters to the slave.
78
port commands and encodings are explained in Section 5.6. Legacy requests which are targeted to non-coherent address space are issued on the main port. The coherent master also needs to satisfy requests from other coherent masters to snoop its cache lines and possibly respond either with the latest copy of the cache line or by giving up its ownership of the cache line. In OCP 3.0, these requests to the master and the corresponding responses are handled via the intervention port. The full set of intervention port commands are explained in Section 6.3.3.1 on page 115. A CPU is a typical example of an entity which would be an OCP coherent master. Section 5.9 presents an abstract model that illustrates the interaction between the main port and the intervention port, and between the coherent master and coherent slave. A coherence-aware master does not have a coherent cache. For example, a DMA engine could be implemented as a coherence-aware master. A coherence-aware master has a main port but does not have an intervention port. A coherence-aware master uses legacy commands. If the associated address is in the coherent region, then the coherent slave performs the appropriate actions depending on the request and the state of the associated cache line (as seen by the home agent), e.g., a coherent read returns the latest value written. (While processing a request from the coherence-aware master, a coherent slave may send intervention requests for the latest write to be returned, as discussed in detail in Section 13.3.4.1 on page 276.) If the associated address for a request is in the non-coherent address space, then the request has the semantics of a legacy request. The coherent slave is the target of coherent request commands from all or any master in the coherence domain, depending on the type of coherence protocol used. It receives requests on its main port. Before it generates the response, it in turn sends requests on the intervention port to snoop all or a subset of the coherent caches in the coherence domain and may send a request to the memory controller. After it receives the responses to the intervention requests and/or from the memory controller, it finally sends the response to the original request on its main port. The coherent slave also ensures that writes to the same location appear to be seen in the same order by all the coherence masters. The coherent slave implementation usually takes the form of either a snoop- or directory-based scheme, as described in Section 5.11. OCP 3.0 maintains full backward compatibility with OCP 2.2, that is, the command set for the coherence extensions is a superset of the OCP 2.2 command set. OCP 3.0 defines a new signal, MCohCmd, which, when set, indicates a coherent command. Non-coherent commands, which refer to the OCP 2.2 command set, do not have the MCohCmd bit set. In the rest of the document, the port defined by OCP 2.2 is referred to as the legacy port. Note that the main port defined by OCP 3.0 is capable of generating legacy transactions. Hence, a new design would not need both the legacy and main ports.
OCP-IP Confidential
79
A master with a legacy port that only generates transactions to non-coherent space is called a legacy master. A slave with a legacy port is called a legacy slave. Other terms used in this document include: The term requester is interchangeably used for a coherent master which initiates a request. The term responder is interchangeably used for a coherent master which responds to an intervention request. The term owner is interchangeably used for a coherent master which has a cache line in the M or the O state. The term snoop is interchangeably used with intervention. The term home agent is interchangeably used with coherent slave. Thus each coherent address has an associated home which is the coherent slave managing its coherency actions.
5.6 Commands
A master which can only issue legacy commands to noncoherent space is called a legacy master. A master which can issue only legacy commands to both coherent and noncoherent address spaces is called a coherence aware master. A master which can issue legacy commands to both non-coherent and coherent address spaces, and can issue coherent commands to coherent address spaces is called a coherent master. It is illegal for coherent commands to be issued to non-coherent address spaces. Legacy commands accessing the noncoherent address space are called Legacy Commands to Noncoherent Space (LC-NC for short). Legacy commands accessing the coherent address space are called Legacy Commands to Coherent Space (LC-C for short). Table 31 summarizes the allowed combination of OCP masters and command types. The LC-C semantics are different from LC-NC since they operate on a different address space. The LC-C and the Coherent Commands are described in Section 6.2.3.2 on page 99.
OCP-IP Confidential
80
Table 31
Allowed Commands
Master Type
Legacy Commands Legacy Commands to Noncoherent to Coherent Space Space (LC-NC) (LC-C)
Yes Yes Yes No Yes Yes
Table 32 summarizes the scope of the address space access for each command type.
Table 32 Address Space Access by Command Type
Command Type
LC-NC LC-C, CC
OCP-IP Confidential
81
deliver the transactions to B in the same order. These conditions, along with the self intervention mechanism, ensure that all coherent masters see writes to the same cache line in the order established at the home agent. Thus, each coherent master has to implement logic to maintain the ordering imposed by the home. The serialization point at the home is called the primary serialization point and the one at each master is called the secondary serialization point. Unless otherwise noted, the term serialization point refers to the primary serialization point. In a snoop based design, the home agent for all coherent requests is typically the interconnect agent itself, which acts as the coherent slave. Thus, snoop based designs have a single serialization point. In a directory based design, the home agents for coherent addresses may be physically centralized or may be distributed and are typically separate from the interconnect. Each physical home agent becomes the serialization point for the set of coherent addresses it controls.
OCP-IP Confidential
82
Table 33
Main Port No
Intervention Port No
Function
Initiates requests to noncoherent address space only Receives responses from non-coherent address space only Initiates legacy and coherent requests to coherent and non-coherent spaces using legacy commands Receives responses from coherent and non-coherent spaces Initiates requests to both non-coherent and coherent address spaces on main port (including coherent commands) Receives responses on main port Receives intervention requests Generates intervention responses Receives legacy requests Initiates legacy responses Receives requests on main port Generates intervention requests Receives intervention responses Generates legacy port requests1 Receives legacy port responses1 Generates responses on main port
Yes
No
Coherent Master
No
Yes
Yes
Yes
No
No Yes
Possible1 Yes
1. These are requests to a non-coherent slave (typically the memory). This can be handled through a legacy OCP port or through a custom interface.
Figures 79 capture the port connectivities and port directions for three generic cases: Figure 7 for an OCP non-coherent (legacy) system Figure 8 for an OCP coherent system which is snoop based with the interconnect acting as the coherent slave or home.
OCP-IP Confidential
83
Figure 9 for an OCP coherent system with a centralized directory based coherent slave.
{ {
OCP
Slave
Bus Initiator
Slave
Master
Master
Bus Target
Bus Initiator/Target
On-Chip Bus
Figure 8 Block Diagram of Snoop-Based OCP Coherent System
Legacy Master Core
Non-Coherent Master
Master
LP
Slave
LP MP
Master
IP
Master
MP
OCP
LP LP MP IP MP
Slave
Non-Coherent Bus Initiator
Master
Non-Coherent Target
Slave
Coherent Cache Initiator
Slave
Coherence-Aware initiator
Broadcast Interconnect
OCP-IP Confidential
84
Master
LP
Slave
LP
Master
MP IP
Master
MP MP
Slave
IP LP
OCP
LP LP MP IP MP MP IP LP
Slave
Non-Coherent Bus Initiator
Master
Non-Coherent Target
Slave
Coherent Initiator
Slave
Coherent Initiator
Master
MP Coherent Target IP LP
Interconnect
OCP-IP Confidential
85
Figure 10
OCP Wrapper
fencing point for conflicting main port request triggered by main port request
reset
reset
Request
Response
Request
Response
Intervention Port
An abstract implementation of the secondary serialization point is described below. Each request is associated with two fencing points: one at the main port request path and the other at the intervention port request path. Each fencing point is associated with a fencing interval. The main port fencing interval begins when the request enters the lower queue on the request side and lasts till all the associated response is received on the main port response queue. During this interval, the fencing logic does not accept additional conflicting requests on the main port from the master entity (the processor/cache complex). The intervention port fencing interval begins when the self intervention enters the intervention port request side and is detected by the fencing logic. It lasts until the associated response is received on the main port response queue. During this interval, the fencing logic does not accept conflicting requests from the intervention ports request queue. Note that conflicting intervention requests arriving at the master before the self intervention request are
OCP-IP Confidential
86
serviced in order at the intervention port and the appropriate responses generated (i.e., cache look up, possible cache state change, generation of response). Upon receipt of the response for the request, the fences need to be cleared. The fencing logic is implementation specific. A non-coherent request follows the same behavior as a legacy master.
OCP-IP Confidential
87
Figure 11
speculative
non-speculative
Directory Controller
serialization point
A request received on the main port is looked up in the directory controller to determine which of the coherent masters need to be sent intervention requests in addition to the self intervention request. These requests go out on the intervention port. In addition, a request to memory may also need to be sent. The figure shows a speculative path option to memory in which case the memory request is sent before the directory lookup, optimizing for latency. Alternatively, bandwidth conscious designs could do a lookup and determine if a memory request is warranted (e.g., if the line is in M state in a master, then a memory access is not necessary). The directory controller is the serialization point and determines a single order to process conflicting requests across the coherence domain. Cache writeback requests arriving on the main port will be written to memory on the legacy port, after a directory lookup to update the state of the line. Responses arriving at the intervention port and at the legacy port are appropriately merged and zero or more responses are generated depending on the nature of the request (for example, on a read request it could be the read data from memory combined with a completion response or it could be no response if a modified line was returned directly by a responding coherent master to the requesting coherent master). The main port of the requesting coherent master receives only one response for each request. With cache-tocache transfers, the modified line that is received (DVA) also serves as a transaction completion indicator. As already mentioned, receiving only one response makes the design of the coherent master relatively simple. It has the potential to introduce race conditions at the directory, however. It is expected that the implementation will take care to prevent such races and possible deadlocks. Some scenarios are outlined below:
OCP-IP Confidential
88
In the case of a cache-to-cache transfer, the directory may choose to not generate a completion response after the transaction is complete from its perspective. If the slave does generate a response, then the interconnect agent must taken on the responsibility to drop this response. Additionally, the race condition arising below has to be handled by the directory: Assume that a master (say, B) supplies a modified cache line to the original requester A. The response arrives at A and the data is consumed and the transaction is deallocated. It is possible that A generates another request to the same cache line even before the additional response from B to the directory controller has arrived at the latter. In such a case, the directory should hold off servicing the request from A until it has processed the response. This is typically handled by having separate request and response queues at the directory. Note that the directory structure is only logically centralized. The serialization point refers to a single cache line address. Hence the directory controller may be physically distributed with each controller being home to a distinct set of cache line addresses. The set of addresses controlled by each controller is non-overlapping and together cover the complete coherent address space. Note that the coherent slave is required to have a system viewthus, it needs to identify coherent masters as a requesters, the targets of intervention requests, and as responders who provide cache line data and cache state. This information is used to keep the directory up-to-date, to broadcast intervention requests selectively, etc. OCP provides explicit signals for this purpose on both the main port (MCohId, SCohId) and the intervention port (MCohId, SCohId, MCohFwdId, SCohFwdId).
OCP-IP Confidential
89
Figure 12
speculative
non-speculative
Broadcast Logic
serialization point
Frequently, the coherent slave functionality (the shaded portion in Figure 12) is provided by the interconnect agent itself. In such a case, the main port and the intervention port of the coherent slave is not exposed as OCP ports. Only the legacy port gets exposed to the memory subsystem. In this specification, such an interconnect is called a broadcast interconnect or a snoop-based interconnect. Just as in the case of the directory based coherent slave, the snoop based slave and the interconnect need to provide similar functionality to ensure that the coherent master's main port receives at most one response to a request.
OCP-IP Confidential
90
Multithreading and tagging are supported in the OCP coherence extensions, with the above restrictions.
OCP-IP Confidential
91
OCP-IP Confidential
92
Figure 13
Proc00 L1i,L1d
Proc01 L1i,Lid
L2
L2
L2
L2
L2
L2
Shared L3
MP
IP
MP
IP
MP
IP
OCP Wrapper
LP
MP
IP
OCP Wrapper
I/O 0
Memory 0
MP
IP
NUMA Node 0
NUMA Node 1
OCP Interconnect
Main Port (bi-directional, with coherence extensions) Intervention Port (bi-directional) Legacy Port (bi-directional)
NUMA Node 2
NUMA Node 3
OCP-IP Confidential
The non-posted message command always receives a response. The following MCmd command is of type Non-Posted Message:
OCP-IP Confidential
94
CohInvalidate
OCP-IP Confidential
95
1. The initial write request occurs on the Main port but no write data phase appears on the Main port. 2. The home agent sends a self-intervention request to the initiator on the intervention port. No write data phase occurs with this request. 3. The initiator responds with the writeback data on the intervention port, (if the cache line hasnt been invalidated in between steps 1 and 2). This option allows self-intervention data responses and normal snoop responses to use the same data paths and thus be ordered.
96
scohid_enable If this parameter is set, the SCohID signal is instantiated. cohfwdid_enable If this parameter is set, the MCohFwdID and SCohFwdID signals are instantiated. mcohid_wdth Width of the MCohID signal. scohid_wdth Width of the SCohID signal. cohfwdid_wdth Width of the CohFwdID signal.
Group
Basic
Signal
Clk MAddr MCmd Bus widened for coherent commands.
Comments
Required
addr=1 To enable the coherent commands: cohnc_enable coh_enable cohwrinv_enable mdata=1 datahandshake=1 resp respaccept cmdaccept resp = 1 sdata = 1 datahandshake=1 dataaccept resp=1
addr_wdth
Required Required
data_wdth
data_wdth
OCP-IP Confidential
97
Group
Simple
Signal
MAddrSpace MByteEn MDataByteEn
Comments
Optional Required Required
MDataInfo MReqInfo SDataInfo reqinfo reqinfo_wdth resp=1 sdatainfo sdatainfo_wdth resp=1 respinfo respinfo_wdth atomiclength burstlength burstprecise=1
SRespInfo
Optional
Burst
atomiclength_wdth Tied off to cache line size burstlength_wdth Tied off to cache line size Required. Set to 1 for Coherent commands Required. Only INCR, XOR, and WRAP are allowed. Required. Set to 1 for Coherent commands. Required Optional Optional
MBurstSeq
burstseq
MBurstSingleReq
datahandshake=1 burstsinglereq=1
OCP-IP Confidential
98
Group
Coherence
Signal
SCohState MCohCmd MCohID
Comments
Required Default Tie-off=0 Required Default Tie-off=0
mcohid_wdth
Optional; required for directory based protocols and three-hop protocols Optional; required for directory based protocols and three-hop protocols Optional; required for three-hop protocols Optional; required for three-hop protocols Optional Optional Optional Optional Optional
SCohID
scohid_enable
scohid_wdth
MCohFwdID
cohfwdid_enable cohfwdid_wdth
SCohFwdID
cohfwdid_enable cohfwdid_wdth
Thread
connid=0 when threads > 1 threads datahandshake=0 mthreadbusy threads when threads > 1 threads threads
sdatathreadbusy threads threads datahandshake=1 sthreadbusy threads when threads > 1 resp tags tags datahandshake tags resp taginorder taginorder resp threads threads tags tags tags
OCP-IP Confidential
99
Group
Sideband
Signal
SReset_n or MReset_n (all others)
Comments
Required Optional Optional
Test
(all)
6.2.3.1 MCohCmd
When set to one, indicates that the command is coherent. When set to zero, the semantics of the command depend on whether the target address is in coherent address space or non-coherent address space.
6.2.3.2 MCmd
When the OCP interface supports coherency, the width of the MCmd signal is extended to five-bits to accommodate the extra coherence commands. Commands are arranged into two groups: Non-Coherent and Coherent. NonCoherent commands are the same set of commands as in the existing OCP 2.2 command set and are also referred to as Legacy commands. Within the Coherent set of transactions, some existing OCP 2.2 commands remain, but are re-defined as Coherence-Aware2. The Coherence-Aware commands are used by initiators that do not contain caches but access the coherent address space. The new coherent commands must always be issued with MCohCmd asserted. See Table 35 below for the extensions to the encoding of MCmd.
Table 35 Extended MCohCmd and MCmd Encoding
Mnemonic
Data Source
None
0 0 0 0 0 0
Requester No
They are redefined as Non-Cached because the bulk of the use of these commands will be to satisfy Non-Cached accesses; however, they could be used by caching agents as well; examples being write-through caches and cached DMA controllers.
OCP-IP Confidential
Mnemonic
Data Source
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1
0x6 0x7
WriteConditional Broadcast
WRC BCST (Reserved) WR RD RDEX RDL WRNP WRC BCST CC_RDOW CC_RDSH CC_RDDS CC_RDSA CC_UPG CC_WB (Reserved) CC_CB CC_CBI CC_I CC_WRI CC_SYNC (Reserved)
Requester No Requester No
0x8-0xF (Reserved) 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xA 0xB 0xC 0xD 0x0E 0x0F 0x10 0x11 0x12 0x13 0x14 0x15 0x1F Write Read ReadEx ReadLinked WriteNonPost WriteConditional Broadcast CohReadOwn CohReadShare CohReadDiscard CohReadShareAlways CohUpgrade CohWriteBack (Reserved) CohCopyBack CohCopyBackInv CohInvalidate CohWriteInvalidate CohCompletionSync (Reserved)
Requester Yes Home or Owner Home or Owner Home or Owner Yes Yes Yes
Requestor Yes Requester Yes Not Permitted Home or Owner Home or Owner Home or Owner Home or Owner None or Owner Yes Yes No Yes Yes
Requester Yes
The semantics of legacy commands targeting coherent address space are described below. Please see Section 5.6 on page 79 for a list of restrictions related to cache line granularity and Section 5.13 on page 90 for bursts.
OCP-IP Confidential
Write (0x1, WR) This form of coherent request is meant to transfer cache line-sized data to memory (finer granularity can be achieved through the use of byte enables). While the semantics of this command are very similar to the legacy Write (WR) command, the home invalidates cache lines for write invalidate semantics. This command is generated by non-cached or writethrough stores etc. This command is enabled by the port parameter write_enable. Read (0x2, RD) Very similar to a Legacy Read command, but the system returns data from the owning agent rather than home when the former has the most recent copy. This command is generated by non-cached loads or instruction fetches; read misses for write-through memory locations, etc. This command is enabled by the port parameter read_enable. ReadEx (0x3, RDEX) Very similar to a Legacy ReadEx command, but the system returns data from the owning agent rather than home when the former has the most recent copy. This command is generated by non-cached loads. The command is enabled by the port parameter readex_enable. ReadLinked (0x4, RDL) Similar to its non-coherent counterpart (RDL), this command can be used to set a reservation at home, but in a coherent system. This command is generated by non-cached synchronizing3 loads etc. This command is enabled by the port parameter rdlwrc_enable. WriteNonPost (0x5, WRNP) This form of coherent request is meant to transfer cache line-sized data to memory (finer granularity can be achieved through the use of byte enables). While the semantics of this command are very similar to the legacy WriteNonPost (WRNP) command, the system invalidates cache lines for write invalidate semantics. This command is generated by noncached or write-through stores. This command is enabled by the port parameter writenonpost_enable. WriteConditional (0x6, WRC) Similar to its non-coherent counterpart (WRC), this command can be used to clear a reservation at home, but in a coherent system. This command is generated by non-cached synchronizing stores etc. This command is enabled by the port parameter rdlwrc_enable. Broadcast (0x7, BCST) This command is undefined when the target is in coherent space. CohReadOwn (0x8, CC_RDOW) This coherent command is used to read data from home with the intent to modify. This command is generated by processor stores that miss in the cache hierarchy. The data transfer size is a cache line.
3
The term synchronizing loads refers to conditional load instructions, which are available in the instruction sets of various architectures.
OCP-IP Confidential
On all CPUs with coherent caches (excluding the original requester), if there is a cache line with a matching address that is in the Modified or Owned state, the implementation has the choice of: writing back the cache line to home, or, forwarding the data to the requestor directly from the cache, or, doing both.
These options do not affect the behavior of the intervention ports and main ports so there are no port parameters for these options. On all CPUs with coherent caches (not including the original requester), if there is a cache line with the matching address and it is in a state other than Invalid, the cache line state transitions to Invalid. The original requester receives the most up-to-date data. CohReadShared (0x9, CC_RDSH) This coherent command is used to read data from home with no intent to modify. This command is generated by processor loads that miss in the cache hierarchy. The data transfer size is a cache line. For the MOESI protocol: On all CPUs with coherent caches (excluding the original requestor), if there is a cache line with the matching address and it is in the Modified state, the cache line state transitions to Owned. On all CPUs with coherent caches (excluding the original requestor), if there is a cache line with the matching address and it is in the Modified or Owned states, the data is forwarded to the requestor directly from the cache. For the MOESI and MESI protocols: On all CPUs with coherent caches (excluding the original requester), if there is a cache line with the matching address and it is in the Exclusive state, the cache line state transitions to Shared. The implementation may also choose to forward the data to the requestor directly from the cache, this option is enabled by the intport_estate_c2c port parameter. For the MSI and MESI protocol: On all CPUs with coherent caches (excluding the original requestor), if there is a cache line with the matching address and it is in the Modified state, the cache line state transitions to Shared. The cache line is written back to home. The implementation may also choose to forward the data to the requestor directly from the cache. This option does not affect the behavior of the intervention ports and main ports so there is no port parameter for this option.
OCP-IP Confidential
If the cache line with the matching address is in the Shared state, the cache line state stays as previous4. For all protocols, the original requester receives the most up-to-date data. CohReadDiscard (0xA, CC_RDDS) This coherent command is used to read data from the processor caches and not cause any cache line state changes. It is normally generated by external agents (such as coherent DMA controllers) to read data from the processor cache hierarchy. The data transfer size is a cache line. The cache line state is not modified. The original requester receives the data. CohReadShareAlways (0xB, CC_RDSA) This coherent command is used to read data from home with intent to never modify. The install state is always shared. This command is generated by processor instruction fetches for coherent instruction caches. The cache line state transitions are the same as for CohReadShared. The data transfer size is a cache line. Coherent instruction caches are not snooped as there can never be any modified data and the install state is always shared. The original requester receives the requested data. CohUpgrade (0xC, CC_UPG) This coherent command is used to request ownership of a shared cache line from the system. It is usually generated for processor stores which hit cache lines with shared states. This command is of the new type Query. The possible responses are OK (no data) or DVA (data). The data transfer size is either zero or a cache line. On all CPUs with coherent caches (excluding the original requester), if there is a cache line with the matching address and it is in the Modified or Owned state, the implementation has the choice of writing back the cache line to home or forwarding the data to the requestor or doing both5. For this case, the response is DVA. This DVA response only occurs if another agent has modified its copy of the data after receiving the CohUpgrade request (A race within the other agent between its local operations and the initiators command). The more common response is OK (the original requestor has an up-todate copy of the data), and there is no data phase. On all CPUs with coherent caches (not including the original requester), if there is a cache line with the matching address and it is in a state other than Invalid, the cache line state transitions to Invalid. The original requester receives the updated data.
4
Some implementations may choose to forward the data to the requestor directly from the cache, this option requires an additional cache line state (Forwarding/Recent) that is beyond the scope of this document. 5 These options do not affect the behavior of the intervention and main ports, so there is no port parameter for these options.
OCP-IP Confidential
This command is enabled by the port parameter upg_enable. If this command is not enabled, any store which hits a shared cache line will generate a CohReadOwn command. CohWriteBack (0xD, CC_WB) This coherent command is used to writeback cache lines into home memory. It has posted write semantics. When intport_writedata is set to 0, the write data phase happens on the main port along with the request phase. The data transfer size is a cache line. The user has the option of the write data phase to occur on the intervention port after a self-intervention (port parameter intport_writedata=1). For this case, this command is of the new type Message. This option allows self-intervention data responses and normal snoop responses to use the same datapaths and thus be ordered. CohCopyBack (0x10, CC_CB) This coherent command is used to writeback cache lines into home and the cache line is not evicted from the cache hierarchy. This command is generated by processor-specific cache management instructions. It has posted write semantics. The data transfer size is either zero or a cache line. On masters with coherent caches, if the cache line with the matching address is originally in the Modified or Owned state then the cache line will be written back to home. The cache line state transitions to Shared. When intport_writedata is set to 0, the write data phase occurs on the main port along with the request phase. When intport_writedata is set to 1, the write data phase happens on the intervention port as part of the snoop response. On masters with coherent caches, if the cache line with the matching address is in the Shared or Exclusive state, the cache line state is unchanged and there is no data phase. CohCopyBackInv (0x11, CC_CBI) This coherent command is used to writeback cache lines into home and the cache line is evicted from the cache hierarchy. This command is generated by processor-specific cache management instructions. It has posted write semantics. The data transfer size is either zero or a cache line. On masters with coherent caches, if the cache line with the matching address is originally in the Modified or Owned state then the cache line will be written back to home. The cache line state transitions to Invalid. When intport_writedata is set to 0, the write data phase occurs on the main port along with the request phase. When intport_writedata is set to 1, the write data phase happens on the intervention port as part of the snoop response. On all CPUs with coherent caches, if the cache line with the matching address is in the Shared or Exclusive states then the cache line state transitions to Invalid. For this case, there is no data phase.
OCP-IP Confidential
CohInvalidate (0x12, CC_I) This coherent command is used to purge data from the cache hierarchy. This command is generated by processor-specific cache management instructions and also generated by coherent DMA controllers. This command has non-posted write semantics. The data transfer size is zero. On masters with coherent caches, if a cache line contains the requested address, its state is set to invalid, regardless of the previous state. There is no data phase for this command. The port parameter cohwrinv_enable must be set as well for the CohWriteInvalidate command to be used on the main port. CohWriteInvalidate (0x13, CC_WRI) This coherent command is used to inject new data into a coherent system by simultaneously invalidating a cache line from the system and updating its value at home. The use of byte enables allows the update of partial cache lines. Typically used by coherent DMA controllers to write new values into home and remove stale copies from the cache hierarchy. This command has non-posted write semantics. The data transfer size is less than or equal to a cache line. On all CPUs with coherent caches, if the cache line with the matching address is originally in the Modified or Owned state and the write does not modify the entire cache line, then the cache line data will be supplied so that the new write data can be merged. The cache line state transitions to Invalid. For this case, SResp is equal to DVA. The data transfer happens on the intervention port as the snoop response. For this case, the home agent is responsible to merge the newer write data with the older snoop response data before the data is written to system memory. On all CPUs with coherent caches, if the cache line with the matching address is in the Shared or Exclusive states or if the new write modifies all bytes within the cache line, then the cache line state transitions to invalid. For this case, SResp is equal to OK and there is no data phase. The port parameter cohwrinv_enable must be set as well for the CohWriteInvalidate command to be used on the main port. CohCompletionSync (0x14, CC_SYNC) This coherent cache command is used to maintain ordering. This command is of the new type Query. The slave, after receiving this command, in an implementation specific fashion, will send the response when it is satisfied that transaction ordering has been satisfied. Normally this is used to stall the initiator until all preceding requests have reached a global ordering point within the system. The slave responds with a single cycle of DVA on the SResp bus. For this command there is no data phase.
OCP-IP Confidential
6.2.3.3 SCohState
This signal indicates the install state and is part of the response phase and is passed back to the master with any response to a coherent request. It is also used to indicate the prior state of the cache line on interventions. For noncoherent and coherence-aware requests, this signal is a dont care. SCohState is a three-bit field with encodings as shown in Table 36.
Table 36 SCohState Encoding
Mnemonic I S M E O
6.2.3.4 SResp
Existing responses remain as in OCP 2.2, but a new one (OK) is added to support intervention port related transactions and main port transaction (e.g., CC_UPG). The OK response indicates completion without any data transfer. If the OCP interface supports coherence extensions, SResp becomes a three-bit field with encodings as shown in Table 37, below.
Table 37 SResp Encoding
SResp Value
0x0 0x1 0x2 0x3 0x4 0x50x7
Response
No response Data valid / accept Request failed Response error
Mnemonic
NULL DVA FAIL ERR
6.2.3.5 MReqInfo
MReqInfo is not explicitly defined, but mentioned to remind implementors that it is available for sending more coherency hints if desired. Some examples are Instruction or Data miss, Cache management instructions etc.
OCP-IP Confidential
MCmd
Phases
writeresp_enable=0 intport_writedata=0 intport_writedata=1 writeresp_enable=1 intport_writedata=0 intport_writedata=1
WR
Request (with write data) Request; Response Request; Response Request; Response Request (with write data); Response Request (with write data) Request; Response Request; Response Request; Response Request; Response Request; Response1 Request; Response2 Request (with write data)
Request (with write data) Request; Response Request; Response Request; Response Request (with write data); Response Request (with write data) Request; Response Request; Response Request; Response Request; Response Request; Response1 Request; Response2
Request (with write data); Response Request; Response Request; Response Request; Response Request (with write data); Response Request (with write data); Response Request; Response Request; Response Request; Response Request; Response Request; Response1 Request; Response2
Request (with write data); Response Request; Response Request; Response Request; Response Request (with write data); Response Request (with write data); Response Request; Response Request; Response Request; Response Request; Response Request; Response1 Request; Response2 Request (no write data); Response WriteBack data is supplied with selfintervention response on Intervention Port (if cache line ownership hasnt moved to another masterdata race)
WRC
CC_UPG
CC_WB
Request (no write Request (with write data) data); If data is resident Response within local cache, the CopyBack data is supplied with intervention response on the Intervention Port.
OCP-IP Confidential
MCmd
Phases
writeresp_enable=0 intport_writedata=0 intport_writedata=1 writeresp_enable=1 intport_writedata=0 intport_writedata=1
CC_CB
Request (no write Request (with write data) data); If data is resident Response within local cache, the CopyBack data is supplied with intervention response on the Intervention Port.
Request (no write data); Response If modified data is resident within local cache, the CopyBack Data is supplied with intervention response on the Intervention Port. Request (no write data); Response If modified data is resident within local cache, CopyBack Data is supplied with intervention response on the Intervention Port. Request; Response
CC_CBI
CC_I
Request (with write data); Response Request (with write data); Response
Request; Response
Request (with write data); Response Request (with write data); Response If data is resident within local cache, the snoop data is supplied with the intervention response on Intervention Port. Request; Response
CC_WRI
Request; Response
Request (with write data); Response If modified data is resident within local cache, the snoop data is supplied with the intervention response on the Intervention Port. Request; Response
CC_SYNC
1. 2.
Request; Response
Cache line ownership stays with original requesting master. Data transfer only occurs if cache line ownership had moved to another master (data-race)
OCP-IP Confidential
ReadEx The master receives the requested data on SData. Sets a lock on the address for the initiating thread. ReadLinked The master receives the requested data on SData. Sets a reservation on that address. Write, WriteNonPost The request phase includes the write data. WriteConditional If there was an existing reservation for the address by the same initiating thread, the request phase includes the write data. If the write proceeds in this manner, the reservation for the address is cleared. CohUpgrade If the cache line ownership is still resident within the requesting master, there is no data transfer. If the cache line ownership had moved to another master (data race), then the master receives the requested data on SData. CohWriteBack If port parameter intport_writedata=1 there is no data transfer on the main port. The data is transferred on the intervention port. If port parameter intport_writedata=0, the request phase includes the write data. CohCopyBack, CohCopyBackInv There is no data transfer on the main port. If the data was resident within any cache, the data is transferred on the intervention port. CohInvalidate The SResp value is OK and there is no data transfer phase. CohWriteInvalidate The write data is sent along with the Request. The SResp value is OK. If the data was resident within any cache, the snoop data is written back on the intervention port. For this case, the home agent is responsible to merge this older snoop response data with the newer write data. CohCompletionSync The master receives the response from the slave that previous transactions have been made globally visible.
OCP-IP Confidential
Legacy reads to coherent address space are processed as follows: ReadEx: The coherent slave issues I_CBI, the intervention port request to write back a possibly modified cache line to the home memory location and evict the line from the cache hierarchy of each coherent master. The memory is also read (in an implementation specific manner, either
OCP-IP Confidential
speculatively or after the response(s) to I_CBI are received). The slave then sets a lock for the initiating thread on this address at the home memory. The data is returned to the requesting master (either the contents of the modified cache line or the memory contents). It is assumed that an implementation specific mechanism ensures that this is the only ReadEx operating on this location. Other Read Operations: The coherent slave issues I_RDSA, the intervention port request to read a possibly modified cache line and update the home. The memory is also read (in an implementation specific manner, either speculatively or after the response(s) to I_RDSA are received). With Read Linked, the slave then sets a reservation in a monitor for the initiating thread on this address. The data is returned to the requesting master.
Legacy writes to coherent address space are processed as follows: Clearing Write6: (Note the home agent coherent slave will be able to determine if this is a clearing write). The data is written to main memory (request on legacy port of coherent slave) and the lock is cleared atomically in an implementation dependent manner. Write Conditional: If a reservation is set for the matching address and for the corresponding thread, the slave issues I_WRI, the request to update the value at home. If the reservation is cleared, the write is not performed, a FAIL response is returned and no reservations are cleared. Other Writes: Clears the reservations on any conflicting addresses set by other threads. The slave issues I_WRI, the intervention port request to update the value at home.
The term clearing write refers to the Write or WriteNonPost command to the matching address issued after a ReadEx on that thread. It is called a clearing write as it clears any reservations on the matching address set by other threads.
OCP-IP Confidential
scohid_enable If this parameter is set, the SCohID signal is instantiated. cohfwdid_enable If this parameter is set, the MCohFwdID signal is instantiated. mcohid_wdth Width of the MCohID signal. scohid_wdth Width of the SCohID signal. cohfwdid_wdth Width of the CohFwdID signal.
Group
Basic
Signal
Clk MAddr MCmd
Comments
Required
addr=1
addr_wdth
Not allowed Not allowed Optional Optional Optional Not allowed Required (only NULL, DVA, and OK responses allowed)
OCP-IP Confidential
Group
Simple
Signal
MAddrSpace MByteEn MDataByteEn MDataInfo MReqInfo SDataInfo SRespInfo
Comments
Optional Not allowed Not allowed Not allowed
Burst
atomiclength_wdth Tied off to cache line size burstlength_wdth Tied off to cache line size Tied off to 1 Required. Only INCR, XOR, and WRAP are allowed. Tied off to 1 Not allowed Not allowed Not allowed
OCP-IP Confidential
Group
Signal
Comments
Required, used to transmit current state of the cache line Required
Coherence SCohState
Optional; required for directory based protocols and three-hop protocols1 Optional; required for directory based protocols and three-hop protocols1 Optional; required for three-hop protocols1 Optional; required for three-hop protocols1 Optional; needed for split transaction responses Required
SCohID
scohid_enable
scohid_wdth
MCohFwdID
cohfwdid_enable
cohfwdid_wdth
SCohFwdID
cohfwdid_enable
cohfwdid_wdth
SDataValid
intport_split_tranx
OCP-IP Confidential
Group
Thread
Signal
MConnID MDataThreadID MThreadBusy MThreadID MDataThreadBusy SDataThreadBusy SThreadBusy SThreadID SDataThreadID
Comments
Optional
Not allowed Optional Optional Optional Not allowed Optional Optional Optional Optional Not allowed Optional Optional Optional Required Not allowed Not allowed
sdatathreadbusy=0 threads threads sthreadbusy threads threads resp threads resp tags tags datahandshake=0 tags resp taginorder taginorder resp sreset=1 or mreset=1 (all others) (all) threads threads threads tags tags tags
Tags
Sideband
Test
1.
(all)
If coherent master is responsible for providing the system view (see Section 5.2 on page 74).
6.3.3.1 MCmd
The intervention port commands are shown in the Table 40 below. The commands that are write-like (including CohWriteBack, CohCopyBack, CohCopyBackInv, CohWriteInvalidate) have no associated write data during the request phase. If the port parameter intport_writedata=1, the write data transfer phase occurs on the intervention port during the data response phase for the self intervention. The mnemonics for the intervention port commands are prefixed by I_ to distinguish them from the main port commands.
OCP-IP Confidential
Table 40
MCmd
0x0 0x10x7 0x8 0x9 0xA 0xB 0xC 0xD 0xE0xF 0x10 0x11 0x12 0x13 0x140x1F
Command
Idle (Reserved) IntvReadOwn IntvReadShare IntvReadDiscard IntvReadShareAlways IntvUpgrade IntvWriteBack (Reserved) IntvCopyBack IntvCopyBackInv IntvInvalidate IntvWriteInvalidate (Reserved)
Mnemonic
IDLE (Reserved) I_RDOW I_RDSH I_RDDS I_RDSA I_UPG I_WB (Reserved) I_CB I_CBI I_I I_WRI (Reserved)
IntvReadOwn (0x8, I_RDOW) This coherent command is used to read data from home with the intent to modify. This command is generated by processor stores that miss in the cache hierarchy. The slave responds with either SResp=OK (no data) or DVA (data). IntvReadShared (0x9, I_RDSH) This coherent command is used to read data from home with no intent to modify. This command is generated by processor loads that miss in the cache hierarchy. The slave responds with either SResp=OK (no data) or DVA (data). IntvReadDiscard (0xA, I_RDDS) This coherent command is used to read data from the processor caches and not cause any cache line state changes. It is generated by external agents (such as coherent DMA controllers) to read data from the processor cache hierarchy. The slave responds with either SResp=OK (no data) or DVA (data). IntvReadShareAlways (0xB, I_RDSA) This coherent command is used to read data from home with intent to never modify. This command is generated by processor instruction fetches. The slave responds with either SResp=OK (no data) or DVA (data).
OCP-IP Confidential
IntvUpgrade (0xC, I_UPG) This coherent command is used to request ownership of a shared cache line from the system. It is usually generated for processor stores which hit cache lines with shared states. This is a non-posted write. The slave responds with either SResp=OK (no data) or DVA (data). The DVA response occurs when the local CPU has modified its data after the Upgrade command was sent by the originating CPU. IntvWriteBack (0xD, I_WB) This coherent command is used to writeback cache lines into home. This command is generated when a cache miss causes modified cache lines to be evicted from the cache hierarchy. This is a non-posted write. The slave responds with either SResp=OK (no data) or DVA (data). The user has the option of placing the writeback data on this port instead of the main port (Port parameter intport_writedata=1). This option allows self-intervention data responses and normal responses to use the same datapaths. For the self-intervention case, it is possible for the slave to response with OK instead of DVA. This case occurs if another CPU has gained ownership of the cache line before the original writeback transaction has been processed. The cache line would have been previously been written back for this change of ownership (Race between another core requesting the line and writeback completing at the originating CPU). IntvCopyBack (0x10, I_CB) This coherent command is used to writeback cache lines into home and the cache line is not evicted from the cache hierarchy. This command is generated by processor-specific cache management instructions. This is a non-posted write. The slave responds with either SResp=OK (no data) or DVA (data). The user has the option of placing the writeback data on this port instead of the main port (Port parameter intport_writedata=1). This option allows self-intervention data responses and normal responses to use the same datapaths. IntvCopyBackInv (0x11, I_CBI) This coherent command is used to writeback cache lines into home and the cache line is evicted from the cache hierarchy. Functionally, it is the same as CohWriteBack, but this command is generated by processorspecific cache management instructions. This is a non-posted write. The slave responds with either SResp=OK (no data) or DVA (data). The user has the option of placing the writeback data on this port instead of the main port (Port parameter intport_writedata=1). This option allows self-intervention data responses and normal responses to use the same datapaths. IntvInvalidate (0x12, I_I) This coherent command is used to purge data from the cache hierarchy. If a cache line contains the requested address, its state is set to invalid, regardless of the previous state. Typically used by coherent DMA
OCP-IP Confidential
controllers to remove stale copies of data from the cache hierarchy and also by processor-specific cache management instructions. This is a nonposted write. The slave responds with SResp=OK. IntvWriteInvalidate (0x13, I_WRI) This coherent command is used to inject new data into a coherent system by simultaneously invalidating a cache line from the system and updating its value at home. Typically used by coherent DMA controllers to write new values into home and remove stale copies from the cache hierarchy. This is a non-posted write. The slave responds with either SResp=OK (no data) or DVA (data). The original data is merged with the new data before it is written to home. In some systems, a third port for coherent IO traffic can be used to allow external masters (such as DMA engines) to inject these WriteInvalidate commands into the coherent memory system without requiring the CPU main ports to set writeresp_enable=1.
6.3.3.2 SCohState
This signal indicates the cache line state of the slave cache and is part of the intervention response phase. Its encoding is identical to the description of the signal with the same name in the main port signal descriptions (see Table 36 on page 106).
6.3.3.3 MReqSelf
MReqSelf is an output of the master and an input to the slave. It is valid when MCmd is not IDLE. It indicates to the intervention slave that this intervention request is a result of a main port request which originated from the master port of this agent (i.e., it is a self-intervention). This bit is typically asserted by the interconnect. The concept of self-intervention is critical in OCP 3.0 (along with a serialization point) to enforce global order in the coherent system.
6.3.3.4 MCohID
MCohID specifies the target of the request. It is valid when MCmd is not IDLE. For directory based coherence it is used at the intervention ports to indicate the target of the response. For an interrupt command from the main port it is used to indicate the target of the command. This is an optional signal which could be used in three hop protocols when the coherent master also provides the system view (see Section 5.2 on page 74).
6.3.3.5 SCohID
SCohID specifies the target of the response. It is valid when SResp is not NULL. For directory based coherence it is used at the intervention ports to indicate the target of the response. This is an optional signal which could be used in three hop protocols when the coherent master also provides the system view (see Section 5.2 on page 74).
OCP-IP Confidential
6.3.3.6 McohFwdID
MCohFwdID specifies the target for a three hop transaction. It is valid when MCmd is not IDLE. Its main use is meant in directory based coherence where it is used at the intervention port to signal to the target that if a three hop transaction is required, then this is the address of the final target. This is an optional signal which could be used in three hop protocols when the coherent master also provides the system view (see Section 5.2 on page 74).
6.3.3.7 SDataValid
SDataValid is a optional signal. This signal is included if the port parameter intport_split_tranx is set equal to 1. It is an output from the slave and an input to the Master to denote that snoop intervention data is valid on SData.
6.3.3.8 SDataLast
SDataLast is a required signal. It is an output from the slave and an input to the Master to denote that the last data beat of the transfer is valid on SData.
6.3.3.9 MDataAccept
MDataAccept is an optional signal. This signal is included if the port parameter intport_split_tranx is set equal to 1. It is an output from the Master and an input to the slave to denote that the Master can accept snoop intervention data from the slave.
6.3.3.10 MDataThreadBusy
MDataThreadBusy is an optional signal used if threads have been enabled for the Intervention Port. The master notifies the slave that it cannot accept any data associated with certain threads. This 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. This signal is enabled by the port parameter mdatathreadbusy. The semantics of this signal are controlled by the port parameters mdatathreadbusy_exact and mdatathreadbusy_pipelined.
OCP-IP Confidential
Table 41
Group
Request
Signal
MAddr MCmd MAddrSpace MReqInfo MAtomicLength MBurstLength MBurstPrecise MBurstSeq MBurstSingleReq MReqSelf MCohID MCohFwdID MTagID MTagInOrder MThreadsID
Condition
always always always Optional Optional always always always always always Optional Optional Optional Optional Optional always Optional always Optional Optional Optional Optional Always Optional Always Optional Optional Optional Optional Optional Optional
Response
RespDataHandShake SData SDataValid SDataLast SDataInfo STagID STagInOrder SCohID SThreadID SDataThreadID
OCP-IP Confidential
MCmd
I_RDOW
Request; Response; RespDataHandShake1 Request; Response; RespDataHandShake1 Request; Response; RespDataHandShake1 Request; Response; RespDataHandShake1 Request; Response; RespDataHandShake1 Request; Response2 Request; Response2 Request; Response2 Request; Response Request; Response; RespDataHandShake4
Request; Response;
I_RDSH
Request; Response
Request; Response
I_RDDS
Request; Response
Request; Response
I_RDSA
Request; Response
Request; Response
I_UPG
Request; Response
Request; Response
I_WB
Request; Response; RespDataHandShake3 Request; Response; RespDataHandShake3 Request; Response; RespDataHandShake3 Request; Response Request; Response RespDataHandShake4
Request; Response
I_CB
Request; Response
I_CBI
Request; Response
I_I I_WRI
1.
RespDataHandShake group active if cache line was in M or O state in local cache. If port parameter intport_estate_c2c=1, then RespDataHandShake group also active if cache line was in E state in local cache. 2. The request and response transfers are not needed in directory based protocols since the intervention requests are only directed to the original requester. In snoop-based protocols, some implementations may choose to broadcast the intervention requests, in which case these transfers are needed. 3. RespDataHandShake phase might not occur if cache line ownership has been passed to another CPU subsequent to when the originating CC_WB command was issued. WriteBack Data is supplied with self-intervention response 4. RespDataHandShake group only active if the cache line in the local cache was in the M or O state.
If the port parameter intport_split_tranx=1 then it is allowed that the Response phase can begin before the associated RespDataHandShake phase. If the port parameter intport_split_tranx=1 then it is allowed that the Response phase can end before the associated RespDataHandShake phase.
These are optimizations to allow forwarding of the local cache tag lookups before the local cache data array lookup is completed.
Condition(s)
IntvReadOwn, IntvReadShared, IntvReadDiscard, IntvReadSharedAlways, IntvUpgrade MReqSelf = b0, Cache Line State = M, O intport_estate_c2c=1, MReqSelf = b0, Cache Line State = E All other cases IntvWriteBack intport_writedata=1, MReqSelf = b1, Cache Line State = M, O All other cases IntvCopyBack, IntvCopyBackInv intport_writedata=1, Cache Line State = M, O All other cases IntvWriteInvalidate Cache Line State = M, O All other cases IntvInvalidate All cases
SResp Behavior
OCP-IP Confidential
OCP-IP Confidential
7.2 Syntax
The interface configuration file is written using standard Tcl syntax. Syntax is described using the following conventions: Symbol
[] | * + <> () {} \ #
Meaning
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. An open brace must always appear on the same line as the statement line continuation character comments
The syntax of the interface configuration file is: version <version_string> bundle <bundle_name> \ [ revision <revision_string> ] {<bundle_stmt>+} where: <bundle_stmt>: | interface_types <interface_type-name>+ | net <net_name> {<net_stmt>*} | proprietary <vendor_code> <organization_name> {<proprietary_statements>} <net_stmt>: | direction (input|output|inout)+ | width <number-of-bits> | vhdl_type <type-string> | type <net-type> | proprietary <vendor_code> <organization_name> {<proprietary_statements>} The file must contain a single version statement followed by a single bundle statement. The bundle statement must contain exactly one interface_types statement, and one or more net statements. Each net statement must contain exactly one direction statement and may contain additional statements of other types.
OCP-IP Confidential
version The 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. The current version is 4.5. bundle The bundle 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 interface configuration file name. Use a bundle_name of ocp for OCP 1.0 bundles, ocp2 for OCP 2.x bundles, and ocp3 for OCP 3.x bundles. The optional revision_string identifies a specific revision for the bundle. If not provided, the revision_string defaults to 0. The pre-defined ocp, ocp2, and ocp3 bundles use the default value of revision_string to refer to the 1.0, 2.0, and 3.0 versions of the OCP Specification, respectively. For ocp2 bundles, set revision_string to 2 to refer to the 2.2 version of the OCP Specification. interface_types The interface_types statement lists the legal values for the interface types associated with the bundle. 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. Predefined interface types for OCP bundles are slave, master, system_slave, system_master, and monitor. These are explained in Table 18 on page 35. net The 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 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 file described in Chapter 8. proprietary For a description, see Proprietary Statement on page 137. direction The direction statement indicates whether the net is of type input, output, or inout. This field is required and must have as many directionvalues 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. vhdl_type 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.
OCP-IP Confidential
type The type statement specifies that a net has special handling needs for downstream tools such as synthesis and layout. Table 44 shows the allowed <net-type> options. If no <net-type> is specified, normal is assumed.
Table 44 net-type Options
<net-type>
clock clock_sample jtag_tck jtag_tdi jtag_tdo jtag_tms jtag_trstn normal reset scan_enable scan_in scan_out test_mode
Description
clock net clock sample net JTAG test clock JTAG test data in JTAG test data out JTAG test mode select JTAG test logic reset default for nets without special handling needs reset net scan enable net, serves as mode control between functional and scan data inputs scan input net scan output net test mode net, puts logic into a special mode for use during production testing
proprietary For a description, see Proprietary Statement on page 137. 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
OCP-IP Confidential
# 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 } net "Reset" { direction output input type reset } # close the bundle }
OCP-IP Confidential
8.1 Syntax
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. An open brace must always appear on the same line as the statement comments
[<description>] | interface <interface_name> bundle <bundle_name> [revision <revision_string>] [{<interface_body>*}] | addr_region <name> {<addr_region_body>*} | proprietary <vendor_code> <organization_name> {<proprietary_statements>}
The file must contain a single version statement followed by a single module statement. The module statement contains multiple core statements. One core_id must be included. At least one interface statement must be included. One icon statement and one or more addr_region and proprietary statements may also be included.
8.2 Components
This section describes the core RTL configuration file components.
Version Statement
The 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 4.5.
Icon Statement
This 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 Statement
The core_id statement provides identifying information to the tools about the core. This information is required. Syntax of the core_id statement is:
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. See Defined Core Code Values on page 131. The allowed range is 0x000 - 0xFFF.
revision_code A developer-assigned revision code that can provide core revision information. The allowed range is 0x00xF. description An optional Tcl string that provides a short description of the core.
0x8: Cache (Instruction, Data, combined, or both) Processor Type: 0x00: CPU 0x10: DSP 0x20: Hybrid 0x30: Reserved Only values from 0x100 - 0x13F are defined/reserved Example: 32-bit CPU with embedded cache would have <cc> = 0x100 + 0x2 + 0x8 + 0x00 = 0x10A 0x200 - 0x2FF: Bridges Sum values from following choices plus offset 0x200: Domain: 0x00 - 0x7F: Computing 0x00 - 0x3F: PC's 0x00: ISA (inc. EISA) 0x01 - 0x0F: Reserved 0x10: PCI (33MHz/32b) 0x11: PCI (66MHz/32b) 0x12: PCI (33MHz/64b) 0x13: PCI (66MHz/64b) 0x14 - 0x1F: AGP, etc. 0x40 - 0x7F: Reserved 0x80 - 0xBF: Telecom 0xA0 - 0xAF: ATM 0xA0: Utopia Level 1 0xA1: 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)
OCP-IP Confidential
Interface Statement
The interface statement defines and names the interfaces of a core. The interface name is required so that cores with multiple interfaces can specify to which interface a particular connection should be made. Syntax for the interface statement is:
interface "xyz" bundle ocp3 revision 0 <interface_body>: | interface_type <type_name> | port <port_name> net <net_name> | reference_port <interface_name>.<port_name> net <net_name> | prefix <name> | param <name> <value> [{(<attribute> <value>)*}] | subnet <net_name> <bit_range_list> <subnet_name> | location (n|e|w|s|) <number> | proprietary <vendor_code> <organization_name> {<proprietary_statements>}
Ports on a core interface may have names that are different than the nets defined in the bundle type for the interface. In this case, each port in the interface must be mapped to the net in the bundle with which it is associated. Mapping links the module port <prefix><port_name> with the bundle <net_name>. The default rules for mapping are that the port_name is the same as the net_name and the prefix is the name of the interface. These rules can be overridden using the Port and Prefix statements.
OCP-IP Confidential
Interface_type Statement
The 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, slave, system_slave, and monitor as described in Table 18 on page 35. To define a type, specify it in the interface configuration file (described on page 123).
Port Statement
Use the port statement to map a single port corresponding to a signal that is defined in the bundle. Syntax for the port statement is:
Reference_port Statement
The reference_port statement re-directs a net to another bundle. Syntax for the port statement is:
interface tp bundle ocp { reference_port ip.Clk_i net Clk reference_port ip.SReset_ni net MReset_n reference_port ip.EnableClk_i net EnableClk port Control_i net Control port MCmd_i net MCmd } interface ip bundle ocp { port Clk_i net Clk port SReset_ni net SReset_n port EnableClk_i net EnableClk port Control_i net Control port MCmd_o net MCmd }
OCP-IP Confidential
Figure 14
Reference Port
ip
lk _ es i et C _n SReset_n on i tro l_ M i C Control m d_ o MCmd C MReset_n on tro l_ M i C Control m d_ i MCmd C
tp
SR
Clk
OCP bundle
Figure 14 illustrates the operation of a reference port. In the interface tp, no ports exist for bundle signals Clk, EnableClk, and MReset_n. Neither do the bundle signals themselves exist. Instead, they reference the corresponding ports in the ip interface and nets in the bundle connected to that interface. The internal signals in the tp interface that would have been connected to the Clk, EnableClk, and MReset_n signals of the OCP bundle connected to the tp interface are instead connected to the referenced ports in the ip interface.
Prefix Command
The prefix command applies to all ports in an interface. It supplies a string that serves as the prefix for all core port names in the interface. Syntax for the prefix command is:
prefix <name>
For example, the statement prefix external_ specifies that the names for all ports in the interface are of the form external_*. If the prefix command is omitted, the interface name will be inserted as the default prefix. To omit the prefix from the port name, specify it as an empty string, that is prefix "".
Clk
OCP bundle
signal is configured into the interface). Specifying the signal width using an attribute attached to the signal parameter is equivalent to using the corresponding signal width parameter but the attribute syntax is preferred. The width of the signals MData, SData, MByteEn, and MDataByteEn are derived from the single data_wdth parameter, so cannot have their width specified using an attribute. For example, an OCP might be configured to include an interrupt signal as follows.
param interrupt 1
The following example shows the MBurstLength field tied off to a constant value of 4.
Subnet Statement
The subnet statement assigns names to bits or contiguous bit-fields within a net. Syntax for the subnet statement is:
Location Statement
The location statement provides a way for the core to indicate where to place this interface when a schematic symbol for the core is drawn. The location is specified as 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 s 50
OCP-IP Confidential
<addr_region_body>: addr_base <integer> | addr_size <integer> | addr_space <integer> | proprietary <vendor_code> <organization_name> {<proprietary_statements>}
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.
Proprietary Statement
The proprietary statement enables proprietary extensions of the core RTL configuration file syntax. Standard parsers must be able to ignore the extensions, while proprietary parsers can extract additional information about the core. Syntax for the proprietary statement is:
OCP-IP Confidential
# define the module version 4.5 module flashctrl { core_id 0xBBBB 0x001 0x1 Flash/Rom Controller # Use the Vista icon icon vista.ppm addr_region FLASHCTRL0 { addr_base 0x0 addr_size 0x100000 } # one of the interfaces is an OCP slave using the pre-defined ocp2 bundle # Revision is "1", indicating compliance with OCP 2.1 interface tp bundle ocp2 revision 1 { # this is a slave type ocp interface interface_type slave # this OCP is a basic interface with byteen support plus a named SFlag # and MReset_n param mreset 1 param sreset 0 param byteen 1 param sflag 1 {width 1} param addr 1 {width 32} param mdata 1 {width 64} param sdata 1 {width 64} prefix tp # since the signal names do not exactly match the signal # names within the bundle, they must be explicitly linked port Reset_ni net MReset_n port Clk_i net Clk port TMCmd_i net MCmd port TMAddr_i net MAddr 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 SFlag
OCP-IP Confidential
# name SFlag[0] access_error subnet SFlag 0 access_error # stick this interface in the middle of the top of the module location 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 control interface emem bundle flash { # the type 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 configuration file. See Section 7 on page 123 for the syntax definition of the interface configuration file.
bundle flash { #types of flash interfaces #controller: flash controller; flash: flash device itself. interface_types controller flash net addr { #Address to the Flash device direction output input width 19 }
OCP-IP Confidential
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 } }
OCP-IP Confidential
Core Timing
To connect two entities together, allowing communication over an OCP interface, the protocols, signals, and pin-level timing must be compatible. This chapter describes how to define interface timing for a core. This process can be applied to OCP and non-OCP interfaces. 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. When implementing IP cores in a technology independent manner it is difficult to specify only one timing number for the interface signals, since timing is dependent on technology, library and design tools. The methodology specified in this chapter allows the timing of interface signals to be specified in a technology independent way. To make your core description technology independent use the technology variables defined in the Core Preparation Guide. The technology variables range from describing the default setup and clock-to-output times for a port to defining a high drive cell in the library.
OCP-IP Confidential
Figure 15 shows the definition of setuptime and c2qtime. See Section 9.2.5.1 on page 149 for a description of these parameters.
Figure 15 OCP Timing Parameters
logic
logic
c2qtime
setuptime
1 clock cycle
OCP-IP Confidential
logic
drivingcellpin
core
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 17. Or, the combination wireloadcapacitance/wireloadresistance must be specified, as shown in Figure 18.
Figure 17 Variable Loads - wireloaddelay
loadcellpin
logic
loads wireloaddelay
For instructions on calculating a delay, refer to the Synopsys Design Compiler Reference.
OCP-IP Confidential
Figure 18
loadcellpin
wireloadresistance
logic
loads wireloadcapacitance
drivingcellpin
loads * loadcellpin
wireloadresistance
logic logic logic
wireloadcapacitance
c2qtime
wireloaddelay
clock skew
setuptime
1 clock cycle
OCP-IP Confidential
max delay
OCP-IP Confidential
Parameter values are specified using Tcl syntax. Expressions can use any of the technology or environment variables, and any of the following variables: clockperiod This 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:
OCP-IP Confidential
rootclockperiod This variable is set to the period of the main system clock, usually referred to as the root clock. It is typically used when a value needs to be a multiple of the root clock, such as for non-OCP clocks. For example:
OCP-IP Confidential
clock myClock
worstcasedelay The 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:
OCP-IP Confidential
clockname myClock
drivingcellpin This 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:
OCP-IP Confidential
OCP-IP Confidential
Constant values are specified in nanoseconds. For consistency, use expressions that can be interpreted in nanoseconds. wireloaddelay Replaces capacitance/resistance as a way to specify expected delays caused by the interconnect. To maintain portability set this variable to use a technology value 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/capacitance for the same port. For example:
wireloadresistance {[expr $resistancescale * .09]} wireloadcapacitance {[expr $capacitancescale * .12]} wireloadresistance {$mediumnetrcresistance} wireloadcapacitance {$mediumnetrccapacitance}
port <portName> { clockname <clockName> drivingcellpin <drivingCellName> setuptime <Value> holdtime <Value> maxfanout <Value> }
OCP-IP Confidential
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 myInPort { clockname myClock drivingcellpin {$mediumdrivegatepin} setuptime 2 maxfanout {[expr $defaultfanoutload * 1]} }
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/ capacitance for the same port.
OCP-IP Confidential
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 10 wireloaddelay {$longnetdelay} c2qtime {[expr $clockperiod * .2]} }
OCP-IP Confidential
maxdelay { delay 3 fromport myInPort1 toport myOutPort1 delay {[expr $clockperiod *.5]} fromport myInPort2 toport myOutPort2 }
OCP-IP Confidential
version 1.3 port Reset_ni { drivingcellpin {$mediumgatedrivepin} setuptime {[expr $clockperiod * .5]} } port MCmd_i { drivingcellpin {$mediumgatedrivepin} setuptime {[expr $clockperiod * .9]} } port MAddr_i { drivingcellpin {$mediumgatedrivepin} setuptime {[expr $clockperiod * .5]} } port MWidth_i { drivingcellpin {$mediumgatedrivepin} setuptime {[expr $clockperiod * .5]} } port MData_i { drivingcellpin {$mediumgatedrivepin} setuptime {[expr $clockperiod * .5]} } 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 }
OCP-IP Confidential
Part II Guidelines
10 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 Section 4.3 on page 40. Most of the timing diagrams in this chapter are based upon simple OCP clocking, where the OCP clock is completely determined by the Clk signal. A few diagrams are repeated to show the impact of the EnableClk signal. 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 on page 15 and 3 on page 16.
OCP-IP Confidential
Figure 21
1 Clk MCmd Request Phase MAddr MData SCmdAccept Response Phase SResp SData
A
IDLE WR1
IDLE
RD2
IDLE
A1
A2
D1
NULL
DVA2
NULL
D2
Sequence
A. 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.
OCP-IP Confidential
1 Clk MCmd Request Phase MAddr MData SCmdAccept Response Phase SResp SData
A NULL IDLE WR1 A1 D1
WR2 A2 D2
IDLE
WR3 A3 D3
IDLE
NULL
Sequence
A. 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.
OCP-IP Confidential
1 Clk MCmd Request Phase MAddr MData SCmdAccept Response Phase SResp SData
IDLE
RD1
IDLE
A1
NULL
DVA1 D1
NULL
Sequence
A. 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.
OCP-IP Confidential
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, captures the read data, and the response phase ends.
1 Clk MCmd Request Phase MAddr MData SCmdAccept Response Phase SResp SData
A NULL DVA1 IDLE WR1 A1 D1
WR2 A2 D2
IDLE
WR3 A3 D3
IDLE
NULL
DVA2
NULL
DVA3
NULL
Sequence
A. The master starts a write request by driving WR on MCmd and valid address and data on MAddr and MData, respectively. The slave having already asserted SCmdAccept for a request accept latency of 0, drives DVA on SResp to indicate a successful transaction.
OCP-IP Confidential
B. The master starts a new transfer in the next cycle. The slave captures the write address and data and deasserts SCmdAccept, indicating that it is not ready for a new request. C. With SCmdAccept 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 and drives DVA on SResp to indicate a successful transaction. 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. The slave drives DVA on SResp to indicate a successful transaction. G. The master samples the response.
1 Clk MCmd Request Phase MAddr MData SCmdAccept Response Phase SResp SData
A NULL IDLE
WRNP1 A1 D1
IDLE
WRNP2 A2 D2
IDLE
DVA1
NULL
DVA2
OCP-IP Confidential
Sequence
A. The master starts a non-posted write request by driving WRNP on MCmd and valid address and data on MAddr and MData, respectively. The slave asserts SCmdAccept combinationally, for a request accept latency of 0. B. The slave drives DVA on SResp to indicate a successful first transaction. C. The master starts a new transfer. The slave deasserts the SCmdAccept, indicating it is not yet ready to accept a new request. The master samples DVA on SResp and the first response phase ends. D. The slave asserts SCmdAccept for a request accept latency of 1. E. The slave captures the write address and data. F. The slave drives DVA on SResp to indicate a successful second transaction. G. The master samples DVA on SResp and the second response phase ends.
OCP-IP Confidential
Figure 26
Burst Write
1 Clk MCmd MAddr MData Request Phase MBurstLength MBurstSeq MBurstPrecise MReqLast SCmdAccept
A
IDLE WR1
WR2
WR3
WR4
IDLE
0x01
0x42
0x83
0xC4
D1
D2
D3
D4
INCR
INCR
INCR
INCR
Sequence
A. The master starts the burst write by driving WR on MCmd, the first address of the burst on MAddr, valid data on MData, a burst length of four on MBurstLength, the burst code INCR on MBurstSeq, and asserts MBurstPrecise. MReqLast must be deasserted until the last request in the burst. The burst signals indicate that this is an incrementing burst of precisely four transfers. The slave is not ready for anything, so it deasserts SCmdAccept. B. The slave asserts SCmdAccept for a request accept latency of 1. C. The master issues the next write in the burst. MAddr is set to the next word-aligned address. For 32-bit words, the address is incremented by 4. The slave captures the data and address of the first request. D. The master issues the next write in the burst, incrementing MAddr. The slave captures the data and address of the second request. E. The master issues the final write in the burst, incrementing MAddr, and asserting MBurstLast. The slave captures the data and address of the third request. F. The slave captures the data and address of the last request.
OCP-IP Confidential
1 Clk MCmd Request Phase MAddr MData SCmdAccept Response Phase SResp SData
A
NULL DVA1 IDLE RD1
RD2
IDLE
RD3
IDLE
A1
A2
A3
NULL
DVA2
NULL
DVA3
NULL
D1
D2
D3
Sequence
A. 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. 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. 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 request 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.
OCP-IP Confidential
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 request phase. It also sees that SResp is now DVA and captures the data.
1 Clk MCmd Request Phase MAddr MData SCmdAccept Response Phase SResp SData
A
NULL IDLE RD1
IDLE
RD2
RD3
IDLE
A1
A2
A3
DVA1
NULL
DVA2
NULL
DVA3
NULL
D1
D2
D3
Sequence
A. 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. B. Since SCmdAccept is asserted, the request phase ends. The slave responds to the first request with DVA on SResp and valid data on SData. C. The master launches a read request and the slave asserts SCmdAccept. The master sees that SResp is DVA and captures the read data from SData. The slave drives NULL on SResp, completing the first response phase.
OCP-IP Confidential
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. 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 requestto-response latency for this transfer is 2.
1 Clk MCmd Request Phase MAddr MData SCmdAccept SResp Response Phase SData MRespAccept
A
NULL IDLE RD1
IDLE
RD2
IDLE
A1
A2
DVA1
NULL
DVA2
NULL
D1
D2
OCP-IP Confidential
Sequence
A. 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 and the read data on SData 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 and is 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 RespAccept. F. The master asserts MRespAccept, for a response 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.
OCP-IP Confidential
Figure 30
1 Clk MCmd MAddr MData Request Phase MBurstLength MBurstSeq MBurstPrecise MReqLast SCmdAccept SResp Response Phase SData SRespLast
A
NULL 4 IDLE RD1
RD2
RD3
RD4
IDLE
0x01
0x42
0x83
0xC4
INCR
INCR
INCR
INCR
DVA1
DVA2
DVA3
DVA4
NULL
D1
D2
D3
D4
Sequence
A. The master starts a read request by driving RD on MCmd, a valid address on MAddr, four on MBurstLength, INCR on MBurstSeq, and asserts MBurstPrecise. MBurstLength, MBurstSeq and MBurstPrecise must be kept constant during the burst. MReqLast must be deasserted until the last request in the burst. The slave is ready to accept any request, so it asserts SCmdAccept. B. The master issues the next read in the burst. MAddr is set to the next word-aligned address (incremented by 4 in this case). The slave captures the address of the first request and keeps SCmdAccept asserted. C. The master issues the next read in the burst. MAddr is set to the next word-aligned address (incremented by 4 in this case). The slave captures the address of the second request and keeps SCmdAccept asserted. The slave responds to the first read by driving DVA on SResp and the read data on SData.
OCP-IP Confidential
D. The master issues the last request of the burst, incrementing MAddr and asserting MReqLast. The master also captures the data for the first read from the slave. The slave responds to the second request, and captures the address of the third request. E. The master captures the data for the second read from the slave. The slave responds to the third request and captures the address of the fourth. F. The master captures the data for the third read from the slave. The slave responds to the fourth request and asserts SRespLast to indicate the last response of the burst. G. The master captures the data for the last read from the slave, ending the last response phase.
Sequence
A. The master starts a read request by driving RD on MCmd, a valid address on MAddr, three on MBurstLength, INCR on MBurstSeq, and asserts MBurstPrecise. The burst length is the best guess of the master at this point. MBurstSeq and MBurstPrecise are kept constant during the burst. MReqLast must be deasserted until the last request in the burst. The slave is ready to accept any request, so it asserts SCmdAccept. B. The master issues the next read in the burst. MAddr is set to the next word-aligned address (incremented by 4 in this case). The MBurstLength is set to three, since the master knows the burst is longer than it originally thought. The slave captures the address of the first request and keeps SCmdAccept asserted. C. The master issues the next read in the burst. MAddr is set to the next word-aligned address (incremented by 4 in this case). The MBurstLength is set to two. The slave captures the address of the second request, and keeps SCmdAccept asserted. The slave responds to the first read by driving DVA on SResp and the read data on SData.
OCP-IP Confidential
Figure 31
1 Clk MCmd MAddr MData Request Phase MBurstLength MBurstSeq MBurstPrecise MReqLast SCmdAccept SResp Response Phase SData SRespLast
A
NULL 3 IDLE RD1
RD2
RD3
RD4
IDLE
0x01
0x42
0x83
0xC4
INCR
INCR
INCR
INCR
DVA1
DVA2
DVA3
DVA4
NULL
D1
D2
D3
D4
D. The master issues the last request of the burst, incrementing MAddr, setting MBurstLength to one, and asserting MReqLast. The master also captures the data for the first read from the slave. The slave responds to the second request and captures the address of the last request. E. The master captures the data for the second read from the slave. The slave responds to the third request. F. The master captures the data for the third read from the slave. The slave responds to the fourth request and asserts SRespLast to indicate the last response of the burst. G. The master captures the data for the last read from the slave, ending the last response phase.
OCP-IP Confidential
1 Clk MCmd MAddr MData Request Phase MBurstLength MBurstSeq MBurstPrecise MReqLast SCmdAccept SResp Response Phase SData SRespLast
A
NULL 4 IDLE RD 1
RD 2
RD 3
RD 4
IDLE
0x81
0xC2
0x03
0x44
WRAP
WRAP
WRAP
WRAP
DVA 1
DVA 2
DVA 3
DVA4
NULL
D1
D2
D3
D4
Sequence
A. The master starts a read request by driving RD on MCmd, a valid address on MAddr, four on MBurstLength, WRAP on MBurstSeq, and asserts MBurstPrecise. MBurstLength, MBurstSeq, and MBurstPrecise must be kept constant during the burst. MReqLast must be deasserted until the last request in the burst. The slave is ready to accept any request, so it asserts SCmdAccept.
OCP-IP Confidential
B. The master issues the next read in the burst. MAddr is set to the next word-aligned address (incremented by 4 in this case). The slave captures the address of the first request, and keeps SCmdAccept asserted. C. If incremented, the next address would be 0x10. Since the first transfer was from address 0x8 and the burst length is 4, the addresses must be between 0 and 0xF. The master wraps the MAddr to 0, which is the closest alignment boundary. (If the first address were 0x14, the address would wrap to 0x10, rather than 0x20.) The slave captures the address of the second request, and keeps SCmdAccept asserted. The slave responds to the first read by driving DVA on SResp and valid data on SData. D. The master issues the last request of the burst, incrementing MAddr and asserting MReqLast. The master also captures the data for the first read from the slave. The slave responds to the second request and captures the address of the third. E. The master captures the data for the second read from the slave. The slave responds to the third request and captures the address of the fourth. F. The master captures the data for the third read from the slave. The slave responds to the fourth request and asserts SRespLast to indicate the last response of the burst. G. The master captures the data for the last read from the slave, ending the last response phase.
Sequence
A. The master starts a read request by driving RD on MCmd, a valid address on MAddr, four on MBurstLength, INCR on MBurstSeq, and asserts MBurstPrecise. MBurstLength, MBurstSeq, and MBurstPrecise must be kept constant during the burst. MReqLast must be deasserted until the last request in the burst. The slave is ready to accept any request, so it asserts SCmdAccept. B. The master issues the next read in the burst. MAddr is set to the next word-aligned address (incremented by 4 in this case). The slave captures the address of the first request and keeps SCmdAccept asserted. C. The master inserts an IDLE request in the middle of the burst. The slave does not have to deassert SCmdAccept, anticipating more burst requests to come. The slave captures the address of the second request. The slave responds to the first read by driving DVA on SResp and the read data on SData. The slave must keep SRespLast deasserted until the last response.
OCP-IP Confidential
Figure 33
1 Clk MCmd MAddr MData Request Phase MBurstLength MBurstSeq MBurstPrecise MReqLast SCmdAccept SResp Response Phase SData SRespLast
A
NULL 4 IDLE RD1
RD2
IDLE
RD3
RD4
IDLE
0x01
0x42
0x83
0xC4
INCR
INCR
INCR
INCR
DVA1
DVA2
DVA3
DVA4
NULL
D1
D2
D3
D4
D. The master issues the next read in the burst. MAddr is set to the next word-aligned address (incremented by 4 in this case). The master also captures the data for the first read from the slave. The slave responds to the second read by driving DVA on SResp and the read data on SData. If it has the data available for response, the slave does not have to insert a NULL response cycle. E. The master issues the last request of the burst, incrementing MAddr, and asserting MReqLast. The master also captures the data for the second read from the slave. The slave captures the address of the third request and responds to the third request. F. The master captures the data for the third read from the slave. The slave captures the address of the fourth request. The slave responds to the fourth request, and asserts SRespLast to indicate the end of the slave burst. G. The master captures the data for the last read from the slave, ending the last response phase.
OCP-IP Confidential
1 Clk MCmd MAddr MData Request Phase MBurstLength MBurstSeq MBurstPrecise MReqLast SCmdAccept SResp Response Phase SData SRespLast
A
NULL 4 IDLE RD1
RD2
RD3
RD4
IDLE
0x01
0x42
0x83
0xC4
INCR
INCR
INCR
INCR
DVA1
DVA2
DVA3
NULL
DVA4
NULL
D1
D2
D3
D4
Sequence
A. The master starts a read request by driving RD on MCmd, a valid address on MAddr, four on MBurstLength, INCR on MBurstSeq, and asserts MBurstPrecise. MBurstLength, MBurstSeq and MBurstPrecise must be kept constant during the burst. MReqLast must be deasserted until the last request in the burst. The slave is ready to accept any request, so it asserts SCmdAccept.
OCP-IP Confidential
B. The master issues the next read in the burst. MAddr is set to the next word-aligned address (incremented by 4 in this case). The slave captures the address of the first request and keeps SCmdAccept asserted. The slave responds to the first request by driving DVA on SResp and the read data on SData. The slave must keep SRespLast deasserted until the last response. C. The master issues the next read in the burst. MAddr is set to the next word-aligned address (incremented by 4 in this case). The master also captures the data for the first read from the slave. The slave captures the address of the second request and keeps SCmdAccept asserted. The slave responds to the second request. D. The master issues the last request of the burst, incrementing MAddr and asserting MReqLast. The master also captures the data for the second read from the slave. The slave captures the address of the third request and keeps SCmdAccept asserted. The slave responds to the third request. E. The master captures the data for the third read from the slave. The slave captures the address of the fourth request and keeps SCmdAccept asserted. The slave cannot respond to the fourth request, so it inserts NULL to SResp. F. The slave responds to the fourth request and asserts SRespLast to indicate the last response of the burst. G. The master captures the data for the last read from the slave, ending the last response phase.
Sequence
A. The master starts a read request by driving RD on MCmd, a valid address on MAddr, four on MBurstLength, INCR on MBurstSeq, and asserts MBurstPrecise, and MBurstSingleReq. The MBurstPrecise and MBurstSingleReq signals would normally be tied off to logic 1, which is not supplied by the master. The slave is ready to accept any request, so it asserts SCmdAccept. B. The master completes the request cycles. The slave captures the address of the request. The slave responds to the request by driving DVA on SResp and the first response data on SData. The slave must keep SRespLast deasserted until the last response.
OCP-IP Confidential
Figure 35
1 Clk MCmd MAddr MData Request Phase MBurstLength MBurstSeq MBurstSingleReq MBurstPrecise SCmdAccept SResp Response Phase SData SRespLast
A
NULL 4 IDLE RD1
IDLE
0x01
INCR
DVA1
DVA2
DVA3
DVA4
NULL
D1
D2
D3
D4
C. The master captures the first response data. The slave issues the second response. D. The master captures the second response data. The slave issues the third response. E. The master captures the third response data. The slave issues the fourth response, and asserts SRespLast to indicate the last response of the burst. F. The master captures the last response data.
OCP-IP Confidential
1 Clk MCmd Request Phase MAddr SCmdAccept Data Handshake Phase MDataValid MData SDataAccept
A IDLE WR1 A1
IDLE
WR2 A2
WR3 A3
IDLE
D1
D2
D3
Sequence
A. 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.
OCP-IP Confidential
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.
Sequence
A. The master starts a write request by driving WR on MCmd, a valid address on MAddr, INCR on MBurstSeq, five on MBurstLength, and asserts the MBurstPrecise and MBurstSingleReq signals. The master also asserts the MDataValid signal, drives valid data on MData, and deasserts MDataLast. The MDataLast signal must remain deasserted until the last data cycle. B. Since it has not received SCmdAccept or SDataAccept, the master holds the request phase signals, keeps MDataValid asserted, and MData steady. The slave asserts SCmdAccept and SDataAccept to indicate it is ready to accept the request and the first data phase. C. The master completes the request phase, asserts MDataValid and drives new data to MData. The slave captures the initial data and keeps SDataAccept asserted to indicate it is ready to accept more data.
OCP-IP Confidential
D. The master asserts MDataValid and drives new data to MData. The slave captures the second data phase and keeps SDataAccept asserted to indicate it is ready to accept more data.
Figure 37 Burst Write with Combined Request and Data
1 Clk MCmd MAddr SCmdAccept Request Phase MBurstSeq MBurstLength MBurstSingleReq MBurstPrecise MDataValid Data Handshake Phase MData MDataLast SDataAccept Response Phase SResp SRespLast
A D1 INCR 5 IDLE WR1 A1
IDLE
D2
D3
D4
D5
NULL
DVA
NULL
E. The master asserts MDataValid and drives new data to MData. The slave captures the third data phase and keeps SDataAccept asserted to indicate it is ready to accept more data. F. The master asserts MDataValid, drives new data to MData, and asserts MDataLast to identify the last data in the burst. The slave captures the fourth data phase and keeps SDataAccept asserted to indicate it is ready to accept more data. G. The slave captures the last data phase and address.
OCP-IP Confidential
This example also shows how the slave issues SResp at the end of a burst (when the optional write response is configured in the interface). For single request / multiple data bursts there is only a single response, and it can be issued after the last data has been detected by the slave. The SResp is NULL until point G. in the diagram. The slave may use code DVA to indicate a successful burst, or ERR for an unsuccessful one.
OCP-IP Confidential
Figure 38
1 Clk MCmd MAddr MBurstSingleReq Request Phase MBurstSeq MBurstLength MBlockHeight MBlockStride SCmdAccept
BLCK IDLE RD1
RD2
RD2
IDLE
A1
A2
A2+S2
BLCK
BLCK
S1
S2
S2
Response Phase
NULL
DVA1
DVA1
DVA1
DVA1
DVA2
DVA2
NULL
D1
D1
D1
D1
D2
D2
Sequence
A. The master begins the first block read by asserting RD on MCmd, a valid address (A1) on MAddr, BLCK on MBurstSeq, 2 words per row on MBurstLength, 2 rows on MBlockHeight, and the row-to-row spacing (S1) on MBlockStride. The master identifies this as the only request for the read burst by asserting MBurstSingleReq. The slave asserts SCmdAccept signifying that it is ready to accept the request. B. The rising edge of the OCP clock ends the first request phase as the slave captures the request. The master starts the second block read at address A2, with only a single word per row, and requests 2 rows at a spacing of S2. The master deasserts MBurstSingleReq, indicating that there will be one request phase for each data phase. The slave keeps SCmdAccept asserted. The slave also returns a response to the original block burst,
OCP-IP Confidential
including the first word of data. Since there are more data words remaining in the first row of this burst, the slave deasserts SRespRowLast and SRespLast. C. The slave captures the first request for the second transaction, and keeps SCmdAccept asserted for the next cycle. The master presents the second (and last) request in the second block burst. The master sets MAddr to the starting address for the second row (A2 + S2). The master accepts the first response for the first burst. The slave returns the second data word for the first burst, which ends the first row, so the slave also asserts SRespRowLast. D. The slave accepts the second request for the second transaction. The master accepts the second response for the first burst. The slave returns the third data word for the first burst, which is the first word of the second row, so the slave deasserts SRespRowLast. E. The master accepts the third response for the first burst. The slave returns the fourth (and final) data word for the first burst, and asserts SRespLast and SRespRowLast. F. The master accepts the last response for the first burst. The slave returns the first data word for the second burst, which ends the first row, so the slave keeps SRespRowLast asserted and deasserts SRespLast. G. The master accepts the first response for the second burst. The slave returns the second (and final) data word for the second burst, and asserts SRespLast. H. The master accepts the last response for the second burst.
OCP-IP Confidential
Figure 39
Tagged Reads
13
WR2
RD3
RD4
IDLE
A1
A2
A3 = A2
A4
D2
13
01
DVA3
DVA1
NULL
D4
D3
D1
Sequence
A. The master starts the first read request, driving a RD on MCmd and a valid address on MAddr. The master drives a 0 on MTagID, indicating that this read request is for tag 0. The master also deasserts MTagInOrder, allowing the slave to reorder the responses. B. Since SCmdAccept is sampled asserted, the request phase ends with a request accept latency of 0. The master begins a write request to a second address, providing the write data on MData. The master asserts MTagInOrder, indicating that the slave may not reorder this request with respect to other in-order transactions and that MTagID is a dont care. C. When SCmdAccept is sampled asserted, the second request phase ends. The master launches a third request, which is a read to an address that matches the previous write. MTagInOrder is deasserted, enabling reordering, and the assigned tag value is 1. D. Since SCmdAccept is sampled asserted, the third request phase ends. The master launches a fourth request, which is a read. MTagInOrder is asserted, forcing ordering with respect to the earlier in-order write. The
OCP-IP Confidential
slave responds to the second request (the in-order write presented at B) by driving DVA on SResp. Since the transaction is in-order, STagInOrder is asserted and STagID is a dont care. E. SCmdAccept is sampled asserted so the fourth request phase ends. Since the response phase is sampled asserted, the response to the second request ends with a request-to-response latency of 2 cycles. The slave responds to the fourth request (D) by driving DVA on SResp and read data on SData. STagInOrder is asserted to match the associated request. This response was reordered with respect to the first (A) and third (C) requests, which allow reordering. F. The response phase is sampled asserted so the response to the fourth request ends with a request-to-response latency of 1 cycle. The slave responds to the third request (C) by driving DVA on SResp, read data on SData, and a 1 on STagID. STagInOrder is deasserted, indicating that reordering is allowed. This response is reordered with respect to the first request (A), but must occur after the second request (B), which has a matching address. G. Since the response phase is sampled asserted, the response to the third request ends with a request-to-response latency of 3 cycles. The slave responds to the first request (A) by driving DVA on SResp, read data on SData, and a 0 on STagID. STagInOrder is deasserted. H. When the response phase is sampled asserted, the response to the first request ends with a request-to-response latency of 6 cycles.
OCP-IP Confidential
Figure 40
1 Clk MTagID MCmd MAddr Request Phase MBurstSeq MBurstLength MData SCmdAccept
IDLE 01
12
IDLE
RD 1
RD2
IDLE
A1
A2
INCR
INCR
Response Phase
12
12
01
12
12
DVA 2
DVA2
DVA1
DVA2
DVA2
NULL
D2
D2
D1
D2
D2
Sequence
A. The master starts the first read request, driving RD on MCmd and a valid address on MAddr. The request is for a single-word incrementing burst, as driven on MBurstLength and MBurstSeq, respectively. The master also drives a 0 on MTagID, indicating that this read request is for tag 0. B. Once SCmdAccept is sampled asserted, the request phase ends with a request accept latency of 0. The master begins a four-word read request to a second, non-conflicting address, on tag 1. C. SCmdAccept is sampled asserted ending the second request phase. The slave responds to the second request by driving DVA on SResp together with 1 on STagID. The slave provides the first data word from the burst on SData. D. When the response phase is sampled asserted, the first response to the second request ends with a request-to-response latency of 1 cycle. The slave provides the second word of read data for tag 1 on SData, together
OCP-IP Confidential
with a DVA response. Because tag_interleave_size is 2 and the read burst sequence is packing, the slave was forced to return the second word of tag 1s data before responding to tag 0. E. The response phase is sampled asserted, terminating the second response to the second request with a request-to-response latency of 2 cycles. The slave responds to the first request by providing the read data for tag 0 together with a DVA response. F. When the response phase is sampled asserted, the response to the first request ends with a request-to-response latency of 4 cycles. Since the burst length of the first request is 1, the transaction on tag 0 is complete. The slave provides the third word of read data for tag 1 on SData, together with a DVA response. G. The response phase is sampled asserted so the third response to the second request ends with a request-to-response latency of 4 cycles. The slave provides the fourth word of read data for tag 1 on SData, together with a DVA response. H. When the response phase is sampled asserted, the fourth and final response to the second request ends with a request-to-response latency of 5 cycles.
Sequence
A. The master starts the first read request, driving RD on MCmd and a valid address on MAddr. The master 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 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 new read request, but this time it is for thread 1. The slave asserts SCmdAccept, however, it is not ready to respond.
OCP-IP Confidential
Figure 41
Threaded Read
1 Clk MThreadID MCmd Request Phase MAddr MData SCmdAccept SThreadID Response Phase SResp SData
A
NULL 01 IDLE 01
12
03
RD1
IDLE
RD2
RD3
IDLE
A1
A2
A3
03
12
DVA1
NULL
DVA3
NULL
DVA2
NULL
D1
D3
D2
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.
sthreadbusy_exact parameter is not set. In this case the master may ignore the SThreadBusy signals, and the slave does not have to accept requests even when it is not busy. When thread busy is treated as a hint and a request or thread is not accepted, the interface may block for all threads. Blocking of this type can be avoided by treating thread busy as an exact signal using the sthreadbusy_exact parameter. For an example, see Section 10.23. This example shows only the request part of the read transfers. The response part can use a similar mechanism for thread busy.
Figure 42 Threaded Read with Thread Busy
12
02
RD1
IDLE
RD2
RD3
IDLE
A1
A2
A3
SThreadBusy[1] SThreadBusy[0]
A B C D E F G
Sequence
A. The master starts the first read request, driving RD on MCmd and a valid address on MAddr. The master also drives a 0 on MThreadID, associating this read request with thread 0. The slave asserts SCmdAccept for a request accept latency of 0. B. Since SCmdAccept is asserted, the request phase ends. C. The slave asserts SThreadBusy[1] since it is not ready to accept requests on thread 1. The master ignores the hint, and launches a new read request for thread 1. The master can issue a request even though the slave asserts SThreadbusy (see transfer 2). All threads are now blocked.
OCP-IP Confidential
D. The slave deasserts SThreadBusy[1] and asserts SCmdAccept to complete the request for thread 1. E. Since SCmdAccept is asserted, the second request ends. The master issues a new request to thread 0. The slave is not ready to accept the request, and indicates this condition by keeping SCmdAccept deasserted. It chooses not to assert SThreadBusy[0]. The slave does not have to assert SCmdAccept for a request, even if it did not assert SThreadbusy (see transfer 3). F. The slave asserts the SCmdAccept to complete the request on thread 0. G. The master captures the SCmdAccept to complete the requests.
12
03
RD1
IDLE
RD2
RD3
IDLE
A1
A2
A3
SThreadBusy[1] SThreadBusy[0]
A B C D E
OCP-IP Confidential
Sequence
A. The master starts the first read request, driving RD on MCmd and a valid address on MAddr. The master also drives a 0 on MThreadID, indicating that this read request is for thread 0. B. Since SThreadBusy[0] is not asserted, the request phase ends. The slave samples the data and address and asserts SThreadBusy[1] since it is unready to accept requests on thread 1. The master is prevented from sending a request on thread 1, but it can send a request on another thread. C. The slave deasserts SThreadBusy[1] and the master can send the request on thread 1. D. Since SThreadBusy[1] is not asserted, the request phase ends and the slave must sample the data and address. The master can send a request on thread 0 (or thread 1). E. Since SThreadBusy[0] is not asserted, the request phase ends and the slave must sample the data and address.
Sequence
A. Because both SThreadBusy signals were sampled asserted on this rising edge of the OCP clock, the master may not present requests on either thread. The slave indicates its readiness to accept a request on thread 0 in the next cycle by de-asserting SThreadBusy[0]. B. After sampling SThreadBusy[0] deasserted, the master asserts the first read request on thread 0 by driving a 0 on MThreadID, RD on MCmd and a valid address on MAddr. The slave indicates that it can accept requests on both threads in the next cycle by de-asserting SThreadBusy[1] and leaving SThreadBusy[0] deasserted.
OCP-IP Confidential
Figure 44
01
12
13
RD1
RD2
IDLE
RD3
A1
A2
A3
C. The masters first request is sampled by the slave and the request phase ends. The master samples SThreadBusy[1] deasserted and uses the information to assert a second read request, this time on thread 1. The slave asserts SThreadBusy[1] since it cannot guarantee that it can accept another request on thread 1 in the next cycle. D. The masters second request is sampled by the slave and the request phase ends. The master samples SThreadBusy[1] asserted, and is forced to drive MCmd to IDLE, since it has no more requests for thread 0 and the slave cannot accept a request on thread 1. The slave signals that it will be ready to accept requests on both threads in the next cycle by de-asserting SThreadBusy[1] and leaving SThreadBusy[0] deasserted. E. The master samples SThreadBusy[1] deasserted, and uses this information to assert a third read request on thread 1. The slave asserts SThreadBusy[1] since it cannot guarantee that it can accept another request on thread 1 in the next cycle. F. The masters third request is sampled by the slave and the request phase ends. The master samples SThreadBusy[1] asserted, and is forced to drive MCmd to IDLE.
OCP-IP Confidential
10.25 Reset
Figure 45 shows the timing of the reset sequence with MReset_n driven from the master to the slave. MReset_n must be asserted for at least 16 cycles of the OCP clock to ensure that the master and slave reach a consistent internal state. Because the interface does not include the EnableClk signal, the OCP clock is simply Clk.
Figure 45 Reset Sequence
14
15
16
17
VALID
Sequence
A. MReset_n is sampled active on this clock edge. Master and slave now ignore all other OCP signals, except for the connection signals, if present. In the first cycle a response to a previously issued request is presented by the slave and ready to be received by the master. Since the master is asserting MReset_n, the response is not received. The associated transaction is terminated by OCP reset so the response is withdrawn by the slave. B. MReset_n is asserted for at least 16 Clk cycles. C. A new transfer may begin on the same clock edge that MReset_n is sampled deasserted.
OCP-IP Confidential
However, the presence of EnableClk means that MReset_n must be asserted for 16 cycles of the OCP clock (that is, when the rising edge of Clk samples EnableClk asserted), which will require 31 cycles of Clk.
Figure 46 Reset with Clock Enable
29 30 31
32
33
34
35
VALID
Sequence
A. MReset_n and EnableClk are sampled active on this clock edge. Master and slave now ignore all other OCP signals, except for the connection signals, if present. B. MReset_n is asserted for at least 16 Clk cycles with EnableClk sampled high. C. A new transfer may begin on the same clock edge that MReset_n is sampled deasserted and EnableClk sampled high.
OCP-IP Confidential
Figure 47
Response Phase
Sequence
A. The master starts a read request by driving RD on MCmd. At the same time, it presents a valid address on MAddr. B. This clock edge is not valid since EnableClk is sampled low. The slave asserts SCmdAccept in this cycle for a request accept latency of 0. C. The slave uses the value from MAddr to determine what data to return. 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. D. Invalid clock edge. 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.
OCP-IP Confidential
Figure 48
12
13
14
15
IDLE
RD
NULL
M_DISC
M_CON
Sequence
A. The master samples the slaves vote to disconnect on SConnect. The master begins draining the interface by completing the request and datahandshake phases for any transactions that have already begun. B. Having sequenced the final request phase for the last in-flight transaction, the master has drained the request phase and asserts MCmd to IDLE. The master continues draining the interface by waiting for any outstanding response phases from the slave. C. Having sequenced the final response phase for the last in-flight transaction, the slave has drained the response phase and asserts SResp to NULL. The master samples the final response and can change the connection state directly to M_DISC without passing through M_WAIT, since SWait is negated and the interface is quiescent. Independently, the slave votes to connect by asserting SConnect. D. The master samples the slaves vote to connect, but cannot change the connection state until 2 cycles have passed. E. The master re-establishes connection by changing the connection state to M_CON. The master may not assert any new transaction until the slave samples the new connection state. F. The slave samples MConnect and the interface is fully connected. The master asserts a read transaction on MCmd.
states. In each case, the master is thus forced to transition through the M_WAIT transient state on the way to the desired stable state. The data flow and other sideband signals are not shown in the figure for clarity; their behavior is described in the sequence description, below.
Figure 49 Connection Transition Sequences with Slave Pacing
12
13
14
15
M_WAIT
M_OFF
M_WAIT
M_DISC
Sequence
A. The master votes to disconnect (not visible from the interface). Because all data flow transactions are complete, the interface is quiescent and the master changes the connection state by asserting MConnect to M_WAIT, since SWait is asserted. B. The slave samples the M_WAIT state and determines that all sideband signaling is quiescent and the slave is ready to allow disconnect. The slave negates SWait to enable the master to complete the disconnection sequence. C. The master samples SWait negated and changes the connection state to a master-requested disconnect by asserting MConnect to M_OFF. D. The slave samples the M_OFF state and asserts SWait to pace future state changes. The slave also votes to disconnect by negating SConnect. E. The master votes to connect (not visible from the interface) but samples SConnect negated and begins the transition to a slave-requested disconnect. Because SWait is asserted, the master first asserts MConnect to M_WAIT. F. The slave samples the M_WAIT state and determines that it is ready to allow the connection state change, so it negates SWait. G. The master samples SWait negated and changes the connection state to a slave-requested disconnect by asserting MConnect to M_DISC. H. The slave samples the M_DISC state and asserts SWait to pace future state changes.
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
Figure 50
1 Clk
RDOW
MCmd
IDLE
IDLE
MAddr
0x01
Request Phase
MBurstLength
WRAP
Response Phase
SResp
NULL
OK1
NULL
Sequence
A. B. C. The master starts the request on clock 1 by driving the associated request group signals. The slave asserts SCmdAccept in the same cycle. The slave captures the request signal group values and the request phase completes. The slave does the snoop intervention operation. The slave reports the results of the snoop intervention operation. The slave's cache does not contain the requested address so the response of OK is given on the SResp signal. The master recognizes the value on SResp and the transfer is completed.
D.
OCP-IP Confidential
Figure 51
1 Clk
RDOW
MCmd
IDLE
IDLE
MAddr
0x01
Request Phase
MBurstLength
MBurstSeq
WRAP
MBurstPrecise
SCmdAccept
Response Phase
SResp
NULL
DVA1
NULL
SCohState
STATE
D1B0
D1B1
D1B2
D1B3
SDataLast
Sequence
A. B. The master starts the request on clock 1 by driving the associated request group signals. The slave asserts SCmdAccept in the same cycle. The slave captures the request signal group values and the request phase completes. The slave does the snoop intervention operation.
OCP-IP Confidential
C.
The slave reports the results of the snoop intervention operation. The slave's cache contains the most up-to-date copy of the requested address so the response of DVA is given on the SResp signal. Simultaneously, the slave drives the first data beat onto SData. Also simultaneously, the slave drives the cacheline state onto SCohState. The Master recognizes the SResp value to denote valid data and latches the value of the first data beat on SData. Similarly for the 2nd data beat Similarly for the 3rd data beat. The Slave asserts SDataLast to denote it is driving the last data beat. The Master latches the 4th data beat and recognizes SDataLast to complete the transfer.
D. E. F. G.
OCP-IP Confidential
Figure 52
1 Clk
RDOW
MCmd
IDLE
IDLE
MAddr
0x01
Request Phase
MBurstLength
MBurstSeq
WRAP
MBurstPrecise
SCmdAccept
Response Phase
SResp
NULL
DVA1
NULL
SCohState
STATE
SData
D1B0
D1B1
D1B2
D1B3
SDataLast
MDataAccept
When the port parameter intport_split_tranx=1, a separate handshake mechanism is used for the data phase. Two additional signalsSDataValid and MDataAcceptare used for this data handshake.
OCP-IP Confidential
In this configuration, the signal SResp is no longer used to indicated the presence of valid data on the intervention port, instead the new signal SDataValid is used for that purpose. The signal SResp now only indicates whether the local processor contains a copy of the requested memory location or not and thus is only asserted for a single cycle per transaction. In the current example, the data transfer is still co-incident with the response phase. In the following examples, the data transfer is delayed after the response phase using these new signals.
Sequence
A. B. C. The master starts the request on clock 1 by driving the associated request group signals. The slave asserts SCmdAccept in the same cycle. The slave captures the request signal group values and the request phase completes. The slave does the snoop intervention operation. The slave reports the results of the snoop intervention operation. The slave's cache contains the most up-to-date copy of the requested address so the response of DVA is given on the SResp signal. Simultaneously, since the MDataAccept signal is asserted, the slave drives the first data beat onto SData and asserts SDataValid. Also simultaneously, the slave drives the cacheline state onto SCohState. The Master recognizes the SResp value and the response phase completes. The Master recognizes the SDataValid signal is asserted and latches the value of the first data beat. Similarly for the 2nd data beat Similarly for the 3rd data beat. The Slave asserts SDataLast to denote it is driving the last data beat. The Master latches the 4th data beat and recognizes SDataLast to complete the transfer.
D.
E. F. G.
OCP-IP Confidential
Figure 53
MCmd
IDLE
IDLE
MAddr
0x01
Request Phase
MBurstLength
MBurstSeq
WRAP
MBurstPrecise SCmdAccept
Response Phase
SResp
NULL
DVA
NULL
SCohState
STATE
SData
D1B0
D1B1
D1B2
D1B3
SDataLast
MDataAccept
The next diagram shows the use of the MDataAccept signal as a way for the Master to apply flow-control on the slave's data responses.
Sequence
A. B. C. The master starts the request on clock 1 by driving the associated request group signals. The slave asserts SCmdAccept in the same cycle. The slave captures the request signal group values and the request phase completes. The slave does the snoop intervention operation. The slave reports the results of the snoop intervention operation. The slave's cache contains the most up-to-date copy of the requested address so the response of DVA is given on the SResp signal. Simultaneously, the slave drives the first data beat onto SData and
OCP-IP Confidential
asserts SDataValid. Also simultaneously, the slave drives the cacheline state onto SCohState. However, since MDataAccept is de-asserted, the data phase signal group is held. D. The Master recognizes the SResp value and the response phase completes. The slave continues holding the data phase signals, awaiting the assertion of MDataAccept. The Master is finally ready to accept the data and asserts MDataAccept. The Master latches the data value for the 1st data beat. The Slave recognizes MDataAccept and drives the data value for the 2nd data beat. The Master latches the data value for the 2nd data beat. Similarly for the 3rd data beat. The Slave asserts SDataLast to denote it is driving the last data beat. The Master latches the 4th data beat and recognizes SDataLast to complete the transfer.
E. F.
G. H. I.
OCP-IP Confidential
Figure 54
10
MCmd
IDLE
IDLE
MAddr
0x01
Request Phase
MBurstLength
MBurstSeq
WRAP
MBurstPrecise
SCmdAccept
Response Phase
SResp
NULL
DVA
NULL
SCohState
STATE
SData
D1B0
D1B1
D1B2
D1B3
SDataLast
MDataAccept
The next diagram shows the use of the SDataValid signal as a way for the slave to separate the Response phase from the Data Transfer Phase. In systems with shadow copies of the cache tags, the response of the cache tags can be delivered earlier than the data.
Sequence
A. B. C. The master starts the request on clock 1 by driving the associated request group signals. The slave asserts SCmdAccept in the same cycle. The slave captures the request signal group values and the request phase completes. The slave does the snoop intervention operation. The slave reports the results of the snoop intervention operation. The slave's cache contains the most up-to-date copy of the requested address so the response of DVA is given on the SResp signal. Simultaneously, the slave drives the cacheline state onto SCohState.
OCP-IP Confidential
D.
The Master recognizes the SResp value and the response phase completes. Since SDataValid is not asserted, the Master waits for the data values. The Master continues waiting for SDataValid signal to assert. The Slave is finally ready to drive the data and asserts SDataValid and the first data value on SData. The Master latches the data value for the 1st data beat. The Slave drives the data value for the 2nd data beat since MDataAccept was asserted. The Master latches the value for the 2nd data beat. The Slave drives the value for the 3rd data beat. Similarly for the 3rd data beat. The Slave asserts SDataLast to denote it is driving the last data beat. The Master latches the 4th data beat and recognizes SDataLast to complete the transfer.
E. F. G. H. I. J.
OCP-IP Confidential
Figure 55
Overlapped Transactions
1 Clk
RDOW RDOW 2
10
MCmd
IDLE
IDLE
MAddr
0x01
0x1002
Request Phase
MBurstLength
MBurstSeq
WRAP
WRAP
MBurstPrecise
SCmdAccept
Response Phase
SResp
NULL
DVA1
OK2
NULL
SCohState
STATE 1
SData
D1B0
D1B1
D1B2
D1B3
SRespLast
MDataAccept
The following figure shows overlapped transactions with the response phase for the second transaction happening before the data transfer of the first transaction is completed.
Sequence
A. B. The master starts the first request on clock 1 by driving the associated request group signals. The slave asserts SCmdAccept in the same cycle. The slave captures the request signal group values and the request phase completes. The slave does the first snoop intervention operation. The master starts the second request by driving new values for the request group signals. The slave accepts the second request by asserting SCmdAccept in the same cycle.
OCP-IP Confidential
C.
The slave reports the results of the first snoop intervention operation. The slave's cache contains the most up-to-date copy of the requested address so the response of DVA is given on the SResp signal. Also simultaneously, the slave drives the cacheline state onto SCohState. In the same cycle, the slave does the second snoop intervention operation. The Master recognizes the first SResp value and the first response phase completes. Since SDataValid is not asserted, the Master waits for the data values. The slave reports the results of the second snoop intervention operation. The slave's cache does not contain the second requested address so the response of OK is given on the SResp signal. The Master continues waiting for SDataValid signal to assert. The Master recognizes the second SResp value and the second response phase is completed. Since the second transaction does not have a data phase, it is completed. The Slave is finally ready to drive the data for the first request and asserts SDataValid and the first data value on SData. The Master latches the data value for the 1st data beat. The Slave drives the data value for the 2nd data beat since MDataAccept was asserted. The Master latches the value for the 2nd data beat. The Slave drives the value for the 3rd data beat. Similarly for the 3rd data beat. The Slave asserts SDataLast to denote it is driving the last data beat. The Master latches the 4th data beat and recognizes SDataLast to complete the transfer.
D.
E.
F. G. H. I. J.
OCP-IP Confidential
12 Developers Guidelines
This chapter collects examples and implementation tips that can help you make effective use of the Open Core Protocol and does not provide any additional specification material. This chapter groups together a variety of topics including discussions of: 1. The basic OCP with an emphasis on signal timing, state machines and OCP subsets 2. Simple extensions that cover byte enables, multiple address spaces and in-band information 3. An overview of burst capabilities 4. The concepts of threading, tagging extensions, and connections 5. OCP features addressing write semantics, synchronization issues, and endianness 6. Sideband signals with an emphasis on reset management and the connection protocol 7. A description of the debug and test interface
OCP-IP Confidential
OCP-IP Confidential
The internal and external timing can be relaxed by recognizing that the EnableClk signal permits a restricted duty cycle (for instance, only high for every third Clk cycle). Taking advantage of this extra timing margin requires careful control over the timing flow, which may include definition and analysis of multi-cycle paths and other challenges. The design flow must assure that the system-side logic that generates EnableClk does not violate the duty cycle assumption. Finally, the timing flow must ensure that no timing issues arise due to the low duty cycle of the effective OCP clock.
OCP-IP Confidential
As the request phase does not begin until MCmd is asserted, SCmdAccept is a dont 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 OCP clock cycle. High-throughput slaves can approach this rate by providing sufficient internal resources to end most request phases in the same OCP clock cycle that they start. This implies a combinational path from the masters 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 additional requests to present, it can start a new request phase on the next OCP clock cycle. Achieving such high throughput in highfrequency systems requires careful design including cycle time budgeting as described in Section 14.3 on page 316.
(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. If a target core natively includes buffering resources that can be used for response flow control at little cost, using MRespAccept can reduce the response buffering requirement in a complex SOC interconnect. Most simple or low-throughput slave IP cores need not implement MRespAccept. Misuse of MRespAccept makes the slaves job more difficult, because it adds extra conditions (and states) to the slaves logic.
OCP-IP Confidential
Figure 56
Sequential Master
~(WrReq | RdReq)
Idle
Wr Re q
MCmd=Idle
q Re L) Rd pt UL ce N Ac != md p SC es SR &(
cc ep t
~SCmdAccept
~SCmdAccept
SResp != NULL
SC md A
Write
MCmd=Write
Read
MCmd=Read
Wait Resp
MCmd=Idle
State
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 (this example assumes write posting with no response on writes), 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 enabled in this example, 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 transitions 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
OCP-IP Confidential
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 Section 12.1.3.3 on page 220. 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.
(MCmd == Idle)
Idle
Wr it e) ==
d Cm (M ==
(M Cm d
) ad Re
Write
SCmdAccept SResp=NULL WE
Read
SCmdAccept SResp=DVA ~WE
Legend:
State
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 MRespAccept is not enabled in this example, the response phase will end in the same cycle it begins. Writes without responses are assumed so SResp is NULL during the write state. 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.
OCP-IP Confidential
As is the case for the sequential master shown in Figure 56 on page 218, 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 OCP clock 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.
OCP-IP Confidential
Figure 58
Request
Wait Resp
Legend: ~(WrReq | RdReq) /MCmd=Idle, ~Ack WrReq/MCmd=Write, Ack=SCmdAccept RdReq & ~SCmdAccept/MCmd=Read, ~Ack RdReq & SCmdAccept & (SResp != NULL) /MCmd=Read, Ack
State
Input/output Required Arc Optional Arc
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 analysis. 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 appropriate for both the highest-performance and lowest-performance ends of the spectrum. A Moore state machine implementation may be more appropriate at medium performance.
OCP-IP Confidential
Figure 59
Idle
Legend: (MCmd == Read)/ SCmdAccept, SResp=DVA
State
The implementation shown in Figure 59, 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: OCP clock 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 higherperformance 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.
OCP-IP Confidential
Some sample interfaces are listed in Table 45. For each example the nondefault parameter settings are provided. The list of the corresponding OCP signals is provided for reference. Subset variants can further be derived from these examples by enabling various OCP extensions. For guidelines on suggested OCP feature combinations, see Section 15 on page 319.
Table 45 OCP Subsets
Usage
Handshake-only OCP
Purpose
Non-default parameters
Signals
Simple request/acknowledge read_enable=0, Clk, MCmd, handshake, that can be used to addr=0, mdata=0, SCmdAccept synchronize two processing modules. sdata=0, resp=0 Using OCP handshake signals with welldefined timing and semantics allows routing this synchronization process through an interconnect. The OCP command WR is used for requests, other commands are disabled. Interface for cores that only need to support writes. Interface for cores that only need to support reads. read_enable=0, sdata=0, resp=0 write_enable=0, mdata=0 Clk, MAddr, MCmd, MData, SCmdAccept Clk, MAddr, MCmd, SCmdAccept, SData, SResp
Write-only OCP
Read-only OCP
read_enable=0 Clk, MCmd, addr=0, sdata=0, MData, resp=0 SCmdAccept write_enable=0, Clk, MCmd, addr=0, mdata=0 SCmdAccept, SData, SResp addr=0 Clk, MCmd, MData, SCmdAccept, SData, SResp
OCP-IP Confidential
Even for simpler OCP cores, it is good practice to implement the byte enable extension, making byte addressing available at the chip level with no restrictions for the host processors. When a datahandshake phase is used (typically for a single request-multiple data burst), bursts must have the same byte enable pattern on all write data words. It is often necessary to send or receive write byte enables with the write data. To provide full byte addressing capability, the MDataByteEn field can be added to the datahandshake phase. This field indicates which bytes within the OCP data write word are part of the current write transfer. For example, on its master OCP port, a 2D-graphics accelerator can use variable byte enable patterns to achieve good transparent block transfer performance. Any pixel during the memory copy operation that matches the color key value is discarded in the write by de-asserting the corresponding byte enable in the OCP word. Another example is a DRAM controller that, when connected to a x16-DDR device, needs to use the memory data mask lines to perform byte or 16-bit writes. The data mask lines are directly derived from the byte enable pattern. Unpacking operations inside an interconnect can generate variable byte enable patterns across a burst on the narrower OCP side, even if the pattern is constant on the wider OCP side. Such unpacking operations may also result in a byte enable pattern of all zeros. Therefore, it is mandatory that slave cores fully support 0 as a legal pattern. An OCP interface can be configured to include partial word transfers by using either the MByteEn field, or the MDataByteEn field, or both. If only MByteEn is present, the partial word is specified by this field for both read and write type transfers as part of the request phase. This is the most common case. If only MDataByteEn is present, the partial word is specified by this field for write type transfers as part of the datahandshake phase, and partial word reads are not supported. If both MByteEn and MDataByteEn are present, MByteEn specifies partial words for read transfers as part of the request phase, and is dont care for write type transfers. MDataByteEn specifies partial words for write transfers as part of the datahandshake phase, and is dont care for read type transfers.
OCP-IP Confidential
Another example of the usage of the addrspace extension is the case of an OCP-to-PCI bridge, since PCI natively supports address spaces for configuration registers, memory spaces and i/o spaces.
MReqInfo
Uses for MReqInfo can include user/supervisor storage attributes, cacheable storage attributes, data versus program access, emulation versus application access or any other access-related information, such as dynamic endianness qualification or access permission information. MReqInfo bits have no assigned meanings but have behavior restrictions. MReqInfo is part of the request phase, so when MCmd is Idle, MReqInfo is a dont care. When MCmd is asserted, MReqInfo must be held steady for the entire request phase. MReqInfo must be constant across an entire transaction, so the value may not change during a burst. This facilitates simple packing and unpacking of data at mismatched master/slave data widths, eliminating the transformation of information.
SRespInfo
Uses for SRespInfo can include error or status information, such as FIFO full or empty indications, or data response endianness information. SRespInfo bits have no assigned meaning, but have behavior restrictions. SRespInfo is part of the response phase, so when SResp is NULL, SRespInfo is a dont care. When SResp is asserted, SRespInfo must be held steady for the entire response phase. Whenever possible, slaves that generate SRespInfo values should hold them constant for the duration of the transaction, and choose semantics that favor sticky status bits that stay asserted across transactions. This simplifies the design of interconnects and bridges that span OCP interfaces with different configurations. Holding SRespInfo constant improves simple packing and unpacking of data at mismatched data widths. The spanning element may need to break a single transaction into multiple smaller transactions, and so manage the combination of multiple SRespInfo values when the original transaction has fewer responses than the converted ones. If you implement SRespInfo as specified, your implementation should work in future versions of the specification. If the current implementation does not meet your needs, please contact techsupport@ocpip.org so that the Specification Working Group can investigate how to satisfy your requirements.
OCP-IP Confidential
OCP-IP Confidential
Address Sequences
Using the MBurstSeq field, the OCP burst model supports commonly-used address sequences. Benefits include: A simple incrementing scheme for regular memory type accesses A constant addressing mode for FIFO oriented targets (typically peripherals) Wrapping on power-of-two boundaries XOR for processor cache line fill A block transfer scheme for 2-dimensional data stored in memory
User-defined sequences can also be defined. They must be carefully documented in the core specification, particularly the rules to be applied when packing or unpacking. The address behavior for the different sequence types is: INCR Each address is incremented by the OCP word size. Used for regular memory type accesses, SDRAM, SRAM, and burst Flash. STRM The address is constant during the burst. Used for streaming data to or from a target, typically a peripheral device including a FIFO interface that is mapped at a constant address within the system. DFLT1 User-specified address sequence. Maximum packing is required.
OCP-IP Confidential
DFLT2 User-specified address sequence. Packing is not allowed. WRAP Similar to INCR, except that the address wraps at aligned MBurstLength * OCP word size. This address sequence is typically used for processor cache line fill. Burst length is necessarily a power-of-two, and the burst is aligned on its size. XOR Addr = BurstBaseAddress + (index of first request in burst) ^ (current word number). XOR is used by some processors for critical-word first cache line fill from wide and slow memory systems. While it does not always deliver the next sequential words as quickly as WRAP, the XOR sequence maps directly into the interleaved burst type supported by many DRAM devices. The XOR sequence is convenient when there are width differences between OCP interfaces, since the sequence is chosen to successively fill power-of-two sized and aligned words of greater width until the burst length is reached. BLCK Describes a sequence of MBlockHeight row transfers, with the starting address MAddr, row-to-row offset MBlockStride (measured from the start of one row to the start of the next row), and rows that are MBurstLength words long in an incrementing row address per word. MBlockHeight and MBlockStride can be considered as dont care for burst sequences other than BLCK. Figure 60 depicts a block transaction representing a 2dimensional region out of a larger buffer, showing the various parameters.
Figure 60 BLCK Address Sequence
MBurstLength MBlockStride
MBlockHeight
OCP-IP Confidential
The following example shows how to decompose a BLCK burst into a sequence of INCR bursts.
addr = MAddr; for (row = 0; row < MBlockHeight; row++, addr += MBlockStride) { issue INCR using all provided fields (including MBurstLength), except use "addr" for MAddr }
UNKN Indicates that there is no specified relationship between the addresses of different words in the burst. Used to group requests within a burst container, when the address sequence does not match the pre-defined sequences. For example, an initiator can group requests to nonconsecutive addresses on the same SDRAM page, so that the target memory bandwidth can be increased. For targets that have support for some burst sequence, adding support for the UNKN burst sequence can improve the chances of interoperability with other cores and can ease verification since it removes all requirements from the address sequence within a burst. For single requests, MBurstSeq is allowed to be any value that is legal for that particular OCP interface configuration. The BLCK, INCR, DFLT1, WRAP, and XOR burst sequences are always considered packing, whereas STRM and DFLT2 sequences are non-packing. Transfers in a packing burst sequence are aggregated / split when translating between OCP interfaces of different widths while transfers in a non-packing sequence are filled / truncated. The packing behavior of a bridge or interconnect for an UNKN burst sequence is system-dependent. A common policy is to treat an UNKN sequence as packing in a wide-to-narrow OCP request width converter, and as nonpacking in a narrow-to-wide OCP request width converter.
OCP-IP Confidential
multiple data write bursts, the datahandshake phase is locked to the request phase, so this interface configuration only makes sense when both single and multiple request bursts are mixed (that is, burstsinglereq is set).
Unit of Atomicity
Use this option when there is a requirement to limit burst interleaving between several threads. Specifying the atomicity allows the master to define a transfer unit that is guaranteed to be handled as an atomic group of requests within the burst, regardless of the total burst length. The master indicates the size of the atomic unit using the MAtomicLength field.
OCP-IP Confidential
MBurstSeq =
INCR for MBurst {CONT, TWO, FOUR, EIGHT} STRM for MBurst {STRM} DFLT1 for MBurst {DFLT1} DFLT2 for MBurst {DFLT2}
The logic must guarantee that MBurstSeq is constant during the whole burst and must continue driving that MBurstSeq when MBurst=LAST is detected. The value of MBurstLength is derived as follows: MBurstLength = 8 4 2 1 for for for for MBurst MBurst MBurst MBurst {EIGHT} {FOUR} {TWO, CONT, DFLT1, DFLT2, STRM} {LAST}
For precise bursts, MBurstLength is held constant for the entire burst. For imprecise bursts, a new MBurstLength can be derived for each transfer. MReqLast is derived from MBurst - it is set when MBurst is LAST. SRespLast has no equivalent in OCP1.0, and is discarded by the wrapping logic. If required, MDataLast must be generated from a counter or from a queue updated during the request phase.
OCP-IP Confidential
TWO if MBurstLength >= 2 LAST if MBurstLength == 1 else if MBurstSeq {DFLT1, DFLT2, STRM} LAST if MBurstLength == 1 same as MBurstSeq if MBurstLength != 1 else if MBurstSeq {WRAP, XOR, UNKN} LAST always (map to non-burst) MAtomicLength, MReqLast, and MDataLast have no equivalents in OCP 1.0, and are discarded by the wrapping logic. SRespLast must be generated from counter logic.
The logic described above is not suitable if the OCP 2.0 master generates single request / multiple data bursts. In that case, more complex conversion logic is required.
12.4 Tags
Tags are labels that associate requests with responses in order to enable outof-order return of responses. In the face of different latencies for different requests (for instance, DRAM controllers, or multiple heterogeneous targets), allowing the out-of-order delivery of responses can enable higher performance. Responses are returned in the order they are produced rather than having to buffer and re-order them to satisfy strict response order requirements. Tagged transactions to overlapping addresses have to be committed in order but their responses may be reordered if the transactions have different tag IDs (see Section 4.7.1 on page 57). As is the case for threads, to make use of tags, the master will normally need a buffer. The tag value generally only has meaning to the master as it is made up by the master and often corresponds to a buffer ID. The tag is carried by the slave and returned with the response. In the case of datahandshake, the master also tags the datahandshake phase with the tag of the corresponding request. Out-of-order request and response delivery can also be enabled using multiple threads. The major differences between threads and tags are that threads can have independent flow control per thread and have no ordering rules for transfers on different threads. Tags, on the other hand, exist within a single thread so are restricted to a single flow control for all tags. Also, transfers within the same thread still have some (albeit looser) ordering rules when tags are in use. The need for independent flow control requires independent buffering per thread, leading to more complex implementations. Tags enable lower overhead implementations for out-of-order return of responses. Tags are local to a single OCP interface. In a system with multiple cores connected to a bridge or interconnect, it is the responsibility of the interconnect to translate the tags from one interface to the other so that a target sees different tags for requests issued from different initiators. Target core implementation can facilitate the job of the bridge or interconnect by supporting a large set of tags.
OCP-IP Confidential
The MTagInOrder and STagInOrder signals allow both tagged and non-tagged (in-order) initiators to talk to a tagged target. Requests issued with MTagInOrder asserted must be completed in-order with respect to other inorder transactions, so an in-order initiator can guarantee that its responses are returned in request order. To retain compatibility with non-tagged initiators, targets that support tags should also support MTagInOrder and STagInOrder. When MTagInOrder is asserted any MTagID and MDataTagID values are dont care. Similarly, the STagID value is dont care when STagInOrder is asserted. Nonetheless, it is suggested that the slave return whatever tag value the master provided. Multi-threaded OCP interfaces can also have tags. Each threads tags are independent of the other threads tags and apply only to the ordering of transfers within that thread. There are no ordering restrictions for transfers on different threads. The number of tags supported by all threads must be uniform, but a master need not make use of all tags on all threads.
12.5.1 Threads
The thread capability relies on a thread ID to identify and separate independent 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) or must follow the ordering rules for tagging (if tags are in use), 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 DRAM controller could respond to a second read request from a higher-priority initiator before servicing a first request from a lower-priority initiator on a different thread. As routing congestion and physical effects become increasingly difficult at the back-end stage of the ASIC process, multithreading offers a powerful method of reducing wires. Many functional connections between initiator and target pairs do not require the full bandwidth of an OCP link, so sharing the same
OCP-IP Confidential
wires between several connections, based on functional requirements and floor planning data, is an attractive mechanism to perform gate count versus performance versus wire density trade-offs. 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. The MDataThreadID signal simplifies the implementation of the datahandshake extension along with threading, by providing the thread ID associated with the current write data transfer. When datahandshake is enabled, but sdatathreadbusy is disabled, the ordering of the datahandshake phases must exactly match the ordering of the request phases. The thread busy signals provide status information that allows the master to determine which threads will not accept requests. That information also allows the slave to determine which threads will not accept responses. These signals provide for cooperation between the master and the slave to ensure that requests are not presented on busy threads. While multithreading support has a cost in terms of gate count (buffers are required on a thread-per-thread basis for maximum efficiency), the protocol can ensure that the multi-threaded interface is non-blocking. Blocked OCP interfaces introduce a thread dependency. If thread X cannot proceed because the OCP interface is blocked by another thread, Y that is dependent on something downstream that cannot make progress until thread X makes progress, there is a classic circular wait condition that can lead to deadlock. In the OCP1.0 Specification, the semantics of SThreadBusy and MThreadBusy allow these signals to be treated as hints. To guarantee that a multi-threaded interface does not block, both master and slave need to be held to tighter semantics. OCP 2.2 allows cores to follow exact thread busy semantics. This process enables tighter protocol checking at the interface and guarantees that a multi-threaded OCP interface is non-blocking. Parameters to enable these extensions are sthreadbusy_exact, sdatathreadbusy_exact, and mthreadbusy_exact. There is one parameter for each of the OCP phases, request, datahandshake (assuming separate datahandshake) and response (assuming response flow control). The following conditions are true: On an OCP interface that satisfies sthreadbusy_exact semantics, the master is not allowed to issue a command to a busy thread. On an OCP interface that complies with sdatathreadbusy_exact semantics, the master is not allowed to issue write data to a busy thread. On an OCP interface that complies with mthreadbusy_exact semantics, the slave is not allowed to issue a response to a busy thread.
OCP-IP Confidential
These rules allow the phase accept signals (SCmdAccept, SDataAccept or MRespAccept) to be tied off to 1 on multi-threaded interfaces for which the corresponding phase handshake satisfies exact thread busy semantics. By eliminating an additional combinational dependency between master and slave, an exact thread busy based handshake can be considered as a substitute for the standard request/accept protocol handshake. For more information, see Section 12.5.1.2 on page 237.
Request Phase
If enabled, a slaves 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 masters 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 become unavoidable if the exact semantics apply (sthreadbusy_exact = 1). In that case the slave must guarantee that SThreadBusy becomes stable early in the OCP cycle to achieve good frequency performance. A common goal is that SThreadBusy be driven directly from a flip-flop in the slave. A masters 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 slaves SCmdAccept depends upon the current MCmd. If a slaves SCmdAccept request phase output is based upon the masters 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 multicycle 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:
OCP-IP Confidential
Clk -> SThreadBusy -> MCmd -> SResp -> MRespAccept -> SCmdAccept -> Clk
The preceding path has too much latency at typical clock frequencies, so must be avoided. Fortunately, 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:
SThreadBusy -> MCmd -> Clk SCmdAccept -> Clk # Slave accepts if pipeline reg empty SResp -> Clk MRespAccept -> Clk # Master accepts independent of SResp
Response Phase
If enabled, a masters MThreadBusy response phase output should not be dependent upon the current state of any other OCP signal. From the perspective 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 slaves response phase outputs may depend upon the current MThreadBusy. If MThreadBusy is simply a hint (in other words mthreadbusy_exact = 0) the slave is not required to include a combinational path from MThreadBusy into SResp, but such paths become unavoidable if the exact semantics apply (mthreadbusy_exact = 1). In that case the master must guarantee that MThreadBusy becomes stable early in the OCP cycle to achieve good frequency performance. A common goal is that MThreadBusy be driven directly from a flip-flop in the master. The slaves response phase outputs should not depend upon any current master output other than MThreadBusy. This ensures that there is no combinational loop in the case where the masters MRespAccept depends upon the current SResp. The masters MRespAccept response phase output may be based upon the slaves 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 Phase
If enabled, a slaves SDataThreadBusy datahandshake phase output should not depend upon the current state of any other OCP signal. SDataThreadBusy should be stable early enough in the cycle so that the master can factor the current SDataThreadBusy into the decision of which thread to present a data; that is, all of the masters data phase outputs may depend upon the current SDataThreadBusy. If SDataThreadBusy is simply a hint (in other words sdatathreadbusy_exact = 0) the master is not required to include a combinational path from SDataThreadBusy into MDataValid, but such path becomes unavoidable if the exact semantics apply (sdatathreadbusy_exact = 1). In that case, the slave must guarantee that SDataThreadBusy becomes
OCP-IP Confidential
stable early in the OCP cycle to achieve good frequency performance. A common goal is that SDataThreadBusy be driven directly from a flip-flop in the slave. The masters 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 slaves SDataAccept depends upon the current MDataValid. The slaves SDataAccept output may or may not be based upon the masters 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.
Request Group
Master
60%
Slave
12.5.1.3 Slave
Information 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 Section 14.3 on page 316). These signals are also used to generate SCmdAccept: if a particular port has room, a command on the corresponding thread is accepted. The
OCP-IP Confidential
correct port information is selected through a multiplexer 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.
12.5.1.4 Master
The 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 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 threads 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. The request phase in Figure 61 assumes a non-exact thread busy model. The exact model shown in Figure 62 is similar, but SCmdAccept is tied off to 1, so any request issued to a non-busy thread is accepted in the same cycle by the slave.
Figure 62 Multithreaded OCP Interface with threadbusy_exact
Request Group
Master
Buffer Update
Slave
12.5.2 Connections
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 can enable a system to restrict access to shared resources, or
OCP-IP Confidential
foster an error logging mechanism to identify an initiator whose request has created an error in the system. For devices where these concerns are important, the OCP extensions support connections. Connections 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 transfers 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 doesnt make sense to burden them or their masters with the expense of dealing with level3 resources. Alternatively, some slaves need the features of level-3 connections, so in this case it makes sense to pass the connection ID through to them. A connection ID is not usually provided by an initiator core on its OCP interface but is allocated to that particular initiator in the interconnect logic of the system. The connection ID is system-specific, not core-specific; only the system integrator has the global knowledge of the number of initiators instantiated in the application, and what the requirements are in terms of differentiation. As an exception to that rule, if the global interconnect consists of multiple hierarchical structures, a complete subsystem can be integrated (including another interconnect with multiple embedded initiators). In that case, the OCP interface between the two interconnects should implement the connid extension, so that the end-to-end meaning of that OCP field can be preserved at the system level. For a target core, the connid extension is included when such features as access control, error logging or similar initiator-related features require initiator identification.
OCP-IP Confidential
The writeresp_enable parameter controls whether the write-type commands WR and BCST have responses. The write-type commands WRNP and WRC, which are non-posted, always have responses. Table 46 summarizes the behavior with respect to the writeresp_enable parameter.
Table 46 Write Command Response Behavior
writeresp_enable 0
WR, BCST (without response) WRNP, WRC (with response)
1
WR, BCST, WRNP, WRC (with response)
Note that in Table 46, WR and WRNP are the general-purpose write commands; WRC is always associated with an RLC command. Use of the Broadcast command must be limited to a specific category of designs (some interconnect designs may benefit from simultaneous update through distributed registers). It is not expected that standard cores will support the Broadcast command.
OCP-IP Confidential
By separating whether writes have responses (writeresp_enable) from whether the core has control over where the responses are generated (writenonpost_enable), the OCP specification provides the following features: The simple, posted model remains intact. The simplest cores only implement WR, and need not worry about write responses. Cores that can generate or use write responses should enable write responses, providing support for in-band error reporting on write commands. The read and write state machines are duplicated from the standpoint of flow control, producing a simpler design. Such cores would normally only implement the WR command. In this case, the system integrator is in control of where in the write path the write response is generated, allowing a choice of the level of posting based upon performance and coherence trade-offs. Cores that can distinguish between performance and coherence (really only CPUs and bridges) can enable WRNP to implement dynamic choice between WR and WRNP. The additional signaling gives the system integrator the dynamic information needed to choose the posting point as the CPU requests. The only practical difference between WR and WRNP at the protocol level is the expected latency between request and response. This permits some embedded CPUs to achieve high performance particularly as interconnects become pipelined and posting buffers are needed.
write commands. Referred to as lazy synchronization, this mechanism requires read and write semantics, commonly known as LL/SC semantics, for Load-Linked and Store-Conditional. OCPs support for lazy synchronization uses the ReadLinked, and WriteConditional commands. A single OCP parameter rdlwrc_enable is set to 1, to enable the commands. Because some processors might use both semantics (locked and lazy), the OCP interface supports RDEX, RDL, WR(WRNP) and WRC. The system relies upon the existence of monitor logic, that can be located either in the system interconnect, or in the memory controller. The ReadLinked command sets a reservation in the logic, associating the accessing thread with a particular address. The WriteConditional command, being transmitted on the same thread, is locally transformed into a memory write access only if the reservation is still set when the command is received. As the tagged address is not locked, the tag can be reset by competing traffic directed to the same location from other threads between RDL and WRC. Consequently, the WRC command expects a response from the monitor logic, reflecting whether the write operation has been performed. To answer that requirement, OCP provides the value, FAIL for the SResp field (meaning that writeresp_enable is on if rdlwrc_enable is on). WRC is the only OCP command that makes use of the FAIL code, though new commands in future revisions may. FAIL responses are frequently received in a system using lazy synchronization that operates normally. Do not confuse FAIL with SResp=ERR, which effectively signals a system interconnect error or a target error. Both RDL and WRC commands assume a single transaction model and cannot be used in a burst. The semantics of lazy synchronization are defined on the previous page. Some specific sequences resulting from the usage of the RDL and WRC semantics are: A thread can issue more than one RDL before issuing a WRC, or issue more than one RDL without issuing WRC. Whether the subsequent RDL clears the reservation or sets a new one is implementation-specific, depending on the number of hardware monitors. At least one monitor per thread is required. If a thread issues a WR or WRNP command to an address it previously tagged with a RDL command, the write access clears all reservations from other threads for the same address (but not its own reservation). If a thread issues a WRC without having issued a RDL, the WRC will fail. If a thread issues a RDEX between the RDL and WRC, the RDEX is executed, sets the lock and waits for the corresponding write to clear the lock. RDL-WRC reservations will not be affected by the RDEX. The WR or WRNP that clears the lock, also clears any reservation set by other initiators for the same address (with the same MAddr, MByteEn and MAddrSpace if applicable).
OCP-IP Confidential
Because competing requests of any type from other threads to a locked (by RDEX) location are blocked from proceeding until the lock is released, a RDEX command being issued between RDL and WRC commands, also blocks the WRC until the WR or WRNP command clearing the lock is issued. This favours RDEX-WR or WRNP sequence over RDL-WRC, in the sense that competing RDEX-WR or WRNP and RDL-WRC sequences will always result in having the RDEX-WR or WRNP sequence win. Incorrect use of the two synchronization mechanisms can result in deadlock so for example, the sequence of commands shown in Figure 63 might result in a deadlock. In this example Processor 1 tries to release the semaphore using RDL-WRC commands, Processor 2 tries to acquire the semaphore using RDEX-WR or WRNP commands. The RDEX-WR or WRNP sequence always occurs between the RDL and WRC. Because the WR or WRNP clearing the lock in Processor2 will also clear the reservation for Processor 1, the RDL-WRC sequence will never succeed. Processor 1 will never be able to release the lock or Processor2 to acquire it.
Figure 63 Synchronization Deadlock
The deadlock depicted in Figure 63 is a result of bad programming in Processor 2, and is very unlikely to happen in a real application environment. As shown in Figure 64, to achieve forward progress, Processor 2 should read the semaphore value and wait for the semaphore to be free before trying to retrieve it by issuing a RDEX-WR or WRNP.
Figure 64 Correct Synchronization Sequence
RDEX W R(NP)
OCP-IP Confidential
OCP-IP Confidential
BOTH Qualifies cores that can change endianness: Based upon an external input such as a CPU that statically selects its endianness at boot time Based upon an internal configuration register such as a DMA engine, that generates OCP read and write requests in accordance with the endianness of the target, as stated by the DMA programmer Cores that support dynamic endianness
NEUTRAL Qualifies cores that have no inherent endianness. Examples are simple memory devices that only work with full OCP-word quantities, or peripheral devices, the endianness of which can be controlled by the software device driver. While not supported by the standard set of OCP features, it is possible to define a dynamic, endian-aware interconnect using in-band information. By specifying the parameters reqinfo (for request packing / unpacking control), mdatainfo (for data packing / unpacking control when datahandshake is enabled), and respinfo (for response packing / unpacking control), the definition of all these qualifiers becomes platform-specific.
12.6.4 Security
To protect against software and some selective hardware attacks use the OCP interface to create a secure domain across the SOC. The domain might include CPU, memory, I/O etc. that need to be secured using a collection of hardware and software features such as secured interrupts, and memory, or special instructions to access the secure mode of the processor. The master drives the security level of the request using MReqInfo as a subnet. The master provides initiator identification using MConnID. Table 47 summarizes the relevant parameters.
Table 47 Security Parameters
Parameter
reqinfo reqinfo_wdth connid connid_wdth
Value
1 Varies 1 Varies
Notes
MReqInfo is required Minimum width is 1 To differentiate initiators Minimum width is 1
The security request is defined as a named subnet MSecure within MReqInfo, for example:
OCP-IP Confidential
Value 0
non-secure user mode data request user mode non-host functional
Value 1
secure privileged mode instruction request supervisor mode host debug
A special error response is not specified. A security error can be signaled with response code ERR.
OCP-IP Confidential
For simulation and verification, such timing violations represent a major hurdle since they may lead to inconsistent states in the master, slave and monitor interfaces. To address this problem, whenever possible, generate resets in a synchronous manner even if the protocol allows for their asynchronous assertion. Use of OCP resets as asynchronous OCP reset requires that a reset signal observe the setup and hold times as defined in the cores timing guidelines for at least 16 rising OCP clock edges after reset assertion, making the signal effectively synchronous except at assertion time. To satisfy this requirement do not connect an input OCP reset signal to the asynchronous clear/set pin of a D-flip-flop involved in an OCP signal logic cone. Failure to comply with this rule may violate the OCP protocol. For instance, a glitch on an OCP reset signal that would be sampled as deasserted could be interpreted as asserted, inadvertently causing the receiver to cancel pending transactions and hang the interface.
Adding a second reset signal to the interface allows each master and slave to have both a reset output and input. The composite reset state for the OCP interface is established as the combination of the two resets, so that either side (or both) asserting reset causes the interface to be in reset. While in reset, the existing rules about the interface state and signal values apply. Either MReset_n or SReset_n must be present on any OCP interface. Compatibility between different reset configurations of master and slave interfaces is shown in Table 48.
OCP-IP Confidential
Table 48
Reset Configurations
sreset=0, mreset=1
sreset=1, mreset=1 Single reset driven by master (SReset_n input tied off to 1) Incompatible Dual resets
Dual resets driven by the Single reset driven by master same 3rd party Single reset driven by slave Single reset driven by slave (MReset_n input tied off to 1) Incompatible Incompatible
The rules describing this table can be stated as follows. Either mreset or sreset or both must be set to 1 for each core. The default (and only) tie-off value for MReset_n and SReset_n is 1. If mreset is set to 1 for the master and mreset is set to 0 for the slave, the reset configurations are incompatible. If sreset is set to 1 for the slave and sreset is set to 0 for the master, the reset configurations are incompatible.
Cores with a reset input are always interoperable with any other core. Add a reset output if it is needed by the core or subsystem to assure proper operation. Typically this is because both sides need to know about the reset state of the other side, or because the overall system does not function properly if the core or subsystem is in reset, while the OCP interface is not in reset.
connection protocol defines a mechanism for OCP masters and slaves to indicate to each other that a power state transition is desired and then to prepare for that transition. The connection signals allow the master and slave to cooperate to cleanly achieve quiescence before putting the interface into a disconnected state where none of the other in-band nor sideband signals are active, except for the OCP clock. Once the interface has been disconnected, the system can safely transition the power state without losing any transactions or sideband events. While the primary motivation behind the definition and inclusion of the connection protocol is to facilitate power management, there are likely other situations in which OCP masters and slaves may wish to disconnect, so the connection protocol has been defined as a general mechanism.
12.7.2.1 Goals
1. The OCP is connected only if both the master and the slave agree on this connected state. Either the master or the slave can independently request disconnection. 2. No restrictions on when either side can change its vote on the connection state. 3. The protocol should assure a clean disconnect. That is, no OCP transactions or sideband signal transitions can be corrupted during the disconnection process, including posted writes. 4. Connection state transitions will be performed by the master, no matter which side requested the transition. 5. The protocol should allow the side that is not requesting the connection state change to delay the state change until it is prepared to safely transition. 6. The protocol should permit the connection state to be determined from interface signals. That is, the protocol should be stateless at the interface. 7. The protocol should permit the system to distinguish between disconnected states initiated by only the slave request vs. those initiated by the master. 8. The protocol should allow an OCP-to-OCP bridge to easily manage its connection protocol responsibilities on both its upstream and downstream interfaces, without requiring that any system logic be needed to separately control the two interfaces. 9. The protocol should support the case of either side being powered down while disconnected by ensuring that a powered down side can safely ignore inputs and provide static protocol-defined default outputs, typically from isolation transceivers. 10. The protocol should ensure inter-operability with cores that do not implement the connection protocol. 11. The protocol should add a minimum of new configurability/complexity to OCP.
OCP-IP Confidential
12. The protocol should add a minimum of new signals to the interface. The protocol adds one new parameter to OCP, connection. When connection is one, four signals are added to the interface: MConnect, SConnect, SWait, and ConnectCap. One of these signals, ConnectCap, is intended to be tied-off at implementation time to support interoperability with cores that do not implement the connection protocol. Tie ConnectCap to logic 0 on cores that implement the protocol to force the connection state and all other signals to remain connected at all times. The state machine in Figure 65 describes the OCP connection states and the legal transitions between the states. As described in Section 4.3.3.2, the connection state is signaled by the master on the MConnect[1:0] signal. The master and slave are free to request changes to the connection state at any time, but the master is responsible to change the state safely to ensure that no transactions or sideband events are corrupted. Safe transitions are the result of some actions solely under the control of the master, and others which involve interactions with the slave. The system conditions that cause a master or slave to request a state change, and the complete list of actions taken to ensure a safe transition are system specific and outside the scope of the protocol; Figure 65 describes the transition conditions based on both the signals defined by the protocol and internal information from the master (which controls the state machine via its MConnect output).
Figure 65
M_CON
MConnect=3
cCON & ~SWait & ~mwait cCON & ~SWait & ~mwait cDISC & ~SWait & ~mwait
M_WAIT
cOFF & ~SWait & ~mwait MConnect=1
M_OFF
MConnect=0 (cCON | cDISC) & (SWait | mwait) cDISC & ~SWait & ~mwait (cCON | cOFF) & (SWait | mwait)
M_DISC
MConnect=2
In addition to the connection protocol signals MConnect and SWait, Figure 65 introduces several internal master conditions, which are described in Table 49 below. Note that only one of conditions cCON, cDISC and cOFF can be simultaneously true.
Table 49 cCON cDISC cOFF mwait Master Condition Description for Figure 65 Master is prepared to change state to M_CON; SConnect is S_CON Master is prepared to change state to M_DISC; SConnect is S_DISC Master is prepared to change state to M_OFF; SConnect is a dont care Master has chosen to transition through M_WAIT, independently from SWait
OCP-IP Confidential
The conditions cCON, cDISC and cOFF should not be true unless the master has determined that the connection state should change to the associated stable state value and the master has completed its role in assuring a safe transition. In particular, the master must assure that all transactions that it has issued have completed and that it will not issue any new transactions before setting either cDISC or cOFF while in M_CON. Note that it is up to the master to determine which additional transactions to present to the slave before responding to SConnect of S_DISC. The master should also attempt to reach quiescence on its sideband signal outputs before leaving M_CON. Furthermore, the cCON, cDISC and cOFF conditions must also ensure that the master remains in each stable state for at least two OCP clock cycles before transitioning, as described in Section 4.3.3.2. If the slave does not assert SWait, the master is generally free to transition directly between the stable states without entering M_WAIT. However, the master is free to enter M_WAIT independently from SWait, and this situation is modeled in the state machine using the mwait condition. Use of mwait is particularly helpful in linking the connection state machines of two OCP interfaces, such as in a bridging situation. For example, if the operation of the bridge requires the use of SWait on the upstream (bridge slave) interface, then the bridge can use mwait on the downstream interface (where it is master) so that the downstream interface can always copy the upstream interface's transitions to M_WAIT. This avoids the situation where the upstream interface has gone to M_WAIT and the downstream interface must then stay in its current stable state because the bridge cannot know what the next upstream stable state will be. While all dataflow communication must be complete before the master may leave M_CON, the master cannot generally cause slave sideband communication to become quiescent. Slaves that have sideband outputs other than SReset_n should assert SWait to S_WAIT whenever those outputs may be active. S_WAIT forces the master to transition through M_WAIT, thereby giving the slave the opportunity to end its sideband activity before the master disconnects. Note that some sideband communication protocols may require that the master respond (via its sideband outputs) to slave sideband signals while in M_WAIT. This is why the connection protocol cannot require quiescence on master sideband outputs before leaving M_CON and why M_WAIT entered from M_CON is still considered connected. On the way back to M_CON, sideband communication is not allowed until M_CON is reached. New transactions may not be issued in the same cycle that the interface transitions to M_CON. This is intended to allow the slave to sample the MConnect signal with the OCP clock, rather than reacting to it in the same cycle it is presented, which could adversely affect the operating frequency of the slave with little apparent benefit. A slave initiated disconnect (MConnect of M_DISC) may frequently occur when a slave core is powered off, but the master side - which is likely a system interconnect - is still powered. In such situations, the master side may need to manage the situation where a system initiator attempts to communicate with the disconnected slave. For instance, the master could automatically respond to initiator transactions with errors when the connection state is M_DISC. Future versions of this Specification may include specific features to control the upstream behavior for situations involving disconnected slaves.
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
The requesting coherent master, Proc0, initiates the CC_RDSH request transaction on the main OCP port to gain a sharing ownership on a memory address. This request is delivered as a read to the memory slave, Memory (the home of the read address), on its main OCP port. Concurrently, the coherence request is turned into a corresponding coherence intervention request (I_RDSH), which is delivered to other coherence masters on their intervention ports. Figure 66 shows three intervention requests sent to Proc0, Proc1, and Proc2, respectively. Note the self-intervention request (Self I_RDSH) sent back to Proc0.
OCP-IP Confidential
Figure 66
Snoop-Bus-Based OCP Coherence System: Coherent Master and Slave Ports, Communication Flow of a CC_RDSH Transaction
Mp: Req -- the request channel on the main OCP port Mp: Resp -- the response channel on the main OCP port Ip: Req -- the request channel on the intervention port Ip: Resp -- the response channel on the main OCP port
Proc0 $s
Proc1 $s
Proc2 $s
OCP wrapper
OCP wrapper
M-hit
Ip: Req
Mp: Req
Mp: Resp
Ip: Resp
Ip: Req
Mp
Ip: Resp
Ip: Req
Mp
Ip: Resp
Self H I_RDS
s Sy
H DS I_R
SH I_RD Sys
CC D _R SH
Mp: Req
Mp: Resp
OCP wrapper
Memory
Proc2, which has the cache line in M state, relinquishes its ownership on receipt of Sys I_RDSH request. Locally, it transitions to the S state. An intervention response with data is returned on master Proc2s intervention port back to the coherent slave. The coherent slave sends a response to the Proc0 response main port. The coherent slave also updates the memory by sending a write transaction to it. The initiating master receives, on the main port, the coherence response with the latest data and can update its coherence state to S for its cached copy of data from the memory address accordingly.
OCP-IP Confidential
The memory is updated with the modified value and has the latest copy. This flow assumes that the memory has not returned the response to the action in step (b). It is assumed that the memory controller will squash the internal read from memory on receipt of the updated contents at this step.
Note that we have shown one implementation choice. Other implementations are permitted using the set of OCP coherence extensions.
The initiating master, Proc0, initiates the transaction and sends a coherence CC_RDSH request, on the main OCP port, to gain a sharing ownership on a memory address. This coherence request is delivered to the Directory/Memory slave (the home of the read address) on its main OCP port.
OCP-IP Confidential
Figure 67
Mp: Req -- the request channel on the main OCP port Mp: Resp -- the response channel on the main OCP port Ip: Req -- the request channel on the intervention port Ip: Resp -- the response channel on the main OCP port
Proc0 $s
g
Proc2 $s
M-hit
Ip: Resp Ip: Req
OCP wrapper
Ip: Resp
Mp: Req
Mp: Resp
a Cache line Data and SCohState to S Self I_RDSH Cache line Data and SCohState to S
On the Directory/Memory slave, the directory-based coherence logic lookup indicates that master Proc2 has the latest dirty data. A self intervention request (Self I_RDSH) is returned to the initiating master, Proc0, using its intervention port. At the same time, a system coherence intervention request (Sys I_RDSH) is sent from the intervention port of the Directory/Memory slave to the intervention port of master Proc2 in order to retrieve the latest dirty data. In response master Proc2 relinquishes its exclusive ownership of the memory address, e.g., by changing its cached lines state from M (dirty) to S (shared); and returns an intervention response with data from its intervention port to the Directory/Memory slave.
CC D _R SH
sI Sy H DS _R
Mp: Req
Mp: Resp
Ip: Resp
Ip: Req
OCP Interconnect
OCP wrapper
b
Directory/Memory Slave
OCP-IP Confidential
Upon receiving the latest dirty data, both the directory and the memory are updated; in addition, the Directory/Memory slave returns the response with data and with coherence state information (of S) back to the initiating master Proc0 on its main port. The initiating master Proc0 receives the latest data response and updates its coherence state for the memory address accordingly.
13.2.1.1 Self-Intervention
Self-intervention is important for the design of the OCP Coherence Extensions. If the self-intervention request is not sent back to the initiating master, the master must enforce the order between the initiating masters main port response to a previously sent main port request and a new conflicting intervention request. To prevent a race between the two coherence masters trying to access the same cache line, the initiating master must block the conflicting intervention request from changing the masters coherence state until after the response to its prior coherent request has been received on its main port. This additional blocking creates a new dependency as shown on top in Figure 68-(B). As shown in the diagram with the top dashed arrow going from MP:resp to Ip:request, this forms a circular dependency and violates the dependence ordering for deadlock avoidance. Figure 68-(C) is a simplified legal dependency diagram that can be applied to the main and intervention ports of a single coherence master or slave where the self-intervention request sets the ordering of the initiators request with respect to other coherent intervention requests at the initiating masters intervention port. With self-intervention, there is no circular dependency between ports for a coherence master or slave; therefore, self-intervention is critical to correct OCP coherence operation and to deadlock avoidance.
OCP-IP Confidential
Figure 68
Mp: Req -- the request channel on the main OCP port Mp: Resp -- the response channel on the main OCP port Ip: Req -- the request channel on the intervention port Ip: Resp -- the response channel on the main OCP port (A) With self-intervention
Mp: Req
Mp: Resp
Ip: Resp
Ip: Req
Coherence Master 0
Mp: Req
Mp: Resp
Ip: Resp
Ip: Req
Coherence Master 1
Mp: Req
Mp: Resp
Ip: Resp
Ip: Req
Coherence Slave 0
Needed in order to decide the order between Mp responses and Sys intervention requests
Dependencies between main and intervention ports of each coherence master or slave
Mp: Req
Mp: Resp
Ip: Resp
Ip: Req
Mp: Req
Mp: Resp
Ip: Resp
Ip: Req
OCP-IP Confidential
Figure 69
CPU2 L1i, L1d CPU3,4 Coh DMA1 DSP NonCoh $ DMA2 (Legacy Core)
L2 (MSI)
Coh $
Coh $
OCP wrapper
OCP wrapper
OCP wrapper
OCP wrapper
MP1
IP1
MP2
IP2
MP3
OCP4
OCP8
OCP6
OCP5
OCP7
Memory Controller/DRAM For Coherent and Non-Coherent Address Regions Memory Sub System
OCP Connections Main Port (bi-directional, with coherence extensions) Intervention Port (bi-directional) Legacy Port (bi-directional)
OCP-IP Confidential
Every request reaching the serialization point will be served and completed before any other subsequent conflicting requests. In the Directory module, which is the home of cache lines provided by the memory module, conflicting requests are serialized (i.e., served and completed one by one) in the order they arrive to the directory module. This serialization is to prevent possible deadlock causing by two initiators concurrently accessing to the same cache line. Note that a request that hasnt reached the serialization point has no effect on the requestors or any other coherent masters cache line state. Requests are also serialized in the order they arrive to the Directory module for the coherent I/O A module.
Address regions 1 and 7 are non coherent address regions associated with the Memory module directly. Address region 5 is for the I/O B slave only.
Note that in the example design the OCP main port requests are routed by the interconnect module based on the OCP MAddr field and the address-regionto-slave (or proxy-slave) assignments mentioned above. In addition, care must be taken to ensure that the request re-dispatching, which also uses the MAddr field, between the Directory, I/O A, and Memory modules is handled properly without interfering with the main routing domain between masters and slaves.
OCP-IP Confidential
As for intervention port requests, since the MAddr field value is used to indicate which data line is of interest for an intervention transaction, the Coherent Core Identification is used to indicate the destination of each intervention request.
System Connectivity
For simplicity, in this example design, we have the following address region and command issuing limitations (note that these are not requirements imposed by the OCP coherence extensions): Legacy slaves can only have non-coherent address regions (such as I/O B) Coherent slaves can have both coherent and non-coherent address regions (such as the Memory slave), or have only coherent address regions (such as I/O A). OCP coherent and coherence-aware commands can only target coherent address regions. OCP legacy commands can be sent to only non-coherent address regions.
System Address Map
Figure 70
Address Max
Address Region 7: - to /Memory, non-choerent Address Region 5: - to I/O B, non-coherent Address Region 8: - to Directory => Memory, coherent
OCP-IP Confidential
The following main port connectivity maps (for domains 1 and 2) between OCP masters and slaves are used for the example design in order to determine how to deliver OCP main port or legacy port requests: Domain 1: CPU1/2 Address Region 0, 1, 2, 3, 4, 5, 6, 7, and 8 We need: a connection to the Directory module for regions 0, 2, 3, 4, 6, and 8; a connection to the Memory module directly for regions 1 and 7; and a connection to the non-coherent I/O B module for region 5. CPU3/4 Address Region 0, 4, 6, and 8 We need a connection to the Directory module. Coherent DMA1 Address Region 2, 3, and 4 We need a connection to the Directory module. DSP Address Region 0, 1, 4, 6, 7, and 8 We need a connection to the Directory module for regions 0, 4, 6, and 8, and a connection to the Memory module for regions 1 and 7. Legacy DMA2 Address Region 1, 5, and 7 We need a connection to the Memory module for regions 1 and 7, and a connection to the non-coherent I/O B for region 5.
Domain 2: Directory Address Region 0, 4, 6, 8 located at the Memory module. We need a connection between the Directory proxy and the Memory module Directory Address Region 2 and 3 located at I/O A. We need a connection between the Directory proxy and the I/O A module.
Based on the above main port and legacy port connectivity, plus, how caches and intervention ports are used structurally in the example design, the following intervention port connectivity needs to be established in order to deliver system-level cache interventions: Directory CPU1/2, CPU3/4, and Coherent DMA1 We need: an intervention connection between the Directory proxy and CPU1/2; an intervention connection between the Directory proxy and CPU3/4; and an intervention connection between the Directory proxy and Coherent DMA1.
Since no cache-to-cache transfers are allowed, no direct connectivity between coherent OCP masters is needed. In the example design, the underlying OCP coherent interconnect only needs to provide connections as mentioned in this subsection; therefore, a fully connected network is not needed. Also, in contrast to a snoop-bus-based OCP coherent design and a design with cache-to-cache transfer, there is no need to:
OCP-IP Confidential
Copy a main port coherent request and turn it into multiple intervention port requests. Convert an intervention port response into a main port coherent response delivering back to the originating coherent master.
Line Size
n/a 64 bytes 64 bytes 64 bytes 64 bytes
Directory
MSI
64 bytes
8 bytes
Return route for responses corresponding to each main port request can be determined by the interconnect module internally; therefore, no addition main port response signal is needed. Similarly, return route for responses corresponding to each intervention port request can also be determined by the interconnect module internally; thus, the coherent core identifications for the Directory slave may not be neededthis is an implementation choice.
OCP-IP Confidential
Parameter
coh_enable cohcmd_enable cohnc_enable cohwrinv_enable burstsinglereq datahandshake burstlength burstlength_wdth burstprecise burstseq burstseq_incr_enable burstseq_wrap_enable burstseq_xor_enable burstseq_strm_enable byteen mdatabyteen writeresp_enable intport_writedata
Value
1 1 1 1 1 1 1 5 1 1 1 1 1 1 1 1 1 0
Notes
Coherent and legacy commands are issued on Mp0 and 2. Only coherent commands are issued on Mp1. Support SRMD bursts and cache line burst sequences (INCR, WRAP, XOR, and more)
Corresponding Signals
MCohCmd, extended MCmd
Allow partial cache line MByteEn, MDataByteEn transfer for reads and writes Writes have responses Coherent write data words are delivered using the main port
OCP-IP Confidential
Parameter
cohstate_enable reqinfo threads sthreadbusy sthreadbusy_exact sdatathreadbusy sdatathreadbusy_exact mthreadbusy mthreadbusy_exact
Value
1 1 1 1 1 1 1 1 1
Notes
Corresponding Signals
SCohState
Parameter
None mdata datahandshake reqinfo intport_split_tranx
Value
Notes
Required signals
Corresponding Signals
MReqSelf, MCmd, SCohState
0 0 1 1
No write data Use to carry coherent ID on bit 0, 1, and 2 Allow response datahandshake protocol Support SRMD bursts and cache line burst sequences (INCR, WRAP, and XOR) MReqInfo SDataValid
1 1 1 5 1 1 1 1 1
OCP-IP Confidential
Parameter
byteen mdatabyteen writeresp_enable threads sthreadbusy sthreadbusy_exact mthreadbusy mthreadbusy_exact mdatathreadbusy mdatathreadbusy_exact
Value
0 0 1 1 1 1 1 1 1 1
Notes
Read for ownership always return the full cache line Writes have responses Use single-threaded non-blocking protocol
Corresponding Signals
Parameter
coh_enable cohcmd_enable cohnc_enable cohwrinv_enable burstsinglereq datahandshake burstlength burstlength_wdth burstprecise burstseq burstseq_incr_enable burstseq_wrap_enable burstseq_xor_enable burstseq_strm_enable byteen mdatabyteen writeresp_enable intport_writedata
Value
1 1 1 0 1 1 1 5 1 1 1 1 1 1 1 1 1 0
Notes
coherence-aware and legacy commands are issued on Mp3 Support SRMD bursts and burst sequences INCR, WRAP, XOR, and more.
Corresponding Signals
MCohCmd, extended MCmd
Allow partial transfer for MByteEn, MDataByteEn reads and writes Writes have responses Must be 0 since there is no intervention port for this master
OCP-IP Confidential
Parameter
cohstate_enable reqinfo threads sthreadbusy sthreadbusy_exact sdatathreadbusy sdatathreadbusy_exac t mthreadbusy mthreadbusy_exact
Value
0 1 1 1 1 1 1 1 1
Notes
Corresponding Signals
Only issuing coherence- NO SCohState aware commands Use to carry coherent ID MReqInfo on bit 0, 1, and 2 Use single-threaded non-blocking protocol SThreadBusy, SDataThreadBusy, MThreadBusy
OCP-IP Confidential
Table 54
Parameter
coh_enable cohcmd_enable cohnc_enable cohwrinv_enable burstsinglereq datahandshake burstlength burstlength_wdth burstprecise burstseq burstseq_incr_enable burstseq_wrap_enable burstseq_xor_enable burstseq_strm_enable burstseq_unkn_enable byteen mdatabyteen writeresp_enable intport_writedata cohstate_enable
Value
1 1 1 1 1 1 1 5 1 1 1 1 1 1 1 1 1 1 0 1*
Notes
Coherent, coherenceaware, and legacy commands can be issued on Mp6. Support SRMD bursts and cache line burst sequences (INCR, WRAP, XOR, and more)
Corresponding Signals
MCohCmd, extended MCmd
Allow partial cache line MByteEn, MDataByteEn transfer for reads and writes Writes have responses Must be 0 for slaves The master interconnect SCohState side has no coherent caches but it can deliver coh and cohnon-cached requests. Use to carry coherent ID MReqInfo on bit 0, 1, and 2 Use single-threaded non-blocking protocol SThreadBusy, SDataThreadBusy, MThreadBusy
1 1 1 1 1 1 1 1
OCP-IP Confidential
Coherent
None None CC_WB, CC_RDSH CC_RDSH CC_RDSH None CC_UPG CC_WB, CC_RDOW CC_RDOW CC_RDOW CC_I RD RDL WR or WRNP WRC
Read LL Write SC
* A cache miss is encountered and a dirty line is the victimized line. Thus, a CC_WB request is issued for the victimized line first before sending a CC request for the cache miss. A cache miss is encountered and a shared line is the victimized line, i.e., no writebacks are needed.
OCP-IP Confidential
OCP-IP Confidential
Table 56
Coherent
M, S, I MSI_to_I M I
System Intervention
I_RDOW
S, I I_RDSH M
I S
S, I I_UPG M
Same state SResp = OK; SCohState = I* I SResp = DVA, SData; SCohState = M SResp = OK; SCohState = I* SResp = OK; SCohState = I*
S, I I_I I_WR
M, S, I I
* For self intervention responses, the SCohState does not get used by the directory module; therefore, the signal value is a dont care. For these system intervention responses, the SCohState is also a dont care. The SCohState indicates the prior cache state of the targeting cache line. The SCohState indicates the installing (e.g., next) cache state of the targeting cache line.
OCP-IP Confidential
Table 57
Actions (for each transient state, the final cache line state is determined by the transient state alone)
Send SData to Cache and Update Cache State to SCohState*. Unblock blocked fences. Update Cache State to SCohState*. Unblock blocked fences.
Coherent
CC_UPG command
SResp OK, SCohState; or Update Cache State to SResp DVA, SCohState SCohState*. If DVA, also send SData to Cache. Unblock blocked fences. SResp OK, SCohState Update Cache State to SCohState*. Unblock blocked fences.
* The SCohState indicates the installing (e.g., next) cache state of the targeting cache line.
Intended Transaction
Read LL Write SC
Coherence Aware
No hardware cache updates are considered in the example design. However, the DSP master can still have software caches where, for instance, system software is used to move a large amount of data from memory to an internal data buffer (inside the DSP) and from the data buffer to the memory before and after data processing, respectively.
OCP-IP Confidential
When main port responses are received, the DSP masters OCP wrapper only needs to return data words for reads as indicated in Table 59.
Table 59 Upon Receiving Main Port Responses From Coherent Address Space
Intended Transaction
Read Write
OCP-IP Confidential
connecting not only to the interconnect on the top with Mp6/Ip6 but also a legacy port OCP5 in order to send regular OCP requests to the Memory module and the I/O A.
Interconnect
OCP Main Port Connection (with signals going both directions and the coherence extension)
OCP8
OCP6
OCP5
Mp6
Ip6
I/O A
Directory-Based OCP wrapper Legacy OCP Port Connection (with signals going both directions)
Directory
OCP-IP Confidential
Table 61
Received Mp Action Comment Request Sending System Send Legacy Sending Self Intervention on Intervention on Requests to the Memory Module Ip Ip* or I/O A
CC_RDOW ActionX(I_RDOW): ActionY1(I_RDOW): If N == 0: Send self Send system ActionZ1: Send RD I_RDOW request I_RDOW with to memory or I/O with proper Coh Coh Core ID in Core ID in MReMReqInfo for qInfo each outstanding Coh Core ID Wait for N Ip responses Take ActionX(I_RDSH) ActionY2(I_RDSH): If N == 0: Send system Take ActionZ1 I_RDSH with Coh Core ID in MReqInfo for the outstanding Coh Core ID with state == M Will wait for N responses (N can be either 1 or 0) Take ActionY2(I_RDDS) Take ActionY1(I_UPG) Take ActionY1(I_WRI) + Mp data words If N == 0: Take ActionZ1 If N == 0: Take ActionZ1 If N == 0: ActionZ2: Send WR + data words to memory or I/O May not need to wait for the previous self intervention request to be completed before launching May not need to wait for the previous self intervention request to be completed before launching There can be no outstanding Coherent Core IDs for the targeting cache line; thus, N is 0
CC_RDSH
CC_I
Take ActionX(I_I)
Take ActionY1(I_I)
n/a
n/a
Take ActionZ2
n/a
Take ActionZ2
OCP-IP Confidential
Received Mp Action Comment Request Sending System Send Legacy Sending Self Intervention on Intervention on Requests to the Memory Module Ip Ip* or I/O A
WR + data words to coherent address space RD to coherent address space WR + data words to noncoherent address space RD to noncoherent address space n/a Take ActionY1(I_RDOW) If N == 0: Take ActionZ2
n/a
Take ActionY2(I_RDSH)
If N == 0: Take ActionZ1
n/a
n/a
n/a
n/a
* When there are no outstanding self intervention requests. When the corresponding self intervention requests can be sent.
OCP-IP Confidential
Table 62
Original Mp Request
Action After Receiving Ip Responses or Memory/ Any Data Words Going I/O Responses: Send to Memory or I/O Mp Responses
IF Ip SResp == DVA: n/a Send Mp SResp of DVA, Ip response data words, SCohState of M* ELSE: Send Mp SResp of DVA, SData = memory or I/O data words, SCohState of M*
CC_RDOW
CC_RDSH
IF Ip SResp == DVA: Ip response SData Send Mp SResp of DVA, words Ip response data words, SCohState of S* ELSE: Send Mp SResp of DVA, SData = memory or I/O data words, SCohState of S*
IF (Ip SResp == DVA): Set Directory cache line state for the originating Coh Core ID slot to S and replace the old dirty slots state from M to S (for the dirty Coh Core ID)
CC_RDDS
n/a IF Ip SResp == DVA: Send Mp SResp of DVA, Ip response data words, SCohState of I* ELSE: Send Mp SResp of DVA, SData = memory or I/O data words, SCohState of I*
n/a
CC_UPG
IF Ip SResp == DVA: Send Mp SResp of OK, SCohState of M* ELSE: Send Mp SResp of OK, SCohState of M* Send Mp SResp of OK, SCohState I* Send Mp SResp of OK, SCohState I* Send Mp SResp of OK, SCohState I* Send Mp SResp of OK, SCohState S*
n/a
Reset Directory cache line state and set the originating Coh Core ID slot to M
Reset Directory cache line state Reset Directory cache line state IF directory slot was M: Reset Directory cache line state IF directory slot was M: set the originating Coh Core ID slot to S
OCP-IP Confidential
Original Mp Request
Action After Receiving Ip Responses or Memory/ Any Data Words Going I/O Responses: Send to Memory or I/O Mp Responses
Send Mp SResp of OK, SCohState I Mp request MData && Ip response SData words
WR + data words targeting coherent address space RD targeting coherent address space
IF Ip SResp == DVA: Ip response SData Send Mp SResp of DVA, words Ip response data words, SCohState of I ELSE: Send Mp SResp of DVA, SData = memory or I/O data words, SCohState of I Legacy SResp DVA Mp request MData
WR + data words targeting noncoherent address space RD targeting noncoherent address space
n/a
n/a
* The SCohState indicates the installing (i.e., next) cache state of the targeting cache line. For self intervention responses, the SCohState does not get used by the directory module; therefore, the signal value is a dont care. For these system intervention responses, the SCohState is also a dont care.
OCP-IP Confidential
When connectivity is defined, a (virtual) data stream is maintained between a master Mp to a slave Mp, or a slave Ip to a master Ip. No burst interleaving when multiple initiator threads are turned into one target thread at the thread merging points in the interconnect module (we use only single-threaded, non-blocking protocol for all OCP ports in the example design).
In this example design, we do not support cache-to-cache forwarding (i.e., the 3-way communication). However, if it is supported, additional capability needs to be provided by the interconnect. For instance, a virtual data stream between a coherent masters Ip response channel and another coherent masters Mp response channel needs to be established. This also implies that each coherent transaction originated on a main port may get a Data response and a completion response where: (1) both responses may come back in the same time; (2) the Data response may come back first; or (3) the completion response may come back first inside the interconnect. Hence, special attention needs to be taken care of by the interconnect or the coherent master.
OCP-IP Confidential
here. The diagram is not intended to accurately depict the duration of any individual transaction or series of transactions. Conventions used in all space-time diagrams include: Time flows from top to bottom.
CC_WB Transaction High-Level Data Flow
Figure 72
CPU 1/2
M g Req a Resp I
CPU 3/4 L2 $$
DMA 1
L2
OCP wrapper
Resp d Req
Resp
Req
Resp
Req
Mp0
Ip0
Ip1
Ip2
Table
Table
Directory
Req
esp O 1 3 : SR oh K, SC State
Mp6
I
b
Ip6
OCP6
Resp
Req
Req
Resp
OCP wrapper
e
Memory Controller/DRAM
All ports of each OCP entity are shown. Transactions are represented by arrows between ports. Labels indicate the major action(s), including state change(s), that are performed by the transaction.
OCP-IP Confidential
Figure 73
Directory, CohID 4
Ip6 OCP5
Memory
OCP6
Dir State (M at
I_ W
B;
dr; M M ad
In Re q
elf,C fo=S
I D1
OCP-IP Confidential
time
OK; S SResp CohSta te I
SResp
OK; SC
ohState
MSI_I
For instance, Table 73 is used to illustrate the following: For CPU 1/2, after it issues a CC_WB main port request and two datahandshake phases (MData0 and MData1), it will receive a self I_WB intervention request on its intervention port Ip0 and after the CPU responding with an intervention port response (SResp OK and SCohState of I), it will eventually receive a main port SResp to indicate the completion of it CC_WB transaction (and the cache line state goes to I). On the other hand, the Directory module not only sends a self intervention request back to CPU 1/2 (indicated by CID1), it also writes back the cache line (MData0 and MData1) to its home Memory module using its legacy OCP5 port.
Figure 74
CPU 1/2, CohID 1
Mp0
CC_RDSH; Mad
DMA 1 CohID 2
Ip2
Memory
OCP6
Ip0
dr; MReqInfo=
CID1
Dir State (M at
f,CID1
I_to_S
SResp OK; SC ohState I
OCP-IP Confidential
time
Di
rS
ta t e CI (S a D2 t C ) ID
WR; MAddr;
MData0 MData1
1,
SResp DVA
I_to_S
DMA 1 CohID 2
Ip2
Memory
OCP6
Ip0
I_RDOW; MA
I_RDOW, MA ddr,
MReqInfo=Sy s,
CID2
SI_to_M
SResp OK; SC ohState I
time
SResp DVA;
CI at (S ) te D 2 ta C I rS Di 1, D
SI_to_M
13.3.6.4 Cache Upgrade When the Cache Line is Shared by Multiple Masters
Figure 76 displays the space-time data flow for a coherent CC_UPG transaction originating from CPU 1/2 where the cache line is also shared at the CPU 1/2 masters cache, the CPU 3/4 masters cache, and the DMA1 masters cache. Therefore, after the Directory receives the CC_UPG request, it sends three intervention requests, a self intervention request to the CPU 1/2 master, two I_UPG system intervention requests to the CPU 3/4 master and the CPU 5/6 master each.
Figure 76
CPU 1/2, CohID 1
Mp0 Ip0
CC_UPG; MA ddr; MReqInfo= CID1
DMA 1 CohID 2
Ip2
Memory
OCP6
SI_to_M
tate I
I S I
OCP-IP Confidential
time
SR
Di rS ta
te CI (S a D2 t C ) ID
1,
SI_to_M
Figure 77
DMA 1 CohID 2
Ip2
Memory
OCP6
Ip6
I_I, MAddr, MR
MSI_to_I
SResp OK; SC ohState I hState I SResp OK; SCo ohState I SResp OK; SC
OCP-IP Confidential
time
Di rS ta t
( I)
MSI_to_I
Please note that in this figure we have intentionally made the memory module an internal module inside the Directory slave.
The corresponding space-time diagram to the above CC_RDSH and cache answers request transaction is displayed in Figure 79the labels indicated on dashed communication activities match those from Figure 78.
Figure 78 CC_RDSH and Cache Answers Request High-Level Data Flow
Proc0
I S g Req a Resp
Proc1 L2
M S
L2
OCP wrapper
Resp Req
M-hit
Resp e Req
Three-Way Forwarding
Cache Line Data SCohState "S"
f Sel
OCP wrapper
OCP-IP Confidential
Sy s
I_ R DS H
H DS _R CC
D I_R SH
Figure 79
Directory/Memory
Mp Ip
Proc1
Ip
CC_RDSH, MA ddr, Proc0 Dir State: M at Proc0, I_RDSH-self, MAddr Proc1 I_RDSH-sys, Proc1, MAddr, Fw Pr oc0
M I I_S
SResp OK, SC oh State I
Fw
SResp DVA, SData, SCohState S
SResp DVA,
I_S L2
Mem
OCP-IP Confidential
M WR SD Add at r, a
Drop
response of SResp OK and SCohState I; and (b) changes the coherence state of cache-line address X to State to I. This may ripple through caches on the processor side. More activities happen during time t+4, t+5, t+6, and t+7. That is, the directory returns cache line data to B and the CC_UPG coherence request coming from master A has been accepted by the directory. At time t+8, say, master A receives and accepts a self-intervention CC_UPG request on MAddr X for the CC_UPG request master A sent at time t. Master A first blocks its intervention port; then, checks its coherence state module and finds cache-line address X is in State I which is different from the State when master A was issuing the CC_UPG request. However, we do have a transition from State I to M for handling the receiving of a self-intervention CC_UPG request as shown in Table 55 so master A can complete its remaining operations.
This example illustrates the race condition and explains the need for the transition row (including Self Intervention: I_UPG and from state I to state M). Other transitions listed in Table 55 that are used to handle race conditions are the S to SI_to_M transition labelled with Self Intervention: I_RDOW and the I to I transition labelled with Self Intervention: I_I or Self Intervention: I_WB.
OCP-IP Confidential
SResp, SCohState, and possible SData need to be delivered in this phase. Please notice that in the mean time the home slave of the MAddr address can be launching a memory read or write command
OCP-IP Confidential
Figure 80
From / To Coherence Masters Self Ip: Req Mp: Req CC_RDOW Self Ip: Resp Ip: Resps -- one has dirty data
Data
Ip: Reqs
Mp: Resp
Snoop Phase
Ignored
Data
Mp: Req
Ip: Req
Ip: Resp
Ignored
Mp: Resp
DRAM Write
OCP-IP Confidential
Figure 81
Memory Subsystem
MP IP
MP
IP
MAddr
MA I_RDOW-self;
M I SI_to_M L2 L2
time
I
SResp DVA; SCohState M
Ignored/ Dropped
MAd I_RDOW-sys;
dr
RD
r dd MA
SI_ to_ M M
Mem
Ignored/ Dropped
L2
Figure 82
From / To Coherence Masters Self Ip: Req Ip: Reqs Self Ip: Resp Ip: Resps -- none has dirty data Mp: Resp
Snoop Phase
Ignored
Mp: Req
Ip: Req
Mp: Resp
Data
OCP-IP Confidential
Figure 83
Memory Subsystem
MP IP
MP
MAddr
ddr
S I I_to_S L2 L2
SResp OK; SCo hState S SResp OK; SC ohState S
Ignored/ Dropped
MAd I_RDOW-sys;
dr
OCP-IP Confidential
time
RD dd MA r
ta1;
SData1, SData2
Mem
I_t
o_
L2
Figure 84
Ip: Reqs
No Data
Ip: Resps
Mp: Resp
Snoop Phase
Ignored No Data
Data
Mp: Req
Ip: Req
Mp: Resp
Figure 85
Memory Subsystem
MP IP
MP
IP
ddr; MData1 MData2
I I MSI_to_I L2 L2
SResp OK; SC SResp OK; SCo
Ignored/ Dropped
ohState I
I_WB-sys; MA
ddr
WR dd MA
OCP-IP Confidential
time
,M t a1 Da r: M
ta2 Da
Mem
Ignored/ Dropped
SResp DVA; SCohState I
SResp OK; SCohState I
MS I_
to_ I I
L2
Implementations that follow the second approach require more complex mechanisms and careful design than implementations that follow the first approach; hence, in this document, for reasons of brevity, only examples that follow the first approach are shown. An example of the race condition of CC_WB from Proc0 and CC_RDOW from Proc1 at the same memory address are shown in Figures 86(a) and 86(b). Figure 86(a) shows the case in which Proc0 wins arbitration at the coherent request serialize/select logic unit in the OCP coherent interconnect: event (A2) appears prior to event (B2), and event (A3) appears prior to event (B3). In this case, only the order of event (A14) completes before event (B7) starts, event (A10) completes before event (B4), and no other ordering between Proc0 and Proc1 is maintained. The behaviors related to the CC_WB request from Proc0 are shown in Figure 86(a). (A1) Proc0 sends a Cache Coherent Write Back (CC_WB) command with data from its main request port. (A2) The coherent request serialize/select logic unit in the interconnection network selects the CC_WB command from Proc0 and sends this command with its associated MData to the target, Memory 0. (A3) The coherent request serialize/select logic unit sends I_WB as a self intervention request to the intervention request port of the initiator, Proc0. Since CC_WB does not require a check of the cache states of other coherent masters, the OCP coherence interconnect does not send I_WB as a system intervention request to the other coherent masters. (A4) OCP wrapper of Memory0 receives the CC_WB command with MData from its main request port, translates the CC_WB request into an I_WB request, and sends the I_WB request to its intervention request port. (Note: Memory0 will execute the write after it receives the intervention response at (A10).) (A5) OCP wrapper of Memory0 sends I_WB from its intervention request port. The OCP coherence interconnect ignores and drops this request. (A6) Proc0 receives I_WB as a self intervention request from its intervention request port and checks its cache state for the requested address location. Proc0 changes the cache state from M to MS_to_I. (A7) Proc0 sends its cache state, Modified, to its OCP wrapper. (A8) OCP wrapper of Proc0 translates the snoop response Modified into SResp OK, SCohState Modified, and sends it from its intervention response port. (A9) SResp merge logic unit in the OCP coherence interconnect receives the intervention port response (A9), generates the intervention response SResp OK, SCohState Modified for the coherent memory system, and sends it to the intervention port of Memory0. (A10) OCP wrapper of Memory0 receives the intervention response SResp OK, SCohState Modified and executes memory write to Memory0.
OCP-IP Confidential
(A11) OCP wrapper of Memory0 generates the main port response SResp DVA, SCohState Invalid, and sends it to its main response port. (A12) OCP wrapper of Memory0 sends SResp DVA, SCohState Invalid from its main response port. (A13) SResp merge logic unit in the OCP coherence interconnect receives the main port response from Memory0. It sends SResp DVA, SCohState Invalid as the main port response to Proc0. (A14) Proc0 receives SResp DVA, SCohState Invalid as the main port response, and changes its cache state from MS_to_I to I. The CC_WB command transaction ends.
Figure 86(a) CC_WB Race Condition, Proc0
Proc0
Proc1
Cache
A12 A6 A7
Cache
Modified
OCP Wrapper
OCP Wrapper
MP: Req
MP: Resp
IP: Resp
IP: Req
MP: Req
B1
MP: Resp
IP: Resp
IP: Req
A1
A8
A2
oh SR St es at p e OK M od ifi ed
MP: Req
MP: Resp
IP: Resp
SC
Memory0
OCP-IP Confidential
M em or yW
rit e
) elf (s
d Cm
W DO _R Broadcast C
d K ie O dif p o es e M SR tat S oh SC
MC m wit d CC hM _ Da WB ta
A lid DV va sp te In e SR Sta h Co S A1
1
A10 A1 2
A5
IP: Req
A4 A1 0
A9
OCP Wrapper
Coherent Memory Subsystem
The behaviors related to the CC_RDOW request from Proc1 are shown in Figure 86(b). (B1) Proc0 sends the Cache Read Own (CC_RDOW) command from its main request port. (B2) The coherent request serialize/select logic unit in the OCP coherence interconnect network selects the CC_RDOW command from Proc1 and sends this command to the target, Memory 0. Note that at this point, the CC_WB command issued by Proc0 has already been sent to Memory0. (B3) The coherent request serialize/select logic unit sends I_RDOW as a self intervention request to the intervention request port of the initiator, Proc1. It also sends I_RDOW as system intervention requests to all other coherent masters, including Proc0. Note that at this point, I_WB from Proc0 has already sent to Proc0. (B4) OCP wrapper of Memory0 receives the CC_RDOW from its main request port, and sends Memory Read speculatively to Memory0. Memory0 executes the read. (B5) OCP wrapper of Memory0 translates the CC_RDOW request into an I_RDOW request and sends it to its intervention request port. (B6) OCP wrapper of Memory0 sends I_RDOW from its intervention request port. OCP coherence interconnect ignores and drops this request. (B7) Proc0 receives I_RDOW as a system intervention request from its intervention request port and checks its cache state at the requested address location. Since the cache state is I, Proc0 does not change the cache state. (B8) Proc0 sends the cache state Invalid to its OCP wrapper. (B9) OCP wrapper of Proc0 translates the snoop response Invalid into SResp OK, SCohState Invalid, and sends it from its intervention response port. (B10) Proc1 receives I_RDOW as a self intervention request from its intervention request port and checks its cache state at the requested address location. Proc1 changes the cache state from I to SI_to_M. (B11) Proc1 sends the cache state Invalid to its OCP wrapper. (B12) OCP wrapper of Proc1 translates the snoop response Invalid into SResp OK, SCohState Invalid, and sends it from its intervention response port. (B13) SResp merge logic unit in the OCP coherence interconnect receives the intervention port responses (B9) and (B12), generates the intervention response SResp OK, SCohState Invalid for the coherent memory system, and sends it to the intervention port of Memory0. (B14) OCP wrapper of Memory0 receives the intervention response SResp OK, SCohState Invalid and sends it to its main response port.
OCP-IP Confidential
(B15) Main response port of the OCP wrapper of Memory0 waits for the read data. (B16) Memory0 sends the read data to its main response port. (B17) The OCP wrapper of Memory0 sends SResp DVA with SData, SCohState Modified as the main port response. (B18) SResp merge logic unit in OCP coherence interconnect receives the main port response from Memory0. It sends SResp DVA with SData, SCohState Modified as the main port response to the Proc1. (B19) Proc1 receives SResp DVA with SData, SCohState Modified as the main port response. It updates the cache line and changes its cache state from SI_to_M to M. The CC_RDOW transaction ends.
Figure 86(b) CC_RDOW Race Condition, Proc1
Proc0 Proc1
Cache
B7 B8
Cache
I (no state chenge)
Invalid
Invalid
OCP Wrapper
MP: Req MP: Resp IP: Resp IP: Req MP: Req
OCP Wrapper
MP: Resp
SResp DVA w ith S SCohS tate Mo Data dified
IP: Resp
IP: Req
B12
B9
B1
I_ R D O W
(s ys )
C_ dC Cm
OW RD
B2
M C m d
Merge a ta B18 SD B13 ith ified w d VA Mo OK lid p D tate sp Inva e es S SR tate S R Coh hS B6 B17 S Co S
MP: Req
MP: Resp
IP: Resp
IP: Req
B4 B5
B15
B14
OCP Wrapper
(Coherent Memory Subsystem)
Memory Read
B16
Memory0
OCP-IP Confidential
K id p O al es Inv S R ta te S oh SC
Cm M d C C W O D _R
OCP-IP Confidential
(A10) OCP wrapper of the Memory0 receives the response SResp OK, SCohState Invalid from its intervention response port, and it cancels Memory Write to Memory0. (A11) OCP wrapper of Memory0 generates the intervention response SResp OK, SCohState Invalid and sends it to its main response port. (Note a different implementation may generate SResp DVA, SCohState Invalidthe value of SResp is implementation dependent.) (A12) OCP wrapper of Memory0 sends SResp OK, SCohState Invalid from its main response port. Since this is a write transaction, no data is sent from its main response port. (A13) SResp merge logic unit in the OCP coherence interconnect receives the main port response from Memory0. It sends SResp OK, SCohState Invalid as the main port response to Proc0. (A14) Proc0 receives SResp OK, SCohState Invalid as the main port response. Proc0 changes the cache state from MSI_to_I to I. The CC_WB transaction ends.
OCP-IP Confidential
Proc0
A14
Proc1
MSI_to_I -> I I -> MSI_to_I
Cache
A6 A7
Cache
Invalid
OCP Wrapper IP: Req MP : Req MP : Resp IP: Resp IP: Req
MP: Resp
IP: Resp
A8
md MC
B( I_ W
lf Se
A3
C_
WB w
ith
A12
MD ata
K d p O ali e s In v SR t ate hS Co S
A9
SC SRe oh s St a p O te K In v alid
A5
MP : Req
A4
MP : Resp
IP: Resp
A10 A11
Memory0
The behaviors related to the CC_RDOW request from Proc1 are shown in Figure 87(b). (B1) Proc1 sends a Cache Read Own (CC_RDOW) command from its main request port. (B2) The coherent request serialize/select logic unit in the OCP coherence interconnect network selects the CC_RDOW command from Proc1 and sends this command to the target, Memory 0. (B3) The coherent request serialize/select logic unit sends I_RDOW as a self intervention request to the intervention request port of the initiator, Proc1. It also sends I_RDOW as system intervention requests to all other coherent masters, including Proc0.
OCP-IP Confidential
(B4) OCP wrapper of Memory0 receives the CC_RDOW command from its main request port, and sends Memory Read speculatively to Memory0. Memory0 executes the read. (B5) OCP wrapper of the Memory0 translates the CC_RDOW request into an I_RDOW request and sends it to its intervention request port. (B6) OCP wrapper of Memory0 sends I_RDOW from its intervention request port. The OCP coherence interconnect ignores and drops it. (B7) Proc0 receives I_RDOW as a system intervention request from its intervention request port and checks its cache state at the requested address location. Proc0 changes the cache state from M to I. (B8) Proc0 send its cache state Modified to its OCP wrapper with the data of the requested cache line. (B9) OCP wrapper of Proc0 translates the snoop response Modified into SResp DVA with SData, SCohState Modified, and sends it from its intervention response port. (B10) Proc1 receives I_RDOW as a self intervention request from its intervention request port and checks its cache state at the requested address location. Proc1 changes the cache state from I to SI_to_M. (B11) Proc1 sends its cache state Invalid to its OCP wrapper. (B12) OCP wrapper of Proc1 translates the snoop response Invalid into SResp OK, SCohState Invalid, and send it from its intervention response port. (B13) SResp merge logic unit in the OCP coherence interconnect receives the intervention port responses (B9) and (B12), generates the intervention response SResp DVA with SData, SCohState Modified for the coherent memory system, and sends it to the intervention port of Memory0. (Note: If the main port response of Memory0 is ignored, Memory0 does not need the data of CC_RDOW, because CC_RDOW is issued by store miss case and the data will be updated in the initiator.) (B14) SResp merge logic unit in the OCP coherence interconnect generates the intervention response SResp DVA with SData, SCohState Modified for the initiator, Proc1, and sends it to the main port of Proc1. (Note that the OCP interconnect may skip (B14) and instead send the modified data at (B17). This is an implementation-dependent choice.) (B15) Proc1 updates its cache and changes the cache state from SI_to_M to M. (B16) OCP wrapper of Memory0 receives the intervention response SResp DVA with SData, SCohState Modified and sends it to its main response port. (B17) Main response port of the OCP wrapper of Memory0 waits for the read data. (B18) Memory0 sends the read data to its main response port.
OCP-IP Confidential
(B19) The OCP wrapper of Memory0 sends SResp OK, SCohState Modified as the main port response. (Note that this response is implementationdependent: the OCP wrapper of Memory0 may also send SRespDVA with SData, SCohState Modified from its main response port for the OCP coherence interconnect to send to Proc1, instead of (B14).) (B20) SResp merge logic unit in the OCP coherence interconnect receives the main port response from Memory0. It ignores/drops the response. The CC_RDOW transaction ends.
Figure 87(b) CC_RDOW Request from Proc1
Proc0
Proc1
B15
Cache
B7 B8
M -> I
B10 B11
Invalid
MP: Resp
IP: Req
MP: Req
B1
MP: Resp
IP: Resp
a ith SDat DVA w SResp ate Modified SCohSt
IP: Req
I_ R W DO
B12
md MC SC SRe oh s Sta p O te K I nv ali d
MCm d
d Cm M
D _R CC
OW
SR e SC sp oh D V St A at wi e th M od SD ifie ata d
B20
B13 B14
B2
MC md C
B19
B6
MP: Req
B4 B5
MP: Resp
B17
IP: Resp
B16
IP: Req
Memory0
B18
OCP-IP Confidential
1. The requestor waits for self intervention and for response. The home agent is simple: a CC_WB command has no effect on the state of the cache line until the reception of a self intervention. When this happens, the intervention port is blocked until the reception of a response which invalidates the status of the cache line. 2. When the requestor sends a CC_WB command, it commits at once (cache line state transitions to I when generating CC_WB) and does not wait for a self intervention or response.In this case, the coherence master implementation must be more complex than in the first approach. The coherent slave (snoop controller), which will be able to detect the race, drops the memorys response (i.e., it ignores stale data) and re-reads the data from memory (by issuing a second request) once the processor with the up-to-date copy writes back. Since the implementation of the second approach requires complex mechanisms and careful design, this document only shows examples of the first approach. The behaviors of the coherent masters (processors), interconnect, and memory subsystem are based on Tables 5557 and Figures 8085. The behaviors related to Proc0 CC_WB are shown in Figure 88(a). (A1) Proc0 sends a Cache Coherent Write Back (CC_WB) command. Since intport_writedata=1, Proc1 does not send modified data. (A2) The coherent request serialize/select logic unit in the interconnection network selects the CC_WB command from Proc0 and sends this command to the target, Memory 0. (A3) The coherent request serialize/select logic unit in the interconnection network sends I_WB to the intervention request port of Proc0 as a selfintervention. Since I_WB is not required to be sent to other coherent masters as a system intervention, the OCP coherence interconnect network does not send I_WB as system intervention requests. (A4) OCP wrapper of Memory0 translates the CC_WB request into an I_WB request and sends it to its intervention request port. (A5) OCP wrapper of Memory0 sends I_WB from its intervention request port. The OCP coherence interconnect ignores and drops it. (A6) Proc0 receives I_WB as a self intervention request from its intervention request port and checks its cache state at the requested address location. Proc0 changes the cache state from M to MS_to_I. (A7) Proc0 sends its cache state Modified, and also sends the modified data of the requested cache line to its OCP wrapper. (A8) OCP wrapper of Proc0 translates the snoop response Modified into SResp DVA with SData, SCohState Invalid, and sends it from its intervention response port. (Note: this response is implementationdependent: SCohState can also be Modified as shown in Figure 86(a).)
OCP-IP Confidential
(A9) SResp merge logic unit in the OCP coherence interconnect receives the intervention port response (A8), generates the intervention response SResp DVA with SData, SCohState Invalid for Memory0, and sends it to the intervention port of Memory0. (A10) OCP wrapper of the Memory0 receives the response SResp DVA with SData, SCohState Invalid from its intervention response port, and sends Memory Write to Memory0. Memory0 executes the write. (A11) OCP wrapper of Memory0 generates the intervention response SResp DVA, SCohState Invalid and sends it to its main response port. (A12) OCP wrapper of Memory0 sends SResp DVA, SCohState Invalid from its main response port. Since this is a write transaction, no data is sent from its main response port. (A13) SResp merge logic unit in the OCP coherence interconnect receives the main port response from Memory0. It sends SResp DVA, SCohState Invalid as the main port response to Proc0. (A14) Proc0 receives SResp DVA, SCohState Invalid as the main port response, and changes its cache state from MS_to_I to I. The CC_WB transaction ends.
OCP-IP Confidential
Proc0
A14
Proc1
MS_to_I -> I M -> MS_to_I
Cache
A7
A6
Cache
Modified
MP : Resp
IP: Resp
A8
MP : Resp
IP: Resp
IP: Req
a at SD id ith al w Inv VA te D ta p S es oh SR SC
A3 A2
SR e SC sp oh DV St A w at i e th In S va Da lid ta
Memory0
The behaviors related to the CC_RDOW request from Proc1 are shown in the Figure 88(b). (B1) Proc1 sends a Cache Read Own (CC_RDOW) command from its main request port. (B2) The coherent request serialize/select logic unit in the OCP coherence interconnection network selects the CC_RDOW command from Proc1 and sends this command to the target, Memory 0. Note that at this point, the CC_WB command issued by Proc0 has already been sent to Memory0.
OCP-IP Confidential
Me mo ry
Wr i te
W CC_ md MC B
_W
Cm
_ CC
W O RD
MC m wit d CC hM _ Da WB ta
A12
A5
MP: Req
A4
MP : Resp
IP: Resp
A10 A11
(B3) The coherent request serialize/select logic unit sends I_RDOW as a self intervention request to the intervention request port of the initiator, Proc1. It also sends I_RDOW as system intervention requests to all other coherent masters, including Proc0. Note that at this point, I_WB from Proc0 has already been sent to Proc0. (B4) OCP wrapper of the Memory0 receives the CC_RDOW command from its main request port, and sends Memory Read speculatively to Memory0. Memory0 executes the read. (B5) OCP wrapper of the Memory0 translates the CC_RDOW request into an I_RDOW request and sends it to its intervention request port. (B6) OCP wrapper of Memory0 sends I_RDOW from its intervention request port. The OCP coherence interconnect ignores and drops this request. (B7) Proc0 receives I_RDOW as a system intervention request from its intervention request port and checks its cache state at the requested address location. Since the cache state is I, Proc0 does not change the cache state. (B8) Proc0 send its cache state Invalid to its OCP wrapper. (B9) OCP wrapper of Proc0 translates the snoop response Invalid into SResp OK, SCohState Invalid, and sends it from its intervention response port. (B10) Proc1 receives I_RDOW as a self intervention request from its intervention request port and checks its cache state at the requested address location. Proc1 changes the cache state from I to SI_to_M. (B11) Proc1 sends its cache state Invalid to its OCP wrapper. (B12) OCP wrapper of Proc1 translates the snoop response Invalid into SResp OK, SCohState Invalid, and sends it from its intervention response port. (B13) SResp merge logic unit in the OCP coherence interconnect receives the intervention port responses (B9) and (B12), generates the intervention response SResp OK, SCohState Invalid for the coherent memory system, and sends it to the intervention port of Memory0. (B14) OCP wrapper of Memory0 receives the intervention response SResp OK, SCohState Invalid and sends it to its main response port. (B15) Main response port of the OCP wrapper of Memory0 waits for the read data. (B16) Memory0 sends the read data to its main response port. (B17) The OCP wrapper of Memory0 sends SResp DVA with SData, SCohState Modified as the main port response. (B18) SResp merge logic unit in OCP coherence interconnect receives the main port response from Memory0. It sends SResp DVA with SData, SCohState Modified as the main port response to Proc1.
OCP-IP Confidential
(B19) Proc1 receives SResp DVA with SData, SCohState Modified as the main port response. It updates the cache line and changes its cache state from SI_to_M to M. The CC_RDOW transaction ends.
Figure 88(b) CC_RDOW Request, Proc1
Proc0
Proc1
B19
Cache
B7 B8
Cache
B10 B11
Invalid
Invalid
MP: Resp
IP: Resp
B12
IP: Req
D O W (s ys )
m MC
W DO _R CC d
I_ R
B2
MCm
Merge ta Da B13 h S d B18 wit odifie K id VA M p O nval p D tate I es es S SR tate SR Coh hS B6 B17 S Co S
M C
m d
MP: Req
B4
MP : Resp
B15 B5
IP: Resp
B14
IP: Req
OCP Wrapper
(Coherent Memory Subsystem)
Memory0
Memory Read
B16
OCP-IP Confidential
K id p O al es Inv SR tate S oh SC
m C M d C_ C RD W O
(A3) The coherent request serialize/select logic unit in the OCP coherence interconnect network sends I_WB to the intervention request port of Proc0 as a self-intervention. Since I_WB is not required to be sent to other coherent masters as a system intervention, the OCP coherence interconnect network does not send I_WB as system intervention requests. Note that at this point, I_RDOW from Proc1 has already been sent to coherent masters. (A4) OCP wrapper of Memory0 translates the CC_WB request into an I_WB request and sends it to its intervention request port. (A5) OCP wrapper of Memory0 sends I_WB from its intervention request port. The OCP coherence interconnect ignores and drops this request. (A6) Proc0 receives I_WB as a self intervention request from its intervention request port and checks its cache state at the requested address location. Since Proc0 already received I_RDOW as a system intervention from its intervention request port and updated its cache state, the cache state is I. Proc0 changes the cache state from I to MSI_to_I. (A7) Proc0 sends its cache state, Invalid, to its OCP wrapper. (A8) OCP wrapper of Proc0 translates the snoop response Invalid into SResp OK, SCohState Invalid, and sends it from its intervention response port. (A9) SResp merge logic unit in the OCP coherence interconnect receives the intervention port response (A7), generates the intervention response SResp OK, SCohState Invalid for Memory0, and sends it to the intervention port of Memory0. (A10) OCP wrapper of the Memory0 receives the response SResp OK, SCohState Invalid from its intervention response port, and cancels Memory Write to Memory0. (A11) OCP wrapper of Memory0 generates the intervention response SRespOK, SCohState Invalid and sends it to its main response port. (Note that the value of SResp is implementation dependent: a different implementation may generate the response SResp DVA, SCohState Invalid. ) (A12) OCP wrapper of Memory0 sends SResp OK, SCohState Invalid from its main response port. Since this is a write transaction, no data is sent from its main response port. (A13) SResp merge logic unit in OCP coherence interconnect receives the main port response from Memory0. It sends SResp OK, SCohState Invalid as the main port response to Proc0. (A14) Proc0 receives SResp OK, SCohState Invalid as the main port response. Proc0 changes the cache state from MSI_to_I to I. The CC_WB transaction ends.
OCP-IP Confidential
Proc0
A14
Proc1
MSI_to_I -> I I -> MSI_to_I
Cache
A7
A6
Cache
Invalid
OCP Wrapper IP: Req MP: Req MP : Resp IP: Resp IP: Req
MP: Resp
IP: Resp
A8
dI Cm
B _W
(Se
lf)
A3
MC md
A9
SC SR e oh St a s p O te K In v alid
CC _
WB
A12
A5
MP : Req
A4
MP: Resp
IP: Resp
A10 A11
Memory0
The behaviors related to the CC_RDOW request from Proc1 are shown in Figure 89(b). (B1) Proc1 sends the Cache Read Own (CC_RDOW) command from its main request port. (B2) The coherent request serialize/select logic unit in the OCP coherence interconnect network selects the CC_RDOW command from Proc1 and sends this command to the target, Memory 0. (B3) The coherent request serialize/select logic unit sends I_RDOW as a self intervention request to the intervention request port of the initiator, Proc1. It also sends I_RDOW as system intervention requests to all other coherent masters, including Proc0. (B4) OCP wrapper of Memory0 receives the CC_RDOW request from its main request port, and sends Memory Read speculatively to Memory0. Memory0 executes the read.
OCP-IP Confidential
(B5) OCP wrapper of the Memory0 translates the CC_RDOW request into an I_RDOW request and sends it to its intervention request port. (B6) OCP wrapper of Memory0 sends I_RDOW from its intervention request port. The OCP coherence interconnect ignores and drops it. (B7) Proc0 receives I_RDOW as a system intervention request from its intervention request port and checks its cache state at the requested address location. Proc0 changes the cache state from M to I. (B8) Proc0 send its cache state Modified to its OCP wrapper with the data of the requested cache line. (B9) OCP wrapper of Proc0 translates the snoop response Modified into SResp DVA with SData, SCohState Modified, and sends it from its intervention response port. (B10) Proc1 receives I_RDOW as a self intervention request from its intervention request port and checks its cache state of the requested address location. Proc1 changes the cache state from I to SI_to_M. (B11) Proc1 sends its cache state Invalid to its OCP wrapper. (B12) OCP wrapper of Proc1 translates the snoop response Invalid into SResp OK, SCohState Invalid, and sends it from its intervention response port. (B13) SResp merge logic unit in the OCP coherence interconnect receives the intervention port responses (B9) and (B12), generates the intervention response SResp DVA with SData, SCohState Modified for the coherent memory system, and sends it to the intervention port of Memory0. (B14) SResp merge logic unit in the OCP coherence interconnect generates the intervention response SResp DVA with SData, SCohState Modified for the initiator, Proc1, and sends it to the main port of Proc1. (Note that the OCP coherence interconnect can skip (B14), and the modified data can be sent at (B17). This is implementation dependent.) (B15) Proc1 updates its cache and changes the cache state from SI_to_M to M. (B16) OCP wrapper of Memory0 receives the intervention response SResp DVA with SData, SCohState Modified and sends it to its main response port. (B17) Main response port of the OCP wrapper of Memory0 waits for the read data. (B18) Memory0 sends the read data to its main response port. (B19) The OCP wrapper of Memory0 sends SResp OK, SCohState Modified as the main port response. (Note that this is implementation dependent: the OCP wrapper of Memory0 may also send SRespDVA with SData, SCohState Modified from its main response port and have the OCP coherence interconnect send it to Proc1 at this time, instead of at (B14).)
OCP-IP Confidential
(B20) SResp merge logic unit in OCP coherence interconnect receives the main port response from Memory0. It ignores/drops the response. The CC_RDOW transaction ends.
Figure 89(b) CC_RDOW Request, Proc1
Proc0
Proc1
B15
Cache
B7 B8
M -> I
B10 B11
Invalid
MP: Resp
IP: Req
MP: Req
B1
MP : Resp
IP: Resp
a ith SDat DVA w SResp ate Modified SCohSt
IP: Req
I_R md MC W DO
B12
d Cm M
CC
B2
MC md C
SR e SC sp oh DV St A at wi e th M S od D ifie ata d
B20
B13
B14
B19
B6
MP : Req
B4 B5
MP: Resp
B17
IP: Resp
B16
IP: Req
Memory0
B18
OCP-IP Confidential
SC SR e oh S ta sp O te K Inv ali d
D _R
OW
OCP-IP Confidential
14
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 63 represents the inter-operability of two OCP interfaces.
Table 63 Core Interface Compatibility
Level0
Level0 Level1 Level2 X X X
Level1
X V V
Level2
X V V*
X V
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.
OCP-IP Confidential
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.
OCP-IP Confidential
Table 64
Signal
Control, Status ControlBusy, StatusBusy ControlWr, StatusRd Datahandshake Group (excluding MDataThreadID) EnableClk MDataThreadID MRespAccept MThreadBusy MThreadID Request Group (excluding MThreadID) MReset_n, SReset_n Response Group (excluding SThreadID) SCmdAccept SDataAccept SDataThreadBusy SError, SFlag, SInterrupt, MFlag, MError SThreadBusy SThreadID Table 65
Core
Master
From
SThreadBusy SThreadBusy SDataThreadBusy Response Group
To
Request Group Datahandshake Group MRespAccept Response Group SCmdAccept and SDataAccept SCmdAccept and SDataAccept
Slave
OCP-IP Confidential
Table 66
Core
Master
From
Request Group Datahandshake Group Response Group
To
SThreadBusy SDataThreadBusy MRespAccept MThreadBusy SCmdAccept and SDataAccept SCmdAccept and SDataAccept
Slave
OCP-IP Confidential
15
OCP Profiles
A strength of OCP is the ability to configure an interface to match a cores communication requirements. While the large number of configuration options makes it possible to fit OCP into many different applications, it also results in multiple implementation possibilities. This chapter provides profiles that capture the OCP features associated with standard communication functions. The pre-defined profiles help map the requirements of a new core to OCP configuration guidelines. The expected benefits include: Reduced risk of incompatibility when integrating OCP based cores originating from different providers Reduced learning curve in applying OCP for standard purposes Simplified circuitry needed to bridge an OCP based core to another communication interface standard Improved core maintenance Simplified creation of reusable core test benches
Profiles address only the OCP interface, with each profile consisting of OCP interface signals, specific protocol features, and application guidelines. For cores natively equipped with OCP interfaces, profiles minimize the number of interface and protocol options that need to be considered.
OCP-IP Confidential
Two sets of OCP profiles are provided: profiles for new IP cores implementing native OCP interfaces and profiles that are targeted at designers of bridges between OCP and other bus protocols. Since the other bus protocols may have several implementation flavors that require custom OCP parameter sets, the bridging profiles are incomplete. The bridging profiles can be used with OCP serving as either a master or a slave. The native OCP profiles are designed for new IP cores implementing native OCP interfaces. Consensus profiles have been jointly defined by users of OCP and are intended to supersede several of the existing profiles. The consensus profiles define a unified set of OCP interfaces for system houses, IP providers and EDA vendors. Figure 90 depicts a system built out of diverse IP blocks. Many of the blocks can be characterized as peripherals and are often connected with a simple peripheral interconnect employing relaxed requirements for latency and throughput. Connecting the peripheral interconnect to the high-speed interconnect through the use of a bridge component will likely increase system latency. The high-speed interconnect services the processor subsystem including processors, co-processors, DMAs, and memories. For these components high throughput is a requirement, so they frequently use more advanced communication schemes.
Figure 90 Native Profiles
Processor
Graphics accelerator
DMA engine
High-speed interconnect
Peripheral interconnect
DRAM Interrupt controller Timer I/O device
OCP-IP Confidential
Signal*
Clk EnableClk MReset
Enabling Parameter
Required enableclk mreset 0/1 sreset 0/1
Width Parameter
Fixed Fixed Fixed
Usage
Clock input (page 14) Enable interface clock input (page 14) Slave reset input =1 Master reset output is optional (page 27) Master reset input =1 Slave reset output is optional (page 28)
SReset
Fixed
OCP-IP Confidential
Signal*
Enabling Parameter
Width Parameter
Usage
Additional parameters
endian little, big, both, neutral force_aligned = 1 writeresp_enable = 0 or 1
* See Section 15.1.4 on page 332 for additional signals
All endianness options are allowed but the modules are required to state their endianness. Little endian is recommended (page 51) Byte enables are power-of-two in size and aligned to that size (page 60) Controls response to posted write (non-posted writes always provide a response).
Feature Set
The simple slave profile supports only single accesses, so no burst-related signals are used. The accepted commands are IDLE, RD, WR, and WRNP. Posted writes only return a response if writeresp_enable is enabled; nonposted writes always return a response. For non-posted writes the response must issue from the receiving slave. When responses are required for posted writes (writeresp_enable is enabled), any component between the master and the slave (e.g., an interconnect) can provide the response. This process represents a trade-off between the potential speed improvements of posted writes and the more reliable write completion and error tracking of the nonposted writes. The allowed responses for SResp are NULL, DVA, and ERR. If present, the read and write data signals SData and MData must have the same width. To simplify the interface, the force_aligned parameter is set to 1, limiting byte enable patterns on the MByteEn signal to power-of-two in size and aligned to that size. A byte enable pattern of all 0s is legal. This means that the byte enable patterns generated by simple slave profile masters are force-aligned. In addition, slaves using this profile can assume that the incoming byte enable patterns are force-aligned. The size of the MByteEn is 2 bits when data_wdth is 16, 4 bits for a data_wdth of 32, and 8 bits for a data_wdth of 64. The allowed MByteEn values for a data_wdth of 32 are indicated by the shaded rows in Table 68.
Table 68 MByteEn Patterns for data_wdth = 32 in Simple Slave Profile
MByteEn[3]
0 0 0
OCP-IP Confidential
MByteEn[2]
0 0 0
MByteEn1]
0 0 1
MByteEn[0]
0 1 0
MByteEn[3]
0 0 0 0 0 1 1 1 1 1 1 1 1
MByteEn[2]
0 1 1 1 1 0 0 0 0 1 1 1 1
MByteEn1]
1 0 0 1 1 0 0 1 1 0 0 1 1
MByteEn[0]
1 0 1 0 1 0 1 0 1 0 1 0 1
Since resets are usually handled outside of OCP signaling, no module is required to have a reset output, but every module interface needs to have a reset input. In the OCP signal naming scheme, this requirement means that all masters must have SReset enabled and all slaves an MReset input. It is optional for slaves to have an SReset signal and for masters to have an MReset signal. If the cores do not drive the reset signals, they need to be driven by a system-component that generates the reset. The Clk and EnableClk signals are required inputs in both masters and slaves and they are driven by a third entity (neither the masters nor the slaves). Slaves must be able to support the entire feature set defined in this profile. Masters do not need to be able to issue all the commands since only one WR, RD or WRNP is required. If masters only issue read commands (write_enable and writenonpost_enable parameters set to 0), they can omit the MData signal and responses to writes (writeresp_enable has to be 0 in the master parameter list). If a master issues only write commands, the SData signal can be omitted. Using these options does not compromise interoperability with Simple Slave Profile slaves.
Interoperability Issues
A slave that can accept commands on every cycle can permanently tie SCmdAccept high. When configured in this fashion unsupported or otherwise problematic commands are accepted, so all slaves would need to accept all commands. In case of errors, the master can be notified with the SResp signal (ERR).
OCP-IP Confidential
Signal*
Clk EnableClk MReset
Enabling Parameter
Required enableclk mreset 0/1 sreset 0/1
SReset
Fixed
MCmd
mdata byteen
MBurstLength MReqLast
burstlength_wdth Length of the burst, driven by the 6 max master (page 20) Fixed Last request in the burst, driven by the master (page 22)
OCP-IP Confidential
Signal*
SCmdAccept
Enabling Parameter
cmdaccept
Additional parameters
endian little, big, both, neutral force_aligned Modules are required to state their endianness. Little endian is recommended (page 51) Byte enables are power-of-two in size and aligned to that size (page 60) Posted writes expect a response. Can be 0 for a master that only issues read operations or nonposted write.
writeresp_enable
For this profile the burstprecise parameter is zero, so the MBurstPrecise signal is not used in the interface and all bursts are precise.
Feature Set
While the High-Speed Profile shares many features with the Simple Slave Profile, the force aligned requirement is eliminated since the attached modules can afford more complex interface logic. Two additional features are multiple-request multiple-data (MRMD) type bursts and the response accept signal (MRespAccept). MRespAccept grants capability to the master to block the response flow from the slave if it cannot process new responses anymore. Bursts offer higher transfer efficiencies when compared to single transfers by introducing atomicity for multiple associated requests. This atomicity ensures that requests in the same transaction, i.e. with spatial locality, are issued back-to-back. This behavior is crucial when accessing an SDRAM memory to attain high throughputs. Since the length of the burst is transmitted in the beginning (with MBurstLength) and all bursts are precise (MBurstLength value remains constant over the whole burst), further optimizations are possible in the scheduling and arbitration processes. The address sequence of the burst is provided by MBurstSeq. Allowed sequences are:
OCP-IP Confidential
Incrementing (INCR) The address is incremented with the OCP word size for each transfer Wrapping (WRAP) Like incrementing burst but it does not have to start from the first address and the address wraps at the address boundary defined by MBurstLength*OCP word size Streaming (STRM) The address remains constant over the whole burst MBurstSeq and MBurstLength provide the information needed to generate and receive MRMD bursts. Additional information can help simplify interconnect and slave design. OCP offers framing signals that can be used by the master to identify the last request (MReqLast) and by the slave to identify the last response (SRespLast) in the burst. These additional framing signals are also part of this profile. Slaves must support the entire feature set defined in this profile. Masters need not be able to issue all the commands since only one WR, RD or WRNP is required. If masters only issue read commands (write_enable and writenonpost_enable parameters set to 0), they can omit the MData signal and responses to writes (writeresp_enable has to be 0 in the master parameter list). If a master issues only write commands, SData can be omitted. Masters must support at least one of the burst addressing modes.
Interoperability Issues
The force aligned requirement of the simple slave profile and the MRespAccept signal and burst features of the high-speed profile present some interoperability problems between the interfaces. A bridge or some other component linking simple slave and high-speed profile interfaces needs to break transactions with misaligned byte enables (coming from the high-speed profile to the simple slave profile) into transactions with legal byte enable patterns. A similar process needs to be followed for burst accesses coming from a high-speed profile master to a simple slave profile slave. The MRMD nature of high-speed profile bursts means that the bridge can ignore the burst related signals on the request side, but needs to generate an SRespLast. In addition, if Master is High-Speed Profile, the bridge may need to limit the number of outstanding requests on the interface or to buffer Simple Slave Profile slave responses in case the master de-asserts MRespAccept. If Master is Simple Slave Profile, and the slave is High-Speed Profile, the bridge may tie MRespAccept asserted.
MDataLast, MDataRowLast, MDataByteEn, and SRespRowLast. MReqLast is not used in the Advanced High-Speed Profile. In general, all signals with an M prefix are driven by the master while all signals with an S prefix are driven by the slave. Exceptions to this rule are made for the MReset_n and SReset_n signals, which can be driven by other entities, depending on the system.
Table 70 Advanced High-Speed Profile Signals
Name
Clk EnableClk MReset (Slaves only) SReset (Masters only) Request phase signals MAddr MCmd MData MDataValid MByteEn MDataByteEn MBlockHeight MBlockStride MBurstSeq MBurstLength MBurstSingleReq MDataLast MDataRowLast SCmdAccept Response phase signals SData SDataAccept SResp SRespLast SRespRowLast MRespAccept
Width
1 1 1 1
Usage
Clock input to masters and slaves Enable interface clock input to masters and slaves Reset input to slaves Reset input to masters
Address of the transfer (byte address, aligned to the OCP word size) Command of the transfer Write data Write data valid Byte enable Datahandshake phase write byte enables Height of 2D block burst Address offset between 2D block rows The address sequence of the burst Burst length Burst uses single request, multiple data (SRMD) protocol Last write data in burst Last write data in row Slave accepts the transfer and ends the request phase
Read data Slave accepts write data Slave response to transfer Indicates the last response in the burst Last response in row Master accepts the transfer and ends the response phase
OCP-IP Confidential
Feature Set
With the exception of MReqLast, which is not present in this profile, the Advanced High-Speed Profile includes all features already available in the High-Speed Profile and includes a number of additional features, discussed below. Two-dimensional block bursts can be used. This burst sequence allows for efficient transfers of block-based data, such as macro-blocks in a picture or a video stream. The signals used for this feature are: MBlockHeight, MBlockStride, and SRespRowLast. MBurstSeq can also use the BLCK value on top of the already allowed INCR, WRAP, and STRM encodings. The exclusive-OR (XOR) burst sequence is supported. This address sequence is required for optimized accesses to some high-performance memories such as XDR. There are no additional signals for this feature; only the added allowed encoding for MBurstSeq. Exclusive reads (MCmd set to RDEX) are supported. Exclusive reads provide strong synchronization to access shared resources. There are no additional signals for this feature; only the added allowed encoding for MCmd. A data handshake phase is included to optimize flow control on the write transactions. Using this third phase allows the master to decouple the generation of the command from the actual emission of data. The signals used for this feature are MDataValid, SDataAccept, MDataByteEn, and MDataLast.
Single request, multiple data (SRMD) transactions are recommended for high bandwidth data transfers. Each transaction is associated to a single command independent of the number of data phases in the burst so the use rate of the command and address lines can be reduced. It is strongly recommended for a master that supports the Advanced High-Speed Profile to only issue SRMD commands and to tie its MBurstSingleReq signal to 1. For compatibility with the High-Speed Profile, slaves that support the Advanced High-Speed Profile are required to support both SRMD and MRMD transactions. Slave devices can detect the type of transaction in progress based on the MBurstSingleReq signal. MReqLast is not present in the Advanced High-Speed Profile since the usage of SRMD transactions makes it irrelevantMReqLast would always be asserted.
Using RDEX
RDEX is used as a synchronization primitive required for hardware support of semaphores or read/modify/write sequences. These sequences are required when a processor needs to read from a shared resource (registers or memories) and then write to the same location in an atomic manner. Example: Semaphore is used to control a shared memory resource. When a processor needs access to this memory, it first reads from a semaphore register and writes 1 to the same location using a RDEX/WRNP transaction. If the value read was 1, the semaphore was already taken and the processor cannot access the resource. In this case the value in the register is still 1. If the value read was 0, the semaphore was clear, and the processor can now
OCP-IP Confidential
access the memory. After the RDEX/WRNP, the register value is 1 and other processors cannot access the memory. The atomicity of the transaction guarantees that no other processor may access the semaphore between the read and the write in the transaction, and that only one master can have control of the semaphore at any given time. For transaction atomicity to be guaranteed in the system, RDEX must be supported at each arbitration point, starting from the processor and continuing down to the last arbitration point before any system target which can be used as a protected shared resource. For a regular target, e.g., a simple peripheral, RDEX support is not strictly required since the last arbitration point takes care of the atomicity requirement, and RDEX can be translated into a regular RD in this case. For some more complex targets, e.g., an interconnect or a multi-threaded target, RDEX support is mandatory because at least one arbitration point exists after this OCP interface. To correctly support software synchronization primitives, the hardware is required to keep the RDEX/WRNP transaction atomic, i.e., ensure that no other command to the semaphore can be interleaved between the RDEX command and the corresponding write, as specified in the OCP protocol. No further action is required on the hardware sidethe rest of the sharing protocol is handled through software. A master can, in theory, clear the lock set by another master, or write to a shared resource it does not have access rights to. This would be a violation of the overall system software protocol, and would result in incorrect operation, but would not be a violation of the OCP protocol.
OCP-IP Confidential
When connecting a Simple Slave Profile master to a slave that supports the Advanced High-Speed Profile, no glue logic is required for the request group signals. MBurstLength shall be tied to 1 and MBurstSeq to INCR on the slave interface to make sure all transactions are correctly treated as single requests. A write response to a non-posted write burst shall be issued to the master when all responses in the transaction have been received. If at least one response in the burst had an SResp value of ERR, it is expected that an error response is forwarded to the master. For a response to a posted write command, it is acceptable to immediately send a response to the initiator after acceptance of the request or after receiving the first response from the slave and to drop the next responses, with the drawback that an ERR value for SResp in the rest of the transaction would not be detected. This is true for both Simple Slave Profile and High-Speed Profile masters connected to an Advanced High-Speed Profile slave. When connected a High-Speed Profile master to an Advanced High-Speed Profile slave, the MBurstSingleReq slave input shall be tied to 0 so that all transactions are treated as MRMD. All High-Speed Profile burst sequences are also supported by the Advanced High-Speed Profile, so no further logic is required for the request and response phases. The write data phase only exists within the Advanced High-Speed Profile. When translating a burst from an Advanced High-Speed Profile master, the glue logic must make sure it correctly realigns the data from the data handshake phase with the commands passed to the slave. This means that the logic must wait for the current data to be available from the master, i.e., for MDataValid to be asserted, before passing the associated command to the slave so that write data are always part of the request phase. The RDEX transaction from Advanced High-Speed Profile to Simple Slave Profile or High-Speed Profile cannot be treated as an exclusive operationit can only be translated into a regular RD transaction. If an Advanced HighSpeed Profile master connected to a Simple Slave Profile or High-Speed Profile slave wishes to perform an exclusive access to a resource, it shall do so using other means. For instance, specific dedicated resources can be added to the system for inter-processor synchronization purposes. Another possible solution is to design the system logic, in interconnect and/or bridges, to emulate exclusive access behavior.
Parameter List
Table 71 lists the set of parameters used in the Advanced High-Speed Profile that have non-zero values.
OCP-IP Confidential
Table 71
Parameter
burstseq_blck_enable burstseq_incr_enable burstseq_strm_enable
Values
1 1 1
Description
Block burst address sequence (BLCK) enabled Incrementing burst address sequence (INCR) enabled Streaming burst address sequence (STRM) enabled Wrapping burst address sequence (WRAP) enabled Xor burst address sequence (XOR) enabled
burstseq_wrap_enable 1 burstseq_xor_enable endian read_enable readex_enable write_enable writenonpost_enable datahandshake addr addr_wdth blockheight blockheight_wdth blockstride blockstride_wdth burstlength burstlength_wdth burstseq burstsinglereq byteen cmdaccept dataaccept datalast datarowlast data_wdth 1
little, big, Used endianness needs to be stated both, neutral 1 1 1 1 1 1 64 (max.) 1 6 (max) 1 32 (max) 1 6 (max) 1 1 1 1 1 1 1 32, 64, 128 Allowed sizes for data (MData/SData) are 32, 64, and 128 bits Byte enable signal (MByteEn) is enabled Command accept signal (SCmdAccept) is enabled Burst length signal (MBurstLength) is enabled Burst length signal (MBurstLength) maximum size is 6 bits Burst address sequence signal (MBurstSeq) signal enabled Write operations (MCmd=WR) are enabled Non-posted write operations (MCmd=WRNP) are enabled All writes (posted and non-posted) expect a response Address signal (MAddr) is enabled Address signal (MAddr) maximum size is 64 bits Read operations (MCmd=RD) are enabled
OCP-IP Confidential
Parameter
enableclk mdata mdatabyteen resp respaccept resplast resprowlast sdata mreset
Values
1 1 1 1 1 1 1 1 0/1
Description
Enable clock signal (EnableClk) is enabled Write data signal (MData) is enabled
Response signal (SResp) is enabled Response accept signal (MRespAccept) is enabled Last response indicator signal (SRespLast) enabled
Read data signal (SData) is enabled Controls MReset signal: Slaves should have a reset input (1), reset output for masters is optional (0) Controls SReset signal: Masters should have a reset input (1), reset output for slaves is optional (0)
sreset
1/0
OCP-IP Confidential
MTagInOrder, STagInOrder, MConnID, MThreadBusy, SDataThreadBusy, and SThreadBusy are also optional signals in the high-speed and advanced high-speed profiles. For systems that use OCP threads and allow interleaving within request phases and data handshake phases, the use of threadbusy signals is recommended.
15.1.5 Security
Layered profiles extend the OCP interface as an add-on to any other profile, when additional features are required. The Security profile serves as an example of this concept. To protect against software and some selective hardware attacks use the OCP interface to create a secure domain across the SOC. The domain might include CPU, memory, I/O etc. that need to be secured using a collection of hardware and software features such as secured interrupts, and memory, or special instructions to access the secure mode of the processor. The master drives the security level of the request using MReqInfo as a subnet. The master provides initiator identification using MConnID.
Figure 91 Security Signal Processing
Master
SResp, existing response phase signals
Slave
Interface Configuration
Table 72 lists the OCP configuration parameters that need to be set along with the recommended values. For default values refer to Table 29, Configuration Parameter Defaults, on page 68.
OCP-IP Confidential
Table 72
Security Parameters
Parameter
reqinfo reqinfo_wdth connid connid_wdth
Value
1 Varies 1 Varies
Notes
MReqInfo is required Minimum width is 1 To differentiate initiators, if required Minimum width is 1
Implementation Notes
When implementing this profile, consider the following suggestions: Define the security request as a named subnet MSecure within MReqInfo, for example: subnet MReqInfo M:N MSecure, where M is >= N. With the exception of bit 0, other bits are optional and the encoding is user-defined. Bit 0 of the MSecure field is required and must use the specified value. The suggested encoding for the MSecure bits is: Bit
0 1 2 3 4 5
Value 0
non-secure user mode data request user mode non-host functional
Value 1
secure privileged mode instruction request supervisor mode host debug
A special error response is not specified. A security error can be signaled with response code ERR.
Each profile addresses distinct OCP interfaces, though most systems constructed using OCP will have a mix of functional elements. As different cores and subsystems have diverse communication characteristics and constraints, various profiles will prove useful at different interfaces within the system.
OCP-IP Confidential
Core Characteristics
Cores with the following characteristics would benefit from using this profile: Communication of an undefined amount of data elements to consecutive addresses Imprecise burst model Aligned command/write data flows, decoupled read data flow 32 bit address Natural data width Optional use of byte enables Single thread Support for producer/consumer synchronization
Sequential Undefined Length Data Flow Signals Processing
Figure 92
MData, (MDataByteEn)
Master
SData, SResp MRespAccept
MCmd = { Idle | W rite | W rite NonPost | Read}
Slave
Interface Configuration
Table 73 lists the OCP configuration parameters that need to be set along with the recommended values. For default values refer to Table 29, Configuration Parameter Defaults, on page 68.
OCP-IP Confidential
Table 73
Parameter
addr_width burstlength burstlength_width burstseq byteen data_width read_enable respaccept write_enable writenonpost_enable writeresp_enable
Value
32 1 2 1 1 (optional) core specific 1 (optional) 1 1 (optional) 1 1
Notes
For interfaces that are capable of partial access Choose a data width that is natural to the operation of the core For read capable interface only
Implementation Notes
When implementing this profile, consider the following suggestions: The core streams data to and from a memory-based buffer at sequential addresses. When hitting the boundaries of that buffer a non-sequential address is occasionally given. MBurstLength equals 2 while the data stream proceeds to sequential addresses; MBurstLength equals 1 to indicate that a non-sequential address follows, or that the stream terminates. Start read transactions as early as possible to hide read latency behind ongoing transactions. To implement a producer/consumer synchronization scheme (typically the case when data written by the IP core to shared memory is read by another core in the system), the IP core should issue a synchronization request (for instance through an OCP flag interface) only after receiving a response that the last write transaction has committed. To accomplish this step, perform all write transactions up to the last one as posted writes. Make the final write transaction a non-posted write. This will lead to reception of a response once the non-posted write transaction has committed, i.e., completed at the final destination. Error response should lead to an interrupt.
OCP-IP Confidential
Core Characteristics
Cores with the following characteristics would benefit from using this profile: Address mapped communication, but target decoding is handled upstream Natural data width (unconstrained, but 32 bits is most common) Natural address width (based on the number of internal registers X data width) No bursting Precise write responses indicate completion of write side-effects Single threaded Optional aligned byte enables for sub-word CPU access Optional response flow control Optional use of side-band signals for interrupt, error, and DMA ready signaling
Register Access Signals Processing
Figure 93
Interface Configuration
Table 74 lists the OCP configuration parameters that need to be set along with the recommended values. For default values refer to Table 29, Configuration Parameter Defaults, on page 68.
Table 74 Register Access Parameter Settings
Parameter
addr addr_wdth byteen cmdaccept data_wdth force_aligned interrupt mdatainfo mreset respaccept serror sreset writenonpost_enable writeresp_enable
Value
1 Varies Varies 1 Varies 1 Varies 0 Varies 1 Varies Varies Varies 1
Notes
8, 16, 32 and 64 bits; 32 is preferred Normally read/written by aligned CPU For cores with multiple interrupt lines use SFlag
Include when possible! If core has internally-generated errors If core receives own (non-interface) reset Not usually needed Precise write responses needed for posted writes.
Implementation Notes
When implementing this profile, consider the following suggestions: Choose a data width based on the internal register width of the core. Choose an address width based on the data width and number of registers. Design new cores so that all read/write side-effects can be managed without using byte enables. Design new cores so that registers are at least 32 bit aligned. Use force aligned byte enables for cores with side effects in multiple-use registers. Implement response flow control if convenient. Implement sideband signaling towards CPU (interrupts, sideband errors, etc.) on this interface, since it is largely controlled by the CPU.
OCP-IP Confidential
Select reset options based on the expected use of the core in a larger system. Use regular Write commands for precise completion, unless the core is capable of per-transfer posting decisions, where mixing Write and WriteNonPost helps.
Core Characteristics
Cores with the following characteristics would benefit from using this profile: Block-based communication (includes a single data element block) A single request/multiple data burst model using incremental or a stream burst sequence De-coupled, pipelined command and data flows 32 bit address Natural data width and block size Use of byte enables Single threaded Support for producer/consumer synchronization through non-posted writes
OCP-IP Confidential
Figure 94
Master
SDataAccept
Slave
Interface Configuration
Table 75 lists the OCP configuration parameters that need to be set along with the recommended values. For default values refer to Table 29, Configuration Parameter Defaults, on page 68.
Table 75 Block Data Flow Parameter Settings
Parameter
addr_width burstlength burstlength_width burstseq
Value
32 1 Core specific 1
Notes
Choose a burst length that is natural to the operation of the core If the core is STRM burst capable If the core is STRM burst capable
burstseq_strm_enable 1 burstsinglereq byteen data_width dataaccept datahandshake mdatabyteenable read_enable respaccept 1 1 Core specific 1 1 1 1 1
For interfaces that are capable of partial access Choose a data width that is natural to the operation of the core
OCP-IP Confidential
Parameter
write_enable writenonpost_enable writeresp_enable
Value
1 1 1
Notes
For write capable interface only See note on synchronization below Needed for posted writes
Implementation Notes
When implementing this profile, consider the following suggestions: Start read transactions as early as possible to minimize read latency behind ongoing transactions. To implement a synchronization scheme (typically the case when data written by the IP core to shared memory is read by another core in the system), the IP core should issue a synchronization request (for instance through an OCP flag interface) only after receiving a response that the last write transaction has committed. To accomplish this step, perform all write transactions up to the last one as posted writes. Make the final write transaction a non-posted write. This will lead to reception of a response once the non-posted write transaction has committed, i.e., completed at the final destination. Error responses should lead to an interrupt.
Core Characteristics
Cores with the following characteristics would benefit from using this profile:
OCP-IP Confidential
Byte enable Natural data width Constrained burst size Single thread Caching and similar extensions mapped to MReqInfo or corresponding OCP commands
Simple H-Bus Signal Processing
Figure 95
Master
Slave
Interface Configuration
Table 76 lists the OCP configuration parameters that need to be set along with the recommended values. For default values refer to Table 29, Configuration Parameter Defaults, on page 68.
Table 76 Simple H-Bus Parameter Settings
Parameter
addr_wdth burstlength burstlength_wdth burstprecise burstseq burstseq_wrap_enable byteen data_wdth force_aligned mreset
Value
Varies 1 5 0 1 1 1 Varies 1 1
Notes
Use native address width
Only short burst supported MBurstPrecise signal is not part of the interface. All bursts are precise Subset of burst codes common with OCP and CPU
Parameter
readex_enable reqinfo reqinfo_wdth reqlast respaccept sreset writeresp_enable
Value
1 1 Varies 1 1 1 1
Notes
For CPUs with locked access
Implementation Notes
When implementing this profile, consider the following suggestions: If the CPUs burst parameters such as data alignment are not supported in OCP, such bursts are broken into single transactions. All requests have a response. If the CPU address and write data are pipelined, the OCP bridge will align them. CPU specific information is mapped to the MReqInfo field, however, since this field is often used for proprietary bits by OCP users, a bit-to-bit mapping is not provided. For this field concatenate bit fields starting from bit 0. If the in-band field contains control information that has equivalent native OCP functionality, map the information to the corresponding OCP request. For example, a bit that can be buffered can be mapped to OCP posted or non-posted write types.
Core Characteristics
Cores with the following characteristics would benefit from using this profile: Packet type communication Natural address width Separate command/write data handshake Byte enable Natural data width Multi-thread (blocking)
OCP-IP Confidential
Figure 96
MData, MDataByteEn
Master
MDataValid
SDataAccept
Slave
SResp MRespAccept
MCmd = { Idle | Write | WriteNonPost}
Interface Configuration
Table 77 lists the OCP configuration parameters that need to be set along with the recommended values. For default values refer to Table 29, Configuration Parameter Defaults, on page 68.
Table 77 X-bus Packet Write Parameter Settings
Parameter
addr_wdth burstlength burstlength_wdth burstprecise burstseq burstseq_strm_enable burstseq_wrap_enable byteen data_wdth dataaccept datahandshake
OCP-IP Confidential
Value
Varies 1 5 0 1 1 1 0 Varies 1 1
Notes
Use native address width
Only short burst support MBurstPrecise signal is not part of the interface. All bursts are precise Subset of burst codes common with OCP and CPU
Parameter
datalast interrupt mdatabyteen mreset read_enable reqdata_together reqinfo reqinfo_wdth reqlast respaccept resplast sdata sreset sthreadbusy threads writenonpost_enable writeresp_enable
Value
1 0 1 1 0 Varies 1 Varies 1 1 1 0 1 0 Varies 1 1
Notes
Can be created of burst size Interrupts are not part of this interface
Write only A simpler bridge can often be made if 1, some performance loss possible
Map CPU-specific in-band info here Superfluous for single request, datalast suffices
Implementation Notes
When implementing this profile, consider the following suggestions: Data ordering among read and write port transactions is the responsibility of the CPU. The bridge must consider the read and write ports as single master with regard to exclusive access. Only precise bursts are supported. If CPU burst parameters do not map to OCP, break the burst into single accesses. CPU specific information is mapped as in the H-bus profile.
Core Characteristics
Cores with the following characteristics would benefit from using this profile: Packet type communication
OCP-IP Confidential
Figure 97
Natural address width Single-request multiple-data read Byte enable Natural data width Multi-thread (blocking) Caching and similar extensions mapped to MReqInfo Write support for ReadEx/Write synchronization
MCmd, MAddr, MBurstLength, MReqInfo, MThreadID, MBurstSeq SCmdAccept MData, MDataValid, MDataThreadID SDataAccept
Master
SResp, SData, SRespLast, SThreadID MRespAccept
MCmd = { Idle | Read | ReadEx | Write}
Slave
Interface Configuration
Table 78 lists the OCP configuration parameters that need to be set along with the recommended values. For default values refer to Table 29, Configuration Parameter Defaults, on page 68.
Table 78 X-bus Packet Read Parameter Settings
Parameter
addr_wdth burstlength burstlength_wdth burstprecise
Value
Varies 1 5 0
Notes
Use native address width
Only short burst support MBurstPrecise signal is not part of the interface. All bursts are precise
OCP-IP Confidential
Parameter
burstseq burstseq_strm_enable burstseq_wrap_enable burstsinglereq byteen data_wdth force_aligned
Value
1 1 1 1 1 Varies 0
Notes
Subset of burst codes common with OCP and CPU
8, 16, 32 and 64 bits If CPU alignment is not supported in OCP, such bursts are broken into single transactions. Interrupts are not part of this interface
interrupt mreset readex_enable reqinfo reqinfo_wdth respaccept resplast sreset sthreadbusy threads write_enable
0 1 1 1 Varies 1 1 1 0 Varies 1
Implementation Notes
When implementing this profile, consider the following suggestions: Data integrity among read and write port transactions is the responsibility of the CPU. The bridge must consider the read and write ports as single master with regard to exclusive access. Both transfers in the ReadEx/ Write pair should be issued on the X-bus packet read interface. Only precise bursts are supported. If the CPU burst parameters do not map to OCP, break the burst into single accesses. CPU specific information is mapped as in the H-bus profile.
OCP-IP Confidential
OCP-IP Confidential
16
Core Performance
To make it easier for the system integrator to choose cores and architect the system, an IP core provider should document a cores performance characteristics. This chapter supplies a template for a core performance report on page 354, and directions on how to fill out the template.
OCP-IP Confidential
7. Special reset requirements. If the core needs MReset_n/SReset_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.
g. Use of side-band signals. For each sideband signal (such as SInterrupt, MFlag) explain the use of the signal. h. If the OCP interface has any implementation restrictions, they need to be clearly documented.
OCP-IP Confidential
d. Burst support and effect on latency and throughput numbers. If the core has burst support, state how it makes use of bursts, and how the use of bursts affects the latency and throughput numbers stated above. 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. If multiple threads are present, 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 every non-OCP interface, you will need to provide all of the same information as for OCP interfaces wherever it is applicable.
OCP-IP Confidential
OCP-IP Confidential
For slave OCP interfaces: a. 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. No overlap of operations therefore reciprocal of latency.
i.
Throughput of operations (per OCP cycle for sequences of reads, writes, and interleaved reads/ writes) Maximum number of operations outstanding (pipelining support)
j.
No pipelining support.
k. Effect of burst support on latency and throughput numbers l. High level flow-control
No burst support.
No high-level flow-control support. No thread support. No connection information support. 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.
m. Use of threads (if any) n. Use of connection information o. Use of side-band signals
p. Implementation restrictions For every non-OCP interface Provide all of the same information as for OCP interfaces wherever it is applicable. Hitachi flash card HN29WT800 Only 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
OCP-IP Confidential
OCP-IP Confidential
For slave OCP interfaces: a. Unloaded latency for each operation (in OCP cycles) i. Throughput of operations (per OCP cycle for sequences of reads, writes, and interleaved reads/ writes) Maximum number of operations outstanding (pipelining support)
j.
k. Effect of burst support on latency and throughput numbers l. High level flow-control
m. Use of threads (if any) n. Use of connection information o. Use of side-band signals p. Implementation restrictions For every non-OCP interface Provide all of the same information as for OCP interfaces wherever it is applicable.
OCP-IP Confidential
17
Compliance
This section contains the OCP compliance checks that can help you create checking solutions in the language and tool of your choice. The guidelines listed in this section are based on the Specification and Guidelines parts of this document and allow you to verify an IP/Verification IP (VIP) for OCP compliance. In all cases, Part I, Specification is the definitive reference. Any references made to Part II, Guidelines are not definitive as Part I supersedes the guidelines. For a core to be considered OCP compliant it must satisfy the compliance definition as described in Section 1.2 on page 3.
Configurable IP/VIP supporting multiple OCP configurations must support the setup of any configuration using a <core>_rtl.conf file. The mechanisms used to fix the configuration must provide a method for generating a core_rtl.conf file that represents the fixed configuration and can be used to configure the IP/VIP directly. For IP providers <core>_rtl.conf generation likely occurs during the IP generation step. When the IP code is generated based on configuration, and other settings in the GUI, the <core>_rtl.conf file is generated along with the IP. Closed System Context In a closed system, the verification of an IP/VIP with one or more OCP interfaces may be driven from a <core>_rtl.conf file. A vendor is free to implement any other solution. For example, a VERA verification environment could use a VERA object to control the OCP stimuli generators instead of a <core>_rtl.conf file. If the IP/VIP is being developed in a closed system for delivery in an open system context, then the verification must include the <core>_rtl.conf files and any applicable <core>_rtl.conf generators that are delivered with the IP/VIP.
OCP-IP Confidential
Compliance 361
Check the compliance of the DUT OCP interfaces using static or dynamic verification techniques described in the next section
Figure 98 OCP Configurability
Configuration parameter defaults Table 22, OCP 2.0 Specification Table 25, OCP 2.2 Specification
Signal default tie - off values Relevant checks subset Table 12, OCP 2.0 Specification Table 13, OCP 2.2 Specification
Dynamic verification
Static verification
OCP-IP Confidential
Using a protocol checker on the VIP monitor traces of OCP interface activity to make sure that the protocol is not violated. Assessing the quality of the stimuli using functional and code coverage.
The OCP configuration parameters determine which protocol checks must be active and how the OCP functional coverage is defined.
Stimuli
Because of the degree of difficulty of defining a golden set of stimuli for any OCP interface configuration, you will need to implement a smart and efficient set of stimuli. This may be accomplished using constraint-driven random stimuli generation. The quality of the stimuli must be assessed using both functional and code coverage as described below.
Protocol Checks
The protocol checker is a passive component that monitors a specific set of OCP configuration parameters to determine whether the OCP protocol is violated. The protocol checker can be written in a variety of languages including HDL, PSL, SVA, E, NSCa, or VERA. The protocol checker must be instantiated on each OCP interface of the DUT. To allow this document to be easily referenced, the names of the protocol checks must match the names given to the compliance checks described in this document.
Functional Coverage
Measure the quality of the applied stimuli. The target is 100% functional coverage. Run code coverage on the RTL to determine whether there are any verification holes such as uncovered FSM states or missed branches. Based on the code coverage analysis, additional coverage metrics may be required. The guidelines for OCP functional coverage are provided in Chapter 20. Any additional coverage metrics, based on code-coverage analysis, are design dependent and are out of the scope of this document.
This approach uses a formal tool to prove that, given the stimulus limits defined by the OCP protocol constraints, the OCP interface of the DUT never violates OCP protocol assertions. The formal proof may be exhaustive (the assertions are never violated) or bounded (up to a certain depth of the state
OCP-IP Confidential
Compliance 363
space the assertions are never violated). Stimuli are not needed; instead the tool relies on the 'all acceptable stimuli' definitions provided by the OCP protocol constraints. The OCP configuration parameters determine: Which protocol assertions must be active. How the functional coverage must be defined. Which protocol constraints must be active.
Protocol Assertions
Formal verification revolves around taking the protocol assertions and attempting to prove that they are never violated. If a violation is found, the formal tool provides a test sequence that illustrates the violation on the design. The assertions can be written in different languages such as HDL, PSL or SVA. To allow this document to be easily referenced, the names of the assertions must match the names given to the compliance checks described in this document.
Protocol Constraints
To place bounds on the stimuli that a formal engine must consider, the design must be connected to protocol constraints or some form of generator description. Constraints can be specified using the same language as is used for protocol assertions, typically in HDL, PSL, SVA, or OVA. Protocol constraints are not provided and must be obtained or created for use with formal tools. Constraints must be specific enough to prevent invalid test sequences that can lead to false negative test results (as indicated by protocol assertion failures) but not so specific that they prevent valid test sequences. The latter situation can lead to false positive test results implied by protocol assertion success over an incomplete set of test sequences. Using functional coverage, false positive results can be checked, however, the false negatives cannot be checked as easily.
Functional Coverage
You must insure that all of the protocol assertions are verified to a reasonable extent, and that the protocol constraints are sound. To accomplish this, some functional coverage must be added as a function of the OCP configuration parameters. The functional coverage definition should cover: Which assertions warrant exhaustive proofs Which assertions are ok with just bounded proofs, at what depth Detect and correct an over-constrained environment
The guidelines for the OCP functional coverage are described in Chapter 20.
OCP-IP Confidential
OCP-IP Confidential
Table 79
Name
1.1.1 signal_valid_<signal>_when_reset_inactive MCmd MDataValid MThreadBusy SDataThreadBusy SResp SThreadBusy 1.1.2 request_valid_<signal> MAddr MAddrSpace MAtomicLength MBlockHeight MBlockStride MBurstLength MBurstPrecise MBurstSeq MBurstSingleReq MByteEn MConnID MReqLast MThreadID SCmdAccept 1.1.3 datahs_valid_<signal> MDataByteEn MDataLast MDataThreadID SDataAccept 1.1.4 response_valid_<signal> MRespAccept SRespLast SThreadID 1.1.5 request_valid_MTagInOrder 1.1.6 response_valid_STagInOrder 1.1.7 request_valid_MTagID_when_MTagInOrder_zero 1.1.8 datahs_valid_MDataTagID_when_MTagInOrder_zero 1.1.9 response_valid_STagID_when_STagInOrder_zero
Activation Parameters
datahandshake mthreadbusy sdatathreadbusy resp sthreadbusy addr addrspace atomiclength blockheight blockstride burstlength burstprecise burstseq burstsinglereq byteen connid reqlast threads > 1 cmdaccept mdatabyteen datalast datahandshake & threads > 1 dataaccept respaccept resplast resp & threads > 1 Taginorder resp & taginorder tags > 1 datahandshake & tags > 1 resp & tags > 1
OCP-IP Confidential
Table 80
Name
1.2.1 request_exact_SThreadBusy 1.2.2 request_pipelined_SThreadBusy 1.2.3 request_hold_<signal> MAddr MAddrSpace MAtomicLength MBlockHeight MBlockStride MBurstLength MBurstPrecise MBurstSeq MBurstSingleReq MByteEn MCmd MConnID MData MDataInfo MReqInfo MReqLast MThreadID 1.2.4 request_value_MCmd_<command> BCST RDL WRC RD RDEX WR WRNP 1.2.5 request_value_<signal>_word_aligned MAddr MBlockStride 1.2.6 request_value_<signal>_0x0 MAtomicLength MBurstLength MBlockHeight 1.2.7 request_value_MBurstSeq_<sequence> BLCK DLFT1 DLFT2 INCR STRM UNKN WRAP XOR 1.2.8 request_value_MByteEn_force_aligned 1.2.9 request_value_MThreadID
OCP-IP Confidential
Activation Parameters
sthreadbusy & sthreadbusy_exact & ~sthreadbusy_pipelined sthreadbusy & sthreadbusy_exact & sthreadbusy_pipelined cmdaccept & addr cmdaccept & addrspace cmdaccept & atomiclength cmdaccept & blockheight cmdaccept & blockstride cmdaccept & burstlength cmdaccept & burstprecise cmdaccept & burstseq cmdaccept & burstsinglereq cmdaccept & byteen cmdaccept cmdaccept & connid cmdaccept & mdata & !datahandshake cmdaccept & mdatainfo & !datahandshake cmdaccept & reqinfo cmdaccept & reqlast cmdaccept & threads > 1 !broadcast_enable !rdlwrc_enable !rdlwrc_enable !read_enable !readex_enable !write_enable !writenonpost_enable addr blockstride atomiclength burstlength blockheight blockstride burstlength & !burstseq_blck_enable burstlength & !burstseq_dflt1_enable burstlength & !burstseq_dflt2_enable burstlength & !burstseq_incr_enable burstlength & !burstseq_strm_enable burstlength & !burstseq_unkn_enable burstlength & !burstseq_wrap_enable burstlength & !burstseq_xor_enable byteen & force_aligned threads > 1
Name
1.2.10 datahs_exact_SDataThreadBusy
Activation Parameters
datahandshake & sdatathreadbusy & sdatathreadbusy_exact & ~sdatathreadbusy_pipelined datahandshake & sdatathreadbusy & sdatathreadbusy_exact & sdatathreadbusy_pipelined dataaccept & mdata & datahandshake mdatabyteen & dataaccept & datahandshake dataaccept & mdatainfo & datahandshake datahandshake & threads > 1 & dataaccept dataaccept & datahandshake datalast & dataaccept & datahandshake Mdatabyteen & datahandshake & force_aligned datahandshake & threads > 1 resp & mthreadbusy & mthreadbusy_exact & ~mthreadbusy_pipelined resp & mthreadbusy & mthreadbusy_exact & mthreadbusy_pipelined respaccept & sdata & resp & (read_enable | readex_enable | rdlwrc_enable) respaccept & sdatainfo respaccept & resp respaccept & resp & respinfo respaccept & resp & resplast respaccept & resp & threads > 1 resp & rdlwrc_enable resp & threads > 1 cmdaccept & taginorder & tags > 1 resp & respaccept & taginorder & tags > 1 cmdaccept & tags > 1 datahandshake & dataaccept & tags > 1 resp & respaccept & tags > 1
1.2.11 datahs_pipelined_SDataThreadBusy
1.2.12 datahs_hold_<signal> MData MDataByteEn MDataInfo MDataThreadID MDataValid MDataLast 1.2.13 datahs_value_MDataByteEn_force_aligned 1.2.14 datahs_value_MDataThreadID 1.2.15 response_exact_MThreadBusy
1.2.16 response_pipelined_MThreadBusy
SDataInfo SResp SRespInfo SRespLast SThreadID 1.2.18 response_value_SResp_FAIL_without_WRC 1.2.19 response_value_SThreadID 1.2.20 request_hold_MTagInOrder 1.2.21 response_hold_STagInOrder 1.2.22 request_hold_MTagID_when_MTagInOrder_zero 1.2.23 datahs_hold_MDataTagID_when_MTagInOrder_zero 1.2.24 response_hold_STagID_when_STagInOrder_zero
1.2.25 request_value_MTagID_when_MTagInOrder_zero tags > 1 1.2.26 datahs_value_MTagID_when_MTagInOrder_zero datahandshake & tags > 1
OCP-IP Confidential
Name
Activation Parameters
1.2.27 response_value_STagID_when_STagInOrder_zero resp & tags > 1 1.2.28 datahs_order_MDataTagID_when_MTagInOrder_zero 1.2.29 response_reorder_STagID_tag_interleave_size burstlength & datahandshake & tags > 1 burstsinglereq & resp & tags > 1
1.2.30 response_reorder_STagID_overlapping_addresses resp & tags > 1 & (addr | addrspace | byteen)
Table 81
Name
1.3.1 burst_hold_MBurstLength_precise 1.3.2 burst_hold_<signal> MAddrSpace MAtomicLength MBurstPrecise MBurstSeq MBurstSingleReq MCmd MConnID MReqInfo SRespInfo 1.3.3 burst_hold_<signal>_BLCK MBlockHeight MBlockStride 1.3.4 burst_hold_<signal>_STRM MByteEn MDataByteEn
Activation Parameters
burstlength burstlength & addrspace burstlength & atomiclength burstlength & burstprecise burstseq & burstlength burstlength & burstsinglereq burstlength burstlength & connid burstlength & reqinfo burstlength & respinfo burstlength & burstseq_blck_enable & burstseq & blockheight burstlength & burstseq_blck_enable & burstseq & blockstride burstlength & burstseq_strm_enable & byteen & burstseq burstlength & burstseq_strm_enable & datahandshake & mdatabyteen & burstseq reqdata_together & datahandshake burstlength & addr & burstseq_blck_enable & burstseq burstlength & addr & burstseq_incr_enable & burstseq burstlength & addr & burstseq_strm_enable & burstseq burstlength & burstseq_wrap_enable & addr & burstseq burstlength & burstseq_xor_enable & addr & burstseq
1.3.5 burst_phase_order_reqdata_together 1.3.6 burst_sequence_MAddr_BLCK 1.3.7 burst_sequence_MAddr_INCR 1.3.8 burst_sequence_MAddr_STRM 1.3.9 burst_sequence_MAddr_WRAP 1.3.10 burst_sequence_MAddr_XOR
OCP-IP Confidential
Name
1.3.11 burst_value_<signal>_<sequence> MByteEn STRM MDataByteEn MByteEn MDataByteEn STRM DFLT2 DFLT2
Activation Parameters
burstlength & burstseq_strm_enable & byteen & burstseq burstseq & burstseq_strm_enable & mdatabyteen & datahandshake burstlength & burstseq_dflt2_enable & byteen & burstseq burstseq & burstseq_dflt2_enable & mdatabyteen & datahandshake burstlength & burstseq_incr_enable & burst_aligned & burstseq burstlength & burstseq_incr_enable & addr burstlength & burstseq_blck_enable & addr burstlength & burstseq & burstseq_wrap_enable burstlength & burstseq & burstseq_xor_enable burstlength & burstseq_incr_enable & burst_aligned & burstseq burstprecise & burstseq_wrap_enable & burstlength & burstseq burstprecise & burstseq_xor_enable & burstlength & burstseq burstprecise & burstseq_blck_enable & burstlength & burstseq burstaligned & burstprecise & burstseq_incr_enable & burstseq burstprecise & burstsinglereq burstsinglereq & burstreq & burstseq_unkn_enable burstlength & readex_enable burstlength & rdlwrc_enable burstlength & rdlwrc_enable reqlast Reqlast & burstsinglereq mreqlast &mreqrowlast mreqlast &mreqrowlast datalast & mdata datalast & mdata mdatalast & mdatarowlast
1.3.12 burst_value_MAddr_INCR_burst_aligned 1.3.13 burst_value_MAddr_<sequence>_no_wrap INCR BLCK 1.3.14 burst_value_MBurstLength_<sequence> WRAP XOR 1.3.15 burst_value_MBurstLength_INCR_burst_aligned 1.3.16 burst_value_MBurstPrecise_<sequence> WRAP XOR BLCK 1.3.17 burst_value_MBurstPrecise_INCR_burst_aligned 1.3.18 burst_value_MBurstPrecise_SRMD 1.3.19 burst_value_MBurstSeq_UNKN_SRMD 1.3.20 burst_value_MCmd_<command> RDEX RDL WRC 1.3.21 burst_value_MReqLast_MRMD 1.3.22 burst_value_MReqLast_SRMD 1.3.23 burst_value_MReqRowLast_MRMD 1.3.24 burst_value_MReqRowLast_SRMD 1.3.25 burst_value_MDataLast_MRMD 1.3.26 burst_value_MDataLast_SRMD 1.3.27 burst_value_MDataRowLast_MRMD
OCP-IP Confidential
Name
1.3.28 burst_value_MDataRowLast_SRMD 1.3.29 burst_value_SRespLast_MRMD 1.3.30 burst_value_SRespLast_SRMD 1.3.31 burst_value_SRespRowLast_MRMD 1.3.32 burst_value_SRespRowLast_SRMD 1.3.33 burst_hold_MTagID_when_MTagInOrder_zero 1.3.34 burst_hold_MTagInOrder
Activation Parameters
mdatalast & mdatarowlast resplast & resp resplast & resp & burstsinglereq sresplast & sresprowlast sresplast & sresprowlast burtstlength & tags > 1 burstlength & tags > 1 & taginorder
Table 82
Name
1.4.1 transfer_phase_order_datahs_before_request_begin 1.4.2 transfer_phase_order_datahs_before_request_end 1.4.3 transfer_phase_order_response_before_request_begin 1.4.4 transfer_phase_order_response_before_request_end 1.4.5 transfer_phase_order_response_before_datahs_begin 1.4.6 transfer_phase_order_response_before_datahs_end 1.4.7 transfer_phase_order_response_before_last_datahs_begin _SRMD_wr 1.4.8 transfer_phase_order_response_before_last_datahs_end_ SRMD_wr 1.4.9 transfer_phase_order_reqdata_together_MRMD
Activation Parameters
datahandshake datahandshake resp resp resp & datahandshake resp & datahandshake resp & datahandshake & burstsinglereq resp & datahandshake & burstsinglereq reqdata_together & burstsinglereq
Table 83
Name
1.5.1 rdex_hold_<signal> MAddr MAddrSpace MByteEn MDataByteEn) 1.5.3 rdex_lock_release_no_burst_allowed
Activation Parameters
readex_enable & addr readex_enable & addrspace readex_enable & byteen readex_enable & mdatabyteen & datahandshake burstlength & readex_enable
OCP-IP Confidential
Table 84
Sideband Checks
Name
1.6.1 signal_valid_<signal> MReset_n SReset_n 1.6.2 signal_valid_<signal>_when_reset_inactive ControlBusy ControlWr MError SError SInterrupt StatusBusy StatusRd 1.6.3 signal_hold_<signal>_16_cycles MReset_n SReset_n 1.6.4 signal_hold_Control_after_reset 1.6.5 signal_hold_Control_2_cycles 1.6.6 signal_hold_Control_ControlBusy_active 1.6.7 signal_hold_ControlWr_after_reset 1.6.8 signal_value_ControlWr_Control_transitioned 1.6.9 signal_value_ControlWr_ControlBusy_active 1.6.10 signal_hold_ControlWr_2_cycle 1.6.11 signal_value_ControlBusy 1.6.12 signal_hold_StatusRd_2_cycles 1.6.13 signal_value_StatusRd_StatusBusy_active
Activation Parameters
mreset sreset controlbusy controlwr merror serror interrupt statusbusy statusrd mreset sreset control control controlbusy controlwr control & controlwr controlbusy & controlwr controlwr controlwr & controlbusy statusrd statusrd & statusbusy
Table 85
Name
1.7.1 signal_valid_<signal> MConnect SConnect SWait 1.7.2 signal_hold_MConnect_2_cycles 1.7.3 signal_value_MCmd_MConnect_not_connected 1.7.4 signal_order_MConnect_transaction 1.7.5 signal_value_SWait_MConnect_stable_state
Activation Parameters
connection
1.7.6 signal_value_SConnect_MConnect_connected connection 1.7.7 signal_value_SConnect_MConnect_connected connection 1.7.8 signal_value_MConnect_ConnectCap 1.7.9 signal_value_SConnect_ConnectCap 1.7.10 signal_value_SWait_ConnectCap
OCP-IP Confidential
MThreadBusy SThreadBusy
MBlockHeight and MBlockStride can be invalid for non-BLCK requests during the request phase.
OCP-IP Confidential
If datahandshake=1 and mdatabyteen=1 then MByteEn can be invalid for write accesses during the request phase Protocol hierarchy Signal group
Request phase Dataflow MAddr, MAddrSpace, MAtomicLength, MBurstLength, MBurstPrecise, MBurstSeq, MBurstSingleReq, MByteEn, MConnID, MReqLast, MThreadID, SCmdAccept, MBlockHeight, MBlockStride, MReqRowLast X, Z Section 4.3.3.1 on page 46 Section 12.1.2.1 on page 215
Critical signals
MDataRowLast
Response Dataflow MRespAccept, SRespLast, SRespRowLast, SThreadID X, Z Section 4.3.3.1 on page 46 Section 12.1.2.2 on page 216
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
The following exceptions apply: 1. If datahandshake=1 and mdatabyteen=1 then MByteEn can change for write accesses during the request phase. 2. For read requests the MData and MDataInfo fields can change during the request phase. 3. For write requests the SData and SDataInfo fields can change during the response phase. 4. Non-enabled data bytes in MData and bits in MDataInfo fields can change during the request and datahandshake phases. 5. Non-enabled data bytes in SData and bits in SDataInfo fields can change during the response phase. 6. MDataByteEn can change during read-type transfers.
OCP-IP Confidential
7. MTagID can change if MTagInOrder is asserted, and MDataTagID can change for the corresponding datahandshake phase. 8. STagID can change if STagInOrder is asserted. Protocol hierarchy Signal group
Request Dataflow MAddr, MCmd, MData, MAddrSpace, MByteEn, MDataInfo, MReqInfo, MAtomicLength, MBurstLength, MBurstPrecise, MBurstSeq, MBurstSingleReq, MReqLast, MConnID, MThreadID, MBlockHeight, MBlockStride, MReqRowLast Hold Section 12.1.2.1 on page 215
Critical signals
OCP-IP Confidential
if if if if
= = = =
OCP-IP Confidential
UNKN WRAP XOR Protocol hierarchy Signal group Critical signals Assertion type References
0000000000010000 0000000000100000 0000000001000000 0000000010000000 0000000100000000 0000001000000000 0000010000000000 0000100000000000 0001000000000000 0010000000000000 0100000000000000 1000000000000000 0000000000000011 0000000000001100 0000000000110000 0000000011000000 0000001100000000 0000110000000000 0011000000000000 1100000000000000 0000000000001111 0000000011110000 0000111100000000 1111000000000000 0000000011111111 1111111100000000 1111111111111111 0000000000000000 If datahandshake=1 and mdatabyteen=1 then MByteEn can change for write accesses during the request phase. Protocol hierarchy Signal group Critical signals Assertion type References
Request Dataflow - simple extensions MByteEn Value Section 4.9.1.3 on page 60
OCP-IP Confidential
Datahandshake Dataflow MData, MDataByteEn, MDataInfo, MDataLast, MDataRowLast, MDataThreadID, MDataValid, Hold Section 12.1.2.3 on page 217
0000000010000000 0000000100000000 0000001000000000 0000010000000000 0000100000000000 0001000000000000 0010000000000000 0100000000000000 1000000000000000 0000000000000011 0000000000001100 0000000000110000 0000000011000000 0000001100000000 0000110000000000 0011000000000000 1100000000000000 0000000000001111 0000000011110000 0000111100000000 1111000000000000 0000000011111111 1111111100000000 1111111111111111 0000000000000000 Protocol hierarchy Signal group Critical signals Assertion type Reference
Datahandshake Dataflow - simple extensions MDataByteEn Value Section 4.9.1.3 on page 60
OCP-IP Confidential
Response Dataflow SData, SDataInfo, SResp, SRespInfo, SRespLast, SRespRowLast, SThreadID Hold Section 12.1.2.2 on page 216
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
The hold requirements for SRespInfo in a burst are different for the 2.0 versus 2.2 specifications. OCP 2.0 page 44 states that: SRespInfo must be held steady by the slave for every transfer in a burst. OCP 2.2 page 55 states that: If possible, slaves should hold SRespInfo steady for every transfer in a burst Protocol hierarchy Signal group Critical signals Assertion type Reference
Burst Dataflow - burst extensions MAddrSpace, MAtomicLength, MBurstPrecise, MBurstSeq, MBurstSingleReq, MCmd, MConnID, MReqInfo, (SRespInfo) Hold Section 4.6.3 on page 55
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
FIRST_OFFSET Is the byte offset (from BASE) of the first transfer in the burst. CURRENT_COUNT Is the count of current transfer in the burst starting at 0. WORD_SHIFT Is the log2 of the OCP word size in bytes. The current address of the transfer is BASE | (FIRST_OFFSET ^ (CURRENT_COUNT << WORD_SHIFT)). Protocol hierarchy Signal group Critical signals Assertion type Reference
Burst Dataflow - basic signals MAddr Ordering Section 4.6.1 on page 53
Example For an interface with data_width=32, size=2 and: MBurstLength = 2:MAddr[2:0] = 0 MBurstLength = 4:MAddr[3:0] = 0
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
phases of a MRMD burst, except on the last one when it must be 1. If mdatalast and mdatarowlast are both enabled, whenever MDataLast is asserted MDataRowLast must also be asserted. Protocol hierarchy Signal group Critical signals Assertion type References
Burst Dataflow - burst extensions MDataRowLast, MDataLast Value Section 4.6.6 on page 56
OCP-IP Confidential
should only focus on the request phase. The datahandshake phase is covered by phase property datahs_order_MDataTagID_when_ MTagInOrder_zero. This last property checks that the datahandshake phase observes the same order as the request phase. Protocol hierarchy Signal group Critical signals Assertion type Reference
Burst Dataflow - tag extensions MTagID, (MTagInOrder) Hold Section 4.7.1 on page 57
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
When mdatabyteen = 1, the unlocking command following a ReadEx must retain for MDataByteEn the value given to MByteEn during the ReadEx command. If MByteEn is absent, MDataByteEn must be all 1s. Protocol hierarchy Signal group Critical signals Assertion type References
ReadEx Dataflow - basic signals, simple extensions MAddr, MAddrSpace, MByteEn, MDataByteEn Hold Section 4.4 on page 49 Section 4.6 on page 52
OCP-IP Confidential
MError
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
SWait
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
burstseq_unkn_enable
Section 4.9.5 on page 64
OCP-IP Confidential
OCP-IP Confidential
OCP-IP Confidential
Rule 2.6.28
master_slave_cfg_interoperability
If either master or slave have connection parameter set to 0, then ConnectCap for master and slave that have this parameter to 1 must be tied off to 0. Protocol hierarchy Critical parameters Reference
sideband connection Section 3.2.1 on page 26
OCP-IP Confidential
OCP-IP Confidential
20
Functional Coverage
The functional coverage approach described in this chapter is bottom-up, meaning the analysis starts at the signal level and goes up to the transaction level. The transfer level has been skipped for reasons highlighted in Section 20.2 on page 447. Along this path several coverage types are used. The signal level uses toggle, state, and meta coverages, while the transaction level uses cross and meta coverages. Toggle coverage Toggle coverage provides baseline information that a system is connected properly, and that higher level coverage or compliance failures are not simply the result of connectivity issues. Toggle coverage answers the question: Did a bit change from a value of 0 to 1 and back from 1 to 0? This type of coverage does not indicate that every value of a multi-bit vector was seen but measures that all the individual bits of a multi-bit vector did toggle. In certain cases, not all bits can toggle. A system that only supports RD commands, (010) for example, will only need toggle coverage on MCmd bit1. MCmd bit0 and bit2 will always be 0. Therefore they must be filtered from the MCmd toggle coverage. State coverage State coverage applies to signals that are a minimum of two bits wide. In most cases, the states (also commonly referred to as coverage bins) can be easily identified as all possible combinations of the signal. For example, for the SResp signal, the states could be 00 (IDLE), 01 (DVA), 10 (FAIL) and 11 (ERR). If the state space is too large, an intelligent classification of the states must be made. In the case of the MAddr signal for example, a possible choice of the coverage bins could be one bin to cover the lower address range, one bin to cover the upper address range and one bin to cover all other intermediary addresses. Meta coverage Meta coverage is collecting second-order coverage data. Possible meta coverage measurements include accept backpressure delays, threadbusy backpressure delays and inter-phase delays. Meta coverage information is
OCP-IP Confidential
particularly useful to flag excessive latencies (possibly indicating deadlocks) and to evaluate the OCP backpressure mechanisms (accept / threadbusy). Cross coverage Cross coverage measures the activity of one or multiple categories. A category is defined at the transaction level that typically groups multiple OCP signals to form a more abstract, higher-level view of a particular aspect of the OCP protocol. The most pertinent category example is the transTypes. This category combines the MCmd, MBurstLength and MBurstSingleReq signals into a higher-level category. Cross coverage on one category, for example the transTypes category, indicates which kind of transactions were applied to the system under test (for instance, MRMD-RD-4, SINGLE-WRNP, etc.). Cross coverage on multiple categories, for example the transTypes and transResults categories, not only provides information about the transactions applied to the system, but also on their results. In essence, cross coverage measures the types of transactions passing through a system.
OCP-IP Confidential
MTagID/MDataTagID/STagID MThreadID/MDataThreadID/SthreadID
Signals that are only one bit wide only have toggle coverage:
MBurstPrecise/MBurstSingleReq MReqLast/MDataLast/SRespLast MTagInOrder/STagInOrder MReqRowLast/MDataRowLast/SRespRowLast
Table 86
Req
X X X
Datahs Resp
Level 2
State State State Meta Meta Meta State Meta State
X X
OCP-IP Confidential
Req
X X
Datahs Resp
Level 2
State State State State State State State State State State State
X X
Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle Toggle
State
State State
State
OCP-IP Confidential
Req
Datahs Resp
Level 2
State
Table 87 outlines options for signal level meta coverage. For each phase group (req/datahs/resp), two meta coverage types are identified: accept backpressure delay and threadbusy backpressure delay. Other meta coverage types could be identified.
Table 87 Signal Level Meta Coverage Examples
Phase Group
Request phase
Coverage Types
Accept backpressure delay Thread busy backpressure delay
Details
MCmd SCmdAccept delay SThreadBusy backpressure delay (per bit) MDataValid SDataAccept delay SDataThreadBusy backpressure delay (per bit) SResp MRespAccept delay MThreadBusy backpressure delay (per bit)
Datahs phase
OCP-IP Confidential
Req
H*L
Datahandshake Writeresp_enable
H*L H*L H*L H*L H*L H*L 1 H*L H*L H*L H*L H*L H*L H*L H*L
0 0 0 1 1 1
1 1 1
1 1 1
0 1 dont care
Notes to Table 88: 1. The table shows how phases are combined into SINGLE transfers, MRMD bursts and SRMD bursts. SINGLE transfers can be de-generated from either MRMD or SRMD bursts. 2. L stands for the MBlockLength (one in the case of a SINGLE transfer) and H stands for MBlockHeight. 3. transTypes are controlled by the signals MBurstSingleReq, MCmd and MBlockHeight(H), MBurstLength (L) and the parameters datahandshake and writeresp_enable. 4. RDEX, RDL, and WRC commands only apply to SINGLE transfers.
OCP-IP Confidential
5. RD, RDEX, and RDL are not controlled by the datahandshake and writeresp_enable parameters. 6. WRNP and WRC are not controlled by the writeresp_enable parameter. 7. The possible transTypes are: SINGLE transfers RD, WR, BCST, WRNP, RDEX, RDL, and WRC MRMD bursts RD, WR, BCST, and WRNP SRMD bursts RD, WR, BCST, snf WRNP
The following example illustrates this. If MBurstSingleReq supports values 0 and 1 and If MCmd only supports RD,WR,WRNP,RDEX and If datahandshake == 1 and writeresp_enable == 1 then the transTypes will be: a) SINGLE transfers, RD/WR/WRNP/RDEX b) MRMD bursts, RD/WR/WRNP c) SRMD bursts, RD/WR/WRNP
Category Concept
A category groups one or more OCP signals and serves as a building block for cross coverage. A category also represents a higher level view of the OCP protocol, allowing intelligent crosses to be made of one or more categories. Table 89 lists and describes the proposed categories:
Table 89 Categories
Name
transTypes transTargets transResults
Description
Category containing the transaction types based on Table 88 Category containing the transaction targets (MAddr / MAddrSpace) Category containing the transaction results (SResp)
transBurstProps Category containing the burst properties (AtomicLength / MBurstPrecise / MBurstSeq) transByteens flowThreads flowTagTypes Category containing the transaction byte enables (MByteEn / MDataByteEn) Category containing the flows as function of the ThreadID Category containing the flows as function of the TagInOrder / TagID
Notes to Table 89: 1. The transBurstProps category may be split into multiple categories enabling a higher granularity for cross coverage. 2. The flowTagTypes category combines the TagInOrder and TagID signals. The tag type is encoded as follows:
OCP-IP Confidential
If TagInOrder, then tag type == tag-in-order (1 enumerated value) If not, then tag type == the TagID (multiple enumerated values)
If the TagID range is too large, sub-ranges should be defined. As such, the tag type will have 1 + x enumerated values.
Signal
MAddr MAddrSpace MAtomicLength MBlockHeight MBurstLength MBurstPrecise MBurstSeq MBurstSingleReq MByteEn MCmd MDataByteEn MDataTagID MDataThreadID MTagID MTagInOrder MThreadID SResp X X X X
X X X
X X
X X X X X X X
OCP-IP Confidential
Signal
X X
OCP-IP Confidential
Table 91
Categories transTypes
X X X X X X X X X X
OCP-IP Confidential
Accept backpressure delays relative to the position in the transaction Threadbusy backpressure delays relative to the position in the transaction
transTargets
X
transResults
transBurstProps
transByteens
Flow Threads
X
flowTagTypes
Cross Description
Cross all transaction types with all targets Cross all transaction types for all threads Cross all transaction types with all transaction results Cross all transaction types for all bursts with all byte enable patterns Cross all transaction types for all bursts with the transaction results
Coverage Details
req to req / datahs to datahs / resp to resp delays req to datahs / req to resp / datahs to resp delays First req accepted delay / last req accepted delay for MRMD bursts Measure when accept backpressure occurs in a transaction Measure when threadbusy backpressure occurs in a transaction
State coverage Sideband signals that consist of multiple bits can have state coverage similar to the dataflow signals. Meta coverage Meta coverage can be added for the control and status signals. Some examples of meta coverage that might be added for the control signals handshake are: The delay between two ControlWr signal assertions. The length of the ControlBusy signal assertion. The ControlBusy assertion relative to the previous ControlWr assertion.
Some examples of meta coverage that might be added for the status signals handshake are: The delay between two StatusRd signal assertions. The length of the StatusBusy signal assertion.
OCP-IP Confidential
Sideband Signals
Naming template: sideband_<coverage type>_<signal name | meta name>_<bin>
OCP-IP Confidential
In which: <coverage type>:toggle state meta <signal name>:OCP signal <meta name>:ControlWrControlWrDelay ControlBusyDuration ControlWrControlBusyDelay StatusRdStatusRdDelay StatusRdDuration <bin>: be free to choose a clear name Examples: sideband_toggle_ControlWr sideband_state_Control_3 sideband_meta_StatusRdDuration_5
OCP-IP Confidential
OCP-IP Confidential
A.1 Header
The header section defines the parameters of the OCP connection from which the trace data originated. Example 2 shows a sample OCP trace file.
Example 2 Sample OCP Trace File
# ocpversion=ocp2.2-1.6 # name=ocp20_ocpmon2 # mreset=1 # addr_wdth=32 # data_wdth=64 ## 10.0 0 0 xxxxxxxx x xxxxxxxxxxxxxxxx 110.0 1 0 xxxxxxxx x xxxxxxxxxxxxxxxx 120.0 210.0 1 1 00000000 1 0000000087654321 220.0 230.0 370.0 1 0 xxxxxxxx x xxxxxxxxxxxxxxxx 380.0 1 0 xxxxxxxx x xxxxxxxxxxxxxxxx ...
1 0000000087654321 0 xxxxxxxxxxxxxxxx
OCP-IP Confidential
Parameters in the header section show the parameter name and the assigned value. The ocpversion is derived from the install tree and provides the OCPIP revision number and release number. For example, ocpversion=ocp2.21.6. The name parameter identifies the OCP monitor from which the trace data was recorded. For example, name=ocp20_ocpmon2 indicates the OCP monitor name was ocp20_ocpmon2. If a parameter is not specified in the header, the default value listed in Table 29 on page 68 is used. If signals are enabled, width parameters are required for the corresponding signals, but width parameters do not have explicit defaults. Typically, trace files generated by monitors specify all parameter values. Since mreset and sreset do not have defaults, values must be specified for each. The header of the trace file always ends with a double pound sign (##). Optional comment lines preceded by a pound sign may appear following the header and contain information about the program that generated the file.
459
Table 93
Field
Simulation Time MReset_n SReset_n MCmd MAddr MAddrSpace MByteEn MConnID MReqInfo MThreadID MTagID MTagInOrder MAtomicLength MBurstLength MBlockHeight3 MBlockStride3 MBurstPrecise MBurstSeq MBurstSingleReq MReqLast MReqRowLast 3 SCmdAccept SThreadBusy MData MDataInfo MDataValid MDataByteEn MDataThreadID MDataTagID MDataLast MDataRowLast 3
Parameter Condition
None mreset parameter is 1 sreset parameter is None addr is 1 addrspace is 1 byteen connid is 1 reqinfo is 1 threads > 1 tags > 0 taginorder is 1 atomiclength is 1 burstlength is 1 blockheight is 1 blockstride is 1 burstprecise is 1 burstseq is 1 burstsinglereq is 1 reqlast is 1 reqrowlast is 1 cmdaccept is 1 sthreadbusy is 1 mdata is 1 mdatainfo is 1 datahandshake is 1 mdatabyteen is 1 threads > 1 and datahandshake is 1 tags > 1 and datahandshake is 1 datalast is 1 datarowlast is 1
Format
floating point hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal
OCP-IP Confidential
Field
SDataAccept SDataThreadBusy SResp SRespInfo SThreadID STagID SData SDataInfo SRespLast SRespRowLast 3 MRespAccept MThreadBusy MFlag MError SFlag SError SInterrupt Control ControlWr ControlBusy Status StatusRd StatusBusy
1.
Parameter Condition
dataaccept is 1 sdatathreadbusy is 1 resp is 1 respinfo is 1 threads > 1 and resp is 1 tags > 1 and resp is 1 sdata is 1 sdatainfo is 1 resplast is 1 resprowlast is 1 respaccept is 1 mthreadbusy is 1 mflag is 1 merror is 1 sflag is 1 serror is 1 interrupt is 1 control is 1 controlwr is 1 controlbusy is 1 status is 1 statusrd is 1 statusbusy is 1
Format
hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal hexadecimal binary binary binary binary binary hexadecimal binary binary hexadecimal binary binary
The threadid_wdth parameter is internal and calculated as follows: threadid_wdth = max(1, log2(threads)) The tagid_wdth parameter is internally derived, and is calculated as follows: tagid_wdth = max(1, log2(tags)) No signals are associated with *threadbusy_pipelined parameters. The existing Thread Signals are used in that case.
2.
3.
OCP-IP Confidential
Index
A
access mode information 18 addr parameter 69 addr_base statement 137 addr_size statement 137 addr_wdth parameter 14, 69 address conflict 49 match 49 region statement 137 sequence BLCK 228 burst 53, 227 DFLT1 227 DFLT2 228 INCR 227 STRM 227 UNKN 229 user defined 227 WRAP 228 XOR 228 space 9 coherent 77 non-coherent 77 transfer 17 addrspace parameter 17, 69 addrspace_wdth 17 addrspace_wdth parameter 69 arbitration, shared resource 8 area savings 216, 220 asynchronous reset assertion 46, 246 atomicity requirements 55 atomiclength parameter 20, 69 atomiclength_wdth parameter 20, 69 ATPG vectors 253 block data flow profile 339 blockheight parameter 20 blockheight_wdth parameter 20 blockstride parameter 20 blockstride_wdth parameter 20 bridging profiles 341 Broadcast command description 8 enabling 59 transfer effects 50 broadcast_enable parameter 68 bundle characteristics 134 defining core 133 non-OCP interface 123 name 133 nets 134 port mapping 133 signals 125 statement 125 bundle statement 125 burst address sequence 21, 53 address sequences 227 alignment 60 burst_aligned parameter 60 command restrictions 52 constant fields 55 definition 52 exclusive OR 53 extension 226 framing 170 imprecise definition 52 MBurstLength 55 read 172 uses 227 INCR 60 incrementing precise read 175 interleaving 62 length 20 lengths 227 null cycles 177 packets 52 phases datahandshake 56 precise definition 52 MBustLength 54 read 170 precise write 165
B
basic OCP signals 13 BCST 15 bit naming 136 BLCK address sequence 228 block last request 22 response 22 transfer 21
request, last 22 response, last 22 sequences 59 signals 19 single request 21 single request/multiple data conditions 229 definition 52 read 178 write 181 state machine 222 support reporting instructions 350, 351 signals 19 tagged 187 transfers atomic unit 20 total 20 types 52 wrapping 174 write last 21 burst_aligned parameter 60, 68 burstlength parameter 20, 69 burstlength_wdth parameter 20, 69 burstprecise parameter 21, 69 bursts precise uses 227 burstseq 68 burstseq parameter 21, 69 burstseq_dflt1_enable parameter 68 burstseq_dflt2_enable parameter 68 burstseq_incr_enable parameter 68 burstseq_strm_enable parameter 68 burstseq_unkn_enable parameter 68 burstseq_wrap_enable parameter 68 burstseq_xor_enable parameter 68 burstsinglereq parameter 21, 69 bus independence 8 of signals 125 wrapper interface module 2 byte enable data width conversion 54 field 17 MByteEn signal 17 pattern 56 supported patterns 60 write 17 byteen parameter 17, 69
C
c2qtime port constraints 149 timing 142 c2qtimemin 149 cache coherence definition 74 cache line 75 cacheable storage attributes 18 capacitance wireload 151 wireloaddelay 151 capacitive load 143 cell library name 143 chipparam variable 147 Clk signal function 14 summary 31 ClkByp signal function 29 summary 34 test extensions 253 timing 49 clkctrl_enable parameter 30, 71 clock bypass signal 30 control test extensions 253 divided enabling 214 timing 214 gated test 30 non-OCP 148 portname 149 signal 14 test 30 clockName 148 clockname field 149 clockperiod variable 146 cmdaccept parameter 15, 69 coh_enable 95 cohcmd_enable 95 coherence intervention port 77 protocol four hop 76 three hop 76 coherence-aware masters 77 coherent master 77 slave 78 coherent address space 77 coherent commands 75
Index 463
cohfwdid_enable 96 cohfwdid_wdth 96 cohnc_enable 95 cohstate_enable 95 cohwrinv_enable 95 combinational dependencies 39, 317, 318 Mealy state machine 220 paths 145, 154 slave state machine 221 command encoding 15 limiting 15 request types 15 commands basic 8 extensions 8 required 64 concurrency 233 configurable interfaces 135 ConnectCap function 27 summary 33 connection description 239 identifier definition 239 field 24 support 350, 351 transfer handling 58 uses 10 transfers 58 connection parameter 26 connid parameter 24, 69 connid_wdth parameter 24, 69 control event signal 28 field 28 information specifying 28 timing 48 parameter 28, 71 timing 48 Control signal function 25 summary 33 timing 48 control_wdth parameter 28, 71 controlbusy parameter 28, 71 ControlBusy signal function 25 summary 33 timing 48
controlwr parameter 28, 71 ControlWr signal 48 function 25 summary 33 core area 148, 349 code 131 control busy 28 event 28 information 28 documentation 349 documentation template 354 endianness 62 frequency range 349 ID 349 interconnecting 144 interface defining 133 endianness 52 timing parameters 142 interoperability 64 name 349 power consumption 349 process dependent 349 revision 131 RTL configuration file 129 status busy 29 event 29 information 28 synthesis configuration file defining 141 tie-off constants 67 timing 141, 315 core_id statement 130 core_name 129 core_stmt 129
D
data byte parity 18 data width conversion 54 endianness 244 data_wdth 31 data_wdth parameter 14, 15, 16, 17, 20, 31, 34, 69 dataaccept parameter 16, 69 dataflow signals definitions 13 naming 13 timing 41 datahandshake extension 180 intra-phase output 237 parameter 15
phase active 41 order 43 sequence 217 signal group 38 datahandshake parameter 63, 68 datalast parameter 21, 69 datarowlast parameter 69 ddr_space statement 137 debug and test interface 30, 253 DFLT1 burst sequence 53, 60 DFLT2 burst sequence 53, 60 direction statement 125 divided clock 214 driver strength 143 drivingcellpin parameter timing requirements 143 values 149 DVA 16 DVA response 16, 49
FIFO full 19 flags core-specific 25 master 27 slave 28 flow-control 61, 350, 351 force_aligned parameter 60, 68
H
H-bus profile 341 high-frequency design 217 hold time checking 142 holdtime description 150 timing 142
I
icon statement 130 implementation restrictions 350, 351 imprecise burst 55 INCR burst sequence 53, 60 inout ports 151, 152 input load 143 port syntax 151 signal timing 142 instance size 148 interface characteristics 350 clock control 30 compatibility 64 configurable 135 configuration file 123 core RTL description 129 debug and test 30 endianness 52 location 136 multiple 133 parameters 135 scan 29 statement 133 type statement 134 types 125 interface_types statement 125 interfaceparam variable 147 internal scan techniques 253 interoperability rules 64 interrupt
E
EnableClk function 14 summary 14, 31 use with divided clocks 214 enableclk parameter 214 endian parameter 62, 68, 244 endianness attributes 62 bit ordering 244 concepts 51 data width issues 244 definitions 62 dynamic interconnect 245 ERR response 16 error correction code 18 master 27 report mechanisms 11 signal 25 slave 27 exclusive OR bursts 53 extended OCP signals 16, 223
F
FAIL response 16, 49 false path constraints 145, 154 falsepath parameter 145, 154 fanout maximum 150
Index 465
parameter 28 processing 10 signal 25 slave 28 interrupt parameter 71 intervention port 77 intport_exists 95 intport_writedata 95
J
jtag_enable parameter 30, 71 jtagtrst_enable 30 jtagtrst_enable parameter 71
cohfwdid_enable 96 cohnc_enable 95 cohstate_enable 95 cohwrinv_enable 95 intport_exists 95 intport_writedata 95 mcohid_enable 95 mcohid_wdth 96 rdlwrc_enable 95 read_enable 95 readex_enable 95 scohid_enable 96 scohid_wdth 96 upg_enable 95 write_enable 95 writenonpost_enable 95 master coherence-aware 77, 78 coherent 77 error signal 27 flags 27 interface documentation 350 reset 27, 46 response accept 15 signal compatibility 64 slave interaction 235 thread busy 24 MAtomicLength signal atomicity 55 function 19 summary 32 maxdelay parameter description 154 timing 145 maxfanout variable 150 MBurstLength signal burst lengths 54 function 19 summary 32 values 227 MBurstPrecise signal function 19 summary 32 MBurstSeq signal address sequences 227 encoding 21 function 19 summary 32 MBurstSingleReq signal conditions 55 function 20 summary 32 MBurstSinqleReq signal transfer phases 42 MByteEn signal function 16
L
latency sensitive master 221 lazy synchronization command sequences 242 mechanism 241 legacy commands 75 level0 timing 315, 316 level1 timing 315, 316 level2 timing 315, 316 loadcellpin description 150 timing 143 loads parameter description 150 timing 143 location statement 136 locked synchronization 241 longest path 149
M
MAddr effect of data_wdth on 14 function 14 setting the width of 14 summary 31 MAddrSpace signal function 16 summary 31 main port 77 MCmd 94 MCohCmd signal 94 SCohState 94 SResp 94 main port parameter coh_enable 95 cohcmd_enable 95
summary 31 MCmd 94, 99 MCmd signal function 14 summary 31 MCohCmd 94, 99 mcohid_enable 95 mcohid_wdth 96 MConnect function 26 summary 33 MConnID signal function 23 summary 32 mdata parameter 15, 69 MData signal data valid 15 description 14 request phase 217 summary 31 mdatabyteen parameter 17, 69 MDataByteEn signal function 16 phases 41 summary 31 mdatainfo parameter 18, 69 MDataInfo signal function 16 summary 31 mdatainfo_wdth parameter 18, 70 mdatainfobyte_wdth parameter 18, 70 MDataLast signal function 20 phases 56 summary 32 MDataTagID signal flow 57 function 22 summary 32 MDataThreadID signal datahandshake 234 function 23 summary 32 MDataValid signal datahandshake 217 function 14 summary 31 timing 217 MError 27 merror parameter 27, 71 MError signal summary 33
Message 93 Non-Posted 93 mflag parameter 27, 71 MFlag signal function 25 summary 33 mflag_wdth parameter 27, 71 MFlags 27 MReqInfo signal function 17 summary 31 MReqLast signal function 20 phases 56 summary 32 mreset parameter 27, 71 MReset_n signal function 25 required cycles 46 summary 33 timing 46 MRespAccept signal definition 14 response phase 216 response phase output 236 saving area 216 summary 31 MSecure subnet 245 MTagID signal flow 57 function 22 summary 32 MTagInOrder signal 233 function 22 summary 32 mthreadbusy parameter 24, 70 MThreadBusy signal definition 23 information 58 intra-phase output 236 semantics 44 summary 32 timing cycle 44 mthreadbusy_exact parameter 44, 61, 68 mthreadbusy_pipelined parameter 44, 70 MThreadID signal function 23 summary 32
N
nets bit naming 136 characterizing 125
Index 467
redirection 134 statement 125 non-coherent address space 77 Non-Posted Message 93 NULL response 16, 177
mapping 133 module names 135 output, syntax 152 renaming 134 statement 134 timing constraints 141 Posted Message 93 posted write model 42 timing diagram 163 power consumption estimates 349 idling cores 214 precise burst 54 precise bursts 227 prefix command 135 profiles benefits 319 block data flow 339 bridging 341 H-bus 341 register access 337 sequential undefined length data flow 335 types 334 X-bus packet read 345 X-bus packet write 343 programmable register interfaces 337 proprietary statement 137 protocol interoperability 64 phases mapping 41 order 43 rules 41
O
out-of-band information 27 output port syntax 152 signal timing 142
P
packets 52 param variable 147 parameter blockstride_wdth 20 mdatainfo_wdth 18 mdatainfobyte_wdth 18 parameter summary 31 partial word transfer 50 path longest 149 shortest 149 phase interoperability 66 intra-phase 235 options 63 ordering between transfers 43 request 215 within transfer 43 protocol 40 timing 215 transfer 42 physical design parameters 143 pin level timing 142 pipeline decoupling request phase 226 request/response protocol 216 support 350 transfer 222 without MRespAccept 216 write data, slave 16 pipelined access 339 point-to-point signals 8 port constraint variables 149 delay 154 inout 151, 152 input, syntax 151
Q
Query 94
R
RDEX 15 rdlwrc_enable 95 rdlwrc_enable parameter 68 read burst wrapping 174 data field 16 imprecise burst 172 incrementing precise burst 175 information 18 non-pipelined timing diagram 167 optimizing access 216 out-of-order completion 189 tagged 185, 187 precise burst 170
single request/multiple data 178 tagged 185, 187 threaded 189 timing diagram 159 Read command enabling 59 transfer effects 49 read_enable 95 read_enable parameter 68 ReadEx command burst restrictions 52 enabling 59 transfer effects 49 readex_enable 95 readex_enable parameter 68 ReadLinked command 242 burst restrictions 52 enabling 59 encoding 15 mnemonic 15 transfer effects 49 reference_port statement 134 register access profile 337 reqdata_together parameter 63, 68, 181, 229 reqinfo parameter 18, 70 reqinfo_wdth parameter 18, 70 reqlast parameter 22, 70 reqrowlast parameter 22, 70 request delays 162 flow-control mechanism 161 handshake 161 information 18 interleaving 55 last 56 last in a burst 22 order 23 phase intra-phase 235 order 43 outputs 215, 235 signal group 41 timing 215 transfer ordering 43 worst-case combinational path 235 pipelined 168 signals active 41 group 38 tag identifier 23 thread identifier 24 reset asynchronous
completed transactions 46 asynchronous assertion 246 conditions 246 domains 247 dual signals 247 interface compatibility 247 master 27 phases 46 power-on 246 signal 25 slave 28 special requirements 350 state 46 timing 195 resistance wireload 151 wireloaddelay 151 resp parameter 16, 70 respaccept parameter 15, 70 respinfo parameter 19, 70 respinfo_wdth parameter 19, 70 resplast parameter 22, 70 response accept 15 accept extension 169 delays 162 encoding 16 field 16 information 19 last in a burst 22 mnemonics 16 null cycle 177 order 23 phase active 41 intra-phase 236 order 43 slave 236 timing 216 pipelined 168 required types 64 signal group 38 tag identifier 23 thread identifier 24 resprowlast parameter 22, 70 revision_code 131 rootclockperiod variable 147 RTL proprietary extenstions 137
S
scan clock 253 control 253 data
Index 469
in 29 out 30 interface signals 29 mode control 29 Scanctrl signal 29 Scanin signal 29 Scanout signal 30 test environments 253 test mode 253 Scanctrl signal function 29 summary 34 uses 253 scanctrl_wdth parameter 29, 71 Scanin signal function 29 summary 34 timing 49 Scanout signal function 29 summary 34 timing 49 scanport parameter 71 scanport_wdth parameter 29, 71 SCmdAccept signal definition 14 request phase 215 request phase output 235 summary 31 scohid_enable 96 scohid_wdth 96 SCohState 94 SConnect function 26 summary 33 sdata parameter 16, 70 SData signal function 14 summary 31 SDataAccept signal datahandshake 217 function 14 summary 31 sdatainfo parameter 18, 70 SDataInfo signal function 17 summary 31 sdatainfo_wdth parameter 18, 70 sdatainfobyte_wdth parameter 70 sdatathreadbusy parameter 24, 70 SDataThreadBusy signal function 23 semantics 44
summary 32 timing cycle 44 SDataThreadbusy signal information 58 sdatathreadbusy_exact parameter 44, 68 sdatathreadbusy_pipelined parameter 44, 70 security level 245, 333 parameters 245 semaphores 241 sequential undefined length data flow profile 335 serror parameter 27, 71 SError signal function 25 summary 33 setuptime description 150 timing 142 sflag parameter 28, 71 SFlag signal function 25 summary 33 sflag_wdth parameter 28, 71 shared resource arbitration 8 shortest path 149 sideband signals definitions 25 timing 46, 246 signal attribute list 135 basic OCP 13 configuration 31 dataflow 13 direction 35 driver strength 143 extensions simple 16 thread 23 group division 38 mapping 41 interface interoperability 66 ordering 235 requirements 64 sideband 25 test 29 tie-off 67, 135 rules 66 tie-off values 31 timing input 142 output 142 requirements 40 restrictions 235
ungrouped 44 width 136 width mismatch 66 SInterrupt signal function 25 summary 33 slave coherent 78 combinational paths 236 error 27 flag description 28 interface documentation 350 interrupt 28 optimizing 233 pipelined write data 16 reset 28, 46 response field 16 response phase 236 signal compatibility 64 successful transfer 49 thread busy 24 transfer accept 15 write accept 16 thread busy 24 sreset parameter 28, 71 SReset_n signal function 25 required cycles 46 summary 33 timing 46 SResp 94 SResp signal function 14 summary 31 SRespInfo signal function 17 summary 31 SRespLast signal function 20 phases 56 summary 32 STagID signal flow 57 function 22 summary 32 STagInOrder signal 233 function 22 summary 32 state machine combinational master 220 Mealy 220 slave 221 diagrams 215
multi-threaded behavior 234 sequential master 217 sequential slave 219 states 76 status busy 29 core 28 event 29 information response 19 signals 28 parameter 28 timing 48 status parameter 71 Status signal function 25 summary 33 status_wdth parameter 28, 71 statusbusy parameter 29, 71 StatusBusy signal function 25 summary 33 timing 48 statusrd parameter 29, 71 StatusRd signal function 25 summary 33 timing 48 sthreadbusy parameter 25, 70 SThreadBusy signal function 23 information 58 semantics 44 slave request phase 235 summary 32 timing cycle 44 sthreadbusy_exact parameter 44, 61, 68, 191 sthreadbusy_pipelined parameter 44, 70 SThreadID signal function 23 summary 32 STRM burst sequence 53, 60 subnet statement 136 SWait function 26 synchronization deadlock 243 lazy 241 locked 241 synchronous handshaking signals 3 interface 8 system
Index 471
initiator 2 target 2
T
tag burst handling 187 burst interleaving 62 definition 232 flow 57 identifier binary-encoded value 23 interleaving 57 ordering 57 read handling 185 value 232 tag_interleave_size parameter 62 taginorder parameter 23, 70 tags parameter 22, 70 TCK signal function 29 summary 34 TDI signal function 29 summary 34 TDO signal function 29 summary 34 test clock 30 clock control extensions 253 data in 30 out 30 logic reset 30 mode 30 signals definitions 29 timing 46, 49 TestClk signal function 29 summary 34 timing 49 thread arbitration 192 blocking 191 busy hint 191 master 24 signals 58 slave 24 busy semantics 234 busy signals 234 dependency 234 description 233 end-to-end identification 58
identifier binary-encoded value 24 definition 239 request 24 response 24 uses 58 mapping 58 multiple concurrent activity 58 non-blocking 61 multi-threaded interface 237 ordering 10 signal extensions 23 state machine implementation 234 transfer order 233 valid bits 238 threads parameter 24, 70 throughput documenting 350 maximum 216 peak data 221 timing categories definitions 315 level0 316 level1 316 level2 316 combinational path 40 combinational paths 145 constraints ports 141 core 141 connecting 144 interface parameters 142 dataflow signals 41 diagrams 159 max delay 145 parameters 149 pin-level 142 pins 143 sideband signals 46 signals 40, 235 test signals 46 TMS signal function 29 summary 34 transfer accept 15 address 14 address region 17 assigning 58 burst linking 52 byte enable 17 command 15 concurrent activity 58 connection ID 24
data widths 9 effects of commands 49 efficiency 9, 54 endianness 52 order 10, 43 out-of-order 58 phases 42 pipelining 9 successful 49 type 15 TRST_N signal function 29 summary 34 type statement 126
transfer 9, 50 worstcasedelay 148 WRAP burst sequence 53, 60 wrapper interface modules 2 write byte enables 17 data burst 21 extra information 17 master to slave 15 slave accept 16 tag ID 23 thread ID 24 valid 15 nonpost phases 42 timing diagram 164 non-posted semantics 240 posted phases 42 semantics 240 precise burst 165 response enabled 163 single request, multiple data 181 timing diagram 159 Write command burst restrictions 52 enabling 59 transfer effects 49 write_enable 95 write_enable parameter 68 WriteConditional command 242 burst restrictions 52 enabling 59 encoding 15 mnemonic 15 transfer effects 50 WriteNonPost command burst restrictions 52 enabling 59 encoding 15 mnemonic 15 semantics 8 transfer effects 49 writenonpost_enable 95 writenonpost_enable parameter 68, 240 writeresp_enable parameter 68, 240
U
UNKN burst sequence 53, 60 upg_enable 95
V
vendor code 130 version 148 statement 125, 130 VHDL ports 125 signals 125 vhdl_type command 125 Virtual Socket Interface Alliance 1 visible 77
W
width data 9 interoperability 66 mismatch 66 wireloadcapacitance description 151 See also wireloaddelay timing 143 wireloaddelay description 151 timing 143 wireloadresistance description 151 timing 143 word corresponding bytes 17 packing 54 padding 54 partial 50 power-of-2 15 size 9, 15 stripping 54
X
X-bus packet read profile 345 write profile 343 XOR address sequence 53
Index 473
OCP-IP Administration 3116 Page Street Redwood City, CA 94063 Ph: +1 (512) 551.3377 Fax: +1 (650) 365.4658 admin@ocpip.org www.ocpip.org