Intro To SLIMbus

9-Feb-2009
MIPI Alliance Specification for

Serial Low-power Inter-chip Media Bus (SLIMbusSM)
Version 1.01.01 14 July 2008

MIPI Board Approved 3 December 2008
* Note to Implementers *
This document is a MIPI Specification formally approved by the MIPI Alliance Board of Directors
per the process defined in the MIPI Alliance Bylaws. Implementers should be aware of the
following:
This version of the SLIMbus specification implements a number of minor revisions based
on implementation feedback. No new features were added from the previous release,
MIPI Alliance Specification for Serial Low-power Inter-chip Media Bus (SLIMbusSM),
version 1.00.00.
The LML WG is committed to supporting the adoption of SLIMbus by designing new
device classes, by helping the SLIMbus community to develop standardized methods to
test and validate SLIMbus implementations and by generating comprehensive white
papers on SLIMbus benefits and architectures.
The MIPI Alliance has established an e-mail address to allow any MIPI member to submit
anonymous questions about the SLIMbus specification. Questions can be sent to lml-
questions@mipi.org. MIPI has no obligation to respond to such questions, but shall make
reasonable efforts to do so.
Copyright 2007-2009 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
Version 1.01.01 14-Jul-2008 MIPI Alliance Specification for SLIMbusSM
MIPI Alliance Specification for

Serial Low-power Inter-chip Media Bus
(SLIMbusSM)
Version 1.01.01 14 July 2008

MIPI Board Approved 3-Dec-2008
Further technical changes to this document are expected as work continues in the LML Working Group

1 NOTICE OF DISCLAIMER
2 The material contained herein is not a license, either expressly or impliedly, to any IPR owned or controlled
3 by any of the authors or developers of this material or MIPI. The material contained herein is provided on
4 an AS IS basis and to the maximum extent permitted by applicable law, this material is provided AS IS
5 AND WITH ALL FAULTS, and the authors and developers of this material and MIPI hereby disclaim all
6 other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if
7 any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of
8 accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of
9 negligence.
10 All materials contained herein are protected by copyright laws, and may not be reproduced, republished,
11 distributed, transmitted, displayed, broadcast or otherwise exploited in any manner without the express
12 prior written permission of MIPI Alliance. MIPI, MIPI Alliance and the dotted rainbow arch and all related
13 trademarks, tradenames, and other intellectual property are the exclusive property of MIPI Alliance and
14 cannot be used without its express prior written permission.
15 ALSO, THERE IS NO WARRANTY OF CONDITION OF TITLE, QUIET ENJOYMENT, QUIET

16 POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD
17 TO THIS MATERIAL OR THE CONTENTS OF THIS DOCUMENT. IN NO EVENT WILL ANY
18 AUTHOR OR DEVELOPER OF THIS MATERIAL OR THE CONTENTS OF THIS DOCUMENT OR
19 MIPI BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE
20 GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL,
21 CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER
22 CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR
23 ANY OTHER AGREEMENT, SPECIFICATION OR DOCUMENT RELATING TO THIS MATERIAL,
24 WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH
25 DAMAGES.
26 Without limiting the generality of this Disclaimer stated above, the user of the contents of this Document is
27 further notified that MIPI: (a) does not evaluate, test or verify the accuracy, soundness or credibility of the
28 contents of this Document; (b) does not monitor or enforce compliance with the contents of this Document;
29 and (c) does not certify, test, or in any manner investigate products or services or any claims of compliance
30 with the contents of this Document. The use or implementation of the contents of this Document may
31 involve or require the use of intellectual property rights ("IPR") including (but not limited to) patents,
32 patent applications, or copyrights owned by one or more parties, whether or not Members of MIPI. MIPI
33 does not make any search or investigation for IPR, nor does MIPI require or request the disclosure of any
34 IPR or claims of IPR as respects the contents of this Document or otherwise.
35 Questions pertaining to this document, or the terms or conditions of its provision, should be addressed to:
36 MIPI Alliance, Inc.

37 c/o IEEE-ISTO
38 445 Hoes Lane
39 Piscataway, NJ 08854
40 Attn: Board Secretary
41

ii
42 Contents
43 Version 1.01.01 14 July 2008 ........................................................................................................................i
44 1 Introduction ........................................................................................................................................... 21
45 1.1 Scope ............................................................................................................................................. 21
46 1.2 Purpose .......................................................................................................................................... 21
47 1.3 Summary of SLIMbus Features ..................................................................................................... 22
48 2 Terminology .......................................................................................................................................... 23
49 2.1 Definitions ..................................................................................................................................... 23
50 2.2 Abbreviations ................................................................................................................................ 27
51 2.3 Acronyms ...................................................................................................................................... 27
52 3 References ............................................................................................................................................. 29
53 4 The SLIMbus Model ............................................................................................................................. 30
54 4.1 Device Communication ................................................................................................................. 30
55 4.2 Bus Organization ........................................................................................................................... 31
56 4.2.1 Control Space ........................................................................................................................ 31
57 4.2.2 Data Space ............................................................................................................................. 31
58 4.3 Devices .......................................................................................................................................... 31
59 4.3.1 Device Classes ....................................................................................................................... 32
60 4.4 Components ................................................................................................................................... 33
61 4.4.1 Simple Component Example ................................................................................................. 33
62 4.4.2 Complex Component Example .............................................................................................. 33
63 4.4.3 Component Requirements ..................................................................................................... 34
64 4.5 Channels ........................................................................................................................................ 34
65 4.5.1 Data Channels ........................................................................................................................ 34
66 4.5.2 Control Space Channels......................................................................................................... 35
67 4.6 Frame Layer................................................................................................................................... 35
68 4.7 Physical Layer ............................................................................................................................... 35

iii
69 4.8 System Example ............................................................................................................................ 35
70 5 Physical Layer ....................................................................................................................................... 37
71 5.1 Physical Medium Independent Signaling and Logic Types........................................................... 38
72 5.1.1 Collision Detection ................................................................................................................ 40
73 5.2 Physical Medium Dependent Specifications ................................................................................. 40
74 5.2.1 Signaling Voltages ................................................................................................................. 40
75 5.2.2 CLK Terminal Output Specifications .................................................................................... 41
76 5.2.3 CLK Terminal Input Specifications ....................................................................................... 43
77 5.2.4 DATA Terminal .................................................................................................................... 44
78 5.2.5 Bus Holder Specifications ..................................................................................................... 45
79 5.2.6 Component Power Down on an Active Bus .......................................................................... 46
80 5.2.7 System Timing Budget (informative) .................................................................................... 46
81 6 Frame Structure ..................................................................................................................................... 52
82 6.1 Cells, Slots, Subframes, Frames, and Superframes ....................................................................... 52
83 6.1.1 Cell ........................................................................................................................................ 52
84 6.1.2 Slot......................................................................................................................................... 52
85 6.1.3 Subframe................................................................................................................................ 52
86 6.1.4 Frame ..................................................................................................................................... 52
87 6.1.5 Superframe ............................................................................................................................ 53
88 6.1.6 Relationship of Frame Structure Constructs .......................................................................... 53
89 6.1.7 Integrating the Concepts (informative) .................................................................................. 54
90 6.2 Clock Gears, Frequencies, and Root Superframes......................................................................... 55
91 6.2.1 Clock Gears ........................................................................................................................... 56
92 6.2.2 Clock Gear Example (informative)........................................................................................ 56
93 6.2.3 Root Frequency...................................................................................................................... 56
94 6.2.4 Root Superframes .................................................................................................................. 56
95 6.2.5 Natural Frequencies ............................................................................................................... 57
96 6.2.6 Cardinal Frequencies ............................................................................................................. 58

iv
97 6.3 Control Space ................................................................................................................................ 58
98 6.3.1 Framing Channel ................................................................................................................... 59
99 6.3.2 Guide Channel ....................................................................................................................... 68
100 6.3.3 Message Channel ................................................................................................................... 68
101 6.4 Data Space ..................................................................................................................................... 69
102 6.4.1 Segment Organization ........................................................................................................... 69
103 6.4.2 Data Channel Properties ........................................................................................................ 70
104 6.4.3 Data Channel Definition Example (informative) ................................................................... 71
105 6.4.4 Segment Timing Model ......................................................................................................... 73
106 7 Information Elements and Value Elements ........................................................................................... 76
107 7.1 Information Elements .................................................................................................................... 76
108 7.1.1 Types of Information Elements ............................................................................................. 78
109 7.1.2 Core Information Elements.................................................................................................... 78
110 7.1.3 Reporting Core Information .................................................................................................. 80
111 7.2 Value Elements .............................................................................................................................. 81
112 8 Message Protocol and Tracking............................................................................................................. 82
113 8.1 Guide Channel ............................................................................................................................... 83
114 8.1.1 The Guide Integrity Field ...................................................................................................... 84
115 8.1.2 The ENT Bit .......................................................................................................................... 84
116 8.1.3 The Guide Value Field........................................................................................................... 84
117 8.1.4 Guide Byte Corner Cases....................................................................................................... 84
118 8.2 Message Syntax ............................................................................................................................. 85
119 8.2.1 Arbitration Field .................................................................................................................... 86
120 8.2.2 Header Field .......................................................................................................................... 88
121 8.2.3 Message Payload Field .......................................................................................................... 90
122 8.2.4 Message Integrity and Response Field .................................................................................. 90
123 8.2.5 Addressing ............................................................................................................................. 92
124 8.3 Message Synchronization and Tracking ........................................................................................ 93

v
125 8.3.1 Message Synchronization Acquisition................................................................................... 93
126 8.3.2 Message Tracking .................................................................................................................. 94
127 8.3.3 Message Synchronization Maintenance................................................................................. 94
128 8.3.4 Message Synchronization Loss.............................................................................................. 95
129 8.4 Message Protocol........................................................................................................................... 95
130 8.4.1 Message Transmission ........................................................................................................... 95
131 8.4.2 Message Reception ................................................................................................................ 96
132 9 Transport Protocols ............................................................................................................................. 100
133 9.1 Data Channels and Flow Control ................................................................................................. 100
134 9.2 Channel Taxonomy...................................................................................................................... 100
135 9.2.1 Absence of Flow Control ..................................................................................................... 100
136 9.2.2 Single-ended Flow Control .................................................................................................. 100
137 9.2.3 Double-ended Flow Control ................................................................................................ 101
138 9.3 Transport Protocols...................................................................................................................... 101
139 9.3.1 Isochronous Protocol ........................................................................................................... 102
140 9.3.2 Pushed Protocol ................................................................................................................... 102
141 9.3.3 Pulled Protocol .................................................................................................................... 104
142 9.3.4 Locked Protocol ................................................................................................................... 105
143 9.3.5 Asynchronous Protocol........................................................................................................ 108
144 9.3.6 Extended Asynchronous Protocol ........................................................................................ 113
145 9.3.7 User Defined Protocol ......................................................................................................... 116
146 9.4 Auxiliary Bits Format .................................................................................................................. 116
147 9.4.1 SPDIF Tunneling ................................................................................................................. 116
148 9.4.2 User-Defined AUX Field ..................................................................................................... 117
149 9.4.3 AUX Field Format ID.......................................................................................................... 117
150 9.5 Data Type Field ........................................................................................................................... 118
151 9.6 Presence Rate............................................................................................................................... 119
152 9.7 DATA Field Length..................................................................................................................... 120

vi
153 10 Bus Processes .................................................................................................................................. 121
154 10.1 Boot and Synchronization Processes ........................................................................................... 121
155 10.1.1 Active Framer Boot Sequence ............................................................................................. 122
156 10.1.2 Component Synchronization Clock Receiver ................................................................... 124
157 10.1.3 Component Synchronization Clock Source ...................................................................... 127
158 10.1.4 Example of the Boot and Synchronization Processes (informative) .................................... 128
159 10.2 Error Handling ............................................................................................................................. 128
160 10.2.1 Transmission Errors ............................................................................................................. 128
161 10.2.2 Behavior on Collisions within Segments ............................................................................. 129
162 10.2.3 Behavior on Collisions within the Message Channel .......................................................... 129
163 10.2.4 Framing Errors..................................................................................................................... 129
164 10.2.5 Messaging Errors ................................................................................................................. 129
165 10.2.6 Reporting Core Information ................................................................................................ 130
166 10.3 Bus Management ......................................................................................................................... 130
167 10.3.1 General Behavior ................................................................................................................. 130
168 10.3.2 Pausing and Restarting the Bus Clock ................................................................................. 134
169 10.3.3 Bus Shutdown ...................................................................................................................... 136
170 10.4 Reset Hierarchy ........................................................................................................................... 136
171 10.4.1 Bus Reset ............................................................................................................................. 137
172 10.4.2 Component Reset ................................................................................................................. 138
173 10.4.3 Device Reset ........................................................................................................................ 138
174 10.4.4 Resetting a Port .................................................................................................................... 138
175 10.5 Clock Gear Changes .................................................................................................................... 139
176 10.5.1 Behavior of Channels during a Clock Gear Change ............................................................ 139
177 10.6 Subframe Mode Change .............................................................................................................. 141
178 10.6.1 Behavior of Channels during a Change of Subframe Length .............................................. 142
179 10.7 Root Frequency Change .............................................................................................................. 142
180 10.7.1 Behavior of Channels during a Root Frequency Change ..................................................... 143

vii
181 10.8 Framer Handover ......................................................................................................................... 144
182 10.8.1 Releasing the Active Framer Role ....................................................................................... 144
183 10.8.2 Obtaining the Active Framer Role ....................................................................................... 145
184 10.8.3 Error Cases .......................................................................................................................... 145
185 10.9 Device Discovery ........................................................................................................................ 145
186 10.9.1 Behavior of Devices other than the Active Manager ........................................................... 145
187 10.9.2 Active Manager Behavior .................................................................................................... 147
188 10.10 Assigning and Changing a Device Address ............................................................................. 148
189 10.11 Changing the Device Arbitration Priority ................................................................................ 149
190 10.12 Information Requests and Value Requests .............................................................................. 149
191 10.12.1 Behavior of the Transaction Initiator ............................................................................... 150
192 10.12.2 Behavior of the Transaction Target ................................................................................. 150
193 10.12.3 Atomic Transactions ........................................................................................................ 151
194 10.13 Channel Management .............................................................................................................. 151
195 10.13.1 Initializing a Data Transport ............................................................................................ 151
196 10.13.2 Disconnecting Ports ......................................................................................................... 155
197 10.13.3 Pausing a Data Channel ................................................................................................... 155
198 10.13.4 Cancelling a Data Channel .............................................................................................. 156
199 10.13.5 Changing Content Definitions ......................................................................................... 156
200 10.13.6 Moving a Data Channel ................................................................................................... 156
201 11 Core Messages ................................................................................................................................. 157
202 11.1 Device Management Messages.................................................................................................... 158
203 11.1.1 REPORT_PRESENT (DC, DCV) ....................................................................................... 158
204 11.1.2 ASSIGN_LOGICAL_ADDRESS (LA) .............................................................................. 159
205 11.1.3 RESET_DEVICE () ............................................................................................................. 159
206 11.1.4 CHANGE_LOGICAL_ADDRESS (LA) ............................................................................ 159
207 11.1.5 CHANGE_ARBITRATION_PRIORITY (AP)................................................................... 160
208 11.1.6 REQUEST_SELF_ANNOUNCEMENT () ......................................................................... 160

viii
209 11.1.7 REPORT_ABSENT () ......................................................................................................... 161
210 11.2 Data Channel Management Messages ......................................................................................... 161
211 11.2.1 CONNECT_SOURCE (PN, CN) ........................................................................................ 161
212 11.2.2 CONNECT_SINK (PN, CN) ............................................................................................... 162
213 11.2.3 DISCONNECT_PORT (PN) ............................................................................................... 162
214 11.2.4 CHANGE_CONTENT (CN, FL, PR, AF, DT, CL, DL) ..................................................... 162
215 11.3 Information Management Messages ............................................................................................ 163
216 11.3.1 REQUEST_INFORMATION (TID, EC) ............................................................................ 163
217 11.3.2 REQUEST_CLEAR_INFORMATION (TID, EC, CM) ..................................................... 164
218 11.3.3 REPLY_INFORMATION (TID, IS) ................................................................................... 165
219 11.3.4 CLEAR_INFORMATION (EC, CM) ................................................................................. 165
220 11.3.5 REPORT_INFORMATION (EC, IS) .................................................................................. 166
221 11.4 Reconfiguration Messages ........................................................................................................... 167
222 11.4.1 BEGIN_RECONFIGURATION ()...................................................................................... 167
223 11.4.2 NEXT_ACTIVE_FRAMER (LAIF, NCo, NCi) ................................................................. 167
224 11.4.3 NEXT_SUBFRAME_MODE (SM) .................................................................................... 168
225 11.4.4 NEXT_CLOCK_GEAR (CG) ............................................................................................. 168
226 11.4.5 NEXT_ROOT_FREQUENCY (RF) ................................................................................... 169
227 11.4.6 NEXT_PAUSE_CLOCK (RT) ............................................................................................ 169
228 11.4.7 NEXT_RESET_BUS () ....................................................................................................... 170
229 11.4.8 NEXT_SHUTDOWN_BUS () ............................................................................................ 171
230 11.4.9 NEXT_DEFINE_CHANNEL (CN, TP, SD, SL) ................................................................ 171
231 11.4.10 NEXT_DEFINE_CONTENT (CN, FL, PR, AF, DT, CL, DL)....................................... 172
232 11.4.11 NEXT_ACTIVATE_CHANNEL (CN)........................................................................... 173
233 11.4.12 NEXT_DEACTIVATE_CHANNEL (CN) ..................................................................... 173
234 11.4.13 NEXT_REMOVE_CHANNEL (CN).............................................................................. 173
235 11.4.14 RECONFIGURE_NOW () .............................................................................................. 174
236 11.5 Value Management Messages ..................................................................................................... 174

ix
237 11.5.1 REQUEST_VALUE (TID, EC) .......................................................................................... 174
238 11.5.2 REQUEST_CHANGE_VALUE (TID, EC, VU) ................................................................ 175
239 11.5.3 REPLY_VALUE (TID, VS) ................................................................................................ 176
240 11.5.4 CHANGE_VALUE (EC, VU)............................................................................................. 176
241 11.6 Core Message Range Checking ................................................................................................... 177
242 11.6.1 Core Message Sequence Checks.......................................................................................... 177
243 11.6.2 Core Message Parameter Checks......................................................................................... 177
244 12 Device Classes ................................................................................................................................. 179
245 12.1 Device Class-independent Requirements .................................................................................... 179
246 12.2 Interface Device Class ................................................................................................................. 181
247 12.2.1 Port and Transport Protocol Support ................................................................................... 181
248 12.2.2 Interface Device Core Message Support.............................................................................. 182
249 12.2.3 Interface Device Core Information Element Support .......................................................... 183
250 12.2.4 Interface Device Class-specific Messages ........................................................................... 183
251 12.2.5 Interface Device Class-specific Information Elements ........................................................ 183
252 12.2.6 Reporting Class-specific Information .................................................................................. 185
253 12.2.7 Interface Device Class-specific Value Elements ................................................................. 186
254 12.2.8 Boot Requirements .............................................................................................................. 186
255 12.2.9 Bus Reset Requirements ...................................................................................................... 186
256 12.2.10 Device Reset Requirements ............................................................................................. 186
257 12.2.11 Component Reset Requirements...................................................................................... 186
258 12.2.12 Additional Requirements ................................................................................................. 186
259 12.3 Manager Device Class ................................................................................................................. 187
261 12.3.2 Manager Core Message Support .......................................................................................... 187
262 12.3.3 Manager Core Information Element Support ...................................................................... 189
263 12.3.4 Manager Class-specific Messages ....................................................................................... 189
264 12.3.5 Manager Class-specific Information Elements .................................................................... 189

x
266 12.3.7 Manager Class-specific Value Elements ............................................................................. 190
272 12.4 Framer Device Class .................................................................................................................... 191
274 12.4.2 Framer Core Message Support ............................................................................................ 191
275 12.4.3 Framer Core Information Element Support ......................................................................... 192
276 12.4.4 Framer Class-specific Messages .......................................................................................... 192
277 12.4.5 Framer Class-specific Information Elements....................................................................... 193
279 12.4.7 Framer Class-specific Value Elements ................................................................................ 195
285 12.5 Generic Device Class................................................................................................................... 196
287 12.5.2 Generic Device Core Message Support ............................................................................... 196
288 12.5.3 Generic Device Core Information Element Support ............................................................ 198
289 12.5.4 Generic Device Class-specific Messages............................................................................. 198
290 12.5.5 Generic Device Class-specific Information Elements ......................................................... 198
292 12.5.7 Generic Device Class-specific Value Elements ................................................................... 198

xi
298 Annex A Usage Examples (informative) ..................................................................................................... 200
299 A.1 Assumed Pre-conditions .............................................................................................................. 200
300 A.2 Use Cases .................................................................................................................................... 200
301 A.2.1 Use Case 1 Voice Call, Handset ....................................................................................... 200
302 A.2.2 Use Case 2 Voice Call, Handheld Hands Free.................................................................. 202
303 A.2.3 Use Case 3 Voice Call, Bluetooth Headset .................................................................... 202
304 A.2.4 Use Case 4 Music Playback, Built-in Stereo Speakers ..................................................... 204
305 A.2.5 Use Case 5 Ring Signal and Voice Answer ...................................................................... 205
306 Annex B Physical Layer Implementation Notes (informative) ................................................................... 207
307 B.1 Why Does SLIMbusSM Require a Dedicated Physical Layer?..................................................... 207
308 B.2 Typical System Power Budget..................................................................................................... 207
309 B.3 Example Slew Rate Control Circuits ........................................................................................... 208
310 B.3.1 Nested Miller AC Feedback Driver ..................................................................................... 208
311 B.3.2 Gradual Turn-On Driver ...................................................................................................... 208
312 B.3.3 Transition Time Locked Driver ........................................................................................... 210
313 B.4 Notes on Implementing SLIMbus using CMOS IOs ................................................................... 210
314 Annex C Natural Frequencies (informative) ............................................................................................... 213
315 Annex D Determining NCo and NCi (informative) ..................................................................................... 216
316 D.1 Fi > Fo ......................................................................................................................................... 217
317 D.2 Fi < Fo ......................................................................................................................................... 218
318
319

xii
320 Figures
321 Figure 1 SLIMbus System View .................................................................................................................. 30
322 Figure 2 Simple SLIMbus Component Example .......................................................................................... 33
323 Figure 3 Complex SLIMbus Component Example ...................................................................................... 34
324 Figure 4 System Example ............................................................................................................................. 36
325 Figure 5 Conceptual IO Configurations for Components on SLIMbus ........................................................ 37
326 Figure 6 DATA Terminal Bus Holder Examples ......................................................................................... 38
327 Figure 7 Output Driver is Disabled while CLK is Low ................................................................................ 38
328 Figure 8 NRZI Signaling Example ............................................................................................................... 39
329 Figure 9 Logical-OR NRZI Signaling Example ........................................................................................... 39
330 Figure 10 Recommended Clock Driver Implementation .............................................................................. 42
331 Figure 11 Clock Driver Output Waveform Constraints................................................................................ 42
332 Figure 12 Received Clock Signal Constraints .............................................................................................. 43
333 Figure 13 Bus Holder I/V Mask ................................................................................................................... 46
334 Figure 14 TSKEW Specification ...................................................................................................................... 47
335 Figure 15 TCLKISLEW Specification ................................................................................................................ 47
336 Figure 16 TCLKUNCERT Specification .............................................................................................................. 48
337 Figure 17 Data Transmit Timing Constraints ............................................................................................... 49
338 Figure 18 Overview of the SLIMbus TDM Scheme .................................................................................... 55
339 Figure 19 Clock Gear Example .................................................................................................................... 56
340 Figure 20 Root Superframe Example ........................................................................................................... 57
341 Figure 21 Natural Frequency Example ......................................................................................................... 58
342 Figure 22 Example Organization of Control and Data Space Slots.............................................................. 59
343 Figure 23 Overlap between Various Subframes ........................................................................................... 60
344 Figure 24 Distribution of Framing Information over Multiple Slots ............................................................ 60
345 Figure 25 Phasing Signal Contents ............................................................................................................... 66
346 Figure 26 Phase Snapshot Example.............................................................................................................. 67

xiii
347 Figure 27 Segment Organization .................................................................................................................. 69
348 Figure 28 Data Channel Organization Example ........................................................................................... 72
349 Figure 29 Segment Windows and Segment Window Boundaries Example ................................................. 74
350 Figure 30 Information Map .......................................................................................................................... 76
351 Figure 31 Element Code for Byte-based Access .......................................................................................... 77
352 Figure 32 Element Code for Elemental Access ............................................................................................ 77
353 Figure 33 Value Map .................................................................................................................................... 81
354 Figure 34 Message Channel and Guide Channel Overview ......................................................................... 83
355 Figure 35 ENT Bit ........................................................................................................................................ 84
356 Figure 36 Message Fields ............................................................................................................................. 85
357 Figure 37 CRC Coverage ............................................................................................................................. 91
358 Figure 38 CRC Engine ................................................................................................................................. 91
359 Figure 39 Message Synchronization State Diagram ..................................................................................... 94
360 Figure 40 Basic Message Parsing Diagram .................................................................................................. 97
361 Figure 41 Isochronous Protocol Segment Organization ..............................................................................102
362 Figure 42 Pushed Protocol Segment Organization ......................................................................................102
363 Figure 43 Pulled Protocol Segment Organization .......................................................................................104
364 Figure 44 Locked Protocol Segment Organization......................................................................................106
365 Figure 45 Segment Window PHASES and SPAN ......................................................................................106
366 Figure 46 VP Evaluation Example, 44.1k Flows.........................................................................................107
367 Figure 47 VP Evaluation Example, 16k Flows ...........................................................................................107
368 Figure 48 Asynchronous Protocol Segment Organization...........................................................................108
369 Figure 49 Asynchronous Half-duplex Protocol State Diagram ...................................................................109
370 Figure 50 Extended Asynchronous Protocol Segment Organization...........................................................114
371 Figure 51 SPDIF Sub-frame Format ...........................................................................................................116
372 Figure 52 SPDIF Block Structure ................................................................................................................116
373 Figure 53 Message Sequence Example .......................................................................................................121
374 Figure 54 Split Transaction Example ..........................................................................................................121

xiv
375 Figure 55 Boot Process for the Active Framer ............................................................................................122
376 Figure 56 Example CLK and DATA Line Behavior during Boot ...............................................................124
377 Figure 57 Component Synchronization Process ..........................................................................................125
378 Figure 58 Typical SLIMbus Boot Behavior ................................................................................................128
379 Figure 59 Example Bus Management Sequence .........................................................................................131
380 Figure 60 RECONFIGURE_NOW Message Timing ..................................................................................132
381 Figure 61 Using RECONFIGURE_NOW to Switch between Operating Mode .........................................132
382 Figure 62 Loss of Superframe Synchronization after RECONFIGURE_NOW Message ...........................133
383 Figure 63 Verification of Reconfiguration Message Example ....................................................................134
384 Figure 64 Physical Layer Behavior during a Clock Pause ..........................................................................134
385 Figure 65 Restart of a Paused Bus Clock ....................................................................................................135
386 Figure 66 Clock Pause Announcement........................................................................................................136
387 Figure 67 Shutdown Announcement ...........................................................................................................136
388 Figure 68 Active Framer Reset State Diagram ............................................................................................137
389 Figure 69 Clock Gear Change Announcement ............................................................................................139
390 Figure 70 First 96 Slots of a Superframe in Gear 6 .....................................................................................140
391 Figure 71 Full Frame in Gear 7 ...................................................................................................................141
392 Figure 72 Two Frames in Gear 8 .................................................................................................................141
393 Figure 73 Changing the Message Channel Characteristics..........................................................................142
394 Figure 74 Root Frequency Change Announcement .....................................................................................143
395 Figure 75 Framer Handover State Diagram.................................................................................................144
396 Figure 76 Bus Behavior for Framer Handover ............................................................................................145
397 Figure 77 Device Enumeration State Diagram ............................................................................................146
398 Figure 78 REQUEST-REPLY Example ......................................................................................................150
399 Figure 79 Example Transport Setup ............................................................................................................152
400 Figure 80 Port State Diagram ......................................................................................................................153
401 Figure 81 Move Channel Example ..............................................................................................................156
402 Figure 82 Use Case 1 ...................................................................................................................................200

xv
403 Figure 83 Use Case 2, Hands Free ..............................................................................................................202
404 Figure 84 Use Case 3, Bluetooth .................................................................................................................202
405 Figure 85 Use Case 4, Built-in Speakers .....................................................................................................204
406 Figure 86 Use Case 5, Ring Signal ..............................................................................................................205
407 Figure 87 System Topology of an Example Handset Implementing SLIMbus ...........................................207
408 Figure 88 Using AC Feedback in a CMOS Output Driver ..........................................................................208
409 Figure 89 GTO Driver Topology.................................................................................................................209
410 Figure 90 Response of GTO Driver into a Lumped Load ...........................................................................209
411 Figure 91 Transition Time Locked Driver Example ...................................................................................210
412 Figure 92 SLIMbus IO Examples using Traditional CMOS IO Driver Topologies ....................................211
413 Figure 93 Minimal Wait Time and Maximal Overlap Period......................................................................216
414 Figure 94 Maximal Wait Time and Minimal Overlap Period......................................................................217
415 Figure 95 Determining NCi .........................................................................................................................218
416 Figure 96 Determining NCo ........................................................................................................................218
417
418

xvi
419 Tables
420 Table 1 Parameters for Components using 1.8V Signaling .......................................................................... 40
421 Table 2 Static Electrical Characteristics for 1.8V Signaling ........................................................................ 40
422 Table 3 Parameters for Components using 1.2V Signaling .......................................................................... 41
423 Table 4 Static Electrical Characteristics for 1.2V Signaling ........................................................................ 41
424 Table 5 Clock Output Timing Characteristics .............................................................................................. 42
425 Table 6 Clock Input Timing Requirements .................................................................................................. 43
426 Table 7 Clock Input Electrical Characteristics ............................................................................................. 43
427 Table 8 DATA Output Electrical Characteristics ......................................................................................... 44
428 Table 9 DATA Output Timing Characteristics............................................................................................. 44
429 Table 10 DATA Input Timing Requirements ............................................................................................... 44
430 Table 11 Driver Disable Timing Specification ............................................................................................. 45
431 Table 12 Bus Holder Electrical Specification............................................................................................... 45
432 Table 13 Input Leakage Constraints ............................................................................................................. 46
433 Table 14 Relationship of the number of Cells, Slots, Subframes, Frames, Superframes ............................. 53
434 Table 15 Subframe Coding ........................................................................................................................... 62
435 Table 16 SLIMbus Frequencies and Clock Gear Coding ............................................................................. 63
436 Table 17 Root Frequency ............................................................................................................................. 64
437 Table 18 Guide Channel Slots ...................................................................................................................... 68
438 Table 19 Segment Lengths ........................................................................................................................... 70
439 Table 20 Segment Distributions ................................................................................................................... 71
440 Table 21 Slice Size ....................................................................................................................................... 77
441 Table 22 Core Information Elements ........................................................................................................... 78
442 Table 23 Guide Byte ..................................................................................................................................... 83
443 Table 24 Message Field Overview ............................................................................................................... 85
444 Table 25 Arbitration Field Overview ........................................................................................................... 86
445 Table 26 Short Arbitration Field Composition ............................................................................................. 86

xvii
446 Table 27 Long Arbitration Field Composition ............................................................................................. 86
447 Table 28 Arbitration Types .......................................................................................................................... 87
448 Table 29 Arbitration Extension .................................................................................................................... 87
449 Table 30 Arbitration Priority Codes ............................................................................................................. 87
450 Table 31 Header Fields ................................................................................................................................. 88
451 Table 32 Message Types .............................................................................................................................. 88
452 Table 33 Destination Types .......................................................................................................................... 89
453 Table 34 Broadcast Header Format .............................................................................................................. 89
454 Table 35 Short Header Format with a Logical Address ............................................................................... 89
455 Table 36 Long Header Format with an Enumeration Address ..................................................................... 90
456 Table 37 Message Payload Format ............................................................................................................... 90
457 Table 38 Message Integrity and Response Field .......................................................................................... 90
458 Table 39 Integrity and Response Field ......................................................................................................... 91
459 Table 40 Message Response Codes .............................................................................................................. 92
460 Table 41 Enumeration Address Fields.......................................................................................................... 92
461 Table 42 Logical Address Values ................................................................................................................. 93
462 Table 43 Message Response Interpretation .................................................................................................. 95
463 Table 44 Message Response Writing Rules ................................................................................................. 99
464 Table 45 Message Response Reading Rules for Destination Devices .......................................................... 99
465 Table 46 Message Response Reading Rules for Non-destination Devices................................................... 99
466 Table 47 Transport Protocol Overview .......................................................................................................101
467 Table 48 TAG Semantics for the Pushed Protocol ......................................................................................103
468 Table 49 Example TAG Slot Values for a Pushed Channel ........................................................................104
469 Table 50 TAG Semantics for Pulled Protocol .............................................................................................104
470 Table 51 Example TAG Sequence for the Pulled Protocol .........................................................................105
471 Table 52 TAG Semantics for the Asynchronous Protocol...........................................................................108
472 Table 53 Flow Control Conditions ..............................................................................................................110
473 Table 54 Example TAG Slot Sequence for Channel Ownership .................................................................111

xviii
474 Table 55 Example TAG Slot Sequence for Flow Control and Data Transfer .............................................112
475 Table 56 TAG field Slot Layout for the Extended Asynchronous Protocol ................................................114
476 Table 57 Example TAG Slot Sequence for the Extended Asynchronous Protocol .....................................115
477 Table 58 AUX Bit Definition for IEC60958 ...............................................................................................117
478 Table 59 AUX Field Format ID ..................................................................................................................117
479 Table 60 Data Types....................................................................................................................................118
480 Table 61 LPCM Audio Number Format Comparison .................................................................................118
481 Table 62 Presence Rate ...............................................................................................................................119
482 Table 63 DATA Field Length .....................................................................................................................120
483 Table 64 Channel Configuration Messages .................................................................................................154
484 Table 65 Core Message Codes ....................................................................................................................157
485 Table 66 NEXT_PAUSE_CLOCK Payload Value .....................................................................................170
486 Table 67 Interface Device Core Message Support ......................................................................................182
487 Table 68 Interface Device Core Information Element Support ...................................................................183
488 Table 69 Interface Device Class-specific Information Elements.................................................................184
489 Table 70 Manager Core Message Support...................................................................................................187
490 Table 71 Manager Core Information Element Support ...............................................................................189
491 Table 72 Manager Class-specific Information Elements .............................................................................189
492 Table 73 Framer Core Message Support .....................................................................................................191
493 Table 74 Framer Core Information Element Support ..................................................................................192
494 Table 75 Framer Class-specific Information Elements ...............................................................................193
495 Table 76 QUALITY Information Element ..................................................................................................193
496 Table 77 Generic Device Core Message Support ........................................................................................196
497 Table 78 Generic Device Core Information Element Support.....................................................................198
498 Table 79 Use Case 1 and 2 Configuration ...................................................................................................201
499 Table 80 Use Case 1 and 2 Slot Layout ....................................................................................................201
500 Table 81 Use Case 3 Configuration .............................................................................................................203
501 Table 82 Use Case 3 Slot Layout .............................................................................................................203

xix
503 Table 84 Use Case 4 Slot Layout .............................................................................................................205
505 Table 86 Use Case 5 -- Slot Layout .............................................................................................................206
506 Table 87 Natural Frequencies for 4k Family of Flows ................................................................................213
507 Table 88 Natural Frequencies for 11.025k Family of Flows .......................................................................214
508 Table 89 Natural Frequencies for 12k Family of Flows ..............................................................................215
509

xx
510 MIPI Alliance Specification for SLIMbusSM
511 1 Introduction
512 Demand for multimedia functions within mobile terminals is increasing. A key driver for unit growth and
513 product differentiation is digital audio.
514 Commonly used digital audio interfaces in mobile terminals such as I2S and PCM are generally intended
515 for point-to-point connection between an application processor and a single digital audio device. Typically,
516 these interfaces only support one or two digital audio channels. As such, adding functions and digital audio
517 channels to mobile terminals beyond those for voice communication and simple stereo music applications
518 is very difficult without increasing the number of bus structures in the mobile terminal. Though scalable,
519 just adding bus structures limits design flexibility and is costly in terms of pin count, package size, PCB
520 layout area and power consumption.
521 In addition, numerous control bus structures such as I2C, SPI, microWire, UART and GPIOs, typically
522 reside in parallel to audio buses not only for audio device control, but handling the countless low
523 bandwidth control tasks required for lighting, haptic feedback, temperature monitoring and power
524 sequencing.
525 SLIMbusSM provides the mobile terminal industry a standard, robust, scalable, low-power, high-speed,
526 cost-effective, two wire multi-drop interface that supports a wide range of digital audio and control
527 solutions for mobile terminals.
528 SLIMbus effectively replaces many other digital audio buses such as PCM and I2S, as well as control buses
529 such as I2C, SPI, or UART, in a mobile terminal by providing flexible and dynamic assignment of bus
530 bandwidth between digital audio and non-audio control and data functions.
531 SLIMbus is not backward compatible with any current digital audio bus or digital control bus.
532 1.1 Scope
533 SLIMbus interface protocols and commands are within the scope of this specification.
534 Electrical specifications at the physical terminals of SLIMbus Devices, as well as a description of signal
535 timing relationships, are also within the scope of this specification.
536 Implementation details of the SLIMbus interface within an electronic device are not within the scope of this
537 document.
538 1.2 Purpose
539 The purpose of this document is to specify a standard interface between baseband or application processors
540 and peripheral components.
541 Implementing the SLIMbus Specification greatly increases the flexibility for mobile terminal system
542 designers to realize multiple products within a product line quickly, each with widely varying digital audio
543 and user interface features, without the addition of multiple bus structures.
544 SLIMbus reduces the time-to-market and design cost of mobile terminals by simplifying the
545 interconnection of products from different manufacturers.

21
546 1.3 Summary of SLIMbus Features
547 A SLIMbus interface offers many benefits, including:

548 Audio, data, bus and Device control on a single bus
549 Reduced pin count for lower overall product cost
550 Support for more than ten Components at typical bus lengths and speeds
551 Support for multiple, high quality audio channels
552 Multiple, concurrent sample rates on a single bus
553 Efficient, host-less, peer-to-peer communication
554 Standardized Message set for improved software reuse and increased interoperability
555 Established framework for Device creation
556 Use of common digital audio clocks as well as established system clocks
557 Dynamic clock frequency changes for optimizing bus power consumption
558

22
559 2 Terminology
560 The MIPI Alliance has adopted section 13.1 of the IEEE Standards Style Manual, which dictates use of the
561 words shall, should, may, and can in the development of documentation, as follows:
562 The word shall is used to indicate mandatory requirements strictly to be followed in order
563 to conform to the standard and from which no deviation is permitted (shall equals is
564 required to).
565 The use of the word must is deprecated and shall not be used when stating mandatory
566 requirements; must is used only to describe unavoidable situations.
567 The use of the word will is deprecated and shall not be used when stating mandatory
568 requirements; will is only used in statements of fact.
569 The word should is used to indicate that among several possibilities one is recommended
570 as particularly suitable, without mentioning or excluding others; or that a certain course
571 of action is preferred but not necessarily required; or that (in the negative form) a certain
572 course of action is deprecated but not prohibited (should equals is recommended that).
573 The word may is used to indicate a course of action permissible within the limits of the
574 standard (may equals is permitted).
575 The word can is used for statements of possibility and capability, whether material,
576 physical, or causal (can equals is able to).
577 All sections are normative, unless they are explicitly indicated to be informative.
578 Numbers are decimal unless otherwise indicated. A prefix of 0x indicates a hexadecimal number, while a
579 prefix of 0b indicates a binary number.
580 This document uses the C/Verilog representation for operators where bitwise AND is represented by &,
581 bitwise OR is represented by |, bitwise XOR is represented by ^ and 1s complement (negation) is
582 represented by ~. The modulo operator is represented by %.
583 Throughout this document, the chronology for binary sequences and timing diagrams is from left (earlier in
584 time) to right (later in time), unless otherwise specified. In multi-row sequence diagrams, the chronology is
585 from upper rows (earlier in time) to lower rows (later in time), unless otherwise stated.
586 2.1 Definitions
587 Cardinal Frequency: A CLK frequency from the set 24.576 MHz, 12.288 MHz, 6.144 MHz etc. See
588 section 6.2.6 for more detail.
589 Cell: The smallest subdivision of the SLIMbus data stream is the Cell. A Cell is the region of the DATA
590 line signal that lies between two consecutive positive edges of the CLK.

23
591 Class-specific Message: A Message with a Message Code that is interpreted by a destination Device
592 according to the version of the Device Class of the source Device (Source-referred Messages) or to its own
593 version of its Device Class (Destination-referred Messages).
594 Clock Gear: Ten Clock Gears (CG) are defined that divide the Root Frequency by powers of two. For a
595 given Root Frequency, the Clock Gears provide a 512x range of frequencies for the SLIMbus CLK and can
596 help optimize power consumption and bandwidth.
597 Clock Sourcing Component: A Clock Sourcing Component is the Component that contains the active
598 Framer.
599 Clock Receiving Component: A Clock Receiving Component is a Component that does not contain the
600 active Framer.
601 Collision: A Collision occurs when a Device detects a value on the DATA line that differs from the value it
602 drove. Collisions cannot occur during normal operation of the bus. To detect error conditions, Devices
603 check for Collisions as described in section 5.1.1.
604 Component: A Component contains a set of Devices and the necessary logic needed to provide bus access
605 to these Devices. Each Component contains an Interface Device and typically contains one or more other
606 Devices.
607 Control Space: Control Space is a programmable portion of a Frame defined by the repetition of
608 Subframes within the Frame and by the Control Space width in the Subframes. See section 6.3.
609 Core Message: A Message with a Message Code that is interpreted in the same way by all Devices
610 regardless of Device Class. See section 11 for more information.
611 Data Channel: A portion of Data Space allocated for communication between a subset of the Devices on
612 the SLIMbus. See section 6.4.2.
613 Data Space: Data Space is a programmable portion of each Frame. If present, Data Space is interleaved
614 with Control Space at the Subframe level. Refer to sections 6.1, 6.2 and 6.4 for more information.
615 Device: A Device is a separately addressable entity within a SLIMbus Component. Each Device belongs to
616 a single Device Class and implements a single version of the corresponding Device Class definition. After
617 enumeration each Device is addressed with a single Logical Address.
618 Device Class: A Device Class is a set of behaviors, Messages, Transport Protocols and Information
619 Elements that define a specific type of Device. Device Classes are specified in section 12.
620 Device Class Version: A Device Class Version (DCV) is an 8-bit code used to identify the specific
621 implementation of Device Class for a particular Device.
622 Enumeration Address: An Enumeration Address is a 48-bit value that allows a Device to receive
623 Messages. An Enumeration Address is comprised of four fields: Manufacturer ID, Product Code, Device
624 Index and Instance Value. See section 8.2.5.1 for details.
625 Frame: A Frame is a group of 192 contiguous Slots (768 Cells). The first Slot of each Frame carries the
626 Frame Sync symbol. See section 6.1.4.
627 Framer: A Framer is a Device that can be the source of the SLIMbus clock (CLK), Framing Channel and
628 Guide Channel. There is one active Framer on an instance of SLIMbus at any one time. This document
629 allows for alternate Framers and defines the process for handover from one Framer to another.

24
630 Frame Structure: The Frame Structure is the organization of defined areas within the TDM stream that
631 allow for the transport of isochronous and packet data formats. See section 6 for a complete description.
632 Frame Sync symbol: The Frame Sync symbol is a fixed value (0b1011) in the first Slot of every Frame,
633 that a Component uses to achieve synchronization with the Frame Structure.
634 Framing Channel: A portion of Control Space allocated for the transmission of Frame Sync symbols and
635 Framing Information. The Framing Channel is written to the bus by the active Framer.
636 Framing Information: The Framing Information is a portion of the Framing Channel that contains
637 information on the Frame Structure organization and bus timing. Refer to section 6.3.1.1 for more
638 information.
639 Guide Channel: The Guide Channel provides the necessary information for Components to acquire and
640 verify Message synchronization in the Message Channel. It uses two Slots of Control Space, called the
641 Guide Byte, once every Superframe.
642 INT(): A mathematical function that returns the integer portion of a number. For example, INT(4.12)
643 returns 4.
644 Interface Device: Each Component contains one Interface Device. The Interface Device is responsible for
645 monitoring the Frame Layer and the Message Protocol, Component Reset, and status reporting.
646 Information Element. An Information Element is a specific piece of data that resides in a Device, and that
647 is made available to other Devices via Messages. Some Information Elements are common for all Devices
648 and are defined as Core IEs; others are specific to a Device Class or are user definable.
649 Logical Address: A Logical Address is an 8-bit number used to uniquely identify an enumerated Device
650 on the bus. See section 8.2.5.2.
651 Manager: A Manager is a Device that is responsible for bus configuration and Device management.
652 Although multiple Components on a single SLIMbus may include Managers, only a single Manager may
653 be active at any one time.
654 Message: A Message is an item that is sent from one Device to one or more other Devices through the
655 Message Channel. Some Messages are common for all Devices and are defined as Core Messages; others
656 are specific to a Device Class or are user definable.
657 Message Channel: The Message Channel is composed of Control Space Slots not allocated to the Framing
658 Channel or Guide Channel. It is used for bus configuration and Device management as well as general
659 purpose Device-to-Device Messaging.
660 Natural Frequency: A Natural Frequency describes a CLK line rate that is an exact multiple of a desired
661 audio sample rate. A Natural Frequency allows such flows to be conveyed without flow control
662 mechanisms. In addition, a Natural Frequency can also ease implementation by making the SLIMbus CLK
663 directly usable within a Component. See section 6.2.5 for a detailed explanation.
664 Phasing Signal: The Phasing Signal communicates an embedded 25 Hz timing reference. It is part of the
665 Framing Information. Consuming two Cells per Superframe, it transports one 14-bit value called a Phase
666 Snapshot every ten Superframes. See section 6.3.1.8.
667 Port: A Port is the part of a Device through which data flows to or from a single Data Channel. The Port
668 contains the necessary parameters, i.e. connection status, Channel Number, Transport Protocol used, and
669 the relevant Data Channel Parameters for a Device to connect to the Data Channel. Port parameters may be

25
670 fixed at design time or may be programmable. Ports are the only SLIMbus entities that are allowed to
671 access the Data Space. A Device may have more than one Port.
672 Reconfiguration Boundary: The Reconfiguration Boundary is the first Superframe boundary that comes
673 at least two Slots after the end of a RECONFIGURE_NOW Message.
674 Reconfiguration Message: A Reconfiguration Message is a Message that forms part of the
675 Reconfiguration Sequence. See section 11.4.
676 Reconfiguration Sequence: A sequence of Messages starting with BEGIN_RECONFIGURATION,

677 followed by a variable number of NEXT_ Messages and finished with a RECONFIGURE_NOW Message
678 is known as a Reconfiguration Sequence. This process provides the ability to change the bus organization
679 and CLK frequency without disrupting the contents of any Data Channels.
680 Root Frequency: The Root Frequency is the frequency of the SLIMbus CLK line in Gear 10. In lower
681 Clock Gears the CLK runs at the Root Frequency divided by 2(10-CG), where CG is the Clock Gear. The
682 Root Frequency establishes a basis for describing the SLIMbus CLK line frequency. In Gear 1 through
683 Gear 9, typical systems can generate the SLIMbus CLK without ever generating a signal at the Root
684 Frequency.
685 Root Superframe: Root Superframes are Clock Gear-independent divisions of the SLIMbus timeline.
686 They have the same frequency and phasing as the bus's Superframes in Gear 10. In lower Clock Gears,
687 each Superframe spans 2 (10-CG) Root Superframes, where CG is the Clock Gear. See section 6.2.4.
688 Segment: A Segment is a distinct group of contiguous Data Space Slots that have been allocated to the
689 same Data Channel.
690 Segment Distribution: The Segment Distribution (SD) defines the Segment Offset and the Segment
691 Interval and is used in the allocation of Data Space Slots to Data Channels See section 6.4.2.
692 Slot: A Slot is a group of four contiguous Cells. It is at the Slot level that the SLIMbus DATA signal is
693 time-division-multiplexed between different channels.
694 Subframe: A Subframe is the division of the Frame Structure at which Control Space and, if present, Data
695 Space are interleaved. The Subframe length can be 6, 8, 24, and 32 Slots (24, 32, 96, and 128 Cells).
696 Subframe Mode: The Subframe Mode (SM) is a binary code carried in the Framing Information that
697 indicates what Subframe length and Control Space width are being used.
698 Superframe: A Superframe is composed of eight consecutive Frames and contains a complete set of
699 Framing Information.
700 Transport Protocol: A Transport Protocol is an attribute of a Data Channel that describes how flow
701 control is accomplished. Several Transport Protocols are defined. Each Transport Protocol describes a set
702 of behaviors for a particular type of flow control.
703 User Message: A Message with a Message Code that is interpreted by a destination Device according to
704 the product documentation of the source Device (Source-referred Messages) or of the destination Device
705 (for Destination-referred Messages).
706 Whitening Signal: The Whitening Signal is part of the Framing Information and consumes one Cell per
707 Superframe. The Whitening Signal helps to keep the spectrum of the SLIMbus DATA signal benign,
708 improve analog performance and can ease system integration.

26
709 2.2 Abbreviations
710 e.g. For example (Latin: exempli gratia)
711 i.e. That is (Latin: id est)
712 2.3 Acronyms
713 AES Audio Engineering Society
714 AT Arbitration Type
715 CG Clock Gear
716 DC Device Class
717 DI Device Index
718 DT Destination Type
719 EA Enumeration Address
720 FE Framing Extension
721 IV Instance Value
722 ISTO Industry Standards and Technology Organization
723 LA Logical Address
724 LPCM Linear Pulse Code Modulation
725 LSB Least Significant Bit
726 MC Message Code
727 MI Manufacturer ID
728 MT Message Type
729 Mbps Megabits per second
730 MEMS Micro-Electro-Mechanical Structures
731 MIPI Mobile Industry Processor Interface
732 MSB Most Significant Bit
733 MT Message Type
734 NRZI Non-Return-to-Zero Inverted
735 PC Product Code

27
736 PDM Pulse Density Modulation
737 PI Primary Integrity
738 PS Phase Snapshot
739 RF Root Frequency
740 RL Remaining Length
741 SPDIF Sony / Philips Digital Interface
742 SLIMbusSM Serial Low-power Inter-chip Media Bus
743 SM Subframe Mode
744 TDM Time Division Multiplexed
745 TID Transaction ID

746

28
747 3 References
748 [AES01] AES-12id-2006, AES Information Document for digital audio measurements - Jitter
749 performance specifications, Audio Engineering Society, New York, NY, USA
750 [IEC01] IEC 60958, Digital audio interface, International Electrotechnical Commission, Geneva,
751 Switzerland.
752 [IEC02] IEC 61937, Digital audio - Interface for non-LPCM-encoded audio bitstreams applying
753 IEC 60958, International Electrotechnical Commission, Geneva, Switzerland.
754 [MIPI01] MIPI Alliance, MIPI Manufacturer IDs, Homepage, <https://www.mipi.org/>, October
755 2006
756
757

29
758 4 The SLIMbus Model

759 SLIMbus models a system as a set of Devices communicating over a shared bus. All transfers on the bus
760 are handled by predefined Transport Protocols optimized for specific data flows. These protocols include
761 several Transport Protocols designed to handle common flow types such as isochronous and asynchronous
762 streams as well as protocols to handle bus control and configuration traffic. In order to provide system
763 flexibility at a low cost, the shared bus is configured in a synchronous, two-wire, multidrop design and
764 utilizes a TDM frame structure.
765 In order to reduce the requirements for Device implementation, this document is written in such a manner
766 as to place restrictions on activity that would result in undesirable operation. Therefore, unless specifically
767 stated otherwise, there is no requirement for an implementation to check for, or react to, SLIMbus activity
768 that is prohibited by design. For example, a Device is not required to validate that another Device is
769 permitted to send a particular type of command.
770 4.1 Device Communication
771 SLIMbus offers Devices two methods of communicating with each other, Messages and Data Channels.
772 Messages can be used for various control functions such as bus management, configuration and status
773 updates. Data Channels have been designed to provide the necessary services for data transport, particularly
774 audio streaming. Figure 1 shows a conceptual view of a SLIMbus system.
775
776
777 Figure 1 SLIMbus System View
778 Note, in the figure a SLIMbus Device does not necessarily represent a packaged electronic component. See
779 section 4.3 for more information.

30
780 4.2 Bus Organization
781 SLIMbus uses a TDM frame structure that is optimized for the transport of constant bitrate media streams,
782 but can accommodate various types of asynchronous data transport as well. Control information can also be
783 interleaved with the data streams.
784 The SLIMbus Frame Structure is partitioned into two regions known as Control Space and Data Space.
785 Control Space is used to supply configuration, synchronization and status information on the bus. Data
786 Space carries application-specific data between Devices.
787 4.2.1 Control Space
788 The size of the Control Space is programmable and controlled by the Subframe Mode which determines the
789 Subframe length and Control Space width. Control Space is composed of three channels of information: the
790 Framing Channel, the Guide Channel and the Message Channel, each with a different responsibility.
791 The Framing Channel conveys two types of information, a Frame Sync symbol used to indicate the start of
792 a Frame, and the Framing Information which includes information indicating the current state of the bus
793 and the size of Control Space. The Framing Channel relative bandwidth is fixed.
794 The Guide Channel provides the necessary information for Devices to acquire and verify Message
795 synchronization in the Message Channel. The Guide Channel relative bandwidth is fixed.
796 The Message Channel is used to transfer Messages between Devices. The bandwidth allocated to the
797 Message Channel is programmable to allow an optimal balance between Message latency and throughput,
798 and bus efficiency.
799 4.2.2 Data Space
800 Any bus bandwidth not allocated to Control Space is Data Space. Data Space is composed of zero or more
801 Data Channels that are dynamically created by the active Manager depending on the application. The
802 number of Data Channels depends on the size of Data Space and type of data streams carried by the
803 channels.
804 4.3 Devices
805 A Device can be thought of as the logical implementation of a system feature such as audio input or output.
806 As such, a Device needs several parts to handle control information as well as process any data required to
807 realize the feature. The fundamental pieces of the Device are the Enumeration and Logical Addresses,
808 Information and Value Elements, and Ports.
809 A Device identifies itself using two different addresses, an Enumeration Address and a Logical Address, to
810 connect to control information. An Enumeration Address is a 48-bit number comprised of four fields: a
811 Manufacturer ID, a Product Code, a Device Index and an Instance Value. An Enumeration Address is
812 primarily used during Device discovery and bus configuration. For more information see section 8.2.5.1.
813 A Logical Address is an 8-bit number assigned during the enumeration procedure. It provides a convenient,
814 shorthand notation for directing control information to the appropriate Device. A Logical Address also
815 provides some control of the bus arbitration procedure. See section 8.2.5.2 for more information.
816 Bus and Device status information is maintained by each Device in standardized bit-fields called
817 Information Elements. An Information Element can be Boolean, having only two distinct values, or
818 enumerated, having many values. An Information Element can be read using a REQUEST-REPLY
819 mechanism or a Device may autonomously send the Information Element status using a special REPORT

31
820 Message. In addition, some Information Elements can be changed to their reset values using the
821 CLEAR_INFORMATION Message.
822 Another, more general type of data store, the Value Element, can be used to provide a standardized method
823 to read and update Device parameters. Similar to an Information Element, a Value Element can be Boolean
824 or enumerated and also supports a REQUEST-REPLY mechanism. Unlike an Information Element, a
825 Value Element can be set to a specific value using the CHANGE_VALUE Message.
826 To reduce bandwidth requirements, multiple Information or Value Elements can be accessed in a single
827 transaction using Slices. See section 7 for more information.
828 The final part of a Device is the Port. Just as a Logical Address provides a connection to control
829 information, a Port provides the connection to data. A Device may have up to sixty-four Ports.
830 Port capabilities may differ based on the features supported by the Device and should be specified in the
831 Component data sheet. Typical Port attributes include data directionality, i.e. input-only (sink), output-only
832 (source), or both input and output; supported Transport Protocols; and data width. For example, the Port
833 attributes for a MEMS microphone could be output-only, Isochronous Transport Protocol and 16-bit data
834 width.
835 4.3.1 Device Classes
836 To facilitate Device design, this document provides definitions of four Device Classes. A Device Class
837 definition specifies the minimum requirements for control information, Device behavior, Transport
838 Protocol support and data storage necessary to implement a Device of that Device Class.
839 Devices based on three of the Device Class definitions: Interface Device, Manager and Framer, are required
840 to create a functioning SLIMbus. The fourth Device Class, Generic, is available for use by any Device for
841 which there is no specific Device Class defined.
842 4.3.1.1 Interface Device
843 An Interface Device is a member of the Interface Device Class and provides bus management services for
844 the Component in which it resides. The Interface Device monitors the Frame Layer and Message Protocols
845 implemented by the Component. The Interface Device also manages Component Reset so that a
846 Component can properly sequence its Devices. In addition, the Interface Device reports information about
847 the status of the Component. Each Component has one Interface Device. See section 12.2 for more
848 information.
849 4.3.1.2 Manager
850 Managers are Devices belonging to the Manager Device Class. A Manager has all the capabilities needed to
851 administer the bus, such as bus enumeration, bus configuration and dynamic channel allocation. Multiple
852 Managers may exist on a single bus, but only one of the Managers shall be active in the Manager role at
853 any given time. The Manager responsible for administering the bus is known as the active Manager. While
854 more than one Manager may be on the bus, the mechanism for changing Managers is outside the scope of
855 this document. See section 12.3 for more information.
856 4.3.1.3 Framer
857 Framers are Devices belonging to the Framer Device Class. A Framer drives the CLK line and places
858 information on the DATA line required to establish the Frame Structure on the bus. Multiple Framers may
859 exist on a single bus, but only one Framer drives the CLK line at any given time. The Framer that is driving
860 the CLK line is called the active Framer. This document defines a mechanism for changing Framers while
861 the bus is active. See section 12.4 for more information.

32
862 4.3.1.4 Generic Device
863 Generic Devices are members of the Generic Device Class. The Generic Device Class provides basic
864 SLIMbus functionality for a Device. See section 12.5 for more information.
865 4.4 Components
866 In order to simplify the design and development of SLIMbus Components, each Component can be viewed
867 as containing a set of Devices and the necessary circuitry needed to provide bus access to these Devices. A
868 Component shall have one, and only one, Interface Device, but may have many Devices of other Device
869 Classes. Basic requirements for Components are discussed in this section. However, Component design is
870 beyond the scope of this document.
871 4.4.1 Simple Component Example
872 Figure 2 shows the building blocks of a simple Component that contains two Devices. Each Device
873 communicates over the bus using the same Message Protocol. In addition, one of the Devices contains a
874 single Port, P0, that uses a dedicated Transport Protocol to transfer data between the system feature it is
875 implementing, possibly a stereo DAC, and other Devices on the bus.
IE LA
IE Message
EA
IE Protocol
Interface Device DATA
Frame Physical
Layer Layer
CLK
IE LA
IE Transport
EA P0
IE Protocol
Device
876
877
878 Figure 2 Simple SLIMbus Component Example
879 As can be seen in the figure, data and control information sent from a Device are first encoded using a
880 specific protocol. For example, the Message Protocol for control information and the Isochronous
881 Transport Protocol for data. The data and control streams are then interleaved by the Frame Layer and
882 finally converted by the Physical Layer into electrical signals on the DATA and CLK lines. In the opposite
883 direction, the signals on the CLK and DATA lines are translated by the Physical Layer into a bit stream.
884 The bit stream is then split into data and control streams by the Frame Layer. The data and control streams
885 are then decoded by the corresponding protocols and sent to the appropriate Devices within the
886 Component.
887 4.4.2 Complex Component Example
888 A more complex Component example can be found in Figure 3, where three Devices are shown, one
889 containing a significant number of Ports.

33
890
891 Figure 3 Complex SLIMbus Component Example
892 4.4.3 Component Requirements
893 A Component shall operate within the timing and electrical constraints given in section 5. When the
894 Component is a Clock Receiving Component, its Physical Layer shall be able to operate over the entire
895 frequency range of 0 to 28.8 MHz, in all Subframe Modes and Clock Gears indicated in section 6.2.
896 A Component shall be able to synchronize to the bus, and Clock Receiving Components shall be able to
897 determine the bus parameters from the Framing Information. In addition, a Component shall implement the
898 Message Protocol.
899 4.5 Channels
900 Channels are used to convey information on the bus. Both control information and data can be transferred
901 between a pair of Devices (inter-Device communication), or between one Device and many other Devices
902 (Broadcast communication). Since SLIMbus provides both Data Channels and Control Space channels,
903 protocols for each type are defined in this document.
904 4.5.1 Data Channels
905 Information carried by a Data Channel is application specific and many different data formats exist. In
906 order to avoid encumbering a system with a large number of data protocols, this document, instead,
907 identifies a handful of frequently used Transport Protocols that can be used with virtually any data format
908 to dynamically create the required Data Channels.
909 Transport Protocols define a data flow type, such as isochronous or asynchronous, a flow control
910 mechanism and a side-channel for any additional application-specific information. A common data
911 structure, the Segment, is defined to hold the Transport Protocol information. See section 6.4.1 for more
912 information.

34
913 4.5.2 Control Space Channels
914 Control Space channels are unique on SLIMbus in that there is no common data structure defining the flow
915 control for a channel. In addition, two of the channels, the Guide Channel and the Framing Channel, have
916 no programmable attributes and utilize a fixed relative bandwidth. Consequently the definition for these
917 two channels is somewhat simpler than other channels.
918 4.5.2.1 Framing Channel
919 The Framing Channel has no provision for flow control and has a fixed channel-relative bandwidth. The
920 Framing Channel carries two types of information, the Frame Sync symbol and the Framing Information.
921 Both pieces of information are sent at regular intervals though they are offset in time. See section 6.3.1 for
922 more information.
923 4.5.2.2 Guide Channel
924 The Guide Channel is the simplest of the three Control Space channels. Like the Framing Channel, no flow
925 control is provided and the channel-relative bandwidth is fixed. Data is organized as a simple Guide Byte
926 that is sent at regular intervals. See section 6.3.2 for more information.
927 4.5.2.3 Message Channel
928 The Message Channel is the most complex of the Control Space channels. Flow control is provided in the
929 form of an acknowledgement symbol and the channel-relative bandwidth is programmable. Various types
930 of information can be carried in the Message Channel including bus configuration, Device control and
931 Device status. Information is transferred between Devices in containers called Messages. See section 8 for
933 4.6 Frame Layer
934 The SLIMbus Frame Structure interleaves Control Space channels and Data Channels into a single,
935 serialized bit stream. Each Component uses a functional block called the Frame Layer to combine control
936 and data information into a single bit stream for transmission on the bus. Also, the Frame Layer is used to
937 split the incoming bit stream into separate control and data streams.
938 In addition, a Framer also contains logic to generate the Guide and Framing Channels used to synchronize
939 Devices on the bus.
940 Design of the Frame Layer is beyond the scope of this document.
941 4.7 Physical Layer
942 The Physical Layer provides for the transmission and reception of the SLIMbus bit stream between
943 Components. SLIMbus uses a synchronous, two-wire, multi-drop bus architecture to transfer information
944 between Components. The two lines, CLK and DATA, are the only wires required to implement the bus.
945 The CLK line distributes a high-quality, unidirectional clock signal to all Components. The DATA line is
946 bidirectional, carrying all information sent or received on the bus. Information is signaled using Non-
947 Return-to-Zero Inverted, or NRZI encoding. See section 5 for additional information.
948 4.8 System Example
949 Figure 4 shows an example system that can be designed with SLIMbus, where several Components are
950 shown around the SLIMbus. The top-left Component is an Application Engine, the bottom-left is a

35
951 baseband. On the right side two microphones and a dual channel DAC are shown. The data of the
952 microphones is transmitted to the Application Engine, where it is processed and transmitted to the
953 baseband. Post processing of the incoming audio is performed in the stereo DAC and therefore the audio is
954 transported directly from the baseband to the DAC.
955
956 Figure 4 System Example
957 The Application Engine contains two Devices, one being an Interface Device and the other a Manager. In
958 this configuration, the Manager in the Application Engine will be the active Manager. This Manager
959 contains a number of Ports, used in this use case to transport audio data to and from the Application
960 Engine. Note that in this example, the Ports support multiple Transport Protocols, so that the Application
961 Engine can be used in multiple systems.
962 The baseband contains three Devices, one Interface Device, a Framer and another Manager. In this
963 scenario, this Framer is the only one in the system and will be used to clock the bus. The Manager will not
964 be used as the active Manager, and is inactive in this use case. However, as the Manager is the only Device
965 that contains Ports, it is still configured to transmit and receive audio data.
966 The top two Components on the right are identical MEMS Microphones that both contain two Devices: An
967 Interface Device and a Generic Device. These Generic Devices only contain a single Port, which in this
968 example are only able to transmit audio data using the Isochronous Protocol, at a 16 kHz sample rate.
969 Given that these are low cost Devices, they extensively use the bus clock signal internally and require a bus
970 clock frequency of 3.072, 6.144, 12.288 or 24.576 MHz, in order to be able to generate the audio.
971 The bottom-right Component is a stereo DAC, and contains three Devices, one Interface Device, and two
972 Generic Devices, one of which supports stereo audio playback. As the DAC has been designed to operate at
973 a broader frequency range and in more complex use cases than the microphones, the Generic Devices have
974 multiple Ports which support multiple Transport Protocols each.
975

36
976 5 Physical Layer

977 The SLIMbus Physical Layer can be thought of as divided into two parts, a Physical Medium Independent
978 part and a Physical Medium Dependent part. Section 5.1 describes the Physical Medium Independent
979 aspect and section 5.2 describes the Physical Medium Dependent aspect in more detail.
980 A SLIMbus system uses a synchronous, two-wire, multi-drop bus to transfer information between
981 Components. One wire is used to transfer a clock signal while the other wire transfer a data signal.
982 Throughout this document the two wires are known as the CLK line and DATA line, respectively.
983 The CLK and DATA lines shall use single-ended, ground referenced, rail-to-rail, voltage mode signals. The
984 DATA line shall be driven on the positive edge and read on the negative edge of the CLK signal. The CLK
985 line shall have only two states, driven high and driven low. The DATA line can be driven high, driven low,
986 or held at the high or low level.
987 DATA terminals shall be bidirectional. If a Component contains a Framer, the CLK terminal shall be
988 bidirectional. If a Component does not contain a Framer, the CLK terminal shall be input-only. Figure 5
989 illustrates the conceptual IO configurations for a SLIMbus Component.
990
991 Figure 5 Conceptual IO Configurations for Components on SLIMbus
992 A DATA terminal shall implement a bus holder to maintain the DATA line at the last high or low level.
993 Figure 6 shows two possible bus holder implementations.

37
994
995
996 Figure 6 DATA Terminal Bus Holder Examples
997 A Component stops driving the DATA line on the negative edge of the CLK signal, and allows the bus
998 holder to maintain the signal level. This procedure avoids the risk of momentary contention when different
999 Components drive the bus on consecutive clock cycles. See Figure 7 and section 5.2.4.3 for additional
1000 information.
1001
1002 Figure 7 Output Driver is Disabled while CLK is Low
1003 5.1 Physical Medium Independent Signaling and Logic Types
1004 The CLK line shall be unencoded.
1005 The DATA line shall be encoded using Non-Return-to-Zero Inverted (NRZI) coding, where a transition on
1006 the DATA line at the positive edge of the CLK line represents a logical one, while the absence of a
1007 transition represents a logical zero.
1008 Except where otherwise specified, a Component shall transmit data by driving each bit onto the DATA
1009 line. This is known as conventional signaling.

38
CLK
TX 1 0 1 1 1 0 1 X X
DATA
1010 RX X 1 0 1 1 1 0 1
1011
1012 Figure 8 NRZI Signaling Example
1013 In certain Cells, for example during arbitration and Message acknowledgement (see sections 8.4.1 and
1014 8.4.2), more than one Component may simultaneously write to the DATA line. In these Cells, a Component
1015 drives the DATA line when it is writing a one but not when it is writing a zero. If no Component writes a
1016 one, the Cell is held by the bus holder at the last level driven. This method of writing to the DATA line is
1017 known as Logical-OR signaling.
1018 When using Logical-OR signaling, a Component shall set its output driver to high-impedance, leaving the
1019 bus holder to maintain the previous level and signaling a logical zero, or drive the DATA line to the reverse
1020 of its state as read at the previous negative edge of CLK, signaling a logical one. Multiple Components may
1021 drive the same level onto the DATA line. Note that Logical-OR signaling avoids contention between
1022 Components.
1023 Figure 9 shows an example with two Components that are both writing to the DATA line simultaneously
1024 using Logical-OR signaling. Driver 1 transmits 0b100 while Driver 2 transmits 0b101. With conventional
1025 signaling the two output drivers would contend the final bit with indeterminate results. With Logical-OR
1026 signaling, the possibility of contention is eliminated and the Component that drives a logical one always
1027 succeeds.
1028
1029 Figure 9 Logical-OR NRZI Signaling Example

39
1030 5.1.1 Collision Detection
1031 A Component shall implement Collision detection by monitoring the behavior of the DATA line while
1032 transmitting data on the SLIMbus. When a Component drives the DATA line, it shall read the line state,
1033 LOW or HIGH, on the falling edge of the CLK signal. If the transmitted and received states differ, the
1034 Component shall record the occurrence of a Collision as described in section 10.2.
1035 A Component can cause a Collision only when it is driving the DATA line. Note that in Logical-OR
1036 signaling, transmitting a logical zero does not involve driving the DATA line (section 5.1). Thus even
1037 arbitration and Message acknowledgement are normally Collision-free.
1038 Collisions can have various physical causes, e.g. two Devices driving the DATA line simultaneously, clock
1039 latency from Component to Component, slow DATA line reflections, CLK line glitches, incorrect
1040 Component synchronization, incorrect programming of Segment locations and DATA line noise.
1041 5.2 Physical Medium Dependent Specifications
1042 A SLIMbus Component drives the CLK and DATA lines using CMOS-like signals, i.e. single-ended,
1043 ground referenced, rail-to-rail, voltage mode signals. Therefore, electrical specifications in this document
1044 are given relative to the supply voltage, VDD. The CLK and DATA terminals shall use the same signaling
1045 levels.
1046 5.2.1 Signaling Voltages
1047 The CLK terminal should be designed to operate even in the presence of repeated reflection-induced
1048 transient overvoltage and undervoltage conditions corresponding to 1.1*VDD and -0.1*VDD behind a 33
1049 resistance.
1050 The DATA terminal should be designed to operate even in the presence of repeated reflection-induced
1051 transient overvoltage and undervoltage conditions corresponding to 1.5*VDD and -0.5*VDD behind a 33
1052 resistance.
1053 This document uses 1.2V and 1.8V signaling to describe various parameters. However, no requirement is
1054 made on VDD, and therefore, the bus signaling voltages, used by a Component. Nonetheless, it is
1055 recommended that a SLIMbus Component support 1.2V or 1.8V signaling.
1056 A Component using 1.8V signaling shall meet the requirements given in Table 1.
1057 Table 1 Parameters for Components using 1.8V Signaling
Symbol Parameter Min Max Units

VDD SLIMbus Supply Voltage 1.65 1.95 V
VIL Input-LOW Voltage, settled -0.1*VDD 0.35*VDD V
VIH Input-HIGH Voltage, settled 0.65*VDD 1.1*VDD V
1058 Additionally, the Component shall have the static output electrical characteristics shown in Table 2.
1059 Table 2 Static Electrical Characteristics for 1.8V Signaling
Symbol Parameter Condition Min Max Units

VOL Output-LOW Voltage IOL = 1mA 0 0.1*VDD V
VOH Output-HIGH Voltage IOH = -1mA 0.9*VDD VDD V

40

CIO IO Capacitance 5 pF
1060 The CIO should be designed to be below 3pF for most cases. CIOmax allows for larger geometry, high
1061 voltage-capable devices
1062 A Component using 1.2V signaling shall meet the requirements given in Table 3.
1063 Table 3 Parameters for Components using 1.2V Signaling

VDD SLIMbus Supply Voltage 1.1 1.3 V
VIL Input-LOW Voltage, settled -0.1*VDD 0.35*VDD V
VIH Input-HIGH Voltage, settled 0.65*VDD 1.1*VDD V
1064 Additionally, the Component shall have the static output electrical characteristics shown in Table 4.
1065 Table 4 Static Electrical Characteristics for 1.2V Signaling

VOL Output-LOW Voltage IOL = 1mA 0 0.1*VDD V
VOH Output-HIGH Voltage IOH = -1mA 0.9*VDD VDD V
CIO IO Capacitance 5 pF
1066 The CIO should be designed to be below 3pF for most cases. CIOmax allows for larger geometry, high
1067 voltage-capable devices
1068 5.2.2 CLK Terminal Output Specifications
1069 The clock signal is transmitted from the active Framer to all Components. The Component that contains the
1070 active Framer is called the Clock Sourcing Component. As the Clock Sourcing Component can be changed
1071 dynamically to any Framer on the bus, the physical location of the clock driver on the CLK line cannot be
1072 realistically constrained.
1073 To reduce active power consumption the CLK line is typically not terminated. To avoid reflections and
1074 overvoltage problems on such a system, the CLK line shall be slew rate controlled. This constraint makes a
1075 conventional CMOS IO unsuitable for driving the CLK line at high speeds but it is possible to drive the
1076 CLK line at low speeds using a carefully matched CMOS driver. This document does not mandate a
1077 maximum output frequency for a Framer.
1078 The clock driver is the circuit in every Framer that is responsible for driving the CLK signal. Components
1079 that do not implement a Framer do not have to implement any form of clock driver. When a Framer is not
1080 the active Framer, the clock driver shall be disabled. In such configurations the CLK terminal of the Device
1081 shall behave according to the CLK input specifications only. The clock driver output and input should share
1082 the same physical terminal on the Component as this reduces external routing overheads and corresponding
1083 loads.

41
Internal External
Enable
Slew Rate Clock Net

Clock Out
Controlled Driver
Clock In
1084
1085 Figure 10 Recommended Clock Driver Implementation
1086 The ability to select between different Framers on the bus according to dynamic system requirements
1087 means that Framers do not need to be capable of generating clock signals for all frequencies required by the
1088 system. The Component manufacturer shall specify the capabilities of Framers to allow the system designer
1089 to both select suitable Components and choose between multiple Framers within a system to optimize
1090 bandwidth and CLK line quality requirements.
1091 The CLK line shall be treated as an unterminated transmission line. Fast edges on the clock signal will
1092 introduce reflections on the CLK line, degrading CLK line quality and could potentially generate glitches
1093 in a receiving Device. To avoid this problem, the slew rates of the CLK line must be carefully controlled.
1094 The maximum allowable slew rate on the CLK line is directly related to the length of the longest end-to-
1095 end path on the CLK line. The longer this length, referred to as the bus diameter, the lower the slew rate
1096 needed to generate a reliable clock signal. Generally, the bus diameter is expected to be less than 20cm,
1097 which results in a minimum transition time of 4ns. To allow larger bus diameters, lower slew rates may be
1098 used. However, terminated topologies might be required for bus diameters over 50 cm.
1099 When driving the test load specified in section 5.2.2.1 the CLK line driver shall conform to the timing
1100 characteristics shown in Table 5.
1101
1102 Figure 11 Clock Driver Output Waveform Constraints
1103 Table 5 Clock Output Timing Characteristics

TCLKOH Clock Output High Time 12 - ns
TCLKOL Clock Output Low Time 12 - ns
SRCLK Clock Output Slew Rate 20%<VO<80% 0.02*VDD 0.2*VDD V/ns

42
1104 The rise and fall times of the clock driver constrain both the maximum operating frequency and length of
1105 the CLK line. Manufacturers shall specify the Framer maximum and minimum slew rates into the specified
1106 test load.
1107 The Framer may be configured outside of the SLIMbus via software, or any other method, with details of
1108 the load that will be applied to the CLK and DATA lines, thus allowing basic CMOS drivers with
1109 selectable output strengths to be used for low frequency operation of the SLIMbus.
1110 5.2.2.1 Clock Driver Test Load
1111 The clock driver will typically be presented with a reactive load. To avoid the generation of reflections, the
1112 voltage on the CLK line must be brought up and down slowly. This is tested by ensuring the maximum and
1113 minimum slew rates are adhered to into lumped models of the largest and smallest loads, represented by
1114 15pF and 75pF. This constraint alone does not guarantee monotonic operation into all possible loads so the
1115 Framer should be designed to drive unterminated transmission lines of lengths of at least 20cm while
1116 keeping the edges within the SRCLK specification.
1117 5.2.3 CLK Terminal Input Specifications
1118 Each Component's set of timing requirements for correct operation shall meet the constraints given in Table
1119 6. Its respective Min limits shall be no higher than the values in the table.
TCLKIH TCLKIL
VIHmin
VILmax
1120
1121 Figure 12 Received Clock Signal Constraints
1122 Table 6 Clock Input Timing Requirements

TCLKIH CLK Input High Time 12 - ns
TCLKIL CLK Input Low Time 12 - ns
SRCLKI Clock Input Slew Rate 20%<VI<80% 0.02*VDD - V/ns
1123 Table 7 Clock Input Electrical Characteristics

HCLKI CLK Input Hysteresis 50 - mV
1124 Use of a glitch rejection filter on the CLK input is optional. The glitch filter shall not in any way impact the
1125 system timing, i.e. the delay through any glitch rejection filter on the CLK input must be included in the
1126 TDV constraint.
1127 The CLK input shall be capable of receiving slowly changing edges without glitching.

43
1128 5.2.4 DATA Terminal
1129 As the DATA line is common to all Components it is possible during error conditions that two or more
1130 Components could drive the DATA line simultaneously with opposing values. To moderate such
1131 contention, the transmit driver of each DATA terminal shall be current limited.
1132 The DATA terminal of a SLIMbus Device makes use of a modified CMOS IO structure that incorporates a
1133 bus holder and a method of ensuring the slew rate constraints are met into all loads. SLIMbus does not
1134 require the DATA signal to be used as a clock and consequently the DATA input does not require a glitch
1135 filter.
1136 5.2.4.1 DATA IO Electrical Specifications
1137 The DATA line IO shall meet the electrical specifications in Table 8.
1138 Table 8 DATA Output Electrical Characteristics

ISHORT Short Circuit Output Current Tied to opposite rail -100 100 mA
1139 The output impedance of the DATA output driver is typically of the range 25 to 100 but will vary with
1140 driver topology and may vary dynamically. The output impedance is constrained by both timing and a hard
1141 current limit to avoid serious damage potentially caused by momentary contention in error conditions.
1142 The DATA terminal shall be over/undervoltage protected to allow for typical overshoots caused by
1143 possible fast rise times on long transmission lines. If the IO cannot receive signals in the range depicted by
1144 VITDATA it shall include catch diodes or similar device(s) to limit the local input voltage presented to the
1145 Component.
1146 The maximum slew rate, SRDATAmax, is specified for a single Component driving the test load described in
1147 section 5.2.4.2. The slew rate observed on the DATA line can be greater than SRDATAmax when multiple
1148 Components are driving the bus during Logical-OR signaling.
1149 The output driver of a DATA terminal shall drive the test loads specified in section 5.2.4.2 with the
1150 dynamic specifications shown in Table 9.
1151 Table 9 DATA Output Timing Characteristics

SRDATA Data Output Slew Rate 20%<VO<80% - 0.5 * VDD V/ns
TDV Time for Data Output 12 ns
Valid
1152 Care should be taken to ensure that any additional loading on the CLK or DATA lines, e.g. passive devices
1153 used to reduce EMI or reflections, is accounted for in the system timing budget.
1154 A SLIMbus system shall meet the system level timing constraints in Table 10.
1155 Table 10 DATA Input Timing Requirements

TH Data Input Hold Time 2 - ns
TSETUP Data Input Setup Time 3.5 - ns

44
1156 5.2.4.2 DATA Driver Test Load
1157 The DATA signal does not need to be monotonic and as such capacitive test loads of 15 pF and 75 pF shall
1158 be used to verify the Slew rate, transient voltage, and transition time specifications.
1159 5.2.4.3 Additional Timing Constraints
1160 At some point between the SLIMbus CLK negative edge and the first possible positive edge, the transmitter
1161 shall disable its active driver and revert to its bus holder. The active driver shall meet the TDD specification
1162 in Table 11.
1163 Table 11 Driver Disable Timing Specification

TDD Driver Disable Time - 10 ns
1164 The bus holder is able to hold the value on the bus as long as the bus remains in a powered state. As the
1165 clock transition times can be very large the data can be sampled by receivers when driven or when being
1166 held by the bus holders.
1167 5.2.5 Bus Holder Specifications
1168 The DATA IO shall contain a bus holder; this is specified in Table 12 as a minimum and maximum output
1169 impedance.
1170 Table 12 Bus Holder Electrical Specification

RDATAS Bus Holder Output Impedance 0.1*VDD < V < 0.9*VDD 10k 50k
1171 This effectively creates a mask in the IV characteristic as shown in Figure 13.

45
10k
50k
0.1*VDD
0 V
0.9*VDD
50k
10k
1172
1173 Figure 13 Bus Holder I/V Mask
1174 All CLK and DATA lines implementing a bus holder shall comply to the bus holder I/V mask as shown in
1175 Figure 13. Consequently, this specification applies to all DATA terminals as well as any CLK terminals
1176 that implement a bus holder. A CLK line IO that does not implement a bus holder shall meet the leakage
1177 specification in Table 13.
1178 Table 13 Input Leakage Constraints

ILCLK Input Leakage Current VI=0.1*VDD, -5 5 A
VI=0.9*VDD
1179 5.2.6 Component Power Down on an Active Bus
1180 The Physical Layer of a Component may be designed so that it can be powered down while the bus remains
1181 active. While in a powered down state, or during the change to or from a powered down state, the CLK and
1182 DATA terminals of such a Component shall meet the requirements for IO capacitance and input leakage
1183 current given in sections 5.2.1 and 5.2.5, respectively.
1184 5.2.7 System Timing Budget (informative)
1185 The maximum frequency that the bus can operate is a physical constraint that depends on the length of the
1186 bus, the loads attached to the bus and the capabilities of the Framer. In sensibly designed systems SLIMbus
1187 can operate at all common system frequencies up to 20MHz. Operation is possible beyond this but
1188 considerable care is required on the part of the system designer to guarantee that signal integrity and proper
1189 timing is maintained. The maximum frequency allowed by this specification is constrained by the clock
1190 driver quality and the internal timing of the data paths and the length of the bus.
1191 As the DATA line is always driven on the positive edge, and sampled on the negative edge, of the CLK
1192 line, the timing is determined by the CLK high phase. The worst-case timing budget occurs when the
1193 Component that sees the latest CLK line positive edge transmits to the Device that sees the earliest CLK

46
1194 line negative edge. Due to differences in trigger levels this does not necessarily correspond to the physical
1195 positions of the Devices on the CLK line.
1196 5.2.7.1 Clock Uncertainty and Jitter
1197 The maximum allowable CLK line uncertainty consists of transmission line delay, TSKEW, longest rise or
1198 fall time at the receiver, TCLKISLEW, and jitter effects, TJITTER.
1199 TSKEW is directly related to the length of the longest path the CLK signal has to make. This is not the same
1200 as the bus diameter as the active Framer may be located in the center of the bus. The longest possible length
1201 is the bus diameter L and occurs when the Framer is located at the end of the CLK line. The transmission
1202 line delay specification applies at all voltages on the transition between VILmax and VIHmin at the CLK
1203 terminal of each Component on the bus.
1204
1205 Figure 14 TSKEW Specification
1206 For a typical PCB, the transmission line delay, TD, varies from about 60 to 75ps per cm. Therefore, TSKEW
1207 can be described as:
1208 TSKEW = LCLK* TD/CM (in ps)
1209 The clock uncertainty contribution from the input transition time, TCLKISLEW, is the delay from VILmax to
1210 VIHmin at the lowest slew rate of the active Framer and is shown in Figure 15.
1211
1212 Figure 15 TCLKISLEW Specification
1213 These restrictions define TCLKISLEW as:
1214 TCLKISLEW = 0.3* TCLKOSLEWmax

47
1215 The jitter of the CLK signal is not mandated in this document although the peak-peak period jitter, TJITTER,
1216 must be taken into account when running at high frequencies where it impacts system timing. Note that
1217 TJITTER includes all sources of jitter from both the time domain (phase noise related) and voltage domain
1218 (noise).
1219 In systems where analog-to-digital or digital-to-analog conversion quality is important, additional clock
1220 jitter considerations might apply [AES01]. Such considerations are beyond the scope of this document.
1221 However, they are reflected in the clock QUALITY Information Element that is described in section
1222 12.4.5.1.
1223 The combined clock uncertainty is referred to as TCLKUNCERT and is shown below. TCLKUNCERT is taken to be
1224 the larger of the uncertainties calculated from the rising or negative edge of the CLK line.
1225
1226 Figure 16 TCLKUNCERT Specification
1227 TCLKUNCERT = TSKEW + TCLKISLEW + TJITTER
1228 Extra margin should be added to the clock uncertainty to allow for noise on the CLK line and differences in
1229 the supplies and grounds from Component to Component.
1230 5.2.7.2 Time to Drive Data Valid
1231 The time to drive the data valid, TDV, is the time for the data to become valid from the time the transmitter
1232 receives the positive edge of the CLK line. For a CMOS IO this is typically quoted into a fixed load. For
1233 SLIMbus, this specification must be met into the range of test loads. TDV can be broken down into the
1234 Component-specific (internal) delays and the line-specific (external) delays:
1235 TDO is the time from the positive edge of the CLK line on the transmitter to the point when the
1236 voltage on the DATA terminal of the transmitter is higher than VOLDATA and lower than
1237 VOHDATA.
1238 TSETTLE is the time required for the voltage at all points on the DATA line to be higher than
1239 VOHDATA or lower than VOLDATA. This includes all transmission line delays.
1240 TSETTLE has an effect on the overshoot and EMI aspects of the SLIMbus system implementation. Overshoot
1241 and EMI increase as TSETTLE becomes smaller.

48
1242 5.2.7.3 Setup Time
1243 TSETUP is the minimum receiver setup time, measured at the receiver terminals. The signal on the DATA
1244 terminal is stable for the period of the setup time from the local negative edge to allow the receiver to
1245 accurately sample its state.
1246 5.2.7.4 Timing Budget Calculation
1247 The DATA line must be driven to a stable value in a time equivalent to the difference from the latest
1248 possible positive edge to the first possible negative edge, less the receiver setup time as shown in Figure 17.
1249
1250 Figure 17 Data Transmit Timing Constraints
1251 From this diagram it can be seen that the time available to transmit, TCLKIH + TCLKISLEW, must be long
1252 enough to accommodate clock uncertainty, time for the data to settle to a valid state on the DATA line and
1253 setup time:
1254 TCLKIH + TCLKISLEW > TCLKUNCERT + TDV + TSETUP
1255 The clock uncertainty and waveform constraints will vary depending on the quality of the active Framer.

49
1256 5.2.7.5 Timing Budget Examples
1257 When operating the SLIMbus at frequencies above 20MHz the timing budget becomes gradually more
1258 critical. This section describes how to calculate the timing budget for system designers who require
1259 operation of a SLIMbus at high frequencies.
1260 The timing budget for SLIMbus consists of fixed delays that are directly limited in the specification and
1261 variable delays. An example of the timing budget at 20MHz is provided below, it is assumed from these
1262 examples that the clock driver is 1.8V and has a slew rate range of 0.12 to 0.45V/ns (allowing a 20cm bus
1263 and 9ns maximum TCLKOSLEW).
1264 Example of Timing Budget at 19.2MHz, 20cm, 75pF:
1265 TCLKUNCERT = 7ns (TCLKISLEW = 4.5ns, 1.5ns for TSKEW, 0.5ns for Jitter, 0.5ns for some margin to
1266 cope with noise)
1267 TDV = 12ns (7ns TSETTLE and 5ns for TDO)
1268 TSETUP = 3.5ns
1269 Total transmit time = 22.5ns
1270 Total Available time = TCLKIH + TCLKISLEW 26ns (For identical linear slopes and 50/50 Duty cycle this
1271 should end up as 50% of a full clock cycle.
1272 This leaves 3ns for deviations in duty cycle, noise, extra jitter
1273 If operation at 26MHz is required, TCLKIH falls from 22.5ns to 17.3ns. To allow the bus to run at this speed
1274 the length or bus capacitance can be reduced at the system designers discretion. This allows for a reduction
1275 in TSETTLE.
1276 Example of Timing Budget at 26MHz, 10cm, 35pF:
1277 TCLKUNCERT = 6.5ns (TCLKISLEW = 4.5ns, 1ns for TSKEW, 0.5ns for Jitter, 0.5ns for margin to cope
1278 with noise)
1279 TDV = 7ns (3ns TSETTLE and 4ns for TDO)
1280 TSETUP = 3.5ns
1281 Total transmit time = 17ns
1282 Total Available time = TCLKIH+TCLKISLEW = 19.23ns
1283 For reliable transmission at 26MHz less noise and jitter would be advisable.
1284 With a lower bus capacitance it is likely that TCLKISLEW could also be reduced. TSKEW could also be reduced,
1285 relaxing the timing budget further. Device manufacturers can provide SLIMbus compatible Devices that
1286 have tighter TCLKISLEW, TDO, and TSETUP parameters to simplify the design of buses that operate to the
1287 maximum frequency permitted in Gear 10, 28.8 MHz.
1288 If device designers struggle to meet the TSETUP specification, for example on large devices with shared
1289 terminals, it should be noted that an internal delay on the inverted clock to the data sampling register
1290 directly increases setup time with no external effects.

50
1291 At the other extreme a less well constrained clock driver can be used at limited speeds. Imagine a 1.8V
1292 clock driver with a specified slew rate of 0.06V/ns to 0.3V/ns, giving minimum and maximum TCLKOSLEW
1293 times of 3.6ns and 18ns. This Framer can be used with a CLK line of up-to 30cm at speeds up to 11.9MHz.
1294 Example of Timing Budget at 12.288MHz, 30cm, 75pF:
1295 TCLKUNCERT = 15ns (TCLKISLEW = 10ns, 2.5ns for TSKEW, 1ns for Jitter, 1.5ns for some margin to
1296 cope with noise)
1297 TDV = 12ns (7ns TSETTLE and 5ns for TDO).
1298 TSETUP = 3.5ns
1299 Total transmit time = 30.5ns
1300 Total Available time = TCLKIH + TCLKISLEW 40ns (For identical linear slopes and 50/50 Duty
1301 cycle this should end up as 50% of a full clock cycle
1302

51
1303 6 Frame Structure

1304 The SLIMbus bit stream is organized in a Time Domain Multiplexed (TDM) configuration. This
1305 organization allows SLIMbus to carry control and data information as well as bus configuration
1306 information. Throughout this document the organization of information on the bus is called the Frame
1307 Structure.
1308 At the highest level of abstraction, the Frame Structure is split into two regions known as Control Space
1309 and Data Space. Control Space carries bus configuration and synchronization information as well as other
1310 inter-Device communication. Data Space carries application-specific information such as isochronous,
1311 near-isochronous and asynchronous data streams. Control Space and Data Space can be further divided into
1312 channels, with each channel representing a particular information flow. The relative bandwidth used by the
1313 Control Space and Data Space is configurable so that the bus can be adapted to virtually any application.
1314 Refer to sections 6.3.1.4 and 10.6 for more details on the partitioning of the Control Space and Data Space.
1315 At a more fundamental level, the Frame Structure is composed of five building blocks: Cells, Slots,
1316 Subframes, Frames and Superframes. Section 6.1 describes these building blocks in detail.
1317 6.1 Cells, Slots, Subframes, Frames, and Superframes
1318 SLIMbus uses a synchronous, two-wire bus to carry information between Devices. The following sections
1319 describe several conceptual parts to aid the reader in understanding how the Frame Structure is imposed on
1320 the bus signals.
1321 6.1.1 Cell
1322 The smallest subdivision of a SLIMbus data flow is the Cell. A Cell is defined as a region of the DATA
1323 signal that is bounded by two consecutive positive edges of the CLK line. Each Cell can hold a single bit of
1324 information.
1325 6.1.2 Slot
1326 A Slot is defined as four contiguous Cells and is the unit of bandwidth allocation on SLIMbus. Cells within
1327 a Slot are labeled C0 through C3.
1328 Slots shall be transmitted C3 first followed by C2, C1 and C0, in that order.
1329 6.1.3 Subframe
1330 A Subframe is defined as the division of the Frame Structure at which Control Space and Data Space are
1331 interleaved. The Subframe length is programmable and shall be six, eight, twenty-four or thirty-two
1332 contiguous Slots (24, 32, 96 or 128 Cells). Slots within a Subframe are labeled S0 through S(n-1), where n
1333 is the Subframe length.
1334 Subframes shall be transmitted S0 first followed by S1, S2, S(n-1), in that order.
1335 At least one Slot, and as many as all Slots, of a Subframe may be allocated to Control Space. Any Slots not
1336 allocated to Control Space are considered Data Space. See section 6.3.1.4 for more information.
1337 6.1.4 Frame
1338 A Frame is defined as 192 contiguous Slots. Slots within a Frame are labeled S0 through S191.

52
1339 Frames shall be transmitted S0 first followed by S1, S2, S191, in that order.
1340 The first Slot (Slot 0) of each Frame shall contain the Frame Sync symbol that a Component can use to
1341 synchronize to the bus. Slot 96 of each Frame shall contain four bits of Framing Information. See section
1342 6.3.1.1 for a description of Framing Information.
1343 6.1.5 Superframe
1344 A Superframe is defined as eight contiguous Frames (1536 Slots). Frames within a Superframe are labeled
1345 Frame 0 through Frame 7.
1346 Superframes shall be transmitted Frame 0 first followed by Frame 1, Frame 2, Frame 7, in that order.
1347 Each Frame of a Superframe shall contain the Frame Sync symbol in Slot 0. In addition, the first Frame
1348 (Frame 0) of a Superframe shall contain the first four bits of Framing Information in Slot 96. Frames 1
1349 through Frame 7 shall also contain four bits of Framing Information in Slot 96 with Frame 7 carrying the
1350 last four bits of Framing Information. Since a Superframe contains a complete set of Framing Information,
1351 a Component uses the Framing Information for Superframe synchronization. See section 6.3.1.1 for a
1352 description of Framing Information.
1353 6.1.6 Relationship of Frame Structure Constructs
1354 Unlike the other basic Frame Structure constructs, Subframes do not have a single, fixed length. For any
1355 given bus configuration, the Subframe length is set to one of four possible values: 6, 8, 24, or 32 Slots.
1356 Consequently, the number of Subframes per Frame depends on the bus configuration. Table 14 summarizes
1357 the relationships between Cells, Slots, Subframes, Frames, and Superframes for the different Subframe
1358 lengths. The shaded table entries highlight the values that vary with the Subframe size.
1359 Table 14 Relationship of the number of Cells, Slots, Subframes, Frames, Superframes
6-Slot Subframe Cells Slots Subframes Frames Superframes

Cell 1 - - - -
Slot 4 1 - - -
Subframe 24 6 1 - -
Frame 768 192 32 1 -
Superframe 6144 1536 256 8 1

Cell 1 - - - -
Slot 4 1 - - -
Subframe 32 8 1 - -
Frame 768 192 24 1 -
Superframe 6144 1536 192 8 1

Cell 1 - - - -
Slot 4 1 - - -

53
Subframe 96 24 1 - -
Frame 768 192 8 1 -
Superframe 6144 1536 64 8 1

Cell 1 - - - -
Slot 4 1 - - -
Subframe 128 32 1 - -
Frame 768 192 6 1 -
Superframe 6144 1536 48 8 1
1360 6.1.7 Integrating the Concepts (informative)
1361 Figure 18 illustrates the SLIMbus Frame Structure from the Cell level up to the Superframe level. The
1362 values in the Cells and Slots are examples, as is the division between the Control Space and the Data Space.
1363 Note that the figure represents only one possible bus configuration.
1364 Control Space appears at the beginning of every Subframe and it only appears once per Subframe. This is
1365 the defining feature of the Subframe it is the division with which the Control Space is interleaved within
1366 the Frame Structure. The Framing Channel, Guide Channel and Message Channel make up Control Space.
1367 Note that the Framing Channel has two components per Frame, the Frame Sync symbol and Framing
1368 Information.
1369 The Frame Structure regains strict regularity at the Frame level. Each Frame contains 192 Slots and each
1370 Superframe contains eight Frames. Figure 18 does not attempt to distinguish between Control Space and
1371 Data Space in its representation of Frames or Superframes. However, the figure still shows the Framing
1372 Channel at the highest levels since it is a consistent and useful marker in the Frame Structure.

54
1373
Framing Channel
Frame
Frame Frame Frame Frame Frame Frame Frame
Superframe
Frame Subframe Subframe ... Subframe Subframe ...
Subframe Control Data
Slots 0b1011 0b0010 0b1110 0b0100
C3 C2 C1 C0 C3 C2 C1 C0 C3 C2 C1 C0 C3 C2 C1 C0
Cells 1 0 1 1 0 0 1 0 1 1 1 0 0 1 0 0
CLK
Framing Channel
Frame Sync Symbol Guide Channel (Frame 0 only)
Framing Information Message Channel

1374
1375
1376 Figure 18 Overview of the SLIMbus TDM Scheme
1377 6.2 Clock Gears, Frequencies, and Root Superframes
1378 This document does not specify a particular CLK frequency. The CLK frequency can be set according to
1379 the application needs.
1380 While a Superframe always consist of 1536 Slots (6144 Cells), it can vary in duration. In other words, the
1381 length of a Superframe is fixed in terms of Slots, and therefore Cells, but not in terms of time.
1382 Consequently, the Superframe rate can be changed on SLIMbus.
1383 The Superframe rate can be changed while the bus is active. The Superframe rate of an active SLIMbus can
1384 be varied by changing the Clock Gear, the Root Frequency or both. Note that these changes can take place
1385 even while Data Channels are active and Messages are being transmitted in the Message Channel.
1386 On SLIMbus, a temporal frame of reference that is independent of the Clock Gear is provided by the Root
1387 Frequency and Root Superframe size. In the top Clock Gear, Gear 10, the Root Frequency and Root
1388 Superframe size correspond to the actual CLK frequency and the actual Superframe size, respectively.
1389 Lowering the Clock Gear halves the CLK frequency and doubles the duration of a Superframe, but leaves
1390 the Root Frequency and Root Superframes unaltered. This is useful, for example, in minimizing the bus
1391 power consumption.

55
1392 6.2.1 Clock Gears
1393 Clock Gears provide a range of power-of-two frequency steps for operating SLIMbus and establish a
1394 framework for easily balancing bus bandwidth and power consumption. Increasing to the next Clock Gear
1395 without changing the Root Frequency shall double the SLIMbus CLK frequency. There are ten Clock
1396 Gears, Gear 1 to Gear 10, providing a frequency span of 512.
1397 Note that each Clock Gear has a frequency span of 2.25x. For example, the Gear 5 frequency can range
1398 from 0.4 to 0.9 MHz. Therefore, SLIMbus CLK frequencies can vary from 0.025 (Gear 1, minimum
1399 frequency) to 28.8 MHz (Gear 10, maximum frequency) for a total span of 1152.
1400 6.2.2 Clock Gear Example (informative)
1401 Consider an example SLIMbus system that supports isochronous 16-bit flows at 8 kHz and 48 kHz sample
1402 rates. The Root Frequency is 24.576 MHz. Below is a possible use case sequence in which the Clock Gear
1403 changes:
1404 Two 8 kHz sample rate flows are active so a CLK frequency of 384 kHz (Gear 4) is sufficient.
1405 Later on, two 48 kHz sample rate flows also become active. The CLK frequency is raised to 3.072
1406 MHz by changing the Clock Gear to seven in order to accommodate the increased bandwidth
1407 requirements.
1408 Finally, the two 48 kHz sample rate flows become inactive leaving just the two 8 kHz sample rate
1409 flows. The Clock Gear is changed back to four, lowering the CLK frequency to 384 kHz and thus
1410 reducing power consumption.
1411 Figure 19 shows how the Superframe rate changes as the Clock Gear is changed according to the needs of
1412 the use case.
1413
1414 Figure 19 Clock Gear Example
1415 This example demonstrates how SLIMbus Clock Gears can be used to minimize the bus power
1416 consumption. Instead of always running the bus at the highest required frequency for a platform, Clock
1417 Gears can be used to tune the CLK frequency for the current application.
1418 6.2.3 Root Frequency
1419 The Root Frequency shall be 2(10-CG) times the frequency of the CLK line, where CG is the current Clock
1420 Gear. In Gear 10, the CLK frequency is the same as the Root Frequency.
1421 Note that the Root Frequency indicates a Gear 10 frequency as described here, even if the active Framer
1422 does not support generation of such a frequency.
1423 The Root Frequency may be changed while the bus is active.
1424 6.2.4 Root Superframes
1425 Many SLIMbus constructs and processes are defined with respect to Superframes. This includes such
1426 things as Data Channel definitions and the coordination of bus configuration changes. But the frequency of
1427 the Superframes depends on the Clock Gear, and their phasing depends on the timing of previous Clock

56
1428 Gear changes. For some purposes it is more natural to use a reference framework that is independent of the
1429 Clock Gear. The concept of Root Superframes provides this framework.
1430 Root Superframes are Clock Gear-independent divisions of the SLIMbus timeline. In Gear 10, Root
1431 Superframes have the same frequency and phasing as the bus's actual Superframes. With each step down
1432 the Clock Gears the duration of the actual Superframes progressively doubles, quadruples etc., but the Root
1433 Superframes remain unaltered. This concept is illustrated in Figure 20 through a Clock Gear change. Note
1434 that Superframe Boundaries are always also Root Superframe boundaries.
1435
1436 Figure 20 Root Superframe Example
1437 Formally, Root Superframes are divisions of the SLIMbus Superframes into 2(10-CG) equal parts, where CG
1438 is the Clock Gear. Each Root Superframe spans 6144/2(10-CG) Cells. A consequence of these numbers is that
1439 every Root Superframe boundary falls on an actual Cell boundary, even in Gear 1.
1440 Root Superframes are used by the Phasing Signal to communicate an embedded timing reference. See
1441 section 6.3.1.8. Root Superframes are also used in the Locked Transport Protocol. See section 9.3.4.
1442 Note that the Root Superframe indicates a constant time reference based on Gear 10, even if the active
1443 Framer does not support an output CLK at Root Frequency.
1444 6.2.5 Natural Frequencies
1445 A Natural Frequency is defined as a CLK frequency that allows a family of data flows to be supported
1446 using the allowed channel rate multipliers. For example, Natural Frequencies for 11.025 kHz and 44.1 kHz
1447 sample rate flows include 5.6448 MHz, 11.2896 MHz, and 22.5792 MHz. Similarly, Natural Frequencies
1448 for 8 kHz and 48 kHz sample rate flows include 6.144 MHz, 12.288 MHz, and 24.576 MHz. An additional
1449 benefit is that an isochronous data flow using a permitted channel rate multiplier does not require flow
1450 control. See Table 20 for a list of the channel rate multipliers.
1451 Data flows at rates other than a multiple of the Superframe rate can be supported using flow control at the
1452 expense of bus efficiency. Typically, a higher than necessary bandwidth is allocated to the data flow in
1453 order to use one of the prescribed multipliers, thus wasting some of the bandwidth. Also, additional Slots
1454 may be allocated for flow control signaling, thereby consuming more bandwidth. Refer to section 9.3 for
1455 information on how flow control mechanisms work with Data Channels.
1456 Figure 21 illustrates an example data flow on SLIMbus. In the figure, the Root Frequency has been selected
1457 so that the SLIMbus CLK frequency is a Natural Frequency for this data flow. The top timeline shows a
1458 data flow with a constant frequency. When the data flow is carried on SLIMbus as shown in the bottom
1459 timeline, the constant periodicity of the data flow is preserved. The data flow occupies each Segment of the
1460 associated Data Channel. Refer to section 6.4.1 for details on Segments.

57
1461
1462 Figure 21 Natural Frequency Example
1463 The use of Natural Frequencies is not mandated on SLIMbus. Refer to Annex C for details on Natural
1464 Frequencies across Clock Gears for each Presence Rate defined in section 9.6.
1465 6.2.6 Cardinal Frequencies
1466 Natural Frequencies have properties that ease channel allocation on SLIMbus. For a given family of flows,
1467 they enable the use of a pure isochronous channel with no flow control. However, concurrent support for
1468 flows, or families of flows, with non-integer frequency relationships is sometimes required, e.g. 8 kHz and
1469 44.1 kHz. In these cases, the CLK line cannot be set to a frequency that is a Natural Frequency for all flows
1470 on the bus.
1471 In audio applications, one important family of sample rates is comprised entirely of multiples of 4 kHz, i.e.
1472 8, 12, 16, 24, 32, 48, 96 kHz, etc. Another family is comprised entirely of multiples of 11.025 kHz, i.e.
1473 11.025, 22.05, 44.1, 88.2 kHz, etc.
1474 The CLK line frequencies 24.576 MHz, 12.288 MHz, 6.144 MHz, etc. have special significance because
1475 they can carry the 4 kHz family of flows isochronously, and the 11.025 kHz family of flows with relatively
1476 high efficiency. For this reason, these clock frequencies are referred to as Cardinal Frequencies. Note that
1477 there is only one Cardinal Frequency in each SLIMbus Clock Gear.
1478 The use of Cardinal Frequencies is not mandated on SLIMbus.
1479 6.3 Control Space
1480 Control Space contains the information needed for a Device to discover the bus state (Framing Channel), to
1481 track Messages (Guide Channel), and the Messages themselves (Message Channel).
1482 The Control Space size is programmable by setting the Control Space width (number of Control Space
1483 Slots per Subframe) and the Subframe length. The number of Control Space Slots per Frame is given by the
1484 following equation:
1485 # of Slots per Frame = Control Space width in Slots * Frame length in Slots / Subframe length in
1486 Slots
1487 For example, if the Control Space width is eight Slots and the Subframe length is twenty-four Slots, then
1488 the number of Control Space Slots per Frame is:
1489 # of Slots per Frame = 8 Slots * 192 Slots per Frame / 24 Slots = 64 Slots/Frame
1490 The number of Control Space Slots per Superframe is just eight times the number of Control Space Slots
1491 per Frame since there are always eight Frames per Superframe. In the example, there would be 512 Slots of
1492 Control Space per Superframe.
1493 The Control Space width and Subframe length are not individually programmable, but are set as a single
1494 parameter known as the Subframe Mode. See Table 15 for the available Subframe Modes.

58
1495 The Framing Channel occupies two Slots per Frame and the Guide Channel occupies two Slots per
1496 Superframe for all bus configurations. Control Space Slots not used for the Framing Channel or Guide
1497 Channel are allocated to the Message Channel.
1498 Again, referring to the example, the number of Slots per Superframe allocated to the Message Channel is:
1499 # of Slots per Superframe = (64 Slots/Frame - 2 Framing Channel Slots/Frame) * 8

1500 Frames/Superframe - 2 Guide Channel Slots/Superframe = 494 Slots/Superframe
1501 Figure 22 illustrates how Control and Data Space Slots make up the first Frame of a Superframe for one
1502 particular Subframe configuration. Guide Channel Slots are allocated only for the first Frame of a
1503 Superframe.
1504
1505 Figure 22 Example Organization of Control and Data Space Slots
1506 6.3.1 Framing Channel
1507 The Framing Channel provides information about the state of the bus and helps define the Frame Structure.
1508 The Frame Sync symbol and Framing Information are sent in the Framing Channel. The Framing Channel
1509 shall occupy Slot 0 and Slot 96 of each Frame.
1510 The Frame Sync symbol is a fixed bit-sequence, 0b1011. The active Framer shall transmit the Frame Sync
1511 symbol once per Frame in Slot 0. Components shall use the Frame Sync symbol to lock onto the Frame
1512 Structure. See section 10.1.2.3 for additional information.
1513 The 32-bits of Framing Information contain all the data necessary for a Component to detect and verify the
1514 Subframe Mode, synchronize Device state machines and configure Components so they can properly
1515 communicate on the bus. See section 6.3.1.1 for additional information.
1516 The active Framer shall transmit four bits of Framing Information once per Frame in Slot 96. The complete
1517 Framing Information shall be sent in eight consecutive Frames.

59
1518 Figure 23 shows the relationship between the various Subframe lengths and the Frame size. Note that Slot 0
1519 and Slot 96 always occur at the start of a Subframe regardless of Subframe length.
Frame (192 Slots)

Subframes/
Frame
6
24
32
Frame Sync Symbol Framing Information

1520 Slot 0 Slot 96
1521 Figure 23 Overlap between Various Subframes
1522 6.3.1.1 Framing Information
1523 The 32-bit Framing Information is sent by the active Framer once per Superframe in eight consecutive
1524 Frames. Therefore, it takes 1536 Slots (6144 Cells) to acquire a set of Framing Information after a
1525 Component has locked onto the Frame Structure. Figure 24 shows the contents of the Framing Information
1526 Slots.
1527
1528 Figure 24 Distribution of Framing Information over Multiple Slots
1529 Framing Information shall include a flag FE and fields SM, CG, RF and R as shown in Figure 24. It shall
1530 also include a stripe S into which the active Framer encodes a Superframe Sync pattern, a Whitening Signal
1531 and a Phasing Signal. The coding shall be performed via the parity of the Slot 96 nibbles. For example, in
1532 the sixth Frame of the Superframe, the active Framer shall send S[2] as the exclusive-OR of SM[0], RF[2],

60
1533 R[2], and P[1]. A Receiver that uses the Phasing Signal shall decode P[1] as the exclusive-OR of SM[0],
1534 RF[2], R[2], and S[2]. Coding the stripe S moderates the worst case spectrum of the data waveform when
1535 the bus is carrying little or no traffic. This tends to reduce interference with analog circuitry. Coding of
1536 stripe S has no relation to detection and handling of errors in the Framing Information.
1537 The active Framer shall set the reserved bits, R[10:0], to all zeros. Components reading the Framing
1538 Information shall not use the contents of the reserved bits except to decode the stripe S.
1539 The information in fields SM, CG, and RF applies to the current Superframe only. A Component uses these
1540 fields to discover the bus configuration when joining the bus, and thereafter to verify the bus configuration
1541 on an ongoing basis. Changes shall be announced by the active Manager in the Message Channel using the
1542 process described in section 10.3.1. A change in Framing Information without such an announcement shall
1543 indicate an error condition on the bus. See section 10.2.4 for the proper response to such an error condition.
1544 6.3.1.2 Framing Extension Field
1545 The Framing Extension (FE) field signals the presence of specific Framing Information fields in the current
1546 Superframe. The active Framer shall set FE to 0 to indicate that the Subframe Mode (SM), Clock Gear
1547 (CG), Root Frequency (RF) and Reserved (R) fields are present in the current Superframe. If a Component
1548 receives a Superframe with FE=0, it shall obey all specified behaviors based on the SM, CG, and RF fields.
1549 If a Component receives a Superframe with FE=1, it shall assume the RF, CG, SM and R fields are absent
1550 in the current Superframe. Note, the stripe S is still considered valid when FE=1.
1551 The FE field shall have no effect on the mechanisms for acquisition and verification of the Frame
1552 synchronization. In addition, the FE field shall have no effect on the mechanism used for locking onto the
1553 Superframe Sync pattern. A Component that locks to the Superframe Sync pattern when FE=1 cannot
1554 determine the current Subframe Mode (SM) and therefore shall defer the process of acquiring Superframe
1555 synchronization and Message synchronization until the Subframe Mode has been indicated in the Framing
1556 Information.
1557 For the purposes of verifying Superframe synchronization, Components can only check the SM, CG, and
1558 RF fields against their internal record when those fields are present, i.e. when FE=0. The FE field shall
1559 have no effect on the mechanisms for acquisition and verification of Message synchronization.
1560 Note that the FE field differs from SM, CG, and RF fields in that it changes value without any prior
1561 announcement from the active Manager.
1562 6.3.1.3 Superframe Sync Pattern
1563 The Superframe Sync pattern is a punctured repeating pattern, 0X011XXX, that allows a Component to
1564 detect the beginning of a new Superframe. The active Framer shall encode the Superframe Sync pattern in
1565 stripe S of the Framing Information using the equations shown in Figure 24.
1566 Clock Receiving Components lock on to the Superframe Sync pattern. The process of acquiring and
1567 verifying Superframe synchronization is described in section 10.1.2.4.
1568 6.3.1.4 Subframe Mode Field
1569 The Subframe Mode encodes the Control Space width and Subframe length in a single field, SM[4:0], of
1570 the Framing Information.
1571 The active Framer shall transmit the Subframe Mode using the coding shown in Table 15.

61
1572 Table 15 Subframe Coding
Coding Control Space Width Subframe Length Comments

(SM[4:0]) (Slots) (Slots)
0b11111 24 32
0b11110 Reserved Reserved Same as 0b00000
0b11101 16 32
0b11100 16 24
0b11011 12 32
0b11010 12 24
0b11001 8 32
0b11000 8 24
0b10111 6 32
0b10110 6 24
0b10101 6 8
0b10011 4 32
0b10010 4 24
0b10001 4 8
0b10000 4 6
0b01111 3 32
0b01110 3 24
0b01101 3 8
0b01100 3 6
0b01011 2 32
0b01010 2 24
0b01001 2 8
0b01000 2 6
0b00111 1 32
0b00110 1 24
0b00101 1 8
0b00100 1 6
0b00000 8 8 100% Control Space, 0% Data Space

62
1573 The active Manager shall not configure the bus to use any Reserved Subframe Modes. A Component that
1574 observes a Reserved Subframe Mode coding in the Framing Information shall behave as specified in the
1575 Comments column in Table 15.
1576 The active Framer shall only change the Subframe Mode at the direction of the active Manager as specified
1577 in section 10.6.
1578 As the Subframe Mode determines the relative allocation of the Control Space and Data Space, the concept
1579 of Subframe length has no practical effect when the Frame Structure is fully allocated to the Control Space.
1580 Even though the 100% Control Space mode (0b00000) is labeled 8/8 in Table 15, it can also be thought
1581 of as 6/6, 24/24, or 32/32.
1582 6.3.1.5 Clock Gear Field
1583 The Clock Gear field, CG[3:0], in the Framing Information shall be encoded as shown in Table 16.
1584 Table 16 SLIMbus Frequencies and Clock Gear Coding
Coding Clock Gear Minimum Frequency Maximum Frequency

(CG[3:0]) (MHz) (MHz)
0b0000 Not Indicated 0 28.8
0b0001 1 0.025 0.05625
0b0010 2 0.05 0.1125
0b0011 3 0.1 0.225
0b0100 4 0.2 0.45
0b0101 5 0.4 0.9
0b0110 6 0.8 1.8
0b0111 7 1.6 3.6
0b1000 8 3.2 7.2
0b1001 9 6.4 14.4
0b1010 10 12.8 28.8
0b1011
0b1100
0b1101 Reserved Reserved Reserved
0b1110
0b1111
1585 A Device that observes a Not Indicated or Reserved code in the Framing Information, and does not
1586 have independent knowledge of the CLK line frequency, should disable any functionality that depends on
1587 the CLK line being within a particular range of frequencies.
1588 The active Manager shall not configure the bus to use any Reserved Clock Gear values. A Component
1589 that observes a Reserved Clock Gear coding in the Framing Information shall behave as if it received a
1590 Not Indicated Clock Gear code.
1591 The active Framer shall only change the Clock Gear at the direction of the active Manager as specified in
1592 section 10.5.

63
1593 6.3.1.6 Root Frequency Field
1594 Shared knowledge of the Root Frequency allows simple, low-cost programming of frequency-sensitive
1595 Components. Components can use the Root Frequency field, RF[3:0], to verify that they are at the
1596 Cardinal, or any other preferred, frequency. The Root Frequency field also allows more complex
1597 Components to generate internal clocks without resorting to User Messages for configuring internal clock
1598 generation circuits.
1599 The Root Frequency of SLIMbus indicates the frequency of the CLK line as if the bus were in Gear 10. The
1600 Root Frequency field, RF[3:0], in the Framing Information shall indicate the Root Frequency of the bus as
1601 coded in Table 17. Together with the Clock Gear field, the Root Frequency enables a Component to
1602 identify the frequency of the SLIMbus CLK line.
1603 Table 17 Root Frequency
RF[3:0] Root Frequency Phase Modulus

(MHz) (PM)
(see section 6.3.1.8)
0b1111
0b1110
0b1101
Reserved Reserved
0b1100
0b1011
0b1010
0b1001 27 5625
0b1000 26 8125
0b0111 25 15625
0b0110 24 625
0b0101 19.2 125
0b0100 16.8 875
0b0011 15.36 100
0b0010 22.5792 147
0b0001 24.576 160
0b0000 Not Indicated defaults to 160
1604 The Not Indicated code denotes that the operating frequency is either unknown or not listed in Table 17.
1605 If the Clock Gear is indicated while the Root Frequency is not indicated, a Component does not know the
1606 SLIMbus CLK frequency. A Component may assume that the Cardinal Frequency in the current Clock
1607 Gear is in use. A Device that requires knowledge of the SLIMbus CLK frequency might not function
1608 properly if the frequency information is not indicated. Refer to section 6.2.6 for more information on
1609 Cardinal Frequencies.
1610 The active Manager shall not configure the bus to use any Reserved Root Frequency values. A
1611 Component that observes a reserved Root Frequency coding in the Framing Information shall behave as if
1612 it received a Not Indicated Root Frequency code.

64
1613 The active Manager should ensure that the Root Frequency is set to Not Indicated (0b0000) whenever the
1614 Clock Gear is set to Not Indicated (0b0000).
1615 The active Framer shall only change the Root Frequency at the direction of the active Manager as specified
1617 6.3.1.7 Whitening Signal
1618 The Whitening Signal is encoded in stripe S of the Framing Information as shown in Figure 24. It helps to
1619 keep the autocorrelation properties and electromagnetic spectrum of the data waveform reasonably benign
1620 at all times. This tends to ease mixed-signal Component design and system integration.
1621 The active Framer shall write a sequence having appropriate properties to the Whitening Signal.
1622 Specifically, the absolute values of the sequence's autocorrelation coefficients shall be less than 0.1 for all
1623 lags from 1 up to at least 14. For example, any maximum length sequence of length 15 or more may be
1624 used.
1625 A Clock Receiving Component is not required to make use of the Whitening Signal. Therefore, it may
1626 choose not to decode S6 of stripe S.
1627 6.3.1.8 Phasing Signal
1628 In some cases, all of the various SLIMbus-connected processes can be synchronized via the bus's
1629 Superframes or Root Superframes. For example, when the bus is operating at any of the Cardinal
1630 Frequencies its Root Superframes constitute a 4 kHz frequency-and-phase reference. In a basic telecoms
1631 system this might be the only timing reference that is required.
1632 However, some applications need either a different timebase or a broader idea of time. To support such
1633 applications, a 25 Hz timing reference is embedded in the Framing Channel. 25 Hz has been chosen partly
1634 because it is the highest common factor of the more-common audio sample rates. Additionally, it provides
1635 a good foundation for timecode.
1636 Using a simple per-Superframe flag to carry the timing reference would be impractical. The flag would
1637 toggle at the beat frequency of the Superframe rate and 25 Hz. When the bus clock runs at 13 MHz for
1638 example, this beat frequency is approximately 0.26 Hz. To obtain much higher update rates, the timing
1639 reference is instead communicated via numbers called Phase Snapshots. These are carried in the Phasing
1640 Signal.
1641 The concept of Root Superframe numbering is fundamental to the Phasing Signal. The Root Superframes
1642 (section 6.2.4) are conceptually numbered from 0 upwards, modulo a value called the Phase Modulus, PM.
1643 The numbering is such that the start of every Root Superframe 0 is also the start of a cycle of the 25 Hz
1644 timing reference. To achieve this, the Root Superframe rate divided by PM must be a unit fraction of 25,
1645 i.e. 25/N, where N is an integer. Therefore, the appropriate value for PM depends on the Root Frequency.
1646 For example, if the Root Frequency is 24 MHz, a value of 625 is appropriate. The Root Superframe rate
1647 divided by PM is then 24000000/(6144 * 625) = 6.25, which is 25/4. Table 17 specifies the PM values that
1648 shall be used at particular Root Frequencies. A Device may use a value different than the one in the table
1649 for Not Indicated. Mechanisms for changing the Not Indicated PM value are beyond the scope of this
1650 document.
1651 The Phasing Signal consumes two Cells per Superframe. These Cells are designated P1 and P0 and are
1652 shown alongside the other Framing Information in Figure 24.
1653 The active Framer shall generate the Phasing Signal and group the Superframes into consecutive blocks of
1654 ten. Within each Superframe block, the active Framer shall organize the Phasing Signal as shown in Figure
1655 25.

65
P1 P0
First Superframe
0 PS[13]
of Block
PS[12] PS[11]
0 PS[10]
1 PS[9]
1 PS[8]
1 PS[7]
PS[6] PS[5]
Symbol Key
Superframe Block
PS[4] PS[3] 0
Sync Symbol
PS[2] PS[1] SV Snapshot Valid
Last Superframe PS Phase Snapshot

PS[0] SV
of Block
1656
1657 Figure 25 Phasing Signal Contents
1658 The Superframe Block Sync symbol is a punctured repeating pattern, 0X0111XXXX, that allows a
1659 Component to determine the block boundaries. Once a Component determines the block boundaries, it can
1660 then access the Snapshot Valid, SV, and Phase Snapshot, PS[13:0], fields.
1661 If the active Framer knows PS field contains valid information, it shall set the SV field to 1, otherwise it
1662 shall set the SV field to 0. A Component that observes SV=0 shall ignore the contents of the PS field.
1663 A valid PS field shall contain the number of the first Root Superframe in the following block, calculated
1664 with the assumption that there will be neither a Root Frequency change nor a Clock Pause at the start of
1665 that block. Figure 26 shows an example of the Phasing Signal with valid and invalid PS fields.

66
Root Superframe Root Superframe Root Superframe Root Superframe Root Superframe
#34 #54 #74 #118 #158
Root Superframes
20 30 40 50 60 70 80 90 100 110 120 130 140 150
Superframes
Phasing Signal Valid PS Valid PS Invalid PS Valid PS Valid PS

Blocks =34 =54 (74) =118 =158
Gear 9 Gear 8
1666
1667
1668 Figure 26 Phase Snapshot Example
1669 In Gear 9, the Phase Snapshots increment by twenty because there are two Root Superframes per
1670 Superframe and ten Superframes in a Superframe block. In Gear 8 there are four Root Superframes per
1671 Superframe so the increment increases to forty, in Gear 7 the increment is eighty, and so on.
1672 The active Framer may transmit SV=0 in blocks that span or immediately follow a Clock Gear change, a
1673 Root Frequency change or a Clock Pause. In all other blocks it shall transmit a valid Phase Snapshot with
1674 SV=1, except when the current Clock Gear is "Not Indicated" in which case it shall transmit
1675 PS[13:0]=0x0000 and SV=0. See section 6.3.1.5.
1676 An active Framer may adopt the following procedure for generating a legal Phasing Signal. In each
1677 Superframe block:
1678 Transmit PS = (PHASEblock + 10 * 2(10-CG)) % PM.
1679 where PHASEblock is the number of the first Root Superframe in the block, CG is the Clock Gear
1680 during that Root Superframe, and PM is the Phase Modulus during that Root Superframe.
1681 If a Clock Gear change, Root Frequency change or Clock Pause takes place during the block,
1682 transmit SV=0, else transmit SV=1.
1683 This procedure avoids the need for intelligent look-ahead. In Figure 26 for example, the value of 74 for the
1684 third Phase Snapshot would have been valid if the Clock Gear change had not taken place. Because the
1685 Clock Gear change did take place, the Phase Snapshot is invalid. The active Framer simply sends SV=0 in
1686 this Superframe block.
1687 A Component that uses the Phasing Signal shall maintain its own internal count of Root Superframes.
1688 When such a Component acquires Superframe synchronization it shall watch for the next valid Phase
1689 Snapshot in the Phasing Signal. It shall initialize its internal Root Superframe count to that Phase Snapshot
1690 at the end of the corresponding block of Superframes. Thereafter, in normal operation the Component shall
1691 autonomously maintain its count of Root Superframes. It shall do this either by incrementing the count
1692 every 6144/2(10-CG) Cells and wrapping it when it gets to PM, or in any way that results in the same
1693 externally observable behavior.
1694 In normal operation the Component shall additionally check its internal count of Root Superframes against
1695 all the valid Phase Snapshots that it receives. It shall ignore isolated mismatches, but shall re-align its phase
1696 if it sees mismatches with two consecutive valid Phase Snapshots. It shall do this by initializing its internal
1697 Root Superframe count to the second of those Phase Snapshots at the end of the corresponding block of

67
1698 Superframes. A Component that uses the Phasing Signal shall set its internal count of Root Superframes to
1699 zero whenever it observes a Root Frequency change, i.e. at a Reconfiguration Boundary where a
1700 NEXT_ROOT_FREQUENCY Message takes effect. The Root Superframe that immediately follows such a
1701 Reconfiguration Boundary shall be labeled number 0.
1702 6.3.2 Guide Channel
1703 The Guide Channel provides the necessary information for a Component to acquire and verify Message
1704 synchronization in the Message Channel. The Guide Channel occupies two Slots (one Slot-pair) per
1705 Superframe. These Slots are in Frame 0 for all bus configurations. The corresponding Slots in Frames 1 to
1706 7 are allocated to the Message Channel.
1707 The Guide Byte is the only information sent in the Guide Channel and shall be carried in the Superframe
1708 Slots as shown in Table 18.
1709 Table 18 Guide Channel Slots
Control Space Width GB[7:4] GB[3:0]

1 Slot SL of the Superframe Slot 2*SL of the Superframe
2 Slot 1 of the Superframe Slot SL of the Superframe
3 or greater Slot 1 of the Superframe Slot 2 of the Superframe
1710 Notes
1711 GB is the Guide Byte
1712 SL is the Subframe length in Slots
1713 A Device in a Component shall not participate in the Message Channel until the Component has used the
1714 Guide Channel to achieve Message synchronization. Subsequently, the Component shall monitor the Guide
1715 Channel every Superframe to verify that it remains in, or if necessary reacquires, Message synchronization.
1716 Refer to section 8.1 for detailed information on the construction and use of the Guide Channel.
1717 6.3.3 Message Channel
1718 The Message Channel consists of the Control Space Slots that are not used by the Framing Channel or the
1719 Guide Channel. Devices on the bus use the Message Channel to communicate with each other by means of
1720 the Message Protocol defined in section 8. In order to transmit Messages, a Device uses a priority-based
1721 mechanism to gain access to the Message Channel. Refer to section 10.11 for more information on policies
1722 for Message Channel priorities.
1723 6.3.3.1 Message Channel Size
1724 The size of the Message Channel varies according to the bus configuration.
1725 The minimum number of Control Space Slots per Superframe arises in the case where the Subframe length
1726 is 32 Slots (6 Subframes/Frame) and just one Slot per Subframe is allocated to Control Space. This
1727 condition yields:
1728 # of Slots per Superframe = 1 Slot/Subframe * 6 Subframes/Frame * 8 Frames/Superframe = 48

1729 Slots/Superframe

68
1730 For each Superframe, 16 Slots of the Control Space are used for the Framing Channel (two Slots per
1731 Frame) and two Slots are used for the Guide Channel. Therefore, the minimum number of Slots available
1732 for the Message Channel is:
1733 # of Slots = (48 Slots - 16 Slots - 2 Slots)/Superframe = 30 Slots/Superframe
1734 The maximum number of Control Space Slots per Superframe is given by the equation:
1735 # of Slots = 192 Slots/Frame * 8 Frames/Superframe =1536 Slots/Superframe
1736 Substituting 1536 Slots in the calculation for the number of Message Channel Slots yields:
1737 # of Slots = (1536 Slots - 16 Slots - 2 Slots)/Superframe = 1518 Slots/Superframe
1738 Thus, in a Superframe, the number of Slots available to the Message Channel ranges from 30 to 1518. A
1739 number of intermediate Message Channel sizes are available given the various Subframe Mode options
1740 shown in Table 15.
1741 6.4 Data Space
1742 Slots not explicitly allocated to Control Space are considered Data Space. The active Manager can organize
1743 these Slots into Data Channels to transport application-specific data streams between Devices on the bus.
1744 Data Space can contain up to 256 Data Channels.
1745 A Data Channel is a stream of one or more contiguous Slots organized in a consistent data structure that
1746 repeats at a fixed interval. The largest possible group of contiguous Slots within a Data Channel is known
1747 as a Segment. The interval that the Segment repeats is known as the Segment Interval. The distance, in
1748 Slots, of the first Slot of the Segment from the first Slot (Slot 0) of the Superframe is known as the Segment
1749 Offset.
1750 A Data Channel is uniquely determined by its Segment Length, Segment Interval, and Segment Offset. As
1751 such, a Data Channel can be viewed as a virtual bus with its own bandwidth guarantee and latency.
1752 6.4.1 Segment Organization

Not Used
1753
1754 Figure 27 Segment Organization
1755 A Segment is composed of three fields called the TAG, AUX, and DATA fields. Note the TAG and AUX
1756 fields are optional and may be omitted. These fields shall be organized within the Segment as shown in
1757 Figure 27. The exact composition of the Segment depends on the Transport Protocol. Refer to section 9.3
1758 for information on Transport Protocols.

69
1759 The Segment structure shall be MSB aligned within the Segment. If the Segment Length is longer than the
1760 combined length of the TAG, AUX and DATA fields then the Slots after the DATA field are unused. The
1761 source Device shall not drive, and a sink Device shall ignore, the unused Slots.
1762 6.4.2 Data Channel Properties
1763 A Data Channel is defined by three parameters: the Segment Interval, the Segment Offset and the Segment
1764 Length.
1765 The Segment Interval is defined as the number of Slots between the first Slot of a Segment and the first
1766 Slot of the next consecutive Segment in a Data Channel. The Segment Interval shall be constant throughout
1767 the Superframe. The Segment Interval is not inherently constrained by the Frame or Subframe length. A
1768 Data Channel may have multiple Segments in some or all of its Subframes.
1769 The Segment Offset is defined as the number of Slots between the Superframe boundary at the start of a
1770 Superframe and the first Slot of the first Segment in a Data Channel within that Superframe. The Segment
1771 Offset shall be less than the Segment Interval. For example, a Data Channel with a Segment Offset of 200
1772 has its first Slot per Superframe in Slot 8 of Frame 1 and has a Segment Interval greater than 200.
1773 The Segment Length is defined as the number of Slots per Segment in a Data Channel and shall be encoded
1774 as shown in Table 19. A Device shall not send a reserved Segment Length code. A Device that receives a
1775 reserved Segment Length code shall behave as if there are no Slots allocated to that Data Channel.
1776 Table 19 Segment Lengths
Segment Length (Slots) Segment Length Code (SL[4:0])

1 to 31 0b00001 to 0b11111
Reserved 0b00000
1777 A fourth parameter, the Channel Rate Multiplier is defined as the number of Segments per Superframe.
1778 Since the Superframe length is fixed (1536 Slots), the Segment Interval directly determines the Channel
1779 Rate Multiplier. See Table 20.
1780 A Slot shall be allocated to only one Data Channel at a time. Data Channels shall not overlap.
1781 The Segment Offset and the Segment Length are constrained by the current Subframe Mode.
1782 A Component with an output Port shall not allow that Port to drive the DATA line during Slots allocated to
1783 Control Space, even if the Component receives a Data Channel definition that overlaps Control Space.
1784 Together the Segment Interval and Segment Offset of a Data Channel are referred to as its Segment
1785 Distribution. The Segment Distribution shall be coded as shown in the Segment Distribution Code
1786 column of Table 20. In the table, 'SN' refers to bit N of the Segment Offset value. This coding is used by the
1787 NEXT_DEFINE_CHANNEL Message (see sections 11.4.9) and relies on the fact that when the Segment
1788 Interval is a multiple of three, the two MSBs of the Segment Offset can only be 0b00, 0b01, or 0b10. This
1789 leaves 0b11 for identifying a Data Channel with a Segment Interval that is not a multiple of three.
1790 For example, the first row of the table covers the 1536 different distributions that have a Segment Interval
1791 of 1536 Slots. The eleventh row covers the 512 different distributions that have a Segment Interval of 512
1792 Slots. Together these rows consume 2048 Segment Distribution codes, i.e. 0bXX1XXXXXXXXX.
1793 A Device shall not send a reserved Segment Distribution code. A Device that receives a reserved Segment
1794 Distribution code shall behave as if SD=0b000000000000.

70
1795 Table 20 Segment Distributions
Segment Interval Channel Rate Multiplier Segment Distribution Code

(Slots) (Segments per Superframe) SD[11:0]
1536 1 S10S9 1 S8S7S6S5S4S3S2S1S0
768 2 S9S8 0 1 S7S6S5S4S3S2S1S0
384 4 S8S7 0 0 1 S6S5S4S3S2S1S0
192 8 S7S6 0 0 0 1 S5S4S3S2S1S0
96 16 S6S5 0 0 0 0 1 S4S3S2S1S0
48 32 S5S4 0 0 0 0 0 1 S3S2S1S0
24 64 S4S3 0 0 0 0 0 0 1 S2S1S0
12 128 S3S2 0 0 0 0 0 0 0 1 S1S0
6 256 S2S1 0 0 0 0 0 0 0 0 1 S0
3 512 S1S0 0 0 0 0 0 0 0 0 0 1
512 3 1 1 1 S8S7S6S5S4S3S2S1S0
256 6 1 1 0 1 S7S6S5S4S3S2S1S0
128 12 1 1 0 0 1 S6S5S4S3S2S1S0
64 24 1 1 0 0 0 1 S5S4S3S2S1S0
32 48 1 1 0 0 0 0 1 S4S3S2S1S0
16 96 1 1 0 0 0 0 0 1 S3S2S1S0
8 192 1 1 0 0 0 0 0 0 1 S2S1S0
4 384 1 1 0 0 0 0 0 0 0 1 S1S0
2 768 1 1 0 0 0 0 0 0 0 0 1 S0
Reserved Reserved 110000000001
0 000000000000
1796 6.4.3 Data Channel Definition Example (informative)
1797 Figure 28 shows an example SLIMbus bandwidth allocation for the first Frame of a Superframe. Each
1798 number represents a Slot where 0 is the first Slot of the Superframe.

71
1799
1800 Figure 28 Data Channel Organization Example
1801 The Control Space has a width of two Slots (8 Cells) and the Subframe length is eight Slots (32 Cells). This
1802 configuration corresponds to a Subframe Mode of 0b01001.
1803 The Data Channel shown in the figure has the following attributes:
1804 Segment Length: 2
1805 Segment Offset: 4
1806 Segment Interval: 16
1807 Consequently, the Data Channel is allocated using:

1808 Segment Length: 0b00010
1809 Segment Distribution: 0b110000010100
1810 Note that a Data Channel has equidistant spacing throughout the Frame. This typically helps minimize
1811 buffering requirements as channel latency is consistent between Segments. Also, for a given Clock Gear, a
1812 Data Channel has a constant number of Segments per Superframe.

72
1813 6.4.4 Segment Timing Model
1814 Section 6.4.1 introduces the general structure of a Segment and section 6.4.2 describes how Data Channels
1815 are allocated in the Frame Structure. The following three subsections describe an application model for
1816 how Segments are handled before and after they are carried on SLIMbus.
1817 Components that support Data Channels shall behave like the model.
1818 6.4.4.1 Segment Windows and Segment Window Boundaries
1819 A Segment Window is defined as the range of Slots that a given Data Channels Segment could possibly be
1820 located (ignoring overlap with the Control Space Slots). A Data Channel with a Segment Interval of M has
1821 1536/M Segment Windows per Superframe where each Segment Window has a length of M Slots. The first
1822 Segment Window in a Superframe shall start at Slot 0 of the Superframe with each successive Segment
1823 Window beginning M Slots later.
1824 A Segment Window Boundary is defined to be the time instant that one Segment Window ends and the
1825 next Segment Window begins. For each Data Channel with a unique Segment Interval, there are a set of
1826 Segment Windows and a corresponding set of Segment Window Boundaries. Note that the beginning of a
1827 Superframe shall be a Segment Window Boundary because it denotes the start of the first Segment Window
1828 in a Superframe. Moreover, the Superframe boundary shall be a Segment Window Boundary for all Data
1829 Channels regardless of their Segment Intervals. Even though different Segment Windows may have
1830 different lengths, there is always an integer number of Segment Windows per Superframe.
1831 If data is present, a Port shall buffer a Segments data during its Segment Window. The Segment Data shall
1832 be released to its destination at the next Segment Window Boundary.
1833 6.4.4.2 Segment Window Boundary Example (informative)
1834 Figure 29 shows an example of Segment Window Boundaries and Segment Windows. For a specific bus
1835 configuration and Data Channel allocation, the effect of the Segment Windows and Segment Window
1836 Boundaries is discussed.

73
1837
1838 Figure 29 Segment Windows and Segment Window Boundaries Example
1839 Figure 29 shows all 1536 Slots in a Superframe where each box represents one Slot. In this example, the
1840 Subframe length is 32 Slots, i.e. 48 Subframes per Superframe, and the Control Space width is four Slots.
1841 Both Data Channels have a Segment Interval of 512 Slots and therefore three Segments per Superframe.
1842 The data for the Segments that will be transmitted in Segment Window 2, must be available at Segment
1843 Window Boundary 1. That same data must be available to the sink at Segment Window Boundary 2.
1844 As a consequence of the requirements on releasing data only on Segment Window Boundaries, Data
1845 Channels can be moved within a Segment Window without altering the latency of a single Segment. Thus,
1846 Data Channels can be moved seamlessly within the Frame Structure.

74
1847 6.4.4.3 Repeatable Latency
1848 To avoid phase issues between related Data Channels, consideration is given to the latency involved within
1849 the Device itself. That is, the latency that occurs before an output Port passes a Segment to the Frame Layer
1850 and the latency that occurs after an input Port passes up a Segment to a Device. These latencies are defined
1851 to be repeatable if the latency is consistent from occurrence to occurrence.
1852 A Data Channel using the Isochronous Transport Protocol has repeatable latency if its source Device and
1853 sink Devices all have repeatable latency at every Segment Window Boundary.
1854 A Data Channel using the Locked Transport Protocol has repeatable latency if its source Device and sink
1855 Devices all have repeatable latency at the start of every Root Superframe 0.
1856 Achieving repeatable latency with the Pushed and Pulled Transport Protocols is more involved. For
1857 instance, the source Device and sink Devices must have repeatable latency at the instant that they start
1858 carrying the Data Channel.
1859

75
1860 7 Information Elements and Value Elements

1861 Information and Value Elements are data stores used to hold status, configuration or other important
1862 information needed by a Device. An Element can hold a simple Boolean value or a more complex,
1863 multistate value.
1864 7.1 Information Elements
1865 Three categories of Information Element are defined: Core, Class-specific and User.
1866 Core Information Elements contain the same type of information for all Devices of all Device Classes.
1867 Element Codes used to access the Information Elements address the same Device information regardless of
1868 Device Class.
1869 Class-specific Information Elements contain the same type of information for all Devices of a particular
1870 Device Class, but may be different for Devices of a different Device Class. Element Codes used to access
1871 the Information Elements may address different Device information for each Device Class.
1872 User Information Elements contain information that is specific to a specific product or product family. User
1873 Information Elements and their Element Codes are beyond the scope of this document.
1874 The Information Elements are organized into an Information Map that has three one-kilobyte regions as
1875 shown in Figure 30. The figure also shows the associated Byte Address values. Byte Addresses in the range
1876 0xC00 to 0xFFF are reserved. A Device shall not transmit a Reserved Byte Address. Section 10.12.2
1877 mandates particular behavior for a Device that receives data requests containing Byte Addresses in the
1878 reserved range.
1879
1880 Figure 30 Information Map

76
1881 Information Elements shall be located in the appropriate region of the Information Map. They shall not
1882 overlap other Information Elements in the map. Each Information Element shall occupy no more than
1883 sixteen bytes of the Information Map address space.
1884 There are two methods of accessing Information Elements, byte-based access and elemental access. Note
1885 that a Device is typically required to support only byte-based accesses.
1886 Byte-based accesses are analogous to generic memory reads and writes. The Element Code for such
1887 accesses includes the Byte Address of the first byte plus an indication of the number of bytes to be
1888 transferred (the Slice Size). For example, when the Byte Address is N and the Slice Size is two, the bytes at
1889 N and N+1 are transferred. When vacant parts of the Information Map are transferred using byte-based
1890 accesses, they shall appear as zeros.
1891 Figure 31 and Table 21 show the structure and interpretation of the Element Codes that shall be used for
1892 byte-based accesses.
1893
1894 Figure 31 Element Code for Byte-based Access
1895 Table 21 Slice Size
SS[2:0] Slice Size (bytes)

0b000 1
0b001 2
0b010 3
0b011 4
0b100 6
0b101 8
0b110 12
0b111 16
1896 In elemental accesses, the Element Code uniquely identifies a single Information Element.
1897 Figure 32 shows the structure of the Element Codes that shall be used for elemental accesses. Here the Byte
1898 Address and the Bit Number together point to the Information Element's lowest bit, i.e. the one with the
1899 lowest address in the Information Map. The size of the Information Element is not expressed.
1900
1901 Figure 32 Element Code for Elemental Access
1902 As indicated in Figure 31 and Figure 32, EC[3] is one for byte-based accesses and zero for elemental
1903 accesses.

77
1904 Each Element Code defines a slice of the Information Map. This is referred to as an Information Slice. In a
1905 byte-based access, the Information Slice is a whole number of bytes long and can contain multiple
1906 Information Elements. In an elemental access, the Information Slice contains a single Information Element
1907 and has the same length as the Information Element.
1908 As specified in section 10.12.2, Information requests may be handled with abbreviated replies in which the
1909 Message Payload contains only a Transaction ID.
1910 A Device is not required to support both byte-based and elemental access methods except as provided in its
1911 Device Class definition. Typically, a Device supports only the byte-based access method.
1912 7.1.1 Types of Information Elements
1913 An Information Element that is only capable of being in one of two states is referred to as a Boolean
1914 Information Element. A Boolean Information Element shall obey the following rules:
1915 it shall be coded on one bit
1916 the logic value zero (0) shall indicate that it is in its FALSE condition
1917 the logic value one (1) shall indicate that it is in its TRUE condition
1918 the expression cleared shall mean that the value of the bit is made to the FALSE condition
1919 the expression set shall mean that the value of the bit is made to the TRUE condition
1920 if not implemented, it shall behave as if its value is FALSE
1921 An Information Element that is capable of being in more than two states is referred to as Enumerated
1922 Information Element. An Enumerated Information Element shall obey the following rules:
1923 the expression cleared shall mean that the value of all bits is returned to the specified default
1924 value
1925 if not implemented, it shall behave as if it possesses the fixed value of all zeroes (0)
1926 7.1.2 Core Information Elements
1927 This section defines the Core Information Elements. It does not specify whether implementation of the
1928 Information Elements is mandatory or optional, or whether accesses of them are byte-based, elemental or
1929 both. Information Element support requirements are specified separately for each Device Class in the
1930 various Device Class definitions.
1931 Table 22 Core Information Elements
Name Description Type Size Byte Address,

(bits) Bit Number of
lowest bit
DEVICE_CLASS Indicates the Device's Device read-only 8 0x009, 0
Class
DEVICE_CLASS_VERSION Version of the Device Class read-only 8 0x008, 0
definition
EX_ERROR There has been a Message clearable 1 0x000, 3
execution error
RECONFIG_OBJECTION The Device objects to the bus read-only 1 0x000, 2
reconfiguration

78
Name Description Type Size Byte Address,

(bits) Bit Number of
lowest bit
DATA_TX_COL A Collision was detected in a clearable 1 0x000, 1
Data Channel
UNSPRTD_MSG An unsupported Message has clearable 1 0x000, 0
been received
1932
1933 The Core Information Elements are listed in Table 22. Each of the Core Information Elements shall have
1934 the attributes identified for it in Table 22.
1935 Each clearable Information Element in Table 22 shall be cleared by each of the following occurrences:
1936 the Component undergoing boot as described in section 10.1.
1937 the Device being reset by a Device Reset, a Component Reset or a Bus Reset (section 10.4)
1938 the Information Element being a target of an appropriately formulated
1939 REQUEST_CLEAR_INFORMATION or CLEAR_INFORMATION Message
1940 7.1.2.1 DEVICE_CLASS
1941 The DEVICE_CLASS Information Element shall be equal to the Device Class Code of the Device.
1942 7.1.2.2 DEVICE_CLASS_VERSION
1943 The DEVICE_CLASS_VERSION Information Element shall be equal to the version of the Device Class
1944 implemented by the Device.
1945 7.1.2.3 EX_ERROR
1946 EX_ERROR is a clearable Boolean Information Element that indicates there has been an execution error
1947 related to Message sequencing or to a Message parameter value. Details can be found in section 11.6.
1948 The Information Element shall be set only when the Device containing the Information Element receives a
1949 Message that is supported, but that fails one or more sequence or parameter checks
1950 7.1.2.4 RECONFIG_OBJECTION
1951 RECONFIG_OBJECTION is a read-only Boolean Information Element that indicates when a Device
1952 objects to the announced bus reconfiguration. A Device that supports RECONFIG_OBJECTION shall set
1953 the Information Element to TRUE while it is unable to implement all of the bus reconfiguration
1954 announcements (section 11.4) that is has received since the last BEGIN_RECONFIGURATION Message.
1955 The Device shall otherwise clear RECONFIG_OBJECTION.
1956 7.1.2.5 DATA_TX_COL
1957 DATA_TX_COL is a clearable Boolean Information Element that indicates when a Collision has been
1958 detected in a Data Channel. The Device shall set DATA_TX_COL whenever the Component the Device
1959 resides within detects a DATA line Collision while one of the Device's Ports is writing to a Data Channel.
1960 See section 10.2.2 for more information.
1961 DATA_TX_COL shall always return FALSE if a Device does not implement any Ports.

79
1962 7.1.2.6 UNSPRTD_MSG
1963 UNSPRTD_MSG is a clearable Boolean Information Element that indicates when an unsupported Message
1964 has been received by a Device. The Device shall set UNSPRTD_MSG whenever it receives a non-
1965 broadcast Message that it does not implement as a Destination.
1966 7.1.3 Reporting Core Information
1967 This section provides guidelines for reporting the value of Core Information Elements to another Device.
1968 Some of the conditions listed in here should not occur during normal operation. However, during initial
1969 application development, these conditions can occur quite frequently. Reporting these conditions is
1970 intended primarily to aid debug efforts.
1971 7.1.3.1 UNSPRTD_MSG
1972 Reception of an unsupported Message is most likely the result of a procedural error and does not normally
1973 occur during bus operation. If this Information Element is set, a Device should send a
1974 REPORT_INFORMATION Message that includes byte 0x000 of the Information Map to the active
1975 Manager. The Device may send the same Message to the source Device that sent the unsupported Message.
1976 7.1.3.2 EX_ERROR
1977 Detection of an execution error is most likely the result of a procedural error and does not normally occur
1978 during bus operation. If this Information Element is set, a Device should send, at the earliest opportunity, a
1980 Manager.
1981 7.1.3.3 DATA_TX_COL
1982 Detection of a Collision in Data Space is most likely the result of a glitch on the DATA line, though it
1983 could also be caused by erroneously overlapping definitions of Segment Distributions. If this Information
1984 Element is set, a Device should send, at the earliest opportunity, a REPORT_INFORMATION Message
1985 that includes byte 0x000 of the Information Map to the active Manager.
1986 7.1.3.4 RECONFIG_OBJECTION
1987 If a Device chooses to object to an intended reconfiguration, the Device may send a
1989 Manager.
1990 There can be deterministic timing advantages in designing a system in which the active Manager polls the
1991 RECONFIG_OBJECTION Information Elements of Devices that it knows have the capacity to analyze and
1992 object to reconfiguration.
1993 7.1.3.5 DEVICE_CLASS
1994 This Information Element is fixed and should not be reported by the REPORT_INFORMATION Message
1995 in normal bus operation.
1996 7.1.3.6 DEVICE_CLASS_VERSION
1998 in normal bus operation.

80
1999 7.2 Value Elements
2000 Value Elements are typically parameters that are used to configure Device behavior. The Value Elements
2001 are organized into a Value Map. Just like the Information Map (section 7.1) the Value Map has three one-
2002 kilobyte regions as shown in Figure 33. Byte Addresses in the range 0xC00 to 0xFFF are reserved. A
2003 Device shall not transmit a Reserved Byte Address. Section 10.12.2 mandates particular behavior for a
2004 Device that receives data requests containing Byte Addresses in the reserved range.
2005
2006 Figure 33 Value Map
2007 Value Elements shall be located in the appropriate region of the Value Map. They shall not overlap other
2008 Value Elements in the map. Each Value Element shall occupy no more than sixteen bytes of the Value Map
2009 address space.
2010 There is no requirement for a Device to use the entire Byte Address range. In addition, there is no required
2011 mapping between a Devices Byte Addresses and any internal memory map within a Component.
2012 Value Messages use a 16-bit Element Code to identify a Value Slice. Byte-based and elemental accesses
2013 are possible. The structure and meaning of the Element Codes shall be the same as described in section 7.1.
2014 When vacant parts of the Value Map are transferred using byte-based accesses, they shall appear as zeros.
2015 Each Element Code defines a slice of the Value Map, referred to as a Value Slice. In a byte-based access,
2016 the Value Slice is a whole number of bytes long and can contain multiple Value Elements. In an elemental
2017 access, the Value Slice contains a single Value Element and has the same length as the Value Element.
2018 As specified in section 10.12.2, a Value REQUEST Message may be handled with an abbreviated REPLY
2019 Message in which the Message Payload contains only a Transaction ID.
2020

81
2021 8 Message Protocol and Tracking

2022 This section defines the Message Protocol used by Devices to exchange Messages. The Message Protocol
2023 consists of the Message Channel, which carries Messages between Devices, the Guide Byte, which contains
2024 the necessary information for Components to synchronize with the Message Channel, the Guide Channel,
2025 which carries the Guide Byte, and a set of behaviors that describe the flow of Messages between Devices.
2026 A Message is an integer number of bytes in length, ranging from a minimum of six to a maximum of
2027 thirty-nine bytes. Fields are provided for channel arbitration, source and destination addresses, Message
2028 contents (payload), Message integrity and acknowledgement. The Message syntax is described in section
2029 8.2.
2030 The Guide Byte contains fields so that a Device can determine the location of Messages within the Message
2031 Channel, and the integrity of the Guide Byte. The Guide Byte fields are described in sections 8.1.1 through
2032 8.1.3.
2033 Since two Slots are required to carry a byte, the Message Channel and the Guide Channel are organized as
2034 streams of Slot-pairs. These channels always occupy an even number of Slots in a Frame.
2035 Both Slots of a Message Channel Slot-pair are always contained within a single Frame, though they can be
2036 in different Subframes. When a Message is put into the Message Channel, the Message is byte justified to a
2037 Slot-pair, i.e. the first Cell of the Slot-pair holds the first bit of the Message. The Message Channel is
2038 described in section 6.3.3.
2039 The Guide Channel occupies a predetermined set of Slots within a Superframe as described in section 6.3.2.
2040 These Slots are located so that the Guide Channel Slot-pair never falls between the Slots of a Message
2041 Channel Slot-pair.
2042 Figure 34 shows two example SLIMbus configurations using different Subframe Modes. In the first
2043 configuration, the Guide Channel Slot-pair is contiguous while in the second configuration the Guide
2044 Channel Slot-pair is split across two Subframes.

82
2045
2046 Figure 34 Message Channel and Guide Channel Overview
2047 8.1 Guide Channel
2048 The Guide Channel contains the information necessary for a Component to acquire and maintain Message
2049 synchronization.
2050 The Guide Channel is composed of two Slots per Superframe, called the Guide Byte. The Guide Byte shall
2051 be written by the active Framer, and is illustrated in Table 23.
2052 Table 23 Guide Byte
Byte 7 6 5 4 3 2 1 0
0 ENT GV[4] GV[3] GV[2] GV[1] GV[0] GI[1] GI[0]

83
2053 8.1.1 The Guide Integrity Field
2054 The Guide Integrity field, GI[1:0], is a simple parity check of the Guide Byte contents. It provides some
2055 degree of error detection in the Guide Channel.
2056 The active Framer shall generate the Guide Integrity field as follows:
2057 GI[0] = ~(GV[4] ^ GV[2] ^ GV[0])
2058 GI[1] = ~(ENT ^ GV[3] ^ GV[1])
2059 A Component shall use the following formula to validate the Guide Byte:
2060 Guide Byte Parity Check = (ENT ^ GV[3] ^ GV[1] ^ GI[1]) & (GV[4] ^ GV[2] ^ GV[0] ^ GI[0])
2061 Note that the Guide Byte parity check detects all isolated Guide Channel errors that affect no more than
2062 two consecutive Cells. It also detects when the Guide Channel is not being driven.
2063 8.1.2 The ENT Bit
2064 The ENT bit indicates if the Guide Byte occurred between the Remaining Length (RL) field and the start of
2065 the next Message. If the Guide Byte occurs after the RL field, but before the start of the next Message, the
2066 ENT bit shall be set to zero. If the Guide Byte occurs elsewhere, the ENT bit shall be set to one.
2067
2068 Figure 35 ENT Bit
2069 Note that the Guide Value is 0b00000 while the Message Channel is idle, and that the Guide Byte cannot
2070 occur between the Arbitration Type and Arbitration Priority fields of a Message.
2071 When the Guide Byte occurs between the Arbitration Priority and Source Address fields of a Message, the
2072 ENT bit is set to one. When the Guide Byte occurs between the Remaining Length and Message Code
2073 fields of a Message, the ENT bit is set to zero.
2074 8.1.3 The Guide Value Field
2075 The Guide Value, GV[4:0], indicates the number of bytes in the Message Channel until the end of the RL
2076 field, or until the end of the Message. Depending where the Guide Byte is inserted, the GV value has
2077 different meanings:
2078 When ENT=0, the Guide Value shall be the number of bytes in the Message Channel, 0 to 31, that
2079 remains after the Guide Byte until the end of the current Message.
2080 When ENT=1, the Guide Value shall be the number of bytes in the Message Channel, 1 to 7, that
2081 remains after the Guide Byte until the end of the RL field.
2082 8.1.4 Guide Byte Corner Cases
2083 If no Devices are sending a Message in the Message Channel, the ENT bit and the Guide Value shall be
2084 zero, i.e. ENT=0 and GV=0b00000.

84
2085 If the Guide Byte occurs immediately after the end of a Message, the ENT bit and the Guide Value shall be
2086 zero.
2087 8.2 Message Syntax
2088 Devices exchange information over the Message Channel in the form of Messages. A Message consists of
2089 the four fields shown in Figure 36. The maximum Message length is thirty-nine bytes.
2090
2091
2092 Figure 36 Message Fields
2093 The Arbitration field is present in all Messages and contains four sub-fields: Arbitration Type, Arbitration
2094 Extension, Arbitration Priority and Source Address. See section 8.2.1 for more information.
2095 The Header field is present in all Messages and contains six sub-fields: Remaining Length, Message Type,
2096 Destination Type, Message Code, Primary Integrity, and Destination Address. See section 8.2.1.4 for more
2097 information.
2098 The Message Payload contains Message-specific parameters and data, and in some cases has zero length.
2099 See section 8.2.3 for more information.
2100 The Message Integrity and Response field is present in all Messages and contains two sub-fields, a 4-bit
2101 CRC and a 4-bit Message Response field. See section 8.2.4 for more information. A Component shall send
2102 the Message Response sub-field using Logical-OR signaling as described in section 5.1.
2103 Table 24 describes the different fields that constitute a Message.

2104 Table 24 Message Field Overview
Field Bytes Description

Arbitration 2 or 7 Message priority plus either a Logical or Enumeration Address-based
arbitration from a source Device requesting access to the Message Channel.
Header 3, 4 or 9 Information sent by the source Device such as the length of the Message.
Message 0 to Message parameters or data sent from the source Device to the destination
Payload Maximum Device.
Payload
Length
Message 1 4-bit CRC field sent by the source Device and 4-bit response field sent by the
Integrity destination Devices.
and
Response
2105 A Device shall set all reserved Cells in a field to zero when sending a Message. Reserved Cells are
2106 indicated as Rsvd in the tables in this section.

85
2107 A Device shall not send a Message with a field set to any of its reserved or illegal values.
2108 8.2.1 Arbitration Field
2109 The bits are allocated to the Cells within the bytes as shown in the tables in this section.
2110 The Arbitration field contents are described in Table 25.

2111 Table 25 Arbitration Field Overview
Field Mnemonic Comment

Arbitration Type AT[3:0] 4-bit field indicating Short or Long Arbitration.
Arbitration Extension AE 1-bit Arbitration Extension field.
Arbitration Priority AP[2:0] 3-bit Arbitration Priority code.
Source Address LA[7:0] or EA[47:0] The 8-bit Logical Address or 48-bit Enumeration
Address of the Device attempting to gain access to the
bus.
2112 There are two types of arbitration, called Short Arbitration and Long Arbitration. During Short Arbitration,
2113 a Device shall use its Logical Address when sending the arbitration sequence. During Long Arbitration, a
2114 Device shall use its Enumeration Address when sending the arbitration sequence.
2115 Table 26 shows Short Arbitration used by a Device with a Logical Address (section 8.2.5.2).
2116 Table 26 Short Arbitration Field Composition
Byte 7 6 5 4 3 2 1 0
0 AT[3]=1 AT[2]=1 AT[1]=1 AT[0]=1 AE=0 AP[2] AP[1] AP[0]
1 LA[7] LA[6] LA[5] LA[4] LA[3] LA[2] LA[1] LA[0]
2117 Table 27 shows Long Arbitration used by a Device with an Enumeration Address (section 8.2.5.1).
2118 Table 27 Long Arbitration Field Composition
Byte 7 6 5 4 3 2 1 0
0 AT[3]=0 AT[2]=1 AT[1]=0 AT[0]=1 AE=0 AP[2] AP[1] AP[0]
1 EA[47] EA[46] EA[45] EA[44] EA[43] EA[42] EA[41] EA[40]
2119 8.2.1.1 Arbitration Type Field
2120 The Arbitration Type field indicates whether the Arbitration field is Short (Logical Address from an
2121 enumerated Device) or Long (Enumeration Address from an unenumerated Device). In most cases, a
2122 Device uses Short arbitration for sending Messages. During Device discovery, or when a Device does not
2123 have a Logical Address, a Device uses Long arbitration.

86
2124 When the Message Channel is idle (no Device is transmitting), all Cells are equal to zero.
2125 All other values of the Arbitration Type field are illegal.
2126 Table 28 Arbitration Types
Arbitration Type Description

(AT[3:0])
0b0000 No Arbitration
0b0001 to 0b0100 Illegal
0b0101 Long Arbitration
0b0110 to 0b1110 Illegal
0b1111 Short Arbitration
2127 8.2.1.2 Arbitration Extension
2128 The Arbitration Extension field, AE, is a single bit value that shall be treated by a Device as part of the
2129 normal arbitration sequence.
2130 Table 29 Arbitration Extension
Arbitration Description
Extension
(AE)
0b0 Normal
0b1 Reserved
2131 8.2.1.3 Arbitration Priority Codes
2132 The Arbitration Priority codes are defined in Table 30.

2133 Table 30 Arbitration Priority Codes
Arbitration Description
Priority
(AP[2:0])
0b000 Reserved
0b001 Low Priority Messages
0b010 Default Messages
0b011 High Priority Messages
0b100 Manager assigned only
0b111 Maximum Priority, for test and debug only

87
2134 8.2.1.4 Source Address
2135 The Source Address is the Enumeration Address or Logical Address of the Device sending a Message. See
2136 section 8.2.5.1 and section 8.2.5.2 for descriptions of the Enumeration Address and Logical Address,
2137 respectively.
2138 8.2.2 Header Field
2139 There are three reserved Cells in the Header field. A Device shall set these Cells to zero, and the contents
2140 shall be used only for CRC generation.
2141 An overview of the Header field can be found in Table 31.

2142 Table 31 Header Fields
Field Mnemonic Description

Message Type MT[2:0] 3-bit Message Type. Informs the destination Device how the Message
Code is to be interpreted.
Remaining RL[4:0] 5-bit Remaining Length. Specifies the remaining number of bytes in
Length the Message. This is the length of the Header, Message Payload, and
the Message Integrity and Response fields minus one.
Message Code MC[6:0] 7-bit Message Code. Informs the destination Device about the nature of
the Message. There are 128 Message Codes for each Message Type.
Destination Type DT[1:0] 2-bit Destination Type. Informs the destination Device how the
Destination Address is to be interpreted.
Primary Integrity PI[3:0] 4-bit Primary Integrity. Provides error checking for the beginning of a
Message, spanning the Arbitration Type to the Primary Integrity. The
error checking is a 4-bit CRC with the polynomial given in section
8.2.4.1.
Destination LA[7:0] If the Destination Type is set to Logical Address, this field describes an
Address or 8-bit Logical Address of the Destination.
EA[47:0] If the Destination Type is set to Enumeration Address, this field
describes a 48-bit Enumeration Address.
or
If the Destination Type is set to Broadcast, this field is not present.
not present
2143 8.2.2.1 Message Type
2144 The Message Type field informs the destination Device how it should interpret the Message Code. The
2145 defined Message Types are shown in Table 32.
2146 Table 32 Message Types
Message Type Description

(MT[2:0])
0b000 Core Message
0b001 Destination-referred Class-specific Message
0b010 Destination-referred User Message
0b011 Illegal
0b100 Reserved

88
Message Type Description

(MT[2:0])
0b101 Source-referred Class-specific Message
0b110 Source-referred User Message
0b111 Illegal
2147 8.2.2.2 Message Codes
2148 Message Codes are specific to a Message Type. See section 8.2.2.1 for a description of Message Types.
2149 8.2.2.3 Destination Type
2150 The Destination Type field informs the destination Device how the Destination Address is to be interpreted.
2151 There are three valid, and one reserved, code as shown in Table 33.
2152 Table 33 Destination Types
Destination Type Description

(DT[1:0])
0b00 Destination is a Logical Address
0b01 Destination is an Enumeration Address
0b10 Reserved
0b11 All Devices are Destinations, no Destination Address included in Header
2153 Depending on the Destination Type, the Header uses one of three different formats: Broadcast, Short or
2154 Long.
2155 The Broadcast Header format is shown in Table 34. The Broadcast Header is used to send a Message to all
2156 Devices on the bus.
2157 Table 34 Broadcast Header Format
Byte 7 6 5 4 3 2 1 0
0 MT[2] MT[1] MT[0] RL[4] RL[3] RL[2] RL[1] RL[0]
1 Rsvd=0 MC[6] MC[5] MC[4] MC[3] MC[2] MC[1] MC[0]
2 Rsvd=0 Rsvd=0 DT[1]=1 DT[0]=1 PI[3] PI[2] PI[1] PI[0]
2158 The Short Header format is shown in Table 35. The Short Header is used to send a Message to a specific
2159 Device on the bus.
2160 Table 35 Short Header Format with a Logical Address
Byte 7 6 5 4 3 2 1 0
3 LA[7] LA[6] LA[5] LA[4] LA[3] LA[2] LA[1] LA[0]

89
2161 The Long Header format is shown in Table 36. The Long Header is used to send a Message to a specific
2162 Device on the bus.
2163 Table 36 Long Header Format with an Enumeration Address
Byte 7 6 5 4 3 2 1 0
2164 8.2.3 Message Payload Field
2165 The maximum length of the Message Payload field varies with Message Header type and can be
2166 twenty-two bytes (Long Header), twenty-seven bytes (Short Header) and twenty-eight bytes (Broadcast
2167 Header). The Message Payload field format is shown in Table 37. Note, unlike the Enumeration Address in
2168 the Arbitration and Long Header fields (see Table 27 and Table 36), the Message Payload field is organized
2169 with the Least Significant Byte first.
2170 Table 37 Message Payload Format
Byte 7 6 5 4 3 2 1 0
0 PD[7] PD[6] PD[5] PD[4] PD[3] PD[2] PD[1] PD[0]
1 PD[15] PD[14] PD[13] PD[12] PD[11] PD[10] PD[9] PD[8]
.
.
.
N PD[8N+7] PD[8N+6] PD[8N+5] PD[8N+4] PD[8N+3] PD[8N+2] PD[8N+1] PD[8N+0]
2171 The contents of the Message Payload shall be specified individually for each Message.
2172 8.2.4 Message Integrity and Response Field
2173 The Message Integrity and Response field is comprised of the sub-fields shown in Table 38.
2174 Table 38 Message Integrity and Response Field
Field Mnemonic Description

Message MI[3:0] See section 8.2.4.1
Integrity
Message MR[3:0] All destination Devices indicate Positive or Negative Acknowledge
Response according to Table 40

90
2175 The Message Integrity and Response sub-fields are allocated to the Cells within the Integrity and Response
2176 field as shown in Table 39.
2177 Table 39 Integrity and Response Field
7 6 5 4 3 2 1 0
Byte 0 MI[3] MI[2] MI[1] MI[0] MR[3] MR[2] MR[1] MR[0]
2178 8.2.4.1 Integrity Fields
2179 The two Integrity fields, Primary Integrity and Message Integrity, each use the same 4-bit Cyclic
2180 Redundancy Check (CRC) calculation to provide error detection. As shown in Figure 37, the Primary
2181 Integrity field covers the Arbitration field and the Message Type, Remaining Length, Message Code and
2182 Destination Type sub-fields of the Header field. The Message Integrity field additionally covers the
2183 Destination Address, if present, and the Message Payload, if any. Reserved Cells shall be included when
2184 performing Integrity CRC calculations.
2185
2186 Figure 37 CRC Coverage
2187 The CRC shall be calculated in the following manner. The CRC generator shall be initialized to 0b0000.
2188 The CRC calculation starts with the first Cell of the Message. During each following Cell the CRC shall be
2189 updated according to the formula CRC = X4 + X + 1, as implemented in Figure 38 with the switch set to the
2190 XOR gate, or equivalent. Note that at the start of the relevant Integrity fields, the bit-values b3 to b0 relate to
2191 the CRC value as CRC[3:0] = [b3, b2, b1, b0].
2192
2193
2194 Figure 38 CRC Engine
2195 The CRC passes if the state of the CRC engine at the end of the Integrity field is 0b0000, otherwise the
2196 CRC fails.
2197 The Primary Integrity CRC calculation completes with the final Cell of the Destination Type field. The
2198 Message Integrity CRC calculation completes with the last Cell before the Message Integrity field.
2199 For example, when the active Manager sends a RECONFIGURE_NOW Message with Arbitration Priority
2200 0b110 and it receives only positive acknowledgements, the Message consists of the hexadecimal string
2201 0xF6FF035F3B0A. The Primary Integrity CRC is 0xB and the Message Integrity CRC is 0x0, in this
2202 example.

91
2203 8.2.4.2 Message Response Field
2204 The Message Response field is encoded according to Table 40.

2205 Table 40 Message Response Codes
Response Field Mnemonic Description

MR[3:0]
0b1010 PACK Positive Acknowledge
0b1111 NACK Negative Acknowledge
0b0000 NORE No Response
All others UDEF Undefined
2206 8.2.5 Addressing
2207 SLIMbus uses 48-bit Enumeration Addresses to uniquely identify enumerating Devices. During
2208 enumeration, a Device uses its Enumeration Address to announce its presence on the bus. The active
2209 Manager can respond to the Device using the Devices Enumeration Address. After enumeration, a Device
2210 is addressed by an 8-bit Logical Address.
2211 8.2.5.1 Enumeration Address
2212 An Enumeration Address is a 48-bit number comprised of four fields: Manufacturer ID, Product Code,
2213 Device Index and Instance Value, as shown in Table 41.
2214 Table 41 Enumeration Address Fields
7 6 5 4 3 2 1 0
EA[47:40] MI[15] MI[14] MI[13] MI[12] MI[11] MI[10] MI[9] MI[8]
EA[39:32] MI[7] MI[6] MI[5] MI[4] MI[3] MI[2] MI[1] MI[0]
EA[31:24] PC[15] PC[14] PC[13] PC[12] PC[11] PC[10] PC[9] PC[8]
EA[23:16] PC[7] PC[6] PC[5] PC[4] PC[3] PC[2] PC[1] PC[0]
EA[15:8] DI[7] DI[6] DI[5] DI[4] DI[3] DI[2] DI[1] DI[0]
EA[7:0] IV[7] IV[6] IV[5] IV[4] IV[3] IV[2] IV[1] IV[0]
2215 The Manufacturer ID, MI[15:0], is assigned by the MIPI Alliance and uniquely identifies the company or
2216 organization responsible for the development of the Component. See [MIPI01] for details. Only
2217 Manufacturer IDs assigned by the MIPI Alliance shall be used in this field.
2218 The Product Code field, PC[15:0], is assigned by the Component manufacturer. The Product Code should
2219 uniquely identify the Component model, e.g. family, variant, major version etc.
2220 The Device Index field, DI[7:0], is assigned by the Component manufacturer. Each Device within a
2221 Component shall have a unique Device Index.
2222 The Manufacturer ID, the Product Code and the set of Device Index values shall be identical for all
2223 instances of the same Component.
2224 The Instance Value field, IV[7:0], may be configurable at system design time or during system manufacture
2225 using pin-strapping, non-volatile memory programming or other typical methods. Each instance of a

92
2226 Component in a system may have a unique Instance Value. Methods for determining the Instance Value are
2227 outside the scope of this document.
2228 The Manufacturer ID, Product Code and the Instance Value shall be identical for all Devices in the same
2229 Component.
2230 Enumeration Addresses should be unique across all Devices on the bus. Enumeration Addresses shall be
2231 unique across all Devices that can enumerate concurrently. If there are multiple instances of the same
2232 Component on the bus, and the instances contain Devices with identical Enumeration Addresses, these
2233 Devices shall enumerate in turn rather than concurrently. The definition of a mechanism for determining
2234 numeration order is outside the scope of this specification.
2235 8.2.5.2 Logical Address
2236 A Logical Address is used in Header and Destination Type fields to identify the source Device and
2237 destination Device of a Message. A Logical Address is an eight-bit number that uniquely identifies an
2238 enumerated Device on the bus and is assigned by the active Manager during the enumeration process. Some
2239 Logical Address values have special significance as indicated in Table 42.
2240 Table 42 Logical Address Values
Logical Address Description

0xFF Active Manager. Shall not be assigned by active Manager
0xF0 to 0xFE Reserved. Shall not be assigned by active Manager.
0x00 to 0xEF Available for general use
2241 8.3 Message Synchronization and Tracking
2242 In order to transmit or receive Messages, a Component first acquires Message synchronization as described
2243 in section 8.3.1. Once the Component achieves Message synchronization, it tracks all Messages in the
2244 Message Channel as described in section 8.3.2. The Component also checks its internal state against every
2245 Guide Byte as described in section 8.3.3. Behavior on the loss of Message synchronization is described in
2246 section 8.3.4.
2247 While a Component is not in Message synchronization, the Devices in that Component shall not transmit in
2248 the Message Channel.
2249 8.3.1 Message Synchronization Acquisition
2250 A Component shall achieve Frame and Superframe synchronization according to section 10.1.2 or 10.1.3.
2251 A Component shall achieve Message synchronization in the following way:
2252 The Component shall read the upcoming Guide Byte, and check the parity.
2253 If the parity check does not pass, a Device shall not use the Guide Byte contents and shall
2254 wait for the next Guide Byte.
2255 If ENT=1, the Guide Channel appeared during the arbitration sequence of a Message. In this case,
2256 the Guide Value indicates the number of bytes left until the end of the first byte of the Header,
2257 which contains the Remaining Length (RL) field. A Component shall track the Arbitration
2258 Sequence, read the RL field and track the Message until the end.
2259 If ENT=0, the Guide Channel did not appear during the arbitration sequence of a Message. In this
2260 case, the Guide Value indicates the number of bytes left until the end of the Message. A

93
2261 Component shall track the Message until the end. Note, if the Guide Value equals 0b00000, there
2262 is no Message ongoing in the Message Channel.
2263 In the absence of events that would cause loss of synchronization, the Component shall achieve
2264 Message synchronization no later than the end of the following Guide Byte.
2265 A state diagram showing a Component tracking the Guide Channel and Message Channel in order to
2266 achieve Message synchronization is shown in Figure 39.
Frame and Superframe

Synchronization Achieved
Wait until end of RL Field Wait for Guide Byte
Wait until end of Message Synchronization Achieved

2267
2268 Figure 39 Message Synchronization State Diagram
2269 As specified in section 10.1.1.5, when the Clock Sourcing Component is not in Message synchronization,
2270 the active Framer writes the ENT bit and the Guide Value as zero.
2271 8.3.2 Message Tracking
2272 In order to remain synchronized to the Message Channel, a Component shall track the Messages appearing
2273 in the Message Channel. Message tracking involves reading different parts of the Message, e.g. the
2274 Remaining Length field in the Message Header, and continuously making judgments on whether to stay in
2275 Message synchronization or take other action. See section 8.4.2.
2276 8.3.3 Message Synchronization Maintenance
2277 While tracking Messages, a Component shall continue monitoring every Guide Byte. If the Guide Byte
2278 Parity Check is equal to zero, the Component shall lose Message synchronization. Otherwise, the
2279 Component shall check the consistency of the Guide Byte with its internal Component state. The internal
2280 Component state is based on Message Tracking (see section 8.3.2).
2281 If a Component has a mismatch when comparing the Guide Byte information with its internal Message
2282 Channel tracking mechanism, the Component shall update its internal tracking mechanism with the Guide
2283 Byte information. The Components Interface Device shall set the LOST_MS Information Element to
2284 TRUE and the current Message shall be considered aborted. A Component can be in a number of different
2285 conditions:
2286 A Device within the Component was transmitting a Message. The Device shall stop transmission
2287 of the current Message.
2288 A Device within the Component was receiving a Message. The Device shall not send a NACK or
2289 other response to the Message.
2290 No Device within the Component was sending or receiving a Message. No particular action is
2291 mandated for this condition.

94
2292 The Component may resynchronize itself according to the Guide Byte information it just received.
2293 8.3.4 Message Synchronization Loss
2294 A Component that has lost track of the Message flow but that is still in synchronization with the
2295 Superframe shall wait for the next Superframe boundary and again achieve synchronization with the Guide
2296 Channel. The Component shall update its Core Information Elements and set its Interface Device's
2297 LOST_MS Information Element to TRUE.
2298 This error shall have no effect on the way the Component is using the Data Space.
2299 8.4 Message Protocol
2300 The Message Protocol is a set of processes that provide a mechanism for assembling and checking parts of
2301 Messages passing between Devices and the Frame Layer.
2302 8.4.1 Message Transmission
2303 When preparing a Message for transmission, a Device shall obey the Message syntax rules in section 8.2.
2304 Because the Message Channel is a shared resource, an arbitration mechanism is defined to let a Device
2305 determine whether it is allowed to transmit a Message.
2306 There are two different types of arbitration, called Short and Long arbitration. In almost all cases, a Device
2307 uses Short arbitration, where the arbitration sequence contains the Logical Address of the Device. During
2308 enumeration, a Device uses Long arbitration, where the arbitration sequence contains the Enumeration
2309 Address of the Device.
2310 A Device may initiate arbitration in the first Cell of any Message Channel Slot-pair when the channel is
2311 available. A Device shall not start arbitration in any other Cell, or while its Component has determined that
2312 the channel is unavailable. There are two situations in which the Message Channel is available:
2313 Immediately following the end of a Message in the Message Channel, as determined by tracking
2314 Messages or from a valid Guide Value.
2315 When the Message Channel is unused, i.e. when the previous Message Channel Slot-pair was
2316 unused.
2317 A Device shall use Logical-OR signaling (section 5.1) while arbitrating. The Device shall verify the state of
2318 the bus after every Cell. If the value on the bus is different from the value transmitted by the Device, the
2319 Device loses arbitration. If a Device loses arbitration, it shall stop transmitting the Arbitration field within
2320 half a Cell, i.e. it shall not transmit another bit.
2321 A Device obtains access to the Message Channel if it reaches the end of the Arbitration field without losing
2322 arbitration. The Device shall proceed to send the Header, Payload and Message Integrity fields of its
2323 Message. A Device that is not transmitting shall parse the Message to determine if it is a destination of the
2324 Message.
2325 The source Device shall read the Response field and shall act as indicated in Table 42.
2326 Table 43 Message Response Interpretation
Response Action
PACK The Device shall assume that all destination Devices correctly received the Message.
NACK The Device shall assume that none of the destination Devices correctly received the Message.

95
Response Action
NORE The Device shall assume that none of the destination Devices received the Message.
UDEF The Device shall assume that none of the destination Devices received the Message.
2327 The Message Response field might not contain a PACK for a variety of reasons. Therefore, the appropriate
2328 reaction for any given response varies depending on the application. At a minimum, the source Device
2329 should retransmit the Message at least once, but should not retransmit the Message indefinitely.
2330 Any Device may restart arbitration as soon as the Message has ended.
2331 8.4.2 Message Reception
2332 A Device intended to receive a Message is known as a destination Device. A destination Device shall
2333 respond to the source Device by sending an appropriate acknowledgement in the Response field. While
2334 sending its acknowledgement, a Device shall use Logical-OR signaling as described in section 5.1. A
2335 Device that is not a destination Device shall not acknowledge the Message. The destination Device shall
2336 behave as though the Messages were executed in the order in which they were received.
2337 A Component shall always parse the following Message fields (section 8.2):
2338 The Arbitration Type, so that it knows the length of the Arbitration field
2339 The Message Type, some MT codes causes the Component to lose Message synchronization
2340 The Remaining Length, in order to maintain Message synchronization
2341 The Primary Integrity, for CRC calculation
2342 The Message Response, to see the result of the CRC calculation
2343 Message parsing and the relation between CRC failure and Response field behavior can be visualized as in
2344 the state diagram in Figure 40.
2345 A Device shall temporarily record the Logical Address of the source Device. A Device should discard its
2346 record of the source Device's Logical Address if it is not a destination of the Message. A destination Device
2347 should discard its record of the source Device's Logical Address when it has completed any necessary
2348 transactions based on the Message. For example, a destination Device of a REQUEST_INFORMATION
2349 Message needs the source Device's Logical Address until it has sent or abandoned the corresponding
2350 REPLY_INFORMATION Message (see section 10.12).
2351 A destination Device is not required to check that a Message Code is appropriate from a particular source
2352 Device.

96
IDLE
ParseLongArb ParseShortArb
Long Arbitration Short Arbitration

IllegalArbType
ParseHeader ParseHeader
ReceivedMessageOK
Header InvalidHeader Error
Error Recovery
ParsePayload
Payload
FailedResponse
ParseIntegrity
Message Integrity and Response

2353
2354 Figure 40 Basic Message Parsing Diagram
2355 8.4.2.1 Arbitration Sequence Parsing
2356 While in the Idle state, a Component shall read the first Slot of every Message Channel Slot-pair and
2357 interpret it according to Table 28. The Component shall ignore the contents of the second Slot of a Message
2358 Channel Slot-pair.
2359 Depending upon the value of the Arbitration Type, the Component shall either stay in the Idle State, move
2360 to one of the Arbitration states, or when a Component observes an illegal value in the Arbitration field, the
2361 Component shall change to the Error state in Figure 40.
2362 In the latter case, the Components Interface Device shall change its LOST_MS Information Element to
2363 TRUE and lose Message synchronization as described in section 8.3.4.
2364 When the Arbitration Type indicates Short Arbitration, the Component shall move to the Short Arbitration
2365 state in Figure 40. When the Arbitration type indicates Long Arbitration, the Component shall move to the
2366 Long Arbitration state in Figure 40.
2367 After successfully parsing one of the Arbitration sequences, the Component shall continue parsing the
2368 Header field.

97
2369 8.4.2.2 Message Type Field Parsing
2370 A Component that observes a Message with an Illegal Message Type shall discard the Message and lose
2371 Message synchronization (InvalidHeader transition in Figure 40).
2372 A Component that observes a Message with Reserved Message Type shall discard the Message but stay in
2373 Message synchronization.
2374 For all other values of the Message Type, a Component shall continue to receive the Message and parse the
2375 Message Code Field.
2376 8.4.2.3 Message Code Field Parsing
2377 A Core Message shall be interpreted by a Device using Table 65.
2378 A Destination-referred Class-specific Message shall be decoded by a Device using its own Device Class
2379 Message Code table. See section 12.
2380 A Destination-referred User Message shall be decoded by a Device using its own User Message Code table.
2381 A Source-referred Class-specific Message shall be decoded by a Device using the Message Code table for
2382 the Device Class of the source Device of the Message. In order to interpret the Message Code, a destination
2383 Device of a Source-referred Class-specific Message needs to know the Device Class of the Device that sent
2384 the Message. A Source-referred Class-specific Message received from a Device whose Device Class is
2385 unknown shall be treated as unsupported by the destination Device. For more information on unsupported
2386 Messages see section 10.2.5.
2387 A Source-referred User Message shall be decoded by a Device using the User Message Code table for the
2388 source Device of the Message. In order to interpret the Message Code, a Destination of a Source-referred
2389 User Message needs to know the User Messages of the Device that sent the Message. A Source-referred
2390 User Message received from a Device whose User Messages are unknown shall be treated as unsupported
2391 by the destination Device.
2392 Many Message Codes do not have application to all Destination Types. A Device is not required to check
2393 that a Message Code is appropriate for a particular Destination Type.
2394 8.4.2.4 Destination Type Field Parsing
2395 If a Device observes a Message with a reserved value for the Destination Type, the Device shall discard the
2396 Message and shall not act on the contents.
2397 8.4.2.5 Remaining Length Field Parsing
2398 A Component shall read the Remaining Length field. If the RL field indicates a Message Payload length
2399 longer than what is needed for the necessary fields for a particular Message, a Device shall assume that the
2400 relevant content is located in the beginning of the Message Payload, with layout as specified for that
2401 Message. The unknown field(s) shall be considered reserved, i.e. Devices shall use these fields only for
2402 CRC calculation.
2403 If the RL field indicates a length shorter than what is needed for that Message, a destination Device shall
2404 discard the Message. If implemented, the destination Device should change its EX_ERROR Information
2405 Element to TRUE.

98
2406 8.4.2.6 Primary Integrity Field Parsing
2407 A Component shall read the Primary Integrity and verify the value with its internal CRC as described in
2408 section 8.2.4.1. If the CRC fails, the Component shall change to the Error state and lose Message
2409 synchronization (InvalidHeader transition in Figure 40).
2410 8.4.2.7 Message Response Field Parsing
2411 A Device that is a destination of the incoming Message shall write to the Response Field as mandated in
2412 Table 44. A Device that is not a destination shall not write to the Response Field.
2413 Table 44 Message Response Writing Rules
Response Description
PACK A destination Device shall issue PACK when the Message Integrity CRC passes, except when
the Device requires retransmission of the Message.
NACK A destination Device shall issue NACK if the Message Integrity CRC fails.
A destination Device should issue NACK if it needs retransmission of the Message.
NORE A destination Device shall not issue NORE.
UDEF A destination Device shall not issue UDEF.
2414 A Device that is a destination of the incoming Message shall read and react to the Response field as
2415 mandated in Table 45.
2416 Table 45 Message Response Reading Rules for Destination Devices
Issued Read Action

Response Response
PACK PACK The Device shall start processing the received Message.
PACK NACK
The Device shall discard the received Message.
NACK NACK
NACK PACK The Device shall discard the received Message. It shall also cause its
PACK, NORE, Component to lose Message synchronization, return to the
NACK UDEF SeekingMessageSync state and assert LOST_MS.
2417 A Device that is not a destination of the incoming Message shall react to the Response field as mandated in
2418 Table 46.
2419 Table 46 Message Response Reading Rules for Non-destination Devices
Issued Read Action

Response Response
NORE UDEF The Device shall cause its Component to lose Message synchronization, return
to the SeekingMessageSync state and assert LOST_MS.
2420
2421

99
2422 9 Transport Protocols
2423 9.1 Data Channels and Flow Control
2424 To completely define a Data Channel, the following parameter sets must be communicated to the Devices
2425 involved: a Channel Definition, a Content Definition, and whether the Data Channel is active or inactive.
2426 A Channel Definition indicates the location and size of the Segments in the Frame Structure. It also
2427 determines the Transport Protocol that shall be used in the Data Channel. The Transport Protocol defines
2428 the flow control or handshaking method used by the Ports to access the channel. A number of Transport
2429 Protocols are defined in this section, ranging from isochronous, where every Segment contains data, to
2430 asynchronous, where handshaking is used to emulate UART traffic. See also section 10.13.
2431 The Content Definition contains a number of parameters that provide additional information on the data
2432 being transported through the Data Channel. It indicates the Presence Rate (Rate of Segments that contain
2433 data), the Data Type, the DATA field length (in Slots), the Auxiliary Format (see section 9.4) and whether
2434 the flow is Frequency Locked.
2435 9.2 Channel Taxonomy
2436 The Channel Definition and Content Definition shall be broadcast through the Message Channel. This
2437 section gives guidance on how to determine the Message parameters for the relevant Messages
2438 (NEXT_DEFINE_CONTENT, CHANGE_CONTENT, and NEXT_DEFINE_CHANNEL).
2439 A first step is to determine whether flow control is needed, and if it is, what type is appropriate. This
2440 typically depends on the Devices and the type of Data involved. If needed, one of the two supported styles
2441 of flow control needs to be selected: Single-ended, or Double-ended flow control.
2442 9.2.1 Absence of Flow Control
2443 In cases where the frequency of the CLK line is an integer multiple of the flow rate, no flow control is
2444 needed. See for instance section 6.2.5 on Natural Frequencies. In these cases, the Isochronous Transport
2445 Protocol (see section 9.3.1) can be used. If the Isochronous Transport Protocol is used, the Frequency
2446 Locked field must be set to indicate that the frequency of the flow and the bus frequency are locked.
2447 9.2.2 Single-ended Flow Control
2448 Single-ended flows are flows where presence or absence of data is regulated by a shared algorithm (for the
2449 Locked Protocol), or by the use of a Presence bit (for the Pulled and Pushed Protocol respectively). These
2450 protocols are designed to optimally carry constant bitrate media streams (such as LPCM audio). The exact
2451 flow control method suited for a flow depends on the Root Frequency, as well as the characteristics of the
2452 flow.
2453 Independent of the type of data that is transported, the Frequency Locked field indicates whether the flow
2454 rate is locked to the CLK line. If the Frequency Locked field is set, the ratio between the flow rate and the
2455 CLK frequency is exactly PR / (RF*2(10-CG)). If the Frequency Locked field is not set, this ratio might be
2456 approximate.

100
2457 9.2.3 Double-ended Flow Control
2458 With double-ended handshaking, either Device involved in the transport can pause the transfer of data. This
2459 is achieved via two or more flow control bits in every Segments TAG field. The four Asynchronous
2460 Transport Protocols all use this type of flow control. These Transport Protocols have been designed to
2461 optimally support asynchronous data flow, such as data traffic to and from a Bluetooth modem.
2462 Independent of the type of data that is transported, the Frequency Locked field should not be set, and the
2463 Presence Rate field should be set to not indicated. These parameters should be ignored by Devices when
2464 initializing an Asynchronous transport.
2465 9.3 Transport Protocols
2466 A Transport Protocol determines how flow control is performed for that specific channel and how the flow
2467 control information shall be mapped to the bits in the TAG field.
2468 A Data Channel has exactly one data source at a time and may have one or more data sinks. The source
2469 produces data and a sink consumes data. The TAG bits are used to carry the flow control/information.
2470 Each TAG bit has an associated Read/Write state for every Device that indicates if the Device shall read or
2471 write the TAG bit. The R/W default state is defined by the protocol in use. Only one Device at a time is
2472 allowed to write in a TAG bit. Multiple Devices can read the same TAG bit simultaneously. TAG bits that
2473 are identified as Reserved shall be written as zeros, and shall be ignored by receiving Devices.
2474 Table 47 lists the Transport Protocols that can be used when defining a Data Channel. A Device may
2475 support all, or only a subset, of these Transport Protocols. Reserved values shall not be used when
2476 defining a channel. A Device shall treat Reserved Transport Protocol codes as unsupported Transport
2477 Protocols. See section 11.4.9 for more information.
2478 Table 47 Transport Protocol Overview
TP Protocol Name Type # of TAG field

Slots
0 Isochronous Protocol Multicast 0
1 Pushed Protocol Multicast 1
2 Pulled Protocol Unicast 1
3 Locked Protocol Multicast 0
4 Asynchronous Protocol Simplex Unicast 1
5 Asynchronous Protocol Half-duplex Unicast 1
6 Extended Asynchronous Protocol Simplex Unicast 2
7 Extended Asynchronous Protocol Half-duplex Unicast 2
8 to 13 Reserved - -
14 User Defined Protocol 1 - 1
15 User Defined Protocol 2 - 2

101
2479 9.3.1 Isochronous Protocol
2480 This protocol does not provide any flow information nor flow control. It should be used to carry data whose
2481 rate matches exactly the channel rate, or where flow control is embedded in the data. There are no TAG bits
2482 used, therefore the length of the TAG field shall be zero Slots.
Not Used
2483
2484 Figure 41 Isochronous Protocol Segment Organization
2485 A typical case is the transport of a 48 kHz sample rate PCM audio (samples available 48000 times per
2486 second) using a 48 kHz channel rate (channel Segment available 48000 times per second).
2487 As an example, when 16-bits linear PCM audio is transported over the bus, the DATA field is four Slots
2488 wide and there are no AUX bits. The Segment size is then four Slots (16-bits).
2489 The Isochronous Protocol allows multiple sinks to be connected to a Data Channel.
2490 9.3.2 Pushed Protocol
2491 The Pushed protocol includes flow information. It is used to carry data whose rate is equal to, or lower
2492 than, the channel rate. The source Device drives the data flow and the TAG bits indicate availability of data
2493 in the DATA field.
Not Used
2494
2495 Figure 42 Pushed Protocol Segment Organization
2496 When the source does not use the Segment, it shall reset the STROBE bit and not drive the remaining Cells
2497 of the Segment following C1:
2498 TAG Cell C0, PRESENCE bit
2499 The AUX field Slots, if any
2500 The DATA field Slots, if any

102
2501 When the source does use the Segment, it shall set the STROBE bit and shall drive C0, the AUX Slots and
2502 the DATA Slots.
2503 When the source decides to send data in the DATA field, it shall set the P bit. If the STROBE bit is one, but
2504 the P bit is zero, the source shall drive the AUX field Slots and the DATA field Slots with zeros.
2505 When the STROBE bit is one, a sink shall read the P bit to detect if there is data in the DATA field. If the P
2506 bit is set, the sink shall use the contents of the DATA field. If the P bit is not set, the AUX and DATA
2507 fields may be ignored.
2508 The STROBE bit indicates when data should be present in the Segment.
2509 When the Frequency Locked bit is set, the STROBE bit shall provide the sink(s) with a pattern that is
2510 derived from the ratio between the data rate and the channel rate. The P-bit can be used to verify if the data
2511 stream is active. For example, when the STROBE bit is one and the P bit is zero, the source has no data to
2512 transport.
2513 When the STROBE bit is equal to zero, the PRESENCE bit shall not be driven by the source and should
2514 not be read by a sink.
2515 Table 48 TAG Semantics for the Pushed Protocol
Cell Name Source Sink(s) Description

C3 - Write 0 Ignore Reserved
C2 STR Write Read STROBE bit. STR=1 indicates that data is expected to
be present in the Segment
C0 P Write Read PRESENCE bit. P=1 indicates that data is present in the
(conditional) (conditional) rest of the Segment
2516 A use case for which the Pushed Protocol is well suited is the transport of 44.1 kHz sample rate PCM audio
2517 (samples available approximately 44100 times per second) using a 48 kHz channel rate (channel Segment
2518 available 48000 times per second). There will be about 147 samples available every 160 channel Segments.
2519 Some of the Segments will have to be ignored by the sink. In this case, the sink knows which Segments to
2520 use by reading the P bit in the TAG field Slot.
2521 When the Pushed protocol is used to carry constant bitrate streams such as LPCM audio, the source shall
2522 constrain the pattern of occupied Segments, i.e. Segments with P=1, to avoid buffer overflow/underflow at
2523 the sink(s). In steady-state operation, the source shall constrain the peak-to-peak wideband jitter of the
2524 occupied output Segments to less than two times the reciprocal of the stream's Presence Rate (section 9.6).
2525 An effect of this is that sinks typically do not need to buffer more than four Segments.
2526 The Pushed Protocol allows multiple sinks to be connected to the same Data Channel (multicast), as there
2527 is no feedback from the sinks.
2528 9.3.2.1 Example Tag Slot Values (informative)
2529 Table 49 gives an example of a sequence of events, making more explicit the mechanisms described in
2530 section 9.3.2.

103
2531 Table 49 Example TAG Slot Values for a Pushed Channel
Sequence C3 STR C1 P Comment

Segment i 0 1 0 1 The source has a sample available. It sets the STR bit and
the P bit
Segment i+1 0 1 0 1 The source has a sample available. It sets the STR bit and
the P bit
Segment i+2 0 0 0 - The source does not have a sample available. It resets the
STR bit and does not drive the Segment after C1
the P bit
the P bit
Segment i+5 0 0 0 - The source does not have a sample available. It resets the
STR bit and does not drive the Segment after C1
2532 9.3.3 Pulled Protocol
2533 The Pulled Transport Protocol provides a flow control mechanism where the sink Device requests, or pulls,
2534 data from the source Device when needed. The TAG bits indicate availability of data in the DATA field.
Not Used
2535
2536 Figure 43 Pulled Protocol Segment Organization
2537 Table 50 TAG Semantics for Pulled Protocol
Cell Name Source Sink Description

C2 SRQ Read Write Sample Request. SRQ=1 requests a sample in the
current Segment
C0 P Write Read PRESENCE bit. P=1 indicates that data is present in the
(conditional) (conditional) DATA field
2538 The sink shall drive the SRQ (Sample Request) bit. The Source shall read the SRQ bit.
2539 In steady-state operation, when SRQ=1 the source shall provide a valid sample in the current Segment.
2540 Whenever it provides a valid sample it shall set the P bit to indicate that the sample is present.

104
2541 When SRQ=0, the source shall not drive the remaining Cells of the Segment following C1. If, for any
2542 reason, the source is not capable of servicing the sample request on time, it shall reset P to zero and write
2543 zeros to that Segment's AUX and DATA fields. The Sink and Source shall be designed such that, in steady-
2544 state operation, every Segment with a sample request is serviced within the Segment.
2545 The use cases for the Pulled Protocol are similar to the ones of the Pushed Protocol. For example, an audio
2546 DAC can be designed to use its own clock when independence from the SLIMbus CLK line is desired. The
2547 Pulled Profile manages the frequency mismatch between the CLK line and the DAC's clock.
2548 When the Pulled Protocol is used to carry constant bitrate streams such as LPCM audio, the sink shall
2549 constrain the pattern of Segment requests, i.e. Segments with SRQ=1, to avoid buffer overflow/underflow
2550 at the source. In steady-state operation, the sink shall constrain the peak-to-peak wideband jitter of the
2551 Segment requests to less than two times the reciprocal of the stream's Presence Rate. An effect of this is
2552 that sources typically do not need to buffer more than four Segments.
2553 The Pulled Protocol does not allow multiple sinks to be connected to the same Data Channel. It is a point-
2554 to-point link.
2555 9.3.3.1 Example for the Pulled Protocol (informative)
2557 section 9.3.3.
2558 Table 51 Example TAG Sequence for the Pulled Protocol
Sequence C3 SRQ C1 P Comment

Segment i 0 0 0 - The sink does not request a sample. The source does not
drive the Segment after C1.
Segment i+1 0 1 0 1 The source gets a sample request (SRQ=1) and writes data
in the Segment (P=1). The sink reads the Segment data.
Segment i+2 0 1 0 1 The source gets a sample request (SRQ=1) and writes data
in the Segment (P=1). The sink reads the Segment data.
Segment i+3 0 0 0 - The sink does not request a sample. The source does not
drive the Segment after C1.
Segment i+4 0 1 0 0 The sink requests a sample but the source does not have a
sample available on time. It resets P and writes 0 in the
remaining Cells of the Segment.
2559 9.3.4 Locked Protocol
2560 The Locked Transport Protocol is applicable to constant bitrate streams that are frequency locked to the
2561 CLK line. There are no TAG bits used, therefore the length of the TAG field shall be zero Slots.

105
Not Used
2562
2563 Figure 44 Locked Protocol Segment Organization
2564 In place of a PRESENCE bit, P, that requires a TAG field Slot, the Locked Protocol uses virtual
2565 PRESENCE bits, VP. Copies of the VP bits shall be separately synthesized at each of the source and sink
2566 Devices. The mechanisms for this are synchronized by the Phasing Signal.
2567 The source Device shall write data to those of its Segments whose VP bit evaluates to 1, and the sink or
2568 sinks shall read that data. When the VP bit evaluates to 0 the source Device shall not drive the Segment,
2569 and the sink or sinks shall ignore the contents of the Segment.
2570 Section 6.2.4 introduces Root Superframes and section 6.3.1.8 specifies Root Superframe numbering. For
2571 any point in the SLIMbus waveform, the distance of that point from the start of Root Superframe 0 can be
2572 expressed in Root Superframes modulo PM. Figure 45 illustrates this concept for operation at a Cardinal
2573 Frequency with Data Channels having 48,000 Segments per second. The figure shows Segment Windows
2574 (section 6.4.4.1) rather than individual Segments.
2575
2576 Figure 45 Segment Window PHASES and SPAN
2577 In the Locked Protocol, the value of each Segment's VP bit shall be as follows:
2578 If INT(PHASESW * RATIO) = INT((PHASESW + SPAN) * RATIO) then VP=0, else VP=1.
2579 where
2580 INT() indicates the integer operator.
2581 PHASESW is the distance of the start of the associated Segment Window from the start of
2582 Root Superframe 0, expressed in Root Superframes modulo PM.
2583 SPAN is the extent of the Segment Windows, expressed in Root Superframes, i.e. SPAN
2584 = 2(10 - CG) * Segment Interval / 1536.

106
2585 RATIO is the ratio of the stream's Presence Rate to the bus's Root Superframe rate, i.e.
2586 RATIO = 6144 * Presence Rate / Root Frequency.
2587 Figure 46 illustrates VP evaluation for 44.1k flows in 48k channels with a 12.288 MHz clock.
2588
2589 Figure 46 VP Evaluation Example, 44.1k Flows
2590 Figure 47 provides a further illustration covering 16k flows with a 13 MHz or 26 MHz clock.
2591
2592 Figure 47 VP Evaluation Example, 16k Flows
2593 Components that use the Locked Protocol shall maintain an internal count of Root Superframes modulo
2594 PM. This shall be synchronized to the Phasing Signal and to Root Frequency changes as detailed in section
2595 6.3.1.8.
2596 The Locked Protocol shall not be used by Components that do not know the bus's Clock Gear or the
2597 stream's Presence Rate. This situation typically arises when the Clock Gear or the Presence Rate is 'Not
2598 Indicated', i.e. CG=0b0000 or PR=0b0000000.

107
2599 9.3.5 Asynchronous Protocol
2600 The Asynchronous protocol provides the necessary means to achieve an asynchronous data transmission,
2601 including flow control signals, over a serial synchronous link. The Asynchronous Protocol shall be used
2602 only in a point-to-point configuration between a single source Device and a single sink Device.
Not Used
2603
2604 Figure 48 Asynchronous Protocol Segment Organization
2605 The Asynchronous Protocol TAG bit definition is given in Table 52.
2606 Table 52 TAG Semantics for the Asynchronous Protocol
Cell Name Primary Secondary Description

Owner Owner
C3 T1 Write Read Primary Owner Token. Used by the primary owner to indicate
that it owns the AUX+DATA fields
C2 T2 Read Write Secondary Owner Token. Used by the secondary owner to
indicate that it owns the AUX+DATA fields
C1 CTS R/W W/R Clear To Send. CTS=0 indicates that the source Device shall
stop sending data
C0 P W/R R/W PRESENCE bit. P=1 indicates that data is present in the
current Segment
2607 The TAG bits are used to indicate the following aspects of the channel:
2608 Ownership of the AUX and DATA field Slots
2609 Ability of the sink Device to receive data
2610 Availability of data in the Segment
2611 9.3.5.1 Channel Ownership
2612 When a channel with the Asynchronous Half-duplex protocol is activated, it shall be idle and neither end of
2613 the link has ownership. When a Device needs to gain ownership of the channel, it shall use its associated
2614 token bit. The primary owner shall use the T1 bit, and the secondary owner shall use the T2 bit. The
2615 primary owner has a higher priority than the secondary owner. In order to protect against single bit errors,
2616 token bits shall be repeated in two successive Segments to change ownership state. The state diagram in
2617 Figure 49 defines how ownership of the channel is established, maintained, and relinquished in the
2618 Half-duplex protocol.

108
2619 The state diagram in Figure 49 is interoperable with, but not functionally equivalent to, the Asynchronous
2620 Protocol State Diagram defined in SLIMbus specifications prior to version 1.01.01.
2621
2622 Figure 49 Asynchronous Half-duplex Protocol State Diagram
2623 In the Idle state, a change in T1 or T2 in a Segment causes a change in state. If only T2=1, the secondary
2624 owner has the advantage. If T1=1, the primary owner has the advantage. A second Segment in which the
2625 same token is one gives ownership to that end of the link. In the Primary Ownership state, a change to
2626 T1=0 causes a transition to the Primary Release state. In this case, a second change to T1=0 causes a return
2627 to the Idle state, but a change to T1=1 causes a return to the Primary Ownership state. In the Secondary
2628 Ownership state, changes in the T2 bit mirror those for T1 in the Primary Ownership state. However, it also
2629 must react to T1=1 which indicates that the primary end of the link wants to take ownership, and causes a
2630 change to the Secondary Release state. In this case, a second segment with T1=1 causes a change to the
2631 Neither state, but a change to T1=0 causes a return to the Secondary Ownership state. States inside the
2632 shaded boxes in Figure 49 are those in which ownership is established. A change in state observed in the
2633 current segment shall take effect in the next segment.

109
2634 The Asynchronous Protocol can provide either a simplex or half-duplex transport within a Data Channel.
2635 Simplex versus half-duplex operation is noted in Table 47.
2636 When a Data Channel is activated using the Asynchronous Simplex protocol, the Secondary Owner shall
2637 not attempt to take ownership of the channel, and the primary owner shall disregard the T2 bit. When full
2638 duplex communication is required, two Data Channels may be opened using the Asynchronous Simplex
2639 protocol. In this case, each Device would be the Primary Owner of one simplex Asynchronous Data
2640 Channel.
2641 At all times when the channel does not have an owner, the remaining bits in the tag shall not be driven by
2642 either end of the link, and the AUX and DATA field Slots shall not be driven by either end of the link.
2643 When the channel does have an owner, the CTS bit shall not be driven by the owner, the P bit shall not be
2644 driven by the non-owner, and the AUX and DATA field Slots shall not be driven by the non-owner.
2645 Once channel ownership is established, the non-owner shall begin driving the CTS bit, the owner shall
2646 begin driving the P bit, and the owner shall begin driving the AUX and DATA field Slots.
2647 9.3.5.2 Flow Control
2648 In order to protect against single bit errors, flow control shall be determined from the value of the CTS bit
2649 in two successive Segments. If the value in both the previous Segment and the current Segment are zero,
2650 flow is off. If the value in both the previous Segment and the current Segment are one, flow is on. If the
2651 value in the previous Segment differs from the value in the current Segment, CTS is invalid, and flow shall
2652 be off.
2653 If the channel owner sees a change in flow from off to on, it shall not place AUX or DATA in the channel
2654 until the next Segment. If the channel owner sees a change in flow from on to off, it shall not place AUX or
2655 DATA in the Channel after the current Segment.
2656 If the channel does not have ownership established, flow control shall be off regardless of the values seen
2657 on CTS.
2658 Table 53 Flow Control Conditions
State CTS Flow

Primary Ownership Valid 1 ON
Secondary Ownership Valid 1 ON
Primary Release Valid 1 ON
Secondary Release Valid 1 ON
Primary Advantage - OFF
Secondary Advantage - OFF
Neither - OFF
- Valid 0 OFF
- Invalid OFF
2659 9.3.5.3 Data Transmission
2660 If flow is on, the channel owner shall indicate whether data is present in the AUX and DATA field Slots by
2661 setting the P bit in the TAG field Slot of the associated Segment. The P bit is read-only from the existing
2662 Segment.

110
2663 9.3.5.4 Behavior on Bit Errors
2664 The following sections describe the impact of bit errors on the TAG field Slots and the potential impact on
2665 the behavior of the Asynchronous Transport Protocol.
2666 9.3.5.4.1 Bit Errors in T1 or T2
2667 The state machine for channel ownership has been designed such that single bit errors that affect both the
2668 primary and the secondary owner will not affect ownership of the channel. A transition will occur to an
2669 intermediate state. In this state, an error-free token bit in the following Segment will return ownership to
2670 the correct state.
2671 A second, successive bit error could cause an undesired change in the channel ownership, but no single bit
2672 error will have any such effect.
2673 9.3.5.4.2 Bit Errors in CTS
2674 Any change in the value of CTS causes the flow control state to become invalid. If the change in value is
2675 caused by a bit error in a single Segment, the flow control will be invalid for two consecutive Segments.
2676 This means that the channel owner will be flowed off for a minimum of one and a maximum of two
2677 Segments.
2678 A second, successive bit error could cause an undesired change in flow control, but no single bit error will
2679 have any such effect.
2680 Bit errors in CTS have no effect if the channel ownership is not established.
2681 9.3.5.4.3 Bit Errors in P
2682 A spurious bit error which changes the value of P during a transmission can be detected only at higher
2683 layers.
2684 If P is supposed to be 1 but is read as a 0, the data conveyed in the Segment will be ignored, resulting in
2685 data loss.
2686 If P is supposed to be 0 but is read as a 1, the receiver will treat the Segment content as valid, resulting in
2687 spurious data in the transmission.
2688 Bit errors in P have no effect if the channel ownership is not established or if flow is off.
2689 9.3.5.5 Examples for the Asynchronous Protocol (informative)
2690 Table 54 gives an example of a sequence of Segments illustrating the processes involved in channel
2691 ownership described in section 9.3.5.1.
2692 Table 54 Example TAG Slot Sequence for Channel Ownership
Segment T1 T2 CTS P Comment

Segment i 0 0 Z Z The channel is idle. Neither the primary nor the
secondary owner is requesting ownership of the
channel, and the ownership state is Neither.
Segment i+1 0 1 Z Z The secondary owner requests channel ownership
(T2=1), and the ownership state changes to Secondary
Advantage.

111

Segment i+2 1 1 Z Z The primary owner requests channel ownership
(T1=1), overriding the T2 bit. The ownership state
changes to Secondary Release.
Segment i+3 1 0 Z Z The primary owner continues to request channel
ownership (T1=1), and the ownership state changes to
Neither.
Primary Advantage.
Primary Ownership.
Segment i+6 1 0 0 0 The secondary owner begins driving the CTS bit, and
the primary owner begins driving the P bit, as well as
the AUX and DATA field Slots.
Segment i+7 0 0 0 0 An error on the T1 bit causes it to be read as zero. The
ownership state changes to Primary Release but the
primary owner continues to own the channel.
Segment i+8 1 0 0 0 The T1 bit is read correctly again as a 1, and the
ownership state returns to Primary Ownership.
Segment i+9 0 0 0 0 The primary owner ceases to request channel
ownership (T1=0) and the ownership state changes to
Primary Release
Segment i+10 0 0 0 0 The primary owner continues with T1=0, and the
ownership state returns to Neither.
Segment i+11 0 0 Z Z The channel has no owner.
2693 Notes:
2694 Z represents a not driven condition.
2695 Table 55 gives an example of a sequence of Segments, illustrating the processes involved in flow control
2696 and data transmission described in section 9.3.4. Note that in the following example, the primary owner
2697 gains channel ownership and sends data, however a similar sequence applies should the secondary owner
2698 gain channel ownership.
2699 Table 55 Example TAG Slot Sequence for Flow Control and Data Transfer

Segment i 0 0 Z Z The channel is idle. Neither the primary nor the
secondary owner is requesting ownership of the channel,
and the ownership state is Neither.
Segment i+1 1 0 Z Z The primary owner requests channel ownership (T1=1),
and the ownership state changes to Primary Advantage.

112

Primary Ownership. The primary owner becomes the
DATA source and the secondary owner becomes the
DATA sink.
Segment i+3 1 0 1 0 The channel ownership is now established and the sink
may set the CTS bit to indicate to the source that it is
ready to accept data. Note that there is no requirement
for CTS to change immediately after channel ownership
is established, but in this example it does.
Segment i+4 1 0 1 0 With the second occurrence of CTS=1, flow control is
on. The DATA source has not set P in this Segment.
Segment i+5 1 0 1 1 One Segment after flow on, the source may start writing
data in the current Segment, and in this example does so
by setting P=1.
Segment i+6 1 0 1 1 A second Segment in which the DATA source sends
data to the DATA sink.
Segment i+7 1 0 1 0 The DATA sink allows data to be present in the current
Segment (CTS=1) but the source does not have any
DATA to write in the Segment (P=0).
Segment i+8 1 0 1 1 Another Segment in which the DATA source sends data
to the DATA sink.
Segment i+9 1 0 0 1 The DATA sink stops allowing data to be sent (CTS=0).
Flow control is marked invalid because the last 2 CTS
values are not equal. The DATA source may send data
in the current Segment, and in this example does so.
Segment i+10 1 0 0 0 The DATA sink continues to prevent data from being
sent (CTS=0). Flow control is off. The DATA source
does not send data in the current Segment.
Segment i+11 0 0 0 0 The source has finished its transmission and releases the
token T1=0. CTS and P are reset to 0 by their respective
owner.
Segment i+12 0 0 0 0 The primary owner continues with T1=0, and the
ownership state returns to Neither.
Segment i+13 0 0 Z Z The channel has no owner.
2700 Notes:
2702 9.3.6 Extended Asynchronous Protocol
2703 When the channel rate is low and the required data rate is high, it is possible to send multiple bytes in the
2704 Segment DATA field. The Extended Asynchronous Protocol has a DATA field size that can range from 2
2705 to 28 Slots inclusive by increments of two Slots. The processes of channel ownership management and
2706 flow control in the Extended Asynchronous Protocol are identical to the ones in the Asynchronous
2707 Protocol.

113
2708 The difference lies in the addition of a second TAG field Slot. This is written by the source of the Data and
2709 shall indicate how many bytes are valid (and associated to the P bit) in the DATA field because the data
2710 transfer length might not be a multiple of the DATA field length. This value is referred to as the number of
2711 valid bytes (NVB).
2712 The Frame Structure does not allow more than 31 Slots in the Segment DATA field. Since the Extended
2713 Asynchronous Transport Protocol requires a DATA field that is an even number of bytes, NVB can take
2714 values in the range 0 to 14. In any case, the largest value of NVB is bounded by the number of consecutive
2715 bytes available in the Data Space, which depends on the Subframe Mode and the Extended Asynchronous
2716 Data Channel's Segment Interval. See sections 6.3.1.4 and 6.4.2 for more information on Subframe coding
2717 and the Segment Interval, respectively.
2718 If the channel is not owned by either the source Device or the sink Device, the second TAG field Slot shall
2719 not be driven.
2720
2721
2722 Figure 50 Extended Asynchronous Protocol Segment Organization
2723 In addition to the information already conveyed by the TAG bits, the source Device shall indicate how
2724 many bytes are valid (and associated to the P bit) in the DATA field because the data transfer length might
2725 not be a multiple of the DATA field length. A second TAG field Slot (4-bits) is allocated to the coding of
2726 the number of valid bytes (NVB).
2727 Table 56 TAG field Slot Layout for the Extended Asynchronous Protocol
Cell Name Source Sink Description

C7 T1 W R Primary Owner Token. Used by the primary owner to indicate that
it owns the AUX+DATA fields
C6 T2 R W Secondary Owner Token. Used by the secondary owner to indicate
that it owns the AUX+DATA fields
C5 CTS R/W W/R Clear To Send. CTS=0 indicates that the source shall stop
transmitting data
C4 P W/R R/W PRESENCE bit. P=1 indicates that data is present in the current
Segment
C3 NVB[3] W/R R/W MSB of the NVB value
C2 NVB[2] W/R R/W
C1 NVB[1] W/R R/W
C0 NVB[0] W/R R/W LSB of the NVB value

114
2728 9.3.6.1 Example for the Extended Asynchronous Protocol (informative)
2730 section 9.3.6. The example assumes that the DATA field is sixteen Slots (eight bytes) wide and that a data
2731 transfer of twenty-one bytes (two packets of eight bytes and one packet of five bytes) shall be transported
2732 by the Data Channel.
2733 Table 57 Example TAG Slot Sequence for the Extended Asynchronous Protocol
Segment T1 T2 CTS P NVB[3:0] Comment

Segment i 1 0 1 0 0b0000 The sink sets the CTS bit to indicate to the
source that it is ready to accept data.
Segment i+1 1 0 1 0 0b0000 Second occurrence of CTS=1. Flow is now
on, but the source is not allowed to send data
in this Segment.
Segment i+2 1 0 1 1 0b1000 Flow continues to be on, and the source
writes DATA (first eight bytes) in the
Segment (P=1).
Segment i+3 1 0 0 1 0b1000 Flow becomes invalid because CTS is zero,
but the source writes DATA (second eight
bytes) in the Segment (P=1).
Segment i+4 1 0 0 0 0b0000 Flow is now off, and the source is not
allowed to write any further data until it is
flowed on again.
Segment i+5 1 0 1 0 0b0000 The sink sets the CTS bit to indicate that it is
ready to accept data again, but as flow is still
invalid, the source cannot write DATA in
this Segment (P=0).
Segment i+6 1 0 1 0 0b0000 Second occurrence of CTS=1. Flow is now
on, but the source is not allowed to send
DATA in this Segment.
Segment i+7 1 0 1 1 0b0101 Flow continues to be on, and the source
writes DATA (final five bytes) in the
Segment (P=1).
Segment i+8 1 0 1 0 0b0000 The source has finished its transmission and
although still flowed on does not place
DATA in the Segment (P=0).
Segment i+9 0 0 1 0 0b0000 The source ceases requesting ownership of
the channel (T1=0).
Segment i+10 0 0 0 0 0b0000 The primary owner continues with T1=0,
and the ownership state returns to Neither.
Segment i+11 0 0 Z Z 0bZZZZ The channel ownership state is now Neither.
2734 Notes:

115
2736 9.3.7 User Defined Protocol
2737 User protocols provide the ability to extend the SLIMbus data transmission mechanisms. When a User
2738 protocol is used in a Data Channel, it is assumed that a Device connected to the Data Channel knows the
2739 definition of the TAG bits and how they are used. A user protocol description should also define the default
2740 Read/Write states of these TAG bits.
2741 There are two IDs available for User defined protocols. The first protocol ID, User 1, indicates a protocol
2742 with one TAG field Slot. The second protocol ID, User 2, indicates a protocol with two TAG field Slots.
2743 9.4 Auxiliary Bits Format
2744 The auxiliary (AUX) bits carry side information linked to the content of the DATA field. They usually
2745 depend on the type of Device producing the data. The AUX bits shall be driven by the DATA source.
2746 9.4.1 SPDIF Tunneling
2747 The IEC 60958 [IEC01] standard defines 4-bits that are transmitted concurrently with audio data and
2748 framing information within an IEC 60958 sub-frame. It may be necessary to carry these bits along with any
2749 data on SLIMbus.
2750 An IEC 60958 frame is uniquely composed of two sub-frames, each one made of 4-bit fields.
2751
2752 Figure 51 SPDIF Sub-frame Format
2753 The first IEC 60958 sub-frame (left or "A" channel in stereophonic operation) normally starts with
2754 preamble "M". However, the preamble changes to preamble "B" once every 192 frames to identify the start
2755 of the block structure used to organize the channel status information. The second IEC 60958 sub-frame
2756 (right or "B" channel in stereophonic operation) always starts with preamble "W".
2757
2758 Figure 52 SPDIF Block Structure
2759 Bits 28 to 31 are of interest for the definition of the AUX bit field. Bit 4 to 27 shall be carried in the DATA
2760 field.
2761 V is a validity bit, which is set when the channel does not carry linear PCM audio.
2762 U is the User Data bit, which is part of a block structure of 192-bits (see IEC60958).
2763 C is the channel status, which is part of a block structure of 192-bits (see IEC60958).
2764 P is the parity bit, computed in such a way that bits 4 to 31 inclusive carry an even number of ones
2765 and an even number of zeros (even parity).

116
2766 The IEC60958 preamble is not transported with the data over SLIMbus. Therefore, the start of block
2767 structure must be announced in a different manner. The P bit can easily be reconstructed by an SPDIF
2768 transmitter and does not carry crucial information. A Z bit indicating the start of a block structure can
2769 replace it. The Z bit shall be changed to one every IEC60958 frame 0 and changed to zero for all other
2770 frames.
2771 Table 58 AUX Bit Definition for IEC60958
Cell Name Description

C3 Z Frame 0 of IEC60958 block
C2 C Channel status bit, organized in blocks of 192-bits
C1 U User Data bit, organized in blocks of 192-bits
C0 V Validity. Set when the channel does not carry linear PCM audio
2772 9.4.2 User-Defined AUX Field
2773 A user-defined AUX field format provides the ability to define custom sideband information. When a user-
2774 defined AUX field format is used with a Data Channel, it is assumed that a Device connected to the Data
2775 Channel knows the definition of the AUX bits.
2776 Two formats are provided for the AUX field, the first with four AUX bits and the second with eight AUX
2777 bits.
2778 9.4.3 AUX Field Format ID
2779 Table 59 lists the AUX Field Format IDs that shall be used when defining a channel. A Device shall not
2780 send a reserved AUX Field Format code when defining or updating the content of a Data Channel. A
2781 Device that receives a Reserved AUX format codes shall behave as if it received an unsupported AUX
2782 format code.
2783 If a Data Source does not support the AUX format as specified for a Data Channel, it shall fill the AUX
2784 field with zeroes. A Data Source that receives an unsupported AUX format should set its EX_ERROR
2785 Information Element if it supports such range checking. Refer to section 11.6 for more details on parameter
2786 range checking.
2787 If a Data Sink does not support the AUX format as specified for a Data Channel, the Data Sink shall ignore
2788 the contents of the AUX field. A Data Sink that receives an unsupported AUX format may set its
2789 EX_ERROR Information Element if it supports such range-checking.
2790 Table 59 AUX Field Format ID
AF[3:0] Number of AUX field Slots Usage of AUX field Slots

0b0000 0 Not applicable
0b0001 1 ZCUV for tunneling IEC60958
0b0010 1
0b0011 1
0b0100 1 Reserved
0b0101 1
0b0110 1

117
AF[3:0] Number of AUX field Slots Usage of AUX field Slots

0b0111 1
0b1000 1
0b1001 1
0b1010 1
0b1011 1 User defined
0b1100 2
0b1101 2 Reserved
0b1110 2
0b1111 2 User defined
2791 9.5 Data Type Field
2792 The Data Type field identifies the DATA field content of a Segment and shall be coded as shown in Table
2793 60. The Data Type field is used in the NEXT_DEFINE_CONTENT and CHANGE_CONTENT Messages.
2794 Table 60 Data Types
DT[3:0] Data Type

0b0000 Not Indicated
0b0001 LPCM audio (offset sign-and-magnitude, MSB justified, MSB first)
0b0010 IEC61937 Compressed audio
0b0011 Packed PDM audio
0b0100 Reserved
to 0b1111
2795 A source Device may use the Not indicated Data Type code to inform the destination Device the contents
2796 of a Data Channel are not one of the defined Data Types or are unidentified.
2797 A Device shall neither define nor update the content of a Data Channel using a Reserved Data Type. A
2798 Device that receives such a code in a Data Channel's content definition or update Message shall behave as
2799 if it received a Not Indicated Data Type.
2800 There shall be exactly one audio channel per Data Channel for the LPCM audio Data Type. The audio
2801 samples on the DATA line shall use the offset sign-and-magnitude number format. Applications typically
2802 use a twos-complement number format for LPCM audio samples. Consequently, Sources and Sinks of
2803 LPCM audio will likely need to translate between these two formats. The translation between formats is
2804 inexpensive, especially when done bit-serially in hardware. Table 61 shows common values in both offset
2805 sign-and-magnitude and twos-complement formats.
2806 Table 61 LPCM Audio Number Format Comparison
Signed Fraction Offset Sign-and-Magnitude Twos-complement

+ 32767 / 32768 b_0_111111111111111 b_0_111111111111111
+ 127 / 32768 b_0_000000001111111 b_0_000000001111111

118
Signed Fraction Offset Sign-and-Magnitude Twos-complement

+ 7 / 32768 b_0_000000000000111 b_0_000000000000111
+ 3 / 32768 b_0_000000000000011 b_0_000000000000011
+ 1 / 32768 b_0_000000000000001 b_0_000000000000001
0 b_0_000000000000000 b_0_000000000000000
- 1 / 32768 b_1_000000000000000 b_1_111111111111111
- 3 / 32768 b_1_000000000000010 b_1_111111111111101
- 7 / 32768 b_1_000000000000110 b_1_111111111111001
- 127 / 32768 b_1_000000011111110 b_1_111111100000001
- 32767 / 32768 b_1_111111111111110 b_1_000000000000001
2807 With quiet audio signals, the offset sign-and-magnitude format has the majority of its bits equal to zero.
2808 Since the DATA line uses NRZI coding, power consumption in the physical layer is reduced for quiet
2809 signals. In addition, conducted and radiated interference tends to be less with the offset sign-and-magnitude
2810 format than with the twos-complement format.
2811 9.6 Presence Rate
2812 The Presence Rate of a constant bitrate stream is the mean flow rate of that stream expressed in occupied
2813 Segments of that Data Channel per second. For variable bitrate streams it is an upper bound on the flow
2814 rate, also expressed in occupied Segments per second.
2815 Table 62 Presence Rate
PR[6:3]
PR[2:0] 0b0000 0b0001 0b0010 0b0011 to 0b1111
0b000 Not Indicated Reserved 4k
0b001 12k 11.025k 8k
0b010 24k 22.05k 16k
0b011 48k 44.1k 32k
Reserved
0b100 96k 88.2k 64k
0b101 192k 176.4k 128k
0b110 384k 352.8k 256k
0b111 768k 705.6k 512k
2816 For each Presence Rate defined in Table 62, Annex C identifies the Natural Frequencies for all Clock
2817 Gears.
2818 A Device shall neither define nor update the content of a Data Channel using a Reserved Presence Rate.
2819 A Device that observes such a code in a Data Channel's content definition or update Message shall behave
2820 as if it received a Not Indicated Presence Rate.

119
2821 9.7 DATA Field Length
2822 Information on the length of the DATA field is carried via DL[4:0] in the NEXT_DEFINE_CONTENT and
2823 CHANGE_CONTENT Messages. When DL=0b00000, Sinks may assume that the DATA field consists of
2824 every Slot in the Segment that is not allocated to the TAG or AUX fields.
2825 Table 63 DATA Field Length
DL[4:0] Description
0b00000 Not Indicated
0b00001 to 0b11111 1 to 31 Slots, respectively
2826
2827

120
2828 10 Bus Processes

2829 This section describes and specifies several key SLIMbus processes, bringing together aspects from all
2830 sections. Message sequence charts are used extensively to describe the Message interactions in the Message
2831 Channel. All charts and text assume that Messaging is error free, i.e. no Messages are corrupted or are lost,
2832 unless explicitly mentioned.
2833 Figure 53 shows an example of a simple Message sequence.
Source Destination
MESSAGE
2834
2835 Figure 53 Message Sequence Example
2836 Some of the transactions are split. The request and reply are contained in separate Messages. Figure 54
2837 contain an example of the split transaction.
2838
2839 Figure 54 Split Transaction Example
2840 10.1 Boot and Synchronization Processes
2841 The SLIMbus boot and synchronization processes have been divided into different phases. For each phase,
2842 the allowed behavior of a Component on the bus and the condition for switching to the next phase is
2843 defined in this section.
2844 A Component shall be capable of joining the bus by following the appropriate boot and synchronization
2845 processes. The active Framer shall boot according to section 10.1.1. Clock Receiving and Clock Sourcing
2846 Components shall synchronize according to sections 10.1.2 and 10.1.3, respectively.
2847 A Component cycles through various states, sometimes at a different rate than other Components. At any
2848 given point in time, there is not necessarily a single state that represents all Components on the bus.
2849 Therefore, the state diagrams in this section are described from the viewpoint of a single Component.

121
2850 In order to have more control over system power consumption, the SLIMbus protocol allows a Component
2851 to stop participating on the bus while the SLIMbus is active.
2852 This section also describes the behavior of a Component after it has detected loss of Frame, Superframe or
2853 Message synchronization. A Component shall implement the necessary recovery mechanisms to deal with
2854 the loss of Superframe synchronization, Frame synchronization, and Message synchronization.
2855 10.1.1 Active Framer Boot Sequence
2856 The Clock Sourcing Component is responsible for booting the SLIMbus. As such, it is responsible for
2857 starting the CLK, for writing the information in the Framing Channel and for transmitting the Guide
2858 Channel. During the boot process, the active Framer shall progress through five different states: Undefined,
2859 CheckingDataLine, StartingClock, StartingData, and Booted. A state diagram that describes the mandated
2860 behavior can be found in Figure 55. Figure 56 shows the detectable behavior of the Clock Sourcing
2861 Component on the bus.
Undefined
UndefinedEvent
CheckingDataLine
DataLineOK
BusShutdown
StartingClock
InternalTimeOut BusReset
or
ComponentReset
StartingData
FramesComplete
Booted
2862
2863 Figure 55 Boot Process for the Active Framer
2864 10.1.1.1 Undefined State
2865 In the Undefined state, no requirement on the behavior of the CLK and DATA terminals is made in this
2866 document. The event that initiates the change to the CheckingDataLine state is also outside of the scope of
2867 this document.
2868 10.1.1.2 CheckingDataLine State
2869 The CheckingDataLine state allows the active Framer to verify that the DATA line is available for use, that
2870 the bus holders are operational and that Devices connected to the bus are in a state suitable to start driving
2871 the CLK line.

122
2872 In the CheckingDataLine state the active Framer shall continuously drive the CLK line below VOL and
2873 transmit the Framing Channel and the Guide Channel on the DATA line using its internal clock for timing.
2874 Additionally, the active Framer shall read the state of the DATA line on every negative edge of its internal
2875 clock, and perform the following checks. In the driven Cells, i.e. in the Framing Channel Slots and the
2876 Guide Channel Slots, the active Framer shall verify that the read state of the DATA line is the same as the
2877 driven state. For undriven Cells, the active Framer shall verify that the read state of the DATA line is the
2878 same as the read state for the previous Cell.
2879 The active Framer shall not move to the StartingClock state until there have been eight consecutive Frames
2880 with no DATA line-check failures. The active Framer may implement a time out function and return to the
2881 Undefined state if it is not able to continue to the StartingClock state within a reasonable period of time.
2882 This period of time is beyond the scope of this specification.
2883 The active Framer shall have all Framing Information, and any additional information, necessary to start
2884 the bus before this state is reached. Any requirements for obtaining this information shall be described in
2885 the Framer documentation.
2886 10.1.1.3 StartingClock State
2887 In the StartingClock state, the active Framer shall start clocking (toggling) the CLK line. The Clock
2888 Sourcing Component shall refrain from sending any data (including the Framing Channel) on the DATA
2889 line, for four Frames. After four Frames, the active Framer shall change to the StartingData state.
2890 The initial frequency for the CLK line is not mandated in this document. This state can be used to stabilize
2891 the CLK frequency, slew rate or to test the CLK line to otherwise optimize the clock driver circuit, so long
2892 as this does not violate the constraints in section 5.2.2.
2893 10.1.1.4 StartingData State
2894 In the StartingData state, the active Framer shall continue clocking the bus. The Framing Channel and
2895 Guide Channel shall be written by the active Framer while in the StartingData state, enabling rapid
2896 synchronization of the Devices on the bus.
2897 The active Framer shall not transmit any Messages while in this state. Starting at the Superframe boundary,
2898 the active Framer shall transmit sixteen Frames and then change to the Booted state.
2899 10.1.1.5 Booted State
2900 In the Booted state, the active Framer continues to write the Framing Channel and Guide Channel to the
2901 bus. While the Clock Sourcing Component is not in Message synchronization (section 8), the active Framer
2902 shall write the ENT bit and the Guide Value as zero. An active Framer in the Booted state can be moved to
2903 the StartingClock state as described in sections 10.4.1 and 10.4.2.

123
2904
2905 Figure 56 Example CLK and DATA Line Behavior during Boot
2906 10.1.2 Component Synchronization Clock Receiver
2907 This section specifies the synchronization process for Clock Receiving Components.
2908 During the synchronization process, a Clock Receiving Component extracts any necessary information
2909 about the current state of the bus from the two bus lines. Therefore, changes between states are initiated by
2910 observing the CLK and the DATA line.
2911 The synchronization process takes a Component through six states: Undefined, Reset, SeekingFrameSync,
2912 SeekingSuperframeSync, SeekingMessageSync and Operational. See Figure 57. A Component that does not
2913 contain the active Framer shall only transmit data on the SLIMbus while in the Operational state or the
2914 SeekingMessageSync state.

124
Undefined
UndefinedEvent
Reset
DataLineActivity
NoDataLineActivity
SeekingFrameSync
FrameSyncLost
or FrameSyncFound
TimeOut
FrameSyncLost
SeekingSuperframeSync ComponentReset
SuperframeSyncLost FrameSyncLost
In Frame Synchronization
SuperframeSyncFound
In Superframe Synchronization
SuperframeSyncLost SeekingMessageSync
MessageSyncFound
Synchronization
MessageSyncLost
In Message
Operational
2915
2916 Figure 57 Component Synchronization Process
2917 A Component resides in the Undefined state if it is not tracking events on the SLIMbus. An external event
2918 (outside the scope of this specification) initiates the change to the Reset state (Figure 57, UndefinedEvent
2919 transition). A transition on the DATA line causes the Component to move to the SeekingFrameSync state.
2920 The Component remains in this state until three Frame Sync symbols have been detected. Then a change to
2921 the SeekingSuperframeSync state occurs (Figure 57, FrameSyncFound transition), where the Framing
2922 Channel is parsed until the Superframe boundary has been found, and the complete Framing Information
2923 has been received and processed to find the location of the Message Channel. After a valid Guide Byte is
2924 received, the Component moves to the Operational state (Figure 57, MessageSyncFound transition).
2925 Often, a Component begins synchronizing to the bus as the active Framer starts booting. In such cases, a
2926 Components progress through its synchronization states tends to be smooth and deterministic. In contrast,

125
2927 when a Component synchronizes to a bus that is already active, the time it takes to reach the Operational
2928 state is non-deterministic. This is due to the possible occurrence of the Frame Sync symbol in other bus
2929 traffic.
2930 10.1.2.1 Undefined State
2931 In the Undefined state, the behavior of the Component is not characterized. A chip-level reset signal or
2932 software event could be used to bring the Component out of the Undefined state though the specific event
2933 that initiates the change of state is outside the scope of this document. A Component may pause the bus
2934 boot process at this stage by driving the DATA line low, e.g. during hardware power-up.
2935 A Component may be designed such that it allows the bus to be active while the Component itself is in the
2936 Undefined state, i.e. is unpowered. The Component shall meet the requirements expressed in section 5.2.6.
2937 10.1.2.2 Reset State
2938 In the Reset state, a Component shall not drive the bus and shall not impede other Components from
2939 becoming operational. If the Component is ready to join the bus, the Component shall sample the DATA
2940 line at every negative edge of the CLK line. As soon as a change on the DATA line is detected, the
2941 Component should enter the SeekingFrameSync state (Figure 57, DataLineActivity transition).
2942 If a Component moves to the Reset state from the SeekingFrameSync or Operational states, the Component
2943 shall cause each Device in the Component to undergo a Device Reset (section 10.4.3) and release its
2944 Logical Address.
2945 10.1.2.3 SeekingFrameSync State
2946 In the SeekingFrameSync state, Components shall search for repetitions of the Frame Sync symbol. A
2947 Component detecting three Frame Sync symbols repeating at an interval of 192 Slots (768 Cells) shall
2948 change to the SeekingSuperframeSync state (Figure 57, FrameSyncFound transition). During boot, this
2949 transition occurs 385 Slots (1540 Cells) after the first bit of the first Frame Sync symbol has been detected.
2950 The beginning of the first Cell of each of the detected Frame Sync symbols is a Frame boundary. As
2951 indicated in section 6, Frame boundaries are also Subframe boundaries and Slot boundaries. A Component
2952 that has achieved Frame Sync may begin treating the incoming data in Slot form.
2953 In order to provide a reset mechanism for a Component that has not achieved Frame synchronization, the
2954 Component shall monitor DATA line activity. The Component shall move to the Reset state if it detects
2955 DATA line inactivity (no transitions on the DATA line) for 1536 consecutive Cells (Figure 57,
2956 NoDataLineActivity transition). It may move to the Reset state after fewer than 1536 Cells. However, the
2957 Component shall not move to the Reset state before it detects DATA line inactivity of at least 768
2958 consecutive Cells.
2959 A Component that has achieved Frame synchronization shall continuously verify Frame Sync symbols. If
2960 verification fails in two consecutive Frames, a Component shall move to the SeekingFrameSync state
2961 (Figure 57, FrameSyncLost transitions). The Component shall make this move no more than 764 CLK
2962 periods after the second Frame Sync symbol verification failure and shall cause all of its Devices to reset
2963 their Ports, as defined in section 10.4.4. Isolated errors in the verification of Frame Sync symbols shall be
2964 ignored.
2965 10.1.2.4 SeekingSuperframeSync State
2966 In the SeekingSuperframeSync state, a Component verifies the contents of the Framing Information. See
2967 section 6.3.1.1.

126
2968 A Component shall determine from the Superframe Sync pattern which of the eight Frame boundaries is
2969 the Superframe boundary.
2970 A Component shall not change to the SeekingMessageSync state before it has verified the Superframe Sync
2971 pattern over sixteen consecutive Frames. If the Component has not verified the Superframe Sync pattern
2972 after thirty-two Frames, it shall change to the SeekingFrameSync state (Figure 57, TimeOut transition) and
2973 seek Frame synchronization at a different phase.
2974 For Superframes with FE=0, a Component shall read the SM field of the Framing Information and shall not
2975 change to the SeekingMessageSync state until it has observed the contents of this field as being identical
2976 across two Superframes.
2977 In addition, if the Component uses the CG or RF field it shall read the used field and shall not change to the
2978 SeekingMessageSync state until it has observed the contents as being identical across two consecutive
2979 occurrences of the field.
2980 A Component that has achieved Superframe synchronization shall continuously verify the Superframe Sync
2981 pattern. If verification fails in two consecutive Superframes, the Component shall move to the
2982 SeekingSuperframeSync state (Figure 57, SuperframeSyncLost transitions). Isolated verification errors shall
2983 be ignored. A Component shall also continuously verify the SM, and those of the CG and RF Framing
2984 Information fields that they use. For each of those fields, if the Component sees a verification failure in two
2985 consecutive occurrences, it shall move to the SeekingSuperframeSync state (Figure 57, SuperframeSyncLost
2986 transitions). Other conditions that cause the Component to move to the SeekingSuperframeSync state are
2987 detailed in sections 10.2.4 and 10.3.1.
2988 A Component shall cause all Devices within the Component to reset their Ports as defined in section 10.4.4
2989 when moving from the SeekingMessageSync or Operational state to the SeekingSuperframeSync state.
2990 10.1.2.5 SeekingMessageSync State
2991 A Component shall observe the Guide Channel and try to achieve Message synchronization as mandated by
2992 section 8.3.1. Once the Component has achieved Message synchronization, it shall enter the Operational
2993 state.
2994 A Component that has achieved Message synchronization shall continuously verify the Guide Channel and
2995 the Message Channel as described in section 8.3.2. Various events can cause a Component to assume it has
2996 lost Message synchronization. Refer to sections 8 and 10.2.3 for details. If this happens, the Component
2997 shall move to the SeekingMessageSync state.
2998 10.1.2.6 Operational State
2999 In the Operational state, a Component has coherent information on the Subframe Mode and the other
3000 information in the Framing Channel and has access to the Message Channel.
3001 A Component Reset (see section 10.4.2) moves a Component in the Operational state to the Reset state.
3002 10.1.3 Component Synchronization Clock Source
3003 The Message synchronization requirements in sections 8.3, 10.2.3 and 12.2.5.2 apply to the Clock Sourcing
3004 Component just as much as they apply to Clock Receiving Components. The same is true of the Bus Reset
3005 and Component Reset requirements in sections 10.4.1 and 10.4.2. Consequently, a Component has to
3006 support the Reset, SeekingMessageSync and Operational states of Figure 57, even while it is the Clock
3007 Sourcing Component.

127
3008 Referring to Figure 57, a Component should support all of the states in the figure while it is the Clock
3009 Sourcing Component. While a Component is the Clock Sourcing Component, it may use information
3010 passed internally from the active Framer to progress more smoothly through the SeekingFrameSync and
3011 SeekingSuperframeSync states.
3012 10.1.4 Example of the Boot and Synchronization Processes (informative)
3013 Figure 58 shows the synchronization process of a Component that synchronizes at the same time as the
3014 active Framer boots, and its reaction to the signals it receives. The Component autonomously reaches the
3015 SeekingFrameSync state, acquires Frame synchronization and starts on the Superframe synchronization.
3016 Note, at this resolution the Message synchronization state is not visible.
3017
3018 Figure 58 Typical SLIMbus Boot Behavior
3019 10.2 Error Handling
3020 A Device shall maintain a number of Information Elements that can be communicated over the SLIMbus.
3021 These Information Elements are defined in section 7.1.2. Additionally, Class-specific Information Elements
3022 have been defined for Interface Devices, Managers and Framers described in sections 12.2.4, 12.3.4 and
3023 12.4.4, respectively. This section describes a number of detectable errors that influence these Information
3024 Elements.
3025 10.2.1 Transmission Errors
3026 Collisions can occur in the Control Space and Data Space.
3027 For instance, the following non-exhaustive list of possibilities can contribute to Collision in the Data Space:
3028 Incorrect programming of the channel parameters, e.g. Segment Distribution and Segment Length.
3029 Activating two or more sources with the same Channel Number
3030 For the Control Space, the following non-exhaustive list of possibilities can contribute to Collisions:
3031 Two or more Devices using the same Logical Address
3032 Incorrectly interpreting the Frame and Superframe boundaries
3033 Incorrectly interpreting the current Subframe Mode
3034 Incorrectly interpreting Message boundaries

128
3035 The DATA line is monitored for Collisions using the mechanism described in section 5.1.1.
3036 Depending on whether the Collision is detected in the Data Space or Control Space, the Component shall
3037 set the appropriate Information Element of the relevant Device.
3038 10.2.2 Behavior on Collisions within Segments
3039 If a Device detects a Collision during the transmission of a Segment, it shall, before the beginning of the
3040 next Cell, initiate a transmit back-off, whereby it temporarily pauses transmission of the current SLIMbus
3041 Segment. The Device shall resume transmission at the start of the next Segment. The Device shall also
3042 change the DATA_TX_COL Core Information Element to TRUE at the start of transmit back-off. See
3043 section 7.1.2.5.
3044 Note that a Collision in a Data Channel does not cause a Component to stop sending in the Framing
3045 Channel, Message Channel, or any other channel.
3046 10.2.3 Behavior on Collisions within the Message Channel
3047 A Component shall initiate a transmit back-off when a Collision is detected in the Message Channel and set
3048 the MC_TX_COL Information Element in its Interface Device. See section 12.2.5.5. During the transmit
3049 back-off, the SLIMbus Component shall not attempt any further transmission in the Message Channel. A
3050 transmit back-off shall commence before the beginning of the next Cell. A Component shall lose Message
3051 synchronization and return to the SeekingMessageSync state. The Component shall need to regain Message
3052 synchronization by waiting for the next valid Guide Byte.
3053 If the Component was transmitting a Message, the SLIMbus Component should retransmit the complete
3054 Message, using the normal arbitration mechanism, after it has regained Message synchronization.
3055 Immediately after the transmit back-off is initiated, the Component should start the Message
3056 synchronization process. See section 8.3. The transmit back-off shall be terminated as soon as Message
3057 synchronization is regained.
3058 Note that a Collision in the Message Channel does not cause a Component to suspend a transmission in the
3059 Framing Channel or a Data Channel.
3060 10.2.4 Framing Errors
3061 The mechanisms described in Figure 57 also play a role in recovering from bit errors, spurious CLK line
3062 transitions and some of the higher protocol errors on the SLIMbus. Spurious CLK line transitions result in a
3063 Component moving from the Operational state to the SeekingFrameSync state because verification of the
3064 Frame Sync symbol fails. In addition, a Component continuously verifies one or more of the Framing
3065 Information fields. If, for some reason, the information changes without detecting the appropriate Message
3066 in the Message Channel, a Component shall assume that it has missed a vital bus Message and change to
3067 the SeekingSuperframeSync state (see Figure 57).
3068 10.2.5 Messaging Errors
3069 A Device shall set the UNSPRTD_MSG Information Element if it receives a unicast Message that it does
3070 not implement as a destination Device. Note that this applies for all Message Types as found in Table 32.
3071 The Device shall not act upon an unsupported Message with the exception of setting the UNSPRTD_MSG
3072 Information Element.
3073 A destination Device shall not set the UNSPRTD_MSG Information Element if it receives a broadcast
3074 Message that is optional for the Device Class to which the destination Device belongs.

129
3075 A destination Device shall discard a Message it determines to be unsupported.
3076 10.2.6 Reporting Core Information
3077 A Device may report the value of Core Information Elements to other Devices using the
3078 REPORT_INFORMATION Message (section 11.3.5). For more information on reporting Information
3079 Elements see section 7.1.3.
3080 10.3 Bus Management
3081 A number of bus processes require that all Components on the bus perform a change of state at exactly the
3082 right moment (at a Superframe boundary). If a Device objects to a particular change of state, the active
3083 Manager shall configure the Device so that it does not interfere with bus operation while in the new bus
3084 state.
3085 This section captures these processes and specifies necessary timing and behavior of the different
3086 Components and Devices.
3087 10.3.1 General Behavior
3088 The bus processes described in this section all follow the same sequence: A
3089 BEGIN_RECONFIGURATION Message, followed by a number of Reconfiguration Messages that can be
3090 identified by the NEXT_ prefix, are terminated by the RECONFIGURE_NOW Message, which causes all
3091 Devices to change their mode of operation at a well defined Superframe boundary. Just like all the other
3092 Messages, Reconfiguration Messages shall behave as though they are executed in order. Figure 59 shows
3093 an example of three Reconfiguration Messages followed by a RECONFIGURE_NOW Message.
3094 The active Manager shall indicate the start of a Reconfiguration Sequence by broadcasting the
3095 BEGIN_RECONFIGUATION Message. No Reconfiguration Messages shall be transmitted without first
3096 sending the BEGIN_RECONFIGURATION Message. The active Manager shall end a Reconfiguration
3097 Sequence with the RECONFIGURE_NOW Message.
3098 A Component shall assume that it has received all Reconfiguration Messages if it has not lost Message
3099 synchronization between receiving a BEGIN_RECONFIGURATION Message and a
3100 RECONFIGURE_NOW Message. If a Component receives a RECONFIGURE_NOW Message without
3101 first receiving a corresponding BEGIN_RECONFIGURATION Message, or if a Component loses Message
3102 synchronization between the BEGIN_RECONFIGURATION and RECONFIGURE_NOW Messages, the
3103 Component shall set the EX_ERROR Information Element as defined in section 7.1.2.3 if the EX_ERROR
3104 Information Element is implemented. In addition, a Clock Receiving Component shall lose Superframe
3105 synchronization at the Reconfiguration Boundary (Figure 57, SuperframeSyncLost transition).
3106 The effect of the RECONFIGURE_NOW Message is the cumulative effect of all Reconfiguration
3107 Messages, as though they are executed in order within a single Cell period. This implies that multiple
3108 Reconfiguration Messages that change the same bus property, such as Clock Gear, behave as though only
3109 the last change was received.

130
ActiveManager Device1 Framer Device3
BEGIN_RECONFIGURATION
NEXT_CLOCK_GEAR
NEXT_SUBFRAME_MODE
NEXT_ACTIVATE_CHANNEL
RECONFIGURE_NOW
3110
3111 Figure 59 Example Bus Management Sequence
3112 10.3.1.1 RECONFIGURE_NOW Timing
3113 Pending changes shall take effect at the first Superframe boundary that comes at least two Slots after the
3114 end of the RECONFIGURE_NOW Message. This Superframe boundary is called the Reconfiguration
3115 Boundary. See Figure 60 and Figure 61. Note, a Component that does not observe a PACK in response to a
3116 RECONFIGURE_NOW Message shall not execute the Reconfiguration Messages. A Device within the
3117 Component shall not discard the announced changes. As with any Message that does not receive a PACK,
3118 the active Manager should retransmit the RECONFIGURE_NOW Message if a change to the bus
3119 configuration is still required.
3120 A Component shall behave as though all Reconfiguration Messages are executed at the associated
3121 Reconfiguration Boundary. Note that although the number of Messages in a Reconfiguration Sequence is
3122 not limited, the number of parameters that the Messages effect is limited.

131
3123
3124 Figure 60 RECONFIGURE_NOW Message Timing
3125 10.3.1.2 Behavior after a RECONFIGURE_NOW
3126 After a RECONFIGURE_NOW Message, a Component and its Devices continue operation until the
3127 Reconfiguration Boundary. At that moment, the Component shall change its behavior to reflect all of the
3128 pending Messages.
3129
3130 Figure 61 Using RECONFIGURE_NOW to Switch between Operating Mode
3131 A Device might not be able to execute the pending changes of a RECONFIGURE_NOW Message at the
3132 Reconfiguration Boundary, because it might not have received all Reconfiguration Messages. This occurs
3133 for instance when a Component becomes synchronized to the SLIMbus after the first NEXT Message has
3134 been sent, but before the RECONFIGURE_NOW Message.
3135 Figure 62 shows what happens when a Component that does not have the necessary information tries to
3136 execute the RECONFIGURE_NOW Message. The Component just gains Superframe synchronization after
3137 the first Superframe, only for its Devices to receive a RECONFIGURE_NOW Message.

132
3138
3139 Figure 62 Loss of Superframe Synchronization after RECONFIGURE_NOW Message
3140 10.3.1.3 Behavior of the BEGIN_RECONFIGURATION Message
3141 The BEGIN_RECONFIGURATION Message indicates to a Device the start of a Reconfiguration

3142 Sequence. If the active Manager needs to cancel all announced changes, it shall send a second
3143 BEGIN_RECONFIGURATION Message. The reception of a BEGIN_RECONFIGURATION Message
3144 shall clear all pending bus state changes that have been communicated by Reconfiguration Messages.
3145 10.3.1.4 Combinations of Reconfiguration Messages
3146 The order of the Reconfiguration Messages influences the result of the RECONFIGURE_NOW Message.
3147 Multiple Reconfiguration Messages can influence the same parameter in a Component, e.g. the Clock Gear.
3148 In this case, the most recently received value shall be used to update the parameter.
3149 Reconfiguration Messages that receive a negative acknowledge shall be discarded by a Component.
3150 After the RECONFIGURE_NOW Message is sent, the active Manager shall not broadcast any
3151 Reconfiguration Messages until after the Reconfiguration Boundary. The active Manager may prevent error
3152 conditions from occurring by simply delaying all of its outgoing Messages until after the Reconfiguration
3153 Boundary.
3154 10.3.1.5 Verification of Announced Changes
3155 At any point during the Reconfiguration Messages, the active Manager may interact with any or all of the
3156 SLIMbus Devices to verify whether the Device can still operate under the announced conditions. A Device
3157 may implement the RECONFIG_OBJECTION Information Element as specified in section 7.1.2.4. The
3158 active Manager shall use the REQUEST_INFORMATION and the REPLY_INFORMATION Message
3159 pair for this interaction. The active Manager may use this mechanism before sending the
3160 RECONFIGURE_NOW Message. See Figure 63 for an example.

133
3161
3162
3163 Figure 63 Verification of Reconfiguration Message Example
3164 10.3.2 Pausing and Restarting the Bus Clock
3165 The active Manager may request the active Framer pause the bus clock at the associated Reconfiguration
3166 Boundary by sending a NEXT_PAUSE_CLOCK Message during a Reconfiguration sequence. Just like
3167 most Reconfiguration Messages, the NEXT_PAUSE_CLOCK Message can be stacked with any other
3168 Reconfiguration Message.
3169 If any other Reconfiguration Messages have been sent, their changes take effect when the bus is restarted
3170 after a Clock Pause. For example, if a NEXT_CLOCK_GEAR Message has been sent, the active Framer
3171 restarts the bus in the announced Clock Gear.
3172 The payload of the NEXT_PAUSE_CLOCK Message defines the clocking recovery behavior of the active
3173 Framer. A Framer shall support all Clocking Recovery strategies listed as Mandatory, and may also
3174 support any Clocking Recovery strategy listed as Optional, in Table 66. An active Framer that receives
3175 an unsupported value shall behave as if it received an Unspecified Delay value.
3176 The behavior during a Clock Pause is shown at the bus level in Figure 64 and Figure 65.
3177
3178 Figure 64 Physical Layer Behavior during a Clock Pause

134
3179 The active Framer shall pause the CLK after the positive edge of the first clock cycle of the new
3180 Superframe, but shall not send the first bit of the Frame Sync symbol, i.e. the active Framer does not toggle
3181 the DATA line at the Superframe boundary.
3182 The Framer shall stop the CLK line at the Superframe boundary, after the first low-to-high transition of the
3183 first clock cycle of the new Superframe, but before the first high-to-low transition. Note that because of the
3184 NRZI coding, the DATA signal can be either high (VIH) or low (VIL) when the CLK is stopped.
3185 The active Manager shall transmit the necessary Messages to suspend any activity on the bus and in a
3186 Device prior to activating a Clock Pause. A channel that is not deactivated by the active Manager shall
3187 remain active over a Clock Pause.
3188 If a Message is interrupted by a Clock Pause, i.e. only part of the Message has been sent at the Superframe
3189 boundary, the source Device shall resume sending the rest of the Message in the first Message Slot after the
3190 Framer has resumed toggling the CLK line.
3191 A Component, its Devices and their Ports shall resume normal operation after wake-up as though the Clock
3192 Pause never happened.
3193
3194 Figure 65 Restart of a Paused Bus Clock
3195 A Device may prompt the Framer to restart the CLK by transmitting a logical one on the DATA line during
3196 a Clock Pause. After observing a change of state of the DATA line, the Framer shall restart the CLK signal.
3197 The timing requirements for the CLK restart are mandated by the active Manager in the payload of the
3198 NEXT_PAUSE_CLOCK Message. See Table 66.
3199 At the Clock restart, the CLK line and Frame Structure shall be adapted to reflect any additional announced
3200 changes. On the first clock cycle, the active Framer shall send the first bit of the Frame Sync symbol of the
3201 first Frame of a new Superframe.

135
Active Manager Device1 Framer Device3
NEXT_PAUSE_CLOCK
RECONFIGURE_NOW
Reconfiguration Boundary
3202
3203
3204 Figure 66 Clock Pause Announcement
3205 10.3.3 Bus Shutdown
3206 The active Manager shall announce shutdown of the bus by broadcasting the NEXT_SHUTDOWN_BUS
3207 Message. The active Framer shall respond to this command by moving to the Undefined state (Figure 55) at
3208 the associated Reconfiguration Boundary. At this point, a Component whose Interface Device supports
3209 NEXT_SHUTDOWN_BUS shall move to the Undefined state (Figure 57). If the bus reboots after having
3210 been in the Undefined state, these Components shall go through the complete boot process as described in
3211 section 10.1. A Component can be powered down using mechanisms outside of the scope of this
3212 specification. The bus can be restarted only by going through the boot sequence.
3213
3214 Figure 67 Shutdown Announcement
3215 10.4 Reset Hierarchy
3216 This section defines how the reset of SLIMbus elements, including the entire bus, is accomplished. For
3217 clarity, the processes are described in a top-down, hierarchical fashion, beginning with a reset of the entire
3218 bus, followed by a Component Reset, a Device Reset and a Port Reset.

136
3219 10.4.1 Bus Reset
3220 A Bus Reset causes all Components on the bus to undergo a Component Reset (section 10.4.2). To initiate
3221 the Bus Reset, the active Manager sends a Reconfiguration Sequence that contains a NEXT_RESET_BUS
3222 Message. If a Component is in its Operational state and its Interface Device supports the
3223 NEXT_RESET_BUS Message, the Bus Reset shall directly cause the Component to undergo a Component
3224 Reset. Otherwise, the Component resets indirectly as described below.
3225 At the Reconfiguration Boundary that is associated with the NEXT_RESET_BUS announcement, the
3226 active Framer shall leave the Booted state as shown in Figure 68 (BusReset transition) and repeat its boot
3227 sequence starting at the StartingClock state (see section 10.1.1.3 and beyond). The active Framer may
3228 autonomously change the Clock Gear, Subframe Mode and Root Frequency. If the active Framer does
3229 change any of the bus parameters, it shall use legal values as described in section 6.3.1.
3230 After the Reconfiguration Boundary, the Clock Sourcing Component sends four Frames without any
3231 information in the Framing Channel (0x0 in all Framing Slots). This sequence causes a Component not
3232 directly reset by the NEXT_BUS_RESET Message to lose Frame synchronization in two Frames, and then
3233 causes the Component to perform a Component Reset in four Frames, as described in sections 10.1.2.2 and
3234 10.1.2.3.
3235 Note, that if the NEXT_RESET_BUS announcement is combined with other Reconfiguration Messages,
3236 the changes to the bus configuration induced by these other announcements are likely to be negated by the
3237 subsequent reset sequence. As an example, the effect of a NEXT_ACTIVATE_CHANNEL is cancelled
3238 several Frames later by the absence of the Frame Sync symbols thus causing any Devices involved in the
3239 particular transport to lose Frame synchronization.
Undefined
UndefinedEvent
CheckingDataLine
DataLineOK
BusShutdown
StartingClock
InternalTimeOut BusReset
or
ComponentReset
StartingData
FramesComplete
Booted
3240
3241 Figure 68 Active Framer Reset State Diagram

137
3242 10.4.2 Component Reset
3243 A Component Reset causes a Component to repeat part of its synchronization process. Also, all Devices
3244 within the Component are reset and release their Logical Addresses. There are two ways to reset a
3245 Component:
3246 Reset of the complete bus as described in section 10.4.1
3247 Reset of a single Component. To perform a Component Reset, the active Manager shall send a
3248 RESET_DEVICE Message to the Interface Device of the Component that it wants to reset. A
3249 Component in the Operational state that receives this Message shall move to the Reset state
3250 (Figure 57). The Clock Sourcing Component shall move its active Framer to the StartingClock
3251 state (Figure 55).
3252 A Clock Receiving Component shall perform the Reset without disturbing the bus operation, i.e. without
3253 generating glitches on the bus. Following a Component Reset, the Component shall follow the process
3254 defined in section 10.1.2 or 10.1.3 to resynchronize to the bus.
3255 10.4.3 Device Reset
3256 A Device Reset shall result in the Device performing a Port Reset for all of its Ports (section 10.4.4), if any,
3257 and performing a reset of all implemented Core Information Elements (section 7.1.2).
3258 A Device Reset can be initiated in multiple ways:

3259 as part of a complete Bus Reset,
3260 as part of a Component Reset,
3261 by receiving the RESET_DEVICE Message.
3262 As the result of a reset, a Device shall change all implemented Core Information Elements to their reset
3263 values. If the Device Reset is not part of a Component Reset, the Component shall remain in the
3264 Operational state. Any announced changes shall be lost by the Device and it shall act as though it has not
3265 received a BEGIN_RECONFIGURATION Message. If the Device contains any Ports, the Device shall
3266 reset these Ports, and as a result stop participating in any ongoing transports.
3267 There are no timing requirements for the execution of the RESET_DEVICE Message, although a Device
3268 should be designed in such a way that the time it takes for resetting it is minimal.
3269 A Device Class definition should contain additional Class-specific requirements for the RESET_DEVICE
3270 Message and that the Component documentation contains a description of product specific behavior. For
3271 instance, guidance should be given on the reset of Class-specific Information Elements.
3272 For the Device Classes defined in this document, special reset behavior is defined in section 12.
3273 10.4.4 Resetting a Port
3274 Resetting a Port shall result in that Port stopping participation in any ongoing data transfer. The Port shall
3275 move to the Disconnected state in Figure 80.
3276 A Port Reset can be initiated in the following ways:

3277 as part of a complete Bus Reset
3278 as part of a Component or Device Reset
3279 as a result of DISCONNECT_PORT or NEXT_REMOVE_CHANNEL Message (section 10.13)

138
3280 if the Component loses Superframe or Frame synchronization
3281 10.5 Clock Gear Changes
3282 The active Manager shall announce a Clock Gear change by sending the NEXT_CLOCK_GEAR Message
3283 using the broadcast mechanism. The NEXT_CLOCK_GEAR Message is intended to allow a Device to
3284 prepare for the Clock Gear change by, for instance, calculating the divider settings for a PLL that will be
3285 needed after the Clock Gear change. If a Device is not capable of performing its function at a specific
3286 Clock Gear, the active Manager is responsible for disabling that Device before the Clock Gear change is
3287 activated.
3288 A Component shall configure its Frame Layer according to the pending Clock Gear at the associated
3289 Reconfiguration Boundary.
NEXT_CLOCK_GEAR
.
.
.
RECONFIGURE_NOW
Reconfiguration Boundary
3290
3291 Figure 69 Clock Gear Change Announcement
3292 The active Manager shall broadcast the RECONFIGURE_NOW Message to initiate a Clock Gear change.
3293 10.5.1 Behavior of Channels during a Clock Gear Change
3295 Channel location in the Frame and Superframe for the Framing Channel shall remain constant over a Clock
3296 Gear change. As a result, repetition rates of Frames and Superframes changes, as discussed in section
3297 10.5.1.4. After the Reconfiguration Boundary, the active Framer shall transmit the new Clock Gear value in
3298 the Framing Channel as instructed by the active Manager.
3300 A NEXT_CLOCK_GEAR Message shall not influence the location and parameters of the Message
3301 Channel.

139
3302 10.5.1.3 Data Channels
3303 In absence of explicit Messages from the active Manager changing the definition of a Data Channel, the
3304 Data Channel parameters shall remain constant over a Clock Gear change. While the active Manager may
3305 use the default behavior, it should explicitly reprogram all channel definitions before changing the Clock
3306 Gear.
3307 Typical Messages sent by the active Manager during a Clock Gear change include
3308 NEXT_DEFINE_CHANNEL (section 11.4.9), NEXT_DEACTIVATE_CHANNEL (section 11.4.12) and
3309 NEXT_REMOVE_CHANNEL (section 11.4.13).
3310 10.5.1.4 Clock Gear Change Example (informative)
3311 As an example, Figure 70 through Figure 72 show a schematic representation of the SLIMbus using three
3312 different Clock Gears. In the example, the Segments repeat at 48 kHz. The Root Frequency of the bus is
3313 assumed to be 24.576 MHz, and uses Subframe Mode 0b01001. In Figure 70 the bus is in Gear 6, and there
3314 is enough bandwidth available for a single 16-bit wide, 48 kHz sample rate flow. The distance between two
3315 Segments is exactly eight Slots. Note, in the figure each numbered box represents one Slot.
0 1 2 3 4 5 6 7
8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23
24 25 26 27 28 29 30 31
32 33 34 35 36 37 38 39
40 41 42 43 44 45 46 47
48 49 50 51 52 53 54 55
56 57 58 59 60 61 62 63
64 65 66 67 68 69 70 71
72 73 74 75 76 77 78 79
80 81 82 83 84 85 86 87
88 89 90 91 92 93 94 95
3316
3317 Figure 70 First 96 Slots of a Superframe in Gear 6
3318 In Figure 71, the active Manager has changed the Clock Gear, such that there is bandwidth available for a
3319 second channel. Typically, the active Manager should send a NEXT_DEFINE_CHANNEL Message that
3320 increases the repeat distance between two Segments to sixteen to keep the repetition rate (in seconds)
3321 constant. As a result, the intermediate Slots (10-13) become available for the second channel. Note also that
3322 the Control Space has doubled in bandwidth, as the Subframe Mode is constant. If the active Manager does
3323 not send the appropriate NEXT_DEFINE_CHANNEL Message, the channel parameters stay the same over
3324 the Reconfiguration Boundary and the channel doubles in bandwidth, i.e. the repetition rate doubles.

140
3325
3326
3327 Figure 71 Full Frame in Gear 7
3328 In Figure 72, the active Manager has increased the Clock Gear again to Gear 8. This has again doubled the
3329 number of Slots available for the Control Space. In addition, it has become possible to transport four 16-bit,
3330 48 kHz sample rate flows, assuming that the active Manager adapts the channel parameters again.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95
96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127
128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159
160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191
192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223
224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255
256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287
288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319
320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351
3331 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383
3332
3333 Figure 72 Two Frames in Gear 8
3334 10.6 Subframe Mode Change
3335 The active Manager shall announce a change of Subframe length by broadcasting the
3336 NEXT_SUBFRAME_MODE Message. This Message allows a Device to prepare for the changes in the
3337 definition of the Message Channel. The new Subframe Mode is indicated in the payload of the
3338 NEXT_SUBFRAME_MODE Message according to Table 15.

141
3339
3340 Figure 73 Changing the Message Channel Characteristics
3341 The active Manager shall broadcast a RECONFIGURE_NOW Message to initiate the announced Subframe
3342 Mode change.
3343 A Component shall configure its Frame Layer according to the pending Subframe Mode at the associated
3345 10.6.1 Behavior of Channels during a Change of Subframe Length
3347 The change of Subframe Mode has no influence on the location and width of the Framing Channel, but the
3348 active Framer shall adapt the content of the Framing Channel to match the new bus parameters.
3350 The Subframe Mode determines the parameters of the Message Channel, as defined in section 6.3. If the
3351 new definition of the Message Channel overlaps with existing Data Channels, the active Manager shall
3352 move or cancel the Data Channels before it broadcasts the RECONFIGURE_NOW Message.
3354 The NEXT_SUBFRAME_MODE has no influence on the definitions of the Data Channels. However,
3355 because of programming errors, or in some other extreme cases, overlap between the Message Channel and
3356 a Data Channel could occur. In this case the Component in which this conflict occurs shall give the
3357 Message Channel priority over the Data Channel. This implies that a Component shall never overwrite the
3358 Message Channel with a Segment, even though the overlap is the result of explicit programming by the
3359 active Manager. Note that Root Frequency changes can influence the Transport Protocol that is needed to
3360 transport the Data through a channel.
3361 10.7 Root Frequency Change
3362 The active Manager shall announce a Root Frequency change by sending the
3363 NEXT_ROOT_FREQUENCY Message using the broadcast mechanism. This Message is intended to allow
3364 a Device to prepare for the frequency change. If a Device is not capable of performing its function at the
3365 new Root Frequency, the active Manager shall be responsible for disabling that Device, before the new
3366 Root Frequency is used on the bus.

142
NEXT_ROOT_FREQUENCY
RECONFIGURE_NOW
3367
3368
3369 Figure 74 Root Frequency Change Announcement
3370 The active Manager shall broadcast the RECONFIGURE_NOW Message to initiate the Root Frequency
3371 change. At the Reconfiguration Boundary, the active Framer shall change the CLK line to match the
3372 announced Root Frequency and Clock Gear. The active Manager should verify whether the active Framer
3373 is capable of producing the announced Root Frequency by requesting the RECONFIG_OBJECTION
3374 Information Element specified in section 7.1.2.4.
3375 A Component shall configure its Frame Layer according to the pending Root Frequency at the associated
3377 10.7.1 Behavior of Channels during a Root Frequency Change
3379 At the associated Reconfiguration Boundary, the active Framer shall change the contents of the Root
3380 Frequency (RF) field in the Framing Channel to reflect the new Root Frequency.
3382 Unless additional changes are announced, the Control Space width and Subframe length remain constant.
3383 Therefore, the Message Channel bandwidth scales with the bus frequency.
3385 In absence of explicit Messages from the active Manager changing the definition of the Data Channel, the
3386 Segment Distribution and Segment Length remain constant over a Root Frequency change. While the
3387 active Manager may use the default behavior, it should explicitly reprogram all channel definitions before
3388 changing the Root Frequency.
3389 Typical Messages sent by the active Manager during a Clock Gear change include
3390 NEXT_DEFINE_CHANNEL (section 11.4.9), NEXT_DEACTIVATE_CHANNEL (section 11.4.12) and
3391 NEXT_REMOVE_CHANNEL (section 11.4.13).
3392 Note that Root Frequency changes can influence the Transport Protocol that is needed to transport data
3393 through a channel.

143
3394 10.8 Framer Handover
3395 The active Manager shall announce Framer handover by broadcasting the NEXT_ACTIVE_FRAMER
3396 Message. Unless autonomous behavior is mandated by the Device Class definition, the active Manager
3397 shall transmit the necessary Messages to prepare all Devices for the upcoming change.
3398 In this section, the Framer that is leaving the Active state is denoted as the outgoing Framer, while the
3399 Framer that is intended to become the active Framer is denoted as the incoming Framer.
3400 The active Manager shall determine the values for the Message parameters NCo and NCi such that there is
3401 no contention on the CLK line during the handover.
[Active Framer] [Inactive Framer]
Timeout [NCi cycles] ReconfigurationBoundary

Active Obtaining Inactive
ReconfigurationBoundary Timeout [NCo cycles]
Releasing
3402
3403 Figure 75 Framer Handover State Diagram
3404 As shown in Figure 75, Framer handover happens in two distinct steps. The Incoming Framer moves from
3405 the Inactive state to the Obtaining state at the Reconfiguration Boundary. The change from the Obtaining
3406 state to the Active state happens after a timeout of NCi cycles.
3407 Framer Handover also typically implies a change from Clock Sourcing Component to Clock Receiving
3408 Component for the Component that holds the outgoing Framer and a change from Clock Receiving
3409 Component to Clock Sourcing Component for the incoming Framer. Therefore, these Components change
3410 their behavior, such as reset recovery, as specified in section 10.4.
3411 At boot time, the Framer of the Clock Sourcing Component moves to the Active state in Figure 75 and then
3412 boots as described in Figure 55. Any other Framers on the bus enter the Inactive state in Figure 75. The
3413 active Framer needs to be in the Booted state (Figure 55) and both Components in the Operational state
3414 (Figure 57) in order to perform a Framer handover.
3415 In a general case, NCo and NCi can be calculated from NCo = INT(4*Fo/Fi)+1 and NCi = INT(4*Fi/Fo).
3416 See Annex D for a detailed explanation on how to calculate NCo and NCi.
3417 10.8.1 Releasing the Active Framer Role
3418 Immediately after the Reconfiguration Boundary, the active Framer shall drive the CLK line HIGH for
3419 exactly NCo cycles. When NCo cycles have expired, the outgoing Framer shall stop driving the CLK line.
3420 When releasing its role, the active Framer shall not drive the DATA line.

144
3421
3422 Figure 76 Bus Behavior for Framer Handover
3423 10.8.2 Obtaining the Active Framer Role
3424 Starting at the third positive edge of its internal clock following the Reconfiguration Boundary, the
3425 incoming Framer shall drive the CLK line HIGH for NCi cycles. When NCi cycles have expired, the
3426 incoming Framer shall start clocking the bus (toggling the CLK line) and driving the DATA line with the
3427 Frame Sync symbol that starts the next Superframe.
3428 10.8.3 Error Cases
3429 Two error cases are possible:

3430 The outgoing Framer has lost Message synchronization after the NEXT_ACTIVE_FRAMER
3431 Message has been received, or has not received the NEXT_ACTIVE_FRAMER Message. This
3432 causes the outgoing Framer to discard all stacked changes, and therefore it will not participate in
3433 the handover.
3434 The incoming Framer has lost Message synchronization after the NEXT_ACTIVE_FRAMER
3435 Message has been received, or has not received the NEXT_ACTIVE_FRAMER Message. This
3436 causes the outgoing Framer to act normally, but the incoming Framer will not take over. As a
3437 result, the bus will not be clocked anymore.
3438 10.9 Device Discovery
3439 10.9.1 Behavior of Devices other than the Active Manager
3440 The behavior of a Device during Device discovery is shown in Figure 77. Depending on the state the
3441 Device is in, the behavior is different. If a Device has received a Logical Address, i.e. has been enumerated,
3442 it shall enter the Enumerated state directly (HaveLA transition). If a Device is unenumerated, has not yet
3443 received a Logical Address and gains Message synchronization, it shall enter the TryingToAnnounce state

145
3444 and send a REPORT_PRESENT Message to the active Manager. The payload of the REPORT_PRESENT
3445 Message shall contain the Device Class code and the Device Class Version (DCV) of the Device. As soon
3446 as the REPORT_PRESENT has been acknowledged, the Device enters the WaitingForLA state. In this
3447 state, the Device shall wait until it receives an ASSIGN_LOGICAL_ADDRESS or a
3448 REQUEST_SELF_ANNOUNCEMENT Message. The ASSIGN_LOGICAL_ADDRESS Message shall
3449 cause the Device to change to the Enumerated state. The REQUEST_SELF_ANNOUNCEMENT Message
3450 shall cause the Device to return to the TryingToAnnounce state.
EnumerationReset
Reset
SendReportPresent TryingToAnnounce
ReceiveRequestAnnouncement HaveLA
ReleaseLA
RecieveALA
WaitingForLA
RecieveALA
Enumerated
3451
3452 Figure 77 Device Enumeration State Diagram
3453 10.9.1.1 EnumerationReset State
3454 A Device enters the EnumerationReset state upon initial boot or if it releases its Logical Address. A Device
3455 releases its Logical Address if it detaches from the bus (see section 10.9.1.5) or if its Component reaches
3456 the Reset state of Figure 57 (also see sections 10.1.2.2, 10.1.2.3 and 10.4.2).
3457 A Device leaves the EnumerationReset state upon achieving Message synchronization. In the case were the
3458 Device does not have a Logical Address, it proceeds to the TryingToAnnounce state. If the Device has a
3459 predetermined Logical Address, it moves to the Enumerated state. The methods for assigning and
3460 managing predetermined Logical Addresses are outside the scope of this specification.
3461 10.9.1.2 TryingToAnnounce State
3462 While in the TryingToAnnounce state, a Device shall attempt to send the REPORT_PRESENT Message.
3463 The Device shall repeat the REPORT_PRESENT Message until it is positively acknowledged by the active
3464 Manager. After receiving the positive acknowledgement from the active Manager, the Device shall move to

146
3465 the WaitingForLA state. In addition, the Device shall act upon an ASSIGN_LOGICAL_ADDRESS
3466 Message sent to the Enumeration Address of the Device by changing to the Enumerated state.
3467 Although a Device in the TryingToAnnounce state cannot be the destination of a unicast Message, it shall
3468 still observe broadcast Messages and be prepared for a change in the bus configuration, so as not to disrupt
3469 normal bus operation while sending the REPORT_PRESENT Message.
3470 10.9.1.3 WaitingForLA State
3471 While in the WaitingForLA state, a Device shall not send any Messages, but act only upon receiving an
3472 ASSIGN_LOGICAL_ADDRESS Message or a REQUEST_SELF_ANNOUNCEMENT Message.
3473 Although a Device in the WaitingForLA state cannot be the destination of a unicast Message, it shall still
3474 observe broadcast Messages and be prepared for changes in bus configuration.
3475 10.9.1.4 Enumerated State
3476 A Device in the Enumerated state shall ignore all REQUEST_SELF_ANNOUNCEMENT Messages. The
3477 Device is now able to be a full participant in the Message Channel and can be assigned to Data Channels in
3478 the Data Space.
3479 10.9.1.5 Device Behavior when Detaching from the Bus
3480 A Device that will no longer participate in SLIMbus activity shall transmit the REPORT_ABSENT
3481 Message to the active Manager. The Device shall continue to transmit the Message until it receives a
3482 positive acknowledge. Once the Device receives a positive acknowledge, it shall surrender its Logical
3483 Address and shall leave the Enumerated state.
3484 If a Device that has left the bus subsequently wishes to re-join, it shall enter the Discovery state and shall
3485 follow the process described in section 10.9.1.2. The Device shall not assume that it will regain the same
3486 Logical Address as during its previous participation on the bus.
3487 When all Devices within a Component detach from the bus, the Interface Device of that Component should
3488 send a REPORT_ABSENT Message. This Message shall be interpreted by the active Manager as though
3489 all Devices in that Component have sent the REPORT_ABSENT Message separately.
3490 If the Device leaves and rejoins the bus without having received an acknowledgement of its
3491 REPORT_ABSENT Message, the active Manager will see a second REPORT_PRESENT from the Device
3492 without a REPORT_ABSENT in-between. The active Manager may consider this an error if it had no
3493 knowledge of the Device detaching from the bus. This can be handled in the same manner as other error
3494 cases that produce the same situation, such as a Device that has suffered temporary power loss.
3495 10.9.2 Active Manager Behavior
3496 Following the completion of the boot process for its Component, the active Manager shall bypass the
3497 TryingToAnnounce and WaitingForLA states shown in Figure 77, shall enter the Enumerated state and shall
3498 use the Logical Address 0xFF.
3499 10.9.2.1 Static Configuration (informative)
3500 If the bus configuration is determined at design time, ASSIGN_LOGICAL_ADDRESS Messages can be
3501 transmitted by the active Manager as soon as it has achieved Message synchronization. Transmission of the
3502 ASSIGN_LOGICAL_ADDRESS Message will fail if the destination Device has not yet achieved Message
3503 synchronization. The active Manager should wait and retry if this happens. Alternatively, the active
3504 Manager can wait until a Device has achieved Message synchronization before trying to assign a Logical

147
3505 Address. In this case, the active Manager waits until it receives a REPORT_PRESENT Message from the
3506 Device before sending ASSIGN_LOGICAL_ADDRESS.
3507 10.9.2.2 Other Situations (informative)
3508 If the active Manager does not have complete knowledge of the Devices on the bus, it should wait for the
3509 relevant REPORT_PRESENT Messages, before sending the corresponding
3510 ASSIGN_LOGICAL_ADDRESS Messages. This can be the case for instance when multiple vendors are
3511 supplying similar parts for the same Device.
3512 10.9.2.3 Dealing with Corner Cases
3513 If necessary, the active Manager can initiate a retransmission of the REPORT_PRESENT Message by
3514 broadcasting the REQUEST_SELF_ANNOUNCEMENT Message. This causes a Device that has not
3515 received a Logical Address to retransmit a REPORT_PRESENT Message, as mandated in section 10.9.1. If
3516 the active Manager needs to cause all Devices to repeat the REPORT_PRESENT Message, it shall first
3517 force all Devices to return to the TryingToAnnounce state. This can be accomplished, for instance, by
3518 performing a Bus Reset as described in section 10.4.
3519 In some extreme situations, for instance after a power glitch, a Device might resend the
3520 REPORT_PRESENT. In this case, the active Manager should detect that the Device has announced itself
3521 multiple times and take appropriate action.
3522 10.10 Assigning and Changing a Device Address
3523 As already stated in section 10.9, the active Manager shall be responsible for the assignment of Logical
3524 Addresses. There are two Core Messages that deal with Address configuration, called
3525 ASSIGN_LOGICAL_ADDRESS and CHANGE_LOGICAL_ADDRESS.
3526 By design, every Device has an Enumeration Address (see section 8.2.5.1). Initially, except for the active
3527 Manager, a Device does not have a Logical Address, which is used as the Source and Destination of most
3528 Messages. The ASSIGN_LOGICAL_ADDRESS Message shall be used by the active Manager to assign a
3529 Logical Address to a Device. That Logical Address shall be used by the destination Device during the
3530 arbitration sequence of all outgoing Messages. In addition, the ASSIGN_LOGICAL_ADDRESS Message
3531 also informs a Device that it shall be the destination Device of all Messages that contain that specific
3532 Logical Address in their Header. As described in section 11.1.2, the ASSIGN_LOGICAL_ADDRESS
3533 Message shall contain the Enumeration Address (See section 8.2.5.1) of the destination Device.
3534 There are no requirements on the timing of the ASSIGN_LOGICAL_ADDRESS Message. Note, that if
3535 Message execution is delayed for some reason, the Device remains severely limited in the Messages that it
3536 may send (see section 10.9), and that Messages that have this address as Destination will not be
3537 acknowledged.
3538 The active Manager shall ensure that Logical Addresses are unique at bus level so that no two Devices try
3539 to use the same Logical Address at the same time.
3540 A Device shall use the assigned Logical Address, until a Component Reset (see section 10.4) forces the
3541 Device to discard the address, the Device detaches from the bus (see section 10.9.1.5), or until a
3542 CHANGE_LOGICAL_ADDRESS Message is received.
3543 A Device shall ignore a second ASSIGN_LOGICAL_ADDRESS Message and shall not use the Logical
3544 Address in the payload of that second Message. If implemented, the Device should set the EX_ERROR
3545 Information Element, if an ASSIGN_LOGICAL_ADDRESS Message is received while the Device already
3546 has a Logical Address.

148
3547 The CHANGE_LOGICAL_ADDRESS Message shall be used by the active Manager to inform a Device of
3548 a change in the Logical Address that it shall use during the Short arbitration sequence of all outgoing
3549 Messages. In addition, this Message also informs a Device that it is the destination Device of a Message
3550 that contains that new Logical Address in its Header.
3551 There are no requirements on the timing of the CHANGE_LOGICAL_ADDRESS Message, although
3552 execution should be timely. Note, that until the execution has finished, Messages that have this address as
3553 Destination will not be acknowledged. In addition, Messages that are sent by the destination of the
3554 CHANGE_LOGICAL_ADDRESS Message will still use the old Address.
3555 10.11 Changing the Device Arbitration Priority
3556 The active Manager uses the CHANGE_ARBITRATION_PRIORITY Message to assign a new Arbitration
3557 Priority to a Device. A Device may use the Manager assigned Arbitration Priority for some or all of its
3558 outgoing Messages. The Device documentation should indicate how Arbitration Priorities are handled. For
3559 each Message Code if a Device does not use the newly assigned Arbitration Priority, it shall use the default
3560 Arbitration Priority. An active Manager may be able to change the set of Messages for which Arbitration
3561 Priority can be Manager assigned, but such a mechanism is outside of the scope of the document.
3562 A Device shall not change the Arbitration Priority of a Message at runtime unless it receives a
3563 CHANGE_ARBITRATION_PRIORITY Message. A Device shall define High, Default or Low Arbitration
3564 Priority for all Messages. The Arbitration Priority for all Messages sent by a Device shall be stated in the
3565 Device documentation. A Component should arbitrate with the Default Arbitration Priority, but High and
3566 Low Priority Arbitration is also allowed. When arbitrating with an Enumeration Address, a Device shall not
3567 use the Arbitration Priority assigned by the active Manager.
3568 Arbitration Priority takes care of only the high level differences between different Devices on the bus. For
3569 more detailed control over the arbitration behavior on the bus, the active Manager may reassign Logical
3570 Addresses based on priority.
3571 A Device shall behave as though all Messages are executed in the order they are received, even if the
3572 Messages have different Arbitration Priorities.
3573 10.12 Information Requests and Value Requests
3574 A Device that supports the REQUEST_INFORMATION, REQUEST_CLEAR_INFORMATION,

3575 REQUEST_VALUE or REQUEST_CHANGE_VALUE Messages shall adhere to the behavior specified in
3576 this section. These four Messages are called REQUEST Messages, while the REPLY_VALUE and
3577 REPLY_INFORMATION Messages are called REPLY Messages.

149
3578
3579 Figure 78 REQUEST-REPLY Example
3580 An example sequence diagram between an active Manager and multiple Devices with multiple REQUEST-
3581 REPLY interactions is shown in Figure 78.
3582 10.12.1 Behavior of the Transaction Initiator
3583 The source Device of each REQUEST Message shall generate a Transaction ID (TID) for the Message and
3584 then wait for the corresponding REPLY Message with the same Transaction ID. The algorithm to
3585 determine the Transaction ID is out of scope for this document. Devices may elect to generate only a single
3586 REQUEST Message at a time, and wait for the corresponding REPLY Message before generating a second
3587 REQUEST Message. In this case, the TID can always have the same value. Another approach is to
3588 increment the TID between consecutive REQUESTs.
3589 Normally, the initiator receives a corresponding REPLY Message. However, in some cases a REPLY
3590 Message might not arrive. Therefore, the initiator may expire pending transactions if the request remains
3591 pending. This implies that the Transaction ID can be used again and a REPLY Message is not expected
3592 anymore by the initiator. For these Messages, the source Device may choose to resend the REQUEST.
3593 If a REPLY Message is received without a corresponding pending Transaction ID, the Message should be
3594 discarded by the receiving Device.
3595 10.12.2 Behavior of the Transaction Target
3596 A destination Device of a REQUEST Message shall send a corresponding REPLY Message. The REPLY
3597 Message shall contain the same Transaction ID as the REQUEST Message, and shall have the Logical
3598 Address of the source of the REQUEST Message as its Destination Address.
3599 If the Element Code of a REQUEST Message is in the range 0xC000 to 0xFFFF or is an elemental access
3600 that the target does not support, the target shall abbreviate the REPLY Message such that its payload is just
3601 the Transaction ID. Examples of elemental accesses that may be unsupported are requests to an unused
3602 region of the Information Map or requests to bit numbers other than the lowest bit number of an
3603 Information Element. The target may also do the same as a way of denying data requests, e.g. for security
3604 reasons.

150
3605 A Device shall support at least one open transaction, and may support more than one.
3606 If the REPLY does not receive a positive Acknowledge, the REPLY Message should be retransmitted.
3607 REPLY Messages shall not be retransmitted indefinitely.
3608 10.12.3 Atomic Transactions
3609 The REQUEST_CLEAR_INFORMATION and the REQUEST_CHANGE_VALUE Messages request the

3610 Target to behave as though it performs three distinct actions: saves the current contents of the indicated
3611 Information or Value Slice, clears or updates the indicated Information or Value Slice and replies to the
3612 REQUEST Message with the saved contents.
3613 In addition, the Target shall behave as though the first two actions are a single, atomic operation. In other
3614 words, the contents of the indicated Information Slice or Value Slice shall not change between saving the
3615 contents and clearing or updating the contents.
3616 10.13 Channel Management
3617 The active Manager shall be responsible for initializing a Data Channel and communicating the relevant
3618 content parameters to all Devices using that Data Channel.
3619 10.13.1 Initializing a Data Transport
3620 An example of the active Manager constructing a Data Channel is found in Figure 79. Initializing a Data
3621 Channel in this way often occurs in distinct phases, although this specification allows for exchanging the
3622 order of some of the Messages.

151
Active Device1 Device2

Manager Source Sink
CONNECT_SOURCE(PN, CN)
CONNECT_SINK(PN, CN)
NEXT_DEFINE_CHANNEL(CN)
NEXT_ACTIVATE_CHANNEL(CN)
NEXT_DEFINE_CONTENT(CN)
RECONFIGURE_NOW
3623
3624 Figure 79 Example Transport Setup
3625 In the example of Figure 79, four distinct steps can be distinguished: Port association, Data Channel
3626 definition, content definition, and channel activation.
3627 Ports are associated with channels through the CONNECT_SOURCE or CONNECT_SINK Messages,
3628 which indicate to a Device a Port and Channel Number. The channel and content parameters are
3629 communicated through the various DEFINE_CONTENT and DEFINE_CHANNEL Messages and the
3630 activation is announced by the NEXT_ACTIVATE_CHANNEL Message.
3631 Figure 80 contains a state diagram showing the normative behavior for Ports. Initially, a Port is in the
3632 Disconnected state, where it shall not transmit or receive any data. This is also the state where the Port
3633 resides after it has been reset. As soon as the Port is connected to a Data Channel, see section 10.13.1.1, it
3634 moves to the Unconfigured state. As long as a Port is in this state, it shall not transmit or receive any data.
3635 In the Unconfigured state, the Port shall be able to receive channel configuration Messages for the Channel
3636 Number specified by the CONNECT_SOURCE or CONNECT_SINK Message and shall act upon them as
3637 specified for the Message. Channel configuration messages are listed in Table 64.
3638 To move to the Configured state, a Port needs to receive all necessary configuration parameters. The timing
3639 for this transition depends on the Messages that are used. For example, in Figure 79 all the necessary
3640 parameters are communicated in the same Reconfiguration Sequence, and therefore the Port shall move to
3641 the Configured state at the associated Reconfiguration Boundary. If the necessary parameters are
3642 communicated as part of multiple Reconfiguration Sequences, the Port shall move to the Configured state
3643 at the Reconfiguration Boundary that belongs to the sequence that contains the last set of parameters. If a
3644 CHANGE_CONTENT Message is used to broadcast some of the necessary parameters, and the remaining
3645 parameters are sent through a Reconfiguration Sequence, the Port shall move to the Configured state as
3646 soon as all parameters have taken effect, either at the associated Reconfiguration Boundary, or at the first

152
3647 Superframe boundary that occurs at least two Slots after the end of the CHANGE_CONTENT Message,
3648 whichever comes last.
3649
3650 Figure 80 Port State Diagram
3651 10.13.1.1 Connecting Ports
3652 For the Isochronous, Pushed, Pulled and Locked Transport Protocols, the Data Channel shall have exactly
3653 one Port associated to it by the CONNECT_SOURCE Message. For the Asynchronous and Extended
3654 Asynchronous Transport Protocols, the transport shall have exactly one primary owner associated to it by
3655 the CONNECT_SOURCE Message, and one secondary owner associated to it by the CONNECT_SINK
3656 Message. Together, the CONNECT_SOURCE and the CONNECT_SINK Message are called Connection
3657 Messages.
3658 Note, that these Connection Messages are not Reconfiguration Messages and may be transmitted by their
3659 source Device (typically, but not restricted to, the active Manager) outside a Reconfiguration Sequence.
3660 The Connection Messages shall cause the destination Device to start capturing all channel configuration
3661 Messages (Table 64) that contain the same Channel Number as the Connection Message.
3662 Connection Messages may be transmitted, and retransmitted, at any time. When an already connected Port
3663 receives a repeated Connection Message (a Connection Message that does not change the Port connection),
3664 the Port shall continue to function as if the repeated Connection Message had not been received.
3665 Note that this specification does not require a Port to check whether Connection Messages change its
3666 connection. Consequently, when a connection is to be changed, the Device sending the Connection
3667 Message is responsible for managing the state of the Port. This typically involves sending a
3668 DISCONNECT_PORT Message before the new Connection Message.
3669 A Port may check whether Connection Messages change its connection, and may take appropriate action if
3670 they do make a change, including moving from the Configured state to the Unconfigured state.

153
3671 A Port shall capture and act upon the Messages that contain the same Channel Number as the last received
3672 Connection Message, regardless of its current state.
3673 Table 64 Channel Configuration Messages
Message Code Description

(MC[6:0])
0x50 NEXT_DEFINE_CHANNEL (CN, TP, SD, SL)
0x51 NEXT_DEFINE_CONTENT (CN, FL, PR, AF, DT, CL, DL)
0x18 CHANGE_CONTENT (CN, FL, PR, AF, DT, CL, DL)
0x54 NEXT_ACTIVATE_CHANNEL (CN)
0x55 NEXT_DEACTIVATE_CHANNEL (CN)
0x58 NEXT_REMOVE_CHANNEL (CN)
3674 10.13.1.2 Defining the Channel and the Content
3675 After the active Manager has notified all the Devices about their involvement in the transport, the Transport
3676 Protocol and other parameters of the transport can be sent to the Devices. A Port can be notified of the
3677 Channel and Content Parameters as soon as it knows the Channel Number.
3678 10.13.1.2.1 The NEXT_DEFINE_CHANNEL Message
3679 To communicate the channel definition, the active Manager shall broadcast the
3680 NEXT_DEFINE_CHANNEL Message as part of a Reconfiguration Sequence. After the associated
3681 Reconfiguration Boundary, a Device shall ensure that the Segment Distribution, Transport Protocol, and
3682 Segment Length from the payload of this Message are used for the Data Channel. As described in section
3683 10.3.1.1, the channel definition changes from the NEXT_DEFINE_CHANNEL Message are synchronized
3684 with the Subframe Mode changes, to allow for seamless Root Frequency, Clock Gear and Subframe Mode
3685 transitions.
3686 The active Manager is responsible for allocating the available SLIMbus bandwidth in such a way that none
3687 of the Data Channels overlap with each other or with the Control Space.
3688 The NEXT_DEFINE_CHANNEL Message may be transmitted by the active Manager at any time,
3689 implying that it influences the state of a Port in the Unconfigured and the Configured states. See Figure 80.
3690 A Port based on versions of the SLIMbus specification prior to version 1.01.01 may ignore
3691 NEXT_DEFINE_CHANNEL Messages that specify an unsupported Transport Protocol. However, such
3692 behavior can lead to problems with Ports in the Configured state, if the Transport Protocol changes. A Port
3693 based on SLIMbus Specifications version 1.01.01 and later should not transmit or receive in a Data
3694 Channel if a NEXT_DEFINE_CHANNEL Message specifies a Transport Protocol that the Port does not
3695 support.
3696 A Device should set its EX_ERROR Information Element if it supports such range checking. Refer to
3697 section 11.6 for more details on parameter range checking.
3698 10.13.1.2.2 Defining the Channel Content
3699 The active Manager should notify the Devices involved in a transport of the Segment format that shall be
3700 used by the data source or sinks. To do so, the active Manager should broadcast the
3701 NEXT_DEFINE_CONTENT Message, or the CHANGE_CONTENT Message. In addition, the

154
3702 CHANGE_CONTENT Message may be used by a Device to set or change the Content Definition of a
3703 Channel.
3704 The NEXT_DEFINE_CONTENT Message changes the Content Parameters at the associated
3705 Reconfiguration Boundary, just like any of the other Reconfiguration Messages. The
3706 CHANGE_CONTENT Message changes the Content Parameters at the first Superframe boundary after the
3707 Message. If the Port is active, or becomes active at that moment, the new Content Definition shall be used.
3708 If the Port remains inactive, the Content Definition shall be stored for future use.
3709 The NEXT_DEFINE_CONTENT and CHANGE_CONTENT Messages may be sent by the active
3710 Manager at any time, implying that it can influence the state of a Port in the Unconfigured and the
3711 Configured state (see Figure 80). If the Port is in the Configured state and is active, the Content Definition
3712 shall be used by the Port from the appropriate time. Depending on which Content Definition Message has
3713 been used the appropriate time is either the corresponding Reconfiguration Boundary or the upcoming
3714 Superframe boundary.
3715 10.13.1.2.3Activating the Channel
3716 The active Manager shall broadcast the NEXT_ACTIVATE_CHANNEL Message as part of a
3717 Reconfiguration Sequence to notify the Devices involved in a transport that the Data Channel shall be
3718 activated at the associated Reconfiguration Boundary.
3719 The active Manager shall ensure that Device Ports have the necessary information to operate properly. If,
3720 for any reason, one or more of the channel definition, content definition and channel activation Messages
3721 have not been received, the Port shall remain inoperable, and shall not transmit or receive any information
3722 in the Data Channel.
3723 Note that this does not imply that the NEXT_DEFINE_CHANNEL, NEXT_DEFINE_CONTENT or
3724 NEXT_ACTIVATE CHANNEL Messages need to be sent during the same Reconfiguration sequence.
3725 Typically, the active Manager sends these Messages during the same sequence, when it is constructing the
3726 Data Channel. Subsequent changes however, can be made by sending only one of the Messages.
3727 10.13.1.2.4 Full Configuration
3728 As soon as a Port has received the Channel Definition, the Content Definition, and either the
3729 NEXT_ACTIVATE_CHANNEL or the NEXT_DEACTIVATE_CHANNEL Message, it shall move to the
3730 Configured state at the appropriate time, which shall be the moment at which the last change takes effect.
3731 10.13.2 Disconnecting Ports
3732 The DISCONNECT_PORT Message instructs a Port that it shall no longer be involved with a particular
3733 Data Channel. Regardless of the Port state, it shall reset and return to the Disconnected state. This implies
3734 that the Port shall cease to transmit or receive data in the Data Channel. In addition, the Port shall discard
3735 any knowledge of the Data Channel Definition and Content and shall discard the Channel Number. These
3736 changes shall take effect at the first Superframe boundary that comes at least two Slots after the end of the
3737 DISCONNECT_PORT Message.
3738 In addition, a Port Reset causes the Port to move to the Disconnected state as described in section 10.4.4.
3739 10.13.3 Pausing a Data Channel
3740 To temporarily suspend Data Channel operation, the NEXT_DEACTIVATE_CHANNEL shall be

3741 broadcast by the active Manager. This Message may be used in both the Unconfigured and the Configured
3742 state. A Port shall not transmit or receive data in a deactivated Data Channel. A Port shall maintain its

155
3743 knowledge of the Data Channel and Content definition, so that a NEXT_ACTIVATE_CHANNEL will
3744 resume Data Channel operation.
3745 10.13.4 Cancelling a Data Channel
3746 To release the bandwidth allocated to a Data Channel, the active Manager shall broadcast a
3747 NEXT_REMOVE_CHANNEL with the relevant Channel Number during one of the reconfiguration
3748 sequences. At the associated Reconfiguration Boundary, all Ports involved in the transport shall be reset
3749 and return to the Disconnected state (Figure 80).
3750 10.13.5 Changing Content Definitions
3751 In some use cases, the source Device of the transport needs to inform the sink(s) of a change in the channel
3752 format. In this case, the source Device should send the CHANGE_CONTENT Message with the new
3753 content description in the payload. The announced content parameters shall be used by the source Device
3754 from the first Superframe boundary at least two Slots after the transmission of the CHANGE_CONTENT
3755 Message.
3756 10.13.6 Moving a Data Channel
3757 When a Data Channel has to be moved in the Data Space to free some bandwidth or to fit in the new
3758 available space left after a mode change, the active Manager shall broadcast the
3759 NEXT_DEFINE_CHANNEL Message to notify the Devices involved in the transport of the new channel
3760 parameters. The Segment length typically remains unchanged. The Segment Distribution field shall be
3761 computed accordingly to the expected move.
3762
3763 Figure 81 Move Channel Example
3764

156
3765 11 Core Messages

3766 Messages of the Core Message Type shall be interpreted in the same way by all Devices. They are intended
3767 for managing and operating the SLIMbus itself and are interpreted using Table 65.
3768 A Device does not need to support all Core Messages. In fact, a minimal subset is defined in each version
3769 of the definition of each Device Class. Refer to the relevant Device Class definition for details.
3770 Table 65 Core Message Codes

(MC[6:0])
Device Management Messages
0x01 REPORT_PRESENT (DC, DCV)
0x02 ASSIGN_LOGICAL_ADDRESS (LA)
0x04 RESET_DEVICE ()
0x08 CHANGE_LOGICAL_ADDRESS (LA)
0x09 CHANGE_ARBITRATION_PRIORITY (AP)
0x0C REQUEST_SELF_ANNOUNCEMENT ()
0x0F REPORT_ABSENT ()
Data Channel Management Messages
0x10 CONNECT_SOURCE (PN, CN)
0x11 CONNECT_SINK (PN, CN)
0x14 DISCONNECT_PORT (PN)
0x18 CHANGE_CONTENT (CN, FL, PR, AF, DT, CL, DL)
Information Management Messages
0x20 REQUEST_INFORMATION (TID, EC)
0x21 REQUEST_CLEAR_INFORMATION (TID, EC, CM)
0x24 REPLY_INFORMATION (TID, IS)
0x28 CLEAR_INFORMATION (EC, CM)
0x29 REPORT_INFORMATION (EC, IS)
Reconfiguration Messages
0x40 BEGIN_RECONFIGURATION ()
0x44 NEXT_ACTIVE_FRAMER (LAIF, NCo, NCi)
0x45 NEXT_SUBFRAME_MODE (SM)
0x46 NEXT_CLOCK_GEAR (CG)
0x47 NEXT_ROOT_FREQUENCY (RF)
0x4A NEXT_PAUSE_CLOCK (RT)
0x4B NEXT_RESET_BUS ()

157

(MC[6:0])
0x4C NEXT_SHUTDOWN_BUS ()
0x50 NEXT_DEFINE_CHANNEL (CN, TP, SD, SL)
0x51 NEXT_DEFINE_CONTENT (CN, FL, PR, AF, DT, CL, DL)
0x54 NEXT_ACTIVATE_CHANNEL (CN)
0x55 NEXT_DEACTIVATE_CHANNEL (CN)
0x58 NEXT_REMOVE_CHANNEL (CN)
0x5F RECONFIGURE_NOW ()
Value Management Messages
0x60 REQUEST_VALUE (TID, EC)
0x61 REQUEST_CHANGE_VALUE (TID, EC, VU)
0x64 REPLY_VALUE (TID, VS)
0x68 CHANGE_VALUE (EC, VU)
3771 All unassigned Core Message codes are reserved. A source Device shall not send a Message with a
3772 reserved Core Message Code. A destination Device that receives a Message with a reserved Core Message
3773 Code shall treat the Message as unsupported. Refer to section 10.2.5 for details on unsupported Messages.
3774 The following sections define the semantics of each of the Messages in Table 65, including the meaning of
3775 the payload and response fields where relevant. A dash (-) in a Cell indicates that the Cell is reserved.
3776 Sources shall send zeros in all reserved Cells. Destinations shall not use the contents of reserved Cells,
3777 except for Message integrity verification.
3778 11.1 Device Management Messages
3779 Device Management Messages are used for discovery and configuration of Devices on the bus.
3780 11.1.1 REPORT_PRESENT (DC, DCV)
3781 The REPORT_PRESENT Message is sent by an unenumerated Device to announce its presence on the bus.
3782 Message Format
3783 This Message uses a Long Arbitration field and a Short Header field.
3784 Payload
3785 Two bytes holding the Device Class code, DC[7:0], and the Device Class Version code, DCV[7:0], of the
3786 Device.
D7 D6 D5 D4 D3 D2 D1 D0
Byte 0 DC[7] DC[6] DC[5] DC[4] DC[3] DC[2] DC[1] DC[0]
Byte 1 DCV[7] DCV[6] DCV[5] DCV[4] DCV[3] DCV[2] DCV[1] DCV[0]

158
3787 Description
3788 This Message shall be sent only to the active Manager.
3789 This Message shall be sent by an unenumerated Device after it has gained Message synchronization as
3790 described in section 10.9.1.3.
3791 11.1.2 ASSIGN_LOGICAL_ADDRESS (LA)
3792 The ASSIGN_LOGICAL_ADDRESS Message assigns a Logical Address to a Device.
3793 Message Format
3794 This Message uses a Short Arbitration field and a Long Header field.
3795 Payload
3796 A single byte holding a Logical Address, LA[7:0].

D7 D6 D5 D4 D3 D2 D1 D0
Byte 0 LA[7] LA[6] LA[5] LA[4] LA[3] LA[2] LA[1] LA[0]
3797 Description
3798 This Message shall be sent only by the active Manager.
3799 This Message may be sent as part of the Device Discovery as specified in section 10.10.
3800 11.1.3 RESET_DEVICE ()
3801 The RESET_DEVICE Message informs a Device to perform its reset procedure.
3802 Message Format
3803 This Message uses a Short Arbitration field and a Short Header field.
3804 Payload
3805 None
3806 Description
3808 This Message informs a Device to perform its reset procedure. General rules for performing a reset are
3809 given in section 10.4. Specific rules for each Device Class are given in the relevant Device Class definition
3810 in section 12.
3811 11.1.4 CHANGE_LOGICAL_ADDRESS (LA)
3812 The CHANGE_LOGICAL_ADDRESS Message changes the value of the Logical Address of the
3813 destination Device.

159
3814 Message Format
3816 Payload
3817 A single byte holding the new Logical Address, LA[7:0].

D7 D6 D5 D4 D3 D2 D1 D0
Byte 0 LA[7] LA[6] LA[5] LA[4] LA[3] LA[2] LA[1] LA[0]
3818
3819 Description
3821 This Message may be used by the active Manager to change the Logical Address of a Device as specified in
3822 section 10.10.
3823 11.1.5 CHANGE_ARBITRATION_PRIORITY (AP)
3824 The CHANGE_ARBITRATION_PRIORITY Message is sent to one or more Devices to change the value
3825 of their Arbitration Priority.
3826 Message Format
3827 This Message uses a Short Arbitration field and a Short or Broadcast Header field.
3828 Payload
3829 A single byte holding the new Arbitration Priority, AP[2:0].

D7 D6 D5 D4 D3 D2 D1 D0
Byte 0 - - - - - AP[2] AP[1] AP[0]
3830 Description
3832 This Message may be sent by the active Manager to change the Arbitration Priority of a Device as specified
3834 11.1.6 REQUEST_SELF_ANNOUNCEMENT ()
3835 The REQUEST_SELF_ANNOUNCEMENT Message is sent by the active Manager to request an

3836 unenumerated Device retransmit a REPORT_PRESENT Message.
3837 Message Format
3838 This Message uses a Short Arbitration field and a Broadcast Header field.
3839 Payload
3840 None

160
3841 Description
3843 This Message may be sent by the active Manager as part of the Device Discovery as specified in section
3844 10.9.
3845 11.1.7 REPORT_ABSENT ()
3846 The REPORT_ABSENT Message shall be sent from a Device to announce that it is about to leave the bus.
3847 Message Format
3849 Payload
3850 None
3851 Description
3852 This Message shall be sent only to the active Manager.
3853 A Device shall send this Message when it intends to leave the bus as described in section 10.9.1.5.
3854 11.2 Data Channel Management Messages
3855 Data Channel Management Messages are used to communicate information to Devices about Channels in
3856 the Data Space.
3857 11.2.1 CONNECT_SOURCE (PN, CN)
3858 The CONNECT_SOURCE Message informs the Device to connect the specified Port, PN, to the specified
3859 Data Channel, CN. The Port shall act as the data source for the Data Channel.
3860 Message Format
3862 Payload
3863 Two bytes holding the Port Number, PN[5:0], and the Data Channel Number, CN[7:0].
D7 D6 D5 D4 D3 D2 D1 D0
Byte 0 - - PN[5] PN[4] PN[3] PN[2] PN[1] PN[0]
Byte 1 CN[7] CN[6] CN[5] CN[4] CN[3] CN[2] CN[1] CN[0]
3864 Description
3865 This Message informs a Device to connect its Port PN to channel CN. Refer to section 10.13.1.1 for further
3866 information.

161
3867 11.2.2 CONNECT_SINK (PN, CN)
3868 The CONNECT_SINK Message informs the Device to connect the specified Port, PN, to the specified Data
3869 Channel, CN. The Port shall act as a data sink for the Data Channel.
3870 Message Format
3872 Payload
3873 Two bytes holding the Port Number, PN[5:0], and the Data Channel Number, CN[7:0].
D7 D6 D5 D4 D3 D2 D1 D0
3874 Description
3875 This Message informs a Device to connect its Port PN to channel CN. Refer to section 10.13.1.1 for further
3876 information.
3877 11.2.3 DISCONNECT_PORT (PN)
3878 The DISCONNECT_PORT Message informs the Device to disconnect the specified Port, PN, from the
3879 specified Data Channel, CN.
3880 Message Format
3882 Payload
3883 A single byte holding the Port Number, PN[5:0].

D7 D6 D5 D4 D3 D2 D1 D0
3884 Description
3885 This Message informs a Device to disconnect its Port PN from channel CN. See section 10.13.4 for more
3886 information.
3887 11.2.4 CHANGE_CONTENT (CN, FL, PR, AF, DT, CL, DL)
3888 The CHANGE_CONTENT Message broadcasts detailed information about the structure of the Data
3889 Channel contents.
3890 Message Format

162
3892 Payload
3893 Four bytes holding a Data Channel Number, CN[7:0], for use as an identifier, followed by a list of
3894 parameters that define the Data Channel content:
3895 Frequency Locked bit, FL
3896 Presence Rate, PR[6:0]
3897 Auxiliary Bit Format AF[3:0]
3898 Data Type, DT[3:0]
3899 Channel Link bit, CL
3900 DATA Length, DL[4:0]
D7 D6 D5 D4 D3 D2 D1 D0
Byte 1 FL PR[6] PR[5] PR[4] PR[3] PR[2] PR[1] PR[0]
Byte 2 AF[3] AF[2] AF[1] AF[0] DT[3] DT[2] DT[1] DT[0]
Byte 3 - - CL DL[4] DL[3] DL[2] DL[1] DL[0]
3901 Description
3902 This Message informs a Device of the structure of the Data Channel content. Refer to section 10.13.5 for
3904 The FL bit indicates whether the content flow is known to be frequency locked to the SLIMbus CLK
3905 signal. See section 9.2.
3906 The PR field describes the Presence Rate. See section 9.6.
3907 Auxiliary bit formats and data types are defined in section 9.4.
3908 The CL bit, when 1, indicates that the content of channel CN is related to that of channel CN-1. When the
3909 CL bit is 0, the contents of channel CN is not necessarily related to the contents of channel CN-1.
3910 The DL field indicates the length of the DATA field, in Slots, as specified in section 9.7.
3911 11.3 Information Management Messages
3912 Information Management Messages are used to communicate and manage Information Elements. A Device
3913 may send information to another Device in reply to a REQUEST Message or autonomously in the form of a
3914 REPORT Message. In addition, a Device may be requested to selectively change Information Elements to
3915 their reset values.
3916 In all cases, Information Elements are addressed through an Information Slice, which may contain one or
3917 more Information Elements. See section 7.1 for more on Information Slices.
3918 11.3.1 REQUEST_INFORMATION (TID, EC)
3919 The REQUEST_INFORMATION Message instructs a Device to send the indicated Information Slice.

163
3920 Message Format
3922 Payload
3923 Three bytes holding an 8-bit Transaction ID, TID[7:0], followed by a 16-bit Element Code, EC[15:0],
3924 indicating the Information Slice.
D7 D6 D5 D4 D3 D2 D1 D0
Byte 0 TID[7] TID[6] TID[5] TID[4] TID[3] TID[2] TID[1] TID[0]
Byte 1 EC[7] EC[6] EC[5] EC[4] EC[3] EC[2] EC[1] EC[0]
3925 Description
3926 This Message instructs the destination Device to return the specified Information Slice. Refer to section
3927 10.12.1 for more information on REQUEST-REPLY transactions and to section 7.1 for the definition of
3928 Element Codes.
3929 11.3.2 REQUEST_CLEAR_INFORMATION (TID, EC, CM)
3930 The REQUEST_CLEAR_INFORMATION Message instructs a Device to send the indicated Information
3931 Slice and to clear all, or parts, of that Information Slice.
3932 Message Format
3934 Payload
3935 Three to nineteen bytes holding an 8-bit Transaction ID, TID[7:0]; a 16-bit Element Code, EC[15:0],
3936 indicating the Information Slice; followed by zero to sixteen bytes of Clear Mask, CM[].
D7 D6 D5 D4 D3 D2 D1 D0
Byte 3 CM[7] CM[6] CM[5] CM[4] CM[3] CM[2] CM[1] CM[0]
.
.
.
Byte N+2 CM[8N-1] CM[8N-2] CM[8N-3] CM[8N-4] CM[8N-5] CM[8N-6] CM[8N-7] CM[8N-8]
3937 Description
3938 This Message asks the destination Device to return the identified Information Slice, and to atomically
3939 change the value of the Information Slice according to the CM field. The CM field shall be placed in the
3940 LSBs of the relevant payload byte(s).

164
3941 A Device shall change to their reset values, those bits of the identified Information Slice for which the
3942 corresponding Clear Mask bit is 1.
3943 If the size of Clear Mask is smaller than the size of the Information Slice, the Device shall pad the MSBs of
3944 Clear Mask with ones. For example, if the size of Clear Mask is zero bytes, the Device shall change all bits
3945 of the Information Slice to their reset values. If the size of Clear Mask is larger than the size of the
3946 Information Slice, the Device shall change only the portion of the Information Map corresponding to the
3947 identified Information Slice.
3948 Refer to section 10.12 for more information on REQUEST-REPLY transactions and to section 7.1 for the
3949 definition of Element Codes.
3950 11.3.3 REPLY_INFORMATION (TID, IS)
3951 The REPLY_INFORMATION Message is sent by a Device in response to a REQUEST_INFORMATION

3952 or REQUEST_CLEAR_INFORMATION Message.
3953 Message Format
3955 Payload
3956 One to seventeen bytes holding an 8-bit Transaction ID, TID[7:0], optionally followed by the requested
3957 Information Slice, IS[] in one to sixteen bytes.
D7 D6 D5 D4 D3 D2 D1 D0
Byte 1 IS[7] IS[6] IS[5] IS[4] IS[3] IS[2] IS[1] IS[0]
.
.
.
Byte N IS[8N-1] IS[8N-2] IS[8N-3] IS[8N-4] IS[8N-5] IS[8N-6] IS[8N-7] IS[8N-8]
3958 Description
3959 The Destination Address field shall be the Logical Address of the Device that sent the
3960 REQUEST_INFORMATION or REQUEST_CLEAR_INFORMATION Message.
3961 The Transaction ID TID[7:0] shall be the Transaction ID of the corresponding

3962 REQUEST_INFORMATION or REQUEST_CLEAR_INFORMATION Message
3963 As specified in section 10.12.2, the payload may consist of only the Transaction ID. In all other cases the
3964 Payload shall contain the Information Slice that was identified in the corresponding REQUEST Message.
3965 The Information Slice shall be placed in the LSBs of the relevant payload byte(s). Any unused bits shall be
3966 filled with zeros. Refer to section 10.12 for more information on REQUEST-REPLY transactions and
3967 section 7.1for the definition of Element Codes.
3968 11.3.4 CLEAR_INFORMATION (EC, CM)
3969 The CLEAR_INFORMATION Message instructs a Device to selectively clear all, or parts, of the
3970 Information Slice.

165
3971 Message Format
3973 Payload
3974 Two to eighteen bytes holding a 16-bit Element Code, EC[15:0], indicating the Information Slice, followed
3975 by zero to sixteen bytes of Clear Mask, CM[].
D7 D6 D5 D4 D3 D2 D1 D0
Byte 2 CM[7] CM[6] CM[5] CM[4] CM[3] CM[2] CM[1] CM[0]
.
.
.
Byte N+1 CM[8N-1] CM[8N-2] CM[8N-3] CM[8N-4] CM[8N-5] CM[8N-6] CM[8N-7] CM[8N-8]
3976 Description
3977 The CM field shall be placed in the LSBs of the relevant payload byte(s).
3978 A Device shall change to their reset values, those bits of the identified Information Slice for which the
3979 corresponding Clear Mask bit is 1.
3980 If the size of Clear Mask is smaller than the size of the Information Slice, the Device shall pad the MSBs of
3981 Clear Mask with ones. For example, if the size of Clear Mask is zero bytes, the Device shall change all bits
3982 of the Information Slice to their reset values. If the size of Clear Mask is larger than the size of the
3983 Information Slice, the Device shall change only the portion of the Information Map corresponding to the
3984 identified Information Slice.
3985 Refer to section 7.1 for the definition of Element Codes.
3986 11.3.5 REPORT_INFORMATION (EC, IS)
3987 The REPORT_INFORMATION Message is used by a Device to inform another Device about a change in
3988 an Information Slice.
3989 Message Format
3991 Payload
3992 Three to eighteen bytes holding a 16-bit Element Code, EC[15:0], followed by one to sixteen bytes of the
3993 corresponding Information Slice, IS[].

166
D7 D6 D5 D4 D3 D2 D1 D0
Byte 2 IS[7] IS[6] IS[5] IS[4] IS[3] IS[2] IS[1] IS[0]
.
.
.
Byte N+1 IS[8N-1] IS[8N-2] IS[8N-3] IS[8N-4] IS[8N-5] IS[8N-6] IS[8N-7] IS[8N-8]
3994 Description
3995 This Message is normally, though not exclusively, used to indicate a change in an internal Information
3996 Slice. The Information Slice shall be placed in the LSBs of the relevant payload byte(s). Any unused bits
3997 shall be filled with zeros. Refer to sections 7.1.3, 12.2.6, 12.3.6 and 12.4.6 for more information on
3998 reporting Information Elements.
3999 11.4 Reconfiguration Messages
4000 Reconfiguration Messages are used for tasks whose effect must be synchronized between all Devices.
4001 11.4.1 BEGIN_RECONFIGURATION ()
4002 The BEGIN_RECONFIGURATION Message informs all Devices of the start of a Reconfiguration
4003 Sequence.
4004 Message Format
4006 Payload
4007 None
4008 Description
4010 This Message is sent by the active Manager to indicate the start, or restart, of a Reconfiguration Sequence.
4011 See section 10.3.1.
4012 11.4.2 NEXT_ACTIVE_FRAMER (LAIF, NCo, NCi)
4013 The NEXT_ACTIVE_FRAMER Message informs a Device that the active Framer is going to hand over
4014 the role of Framer to a specified inactive Framer with the Logical Address LAIF. See section 10.8.
4015 Message Format
4017 Payload

167
4018 Four bytes holding an 8-bit Logical Address of the Incoming Framer, LAIF[7:0], followed by two packed
4019 bytes holding the Number of Outgoing Framer Clock cycles, NCo[11:0], and the Number of Incoming
4020 Framer Clock cycles, NCi[11:0].
D7 D6 D5 D4 D3 D2 D1 D0
Byte 0 LAIF[7] LAIF[6] LAIF[5] LAIF[4] LAIF[3] LAIF[2] LAIF[1] LAIF[0]
Byte 1 NCo[7] NCo[6] NCo[5] NCo[4] NCo[3] NCo[2] NCo[1] NCo[0]
Byte 2 NCi[3] NCi[2] NCi[1] NCi[0] NCo[11] NCo[10] NCo[9] NCo[8]
Byte 3 NCi[11] NCi[10] NCi[9] NCi[8] NCi[7] NCi[6] NCi[5] NCi[4]
4021 Description
4022 This Message shall only be sent by the active Manager.
4023 This Message informs a destination Device that the specified inactive Framer shall become the active
4024 Framer and the source Device shall become an inactive Framer at the associated Reconfiguration
4025 Boundary. See section 10.8 for more information.
4026 The Message parameters NCo and NCi are the number of internal clock cycles that the active and inactive
4027 Framers, respectively, shall hold the CLK line HIGH.
4028 11.4.3 NEXT_SUBFRAME_MODE (SM)
4029 The NEXT_SUBFRAME_MODE Message informs a Device that the active Manager intends to change the
4030 Subframe Mode.
4031 Message Format
4033 Payload
4034 A single byte holding the new Subframe Mode, SM[4:0].

D7 D6 D5 D4 D3 D2 D1 D0
Byte 0 - - - SM[4] SM[3] SM[2] SM[1] SM[0]
4035 Description
4037 This Message informs a Device that the active Manager intends to change the Subframe Mode to the value
4038 in the Payload field at the associated Reconfiguration Boundary. The Subframe Mode shall be encoded
4039 using the values in Table 15. Reserved values shall not be used.
4040 11.4.4 NEXT_CLOCK_GEAR (CG)
4041 Message from the active Manager to inform all destinations that it intends to change the Clock Gear.
4042 Message Format

168
4044 Payload
4045 A single byte holding the new Clock Gear, CG[3:0].

D7 D6 D5 D4 D3 D2 D1 D0
Byte 0 - - - - CG[3] CG[2] CG[1] CG[0]
4046 Description
4048 This Message informs a Device that the active Manager intends to change the Clock Gear to the value in
4049 the Payload field at the associated Reconfiguration Boundary. The Clock Gear shall be encoded using the
4050 values in Table 16. Reserved values shall not be used. See section 10.6 for more information.
4051 11.4.5 NEXT_ROOT_FREQUENCY (RF)
4052 The NEXT_ROOT_FREQUENCY Message informs a Device that the active Manager intends to change
4053 the Root Frequency.
4054 Message Format
4056 Payload
4057 A single byte holding the new Root Frequency, RF[3:0]

D7 D6 D5 D4 D3 D2 D1 D0
Byte 0 - - - - RF[3] RF[2] RF[1] RF[0]
4058 Description
4060 This Message informs a Device that the active Manager intends to change the Root Frequency to the value
4061 in the Payload field at the associated Reconfiguration Boundary. The Root Frequency shall be encoded
4062 using the values in Table 17. Reserved values shall not be used. See section 10.7 for more information.
4063 This Message also affects the behavior of Components that use the Phasing Signal. See section 6.3.1.8.
4064 11.4.6 NEXT_PAUSE_CLOCK (RT)
4065 The NEXT_PAUSE_CLOCK Message informs a Device that the active Manager intends to have the active
4066 Framer pause the bus.
4067 Message Format
4069 Payload
4070 A single byte holding the new Restart Time, RT[7:0].

169
D7 D6 D5 D4 D3 D2 D1 D0
Byte 0 RT[7] RT[6] RT[5] RT[4] RT[3] RT[2] RT[1] RT[0]
4071 Description
4073 This Message informs a Device that the active Manager intends to have the active Framer pause the bus at
4074 the associated Superframe boundary. The Restart Time held in the Payload field shall be encoded using the
4075 values in Table 66. Reserved values shall not be used.
4076 See section 10.3.2 for details of SLIMbus Clock Pause.

4077 Table 66 NEXT_PAUSE_CLOCK Payload Value
RT[7:0] Description Requirement

0x00 Fast Recovery. After a restart request, the active Framer shall resume toggling Optional
the CLK line within four cycles of the CLK line frequency (as indicated by
the Clock Gear and Root Frequency) used for the upcoming Frame.
0x01 Constant Phase Recovery. After the restart request, the active Framer shall Optional
resume toggling the CLK line so the duration of the Pause is an integer
number of Superframes in the upcoming Clock Gear.
0x02 Unspecified Delay. After a restart request, the active Framer shall resume Mandatory
toggling the CLK line after an unspecified delay.
No requirement exists for the time the active Framer takes to restart the clock
signal. This allows for system designers to stop all clock generation circuitry
to save power. The Framer documentation shall indicate the restart delay
period.
0x03 to Reserved. N/A
0xFF
4078 11.4.7 NEXT_RESET_BUS ()
4079 The NEXT_RESET_BUS Message informs a Device that the active Manager intends to have the active
4080 Framer reset the bus.
4081 Message Format
4083 Payload
4084 None
4085 Description
4087 This Message informs a Device that the active Manager intends to have the active Framer reset the bus at
4088 the associated Reconfiguration Boundary as described in section 10.4.1.

170
4089 11.4.8 NEXT_SHUTDOWN_BUS ()
4090 The NEXT_SHUTDOWN_BUS Message informs a Device that the active Manager intends to shutdown
4091 the bus.
4092 Message Format
4094 Payload
4095 None
4096 Description
4098 This Message informs a Device that the active Manager intends to shutdown the bus at the associated
4099 Reconfiguration Boundary. See section 10.3.3.
4100 11.4.9 NEXT_DEFINE_CHANNEL (CN, TP, SD, SL)
4101 The NEXT_DEFINE_CHANNEL Message informs a Device that the active Manager intends to define the
4102 parameters of a Data Channel.
4103 Message Format
4105 Payload
4107 parameters that define the properties of the Data Channel:
4108 Transport Protocol, TP[3:0]
4109 Segment Distribution, SD[11:0]
4110 Segment Length, in Slots, SL[4:0]
D7 D6 D5 D4 D3 D2 D1 D0
Byte 1 SD[7] SD[6] SD[5] SD[4] SD[3] SD[2] SD[1] SD[0]
Byte 2 TP[3] TP[2] TP[1] TP[0] SD[11] SD[10] SD[9] SD[8]
Byte 3 0 0 0 SL[4] SL[3] SL[2] SL[1] SL[0]
4111 Description
4113 This Message informs a Device of the structure of a Data Channel. If the Data Channel, CN, is already
4114 defined, its attributes shall be modified according to the parameters in the Payload field. If the Data
4115 Channel is not defined, it shall be created.

171
4116 Note that this Message does not affect whether a Data Channel is activated or not. Refer to section 10.13
4117 for details on Data Channel management.
4118 This Message takes effect at the associated Reconfiguration Boundary. See section 10.3.1 for more
4119 information.
4120 11.4.10 NEXT_DEFINE_CONTENT (CN, FL, PR, AF, DT, CL, DL)
4121 The NEXT_DEFINE_CONTENT Message informs a Device how the Data Channel CN shall be used.
4122 Message Format
4124 Payload
4126 parameters that define the Data Channel content:
4127 Frequency Locked bit, FL
4128 Presence Rate, PR[6:0]
4129 Auxiliary Bit Format, AF[3:0]
4130 Data Type, DT[3:0]
4131 Channel Link bit, CL
4132 DATA Length, DL[4:0]
D7 D6 D5 D4 D3 D2 D1 D0
Byte 1 FL PR[6] PR[5] PR[4] PR[3] PR[2] PR[1] PR[0]
Byte 2 AF[3] AF[2] AF[1] AF[0] DT[3] DT[2] DT[1] DT[0]
Byte 3 0 0 CL DL[4] DL[3] DL[2] DL[1] DL[0]
4133 Description
4135 This Message informs a Device of the structure of the Data Channel content. The new Data Channel
4136 content shall take effect at the associated Reconfiguration Boundary following the Message reception.
4137 Refer to 10.13.5 for more information.
4138 The FL bit indicates whether the content flow is known to be frequency locked to the SLIMbus CLK
4139 signal. See section 9.2.
4140 The PR field describes the Presence Rate. See section 9.6.
4141 Auxiliary bit formats and data types are defined in section 9.4.
4142 The CL bit, when 1, indicates that the content of channel CN is related to that of channel CN-1. When the
4143 CL bit is 0, the contents of channel CN is not necessarily related to the contents of channel CN-1.
4144 The DL field indicates the length of the DATA field in Slots as specified in section 9.7.

172
4145 11.4.11 NEXT_ACTIVATE_CHANNEL (CN)
4146 The NEXT_ACTIVATE_CHANNEL Message is used to switch on the specified Data Channel.
4147 Message Format
4149 Payload
4150 A single byte holding the Channel Number, CN[7:0], of the Data Channel that is being activated.
D7 D6 D5 D4 D3 D2 D1 D0
4151 Description
4153 This Message is sent by the active Manager as part of the process of initializing a data transport as specified
4154 in section 10.13.1.
4155 11.4.12 NEXT_DEACTIVATE_CHANNEL (CN)
4156 The NEXT_DEACTIVATE_CHANNEL Message is used to switch off a specified Data Channel.
4157 Message Format
4159 Payload
4160 A single byte holding the Channel Number, CN[7:0], of the Data Channel that is being deactivated.
D7 D6 D5 D4 D3 D2 D1 D0
4161 Description
4163 This Message is sent by the active Manager as part of the process of suspending a data transport as
4164 specified in section 10.13.3.
4165 11.4.13 NEXT_REMOVE_CHANNEL (CN)
4166 The NEXT_REMOVE_CHANNEL Message is used to switch off and disconnect the specified Data
4167 Channel.
4168 Message Format

173
4170 Payload
4171 A single byte holding the Channel Number, CN[7:0], of the Data Channel that is being removed from the
4172 bus.
D7 D6 D5 D4 D3 D2 D1 D0
4173 Description
4175 This Message informs a Device the active Manager intends to remove an existing Data Channel from the
4176 bus. A Device shall disconnect and reset any Ports connected to the specified Data Channel at the
4177 associated Reconfiguration Boundary.
4178 This Message is sent by the active Manager as part of cancelling a Data Channel as specified in section
4179 10.13.6.
4180 11.4.14 RECONFIGURE_NOW ()
4181 The RECONFIGURE_NOW Message is used to change the bus configuration.
4182 Message Format
4184 Payload
4185 None
4186 Description
4188 This Message informs a Device the active Manager intends to change the bus configuration at the
4189 associated Reconfiguration Boundary. See section 10.3.1.
4190 11.5 Value Management Messages
4191 Value Management Messages are used to communicate and update Value Elements. A Device may send
4192 information to another Device in reply to a REQUEST Message. In addition, a Device may be requested to
4193 update Value Elements.
4194 In all cases, Value Elements are addressed through a Value Slice, which may contain one or more Value
4195 Elements. See section 7.2 for more information on Value Slices.
4196 11.5.1 REQUEST_VALUE (TID, EC)
4197 The REQUEST_VALUE Message instructs a Device to send the indicated Value Slice.
4198 Message Format

174
4200 Payload
4201 Three bytes holding an 8-bit Transaction ID, TID[7:0], followed by a 16-bit Element Code, EC[15:0],
4202 indicating the Value Slice.
D7 D6 D5 D4 D3 D2 D1 D0
4203 Description
4204 This Message instructs the destination Device to return the specified Value Slice. Refer to section 10.12.1
4205 for more information and to section 7.1 for the definition of the Element Codes.
4206 11.5.2 REQUEST_CHANGE_VALUE (TID, EC, VU)
4207 The REQUEST_CHANGE_VALUE Message instructs a Device to send the specified Value Slice and to
4208 update that Value Slice.
4209 Message Format
4211 Payload
4212 Three to nineteen bytes holding an 8-bit Transaction ID TID[7:0]; a 16-bit Element Code, EC[15:0],
4213 indicating the Value Slice; followed by zero to sixteen bytes of Value Update, VU[].
D7 D6 D5 D4 D3 D2 D1 D0
Byte 3 VU[7] VU[6] VU[5] VU[4] VU[3] VU[2] VU[1] VU[0]
.
.
.
Byte N+2 VU[8N-1] VU[8N-2] VU[8N-3] VU[8N-4] VU[8N-5] VU[8N-6] VU[8N-7] VU[8N-8]
4214 Description
4215 This Message asks the destination Device to return the identified Value Slice, and to atomically change the
4216 value of that Value Slice according to the VU field. The VU field shall be placed in the LSBs of the
4217 relevant payload byte(s).
4218 A Device shall overwrite the identified Value Slice with Value Update. If the size of Value Update is
4219 smaller than the size of the Value Slice, the Device shall pad the MSBs of Value Update with zeroes. For
4220 example, if the size of Value Update is zero bytes, the Device shall change all bits of the Value Slice to
4221 zeroes. If the size of Value Update is larger than the size of the Value Slice, the Device shall change only
4222 the portion of the Value Map corresponding to the identified Value Slice.

175
4223 Refer to section 10.12 for more information on REQUEST-REPLY transactions and to section 7.1 for the
4224 definition of Element Codes.
4225 11.5.3 REPLY_VALUE (TID, VS)
4226 The REPLY_VALUE Message is sent by a Device in response to a REQUEST_VALUE or

4227 REQUEST_CHANGE_VALUE Message.
4228 Message Format
4230 Payload
4231 One to seventeen bytes holding an 8-bit Transaction ID, optionally followed by the requested Value Slice,
4232 VS[] in one to sixteen bytes.
D7 D6 D5 D4 D3 D2 D1 D0
Byte 1 VS[7] VS[6] VS[5] VS[4] VS[3] VS[2] VS[1] VS[0]
.
.
.
Byte n VS[8N-1] VS[8N-2] VS[8N-3] VS[8N-4] VS[8N-5] VS[8N-6] VS[8N-7] VS[8N-8]
4233 Description
4234 The Destination Address field shall be the Logical Address of the Device that sent the REQUEST_VALUE
4235 or REQUEST_CHANGE_VALUE Message.
4236 The Transaction ID TID[7:0] shall be the Transaction ID of the corresponding REQUEST_VALUE or
4237 REQUEST_CHANGE_VALUE Message
4238 As specified in section 10.12.2, the payload may consist of only the Transaction ID. In all other cases the
4239 payload shall contain the Value Slice that was identified in the corresponding REQUEST Message. The
4240 Value Slice shall be placed in the LSBs of the relevant payload byte(s). Any unused bits shall be filled with
4241 zeros. Refer to sections 10.12 and 7.2 for more information.
4242 11.5.4 CHANGE_VALUE (EC, VU)
4243 The CHANGE_VALUE Message instructs a Device to update the indicated Value Slice.
4244 Message Format
4246 Payload
4247 Two to eighteen bytes holding a 16-bit Element Code, EC[15:0], followed by zero to sixteen bytes of Value
4248 Update, VU[].

176
D7 D6 D5 D4 D3 D2 D1 D0
Byte 2 VU[7] VU[6] VU[5] VU[4] VU[3] VU[2] VU[1] VU[0]
.
.
.
Byte N+1 VU[8N-1] VU[8N-2] VU[8N-3] VU[8N-4] VU[8N-5] VU[8N-6] VU[8N-7] VU[8N-8]
4249 Description
4250 The VU field shall be placed in the LSBs of the relevant payload byte(s).
4251 A Device shall overwrite the identified Value Slice with Value Update. If the size of Value Update is
4252 smaller than the size of the Value Slice, the Device shall pad the MSBs of Value Update with zeroes. For
4253 example, if the size of Value Update is zero bytes, the Device shall change all bits of the Value Slice to
4254 zeroes. If the size of Value Update is larger than the size of the Value Slice, the Device shall change only
4255 the portion of the Value Map corresponding to the identified Value Slice.
4256 Refer to section 7.1 for the definition of Element Codes.
4257 11.6 Core Message Range Checking
4258 This section provides guidelines on range checking for a received Core Message.
4259 If the EX_ERROR Core Information Element is implemented, it shall be set when:
4260 the received Core Message is supported by the Device, and
4261 the indicated check procedure is implemented, and
4262 the received Core Message fails the check.
4263 11.6.1 Core Message Sequence Checks
4264 Received an ASSIGN_LOGICAL_ADDRESS Message when a Logical Address has already been assigned
4265 Received any NEXT Message before receiving a BEGIN_RECONFIGURATION Message
4266 Received a RECONFIGURE_NOW Message before receiving a BEGIN_RECONFIGURATION Message
4267 A RECONFIGURE_NOW Message is transmitted between the RECONFIGURE_NOW and the

4268 Reconfiguration Boundary
4269 A BEGIN_RECONFIGURATION Message is transmitted between the RECONFIGURE_NOW and the

4270 Reconfiguration Boundary
4271 11.6.2 Core Message Parameter Checks
4272 Received an ASSIGN_LOGICAL_ADDRESS Message with a Logical Address prohibited in Table 42
4273 Received a CHANGE_LOGICAL_ADDRESS Message with a Logical Address prohibited in Table 42

177
4274 Received a CHANGE_ARBITRATION_PRIORITY Message with an Arbitration Priority prohibited in

4275 Table 30
4276 Received a CONNECT_SOURCE Message with a Port number that does not exist on the Device
4277 Received a CONNECT_SOURCE Message with the number of a local Port that is configured as input-only
4278 Received a CONNECT_SINK Message with a Port number that does not exist on the Device
4279 Received a CONNECT_SINK Message with the number of a local Port that is configured as output-only
4280 Received a DISCONNECT_PORT Message with a Port number that does not exist on the Device
4281 Received a CHANGE_CONTENT Message with a parameter value that a local Port connected to the
4282 channel does not support
4283 Received a CHANGE_CONTENT Message with the Channel Number equal to 0 if the Channel Link bit is
4284 set
4285 Received a REQUEST_CLEAR_INFORMATION Message with the elemental access code of an

4286 Information Element that is read-only
4287 Received a CLEAR_INFORMATION Message with the elemental access code of an Information Element
4288 that is read-only
4289 Received a NEXT_ACTIVE_FRAMER Message as the specified next active Framer if the Device is not a
4290 member of the Framer Device Class
4291 Received a NEXT_DEFINE_CHANNEL Message with a parameter value that a local Port connected to the
4293 Received a NEXT_DEFINE_CONTENT Message with a parameter value that a local Port connected to the
4295 Received a NEXT_DEFINE_CONTENT Message with the Channel Number equal to 0 if the Channel Link
4296 bit is set
4297 Received a REQUEST_CHANGE_VALUE Message with the elemental access code of a Value Element
4298 that is read-only
4299 Received a CHANGE_VALUE Message with the elemental access code of a Value Element that is
4300 read-only
4301 Received a Core Message with the Remaining Length Header field indicating a Message Payload shorter
4302 than specified in section 11 for the Message
4303

178
4304 12 Device Classes

4305 A Device Class is a category of Devices that share certain characteristics and functions. A Device Class
4306 definition is a collection of requirements on the behavior and supported features of a member of that
4307 Device Class. By fulfilling these requirements, a high level of interoperability between Devices can be
4308 achieved.
4309 A Device Class definition shall specify the following items:

4310 The Device Class code.
4311 The version of the Device Class definition.
4312 Transport support requirements. These requirements include the minimum number of Ports and
4313 required attributes, e.g. directionality, Transport Protocols, etc.
4314 Message support requirements. These requirements include the Core Messages (also see section
4315 12.1), the definition of Class-specific Messages and requirements for supporting the Class-specific
4316 Messages.
4317 Information Element support requirements. These requirements include Core Information
4318 Elements (also see section 12.1), the definition of the Class-specific Information Elements and the
4319 requirements for supporting the Class-specific Information Elements.
4320 Value Element support requirements. These requirements include Core Value Elements, the
4321 definition of Class-specific Value Elements and requirements for supporting the Class-specific
4322 Value Elements.
4323 Operation requirements. These requirements include all behavior that is important to the operation
4324 of a Device that belongs to that Device Class.
4325 12.1 Device Class-independent Requirements
4326 This section describes a set of requirements that apply to a Device regardless of its particular Device Class.
4327 A Device shall belong to only one Device Class and shall implement only one version of the corresponding
4328 Device Class.
4329 The Device Class shall be represented by an 8-bit code. Only a Device Class code assigned by the MIPI
4330 Alliance shall be used by a Device.
4331 The Device Class Version (DCV) shall be represented by an 8-bit code. The first version of a Device Class
4332 definition shall specify DCV equal to 0x01. Later versions of the Device Class shall have a number one
4333 greater than the previously defined version, up to a maximum value of 255 (0xFF).
4334 A Device shall be capable of sending the following Core Messages:

4335 REPLY_INFORMATION
4336 REPORT_PRESENT
4337 A Device shall be capable of receiving the following Core Messages and shall perform the action specified
4338 for the Message:
4339 ASSIGN_LOGICAL_ADDRESS
4340 CHANGE_LOGICAL_ADDRESS

179
4341 CLEAR_INFORMATION
4342 REQUEST_CLEAR_INFORMATION
4343 REQUEST_INFORMATION
4344 REQUEST_SELF_ANNOUNCEMENT
4345 RESET_DEVICE
4346 This does not constitute a requirement for a Device to support all forms of the CLEAR_INFORMATION,
4347 REQUEST_CLEAR_INFORMATION and REQUEST_INFORMATION Messages.
4348 A Device that supports at least one Transport Protocol shall also be capable of sending the following Core
4349 Messages:
4350 <none>
4351 A Device that supports at least one Transport Protocol shall also be capable of receiving the following Core
4352 Messages and shall perform the action specified for the Message:
4353 BEGIN_RECONFIGURATION
4354 CHANGE_CONTENT
4355 CONNECT_SINK (Sink Devices Only)
4356 CONNECT_SOURCE (Source Devices Only)
4357 DISCONNECT_PORT
4358 NEXT_ACTIVATE_CHANNEL
4359 NEXT_DEACTIVATE_CHANNEL
4360 NEXT_DEFINE_CHANNEL
4361 NEXT_DEFINE_CONTENT
4362 NEXT_REMOVE_CHANNEL
4363 RECONFIGURE_NOW
4364 In the following rules, the statement shall be able to generate means that the Device shall be able to
4365 create and transmit the Message when it is required for one of the sequences as described in the Message
4366 and the sequence description.
4367 In the following rules, the statement shall be able to receive and interpret means that the Device shall
4368 comply with the description of the Message and the description of sequences associated with this Message
4369 as described in the relevant sections, and shall perform any action mandated by the reception of the
4370 Message. If no action is required from the Device, it may ignore the Message but shall behave as if the
4371 Message has been successfully supported and processed.
4372 A Device shall obey the following rules for Core Messages:
4373 All mandatory Core Messages shall be implemented
4374 Any optional Core Message may be implemented
4375 Core Messages that are neither mandatory nor optional shall not be implemented
4376 Core Messages that are neither mandatory nor optional shall be not be acted upon when received

180
4377 In addition, a Device shall obey the following rules for Class-specific Messages listed for its own Device
4378 Class:
4379 The Device shall be able to transmit every Source-referred Class-specific Message that is
4380 mandatory as Source for its Device Class Version
4381 The Device may transmit any Source-referred Class-specific Message that is optional as Source
4382 for its Device Class Version
4383 The Device shall not transmit any other Source-referred Class-specific Message
4384 The Device shall be able to receive and interpret every Destination-referred Class-specific
4385 Message that is mandatory as Destination for its Device Class Version
4386 The Device may receive and interpret any Destination-referred Class-specific Message that is
4387 optional as Destination for its Device Class Version
4388 The Device shall treat all other received unicast Destination-referred Class-specific Messages as
4389 unsupported
4390 In addition, a Device shall obey the following rules for Class-specific Messages listed for all Device
4391 Classes other than its own:
4392 The Device may transmit any Destination-referred Class-specific Message
4393 The Device may receive and interpret any Source-referred Class-specific Message
4394 In addition, a Device shall obey the following rules for User Messages:
4395 The Device may transmit any Source-referred User Message
4396 The Device may receive and interpret any Destination-referred User Message
4397 The Device may transmit any Destination-referred User Message
4398 The Device may receive and interpret any Source-referred User Message
4399 A Device shall support the following Core Information Elements:

4400 DATA_TX_COL
4401 DEVICE_CLASS
4402 DEVICE_CLASS_VERSION
4403 UNSPRTD_MSG
4404 12.2 Interface Device Class
4405 This section is the Device Class definition for SLIMbus Interface Devices.
4406 A SLIMbus Interface Device shall have Device Class code 0xFD. A SLIMbus Interface Device that
4407 implements this version of the Device Class definition shall have Device Class Version code 0x01.
4408 12.2.1 Port and Transport Protocol Support
4409 There are no Port or Transport Protocol requirements defined for the Interface Device Class.

181
4410 12.2.2 Interface Device Core Message Support
4411 A Device of the Interface Device Class (Interface Device) shall be able to send all Core Messages in the
4412 Mandatory column, and may also send any Core Message in the Optional column, of the As Source
4413 section of Table 67.
4414 An Interface Device shall be able to receive all Core Messages in the Mandatory column, and may also
4415 receive any Core Message in the Optional column, of the As Destination section of Table 67.
4416 Table 67 Interface Device Core Message Support
As Source
Mandatory Optional
REPLY_INFORMATION CHANGE_CONTENT
REPORT_INFORMATION CHANGE_VALUE
REPORT_PRESENT CLEAR_INFORMATION
REPLY_VALUE
REPORT_ABSENT (2)
REQUEST_CHANGE_VALUE
REQUEST_CLEAR_INFORMATION
REQUEST_INFORMATION
REQUEST_VALUE
As Destination
Mandatory Optional
ASSIGN_LOGICAL_ADDRESS CHANGE_ARBITRATION_PRIORITY
BEGIN_RECONFIGURATION CHANGE_CONTENT (1)
CHANGE_LOGICAL_ADDRESS CHANGE_VALUE
CLEAR_INFORMATION CONNECT_SINK (1)
NEXT_SUBFRAME_MODE CONNECT_SOURCE (1)
RECONFIGURE_NOW DISCONNECT_PORT (1)
REQUEST_ CLEAR_INFORMATION NEXT_ACTIVATE_CHANNEL (1)
REQUEST_ INFORMATION NEXT_ACTIVE_FRAMER
REQUEST_SELF_ANNOUNCEMENT NEXT_CLOCK_GEAR (3)
RESET_DEVICE NEXT_DEACTIVATE_CHANNEL (1)
NEXT_DEFINE_CHANNEL (1)
NEXT_DEFINE_ CONTENT (1)
NEXT_PAUSE_CLOCK
NEXT_REMOVE_CHANNEL (1)
NEXT_RESET_BUS
NEXT_ROOT_FREQUENCY (4)
NEXT_SHUTDOWN_BUS

182
REPLY_INFORMATION
REPLY_VALUE
REPORT_INFORMATION
REQUEST_VALUE
4417 Notes
4418 1. Support for these Messages is required if the Device supports a Transport Protocol (see section 12.1).
4419 2. The REPORT_ABSENT Message has special meaning when sent by an Interface Device. As described in
4420 section 10.9.1.5, it means that the entire Component is going to cease participation in SLIMbus activity.
4421 3. Support for NEXT_CLOCK_GEAR is required if any part of the Component uses the Clock Gear
4422 information (see sections 10.2.4 and 10.1.2.4).
4423 4. Support for NEXT_ROOT_FREQUENCY is required if any part of the Component uses the Root Frequency
4424 information (see sections 10.2.4 and 10.1.2.4).
4425 Messages shown in italics are mandatory for all Devices.
4426 12.2.3 Interface Device Core Information Element Support
4427 An Interface Device shall support all Core Information Elements in the Mandatory column, and may also
4428 support any Core Information Element in the Optional column, of Table 68.
4429 Table 68 Interface Device Core Information Element Support
Mandatory Optional
DATA_TX_COL EX_ERROR
DEVICE_CLASS RECONFIG_OBJECTION
DEVICE_CLASS_VERSION
UNSPRTD_MSG
4430 Notes
4431 Information Elements shown in italics are mandatory for all Devices.
4432 An Interface Device shall support byte-based requests and clears of its Core Information Elements using 1,
4433 2 and 4-byte Slice Sizes. The Device may also support other byte-based and elemental accesses. See
4434 section 7.1 for descriptions of byte-based and elemental access methods.
4435 12.2.4 Interface Device Class-specific Messages
4436 No Class-specific Messages are defined for the Interface Device Class.
4437 12.2.5 Interface Device Class-specific Information Elements
4438 This section defines the Interface Device Class-specific Information Elements, and specifies the associated
4439 support requirements. Each Information Element shall have the attributes identified for it in Table 69.

183
4440 An Interface Device shall support all Information Elements that are shown as "Mandatory", and may also
4441 support any Information Element that is shown as "Optional", in Table 69.
4442 Table 69 Interface Device Class-specific Information Elements
Name Description Type Size Byte Support

(bits) Address,
Bit
Number
of Lowest
Bit
DATA_SLOT_OVERLAP Internal Port contention Clearable 1 0x400, 4 Mandatory
LOST_MS Lost Message Clearable 1 0x400, 3 Mandatory
synchronization
LOST_SFS Lost Superframe Clearable 1 0x400, 2 Mandatory
synchronization
LOST_FS Lost Frame Clearable 1 0x400, 1 Mandatory
synchronization
MC_TX_COL Message Channel Clearable 1 0x400, 0 Mandatory
Collision detected
4443 An Interface Device shall support byte-based requests and clears of its Class-specific Information Elements
4444 using 1, 2 and 4-byte Slice Sizes. The Device may also support other byte-based and elemental accesses.
4445 See section 7.1 for descriptions of byte-based and elemental access methods.
4448 the Interface Device being reset by a Device Reset, a Component Reset or a Bus Reset (section
4449 10.4)
4452 12.2.5.1 DATA_SLOT_OVERLAP
4453 DATA_SLOT_OVERLAP is a clearable Boolean Information Element. It indicates that there has been
4454 internal contention between Ports. An Interface Device of a Component shall set
4455 DATA_SLOT_OVERLAP whenever it suppresses the output of a Port within the Component due to
4456 Segment overlap with the Control Space or with the output of another Port.
4457 When the Control Space is configured to overlap with a Segment, the Component in which this conflict
4458 occurs gives the Control Space priority over the Data Channel as stated in section 6.4.2. Consequently, a
4459 Component never overwrites the Control Space with a Segment, even though the overlap is the result of
4460 explicit programming.
4461 12.2.5.2 LOST_MS
4462 LOST_MS is a clearable Boolean Information Element. It indicates that the Component has lost Message
4463 synchronization. An Interface Device shall set LOST_MS whenever it observes any of the following:
4464 Failed Guide Byte Parity Check (section 8.3.3)
4465 Mismatch of the Guide Byte (section 8.3.2)

184
4466 Illegal Arbitration Type (section 8.2.1.1)

4467 Illegal Message Type (section 8.2.2.1)
4468 Failure of the Primary Integrity CRC (section 8.2.4.1)
4469 Undefined Message Response code (section 8.2.4)
4470 Collision in the Message Channel (section 10.2.3)
4471 12.2.5.3 LOST_SFS
4472 LOST_SFS is a clearable Boolean Information Element. It indicates that the Component has lost
4473 Superframe synchronization. An Interface Device shall set LOST_SFS whenever the Component moves to
4474 the SeekingSuperframeSync state from a state other than the SeekingFrameSync state (Figure 57).
4475 12.2.5.4 LOST_FS
4476 LOST_FS is a clearable Boolean Information Element. It indicates that the Component has lost Frame
4477 synchronization. The Interface Device of a Component shall set LOST_FS whenever the Component
4478 moves to the SeekingFrameSync state from a state other than the Reset state (Figure 57).
4479 12.2.5.5 MC_TX_COL
4480 MC_TX_COL is a clearable Boolean Information Element. It indicates that a Collision has been detected in
4481 the Message Channel. The Interface Device of a Component shall set MC_TX_COL whenever it detects a
4482 DATA line Collision (section 5.1.1) while a Device within the Component is writing to the Message
4483 Channel.
4484 An Interface Device based on SLIMbus specifications prior to version 1.01.01 may suppress the setting of
4485 MC_TX_COL while the Component is using Logical-OR signaling. However, an Interface Device based
4486 on SLIMbus Specification version 1.01.01 and later should not suppress the setting of MC_TX_COL while
4487 the Component is using Logical-OR signaling.
4488 12.2.6 Reporting Class-specific Information
4489 This section provides guidelines for reporting the value of Interface Device Class-specific Information
4490 Elements to another Device.
4491 MC_TX_COL
4492 Detection of a Collision in the Message Channel is most likely to be as a result of a glitch on the DATA
4493 line. However, a Component that has not yet detected it has lost Message synchronization can cause such a
4494 Collision by sending data from at least one of its Devices. The Interface Device shall send a
4495 REPORT_INFORMATION Message, including byte 0x400 of the Information Map, to the active Manager
4496 once it has completed the back-off process described in section 10.2.3.
4497 LOST_FS
4498 Loss of Frame synchronization can be caused by a number of conditions during normal bus operation. If an
4499 Interface Device detects that its Component has lost Frame synchronization, it shall send a
4501 once it has regained Message synchronization.
4502 LOST_SFS

185
4503 Loss of Superframe synchronization can be caused by a number of conditions during normal bus operation.
4504 If an Interface Device detects that its Component has lost Superframe synchronization, it shall send a
4507 LOST_MS
4508 Loss of Message synchronization can be caused by a number of conditions during normal bus operation. If
4509 an Interface Device detects that its Component has lost Message synchronization, it shall send a
4512 DATA_SLOT_OVERLAP
4513 A Data Space Slot Overlap is most likely the result of a procedural error when assigning Segment
4514 Distributions, and does not occur during normal bus operation. If an Interface Device detects a Data Space
4515 Slot overlap, it shall send a REPORT_INFORMATION Message, including byte 0x400 of the Information
4516 Map, to the active Manager at the earliest opportunity.
4517 12.2.7 Interface Device Class-specific Value Elements
4518 No Class-specific Value Elements are defined for the Interface Device Class.
4519 12.2.8 Boot Requirements
4520 There are no requirements for an Interface Device during the boot process.
4521 12.2.9 Bus Reset Requirements
4522 No action is required by an Interface Device when it receives a NEXT_RESET_BUS Message. Note that if,
4523 and when, a SLIMbus Reset takes effect, the Device shall reset as a result of the process described in
4524 section 10.4.
4525 12.2.10 Device Reset Requirements
4526 When an Interface Device receives a RESET_DEVICE Message, it shall perform the following actions in
4527 addition to those specified for all Devices in section 10.4.3:
4528 The Interface Device shall cause all Devices within the same Component to perform a reset as
4529 described in section 10.4.2.
4530 12.2.11 Component Reset Requirements
4531 When an Interface Device receives a Component Reset by the mechanisms described in section 10.4.2, it
4532 shall perform the actions specified in that section. No additional Component Reset requirements are
4533 mandated for an Interface Device.
4534 12.2.12 Additional Requirements
4535 An Interface Device monitors the Frame Layer within its Component. It also monitors the Message
4536 Protocol within its Component. Consequently, an Interface Device is responsible for tracking and reporting
4537 the following status information:
4538 Collisions in the Message Channel
4539 Loss and recovery of Superframe synchronization

186
4540 Loss and recovery of Frame synchronization

4541 Loss and recovery of Message synchronization
4542 Internal arbitration errors
4543 Note that, in contrast to the listed Collisions that are tracked only by an Interface Device, all Devices are
4544 responsible for tracking Collisions in any Data Channel for which they are the data source.
4545 12.3 Manager Device Class
4546 This section is the Device Class definition for SLIMbus Managers.
4547 A SLIMbus Manager shall have Device Class code 0xFF. A SLIMbus Manager that implements this
4548 version of the Device Class definition shall have Device Class Version code 0x01.
4549 A Manager may be in one of two roles: active or inactive. As described in section 4.3.1.1, there is only one
4550 active Manager on the bus, and this Device has unique requirements placed upon it. The support
4551 requirements for Messages and Information Elements can vary depending on the role, as can some aspects
4552 of operation.
4554 There are no Port or Transport Protocol requirements defined for the Manager Device Class.
4555 12.3.2 Manager Core Message Support
4556 A Manager shall be able to send all Core Messages in the Mandatory column, and may also send any
4557 Core Message in the Optional column, of the As Source section of Table 70.
4558 A Manager shall be able to receive all Core Messages in the Mandatory column, and may also receive
4559 any Core Message in the Optional column, of the As Destination section of Table 70.
4560 Table 70 Manager Core Message Support
As Source
Mandatory Optional
ASSIGN_LOGICAL_ADDRESS (2) CHANGE_ARBITRATION_PRIORITY (2)
BEGIN_RECONFIGURATION (2) CHANGE_CONTENT
CHANGE_LOGICAL_ADDRESS (2) CHANGE_VALUE
CLEAR_INFORMATION NEXT_PAUSE_CLOCK (2)
CONNECT_SINK (2) NEXT_SHUTDOWN_BUS (2)
CONNECT_SOURCE (2) REPLY_VALUE
DISCONNECT_PORT (2) REPORT_ABSENT
NEXT_ACTIVATE_CHANNEL (2) REPORT_INFORMATION
NEXT_ACTIVE_FRAMER (2) REQUEST_CHANGE_VALUE
NEXT_CLOCK_GEAR (2) REQUEST_SELF_ANNOUNCEMENT (2)
NEXT_DEACTIVATE_CHANNEL REQUEST_VALUE

187
NEXT_DEFINE_CONTENT (2)
NEXT_RESET_BUS (2)
NEXT_ROOT_FREQUENCY (2)
NEXT_SUBFRAME_MODE (2)
RECONFIGURE_NOW (2)
REPLY_INFORMATION
REPORT_PRESENT
REQUEST_INFORMATION
RESET_DEVICE (2)
As Destination
Mandatory Optional
ASSIGN_LOGICAL_ADDRESS BEGIN_RECONFIGURATION (1)
CHANGE_LOGICAL_ADDRESS CHANGE_ARBITRATION_PRIORITY
CLEAR_INFORMATION CHANGE_CONTENT (1)
REPLY_INFORMATION CHANGE_VALUE
REPORT_INFORMATION CONNECT_SINK (1)
REPORT_PRESENT (2) CONNECT_SOURCE (1)
REQUEST_CLEAR_INFORMATION DISCONNECT_PORT (1)
REQUEST_INFORMATION NEXT_ACTIVATE_CHANNEL (1)
REQUEST_SELF_ANNOUNCEMENT NEXT_ACTIVE_FRAMER
RESET_DEVICE NEXT_CLOCK_GEAR
NEXT_DEACTIVATE_CHANNEL (1)
NEXT_PAUSE_CLOCK
NEXT_RESET_BUS
NEXT_ROOT_FREQUENCY
NEXT_SHUTDOWN_BUS
NEXT_SUBFRAME_MODE
RECONFIGURE_NOW (1)
REPLY_VALUE
REPORT_ABSENT (2)

188
REQUEST_VALUE
4561 Notes
4563 2. These Messages shall be supported only when the Device is the active Manager.
4565 12.3.3 Manager Core Information Element Support
4566 A Manager shall support all Core Information Elements in the Mandatory column, and may also support
4567 any Core Information Element in the Optional column, of Table 71.
4568 Table 71 Manager Core Information Element Support
Mandatory Optional
UNSPRTD_MSG
4569 Notes
4571 A Manager shall support byte-based requests and clears of its Core Information Elements using 1, 2 and 4-
4572 byte Slice Sizes. The Device may also support other byte-based and elemental accesses. See section 7.1 for
4573 descriptions of byte-based and elemental access methods.
4574 12.3.4 Manager Class-specific Messages
4575 No Class-specific Messages are defined for the Manager Device Class.
4576 12.3.5 Manager Class-specific Information Elements
4577 This section defines the Manager Class-specific Information Elements, and specifies the associated support
4578 requirements. Each Information Element shall have the attributes identified for it in Table 72.
4579 A Manager shall support all Information Elements that are shown as "Mandatory", and may also support
4580 any Information Element that is shown as "Optional", in Table 72.
4581 Table 72 Manager Class-specific Information Elements

(bits) Address,
Bit
Number
of Lowest
Bit
ACTIVE_MANAGER The Device is the active Read 1 0x400, 0 Mandatory
Manager only

189
4582 A Manager shall support byte-based requests and clears of its Class-specific Information Elements using 1,
4583 2 and 4-byte Slice Sizes. The Device may also support other byte-based and elemental accesses. See
4584 section 7.1 for descriptions of byte-based and elemental access methods.
4587 the Manager being reset by a Device Reset, a Component Reset or a Bus Reset (section 10.4)
4590 12.3.5.1 ACTIVE_MANAGER
4591 ACTIVE_MANAGER is a read-only Boolean Information Element. It shall have the value TRUE if the
4592 Device is the active Manager and FALSE if the Device is not the active Manager (section 4.3.1.2).
4594 This section provides guidelines for reporting the value of Manager Class-specific Information Elements to
4595 another Device.
4596 ACTIVE_MANAGER
4598 during normal bus operation except when sent as part of byte 0x400 of the Information Map.
4599 12.3.7 Manager Class-specific Value Elements
4600 No Class-specific Value Elements are defined for the Manager Device Class.
4602 There are no requirements for a Manager during the boot process.
4604 No action is required by a Manager when it receives a NEXT_RESET_BUS Message.
4606 When a Manager receives a RESET_DEVICE Message, the only actions required are those specified for all
4607 Devices in section 10.4.3.
4609 When a Manager receives a Component Reset by the mechanisms described in section 10.4.2, it shall
4610 perform the actions specified in that section. No additional Component Reset requirements are mandated
4611 for a Manager.
4613 The active Manager has many requirements that are unique in that it is responsible for the establishment,
4614 maintenance, and shutdown of the entire SLIMbus system.

190
4615 12.4 Framer Device Class
4616 This section is the Device Class definition for SLIMbus Framers.
4617 A SLIMbus Framer shall have Device Class code 0xFE. A SLIMbus Framer that implements this version
4618 of the Device Class definition shall have Device Class Version code 0x01.
4619 A Framer may be in one of two roles: active or inactive. As described in section 4.3.1.3, there is only one
4620 active Framer on the bus at a given time, and this Device has unique requirements placed upon it. The
4621 support requirements for Messages and Information Elements can vary depending on the role, as can some
4622 aspects of operation.
4624 There are no Port or Transport Protocol requirements defined for the Framer Device Class.
4625 12.4.2 Framer Core Message Support
4626 A Framer shall be able to send all Core Messages in the Mandatory column, and may also send any Core
4627 Message in the Optional column, of the As Source section of Table 73.
4628 A Framer shall be able to receive all Core Messages in the Mandatory column, and may also receive any
4629 Core Message in the Optional column, of the As Destination section of Table 73.
4630 Note that the requirements for Core Message support are the same whether a Device is the active Framer or
4631 an inactive Framer. However, the actions taken by the Device when certain Messages are received may be
4632 different depending on whether the Device is the active Framer or an inactive Framer.
4633 Table 73 Framer Core Message Support
As Source
Mandatory Optional
REPORT_PRESENT CHANGE_VALUE
CLEAR_INFORMATION
REPLY_VALUE
REPORT_ABSENT
REPORT_INFORMATION
REQUEST_INFORMATION
REQUEST_VALUE
As Destination
Mandatory Optional
ASSIGN_LOGICAL_ADDRESS CHANGE_ARBITRATION_PRIORITY
BEGIN_RECONFIGURATION CHANGE_CONTENT (1)
CHANGE_LOGICAL_ADDRESS CHANGE_VALUE

191
CLEAR_INFORMATION CONNECT_SINK (1)

NEXT_ACTIVE_FRAMER CONNECT_SOURCE (1)
NEXT_CLOCK_GEAR DISCONNECT_PORT (1)
NEXT_PAUSE_CLOCK NEXT_ACTIVATE_CHANNEL (1)
NEXT_RESET_BUS NEXT_DEACTIVATE_CHANNEL (1)
NEXT_ROOT_FREQUENCY NEXT_DEFINE_CHANNEL (1)
NEXT_SHUTDOWN_BUS NEXT_DEFINE_CONTENT (1)
NEXT_SUBFRAME_MODE NEXT_REMOVE_CHANNEL (1)
RECONFIGURE_NOW REPLY_INFORMATION
REQUEST_CLEAR_INFORMATION REPLY_VALUE
REQUEST_INFORMATION REPORT_INFORMATION
REQUEST_SELF_ANNOUNCEMENT REQUEST_CHANGE_VALUE
RESET_DEVICE REQUEST_VALUE
4634 Notes
4636 Messages in italics are mandatory for all Devices.
4637 12.4.3 Framer Core Information Element Support
4638 A Framer shall support all Core Information Elements in the Mandatory column, and may also support
4639 any Core Information Element in the Optional column, of Table 74.
4640 Table 74 Framer Core Information Element Support
Mandatory Optional
UNSPRTD_MSG
4641 Notes
4643 A Framer shall support byte-based requests and clears of its Core Information Elements using 1, 2 and 4-
4644 byte Slice Sizes. The Device may also support other byte-based and elemental accesses. See section 7.1 for
4645 descriptions of byte-based and elemental access methods.
4646 12.4.4 Framer Class-specific Messages
4647 No Class-specific Messages are defined for the Framer Device Class.

192
4648 12.4.5 Framer Class-specific Information Elements
4649 This section defines the Framer Class-specific Information Elements, and specifies the associated support
4650 requirements. Each Information Element shall have the attributes identified for it in Table 75.
4651 A Framer shall support all Information Elements that are shown as "Mandatory", and may also support any
4652 Information Element that is shown as "Optional", in Table 75.
4653 Table 75 Framer Class-specific Information Elements

(bits) Address,
Bit
Number
of Lowest
Bit
QUALITY Quality of the generated Read 2 0x400, 6 Optional
clock only
GC_TX_COL Guide Channel Collision Clearable 1 0x400, 3 Mandatory
detected
FI_TX_COL Framing Information Clearable 1 0x400, 2 Mandatory
Collision detected
FS_TX_COL Frame Sync Symbol Clearable 1 0x400, 1 Mandatory
Collision detected
ACTIVE_FRAMER The Device is the active Read 1 0x400, 0 Mandatory
Framer only
4654 A Framer shall support byte-based requests and clears of its Class-specific Information Elements using 1, 2
4655 and 4-byte Slice Sizes. The Device may also support other byte-based and elemental accesses. See section
4656 7.1 for descriptions of byte-based and elemental access methods.
4659 the Framer being reset by a Device Reset, a Component Reset or a Bus Reset (section 10.4)
4662 12.4.5.1 QUALITY
4663 QUALITY is a read-only, enumerated Information Element and is coded using 2-bits. It is used to report
4664 the quality of the CLK signal that is generated by the Framer. The Framer shall code this Information
4665 Element with one of the values listed in Table 76.
4666 Table 76 QUALITY Information Element
Field Description
0b00 Potentially irregular punctured clock unsuitable for use as a timing reference for generic phase-
locked loops.
0b01 Irregular clock that has a lower-frequency regular clock embedded. For example, such clocks can
be created by cyclic pulse swallowing.

193
Field Description
0b10 Regular clock that potentially has more than 1 ns RMS of wideband jitter (100Hz measurement
corner, see [AES01]).
0b11 Low-jitter clock that is known to have less than 1 ns RMS of wideband jitter (100Hz measurement
corner, see [AES01]).
4667 The QUALITY Information Element may be changed by mechanisms outside the scope of this document.
4668 12.4.5.2 GC_TX_COL
4669 GC_TX_COL is a clearable Boolean Information Element. It indicates a Collision has been detected in the
4670 Guide Channel. The Framer shall set GC_TX_COL whenever it detects a DATA line Collision (section
4671 5.1.1) while it is writing the Guide Byte.
4672 12.4.5.3 FI_TX_COL
4673 FI_TX_COL is a clearable Boolean Information Element. It indicates a Collision has been detected in a
4674 Framing Information Slot. The Framer shall set FI_TX_COL whenever it detects a DATA line Collision
4675 (section 5.1.1) while it is writing the Framing Information.
4676 12.4.5.4 FS_TX_COL
4677 FS_TX_COL is a clearable Boolean Information Element. It indicates a Collision has been detected in a
4678 Frame Sync Slot. The Framer shall set FS_TX_COL whenever it detects a DATA line Collision (section
4679 5.1.1) while it is writing the Frame Sync symbol.
4680 12.4.5.5 ACTIVE_FRAMER
4681 ACTIVE_FRAMER is a read-only Boolean Information Element. It shall have the value TRUE if the
4682 Device is the active Framer and FALSE if the Device is not the active Framer (sections 4.3.1.3 and 10.8).
4684 This section provides guidelines for reporting the value of Framer Class-specific Information Elements to
4685 another Device.
4686 QUALITY
4687 A change in the quality of the CLK signal may occur at any time as part of the normal operation of the bus.
4688 The active Framer should send a REPORT_INFORMATION Message that includes byte 0x400 of the
4689 Information Map to the active Manager, if this Information Element changes to a lower quality value. The
4690 active Framer may also send a REPORT_INFORMATION Message that includes byte 0x400 of the
4691 Information Map to the active Manager, if this Information Element changes to a higher quality value.
4692 GC_TX_COL
4693 If the active Framer detects a Collision in the Guide Channel, it is either the result of a single glitch on the
4694 DATA line or of at least one Device writing in the wrong Slot. The active Framer may attempt to send a
4696 Manager once the Guide Channel is free of Collisions.
4697 FI_TX_COL

194
4698 If the active Framer detects a Collision in the Framing Information, it is either the result of a single glitch
4699 on the DATA line or of at least one Device writing in the wrong Slot. The active Framer may attempt to
4700 send a REPORT_INFORMATION Message that includes byte 0x400 of the Information Map to the active
4701 Manager once the Framing Channel is free of Collisions.
4702 FS_TX_COL
4703 If the active Framer detects a Collision in the Frame Sync symbol, it is either the result of a single glitch on
4704 the DATA line or of at least one Device writing in the wrong Slot. The active Framer should attempt to
4705 send a REPORT_INFORMATION Message that includes byte 0x400 of the Information Map to the active
4706 Manager once the Framing Channel is free of Collisions.
4707 ACTIVE_FRAMER
4708 The ACTIVE_FRAMER Information Element is changed only by the process of Framer handover. Since
4709 Framer handover is initiated by the active Manager, this Information Element should not be reported by the
4710 REPORT_INFORMATION Message in normal bus operation except when sent as part of byte 0x400 of
4711 the Information Map.
4712 12.4.7 Framer Class-specific Value Elements
4713 No Class-specific Value Elements are defined for the Framer Device Class.
4715 If a Framer is part of the Clock Sourcing Component used to boot the bus, it shall provide an initial value
4716 for the Subframe Mode, Clock Gear, and Root Frequency for the Component. These values shall be used
4717 by the Component until changed by the active Manager as described in sections 10.5, 10.6, and 10.7.
4719 When the active Framer receives a NEXT_RESET_BUS Message, it shall prepare to perform a Bus Reset
4720 as described in section 10.4.
4721 No action is required by an inactive Framer when it receives a NEXT_RESET_BUS Message.
4723 When the active Framer receives a RESET_DEVICE Message, it shall perform the following actions in
4724 addition to those specified for all Devices in section 10.4.3:
4725 The active Framer shall continue clocking the bus and continue writing the Framing Channel and
4726 Guide Channel.
4727 When an inactive Framer receives a RESET_DEVICE Message, the only actions required are those
4728 specified for all Devices in section 10.4.3.
4730 When a Framer receives a Component Reset by the mechanisms described in section 10.4.2, it shall
4731 perform the actions specified in that section. No additional Component Reset requirements are mandated
4732 for Devices of the Framer Device Class.

195
4734 The active Framer is responsible for tracking and reporting certain items to do with the Components
4735 physical interface:
4736 Collisions with the Frame Sync symbol
4737 Collisions in the Framing Information
4738 Collisions in the Guide Channel field
4739 Note that, in contrast to the listed Collisions that are tracked only by the active Framer, all Devices are
4740 responsible for tracking Collisions in any Data Channels for which they are the data source.
4741 The active Framer also has other requirements that are unique in that it is responsible for toggling the CLK
4742 line, sending the Frame Sync symbol, sending the Framing Information and sending the Guide Byte.
4743 A Framer shall be capable of assuming and relinquishing the role of active Framer using the process
4744 described in section 10.8.
4745 12.5 Generic Device Class
4746 This section presents requirements that apply to those members of the Generic Device Class that implement
4747 SLIMbus.
4748 A Member of the Generic Device Class shall have Device Class code 0x00. In the absence of a separate
4749 Generic Device Class definition, a member of the Generic Device Class shall have Device Class Version
4750 code 0x01.
4752 There are no Port or Transport Protocol requirements defined for the Generic Device Class.
4753 12.5.2 Generic Device Core Message Support
4754 A Device of the Generic Device Class (Generic Device) shall be able to send all Core Messages in the
4755 Mandatory column, and may also send any Core Message in the Optional column, of the As Source
4756 section of Table 77.
4757 A Generic Device shall be able to receive all Core Messages in the Mandatory column, and may also
4758 receive any Core Message in the Optional column, of the As Destination section of Table 77.
4759 Table 77 Generic Device Core Message Support
As Source
Mandatory Optional
REPORT_PRESENT CHANGE_VALUE
CLEAR_INFORMATION
REPLY_VALUE
REPORT_ABSENT
REPORT_INFORMATION

196
REQUEST_INFORMATION
REQUEST_VALUE
As Destination
Mandatory Optional
ASSIGN_LOGICAL_ADDRESS BEGIN_RECONFIGURATION (1)
CHANGE_LOGICAL_ADDRESS CHANGE_ARBITRATION_PRIORITY
CLEAR_INFORMATION CHANGE_CONTENT (1)
REQUEST_CLEAR_INFORMATION CHANGE_VALUE
REQUEST_INFORMATION CONNECT_SINK (1)
REQUEST_SELF_ANNOUNCEMENT CONNECT_SOURCE (1)
RESET_DEVICE DISCONNECT_PORT (1)
NEXT_ACTIVATE_CHANNEL (1)
NEXT_ACTIVE_FRAMER
NEXT_CLOCK_GEAR
NEXT_DEACTIVATE_CHANNEL (1)
NEXT_PAUSE_CLOCK
NEXT_ROOT_FREQUENCY
NEXT_RESET_BUS
NEXT_SHUTDOWN_BUS
NEXT_SUBFRAME_MODE
RECONFIGURE_NOW (1)
REPLY_INFORMATION
REPLY_VALUE
REPORT_INFORMATION
REQUEST_VALUE
4760 Notes

197
4763 12.5.3 Generic Device Core Information Element Support
4764 A Generic Device shall support all Core Information Elements in the Mandatory column, and may also
4765 support any Core Information Element in the Optional column, of Table 78.
4766 Table 78 Generic Device Core Information Element Support
Mandatory Optional
UNSPRTD_MSG
4767 Notes
4769 A Generic Device shall support byte-based requests and clears of its Core Information Elements using 1, 2
4770 and 4-byte Slice Sizes. The Device may also support other byte-based and elemental accesses. See section
4771 7.1 for descriptions of byte-based and elemental access methods.
4772 12.5.4 Generic Device Class-specific Messages
4773 No Class-specific Messages are defined for the Generic Device Class.
4774 12.5.5 Generic Device Class-specific Information Elements
4775 No Class-specific Information Elements are defined for the Generic Device Class.
4777 No guidelines for reporting the value of Generic Device Class-specific Information Elements are provided.
4778 12.5.7 Generic Device Class-specific Value Elements
4779 No Class-specific Value Elements are defined for the Generic Device Class.
4781 There are no requirements for a Generic Device during the boot process.
4783 No action is required by a Generic Device when it receives a NEXT_RESET_BUS Message.
4785 When a Generic Device receives a RESET_DEVICE Message, the only actions required are those specified
4786 for all Devices in section 10.4.3.

198
4788 When a Generic Device receives a Component Reset by the mechanisms described in section 10.4.2, it
4789 shall perform the actions specified in that section. No additional Component Reset requirements are
4790 mandated for a Generic Device.
4792 No additional requirements are defined for the Generic Device Class.
4793
4794

199
4795 Annex A Usage Examples (informative)

4796 SLIMbusSM enables many different ways to partition audio functionality in a system. Therefore, the use
4797 cases in this section can be seen as inspiration for basic SLIMbus system configurations. Assumptions are
4798 made to present as realistic as possible scenarios without getting into implementation-specific details.
4799 A.1 Assumed Pre-conditions

4800 Setup and configuration of SLIMbus is not included in the use case examples.
4801 Combined Application and baseband processor (for simplicity only)
4802 Manager and Framer included in the combined application/baseband processor
4803 Microphone can support only 8kHz sample rate source
4804 Ports in Devices assumed to be statically assigned and unidirectional
4805 Music has a 44.1 kHz sample rate and voice call audio has an 8 kHz sample rate
4806 A.2 Use Cases
4807 The use cases in this section are all based on a low complexity audio system with five physical
4808 Components on SLIMbus. The Components are: application processor, microphone, Bluetooth modem,
4809 stereo amplifier with loudspeakers, and voice call speaker.
4810 A.2.1 Use Case 1 Voice Call, Handset
4811 Use Case 1 is the ordinary voice call use case. Downlink audio is routed from the baseband Component to
4812 the voice call speaker. Also, uplink audio is routed from the microphone to the application processor.
4813 The voice call audio is transferred using the Isochronous Transport Protocol.
4814
4815 Figure 82 Use Case 1
4816 The bus could be configured according to Table 79 and Table 80.

200
4817 Table 79 Use Case 1 and 2 Configuration
Description Value Units

Root Frequency 24.576 MHz
Clock Gear 4
Actual Bus Clock 0.384 MHz
Subframe Rate 4 kHz
Frame Rate 0.5 kHz
Superframe Rate 62.5 Hz
Subframe Length 24 Slots
Control Space Width 4 Slots
Control Space Bandwidth 64 kbps
Data Channel Rate Voice 8 kHz
Segment Length Voice 4 Slots
Data Channel Bandwidth Voice 128 kbps
4818 Table 80 Use Case 1 and 2 Slot Layout
0 1 2 3 4 5 6 7 8 9 10 11
12 13 14 15 16 17 18 19 20 21 22 23
24 25 26 27 28 29 30 31 32 33 34 35
36 37 38 39 40 41 42 43 44 45 46 47
48 49 50 51 52 53 54 55 56 57 58 59
60 61 62 63 64 65 66 67 68 69 70 71
72 73 74 75 76 77 78 79 80 81 82 83
84 85 86 87 88 89 90 91 92 93 94 95
96 97 98 99 100 101 102 103 104 105 106 107
108 109 110 111 112 113 114 115 116 117 118 119
120 121 122 123 124 125 126 127 128 129 130 131
132 133 134 135 136 137 138 139 140 141 142 143
144 145 146 147 148 149 150 151 152 153 154 155
156 157 158 159 160 161 162 163 164 165 166 167
168 169 170 171 172 173 174 175 176 177 178 179
180 181 182 183 184 185 186 187 188 189 190 191
4819 The font color in Table 80 is intended to be connected to the colors of the lines in the routing picture. The
4820 two orange Slots in the Control Space hold the Guide Channel (only in the first Frame of every
4821 Superframe).

201
4822 A.2.2 Use Case 2 Voice Call, Handheld Hands Free
4823 Use Case 2 utilizes the same Slot layout as the example in section A.2.1. In this example, the stereo
4824 amplifier is used as the sink for the downlink voice call audio.
4825
4826 Figure 83 Use Case 2, Hands Free
4827 A.2.3 Use Case 3 Voice Call, Bluetooth Headset
4828 In Use Case 3, the voice call audio is routed to and from the Bluetooth modem and the application
4829 processor. To handle control and data communication between the application processor and the Bluetooth
4830 modem, a full-duplex Asynchronous link is set up between those Devices.
4831 Voice call data is transferred using the Isochronous Transport Protocol while the Bluetooth data is
4832 transferred using the Simplex Asynchronous Transport Protocol.
4833
4834 Figure 84 Use Case 3, Bluetooth
4835 The bus could be configured according to Table 81 and Table 82.

202
4836 Table 81 Use Case 3 Configuration

Clock Gear 4
Subframe Rate 4 kHz
Frame Rate 0.5 kHz
Superframe Rate 62.5 Hz
Segment Length Bluetooth data 4 Slots
Data Channel Rate Bluetooth data 2 kHz
Data Channel Bandwidth Bluetooth data 32 kbps
4837 Table 82 Use Case 3 Slot Layout
0 1 2 3 4 5 6 7 8 9 10 11
12 13 14 15 16 17 18 19 20 21 22 23
24 25 26 27 28 29 30 31 32 33 34 35
36 37 38 39 40 41 42 43 44 45 46 47
48 49 50 51 52 53 54 55 56 57 58 59
60 61 62 63 64 65 66 67 68 69 70 71
72 73 74 75 76 77 78 79 80 81 82 83
84 85 86 87 88 89 90 91 92 93 94 95
96 97 98 99 100 101 102 103 104 105 106 107
108 109 110 111 112 113 114 115 116 117 118 119
120 121 122 123 124 125 126 127 128 129 130 131
132 133 134 135 136 137 138 139 140 141 142 143
144 145 146 147 148 149 150 151 152 153 154 155
156 157 158 159 160 161 162 163 164 165 166 167
168 169 170 171 172 173 174 175 176 177 178 179
180 181 182 183 184 185 186 187 188 189 190 191

203
4840 Superframe).
4841 A.2.4 Use Case 4 Music Playback, Built-in Stereo Speakers
4842 In Use Case 4, music data is transferred from the application processor to the stereo amplifier.
4843 Music is transferred using the Pushed Transport Protocol with four Slots of audio data and one TAG field
4844 Slot. This configuration enables a 44.1 kHz sample rate flow to be distributed in a 48 kHz sample rate
4845 channel.
4846
4847 Figure 85 Use Case 4, Built-in Speakers
4848 The bus could be set up according to Table 83 and Table 84.

Clock Gear 7
Subframe Rate 24 kHz
Frame Rate 4 kHz
Superframe Rate 0.5 kHz
Segment Length Music 5 Slots
Data Channel Rate Music 48 kHz
Data Channel Bandwidth Music 960 kbps

204
4850 Table 84 Use Case 4 Slot Layout
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95
96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111
112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127
128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143
144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159
160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175
176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191
4853 Superframe).
4854 A.2.5 Use Case 5 Ring Signal and Voice Answer
4855 In Use Case 5, a ring signal is generated by the application processor and is routed to the stereo amplifier.
4856 In addition, the phone is configured to respond to voice control commands.
4857 Music is transferred using the Pushed Transport Protocol with four Slots of audio data and one TAG field
4858 Slot. This configuration enables a 44.1 kHz sample rate flow to be distributed in a 48 kHz sample rate
4859 channel.
4860 The voice call audio is transferred using the Isochronous Transport Protocol.
4861
4862 Figure 86 Use Case 5, Ring Signal

205
4863 The bus could be set up according to Table 85 and Table 86.
Description Value Unit

Clock Gear 7
Actual bus clock 3.072 MHz
Subframe Rate 24 kHz
Frame Rate 4 kHz
Superframe Rate 0.5 kHz
Segment Length Music 5 Slots
Data Channel Rate Music 48 kHz
Data Channel Bandwidth Music 960 kbps
4865 Table 86 Use Case 5 -- Slot Layout
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95
96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111
112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127
128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143
144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159
160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175
176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191
4868 Superframe).
4869

206
4870 Annex B Physical Layer Implementation Notes

4871 (informative)
4872 B.1 Why Does SLIMbusSM Require a Dedicated Physical Layer?
4873 SLIMbus is a multi-drop bus that allows multiple slow speed devices within a mobile handset to
4874 communicate in a way that minimizes system cost. It does this primarily by eliminating a number of legacy
4875 point-to-point serial interfaces and associated electrical traces. A conceptual SLIMbus system topology is
4876 shown below:
4877
4878 Figure 87 System Topology of an Example Handset Implementing SLIMbus
4879 Here we clearly see how a reduction in the number of low speed point-to-point interfaces simplifies the
4880 design of the handset. This diagram also serves to highlight the complexities introduced at the physical
4881 layer by a move from multiple point-to-point buses to one larger multi-drop bus, for example line length,
4882 increased loading and possibly flexible wiring with varying line impendence to cope with hinges and
4883 sliders.
4884 SLIMbus is designed to be capable of existing cost-effectively on multiple types of Device, from
4885 loudspeakers, microphones and HID systems to low voltage baseband controllers and wireless modems.
4886 The aforementioned systems exert conflicting constraints on the physical layer of the interface and the
4887 resulting specification has been optimized for saving cost and power at the system level, sometimes at the
4888 expense of additional complexity, and perhaps cost, at the Device level. Where possible this complexity has
4889 been minimized and it is envisioned that the cost of any such complexity will reduce over time as adoption
4890 increases.
4891 B.2 Typical System Power Budget
4892 The power required to transmit a digital signal is usually modeled using the following approximation:
4893 P = fCV2 + Ps + Pl

207
4894 where the active power, fCV2, typically dominates. The short circuit and leakage (quiescent) power will
4895 depend on the chosen driver topology. An approximation of active bus power consumption with random
4896 data would be 1.25 * fCV2. This gives a range of:
4897 12.288MHz into 75pF at 1.8V requires 4mW
4898 384kHz into 30pF at 1.2V requires 21W
4899 B.3 Example Slew Rate Control Circuits
4900 There are numerous methods for controlling the slew rate of the CLK line. Three example methods are
4901 outlined here as examples, though no particular topology is recommended:
4902 Nested Miller Driver
4903 Gradual Turn On Driver
4904 Transition Time Locked Driver
4905 B.3.1 Nested Miller AC Feedback Driver
4906 The concept of using AC feedback on an output driver is quite simple. When the output voltage is moving
4907 rapidly this is fed back to the pre-driver to reduce the overdrive on the output pair, regulating the slew rate
4908 into a wide range of loads by directly limiting the drivers bandwidth.
4909
4910 Figure 88 Using AC Feedback in a CMOS Output Driver
4911 This technique is similar to the stabilization capacitors used to create a dominant pole in driver topologies
4912 aimed for transmitting analog outputs. In such a situation the two output FETs are driven with pre-driver
4913 signals that are biased to allow an analog output, such biasing is not required for SLIMbus where the input
4914 and output signals are firmly digital.
4915 B.3.2 Gradual Turn-On Driver
4916 Gradual turn on drivers use sets of output drivers that can be turned on in parallel at different times.

208
4917
4918 Figure 89 GTO Driver Topology
4919 The function of such a driver is best explained by example. A GTO driver with three parallel drivers that
4920 turn on 3ns after each other is demonstrated into 15 pF, 35pF and 75pF loads below:
GTO Driver
2
1.8
1.6
1.4
1.2
Volts
1
0.8
V(75pf)
0.6
V(35pF)
0.4
V(15pF)
0.2
0
0 2 4 6 8 10 12 14
Time(ns)
4921
4922 Figure 90 Response of GTO Driver into a Lumped Load
4923 Here the three drivers are 4mA, 2mA and 8mA. The subsequent output currents will be 4, 6 then 14mA at 0
4924 to 2ns,3 to 5ns and 6ns until the output reaches opposite rail and the VDS across the output drivers reduces
4925 to zero. This creates three different regions; small loads will have completed the rise or fall before the last
4926 driver is enabled while large loads may require all three stages to become active. Ensuring that the
4927 maximum slew rate for the CLK line is not exceeded using GTO techniques alone is difficult, however his
4928 technique can be improved with a small amount of feedback, either analog (nested miller cap) or some
4929 digital feedback to the pre-drive control circuit. The order in which the output FETs are enabled can also be
4930 varied to allow the slope to be controlled throughout the transition.

209
4931 B.3.3 Transition Time Locked Driver
4932 In some situations where the CLK line must be very tightly controlled, a time-based reference can be
4933 introduced. For the CLK line driver this is convenient, the transition time can be measured and compared to
4934 the clock period.
4935
4936 Figure 91 Transition Time Locked Driver Example
4937 In the example circuit a pair of comparators is set to trigger at 20% and 80% of VDD. The output of the
4938 comparators feeds some decode logic that produces three outputs, one that is high during the rising
4939 transition time, one that indicates the falling transition time and the OR of both signals.
4940 The combined signal enables a current source, which charges a cap. The reference input, the source clock is
4941 gated and the pulses are used to charge a second capacitor with a matched current source. The ratios of the
4942 capacitors are adjusted to select the desired ratio of clock period to transition time.
4943 Every transition time a comparison is made between the voltages on the two capacitors, if the transition
4944 time was found to be too small the filtered bias voltage is reduced to compensate.
4945 Such a feedback loop can be combined with the previous two mentioned techniques. With slightly more
4946 circuitry it also allows any induced or intrinsic jitter to be noise shaped away from both converter over-
4947 sampling frequencies and the audio band.
4948 B.4 Notes on Implementing SLIMbus using CMOS IOs
4949 In situations where SLIMbus must be implemented using conventional (non-slew rate controlled) CMOS
4950 IO structures certain compromises must be made.

210
4951
4952 Figure 92 SLIMbus IO Examples using Traditional CMOS IO Driver Topologies

211
4953 The IO drivers should have the correct output impedance to drive the line while always meeting the
4954 requirements and constraints in section 5. These IO drivers may be controlled outside of SLIMbus using
4955 knowledge of the load in order to meet the specification. This side-band knowledge eliminates the largest
4956 variable. Several methods of obtaining such control are described below:
4957 The DATA input should be overvoltage protected to ensure transmission line reflections do not
4958 damage the device.
4959 If the Component includes a Framer then the maximum frequency of the CLK line driver will be
4960 limited. The maximum output slew rate must stay within the limits of the specification across all
4961 variations of PVT and loads. This may be achieved through the output impedance and/or through a
4962 slew rate limitation. Because of the high dependency on PVT and load of the CMOS IO, the
4963 transition times will be relatively long in some cases. The maximum operating frequency
4964 achievable into test loads must be quoted by the device manufacturer.
4965 As stated in section 5, a Component can be SLIMbus-compliant even if it meets the slew rate
4966 specifications into the maximum load at only reduced CLK line frequencies.
4967 A Component may implement a single terminal using multiple physical pins. This enables the use
4968 of external Components with tighter tolerances than is possible using standard IOs. If SLIMbus is
4969 to be implemented as a muxed option behind legacy buses such as I2S then such pins may become
4970 available.
4971 Hysteresis on the CLK line is required. Given the possibly reduced CLK line driver strength much
4972 care should be taken to ensure the CLK line seen by the active Manager does not glitch. CMOS
4973 IOs for clock reception that include hysteresis are not unusual.
4974
4975

212
4976 Annex C Natural Frequencies (informative)

4977 SLIMbus defines three families of Presence Rates in Table 62. The specified Presence Rates are
4978 power-of-two multiples of 4k, 11.025k, or 12k. Isochronous Data Channels based on these Presence Rates
4979 are supported by configuring the SLIMbus clock to use an appropriate Natural Frequency. Refer to section
4980 6.2.5 for more details on Natural Frequencies.
4981 Table 87 shows the Natural Frequencies across all Clock Gears for the 4k family of Presence Rates. Note
4982 that some combinations of Presence Rate and Clock Gear which can be supported with either of two
4983 Natural Frequencies. One of these Natural Frequencies is derived from the 24.576 MHz Root Frequency
4984 and is the Cardinal Frequency of the associated Clock Gear. The other Natural Frequency is derived from
4985 16.384 MHz which has no entry in Table 17 and thus must be supported with the Not Indicated code.
4986 Dashed lines indicate Presence Rates which cannot be supported in the indicated Clock Gear.
4987 Table 87 Natural Frequencies for 4k Family of Flows
Clock Natural Frequency (MHz) as a Function of Presence Rate

Gear
4k 8k 16k 32k 64k 128k 256k 512k
10 24.576 24.576 24.576 24.576 24.576 24.576 24.576 24.576
16.384 16.384 16.384 16.384 16.384 16.384 16.384
9 12.288 12.288 12.288 12.288 12.288 12.288 12.288 12.288
8.192 8.192 8.192 8.192 8.192 8.192 8.192 8.192
8 6.144 6.144 6.144 6.144 6.144 6.144 6.144 6.144
4.096 4.096 4.096 4.096 4.096 4.096 4.096 4.096
7 3.072 3.072 3.072 3.072 3.072 3.072 3.072 -
2.048 2.048 2.048 2.048 2.048 2.048 2.048
6 1.536 1.536 1.536 1.536 1.536 1.536 - -
1.024 1.024 1.024 1.024 1.024 1.024
5 0.768 0.768 0.768 0.768 0.768 - - -
0.512 0.512 0.512 0.512 0.512
4 0.384 0.384 0.384 0.384 - - - -
0.256 0.256 0.256 0.256
3 0.192 0.192 0.192 - - - - -
0.128 0.128 0.128
2 0.096 0.096 - - - - - -
0.064 0.064
1 0.048 - - - - - - -
0.032
4988 Table 88 shows the Natural Frequencies across all Clock Gears for the 11.025k family of Presence Rates.
4989 Note that some combinations of Presence Rate and Clock Gear which can be supported with either of two
4990 Natural Frequencies. One of these Natural Frequencies is derived from 22.5792 MHz which is a defined
4991 Root Frequency on SLIMbus. The other Natural Frequency is derived from 16.9344 MHz which has no

213
4992 entry in Table 17 and thus must be supported with the Not Indicated code. Dashed lines indicate Presence
4993 Rates which cannot be supported in the indicated Clock Gear.
4994 Table 88 Natural Frequencies for 11.025k Family of Flows

Gear
11.025k 22.05k 44.1k 88.2k 176.4k 352.8k 705.6k
10 22.5792 22.5792 22.5792 22.5792 22.5792 22.5792 22.5792
16.9344 16.9344 16.9344 16.9344 16.9344 16.9344 16.9344
9 11.2896 11.2896 11.2896 11.2896 11.2896 11.2896 11.2896
8.4672 8.4672 8.4672 8.4672 8.4672 8.4672 8.4672
8 5.6448 5.6448 5.6448 5.6448 5.6448 5.6448 5.6448
4.2336 4.2336 4.2336 4.2336 4.2336 4.2336
7 2.8224 2.8224 2.8224 2.8224 2.8224 2.8224 -
2.1168 2.1168 2.1168 2.1168 2.1168
6 1.4112 1.4112 1.4112 1.4112 1.4112 - -
1.0584 1.0584 1.0584 1.0584
5 0.7056 0.7056 0.7056 0.7056 - - -
0.5292 0.5292 0.5292
4 0.3528 0.3528 0.3528 - - - -
0.2646 0.2646
3 0.1764 0.1764 - - - - -
0.1323
2 0.0882 - - - - - -
1 - - - - - - -
4995 Table 89 shows the Natural Frequencies across all Clock Gears for the 12k family of Presence Rates. Note
4996 that some combinations of Presence Rate and Clock Gear which can be supported with either of two
4997 Natural Frequencies. One of these Natural Frequencies is derived from the 24.576 MHz Root Frequency
4998 and is the Cardinal Frequency of the associated Clock Gear. The other Natural Frequency is derived from
4999 18.432 MHz which has no entry in Table 17 and thus must be supported with the Not Indicated code.
5000 Dashed lines indicate Presence Rates which cannot be supported in the indicated Clock Gear.

214
5001 Table 89 Natural Frequencies for 12k Family of Flows

Gear
12k 24k 48k 96k 192k 384k 768k
10 24.576 24.576 24.576 24.576 24.576 24.576 24.576
18.432 18.432 18.432 18.432 18.432 18.432 18.432
9 12.288 12.288 12.288 12.288 12.288 12.288 12.288
9.216 9.216 9.216 9.216 9.216 9.216 9.216
8 6.144 6.144 6.144 6.144 6.144 6.144 6.144
4.608 4.608 4.608 4.608 4.608 4.608
7 3.072 3.072 3.072 3.072 3.072 3.072
2.304 2.304 2.304 2.304 2.304
6 1.536 1.536 1.536 1.536 1.536 - -
1.152 1.152 1.152 1.152
5 0.768 0.768 0.768 0.768 - - -
0.576 0.576 0.576
4 0.384 0.384 0.384 - - - -
0.288 0.288
3 0.192 0.192 - - - - -
0.144
2 0.096 - - - - - -
1 - - - - - - -
5002 Table 87 and Table 89 allow for some interesting observations. First, the Cardinal Frequency appears a
5003 Natural Frequency for both the 4k and the 12k Presence Rate families. Second, the 4k and 12k Presence
5004 Rates also have unique sets of Natural Frequencies, e.g. 9.216 MHz versus 8.192 MHz in Gear 9.
5005

215
5006 Annex D Determining NCo and NCi (informative)

5007 NCo and NCi are computed to allow for at least one clock cycle during each phase of the handover
5008 mechanism. This additional time covers any uncertainties on the rise and fall times and on the clock
5009 frequency knowledge.
5010 The first example assumes that the incoming and outgoing Framers are clocking the bus with the same
5011 frequency. The results are then generalized to different frequencies.
5012 If the bus frequency does not change, the incoming Framer must wait at least two full clock cycles after the
5013 Reconfiguration Boundary before driving the CLK line HIGH. As the incoming Framer clock and the
5014 outgoing Framer clock are not necessarily phased locked, it takes two to three clock cycles for the
5015 incoming Framer to start driving the CLK line HIGH. The period starting at the Reconfiguration Boundary
5016 and ending at the positive edge of the Incoming Framers internal clock is called wait time
5017 The overlap region, the period when both Framers are driving the CLK line HIGH, must last at least one
5018 clock cycle. Therefore, the outgoing Framer drives the CLK line to HIGH during at least four clock cycles
5019 (up to one clock cycle for the wait time, two clock cycles while the outgoing Framer is the only one driving
5020 the CLK line HIGH and one clock cycle while both Framers are driving the CLK line HIGH).
5021
5022
5023 Figure 93 Minimal Wait Time and Maximal Overlap Period

216
5024
5025 Figure 94 Maximal Wait Time and Minimal Overlap Period
5026 Because of the wait time, the overlap period can last from one to two clock cycles. As the time the
5027 incoming Framer spends driving the CLK line alone must be at least one clock cycle, the incoming Framer
5028 must spend at least three clock cycles (the maximum overlap period plus one clock cycle) driving the CLK
5029 line HIGH.
5030 When the Framer frequencies are different, the three and four clock cycle periods are replaced by NCo and
5031 NCi, respectively. Both NCo and NCi depend on the ratio between the outgoing and incoming Framer
5032 clock frequencies. There are two cases to consider, Fi > Fo and Fi < Fo.
5033 D.1 Fi > Fo
5034 The incoming Framer clock frequency, Fi, is higher than the outgoing Framer clock frequency, Fo, (Fi>Fo).
5035 The constraints of having at least one clock cycle of the incoming Framer after the overlap period defines
5036 the relation between NCi and the clock period of the incoming Framer, Ti, and the clock period of the
5037 outgoing Framer, To. NCi*Ti + 2*Ti +Hold Time 4*To + Ti. As the hold time can be as small as 0, NCi
5038 is defined by NCi 4*To/Ti - 1. Therefore, the smallest possible value is NCi = INT(4*To/Ti).

217
Reconfiguration Hand-over period

Boundary
Outgoing Framer
Internal Clock, Fo
HIGH HIGH-Z
Outgoing Framer
Clock Output
4 cycles, Fo
Incoming Framer
Internal Clock, Fi
HIGH-Z HIGH
Incoming Framer
Clock Output 2 cycles, Fi
NCi cycles, Fi
Enable
5039 clock output
5040 Figure 95 Determining NCi
5041 D.2 Fi < Fo
5042 The incoming Framer clock frequency is lower than the outgoing Framer clock frequency (Fi<Fo). The
5043 constraints of having at least one clock cycle of every clock in the overlap period defines the relation
5044 between NCo and (Ti, To). NCo*To Hold Time + 2*Ti + Ti. As the hold time can be as big as Ti, NCo is
5045 defined by NCo*To 4*Ti. Therefore, the smallest possible value is NCo = INT(4*Ti/To)+1.
5046
5047
5048 Figure 96 Determining NCo
5049

218
Contributors
The following companies have contributed to the development of this document.
Analog Devices, Inc.

austriamicrosystems AG
Ericsson AB
Freescale Semiconductor
Infineon Technologies AG
Intel Corporation
LnK
Marvell Semiconductor
Motorola
National Semiconductor
Nokia Corporation
NXP Semiconductors
RF Micro Devices
Sonion
Sony Ericsson Mobile Communications
STMicroelectronics N.V.
Synopsys, Inc
Texas Instruments Incorporated
Toshiba Corporation
Wolfson Microelectronics


Intro To SLIMbus

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Intro To SLIMbus

Încărcat de

Drepturi de autor:

Formate disponibile

9-Feb-2009

MIPI Alliance Specification for

Version 1.01.01 14 July 2008

Copyright 2007-2009 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Specification for

Version 1.01.01 14 July 2008

Copyright 2007-2008 MIPI Alliance, Inc. All rights reserved.

15 ALSO, THERE IS NO WARRANTY OF CONDITION OF TITLE, QUIET ENJOYMENT, QUIET

36 MIPI Alliance, Inc.

Copyright 2007-2008 MIPI Alliance, Inc. All rights reserved.

45 1.1 Scope ............................................................................................................................................. 21

46 1.2 Purpose .......................................................................................................................................... 21

47 1.3 Summary of SLIMbus Features ..................................................................................................... 22

49 2.1 Definitions ..................................................................................................................................... 23

50 2.2 Abbreviations ................................................................................................................................ 27

51 2.3 Acronyms ...................................................................................................................................... 27

53 4 The SLIMbus Model ............................................................................................................................. 30

54 4.1 Device Communication ................................................................................................................. 30

55 4.2 Bus Organization ........................................................................................................................... 31

56 4.2.1 Control Space ........................................................................................................................ 31

57 4.2.2 Data Space ............................................................................................................................. 31

58 4.3 Devices .......................................................................................................................................... 31

59 4.3.1 Device Classes ....................................................................................................................... 32

60 4.4 Components ................................................................................................................................... 33

61 4.4.1 Simple Component Example ................................................................................................. 33

62 4.4.2 Complex Component Example .............................................................................................. 33

63 4.4.3 Component Requirements ..................................................................................................... 34

64 4.5 Channels ........................................................................................................................................ 34

65 4.5.1 Data Channels ........................................................................................................................ 34

66 4.5.2 Control Space Channels......................................................................................................... 35

67 4.6 Frame Layer................................................................................................................................... 35

68 4.7 Physical Layer ............................................................................................................................... 35

Copyright 2007-2008 MIPI Alliance, Inc. All rights reserved.

69 4.8 System Example ............................................................................................................................ 35

70 5 Physical Layer ....................................................................................................................................... 37

71 5.1 Physical Medium Independent Signaling and Logic Types........................................................... 38

72 5.1.1 Collision Detection ................................................................................................................ 40

73 5.2 Physical Medium Dependent Specifications ................................................................................. 40

74 5.2.1 Signaling Voltages ................................................................................................................. 40

75 5.2.2 CLK Terminal Output Specifications .................................................................................... 41

76 5.2.3 CLK Terminal Input Specifications ....................................................................................... 43

77 5.2.4 DATA Terminal .................................................................................................................... 44

78 5.2.5 Bus Holder Specifications ..................................................................................................... 45

79 5.2.6 Component Power Down on an Active Bus .......................................................................... 46

80 5.2.7 System Timing Budget (informative) .................................................................................... 46

81 6 Frame Structure ..................................................................................................................................... 52

82 6.1 Cells, Slots, Subframes, Frames, and Superframes ....................................................................... 52

83 6.1.1 Cell ........................................................................................................................................ 52

86 6.1.4 Frame ..................................................................................................................................... 52

87 6.1.5 Superframe ............................................................................................................................ 53

88 6.1.6 Relationship of Frame Structure Constructs .......................................................................... 53

89 6.1.7 Integrating the Concepts (informative) .................................................................................. 54

90 6.2 Clock Gears, Frequencies, and Root Superframes......................................................................... 55

91 6.2.1 Clock Gears ........................................................................................................................... 56

92 6.2.2 Clock Gear Example (informative)........................................................................................ 56

93 6.2.3 Root Frequency...................................................................................................................... 56

94 6.2.4 Root Superframes .................................................................................................................. 56

95 6.2.5 Natural Frequencies ............................................................................................................... 57

96 6.2.6 Cardinal Frequencies ............................................................................................................. 58

Copyright 2007-2008 MIPI Alliance, Inc. All rights reserved.

97 6.3 Control Space ................................................................................................................................ 58

98 6.3.1 Framing Channel ................................................................................................................... 59

99 6.3.2 Guide Channel ....................................................................................................................... 68