0% found this document useful (0 votes)

3K views526 pages

Mipi DRAFT SoundWire-I3S Specification v0-6r01

Uploaded by

saisrikanth

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

3K views526 pages

Mipi DRAFT SoundWire-I3S Specification v0-6r01

Uploaded by

saisrikanth

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 526

DRAFT Specification for

SoundWire I3S
(SWI3SSM)

Version 0.6
Revision 01
21 September 2024

This document is subject to further editorial and technical development.

Copyright © 2019–2024 MIPI Alliance, Inc.

NOTICE OF DISCLAIMER
The material contained herein is not a license, either expressly or impliedly, to any IPR owned or controlled
by any of the authors or developers of this material or MIPI®. The material contained herein is provided on
an “AS IS” basis and to the maximum extent permitted by applicable law, this material is provided AS IS
AND WITH ALL FAULTS, and the authors and developers of this material and MIPI hereby disclaim all
other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if
any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of
accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of
negligence.
All materials contained herein are protected by copyright laws, and may not be reproduced, republished,
distributed, transmitted, displayed, broadcast or otherwise exploited in any manner without the express
prior written permission of MIPI Alliance. MIPI, MIPI Alliance and the dotted rainbow arch and all related
trademarks, tradenames, and other intellectual property are the exclusive property of MIPI Alliance and
cannot be used without its express prior written permission.
ALSO, THERE IS NO WARRANTY OF CONDITION OF TITLE, QUIET ENJOYMENT, QUIET
POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD
TO THIS MATERIAL OR THE CONTENTS OF THIS DOCUMENT. IN NO EVENT WILL ANY
AUTHOR OR DEVELOPER OF THIS MATERIAL OR THE CONTENTS OF THIS DOCUMENT OR
MIPI BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS
OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL,
CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER
CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY
OTHER AGREEMENT, SPECIFICATION OR DOCUMENT RELATING TO THIS MATERIAL,
WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH
DAMAGES.
Without limiting the generality of this Disclaimer stated above, the user of the contents of this Document is
further notified that MIPI: (a) does not evaluate, test or verify the accuracy, soundness or credibility of the
contents of this Document; (b) does not monitor or enforce compliance with the contents of this Document;
and (c) does not certify, test, or in any manner investigate products or services or any claims of compliance
with the contents of this Document. The use or implementation of the contents of this Document may
involve or require the use of intellectual property rights (“IPR”) including (but not limited to) patents,
patent applications, or copyrights owned by one or more parties, whether or not Members of MIPI. MIPI
does not make any search or investigation for IPR, nor does MIPI require or request the disclosure of any
IPR or claims of IPR as respects the contents of this Document or otherwise.
Questions pertaining to this document, or the terms or conditions of its provision, should be addressed to:
MIPI Alliance, Inc.
c/o IEEE-ISTO
445 Hoes Lane
Piscataway, NJ 08854
Attn: Board Secretary

ii Copyright © 2019–2024 MIPI Alliance, Inc.

Contents
Figures ............................................................................................................................... ix
Tables.................................................................................................................................xv
Release History ............................................................................................................... xxi
Development History .................................................................................................... xxii
1 Introduction .................................................................................................................1
1.1 Scope ............................................................................................................................... 1
1.2 Purpose ............................................................................................................................ 1
1.3 Relationship to Other MIPI Specifications ...................................................................... 2
2 Terminology .................................................................................................................3
2.1 Use of Special Terms ....................................................................................................... 3
2.2 Definitions ....................................................................................................................... 3
2.3 Abbreviations ................................................................................................................... 6
2.4 Acronyms......................................................................................................................... 6
2.5 Typographical Conventions ............................................................................................. 8
2.5.1 Defined Terms .............................................................................................................. 8
2.5.2 References .................................................................................................................... 8
2.5.3 State Names .................................................................................................................. 8
2.5.4 Number Radix .............................................................................................................. 8
3 References ....................................................................................................................9
4 Technical Overview (Informative) ...........................................................................10
4.1 Introduction.................................................................................................................... 10
4.1.1 SWI3S in a System Context ....................................................................................... 10
4.1.2 Features ...................................................................................................................... 11
4.1.3 SWI3S Layering ......................................................................................................... 12
4.1.4 Audio Payload Streams .............................................................................................. 13
4.1.5 PHYs .......................................................................................................................... 14
4.2 Row and Column Structure ........................................................................................... 16
4.2.1 Introduction to Rows & Columns and Related Terminology ..................................... 16
4.2.2 General Description of Rows ..................................................................................... 17
4.2.3 Vertical Structure and SSPs ........................................................................................ 17
4.2.4 Clocking ..................................................................................................................... 19
4.3 Payload Transport .......................................................................................................... 20
4.3.1 SWI3S Payload Concepts and Terminology............................................................... 20
4.3.2 Example Transport Patterns ........................................................................................ 21
4.3.3 SWI3S Payload Traffic Visualization ......................................................................... 27
4.4 Control Data Stream and Commands ............................................................................ 28
4.4.1 Command Protocol Layers ......................................................................................... 28
4.4.2 Control Data Stream ................................................................................................... 29
4.4.3 Command Transport Protocol..................................................................................... 30
4.4.4 Commands .................................................................................................................. 35
4.4.5 Peripheral Command Model....................................................................................... 36
4.5 Reset & Link Power Management ................................................................................. 39
4.5.1 Link States .................................................................................................................. 39

Copyright © 2019–2024 MIPI Alliance, Inc. iii

4.5.2 Link Control Sequences ............................................................................................. 40

4.5.3 Resets.......................................................................................................................... 42
4.6 Typical Link Management Sequences ........................................................................... 43
4.6.1 Comparing Cold Booting with Warm Booting (aka Sleep-Wake). ............................. 43
4.6.2 Cold Booting a Link (including Power-On) ............................................................... 43
4.6.3 Placing an Active Link in Cold_Standby ................................................................... 45
4.6.4 Placing an Active Link in Sleeping ............................................................................ 45
4.6.5 Warm Booting (Wake) ................................................................................................ 46
4.6.6 Starting Audio Payload Transport .............................................................................. 46
4.6.7 Moving an Active Payload Stream within the Transport Pattern ............................... 46
4.7 System Architectures ..................................................................................................... 48
4.7.1 System Topologies ...................................................................................................... 48
4.7.2 Physical Topologies .................................................................................................... 48
4.7.3 Logical Topology ........................................................................................................ 51
4.8 Physical Layer – PHY ................................................................................................... 52
4.8.1 DRAFT: PHY-Agnostic View Presented to Higher Layers ........................................ 52
4.8.2 PHY1 and PHY2: FBCSE Forwarded-Bit-Clock Single-Ended ................................ 53
4.8.3 PHY3: Differential Low Voltage (DLV)..................................................................... 54
4.9 Registers ........................................................................................................................ 58
4.9.1 Address Map ............................................................................................................... 58
4.9.2 Interrupts .................................................................................................................... 58
4.9.3 Error Counters ............................................................................................................ 59
4.9.4 Register Synchronization Model (Dual-Ranked Registers and Commit Commands) 59
5 Link Control & Reset................................................................................................60
5.1 Description (informative) .............................................................................................. 61
5.1.1 Overview .................................................................................................................... 61
5.1.2 Link Control Sequences (Detail) ................................................................................ 65
5.1.3 Peripheral Management Action (PM_Action) Field ................................................... 83
5.1.4 Selection of PHY Number in Peripheral .................................................................... 84
5.1.5 Reset ........................................................................................................................... 85
5.1.6 Peripheral Bus Reset State Machine (PBR_SM) ........................................................ 88
5.1.7 Peripheral Link State Machine (PL_SM): Inactive Link ............................................ 92
5.1.8 Peripheral Link State Machine (PL_SM): Active Link .............................................. 98
5.1.9 Manager Link State Machine (ML_SM): Inactive Link........................................... 103
5.1.10 Manager Link State Machine (ML_SM) for Active States .................................. 106
5.1.11 Choice of Clock Config and Transport Pattern .................................................... 109
5.2 Specifications (normative) ........................................................................................... 111
5.2.1 Reset ......................................................................................................................... 111
5.2.2 Peripheral Link Control ............................................................................................ 116
5.2.3 Manager Link Control .............................................................................................. 128
5.2.4 Device Properties...................................................................................................... 135
6 Link Control PHY ...................................................................................................140
6.1 Description (informative) ............................................................................................ 140
6.1.1 Overview .................................................................................................................. 140
6.1.2 Link Control PHY in the Manager ........................................................................... 140
6.1.3 Link Control PHY in the Peripheral ......................................................................... 141
6.1.4 Relative Drive Strengths of Manager and Peripheral LC_PHY ............................... 141

iv Copyright © 2019–2024 MIPI Alliance, Inc.

6.1.5 PHY–Protocol Interface ........................................................................................... 142

6.2 Specifications (Normative) .......................................................................................... 143
6.2.1 Link Control PHY: Electrical Parameters ................................................................. 143
6.2.2 Device Electrical Parameters .................................................................................... 145
6.2.3 Recommended System Electrical Parameters / Device Operating Conditions......... 146
7 Control Data Stream ...............................................................................................148
7.1 Description (informative) ............................................................................................ 148
7.1.1 Overview of the Control Data Stream ...................................................................... 148
7.1.2 Control Data Stream Transport ................................................................................. 151
7.1.3 8b/10b Encoding ....................................................................................................... 152
7.1.4 Robust Tokens Used in Command Transport Protocol ............................................. 154
7.1.5 Error Detection in the 8b/10b Decoder..................................................................... 156
7.1.6 ###TODO 8b/10b Encoding Examples .................................................................... 157
7.2 Specifications (normative) ........................................................................................... 159
7.2.1 Control Data Stream 8b/10b Encoding ..................................................................... 159
7.2.2 Control Data Stream 8b/10b Decoding .................................................................... 165
7.2.3 Control Data Stream: Idle Patterns ........................................................................... 167
7.2.4 #WIP: Control Data Stream: PHY Calibration Blocks ............................................. 168
7.2.5 #WIP: Control Data Stream: Transport .................................................................... 168
8 Command Transport Protocol ...............................................................................171
8.1 Description (informative) ............................................................................................ 172
8.1.1 Overview of Command Transport Protocol.............................................................. 172
8.1.2 Elements of Phases ................................................................................................... 179
8.1.3 Phase Flowcharts ...................................................................................................... 189
8.1.4 Peripheral Responses in Detail ................................................................................. 202
8.1.5 Manager Responses in Detail ................................................................................... 207
8.1.6 GetStatus Transfer .................................................................................................... 209
8.1.7 Announce Transfer ................................................................................................... 211
8.1.8 Read Transfer ........................................................................................................... 212
8.1.9 Write Transfer ........................................................................................................... 216
8.1.10 Commit Transfer ................................................................................................... 218
8.1.11 CalibratePhy Transfer ........................................................................................... 221
8.1.12 Usage of Robust Tokens in Command Transport Protocol................................... 221
8.1.13 CRC Checking in Command Transport Protocol ................................................. 223
8.1.14 Details of Local and Remote Accesses ................................................................. 225
8.1.15 Transaction Ordering ............................................................................................ 226
8.1.16 Error Handling in the Command Transport Protocol ........................................... 227
8.1.17 Example Error Scenarios in Command Transport Protocol ................................. 230
8.1.18 Examples of Error Handling ................................................................................. 233
8.2 Specifications (normative) ........................................................................................... 235
8.2.1 Structure of Phases ................................................................................................... 235
8.2.2 CRC for Command Transport Protocol .................................................................... 254
8.2.3 Peripheral Responses to Phases ................................................................................ 255
8.2.4 Manager Responses to Phases .................................................................................. 265
8.2.5 Command Transport Protocol Errors ........................................................................ 268
9 Commands ...............................................................................................................269
9.1 Description (informative) ............................................................................................ 269

Copyright © 2019–2024 MIPI Alliance, Inc. v

9.1.1 Overview of Commands ........................................................................................... 269

9.1.2 Peripheral Command Model..................................................................................... 271
9.1.3 Peripheral Command Execution State ...................................................................... 272
9.1.4 Peripheral Remote Access State ............................................................................... 274
9.1.5 Ping Command ......................................................................................................... 278
9.1.6 SSPA (Stream Synchronization Point Announcement) Command ........................... 279
9.1.7 ExitDormant Command............................................................................................ 280
9.1.8 ReadA32 Command: Address Mapped Read ........................................................... 281
9.1.9 WriteA32 Command: Address Mapped Write .......................................................... 282
9.1.10 SSCR & DSCR Commands: Synchronous Commit Requests ............................. 284
9.1.11 Unblock Command ............................................................................................... 286
9.1.12 InitCal & TrimCal Commands Used for Peripheral PHY Calibration ................. 286
9.1.13 Sync_Point_Delay in SSPA, SSCR, and DSCR Commands ................................ 291
9.1.14 Decisions to be folded into this Section ............................................................... 293
9.2 Specifications (normative) ........................................................................................... 294
9.2.1 Command Processing ............................................................................................... 294
9.2.2 Remote Read and Write Accesses (Optional) ........................................................... 296
9.2.3 WriteA32 Command................................................................................................. 299
9.2.4 ReadA32 Command ................................................................................................. 303
9.2.5 SSPA (Stream Synchronization Point Announcement) Command ........................... 306
9.2.6 ExitDormant Command............................................................................................ 308
9.2.7 SSCR and DSCR Commands ................................................................................... 309
9.2.8 Ping Command ......................................................................................................... 310
9.2.9 Unblock Command ................................................................................................... 312
9.2.10 InitCal & TrimCal Commands ............................................................................. 313
10 Transport Pattern (Rows & Columns) ...............................................................315
10.1 Description (informative) ............................................................................................ 315
10.1.2 Transport Clocking and Unit Intervals ................................................................. 315
10.1.3 Relation of Rows to Audio Clocking .................................................................... 315
10.1.4 Wide Bits .............................................................................................................. 316
10.1.5 Key to Bits Used in Transport Patterns ................................................................ 317
10.1.6 Command-Only Transport Patterns ...................................................................... 321
10.1.7 Initial Transport Patterns for DLV PHY ............................................................... 322
10.1.8 Initial Transport Patterns for FBCSE PHY........................................................... 324
10.1.9 Examples of Transport Patterns for DLV PHY .................................................... 327
10.1.10 Examples of Transport Patterns for FBCSE PHY2 .............................................. 332
10.1.11 Example Transport Patterns for FBCSE PHY1 .................................................... 334
10.1.12 Examples of Transport Patterns with Guard Bits ................................................. 335
10.1.13 Examples of Transport Patterns with Wide Bits ................................................... 336
10.1.14 Examples of Transport Patterns with Tail Bits ..................................................... 337
10.1.15 Half-Unit-Interval Granularity for Ends of Transport (EndHalfEarly) ................ 341
10.1.16 Examples of Changing Transport Pattern at SSP ................................................. 342
10.1.17 Examples of Changing Clock Config ................................................................... 344
10.2 Specifications (Normative) .......................................................................................... 347
10.2.1 ###WIP Generic Rules for Transport ................................................................... 347
11 PHY1 & PHY2 Forwarded Bit Clock Single-Ended (FBCSE) ........................349
11.1 Description (informative) ............................................................................................ 350

vi Copyright © 2019–2024 MIPI Alliance, Inc.

11.1.1 # Single-Ended PHY Overview ............................................................................ 352

11.1.2 PHY1&2 (FBCSE) Clock Config and Transport Patterns .................................... 355
11.1.3 PHY1 & PHY2 (FBCSE) System Design Issues ................................................. 356
11.2 Specifications (normative) ........................................................................................... 357
11.2.1 PHY1 & PHY2 (FBCSE): Link Control Behavior ............................................... 357
11.2.2 PHY1 & PHY2 (FBCSE): Electrical Parameters ................................................. 360
11.2.3 PHY1 & PHY2 (FBCSE): Timing Parameters ..................................................... 363
11.2.4 PHY1 & PHY2: Recommended System Parameters............................................ 364
11.2.5 PHY1 & PHY2 (FBCSE): Driving and Sampling Data ....................................... 365
11.3 TEMP OLD DRAFT Tables from v0.5r11 PHY#1 and PHY#2 (FBCSE) .................. 366
12 PHY3 Differential Low-Voltage (DLV) ..............................................................377
12.1 Description (informative) ............................................................................................ 377
12.1.1 Overview of PHY3 (DLV).................................................................................... 377
12.1.2 [DRAFT] PHY3 (DLV): Special Drive Type for CDS Bits ................................. 377
12.1.3 PHY3 (DLV) System Design Issues ..................................................................... 378
12.1.4 DRAFT: Peripheral DLV PHY Timing Calibration .............................................. 379
12.1.5 DRAFT: DLV PHY Calibration in the Peripheral ................................................ 380
12.1.6 PHY3 (DLV) Clock Config and Transport Patterns ............................................. 381
12.2 Specifications (normative) ........................................................................................... 382
12.2.1 PHY3 (DLV): Link Control Behavior .................................................................. 382
12.2.2 PHY3 (DLV): Electrical Parameters .................................................................... 386
12.2.3 PHY3 (DLV): Timing Parameters ........................................................................ 388
12.2.4 PHY3: Recommended System Parameters........................................................... 393
12.2.5 Parameter Measurement Definitions and Test Circuits ........................................ 393
12.3 TEMP OLD DRAFT Tables from v0.5r11 for PHY#3 (DLV) .................................... 394
13 [Draft] Payload Transport ...................................................................................400
13.1.1 Introduction to Data Ports .................................................................................... 400
13.1.2 #NEW# Sequences for Prepare, Ready, and Enable............................................. 400
13.1.3 Payload Control and Status Bits ........................................................................... 405
13.1.4 Relation Between Enabling Source DP and Sink DP ........................................... 411
13.1.5 Example Sequences for Prepare / Ready / Enable ................................................ 412
13.1.6 DRAFT: Description of Data Port Algorithm from the Python Visualizer
(Informative) ......................................................................................................................... 414
13.1.7 Payload Data Scrambling ..................................................................................... 424
13.1.8 Flow Controlled Transport ................................................................................... 424
13.1.9 Programming Errors ............................................................................................. 425
13.1.10 Known TO-DO Items ........................................................................................... 425
13.1.11 Previous Draft Material … ................................................................................... 426
13.1.12 #DRAFT MAC Layer Rules................................................................................. 431
13.1.13 DRAFT: Payload Transport with Interval Skipping ............................................. 433
13.1.14 #SPARE Payload Transport Examples ................................................................. 433
13.2 #WIP Specifications (normative) ................................................................................. 435
13.2.1 Data Port: Prepare, Ready, and Enable ................................................................. 435
13.2.2 Data Port: FlowMode and Port Mode................................................................... 436
13.2.3 #WIP: Data Port : Scrambler ................................................................................ 438
14 Registers ................................................................................................................439
14.1 Description (informative) ............................................................................................ 439

Copyright © 2019–2024 MIPI Alliance, Inc. vii

14.1.1 Address Map ......................................................................................................... 439

14.1.2 Registers ............................................................................................................... 439
14.1.3 Dual-Ranked Registers ......................................................................................... 441
14.1.4 Some ###TBD items for Registers: ...................................................................... 442
14.2 Specifications (normative) ........................................................................................... 444
14.2.1 Peripheral Address Map ....................................................................................... 444
14.2.2 Peripheral Data Port Registers .............................................................................. 447
14.2.3 Peripheral Data Port Register Fields .................................................................... 451
14.2.4 Peripheral System and Link Control Registers ..................................................... 463
14.2.5 Peripheral System and Link Control Register Fields ........................................... 467
14.2.6 Peripheral Control Data Stream Transport Registers............................................ 475
14.2.7 Peripheral Control Data Stream Transport Register Fields .................................. 476
14.2.8 Peripheral PHY1 and #2 (FBCSE) Registers ....................................................... 479
14.2.9 Peripheral PHY1 and #2 (FBCSE) Register Fields .............................................. 481
14.2.10 Peripheral PHY3 (DLV) Registers ....................................................................... 482
14.2.11 Peripheral PHY3 (DLV) Register Fields .............................................................. 484
15 [Draft Notes] Interrupts ......................................................................................487
15.1 Description (informative) ............................................................................................ 487
15.1.1 Interrupt Model ..................................................................................................... 487
15.1.2 Interrupt Cascade Model ...................................................................................... 488
15.1.3 Error Counters ...................................................................................................... 488
15.2 Specifications (normative) ........................................................................................... 489
15.2.1 Error Counters ...................................................................................................... 489
Annex A Hooks for Implementation-Defined Extensions ....................................493
A.1 System Control ............................................................................................................ 493
A.2 Registers & Address Space .......................................................................................... 493
A.3 Command Operations .................................................................................................. 493
A.4 Interrupts ...................................................................................................................... 493
A.5 Audio Circuitry ............................................................................................................ 493
Annex B Example Calibration Algorithms for PHY3 (DLV) ..............................494
B.1 Example Calibration Algorithm: 2-step based on N Previous Values ......................... 494
B.2 Example Calibration Algorithm: Adaptive Step Control ............................................. 494
Annex C PHY–Protocol Interface (PPI) ................................................................495
Annex D Cross Reference of Device Rule Unique Identifiers (Informative) ......496

viii Copyright © 2019–2024 MIPI Alliance, Inc.

Figures
Figure 1 An Example SWI3S Link ................................................................................................. 10
Figure 2 SWI3S Layers .................................................................................................................. 12
Figure 3 An Example SWI3S Link that Uses 1 PHY ..................................................................... 14
Figure 4 An Example SWI3S Link that can Operate with Multiple PHYs .................................... 15
Figure 5 Example Transport Pattern (1 Row with DLV PHY) ....................................................... 17
Figure 6 Example Transport Pattern: 8 PDM Streams with PHY3 (DLV) ..................................... 18
Figure 7 Example Transport Pattern: 1 PDM Stream with PHY1 (FBCSE) .................................. 21
Figure 8 Example Transport Pattern: 2 PDM Streams at Mixed Rates with PHY1 (FBCSE) ....... 21
Figure 9 Example Transport Pattern: PDM Streams Without Sample Grouping ........................... 22
Figure 10 Example Transport Pattern: PDM Streams With Sample Grouping .............................. 23
Figure 11 Example Transport Pattern: Mixed PCM and PDM ....................................................... 24
Figure 12 Example Transport Pattern: Mixing PCM Sample Rates and Widths ............................ 25
Figure 13 Example Transport Pattern: High Bandwidth PCM ....................................................... 26
Figure 14 Example of SWI3S Payload Visualizer Tool ................................................................. 27
Figure 15 Command Protocol Layer Stack: Overview .................................................................. 28
Figure 16 Control Data Stream Symbols within a Transport Pattern ............................................. 30
Figure 17 Key to Command Transport Protocol Diagrams ............................................................ 31
Figure 18 Examples of Write Phases .............................................................................................. 32
Figure 19 Example Read Phases .................................................................................................... 33
Figure 20 Example Ping & Commit Phases ................................................................................... 34
Figure 21 Peripheral Command Model .......................................................................................... 36
Figure 22 Link States ..................................................................................................................... 39
Figure 23 Bus Reset Sequence from Manager ............................................................................... 40
Figure 24 Cold Start Sequence (Simplified)................................................................................... 40
Figure 25 Warm Start Sequence (Simplified) ................................................................................. 40
Figure 26 Peripheral LC_Request and Manager LC_Acknowledge (Simplified) .......................... 41
Figure 27 An Example System Using Multiple SWI3S Links ....................................................... 48
Figure 28 Physical Topology: Point-to-Point ................................................................................. 49
Figure 29 Physical Topology: Generic Multi-Drop ........................................................................ 49
Figure 30 Physical Topology: Multi-drop – Manager-at-End ........................................................ 49
Figure 31 Physical Topology: Star-on-a-Stick ............................................................................... 50

Copyright © 2019–2024 MIPI Alliance, Inc. ix

Figure 32 Physical Topology: Toothbrush ...................................................................................... 50

Figure 33 Physical Topology: Dumbbell ........................................................................................ 50
Figure 34 SWI3S Logical Topologies ............................................................................................ 51
Figure 35 DLV PHY, Example of a Medium Length Multi-Drop Physical Topology ................... 55
Figure 36 DLV PHY, Example of a Shorter Multi-Drop Physical Topology ................................. 56
Figure 37 DLV PHY, Example of a Long Point-to-Point Physical Topology ................................ 56
Figure 38 DLV PHY, Example of a Star-on-a-Stick Physical Topology ........................................ 56
Figure 39 DLV PHY, Example of a Dumbbell Physical Topology ................................................ 57
Figure 40 Link States ..................................................................................................................... 62
Figure 41 Key to Link Control Sequence Diagrams ...................................................................... 67
Figure 42 Cold Start Sequence (Detail) .......................................................................................... 68
Figure 43 Warm Start Sequence (Detail) ........................................................................................ 70
Figure 44 Peripheral LC_Request and Manager LC_Acknowledge (Detail) ................................. 71
Figure 45 Manager LC_Acknowledge does not Trigger Warm Start or Cold Start ....................... 73
Figure 46 Overlapping LC_Requests from 2 Peripherals .............................................................. 74
Figure 47 Warm Start After an LC_Request................................................................................... 76
Figure 48 LC_Request Extended Directly into Warm Start ........................................................... 77
Figure 49 Warm Start After Repeated LC_Requests ...................................................................... 78
Figure 50 Re-entering Inactive Link States .................................................................................... 79
Figure 51 Re-entering an Inactive Link States from PHY3:DLV Using an SSCR......................... 81
Figure 52 Bus Reset Sequence from Manager ............................................................................... 86
Figure 53 Bus Reset Sequence from Manager when DLV PHY is Active ..................................... 87
Figure 54 Peripheral Bus Reset State Machine (PBR_SM) ........................................................... 88
Figure 55 Peripheral Bus Reset Detection: Independent of Initial State of PBR_SM ................... 90
Figure 56 Peripheral Bus Reset Detection: Effect of Wide Timing Tolerances in PBR_SM ......... 91
Figure 57 Peripheral Link State Machine (PL_SM): Inactive Link States ..................................... 92
Figure 58 Key to Peripheral Link State Machine Diagram (PL_SM) ............................................ 93
Figure 59 Peripheral Link Control Request State Machine (PLCR_SM) ...................................... 95
Figure 60 Peripheral Link State Machine (PL_SM): Active Link States ....................................... 98
Figure 61 Manager Link State Machine (ML_SM): Inactive Link Behavior .............................. 103
Figure 62 Key to Manager Link State Machine Diagram (ML_SM) ........................................... 104
Figure 63 Manager Link State Machine (ML_SM): Active Link Behavior for PHY3 (DLV) ..... 106

x Copyright © 2019–2024 MIPI Alliance, Inc.

Figure 64 Manager Link State Machine (ML_SM): Active Link Behavior for PHY1 or PHY2
(FBCSE) ....................................................................................................................................... 107
Figure 65 Manager Flow for Changing Clock Config ................................................................. 110
Figure 66 Link Control PHY in the Manager ............................................................................... 140
Figure 67 Link Control PHY in the Peripheral ............................................................................. 141
Figure 68 Layer Stack: Control Data Stream ............................................................................... 148
Figure 69 Layer Stack: Command Transport Protocol ................................................................. 171
Figure 70 Command Transport Protocol Structure and Naming .................................................. 172
Figure 71 10-bit Symbol Space for CDS ...................................................................................... 173
Figure 72 Generic Structure of a Phase ........................................................................................ 174
Figure 73 Phase Patterns .............................................................................................................. 180
Figure 74 Start of Phase Marker ................................................................................................... 181
Figure 75 Phase Header ................................................................................................................ 181
Figure 76 Manager Packets .......................................................................................................... 182
Figure 77 Peripheral Responses ................................................................................................... 183
Figure 78 Peripheral Responses to a Multicast Commit Phase .................................................... 184
Figure 79 Peripheral Multicast Info in GetStatus Phase............................................................... 185
Figure 80 Peripheral Packet.......................................................................................................... 186
Figure 81 Manager Responses...................................................................................................... 187
Figure 82 Protocol Spacer ............................................................................................................ 187
Figure 83 Calibration Packet ........................................................................................................ 188
Figure 84 Peripheral Calibration Results ..................................................................................... 188
Figure 85 Key to Command Transport Protocol Flowcharts ........................................................ 190
Figure 86 Protocol Flowchart: Common to All Phases (Manager) .............................................. 191
Figure 87 Protocol Flowchart: Common to All Phases (Peripheral) ............................................ 192
Figure 88 Protocol Flowchart: Peripheral in Link State: Dormant............................................... 193
Figure 89 Protocol Flowchart: GetStatus Phase (Ping Command) .............................................. 194
Figure 90 Protocol Flowchart: Announce Phase (SSPA & ExitDormant) .................................... 194
Figure 91 Protocol Flowchart: Commit Phase ............................................................................. 195
Figure 92 Protocol Flowchart: Write Phase (Unblock Command) ............................................... 196
Figure 93 Protocol Flowchart: Write Phase (Local WriteA32 Command) ................................... 196
Figure 94 Protocol Flowchart: ReadSetup Phase (Local ReadA32 Command) ........................... 197
Figure 95 Protocol Flowchart: CalibratePhy Phase ...................................................................... 198

Copyright © 2019–2024 MIPI Alliance, Inc. xi

Figure 96 Protocol Flowchart: Write Phase (Remote WriteA32 Command) ............................... 199
Figure 97 Protocol Flowchart: Remote ReadSetup and ReadData Phases (Manager) ................. 200
Figure 98 Protocol Flowchart: Remote ReadSetup and ReadData Phases (Peripheral) ............... 201
Figure 99 GetStatus Phase & Ping Command .............................................................................. 209
Figure 100 Announce Phases and SSPA & ExitDormant Commands .......................................... 211
Figure 101 ReadSetup Phase & ReadA32 Command .................................................................. 213
Figure 102 ReadData Phase.......................................................................................................... 214
Figure 103 Write Phases and WriteA32 and Unblock Commands ............................................... 216
Figure 104 Commit Phase and SSCR & DSCR Commands ........................................................ 219
Figure 105 Examples of Peripheral Responses to Commit Transfer ............................................ 220
Figure 106 Summary of CalibratePhy Transfer Containing a InitCal Command ........................ 221
Figure 107 CRC Calculation in Command Transport Protocol .................................................... 223
Figure 108 Scope of CRC Calculations on Manager Packets ...................................................... 225
Figure 109 Scope of CRC Calculations on Peripheral Packets .................................................... 225
Figure 110 Example Error Scenario: Ping Command with Missing Peripheral Response ........... 230
Figure 111 Example Error Scenario: ReadSetup with Corrupted READ_DATA_NOW ............. 232
Figure 112 Example Error Scenario: ReadSetup with Corrupted REMOTE_READ_DEFERRED232
Figure 113 Layer Stack: Commands and Register Model ............................................................ 269
Figure 114 Peripheral Command Model ...................................................................................... 271
Figure 115 Peripheral Command Execution State........................................................................ 272
Figure 116 Peripheral Remote Access State ................................................................................. 274
Figure 117 TEMP OLD VERSION TO BE DELETED: Peripheral Remote Access State .......... 277
Figure 118 Command Reference Point for Measuring Row Delay .............................................. 291
Figure 119 #INCORRECT#: SSP Timing Details (when using DLV PHY) ................................ 292
Figure 120 Key to Wide Bits in Transport Pattern Diagrams ....................................................... 317
Figure 121 Key to Control Data Stream Bits ............................................................................... 317
Figure 122 Key to Payload Bits.................................................................................................... 318
Figure 123 Key to PHY-Related Bits and Unit Intervals.............................................................. 319
Figure 124 Command-Only Transport Pattern ............................................................................. 321
Figure 125 Command-Only Transport Pattern: Single Rising Edge ............................................ 321
Figure 126 Initial Transport Pattern for PHY3 (DLV) – Safe-Lock-4 ......................................... 322
Figure 127 Example Transport Patterns: Command-Only for DLV PHY (Lock-N) .................... 323
Figure 128 Example Transport Patterns: Command-Only for FBCSE PHY2 ............................. 324

xii Copyright © 2019–2024 MIPI Alliance, Inc.

Figure 129 Example Transport Patterns: Command-Only for FBCSE PHY1 ............................. 324
Figure 130 NRZS Coding of Control Data Stream with FBCSE PHY ........................................ 325
Figure 131 Example of Data Waveform for Command-Only Transport Pattern for FBCSE PHY325
Figure 132 Example Transport Pattern: PCM Stream .................................................................. 327
Figure 133 Example TP: PDM Streams Without Sample Grouping (DLV PHY) ........................ 328
Figure 134 Example TP: PDM Streams with Sample Grouping (DLV PHY).............................. 329
Figure 135 Example TP: 1 Low-Power PDM Mic Stream (DLV PHY) ...................................... 330
Figure 136 Example TP: 24 Columns (DLV PHY) ..................................................................... 331
Figure 137 Example TP: PCM Streams (FBCSE PHY2) ............................................................. 332
Figure 138 Example TP: PDM Streams Without Sample Grouping (FBCSE PHY2) ................. 333
Figure 139 Example TP: PDM Streams with Sample Grouping (FBCSE PHY2) ....................... 333
Figure 140 Example TP: 1 Slow PDM Mic (FBCSE PHY1) ....................................................... 334
Figure 141 Example TP: 3 PDM Mics (FBCSE PHY1) .............................................................. 334
Figure 142 Example Traffic Pattern: Guard Bits .......................................................................... 335
Figure 143 Example Transport Pattern: Wide Bits ....................................................................... 336
Figure 144 Example Transport Pattern: PDM Streams with PHY Tail Bits ................................. 337
Figure 145 Example Transport Pattern: PDM Streams with PHY Tail Bits (No Sample Grouping)337
Figure 146 Example Transport Pattern: PDM Streams with PHY Tail Bits (Small Sample
Grouping) ..................................................................................................................................... 338
Figure 147 Transport Pattern Example: PCM Streams with PHY Tail Bits ................................. 338
Figure 148 Example Transport Pattern: PCM & PDM Streams with PHY Tail Bits ................... 339
Figure 149 Example TP: Detail of DLV PHY Sync with PHY Tail Bits ...................................... 340
Figure 150 Example TP: 2 PDM Mics in 8 Columns ................................................................... 341
Figure 151 Example TP: 2 PDM Mics in 8 Columns Using EndHalfEarly ................................. 341
Figure 152 Example TP: Disabling PDM Streams ....................................................................... 342
Figure 153 Example TP: Adding a PCM Channel ....................................................................... 343
Figure 154 ### Placeholder .......................................................................................................... 344
Figure 155 #DRAFT Single MIC (PHY1, FBCSE) ..................................................................... 345
Figure 156 #DRAFT Single Mic Using SRI for Reduced Control Bandwidth (PHY1, FBCSE) 345
Figure 157 Start-Up Flow for Manager using DLV PHY ............................................................ 346
Figure 158 Clock Config Example: Scaling Down Row Rate (DLV PHY) ................................. 346
Figure 159 Clock Config Example: Scaling Down Row Rate (DLV PHY) - Detail .................... 347
Figure 160 ###TBD-not-DLV? Clock Config Example: Scaling Up Row Rate .......................... 347

Copyright © 2019–2024 MIPI Alliance, Inc. xiii

Figure 161 ###TBD-not-DLV? Clock Config Example: Changing Column Count .................... 347
Figure 162 Block Diagram of FBCSE PHY Interface Pins in Manager ...................................... 353
Figure 163 Clock Pause in FBCSE .............................................................................................. 354
Figure 164 #DRAFT: DLV Timing Calibration ........................................................................... 379
Figure 165 PHY3 Test Circuit #1 ................................................................................................. 394
Figure 166 PHY3 Measurement Waveform #1 (###TBD-name) ................................................. 394
Figure 167 #OLD# to be deleted: PortSyncOK............................................................................ 400
Figure 168 #OLD# to be deleted: PortReady ............................................................................... 400
Figure 169 Starting a Mic Capture Stream, Enable After Ready ................................................. 401
Figure 170 Starting a Mic Capture Stream, Enable Before Ready ............................................... 402
Figure 171 Starting and Stopping an Amp Render Stream, with Host Fade Out ......................... 403
Figure 172 Starting and Stopping an Amp Render Stream, with Peripheral Fade Out ................ 404
Figure 173 Source DP Enabled Before and Disabled After the Sink DP ..................................... 411
Figure 174 Sink DP: Starting a Stream when the Manager Waits for Ready ............................... 412
Figure 175 Sink DP: Stopping a Stream when the Manager Waits for Ready ............................. 412
Figure 176 Source DP: Starting a Stream, Wait for Ready .......................................................... 413
Figure 177 Source DP: Starting a Stream, Without Waiting for Ready........................................ 413
Figure 178 Source DP: Pausing a Stream ..................................................................................... 414
Figure 179 Dual-Ranked Register with Read-Only Current Value (Dual-RO) ............................ 442
Figure 180 Dual-Ranked Register with Read-Write Current Value (Dual-RW) .......................... 442
Figure 181 Interrupt Channel (with Optional Saturating Error Counter) ..................................... 487

xiv Copyright © 2019–2024 MIPI Alliance, Inc.

Tables
Table 1 Links to Normative Tables of Timing Parameters ............................................................. 66
Table 2 States in the Peripheral Bus Reset State Machine (PBR_SM) .......................................... 89
Table 3 States in the Peripheral Link State Machine (PL_SM): Inactive Link .............................. 93
Table 4 States in the Peripheral Link State Machine: Active Link ................................................. 99
Table 5 Transitions in the PL_SM (Active States) ....................................................................... 101
Table 6 States in the Manager Link State Machine (ML_SM) ..................................................... 105
Table 7 States in the Manager Link State Machine: Active Link ................................................. 108
Table 8 Sources of Reset in Peripheral ......................................................................................... 111
Table 9 Effects of Reset in Peripheral .......................................................................................... 112
Table 10 Sources of Reset in Manager ......................................................................................... 115
Table 11 Effects of Reset in Manager ........................................................................................... 115
Table 12 Peripheral Link States .................................................................................................... 116
Table 13 Summary of Peripheral Data Transfer in Link States .................................................... 117
Table 14 Timing Parameters for Peripheral Link Control Sequences .......................................... 117
Table 15 Audio-mode PHYs in Peripheral ................................................................................... 121
Table 16 Phy-Specific Rules for Audio-mode PHYs in Peripheral .............................................. 122
Table 17 Effect of Explicitly Commiting a Peripheral Management Action (PM_Action) ......... 123
Table 18 Effect of Implicitly Commiting a Peripheral Management Action (PM_Action) ......... 124
Table 19 Power Saving in Peripheral Link States ........................................................................ 126
Table 20 Manager Link States ...................................................................................................... 128
Table 21 Timing Parameters for Manager Link Control Sequences ............................................. 129
Table 22 Selecting Audio-mode PHYs in Manager...................................................................... 132
Table 23 Phy-Specific Rules for Audio-mode PHYs in Manager ................................................ 132
Table 24 Audio-mode PHYs ......................................................................................................... 135
Table 25 Encoding of RowRateRange Field ................................................................................ 136
Table 26 [LC PHY] Supply Voltage for Link Control Interface ................................................... 143
Table 27 [LC PHY] Input and Output Voltage Parameters .......................................................... 143
Table 28 [LC PHY] Output Impedance ........................................................................................ 144
Table 29 [Device] Pin Capacitance .............................................................................................. 145
Table 30 [Device] Pin Leakage Current ....................................................................................... 146
Table 31 Recommended System Parameters [LC PHY] .............................................................. 146

Copyright © 2019–2024 MIPI Alliance, Inc. xv

Table 32 Transport Parameters for Control Data Stream.............................................................. 151

Table 33 K.28.y Comma Symbols ................................................................................................ 154
Table 34 Robust Token Symbols .................................................................................................. 155
Table 35 8b/10b 6-bit Codewords for D-codes ............................................................................ 159
Table 36 8b/10b 4-bit Codewords for D-codes ............................................................................ 161
Table 37 Running Disparity in 8b/10b Encoder ........................................................................... 162
Table 38 8b/10b 6-bit Codewords for K-codes ............................................................................ 162
Table 39 8b/10b 4-bit Codewords for K-codes ............................................................................ 163
Table 40 Robust Token Values ..................................................................................................... 164
Table 41 Running Disparity in 8b/10b Decoder ........................................................................... 166
Table 42 Transport Parameters for Control Data Stream (PHY-independent).............................. 169
Table 43 Transport Parameters for Control Data Stream (PHY1, FBCSE-zero-handover PHY) 169
Table 44 Transport Parameters for Control Data Stream (PHY2, FBCSE-scheduled-handover
PHY)............................................................................................................................................. 169
Table 45 Transport Parameters for Control Data Stream (PHY3, DLV) ...................................... 170
Table 46 Summary of Results of a Phase ..................................................................................... 175
Table 47 Summary of Transfer Types ........................................................................................... 176
Table 48 Summary of Peripheral Calibration Result .................................................................... 189
Table 49 Index to Phase Flowcharts ............................................................................................. 189
Table 50 Summary of Peripheral Responses (Generic to All Phases) .......................................... 202
Table 51 Summary of Peripheral Responses (ReadSetup & ReadData Phases) ........................... 203
Table 52 Summary of Peripheral Responses (Write Phase) ......................................................... 204
Table 53 Summary of Peripheral Responses (Commit) ............................................................... 204
Table 54 Summary of Peripheral Responses (CalibratePhy Phase) ............................................. 205
Table 55 Summary of Manager Responses in Read Transfers ..................................................... 207
Table 56 Summary of Manager Responses in Commit Transfers ................................................ 207
Table 57 CRC Calculation Example ............................................................................................. 224
Table 58 Treatment of Command Transport Protocol Errors in Peripheral .................................. 233
Table 59 Treatment of Command Transport Protocol Errors in Manager .................................... 234
Table 60 Command Transport Protocol Phase Header (All Phases) ............................................ 236
Table 61 Index to Phase Definition Tables ................................................................................... 237
Table 62 Device Selection in Phase Headers................................................................................ 238
Table 63 Assignment of Robust Token Numbers (Manager) ....................................................... 240

xvi Copyright © 2019–2024 MIPI Alliance, Inc.

Table 64 Assignment of Robust Token Numbers (Peripheral) ..................................................... 241

Table 65 Size of Protocol Spacer .................................................................................................. 242
Table 66 Group Mask in SSPA, SSCR, and DSCR Commands ................................................... 242
Table 67 Sync Point Delay in SSPA, SSCR, and DSCR Commands ........................................... 243
Table 68 GetStatus Phase for Ping Command .............................................................................. 244
Table 69 Announce Phase for SSPA Command............................................................................ 245
Table 70 Announce Phase for ExitDormant Command ................................................................ 245
Table 71 Commit Phase for SSCR and DSCR Commands .......................................................... 246
Table 72 Write Phase for WriteA32 Command ............................................................................ 248
Table 73 Write Phase for Unblock Command .............................................................................. 249
Table 74 ReadSetup Phase for ReadA32 Command .................................................................... 250
Table 75 ReadData Phase for Completing a ReadA32 Command ............................................... 251
Table 76 CalibratePhy Phase for InitCal and TrimCal Commands .............................................. 253
Table 77 Peripheral Responses When Command Execution State is Blocked ............................. 255
Table 78 Peripheral Responses Common to All Phases When Command Execution State is not
Blocked ......................................................................................................................................... 256
Table 79 Phase- and Command-Specific Responses When Commands are Not Blocked ........... 258
Table 80 Peripheral Responses Specific to a Write Phase (Unblock Command) ......................... 258
Table 81 Peripheral Responses Specific to a Write Phase (WriteA32 Command) ....................... 259
Table 82 Peripheral Responses Specific to ReadSetup Phase ...................................................... 260
Table 83 Peripheral Responses Specific to ReadData Phase ........................................................ 261
Table 84 Peripheral Responses Specific to Commit Phase .......................................................... 262
Table 85 Peripheral Responses Specific to CalibratePhy Phase ................................................... 262
Table 86 Peripheral Calibration Result to CalibratePhy Phase .................................................... 263
Table 87 Peripheral Responses to GetStatus Phase ...................................................................... 263
Table 88 Manager Response in ReadSetup Phase ........................................................................ 265
Table 89 Manager Response in ReadData Phase.......................................................................... 266
Table 90 Manager Response in Commit Phase ............................................................................ 267
Table 91 Summary of Commands ................................................................................................ 270
Table 92 DRAFT: Command Info Bytes for SSCR & DSCR Commands ................................... 285
Table 93 Calibration Opcodes ...................................................................................................... 288
Table 94 Summary of Command Execution States ...................................................................... 294
Table 95 Opcodes for Commands ................................................................................................ 295

Copyright © 2019–2024 MIPI Alliance, Inc. xvii

Table 96 Summary of Remote Access States ............................................................................... 296

Table 97 Remote Access State Transitions ................................................................................... 297
Table 98 Local & Remote Writes ................................................................................................. 299
Table 99 WriteA32 Command Errors ........................................................................................... 300
Table 100 WriteA32 Command Behavior .................................................................................... 301
Table 101 Local & Remote Reads ................................................................................................ 303
Table 102 ReadA32 Command Errors.......................................................................................... 304
Table 103 ReadA32 Command Behavior ..................................................................................... 305
Table 104 ###TODO: ReadA32 Command Behavior for ReadData Phases ................................ 306
Table 105 SSPA Command Errors ................................................................................................ 306
Table 106 ExitDormant Command Errors .................................................................................... 308
Table 107 SSCR / DSCR Command Errors ................................................................................. 309
Table 108 Ping Command Errors ................................................................................................. 310
Table 109 Peripheral Status Information in Ping Command ........................................................ 310
Table 110 Unblock Command Errors ........................................................................................... 312
Table 111 InitCal & TrimCal Command Errors ........................................................................... 313
Table 112 Combinations of Clock Config and Transport Pattern for PHY1 (FBCSE) ................ 355
Table 113 Combinations of Clock Config and Transport Pattern for PHY2 (FBCSE) ................ 356
Table 114 PHY1 & PHY2 (FBCSE): Timing Parameters for Peripheral Link Control ............... 357
Table 115 FBCSE PHY: Timing Parameters for Manager Link Control ...................................... 359
Table 116 [PHY1 & PHY2] Supply Voltage for PHY1 / PHY2 Interface ................................... 360
Table 117 [PHY1 & PHY2] Input and Output Voltage Parameters .............................................. 360
Table 118 [PHY1 & PHY2] Output Impedance ........................................................................... 361
Table 119 [PHY1 & PHY2] Bus Keeper Behavior ...................................................................... 361
Table 120 [PHY1 & PHY2] Clock ............................................................................................... 363
Table 121 PHY1&2: Jitter Parameters ......................................................................................... 363
Table 122 Recommended System Parameters [PHY1 & PHY2] ................................................. 364
Table 123 PHY1 & PHY2 (FBCSE): NRZS Encoding for CDS ................................................. 365
Table 124 PHY1 & PHY2 (FBCSE): NRZS Decoding for CDS ................................................. 365
Table 125 Combinations of Clock Config and Transport Pattern for PHY3 (DLV)..................... 381
Table 126 DLV PHY: Timing Parameters for Peripheral Link Control ........................................ 382
Table 127 ###TODO PHY3 (DLV): Unit Interval Rate Range .................................................... 383
Table 128 PHY3 (DLV): Timing Parameters for Manager Link Control ..................................... 385

xviii Copyright © 2019–2024 MIPI Alliance, Inc.

Table 129 [PHY3] Single-Ended Output Swing........................................................................... 386

Table 130 [PHY3] Output Voltage Levels .................................................................................... 386
Table 131 [PHY3] Output Impedance .......................................................................................... 387
Table 132 [PHY3] Receiver Parameters ....................................................................................... 387
Table 133 [PHY3] (DLV) Bus Keeper Behavior .......................................................................... 388
Table 134 PHY3 (DLV): Voltage Ramp Time .............................................................................. 390
Table 135 PHY3: Voltage Ramp Time ......................................................................................... 391
Table 136 PHY3: Jitter Parameters .............................................................................................. 391
Table 137 Recommended System Parameters [PHY3] ................................................................ 393
Table 138 Data Port Transport Layer Behavior ............................................................................ 406
Table 139 DRAFT: Data Port Prepare-Ready Behavior ............................................................... 407
Table 140 DRAFT: Data Port External Payload Interface Behavior (NORMAL SEQUENCE) . 410
Table 141 #Draft Transport Parameters ........................................................................................ 430
Table 142 Effect of DPn_FlowMode when DPn_PortMode is Normal ....................................... 436
Table 143 Effect of DPn_PortMode ............................................................................................. 437
Table 144 Effect of DPn_FlowMode when PortMode is a Test Mode ......................................... 437
Table 145 Peripheral Address Map for SWI3S Registers ............................................................. 439
Table 146 Peripheral Top-Level Address Map ............................................................................. 444
Table 147 Peripheral Address Map Blocks for SWI3S Registers ................................................. 445
Table 148 Peripheral Register Map for Data Port (DPn_*) .......................................................... 447
Table 149 Peripheral Register Map for Data Port Dual-ranked Registers (DPn_*_NEXT) ........ 449
Table 150 Peripheral Data Port Register Fields (DPn_*) ............................................................. 451
Table 151 Peripheral Register Map for System and Link Control (SLC_*) ................................ 463
Table 152 Peripheral Register Map for System and Link Control Dual-Ranked Registers
(SLC_*_NEXT) ........................................................................................................................... 466
Table 153 System and Link Control Register Fields (SLC_*) ..................................................... 467
Table 154 Peripheral Register Map for Control Data Stream Registers (CDS_*) ....................... 475
Table 155 Peripheral Register Map for Control Data Stream Dual-Ranked Registers
(CDS_*_NEXT) ........................................................................................................................... 475
Table 156 Control Data Stream Transport Register Fields (CDS_*) ........................................... 476
Table 157 Peripheral Register Map for PHY1 & PHY2 Registers (PHY1_*, PHY2_*) ............. 479
Table 158 Peripheral Register Map for PHY1 and PHY2 Dual-Ranked Registers
(PHY1_*_NEXT, PHY2_*_NEXT) ............................................................................................ 480
Table 159 Peripheral PHY1 or PHY2 (FBCSE) Register Fields (PHY1_*, PHY2_*) ................ 481

Copyright © 2019–2024 MIPI Alliance, Inc. xix

Table 160 Peripheral Register Map for PHY3 (PHY3_*) ............................................................ 482
Table 161 Peripheral Register Map for PHY3 Dual-Ranked Registers (PHY3_*_NEXT) ......... 483
Table 162 Peripheral PHY3 (DLV) Register Fields (PHY3_*) .................................................... 484
Table 163 Summary of Error Counters......................................................................................... 489
Table 164 Summary of Data Port Error Counters ........................................................................ 491
Table 165 Summary of Data Port Event Counters ....................................................................... 492
Table 166 Index of Device Rule Unique IDs ............................................................................... 496

xx Copyright © 2019–2024 MIPI Alliance, Inc.

Release History

Date Version Description

YYYY-MM-DD Target Version: No Board Adopted release yet.

1.0

Copyright © 2019–2024 MIPI Alliance, Inc. xxi

Development History

Date Version Description

2019 v0.1 – v0.2 r04 Private releases of draft sections to technical owners.

2019-03-18 v0.3 r01 First draft release for AudioWG.

Draft release for AudioWG interim FTF in Haifa incorporating

complete rework of Section 9, Control Data Stream and Section
2019-05-10 v0.3 r02 10, Command Protocol Layer.
(Areas with known unknowns have magenta colored tags of
“Question for AudioWG” and “Question for Haifa”.

2019-06-13 v0.4 r01 Draft release for WG review of Section 5 (Row Structure).

Intermediate release to technical owner for checking parts of

2019-06-14 v0.4 r02
Section 9.

2019-07-05 v0.4 r03 Draft release for WG review of Section 9 (Control Data Stream).

2019-08-27 v0.4 r04 Temporary private release for checking.

Draft release for WG review of:

2019-09-03 v0.4 r05 • Section 10 (Command Transport Protocol)
• Section 11 (Commands).

Draft release for discussions in Taipei FTF meeting.

2019-10-15 v0.4 r06
• Section 8 (Link Control and Reset)

2020-01-20 v0.4 r07 (Private release for checking)

Draft release for discussions in Mountain View FTF meeting.

2020-01-23 v0.4 r08
• Section 8 (Link Control and Reset)

2020-04-06 v0.4 r09 (Private release for checking)

2020-08-24 v0.4 r10 (Private release for checking)

2020-08-31 v0.4 r11 (Private release for checking)

2020-09-07 v0.4 r12 (Private release for checking)

2020-09-14 v0.4 r13 (Private release for checking)

2020-09-21 v0.4 r14 (Private release for checking)

2020-10-05 v0.4 r15 (Private release for checking)

xxii Copyright © 2019–2024 MIPI Alliance, Inc.

Draft release for review by AudioWG in VMM, part 1.

Topics to be reviewed in this release are:
• Section 8, Link Control and Reset: complete overhaul of
state machines and added waveforms and draft normative
rules.
• Section 7, Link Control PHY: separated out the electrical
signaling from the logical behavior in Section 8.
• Section 5, Rows and Columns: new Command-Only
waveforms in Section 5.1.8 to support DLV start-up.
• Section 2, Terminology: Clarified some terminology for
2020-10-06 v0.4 r16 PHUIs, BitSlots, Row Config vs. Row Structure, etc.
(See finer detail list in Section 1.3.3).

Note:
some old and obsolete material was archived to sections at
the end of the document ready for deletion in future drafts
including:
• Peripheral Link State sequences from old Section 8.1.10.
• Brief notes about SE-PHY from old Section 7.

2021-01-21 v0.4 r17 (Private release to interim WG chair for checking)

2021-03-09 v0.4 r18 (Private release to interim WG chair for checking)

First Review draft for updated Section 4, Technical Overview.

2021-03-23 v0.4r19 Updated terminology to “Manager” / ”Peripheral” throughout

document.
• Some Figures have not yet been edited to show this
change.

2021-03-29 v0.4r20 (Private release to WG chair for checking)

2021-03-30 v0.4r21 Second Review draft for updated Section 4, Technical Overview.

2021-05-03 v0.4r22 (Private release to WG chair for checking)

2021-05-18 v0.4r23 (Private release to WG chair for checking)

Draft release for review by AudioWG.

2021-05-20 v0.4r24 Topics to be reviewed in this release are:
• Section 4, Technical Overview

2021-11-02 v0.4 r25 (Private release to WG chair for checking)

2021-11-07 v0.4 r26 (Private release to WG chair for checking)

Review draft for:

2021-11-08 v0.4 r27 • Section 4, Technical Overview (Informative).
• Section 10, Transport Pattern (Rows & Columns.

2022-01-14 v0.4 r28 (Private release to WG chair for checking)

Copyright © 2019–2024 MIPI Alliance, Inc. xxiii

2022-03-19 V0.4 r29 (Private release to WG chair for checking)

NOTE: Temporarily moved the 3 Control/Command chapters

nearer to the beginning of the document for the convenience of
reviewers.
2022-03-21 V0.4 r30 Review draft for:
• Section 7, Control Data Stream
• Section 8, Command Transport Protocol
• Section 9, Commands

Sections 7, 8, and 9: Clarifications & corrections from initial

review.
2022-04-07 v0.4 r31
Section 8, Command Transport Protocol:
• Improvements to flowcharts.

2022-05-31 v0.4 r32 Private release to WG chair for creating FTF agenda.

2022-06-07 v0.4 r33 Review draft for Munich FTF.

2022-09-09 v0.4 r34 Review draft for Munich FTF.

2022-10-11 v0.4 r35 Interim release for checking.

2022-10-13 v0.4 r36 Review draft for Vancouver FTF.

2023-01-10 v0.4 r37 Private release to WG chair for checking.

2023-01-11 v0.4 r38 Private release to WG chair for checking.

2023-01-12 v0.4 r39 Review draft for Milan interim FTF meeting.

2023-02-07 v0.4 r40 Interim Release for checking Data Port controls

2023-02-27 v0.4 r41 Private release to WG chair for checking.

2023-02-28 v0.4 r41a Private release to WG chair for checking.

2023-03-02 v0.4 r41b Private release to WG chair for checking.

2023-03-02 v0.4 r42 Review draft for Lisbon FTF meeting.

2023-03-23 v0.4 r43 Private release to WG Member for sourcing content.

2023-03-30 v0.4 r44 Private release to WG Chair for checking content.

2023-04-21 v0.4 r45 Draft for Cupertino meeting.

Interim release.
2023-06-04 v0.5 r01 Includes first draft material for Data Port pseudcode and PDF
insert of first draft material for PHY Tables

xxiv Copyright © 2019–2024 MIPI Alliance, Inc.

Draft for San Jose Meeting.

2023-06-22 v0.5 r02
PDF insert of first draft material for PHY Tables was also updated.

2023-09-05 v0.5 r03 Interim Draft to publish updated Register Chapter.

2023-09-08 v0.5 r04 Draft for Dresden interim FTF meeting.

2023-10-09 v0.5 r05 Draft for Osaka FTF meeting.

2023-10-22 v0.5 r06 Draft following Osaka FTF meeting.

2023-11-26 v0.5 r07 Draft for Columbia FTF meeting.

2023-12-01 v0.5 r08 Draft following Columbia FTF meeting.

2024-02-26 v0.5 r09 Draft for Vienna FTF meeting.

2024-04-15 v0.5r10 Interim draft for checking wording of some new rules

2024-05-07 v0.5r11 Draft for PDF review

2024-05-28 v0.5r12 Draft for San Diego FTF meeting.

2024-08-02 v0.5r13 Interim draft to support work on PHY material

2024-09-04 v0.5r14 Draft for Taipei FTF meeting.

2024-09-21 v0.6 r01 Draft following Taipei FTF meeting

Copyright © 2019–2024 MIPI Alliance, Inc. xxv

1 Introduction
1 This Specification defines the SoundWire I3S (SWI3S) interface, which is used for transporting audio
2 streams and control information together on a single link.
3 A SWI3S Manager communicates in half-duplex fashion with one or more SWI3S Peripherals, using one of
4 several physical interfaces (PHYs) defined within this Specification (including both single-ended and
5 differential signaling options) to match a wide range of physical system constraints such as EMC and bus
6 diameter. The Manager uses PHY-specific signaling to transmit timing information to the Peripheral both
7 for data recovery and to facilitate accurate audio sampling events, either as a directly forwarded bit clock or
8 as a periodic sync signal from which the Peripheral recovers a bit clock. The Specification was developed
9 with a layered approach, which facilitates designs having common blocks that can operate with any of the
10 defined PHYs.
11 The SWI3S interface addresses a wide range of system scenarios where up to 12 Peripheral interfaces share
12 the common bus, and where those Peripherals contain from 0 to 32 audio Data Ports, each with 1 to 16
13 channels.

1.1 Scope
14 This Specification describes the SWI3S interface at several layers of abstraction, from the timing and
15 electrical characteristics of the physical layer, through clock recovery and synchronization to transport of
16 both control and payload information. It includes a command protocol for conveying control and status
17 operations to typical audio devices and content and function of registers within those devices.
18 It does not define the application-level meaning of the payload data conveyed over the interface, such as
19 the mapping between PCM audio channel data values and analogue audio signals. It does not define control
20 and status registers that relate to the application-level behavior of the audio functions of a device.
21 SoundWire Device Class for AudioSM, [MIPI02], is a specification that describes application-level controls.

1.2 Purpose
22 This Specification provides a technical definition of the SWI3S interface to address the needs of the
23 following:
24 • Component design and verification engineers implementing SWI3S Manager and Peripheral
25 devices.
26 • System-level hardware and software engineers designing equipment in which components
27 communicate via SWI3S interfaces.
28 • Test engineers working on components or systems with SWI3S interfaces.

Copyright © 2019–2024 MIPI Alliance, Inc. 1

1.3 Relationship to Other MIPI Specifications

29 SWI3S is a transport interface that provides a set of features that is similar (at the application layer) to that
30 of the SoundWire specification, [MIPI01]. SWI3S and SoundWire could be combined in a system by
31 implementing a bridge device that contained a Peripheral interface on one type of link connected to a
32 Manager interface on the other.
33 SWI3S improves upon SoundWire in a number of areas, including:
34 • Higher bandwidth capability for a similar size of link because of:
35 • Control Data Stream not using any direct Peripheral to Peripheral communication.
36 • Greater flexibility of bandwidth allocation to handover between successive transmitters and to
37 Peripheral-to-Peripheral audio streams (e.g., Wide Bits).
38 • An optional DLV PHY layer using differential low-voltage signaling to support longer links and to
39 provide improved EMI/EMC performance that is critical to some system designs, such as those
40 with microphones adjacent to RF antennas.
41 • Command Protocol that provides a higher data transfer rate.
42 • Detailed support for standby and wakeup.
43 SWI3S does not define the application-level behavior of audio components. The SoundWire Device Class
44 for Audio specification, [MIPI02], is a specification that describes mechanisms that can be used to control
45 the application-level behavior of components for some common audio functions.
46 This Specification describes detailed Peripheral and basic Manager behavior. More sophisticated Manager
47 behavior will be included in a future revision of this Specification.

2 Copyright © 2019–2024 MIPI Alliance, Inc.

2 Terminology

2.1 Use of Special Terms

48 The MIPI Alliance has adopted Section 13.1 of the IEEE Standards Style Manual, which dictates use of the
49 words “shall”, “should”, “may”, and “can” in the development of documentation, as follows:
50 The word shall is used to indicate mandatory requirements strictly to be followed in order
51 to conform to the Specification and from which no deviation is permitted (shall equals is
52 required to).
53 The use of the word must is deprecated and shall not be used when stating mandatory
54 requirements; must is used only to describe unavoidable situations.
55 The use of the word will is deprecated and shall not be used when stating mandatory
56 requirements; will is only used in statements of fact.
57 The word should is used to indicate that among several possibilities one is recommended
58 as particularly suitable, without mentioning or excluding others; or that a certain course
59 of action is preferred but not necessarily required; or that (in the negative form) a certain
60 course of action is deprecated but not prohibited (should equals is recommended that).
61 The word may is used to indicate a course of action permissible within the limits of the
62 Specification (may equals is permitted to).
63 The word can is used for statements of possibility and capability, whether material,
64 physical, or causal (can equals is able to).
65 All sections are normative, unless they are explicitly indicated to be informative.

2.2 Definitions
66 AdjBitRampType: A register bit controling whether the PHY uses a Conductance Ramp (G-Ramp) or
67 Voltage Ramp (V-Ramp) to produce the signal level on the bus for an adjacent bit in a sequence (i.e., when
68 this Device was producing the signal level for the previous bit).
69 Attach: The action of a Peripheral synchronizing to the Control Data Stream and becoming capable of
70 responding to Commands (Attached).
71 Audio-mode PHY: Any of the one or more PHYs used to transfer audio payload, as distinct from the Link
72 Control PHY.
73 Bit: The data value of 0 or 1 (representing payload data, command data, or sync) conveyed in one or more
74 UIs.
75 Bit Clock: A notional internal clock signal with one cycle per Unit Interval. It has a frequency equal to the
76 current Row Rate multiplied by the current Column Count, i.e., 2 × the DDR bit clock transmitted on the
77 bus with some of the Audio-mode PHYs.
78 Bit Rate: The frequency of the Bit Clock; the highest bit rate available to transport information on the Link
79 (equal to the Row Rate * the Column Count).
80 Bus Reset: A signaling sequence that is used to reset all Peripheral devices on the bus.
81 Clock Config: The combination of Row Rate and Column count, e.g., {3.072 MRows/s x 16 Columns}.
82 Cold Reset: The more severe of the 2 resets within SWI3S, which puts Devices into Cold_Standby.
83 ###TODO-Author: clean up this phrasing.
84 Cold_Standby: a Peripheral Link State in which most register state and internal state are lost, targeted at
85 lower power consumption than the Sleeping Link State.
86 Column: The set of UIs with the same Column Number in each successive Row.

Copyright © 2019–2024 MIPI Alliance, Inc. 3

87 Column Count: The number of UIs within a Row.

88 Column Number: An integer, ranging from 0 to (Column Count – 1) representing the position of a UI
89 within a Row.
90 Command: The data that is transported as the payload of a Transfer and that describes an action to be
91 performed in the Peripheral.
92 Command-Only: A Transport Pattern in which the only data transport is the Control Data Stream.
93 Commit Synchronization Point: a special case of a Row Sync Point when the Commit operation that
94 copies Next Value Registers to Current Value Registers takes effect. ###TODO-Author replace existing
95 Commit Event and Commit Point with Commit Synchronization Point.
96 Conductance Ramp (G-Ramp): A change in signal on the bus caused by the PHY controling the change
97 in output conductance that is fed from a nominally constant output voltage.
98 *_CURR: Notation used to name a field in a Current Value Register.
99 Current Value Register: the part of a Dual-Ranked Register that contains the value that controls current
100 operation.
101 Detach: The action of a Peripheral when it changes from Attached to not Attached (Detached).
102 Device Mask: A 12-bit mask in a Command Header that identifies which Peripheral Device Number(s) are
103 addressed by a Command.
104 1-hot Device Mask: A Device Mask that must have exactly 1 bit set to 1, because the Command can target
105 only 1 Peripheral.
106 Device Number: The number (0–11) in a Peripheral that is used to address it with a Command.
107 DN: The second of two SWI3S signal pins (“data negative”).
108 DP: The first of the two SWI3S signal pins (“data positive”).
109 (Note: ‘DP’ is also an acronym for Data Port).
110 Dual-Ranked Register: a pair of a Next Value Register and a Current Value Register that facilitates
111 updating multiple Current Value Registers simultaneously.
112 External: Circuitry, logic, I/Os, etc. outside the SWI3S-defined behavior.
113 FirstBitRampType: A register bit controling whether the PHY uses a Conductance Ramp (G-Ramp) or
114 Voltage Ramp (V-Ramp) to produce the signal level on the bus for the first bit in a sequence (i.e., when this
115 Device was not producing the signal level for the previous bit).
116 G-Ramp: see Conductance Ramp.
117 Gnd: the ground connection on devices, sometimes referred to as Vss.
118 Guard Bit: A bit driven to a statically defined value by a Device Tx to minimize data-dependent crosstalk.
119 Hamming Distance: The number of bits that are different when comparing the bit patterns of two symbols.
120 HandOver: A time period allocated for the change between the bus being driven by one component and
121 being driven by another.
122 HD10 Robust Token: One of a defined set of 2 Robust Tokens that are separated by the maximum possible
123 Hamming Distance (i.e., 10).
124 Implementation-defined: Behavior or values that are defined by the designer of an implementation, not by
125 this Specification.
126 LC:0: a logic 0 value in the Link Control signaling.
127 LC:1: a logic 1 value in the Link Control signaling.
128 LC:weak0: a weakly driven logic 0 value in the Link Control signaling.
129 Link: The combination of Manager interface and Peripheral interface(s) connected by a physical medium.

4 Copyright © 2019–2024 MIPI Alliance, Inc.

130 Link Control PHY: The PHY used to send and receive Link Control signaling (i.e., bus reset, standby and
131 sleep/wake), as distinct from an Audio-mode PHY.
132 Link State: A state that summarizes a high-level view of how a Manager or Peripheral interacts with the
133 Link, with names highlighted thus: StateName.
134 Local: A register or address that is within or close enough to the SWI3S interface that it can be accessed
135 within the time available within 1 Phase.
136 Lock-N: [For some PHYs:] A Transport Pattern that is Command-Only and has N Columns.
137 *_NEXT: Notation used to name a field in a Next Value Register.
138 Next Value Register: the part of a Dual-Ranked Register that contains the new value that will be copied to
139 the corresponding Current Value Register by a Commit operation.
140 No_Response: A set of 10 bits in the Command Protocol Layer that is assigned to a Peripheral, but is then
141 not driven by that Peripheral.
142 Nom / Nominal: Nominal values of electrical and timing parameters are within normal manufacturing
143 tolerances of the expected value, but do not impose any normative requirement (unlike Min and Max).
144 Payload Data: Any data transported on the Link that is part of a stream from a Data Port.
145 Phase: An indivisible unit within the Command Transport Protocol that cannot be interrupted by an Idle
146 Pattern in the Control Data Stream.
147 PHY: Physical layer interface.
148 PHY Idle: A PHY-specific condition at a Peripheral input that indicates that the Manager has parked the
149 bus ready for changing which PHY is in use.
150 PHY_Inactivity: A PHY-specific condition at a Peripheral input that indicates that the Manager has
151 stopped generating Rows using the current Audio-mode PHY.
152 Remote: A register or address that is outside the SWI3S interface and that is not guaranteed to be accessed
153 within the time available within 1 Phase.
154 Robust Token: One of a defined set of 18 8b/10b D-code values used by the Command Protocol Layer.
155 Row: The sequence of UIs from one Row Sync Point to the next.
156 Row Rate: The number of Rows per second.
157 Row Sync Point: The reference point in time at the start of the first UI (Column 0) in a Row.
158 Row Sync Sequence: [For some PHYs:] the sequence of Sync0 and Sync1 Bits that identifies the Row
159 Sync Point.
160 Safe Speed: Bus operation at a Bit Rate that is guaranteed to operate correctly using the reset values of the
161 PHY control parameters in the Peripheral, and without needing Peripheral PHY timing calibration to have
162 been completed. This speed is a function of the choice of PHY. For the DLV PHY it is 9.6 – 12.8 Mbps.
163 Safe-Lock-4: [For some PHYs:] A combination of Clock Config and Command-Only Transport Pattern
164 that provides bus operation at a Safe Speed with 4 Columns and special Peripheral PHY drive behavior.
165 Sample Period: The time between 2 Payload Sampling Events (typically audio signals).
166 Sleeping: a Peripheral Link State in which most register values and internal state are retained, targeted at
167 faster link start-up than from the Cold_Standby Link State.
168 Standby: A generic term for the Link-Inactive states (in a Manager: Standby, in a Peripheral: either
169 Cold_Standby or Sleeping).
170 Stream Synchronization Point (SSP): a special case of a Row Sync Point when the Sampling Events in a
171 set of streams occur simultaneously, and the Transport Pattern for all of the associated Data Ports starts its
172 periodic repeat.
173 Sub-Row Interval: .###TODO-Author

Copyright © 2019–2024 MIPI Alliance, Inc. 5

174 Sync0: [For some PHYs:] One or more UIs containing a Bit value of 0 that is part of the Row Sync
175 Sequence.
176 Sync1: [For some PHYs:] One or more UIs containing a Bit value of 1 that is part of the Row Sync
177 Sequence.
178 Transfer: A transport operation (comprising one or more Phases) provided by the Command Transport
179 Protocol to convey a Command.
180 Transport Interval: The set of adjacent Rows (or, for Sub-Row Intervals, the set of adjacent UIs) during
181 which a Data Port might transport 1 group of (1 or more) Samples.
182 Transport Pattern: The assignment of UIs on the Link to transport information within a sequence of one
183 or more Rows that forms a periodically repeating pattern.
184 Transport Period: The duration of a Transport Interval in units of time. ###TODO-Author: delete if not
185 needed.
186 Typ / Typical: Typical values of electrical and timing parameters are an illustrative target value, and do not
187 impose any normative requirement (unlike Min and Max).
188 Unit Interval (UI): The smallest opportunity to transport a bit of information on the Link, with a period
189 equal to 1 cycle of the Bit Clock (i.e., a half cycle of the DDR bit clock transmitted on the bus with some of
190 the Audio-mode PHYs), corresponding to one Column within one Row.
191 Voltage Ramp (V-Ramp): A change in signal on the bus cause by the PHY controling the change in
192 effective output voltage being fed through a nominally constant output conductance.
193 Warm Reset: The weaker of the 2 severities of reset within SWI3S, associated with a device detaching
194 from the bus.
195 Wide Bit: A set of 2, 3, or more consecutive UIs used to transport one Bit of data.

2.3 Abbreviations
196 e.g. For example (Latin: exempli gratia)
197 i.e. That is (Latin: id est)
198 kHz kilohertz
199 Mbps megabits per second
200 MHz megahertz
201 MRow/s million Rows per second
202 ns nanoseconds
203 wrt with respect to

2.4 Acronyms
204 CDS Control Data Stream
205 CSP Commit Synchronization Point ###TODO-author: check if this acronym is used anywhere.
206 CVR Current Value Register
207 DLL Delay-locked loop
208 DLV Differential Low-Voltage
209 DP Data Port
210 DSCR Device-Synchronous Commit Request (Command)

6 Copyright © 2019–2024 MIPI Alliance, Inc.

211 EMC Electromagnetic Compatibility

212 EMI Electromagnetic Interference
213 FBCSE Forwarded-Bit-Clock Single-Ended
214 FCP Flow Control Port
215 HD10 Hamming Distance of 10 (see HD10 Robust Token in Section 2.2)
216 HO HandOver UI
217 ISI Inter-Symbol Interference
218 LC Link Control
219 LC_PHY Link Control PHY
220 LC_Rx Link Control PHY receiver
221 LC_Tx Link Control PHY transmitter
222 LSB Least Significant Byte (or less significant bytes)
223 LSb Least Significant Bit (or less significant bits)
224 ML_SM Manager Link State Machine
225 MSB Most Significant Byte (or more significant bytes)
226 MSb Most Significant Bit (or more significant bits)
227 NVR Next Value Register
228 NRZS Non-Return-to-Zero – Space
229 PBR_SM Peripheral Bus Reset state machine
230 PCM Pulse-Code Modulation
231 PDM Pulse-Density Modulation
232 PL_SM Peripheral Link State Machine
233 PLL Phase-locked loop
234 PMIC Power Management Integrated Circuit
235 PPI Phy-Protocol Interface
236 PLCR_SM Peripheral Link Control Request state machine
237 RC Resistor-Capacitor
238 RD Running Disparity
239 RF Radio Frequency
240 RO Read-only
241 RW Read-Write
242 RW1C Read-and-Write-1-to-Clear
243 S0 Sync0
244 S1 Sync1
245 SPM Start of Phase Marker

Copyright © 2019–2024 MIPI Alliance, Inc. 7

246 SSCR Stream-Synchronous Commit Request (Command)

247 SSP Stream Synchronization Point
248 SSPA Stream Synchronization Point Announcement
249 SWI3S (pronounced “swiss”) Shorthand for SoundWire I3S.
250 TCGn Transport Commit Group number n.
251 TDM Time-Domain Multiplexed
252 TP Transport Pattern
253 UI Unit Interval

2.5 Typographical Conventions

2.5.1 Defined Terms

254 Initial capitals are used for elements in the Specification that have names that might otherwise be
255 interpreted as normal words, e.g. Manager. The special meanings of such elements are all described in
256 Section 2.2.

2.5.2 References
257 Cross-references to Sections, Figures, Tables, and numbered paragraphs within this document are
258 highlighted using bold italic font, e.g., Figure 1.
259 Citations of external references described in Section 3 are identified by square parentheses, e.g., see
260 [MIPI01].

2.5.3 State Names

261 When conceptual finite state machines are used to aid explanations, the names of states are shown with a
262 colon separating the state machine name from the state name. E.g., FSM1:State1.
263 SWI3S Manager and Peripheral Link States defined in Section 5 are highlighted with purple colored text,
264 e.g., ML:Standby, PL:Attached.
265 SWI3S Peripheral Command Execution States and Peripheral Remote Access States defined in Section 9
266 are highlighted with red colored text, e.g., Blocked, Remote_Write_Busy.

2.5.4 Number Radix

267 Within this Specification, some numbers are represented in non-decimal radix where this helps
268 understanding. Where there might be ambiguity about the value of a number, the following radix notations
269 are used:
270 b101 binary representation of the decimal value 5.
271 0x2A hexadecimal representation of the decimal value 42.
272 The sizes of any fixed width bit-fields in protocol elements or registers are explicitly stated in the text; the
273 use of any particular number representation does not imply the size of the field.

8 Copyright © 2019–2024 MIPI Alliance, Inc.

3 References
274 [MIPI01] MIPI Alliance Specification for SoundWire®, version 1.2.1, MIPI Alliance, Inc., In Press.
275 [MIPI02] MIPI Alliance Specification for SoundWire Device Class for AudioSM, version 1.0, MIPI
276 Alliance, Inc., In Press.
277 [MIPI03] MIPI Alliance Specification for SoundWire-I3S Host Controller Interface (HCI), version
278 1.0, MIPI Alliance, Inc., In Press.
279 [MIPI04] MIPI Alliance, Inc., “MIPI Alliance Manufacturer ID Page”, http://mid.mipi.org, last
280 accessed 29 May 2023.

Copyright © 2019–2024 MIPI Alliance, Inc. 9

4 Technical Overview (Informative)

281 This Section (4) provides an informative overview of SWI3S and does not contain normative material.

4.1 Introduction

4.1.1 SWI3S in a System Context

282 SWI3S is an interface for audio systems that replaces combinations of various interfaces (e.g., TDM, PDM,
283 I2S, HDA, SLIMbus, SPI, I2C, and GPIOs) for audio streaming and ancillary services such as reading and
284 writing control registers, interrupts, reset, and power management (i.e., signaling sleep and wake). SWI3S
285 also delivers an audio quality clock.
286 A SWI3S Link comprises one Manager and one or more Peripherals connected by one set of signal wires
287 (with the number depending upon the choice of PHY, e.g., 2 for any of PHY3 (DLV) or PHY1 or PHY2
288 (FBCSE)). Figure 1 shows an example of a SWI3S Link with a mixture of types of Peripheral.

Peripheral Peripheral Peripheral

#1 (e.g., Mic) #2 (e.g., Amp) ... #N

Manager
289 SWI3S Link
Figure 1 An Example SWI3S Link

290 A more complex system can be partitioned across multiple SWI3S Links, e.g., to provide higher bandwidth,
291 longer physical topologies, or domains for power management, see Section 4.7.1.

4.1.1.1 System Flexibility

292 SWI3S Links can be configured to meet a wide range of system scenarios and electrical characteristics of
293 the Link:
294 • System-specific choice of Row rate and bit clock.
295 • Programming transport-level parameters relating to size and position of bits (Transport Patterns).
296 • Programming PHY-specific parameters relating to low-level timing and electrical behavior.

10 Copyright © 2019–2024 MIPI Alliance, Inc.

4.1.2 Features

4.1.2.1 Features Relating to Audio Applications

297 SWI3S features that relate to audio applications and power management include:
298 • Distribution of audio quality clock at frequencies suitable for audio sampling applications (relating
299 to commonly used cardinal frequencies, e.g., 19.2, 22.5792, 24.0, or 24.576 MHz).
300 • Link-wide synchronization (audio streams and commands).
301 • Transport of periodic payload data, typically audio sample streams to/from digital audio
302 components (see Section 4.3), with support for concurrent use of:
303 • Multiple channels (including fan-out and fan-in to/from multiple devices).
304 • PDM and PCM data encodings.
305 • Differing sample rates (e.g., 44.1 and 48 kHz).
306 • Flow-controlled transmission, including sink-controlled and source-controlled.
307 • Support for low latency transmission (e.g., ~300 ns transport delay).
308 • Embedded command channel for reading and writing control parameters, reporting status, and
309 transferring data such as firmware.
310 • In-band signaling of:
311 • Interrupt conditions from Peripherals.
312 • Wake-up requests from Peripherals.
313 • Reset.
314 • Support for low-power link states, e.g., sleep/wake and clock pause.

4.1.2.2 Summary of Other Technical Features

315 SWI3S is an interface for communication between a Manager device and one or more Peripheral devices,
316 which are typically mixed-signal audio components such as amplifiers or microphones.
317 The features of the interface are:
318 • System architectures comprised of one or more Links that each have one Manager and one or
319 more Peripherals (see Section 4.7).
320 • Choice of physical interface layers (PHYs) to address different system scenarios (see Section 4.8),
321 but sharing some common features:
322 • Timing information from the Manager enabling the Peripheral both to send and receive data
323 bits and to generate audio sampling events.
324 • One shared data connection using half-duplex signaling with handovers scheduled at bit
325 granularity.
326 • Row-based structure of the bitstream to enable allocation of link bandwidth between different
327 functions (see Section 4.2).
328 • A control channel using a command protocol to convey commands from the Manager to the
329 Peripheral(s) that:
330 • Write control information to Peripheral registers and read status information from them (see
331 Section 4.4).
332 • Collects Peripheral status including interrupts.
333 • Link Control, Synchronization and power states (see Section 4.5).

Copyright © 2019–2024 MIPI Alliance, Inc. 11

4.1.3 SWI3S Layering

334 This Specification partitions the description of some of the behavior into layers. This conceptual layering is
335 used to help in clarifying the description, and to facilitate the possibility of future versions of the
336 Specification changing behavior of some layers independently of others, and particularly the PHY (see
337 Section 4.1.5).
338 Note:
339 These layers are conceptual: this Specification does not mandate the internal structure of
340 implementations, and these implementations might not have boundaries between internal blocks
341 that correlate with the boundaries between the layers described in this Specification.
342 Figure 2 illustrates the conceptual layers in a SWI3S device.

Payload stack
(ADCs and DACs use this)
PCM, PDM,
2s complement,
Command stack Data Formats 1s complement,
sign and magnitude,
(Control, status and interrupts use this)

Audio Clocks
etc.

SWI3S Registers Sample Streams

Peripheral Command
Non-SWI3S Registers (local) Payload Model Channels
Model for Registers Non-SWI3S Registers (remote) SSP indications

Ping, Unblock, SSPA, ExitDormant

ReadA32, WriteA32
Commands Stream-Synchronous Commit Request (SSCR) Data Port DP Register Values
Device Synchronous Commit Request (DSCR)
InitCal, TrimCal
Byte Clock

Transfers
Command Transport Phases Interval
Protocol Elements of Phases Samples
Bytes
Row & Bit Clocks

Sample Grouping
Payload Transport
Channel Grouping
Protocol
Bit Owner

8b/10b Encoding (K-Codes & D-Codes) HStart, HCount,

Control Data Stream 30-bit PHY Calibration Blocks Offset,
Undriven Bits Scrambling, ...
Bits & Symbols
Idle Bits

BitClock, RowSync, DataIn, DataOut, DataOutEnable,

PHY Interface: PHY Encoding/Decoding
BitWidth, Guard Bits, Tail Bits.

PHY Transceiver Impedance, Signaling Levels, Signal Timing.

343
Figure 2 SWI3S Layers

344 The left side of the figure shows the layers in the Command stack, which represents how a SWI3S interface
345 connects to the control and status behavior of the device, including registers that control behavior of all of
346 the layers in this diagram. See Section 4.4, Control Data Stream and Commands and Section 4.9,
347 Registers.
348 The right side of the figure shows the layers in the Payload stack, which represents how a SWI3S interface
349 connects to the audio streams within a component. Each stream is associated with a Data Port, which has
350 registers that control the pattern of bits for each sample being transported on the Link. See Section 4.3,
351 Payload Transport.
352 These two uses of the link come together in the PHY and PHY interface layers, where all traffic on the link
353 is combined as a half-duplex serial bitstream with periodic structure of Rows, see Section 4.2,
354 Row and Column Structure and Section 4.8, Physical Layer – PHY.

12 Copyright © 2019–2024 MIPI Alliance, Inc.

4.1.4 Audio Payload Streams

355 A SWI3S Link provides transport capability that can be shared between concurrent audio streams that use
356 different sample rates and data formats (e.g., both PCM and PDM).
357 The audio streams on a SWI3S link can be a mixture of data flowing from any of:
358 • Manager to Peripheral.
359 • Peripheral to Manager.
360 • Peripheral to Peripheral.

4.1.4.1 Audio Sample Clocks

361 The audio sample clock is derived from the link in a PHY-specific manner:
362 • For the DLV PHY, the Manager transmits a Row Sync sequence with defined rising edges that
363 have audio quality clock properties (jitter etc.) so that these edges can be forwarded within the
364 Peripheral Device for use as a sample clock.
365 • For the FBCSE PHY the forwarded bit clock from the Manager is good enough for rising edges to
366 be used as a sample clock.

Copyright © 2019–2024 MIPI Alliance, Inc. 13

4.1.5 PHYs
367 The lowest layers shown in Figure 2 are the PHY interface and PHY transceiver, which communicates
368 electrical signals to and from the physical medium of the link (PCB trace, flex cables etc.).

4.1.5.1 Flexibility of Bandwidth Allocation

369 The PHY provides a parameterized interface controlled by Registers, which combines with features of the
370 higher layers to enable a SWI3S Link to use a longer bus and/or higher speed, or to manage crosstalk, e.g.,:
371 • Flexibility of allocating bandwidth to handover and to Peripheral-to-Peripheral audio streams
372 (e.g., Wide Bits, where needed).
373 • Tail bits to dampen reflections at the end of a period of driving the bus and so reduce ISI.
374 • Guard bits to minimize the impact of a datastream on the spectral content of the bus.
375 • The Control Data Stream being only Manager to/from Peripheral and not from one Peripheral to
376 another.

4.1.5.2 Audio-mode PHYs

377 The Specification separates the physical interface behavior so that the same higher-level models of
378 behavior can be provided over whichever of the PHYs defined in this Specification is appropriate for each
379 SWI3S Link in a system (matching trade-offs between speed, power, EMI, EMC, etc.). In Devices that
380 implement multiple PHYs, the Manager selects the PHY during a Cold Start sequence.
381 Figure 3 shows an example of a SWI3S Link containing a Manager and Peripheral Devices that each
382 support a different set of PHYs, with the only commonality being PHY1. In this example, the Manager
383 would select PHY1 in the Peripherals during Cold Start.

Peripheral #1 Peripheral #2 Peripheral #3

PHY PHY PHY PHY PHY PHY
#1 #2 #3 #1 #2 #1

Manager
PHY PHY SWI3S Link
#1 #2
384
Figure 3 An Example SWI3S Link that Uses 1 PHY

14 Copyright © 2019–2024 MIPI Alliance, Inc.

385 Figure 4 shows another example of a SWI3S Link, where the Manager and Peripherals all support 3
386 different PHYs. In this example, each time that the Manager issues a Cold Start sequence, it chooses which
387 of the PHYs to use to operate the Link, and this choice might vary with scenario.

Peripheral #1 Peripheral #2 Peripheral #3

PHY PHY PHY PHY PHY PHY PHY PHY PHY
#1 #2 #3 #1 #2 #3 #1 #2 #3

Manager
PHY PHY PHY SWI3S Link
#1 #2 #3
388
Figure 4 An Example SWI3S Link that can Operate with Multiple PHYs

389 The PHYs that are defined in this version of the Specification are:
390 • A differential, low-voltage (DLV) PHY for higher maximum speed, low EMI emissions, and low
391 EMC susceptibility. PHY3 is summarized in Section 4.8.3 and described in detail in Section 11.3.
392 • A forwarded-bit-clock single-ended (FBCSE) PHY for less challenging environments. This PHY
393 has 2 modes of behavior for handovers between transmitters in different Devices, which are given
394 different PHY selection numbers, PHY1 and PHY2. The FBCSE PHY is summarized in
395 Section 4.8.2 and described in detail in Section 11.

4.1.5.3 Link Control PHY

396 In addition to the Audio-mode PHY(s), every SWI3S component includes a simple low-speed interface that
397 is used for signaling bus reset and entry and exit from the Inactive Link States (Sleeping and
398 Cold_Standby) that is named the Link Control PHY or LC_PHY, and is described in Section 6.
399 Note:
400 In a component that implements Audio-mode PHY1 and / or PHY2 (forwarded-bit-clock
401 single-ended PHY), the LC_PHY behavior might be implemented by re-using some of the circuitry
402 already included for that PHY.

4.1.5.4 PHY Interface

403 Figure 2 illustrates that the relationship of higher layers to the Audio-mode PHY is via the PHY-agnostic
404 concepts of bit ownership and Row clock. The PHY-agnostic model is summarized in Section 4.8.1, and a
405 possible PHY-Protocol Interface (PPI) is described in Annex C.

Copyright © 2019–2024 MIPI Alliance, Inc. 15

4.2 Row and Column Structure

406 Row & Column Structure is described in more detail in Section 10.

4.2.1 Introduction to Rows & Columns and Related Terminology

407 A SWI3S Link transports a stream of bits which are organized using a fundamental periodic structure
408 named a Row, which provides several benefits:
409 • For the audio application level: Sample clocks can easily be produced from the clock edges that
410 are aligned to Row boundaries.
411 • For the transport level: The Rows facilitate simple (i.e., using only a small number of control
412 register bits) allocation of link bandwidth between different functions.
413 • For system control: Command actions can be synchronized to Row boundaries.
414 • For some PHYs (e.g., PHY3, DLV): Signaling at the start of Rows is used as a timing reference to
415 regenerate a bit clock.
416 The Row Rate in a given system is commonly chosen from one of several values that relate to families of
417 frequencies used in audio applications, e.g., 3.072 MHz, so that typical audio sampling rates can be
418 produced from the Row rate.
419 The Unit Intervals (UIs) within each Row are identified by an integer, named the Column Number,
420 counting upwards from zero to Column Count −1 which forms the “horizontal” part of a two-dimensional
421 model used for controlling Payload Transport (see Section 4.3). For Payload Transport with a periodicity
422 longer than one Row, the vertical part of that payload transport model is provided by counting Rows from
423 Stream Synchronization Points (SSPs, see Section 4.2.3.1). This “horizontal” structure of Rows is similar
424 to that used in SoundWire systems, but the vertical structure within SWI3S is different from SoundWire
425 Frames (see [MIPI01]).
426 The Bit Rate is equal to the Row Rate multiplied by Column Count and corresponds to the frequency of a
427 Bit Clock. The Clock Config is the combination of Row Rate, Bit Rate, and Column Count.
428 The period of the Bit Clock is the duration of the Unit Interval (UI). The assignment of Unit Intervals to
429 transport command and payload information within a sequence of one or more Rows that forms a
430 periodically repeating pattern is named the Transport Pattern.
431 Note:
432 For some PHYs (PHY1 and PHY2) the actual clock signal transmitted on the bus is a DDR clock at
433 half of the Bit Clock frequency. This Specification does not mandate the internal implementation of
434 Peripherals, which could, e.g., use this DDR clock directly, or double it to produce a bit clock.
435 Note:
436 Additional terminology relating to the transport of audio payloads is defined in Section 4.3.1.

16 Copyright © 2019–2024 MIPI Alliance, Inc.

4.2.2 General Description of Rows

437 The Row is composed of a number of Unit Intervals (from 2 to 32, where the minimum number of UIs per
438 Row is dependent on which PHY is in use), each of which can be assigned to one of the following
439 functions:
440 • Payload data bits (typically making up audio samples).
441 • Control Data Stream bits (used to transport Commands).
442 • PHY-specific signaling symbols (e.g., Sync0 and Sync1 in PHY3, DLV).
443 • PHY-specific time periods for managing bus reflections and collisions (e.g., Tails and Handovers).
444 • Guard bits used to isolate devices from data dependent crosstalk.
445 These bits and other elements that make up the Transport Pattern are described in detail Section 10.1.5.
446 Each Row is part of the continuous bitstream with the next Row following immediately afterwards.
447 Figure 5 shows an example of a SWI3S Transport Pattern for a DLV PHY in 1 Row of 16 Columns, with
448 the end of the previous Row and start of the following Row shown greyed out.

4 Data bits 2 Wide Data bits

Row Sync Point (audio payload) (audio payload) next Row Sync Point

... 14 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 ...
... S0 S1 M-CDS
C D1a D1b D1c D1d D2a x2 D2b x2 S0 S1 MC ...

Handover Handover
Control Data Stream bit Handover
Handover to CDS Unallocated UI
DLV PHY: Sync0 DLV PHY: Sync1 DLV PHY: Sync0 DLV PHY: Sync1
(previous Row) (next Row)
449
Figure 5 Example Transport Pattern (1 Row with DLV PHY)

4.2.3 Vertical Structure and SSPs

450 The control data, and typically also the audio payload data, in a SWI3S system stretch over multiple Rows.
451 Audio payload transport is periodic, defined by a time (the Transport Interval) that is one of:
452 • An integer multiple of Rows.
453 • A fraction of a Row (Sub-Row Intervals).
454 Audio sampling behavior is periodic, with the time spacing between Sampling Events (the Sample Period)
455 being either:
456 • Rationally related to the Row Rate:
457 • 1 sample per Transport Interval, or.
458 • N samples per Transport Interval using sample grouping, or
459 • Defined by a skipping ratio (P/Q) defining which Transport Intervals do not contain a
460 sample.
461 • Flow-Controlled by Sink and/or Source control bits that indicate which Transport Intervals
462 contain valid data.
463 A given system can have multiple payload streams running concurrently, which might have different
464 Transport Intervals and Sample Periods.

Copyright © 2019–2024 MIPI Alliance, Inc. 17

465 Figure 6 shows an example of a SWI3S Transport Pattern that repeats after 4 Rows. This contains 8 PDM
466 streams where 4 × 1-bit samples from each source have been grouped together to make more efficient use
467 of the link bandwidth. In this example, payload data streams D1 through D8 all have a Sample Period of
468 1 Row and a Transport Interval of 4 Rows. More examples of Transport Patterns are shown in Section 4.3.

Row Sync Point SSPs (Stream Synchronization Points)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C D1 D1 D1 D1 D2 D2 D2 D2 S0 x2

S1 M-CDS
C D3 D3 D3 D3 D4 D4 D4 D4 S0 x2

S1 M-CDS
C D5 D5 D5 D5 D6 D6 D6 D6 S0 x2

S1 M-CDS
C D7 D7 D7 D7 D8 D8 D8 D8 S0 x2

S1 M-CDS
C D1 D1 D1 D1 D2 D2 D2 D2 S0 x2

Group of 4 Samples Group of 4 Samples

from PDM stream #1 from PDM stream #2
469
Figure 6 Example Transport Pattern: 8 PDM Streams with PHY3 (DLV)

4.2.3.1 Stream Synchronization Points (SSPs)

470 A Stream Synchronization Point (SSP) is a point in time when one or more audio payload streams
471 experience the start of a Transport Interval simultaneously. These SSPs have a scope that can be:
472 • 1 or more Data Ports in 1 Commit Group in a Device.
473 • 1 or more Commit Groups within a Device.
474 • 1 or more Devices.
475 • All Data Ports in a system.
476 For a single Data Port the SSP Interval is equal to the Transport Interval.
477 For a set of Data Ports the SSP Interval is the lowest common multiple of the Transport Intervals.
478 When using skipping ratio, the interval used for the SSP calculation is a multiple of the Transport Interval.
479 The Manager indicates an SSP by sending either of 2 Commands, both of which select the scope using a
480 Device Mask and a Commit Group Mask:
481 • SSPA Commands.
482 • SSCR Commands (see Section 4.4.4), which also commits changes in dual-ranked registers.
483 Note:
484 SSPs can occur as frequently as every Row (e.g., in a simple Link with PDM streams that are
485 identical in every Row) so there are typically many SSPs that are not explicitly indicated by a
486 corresponding SSCR Command.

4.2.3.2 Control Data Stream Alignment

487 Alignment of the symbols in the Control Data Stream is indicated by Start of Phase Markers (see
488 Section 4.4.2) and is independent of the alignment of audio payload operations, and independent of SSPs.
489 Symbols used in the Control Data Stream each occupy 10 Rows and the idle periods within the stream are a
490 multiple of 2 Rows, so the Control Data Stream remains aligned to even numbers of Rows. The SSP

18 Copyright © 2019–2024 MIPI Alliance, Inc.

491 Interval can be either an even or odd number of Rows so even when idle periods are inserted in the Control
492 Data Stream, an SSP might not align perfectly with the CDS symbols. The SSCR and SSPA Commands
493 used to indicate SSPs include a delay parameter of either 14 or 15 Rows so that they can accurately indicate
494 the position of SSPs on either odd or even numbered Row boundaries. (See also Section 9.1.13)

4.2.4 Clocking

4.2.4.1 Bit Clock for Transport

495 The Manager delivers a clock to the Peripherals that relates to transport of each bit. This is delivered in a
496 PHY-dependent manner, e.g.:
497 • A recovered bit clock when using PHY3 (DLV PHY).
498 • A forwarded bit clock when using PHY1 or PHY2 (FBCSE PHY). This forwarded bit clock is
499 DDR using both edges.

4.2.4.2 Row Sync Point

500 The Manager delivers a periodic indication of the Row Sync Point to the Peripherals, which identifies
501 where Column 0 starts. This indication is delivered in a PHY-dependent manner, e.g.:
502 • For recovered-bit-clock PHYs, such as PHY3 (DLV PHY), the transition between the Sync0 and
503 Sync1 bits in the Row Sync sequence.
504 • For forwarded-bit-clock PHYs, such as PHY1 and PHY2 (FBCSE PHY), the particular rising edge
505 of the forwarded bit clock that starts the Control Data Stream column(s).
506 Row Sync Points are the reference for the start of Rows, which are used in, e.g.:
507 • Stream Synchronization Points (SSPs) indicated by SSCR or SSPA Commands.
508 • The action point for Commands.
509 • The Commit Point in an SSCR or DSCR Command.

4.2.4.3 Audio Sample Clock

510 The Manager delivers an audio quality clock to the Peripherals, which can be used as an audio sample
511 clock. This clock is delivered in a PHY-dependent manner, e.g.:
512 • For PHY3 (DLV): the transition between the Sync0 and Sync1 bits in the Row Sync sequence.
513 Note: in typical designs the Peripheral will use the received Sync edge itself rather than selecting
514 the corresponding edge from the recovered bit clock.
515 • For forwarded-bit-clock PHYs, such as PHY1 or PHY2 (FBCSE): selected edges of the forwarded
516 bit clock.
517 Note: In typical designs the Peripheral will select from the rising edges that are used to indicate the
518 Row Sync Point at the start of column 0.

Copyright © 2019–2024 MIPI Alliance, Inc. 19

4.3 Payload Transport

519 Note:
520 This Section is an overview of Payload Transport, which is specified in detail in Section 12.3.

4.3.1 SWI3S Payload Concepts and Terminology

4.3.1.1 Payload Streams

521 A payload stream is a sequence of sample frames.
522 A sample frame is one sample from each channel (all captured at the same sampling event).
523 The sample frames occur at a periodic rate (the sample rate).
524 Individual channel samples can be grouped together for Transport, using sample grouping for efficient use
525 of bus bandwidth and/or channel grouping for fan-out/fan-in to/from multiple Devices.

4.3.1.2 Data Ports

526 A Data Port is the collection of registers and logic that controls how payload streams are transported on the
527 Link. A Data Port can behave as either a:
528 Source Data Port, which sends data to the SWI3S Link (e.g., captured from the input on a
529 microphone peripheral), or a
530 Sink Data Port, which takes data from the SWI3S Link (e.g., fed to the output on an amplifier
531 peripheral).

4.3.1.3 Transport Pattern

532 The Transport Pattern is the repeating pattern of how UIs on the Link are assigned to a payload stream.
533 This pattern occupies an integer number of Rows, and includes an integer number of complete sample
534 frames from the payload stream.

4.3.1.4 Transport Flexibility

535 SWI3S Data Port parameters provide flexibility for a wide range of system scenarios including:
536 • Mixtures of PCM and PDM streams.
537 • Mixtures of sample rates and word widths.
538 • Supporting bus-level aggregation (sometimes referred to as fan in and fan out).
539 • Supporting peripheral-to-peripheral data streams with Wide Bits where physical bus topology
540 would provide signal integrity challenges at the bitrate used by other streams on the Link.
541 Transport opportunities occur once per Transport Interval, which is defined by the Interval parameter.
542 In typical Transport Patterns the basic bandwidth allocation uses the HorizontalStart and
543 HorizontalCount parameters to allocate one or more columns to each stream or related set of streams and
544 the Offset parameter to control the number of Rows after the SSP when a particular stream starts. When
545 combined with the number of bits to be transported for that stream within one transport interval, these
546 parameters identify a basic rectangle within the Transport Pattern.
547 Other parameters then control the grouping of 1 or more channels, and the grouping of 1 or more samples,
548 to give more sophisticated control of the Transport Pattern.

20 Copyright © 2019–2024 MIPI Alliance, Inc.

4.3.2 Example Transport Patterns

549 This Section contains example Transport Patterns illustrating how some of the Data Port parameters can be
550 used to arrange the payload traffic.

4.3.2.1 Example Transport Patterns: 1 or 2 PDM Microphones with PHY1 (FBCSE)

551 This example illustrates a minimal transport pattern for the single-ended PHY with 1 PDM microphone
552 stream plus a control channel.
553 The Clock Config in the example in Figure 7 is 3.072 MRows/sec × 2 columns = 6.144 Mbps.
554 The audio streams in this Transport Pattern are:
555 1 channel of 3.072 MHz × 1 bit.
556 The SSP Rate in this example is 3.072 MHz because the pattern repeats in every Row.

Row Sync Point SSPs

0 1
C D1
C D1
C D1
C D1
C D1
557
Figure 7 Example Transport Pattern: 1 PDM Stream with PHY1 (FBCSE)

558 Figure 8 shows how the same bit rate on the link can be used to add a second PDM Mic at half the sample
559 rate, with the control channel also being reduced to 1.536 Mbps.
560 The Clock Config in the example in Figure 8 is 1.536 MRows/sec × 4 columns = 6.144 Mbps.
561 The audio streams in this Transport Pattern are:
562 1 channel of 3.072 MHz × 1 bit; Sample Grouping = 2, so latency = 651 nsec.
563 1 channel of 1.536 MHz × 1 bit; Sample Grouping = 1, so latency = 651 nsec.
564 The SSP Rate in this example is 1.536 MHz because the pattern repeats in every Row.

Row Sync Point SSPs

0 1 2 3
C D1 D1 D2
C D1 D1 D2
C D1 D1 D2
C D1 D1 D2
C D1 D1 D2
565
Figure 8 Example Transport Pattern: 2 PDM Streams at Mixed Rates with PHY1 (FBCSE)
566 ###Note to Reviewers: we will add Rod’s low power example with 1x PDM Mic and low-BW
567 Control.

Copyright © 2019–2024 MIPI Alliance, Inc. 21

568 ###TODO-Author: start from figures in archived Annex on “Effects of Physical Topology on PHY
569 Signaling”.
570 (1 with sample grouping, 1 with SRI.
571 16 column. 768kRows/s. 16 columns. Interval=1. Sample grouping=4. PHY2
572 CDS, HO, D, empty, 3 x {empty, empty, D, empty}.
573 16 column. 384kRows/s. 16 columns. Interval=1. Sample grouping=8 PHY1
574 CDS, HO, 8xD, 6 x empty.
575 16 column. 384kRows/s. 16 columns. SRI=1. Interval=2 UIs. PHY1
576 CDS, D, 7x {empty, D}. Latency = 1 sample (~=326ns).
577
578

4.3.2.2 Example Transport Patterns: 4 PDM Microphones with PHY3 (DLV PHY)
579 The Clock Config in the example in Figure 9 is 3.072 MRows/sec × 16 columns = 49.152 Mbps.
580 The audio streams in this Transport Pattern are:
581 4 channels of 3.072 MHz × 1 bit; latency = 326 nsec.
582 The SSP Rate in this example is 3.072 MHz because the pattern repeats in every Row.

Row Sync Point SSPs

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C D1 D2 D3 D4 S0
S1 M-CDS
C D1 D2 D3 D4 S0
S1 M-CDS
C D1 D2 D3 D4 S0
S1 M-CDS
C D1 D2 D3 D4 S0
S1 M-CDS
C D1 D2 D3 D4 S0
583
Figure 9 Example Transport Pattern: PDM Streams Without Sample Grouping

584 The Sample Grouping Data Port parameter enables a trade-off between PDM latency and bandwidth
585 utilization.
586 Figure 10 shows an example Transport Pattern with the same 4x 1-bit PDM streams as in Figure 9, but
587 using sample grouping to transmit blocks of 4 bits from each stream, once every 4 Rows. This example
588 frees up bus bandwidth at the cost of increasing transport latency from 1 Row (326 ns @
589 3.072 MRows/sec) to 4 Rows (1.30 µs).
590 The Clock Config in the example in Figure 10 is 3.072 MRows/sec × 16 columns = 49.152 Mbps
591 The audio streams in this Transport Pattern are:
592 4 channels of 3.072 MHz × 1 bit; Sample Grouping = 4, so latency = 1.30 µsec.

22 Copyright © 2019–2024 MIPI Alliance, Inc.

593 The SSP Rate in this example is 768 kHz because the pattern repeats every 4 Rows.

Row Sync Point SSPs (Stream Synchronization Points)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C D1 D1 D1 D1 S0
S1 M-CDS
C D2 D2 D2 D2 S0
S1 M-CDS
C D3 D3 D3 D3 S0
S1 M-CDS
C D4 D4 D4 D4 S0
S1 M-CDS
C D1 D1 D1 D1 S0
S1 M-CDS
C D2 D2 D2 D2 S0
594
595
Figure 10 Example Transport Pattern: PDM Streams With Sample Grouping

Copyright © 2019–2024 MIPI Alliance, Inc. 23

4.3.2.3 Example Transport Pattern: Mixing PCM and PDM

596 The Clock Config in the example in Figure 11 is 3.072 MRows/sec × 16 columns = 49.152 Mbps
597 The audio streams in this Transport Pattern are:
598 2 channels of 48 kHz × 24 bits.
599 4 channels of 48 kHz × 16 bits.
600 3 channels of 3.072 MHz × 1 bit; latency = 326 nsec.
601 The SSP Rate in this example is 48 kHz because the pattern repeats every 64 Rows.

Row Sync Point SSPs (64 rows at 3.072 MRows/sec == 48 kHz)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C D1 D1 D1 D7 D8 D9 S0 x2

S1 M-CDS
C D1 D1 D1 D7 D8 D9 S0 x2

S1 M-CDS
C D2 D2 D2 D7 D8 D9 S0 x2

S1 M-CDS
C D3 D3 D3 D7 D8 D9 S0 x2

S1 M-CDS
C D3 D7 D8 D9 S0 x2

S1 M-CDS
C D4 D4 D4 D7 D8 D9 S0 x2

S1 M-CDS
C D4 D7 D8 D9 S0 x2

S1 M-CDS
C D5 D5 D5 D7 D8 D9 S0 x2

S1 M-CDS
C D5 D7 D8 D9 S0 x2

S1 M-CDS
C D6 D6 D6 D7 D8 D9 S0 x2

S1 M-CDS
C D6 D7 D8 D9 S0 x2

S1 M-CDS
C D7 D8 D9 S0 x2

Total of 24 similar Rows with D7, D8, D9

... ... ... ... ... ...
and 4 unused UIs
S1 M-CDS
C D7 D8 D9 S0 x2

S1 M-CDS
C D7 D8 D9 S0 x2

S1 M-CDS
C D1 D1 D1 D7 D8 D9 S0 x2

S1 M-CDS
C D1 D1 D1 D7 D8 D9 S0 x2
602
Figure 11 Example Transport Pattern: Mixed PCM and PDM

24 Copyright © 2019–2024 MIPI Alliance, Inc.

4.3.2.4 Example Transport Pattern: Mixing PCM Sample Rates and Widths
603 The Clock Config in the example in Figure 12 is 3.072 MRows/sec × 16 columns = 49.152 Mbps
604 The audio streams in this Transport Pattern are:
605 2 channels of 48 kHz × 24 bits (labelled D1 and D2).
606 4 channels of 24 kHz × 16 bits (labelled D3, D4, D5, D6).
607 The SSP Rate in this example is 24 kHz, because the Transport Pattern repeats every 128 Rows.

Row Sync Point SSPs (128 rows at 3.072 MRows/sec == 24 kHz)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C D1 D1 D1 D1 D1 D1 D1 D1 S0
S1 M-CDS
C D1 D1 D1 D1 D1 D1 D1 D1 S0
S1 M-CDS
C D1 D1 D1 D1 D1 D1 D1 D1 S0
S1 M-CDS
C D2 D2 D2 D2 D2 D2 D2 D2 S0
S1 M-CDS
C D2 D2 D2 D2 D2 D2 D2 D2 S0
S1 M-CDS
C D2 D2 D2 D2 D2 D2 D2 D2 S0
S1 M-CDS
C D3 D3 D3 D3 D3 D3 D3 D3 S0
S1 M-CDS
C D3 D3 D3 D3 D3 D3 D3 D3 S0
S1 M-CDS
C D4 D4 D4 D4 D4 D4 D4 D4 S0
S1 M-CDS
C D4 D4 D4 D4 D4 D4 D4 D4 S0
S1 M-CDS
C S0
S1 M-CDS
C S0
... ... Total of 54 similar spare Rows ... ... ...
S1 M-CDS
C S0
S1 M-CDS
C S0
S1 M-CDS
C D1 D1 D1 D1 D1 D1 D1 D1 S0
S1 M-CDS
C D1 D1 D1 D1 D1 D1 D1 D1 S0
S1 M-CDS
C D1 D1 D1 D1 D1 D1 D1 D1 S0
S1 M-CDS
C D2 D2 D2 D2 D2 D2 D2 D2 S0
S1 M-CDS
C D2 D2 D2 D2 D2 D2 D2 D2 S0
S1 M-CDS
C D2 D2 D2 D2 D2 D2 D2 D2 S0
S1 M-CDS
C D5 D5 D5 D5 D5 D5 D5 D5 S0
S1 M-CDS
C D5 D5 D5 D5 D5 D5 D5 D5 S0
S1 M-CDS
C D6 D6 D6 D6 D6 D6 D6 D6 S0
S1 M-CDS
C D6 D6 D6 D6 D6 D6 D6 D6 S0
S1 M-CDS
C S0
S1 M-CDS
C S0
... ... Total of 54 similar spare Rows ... ... ...
S1 M-CDS
C S0
S1 M-CDS
C S0
S1 M-CDS
C D1 D1 D1 D1 D1 D1 D1 D1 S0
S1 M-CDS
C D1 D1 D1 D1 D1 D1 D1 D1 S0
S1 M-CDS
C D1 D1 D1 D1 D1 D1 D1 D1 S0
608
Figure 12 Example Transport Pattern: Mixing PCM Sample Rates and Widths

Copyright © 2019–2024 MIPI Alliance, Inc. 25

4.3.2.5 Example Transport Pattern: High Bandwidth PCM

609 The Clock Config in the example in Figure 13 is 3.072 MRows/sec × 16 columns = 49.152 Mbps
610 The audio streams in this Transport Pattern are:
611 6 channels of 192 kHz × 24 bits.
612 The SSP Rate in this example is 192 kHz, because the Transport Pattern repeats every 16 Rows.

Row Sync Point SSPs (16 rows at 3.072 MRows/sec == 192 kHz)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C D1 D1 D1 D1 D1 D1 D1 D1 D1 S0 x2

S1 M-CDS
C D1 D1 D1 D1 D1 D1 D1 D1 D1 S0 x2

S1 M-CDS
C D1 D1 D1 D1 D1 D1 D2 D2 D2 S0 x2

S1 M-CDS
C D2 D2 D2 D2 D2 D2 D2 D2 D2 S0 x2

S1 M-CDS
C D2 D2 D2 D3 D3 D3 D3 D3 D3 S0 x2

S1 M-CDS
C D3 D3 D3 D3 D3 D3 D3 D3 D3 S0 x2

S1 M-CDS
C D4 D4 D4 D4 D4 D4 D4 D4 D4 S0 x2

S1 M-CDS
C D4 D4 D4 D4 D4 D4 D5 D5 D5 S0 x2

S1 M-CDS
C D5 D5 D5 D5 D5 D5 D5 D5 D5 S0 x2

S1 M-CDS
C D5 D5 D5 D6 D6 D6 D6 D6 D6 S0 x2

S1 M-CDS
C D6 D6 D6 D6 D6 D6 D6 D6 D6 S0 x2

S1 M-CDS
C D1 D1 D1 D1 D1 D1 D1 D1 D1 S0 x2

S1 M-CDS
C D1 D1 D1 D1 D1 D1 D2 D2 D2 S0 x2
613
Figure 13 Example Transport Pattern: High Bandwidth PCM

26 Copyright © 2019–2024 MIPI Alliance, Inc.

4.3.3 SWI3S Payload Traffic Visualization

614 The payload transport options can best be explored using the software tool for SWI3S traffic visualization,
615 which includes a brief description of each of the transport parameters. It can be downloaded from:
616 ###NOTE to Reviewers: this URL is a Causeway folder that is accessible only by Contributor+
617 Members, for use during Spec development. This will be replaced by a URL for ALL members (or
618 possibly the public) prior to adoption of the Spec.
619 https://members.mipi.org/wg/Audio-WG/document/folder/11868
620 Figure 14 shows an example of the output of the SWI3S Visualizer tool for a system using the DLV PHY.

621
Figure 14 Example of SWI3S Payload Visualizer Tool

Copyright © 2019–2024 MIPI Alliance, Inc. 27

4.4 Control Data Stream and Commands

622 A SWI3S link includes a Control Data Stream that transfers information in both directions between the
623 Manager and Peripherals. Layered on top of this Control Data Stream is a Command Transport Protocol
624 that conveys Commands for managing: the link, the payload transport, and other functions within the
625 Peripherals.

4.4.1 Command Protocol Layers

626 The Command Protocol is used to exchange control and status information between the Manager and the
627 Peripherals. It does this by reading and writing Registers, some defined in this Specification, and some in
628 other documents (see the Peripheral Command Model in Section 4.4.5).
629 The Command Protocol comprises three layers:
630 Control Data Stream: (see Section 4.4.2) that describes data encoding used to send symbols over
631 a bitstream, which is then communicated over the PHY (see Section 4.8).
632 Command Transport Protocol: (see Section 4.4.3) that describes transport layer behavior where
633 symbols from the Control Data Stream are arranged to form valid protocol sequences, named
634 Phases and Transfers, which transport the data representing Commands.
635 Commands: (see Section 4.4.4) that describe command behavior in the form of operations such
636 as reading status or writing control information, and the format of data used to describe these
637 Commands. The sequencing rules for the read and write operations is described in the
638 accompanying Peripheral Command Model (see Section 4.4.5).
639 Figure 15 illustrates the layers of the Command Protocol.

SWI3S Registers
Peripheral Command
Non-SWI3S Registers (local)
Model for Registers Non-SWI3S Registers (remote)

Ping, Unblock, SSPA, ExitDormant

ReadA32, WriteA32
Commands Stream-Synchronous Commit Request (SSCR)
Device Synchronous Commit Request (DSCR)
InitCal, TrimCal

Transfers
Command Transport Phases
Protocol Elements of Phases
Bytes

8b/10b Encoding (K-Codes & D-Codes)

Control Data Stream 30-bit PHY Calibration Blocks
Bits & Symbols Undriven Bits
Idle Bits

BitClock, RowSync, DataIn,

PHY Interface: DataOut, DataOutEnable,
(PHY-independent) PHY Encoding/Decoding
BitWidth, Guard Bits, Tail BitSlots.

E.g.,
Impedance,
PHY, e.g., DLV Signaling Levels,
Signal Timing.
640
Figure 15 Command Protocol Layer Stack: Overview

28 Copyright © 2019–2024 MIPI Alliance, Inc.

4.4.2 Control Data Stream

641 The Control Data Stream is the encoding/decoding layer in the Command Protocol, and is specified in
642 detail in Section 7.

4.4.2.1 Summary of Features

643 Features of the Control Data Stream are:
644 • It provides a link that is shared between Manager and all Peripherals, with ownership orchestrated
645 by the Command Protocol Layer.
646 • It transports 8b/10b-encoded symbols for the Command Protocol Layer. This encoding provides
647 several benefits:
648 • 8b/10b K-codes that have a bit pattern that cannot occur elsewhere in the Control Data Stream
649 are used for Start of Phase Markers to synchronize the Command Protocol Layer without
650 knowledge of existing alignment, thus:
651 • A decoder in a Peripheral can identify the start of new Phases without needing to consume
652 power tracking the detail of communication aimed at other Peripherals, and without needing
653 to receive the response signals from other Peripherals, which might be invalid due to signal
654 integrity effects.
655 • 8b/10b D-codes are used for data bytes (catching some single-bit transport errors).
656 • This encoding balances the running disparity to remove DC from the encoded Control Data
657 Stream.
658 • It is independent of the alignment of audio payload operations (i.e., SSPs).
659 • It includes an idle pattern that the Manager uses to provide spacing between protocol elements
660 driven by the Manager and Peripheral, or when it has no Commands to communicate.
661 • The Manager can detect when bits assigned to a Peripheral have not been driven:
662 • For some PHYs, the preceding Sync1 bits leave a known value on the bus.
663 • For other PHYs, the CDS bits are NRZS-encoded from the previous value on the bus.
664 The 8b/10b-encoded symbols of the Control Data Stream are transported using CDS bits on 10 consecutive
665 Rows in the Transport Pattern. In general, there is no fixed relationship between the start of these symbols
666 and the audio payload streams. When the Manager sends a Command that indicates an SSP (i.e., an SSPA
667 or SSCR), the Manager schedules the start of this Command so that the Commit Point occurs aligned with
668 the audio payload streams. Figure 16 shows a fragment of the example Transport Pattern from Figure 13
669 with a highlight around the bits that form 2 CDS symbols.

Copyright © 2019–2024 MIPI Alliance, Inc. 29

Row Sync Point

10 Consecutive CDS Bits Transport
0 1 2 3 4 5 ...
Each 8B/10B-encoded CDS Byte
S1 M-CDS
C D1 ...
CDS Byte #1 S1 M-CDS
C D1 ...
S1 M-CDS
C D1 ...
S1 M-CDS
C D2 ...
S1 M-CDS
C D2 ...
S1 M-CDS
C D2 ...
S1 M-CDS
C D3 ...
S1 M-CDS
C D3 ...
S1 M-CDS
C D4 ...
S1 M-CDS
C D4 ...
S1 M-CDS
C D4 ...
CDS Byte #2 S1 M-CDS
C D5 ...
S1 M-CDS
C D5 ...
S1 M-CDS
C D5 ...
S1 M-CDS
C D6 ...
S1 M-CDS
C D6 ...
S1 M-CDS
C D1 ...
S1 M-CDS
C D1 ...
S1 M-CDS
C D1 ...
S1 M-CDS
C D2 ...
S1 M-CDS
C D2 ...
S1 M-CDS
C D2 ...
670
Figure 16 Control Data Stream Symbols within a Transport Pattern

4.4.3 Command Transport Protocol

671 The Command Transport Protocol is the data communication layer in the Command Protocol, and is
672 specified in detail in Section 8.

4.4.3.1 Summary of Features

673 The Command Transport Protocol:
674 • Is built on top of the Control Data Stream.
675 • Conveys Commands that describe actions to be performed in Peripherals (see Section 4.4.4).
676 • Uses data communication Transfers composed of structured Phases:
677 • Support for multi-byte Transfers to provide greater bandwidth efficiency.
678 • Support for simple interleaving of Transfers targeted at different Peripherals for efficient
679 utilization of the link.
680 • Support for deferred completion of Transfers (deferred reads and buffered writes), e.g., to
681 allow for implementations of Peripherals with significant internal bus latency.
682 • Uses two techniques to provide robustness to bit errors:
683 • Robust Tokens that use a subset of byte values that have an easily verifiable pattern and
684 encode to a set of 8b/10b D-code symbols separated by a Hamming Distance of at least 4,
685 which are used to improve confidence in key elements at the single symbol level, such as
686 Device Mask or Peripheral Response.
687 • HD10 Robust Tokens are a special subset of 2 Robust Tokens that are bit inverses of each
688 other (so are separated by a Hamming Distance of 10), which are used for critical go/no-go
689 decisions in the protocol.
690 • CRC protection, used for larger blocks of data such as command information and command
691 data.

30 Copyright © 2019–2024 MIPI Alliance, Inc.

4.4.3.2 Key to Command Transport Protocol Diagrams

692 Figure 17 is a key to how the 10-bit symbols / bytes are illustrated in the diagrams of Phases.
693 • The magenta colored rectangle with solid black line represents the K-code that resynchronizes all
694 Command decoders at the start of a Phase.
695 • Stronger colored rectangles with a second rectangle inside them represent one or more Robust
696 Tokens that are a selected subset of D-codes that rely on Hamming Distance to facilitate detection
697 of bit errors, and which are used at particular places within the Command Transport Protocol.
698 • Plain rectangles represent one or more normal D-code bytes that are followed by a CRC (also
699 encoded with normal D-code bytes) from whichever Device sent them.
700 • A grey colored rectangle is a block of 10 CDS bits allocated to a symbol from a Peripheral, but not
701 driven, so the physical bus value for each CDS bit is a copy of the preceding bit maintained by a
702 bus keeper in the Manager.
703 • A yellow and purple mixed color rectangle is a block of 30 raw bits (i.e., not 8b/10b-encoded
704 bytes) used for calibrating the timing of the DLV PHY in a Peripheral.
705 • The grey and white striped rectangle is a block of 10 bits driven to alternating 0 and 1 by the
706 Manager as a protocol spacer that allows devices time to react to the preceding symbols.

Transmitted by Manager to All Peripherals

K-Code for Synchronization Robust Token D-Codes Regular D-Codes

Start of Phase Marker Header Byte Manager Byte

Phase Header Manager Packet

(6 Bytes) (N Bytes)
Idle Pattern for Spacing

Protocol Spacer Manager Response Manager CRC Byte

Transmitted by 1 Peripheral to Manager

Period when Bus is Allocated Robust Token D-Codes Regular D-Codes

to a Peripheral but Not Driven
Peripheral: No Response Peripheral Response Peripheral Byte

Peripheral PingInfo[3..0] Peripheral Packet

(N Bytes)
Peripheral Cal Result
Peripheral CRC Byte

Interleaved (between 1 Peripheral and Manager)

Peripheral / Manager
Interleaved Raw Bits

DLV Calibration Block

(30 Bits)
707
Figure 17 Key to Command Transport Protocol Diagrams

Copyright © 2019–2024 MIPI Alliance, Inc. 31

4.4.3.3 Examples of Phases

4.4.3.3.1 Write Phase

708 Figure 18 illustrates the Phase used to transport Write Commands. The bytes in the Phase Header use
709 Robust Tokens. The CRC covers the bytes in the Manager Packet (i.e., opcode, address, and write data).
710 The Protocol Spacer provides time for the Peripheral to process the preceding information and calculate its
711 Peripheral Response. When the Address within the Manager Packet indicates a Remote Write (see
712 Section 4.4.5.2), the set of Peripheral Responses is extended to include REMOTE_WRITE_BUFFERED,
713 REMOTE_WRITE_BUSY and REMOTE_ACCESS_DISABLED. The Write Phase is also used for the
714 Unblock Command because this has a similar pattern of information flow between Manager and Peripheral.

Write Phase: Write Phase:

WriteA32 Command Unblock Command
Start of Phase Marker Start of Phase Marker
PhaseID: WRITE PhaseID: WRITE
Device Mask_H Device Mask_H
1 device 1 device
Phase Device Mask_M Device Mask_M
selected selected
Header Device Mask_L Device Mask_L

Packet_Length =1
Packet_Length_H Packet_Length_H=0x0
Packet_Length_L Packet_Length_L=0x1

Opcode: WriteA32 Opcode: Unblock

Address[31:24] Manager_CRC16_H
(5 + data byte count)

Address[23:16] Manager_CRC16_L
Packet_Length

Address[15:08] Protocol Spacer

Manager
Address[07:00] WRITE_OK
Write data bytes

Packet
Write Data
...
...
...
Manager_CRC16_H
CRC
Manager_CRC16_L
Protocol Spacer Protocol Spacer
Peripheral Response WRITE_OK
715
Figure 18 Examples of Write Phases

32 Copyright © 2019–2024 MIPI Alliance, Inc.

4.4.3.3.2 Read Phases

716 Figure 19 illustrates the Phases used to transport Read Commands. The Manager CRC covers the bytes in
717 the Manager Packet (i.e., opcode, address, and byte count). Similarly to Write Phases, when the Address
718 indicates a Remote Read (see Section 4.4.5.2) the set of Peripheral Responses is extended to include
719 REMOTE_READ_DEFERRED, REMOTE_WRITE_BUSY and REMOTE_ACCESS_DISABLED.
720 The first Phase shows the case when the Peripheral provides the read data immediately. The Peripheral
721 Response is followed by the Peripheral Packet containing the read data and a CRC that covers the read
722 data. Finally, a Manager Response indicates that the CRC was OK, so the read operation is complete.
723 The second Phase shows the case when the Peripheral defers providing the data for a Remote Read
724 Command. The ReadSetup Phase terminates after the Peripheral Response. The Manager can attempt to
725 collect the read data using one or more Read Data Phases from that Peripheral. At some time later, the
726 Peripheral responds with READ_DATA_NOW, which is followed by all of the read data, CRC, and
727 Manager Response in the same pattern as the first Phase in the figure.

ReadSetup Phase ReadSetup Phase ReadData Phase

when Peripheral when Peripheral when Peripheral
provides data immediately defers providing data provides data
Start of Phase Marker Start of Phase Marker Start of Phase Marker
PhaseID: READ_SETUP PhaseID: READ_SETUP PhaseID: READ_DATA

Device Mask_H Device Mask_H Device Mask_H

1 device 1 device
Phase Device Mask_M Device Mask_M Device Mask_M
selected selected
Header Device Mask_L Device Mask_L Device Mask_L
Packet_Length_H=0x0 Packet_Length_H=0x0 Packet_Length_H=0x0
Packet_Length = 6 bytes

Packet_Length_L=0x6 Packet_Length_L=0x6 Packet_Length_L=0x0

(=ReadByteCount from Command

Opcode: ReadA32 Opcode: ReadA32 Protocol Spacer

in original ReadSetup Phase)

Peripheral Packet_Length
Address[31:24] Remote Address[31:24] READ_DATA_NOW

Manager Address[23:16] Remote Address[23:16] Protocol Spacer

Packet Address[15:08] Remote Address[15:08] Peripheral Data
Address[07:00] Remote Address[07:00] ...
ReadByteCount ReadByteCount ...

Manager Manager_CRC16_H Manager_CRC16_H ...

CRC Manager_CRC16_L Manager_CRC16_L Peripheral_CRC16_H
Protocol Spacer Protocol Spacer Peripheral_CRC16_L
(=ReadByteCount from Command)

Peripheral
READ_DATA_NOW READ_DEFERRED Protocol Spacer
Response
Peripheral Packet_Length

Protocol Spacer READ_DATA_OK

Peripheral Data

Peripheral ...
Packet ...
...

Peripheral Peripheral_CRC16_H
CRC Peripheral_CRC16_L
Protocol Spacer
Manager
READ_DATA_OK
728 Response

Figure 19 Example Read Phases

Copyright © 2019–2024 MIPI Alliance, Inc. 33

4.4.3.3.3 Ping and Commit Phases

729 Figure 20 illustrates the Phases used to transport Ping and Commit Request (SSCR & DSCR) Commands.
730 After the Manager CRC there is a block of 12 response slots, with a fixed assignment of 1 slot to each
731 Peripheral Device Number that can exist on the bus.
732 For the Ping Command, these slots contain 1 Robust Token from each Peripheral that conveys Peripheral
733 Status, such as whether it has any interrupts that need servicing.
734 For the Stream-Synchronous Commit Request (SSCR) and Device-Synchronous Commit Request (DSCR)
735 Commands, these slots contain 1 Robust Token from each Peripheral indicating whether it is ready to
736 perform the Commit Command. These are followed by a Manager Response that either confirms the
737 Commit operation or cancels it (e.g., if one of the Peripherals has not responded with
738 COMMIT_READY). This Manager Response uses a special subset of Robust Tokens, called HD10
739 (Hamming Distance 10) tokens, to facilitate correction of small numbers of bit errors.

GetStatus Phase: Commit Phase: Commit Phase:

Ping Command SSCR Command DSCR Command
Start of Phase Marker Start of Phase Marker Start of Phase Marker
PhaseID: GET_STATUS PhaseID: COMMIT PhaseID: COMMIT

Device Mask_H Device Mask_H Device Mask_H

– –
Phase Device Mask_M devices Phase Device Mask_M Device Mask_M devices
Header selected Header selected
Device Mask_L Device Mask_L Device Mask_L
Packet_Length_H=0x0
Packet_Length

Packet_Length_H=0x0 Packet_Length_H=0x0

Packet_Length_L=0x1 Packet_Length_L=0x3 Packet_Length_L=0x3

Packet_Length
= 0x01

Manager
Opcode: Ping Opcode: SSCR Opcode: DSCR

= 0x03
Packet
Manager
Manager Manager_CRC16_H Group Mask Group Mask
Packet
CRC Manager_CRC16_L Row Delay Row Delay
Protocol Spacer Manager Manager_CRC16_H Manager_CRC16_H
Peripheral 0 PingInfo CRC Manager_CRC16_L Manager_CRC16_L
Peripheral 1 PingInfo Protocol Spacer Protocol Spacer
Peripheral 2 PingInfo Peripheral 0 Response Peripheral 0 Response
Peripheral 3 PingInfo Peripheral 1 Response Peripheral 1 Response

Peripheral 4 PingInfo Peripheral 2 Response Peripheral 2 Response

Peripheral Peripheral 5 PingInfo Peripheral 3 Response Peripheral 3 Response

Responses Peripheral 6 PingInfo Peripheral 4 Response Peripheral 4 Response

Peripheral 7 PingInfo Peripheral Peripheral 5 Response Peripheral 5 Response

Peripheral 8 PingInfo Responses Peripheral 6 Response Peripheral 6 Response

Peripheral 9 PingInfo Peripheral 7 Response Peripheral 7 Response

Peripheral 10 PingInfo Peripheral 8 Response Peripheral 8 Response

Peripheral 11 PingInfo Peripheral 9 Response Peripheral 9 Response

Peripheral 10 Response Peripheral 10 Response
Peripheral 11 Response Peripheral 11 Response

Protocol Spacer Protocol Spacer

Manager
Manager Response Manager Response
740 Response

Figure 20 Example Ping & Commit Phases

34 Copyright © 2019–2024 MIPI Alliance, Inc.

4.4.4 Commands
741 This Section is an overview of Commands, which are specified in detail in Section 9.
742 Commands are the data format that describes the operations to be performed in the Peripheral, along with
743 data representing the parameters and/or result. Commands can be categorized as:
744 • Basic operations for link status and control.
745 • Read and write transactions for, e.g., accessing address-mapped registers.
746 • Synchronization operations for orchestrating simultaneous behavior in multiple Peripherals.

4.4.4.1 Summary of Commands

747 The Commands (which are described in detail in Section 9) are:
748 Ping: Used to determine basic status from all Peripherals in one Command.
749 Stream Synchronization Point Announcement (SSPA): Used for stream synchronization in Peripherals.
750 Unblock: Used to provide coherent recovery from synchronization errors that have caused a Peripheral to
751 detach from, and then reattach to, the bus.
752 Address Mapped Writes: Used for writing to Registers or memory. The address is 32 bits wide. The total
753 number of bytes to write can be 1–250. Address space is separated into local and remote regions. Local
754 Writes that are accepted will always receive a definite OK/Failed response during the Phase. Remote Writes
755 that are accepted might provide a definite response, or might be buffered and completed later.
756 Address Mapped Reads: Used for reading from Registers or memory. The address is 32 bits wide. The
757 total number of bytes to read can be 1–256. Local Reads that are accepted will always receive a definite
758 OK-with-data/Failed response during the Phase. Remote Reads that are accepted might provide a definite
759 response during the Phase, or might be deferred with the last of one or more following Read Data Phases
760 delivering OK-with-data/Failed.
761 Commit Requests (SSCR & DSCR): Used for synchronized updates to sets of registers in one device or
762 across several devices. The update can either perform stream synchronization (SSCR) or not (DSCR). The
763 scope of the synchronized update is selectable to include registers defined within this Specification (e.g.,
764 PHY control, Link Control, Payload Transport) and/or those defined elsewhere.
765 InitCal & TrimCal: (applicable to Peripherals that implement the DLV PHY): For providing feedback
766 from the Manager to the Peripheral so that it can adjust the timing of its output to match both the system
767 environment and device variation due to process, voltage, or temperature (PVT).
768 Exit_Dormant: Used to re-establish full communication with a Peripheral that was previously put into an
769 optional low-power state.

Copyright © 2019–2024 MIPI Alliance, Inc. 35

4.4.5 Peripheral Command Model

770 Figure 21 illustrates the conceptual layering model of how a Peripheral processes Commands. Registers
771 control behavior and report status of a SWI3S Peripheral. Some registers are defined within this
772 Specification and some are defined outside it in other specifications such as SDCA ([MIPI02]) or are
773 implementation-defined.

Non-SWI3S Behavior
(other MIPI Specifications and/or
Remote Registers
Implementation-defined) On-chip infrastructure
& Memory (variable latency)
(can be buffered/deferred)

Remote address
Local Registers
Device Power & Memory Address?
(never buffered/deferred) Local address
Management

SWI3S Behavior
Peripheral Behavior Non-SWI3S address

Calibration Link Row Delay Standard Registers

Status Address?
Algorithm Management Counter (never buffered/deferred) Local address,
standard register

Unblock Cal_PHY Ping

Exit
SSPA
SSCR Commands WriteA32, ReadA32
Dormant DSCR (Opcodes)

Command Transport
ReadSetup
Unblock Cal_PHY GetInfo Announce Commit Protocol Write ReadData
(Transfers & Phase Types)

Control Data Stream

(8b/10b coding and SPM detection)

PHY
(e.g., DLV signaling)

774
Figure 21 Peripheral Command Model
775 Note:
776 Figure 21 is a duplicate copy of Figure 114 in Section 9, where there is a more detailed definition
777 of Commands.

4.4.5.1 Response Latency and Local vs Remote Registers

778 In Write and Read Phases, the Peripheral provides its response in the 8b/10b symbol 10 Rows after the end
779 of the CRC that protects the description of the Command. Thus, there is only a short time available for the
780 Peripheral to perform the read or write operation described by the Command and to deliver a response (and
781 read data where appropriate).
782 This time constraint is acceptable for the control registers defined within this Specification, and for some
783 Peripheral designs that add further registers. These registers are referred to as Local Registers. When a
784 Read or Write Command addresses a Local Register it is referred to as a Local Read or Local Write
785 Command. Responses to Local Commands are always a definite indication of success or failure, where
786 success also indicates that the accompanying internal operation has completed.

36 Copyright © 2019–2024 MIPI Alliance, Inc.

787 A complex Peripheral design might add registers (or other resources) using an internal architecture that
788 cannot guarantee completion within the constrained latency (e.g., accessed via slow internal infrastructure,
789 or provided by an internal DSP). These registers are referred to as Remote Registers. When a Read or Write
790 Command addresses a Remote Register it is referred to as a Remote Read or Remote Write Command. The
791 set of possible Responses to Remote Commands is extended to include indications that a Remote Write
792 operation has been buffered (a Buffered Write), or that a Remote Read data transfer operation has been
793 deferred (a Split Read).
794 Note:
795 All of the Peripheral registers defined within this Specification are Local registers, so a Peripheral
796 can support writing and reading these registers without implementing the optional support for
797 Buffered Writes or Split Reads.

4.4.5.2 Remote Reads and Writes

798 Note:
799 This Section is an overview of the Remote Access behavior, which is described in detail in
800 Section 9.1.4.
801 Remote Read commands provide flexibility for the Peripheral to indicate that the read address from the
802 ReadSetup Phase has been captured, but that the read data has been deferred to a later ReadData Phase.
803 This type of operation is sometimes referred to as a split read. If the Manager wishes to complete the read
804 then it will perform subsequent ReadData Phase(s) which will either be deferred again or will receive a
805 definite result indicating one of OK (with read data) or failure.
806 Note:
807 “Split read” refers to the command and the data being delivered in 2 separate phases. The data for
808 a Read Command is always delivered in a single block, either in the ReadSetup Phase or a
809 subsequent ReadData Phase.
810 Remote Write commands provide flexibility for the Peripheral to indicate that both the write address and
811 data have been captured (buffered), and that the operation will complete later, without the need for any
812 further explicit signaling in the Command Transport Protocol. The completion status of these Commands
813 can be read indirectly.
814 Note:
815 Remote Read / Write Commands are not always deferred / buffered: they can also receive a
816 response indicating immediate success or failure. E.g., a Peripheral design might need a number of
817 bit clock cycles to perform a remote access, and the number of Columns in some Clock Configs
818 could provide sufficient bit clock cycles to complete the operation and signal a response.
819 This buffering/deferring of operations is limited to just one operation (write or read) at a time in the
820 Peripheral. This gives Peripheral designers enough flexibility without over-complicating Manager software.
821 The empty/full status of the buffer is available in status bits that can be polled using a Ping command or by
822 reading a status register. Alternatively, a Peripheral accepting a subsequent Remote Command (Read or
823 Write) implicitly confirms that a previous buffered write operation has completed successfully.
824 Note:
825 A failure while performing a buffered write or deferred read operation disables access to the remote
826 write/read address space until this condition is explicitly cleared, so that any error handling software
827 can observe coherent state of these registers before the error occurred.

4.4.5.3 Transaction Ordering

828 The order of performing two transactions (reads, writes, or a mix of these) depends on whether they are
829 Local or Remote accesses.

Copyright © 2019–2024 MIPI Alliance, Inc. 37

4.4.5.3.1 Ordering of Two Local Accesses

830 Every local access (i.e., a read or write command to a local address) always completes with a definite
831 response within one Phase. Thus, it is implicit in the protocol that one local access is strictly ordered with
832 respect to another.

4.4.5.3.2 Ordering of Two Remote Accesses

833 Remote accesses (i.e., read and write commands to remote addresses) within one Peripheral are strictly
834 ordered due to a combination of Peripheral and Manager behavior. The Manager can also choose to
835 supersede a deferred remote read for which the Peripheral has not yet provided data.
836 If a Peripheral completes the processing of a remote read or write immediately (i.e., soon enough to give a
837 response within the initial phase) then the protocol signaling is the same as for local reads or writes, so
838 these remote operations are implictly correctly ordered.
839 If a Peripheral indicates that a remote write operation has been buffered and then receives a request for a
840 second remote access (either read or write) before it has completed the first remote write, then it issues a
841 busy response indicating that the new command has not been accepted. In a typical Controller (either
842 Manager hardware or low-level software) the new remote read or write that receives the busy response will
843 be retained and retried until the Peripheral is no longer busy, which will achieve the effect of the second
844 remote read or write being correctly ordered behind the initial remote write.
845 If a Peripheral defers providing data for a remote read, then the subsequent fate of that read access is
846 dependent upon the Manager. If the Manager requests the read data then the Peripheral can complete the
847 remote read operation normally, but if the Manager chooses to initiate a new remote access (either read or
848 write) then the Peripheral abandons the first remote read operation and attempts to perform the new remote
849 access. A typical Controller/Manager will repeat the request for the read data from the first transaction
850 before requesting the second one, so this will achieve the effect of the second remote read or write being
851 correctly ordered behind the initial remote write.
852 Note:
853 There is no ordering between remote transactions to different Peripherals: in the extreme case, the
854 Manager could initiate remote reads in 12 different Peripheral devices and use Ping commands to
855 determine which Peripheral is ready to process a ReadData Phase. This approach could make
856 efficient use of bus bandwidth by avoiding busy responses to ReadData Phases. Similarly, a
857 Manager might ping Peripherals to check whether they are ready to accept a new remote write
858 command.

4.4.5.3.3 Ordering of Local versus Remote Transactions

859 Local reads and writes can be performed (and completed) while a deferred remote read or buffered remote
860 write is still outstanding, so there is no guarantee of ordering for a local operation that is requested after a
861 remote operation that is not yet complete. This feature enables, e.g., interrupt status registers to be read
862 without waiting for outstanding memory reads from the same Peripheral.
863 When the Manager does need to ensure that a local operation is performed strictly after a remote operation
864 (e.g., a Commit command following the update of a remote *_NEXT Register) then it checks for
865 completion of the remote operation using any of:
866 • Seeing a Peripheral Response to the original remote operation indicating that it completed
867 immediately.
868 • After a buffered remote write: performing a remote read from the register that was being updated
869 by the remote write.
870 • After a buffered write (but not a deferred read): Seeing a Ping Command indicating that the
871 Peripheral is no longer busy with a remote access.

38 Copyright © 2019–2024 MIPI Alliance, Inc.

4.5 Reset & Link Power Management

872 Note:
873 This Section is an overview of the Reset and Link Power Management model, which is specified in
874 detail in Section 5.

4.5.1 Link States

875 Figure 22 shows a simplified high-level view of the Link States in the Peripherals and Manager. The
876 Manager co-ordinates the behavior of the Peripherals using a mix of the Link Control PHY (when the link
877 is inactive) and Commands (when the link is active).

Initial Cold Resets, e.g.:

• Internal POR detector
• ImpDef_Cold_Reset
Peripherals Manager

Cold Standby
Sleeping Bus Idle
Standby

Link Inactive Link Inactive

(using Link Control PHY) (using Link Control PHY)

ColdStart (includes BusReset & PHY_Select) Manager has generated

WarmStart (wake from Sleep) ColdStart or WarmStart
(Link Control PHY sequences)
Bus is in LC_Idle condition Manager has completed
(Link Control PHY: 0,0) parking the bus at LC:Idle

Activate Deactivate Activate Deactivate

PHY #n PHY #n PHY #n PHY #n

PHY Ready PHY#n-specific PHY-Inactivity condition, PHY Ready

typically some time after commiting a
Peripheral Management Action of:
Enter_Sleeping or Manager has completed
Enter_Cold_Standby parking the bus using PHY #n

Link Active Link Active

(using Audio-mode PHY, e.g., DLV) (using Audio-mode PHY, e.g., DLV)
878
Figure 22 Link States
879 Note:
880 Figure 22 is identical to Figure 40 from Section 5, and is duplicated here to clarify the technical
881 overview.
882 The Link-Inactive states (Sleeping and Cold_Standby) facilitate very low power consumption in the
883 Peripherals. The Link Control PHY (LC_PHY) uses simple low-speed signaling to move the Peripherals to
884 the Link-Active states (see Section 4.5.2).
885 The intermediate Activate_PHY state represents a controlled transition between the different electrical
886 signaling standards of the LC_PHY and the selected Audio-mode PHY.
887 The Link-Active state facilitates transport of all of Commands, audio payload, and sampling clock, using
888 an Audio-mode PHY, such as the DLV PHY described in Section 11.3. In normal usage a Commit
889 Command is used to cause all Peripherals to move back to an inactive state simultaneously.
890 The intermediate Deactivate_PHY state represents a controlled transition back to the Link Control PHY
891 signaling before re-entering an inactive state (either Sleeping or Cold_Standby).
892 Note:
893 Each Audio-mode PHY has its own sub-division of the Link Active state into a set of PHY-specific
894 states that model the behavior relating to that PHY.

Copyright © 2019–2024 MIPI Alliance, Inc. 39

4.5.2 Link Control Sequences

895 This Section illustrates the signaling sequences used for basic link control, signaled using the LC_PHY.
896 These are described in detail in Section 5.

4.5.2.1 Link Idle Condition

897 When the Link is not active, it is “parked” with both the DP and DN signals at Link Control signaling
898 values of LC:0 (i.e., at a voltage very near to Ground).

4.5.2.2 Time-Based Link Control Signaling

899 3 sequences described in this section (Bus Reset, Warm Start, and LC_Request are distinguished from each
900 other by the duration of the pulse during which DP=LC:1 and DN=LC:0. The range of times for generation
901 and detection are specified with wide tolerances, which facilitates simple and low power detection of the 3
902 conditions in the Peripheral.

4.5.2.3 Bus Reset

903 The Bus Reset sequence generated by the Manager is illustrated in Figure 23. Resets are described in
904 Section 4.5.3, and the Bus Reset sequence is described in more detail in Section 5.1.5.3.
905 One effect of Bus Reset is to put all Peripherals into Link State: Cold_Standby.

Audio-Mode PHY or DP: Link Control signaling

Link Control signaling

Audio-Mode PHY or DN: Link Control signaling

906 Link Control signaling

Figure 23 Bus Reset Sequence from Manager

4.5.2.4 Cold Start

907 The Cold Start sequence generated by the Manager is illustrated in Figure 24. This comprises a Bus Reset
908 followed by clocking 4 data bits into the Peripheral to indicate which SWI3S-defined Audio-mode PHY
909 behavior will be used after the link is activated. The Cold Start sequence is described in more detail in
910 Section 5.1.2.4.

Start Audio-mode
DP: Link Control signaling PHY signaling

DN=bit3 DN=bit2 DN=bit1 DN=bit0 Start Audio-mode

DN: Link Control signaling
911 PHY signaling

Figure 24 Cold Start Sequence (Simplified)

4.5.2.5 Warm Start

912 The Warm Start sequence generated by the Manager is illustrated in Figure 25. This causes Peripherals to
913 exit from Sleeping and continue with the same Audio-mode PHY behavior that was in use prior to the
914 Manager causing them to enter Sleeping. The Warm Start sequence is described in more detail in
915 Section 5.1.2.5.

Start Audio-mode
DP: Link Control signaling PHY signaling

Start Audio-mode
DN: Link Control signaling PHY signaling
916
Figure 25 Warm Start Sequence (Simplified)

40 Copyright © 2019–2024 MIPI Alliance, Inc.

4.5.2.6 LC_Request (Wake Request or Cold Boot Request) from a Peripheral

917 The Link Control Request (LC_Request) sequence generated by a Peripheral that is in Link State: Sleeping
918 and the subsequent LC_Acknowledge from a Manager are illustrated in Figure 26. The output from the
919 Peripheral is colored pink. The Peripheral output uses a medium drive strength for the 1, so overcomes the
920 Weak0 that the Manager outputs during Standby. The Manager detects the LC_Request from the Peripheral
921 and extends this into an LC_Acknowledge so that any other Peripherals that might generate LC_Requests
922 are aware that a different Peripheral has done so. The LC_Request / LC_Acknowledge sequence is
923 described in more detail in Section 5.1.2.6.
924 This is a non-binding request by a Peripheral asking that the Manager initiates starting the link:
925 subsequently, the Manager might choose either to generate a Warm Start, or to generate a Cold Start, or to
926 take no further action.
927 Note:
928 A Peripheral in the Cold_Standby Link State (and that has first checked that no Audio-mode PHY is
929 currently active on the bus) can use the same signaling to make a Cold Boot Request, to request
930 that the Manager generates a Cold Start sequence. This is also a non-binding request of the
931 Manager which, after generating the LC_Acknowledge, might choose either to generate a Cold
932 Start or to take no further action.

DP: Link Control signaling

DN: Link Control signaling

933
Figure 26 Peripheral LC_Request and Manager LC_Acknowledge (Simplified)

Copyright © 2019–2024 MIPI Alliance, Inc. 41

4.5.3 Resets
934 ###TODO-Author: update the wording to use “sleep-wake” for the action of a warm reset followed
935 by a wake up. Soft Reset and Warm Reset have now been merged into 1 Warm Reset because
936 the effects are very similar.
937 SWI3S defines 2 sets of reset effects, categorized by severity, and one or more potential source of each of
938 these severities. Resets are described in more detail in Section 5.1.5.

4.5.3.1 Severity of Reset

939 Some resets affect only part of the state within a Peripheral or Manager. The sources of reset are
940 categorized into 2 different severities of reset, with this severity determining the scope of the effects. This
941 specification does not define the effect of these resets on the device functionality outside the SWI3S
942 interface, but the typical scope is described in these bullet points.
943 Cold Reset: affects all of the SWI3S interface, returning it to the same condition as after power-on
944 reset, and typically also affects most or all of the rest of the device. The Audio-mode PHY is
945 deactivated and the Peripheral enters Cold_Standby.
946 Warm Reset: affects a small amount of state within the SWI3S interface and stops any payload
947 streaming, but typically affects very little in other parts of the device. Depending on the cause of
948 the Warm Reset, the Audio-mode PHY might either remain activated (and the Peripheral might
949 attempt to re-attach to the bus), or be deactivated.

4.5.3.2 Sources of Reset

950 To simplify the description of resets, the sources of the 2 categories of reset are separated from their effects.
951 The sources include:
952 • Power_On_Reset detected within the device itself.
953 ###AudioWG###26March: 4 lines below here
954 • Bus_Reset signaled by the Manager (see Section 4.5.2.3 and 5.1.5.3). This is a low-level signaling
955 sequence using Link Control signaling. When Peripherals might still have the current Audio-mode
956 PHY Tx active, it can be preceded by some PHY-specific Idle condition from the Manager that
957 deactivates the Audio-mode PHY in the Peripherals.
958 • The Peripheral Management Action (PM_Action) Register Field (see Section 5.1.3) being
959 activated by a Commit Command (see Section 9.1.10).
960 • The Command Transport Protocol layer losing confidence in the Control Data Stream (see
961 ###XREF). This protects against incorrect synchronization and/or excessive bit errors.
962 • PHY-specific conditions causing the PHY to lose lock (e.g., see PHY3, DLV ###XREF). This
963 protects against incorrect synchronization and/or excessive bit errors.
964 • PHY-specific conditions causing the PHY to be deactivated (e.g., see PHY3, DLV ###XREF) and
965 so activate the Peripheral Management Action (See Section 5.1.3). This is similar to the preamble
966 used to guarantee that reset can be signaled.
967 • Other, implementation-defined, sources of reset, e.g., external dedicated pins or pin conditions.

42 Copyright © 2019–2024 MIPI Alliance, Inc.

4.6 Typical Link Management Sequences

968 ###TODO: No need to move this to the Link Control section. It’s good to say HERE that Cold Boot
969 will start in a “standard” setting, use Commands to write registers and then switch to the desired
970 clock config etc. NOTE that this summary description is PHY-agnostic.
971 ADD a set of steps for changing Clock Config (which needs PM_Action:Force_Resync in PHY3,
972 DLV).
973 Note:
974 Some parts of these sequences are specific to the DLV PHY, and will differ for systems using other
975 Audio-mode PHYs.

4.6.1 Comparing Cold Booting with Warm Booting (aka Sleep-Wake).

976 A SWI3S Peripheral interface has two low-power Inactive Link States when it is not using the Audio-mode
977 PHY to communicate:
978 Sleeping: all register values and state are retained (used for sleep-wake), optimized for quick
979 wake-up.
980 Cold_Standby: register state returns to the Cold Reset values, optimized for minimal to zero
981 internal power consumption.
982 The time taken to start a SWI3S Link is dependent upon several factors, such as the number and complexity
983 of Peripheral Devices, and this might be be delayed by the Host waiting for hardware clock sources to
984 stabilize or for software initialization to complete. However, some estimates of typical “time to audio”
985 delays for the SWI3S Link itself are:
986 • Exit from Sleeping (used for sleep-wake) is < 1 msec.
987 • Exit from Cold_Standby (used for cold boot) is typically ~ 2 msec.

4.6.2 Cold Booting a Link (including Power-On)

988 When Peripheral Devices are powered up, the SWI3S interface will receive an initial Cold Reset. Cold
989 Resets can also be generated by the Manager either by commiting a PM_Action of “Enter_Cold_Standby”
990 (see Section 4.6.3) or by using a Bus Reset sequence at any time.
991 A typical sequence of steps for cold-booting a SWI3S Link using the DLV PHY is:
992 1. [optional] If the link is currently active (i.e., the Manager is currently using an Audio-mode PHY
993 to communicate with Peripherals) then:
994 A. The Manager forces all Peripherals into an Inactive Link State (i.e., Cold_Standby or
995 Sleeping), (see Section 4.6.3).
996 2. The Manager generates the Cold Start Sequence (see Figure 24 in Section 4.5.2.4), activates its
997 Audio-mode PHY, and starts generating Rows that each include one bit of the Control Data Stream
998 containing valid Command Transport Protocol.
999 3. [Optional] Initial Manager PHY Calibration. In parallel with Steps #4 and #5, the Manager might
1000 perform internal PHY calibration to optimize its internal timing, e.g., to adjust for internal path
1001 delays. (This optional process is implementation-defined.)
1002 4. The Manager attempts to synchronize all Peripherals by generating frequent Ping Commands
1003 using the “default” configuration (which was loaded into the *_CURR registers by the Cold Reset
1004 in Step #2), which is:
1005 A. Safe-Lock-4 Clock Config, i.e., 4 Columns and 2.40 to 3.20 MRows/sec (9.6 to 12.8 Mbps),
1006 and
1007 B. Command-Only Transport Pattern (and thus a single rising edge per Row), and
1008 C. Peripherals using “Special drive” (passive 1 / active 0) on the CDS stream to respond to
1009 Commands.

Copyright © 2019–2024 MIPI Alliance, Inc. 43

1010 5. The Manager waits for the Ping Command results to indicate that all expected Peripherals are
1011 attached.
1012 Note: DLV:Safe-Lock-4 has no audio streaming capability. If a boot sequence wants to generate
1013 sounds at this time then it needs some simple tone generation capability internal to the amplifier
1014 that can be controlled by writing to registers.
1015 6. The Manager programs *_NEXT Registers in the Peripherals with parameters ready for “normal”
1016 operation including:
1017 A. PHY transceiver parameters such as output amplitude, drive strength, slew time, drive type.
1018 B. Clock Config parameters within the PHY-specific range of Column Count (4 to 32), Row Rate
1019 Hint (nominal 600 kRows/sec to 6 MRows/sec), and UI Hint (nominal 4.8 to 76.8 Mbits/s).
1020 C. Link transport parameters: e.g., new position and width of Control Data Stream within the
1021 “normal” Transport Pattern.
1022 7. [Optional, e.g., in systems where the Link will switch to a slower Row Rate and thus lower CDS
1023 bandwidth than is available in Safe-Lock-4] The Manager programs Registers in the Peripheral,
1024 e.g.:
1025 A. Data Port transport settings ready for later use.
1026 B. Other system-specific setup.
1027 8. The Manager performs an SSCR Command to commit the new parameters from Step #6:
1028 A. The Manager and Peripherals switch to using the new PHY transceiver parameters, Clock
1029 Config, and Transport Pattern synchronously with the SSCR Commit Point.
1030 9. The Manager attempts to synchronize all Peripherals by generating frequent Ping Commands
1031 using the new Clock Config and Transport Pattern (Command-Only and thus a single rising edge
1032 per Row) that were prepared in Step #6 and committed in Step #8.
1033 10. The Manager waits for the Ping Command results to indicate that all expected Peripherals are
1034 attached.
1035 11. [Optional] Manager PHY Calibration. In parallel with Steps #9 and #10, the Manager might
1036 perform internal PHY calibration to optimize its internal timing, e.g., to adjust for internal path
1037 delays. (This optional process is implementation-defined.)
1038 12. [Optional] The Manager uses DLV Calibration Commands to perform PHY calibration on the
1039 attached Peripherals with the current operation settings (see Section 9.1.12).
1040 Note: This step might be omitted in systems with very short links at low bit rates.
1041 13. [Optional] If the initial “normal” speed Transport pattern was using wide CDS bits then, after
1042 Peripheral PHY Calibration is complete, the Manager might reprogram the Command Transport
1043 parameters to reduce the number of Columns being used for the Control Data Stream, and use an
1044 SSCR to commit the changes.
1045 Note: The initial “normal-speed” Transport Pattern in Step #9 uses a CDS width that is wide
1046 enough for successful communication between Manager and Peripherals, even before they have
1047 calibrated their PHYs at the new Clock Config. This CDS width could be as small as 1 or 2
1048 Columns or as large as ColumnCount/4 used with Special Drive Mode so that the waveform on the
1049 bus mimics that of Safe-Lock-4.
1050 The Manager can now issue Commands to start audio payload transport, see Section 4.6.6.

44 Copyright © 2019–2024 MIPI Alliance, Inc.

4.6.3 Placing an Active Link in Cold_Standby

1051 When the Link is currently active, the Manager can send all Peripheral Devices to the “Cold_Standby”
1052 Link State. A typical sequence of steps is:
1053 1. Gracefully manage the shut down of audio output streams, if needed.
1054 2. Program a PM_Action register value of Enter_Cold_Standby in all Peripheral Devices.
1055 3. Use an SSCR Command to commit the PM_Action.
1056 4. Generate the PHY-specific Idle condition (e.g., for PHY #3, a static value of DLV:0), which will
1057 trigger the PHY_Inactivity detector in the Peripheral Devices even if they missed the instruction to
1058 enter Cold_Standby.
1059 5. Deactivate the Audio-mode PHY.
1060 6. Generate the Link Control Idle condition (DP=LC:0 and DN=LC:0), which will send all
1061 Peripherals to an Inactive Link State (Cold_Standby or Sleeping).
1062 When the Manager subsequently uses the Cold Start sequence to bring the Peripherals out of
1063 Cold_Standby or Sleeping, the Peripheral Devices will have their Cold Reset values in all Registers
1064 and the sequence of steps will start from Step #1.A in Section 4.6.2.
1065 Note:
1066 The Manager normally uses the above steps for an orchestrated entry into the “Cold_Standby” Link
1067 State, but it can directly force all Peripheral Devices on the Link to the Cold_Standby Link State by
1068 using a Bus Reset.

4.6.4 Placing an Active Link in Sleeping

1069 When the Link is currently active, the Manager can send all Peripheral Devices to Link State:
1070 Sleeping, which could be thought of as “Warm Standby” in contrast with Link State: Cold_Standby. A
1071 typical sequence of steps is:
1072 1. Gracefully manage the shut down of audio output streams, if needed.
1073 2. Program the *_NEXT Registers in all Peripheral Devices with any changes to the Transport Pattern
1074 that will be used when the system wakes up, e.g., using Wide Bits for the Control Data Stream.
1075 3. Program a PM_Action value of Enter_Sleeping in all Peripheral Devices.
1076 4. Use an SSCR Command to commit the PM_Action and any changes to Clock Config and
1077 Transport Pattern from Step #2.
1078 5. Generate the PHY-specific Idle condition (e.g., for PHY #1, static values of DN/Clock=FBCSE:0
1079 and DP/Data=FBCSE:0), which triggers the PHY_Inactivity detector in the Peripheral Devices
1080 even if they missed the instruction to enter Sleeping.
1081 6. Deactivate the Audio-mode PHY.
1082 7. Generate the Link Control Idle condition (DP=LC:0 and DN=LC:0), which sends all Peripherals
1083 to Link State: Sleeping.
1084 When the Manager uses a Warm Start to wake the Link from Sleeping, the Peripheral Devices will
1085 remember most of their state (e.g., audio transport settings), but will have a small number of Registers
1086 changed to their Warm Reset values (e.g., Data Port channel enables all cleared to 0, and PM_Action
1087 field reset to Stay_Attached) and the sequence of steps will start from Step #1 in Section 4.6.5.

4.6.4.1 Preparing the Clock Config and Transport Pattern for Sleep-Wake
1088 When the Manager wakes the Peripherals from Sleeping, the Clock Config and Transport Pattern will be
1089 whatever had been prepared in the *_NEXT registers in the Peripheral(s), and that will have been
1090 committed into the *_CURR registers by the SSCR in Step #4 in Section 4.6.4 that caused the Peripheral to
1091 enter Sleeping.
1092 To give the quickest return to normal operation, this will typically be an identical Clock Config (Row Rate,
1093 Column Count, and Bit Rate) to what was in use before the Link was put to sleep. In some cases, the

Copyright © 2019–2024 MIPI Alliance, Inc. 45

1094 Transport Pattern might have small differences, e.g., programming the *_NEXT registers to restart the Link
1095 using Wide Bits for the Control Data Stream, so that it is capable of operating at high bit rates even if the
1096 PHY calibration has drifted during a long time in the Sleeping state.

4.6.5 Warm Booting (Wake)

1097 When Peripheral Devices has been placed into the Sleeping Link State (see Section 4.6.4), the sequence of
1098 steps to wake up the Link is shorter than the Cold Boot sequence in Section 4.6.2 and can omit Steps #4
1099 through #8 that use the PHY-specific Safe-Lock configuration. Thus, Warm booting is a much quicker
1100 operation, but the Peripheral Devices need to remember a lot of their state.
1101 A typical sequence of steps for the Manager warm booting a SWI3S Link using the DLV PHY is:
1102 1. The Manager generates the Warm Start Sequence (see Figure 25 in Section 4.5.2.5), activates its
1103 Audio-mode PHY, and starts generating Rows that each include one bit of the Control Data Stream
1104 containing valid Command Transport Protocol.
1105 2. The Manager attempts to synchronize all Peripherals by generating frequent Ping Commands
1106 using the “normal” configuration (that was prepared before the Sleep-Wake cycle, see
1107 Section 4.6.4.1), which is:
1108 A. [DLV] Clock Config parameters within the PHY-specific range of Column Count (4 to 32),
1109 Row Rate Hint (nominal 600 kRows/sec to 6 MRows/sec), and UI Hint (nominal 4.8 to
1110 76.8 Mbits/s).
1111 B. [DLV] Command-Only Transport Pattern (hence single rising edge per Row).
1112 3. The Manager waits for the Ping Command results to indicate that all expected Peripherals are
1113 attached.
1114 4. [Optional] Manager PHY Calibration. In parallel with Steps #2 and #3, the Manager might
1115 perform internal PHY calibration to optimize its internal timing, e.g., to adjust for internal path
1116 delays. (This optional process is implementation-defined.)
1117 5. [Optional] The Manager uses DLV Calibration Commands to perform PHY calibration on the
1118 attached Peripherals with the current operation settings (see Section 9.1.12).
1119 Note: This step might be omitted in systems with very short links at low bit rates.
1120 The Manager can now issue Commands to start audio payload transport, see Section 4.6.6.
1121 Note:
1122 The internal implementation-defined state used for PHY calibration will be retained through the
1123 Sleep-Wake cycle but the effects of this can drift over time and temperature, so the Manager and
1124 Peripherals are typically re-calibrated when they wake up (Step #4 and Step #5).

4.6.6 Starting Audio Payload Transport

1125 1. Program the transport parameters in the *_CURR registers in Data Ports.
1126 2. Write the PrepareCh<c> bits to initiate the prepare operation.
1127 3. Poll the ReadyCh<c> until Peripherals indicate that they are ready.
1128 4. Program the EnableCh<c>_Next registers in Data Ports.
1129 5. Issue an SSCR Command to commit all of the EnableCh<c>_NEXT fields into the
1130 EnableCh<c>_CURR fields to start the audio streams.

4.6.7 Moving an Active Payload Stream within the Transport Pattern

1131 1. Program the new transport parameters in the *_NEXT registers in the Data Ports.
1132 2. Issue an SSCR Command to commit all of the *_NEXT registers into the *_CURR registers to
1133 reconfigure the audio streams.

46 Copyright © 2019–2024 MIPI Alliance, Inc.

1134 Note:
1135 The Manager will align an SSCR to the current SSPs to avoid disrupting Data Port operation so
1136 that this transition in the transport is seamless, and no other streams are perturbed.

Copyright © 2019–2024 MIPI Alliance, Inc. 47

4.7 System Architectures

1137 A SWI3S Link comprises one SWI3S Manager and 1 to 12 SWI3S Peripherals connected to a single set of
1138 physical conductors (a SWI3S bus). A complete system architecture might contain several SWI3S Links,
1139 which could use different Row rates and column counts, and possibly even different PHYs.
1140 Section 4.7.1 discusses system topologies where a system is partitioned across multiple Links.
1141 Section 4.7.2 discusses several choices for physical topology, which describes the relative physical
1142 positioning of Manager and Peripheral(s) within a Link. The constraints on these positions are dependent
1143 on the choice of PHY.
1144 Section 4.7.3 discusses logical topology, which describes what types of data can flow between which pairs
1145 of devices. This can also be dependent on the choice of PHY.

4.7.1 System Topologies

4.7.1.1 Links in Parallel (Multi-Manager Controllers)

1146 A more complex system can be partitioned across multiple SWI3S Links, e.g., to provide higher bandwidth,
1147 longer physical topologies, or domains for power management. Figure 27 shows an example of a system
1148 using multiple SWI3S Links, with 5 microphones and 2 amplifiers distributed across 2 links.

Peripheral Peripheral Peripheral Peripheral Peripheral

Mic #1 Mic #2 Mic #3 Multi-Manager Controller Mic #4 Mic #5

Manager Manager
SWI3S Link #1 SWI3S Link #2
#1 #2

Peripheral Peripheral
Amp #1 Amp #2
1149
Figure 27 An Example System Using Multiple SWI3S Links

4.7.2 Physical Topologies

1150 SWI3S interfaces can be deployed in a range of physical link topologies, with some PHY properties being
1151 programmable to provide the best performance in a given system scenario. This section (4.7.2) introduces
1152 generic physical topologies. ###XREF-to-AnnexD describes the effects of signal reflections within these
1153 physical topologies, how this affects PHY performance, and how it can be mitigated.
1154 Depending upon the PHY in use in a system, signal reflections in the physical medium will have a larger or
1155 smaller influence on the limits of operating conditions. A real physical medium will have imperfections
1156 such as impedance variations or discontinuities, or stubs connecting to devices, so the signal waveforms
1157 will suffer other perturbations. System designers will typically perform signal integrity simulations to
1158 verify that a system will operate correctly given a particular combination of PHY, physical medium,
1159 operating frequency, programmable PHY settings, and link settings such as Transport Pattern (see
1160 Section 10).

48 Copyright © 2019–2024 MIPI Alliance, Inc.

1161 Figure 28 shows the simplest possible physical topology: a point-to-point Link to a single Peripheral. This
1162 facilitates highest bandwidth or longest separation of the Manager and Peripheral.

Manager

P
1163
Figure 28 Physical Topology: Point-to-Point

1164 Figure 29 illustrates a generic physical topology with Peripherals distributed along a broadly linear signal
1165 path on the physical medium, and the Manager positioned anywhere on that signal path. This topology
1166 could be referred to as “generic multi-drop”.

Manager

P P P P P P P P
1167
Figure 29 Physical Topology: Generic Multi-Drop

1168 Figure 30 shows a physical topology in which the Manager is positioned at one end of the medium, but
1169 there is no constraint on the position of Peripherals, so it is a special case of multi-drop, but one that is
1170 commonly used to reduce signal integrity issues.

Manager

P P P P P P P P
1171
Figure 30 Physical Topology: Multi-drop – Manager-at-End

Copyright © 2019–2024 MIPI Alliance, Inc. 49

1172 Figure 31 shows a further special case of the Manager-at-End physical topology from Figure 30 in which
1173 Peripherals are positioned within a limited distance of the far end of the medium. This has the effect of
1174 limiting the maximum time between when a Peripheral receives the incident wave from the Manager, and
1175 the corresponding reflection of that wave from the far end of the medium. This topology is named
1176 “Star-on-a-Stick” because it resembles a star topology attached to a longer (stick) section containing no
1177 Peripherals.

P-far

short
Manager
short

P-far

short
P-far
1178
Figure 31 Physical Topology: Star-on-a-Stick

1179 Figure 32 shows a different special case of the Manager-at-End physical topology in which the Peripherals
1180 are positioned in a group at the far end of the medium from the Manager. This topology has similar
1181 advantages to the star-on-a-stick, in that Manager-to-Peripheral and Peripheral-to-Manager communication
1182 are each relatively easy (e.g., not needing Wide Bits). This topology is named “Toothbrush” because it
1183 resembles the bristles on a toothbrush.

Manager
(short)

P-far P-far
1184
Figure 32 Physical Topology: Toothbrush

1185 Figure 33 shows a different special case of the Manager-at-End physical topology in which the Peripherals
1186 are positioned in one of two groups near to each end of the medium. This is similar to the Manager-at-End
1187 topology, but the close spacing of the groups of peripherals might mean that handover between transmitters
1188 within these groups can be shorter. This topology is named “Dumbbell” because it resembles the weights
1189 being distributed at the end of a dumbbell bar.

Manager

(short) (short)

P-near P-near P-far P-far

1190
Figure 33 Physical Topology: Dumbbell

50 Copyright © 2019–2024 MIPI Alliance, Inc.

4.7.3 Logical Topology

1191 A given Link Configuration provides particular logical connections between Manager and Peripheral(s) in
1192 that system. These logical connections describe which types of data can be transported between different
1193 components on the link. This is related to, but not the same as, the physical topology of the link.
1194 The SWI3S control channel transports control and status information between the Manager and each of the
1195 Peripherals. There is no control-level communication directly from one Peripheral to another. This feature
1196 is different to the communication in a SoundWire system (see [MIPI01]), in which some control
1197 information (to indicate command errors) is passed directly from one Peripheral to another.
1198 In SWI3S, payload data (typically audio streams) can be transported from the Manager to one or more
1199 Peripherals, and from a Peripheral to the Manager. The payload transport programming includes the
1200 flexibility to support Peripheral to Peripheral transport. Depending on physical topology, this sometimes
1201 consumes extra bandwidth.
1202 Figure 34 illustrates three different logical topologies using SWI3S interfaces.

Single Peripheral
Control / Status
Manager Audio Stream(s) Peripheral #1

Multi-Peripheral
Control / Status
Audio Stream(s) P1

Control / Status
Manager Audio Stream(s) P2

Control / Status
Audio Stream(s) P3

Multi-Peripheral with Any-to-Any Audio Streams

Control / Status
Audio Stream(s) P1 P-to-P Audio Stream(s)

Control / Status
Manager Audio Stream(s) P2

Control / Status
Audio Stream(s) P3
1203
Figure 34 SWI3S Logical Topologies

1204 The logical topologies shown in the figure have the following properties:
1205 • Single Peripheral: One Manager communicates with one Peripheral. This configuration facilitates
1206 physical link topologies with electrically very difficult (e.g., long, or less uniform) physical paths
1207 between Manager and Peripheral.
1208 • Multi-Peripheral: One Manager communicates with any of up to 12 Peripherals. This
1209 configuration provides some flexibility for the system design, but imposes tighter constraints on
1210 the physical link topology and/or operating speed than a Single Peripheral configuration.
1211 • Multi-Peripheral with any-to-any payload: One Manager and up to 12 Peripherals communicate
1212 with each other. This is the most flexible system, but might need more sophisticated circuit
1213 analysis in order to program the devices correctly.

Copyright © 2019–2024 MIPI Alliance, Inc. 51

4.8 Physical Layer – PHY

1214 This Section summarizes the PHY Interface and the choice of PHYs described in this Specification.
1215 ###Note to Reviewers: this draft list of signals will be updated when the PHY subgroup finalize the
1216 PHY interface.

4.8.1 DRAFT: PHY-Agnostic View Presented to Higher Layers

1217 ###TODO-Author: bring this in line with new input from Mark Lewis.
1218 The relationship of higher layers to the Audio-mode PHY can be described via the PHY-agnostic concepts
1219 of bit ownership and Row clock, as shown in Figure 2. Annex C describes this informative PHY-Protocol
1220 Interface and PHY-agnostic model, which includes the following:
1221 Signals to or from higher layers:
1222 BitClock: One cycle per column.
1223 RowClock: One cycle per Row.
1224 DataIn: Data captured from the Link.
1225 DataOut: Data to be transmitted to the Link (coming from multiple sources, including the
1226 Command Transport Protocol, and all Data Ports).
1227 DataOutValid: An indication of when this Device “owns” the data connection, i.e. when DataOut
1228 is to be transmitted onto the link.
1229 BitWidth: Data can occupy longer periods to allow for issues on the physical medium such as
1230 settling time for reflections, or timing uncertainty between recovered bit clocks in
1231 Peripheral-to-Peripheral streams. The transport clients give an indication of how long bits are, and
1232 sometimes when input data might be sampled within that period.
1233 CDS_DriveType: The Control Data Stream sometimes uses a special driving behavior (referred to
1234 as “Passive 1 / Active 0”), which is defined more exactly for each Audio-mode PHY.
1235 Status and Control to or from higher layers:
1236 Impedance_Control: ###TODO: detail.
1237 Slew_Rate_Control: ###TODO: detail.
1238 RowSync_Missed: (specific to Some PHYs, e.g., PHY3 DLV).
1239 Behavior in the PHY Interface Layer:
1240 Encoding/Decoding: Only applicable to PHYs that use encoding, e.g., NRZS in the FBCSE PHY.
1241 The DLV PHY does not have any encoding at this layer.
1242 Guard Bits: Adding extra output data with a static value at the end of a sequence of 1 or more
1243 output bits from a single source within this Device. This is used to minimize the impact of a
1244 datastream on the spectral content of the bus.
1245 Tail Bits: Extending the drive of whatever value was last output from this Device at the end of a
1246 sequence of output bits (and Guard bits). This helps to absorb any reflections on the physical
1247 medium, and so reduces ISI from this Device to the next owner (e.g., when that next owner is the
1248 Manager transmitting a DLV Sync sequence).
1249 End-Half-Column-Early: When the Device transmits the last bit of a group of bits owned by one
1250 or more sources (Data Ports or CDS), the actual output drive ends half a column early. This drive
1251 method relies on bus capacitance (and the bus keeper) to maintain the signal beyond the end of the
1252 time when it is actively driven so that it can still be correctly sampled in the receiving Device.

52 Copyright © 2019–2024 MIPI Alliance, Inc.

1253 Note:
1254 The End-Half-Column-Early feature gives finer granularity of handover periods to yield denser
1255 packing of data in systems where the topology and bitrate allow this. See Section ###XREF.
1256 The details of how some of these concepts are implemented are a property of each PHY (e.g., recovered bit
1257 clock versus forwarded bit clock), and are described in the Section for each PHY. This Specification
1258 includes PHY-specific sub-sections where other behavior is affected by the Audio-mode PHY that is in use:
1259 • PHY-Specific Bits and UIs in Section 10.1.5.4.
1260 • Reset and Link Management in Section 5.1.11.
1261 • Registers for each PHY within Section 14.2.

4.8.2 PHY1 and PHY2: FBCSE Forwarded-Bit-Clock Single-Ended

1262 Note:
1263 This Section is a brief summary of the forwarded-bit-clock single-ended PHY (FBCSE PHY), which
1264 is specified in detail in Section 11.
1265 This PHY could be deployed in system scenarios to enable simpler devices, or for lower total link power
1266 consumption.

4.8.2.1 Summary of Features

1267 Features of the FBCSE PHY include:
1268 • 2-pin interface using full-swing single-ended signaling with control over slew time and output
1269 impedance.
1270 • Simple interface with low power receiver.
1271 • Simple clocking with one pin dedicated to a forwarded bit clock from the Manager to the
1272 Peripheral(s).
1273 • One data signal shared between Manager and Peripherals.
1274 o Fast handover between different transmitters (0 or more bit times).
1275 o The data signal can be used for transmission between any pair of devices (including
1276 direct Peripheral to Peripheral).
1277 • Manager signaling includes a forwarded bit clock for Peripherals to:
1278 • Use as an audio quality sample clock, if desired.
1279 • Control transport.
1280 • Align higher layers with Row boundaries (by also observing the Command Protocol in the
1281 Control Data Stream).
1282 • Supports a range of physical link topologies:
1283 • Trade-off between bandwidth and distance.
1284 • Multi-drop capability.
1285 • Supports a range of link speeds:
1286 • Link can easily switch between a wide range of speeds to support lower power operation for a
1287 range of systems scenarios.
1288 • Raw transport bandwidth of, e.g., 6 to 76.8 Mbps (24 Mbps in typical scenarios).
1289 • Row rates to suit audio application, e.g., 768 kRows/s or 3.072 MRows/s.

Copyright © 2019–2024 MIPI Alliance, Inc. 53

1290 • Supports 2 methods of operation (which are viewed as 2 distinct PHYs):

1291 • PHY1: intra-UI handover for lower bandwidth scenarios (power saving from lower clock
1292 speed).
1293 • PHY2: UIs are explicitly scheduled for handover (tighter control of timing enables shorter UIs
1294 / higher bitrates).

4.8.2.2 System Considerations for FBCSE PHY

1295 The electrical characteristics (Tx output levels: V_OH and V_OL, and Rx: input levels: V_IH and V_IL)
1296 are specified to accommodate a certain amount of ground shift between devices due to system-level
1297 properties (see detailed specifications in Section 11.###XREF).
1298 In a system design where the ground shift is larger then it might be necessary to operate the FBCSE PHY at
1299 higher Vdd (1.2 V or 1.8 V) or even change the system design to components that use the DLV PHY.

4.8.3 PHY3: Differential Low Voltage (DLV)

1300 Note:
1301 This Section is a brief summary of the DLV PHY, which is specified in detail in Section 11.3.
1302 This PHY could be deployed in system scenarios which are more sensitive to EMI/EMC or need higher bit
1303 rate, or for lower total link power consumption.

4.8.3.1 Summary of Features

1304 Features of the DLV PHY include:
1305 • 2-pin interface using differential low-voltage signaling and controlled slew times:
1306 • Provides low EMI emissions and low EMC susceptibility.
1307 • Serial terminated drivers and unterminated receivers, facilitating low-power systems.
1308 • Sharing of one data connection between Manager and all Peripherals:
1309 • Fast handover between different transmitters (1 or 2 bit-times).
1310 • Support for direct Peripheral to Peripheral transmission.
1311 • Manager signaling includes a periodic Row Sync signal for Peripherals to:
1312 • Use as an audio quality sample clock.
1313 • Recover the bit clock for transport.
1314 • Align higher layers with Row boundaries for transport.
1315 • Register control over a number of parameters to provide trade-offs between power, speed, EMI,
1316 etc.
1317 • Supports a range of physical link topologies:
1318 • Distance up to 200 cm (for simpler Links such as point-to-point or slower data rates).
1319 • Multi-drop capability (on shorter links).
1320 • Supports a range of link speeds:
1321 • Raw transport bandwidth of up to 76 Mbps (for shorter physical Links).
1322 • Row rates to suit audio application, e.g., 3.072 MRows/s.
1323 • Link can switch to lower speed for lower power modes when the system needs less transport
1324 bandwidth, e.g., lower sample rates in always-on scenarios.
1325 • Some support for system robustness:
1326 • Ability to survive missing Row Syncs without terminating payload streams (e.g., due to brief
1327 interruption to physical connection in links containing connectors).

54 Copyright © 2019–2024 MIPI Alliance, Inc.

4.8.3.2 Effects of Physical Topology on DLV PHY

1328 This section (4.8.3.2) illustrates some typical physical link topologies that were considered when
1329 developing the Specification for the DLV PHY.
1330 Note:
1331 ###XREF-to-AnnexD discusses some of the generic effects of signal integrity on the dimensions of
1332 Links including waveform diagrams of reflections in relatively simple systems.
1333 The DLV PHY uses source-terminated drivers and unterminated receivers, so there will be signal
1334 reflections present on the physical medium.
1335 For Links that are short or that use low bit rates the system designer can program slower rise/fall times for
1336 the DLV PHY output driver such that the signal reflections can be ignored (rise/fall time > round trip
1337 propagation delay).
1338 For Links that are longer or use high bit rates, where the received Sync signal could be affected by physical
1339 layout, the system designer can mitigate the effects of the reflections by programming slew rate and drive
1340 strengths, or allocating more link time to the Sync signal. Additionally, the data transport can be
1341 programmed to use longer bit periods (Wide Bits) and/or Tail bits to absorb reflections and limit the ISI.

4.8.3.2.1 DLV PHY: Medium Length Multi-drop Link

1342 Figure 35 shows an example of a multi-drop Link using the DLV PHY, e.g., in a large tablet. Typical
1343 settings programmed for a Link of this size are:
1344 • Medium rise times (medium bit rate, e.g., 24 Mbps).
1345 • Shortest data bits and shortest handovers (giving highest bandwidth utilization).
1346 Note:
1347 The typical achievable bus diameter in this example is larger than that for the same bitrate using
1348 SoundWire, [MIPI01].

Manager

60 cm

P P P P P P P P
1349
Figure 35 DLV PHY, Example of a Medium Length Multi-Drop Physical Topology

4.8.3.2.2 DLV PHY: Shorter Multi-drop Link

1350 Figure 36 shows an example of a short Link using the DLV PHY, which is small enough that it might not
1351 need such sophisticated signal integrity analysis to choose the parameters. Typical settings programmed for
1352 a Link of this size are:
1353 • Shortest rise times (higher bit rate, e.g., 76.8 Mbps).
1354 • Shortest data bits and shortest handovers (giving highest bandwidth utilization).
1355 Note:
1356 The typical achievable bitrate is in this example is higher than that for the same sized link using
1357 SoundWire, [MIPI01].

Copyright © 2019–2024 MIPI Alliance, Inc. 55

Manager

30 cm

P P P P P P P P
1358
Figure 36 DLV PHY, Example of a Shorter Multi-Drop Physical Topology

4.8.3.2.3 DLV PHY: Long Point-to-Point Link

1359 Figure 37 shows an example of a Long point-to-point Link using the DLV PHY, e.g., distributing data to a
1360 hub in an all-in-one. Typical settings programmed for a Link of this size are:
1361 • Short rise times (allowing high bit rate).
1362 • Short data bits (giving high bandwidth utilization).
1363 • Transport Pattern with minimum handovers per Row to minimize wasted bandwidth (e.g., some
1364 Rows of Manager output only).
1365 • Longer Sync0 part of the Sync sequence (to quiesce the bus before the Sync Edge).

Manager

200 cm
P-far
1366
Figure 37 DLV PHY, Example of a Long Point-to-Point Physical Topology

4.8.3.2.4 DLV PHY: Star-on-a-Stick Link

1367 Figure 38 shows an example of a star-on-a-stick Link topology using the DLV PHY. Typical settings
1368 programmed for a Link of this size and topology are:
1369 • Shorter rise times (allowing high bit rate).
1370 • Manager to/from Peripheral: short data bits, tails, and short handovers (giving good bandwidth
1371 utilization).
1372 • Peripheral to Peripheral audio streams: long data bits (“Wide Bits”) and short handovers from one
1373 peripheral to another (giving medium bandwidth utilization).

P-far

Manager
5 cm

100 cm 5 cm

P-far
5 cm

P-far
1374
Figure 38 DLV PHY, Example of a Star-on-a-Stick Physical Topology

56 Copyright © 2019–2024 MIPI Alliance, Inc.

4.8.3.2.5 DLV PHY: Dumbbell Link

1375 Figure 39 shows an example of a dumbbell Link topology using the DLV PHY, e.g., mics and speakers on
1376 2 sides of a tablet. The peripherals are in 2 groups, at the near and far ends relative to the manager. Typical
1377 settings programmed for a Link of this size and topology are:
1378 • Lowering drive impedance to give good Sync signals.
1379 • Manager to/from Peripherals: short data bits and short handovers (giving good bandwidth
1380 utilization).
1381 • Peripheral to Peripheral: long data bits (“Wide Bits”) and short handovers between peripherals
1382 within one group (giving medium bandwidth utilization).
1383 • Longer handovers between peripherals in the two different groups (lower bandwidth
1384 utilization).

Manager

60 cm
5 cm 5 cm

P-near P-near P-far P-far

1385
Figure 39 DLV PHY, Example of a Dumbbell Physical Topology

Copyright © 2019–2024 MIPI Alliance, Inc. 57

4.9 Registers
1386 Note:
1387 This Section is an overview of the Registers, which are specified in detail in Section 14.

4.9.1 Address Map

4.9.1.1 Top Level Address Map

1388 At the top level, the 4 GBytes of register address space is segregated into:
1389 • Address Space managed within the SWI3S Registers defined by this Specification (some
1390 mandatory, some optional, and some conditional upon other implementation choices, such as the
1391 number of Data Ports).
1392 • Reserved addresses to be assigned in a future version of this Specification.
1393 • Addresses assigned to registers and memory defined in the SoundWire Device Class for Audio
1394 Specification, see [MIPI02].
1395 • Addresses assigned for implementation-defined extensions (both registers and memory).

4.9.1.2 Register Blocks

1396 The SWI3S Registers within this specification are further divided into blocks relating to behavior in
1397 different layers, indicated by the initial part of the Register Field name:
1398 DPN_*: 1 block for each Data Port, which control the payload transport parameters.
1399 SLC_*: 1 block for system and link control (e.g., status, interrupts, nColumns, RowRateRange,
1400 CDS_Transport).
1401 PHY_*: 1 block for each PHY, which control transceiver parameters: drive strength, slope time
1402 etc.
1403 The address assignments with these blocks are optimized for quick start after cold boot, so that writing one
1404 set of consecutive registers within each of these blocks is sufficient.

4.9.2 Interrupts
1405 This Section is an overview of Interrupts, which are specified in detail in Section 15.
1406 SWI3S provides a similar model to the SoundWire interface ([MIPI01]) for reporting asynchronous events
1407 in various layers within the Peripheral Device, referred to as interrupts. There are registers for bitwise
1408 interrupt status/clear and interrupt enable that are read and written using normal read and write commands.
1409 These registers are arranged within the address map to provide efficient gathering of status with multi-byte
1410 reads. The Manager can determine which Peripheral Devices have one or more active interrupts that need
1411 attention by examining the status that can be collected from every Peripheral Device with a single Ping
1412 command.
1413 The sources of interrupts within a SWI3S Peripheral Device are:
1414 • SWI3S Error Indications from various layers, e.g,:
1415 • Data Ports (Port ready, PRBS testing failure).
1416 • Control Data Transport (8b/10b decoder and CRC).
1417 • Command Transport Protocol (incorrectly formatted Commands).
1418 • …
1419 • SSP indication received at unexpected time.
1420 • Other parts of the Device outside the SWI3S Peripheral interface:
1421 • Implementation-defined device-specific behavior (e.g., thermal overload in amplifiers).
1422 • Standard interrupts described in other specifications, e.g., SDCA ([MIPI02]).

58 Copyright © 2019–2024 MIPI Alliance, Inc.

4.9.2.1 Device Status vs Interrupt Status

1423 Some events have bitwise status and clear operation similar to interrupts, but do not have an associated
1424 enable bit because they are expected to be accessed using polling. The sources of DevStat conditions within
1425 Peripherals include:
1426 • Peripheral link status (e.g., Device detaching from the bus because of PLL losing lock or
1427 Command decoder losing confidence).
1428 • Data Ports (SSPs received OK).

4.9.3 Error Counters

1429 The SWI3S Specification provides some support for debugging, tuning, and monitoring the health of a
1430 running system. A SWI3S Peripheral Device can detect a number of non-fatal error conditions (e.g., data
1431 corruption in the Control Data Stream that was detected by a CRC failure). The number of occurrences of
1432 each error can be accrued in a saturating counter (i.e., one that stops at its maximum value without
1433 wrapping round to 0), and a non-zero counter value can be reported via an interrupt.
1434 The error counters are assigned to addresses in the system control (SC_*) block.

4.9.4 Register Synchronization Model (Dual-Ranked Registers and Commit

Commands)
1435 For some operations it is desirable to prepare updates to multiple registers and then commit those updates
1436 simultaneously. This Specification describes a mechanism to meet this need, named Dual-Ranked
1437 Registers, and Commands to initiate the commit operation, named SSCR and DSCR.
1438 Dual-Ranked Registers have a Current Value Register (CVR) that controls current operation of a Device,
1439 and a Next Value Register (NVR) that contains a value set up in advance of a simultaneous change to
1440 multiple control values. Dual-Ranked Registers are described in more detail in Section 14.1.3.
1441 Note:
1442 Fields in Current and Next Value Registers can be identified by their names ending in “_CURR” and
1443 “_NEXT” respectively.
1444 A Commit operation is used to copy the values from the Next Value Registers to the Current Value
1445 Registers. The scope of the Commit operation might be part or all of one Device, or part or all of multiple
1446 Devices within a system. SSCR and DSCR Commands generate the same Commit operation on
1447 Dual-Ranked Registers.
1448 The 2 Commands differ only in that SSCR also indicates a Stream Synchronization Point to all of the Data
1449 Ports that are selected by the Command. Thus, SSCR is used for updating Registers synchronously with
1450 payload operations, and DSCR can be used when it is acceptable for the update to be unsynchronized to
1451 payload operations (which gives the Manager the fÁreedom to schedule the DSCR at any time).
1452 SSCR and DSCR Commands are described in detail in Section 9.1.10.

4.9.4.1 Summary of Synchronization Commands

1453 Summary of Synchronization Commands:
1454 • SSCR and DSCR Commands cause a Commit Synchronization Point (CSP).
1455 • SSCR and SSPA Commands cause a Stream Synchronization Point (SSP).

Copyright © 2019–2024 MIPI Alliance, Inc. 59

5 Link Control & Reset

1456 ###TODO-Author: remove these temp notes after verifying that the normative and informative material
1457 both match this.
1458 Expanding on descriptions in Table 5.
1459 Bad_Command_Confidence (changing from Attached to Syncing). “Resetting this counter” depends on
1460 only (1) the Header being error--free and (2) this Device being selected and (3) count < 8192.
1461 TODO on at least an informative diagram or informative text: define the exact CDS bits from which
1462 counting occurs. DRAFT: the StartOfRow (i.e., the start of Column 0) following the 10th CDS bit of the
1463 last Robust Token in the Header. QUESTION: Is this sufficient decision time? Do we need to be exacting
1464 about which Row the Device detaches (and hence stops the Data Port)? The ChannelEnables will all change
1465 to 0 at the StartofRow following the 8192nd bit (that failed to contain the last bit of a valid header).
1466 Definition: “good header means SPM and all Robust Tokens contain no 8b10b errors AND this Device is
1467 addressed by the Device Mask,
1468
1469 Row x contains 10th bit of the last token of a good header
1470 Row x+8190 contains 10th bit of the end of a good header => stay attached
1471
1472 Row x contains 10th bit of the last token of a good header
1473 Row x+8191 contains 10th bit of the end of a good header => stay attached or fall off
1474
1475 Row x contains 10th bit of the last token of a good header
1476 Row x+8192 contains 10th bit of the end of a good header => stay attached or fall off
1477
1478 Row x contains 10th bit of the last token of a good header
1479 Row x+8193 contains 10th bit of the end of a good header => fall off
1480
1481 ###TODO-Eddie: draw the diagram with a clear threshold and zero uncertainty.
1482
1483 Christian’s proposal:
1484 A Peripheral SHALL detach due to Bad Command Confidence if there is no good header for 8193 Rows.
1485 A Peripheral MAY detach due to Bad Command Confidence if there is no good header for 8191 Rows.
1486 A Peripheral SHALL not detach due to Bad Command Confidence is there is a good header within 8190
1487 Rows.
1488
1489 Command_Sync_is_OK (changing from Syncing to Attached). This depends on (1) the Header being
1490 error-free and (2) this Device being selected and (3) this being a Ping Command and (4) Manager Packet
1491 being error-free (8b10b and CRC).
1492 The Bad_Command_Confidence counter will have started counting FROM ZERO in the Row after the 10th
1493 bit of the last token of the Header in this Ping Command.
1494 If there is an error in the Manager Packet then the Peripheral will not become Attached, so the value of the
1495 Command_Confidence counter is irrelevant.

60 Copyright © 2019–2024 MIPI Alliance, Inc.

1496 Note on clock-gating: the Peripheral does need to count the 30 Rows after the good header before it has
1497 confirmed that it will become attached.
1498
1499

5.1 Description (informative)

5.1.1 Overview

5.1.1.1 Link States

1500 Figure 40 shows a simplified high-level view of the Link States in the Peripherals and Manager. When the
1501 Manager moves between Inactive and Active states it co-ordinates the Peripherals on the Link moving
1502 along with it.
1503 • The Link-Inactive states facilitate very low power consumption in the Manager and Peripherals.
1504 The Manager holds the bus in a low power condition with the DP and DN signal lines both low.
1505 The Manager uses Link Control signaling (simple low-speed full-swing signaling using the Link
1506 Control PHY) to change the link to the active state.
1507 The Peripheral has 2 different Link-Inactive states: Sleeping, which preserves the SWI3S register
1508 values and internal state to allow a rapid Sleep-Wake cycle, and Cold_Standby, where register
1509 values and other state are not preserved, and recovery always includes a Cold Reset similar to the
1510 effect of a power-on reset. Some Peripheral designs might remove power from almost all of the
1511 SWI3S interface while in Cold_Standby.
1512 • The Link-Active state facilitates transport of all of Commands, audio payload, and sampling
1513 clock, using an “Audio-mode PHY”, such as PHY3 (DLV) described in Section 11.3. In normal
1514 usage a Commit Command (SSCR or DSCR) is used to cause all Peripherals to move
1515 simultaneously back to one of the Link-Inactive states.
1516 The general behavior in the Link-Active state is modeled using a number of sub-states (e.g.,
1517 Syncing and Attached), where the details of some of the behavior and conditions for state
1518 transitions are specific to the Audio-mode PHY that is in use.
1519 • The intermediate Activate_PHY and Deactivate_PHY states represent controlled transition
1520 between the different electrical signaling standards of the LC_PHY and the selected Audio-mode
1521 PHY.

Copyright © 2019–2024 MIPI Alliance, Inc. 61

Initial Cold Resets, e.g.:

• Internal POR detector
• ImpDef_Cold_Reset
Peripherals Manager

Cold Standby
Sleeping Bus Idle
Standby

Link Inactive Link Inactive

(using Link Control PHY) (using Link Control PHY)

ColdStart (includes BusReset & PHY_Select) Manager has generated

WarmStart (wake from Sleep) ColdStart or WarmStart
(Link Control PHY sequences)
Bus is in LC_Idle condition Manager has completed
(Link Control PHY: 0,0) parking the bus at LC:Idle

Activate Deactivate Activate Deactivate

PHY #n PHY #n PHY #n PHY #n

PHY Ready PHY#n-specific PHY-Inactivity condition, PHY Ready

typically some time after commiting a
Peripheral Management Action of:
Enter_Sleeping or Manager has completed
Enter_Cold_Standby parking the bus using PHY #n

Link Active Link Active

(using Audio-mode PHY, e.g., DLV) (using Audio-mode PHY, e.g., DLV)
1522
Figure 40 Link States
1523 Note:
1524 Both Manager and Peripherals have internal sources of the initial Cold Reset (such as POR) but
1525 thereafter the Manager is the source of the Bus Reset to the Peripherals (see Section 5.1.5).
1526 Note:
1527 Figure 40 is duplicated in the Technical Overview Section (as Figure 22 in Section 4.5.1).

5.1.1.2 Link Control Sequences (Overview)

5.1.1.2.1 Manager Link Control Sequences

1528 The Manager orchestrates behavior of the link, using in-band signaling on the bus to reset Peripherals and
1529 to change the Peripherals from Link-Inactive states that have minimal power consumption to Link-Active
1530 states when commands and payload data can be transferred. This Link Control Signaling (see
1531 Section 5.1.1.3) is described as an additional simple PHY (see Section 6), but a real implementation of this
1532 Link Control PHY might share circuitry with some of the Audio-mode PHYs described elsewhere in this
1533 Specification.
1534 The Manager uses one of 2 defined signaling sequences on the two link signal pins, DP and DN, to move
1535 the Peripherals to the Link-Active states. These sequences are:
1536 Cold Start: (see Section 5.1.2.4) used to start (or restart) operation when Peripherals have no previously
1537 configured state, such as after a power-on reset. This sequence comprises 3 parts:
1538 1. Bus Reset (see Section 5.1.5.3), which is a signaling sequence that will never occur on the bus
1539 during normal operation (i.e., when the Manager is using the Audio-mode PHY to communicate
1540 with Peripherals), and that forces all Peripherals to a known state. Peripherals can always detect
1541 the Bus Reset sequence independently of their current state: thus Cold Start can be used to recover
1542 Peripherals that have suffered errors or otherwise disconnected from the bus.
1543 2. PHY Selection, where the Manager transmits a 4-bit number to indicate to the Peripherals which
1544 Audio-mode PHY will be used when the link becomes active.

62 Copyright © 2019–2024 MIPI Alliance, Inc.

1545 3. PHY Activation edge, which directs all Peripherals to change to using the selected Audio-mode
1546 PHY and attempt to synchronize to the Control Data Stream from the Manager.
1547 Warm Start: (see Section 5.1.2.5) used to resume operation after Peripherals have previously been active
1548 using an Audio-mode PHY and then placed in the Sleeping Link State to save power. This sequence
1549 enables a short Sleep-Wake cycle and relies on the Peripherals preserving the state at various layers (e.g,
1550 PHY settings and calibration, clock rate ranges for clock recovery, Data Port registers for payload
1551 transport). Warm Start does not affect Peripherals that are in the Cold_Standby Link State.

5.1.1.2.2 Peripheral Link Control Requests

1552 Some Peripherals implement optional capability to generate a Link Control Request sequence
1553 (LC_Request, see Section 5.1.2.6) to ask the Manager to start the link. E.g., this could be used when an
1554 always-on microphone detects a keyword or when a codec detects that a jack has been plugged into a
1555 socket. When a Peripheral is in the Sleeping Link State, the LC_Request is referred to as a “WakeUp
1556 Request” and is dependent on the Manager having configured the Peripheral to enable it to generate the
1557 request. When a Peripheral is in the Cold_Standby Link State, the LC_Request is referred to as a “Cold
1558 Boot Request” and is dependent on the Peripheral (which might have powered up after the Manager)
1559 verifying that no Audio-mode PHY is currently active on the bus.
1560 The Manager immediately acknowledges both WakeUp Requests and Cold Boot Requests, but might defer
1561 actually starting the link, e.g., while a host processor boots, or even take no further action beyond the
1562 acknowledgment, e.g., because of battery charge state. The Manager can optimize the start-up time by
1563 extending its Link Control Acknowledge (LC_Ack) signaling directly into a Warm Start or Cold Start
1564 sequence (see Figure 48 in Section 5.1.2.9).
1565 The Peripheral uses an identical LC_Request signaling sequence on the bus for both WakeUp Requests and
1566 Cold Boot Requests, and it is the Manager that chooses whether to respond with Warm Start, Cold Start, or
1567 merely an acknowledgement.

5.1.1.3 Link Control Signaling

1568 Link Control signaling uses DP and DN as two independent single-ended signals that need only low
1569 bandwidth and slow slew rates, so can be implemented using extremely low- or “zero-” power circuits. It
1570 can be implemented by re-using some circuitry from another Audio-mode PHY, such as PHY1 & PHY2
1571 (FBCSE).
1572 When the link is idle in the inactive state, the two interface signals (DP and DN) are at a nominal level of
1573 zero Volts with respect to Gnd, which facilitates minimal leakage current even in Devices that have had
1574 power removed.
1575 The Link Control Receiver (LC_Rx) simply senses the input voltage, and detects only 2 possible states,
1576 referred to as LC:0 and LC:1.
1577 The Link Control Transmitter (LC_Tx) in the Manager sometimes drives the bus either strongly (so that it
1578 can overcome any Peripheral that is also driving the bus to LC:1, and so enforce a Bus Reset condition), or
1579 weakly (so that it holds the bus at a low voltage, but a Peripheral can overcome this by driving to LC:1 to
1580 signal an LC_Request). Thus the Manager output can sometimes be described as LC:strong0 (LC:s0) or
1581 LC:weak0 (LC:w0).
1582 The LC_Tx in the Peripheral is only used if the Peripheral can generate the optional LC_Requests (see
1583 Section 5.1.1.2.2). It can drive only to the LC:1 level.
1584 The electrical behavior of the LC_Rx and LC_Tx that make up the Link Control PHY (LC_PHY) is
1585 described in more detail in Section 6.

Copyright © 2019–2024 MIPI Alliance, Inc. 63

5.1.1.4 Resetting the Manager

1586 A SWI3S Manager is reset via implementation-defined mechanisms such as power-on reset detection
1587 within the Manager Device or a system-level reset controller.

5.1.1.5 Resetting Peripherals

1588 SWI3S Peripherals can be reset via several mechanisms including:
1589 Peripheral-specific mechanisms:
1590 • Power-on reset detection in the Peripheral device.
1591 • Implementation-defined mechanisms within the Peripheral device such as combinations of other
1592 external pins, or internal fault conditions.
1593 SWI3S-defined mechanisms:
1594 • The PHY-independent Bus Reset signaling sequence from the Manager (see Section 5.1.5.3)
1595 detected by the Peripheral Bus Reset State Machine (see Section 5.1.6).
1596 • Changes in Peripheral Link State initated by the Manager sending a Commit Command sent by the
1597 Manager that uses the PM_Action register field (see Section 5.1.3).
1598 • Changes in Peripheral Link State initated by the Peripheral detecting abnormal conditions:
1599 • Losing Command Confidence (see Section 5.1.8.4)
1600 • Losing Row Lock (see ###XREF)
1601 • PHY_Inactivity on the Audio-mode PHY (see Section 5.1.8.2).
1602 The SWI3S-defined sources of reset are categorized into Cold Reset and Warm Reset, with this severity
1603 determining which parts of the Peripheral state are affected (see Section 5.1.5).

5.1.1.6 Conceptual State Machines for Link State

1604 The conceptual state machines described in this Section (5.1) are informative material provided to help in
1605 understanding the operation of the link, and real implementations might use different mechanisms to create
1606 the behavior that is specified in the normative rules in Section 5.2. The normative rules use a simplified set
1607 of these states to describe that behavior.
1608 The behavior of each Peripheral is modeled with 3 conceptual state machines, which interact with the
1609 Manager using Link Control signaling:
1610 • The Peripheral Bus Reset state machine (PBR_SM, see Section 5.1.6) detects the Bus Reset
1611 sequence from the Manager.
1612 • The Peripheral Link State Machine (PL_SM, see Section 5.1.7 and Section 5.1.8) represents the
1613 Peripheral’s progress from standby through waking and PHY selection to being active, where it
1614 then communicates using one of the Audio-mode PHYs described elsewhere in this Specification.
1615 • The Peripheral Link Control Request state machine (PLCR_SM, see Section 5.1.7.4) represents
1616 the optional feature where a Peripheral can request that the Manager activates the Link in response
1617 to internal conditions or from local events, such as detecting insertion of an audio jack.
1618 The behavior of the Manager is modeled with 1 conceptual state machine:
1619 • Manager Link State Machine (ML_SM, see Section 5.1.9 and Section 5.1.10), whose state
1620 represents how the Manager is currently controlling the link. The state of the ML_SM is
1621 influenced primarily by the host controller (software or hardware), but it can also react to Link
1622 Control Request signals from a Peripheral (see Section 5.1.7.4).

64 Copyright © 2019–2024 MIPI Alliance, Inc.

5.1.1.6.1 Inactive and Active Peripheral Link States

1623 The conceptual model of the PL_SM can be viewed as two parts, corresponding to the link being Inactive
1624 or Active:
1625 • The Inactive Link States relate to Cold_Standby, Sleeping, and the Cold Start and Warm Start
1626 sequences, and are independent of the Audio-mode PHY(s). This generic part of the PL_SM is
1627 described in Section 5.1.7. The Manager co-ordinates the Peripheral moving to the Active state
1628 using Link Control sequences (see Section 5.1.2 5.1.1.2).
1629 • The Active Link States relate to active operation of the link with an Audio-mode PHY used to
1630 transmit bits arranged in a periodic Row structure. This part of the PL_SM is described in
1631 Section 5.1.8. The Peripheral receives clock information from the Manager in a method specific to
1632 each Audio-mode PHY (e.g., using a recovered bit clock or a forwarded bit clock).

5.1.2 Link Control Sequences (Detail)

1633 The diagrams in this Section (5.1.2) illustrate the waveforms for the Link Control signaling sequences that
1634 the Manager uses to take Peripherals out of, and return them into, the 2 inactive Link States: Sleeping and
1635 Cold_Standby. The diagrams also illustrate the sequence of states in the conceptual state machines
1636 (described in later informative sections) that can help in understanding these signaling sequences.
1637 The Peripheral behavior in these sequences is affected by two values in the Peripheral Link Control
1638 registers:
1639 • The Peripheral Management Action (PM_Action) register field influences when and how the
1640 Peripheral re-enters the Sleeping or Cold_Standby Link States, see Section 5.1.3.
1641 • The WakeReqEnable register bit controls whether a Peripheral in the Sleeping state can generate
1642 the optional WakeUp Request to the Manager.
1643 ###Note to Reviewers: Following review comments, the signaling sequence for Peripheral
1644 “WakeUp Requests” has been renamed as a Link Control Request (LC_Request). Some parts of
1645 the text still refer to the scenarios when a Peripheral will generate this sequence as being either a
1646 “WakeUp Request” (when the Peripheral is Sleeping) or a “Cold Boot Request” (when the
1647 Peripheral is in Cold Standby). These older names will probably be phased out in a later draft
1648 (v0.6+).

5.1.2.1 Summary of Standby and Link Start Scenarios

1649 During Standby the Manager maintains the Link-Idle bus condition of DP=LC:weak0, DN=LC:0.
1650 In all cases, to start the link, the Manager generates a Cold Start or Warm Start sequence using the Link
1651 Control PHY Transmitter (LC_Tx) to drive DP and DN.
1652 A Peripheral can request that the Manager starts the link by generating a short pulse of LC:1 on DP, which
1653 the Manager extends, either into a short LC_Acknowledge pulse or directly into a Warm Start or Cold Start
1654 sequence. The signaling sequences are specified such that Peripherals can differentiate between all 3 of
1655 LC_Acknowledge, Warm Start, and Cold Start simply by measuring the duration of the initial pulse of
1656 DP=LC:1.

Copyright © 2019–2024 MIPI Alliance, Inc. 65

5.1.2.2 Timing Parameters in Link Control Sequences

1657 The timing parameters for the Cold Start, Warm Start, and LC_Acknowledge signaling sequences are
1658 defined with:
1659 • Lower and upper limits that enable Peripherals to distinguish between these 3 sequences.
1660 • Ranges and tolerances to facilitate different ways in which Devices might implement their sense of
1661 time, including alternate sets of normative parameter values for each of:
1662 • Time-based (e.g., one-shots using RC-delays), where the Peripheral has a quick trigger response
1663 to input signals, but has wide tolerances in duration. There are simple integer relationships
1664 between the nominal delays for the various parameters to facilitate re-use of circuits.
1665 • Cycle-based (e.g., using an internal low-frequency oscillator), which has sampling uncertainty
1666 in when it detects changes in input signals (because the internal clock is asynchronous to the
1667 Manager), but has more accurate duration. The nominal delays are based around whole- and
1668 half-cycle delays of a clock at a nominal 32.76 kHz and a moderately good duty cycle.
1669 ###TEMP Note to reviewers: the color-coding for Time-based and Cycle-based relates to Table 14
1670 and Section 5.2.2 Requirements 24 and 25.
1671 Note:
1672 The normative rules in Section 5.2 specify different values for Manager and Peripheral versions of
1673 some timing parameters to allow some margin for system behavior such as propagation delays.
1674 (E.g., Man_tXYZ_min > Per_tXYZ_max).
1675 The normative values of timing parameters shown on Link Control sequence diagrams are each specified in
1676 the appropriate sections. Document navigation shortcuts to jump to the tables are shown in Table 1. The
1677 tables of timing parameters specify Min and Max values, which are the lower and upper bounds for the
1678 parameter values in a Device datasheet.
1679 Table 1 Links to Normative Tables of Timing Parameters
Tables Containing Timing Parameters
PHY Peripheral Manager
Link Control Table 14 Table 21
PHY1 & PHY2 (FBCSE) Table 114 Table 115
PHY3 (DLV) Table 126 Table 128

66 Copyright © 2019–2024 MIPI Alliance, Inc.

5.1.2.3 Key to Link Control Sequence Diagrams

1680 Figure 41 is a key to the notation used in the Link Control sequence diagrams.

Syncing States of conceptual state machines

<Name>_SM Cold_Standby Activate PHY
to Row (see later sections)

Start Audio-mode Period of electrical transition between Link Control PHY and
PHY signaling Audio-mode PHY signaling.

Example of Audio-mode PHY signaling.

DN=bit2 Point in time where the Peripheral samples the DN signal in

response to a falling edge on DP.

1 2 3 4 5 6 Parts of the waveforms that are described in the list of steps.

Min Max Timing parameter for which the Specification constrains both
minimum and maximum values

Min Max Timing parameter for which the Specification constrains only the
Per_tXYZ minimum value
1681 Man_tXYZ

Figure 41 Key to Link Control Sequence Diagrams

1682 The state machine names referenced in the sequence diagrams are:
1683 PL_SM: Peripheral Link State Machine, see Figure 57 in Section 5.1.7 and Figure 60 in
1684 Section 5.1.8.
1685 PLCR_SM: Peripheral Link Control Request State Machine, see Figure 59 in Section 5.1.7.4.
1686 ML_SM: Manager Link State Machine, see Figure 61 in Section 5.1.9 and Figure 63 in
1687 Section 5.1.10.

Copyright © 2019–2024 MIPI Alliance, Inc. 67

5.1.2.4 Cold Start Sequence

1688 Figure 42 illustrates the Cold Start sequence where the Manager sends a Bus Reset to all Peripherals, indicates which one of their Audio-mode PHYs is to be
1689 activated, and then starts the bus. The first part of the Cold Start sequence is the Bus Reset (see Section 5.1.5.3) that is detected by the PBR_SM, which in turn
1690 affects the PL_SM. The values of timing parameters in this figure are specified in normative Table 21 in Section 5.2.3 (for the Manager) and normative Table 14
1691 in Section 5.2.2 (for the Peripheral).
1692 Note:
1693 The values of all Link Control timing parameters are different between Manager and Peripheral, and in the normative tables these all have Man / Per
1694 prefixes. This figure uses separate, colored arrows and explicit Man / Per prefixes on names to highlight relationships between particular values in the
1695 Manager and Peripheral, and uses single black arrows without Man / Per prefixes for other parameters.

Bus Reset
PBR_SM Delay1 Armed Delay2
Detected
Idle

Per_tReset10_Max < Man_tReset10_Min

Per_tReset00 Per_tReset10 (Specification guarantees timing margin)
Per_tPhy_Inactivity_HoldOff
Min Max Min Max Min Max
Wait for End Activate
PL_SM Cold Standby Get PHY Number Syncing: Locking_to_Row
of BusReset PHY

Standby_ E.g., DLV

ML_SM Generate Cold Start Activate PHY
Bus_Idle Command-Only
Per_tPhyStart

Max
Man_tReset00 Man_tReset10 tResetRecovery tClock1 tClock0 tClock1 tClock0 tClock1 tClock0 tClock1 tClock0 tClock1 Man_tPhyStart
Min Min Min Max

Start Audio-mode
DP signal: 1 2 3 4 5A 5C 5A 5C 5A 5C 5A 5C 6 8
PHY signaling

5B 5B 5B 5B 7 9

DN=bit3 DN=bit2 DN=bit1 DN=bit0 Start Audio-mode

DN signal: PHY signaling

1696 tSetup tHold tSetup tHold tSetup tHold tSetup tHold

Figure 42 Cold Start Sequence (Detail)

68 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
1697 The steps in this Cold Start sequence are:
1698 1. [Same as Step #1 in the Warm Start sequence:] Before the Cold Start sequence, the Manager is holding the bus in the idle condition (driving
1699 DP=LC:weak0 and DN=LC:0).
1700 2. The Manager changes DP from LC:weak0 to LC:0 to guarantee that all Peripherals see the reset preamble period of LC:00.
1701 3. The Manager drives LC:10 for a long period to indicate the Bus Reset.
1702 4. The Manager drives LC:00 for a short period to end the Bus Reset.
1703 5. The Manager generates 4 clock cycles in which it:
1704 A. Sets up a data value on DN and drives DP=LC:1 for clock high, then
1705 B. Drives a falling edge on DP to clock 1 bit of the 4-bit PHY number into the Peripherals (MSb first, LSb last), then
1706 C. Holds the data value on DN and drives DP=LC:0 for clock low.
1707 6. The Manager generates a final clock high (DP=LC:1) and then …
1708 7. [Same as Step #7 in the Warm Start sequence:] The Manager generates a falling edge on DP to direct the Peripheral to change from LC signaling to the
1709 selected Audio-mode PHY, and start trying to synchronize to the Control Data Stream from the Manager.
1710 8. [Same as Step #8 in the Warm Start sequence:] The Manager drives the bus to LC:00 to ensure that both signals are (very close to) Ground prior to the
1711 Manager changing its output from LC signaling to the voltages associated with the selected Audio-mode PHY.
1712 9. [Same as Step #9 in the Warm Start sequence:] The Manager generates a Command-Only Transport Pattern using the Audio-mode PHY.
1713 Note:
1714 If the Peripheral is instructed to activate a PHY number which is not implemented then it falls back to Link State: Cold_Standby.

Copyright © 2019–2024 MIPI Alliance, Inc. 69

5.1.2.5 Warm Start Sequence

1715 Figure 43 illustrates the Warm Start sequence where the Manager wakes all Peripherals from Sleep. There is no PHY selection signaling in this sequence,
1716 because Warm Start always restarts the bus using the same Audio-mode PHY that was previously in use. The minimum and maximum values of timing
1717 parameters in this figure are specified in normative Table 21 in Section 5.2.3 (for the Manager) and normative Table 14 in Section 5.2.2 (for the Peripheral).

Per_tPhy_Inactivity_HoldOff
Min Max
Activate Syncing
PL_SM Sleeping Warm Start Check
PHY (Locking_to_Row / Syncing_to_Command)

E.g., DLV
ML_SM Standby / Bus Idle Generate Warm Start Activate PHY
Command-Only
Max
Per_tPhyStart
Man_tPhyStart

Man_tWarmStart Min Max

Max

Start Audio-mode
DP signal: LC:weak 0 1 2 8
PHY signaling

7 9

Start Audio-mode
DN signal: LC:0 PHY signaling
1718
Figure 43 Warm Start Sequence (Detail)

1719 The steps in this Warm Start sequence are:

1720 1. [Same as Step #1 in the Cold Start sequence:] Before the Warm Start sequence, the Manager is holding the bus in the idle condition (driving
1721 DP=LC:weak0 and DN=LC:0).
1722 2. The Manager drives LC:10 for a medium length period to indicate the Warm Start.
1723 7. [Same as Step #7 in the Cold Start sequence:] The Manager generates a falling edge on DP to direct the Peripheral to change from LC signaling to the
1724 Audio-mode PHY, and attempt to synchronize to the Control Data Stream from the Manager.
1725 8. [Same as Step #8 in the Cold Start sequence:] The Manager drives the bus to LC:00 to ensure that both signals are (very close to) Ground prior to the
1726 Manager changing its output from LC signaling to the voltages associated with the Audio-mode PHY.
1727 9. [Same as Step #9 in the Cold Start sequence:] The Manager generates a Command-Only Transport Pattern using the Audio-mode PHY.

70 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
5.1.2.6 Link Control Requests (LC_Requests) From a Peripheral
1728 The Peripheral can make 2 types of Link Control Request (LC_Request) to the Manager to ask that it start the link. In both cases, the Manager extends the pulse
1729 to acknowledge the request. The signaling for these 2 scenarios is identical, but the Peripheral pre-condition before the 2 scenarios is different:
1730 • A WakeUp Request, when the Peripheral is in state PL:Sleeping, is dependent on the WakeReqEnable bit.
1731 • A Cold Boot Request, when the Peripheral is in state PL:Cold_Standby, is dependent on the Peripheral checking that no Audio-Mode PHY is currently
1732 active on the bus.
1733 Figure 44 illustrates the LC_Request / LC_Acknowledge Sequence when the Peripheral makes an LC_Request and the Manager generates an LC_Acknowledge
1734 sequence and then returns to the bus to the Idle condition (before possibly issuing a subsequent Warm Start or Cold Start). The values of timing parameters in this
1735 figure are specified in normative Table 21 in Section 5.2.3 (for the Manager) and normative Table 14 in Section 5.2.2 (for the Peripheral). The figure shows the
1736 Peripheral state sequence for both of the Peripheral request scenarios: PL_SM #1 for a WakeUp Request and PL_SM#2 for a Cold Boot Request.

Per_tLC_ReqArmingDelay

PLCR_SM Arming Delay Armed Output LC_Req LC_Req_Idle Arming Delay Armed

PL_SM #1 Sleeping Warm Start Check Sleeping

PL_SM #2 Cold Standby

Generate
ML_SM Standby / Bus Idle Standby / Bus Idle
Wake Ack

Per_tLC_ReqOut Min Max

Man_tLC_AckOut Min Max

Min Max Min Max

Man_tLC_ReqIn Man_tParkBus_LC00

DP signal: 11 LC:weak 0 12 LC:1 and 13 14 LC:1 and

LC:weak 0 LC:1 LC:1
15 16

DN signal: LC:0

1737
Figure 44 Peripheral LC_Request and Manager LC_Acknowledge (Detail)

1738 The steps in the LC_Request / LC_Acknowledge sequence are:

1739 11. Before the LC_Request sequence, the Manager is holding the bus in the idle condition (driving DP=LC:weak0 and DN=LC:0).

Copyright © 2019–2024 MIPI Alliance, Inc. 71

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
1740 12. In response to an internal condition when the Peripheral has already seen the bus at DP=LC:0 and DN=LC:0 for at least Per_tLC_ReqArmingDelay (see
1741 Peripheral Link Control Request State Machine in Section 5.1.7.4), the Peripheral generates the LC_Request with a drive strength that overcomes the
1742 DP=LC:weak0 from the Manager, so the resulting condition on the bus is DP=LC:1.
1743 Note: the Peripheral generates the LC_Request only if it has also satisfied the state-specific enable condition, i.e., for state Sleeping: WakeReqEnable=1
1744 or for state Cold_Standby: the Peripheral has verified there is no Audio-mode PHY activity on the bus.
1745 13. The Manager detects the LC:1 condition and then reinforces it by also driving DP=LC:1 to extend the pulse into an LC_Acknowledge. The constraints
1746 on Peripheral output time (Per_tLC_ReqOut_Min) and Manager reaction time (Man_tLC_ReqIn_Max) guarantee that the Manager will see all valid
1747 LC_Requests.
1748 14. There is a period of overlap when both the Peripheral and Manager are driving DP=LC:1.
1749 15. The Manager ends the LC_Acknowledge by driving DP back to LC:0 to park the bus at LC:00.
1750 16. The Manager changes the drive on DP back to LC:weak0 (bus idle).

72 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
5.1.2.7 LC_Acknowledge is Separated from Warm or Cold Start
1751 Figure 45 illustrates that the LC_Acknowledge pulse is short enough that it does not trigger the Warm Start or Bus Reset detection in any Peripherals. In this
1752 figure, the PLCR_SM state sequence shows the Manager generating an LC_Acknowledge in response to an LC_Request from Peripheral Per1 similar to that in
1753 Figure 44, alongside the reaction of other Peripherals that are either in Sleeping (Per 2) or Cold_Standby (Per3), and remain in those states after the
1754 LC_Acknowledge.

(Man_tLC_ReqIn_Max + Man_tLC_AckOut_Max) < Per3_tReset10 Min

PBR_SM
Armed Delay2 (tReset10) Idle Delay1 (tReset00) Armed
(Per3)

PL_SM
Cold Standby
(Per3)

(Man_tLC_ReqIn_Max + Man_tLC_AckOut_Max) < Per2_tLC_WarmStart Min

PL_SM
Sleeping Warm Start Check Sleeping
(Per2)

PLCR_SM
Arming Delay Armed Output LC_Req LC_Req_Idle Arming Delay Armed
(Per1)

Generate
ML_SM Standby / Bus Idle Standby / Bus Idle
Wake Ack

Man_tLC_AckOut Min Max

Min Max

Man_tLC_ReqIn

DP signal: LC:weak 0 LC:1 and LC:1 and

LC:weak 0 LC:1 LC:1

DN signal: LC:0

1755
Figure 45 Manager LC_Acknowledge does not Trigger Warm Start or Cold Start

1756

Copyright © 2019–2024 MIPI Alliance, Inc. 73

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
5.1.2.8 Overlapping LC_Requests From 2 Peripherals
1757 Figure 46 illustrates the Link Control signaling when 2 Peripherals (#A and #B) both make LC_Requests from events that are so close in time that the
1758 LC_Request from #A was too late to disarm the LC_Request from #B. Thus there is a brief period when the Manager and both Peripherals are driving DP=LC:1.
1759 The behavior of the PLCR_SMs for closely spaced events is discussed at the end of Section 5.1.7.4.1.

PLCR_SM #B Arming Delay Armed Output LC_Req LC_Req_Idle Arming Delay Armed

Sleeping Warm Start Check Sleeping

PL_SM #B
Cold Standby

PLCR_SM #A Arming Delay Armed Output LC_Req LC_Req_Idle Arming Delay Armed

Sleeping Warm Start Check Sleeping

PL_SM #A
Cold Standby

Generate
ML_SM Standby / Bus Idle Standby / Bus Idle
Wake Ack

Per_tLC_ReqDisarm (#B) Max

Per_tLC_ReqArmingDelay (#B) Per_tLC_ReqOut (#B) Min Max

Per_tLC_ReqArmingDelay (#A) Per_tLC_ReqOut (#A) Min Max

Min Max

Min Max Min Max

Man_tLC_ReqIn Man_tParkBus_LC00

DP signal: 11 LC:weak 0 12A 12B 13 14 LC:weak 0

15 16

DN signal: LC:0
1760
Figure 46 Overlapping LC_Requests from 2 Peripherals

74 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
1761 The steps in the LC_Request sequence are:
1762 11. Before the LC_Request sequence, the Manager is holding the bus in the idle condition (driving DP=LC:weak0 and DN=LC:0).
1763 12. In the 2 Peripherals:
1764 A. In response to an internal condition (and only if both WakeReqEnable=1 and Peripheral#A has not yet observed a DP=LC:1 condition), Peripheral
1765 #A drives DP=LC:1.
1766 B. In response to an internal condition (and only if both WakeReqEnable=1 and Peripheral#B has not yet observed a DP=LC:1 condition), Peripheral
1767 #B drives DP=LC:1.
1768 13. The Manager detects this condition and then reinforces it by also driving DP=LC:1 to extend the pulse into an LC_Acknowledge.
1769 14. There is a period of overlap when the Peripheral(s) and Manager are driving DP = LC:1.
1770 15. The Manager ends the LC_Acknowledge by driving DP back to LC:0 to park the bus at LC:00.
1771 16. The Manager changes the drive on DP back to LC:weak0 (bus idle).

Copyright © 2019–2024 MIPI Alliance, Inc. 75

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
5.1.2.9 Warm Start after an LC_Request
1772 Figure 47 shows 2 of the ways in which the Manager reacts to an LC_Request from a Peripheral (pulse with short duration, labelled P1).
1773 In the first example, the Manager responds to the LC_Request by extending it into an LC_Acknowledge (pulse labelled M1, such that P1+M1 is too short to be
1774 interpreted as a Warm Start), then returns the bus to the Idle condition. Some time later (e.g., after it has restarted an internal clock or processor resources), the
1775 Manager generates a Warm Start sequence (pulse labelled M2, which is a medium duration longer than LC_Acknowledge and shorter than Cold Start).
1776 In the second example, the Manager extends the LC_Request directly into a Warm Start sequence (pulse labelled M3, such that P1+M3 is medium duration),
1777 which could result in a shorter sleep-wake cycle. This sequence is shown in more detail in Figure 48.

LC_Request / LC_Acknowledge followed later by a Warm Start

LC_Req + LC_Ack (short time) Warm Start (medium time)

Start mission-mode
DP signal: P1 M1 M2
PHY signaling

Per: tLC_ReqOut
Start mission-mode
DN signal: PHY signaling

LC_Request extended directly into a Warm Start

Warm Start (medium time)

P1 M3 Start mission-mode
DP signal: PHY signaling

Per: tLC_ReqOut
Start mission-mode
DN signal: PHY signaling
1778
Figure 47 Warm Start After an LC_Request

76 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
Per_tLC_ReqArmingDelay

PLCR_SM Arming Delay Armed Output_LC_Req LC_Req_Idle

Activate Syncing
PL_SM Sleeping Warm Start Check
PHY (Locking_to_Row / Syncing_to_Command)

E.g., DLV
ML_SM Standby / Bus Idle Generate Warm Start Activate PHY
Command-Only

Per_tLC_ReqOut Min Max Max

Per_tPhyStart
Max
Man_tPhyStart Max
Min Max
Man_tWarmStart Min Min
Man_tLC_ReqIn
Max

LC:1 and 13 LC:1 and Start Audio-mode

DP signal: 11 LC:weak 0 12 14 8
PHY signaling
LC:weak 0 LC:1 LC:1
7 9

Start Audio-mode
DN signal: LC:0 PHY signaling
1779
Figure 48 LC_Request Extended Directly into Warm Start

1780 The steps in this LC_Request to Warm Start sequence are:

1781 11. Before the LC_Request sequence, the Manager is holding the bus in the idle condition (driving DP=LC:weak0 and DN=LC:0).
1782 12. In response to an internal condition (and only if both WakeReqEnable=1 and the Peripheral has seen the bus at DP=LC:0 and DN=LC:0 for at least
1783 Per_tLC_ReqArmingDelay (see Peripheral Link Control Requests in Section 5.1.7.4)), the Peripheral generates the LC_Request with a drive strength
1784 that overcomes the DP=LC:weak0 from the Manager, so the resulting condition on the bus is DP=LC:1.
1785 13. The Manager detects this condition and then reinforces it by also driving DP=LC:1 to extend the pulse directly into a Warm Start. The constraints on
1786 Peripheral output time (Per_tLC_ReqOut_Min) and Manager reaction time (Man_tLC_ReqIn_Max) guarantee that the Manager will see all valid
1787 LC_Requests.
1788 14. There is a period of overlap when both the Peripheral and Manager are driving DP = LC:1.
1789 7. [Same as Step #7 in the Cold Start sequence:] The Manager generates a falling edge on DP to direct the Peripheral to change from LC signaling to the
1790 Audio-mode PHY, and attempt to synchronize to the Control Data Stream from the Manager.
1791 8. [Same as Step #8 in the Cold Start sequence:] The Manager drives the bus to LC:00 to ensure that both signals are (very close to) Ground prior to the
1792 Manager changing its output from LC signaling to the voltages associated with the Audio-mode PHY.
1793 9. [Same as Step #9 in the Cold Start sequence:] The Manager generates a Command-Only Transport Pattern using the Audio-mode PHY.

Copyright © 2019–2024 MIPI Alliance, Inc. 77

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
1794 Figure 49 shows that the Manager might receive multiple LC_Requests from Peripherals before it restarts the bus, e.g., because it first has to wake its operating
1795 system. After each LC_Request / LC_Acknowledge from any Peripheral, every Peripheral that is armed to generate LC_Requests will wait for at least the
1796 minimum arming delay before generating the next LC_Request (see PLCR_SM in Figure 59), but might wait for much longer to avoid unnecessary waste of
1797 power in the Manager.

Repeated LC_Request / LC_Acknowledge followed later by a Warm Start

LC_Req + LC_Ack (short time) LC_Req + LC_Ack (short time) Warm Start (medium time)

Per_tLC_ReqArmingDelay
Start mission-mode
DP signal: P1 M1 P2 M2 M3 PHY signaling

Per: tLC_ReqOut Per: tLC_ReqOut

Start mission-mode
DN signal: PHY signaling
1798
Figure 49 Warm Start After Repeated LC_Requests

78 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
5.1.2.10 Re-entering Inactive Link States
1799 Figure 50 illustrates the general case of returning to Link State: Sleeping or Cold_Standby. The “Stop PHY” signaling while the Manager is in state
1800 ML:Parking_Bus_PHYn for PHYn is specific to each Audio-mode PHY (e.g., see PHY3:DLV in Figure 51).

PLCR_SM LC_Req_Idle Arming Delay Armed

Ready for Sleeping or Deactivate Sleeping or Cold_Standby

PL_SM Attached
Ready for Cold Standby PHY #n (decided by value of PM_Action)

Link Running Parking Bus Deactivate

ML_SM Parking Bus LC Standby_Bus_Idle
e.g., Command-Only PHYn PHY #n PHY #n

P3 P6
Min

Per_tPhy_Inactivity_PHYn (negligible real time) Per_tLC_ReqArmingDelay

(PHY-Specific)

P8
Min Max

Man_tParkBus_PHYn (negligible real time) Man_tParkBus_LC00

(PHY-specific)

DP signal: LC:0 LC:weak 0

Change to
DP & DN Stop PHY LC signaling

M1 M2 M4 M5 M7
SSCR
DN signal: LC:0

1801
Figure 50 Re-entering Inactive Link States

Copyright © 2019–2024 MIPI Alliance, Inc. 79

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
1802 The sequence of steps for re-entering standby is:
1803 1. The Manager uses the currently active Audio-mode PHY to issue an SSCR command (see Section 9.1.10) that commits a PM_Action (see
1804 Section 5.1.3) directing all Peripherals to enter an Inactive Link State (either Sleeping or Cold_Standby).
1805 2. When the SSCR commit occurs, the Manager parks the bus at a PHY-specific inactive condition to indicate the end of use of that PHY. This parking
1806 condition informs all Peripherals (whether they are Attached or not Attached) that the Manager is changing the link to an inactive state.
1807 3. When a Peripheral detects the Phy_Inactivity, it deactivates its Audio-mode PHY (e.g., turning off power supplies), and activates its LC_Rx. The change
1808 to LC_Rx will typically take zero time.
1809 4. At the end of the PHY-specific parking condition, The Manager deactivates its Audio-mode PHY (e.g., turning off power supplies) and activates its
1810 LC_PHY.
1811 5. The Manager uses its LC_PHY to park the bus in the LC_Idle condition (DP=LC:0 and DN=LC:0).
1812 6. When the Peripheral detects the LC_Idle condition it enters the Inactive Link State selected by PM_Action (either Sleeping or Cold_Standby).
1813 7. The Manager reduces its drive strength on DP to be LC:weak0 so that a Peripheral could now overdrive this to make an LC_Request.
1814 8. In Peripherals that include the ability to generate LC_Requests: after an arming delay the Peripheral is now armed to generate an LC_Request when it
1815 detects an internal trigger condition. The constraints on minimum arming delay in the Peripheral and maximum parking time in the Manager are
1816 specified to guarantee that the Manager output will have reduced its drive strength on DP to LC:weak0 before the earliest Peripheral could generate an
1817 LC_Request.

80 Copyright © 2019–2024 MIPI Alliance, Inc.

5.1.2.11 Re-entering Inactive Link States from PHY3: DLV

1818 Figure 51 illustrates the specific case of returning to an Inactive Link State after using the DLV PHY. This figure shows the timing of Peripheral behavior
1819 following an SSCR that directs it to enter the Inactive link State, so is very similar to the generic case in Figure 50.

PLCR_SM LC_Req_Idle Arming Delay Armed

Ready for Sleeping or Deactivate Sleeping or Cold_Standby

PL_SM Attached
Ready for Cold Standby PHY3:DLV (decided by value of PM_Action)

Link Running Parking Bus Deactivate

ML_SM Parking Bus LC Standby_Bus_Idle
e.g., Command-Only DLV PHY3:DLV PHY3:DLV

P3 P6
Min

Per_tPhy_Inactivity_DLV (negligible real time) Per_tLC_ReqArmingDelay

(PHY-Specific)

P8
Min Max

Man_tParkBus_DLV (negligible real time) Man_tParkBus_LC00

(PHY-specific)

DP signal: LC:0 LC:weak 0

DP S0 S1 Manager DLV: 0 (DP=low)

M1 M2 M4 M5 M7
SSCR
Change from DLV
to LC signaling

DN S0 S1 Manager DLV: 0 (DN=high) DN signal: LC:0

1820
Figure 51 Re-entering an Inactive Link States from PHY3:DLV Using an SSCR

Copyright © 2019–2024 MIPI Alliance, Inc. 81

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
1821 For the DLV PHY, the “Stop PHY” behavior in Step #2 is for the Manager to generate a static value of DLV:0 to park the bus in a known state. Thus, the
1822 sequence of steps for re-entering the Inactive Link State from the DLV PHY using an SSCR is:
1823 1. [DLV-specific] The Manager uses the DLV PHY to issue an SSCR command (see Section 9.1.10) that commits a PM_Action (see Section 5.1.3)
1824 directing all Peripherals to enter an Inactive Link State (either Sleeping or Cold_Standby).
1825 2. [DLV-specific] At the point in time where the SSCR commit occurs, the Manager generates the Sync0 to Sync1 transition to end the last Row and then
1826 parks the bus at static DLV:0, which informs all Peripherals (whether they are Attached or not Attached) that the Manager is changing the link to an
1827 inactive state.
1828 3. [DLV-specific] When the Peripheral detects the DLV Phy_Inactivity condition, it begins to deactivate the DLV PHY (e.g., turning off the power supply
1829 for the Tx output), and activate its LC_Rx.
1830 4. [DLV-specific] The Manager deactivates its DLV PHY and activates its LC_PHY.
1831 5. The Manager uses its LC_PHY to park the bus in the LC_Idle condition (DP=LC:0 and DN=LC:0).
1832 6. When the Peripheral detects the LC_Idle condition it enters the Inactive Link State selected by PM_Action (either Sleeping or Cold_Standby).
1833 7. The Manager reduces its drive strength on DP to be LC:weak0 so that a Peripheral could now overdrive this to make an LC_Request.
1834 8. In Peripherals that include the ability to generate LC_Requests: after an arming delay the Peripheral is now armed to generate an LC_Request when it
1835 detects an internal trigger condition. The constraints on minimum arming delay in the Peripheral and maximum parking time in the Manager are
1836 specified to guarantee that the Manager output will have reduced its drive strength on DP to LC:weak0 before the earliest Peripheral could generate an
1837 LC_Request.

82 Copyright © 2019–2024 MIPI Alliance, Inc.

5.1.3 Peripheral Management Action (PM_Action) Field

1838 Each Peripheral contains a Peripheral Management Action (PM_Action) register field (see ###XREF) that
1839 influences changes to the Peripheral Link State following certain conditions on the link. PM_Action
1840 controls which action the Peripheral will perform when either:
1841 • The PM_Action register is explicitly committed by a Commit Request Command (SSCR or
1842 DSCR) sent by the Manager (see Section 9.1.10), which is similar to copying *_NEXT to
1843 *_CURR in dual-ranked registers, or:
1844 • The PM_Action register is implicitly committed by PHY-specific conditions that detect inactivity
1845 and cause the Audio-mode PHY to be deactivated.
1846 The list of actions that can be selected with the PM_Action field is:
1847 • Enter_Cold_Standby.
1848 • Enter_Sleeping.
1849 • Enter_Dormant.
1850 • Force_Resync.
1851 • Stay_Attached.
1852 Note:
1853 The actual numeric values and the effects of the PM_Action field are specified in Table 17 and
1854 Table 18 in normative Section 5.2.2.

5.1.3.1 Summary of PM_Action Behavior

1855 Note:
1856 PL_SM refers to the Peripheral Link State Machine, which is described in Section 5.1.7.
1857 When operating normally, the PM_Action has a value of Stay_Attached, so that any Commit Command that
1858 is used to update other behavior, such as changing PHY parameters or changing payload transport in Data
1859 Ports, will not change the Link State.

5.1.3.1.1 Explicitly Commiting PM_Action

1860 When PM_Action is explicitly committed by a Commit Command (SSCR or DSCR):
1861 • Some of the PM_Actions affect the Peripheral behavior, but keep the current Audio-mode PHY Rx
1862 activated or partly activated.
1863 • some of the PM_Actions deactivate the current Audio-mode PHY and move the Peripheral to one
1864 of the Inactive Link States (i.e., the PL_SM moves to state Sleeping or Cold_Standby).

5.1.3.1.2 Implicitly Commiting PM_Action

1865 The current PHY can also be deactivated by PHY-specific conditions that detect inactivity on the bus.
1866 When the PHY is deactivated in this way, the PM_Action register is implicitly committed, and the
1867 Peripheral performs the programmed action of Enter_Cold_Standby or Enter_Sleeping. This implicit
1868 commit behavior addresses an error case where the Manager had written to the PM_Action Register to
1869 prepare to enter Cold_Standby or Sleeping but the Peripheral had then lost communication before this
1870 change was properly committed with an SSCR/DSCR.
1871 Note:
1872 If the PM_Action register is implicitly committed by the PHY detecting inactivity, but the PM_Action
1873 indicates that the Manager had not yet prepared the Peripheral for standby (i.e., PM_Action is one
1874 of Stay_Attached, Force_Resync, or Enter_Dormant), then the Peripheral will behave as if
1875 PM_Action were the less severe of the two choices, i.e., Enter_Sleeping.

Copyright © 2019–2024 MIPI Alliance, Inc. 83

5.1.4 Selection of PHY Number in Peripheral

1876 The PHY number is selected within the Peripheral when:
1877 • The Manager explicitly identifies the 4-bit PHY number during the Cold Start sequence that brings
1878 all Peripherals out of the Cold_Standby Link State, see ###XREF, or
1879 • [optional to implement] The Peripheral detects which type of Audio-mode PHY signaling is
1880 already in use when it joins an already active link. This detection process is
1881 implementation-defined (see Hot_Join in Section ###XREF).
1882 The Peripheral retains the same PHY number when the PHY is deactivated and reactivated in a Sleep-Wake
1883 transition.

84 Copyright © 2019–2024 MIPI Alliance, Inc.

5.1.5 Reset
1884 SWI3S devices have some mandatory and some optional sources of reset. Each of these sources is
1885 categorized into 1 of 2 possible severities, which determines how much of the Device is affected by that
1886 reset. These severities are:
1887 Cold Reset: affects all of the SWI3S interface, returning it to the same condition as after power-on
1888 reset, and typically also affects most or all of the rest of the device. The Audio-mode PHY is
1889 deactivated. The Link State in a Peripheral changes to Cold_Standby, and in the Manager to
1890 Standby.
1891 Some Peripheral designs might remove power from most of the SWI3S interface for almost all of
1892 the time that they are in Cold_Standby. This is not visible outside the Peripheral because the
1893 register values that result from the Cold Reset are only observable when the Cold Start sequence
1894 directs the Peripheral to activate its Audio-mode PHY and attach to the bus.
1895 Warm Reset: affects a small amount of state within the SWI3S interface and stops any payload
1896 streaming, but typically affects very little in other parts of the device. Depending on the cause of
1897 the Warm Reset, the Audio-mode PHY might remain activated (e.g., if this Warm Reset was from
1898 the Peripheral losing sync and momentarily becoming detached from the bus), or be deactivated
1899 (e.g., if this Warm Reset resulted from commiting a PM_Action of Enter_Sleeping).
1900 The specific registers and other state in the Peripheral that is affected by each of Cold Reset and Warm
1901 Reset is specified in Table 9 in normative Section 5.2.1.
1902 ###TODO-Author: simple text about Manager Reset (not Cold/Warm). and Table 11 (Manager).

5.1.5.1 Sources of Reset

1903 To simplify the description of resets, the sources of the 2 severities of reset are separated from their effects.
1904 The sources include:
1905 • Power_On_Reset detected within the component itself.
1906 • Bus_Reset signaled by the Manager (see Section 5.1.5.3).
1907 • A Commit Request Command (SSCR or DSCR, see Section 9.1.10) that explicitly commits the
1908 PM_Action register field (see Section 5.1.3).
1909 • The Command Transport Protocol layer losing confidence in the Control Data Stream (see
1910 Section 5.1.8.4).
1911 • PHY-specific conditions for detecting PHY_Inactivity (e.g., for PHY3 (DLV), see ###XREF) that
1912 cause the Peripheral to deactivate the Audio-mode PHY and implicitly commit the PM_Action
1913 register field (see Section 5.1.3.1).
1914 • PHY-specific conditions for detecting when the PHY has lost sync (e.g., for PHY3 (DLV), see
1915 ###XREF).
1916 • Other, implementation-defined sources of reset.
1917 These sources of reset and their severity are specified in more detail in Table 8 (Peripheral) and Table 10
1918 (Manager) in normative Section 5.2.1.

5.1.5.2 Effects of Reset and the PL_SM

1919 Some of these effects of reset are also repeated in the informative descriptions of behavior for each of the
1920 states in the Peripheral Link State Machine (PL_SM, see Section 5.1.7).

Copyright © 2019–2024 MIPI Alliance, Inc. 85

1921 A Cold Reset has a severe effect on the Device:

1922 • The Peripheral Link State changes to Cold_Standby.
1923 • Any payload streams that were enabled are stopped.
1924 • If an Audio-mode PHY was previously active is deactivated.
1925 • SWI3S registers, command protocol state etc., are reset to the same state as after power-on.
1926 A Warm Reset has a milder effect on the Device:
1927 • The Link State will change (it is the change of Link State that causes the Warm Reset).
1928 • Any payload streams that were enabled are stopped.
1929 • Any incompletely received Command Transport Phase is discarded.
1930 • If any remote read or write operations were incomplete then further remote accesses are disabled
1931 (see ###XREF).
1932 • Minimal other state is affected (see Table 9 in normative Section 5.2.1).

5.1.5.3 Bus Reset Sequence

1933 Bus Reset is a signaling sequence from the Manager that is guaranteed to be detected by a Peripheral
1934 independent of its current state (including when an Audio-mode PHY is active, see Section 5.1.5.4). Thus,
1935 the Manager can use this signaling sequence as a fallback mechanism to guarantee that it obtains control of
1936 every Peripheral on the bus that is currently powered.
1937 This sequence is generated by the manager as part of the Cold Start sequence (see Section 5.1.2.4).
1938 The effect of Bus Reset in the Peripheral is described in Section 5.1.5, and includes putting all of the
1939 Peripherals into Link State: Cold_Standby (see PL_SM in Section 5.1.7).
1940 The Bus Reset Sequence generated by the Manager is illustrated in Figure 52, and a Peripheral Bus Reset
1941 State Machine that could be used to detect this sequence is described in Section 5.1.6.
Manager generates LC:00
for Man_tResetRecovery
Manager generates LC:00 A Manager generates LC:10 B C
for Man_tReset00 for Man_tReset10
Manager Min Manager Min Min

Peripheral Max Peripheral Max

Audio-Mode PHY or Link Control signaling: LC:0

PHY Selection in
DP signal: LC:1 LC:0
Link Control signaling Cold Start sequence

DN signal: Audio-Mode PHY or Link Control signaling: LC:0 LC:0 LC:0

Link Control signaling

All Peripherals are guaranteed to detect the All Peripherals are guaranteed to detect All Peripherals are guaranteed to be ready to
first part of Bus Reset before point A because Bus Reset before point B because accept PHY Selection part of Cold Start sequence
1942 Per_tReset00_Max < Man_tReset00_Min Per_tReset10_Max < Man_tReset10_Min before point C, Man_tResetRecovery_Min

Figure 52 Bus Reset Sequence from Manager

1943 Figure 52 shows each of steps ‘A’, ‘B’, and ‘C’ of the Bus Reset Sequence exceeding a defined minimum
1944 time. The corresponding Bus Reset detection circuitry in each Peripheral has threshold times for when it
1945 successfully detects each of the three steps. The threshold times will not be identical in every Peripheral, so
1946 some Peripherals will detect Bus Reset before others, but all Peripherals will have detected Bus Reset
1947 before the Manager has completed step ‘B’ of this Bus Reset sequence (i.e., the step when DP=LC:1 and
1948 DN=LC:0).
1949 The range of acceptable threshold times in Peripherals has wide timing tolerances to facilitate designs using
1950 (or re-using) simple low power timers, such as internal RC delays.

86 Copyright © 2019–2024 MIPI Alliance, Inc.

5.1.5.3.1 Bus Reset Signaling Levels

1951 The Manager generates the Bus Reset sequence using the same signaling voltage levels as for Link Control
1952 signaling (see Section 5.1.1.3). Thus, the Peripheral can use the same LC_Rx circuit for receiving the Bus
1953 Reset sequence.

5.1.5.3.2 Strong Drive for Bus Reset from Manager

1954 In typical cases, the Manager would end the use of the currently selected PHY in an ordered way by
1955 bringing the Peripheral Link State Machine (PL_SM, see Section 5.1.7) in each Peripheral to the
1956 PL:Cold_Standby Link State in which the LC_Rx is the only active PHY transceiver in the Peripheral.
1957 However, the Peripherals detect Bus Reset using an independent Peripheral Bus Reset State Machine
1958 (PBR_SM, see Section 5.1.6) that can detect the Bus Reset sequence even without this ordered change of
1959 Audio-mode PHY. To ensure that all the Peripherals see the Bus Reset sequence, the Manager uses a
1960 stronger Tx output than is needed for normal Link Control signaling in order to overcome PHY-level
1961 behavior of Peripherals that might still be transmitting with an Audio-mode PHY when the Bus Reset
1962 sequence starts. Drive Strengths of LC_PHY in Manager and Peripherals are described in Section 6.1.4.

5.1.5.4 Asserting Bus Reset While an Audio-mode PHY is Active

1963 Bus Reset is typically asserted while all Peripherals are in Link State: Sleeping or Cold_Standby (and so
1964 are expecting Link Control signaling), but it can be preceded by a PHY-specific preamble that forces all
1965 Peripherals to deactivate their Audio-mode PHY. E.g., Figure 53 illustrates how the Manager forces
1966 peripherals using PHY3 (DLV) to be ready for the reset signaling without any collision between the
1967 electrical signaling schemes.
Man_tDLV_Keeper is until either:
(a) bus has no transitions for ~ 10usec or
(b) 8192 * 2.0 * previous tRow has elapsed Manager generates LC:00 for
Man_tReset_Recovery
Manager disables DLV Tx, L A B C
leaving only DLV bus keeper Manager generates DLV:0 for Manager generates LC:00 for
for Man_tDLV_Reset_Keeper Man_tDLV_Park_at_0 Min Man_tReset00 Min Min Min

PHY Selection in
DP: Link Control signaling: LC:0 LC:1 LC:0
DP & DN DLV: Keeper DLV: 0 Cold Start sequence

DN: Link Control signaling: LC:0 LC:0 LC:0

All Peripherals are guaranteed All Peripherals are guaranteed All Peripherals are guaranteed All Peripherals are guaranteed to be
to have detected that DLV PHY is to have detected the first part of to have detected Bus Reset ready to accept PHY Selection part of
1968 no longer in use before this point Bus Reset before this point before this point Cold Start sequence before this point

Figure 53 Bus Reset Sequence from Manager when DLV PHY is Active

1969 The PHY-specific preamble that deactivates PHY1 or PHY2 (FBCSE) is the Manager driving
1970 DP=FBCSE:0 and DN=FBCSE:0 for a longer period than the slowest allowed clock cycle. This
1971 PHY_Inactivity Detector is described in Section ###XREF.
1972 ###TODO-Author: add a similar figure showing the Manager generating this FBCSE Idle sequence
1973 to trigger the Peripheral PHY_Inactivity Detectors, and then generating bus reset using LC
1974 signaling. The period Man_tReset00 will be just an extension of the FBCSE:00.

Copyright © 2019–2024 MIPI Alliance, Inc. 87

5.1.6 Peripheral Bus Reset State Machine (PBR_SM)

1975 The Peripheral Bus Reset State Machine (PBR_SM), illustrated in Figure 54, defines simple monitoring of
1976 the two SWI3S bus signals (DP and DN) that guarantees that a Peripheral will detect a Bus Reset sequence
1977 (see Section 5.1.5.3), independent of the current state of the Peripheral (including whichever PHY might
1978 currently be selected). The Peripheral reacts to this sequence by performing a Cold Reset (see
1979 Section 5.1.5).

Any Cold Reset:

• BusReset from PBR_SM
• Internal POR detector
• Enter_Cold_Standby
• ImpDef_Cold_Reset

Idle

[LC Rx]

Delay1
(tReset00)
[LC Rx]

(DP/DN=LC:00)
AND (Time Per_tReset00)

Armed

[LC Rx]

DP/DN=LC:10

Delay2
(tReset10)
[LC Rx]

(DP/DN=LC:10)
AND (Time Per_tReset10)

Bus
Reset
Detected
[LC Rx]
1980
Figure 54 Peripheral Bus Reset State Machine (PBR_SM)

88 Copyright © 2019–2024 MIPI Alliance, Inc.

5.1.6.1 States in the Peripheral Bus reset State Machine (PBR_SM)

1981 The states in the PBR_SM are described in Table 2. To avoid ambiguity, when these states are referred to
1982 elsewhere in the text they are preceded with “PBR:”. The conditions listed in this table describe only
1983 transitions to new states; the default operation when none of the conditions are present is to remain in the
1984 current state.
1985 Table 2 States in the Peripheral Bus Reset State Machine (PBR_SM)

State Name Description

The Peripheral has not yet received any part of the Bus Reset sequence.
Idle Note:
A Cold Reset (e.g., Power-on) forces the PBR_SM to start in this state.

The Peripheral is monitoring the first part of the Bus Reset sequence
Delay1
(Per_tReset00).

Armed The Peripheral has received the first part of the Bus Reset sequence.

The Peripheral is monitoring the second part of the Bus Reset sequence
Delay2
(Per_tReset10).

The Peripheral has detected the complete Bus Reset sequence. This generates a
Cold Reset within the Peripheral, which includes:
• Forcing the PL_SM to move to the state PL:Wait_for_End_of_Bus_Reset
• Forcing this PBR_SM to move back to state PBR:Idle.
Note:
The PBR_SM is active continuously. When it detects a Bus Reset it will override
the Peripheral Link State, forcing it to PL:Wait_for_End_of_Bus_Reset. In
normal operation, the Peripheral will already be in state PL:Cold_Standby or
Bus_Reset_Detected
PL:Sleeping before the Manager generates a Cold Start sequence, and will thus
be in one of PL:Cold_Standby or PL:Warm_Start_Check at the moment when
the PBR_SM detects the Bus Reset.
Note:
PBR:Bus_Reset_Detected is a transient state used to clarify the description of
behavior. In Figure 54, the exit from this state and the entry to the PBR:Idle
state are shown with the double-headed arrow that is used to indicate transitions
associated with reset.

Copyright © 2019–2024 MIPI Alliance, Inc. 89

5.1.6.2 Bus Reset Detection is Independent of Other Peripheral Behavior

1986 To achieve robust system behavior, the Peripheral detection of Bus Reset (which is described using this
1987 PBR_SM) operates continuously and independently of the remainder of the current state of the Peripheral,
1988 including the initial state of the PBR_SM itself, the state of the Peripheral Link State Machine (PL_SM),
1989 and which Audio-mode PHY is currently selected.
1990 Genuine Link Control signaling from the Manager targeted at the PL_SM, such as WakeUp requests, might
1991 move the PBR_SM part way through its sequence of states before the Manager starts the Bus Reset
1992 sequence. Figure 55 illustrates that Bus Reset Detection is independent of which state the PBR_SM is in
1993 before the Bus Reset sequence starts. The PBR_SM will always reach state PBR:Delay2 in response to the
1994 DP signal changing from LC:0 to LC:1, and will thus always correctly detect a genuine Bus Reset sequence
1995 independently of its initial state.

DP signal: Any PHY Link Control signaling: LC:0 LC:1

signaling

DN signal: Any PHY Link Control signaling: LC:0 LC:0

signaling

Peripheral #1 Bus Reset

... Idle Delay1 Armed Delay2
PBR_SM: Detected

Peripheral #2 Bus Reset

... Delay1 Armed Delay2
PBR_SM: Detected

Peripheral #3 Bus Reset

... Armed Delay2
PBR_SM: Detected

Peripheral #4 Bus Reset

... Delay2 Idle Delay1 Armed Delay2
PBR_SM: Detected

Normal PHY signaling might have left the The PBR_SM in every Peripheral is
PBR_SM in any state at the moment when guaranteed to have reached state PBR:Armed
the Manager starts the first part of the Bus before the Manager starts the second part of
1996 Reset sequence the Bus Reset sequence

Figure 55 Peripheral Bus Reset Detection: Independent of Initial State of PBR_SM

1997 The PBR_SM monitors the DP and DN inputs continuously using the Link Control PHY receiver (LC_Rx).
1998 Depending on which Audio-mode PHY(s) are implemented in a device, the signaling voltage levels used
1999 for an Audio-mode PHY might also be detected by the LC_Rx (e.g., PHY1/PHY2 (FBCSE) use the same
2000 voltage levels as LC, and might share an input circuit). Thus, the PBR_SM might (incorrectly) detect part
2001 of the Bus Reset sequence. However, the Manager behavior is defined such that Audio-mode PHY
2002 signaling can never trigger the whole of the Bus reset sequence. E.g., when using PHY1/PHY2, the
2003 Manager pauses the clock only in a bus condition of DP=1 and DN=1, which will cause the PBR_SM to
2004 return to state Idle.
2005 Figure 55 shows that the PBR_SM will successfully detect a genuine Bus Reset independently of any state
2006 that false signaling might have taken it to.
2007 Note:
2008 For a system using PHY3 (DLV) that has been correctly programmed, there is no voltage overlap
2009 between PHY3 and LC_PHY signaling so that no false signaling occurs.

90 Copyright © 2019–2024 MIPI Alliance, Inc.

5.1.6.3 PBR_SM Timing Tolerances

2010 The circuitry for detecting Bus Reset in the Peripheral is permanently active, so the timings for this
2011 detection are specified with wide tolerances to facilitate simple low power designs. Thus, several
2012 Peripherals on the same bus might detect Bus Reset at different moments within the Bus Reset sequence.
2013 Figure 56 illustrates an example of three Peripherals each with different timing performance in their Bus
2014 Reset detector circuits, and shows that all of the Peripherals will have reached the PBR:Armed state before
2015 the DP signal changes from LC:0 to LC:1, and that all of the Peripherals will have detected the Bus Reset
2016 before the Manager reaches the minimum duration of the period with DP at LC:1.

DP signal: Normal PHY Link Control signaling: LC:0 LC:1

signaling

DN signal: Normal PHY Link Control signaling: LC:0 LC:0

signaling

Peripheral #1 Bus Reset

Idle Delay1 Armed Delay2
PBR_SM: Detected

Peripheral #2 Bus Reset

Idle Delay1 Armed Delay2
PBR_SM: Detected

Peripheral #3 Bus Reset

Idle Delay1 Armed Delay2
PBR_SM: Detected

Peripherals with shorter delay timers will Peripherals with shorter delay timers will
move into the Armed state earlier but all detect Bus Reset earlier, but all Peripherals
Peripherals move into Delay2 together are guaranteed to detect Bus Reset before
2017 when DP changes to LC:1 the end of the Bus Reset sequence

Figure 56 Peripheral Bus Reset Detection: Effect of Wide Timing Tolerances in PBR_SM

Copyright © 2019–2024 MIPI Alliance, Inc. 91

5.1.7 Peripheral Link State Machine (PL_SM): Inactive Link

2018 The parts of the Peripheral Link State Machine (PL_SM) that relate to the inactive link behavior
2019 (Cold_Standby and Sleeping) are shown in Figure 57, and the states are described in Table 3. Figure 58
2020 is a key to the notation used in this diagram. The green box at the bottom of this picture represents the
2021 active link part of the PL_SM (see Figure 60 in Section 5.1.8).

Initial Cold Reset, e.g.:

• Internal POR detector
• ImpDef_Cold_Reset

Cold
Sleeping

(Cold Standby & Sleep / Wake)

Standby
[LC Rx]
[LC Rx]

Inactive Link Behavior

Self-initiated Hot_Join
(Optional) DP Rising Edge
Bus Reset Detected
(see PBR_SM)
DP Falling Edge AND
(t < Per_tWarmStart)

Bus Reset Detected

Wait for End (see PBR_SM) WarmStart
of BusReset Check
[LC Rx] [LC Rx]

DP Falling Edge DP Falling Edge AND

(Per_tWarmStart < t < Per_tReset10)

(4 DP Falling Edges)
Get PHY
DP Falling Edge Number
D3 D2 D1 D0
AND PHY Num [LC Rx]
is NOT supported

DP Falling Edge AND

PHY Num is supported LC_Bus_is_Idle AND LC_Bus_is_Idle AND
(PM_Action Enter_Cold_Standby) (PM_Action = Enter_Cold_Standby)

Transition and Active Link Behavior

Activate Deactivate

(PHY-Specific Conditions)
PHY #n PHY #n

PHY_Ready

PHY_Stopped
PM_Action = Enter_Sleep
PM_Action = Enter_Cold_Standby

PHY-Specific Active Link Behavior

(e.g., Locking_to_Row, Syncing_to_Command, Attached)

One set of states for each PHY Number that is implemented in the Peripheral.
2022 (See detail in PHY-specific sections.)

Figure 57 Peripheral Link State Machine (PL_SM): Inactive Link States

2023 A Peripheral implements one or more of the Audio-mode PHYs described in this Specification. The PL_SM
2024 behaves as described by the set of PHY-independent inactive Link States shown in Figure 57, and then one
2025 set of the PHY-specific active link states (for transition, synchronization, and active communication) shown
2026 in Figure 60 for each of the PHYs that are implemented within the Peripheral.

92 Copyright © 2019–2024 MIPI Alliance, Inc.

5.1.7.1 Key to the PL_SM

2027 Figure 58 is a key to the color coding and notation used in the PL_SM state diagrams: Figure 57 and
2028 Figure 60.

State Inactive Link State in which the Peripheral uses A thinner outline represents states that clarify
State
Name Link Control signaling to sense the input on DP the informative description, but are not needed
Name
[LC Rx] and DN. in the normative material.

State Name PHY-specific states for graceful transition Normal state transition caused by logical conditions
PHY #n between Inactive states (LC PHY signaling) within the Peripheral.
[Tx Off] and Active states (Audio-mode PHY signaling).
Shorthand notation for forced direct state transition
from any state to PL:Cold_Standby when the
Peripheral receives an initial cold reset (such as
Peripheral uses the Audio-mode PHY Rx to internal power-on detection).
Syncing
attempt to synchronize to the Row Sync and
[TxPowerOn]
Control Data Stream from the Manager. State transition caused by Link Control signaling
from the Manager on DP and DN.

Peripheral is fully active, and uses the Bus Reset Detected Shorthand notation for forced direct state transition
Attached (see PBR_SM) ...
Audio-mode PHY Rx and Tx to participate from any state to PL:Held_in_Cold_Reset when the
[TxEnabled]
in bus activity (Commands and Payload). Peripheral sees a Bus Reset from the Manager.

Identifies a state transition that is triggered by a

Ready for Peripheral is using the Audio-mode PHY Rx to Link Control signaling rising / falling edge on DP.
Cold Standby detecting when the Manager has parked the
[Tx Off] bus in the PHY-specific idle condition. Optional special state transition when the Peripheral
can detect that it has powered up when the bus is
already active.
This Peripheral is in a low power state while the
Link is still active, and might use the Audio- PHY_Inactivity Shorthand notation for state transitions when the
Dormant mode PHY Rx to monitor Command traffic. The Peripheral uses the Audio-mode PHY to detect the
[Tx Off]
Peripheral is capable of re-attaching to the bus. PHY-specific Bus_Idle condition from the Manager.

2029 The dotted outline indicates it is an optional state.

Figure 58 Key to Peripheral Link State Machine Diagram (PL_SM)

5.1.7.2 States in the PL_SM (Inactive Link States)

2030 The states in the inactive link part of the PL_SM (Figure 57) are described in Table 3. For clarity, when
2031 these state names are referred to in the text they are preceded with “PL:”.
2032 Table 3 States in the Peripheral Link State Machine (PL_SM): Inactive Link

PL_SM State Description

The Peripheral is in a low-power state in which neither register values nor

other internal state need to be retained, and power might be removed from
most parts of the Peripheral circuitry.
The Peripheral waits for the Cold Start sequence from the Manager.
[Optional behavior] If the Peripheral is confident that the bus is not active
Cold_Standby [1]
with Audio-mode PHY signaling then it might generate an LC_Request
using LC signaling on DP to make a Cold Boot Request to the Manager.
[Optional behavior] If the Peripheral is confident that the bus is already
active then it might perform a “self-initiated hot-join” action (see
Section 5.1.7.5).

Wait_for_End_of_Bus_Reset[2] The Peripheral waits for the end of the Bus Reset part of the Cold Start
(Cold Start #1) sequence from the Manager (see PBR_SM in Section 5.1.6).

Copyright © 2019–2024 MIPI Alliance, Inc. 93

PL_SM State Description

Get_PHY_Number The Peripheral captures the 4-bit PHY Number (see Section 5.1.4)
(Cold Start #2) transmitted by the Manager in the Cold Start sequence.

The Peripheral is in a low-power state in which all SWI3S register values

and internal state are retained, including the selected Audio-mode PHY and
its settings and calibration, but power might be removed from some other
parts of the Peripheral circuitry.
Sleeping [1]
The Peripheral waits for the Warm Start or Cold Start sequences from the
Manager.
[Optional behavior] The Peripheral might generate an LC_Request using
LC signaling on DP to make a WakeUp Request to the Manager.

Warm_Start_Check The Peripheral checks that the LC_Rx has received a valid Warm Start
(Warm Start #1) sequence from the Manager (see Figure 43 in Section 5.1.2.5).

The Peripheral activates implementation-defined internal circuitry for the

selected Audio-mode PHY (such as DLL/PLL, LDO regulator for Tx,
reference voltage for Rx).
Activate_PHY Note:
Time constraints for activation are specific to each Audio-mode PHY.
The LC_Rx (or a similar circuit) remains active, so that the Peripheral can
detect a Bus Reset.

The Peripheral deactivates implementation-defined internal Audio-mode

Deactivate_PHY PHY circuitry (such as DLL/PLL, LDO regulator for Tx, reference voltage for
Rx) and switches to using the LC_Rx.

See the active half of the PL_SM in Figure 60 and the description of states
in Table 4.
<PHY-specific Active Link
States> I/O Control:
• The selected Audio-mode PHY Rx and Tx behave as described in
Table 4.

2033 Note:
1. The state names PL:Cold_Standby and PL:Sleeping are colored purple to indicate that these
states correspond to terms used in the normative material in Section 5.2.2. Other states are
included only to help with the informative description, such as the 2 states used for tracking
progress through the Cold Start sequence.
2. The Peripheral checks for Bus Reset continuously, independent of its current Link State, even if
the state indicates that an Audio-mode PHY is expected to be active. See PBR_SM in
Section 5.1.6.

5.1.7.3 Time-based Transitions in the PL_SM

2034 Some of the transitions in the PL_SM shown in Figure 57 are dependent upon the duration of the defined
2035 LC signaling conditions. Section 5.1.2.2 describes how the parameter values have been chosen to facilitate
2036 different ways in which Devices might implement their sense of time.

94 Copyright © 2019–2024 MIPI Alliance, Inc.

5.1.7.4 Peripheral Link Control Requests (LC_Requests)

2037 In 2 particular circumstances, the Peripheral can generate an optional request to the Manager to ask that it
2038 start the link. These both use the same Link Control Request (LC_Request) signaling sequence and, in both
2039 cases, the Manager extends the pulse to acknowledge the request. The LC_Request signaling for these 2
2040 scenarios is identical, but the Peripheral pre-condition before the 2 scenarios is different:
2041 • A WakeUp Request, when the Peripheral is in state PL:Sleeping, is dependent on the
2042 WakeReqEnable bit.
2043 • A Cold Boot Request, when the Peripheral is in state PL:Cold_Standby, is dependent on the
2044 Peripheral checking that no Audio-Mode PHY is currently active.
2045 These LC_Requests are related to the PL_SM, but the mechanism is illustrated using a separate Peripheral
2046 Link Control Request state machine (see PLCR_SM in Figure 59) to simplify the description of the main
2047 PL_SM state machine.

5.1.7.4.1 Peripheral Link Control Request State Machine (PLCR_SM)

Initial Cold Reset, e.g.:

• Internal POR detector Bus Reset Detected
• ImpDef_Cold_Reset (see PBR_SM)

LC_Req_
Idle

LC_Idle (i.e., (DP = LC:0) AND (DN = LC:0) )

AND ( ( ( Peripheral supports Cold Boot Request)
NOT LC_Idle, i.e., AND (PL_SM:Cold_Standby) )
NOT ((DP = LC:0) OR ( ( Peripheral supports WakeUp Request)
AND (DN = LC:0)) AND (PL_SM:Sleeping)
AND (WakeReqEnable=1) ) )
Arming
Delay

LC_Idle (i.e., DP=LC:0 AND DN=LC:0) AND

(t Per_tLC_ReqArmingDelay)

NOT LC_Idle, i.e., Armed

NOT ((DP = LC:0)
AND (DN = LC:0))

LC_Idle (i.e., DP=LC:0 AND DN=LC:0) AND

Implementation-defined Trigger_Condition

Output
LC_Req (t Per_tLC_ReqOut)
[LC Tx:1]
2048
Figure 59 Peripheral Link Control Request State Machine (PLCR_SM)

Copyright © 2019–2024 MIPI Alliance, Inc. 95

2049 LC_Requests are generated only when the bus is in the LC_Idle condition and the Peripheral is in an
2050 Inactive Link State (PL_SM is in Sleeping or Cold_Standby), so the PLCR_SM returns to and remains in
2051 the PLCR:LC_Req_Idle state whenever the PL_SM leaves Sleeping or Cold_Standby.
2052 The PLCR:Arming_Delay state prevents the Peripheral generating LC_Requests for a short period after the
2053 Peripheral has entered a Link State of PL:Sleeping or PL:Cold_Standby to allow time for the Manager to
2054 reach ML:Standby_Bus_Idle (when its output on DP changes from LC:0 to LC:weak0, so that the
2055 Peripheral can now overdrive this with LC:1 to indicate the LC_Request). This arming delay also allows all
2056 other Peripherals to reach PL:Sleeping or PL:Cold_Standby ready to receive Warm Start or Cold Start,
2057 even if they were slower to detect the bus having been parked at LC_Idle (DP=LC:0 and DN=LC:0).
2058 After the Peripheral reaches PLCR:Armed, if it then detects the (implementation-defined) internal trigger
2059 condition it generates an LC_Request output of DP=LC:1 for a time defined by the limits of
2060 Per_tLC_ReqOut.
2061 If another Device drives DP to LC:1 (either another Peripheral generating an LC_Request or the Manager
2062 signaling Warm Start or Cold Start) before the trigger condition occurs then this causes the PLCR_SM to
2063 return to PLCR:LC_Req_Idle, so disarms the Peripheral LC_Request output until both the bus has returned
2064 to LC_Idle and another full arming delay has expired. This prevents multiple Peripherals driving a series of
2065 consecutive LC_Requests that could be confused with other signaling. If the trigger conditions in 2 or more
2066 Peripherals occur very close together in time (separated by, e.g., 0.5 microseconds, and by not more than
2067 parameter Per_tLC_ReqDisarm) then multiple Peripherals might drive LC_Request outputs onto DP
2068 simultaneously (see Figure 46 in Section 5.1.2.8). This overlapping drive does not cause any problem
2069 because the Peripherals are actively driving in only one direction (DP=LC:1).

5.1.7.4.2 Peripheral Events that Generate LC_Requests

2070 The conditions that cause a Peripheral to generate an LC_Request are outside the scope of this
2071 Specification, but might include events such as:
2072 • Detecting an external audio jack being plugged in.
2073 • Detecting a voice-activation condition.
2074 • A Peripheral being powered up in a system where this can occur after the Manager powers up.

5.1.7.4.3 Enabling Peripheral LC_Requests

2075 WakeUp Requests (i.e., LC_Requests from a Peripheral in Link State: Sleeping) can occur only after the
2076 Manager has explicitly enabled them by writing 1 to the WakeReqEnable register bit in the Peripheral. This
2077 register bit is cleared to 0 (disabled) after a Cold Reset. Cold Boot Requests (i.e., LC_Requests from a
2078 Peripheral in Link State: Cold_Standby) are enabled by implementation-defined conditions within a
2079 Peripheral.

5.1.7.4.4 PLCR_SM Reaction to an LC_Request

2080 When a Peripheral with a PLCR_SM detects an LC_Request (and is not already driving that LC_Request
2081 itself) it will return to state PLCR:LC_Req_Idle, see Figure 59. This state change suppresses this
2082 Peripheral from being triggered to generate a further LC_Request, although it is possible that two
2083 Peripherals each detect their programmed condition near simultaneously, so that their consequent
2084 LC_Requests overlap on the bus (see Figure 46). The physical signaling used by the Manager during
2085 standby (DP=LC:weak0) and by the Peripheral for an LC_Request (only driving the DP in one direction,
2086 i.e., to LC:1) means that there are no physical signal conflicts between devices that might be driving the bus
2087 simultaneously.

96 Copyright © 2019–2024 MIPI Alliance, Inc.

5.1.7.4.5 Manager Reaction to an LC_Request

2088 When the Manager detects an LC_Request, it will acknowledge it by driving the same signal level
2089 (DP=LC:1) for a period longer than the maximum Peripheral LC_Request output. After that time, the
2090 Manager will be the only Device that is still driving the DP signal, so can end this LC_Acknowledge by
2091 driving the bus back to DP=LC:0 without any possibility of physical drive conflicts, before finally releasing
2092 it back to the Idle condition (DP=LC:weak0).
2093 The Manager LC_Acknowledge is shorter than a Warm Start or Bus Reset pulse, so the PL_SMs in all
2094 Peripherals will remain in, or return to, whichever stae (PL:Sleeping or PL:Cold_Standby) they were in
2095 before the request.

5.1.7.4.6 Peripheral Reaction to an LC_Request

2096 When a Peripheral detects the DP=LC:1 condition of an LC_Request (whether from itself or a different
2097 Peripheral), its reactions are to check for a Warm Start (PL_SM changes from PL:Sleeping to
2098 PL:Warm_Start_Check) and possibly also to check for a Bus Reset (PBR_SM changes from PBR:Armed to
2099 PBR:Delay2). Thus, if the Manager extends the LC_Acknowledge directly into either a Warm Start pulse
2100 (see Section 5.1.2.9) or the Bus Reset at the beginning of a Cold Start, the PL_SM (and PBR_SM) in the
2101 Peripheral will correctly follow these sequences. Thus, a Manager that is ready to restart immediately can
2102 minimize the sleep-wake latency of the system, while a Manager that needs time to prepare for the restart
2103 can issue a simple LC_Acknowledge and then perform a Warm Start or Cold Start at some later time.

5.1.7.4.7 Repeating LC_Requests

2104 When a Peripheral makes an LC_Request but has returned to PL:Sleeping or remained in PL:Cold_Standby
2105 without activating the Audio-mode PHY (i.e., without having reached state PL:Activate_PHY#n), the
2106 Peripheral waits for a minimum cooling off period and then might repeat the LC_Request.
2107 Note:
2108 A Manager typically reacts to an LC_Request by issuing Warm Start or Cold Start and activating
2109 the Audio-mode PHY, but it might take time to do this, or even not activate it at all, e.g., when the
2110 battery status is critical.

5.1.7.5 Self-initiated Hot-Join Behavior in Peripherals

2111 Self-initiated hot-join is an optional method for a Peripheral to join the bus that adds to the mandatory
2112 Manager-initiated Cold Start method.
2113 The basic method for a Peripheral to join the bus is that after a power-on reset it enters the Cold_Standby
2114 Link State, and then waits for the Manager to start the bus by using the Link Control signaling to issue a
2115 Cold Start sequence (see Figure 42). Some Peripherals also implement the optional capability to use Link
2116 Control signaling to send a Cold Boot Request to the Manager to request that it issues this Cold Start
2117 sequence (see Peripheral Link Control Request in Section 5.1.7.4).
2118 In some systems it is possible for a Peripheral to power up into PL:Cold_Standby at a time when the
2119 Manager is already using the bus to talk to other Peripherals. In this case, the Peripheral cannot issue a Cold
2120 Boot Request because this Link Control signaling would clash with the Audio-mode PHY signaling. Some
2121 Peripherals implement the optional capability to detect both which Audio-mode PHY is in use on the bus
2122 and sufficient information about the current Clock Config so that they can attempt to attach to the bus
2123 without waiting for a Cold Start sequence. The mechanisms used to achieve this “self-initiated hot-join”
2124 behavior are implementation-defined.
2125 After the Peripheral has hot-joined the bus and obtained Row Lock, it will go through the normal process of
2126 waiting for a valid Ping Command to enter the PL:Attached state (see Section 5.1.8).

Copyright © 2019–2024 MIPI Alliance, Inc. 97

5.1.8 Peripheral Link State Machine (PL_SM): Active Link

2127 The parts of the Peripheral Link State Machine (PL_SM) that relate to the active link behavior are shown in
2128 Figure 60, and the states are described in Table 4. Figure 58 is a key to the notation used in this diagram.
2129 The light blue box at the top of this figure represents the inactive link part of the PL_SM (see Figure 57 in
2130 Section 5.1.7).

Inactive Link Behavior

(Cold Standby &
Sleep / Wake)
Peripheral
Inactive Link Behavior

Sleeping & Cold Standby

Note:
When the Peripheral moves from Activate_PHY to Activate Deactivate
Locking_to_Row, the PHY_Inactivity detector is not PHY #n PHY #n
enabled until a time of Per_tPhy_Inactivity_Holdoff [Tx Off] [Tx Off]
has expired.

Transition and Active Link Behavior

(including PHY-Specific conditions)
Note: PHY_Inactivity PHY_Inactivity
The normative specification rules treat Syncing
PHY_Inactivity
Locking_to_Row and Syncing_to_Command
as a single state named Syncing. PHY_Inactivity

Locking Ready for

To Row Cold Standby
[TxPowerOn] [Tx Off]
( WakeReqEnable AND
ImpDef Trigger Condition )

PHY_GoodRowLock

PHY_Inactivity
PHY_BadRowLock OR PHY_Inactivity
Bad_Command_Confidence

Syncing To Ready for

Command Sleeping
[TxPowerOn] [Tx Off]

Tx_Power_is_OK AND
PHY_BadRowLock OR Command_Sync_is_OK
Bad_Command_Confidence OR Commit PM_Action:
Commit PM_Action: Force_Resync Enter_Cold_Standby ExitDormant Command OR
PHY_Inactivity ( WakeReqEnable AND ImpDef Trigger Condition )
PHY_Inactivity

Commit PM_Action:
Enter_Sleeping
Attached Dormant
[TxEnabled] Commit PM_Action: [Tx Off]
Enter_Dormant

Commit PM_Action:
2131 Stay_Attached

Figure 60 Peripheral Link State Machine (PL_SM): Active Link States

98 Copyright © 2019–2024 MIPI Alliance, Inc.

5.1.8.1 States in the PL_SM (Active Link States)

2132 The states in the active link part of the PL_SM (Figure 60) are described in Table 4. For clarity, when these
2133 state names are referred to in the text they are preceded with “PL:”.
2134 Table 4 States in the Peripheral Link State Machine: Active Link

State Name Description

See the inactive half of the PL_SM in Figure 57 and the description of
states in Table 3.
<Inactive Link Behavior>
I/O Control:
• The Audio-mode PHY is not active.

The Peripheral is attempting to synchronize to the Row Structure generated

by the Manager. Some of this behavior is PHY-specific. It does not provide
responses to Commands and does not transmit and receive audio payload
data.
E.g., PHY3 (DLV) detects RowSync signals from the manager to lock a
Locking_To_Row
PLL or DLL, whereas PHY1 or PHY2 (FBCSE) might either look for the
/ Syncing [1, 2] NRZS-encoded logic 0 bits from the Control data Stream or know
implicitly in a 2-row Clock Config that the rising clock edge is the start
of Column 0.
I/O Control:
• The Audio-mode PHY Rx is enabled.

The Peripheral is attempting to synchronize to the Command Transport

Protocol within the Control Data Stream generated by the Manager. It does
Syncing_To_Command not provide responses to Commands and does not transmit and receive
/ Syncing [1, 2] audio payload data.
I/O Control:
• The Audio-mode PHY Rx is enabled.

The Peripheral is actively participating on the bus; it can provide responses

to Commands and can transmit and receive audio payload data.
Attached [2] I/O Control:
• The Audio-mode PHY Rx is enabled, and the Tx is under the control
of the higher layers (Command Protocol and Payload Transport).

The Peripheral is waiting for the Manager to stop using the Audio-mode
PHY to communicate with other Peripherals on the bus (PHY-specific
condition).
Power Control:
Ready_for_Cold_Standby [2] • The Peripheral might remove power from all circuitry (except for the
PHY_Inactivity Detector and the Bus Reset Detector) in advance of
the pending change to Cold_Standby.
I/O Control:
• The Audio-mode PHY_Inactivity Detector is enabled (but not
necessarily all of the Rx circuit).

Copyright © 2019–2024 MIPI Alliance, Inc. 99

State Name Description

The Peripheral might be monitoring ImpDef internal conditions that could

provoke it to attempt to reattach to the bus.
Power Control:
• Circuits such as DLL/PLL for clock recovery or voltage regulators for
Ready_for_Sleeping [2] PHY3 (DLV) Tx might be turned off.
• The Peripheral might put all other circuitry in a low-power state in
advance of the pending change to Sleeping.
I/O Control:
• The Audio-mode PHY_Inactivity Detector is enabled (but not
necessarily all of the Rx circuit).

The behavior described using Peripheral Link State: Dormant is

optional to implement.
The Peripheral is monitoring the Control Data Stream on the bus, (looking
for the ExitDormant Command) but is not actively participating in
Commands or Payload.
Dormant [2] The Peripheral might be monitoring (implementation-defined) internal
trigger conditions that could provoke it to attempt to reattach to the bus.
Power Control:
• Circuits such as voltage regulators for PHY3 (DLV) Tx might be
turned off.
I/O Control:
• The Audio-mode PHY Rx is enabled, but the Tx is NOT enabled.

2135 Note:
1. The state names Locking_to_Row and Syncing_to_Command are included to help with the
informative description; they correspond to the single state of Syncing in the normative material
in Section 5.2.2.
2. The state names Syncing, Attached, Ready_for_Cold_Standby, Ready_for_Sleeping, and
Dormant are colored purple to indicate that these states correspond to terms used in the
normative material in Section 5.2.2.
2136 Note:
2137 The Peripheral Bus Reset detector is permanently active, so it remains active even in states when
2138 the Audio-mode PHY might be off (Sleeping or Cold_Standby) or only partially on (Dormant,
2139 Ready_for_Sleeping, or Ready_for_Cold_Standby).
2140 Note:
2141 Some of the conditions that cause changes between the Active Link states are PHY-Specific: see
2142 the links from the normative material in Section 5.2.2 to PHY-specific sections. These conditions
2143 are colored red in Figure 60, e.g., PHY_BadRowLock.
2144 Note:
2145 PHY_Inactivity is a PHY-specific condition described and specified in the PHY-specific sections
2146 and can involve both dynamic and static conditions. E.g, the Manager can avoid triggering the
2147 FBCSE PHY_Inactivity Detector by pausing the clock (DN) at 1 with data (DP)=1.

100 Copyright © 2019–2024 MIPI Alliance, Inc.

2148 Table 5 summarizes the stimulus conditions for the PL_SM in Figure 60.
2149 Table 5 Transitions in the PL_SM (Active States)

Condition Description

The Command Transport Protocol decoder detected 1 error-free Ping

Command addressed to this Peripheral.
For this condition, “error-free” includes good Robust Tokens, valid
Command_Sync_is_OK
PhaseID, no transport errors in information from the Manager (either
8b10b or CRC), and no Command Error (i.e., correct PacketLength and
valid Ping Opcode).

The Command Transport Protocol decoder has not decoded any valid and
error-free Phase Header addressed to this Peripheral for the last 8192 Rows.
Bad_Command_Confidence This depends only on good Robust Tokens in the Header and a valid
PhaseID. It is not affected by transport errors in the Manager Packet or
by Command Errors.

The Peripheral reaches the Commit Synchronization Point of an SSCR or

Commit PM_Action <value> DSCR that includes Commit Group 0, and the PM_Action register field has
the stated value.

The Command Transport Protocol Decoder saw an error-free ExitDormant

ExitDormant Command
Command (see Section 9.1.7) addressed to this Peripheral.

The Peripheral detected an implementation-defined trigger condition.

Trigger Condition
E.g., a timer, or a codec detecting a device plugged into a jack.

PHY-specific conditions for deciding that Row clock and Bit clock are good.
PHY_GoodRowLock E.g., for PHY3 (DLV), the bit clock PLL/DLL is locked to the Row Sync
sequence.

PHY-specific conditions for deciding that Row clock and Bit clock are bad.
PHY_BadRowLock E.g., for PHY3 (DLV), the Peripheral has not seen an S0-to-S1 Sync
edge for any of the last 10 Rows.

Time-based PHY-specific conditions for deciding that the Manager is no

longer actively using the Audio-Mode PHY. E.g.,
• For PHY3 (DLV), there has been no change in received value for
Per_tPhy_Inactivity_DLV.
• For PHY1 & PHY2 (FBCSE), the bus has been fixed at (DP=0, DN=0)
for a time of Per_tPhy_Inactivity_FBCSE.
Note:
Section 5.1.8.2 explains the relationship between PHY_Inactivity and
PHY_Inactivity PHY_Idle.
Note:
When the Peripheral activates the Audio-mode PHY (i.e., after exiting
from Sleeping or Cold_Standby), the PHY_Inactivity detector is
suppressed for a short period (Per_tPhy_Inactivity_HoldOff). This avoids
a false positive where a Peripheral that activates its PHY quickly could
decide that a slow Manager has finished using the PHY before it has
actually started using the PHY.

Copyright © 2019–2024 MIPI Alliance, Inc. 101

5.1.8.2 Relationship Between Idle Bus and PHY_Inactivity

2150 When the Manager changes the bus from a Link-Active state (bus signals use the Audio-mode PHY) to a
2151 Link-Inactive state (bus signals use the Link Control PHY) it first uses a Commit command to commit a
2152 PM_Action of Enter_Sleeping or Enter_ColdStandby in each Peripheral and then parks the bus at a
2153 PHY-specific idle condition for a defined period of time. This idle condition is chosen to be compatible
2154 with the transition in signaling levels from the Audio-mode PHY to the Link Control PHY.
2155 Peripherals have an over-riding PHY-Specific PHY_Inactivity Detector that will be triggered by the
2156 PHY-specific idle condition on the bus for a time longer than can occur during normal activity, and so cause
2157 them to recognize that the Manager is changing the bus to a Link-Inactive state even when they have not
2158 received a Commit command that explicitly directed them to do this (e.g., because of a transport error).
2159 When the PHY_Inactivity Detector is triggered, the Peripheral will transition towards an inactive Link
2160 State (either Sleeping or Cold_Standby) according to the value of PM_Action.

5.1.8.3 Power Saving in Ready_for_Sleeping and Ready_for_Cold_Standby

2161 The Manager can use PM_Action to direct some Peripherals to Stay_Attached to the bus while other
2162 Peripherals have been told to Enter_Sleeping or Enter_Cold_Standby to reduce system power consumption.
2163 In this case, the Peripherals directed to Enter_Sleeping or Enter_Cold_Standby can perform most of the
2164 power saving associated with those Link States, but will keep enough of their Audio-mode PHY Rx
2165 behavior alive so that the PHY_Inactivity Detector can determine when the Manager has finally stopped
2166 using the Audio-mode PHY. These interim low-power states are illustrated in the informative PL_SM by
2167 the states PL:Ready_for_Sleeping and PL:Ready_for_Cold_Standby (see Figure 60).

5.1.8.4 Bad Command Confidence in Peripheral

2168 The Peripheral will detach from the bus (i.e., change from PL:Attached to PL:Syncing) when it loses
2169 confidence that its Command decoder is interpreting a valid Command Transport Protocol stream from the
2170 Manager. This occurs when the Peripheral has not seen a valid and error-free Header for a large number of
2171 Rows.
2172 The longest single Command Transport Protocol Phase is a 256-byte read, which occupies around 2870
2173 Rows.
2174 Assuming that bit errors corrupt just one Header, then the worst case spacing of valid headers is in a
2175 continuous stream of the longest possible Command Transport Protocol Phases, which are 256-byte reads
2176 that occupy around 2870 Rows. Thus, the valid and error-free Headers would be separated by 5740 Rows,
2177 which would still be well within the Command Confidence threshold of 8192 Rows (chosen as a suitable
2178 power of 2 above this figure). In practice a Manager would typically interleave shorter Ping Commands, so
2179 the Peripheral could tolerate more than 1 of the Phases being corrupted while still seeing at least 1
2180 error-free header within the Command Confidence threshold and so not detaching from the bus.
2181 Note:
2182 8192 Rows at 3.072 MRows/sec is ~2.7 msec. 8192 Rows at 600 kRows/sec is ~10.67 msec.

102 Copyright © 2019–2024 MIPI Alliance, Inc.

5.1.9 Manager Link State Machine (ML_SM): Inactive Link

2183 The parts of the Manager Link State Machine (ML_SM) that relate to the Inactive Link (when Peripherals
2184 are in Cold_Standby or Sleeping) are shown in Figure 61. The Manager follows this generic behavior,
2185 independently of which Audio-mode PHY(s) are implemented.

Manager Initial Reset, e.g.:

• Internal POR detector
• ImpDef_Host_Reset

Parking
Bus LC
LC Tx: {0,0}

Man_tParkBus_LC00

Inactive Link Behavior

(Standby_Bus_Idle)
Man_tLC_AckOut

Standby LC_Request AND Generate

Bus Idle HostChoosesLC_Ack LC_Ack
LC Tx: {w0,0} LC Tx:
[LC Rx] sequence

Host_DoColdStart OR Host_DoWarmStart OR
(LC_Request AND HostChoosesColdStart) (LC_Request AND HostChoosesWarmStart)

Generate Generate
Cold Start Warm Start
D3 D2 D1 D0
LC Tx: LC Tx:
sequence sequence

Tx_Ready_LC_PHY

Activate Deactivate Transition and Active Link Behavior

PHY #n PHY #n
(PHY-Specific Conditions)
Tx_Ready_PHY#n

Bus_Is_Parked_PHY#n

PHY-Specific Active Link Behavior

(e.g., Command_Only, Payload, Parking_Bus_PHY#n)

One set of states for each PHY Number that is implemented in the Manager.
2186 (See detail in PHY-specific sections.)

Figure 61 Manager Link State Machine (ML_SM): Inactive Link Behavior

Copyright © 2019–2024 MIPI Alliance, Inc. 103

2187 A Manager implements one or more of the Audio-mode PHYs described in this Specification. The ML_SM
2188 contains the set of generic Link States shown in Figure 61, plus one set of the PHY-specific states (for
2189 transition, synchronization, and active communication) for each of the PHYs that are implemented within
2190 the Manager. The PHY-specific states are described in more detail in Section 5.1.10.

5.1.9.1 Key to the ML_SM

2191 Figure 62 is a key to the color coding and notation used in the ML_SM state diagrams: Figure 61,
2192 Figure 63 and Figure 64.

State Name Link Control state in which the Manager uses PHY-specific states for graceful
State Name
LC Tx: DP/DN Link Control signaling to drive specified values transition between LC PHY signaling
PHY #n
(or a sequence of values) on DP and DN. and Audio-mode PHY#n signaling.

Link Control state in which the Manager uses

State Name Link Control signaling to drive specified values State Name PHY-specific states for controlling
LC Tx: DP/DN on DP and DN, and also senses the input on DP PHY #n the Active Link using the selected
to detect a Link Control Request from a [PHY Tx] Audio-mode PHY#n signaling.
[LC Rx]
Peripheral.

Condition Normal state transition caused by logical

conditions within the Manager. Parking Bus PHY-specific states for parking the
PHY #n bus in the PHY-specific idle state
Shorthand notation for forced direct state transition [PHY Tx] using Audio-mode PHY#n signaling.
from any state to ML:Parking_Bus_LC when the
Manager receives a reset stimulus.
2193
Figure 62 Key to Manager Link State Machine Diagram (ML_SM)

104 Copyright © 2019–2024 MIPI Alliance, Inc.

5.1.9.2 States in the ML_SM (Inactive Link States)

2194 The states in the ML_SM are described in Table 6. For clarity, when these states are referred to in the text
2195 they are preceded with “ML:”.
2196 Table 6 States in the Manager Link State Machine (ML_SM)

ML_SM State Description

The Manager actively parks the bus in the Link Control Idle (LC_Idle) condition
Parking_Bus_LC [1]
(driving DP=LC:Strong0 and DN=LC:0) before moving to ML:Standby_Bus_Idle.

The Manager holds the bus in the LC_Idle condition (driving DP=LC:weak0 and
Standby_Bus_Idle [1] DN=LC:0) while all Peripherals are either powered off or in Sleep or Cold_Standby.
The Manager uses the LC_Rx to detect LC_Requests from the Peripheral(s).

The Manager extends a Peripheral LC_Request to generate an LC_Acknowledge

Generate_LC_Ack
(see Section 5.1.2.6) and then parks the bus back at LC_Idle.

The Manager generates a Cold Start sequence (Bus Reset + PHY Selection +
Generate_ColdStart
PHY Activation Edge, see Section 5.1.2.4).

The Manager generates a Warm Start sequence (Warm Start Pulse + PHY
Generate_WarmStart
Activation Edge, see Section 5.1.2.5).

The Manager activates implementation-defined internal circuitry for the selected

Activate_PHY Audio-mode PHY (such as DLL/PLL, LDO regulator for Tx, reference voltage for
Rx).

The Manager deactivates implementation-defined internal Audio-mode PHY

Deactivate_PHY circuitry for the selected Audio-mode PHY (such as DLL/PLL, LDO regulator for Tx,
reference voltage for Rx) and switches to using the LC_PHY.

The selected Audio-mode PHY is active.

<PHY-specific Active
See the Active Link half of the ML_SM in Figure 63 or Figure 64 and the
Link States>
description of states in Table 7.

2197 Note:
1. The state names ML:Parking_Bus_LC and ML:Standby_Bus_Idle are colored purple to indicate
that these states corresponds to terms used in the normative material in Section 5.2.3; other
states are included only to help with the informative description, such as the 3 states used for
generating each of LC_Ack, Cold Start, and Warm Start.

Copyright © 2019–2024 MIPI Alliance, Inc. 105

5.1.10 Manager Link State Machine (ML_SM) for Active States

2198 The parts of the Manager Link State Machine (ML_SM) that relate to the active link behavior using PHY3
2199 (DLV) are shown in Figure 63, and a similar diagram for using PHY1 or PHY2 (FBCSE) is shown in
2200 Figure 64. The states in these figures are described in Table 7. Figure 62 is a key to the notation used in
2201 these diagrams. The light blue boxes at the top of each of these figures represent the inactive link part of the
2202 ML_SM (see Figure 61 and Table 6).

(Standby_Bus_Idle)
Inactive States
Parking
Bus LC
LC Tx: {0,0}

Manager Generic Link Control

Standby Bus Idle,
Generate Cold Start,
Generate Warm Start
Generate LC_Acknowledge

LC PHY Tx Activated

Transition and Active Link Behavior

Activate Deactivate
PHY #3 PHY #3

DLV PHY-Specific
Start_Link

Bus_is_Parked_DLV
(DP/DN = DLV:0)

Command Stop_Link Parking Bus

Only DLV DLV
[DLV Tx] [DLV Tx]

Payload
DLV Stop_Link
[DLV Tx]

2203
Figure 63 Manager Link State Machine (ML_SM): Active Link Behavior for PHY3 (DLV)

106 Copyright © 2019–2024 MIPI Alliance, Inc.

(Standby_Bus_Idle)
Inactive States
Parking
Bus LC
LC Tx: {0,0}

Manager Generic Link Control

Standby Bus Idle,
Generate Cold Start,
Generate Warm Start
Generate LC_Acknowledge

LC PHY Tx Activated

Transition and Active Link Behavior

Activate Deactivate
PHY #1 PHY #1
#2 #2

FBCSE PHY-Specific
Start_Link

Bus_is_Parked_FBCSE
(DP = FBCSE:0)
(DN = FBCSE:0)

Command Stop_Link Parking Bus

Only FBCSE FBCSE
[FBCSE Tx] [FBCSE Tx]

Clock Pause
FBCSE
[FBCSE Tx]

Payload
FBCSE Stop_Link
[FBCSE Tx]

2204
Figure 64 Manager Link State Machine (ML_SM): Active Link Behavior for PHY1 or PHY2
(FBCSE)

Copyright © 2019–2024 MIPI Alliance, Inc. 107

2205 Table 7 States in the Manager Link State Machine: Active Link

State Name Description

<Inactive Link States> See description of states in the ML_SM: Inactive States in Table 6.

The Transport Pattern contains only a Control Data Stream co-ordinated by the
Command_Only_DLV Manager. Neither the Manager nor any of the Peripherals generate any Payload
Command_Only_FBCSE data streams. This “clean” Transport Pattern facilitates the Peripherals
synchronizing to the Control Data Stream.

This is the “normal” state of an active link: The Transport pattern contains a
Payload_DLV
Control Data Stream co-ordinated by the Manager, and might also contain
Payload_FBCSE payload data streams output by any of the Manager and Peripherals.

The behavior described using this state is optional to implement.

Clock_Pause_FBCSE The Manager “freezes time” by pausing the forwarded bit clock while driving
particular levels on both the clock and data lines.

The Manager generates a value or sequence of values that will trigger the
Parking_Bus_DLV
PHY_Inactivity Detector in the Peripherals, so causing them to deactivate their
Parking_Bus_FBCSE PHY and change to either Sleeping or Cold_Standby.

108 Copyright © 2019–2024 MIPI Alliance, Inc.

5.1.11 Choice of Clock Config and Transport Pattern

5.1.11.1 PHY-Specific Limits on Clock Config and Transport Pattern

2206 The Section for each PHY includes a description of any PHY-specific constraints relating to Clock Config
2207 and Transport Pattern such as valid ranges of Row Rate and Bit Rate, and how Clock Config can be
2208 changed dynamically, e.g.,
2209 • PHY1 and PHY2 (FBCSE), see Section 11.1.2.
2210 • PHY3 (DLV), see Section 12.1.6.

5.1.11.2 Clock Config and Transport Pattern for Cold Start (Safe-Lock-N)
2211 When the Manager issues a Cold Start sequence, it starts with a Clock Config and Transport Pattern that is
2212 referred to as a “Safe-Lock-N” config. This is a combination of:
2213 • A Clock Config (combination of Row rate, Bit Rate, and Column Count) that is known to operate
2214 correctly when Peripherals are using the reset values of the PHY Control parameters (drive
2215 impedance, slew rate, etc.), and
2216 • A Command-Only Transport Pattern using CDS Transport parameters that makes it easy for
2217 Peripherals to synchronize to the Control Data Stream.
2218 The software controling the Manager will program PHY settings that are appropriate for the system prior to
2219 issuing the Cold Start sequence.
2220 The clock and transport settings for Safe-Lock-N are PHY-Specific, and are described within the Section
2221 for each PHY, e.g.,
2222 • PHY1 and PHY2 (FBCSE), see Section 11.1.2.
2223 • PHY3 (DLV), see Section 12.1.6.

5.1.11.3 Clock Config and Transport Pattern for Warm Start

2224 When the Manager issues a Warm Start sequence, it starts with the Clock Config and Transport Pattern that
2225 was described by the Registers when the Peripherals were sent to Sleep. The Warm Reset that occurs when
2226 a Peripheral changes to Link State: Sleeping will have turned off all of the Payload transport, leaving a
2227 Command-Only Transport Pattern that facilitates the Peripherals synchronizing to the Control Data Stream
2228 after the Warm Start.
2229 Note:
2230 The contents of the *_CURR registers that define the peripheral behavior after the Warm Start
2231 could have been updated from the *_NEXT registers by the same Commit operation that caused
2232 the peripherals to perform the PM_Action of Enter_Sleeping.

Copyright © 2019–2024 MIPI Alliance, Inc. 109

5.1.11.4 Manager Flow for Clock Config and Transport Pattern

2233 Figure 65 illustrates the flow for how the Manager uses combinations of Clock Config and Transport
2234 Pattern, such as those described for PHY3 (DLV) in Table 125.

Activate PHY

Set Clock Config: Safe-Lock-N

(PHY-specific constraints)

Commands: Tear Down any

Set New Clock Config: Any
Active Audio Streams

Set Transport Pattern: Command-Only

(Lock-N, i.e., no Audio Payload) Yes

Do Peripheral(s)
No
Set New Clock Config: Any need Command-Only
to Re-attach?

Commands: Frequent Pings

(e.g., continuous)

Ping reports that

No
all Peripheral(s)
are Attached?

Yes

Set Transport Pattern: Any

(including Audio Payload)

Commands: Occasional Pings

(e.g. 1 msec, aperiodic)

Ping reports that

No
all Peripheral(s)
are Attached?

Yes

Host Wants to
No
Change Clock Config?

Yes

Can All Peripheral(s)

Remain Attached through this
No
Change to Clock Config?

Yes

Set New Clock Config: Any

2235
Figure 65 Manager Flow for Changing Clock Config

2236 ###TODO-Author: update this figure to show Warm Start using the previous settings rather than
2237 Safe-Lock-N. Replace this with a flow chart that is generic to all PHYs (see 2 v0.4r39 review comments
2238 on Figure 15).

110 Copyright © 2019–2024 MIPI Alliance, Inc.

5.2 Specifications (normative)

5.2.1 Reset

2239 Requirements
2240 1. {} A Peripheral shall implement each source of reset listed in Table 8 for which the table indicates
2241 either of:
2242 A. Mandatory, or:
2243 B. Conditional (and the stated condition is true).
2244 (See also Permission 1.)

2245 Table 8 Sources of Reset in Peripheral

Mandatory
Source of Reset Severity Description / Notes
/ Optional?

The Peripheral detects a Bus Reset

Bus_Reset Mandatory Cold sequence (see Section 5.2.2
Requirement 6).

E.g., on-chip detection or signal from

Power_On_Reset Mandatory Cold
external PMIC.

The Peripheral detects unexpected

PHY_Inactivity (i.e., when the Peripheral is
in Link State: Attached, see Section 5.2.2
PHY_Inactivity Detector Requirement 20.A).
(only when in Link State: Mandatory Warm Note: The Peripheral will normally have
Attached). been Warm reset by commiting a
PM_Action before the Manager stops
using the Audio-mode PHY to trigger
the Inactivity Detector.

PM_Action: The Peripheral performs the Commit

Force_Resync, operation from a Commit Command when
Enter_Dormant, Mandatory Warm PM_Action indicates anything other than
Enter_Sleeping, Stay_Attached, (see Section 5.2.2
Enter_Cold_Standby. Requirement 17.B.i).

The Command Protocol Decoder did not

Detached from bus due to detect valid Commands within the expected
Mandatory Warm
Bad_Command_Confidence time window (see Section 5.2.2
Requirement 14.D).

The PHY-specific PHY_BadRowLock

condition caused the Audio-mode PHY to not
Detached from bus due to Conditional
Warm have a reliable bit clock and/or row clock
PHY_BadRowLock (DLV PHY) (e.g., a PLL/DLL went out of lock).
(see Section 5.2.2 Requirement 14.C).

ImpDef_Cold_Reset Optional Cold Implementation-defined source.

Copyright © 2019–2024 MIPI Alliance, Inc. 111

Mandatory
Source of Reset Severity Description / Notes
/ Optional?

###TODO-Author: replace
ImpDef_WarmReset with Optional Warm Implementation-defined source.
new ImpDef_ForceResync

2246 2. When a Peripheral receives a reset from any of the sources listed in Table 8, it shall change all of
2247 the state shown in Table 9 as being affected by the Severity of that reset (i.e., Cold or Warm, as
2248 shown in Table 8).
2249 3. When a Peripheral receives a reset, it shall preserve the value of any state listed in Table 9 where
2250 the table shows that the state is not affected by the Severity of that reset (i.e., Cold or Warm, as
2251 shown in Table 8).
2252 Table 9 Effects of Reset in Peripheral

Affected
State or Function by which Action of Reset on that State or Function
Reset

See Cold Reset Value in tables of Register Fields in

Section 14.2.
Note:
Where the Cold Reset Value is shown as
All SWI3S-defined Registers “implementation-defined” this means that the value that
not specifically mentioned in Cold is chosen by the implementor and, e.g., might be related
this table. to pins that are sampled at Cold Reset.
Note:
All SWI3S Registers defined in this Specification and
not explicitly described in this table are preserved
through Warm Resets.

Details are PHY-dependent and are specified in the

appropriate PHY-specific Link Control Behavior Section:
• PHY1 & PHY2 (FBCSE PHY): Section 11.2.1.
Clock Config &
• PHY3 (DLV): Section 12.2.1.
CDS Transport Parameters Cold
Note:
(PHY-dependent values)
When a PHY is activated following a Cold Reset, the
Peripheral will set its expected Clock Config to be the
Initial Clock Config specified for that particular PHY.

Cold Disable all payload streams (i.e., all DPn_EnableCh<c> bits

DPn_EnableCh<c>_CURR
Warm change to 0).

Disable all payload streams (i.e., all DPn_EnableCh<c> bits

change to 0).
Note:
DPn_EnableCh<c>_NEXT Cold The _NEXT bits are NOT changed by Warm Reset,
which facilitates resuming audio flow more quickly after
a Sleep-Wake cycle, or when a Peripheral falls off the
bus and then reattaches.

112 Copyright © 2019–2024 MIPI Alliance, Inc.

Affected
State or Function by which Action of Reset on that State or Function
Reset

DPn is not (known to be) synchronised to the Transport

Interval.
Cold Note:
DPn_PortSyncOK
Warm When the Transport Interval in DPn is 1 Row (or a
fraction of 1 Row) then DPn_PortSyncOK will become 1
immediately when the Peripheral re-attaches.

Cold Any incomplete SPM that is in progress is abandoned, and

SPM Detector
Warm the Peripheral resumes waiting for a new SPM.

Command Transport Cold Any incomplete Phase that is in progress is abandoned, and
Protocol Decoder Warm the Peripheral resumes waiting for a new SPM.

Any buffered remote write or deferred remote read that is not

Cold
Command Interpreter complete is abandoned (and thus Remote Accesses become
Warm disabled), see Section 9.2.2 Requirement 4.

Cold All in-flight SSCR and DSCR Commit operations are

SSCR and DSCR Counters
Warm cancelled.

Cold
SDCA-defined Registers and
(Optional: See SDCA Specification, [MIPI02].
state.
Warm)

Values after Cold Reset are Implementation-defined.

Cold It is implementation-defined whether Warm Reset affects the
Any implementation-defined
(Optional: value of ImpDef Registers and state. The values after Warm
Registers and state.
Warm) Reset are Implementation-defined and can be different to
those after Cold Reset.

Set PM_Action to 0x0 (Stay_Attached).

Note: PM_Action is not cleared by Warm Reset, but the
PM_Action Cold effects of commiting values of PM_Action that cause a
Warm Reset will eventually also result in it being cleared
to 0x0 (Stay_Attached), see Section 5.2.2
Requirements 17.B.iii and 20.E.iii.

All Channels are De-prepared by Cold Reset (i.e.,

DPn_PrepareCh<c>_CURR
Cold DPn_PrepareCh<c>=0).
DPn_PrepareCh<c>_NEXT
Note: But not affected by Warm Reset.

Reset values of DP parameters are defined in

Section 14.2.3.
DP Transport Parameters Cold
Note: Some reset values are ImpDef, and could even
be pin strapped.

Copyright © 2019–2024 MIPI Alliance, Inc. 113

Affected
State or Function by which Action of Reset on that State or Function
Reset

Reset values of Shared Transport parameters are defined in

Shared Transport Section 14.2.5.
Cold
Parameters Note: Some reset values are ImpDef, and could even
be pin strapped.

Each Data Port is a member of only TCG0.

Data Port Commit Groups Cold (i.e., Commit_Group_Membership field is reset to
b0001, see ###XREF)

Interrupt Enable
Cold Disable all SWI3S-defined interrupts (i.e., IntEnable[c]=0).
(SWI3S-defined interrupts)

Interrupt Enable (SDCA

Cold Disable all SWI3S-defined cascades (IntEnable[c]=0).
Interrupts)

Interrupt Enable (ImpDef

Cold IntEnable[ImpDef i] might be reset to an ImpDef value.
interrupts)

Interrupt Status Cold All IntStat[x] bits are reset to 0.

The Peripheral deactivates the current Audio-mode PHY,

Peripheral Link State. Cold waits for DP=LC:0 then enters Link State: Cold_Standby
(see Section 5.2.2 Requirement 5).

Set WakeReqEnable to 0 (i.e., disable the Peripheral from

generating any WakeUp requests (see Section 5.2.2
WakeReqEnable field (see
Cold Permission 2).
Section ###XREF)
Note: this bit does not affect the Peripheral generating
Cold Boot Requests (see Section 5.2.2 Permission 3).

Optional Debug Counters Cold Clear debug counters to 0.

The reset values of SWI3S registers are shown in

Section ###XREF. Where these are shown as
Any other SWI3S Registers “implement-defined” this means that they have a value
and SWI3S Peripheral state that is chosen by the implementor and, e.g., might be
not shown in this Table Cold related to pins that are sampled at Cold Reset.
(excluding Implementation- Note:
defined and SDCA). All SWI3S Registers defined in this Specification and
not explicitly described in this table are preserved
through Warm Resets.

114 Copyright © 2019–2024 MIPI Alliance, Inc.

2253 4. A Manager shall implement each source of reset listed in Table 10 for which the table indicates
2254 Mandatory. (See also: Permission 3.)
2255 Table 10 Sources of Reset in Manager

Mandatory
Source of Reset Description / Notes
/ Optional?

E.g., on-chip detection or signal from external

PowerOnReset Mandatory
PMIC.

ImpDef_Cold_Reset Optional Implementation-defined source.

2256 5. When a Manager receives a reset from any of the sources listed in Table 10, it shall change all of
2257 the state shown in Table 11 shown as Mandatory.
2258 Table 11 Effects of Reset in Manager

Mandatory /
State or Function Action of Reset on that State or Function
Optional?

DPn_EnableCh<c>_CURR Mandatory Disable all payload streams.

Set the RD for the next 8b10b symbol to be − .

Control Data Stream Mandatory
(see Section ###XREF Requirement ###XREF)

Command Transport
Mandatory Discard any incomplete Phases.
Protocol

Command Interpreter Mandatory Discard any outstanding Reads or Writes.

Any other Registers and

For the Manager it is optional for all remaining
Manager state not shown in
Optional Registers and state whether they are affected by
this Table (excluding
Cold or Warm Resets (see Permission 4).
Implementation-defined).

Any implementation-defined
Optional Behavior is implementation-defined.
Registers and state.

2259 Permissions
2260 1. A Peripheral may implement any of the sources of reset listed in Table 8 that are shown as
2261 Optional.
2262 2. When a Peripheral receives a Warm Reset from any of the sources listed in Table 8, it may reset
2263 the state shown in Table 9 as being affected by “(Optional: Warm)” Reset.
2264 3. A Manager may implement any of the sources of reset listed in Table 10 that are shown as
2265 Optional.
2266 4. When a Manager receives a reset from any of the sources listed in Table 10, it may reset the state
2267 shown in Table 11 as being Optional.

2268 Recommendations
2269 1. When a Peripheral resets Optional state according to Permission 2, it should reset it to the value
2270 shown in Table 9.

Copyright © 2019–2024 MIPI Alliance, Inc. 115

5.2.2 Peripheral Link Control

2271 Requirements
2272 1. {6101} A Peripheral shall be in one of the Link States shown in Table 12:
2273 Table 12 Peripheral Link States
Mandatory Which PHY is Rules Describing Behavior in this
State Name
/ Optional? Active? State (Informative)
Power off — — —
Requirements 5, 6, 7, 8, 9, 10.
Cold_Standby Mandatory Link Control Permissions: 1, 3, 5.
Recommendations: 2.
Requirements 6, 7, 8, 11, 12.
Sleeping Mandatory Link Control Permissions: 1, 2, 4.
Recommendations: 1.
Audio-mode PHY Requirements: 2, 6, 7, 8, 13, 19, 20.
Syncing Mandatory
(only the Rx) Permissions: 6.
Requirements: 2, 6, 7, 8, 14, 15, 16,
Attached Mandatory Audio-mode PHY 17, 20.
Permission: 11.
Audio-mode PHY Requirements: 2, 6, 7, 8, 20, 23.
Ready_for_Cold_Standby Mandatory (only the Inactivity
Permissions: 1.
Detector)
Audio-mode PHY Requirements: 2, 6, 7, 8, 20, 23.
Ready_for_Sleeping Mandatory (only the Inactivity
Permissions: 1, 9.
Detector)
Audio-mode PHY Requirements: 2, 6, 7, 8, 20, 21, 22.
Dormant Optional
(only the Rx) Permissions: 1, 7, 8.

116 Copyright © 2019–2024 MIPI Alliance, Inc.

2274 2. {6102} While a Peripheral is in any of Link States: Syncing, Attached, Dormant,
2275 Ready_for_Sleeping, or Ready_for_Cold_Standby, it shall transfer data using the Audio-mode
2276 PHY according to Table 13:
2277 Table 13 Summary of Peripheral Data Transfer in Link States
Control Data Stream Payload Data
Link State Notes
Activity Activity
Rx-Only, searching for
valid Ping Command to
Syncing None —
attach to bus.
(Requirement 13.B)
Tx & Rx, interpreting When
Attached Commands normally. EnableCh<c>=1 —
(Requirement 16) (see Section 13.2)
Rx-Only, searching for Imp-Def condition can
Dormant ExitDormant Command None cause change to Syncing
(Requirement 21) (Permission 7)

Imp-Def condition can

Ready_for_Sleeping None None cause change to Syncing
(Permission 9)
Ready_for_Cold_Standby None None —

2278 3. {6103} When the Peripheral detects or generates the Link Control signals described in this Section
2279 (5.2.2), it shall use the Link Control signaling levels described in Section 6.
2280 4. {6104} The Peripheral shall use values for the timing parameters named in this Section (5.2.2) that
2281 are between the lower and upper bounds in Table 14.
2282 Note: i.e., the Min and Max values in the table are the lower and upper bounds for the values in a
2283 Peripheral datasheet.

2284 Table 14 Timing Parameters for Peripheral Link Control Sequences

Parameter Min Typ Max Units Description

Limits on Peripheral Behavior

Limits on the actual time

threshold that a Peripheral
Per_tReset00 64 — 192 µs uses when detecting LC:00 as
part of a Bus Reset sequence.
See Requirement 7.A.

Limits on the actual time

threshold that a Peripheral
Per_tReset10 516 — 1548 µs uses when detecting LC:10 as
part of a Bus Reset sequence.
See Requirement 7.B.

Copyright © 2019–2024 MIPI Alliance, Inc. 117

Parameter Min Typ Max Units Description

Limits on the actual time

threshold that a Peripheral
uses when detecting LC:10 as
Per_tWarmStart 145 — 435 µs part of a Warm Start
sequence.
See Requirement 11.A.

Limits on time between

receiving PhyStart falling edge
See PHY-specific on DP (at the end of Cold Start
requirements and/or or Warm Start) and the
Per_tPhyStart [1] recommendations in Peripheral starting to observe
PHY-specific tables linked Audio-mode PHY signaling
from Table 16. transitions from the Manager.
See Requirements 10.A and
12.A.

Duration of observing Bus Idle

(DP=LC:0 and DN=LC:0)
before generating a Peripheral
Per_tLC_ReqArmingDelay 134 — — µs LC_Request.
See Requirements 24.A and
25.A.

Duration of driving DP=LC:1

when generating a Peripheral
Per_tLC_ReqOut_Cycle-based [2] 33 — 66 µs
LC_Request.
See Requirement 24.C.

A Peripheral cannot start

Per_tLC_ReqDisarm_Cycle-base [2]
driving its own LC_Request
Note: this looser parameter value — — 33 µs later than this time after a DP
applies only when used with rising edge.
Per_tLC_ReqOut_Cycle-based
See Requirement 24.B.

Per_tLC_ReqOut_Time-based [2] Duration of driving DP=LC:1

Note: this looser parameter value when generating a Peripheral
33 — 99 µs
applies only when used with LC_Request.
Per_tLC_ReqDisarm_Time-based See Requirement 25.C.

A Peripheral cannot start

driving its own LC_Request
Per_tLC_ReqDisarm_Time-based [2] — — 1 µs later than this time after a DP
rising edge.
See Requirement 25.B.

Delay after the PHY Activation

Edge before the
Per_tPhy_Inactivity_HoldOff 99 — 297 µs PHY_Inactivity Detector can
cause re-entry to standby.
See Requirement 19.A.

118 Copyright © 2019–2024 MIPI Alliance, Inc.

Parameter Min Typ Max Units Description

Recommended Peripheral Behavior

Recommended interval before

the Peripheral repeats a
WakeUp Request or Cold Boot
Per_tLC_ReqRepeat 5 — — ms
Request.
See Recommendations 1
and 2.

See PHY-specific
recommendations in See Requirements 10.A and
Per_tPhyStart [1]
PHY-specific tables linked 12.A.
from Table 16.

Range of Input Conditions within which the Peripheral Operates Correctly

Minimum duration of 00 after

Bus Reset before the rising
Per_tResetRecovery 70 — — µs edge of the first DP clock cycle
in a Cold Start sequence.
See Requirement 8.B.

Minimum duration of DP=LC:1

at a Peripheral input when
detecting the Phy Number in a
Per_tClock1 4 — — µs Cold Start sequence.
See Requirements 8.C and
8.D.

Minimum duration of DP=LC:0

at a Peripheral input when
Per_tClock0 4 — — µs detecting the Phy Number in a
Cold Start sequence.
See Requirement 8.C.

Minimum input setup time of

DN=PhyNum[bit n] before a
Per_tSetup 1 — — µs
falling edge clock input on DP.
See Requirement 8.C.

Minimum input hold time of

DN=PhyNum[bit n] after a
Per_tHold 1 — — µs
falling edge clock input on DP.
See Requirement 8.C.

2285 Note:
1. All Audio-mode PHYs have a PHY-specific required maximum for Per_tPhyStart, some also have
a required or recommended minimum.
2. The cycle-based and time-based timing parameters are alternatives, depending on the method
that the Peripheral uses to control duration of its LC_Request output pulse.

Copyright © 2019–2024 MIPI Alliance, Inc. 119

2286 5. {6105} After any Cold Reset (see Section 5.2.1 Requirement 1), a Peripheral shall start in Link
2287 State: Cold_Standby with its Link Control PHY Rx activated and wait for Cold Start signaling
2288 according to Requirement 8.
2289 Note: see also Peripheral Cold Boot Request in Permission 3.
2290 6. {6106} Independently of the Link State or whether any Audio-mode PHY is active, a Peripheral
2291 shall continuously monitor the DP and DN signals for the Bus Reset sequence described in
2292 Requirement 7 using the Link Control signaling levels described in Section 6.
2293 7. {6107} A Peripheral shall detect Bus_Reset when it sees the following sequence of inputs:
2294 A. DP=LC:0 and DN=LC:0 for a time of ≥ Per_tReset00, followed by:
2295 B. DP=LC:1 and DN=LC:0 for a time of Per_tReset10.
2296 Note: The Min and Max values of Per_tReset00 in Table 14 constrain the Peripheral-specific
2297 duration that must be exceeded for that Peripheral to consider the 00 condition to be a valid
2298 Reset00 in Step 7A. The Manager will always park the bus at 00 for longer than
2299 Per_tReset00_Max, possibly very much longer.
2300 8. {6108} A Peripheral shall detect Cold Start (see waveform in informative Figure 42) when it sees
2301 the following sequence of inputs:
2302 A. A Bus_Reset according to Requirement 7, followed by:
2303 B. DP=LC:0 and DN=LC:0 for a time of Per_tResetRecovery, followed by:
2304 C. 4 clock cycles on DP for times of Per_tClock1 and Per_tClock0, during which the Peripheral
2305 captures data values from DN provided that they have times of at least Per_tSetup before, and
2306 Per_tHold after, the DP falling edge:
2307 i. PhyNum[3] on DP falling edge #1, followed by:
2308 ii. PhyNum[2] on DP falling edge #2, followed by:
2309 iii. PhyNum[1] on DP falling edge #3, followed by:
2310 iv. PhyNum[0] on DP falling edge #4, followed by:
2311 D. DP=LC:1 for a time of Per_tClock1, followed by:
2312 E. A falling edge on DP.
2313 9. {} When a Peripheral detects a Cold Start sequence according to Requirement 8, but does not
2314 implement the Audio-mode Phy number that was identified by PhyNum in Requirement 8.C then
2315 it shall remain in Link State: Cold_Standby.

120 Copyright © 2019–2024 MIPI Alliance, Inc.

2316 10. {} When a Peripheral detects a Cold Start sequence according to Requirement 8, and does
2317 implement the Audio-mode Phy number that was identified by PhyNum in Requirement 8.C then,
2318 after the Phy activation edge described in Requirement 8.E, it shall:
2319 A. Wait for a time of Per_tPhyStart (see PHY-specific required and recommended limits linked
2320 from Table 16), and then
2321 B. Start receiving signals using the Audio-mode PHY (selected according to Table 15), and then
2322 C. Enter Link State: Syncing.
2323 Table 15 Audio-mode PHYs in Peripheral
PHY PHY
Section Containing PHY-Specific Rules:
Number Short Name
Peripheral remains in Cold_Standby (see Requirement 9).
0 Reserved Note: this PhyNum might be used in a future version of this Spec
for a 1-pin SE PHY with clock recovery similar to the DLV PHY.
1 FBCSE FBCSE PHY behavior is specified in Section 11.
2 FBCSE FBCSE PHY behavior is specified in Section 11.
3 DLV DLV PHY behavior is specified in Section 12.2.
4 – 15 Reserved Peripheral remains in Cold_Standby (see Requirement 9).

2324 11. {xx00} A Peripheral that is in Link State: Sleeping shall detect Warm Start (see waveform in
2325 informative Figure 43) when it sees the following sequence of inputs:
2326 A. DP=LC:1 and DN=LC:0 for a time of Per_tWarmStart, followed by
2327 B. A falling edge on DP.
2328 12. {} When a Peripheral detects a Warm Start sequence according to Requirement 11 then, after the
2329 Phy activation edge described in Requirement 11.B, it shall:
2330 A. Wait for a time of Per_tPhyStart (see PHY-specific required and recommended limits linked
2331 from Table 16), and then
2332 B. Start receiving signals using the Audio-mode PHY that was in use prior to entering Link
2333 State: Sleeping, and then:
2334 C. Enter Link State: Syncing.

Copyright © 2019–2024 MIPI Alliance, Inc. 121

2335 13. {} When a Peripheral is in Link State: Syncing, it shall change to Link State: Attached when both:
2336 A. It satisfies the Phy-specific requirement(s) for becoming attached identified in Table 16, and
2337 B. The Command Transport Protocol decoder decodes a Get_Status Phase that:
2338 i. Selects this Peripheral (see Section 8.2.1 Requirement 4), and
2339 ii. Contains a Ping Command, and
2340 iii. Has zero Transport Errors (Either 8b10b errors or failure of the Manager CRC, see
2341 Section 7.2.2 or Section 8.2 ###XREF to sub-section).
2342 (See also Permission 6.) ###TODO: migrate this PERM to PHY-specific section

2343 Table 16 Phy-Specific Rules for Audio-mode PHYs in Peripheral

Limits on Becoming
PHY Becoming
PHY Per_tPhyStart Detached due to PHY_Inactivity
Short Attached
Number (Requirement PHY_BadRowLock (Requirement 20)
Name (Requirement 13A)
10.A & 12.A) (Requirement 14C)
0 Reserved — — — —
1 FBCSE Section 11.2.1 Section 11.2.1 Section 11.2.1
Requirement 1. — [1]
2 FBCSE Requirement 4. Requirement 2
Section 12.2.1 Section 12.2.1 Section 12.2.1 Section 12.2.1
3 DLV
Requirement 1. Requirement 4. Requirement 2. Requirement 3.
4 – 15 Reserved — — — —
2344 Note:
1. When using PHY1/PHY2, there is no PHY-specific condition that causes a Peripheral to lose row
lock (“fall off the bus”), i.e., change from Attached to Syncing.

2345 14. {} When the Peripheral is in Link State: Attached, it shall change to Link State: Syncing when
2346 any of the following occur:
2347 A. It commits a PM_Action of Force_Resync (see Requirement 17.B.ii), or
2348 B. It commits a PM_Action of Test_###TODO-name (see Requirement 17.B.ii), or
2349 C. It satisfies the PHY-specific requirement(s) for becoming detached due to the
2350 PHY_BadRowLock condition identified in Table 16, or
2351 D. It detects a Bad_Command_Confidence condition, i.e., the Command Transport Protocol
2352 decoder has seen 8192 Rows without encountering a valid and error-free Phase Header in
2353 which this Device was selected.
2354 Note: “error-free” means no Transport Errors in the Control Data Stream, see Section 7.2.2;
2355 “valid” means meeting the Command Transport Protocol rules in Section 8.2.1.
2356 Note: the state change from Attached to Syncing causes a Warm Reset (see Table 8).
2357 (See also Permission ###XREF).
2358 15. {} When a Peripheral enters Link State: Attached, it shall treat the Phase described in
2359 Requirement 13.B as the first Phase interpreted according to the rules in Requirement 16.
2360 Note: So if there is any interrupt condition for which both IntStatus=1 and the corresponding
2361 IntEnable=1, then the Peripheral Ping Response to this first Command will indicate an Alert
2362 condition.
2363 16. {} While the Peripheral is in Link State: Attached it shall interpret the Control Data Stream,
2364 Command Transport Protocol, and Commands according to the rules in Sections 7.2, 8.2, and 9.2.

122 Copyright © 2019–2024 MIPI Alliance, Inc.

2365 17. {} When a Peripheral in Link State: Attached commits the current value of PM_Action, it shall do
2366 both of A and B:
2367 A. Perform the usual Commit behavior of copying *_NEXT Registers in the selected Commit
2368 Groups to the corresponding *_CURR Registers as specified in Section 9.2.7
2369 Requirement XREF, and then:
2370 B. Perform the actions listed in Table 17 for the current value of PM_Action, which are zero or
2371 more of the following actions, in this order:
2372 i. Perform a Warm Reset (see Table 8), and then:
2373 ii. Change to a new Link State, and then:
2374 iii. Change the value of PM_Action.
2375 Table 17 Effect of Explicitly Commiting a Peripheral Management Action (PM_Action)
PM_Action Warm New Peripheral Link Effect on Value
Numeric Reset? State of PM_Action
Name 17.B.ii 17.B.iii
Value 17.B.i
Ready_for_Cold_Standby
(and then later:
0xC Enter_Cold_Standby YES Unchanged [1]
Cold_Standby, see
Requirement 20.E.i)
Ready_for_Sleeping
(and then later:
0x8 Enter_Sleeping YES Unchanged [1]
Sleeping, see
Requirement 20.E.i)
Test_Detach [3]
[###TODO-Author: Reset to 0x0
0x3 check that we say YES Syncing (Stay_Attached)
[2]
that this does set
BLOCKED]
Force_Resync
[###TODO-Author: Reset to 0x0
0x2 check that we say YES Syncing (Stay_Attached)
[2]
that this does NOT
set Blocked]
Unchanged at
Attached 0x0
0x0 Stay_Attached No
(unchanged) (Stay_Attached)
[2]

Enter_Dormant Reset to 0x0

0x4 (if supported by YES Dormant (Stay_Attached)
Peripheral) [4] [2]

1. The value of PM_Action is unchanged because the requested action will not be completed until
the Peripheral reacts to subsequent PHY_Inactivity according to Requirement 20.E.iii.
2. The value of PM_Action is reset to 0x0 (Stay_Attached) because the requested action is
complete.
3. PM_ACTION value 3 (Test_Detach is optional to implement, see ###XREF).
4. This PM_Action value is conditional to support. If the Peripheral does not implement the optional
Dormant state then the corresponding value cannot exist in the PM_Action field (see
Requirement 18 and also Section 5.2.3 Recommendation 1).

Copyright © 2019–2024 MIPI Alliance, Inc. 123

2376 18. {} If the Manager attempts to write a value of Enter_Dormant into the PM_Action field of a
2377 Peripheral that does not support Link State Dormant then the Peripheral shall set the value of
2378 PM_Action to Stay_Attached (0x0, see Table 17).
2379 Note: There is a general rule that the Peripheral chooses a substitute value when the Manager
2380 attempts to write an unsupported value, but this rule makes it clear exactly which substitue value is
2381 used in this case.
2382 19. {} When a Peripheral moves to Link State: Syncing as described in Requirement 10.C (Cold
2383 Start) or Requirement 12.C (Warm Start), it shall not start checking for the PHY_Inactivity
2384 condition described in the PHY-specific rule indicated in Table 16 until either:
2385 A. It has remained in Link State: Syncing for a time of Per_tPhy_Inactivity_Holdoff, or
2386 B. It has moved to Link State: Attached as described in Requirement 13.
2387 Note: This requirement applies only when first entering Link State: Syncing after a Cold Start or
2388 Warm Start, not after having previously been Attached.
2389 20. {} When a Peripheral in one of Link States: Syncing (see Requirement 19), Attached,
2390 Ready_for_Sleeping, Ready_for_Cold_Standby, or Dormant detects the PHY_Inactivity
2391 condition described in the PHY-specific rule indicated in Table 16, it shall do all of the following
2392 in this order:
2393 A. If the Peripheral is currently in Link State: Attached then
2394 i. Perform a Warm Reset (see Table 8), and then:
2395 B. Deactivate the Audio-mode PHY, and then:
2396 C. Activate the Link Control PHY, and then:
2397 D. Wait for the bus to be parked at Link Control Idle (DP=LC:0, DN=LC:0), and then:
2398 E. Perform the actions listed in Table 18 for the current value of PM_Action, which are 2 or 3 of
2399 the following actions, in this order:
2400 i. Change to a new Link State, and then:
2401 ii. Perform a Cold Reset (see Table 8), and then:
2402 iii. Change the value of PM_Action to be 0x0 (Stay_Attached).
2403 Note: Step 20.A performs the Warm Reset ONLY if the Peripheral was Attached when the
2404 (unexpected) PHY_Inactivity occurred. This is because the Peripheral will ALREADY have
2405 performed a Warm Reset when it reached any of the other Active states in this list.

2406 Table 18 Effect of Implicitly Commiting a Peripheral Management Action (PM_Action)

PM_Action New Peripheral Link Cold Reset? Effect on Value
Numeric State of PM_Action
Name (REQ 20.E.i) (REQ 20.E.iii)
Value (REQ 20.E.ii)
Reset to 0x0 [1]
0xC Enter_Cold_Standby Cold_Standby YES
(Stay_Attached)
0x8 Enter_Sleeping
0x2 Force_Resync Reset to 0x0
Sleeping No
0x0 Stay_Attached (Stay_Attached)
0x4 Enter_Dormant [2]
1. When PM_Action is Enter_Cold_Standby, the Cold Reset in Requirement 20.E.ii will reset the
PM_Action to Stay_Attached without needing Requirement 20.E.iii.
2. See Requirement 18.

2407 21. {} When a Peripheral is in Link State: Dormant and decodes a valid ExitDormant Command (see
2408 Section 9.2.6) it shall change to Link State: Syncing.
2409 (Note: see also Permission 7.)

124 Copyright © 2019–2024 MIPI Alliance, Inc.

2410 22. {} When a Peripheral is in Link State: Dormant it shall:

2411 A. Not capture any Payload data from the Audio-mode PHY Rx.
2412 B. Not drive any Payload data or Control Data Stream values onto the bus with its Audio-mode
2413 PHY Tx.
2414 23. {} When a Peripheral is in Link States: Ready_for_Cold_Standby or Ready_for_Sleeping it
2415 shall:
2416 A. Not capture any Payload data from the Audio-mode PHY Rx.
2417 B. Not drive any Payload data or Control Data Stream values onto the bus with its Audio-mode
2418 PHY Tx.
2419 C. Not interpret the Control Data Stream, Command Transport Protocol, and Commands.
2420 (Note: see also Permission 1.)
2421 24. {} When a Peripheral generates an LC_Request (see Permissions 2 and 3, and waveform in
2422 informative Figure 44) using cycle-based pulse duration, it shall perform the following sequence
2423 of actions:
2424 A. Observe that the Bus Idle condition (DP=LC:0 and DN=LC:0) is present for a time of at least
2425 Per_tLC_ReqArmingDelay, and then:
2426 B. Possibly ignore a change in the value of DP for a period of at most
2427 Per_tLC_ReqDisarm_Cycle-based, and then
2428 C. Drive DP=LC:1 for a time of Per_tLC_ReqOut_Cycle-based.
2429 Note: Requirements 24 and 25 are alternatives, depending on the method that the Peripheral
2430 uses to control duration of its LC_Request output pulse.
2431 25. {} When a Peripheral generates an LC_Request (see Permissions 2 and 3, and waveform in
2432 informative Figure 44) using time-based pulse duration, it shall perform the following sequence of
2433 actions:
2434 A. Observe that the Bus Idle condition (DP=LC:0 and DN=LC:0) is present for a time of at least
2435 Per_tLC_ReqArmingDelay, and then:
2436 B. Possibly ignore a change in the value of DP for a period of at most
2437 Per_tLC_ReqDisarm_Time-based, and then
2438 C. Drive DP=LC:1 for a time of Per_tLC_ReqOut_Time-based.

Copyright © 2019–2024 MIPI Alliance, Inc. 125

2439 Permissions
2440 1. {} When a Peripheral is in one of Link States: Cold_Standby, Sleeping,
2441 Ready_for_Cold_Standby, Ready_for_Sleeping, or Dormant, it may remove power from parts
2442 of the Device provided that it retains the minimum functionality and state described in Table 19.
2443 Table 19 Power Saving in Peripheral Link States
Mandatory
State Name Minimum Functionality and Retained State
/ Optional?
Power off — —
Cold_Standby [1] Mandatory Detect Bus Reset (Requirement 6).
Detect Bus Reset (Requirement 6).
Detect Warm Start (Requirement 11).
Sleeping Mandatory
Retain SWI3S Register State.
Retain other state as defined in the device datasheet.
Detect Bus Reset (Requirement 6).
Ready_for_Cold_Standby [1] Mandatory
Detect PHY Inactivity (Requirement 20).
Detect Bus Reset (Requirement 6).
Detect PHY Inactivity (Requirement 20).
Ready_for_Sleeping Mandatory
Retain SWI3S Register State.
Retain other state as defined in the device datasheet.
Detect Bus Reset (Requirement 6).
Detect PHY Inactivity (Requirement 20).
Dormant Optional Detect ExitDormant Command (Requirement 21).
Retain SWI3S Register State.
Retain other state as defined in the device datasheet.
All Link Control and Command functionality and device
Syncing Mandatory
state.
All Link Control and Command functionality and device
Attached Mandatory
state.
2444 Note:
1. When a Peripheral that has removed power from registers in Link State: Cold_Standby or
Ready_for_Cold_Standby receives a Cold Start sequence (see Requirement 8) it will restore
power to registers before applying the Cold Reset caused by the Bus Reset (see Table 8).

2445 2. {} When a Peripheral is in Link State: Sleeping and the WakeReqEnable register field has the
2446 value 1, it may generate an LC_Request (see Requirement 24 or 25).
2447 Note: an LC_Request from Link State: Sleeping is sometimes described as a “WakeUp Request”.
2448 3. {} When a Peripheral is in Link State: Cold_Standby and is confident that there is no signaling on
2449 the bus associated with any of the Audio-mode PHYs implemented in that Peripheral, it may
2450 generate an LC_Request (see Requirement 24 or 25).
2451 Note: an LC_Request from state: Cold_Standby is sometimes described as a “Cold Boot Request”.
2452 4. {} When a Peripheral has generated a WakeUp Request according to Permission 2, but has
2453 remained in Link State: Sleeping without the Audio-mode PHY being reactivated, it may repeat
2454 the WakeUp Request for the same or different internal conditions a reasonable number of times.
2455 (See also: Recommendation 1.)

126 Copyright © 2019–2024 MIPI Alliance, Inc.

2456 5. {} When a Peripheral has generated a Cold Boot Request according to Permission 3, but has
2457 remained in Link State: Cold_Standby without an Audio-mode PHY being activated, it may
2458 repeat the Cold Boot Request for the same or different internal conditions a reasonable number of
2459 times. (See also: Recommendation 2.)
2460 6. {} When a Peripheral is in Link State: Syncing, and the Link traffic includes Payload Data in
2461 addition to the Control Data Stream, the Peripheral may do any of:
2462 A. Change to Link State: Attached as specified in Requirement 13, or
2463 B. Change to Link State: Attached after a longer time than the PHY-Specific requirement
2464 referenced by Requirement 13.A, or
2465 C. Fail to change to Attached.
2466 Note: i.e., some Peripherals will attach to the bus only when the traffic is Command-Only.
2467 7. {} When a Peripheral is in Link State: Dormant and the WakeReqEnable register field has the
2468 value 1, the Peripheral may change to Link State: Syncing as a result of an
2469 implementation-defined trigger condition.
2470 8. {} When a Peripheral is in Link State: Dormant it may deactivate some or all Error Counters (see
2471 Section 15.2.1 Permission ###XREF).
2472 Note: i.e., counting errors and setting the corresponding interrupt conditions is optional while in
2473 Link State: Dormant.
2474 9. {} When a Peripheral is in Link State: Ready_for_Sleeping and the WakeReqEnable register field
2475 has the value 1, the Peripheral may change to Link State: Syncing as a result of an
2476 implementation-defined trigger condition.
2477 10. {} When a Peripheral activates an Audio-mode PHY according to Requirement 10.B or 12.B, it
2478 may prevent its PLL/DLL clock recovery circuit reacting to the input until a time of
2479 Per_tPhy_Inactivity_HoldOff after the Phy activation edge described in Requirement 8.E or
2480 Requirement 11.B.
2481 11. {} When a Peripheral is in Link State: Attached it may change to Link State: Syncing for any
2482 Implementation-defined reason (e.g., a higher layer function in the Device has requested this).
2483
2484 ###TODO-Author: insert 4 new Permissions per Niel’s email to Audio-WG on 4 June 2024. (behavior
2485 relating to Dormant)
2486 Figure 60:
2487 RECO: After committing EnterDormant, the Host should NOT send any Commands to that Peripheral
2488 except Ping or ExitDormant until the Peripheral replies to a Ping.
2489
2490 Peripheral Behavior:
2491 While waiting in Dormant, what to do if:
2492 (A) the Peripheral loses CommandSync?
2493 (B) the Peripheral loses Row Sync?
2494 PROPOSAL: there are 4 permissions (with separate DRUIds and 4 boolean DisCo properties):
2495 (1) The Peripheral MAY reacquire Row/CommandSync (and increment the error counter) and remain in
2496 Dormant.
2497 (2) The Peripheral MAY reacquire Row/CommandSync (and increment the error counter) and treat this as
2498 an internal trigger for ExitDormant (subject to an the enable in the Register).
2499 (3) The Peripheral MAY reacquire Row/CommandSync (and increment the error counter) and treat this as
2500 an internal trigger for ExitDormant (NOT subject to the enable in the Register).

Copyright © 2019–2024 MIPI Alliance, Inc. 127

2501 (4) The Peripheral MAY remain in Dormant until it sees PHY_Inactivity (and hence changes to Sleeping).
2502 [this is essentially migrating to Ready_for_Sleeping]
2503

2504 Recommendations
2505 1. {} When a Peripheral has generated an LC_Request according to Permission 2, but has remained
2506 in Link State: Sleeping without the most recently used Audio-mode PHY being reactivated, the
2507 Peripheral should wait for a time of Per_tLC_ReqRepeat before repeating the LC_Request.
2508 2. {} When a Peripheral has generated an LC_Request according to Permission 3, but has remained
2509 in Link State: Cold_Standby without one of the Audio-mode PHYs being activated, the
2510 Peripheral should wait for a time of Per_tLC_ReqRepeat before repeating the LC_Request.
2511 3. {} When a Peripheral activates an Audio-mode PHY according to Requirement 10.B or 12.B, it
2512 should initialize any hysteresis-related state in the PHY such that any remaining period of
2513 receiving DP=LC:0 and DN=LC:0 is treated as an input of 0 using the selected Audio-mode PHY.

128 Copyright © 2019–2024 MIPI Alliance, Inc.

2519 3. {} The Manager shall use values for the timing parameters named in this Section (5.2.3) that are
2520 between the lower and upper bounds in Table 21.
2521 Note: i.e., the Min and Max values in the table are the lower and upper bounds for the values in a
2522 Manager datasheet.

2523 Table 21 Timing Parameters for Manager Link Control Sequences

Parameter Min Typ Max Units Description

Limits on Manager Behavior

Duration of Manager driving 00 in part 1 of a

Man_tReset00 212 — 236 µs Bus Reset sequence.
See Requirement 9.A.

Duration of Manager driving 10 in a Bus Reset

sequence.
Man_tReset10 1569 — — µs See Requirement 9.B.
Note: there is no mandatory upper time
limit, but see also Man_tReset10Limit.

Duration of Manager driving 00 after Bus

Reset (before the next part of Cold Start
Man_tResetRecovery 72.5 — 80 µs sequence).
See Requirement 9.C.

Duration of DP=LC:1 when generating the Phy

Man_tClock1 5 — 32 µs Number in a Cold Start sequence.
See Requirements 9.D and 9.E.

Duration of DP=LC:0 when generating the Phy

Man_tClock0 5 — 32 µs Number in a Cold Start sequence.
See Requirement 9.D.

Minimum output setup time of

DN=PhyNum[bit n] before output of DP falling
edge.
Man_tSetup 5 — — µs
See Requirement 9.D.
Note: The data value on DN is typically
generated with the DP rising edge.

Minimum output hold time of

DN=PhyNum[bit n] after output of DP falling
edge.
Man_tHold 5 — — µs See Requirement 9.D.
Note: The next data value on DN is
typically generated with the DP rising
edge.

Copyright © 2019–2024 MIPI Alliance, Inc. 129

Parameter Min Typ Max Units Description

Delay between generating falling edge (LC:0)

on DP (at the end of Cold Start or Warm Start)
Man_tPhyStart 64 — 96 µs
and changing to Audio-mode PHY signaling.
See Requirements 9.F and 10.B.

###DRAFT:
72.5 — 80 µs
Man_tWarmStart00

###DRAFT add “00”

Duration of driving DP=LC:1 to indicate Warm
to this parameter
436 — 482 µs Start.
name
See Requirement 10.A.
Man_tWarmStart10

Duration of Manager driving DP=LC:1 to

extend a Peripheral LC_Request into an
Man_tLC_AckOut 100.5 — 111.5 µs LC_Acknowledge.
See Requirement 11.A.

Duration of driving DP=LC:0, before changing

Man_tParkBus_LC00 5 — 32 µs to idle (DP=LC:weak0).
See Requirements 11.B and 6.A.

Recommended Manager Behavior

Minimum duration for which the Manager

generates Rows before deactivating the
Man_tActiveLinkMin 300 — — µs Audio-mode PHY (unless all expected
Peripherals have responded to a Ping).
See Recommendation 6.

Recommend upper limit on duration of

Man_tReset10Limit — — 2000 µs Manager driving 10 in a Bus Reset sequence.
See Recommendation 4.

Range of Input Conditions within which the Manager Operates Correctly

Reaction time of Manager after a Peripheral

generates an LC_Request.
See Requirement 8.
Note:
Man_tLC_ReqIn 0 — 32 µs An LC_Request input is asynchronous to
the Manager, so the time between the DP
input changing to LC:1 and the Manager
actually reacting to that change might vary
between these Min and Max limits, e.g.,
due to timing of internal sampling events.

130 Copyright © 2019–2024 MIPI Alliance, Inc.

2524 4. {} After a Manager Reset (see Section 5.2.1 Requirement 4), a Manager shall do either:
2525 A. Start in Link State: Parking_Bus_PHYn with the previous Audio-mode PHY still active (see
2526 Requirement 5), or:
2527 B. Start in Link State: Parking_Bus_LC with its Link Control PHY activated (see
2528 Requirement 6).
2529 5. {} When the Manager is in Link State: Parking_Bus_PHYn, it shall do all of:
2530 A. Park the bus using the PHY-specific rule shown in Table 23, and then:
2531 B. Deactivate the Audio-mode PHY, and then:
2532 C. Activate the Link Control PHY, and then:
2533 D. Enter Link State: Parking_Bus_LC, and then:
2534 E. Follow Requirement 6.
2535 6. {} When the Manager is in Link State: Parking_Bus_LC, it shall do all of:
2536 A. Drive DP=LC:0 and DN=LC:0 for a time of Man_tParkBus_LC00, and then:
2537 B. Enter Link State: Standby_Bus_Idle, and then:
2538 C. Follow Requirement 7.
2539 7. {} While the Manager is in Link State: Standby_Bus_Idle, it shall do both:
2540 A. Drive a bus idle condition (DP=LC:weak0 and DN=LC:0) for any time duration, and then:
2541 B. Do one of:
2542 i. Generate a Cold Start sequence according to Requirement 9, or:
2543 ii. Generate a Warm Start sequence according to Requirement 10, or:
2544 iii. React to a Peripheral LC_Request according to Requirement 8.B.
2545 8. {} When the Manager is in Link State: Standby_Bus_Idle and the DP input changes to LC:1, the
2546 Manager shall do both:
2547 A. Detect the change on DP within a time of Man_tLC_ReqIn, and then:
2548 B. Immediately do one of:
2549 i. Generate a Cold Start sequence according to Requirement 9, or:
2550 ii. Generate a Warm Start sequence according to Requirement 10, or:
2551 iii. Generate an LC_Acknowledge sequence according to Requirement 11.

Copyright © 2019–2024 MIPI Alliance, Inc. 131

2552 9. {} When a Manager generates a Cold Start sequence (see waveform in informative Figure 42) it
2553 shall perform the following sequence of actions:
2554 A. Drive DP=LC:0 and DN=LC:0 for a time of Man_tReset00, and then:
2555 B. Drive DP=LC:1 and DN=LC:0 for a time of Man_tReset10, and then:
2556 Note: see also Recommendation 4.
2557 C. Drive DP=LC:0 and DN=LC:0 for a time of Man_tResetRecovery, and then:
2558 D. Drive 4 clock cycles on DP for times of Man_tClock1 and Man_tClock0, during which the
2559 Manager drives the following data values on DN with times of at least Man_tSetup before,
2560 and Man_tHold after, the DP falling edge:
2561 i. PhyNum[3] on DN during cycle #1, and then
2562 ii. PhyNum[2] on DN during cycle #2, and then
2563 iii. PhyNum[1] on DN during cycle #3, and then
2564 iv. PhyNum[0] on DN during cycle #4, and then
2565 E. Drive DP=LC:1 and DN=LC:0 for a time of Man_tClock1, and then:
2566 F. Drive DP=LC:0 and DN=LC:0 for a time of Man_tPhyStart, and then:
2567 G. Start generating signals using:
2568 i. The Audio-mode PHY that was identified by PhyNum in Step D, selected according to
2569 Table 22, and
2570 ii. The Clock Config and CDS transport parameters identified as the Safe-Lock Config by the
2571 PHY-specific rule in Table 23, and then:
2572 H. Enter Link State: Command_Only.
2573 Table 22 Selecting Audio-mode PHYs in Manager
PHY
PHY Section Containing
Short Notes
Number PHY-Specific Rules:
Name
0 Reserved The Manager never generates this PHY Number. —
1 FBCSE FBCSE PHY behavior is specified in Section 11.2. PHY1 and PHY2 use the
same electrical transceiver
2 FBCSE FBCSE PHY behavior is specified in Section 11.2. but with different timing rules.
3 DLV DLV PHY behavior is specified in Section 12.2. —
4 – 15 Reserved The Manager never generates this PHY Number. —

2574 Table 23 Phy-Specific Rules for Audio-mode PHYs in Manager

Parking the Bus
Initial Safe-Lock Generating Pre-conditions for using
PHY
PHY Config Rows Changing Clock Audio-mode PHY
Short
Number Config
Name
(Requirement 9.G.ii) (Requirement 12) (Requirement 13)
(Requirement 5.A)
0 Reserved — — — —
1 FBCSE Section 11.2.1 Section 11.2.1 Section 11.2.1
—
2 FBCSE Requirement 11 Requirement 12 Requirement 10
Section 12.2.1 Section 12.2.1 Section 12.2.1 Section 12.2.1
3 DLV
Requirement 7 Requirement 8 Recommendation 2 Requirement 6
4 – 15 Reserved — — — —

132 Copyright © 2019–2024 MIPI Alliance, Inc.

2575 10. {} When the Manager generates a Warm Start sequence (see waveform in informative Figure 43)
2576 it shall perform the following sequence of actions:
2577 A. Drive DP=LC:1 and DN=LC:0 for a time of Man_tWarmStart, and then:
2578 B. Drive DP=LC:0 and DN=LC:0 for a time of Man_tPhyStart, and then:
2579 C. Start generating signals using:
2580 i. The same Audio-mode PHY and Clock Config as before the Manager entered Link State:
2581 Standby_Bus_Idle, and
2582 ii. The Transport parameters for the Control Data Stream that were commited in Peripherals
2583 when the Manager entered Link State: Standby_Bus_Idle, and then:
2584 D. Enter Link State: Command_Only.
2585 11. {} When the Manager generates an LC_Acknowledge sequence (see waveform in informative
2586 Figure 44), it shall perform the following sequence of actions:
2587 A. Drive DP=LC:1 and DN=LC:0 for a time of Man_tLC_AckOut, and then:
2588 B. Drive DP=LC:0 and DN=LC:0, for a time of Man_tParkBus_LC00, and then:
2589 C. Remain in Link State: Standby_Bus_Idle (so return to generating a bus idle condition
2590 according to Requirement 7.A).
2591 12. {} When the Manager is in either of Link States: Command_Only or Payload, it shall generate
2592 Rows according to the Phy-specific rule(s) in Table 23.
2593 13. {} Before the Manager changes the Clock Config according to Requirement 14, it shall perform
2594 any pre-condition actions described by the Phy-specific rule(s) in Table 23.
2595 14. {} When the Manager is generating Rows according to Requirement 12, it shall only change the
2596 Clock Config (i.e., the generated Row Rate and Column Count) when this change is synchronous
2597 with the Commit Point of an SSCR Command addressed to all currently attached Peripherals that
2598 commits the changed values in all of:
2599 A. NumColumns (see ###XREF), and
2600 B. The RowRateRange field (see ###XREF), and
2601 C. The UnitIntervalRange field (see ###XREF), and
2602 15. {} When the Manager is in either of Link States: Command_Only or Payload, it shall generate a
2603 Control Data Stream, containing valid Command Transport Protocol and Commands according to
2604 the rules in Sections 7.2, 8.2, and 9.2.
2605 16. {} When the Manager is in Link State: Command_Only, it shall:
2606 A. Not generate any payload data, and
2607 B. Not send Commands to any Peripheral that causes that Peripheral to generate payload data.
2608 (See also Permission 1.)

2609 Permissions
2610 1. {} When the Manager is in Link State: Payload, it may:
2611 A. Generate payload data, and:
2612 B. Send Commands to any Peripheral that cause that Peripheral to generate payload data.
2613 2. {} When the Manager is in Link State: Command_Only, it may change to the Link State:
2614 Payload at any time (but see also Recommendation 2).
2615 3. {} When the Manager is in Link State: Payload it may change to the Link State: Command_Only
2616 at any time.
2617 4. {} When the Manager is in Link States: Command_Only or Payload it may change to the Link
2618 State: Parking_Bus_PHYn at any time (but see also Recommendation 3)

Copyright © 2019–2024 MIPI Alliance, Inc. 133

2619 5. {} When the Manager issues an SSCR Command to change the Clock Config according to
2620 Requirement 14, then it may commit a PM_Action of Stay_Attached for any Peripheral.
2621 (See also Recommendation 5.).
2622 Note: Some Peripherals will detach from the bus in response to some changes in Clock Config.

2623 Recommendations
2624 1. {} The Manager should not program a PM_Action of Enter_Dormant into a Peripheral that does
2625 not support Dormant behavior.
2626 Note: see Peripheral behavior in Table 17.
2627 2. {} When the Manager is in Link State: Command_Only it should change to Link State: Payload
2628 only after a Ping Command (see Section 9.2.8) has indicated that all expected Peripherals are
2629 attached.
2630 3. {} When the Manager is in Link States: Command_Only or Payload, it should change to Link
2631 State: Parking_Bus_PHYn only when this change is synchronous with a Commit Command
2632 addressed to all currently attached Peripherals that commits a PM_Action of either:
2633 A. Enter_Sleeping, or
2634 B. Enter_Cold_Standby.
2635 Note: The Manager might already have caused some Peripherals to become detached by earlier
2636 commiting a PM_Action of Enter_Sleeping or Enter_Cold_Standby.
2637 4. {} When the Manager generates a Cold Start sequence (see Requirement 9), it should drive the
2638 Reset10 condition in Step 9.B for a time of not longer than Man_tReset10Limit.
2639 Note: If the Manager were to drive the Reset10 condition for an extended period then this would
2640 prevent Peripherals from signaling an LC_Request to the Manager (see Section 5.2.2
2641 Permission 3).
2642 5. {} When the Manager issues an SSCR Command to change the Clock Config according to
2643 Requirement 14 and a Peripheral is known not to be able to remain synchronized throughout that
2644 change of Clock Config then it should also program the PM_Action in that Peripheral so that the
2645 same SSCR also commits a PM_Action of one of (Force_Resync, Enter_Dormant,
2646 Enter_Sleeping, or Enter_Cold_Standby).
2647 (See also Permission 5.)
2648
2649 6. {} When the ###TODO-Author: … describe Man_tActiveLinkMin …
2650 TEMP Notes from the parameter definition: Man_tActiveLinkMin is the minimum duration for which
2651 the Manager generates Rows before deactivating the Audio mode PHY (unless all expected
2652 Peripherals have responded to a Ping).
2653

134 Copyright © 2019–2024 MIPI Alliance, Inc.

5.2.4 Device Properties

2654 ###Question for Reviewers: would it be better to add a new level-1 section between Section 4 and
2655 Section 5 to contain this 1 page of “structural” requirements?

2656 Requirements
2657 1. {} A SWI3S Device shall implement the Link Control PHY Behavior specified in Section 6.2.1.
2658 2. {} A SWI3S Device shall implement the Audio-mode PHY behavior described in 1 or more of the
2659 Audio-mode PHY Sections shown in Table 24 (see also Requirement 3).
2660 Table 24 Audio-mode PHYs
PHY PHY Section containing description Notes
Number Short Name and rules for the PHY
0 Reserved — —
1 FBCSE PHY1 and PHY2 share the same
Section 11 electrical transceiver, but have
2 FBCSE different timing parameters.
3 DLV Section 11.3 —
4–7 Reserved — —
8 ImpDef_A —
9 ImpDef_B Section ###XREF —
10 ImpDef_C —
11 – 15 Reserved — —

2661 3. {} If a SWI3S Device implements PHY1 then it shall also implement PHY2.
2662
2663
2664 ###TODO-Author: check for informative description of RowRateRange_CURR and
2665 UI_RateRange_CURR.
2666
2667
2668 4. {} A SWI3S Device shall interpret the value in the UI_RateRange_CURR Register field according
2669 to Table ###XREF.
2670

Copyright © 2019–2024 MIPI Alliance, Inc. 135

2671 5. {} A SWI3S Device shall interpret the value in the RowRateRange_CURR Register field
2672 according to Table 25. ###TODO-Author: colour the rows in this table. 8 colours.
2673 Table 25 Encoding of RowRateRange Field
Register Setting Row Rate (Rows/sec)
Register Value Octave Frequency
Min Max
(RowRateRange, Number Family [3] Nom
−15% +15%
see Table 153) Bits[6:3] Bits[2:0]
0x00 — — Not Known [1]
0x01 – 0x07 — — Reserved
0x08 1 0 31,340 [2] 32,768 37,638.2
0x09 1 1 37,500
0x0A 1 2 44,100
0x0B 1 3 46,875
0x0C 1 4 48,000
0x0D 1 5 50,000
0x0E 1 6 50,781.25
0x0F 1 7 60,000
0x10 2 0 65,536
0x11 2 1 75,000
0x12 2 2 88,200
0x13 2 3 93,750
0x14 2 4 96,000
0x15 2 5 100,000
0x16 2 6 101,562.5
0x17 2 7 120,000
0x18 3 0 131,072
0x19 3 1 150,000
0x1A 3 2 176,400
0x1B 3 3 187,500
0x1C 3 4 192,000
0x1D 3 5 200,000
0x1E 3 6 203,125
0x1F 3 7 240,000
0x20 4 0 262,144
0x21 4 1 300,000
0x22 4 2 352,800
0x23 4 3 375,000
0x24 4 4 384,000
0x25 4 5 400,000
0x26 4 6 406,250

136 Copyright © 2019–2024 MIPI Alliance, Inc.

Register Setting Row Rate (Rows/sec)

Register Value Octave Frequency
Min Max
(RowRateRange, Number Family [3] Nom
−15% +15%
see Table 153) Bits[6:3] Bits[2:0]
0x27 4 7 480,000
0x28 5 0 524,288
0x29 5 1 600,000
0x2A 5 2 705,600
0x2B 5 3 750,000
0x2C 5 4 768,000
0x2D 5 5 800,000
0x2E 5 6 812,500
0x2F 5 7 960,000
0x30 6 0 1,048,576
0x31 6 1 1,200,000
0x32 6 2 1,411,200
0x33 6 3 1,500,000
0x34 6 4 1,536,000
0x35 6 5 1,600,000
0x36 6 6 1,625,000
0x37 6 7 1,920,000
0x38 7 0 2,097,152
0x39 7 1 2,400,000
0x3A 7 2 2,822,400
0x3B 7 3 3,000,000
0x3C 7 4 3,072,000
0x3D 7 5 3,200,000
0x3E 7 6 3,250,000
0x3F 7 7 3,840,000
0x40 8 0 4,194,304
0x41 8 1 4,800,000
0x42 8 2 5,644,800
0x43 8 3 6,000,000
0x44 8 4 6,144,000
0x45 8 5 6,400,000
0x46 8 6 6,500,000
0x47 8 7 7,680,000
0x48 9 0 8,388,608
0x49 9 1 9,600,000
0x4A 9 2 11,289,600
0x4B 9 3 12,000,000

Copyright © 2019–2024 MIPI Alliance, Inc. 137

Register Setting Row Rate (Rows/sec)

Register Value Octave Frequency
Min Max
(RowRateRange, Number Family [3] Nom
−15% +15%
see Table 153) Bits[6:3] Bits[2:0]
0x4C 9 4 12,288,000
0x4D 9 5 12,800,000
0x4E 9 6 13,000,000
0x4F 9 7 15,360,000
0x50 10 0 16,777,216
0x51 10 1 19,200,000
0x52 10 2 22,579,200
0x53 10 3 24,000,000
0x54 10 4 24,576,000
0x55 10 5 25,600,000
0x56 10 6 26,000,000
0x57 10 7 30,720,000
0x58 11 0 33,554,432
0x59 11 1 38,400,000
0x5A 11 2 45,158,400
0x5B 11 3 48,000,000
0x5C 11 4 49,152,000
0x5D 11 5 51,200,000
0x5E 11 6 52,000,000
0x5F 11 7 61,440,000
0x60 12 0 67,108,864
0x61 12 1 76,800,000
0x62 12 2 90,316,800
0x63 12 3 96,000,000
0x64 12 4 98,304,000
0x65 – 0xFF — — Reserved
2674 Note:
1. “Not known” means that the Manager has not informed the Peripheral what Row Rate is being
used. For some PHYs (e.g., PHY1 & PHY2) this is the value after a Cold Reset.
2. The minimum value for RowRateRange is 31340 Rows/sec which is not as low as 15% below the
nominal value of 32768 Rows/sec. This is to ensure separation between Link Control signaling
and valid Audio-mode PHY traffic.
3. Frequency families 0–7 relate to commonly used frequencies in audio systems divided by 2n:
0: 32.768 kHz crystal × 2n.
1: 38.4 MHz crystal.
2: 44.1 kHz family.
3: 24 MHz crystal.
4: 24.576 MHz crystal.
5: 38.4 MHz crystal ÷ 3.
6: 13 MHz (Bluetooth).
7: 38.4 MHz crystal ÷ 5.

138 Copyright © 2019–2024 MIPI Alliance, Inc.

2675

2676 Permissions
2677 1. A SWI3S Peripheral may implement any set of 0 to 32 Data Ports.
2678 Note: i.e., they might not start at DP0 and might not have consecutive numbers.
2679
2680

Copyright © 2019–2024 MIPI Alliance, Inc. 139

6 Link Control PHY

2681 The Link Control PHY is used for the link control and reset signaling sequences described in Section 5.

6.1 Description (informative)

6.1.1 Overview
2682 Link Control (LC) signaling uses simple “CMOS” signaling, i.e., single-ended and full swing between the
2683 voltage supply rails. The two values that can be signaled are named LC:0 and LC:1. The Manager
2684 sometimes drives LC:0 with a weaker drive strength, named LC:weak0. The detailed electrical
2685 characteristics of LC inputs and outputs are specified in ###XREF-Table in normative Section ###XREF.
2686 To simplify the description, this Specification describes the Link Control signaling behavior as a separate
2687 PHY. However, Managers and Peripherals that include PHY1 and / or PHY2 (forwarded-bit-clock
2688 single-ended PHY, see Section 11) might share some I/O circuitry between that PHY and the Link Control
2689 PHY, e.g., using a subset of the transistors in a multi-finger FBCSE PHY transmitter to provide the LC_Tx
2690 behavior.
2691 The Link Control PHY comprises the Link Control transmitter (LC_Tx) and Link Control receiver
2692 (LC_Rx). The capabilities of the transmitters and receivers in each of Manager and Peripheral are different,
2693 as described in Section 6.1.2 and Section 6.1.3.

6.1.1.1 Output levels in LC PHY compared with PHY1/2 (FBCSE)

2694 The LC PHY nominally uses the same output (VOH & VOL) and input (VIH & VIL) levels as PHY1/2
2695 (FBCSE). However, there is much more settling time available, so the asymptotic rise towards the
2696 supply rails means that it will typically achieve a much better VOH & VOL. These actual output levels
2697 provide a larger margin over the specified VIH & VIL, which can allow for a larger ground offset
2698 between devices as might be seen in large systems using PHY3 (DLV).

6.1.2 Link Control PHY in the Manager

2699 Figure 66 is an example circuit diagram to illustrate the capabilities of the LC_PHY in the Manager. Real
2700 implementations might differ from this circuit.

Vdd_LC_Tx Vdd_LC_Tx

LC:1 LC:1

DP
input Manager Manager
DP pin DN pin
LC:0
LC:weak0
LC:strong0 LC:0

2701 Gnd Gnd

Figure 66 Link Control PHY in the Manager

140 Copyright © 2019–2024 MIPI Alliance, Inc.

2702 The LC_Tx in the Manager can drive each of the DP and DN signals either high (signal level LC:1) or low
2703 (LC:0). When the link is in the LC_Idle condition the DP signal is maintained by a weaker drive from the
2704 Manager (LC:weak0) because DP becomes a shared signal, which the Manager or any of the Peripherals
2705 can pull high to request that the Manager wakes up the link. The Manager has a strong driver for DP=LC:0
2706 to guarantee that it can force a Bus Reset condition even while a Peripheral tries to generate an
2707 LC_Request.
2708 The LC_Rx in the Manager monitors the DP signal to receive LC_Requests from Peripherals but ignores
2709 the DN signal.

6.1.3 Link Control PHY in the Peripheral

2710 Figure 67 is an example circuit diagram to illustrate the capabilities of the LC_PHY in the Peripheral. Real
2711 implementations might differ from this circuit.

Vdd_LC_Tx

(only needed if this Peripheral

LC:1
can generate WakeUp request)

DP Peripheral DN Peripheral
2712 input DP pin input DN pin
Figure 67 Link Control PHY in the Peripheral

2713 The LC_Tx in the Peripheral can drive only the DP signal, and only to a high level (LC:1) used for
2714 requesting that the Manager wakes the link from standby (see Section 5.1.7.4). The Peripheral output
2715 strength is constrained in order to guarantee that a Manager can overdrive it to force a Bus Reset condition
2716 if necessary. Peripherals that do not have LC_Request functionality do not have an LC_Tx.
2717 The LC_Rx in a Peripheral monitors both DP and DN. This receiver is always active, and its outputs are
2718 used by both the Peripheral Link State Machine (see Section 5.1.7) and the Peripheral Bus Reset State
2719 Machine (see Section 5.1.6).

6.1.4 Relative Drive Strengths of Manager and Peripheral LC_PHY

2720 The drive strengths of the LC_PHY in each of Manager and Peripheral are each specified within boundaries
2721 to ensure that both:
2722 • The Manager output of DP=LC:0 and DN=LC:0 can overcome the capacitance of the bus so that
2723 the Manager can park the bus in the LC_Idle condition within the specified time.
2724 • The Manager output of DP=LC:weak0 is strong enough to provide the leakage current of a fully
2725 populated bus so that the Manager can maintain the signal level indefinitely during standby.
2726 • The Peripheral output of DP=LC:Medium1 is strong enough to overcome the Manager output of
2727 LC:weak0 so that the Peripheral can request that the Manager wakes the bus.
2728 • The Manager output of DP==LC:strong0 is strong enough to overcome any Peripherals driving
2729 DP so that the Manager can forcibly reset the bus, independently of the current condition of any
2730 Peripherals.
2731 The ranges of values for these drive strengths are specified in [###XREF to normative Table].
2732 ###Question for PHY SubGroup: Need to specify limits on drive levels (either current or
2733 impedance).
2734 ###TODO-Author: when FBCSE specs have stabilised, ensure that there is EITHER a simplified version of
2735 tables here, OR, clear references to which parts of FBCSE tables are applicable. Niel suggests that LC

Copyright © 2019–2024 MIPI Alliance, Inc. 141

2736 output might have a dedicated table. Impedance specs for LC output need to cover Man_weak0 <
2737 Per_medium1 < Man_strong0. And also maybe a level for Man_medium0.
2738 Man DN for LC: strong0, medium1.
2739 Man DP for LC: ???strong1, strong0, medium0 (because of crosstalk), medium1, weak0.
2740 Per DP for LC: medium1 (> Man weak0).

6.1.5 PHY–Protocol Interface

2741 Annex C describes a suggested set of signals for an internal interface between parts of a Peripheral that
2742 implement the protocol and PHY behavior.

142 Copyright © 2019–2024 MIPI Alliance, Inc.

6.2 Specifications (Normative)

6.2.1 Link Control PHY: Electrical Parameters

2743 ###TODO-Author: This section should be citations of which values to use from the FBCSE tables
2744 (e.g., “V_IH_min and V_IL_max from Table XYZ”). (NOTE: while input levels will be common for
2745 LC_PHY and FBCSE PHY, the output levels use a different definition for both values and test
2746 conditions).

2747 Requirements
2748 1. {} [LC PHY] The Link Control Interface in a Device shall support at least one of the nominal VDD
2749 values shown in Table 26.
2750 Table 26 [LC PHY] Supply Voltage for Link Control Interface

Parameter Symbol Min Nom Max Units

VDD for Nominal 0.9 V Interface VDD_LC_0V9 0.900

VDD for Nominal 1.2 V Interface VDD_LC_1V2 −5 % 1.200 +5 % V

VDD for Nominal 1.8 V Interface VDD_LC_1V8 1.800

2751
2752 2. {} [LC PHY] The input and output voltage parameters for the Link Control Phy shall be within the
2753 ranges shown in Table 27.
2754 Table 27 [LC PHY] Input and Output Voltage Parameters

Parameter Symbol Conditions Min Typ Max Units

VDD= 0.9 V : IOH= −3.3 mA

Logic High Output
VDD= 1.2 V : IOH= −4.4 mA 80 % — — VDD
Voltage
VOH_LC VDD= 1.8 V : IOH= −6.6 mA
Conditional in
Peripheral [1]
(All VDDs) : IOH= −27 uA 95 % — — VDD

VDD= 0.9 V : IOL= +3.3 mA

Logic Low Output VDD= 1.2 V : IOL= +4.4 mA — — 20 % VDD
Voltage VOL_LC VDD= 1.8 V : IOL= +6.6 mA
Not in Peripheral [1]
(All VDDs) : IOL= +27 uA — — 5% VDD

Logic High Input

VIH_LC — 45 % — 65 % VDD
Threshold

Logic Low Input

VIL_LC — 35 % — 55 % VDD
Threshold

Input Hysteresis VHYS_LC — 10 % — — VDD

Overshoot tolerance VOVER VDD = 0.9 V VGND − 0.340 — VDD + 0.340 V

from VDD
(recommended)
Copyright © 2019–2024 MIPI Alliance, Inc. 143
All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024

Parameter Symbol Conditions Min Typ Max Units

VDD = 1.2 V VGND − 0.390 — VDD + 0.390 V

VDD = 1.8 V VGND − 0.585 — VDD + 0.585 V

2755 Note:
1. In the LC_PHY in Peripherals, the only output capability is optional VOH on the DP pin.

2756 3. {} [LC PHY] The ###TODO-Author-wording LC PHY output impedance shall be in accordance
2757 with Table 28.
2758 Table 28 [LC PHY] Output Impedance

Parameter Symbol Conditions Min Typ Max Units

Manager : DP & DN (Logic

1 & 0) IOH = − 00 µA
ZOUT_LC_Medium_Type1 16.0 — 600 Ω
(not-for-long-DLV) IOL = +100 µA
(see Permission 1)

Manager : DP & DN (Logic

IOH = − 00 µA
1 & 0) ZOUT_LC_Medium_Type2 400 490 600 Ω
IOL = +100 µA
(long-DLV compatible)

Peripheral : DP Logic 1 [1] ZOUT_LC_Medium IOH = − 00 µA 400 490 600 Ω

Manager DP Logic 0
during Cold Reset (see ZOUT_LC_Strong0_TypeA IOL = +100 µA 16.0 — 600 Ω
Permission ###XREF)

Manager DP Logic 0
during Cold Reset (see ZOUT_LC_Strong0_TypeB IOL = +4000 µA 16.0 44.5 53.4 Ω
Permission ###XREF)

Weak_Drive_Boost = 0 [2]
5.0 7.0 10.0 kΩ
IOL = +30 µA
Manager : DP Logic 0
ZOUT_LC_Weak0
while bus held in Standby (Optional)
Weak_Drive_Boost = 1 [2] 2.5 3.5 5.0 kΩ
IOL = +30 µA

2759 Note:
1. A Peripheral LC PHY drives DP only if the Peripheral generates the optional LC_Requests (see
Section 5.2.2 Requirement 24.C and Requirement 25.C).
2. In a Manager that implements PHY1 and PHY2 (FBCSE) the Weak_Drive_Strength impedances
also apply to the FBCSE Bus Keeper (see Section ###XREF Requirement ###XREF).
2760

144 Copyright © 2019–2024 MIPI Alliance, Inc.

2761 Permissions
2762 1. {} [LC PHY] The ###TODO-Author-wording LC PHY output impedance for the Manager DP Pin
2763 may use the Row labelled # Table 28, provided that the Manager will only be used in systems that
2764 either:
2765 A. Do not use PHY3 (DLV), or:
2766 B. Have sufficiently low crosstalk between the differential pair that the Manager outputs on DP
2767 and DN will not cause false signaling on DN and DP respectively.
2768

6.2.2 Device Electrical Parameters

2769 Requirements

2770 1. {} The total pin capacitance presented by the combination of all PHYs within a SWI3S Device
2771 shall meet the limits shown in Table 29.
2772 Table 29 [Device] Pin Capacitance

Parameter Symbol Conditions Min Typ Max Units

Peripheral Input capacitance CPin_Peripheral — — — 7 pF

Manager Input capacitance CPin_Manager — — — 8 pF

Copyright © 2019–2024 MIPI Alliance, Inc. 145

2773 2. {} The total leakage current due to all PHYs within a SWI3S Device shall meet the limits shown in
2774 Table 30.
2775 Table 30 [Device] Pin Leakage Current

Parameter Symbol Conditions Min Typ Max Units

Measured single-ended on
IHIGH_Leak_Man — — +7 µA
Manager device pin to VDD
Leakage Current Manager
Measured single-ended on
ILOW_Leak_Man −7 — — µA
Manager device pin to GND

Measured single-ended on
IHIGH_Leak_Per — — +6 µA
Peripheral device pin to VDD
Leakage Current Peripheral
(see Recommendation 1)
Recommended Measured single-ended on
— — +1 µA
IHIGH_Leak_Per Peripheral device pin to VDD

Measured single-ended on
ILOW_Leak_Per −6 — — µA
Peripheral device pin to GND
Leakage Current Peripheral
(see Recommendation 1)
Recommended Measured single-ended on
− — — µA
ILOW_Leak_Per Peripheral device pin to GND

2776 Recommendations
2777 1. {} A SWI3S Peripheral should meet the tighter limits on pin leakage current that are labeled as
2778 “Recommended” in Table 30.

6.2.3 Recommended System Electrical Parameters / Device Operating Conditions

2779 Requirements
2780
2781
2782 1. {} A system should use electrical parameters within the range shown in Table 31.
2783 Table 31 Recommended System Parameters [LC PHY]

Parameter Symbol Conditions Min Typ Max Units

Recommended total
bus capacitance seen
by a device including CBUS_DP
— — — 200 pF
the total pin CBUS_DN
capacitance of the
devices on the bus.

Noise margin (sum of

ground offset & injected VIN_NOISE_MARGIN_LC — — — 15 % VDD
noise)

146 Copyright © 2019–2024 MIPI Alliance, Inc.

2784
2785

2786 2. {} ###.
2787
2788

Copyright © 2019–2024 MIPI Alliance, Inc. 147

7 Control Data Stream

2789 This section describes the Control Data Stream used to convey the information in the Command Transport
2790 Protocol. Its position with respect to other layers is illustrated in Figure 68. (The complete version of this
2791 stack is shown in Figure 15 in Section 4.4.1). The Command Protocol is described in Section 8 and the
2792 Commands in Section 9.

SWI3S Registers
Peripheral Command
Non-SWI3S Registers (local)
Model for Registers Non-SWI3S Registers (remote)

Ping, Unblock, SSPA, ExitDormant

ReadA32, WriteA32
Commands Stream-Synchronous Commit Request (SSCR)
Device Synchronous Commit Request (DSCR)
InitCal, TrimCal

Transfers
Command Transport Phases
Protocol Elements of Phases
Bytes

8b/10b Encoding (K-Codes & D-Codes)

Control Data Stream 30-bit PHY Calibration Blocks
Bits & Symbols Undriven Bits
Idle Bits

E.g.,
Impedance,
PHY, e.g., DLV Signaling Levels,
Signal Timing.
2793
Figure 68 Layer Stack: Control Data Stream

7.1 Description (informative)

2794 A SWI3S link includes a Control Data Stream that transfers information in both directions between the
2795 Manager and Peripherals. Layered on top of this Control Data Stream is a Command Transport Protocol
2796 Layer (see Section 8) that conveys commands for managing the link, the payload transport, and other
2797 functions within the Peripherals.

7.1.1 Overview of the Control Data Stream

2798 The data bits transported on a SWI3S interface include a Control Data Stream of one bit per Row, which
2799 thus occupies all of the bits in one Column (or multiple Columns when using Wide Bits). The specific
2800 Column number that is used for this stream is a function of the PHY. The Control Data Stream is defined
2801 independently of the PHY.
2802 The Control Data Stream comprises a sequence of bytes encoded as 10-bit symbols using an 8b/10b code
2803 (see Section 7.1.3) and, at particular points in the Command Transport Protocol, idle bits inserted by the
2804 Manager. For some PHYs the stream also includes bits dedicated to calibrating the timing delays in the
2805 system (see Section 9.1.12).
2806 The stream is half-duplex with all bits in each symbol being transmitted either from the Manager to the
2807 Peripheral(s) or from one Peripheral to the Manager. The Phases sent by the Manager in the Command
2808 Transport Protocol orchestrate this sharing of the Control Data Stream.
2809 The bytes encoded in the Control Data Stream comprise:
2810 • Normal data bytes, where any of the 256 8-bit values are allowed (encoded as 8b/10b D-codes).

148 Copyright © 2019–2024 MIPI Alliance, Inc.

2811 • Control bytes, where certain special values are allowed (encoded as 8b/10b K-codes), as
2812 “commas” in the stream of encoded symbols. The Command Transport Protocol Layer uses one of
2813 these K-codes (K.28.7) as a Sync Marker to align the Peripheral receivers with the Manager.

7.1.1.1 Benefits of 8b/10b Encoding

2814 The 8b/10b encoding used in the Control Data Stream delivers several benefits:
2815 • There is encoding space to represent control bytes as well as data bytes.
2816 • The Peripheral can successfully detect the synchronization symbol whatever its alignment within
2817 the bitstream.
2818 • Some bit errors can be detected because of the sparse use of the symbol space.
2819 • Disparity is controlled, which reduces low frequencies in the spectral content of the bitstream, so
2820 creates less interference with audio signals.

7.1.1.2 Synchronization
2821 The Control Data Stream decoder in the Peripheral needs to acquire synchronization with the sequence of
2822 symbols that is transmitted by the Manager. The encoding described in Section 7.1.3 provides some control
2823 byte symbols with bit patterns that will not occur anywhere else (at any bit alignment) within any
2824 combination of symbols (or idle bit periods) used by the Command Transport Protocol Layer.
2825 The Command Transport Protocol Layer uses one of these symbols (K.28.7) for its Start of Phase Marker,
2826 and this is the only point in the bitstream where there will be a sequence of either two 1s followed by five
2827 0s, or two 0s followed by five 1s. Thus, the decoder can unambiguously determine both the presence and
2828 bit alignment of the K.28.7 symbol, and hence of the following symbols that make up a Phase at the
2829 Command Transport Protocol Layer. The Peripheral continuously searches for this symbol at every possibly
2830 bit alignment so that it will always regain synchronization with the Command Transport Protocol at the
2831 earliest possible opportunity.
2832 Start of Phase Markers are described in Section 8.1.2.1.

7.1.1.3 Idle Bits

2833 The Control Data Stream can include “Idle Bits”, which are 1 or more pairs of successive CDS bits with
2834 values 0 and then 1. Idle Bits can be inserted by the Manager in 2 possible places:
2835 • At defined places within a Command Transport Protocol Phase as a Protocol Spacer, see
2836 Section 8.1.2.9.
2837 • Between one Command Transport Protocol Phase and the next Phase.
2838 For the Peripheral, when Idle Bits occur as part of a Protocol Spacer they are always exactly 10 bits, so the
2839 Peripherals can remain synchronized to the 10-bit symbol boundaries.
2840 When Idle Bits occur between one Command Transport Protocol Phase and the next Phase, they are not
2841 necessarily a multiple of 10 bits, so the Peripheral receiver has to resynchronize to the 10-bit symbols after
2842 an idle bit sequence. The first symbol of a Phase is always a K.28.7 sync marker (see Section 7.1.1.2),
2843 which is used for this synchronization. The sync marker can be detected by the Peripheral receiver at any
2844 bit alignment, so the receiver is guaranteed to resynchronize with this first symbol after the idle bit
2845 sequence.

Copyright © 2019–2024 MIPI Alliance, Inc. 149

7.1.1.4 Undriven Unit Intervals

2846 In a small number of cases, the Control Data Stream bits that are owned by a Peripheral will actually be
2847 undriven. This can happen when:
2848 • A Peripheral encounters sufficient bit errors that it is unsure whether or when to drive a Peripheral
2849 Response, or
2850 • An addressed Peripheral has not completed its synchronization, so is not currently attached to the
2851 bus, or
2852 • In GetStatus Transfers, which solicit a response from all 12 possible Peripherals, when some of the
2853 Peripheral slots are not populated in the system, or
2854 • In read transfers when the Manager encounters bit errors in the Peripheral Response so leaves a
2855 gap equal to the size of the requested Peripheral Packet, to allow for a Peripheral that might be
2856 delivering read data.
2857 At these times, the physical bus value seen by the Manager’s receiver is produced by a bus keeper
2858 maintaining the value that was last actively transmitted by any Device. The decoding of this physical value
2859 is PHY-dependent:
2860 • In PHY1 and PHY2 (FBCSE), the physical bus value will be an unchanged High or Low from the
2861 last UI of the previous Row so the NRZS decoder will produce a Logic 1.
2862 • In PHY3 (DLV) the physical bus value will be a High that is carried over from the Sync1 bit
2863 earlier in the Row, and this is ‘decoded’ to a Logic 1.
2864 In both of these cases, the resulting value of 10 successive Logic 1s is not a valid 8b/10b symbol, so this
2865 undriven condition is easily detected in the Control Data Stream layer of the Manager.

150 Copyright © 2019–2024 MIPI Alliance, Inc.

7.1.2 Control Data Stream Transport

2866 Normative Rules about CDS Transport are in Section 7.2.5.
2867 CDS transport is similar to payload transport used by Data Ports (see Section 12.3) but with some
2868 simplifications and some PHY-dependent constraints on parameters. CDS transport is similar to a Data Port
2869 that is fixed at 1 sample of 1 bit on every Row.
2870 The Command Transport Protocol (see Section 8) determines which CDS bits are used for input to or
2871 output from the device. In Peripherals, the SPM detector monitors every CDS bit as input in order to detect
2872 Start of Phase Markers at any alignment.
2873 The transport parameters in each Device that control CDS transport are a simplified version of the Data
2874 Port payload parameters and are shown in Table 32. The allocation of parameters to registers is defined in
2875 Section 14.
2876 Table 32 Transport Parameters for Control Data Stream

Parameter Name Range Description

The first column allocated to the CDS bit. The range is limited
depending on the selected PHY.
Note:
For some PHYs (e.g., PHY1 and PHY2, FBCSE) this value
is fixed at 0.
CDS_HorizontalStart[4:0] 0–31 Note:
For some PHYs (e.g., PHY3, DLV, see Section 12.1.6.1) the
Manager will additionally transmit the CDS bit value in all
columns after the end of the Sync1 symbols up to the
programmed HStart, so effectively expand the Width to the
left of CDS_HStart.

0–7 The number of consecutive UIs allocated to the CDS bit. This
CDS_BitWidth[2:0]
(width of 1–8) value is excess-1 encoded.

Enables whether 1 UI is allocated for a Guard Bit:

0 => no guard bit;
CDS_GuardEnable 0–1 1 => allocate 1 UI after the CDS bit for a guard bit. Drive
the Guard Bit after any CDS bit that is owned by this
device.

CDS_GuardPolarity 0–1 The value transmitted during the Guard Bit, when this is enabled.

The number of consecutive UIs allocated to Tail Bits (following

CDS_TailWidth[1:0] 0–2 after the CDS bit, or after the CDS guard bit when this is
enabled).

This parameter is optional (and might be implemented only for

some PHYs).
CDS_EndHalfEarly Enables whether the tx output is turned off half a UI early in the
0–1
(optional) last UI of the CDS sequence (CDS bit, guard bit, or CDS tail bit):
0 => normal drive.
1 => tx drive is ended half a UI early.

Copyright © 2019–2024 MIPI Alliance, Inc. 151

Parameter Name Range Description

0 => special drive (passive 1 active 0).

1 => normal.
CDS_DriveType 0–1
See Section 11.1.1.3 for PHY1 and #2 (FBCSE).
See Section 12.1.2 for PHY3 (DLV).

7.1.3 8b/10b Encoding

2877 ###TODO-Author: (low priority, queued behind other important sections): add a figure showing 3
2878 input bytes being chopped into 5/3 bits, encoded to 6/4 bits and the transmission order of the 6-
2879 and 4-bit chunks. Show RD being updated after each of 6- and 4-bit codewords.

7.1.3.1 Basic Encoding Scheme

2880 The encoding takes a byte and divides it into a 5-bit fragment from the less significant bits (LSbs) that is
2881 encoded as a 6-bit codeword, and a 3-bit fragment from the more significant bits (MSbs) that is encoded as
2882 a 4-bit codeword. Each possible value of a fragment is mapped to either:
2883 • A single codeword, or:
2884 • 1 or other of a pair of possible codewords, with the choice depending upon the current running
2885 disparity (see Section 7.1.3.2).
2886 The details of the 5b/6b and 3b/4b mappings of fragments to codewords are described in the normative
2887 specifications in Section 7.2.1.
2888 Note:
2889 In one special case described in the encoding tables, the mapping used in the 3b/4b-encoding is
2890 dependent upon the value that was used in the 5b/6b-encoding (see D.x.7 in Table 36).

7.1.3.2 Running Disparity

2891 The encoder tracks the running disparity (i.e., the accumulated difference between the number of 1s
2892 transmitted compared to the number of 0s transmitted). For 5/3-bit fragments that map to a pair of possible
2893 6/4-bit codewords, the encoder chooses the codeword that minimizes the absolute value of the running
2894 disparity (abbreviated as RD in the encoding tables in Section 7.2.1).
2895 Each codeword has a disparity of either +2 (when the number of 1s is two more than the number of 0s),
2896 0 (when they are equal), or -2 (when the number of 1s is two less than the number of 0s). The running
2897 disparity is updated after each codeword, so the second step in the encoding (3b/4b) is sometimes affected
2898 by the change in disparity introduced by the first step (5b/6b).
2899 The decoder uses the current value of Running Disparity when examining the codeword, and indicates an
2900 error if the wrong codeword is used, even if that would have been a valid codeword if the Running
2901 Disparity were different. (Decoder errors are discussed further in Section 7.1.5.).

7.1.3.2.1 Running Disparity is Independent of Other Peripherals

2902 There is effectively a separate Running Disparity “contract” between the Manager and each of the
2903 Peripherals. Whenever a Peripheral transmits a sequence of 1 or more symbols to the Manager, its initial
2904 Running Disparity is determined by the value of RD when its decoder accepted the last bit of the most
2905 recent symbol from the Manager, and is not affected by any intervening CDS bits that have been
2906 transmitted by other Peripherals (during Ping Commands in GetStatus Phases or SSCR/DSCR Commands
2907 in Commit Phases). Thus, when the Manager decodes the first symbol from each new Peripheral, it also
2908 re-initializes its Running Disparity to be the value after the last symbol that the Manager transmitted.

152 Copyright © 2019–2024 MIPI Alliance, Inc.

2909 When the Manager next transmits symbols, the values of both its RD and the RD in the Peripheral
2910 decoder(s) are again re-initialized to the value after the most recent symbol that was transmitted by the
2911 Manager.
2912 In the Command Transport Protocol Phases described in Section 8, when the Manager next transmits after
2913 receiving information from a Peripheral, it will be doing one of:
2914 • Starting a new Phase with an SPM that will forcably re-initialize the RD in all Peripheral
2915 receivers.
2916 • Driving a Manager Response to a Commit, ReadSetup, or ReadData Phase, all of which use HD10
2917 tokens which are encoded and decoded to the same symbols, independent of current RD.

7.1.3.3 Transmission Order (Endianness)

2918 The 6-bit codeword that represents the 5 LSbs of the byte is transmitted before the 4-bit codeword that
2919 represents the 3 MSbs, i.e., with little-endian “codeword ordering”. While the codewords themselves might
2920 be considered to be just bit patterns, it is conventional to describe the codewords as having MSbs and LSbs,
2921 and each of these codewords is transmitted LSb first (little-endian bit ordering).
2922 Note:
2923 When illustrating the symbols as bit patterns, it is conventional to show the 10-bit symbols and the
2924 individual codewords in transmission order, i.e., with the 6-bit codeword to the left of the 4-bit
2925 codeword, and the LSbs at the left of each value.

7.1.3.4 D-codes vs. K-codes

2926 Normal data bytes are encoded as D-codes. A D-code is described as D.x.y, where x is the decimal value of
2927 bits 4 to 0 of the unencoded data byte, and y is the decimal value of bits 7 to 5. Thus, e.g.:
2928 • Byte value 255 (0xFF) is encoded as D.31.7.
2929 • Byte value 254 (0xFE) is encoded as D.30.7.
2930 • Byte value 222 (0xDE) is encoded as D.30.6.
2931 • Byte value 188 (0xBC) is encoded as D.28.5.
2932 Control bytes are encoded as K-codes and are similarly described as K.x.y. For each K-code, one or both of
2933 the 5b/6b- and 3b/4b-encoding steps uses a different mapping to codewords than is used for D-codes. The
2934 encoding does not support all 256 possible values for control bytes: the K-codes that can be encoded are:
2935 K.23.7, K.27.7, K.29.7, K.30.7, and K.28.y (for all 8 possible values of y).
2936 Examples of control byte values that can be encoded are:
2937 • Control byte value 254 (0xFE) is encoded as K.30.7.
2938 • Control byte value 188 (0xBC) is encoded as K.28.5.
2939 • Control byte value 252 (0xFC) is encoded as K.28.7.
2940 Note:
2941 The only K-code that is used by the Command Transport Protocol Layer is K.28.7, and the protocol
2942 needs the symbols for this to be detected at any alignment within the bitstream. Thus, this detection
2943 is typically performed outside of the basic 8b/10b decoder, which then only need to decode valid
2944 D-codes.

Copyright © 2019–2024 MIPI Alliance, Inc. 153

7.1.3.5 K-codes as Comma Symbols

2945 K-codes for K.28.1, K.28.5, and K.28.7 have a special property that they contain a particular bit sequence
2946 that will not occur anywhere else in bitstreams comprised of sequences of D-codes and K-codes. Thus, they
2947 can be used as markers to identify the alignment of symbol boundaries within a bitstream, and are
2948 sometimes referred to as “comma symbols”. The Command Transport Protocol Layer uses the K.28.7 code
2949 for this purpose (see SPM in Section 8.1.2.1). The bit patterns for these comma symbols are shown in
2950 Table 33. The K.28.7 bit pattern has the special property that it cannot be formed at any position in a stream
2951 of valid symbols, even with a single bit error.
2952 Note:
2953 The K.28.1 and K.28.5 Comma Symbols are not used in this version of this Specification.

2954 Table 33 K.28.y Comma Symbols

Encoded Symbol
Byte Value
Symbol When RD = -1 When RD = +1
Name Binary, MSb First: Bit Pattern, LSb First: Bit Pattern, LSb First:
Decimal Hex
HGFEDCBA abcdeifghj abcdeifghj
K.28.1 60 0x3C 00111100 0011111001 1100000110
K.28.5 188 0xBC 10111100 0011111010 1100000101
K.28.7 252 0xFC 11111100 0011111000 1100000111

7.1.4 Robust Tokens Used in Command Transport Protocol

2955 Robust Tokens are 16 carefully selected 8-bit data byte values that encode to 10-bit D-code symbols in the
2956 Control Data Stream that have several useful properties:
2957 • The encoded symbols all have zero disparity (i.e., they contain five 1s and five 0s), so they do not
2958 affect the current running disparity value for the Control Data Stream as a whole. This is
2959 advantageous when a sequence of adjacent symbols is driven by different Peripheral devices,
2960 which might be unable to receive each other’s transmissions, and hence unable to adapt their
2961 encoding behavior to changes in disparity caused by those Peripherals.
2962 • There is a single encoding for each symbol. This has 2 advantages: it reduces the probability that a
2963 given symbol is seen in random data from 2/1024 to 1/1024 and the Decoder behavior is not
2964 sensitive to having the “correct” RD.
2965 • The encoded symbols are separated by a minimum Hamming Distance of 4. This guarantees that a
2966 small number of bit errors in the Control Data Stream will not change one Robust Token symbol
2967 into another, so that these bit errors can be detected.
2968 • Some subsets of the encoded symbols are separated by larger Hamming Distance (there are two
2969 subsets of four symbols with Hamming Distance of 6 and four subsets of two symbols with
2970 Hamming Distance of 10), which facilitates choosing symbols which have larger separation in
2971 some special uses.
2972 Robust Tokens are used for elements of the Command Transport Protocol Layer that are treated as 1- or
2973 2-byte fields, where adding two further bytes of CRC to detect bit errors would be inefficient.
2974 Table 34 lists the Robust Token values that are used within the Command Transport Protocol, and the name
2975 of the corresponding 8b/10b-encoded symbols. Robust Token Numbers 0 and 15 are highlighted with green
2976 background to indicate that these are the two “HD10 Robust Tokens” described in Section 7.1.4.1.

154 Copyright © 2019–2024 MIPI Alliance, Inc.

2977 Table 34 Robust Token Symbols

Byte Value Encoded Symbol

Robust
Symbol
Token
Name Binary, MSb First: Bit Pattern, Transmitted
Number Decimal Hex
HGFEDCBA Left Bit First: abcdeifghj

0 D.05.1 37 0x25 00100101 1010011001

1 D.06.6 198 0xC6 11000110 0110010110

2 D.11.2 75 0x4B 01001011 1101000101

3 D.19.5 179 0xB3 10110011 1100101010

4 D.21.2 85 0x55 01010101 1010100101

5 D.10.1 42 0x2A 00101010 0101011001

6 D.13.6 205 0xCD 11001101 1011000110

7 D.18.2 82 0x52 01010010 0100110101

8 D.09.5 169 0xA9 10101001 1001011010

9 D.22.1 54 0x36 00110110 0110101001

10 D.17.6 209 0xD1 11010001 1000110110

11 D.14.5 174 0xAE 10101110 0111001010

12 D.12.2 76 0x4C 01001100 0011010101

13 D.20.5 180 0xB4 10110100 0010111010

14 D.25.1 57 0x39 00111001 1001101001

15 D.26.6 218 0xDA 11011010 0101100110

2978 Note:
2979 The binary byte value and encoded bit pattern in Table 34 are shown using green- and
2980 orange-colored text to emphasize the ordering of the fragments resulting from each of the 5b/6b-
2981 and 3b/4b-encoding steps.

7.1.4.1 HD10 Robust Tokens

2982 Some parts of the Command Transport Protocol Layer use Robust Tokens as a “go/no-go” indication where
2983 only two symbols are used. The symbols chosen for these indications are Robust Token Numbers 0 and 15,
2984 which have a Hamming Distance of 10 (i.e., they are bitwise inverses of each other). These are referred to
2985 as “HD10 Robust Tokens”, and are shown highlighted in Table 34.
2986 The 8b/10b encoder will always generate the exact bit pattern for an HD10 Robust Token, but this might be
2987 corrupted by bit errors in the transport. When the Command Transport Protocol Layer indicates that an
2988 HD10 Robust Token is expected, the 8b/10b decoder compares the received 10-bit symbol with the two

Copyright © 2019–2024 MIPI Alliance, Inc. 155

2989 valid 10-bit patterns that correspond to Robust Tokens 0 and 15, and returns an indication of whichever has
2990 the closest Hamming Distance (biassed towards Robust Token Number 0). If the received symbol was not
2991 an exact match then the decoder will also indicate an error as described in Section 7.1.5.3.

7.1.5 Error Detection in the 8b/10b Decoder

2992 Several possible error conditions can be detected in the 8b/10b-Decoder when it is fed with 10-bit symbol
2993 values that have been corrupted by bit errors in the transport layer. This Section describes the errors that
2994 can be signaled to the Command Transport Protocol Layer. In some circumstances, these errors are
2995 discarded (e.g., before the Peripheral has received an error-free Command Header). Handling of Transport
2996 and Protocol Errors within the Command Transport Protocol is discussed in Section 8.1.1.7.

7.1.5.1 8b/10b-Decoding Errors

2997 The following conditions are all signaled to the Command Transport Protocol Layer as Bad 8b/10b
2998 Symbol Transport Error:
2999 • The 5b/6b-decoding step encounters a codeword that does not correspond to any validly encoded
3000 ‘x’ value (for D.x or K.x).
3001 • The 3b/4b-decoding step encounters a codeword that does not correspond to any validly encoded
3002 ‘y’ value (which is evaluated in the context of the previously decoded D.x or K.x value and the
3003 Running Disparity following the decoding of that value).
3004 • Either of the 5b/6b- or 3b/4b-decoding steps encounters a codeword that would cause the Running
3005 Disparity to exceed +1 or -1 (see Table 41).
3006 Note:
3007 This error is not generated when the Command Transport Protocol is expecting an HD10 token,
3008 even if the received 10-bit symbol provokes one or more of these conditions.

7.1.5.2 Control Byte Errors

3009 The following condition is signaled to the Command Transport Protocol Layer as Bad 8b/10b Symbol
3010 Transport Error:
3011 • The complete 8b/10b-decoding produces a K-code that is not used within the Command Transport
3012 Protocol Layer (i.e., any valid K-code except for K.28.7).

7.1.5.3 Errors Relating to Robust Tokens

3013 In addition to the basic transport errors, when the Command Transport Protocol Layer indicates that it is
3014 expecting a Robust Token or an HD10 Robust Token (see Section 7.1.4.1), the Decoder can report some
3015 more specific errors.
3016 The following condition is signaled as a Bad Robust Token Transport Error:
3017 • The 8b/10b-decoding produces a valid D-code or K-code, but it is not one of the 16 D-codes listed
3018 in Table 34.
3019 The following condition is signaled as an Unexpected Robust Token Protocol Error:
3020 • The 8b/10b-decoding produces a valid D-code that is one of the D-codes listed in Table 34, but the
3021 Robust Token Number is one that does not have an assigned meaning at this particular place in the
3022 byte sequence within the Command Transport Protocol (see Section 8.1.12).
3023 The following condition is signaled as a Bad HD10 Token Transport Error:
3024 • The Command Transport Protocol Layer indicated that it was expecting an HD10 Robust Token
3025 and the 10-bit symbol was not a correctly encoded Robust Token Number 0 or 15. When signaling
3026 this error, the Decoder will also indicate whichever of Robust Token 0 or 15 had a closer
3027 Hamming Distance to the received symbol (see Section 7.1.4.1).

156 Copyright © 2019–2024 MIPI Alliance, Inc.

7.1.6 ###TODO 8b/10b Encoding Examples

3028 ###Note to Reviewers: there will be some example sequences of encoded bytes once the
3029 Command Transport Protocol in Section 8 is completed. The notes in the following sections are
3030 work-in-progress ideas for those examples.
3031 ###notes: Pick short sequences that match the start of a real Command Packet. Show the effect of initial
3032 running disparity of -1 or +1: some encodings are no different, but the effect of the initial disparity is
3033 carried through to subsequent symbols. Consider an example of a GetStatus Phase with some of the
3034 Peripherals generating Token Numbers 16 and 17 to show that all Peripherals generate their response based
3035 on the RD at the point when the Manager finished transmitting.
3036 Robust Tokens are now all 5/5 balanced, so the notes below need to be updated.
3037 TO-DO: choose between figures or inline text using Code style?

7.1.6.1 ###TODO: 8b/10b Encoding Example 1

3038
3039 ###notes:
3040 ###TODO: consider the effect of change to SPM=K.28.7 which will leave RD unchanged, so perhaps two
3041 variants of starting RD are still as interesting?
3042 Initial disparity +1
3043 Control byte K28.7 (balanced 5/5) => RD = +1
3044 Data Byte D.x.y (biassed 4/6) => RD = -1
3045 Data Byte D.x.y (balanced 5/5) => RD = -1
3046 Data Byte D.x.y (biassed 6/4) => RD = +1
3047 Data Byte D.x.y (biassed 5/5) => RD = +1
3048 Show this as a contiguous bit sequence but with breaks to illustrate boundaries, e.g.:
3049 abcdei fghj abcdei fghj abcdei fghj abcdei fghj
3050 ###NOTE: use some notation that groups these as the 6+4 bits that are part of one symbol. i.e., not 4+6.

7.1.6.2 ###TODO: 8b/10b encoding example 2

3051 ###notes:
3052 Same as example 1 but with initial disparity +1, so that the disparities are toggled with respect to
3053 example 1. Maybe show both bitstreams side by side?
3054 Control byte K28.5 (biassed 4/6) => RD = -1
3055 Data Byte D.x.y (biassed 6/4) => RD = +1
3056 Data Byte D.x.y (balanced 5/5) => RD = +1
3057 Data Byte D.x.y (biassed 4/6) => RD = -1
3058 Data Byte D.x.y (biassed 5/5) => RD = -1
3059 Show this as a contiguous bit sequence but with breaks to illustrate boundaries, e.g.:
3060 abcdei fghj abcdei fghj abcdei fghj abcdei fghj

7.1.6.3 ###TODO: 8b/10b encoding example 3

3061 ###notes:
3062 Illustrate an even number of idle bits preceding the same examples, e.g.:
3063 Initial disparity -1; 4 bits idle=> disparity still -1 so same encodings as example 1.

Copyright © 2019–2024 MIPI Alliance, Inc. 157

3064 0101 abcdei fghj abcdei fghj abcdei fghj abcdei fghj
3065 Note: idle bit sequences are always [01]^n, independently of initial RD, and the RD remains unchanged.
3066

7.1.6.4 ###TODO: 8b/10b encoding example 4

3067 ###notes:
3068 Illustrate a Phase using HD10 where there is a bit error, to show the Peripheral correcting to nearest.

158 Copyright © 2019–2024 MIPI Alliance, Inc.

7.2 Specifications (normative)

7.2.1 Control Data Stream 8b/10b Encoding

3069 Requirements
3070 1. {} Each Device (Manager or Peripheral) shall have one 8b/10b-Encoder.
3071 2. {} Each Device (Manager or Peripheral) shall have a ###TODO-Author complete this
3072 3. {} The 8b/10b-Encoder shall maintain a record of the Running Disparity with values chosen from
3073 {+1, -1}.
3074 Note: Running Disparity is abbreviated to “RD” in the following rules in this Section.
3075
3076 4. {} In the Manager: After a Cold Reset, the Manager shall initialize its RD to −1.
3077 Note: The Peripheral does not need a reset value for its RD because the Peripheral will use the RD
3078 from the Decoder, which will have been initialized by the SPM received from the Manager (see
3079 Section 7.2.2 Requirement 5A and 6A).
3080 5. {} In the Manager: At the beginning of each sequence of one or more symbols generated by the
3081 8b/10b-Encoder, the Encoder shall initialize its RD to the value of the RD in the Manager’s
3082 Decoder at the end of the most recently received 8b/10b symbol from a Peripheral.
3083 Note: Calibration Packets are not 8b/10b symbols, so they do not affect the RD in the Manager.
3084 6. {} In a Peripheral: At the beginning of each sequence of one or more symbols generated by the
3085 8b/10b-Encoder, the Encoder shall initialize its RD to the value of the RD in that Peripheral’s
3086 Decoder at the end of the most recently received 8b/10b symbol from the Manager.
3087 Note: Calibration Packets and Protocol Spacers are not 8b/10b symbols, so they do not affect the
3088 RD in the Peripheral.
3089 7. {} The 8b/10b Encoder shall produce a 10-bit symbol for a D-code by:
3090 A. Encoding the 5 LSbs of the input byte as a 6-bit codeword according to Table 35 and updating
3091 the RD according to Table 37, and then
3092 B. Encoding the 3 MSbs of the input byte as a 4-bit codeword according to Table 36 (using the
3093 RD after it was updated in Step 7A) and updating the RD according to Table 37.
3094 Table 35 8b/10b 6-bit Codewords for D-codes

Encoded 6-bit value

Unencoded 5-bit value
(binary: abcdei, left bit
(x in D.x.y)
transmitted first)

binary: MSb on left:

x When RD = -1 When RD = +1
EDCBA

D.0 00000 100111 011000

D.1 00001 011101 100010

D.2 00010 101101 010010

D.3 00011 110001

D.4 00100 110101 001010

Copyright © 2019–2024 MIPI Alliance, Inc. 159

Encoded 6-bit value

Unencoded 5-bit value
(binary: abcdei, left bit
(x in D.x.y)
transmitted first)

binary: MSb on left:

x When RD = -1 When RD = +1
EDCBA

D.5 00101 101001

D.6 00110 011001

D.7 00111 111000 000111

D.8 01000 111001 000110

D.9 01001 100101

D.10 01010 010101

D.11 01011 110100

D.12 01100 001101

D.13 01101 101100

D.14 01110 011100

D.15 01111 010111 101000

D.16 10000 011011 100100

D.17 10001 100011

D.18 10010 010011

D.19 10011 110010

D.20 10100 001011

D.21 10101 101010

D.22 10110 011010

D.23 10111 111010 000101

D.24 11000 110011 001100

D.25 11001 100110

D.26 11010 010110

160 Copyright © 2019–2024 MIPI Alliance, Inc.

Encoded 6-bit value

Unencoded 5-bit value
(binary: abcdei, left bit
(x in D.x.y)
transmitted first)

binary: MSb on left:

x When RD = -1 When RD = +1
EDCBA

D.27 11011 110110 001001

D.28 11100 001110

D.29 11101 101110 010001

D.30 11110 011110 100001

D.31 11111 101011 010100

3095 Table 36 8b/10b 4-bit Codewords for D-codes

Encoded 4-bit value

Unencoded 3-bit value Conditions to Choose Between
(binary: fghj, left bit
(y in D.x.y) D.x.7 Encodings
transmitted first)

binary: MSb on the

Y When RD = –1 When RD = +1 —
left: HGF

D.x.0 000 1011 0100 —

D.x.1 001 1001 —

D.x.2 010 0101 —

D.x.3 011 1100 0011 —

D.x.4 100 1101 0010 —

D.x.5 101 1010 —

D.x.6 110 0110 —

D.x.7 111 0111 0001 D.x.7 = {D.17.7, D.18.7, D.20.7}

D.x.7 111 1110 1000 D.x.7 = {D.11.7, D.13.7, D.14.7}

D.x.7 111 1110 0001 All other values of D.x.7

3096 Note:
3097 The choice between 4-bit codewords is normally a function of the 3-bit value to be encoded plus
3098 the current RD. In the special case of D.x.7, the choice of 4-bit codeword is also a function of the
3099 preceding 6-bit codeword (i.e., the value of ‘x’).

Copyright © 2019–2024 MIPI Alliance, Inc. 161

3100 The 3b/4b encodings used for D.x.7 when x={17,18,20} with RD=-1, and when x={11,13,14} with
3101 RD=+1 are sometimes referred to as the “alternate encodings”, and are defined in this way so that
3102 the complete D-code symbols do not accidentally duplicate the unique bit pattern found in K-codes
3103 used for synchronization (see Table 33). These cells are highlighted in pink in Table 36.

3104 Table 37 Running Disparity in 8b/10b Encoder

Running Disparity Disparity of 6-bit Running Disparity

before this Codeword or 4-bit Codeword after this Codeword

-1 +2 +1

-1 0 -1

+1 0 +1

+1 -2 -1

3105 8. {} The 8b/10b encoder shall produce a 10-bit symbol for a K-code by:
3106 A. Encoding the 5 LSbs of the input byte as a 6-bit value according to Table 38 and updating the
3107 RD according to Table 37, and then:
3108 B. Encoding the 3 MSbs of the input byte as a 4-bit value according to Table 39 (using the RD
3109 after it was updated in Step 8A) and updating the RD according to Table 37.
3110 Table 38 8b/10b 6-bit Codewords for K-codes

Encoded 6-bit value

Unencoded 5-bit value
(binary: abcdei, left bit Used Only in these K-codes
(x in K.x.y)
transmitted first)

X binary: EDCBA, MSb First When RD = –1 When RD = +1 —

K.23 10111 111010 000101 K.23.7

K.27 11011 110110 001001 K.27.7

K.28 11100 001111 110000 K.28.y for any y

K.29 11101 101110 010001 K.29.7

K.30 11110 011110 100001 K.30.7

3111 Note: The 6-bit and 4-bit codewords for K-codes highlighted in yellow in Table 38 and Table 39 are
3112 different to those used for the corresponding D-codes (in Table 35 and Table 36).

162 Copyright © 2019–2024 MIPI Alliance, Inc.

3113 Table 39 8b/10b 4-bit Codewords for K-codes

Encoded 4-bit Value

Unencoded 3-bit Value
(binary: fghj, left bit Used Only in these K-codes
(y in K.x.y)
transmitted first)

Y binary: HGF, MSb First When RD = –1 When RD = +1 —

K.x.0 000 1011 0100 K.28.0

K.x.1 001 0110 1001 K.28.1

K.x.2 010 1010 0101 K.28.2

K.x.3 011 1100 0011 K.28.3

K.x.4 100 1101 0010 K.28.4

K.x.5 101 0101 1010 K.28.5

K.x.6 110 1001 0110 K.28.6

K.x.7 for x =
K.x.7 111 0111 1000
{23, 27, 28, 29, 30}

Copyright © 2019–2024 MIPI Alliance, Inc. 163

3114 9. {} When the Command Transport Protocol Engine instructs the 8b/10b Encoder to transport a
3115 Robust Token, the Encoder shall use the 8b/10b symbol assigned to that Robust Token Number
3116 according to Table 40.
Table 40 Robust Token Values

Robust Name of Byte Value Byte Value

Token 8b/10b (Decimal) (Hex)
Number Symbol

0 D.05.1 37 0x25

1 D.06.6 198 0xC6

2 D.11.2 75 0x4B

3 D.19.5 179 0xB3

4 D.21.2 85 0x55

5 D.10.1 42 0x2A

6 D.13.6 205 0xCD

7 D.18.2 82 0x52

8 D.09.5 169 0xA9

9 D.22.1 54 0x36

10 D.17.6 209 0xD1

11 D.14.5 174 0xAE

12 D.12.2 76 0x4C

13 D.20.5 180 0xB4

14 D.25.1 57 0x39

15 D.26.6 218 0xDA

3117 Note:
3118 The two values used for “HD10 Robust Tokens” are Robust Token Numbers 0 and 15, which are
3119 highlighted with green color in Table 40.
3120 Note:
3121 The 10-bit codewords used for the Robust Tokens are not sensitive to (and do not change) the
3122 Running Disparity, thus they can be correctly decoded even when the Decoder starts with the
3123 wrong value of RD. The codewords are shown in informative Table 34.

164 Copyright © 2019–2024 MIPI Alliance, Inc.

7.2.2 Control Data Stream 8b/10b Decoding

3124 ###TODO-Author: resolve overlaps with Section 8.2.1.
3125 Note:
3126 The rules in Section ###XREF ###TODO-Author: complete this sentence or delete it!

3127 Requirements
3128 1. {} The Manager shall have one 8b/10b-Decoder.
3129 2. {} The Peripheral shall behave as if it has two 8b/10b-Decoders, co-ordinated by the
3130 Phase-decoding rules in Section 8.2.1:
3131 A. Decoder #1 for the Phase-in-Progress.
3132 B. Decoder #2: for Header Detection.
3133 Note: Decoder #2 is used by the rules that search for potential new Headers even while in the
3134 middle of an existing Phase. See Section 8.2.1 Requirements #, #, and #.
3135 Note: Decoding an error-free Header is independent of RD, thus an implementation of Decoder #2
3136 could use the RD state from Decoder #1.
3137 Note: An implementation of the two decoders might save gates by multiplexing a single copy of the
3138 combinatorial logic used to perform the 5b/6b and 3b/4b decoding.
3139 3. {} An 8b/10b-Decoder shall maintain a record of the Running Disparity (abbreviated “RD” in the
3140 remainder of this Section) in received symbols with values chosen from {+1, -1}.
3141 Note: Typical implementations use the same 1 flip-flop for both Decoder RD and Encoder RD (see
3142 Section 7.2.1 Requirement 3).
3143 Note: Running Disparity is abbreviated to “RD” in the following rules in this Section.
3144 4. {} When the Peripheral is not driving CDS bits, it shall search for both of the 10-bit patterns that
3145 correspond to the K.28.7 sync marker at every bit boundary in the contiguous received Control
3146 Data Stream.
3147 Note: i.e., the search does not examine bits driven by this Peripheral, and does not span across
3148 CDS bits received either side of a symbol driven by this Peripheral.
3149 5. {} When the 8b/10b-Decoder in a Peripheral detects the bit pattern “0011111000” (K.28.7) at any
3150 bit alignment within the contiguous received Control Data Stream, it shall:
3151 A. Set the RD to -1.
3152 B. Treat the next bit as the first bit of a 6-bit codeword to be decoded according to
3153 Requirement 9A.
3154 C. Signal to the Command Transport Protocol Decoder that this is the starting point of a possible
3155 Phase Header (see Section 8.2.1 Requirement 5).
3156 Note: “at any bit alignment” in this Requirement includes starting at a bit that was part way through
3157 another valid SPM pattern.
3158 6. {} When the 8b/10b-Decoder in a Peripheral detects the bit pattern “1100000111” (K.28.7) at any
3159 bit alignment within the contiguous received Control Data Stream, it shall:
3160 A. Set the RD to +1.
3161 B. Treat the next bit as the first bit of a 6-bit codeword to be decoded according to
3162 Requirement 9A.
3163 C. Signal to the Command Transport Protocol Decoder that this is the starting point of a possible
3164 Phase Header (see Section 8.2.1 Requirement 5).
3165 Note: “at any bit alignment” in this Requirement includes starting at a bit that was part way through
3166 another valid SPM pattern.

Copyright © 2019–2024 MIPI Alliance, Inc. 165

3167 7. {} When the Command Transport Protocol Decoder State Machine (see ###XREF) in a Peripheral
3168 is not in state Idle, the 8b/10b-Decoder shall:
3169 A. Count received bits modulo 10 to maintain alignment with symbols.
3170 B. If the Command Transport Protocol Decoder indicates that the current symbol is generated by
3171 the Manager then decode the symbol and update its RD according to Requirement 9.
3172 Note: See also: Recommendation 1.
3173 8. {} When the Command Transport Protocol Decoder State Machine (see ###XREF) in a Manager
3174 is not in state Idle, the 8b/10b-Decoder shall:
3175 A. Count received bits modulo 10 to maintain alignment with symbols.
3176 B. If the Command Transport Protocol Decoder indicates that the current symbol is generated by
3177 a Peripheral then decode the symbol and update its RD according to Requirement 9.
3178 9. {} When the Command Transport Protocol Decoder (see ###XREF) indicates that the current
3179 symbol is to be decoded, the 8b/10b-Decoder shall:
3180 A. Decode the first 6 bits received (and the current RD) to either D.x or K.x according to
3181 Table 35 and Table 38 and update the RD from the 6-bit value according to Table 41, and
3182 then:
3183 B. Decode the next 4 bits received (and the RD after it was updated in step 9A) to either D.x.y or
3184 K.x.y according to Table 36 and Table 39 and update the RD from the 4-bit value according to
3185 Table 41 and then:
3186 C. Pass the decoded D.x.y or K.x.y symbol to the Command Transport Protocol Decoder, along
3187 with any error conditions detected (see Requirements 10, 11, and 12).
3188 Table 41 Running Disparity in 8b/10b Decoder

Running Disparity Disparity of Running Disparity Running Disparity

Before this Codeword Received Codeword After this Codeword Overflow

-1 +4, +6 +1 Yes

-1 +2 +1 No

-1 0 -1 No

-1 -2, -4, -6 -1 Yes

+1 +2, +4, +6 +1 Yes

+1 0 +1 No

+1 -2 -1 No

+1 -4, -6 -1 Yes

3189 Note: The rows highlighted in color in Table 41 are a result of decoding invalid inputs (see the error
3190 in Requirement 10.C).

166 Copyright © 2019–2024 MIPI Alliance, Inc.

3191 10. {} When the Command Transport Protocol Decoder (see ###XREF) indicates that the current
3192 symbol is to be decoded, the 8b/10b-Decoder shall indicate an error condition of “Bad 8b/10b
3193 Symbol Transport Error” (see Table 163) if it detects any of the following conditions:
3194 A. The 5b/6b-decoding step in Requirement 9A encounters a codeword that is not listed in either
3195 Table 35 or Table 38, or:
3196 B. The 3b/4b-decoding step in Requirement 9B encounters a codeword that is not listed in either
3197 Table 36 or Table 39, or:
3198 C. Either of the decoding steps in Requirements 9A or 9B encounters a codeword that would
3199 cause a Running Disparity Overflow as indicated in Table 41, or:
3200 D. The combination of decoding steps in Requirements 9A and 9B does not correspond to a valid
3201 D.x.y or K.x.y symbol, or:
3202 E. The combination of decoding steps in Requirements 9A and 9B produces a K-code that is not
3203 K.28.7.
3204 Note: it is possible for a single 10-bit received codeword to trigger more than 1 of the error
3205 conditions described in 10A through 10E. The error counters (see Table 163) might count this as
3206 either 1 or more errors.
3207 11. {} When the Command Transport Protocol Decoder indicates that it is expecting a Robust Token,
3208 the 8b/10b-Decoder shall indicate an error condition of “Bad Robust Token Transport Error”
3209 (see Table 163) if it detects the following condition:
3210 A. The combination of decoding steps in Requirements 9A and 9B does not produce a D-code
3211 that is one of the 16 D-codes listed in Table 40.
3212 12. {} When the Command Transport Protocol Decoder indicates that it is expecting an HD10 Robust
3213 Token, the 8b/10b-Decoder shall indicate an error condition of
3214 “Bad HD10 Token Transport Error” (see Table 163) if it detects any of the following
3215 conditions:
3216 A. The combination of decoding steps in Requirements 9A and 9B does not produce a D-code
3217 that is one D.05.1 or D.26.6 (i.e., Robust Token Number 0 or 15 in Table 40).
3218 13. {} When the Command Transport Protocol Decoder indicates that it is expecting an HD10 Robust
3219 Token, the 8b/10b-Decoder shall evaluate the Hamming Distance between the received 10-bit
3220 symbol and the bit pattern “1010011001” (a correctly encoded D.05.1), and choose one of the
3221 following two values for the decoded output in Requirement 9C:
3222 A. D.05.1 (Robust Token 0), if the 10-bit symbol matches 5 or more of the bits in the pattern for
3223 D.05.1, or
3224 B. D.26.6 (Robust Token 15), if the 10-bit symbol matches 4 or fewer of the bits in the pattern
3225 for D.05.1.
3226 ###TODO-author: check that we have a normative REQ for incrementing the Bad_HD10 error
3227 counter.

3228 Recommendations
3229 1. {} When the ###TODO-Author:rephrase this: Command Transport Protocol Decoder State
3230 Machine (see ###XREF) in a Peripheral is in state Idle, the 8b/10b-Decoder should ignore
3231 received bits other than attempting to detect the K.28.7 symbol described in
3232 Requirements 4, 5 and 6.
3233

7.2.3 Control Data Stream: Idle Patterns

3234 Requirements
3235 1. {} When the Manager Command Interpreter FSM is in state MCI:Idle the Manager shall generate a
3236 CDS Idle pattern, which consists of pairs of CDS bits with values of 0 and then 1.

Copyright © 2019–2024 MIPI Alliance, Inc. 167

3237 ###TODO-Author: rephrase “… MCI:Idle” because this FSM does not exist: it was not needed for
3238 the Manager rules.
3239 2. {} The bits in the CDS Idle pattern shall be encoded with the PHY-specific encoding, e.g., NRZS
3240 for PHY1 & PHY2 (FBCSE PHY).
3241 ###TODO-Author: add a table defining the encodings and including XREF links. DLV is None.
3242 FBCSE is NRZS from previous UI (not previous CDS bit).
3243

7.2.4 #WIP: Control Data Stream: PHY Calibration Blocks

3244 ###notes: maybe all of the normative rules for the 3-bit “calibration measurements” and the 30-bit
3245 “calibration blocks” will be in Section 8.

7.2.5 #WIP: Control Data Stream: Transport

3246 Note:
3247 These simple rules are effectively a subset of the basic data port rules from Section 12.3.
3248 ###TEMP: link to informative material Section 7.1.2.
3249 ###TODO-Author: add an informative figure to explain how to transmit 8b/10b tokens, idle bit pairs, 30-bit
3250 DLV calibration blocks, (endianness etc.). e.g., 10 successive rows containing the CDS bits from 1 token,
3251 labelled with the lower case letters that are used in the 8b10b encoding tables: abcdeifghj. Maybe CDS-a
3252 through CDS-j. Maybe CDS-0 and CDS-1 for the Idle bits. Maybe use purple & yellow for serialising the
3253 calibration blocks (maybe only in the section that describes the calibration command).

3254 Requirements
3255 1. {} The Control Data Stream shall transport 1 bit per Row.
3256 2. {} The direction (transmit or receive) of the CDS bit shall be determined by the Command
3257 Transport Protocol (see Section 8.2.1).
3258 3. …###TODO-Author: write some simple rules to explain this transport. These might be a subset of
3259 what will be written for the Data Port in v1.1. As much as possible, use simple pointers to the CDS
3260 Registers Fields rather than writing more explicit rules. Differences that apply to the CDS:
3261 [HStart is a function of the current PHY: fixed at 0 in PHY1/2, programmable in PHY3]. Check
3262 whether REQ_202 through REQ_204 are the right thing for this.

168 Copyright © 2019–2024 MIPI Alliance, Inc.

3263 4. The CDS transport parameters shall have Cold Start values for:
3264 A. PHY-independent parameters according to Table 42, and
3265 B. PHY-dependent parameters according to one of:
3266 i. Table 43 when using PHY1 (FBCSE-zero-handover), or
3267 ii. Table 44 when using PHY2 (FBCSE-scheduled-handover), or
3268 iii. Table 45 when using PHY3 (DLV).
3269 5. The Manager shall program CDS transport parameters to be within the valid range shown for:
3270 A. PHY-independent parameters according to Table 42, and
3271 B. PHY-dependent parameters according to one of:
3272 i. Table 43 when using PHY1 (FBCSE-zero-handover), or
3273 ii. Table 44 when using PHY2 (FBCSE-scheduled-handover), or
3274 iii. Table 45 when using PHY3 (DLV).
3275 Table 42 Transport Parameters for Control Data Stream (PHY-independent)

Value after Value after Valid

Parameter Name Notes (informative)
Cold Start Sleep-Wake Range

CDS_BitWidth[2:0] 0 unchanged 0–7 0 => Width of 1 UI.

CDS_GuardEnable 0 unchanged 0–1 0 => no guard bit.

CDS_GuardPolarity 0 unchanged 0–1 —

CDS_EndHalfEarly 0 unchanged 0–1 0 => drive for the whole UI.

0 => special drive mode (passive 1, active

CDS_DriveType 0 unchanged 0–1 0) for logical values, i.e., before
PHY-specific encoding to physical values).

3276 Table 43 Transport Parameters for Control Data Stream (PHY1, FBCSE-zero-handover
3277 PHY)

Value after Value after Valid

Parameter Name Notes (informative)
Cold Start Sleep-Wake Range

Position of CDS is what defines

CDS_HorizontalStart[4:0] 0 unchanged 0
column 0.

CDS_TailWidth[1:0] 0 unchanged 0 0 => no tail bit(s).

3278 Table 44 Transport Parameters for Control Data Stream (PHY2,

3279 FBCSE-scheduled-handover PHY)

Value after Value after Valid

Parameter Name Notes (informative)
Cold Start Sleep-Wake Range

Position of CDS is what defines

CDS_HorizontalStart[4:0] 0 unchanged 0
column 0.

CDS_TailWidth[1:0] 0 unchanged 0–2 0 => no tail bit(s).

Copyright © 2019–2024 MIPI Alliance, Inc. 169

3280 Table 45 Transport Parameters for Control Data Stream (PHY3, DLV)

Value after Value after Valid

Parameter Name Notes (informative)
Cold Start Sleep-Wake Range

DLV PHY always has at least 1 UI

CDS_HorizontalStart[4:0] 2 unchanged 2–29
of Sync 1 and 1 UI of handover.

CDS_TailWidth[1:0] 0 unchanged 0–2 0 => no tail bit(s).

170 Copyright © 2019–2024 MIPI Alliance, Inc.

8 Command Transport Protocol

3281 This section describes the Command Transport Protocol Layer used for conveying control and status
3282 commands on a SWI3S Link. Its position with respect to other layers is illustrated in Figure 69. (The
3283 complete version of this stack is shown in Figure 15 in Section 4.4.1). The Control Data Stream is
3284 described in Section 7 and the Commands in Section 9.

SWI3S Registers
Peripheral Command
Non-SWI3S Registers (local)
Model for Registers Non-SWI3S Registers (remote)

Ping, Unblock, SSPA, ExitDormant

ReadA32, WriteA32
Commands Stream-Synchronous Commit Request (SSCR)
Device Synchronous Commit Request (DSCR)
InitCal, TrimCal

Transfers
Command Transport Phases
Protocol Elements of Phases
Bytes

8b/10b Encoding (K-Codes & D-Codes)

Control Data Stream 30-bit PHY Calibration Blocks
Bits & Symbols Undriven Bits
Idle Bits

E.g.,
Impedance,
PHY, e.g., DLV Signaling Levels,
Signal Timing.
3285
Figure 69 Layer Stack: Command Transport Protocol

Copyright © 2019–2024 MIPI Alliance, Inc. 171

8.1 Description (informative)

8.1.1 Overview of Command Transport Protocol

3286 The Command Transport Protocol conveys commands for managing the SWI3S link, the payload transport,
3287 and other functions within the Peripherals. It is layered on top of the Control Data Stream (see Section 7)
3288 that provides data encoding and a shared bidirectional transport path between the Manager and Peripherals.
3289 It transports Commands (Section 9).
3290 Figure 70 illustrates the structure within the Command Transport Protocol in more detail.

Ping, Unblock, SSPA, ExitDormant

ReadA32, WriteA32
Commands Stream-Synchronous Commit Request (SSCR)
Device Synchronous Commit Request (DSCR)
InitCal, TrimCal

Command Transport Protocol

GetStatus Transfer
Announce Transfer
Read Transfer
Transfers Write Transfer
Commit Transfer
Calibrate_PHY Transfer
GetStatus Phase
Announce Phase
ReadSetup Phase, ReadData Phase
Phases Write Phase
Commit Phase
Calibrate_PHY Phase
Start of Phase Marker
Header
Elements of Manager Packet, Peripheral Response
Phases Peripheral Packet, Manager Response
PHY_Calibration Packet
Peripheral Calibration Result
Start of Phase Marker
Robust Tokens
HD10 Robust Tokens
Bytes Normal Data Bytes
<No_Response>
30-bit PHY_Calibration Blocks

8b/10b Encoding (K-Codes & D-Codes)

Control Data Stream 30-bit PHY Calibration Blocks
Bits & Symbols Undriven Bits
Idle Bits
3291
Figure 70 Command Transport Protocol Structure and Naming

172 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.1.1 Command Transport Protocol Bytes & Symbols

3292 At the lowest level, the Command Transport Protocol Layer uses bytes encoded using the 8b/10b encoding
3293 scheme described in Section 7, and one special block of 30 bits that occupies the space equivalent to 3 of
3294 these bytes. These bytes comprise:
3295 • Start of Phase Markers (SPM, see Section 7.1.3.5 and Section 8.1.2.1), which are encoded as
3296 8b/10b control bytes using the code K.28.7.
3297 • Normal data bytes, which can have any value from 0 to 255, and are encoded as 8b/10b data bytes
3298 with code names D.x.y (see Section 7.1.3.4), and which carry either information describing the
3299 Command or data to be used by the Command. Blocks of these normal data bytes are protected by
3300 CRC values, which are also transmitted as normal data bytes.
3301 • Robust Tokens (see Section 7.1.4 and Section 8.1.12), which are encoded as one of a sparse subset
3302 of 16 of the available 8b/10b data bytes (i.e., those with codes D.x.y), and which carry information
3303 describing parts of the Command Transport Protocol that are generally interpreted as a value
3304 within a small enumeration (e.g., for PhaseId or Peripheral Response) or as a number from 0 to 15
3305 (e.g., for Packet_Length_H). Robust Tokens are not protected by CRC because the encoded
3306 8b/10b symbols are separated by a sufficient Hamming Distance.
3307 • HD10 Robust Tokens (see Section 7.1.4.1 and Section ###XREF), which are encoded as one of a
3308 special set of 2 of the Robust Tokens whose symbols are bitwise inverses of each other, so are
3309 separated by the maximum possible Hamming Distance of 10. These provide some immunity to
3310 bit errors in special circumstances when the Peripheral needs to interpret the input as being either
3311 one or the other of only 2 possible Manager Responses, and the Peripheral’s decoder identifies
3312 which one of the 2 possible values is closer (in Hamming Distance) to the received symbol.
3313 • <Protocol Spacer>, which is a 10-bit Idle Pattern (0101010101) that is the same symbol as D10.2.
3314 • <No_Response>, which is the result of the PHY (or the 8b/10b decoder in the Control Data
3315 Stream layer) determining that the 10 bits allocated to the response from a particular Peripheral
3316 have not been driven.
3317 • <PHY_Calibration_Blocks> (see Section ###XREF), which are blocks of 30 bits in the Control
3318 Data Stream that are not 8b/10b encoded symbols but are lower-level information transmitted
3319 between Peripheral and Manager for maintaining correct timing within the PHY layers.
3320 Figure 71 illustrates how these categories of bytes fit within the set of all possible 10-bit symbols:

1x SPM (2 symbols) 2x HD10 Tokens

12x K-codes (24 symbols) 16x Robust Tokens

256x D-Codes used for Normal Bytes
(440 symbols)

1x Protocol Spacer
10-bit sequences within DLV Calibration Packets
3321 1x No Response (all 1s)

Figure 71 10-bit Symbol Space for CDS

Copyright © 2019–2024 MIPI Alliance, Inc. 173

8.1.1.2 Phases
3322 Phases are a structured sequence of bytes that follow a general format shown in Figure 72. Some of the
3323 parts of this generic phase structure are not present in particular types of Phase or are conditional upon the
3324 contents of earlier parts of the Phase such as the Peripheral Response. In the special case of CalibratePhy
3325 Phases, the Peripheral Packet is replaced by a Calibration Packet, which contains a mix of bits driven by
3326 the Peripheral and by the Manager. The detailed structures for each type of Phase are described in
3327 Section 8.1.2.
3328 Note:
3329 The color coding in this figure and the other more detailed figures within this Section is:
3330 The pink or blue colored Command Transport Protocol elements are transmitted by the Manager.
3331 The grey and white striped protocol spacer is an idle period driven by the Manager to allow time for
3332 Manager, peripheral, or both to react to the preceding element.
3333 The yellow or orange colored Command Transport Protocol elements are transmitted by a
3334 Peripheral.
3335 In the special case of the Calibration Packet, the yellow parts represent bits transmitted by a
3336 Peripheral and the purple parts represent bits transmitted by the Manager.

Start of Phase Marker Start of Phase Marker

Phase Header Phase Header

(6 Bytes) (6 Bytes)

Manager Packet Manager Packet

(N Bytes) (N Bytes)

Protocol Spacer Protocol Spacer

Peripheral Response Peripheral Response
Protocol Spacer Protocol Spacer

Peripheral Packet DLV Calibration Packet

(N Bytes) (30 Bits)

Protocol Spacer Protocol Spacer

Manager Response Peripheral Cal Result
3337
Figure 72 Generic Structure of a Phase

3338 All Phases except for the Announce Phase include the opportunity for a Peripheral Response, which
3339 indicates how the Peripheral treated that Phase (see Section 8.1.2.4).
3340 The components of the Phase use different methods to facilitate detecting the effects of bit errors that
3341 occurred when transporting the Control Data Stream (i.e., errors before 8b/10b decoding):
3342 • The Phase Header, Peripheral Response, and Peripheral Calibration Result use Robust Tokens
3343 (these parts of the Phase are illustrated in the figure with a second, bold, rectangle around the
3344 name).
3345 • The Manager Response uses HD10 Robust Tokens, where the Peripheral can perform some error
3346 correction.
3347 • The Manager Packet and Peripheral Packet use normal data bytes and include a 16-bit CRC.
3348 • The Calibration Packet uses pairs of complementary bit values for the value reflected from
3349 Manager to Peripheral, but this is not primarily used for error detection (see Section ###XREF).
3350 A Phase is an indivisible object in the Command Transport Protocol: the elements that make up the Phase
3351 are never separated either by any other bytes or by any idle bits in the Control Data Stream.
3352 The Manager orchestrates the sequence of Phases in the Command Transport Protocol.
3353 The Phases used to construct each type of Transfer are shown in Table 47 in Section 8.1.1.3.

174 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.1.2.1 Peripheral Response to Phases

3354 All Phases except the Announce Phase include the opportunity for a Peripheral Response, which indicates
3355 how the Peripheral treated that Phase, including the effects on other layers within the Peripheral. For Phases
3356 that target a set of Peripherals there are slots allocated for 12 Peripheral Responses, 1 from each Peripheral
3357 that might have been selected. The detailed meanings of Peripheral Responses are described in
3358 Section 8.1.2.4, but they can be divided into three groups to summarize how the Phase ended from the
3359 perspective of the Command Transport Protocol, as shown in Table 46.
3360 Table 46 Summary of Results of a Phase
Result of
Peripheral Response Description
Phase
If there are transport errors then the Peripheral is not
confident that it received the same information that the
TRANSPORT_ERROR Manager sent.
Phase was
or The Peripheral reports the error (for cases where it can do
Ignored
<No_Response> so) but ignores the command operation described by the
Phase and does not alter any of the state in higher layers
(e.g., Transfers or Commands that are in progress).
The Command Transport Protocol Layer received the
COMMANDS_BLOCKED Command, but the Peripheral Command layer could not
COMMAND_ERROR Phase attempt to perform the operation described by the Phase.
Ended in
PROTOCOL_ERROR The Peripheral reports the error but does not attempt to
Protocol
REMOTE_ACCESS_DISABLED perform the command operation and does not alter any of
Layer
REMOTE_WRITE_BUSY the state in higher layers (e.g., Transfers or Commands
that are in progress).
WRITE_OK
WRITE_FAILED The Command Transport Protocol Layer successfully
REMOTE_WRITE_BUFFERED passed the Command to the Peripheral Command layer,
Phase which either performed, or queued up to perform, the
READ_DATA_NOW
Ended in operation described by the Phase.
READ_FAILED
Command The Peripheral Response describes how the operation
REMOTE_READ_DEFERRED Layer ended in the Command layer (e.g., success or failure) and
COMMIT_READY might update the state of higher layers (e.g., register
COMMIT_NOT_READY contents or other Transfers that are in progress).
CALIBRATE_NOW

8.1.1.3 Transfers
3361 A Transfer is the data communication mechanism in the Command Transport Protocol for moving data
3362 between the Manager and Peripheral(s). Each Transfer is comprised of 1 Phase except for a Read Transfer,
3363 which can be split over multiple Phases (see more detailed description in Section 8.1.8.1).
3364 All types of Transfer identify the Command by using a Command Opcode in the first byte of the Manager
3365 Packet. Most Transfers include further Command Info bytes in the remainder of the Manager Packet that
3366 refine the Command (e.g., a register address or a byte count).
3367 Table 47 is a summary of all of the types of Transfer.

Copyright © 2019–2024 MIPI Alliance, Inc. 175

3368 Table 47 Summary of Transfer Types

Selection Command(s)
Phase
Method that use this
Transfer Structure
(see Transfer Description
Name (and link to
Section (see
Section)
8.1.1.5) Section 9)

The Manager sends a Command to a set of

1 GetStatus some (or all) of the Peripherals, and gets
GetStatus Phase Multicast Ping back status information from each of them.
Transfer
Section 8.1.6 There is no confirmation that the Manager
has received the information.

The Manager sends a Command to a set of

Peripherals to pass information to them.
SSPA There is no response to confirm whether
1 Announce the Peripheral(s) received or understood
Announce
Phase Multicast the Command.
Transfer
Section 8.1.7
The Manager sends a Command to a set of
ExitDormant Peripherals to instruct them to exit from the
Dormant state and re-attach to the bus.

The Manager sends a read command to 1

Peripheral. Read commands request that
the Peripheral deliver 1 or more bytes of
1 ReadSetup
data to the Manager, with confirmation that
Phase and
Read the Manager has received the bytes.
0..N ReadData Directed ReadA32
Transfer The Peripheral either completes the
Phases
Transfer in a single ReadSetup Phase or,
Section 8.1.8 in some cases, can defer providing data to
a later ReadData Phase, which makes this
a multi-phase Read Transfer.

The Manager sends an Unblock Command

Unblock to 1 Peripheral to acknowledge that the
Peripheral has re-attached to the bus.

1 Write Phase The Manager sends a write Command to 1

Write
Directed Peripheral. Write Commands deliver one or
Transfer Section 8.1.9
more bytes of data to the Peripheral, with
WriteA32 confirmation of delivery of the data (and an
indication of whether the internal write
operation is guaranteed to have been
performed, or only that it is queued).

The Manager sends a commit request

SSCR Command to a set of Peripherals, and the
Commit 1 Commit Phase Peripherals each indicate their individual
Multicast and
Transfer Section 8.1.10 Response. The Manager then sends an
DSCR indication of whether it confirms or cancels
the Command.

176 Copyright © 2019–2024 MIPI Alliance, Inc.

Selection Command(s)
Phase
Method that use this
Transfer Structure
(see Transfer Description
Name (and link to
Section (see
Section)
8.1.1.5) Section 9)

The Manager sends a Calibrate Command

to 1 Peripheral. The Manager and
InitCal Peripheral co-operate in sending and
CalibratePhy 1 CalibratePhy receiving unencoded bits to support an
and
Transfer Phase Directed internal timing calibration algorithm in the
DLV_Trim_Ca Peripheral. The Peripheral then sends a
Section 8.1.11
l Calibration Result to indicate whether it
considers the result of the calibration to be
satisfactory.

8.1.1.4 Commands
3369 A Command is the operation conveyed by the Command Transport Protocol. It describes an action to be
3370 performed in the Peripheral, including parameters and then a result. Commands can be categorized as:
3371 • Basic operations for link status and control.
3372 • Read and write transactions for accessing address-mapped registers, which might map onto
3373 functional requests (e.g., reset, get, or set).
3374 • Synchronization operations for orchestrating simultaneous behavior in multiple Peripherals and/or
3375 aligned to payload streams.
3376 • Calibration operations for maintaining the correct internal adjustment of time delays
3377 (PHY-specific).
3378 Commands are described in Section 9 and the Peripheral Command Model in Section 9.1.2.

8.1.1.5 Peripheral Addressing and Device Number

3379 Each Peripheral has a Device Number which is a number in the range 0 to 11. The Device Numbers are
3380 chosen by the system integrator so that each Peripheral on a given bus segment has a different Device
3381 Number, and the Command Transport Protocol uses these Device Numbers to identify which Peripheral or
3382 Peripherals are the target of a Phase.
3383 Each Phase Header includes a Device Mask which contains 12 bits, one corresponding to each possible
3384 Device Number. This Mask identifies the selected Peripheral(s) according to the selection method shown in
3385 Table 47:
3386 • A Directed Command targets exactly 1 Peripheral.
3387 • A Multicast Command targets a set of 1 to all of the possible Peripherals.

8.1.1.5.1 Device Selection for Multicast Commands

3388 Each Peripheral examines the Device Mask field in the Phase Header to determine whether it is one of the
3389 target Peripherals for this Command.
3390 Selected: If there is a 1 in the bit corresponding to this Peripheral then it performs the operation
3391 associated with the Command and, for Phases that include Peripheral Responses, provides one
3392 Robust Token at the appropriate point in the sequence of bytes.
3393 Not selected: If there is a 0 in the bit corresponding to this Peripheral then it ignores the
3394 Command in the Manager Packet and does not generate any response anywhere in the sequence of
3395 bytes.

Copyright © 2019–2024 MIPI Alliance, Inc. 177

8.1.1.5.2 Device Selection for Directed Commands

3396 Each Peripheral examines the Device Mask field in the Phase Header to determine whether it is the target
3397 Peripheral for this Command.
3398 Selected: If the only 1 in the Device Mask is in the bit corresponding to this Peripheral then it
3399 performs the operation associated with the Command and provides a Robust Token as the
3400 Peripheral Response at the appropriate point in the sequence of bytes.
3401 Not selected: If there is a 0 in the bit corresponding to this Peripheral, or there are multiple 1s in
3402 the Device Mask, then it ignores the Command in the Manager Packet and does not generate any
3403 response anywhere in the sequence of bytes.

8.1.1.5.3 Device Number Values are Static

3404 For the Command Transport Protocol, Device Number values are considered to be static, because they are
3405 assigned before the Manager uses the Command Transport Protocol to communicate with any Peripheral,
3406 and they do not change while the Manager is communicating with the Peripherals. The method of assigning
3407 Device Numbers is implementation-defined and might be system-specific. These values might be assigned
3408 during manufacture (e.g., by programing non-volatile memory, or blowing fuses), or after power-up (e.g.,
3409 by the device sampling one or more pins to measure external voltages or resistances).
3410 Note:
3411 This contrasts with the SoundWire protocol (see [MIPI01]) where Device Numbers are assigned
3412 dynamically as part of the device enumeration process.
3413 Note:
3414 The value of Device Number is also readable in the DeviceNumber field within the device
3415 identification registers (see ###XREF to field within Table 151).

8.1.1.6 Local and Remote Addresses

3416 Some of the registers in a Peripheral are always accessible quickly enough for the Peripheral Response to
3417 give an indication of the result of an operation. These are referred to as “local registers” and accesses to
3418 them are named local writes or local reads. Local registers include all of the registers described within this
3419 Specification, and might also include some implementation-defined registers or memory.
3420 • Local reads and local writes always complete (with either success or failure) immediately in one
3421 Phase.
3422 The Peripheral might also contain some registers or memory (either implementation-defined or relating to
3423 other specifications such as SDCA, [MIPI02]), that might sometimes not be accessible quickly enough for
3424 the Peripheral Response to give a definite indication of the result of an operation. E.g., because the
3425 Peripheral design has an internal bus separating the SWI3S interface from the internal source of the data.
3426 These are referred to as “remote registers” and accesses to them are “remote writes” or “remote reads”.
3427 • Remote writes can either complete during the Write Phase, or can be buffered (see
3428 Section 8.1.14.1), for possible later completion.
3429 • Remote reads can either complete during the initial ReadSetup Phase, or can be split, with data
3430 possibly being transferred in a subsequent ReadData Phase (see Section 8.1.14.2).
3431 The Peripheral uses the register address received from the Manager (and not any different PhaseId or
3432 Opcode) to determine whether a register is local or remote.
3433 Note:
3434 All of the Peripheral registers defined within this Specification are local registers, so a Peripheral
3435 can support writing and reading these registers without implementing the optional support for
3436 buffered writes or split reads.
3437 Buffered Writes and Split Reads (for Remote Accesses) are described further in Section 8.1.14.

178 Copyright © 2019–2024 MIPI Alliance, Inc.

3438 The Peripheral Command Model and local and remote registers are illustrated in Figure 114 in
3439 Section 9.1.2.

8.1.1.7 Transport and Protocol Errors

3440 The bit error rate in the transport layer that carries the Control Data Stream is dependent upon the PHY, and
3441 can vary with implementation-defined properties both of the individual components (e.g., clock recovery
3442 jitter) and the system design (e.g., quality of the medium). The bit error rates are very low (e.g., better than
3443 10−12), but not zero, so the Control Data Stream and Command Transport Protocol Layer include several
3444 features for detecting transport bit errors, or the after-effect of these bit errors.
3445 Protocol errors might occur when Manager software or Manager or Peripheral components do not follow
3446 the specification, or when transport layer bit errors combine to create scenarios that are not detected by any
3447 of the specified mechanisms at the transport layer. The Command Transport Protocol Layer includes
3448 signaling of some protocol errors in order to make the component behavior more robust to both of these
3449 sources of errors, and to simplify system debugging.
3450 Section 8.1.16 describes categories of errors that can be detected in the transport or Command Transport
3451 Protocol Interpreter layers, such as badly encoded bytes, unexpected values of decoded bytes, or
3452 unexpected phases. These errors are counted within the Peripheral, and can generate interrupts (see
3453 ###XREF) to help with system debugging.
3454 Section 8.1.17 illustrates some example scenarios of Command Transport Protocol sequences that have
3455 been affected by bit errors, showing how the Manager and Peripheral handle their differing interpretations
3456 of what has been transmitted and received.

8.1.2 Elements of Phases

3457 Phases are a structured sequence of some or all of the following elements:
3458 • Start of Phase Marker from the Manager (see Section 8.1.2.1).
3459 • Phase Header from the Manager (see Section 8.1.2.2).
3460 • Manager Packet (see Section 8.1.2.3).
3461 • Peripheral Response (see Section 8.1.2.4).
3462 • Peripheral Multicast Response (see Section 8.1.2.5).
3463 • Peripheral Multicast Info (see Section 8.1.2.6).
3464 • Peripheral Packet (see Section 8.1.2.7).
3465 • Manager Response (see Section 8.1.2.8).
3466 • Protocol Spacer (see Section 8.1.2.9).
3467 • Calibration Packet (see Section 8.1.2.10).
3468 • Peripheral Calibration Result (see Section 8.1.2.11).
3469 Some of the parts of this generic phase sequence are not present in every type of Phase or are conditional
3470 upon other parts of the Phase such as the Peripheral Response.
3471 The detailed structure of the Phases that make up particular types of Transfers are described in
3472 Sections 8.1.6 through 8.1.11.

Copyright © 2019–2024 MIPI Alliance, Inc. 179

3473 Figure 73 illustrates the patterns for each type of Phase.

Write Phase GetStatus Phase Commit Phase Announce Phase

One Peripheral Multiple Peripherals Multiple Peripherals Multiple Peripherals
consumes data produce status receive a request to receive synchronization
information schedule a future operation information
Start of Phase Marker Start of Phase Marker Start of Phase Marker Start of Phase Marker

Phase Header Phase Header Phase Header Phase Header

Manager Packet Manager Packet Manager Packet Manager Packet

Protocol Spacer Protocol Spacer Protocol Spacer

Peripheral Response Peripheral 0..11 Peripheral 0..11
Multicast Info Multicast Response
Protocol Spacer
Manager Response

Peripheral Support for Deferred Reads is Optional

ReadSetup Phase #1 ReadSetup Phase #2 ReadSetup Phase #3 ReadData Phase #1 ReadData Phase #2
One Peripheral One Peripheral fails to One Peripheral defers One Peripheral One Peripheral fails
produces data produce data producing data until later produces data to produce data or
defers data until later
Start of Phase Marker Start of Phase Marker Start of Phase Marker Start of Phase Marker Start of Phase Marker

Phase Header Phase Header Phase Header Phase Header Phase Header

Protocol Spacer Protocol Spacer

Manager Packet Manager Packet Manager Packet Peripheral Response Peripheral Response
Protocol Spacer
Protocol Spacer Protocol Spacer Protocol Spacer
Peripheral Response Peripheral Response Peripheral Response Peripheral Packet
Protocol Spacer
Protocol Spacer
Peripheral Packet Manager Response

Protocol Spacer
Manager Response
Peripheral Support for Calibration Phase is Conditional
on which PHYs are implemented (e.g., PHY#3, DLV)

CalibratePhy Phase #1 CalibratePhy Phase #2

One Peripheral produces and One Peripheral declines to
consumes timing information produce timing information
Start of Phase Marker Start of Phase Marker

Phase Header Phase Header

Manager Packet Manager Packet

Protocol Spacer Protocol Spacer

Peripheral Response Peripheral Response
Protocol Spacer

Calibration Packet

Protocol Spacer
Peripheral Cal Result

3474
Figure 73 Phase Patterns

180 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.2.1 Start of Phase Marker

3475 At the beginning of a Phase, the Manager generates a Start of Phase Marker, which is a control byte
3476 encoded as a K.28.7 symbol. This has the property that the Control Data Stream receiver can
3477 unambiguously discover alignment of this 10-bit symbol, independently of any preceding part of the
3478 Command Transport Protocol or idle bits in the Control Data Stream. Control Data Stream synchronization
3479 is described in Section 7.1.1.2.
3480 Figure 74 illustrates the notation used for Start of Phase Markers in the diagrams of Phases.

Start of Phase Marker

3481
Figure 74 Start of Phase Marker

8.1.2.2 Phase Header

3482 The Phase Header generated by the Manager identifies which type of Phase follows and gives the transport
3483 layer in the Peripheral sufficient information to know where in the sequence of bytes is the slot for its
3484 Peripheral Response. All bytes in a Phase Header are transported using Robust Tokens (see Section 7.1.4
3485 and Section 8.1.12). The mappings of the Robust Token Number to Phase Header field values are specified
3486 in Table 63 and described in Section 8.1.12.1.
3487 Figure 75 shows the Phase Header.

PhaseID: ...
Device Mask_H
Device Mask_M
Device Mask_L
Packet_Length_H
Packet_Length_L
3488
Figure 75 Phase Header

3489 PhaseID: 1 Robust Token that identifies the type of Phase (and hence the type of Transfer). Table 47
3490 summarizes how the various types of Phase are used for the Transfers for each Command.
3491 Device_Mask: 3 Robust Tokens that identify the set of Peripherals that is targeted by this Phase. Each part
3492 of the Device Mask is derived from 4 bits of the Robust Token Number (see Table 63), and the 3 parts are
3493 combined to form a 12-bit mask (most significant 4 bits from the first Robust Token, next 4 bits from the
3494 second token, and the least significant 4 bits from the third Robust Token). Each bit in this mask
3495 corresponds to one Peripheral, with a bit set to 1 indicating that the corresponding Peripheral is included in
3496 the set that is addressed by this Command.
3497 Note:
3498 The Device Mask for Write, ReadSetup, ReadData, and CalibratePhy Phases always selects
3499 exactly 1 Device.
3500 Packet_Length: 2 Robust Tokens which describe the length of the following Manager Packet (excluding
3501 the Manager_CRC bytes). Each half of the Packet Body Length is derived from the 4 bits of the Robust
3502 Token Number (see Table 63), and the two halves are combined to form an 8-bit count (most significant
3503 4 bits from the first Robust Token, least significant 4 bits from the second Robust Token).
3504 Note:
3505 Packet_Length==0 indicates that there is no Manager Packet in this Phase (e.g., in ReadData
3506 Phases), and hence also no Manager_CRC.

Copyright © 2019–2024 MIPI Alliance, Inc. 181

8.1.2.3 Manager Packet

3507 The Manager Packet contains the Command Opcode byte which identifies the Command (see Table 95)
3508 sometimes followed by further command information bytes (e.g., write or read address, byte count, row
3509 delay) and command data bytes (e.g., write data) associated with the Command. The Command Transport
3510 Protocol decoder determines how to interpret the contents of the Manager Packet from the Transfer Type
3511 (indicated by the PhaseID) and from some of the bytes of the Manager Packet (e.g., the Command Opcode
3512 in the first byte, or a byte count that indicates how many data bytes follow the Command Info). The length
3513 and content of the Manager Packet that describes the Command is specific to the Command Opcode.
3514 All bytes of the Manager Packet are transported as 8b/10b Normal data bytes (i.e., not Robust Tokens), see
3515 Section 8.1.1.1. The last two bytes of the Manager Packet contain a 16-bit CRC for the bytes in the packet.
3516 The CRC algorithm is described in Section 8.1.13. In the figures in this section, the Command information
3517 bytes and the Command data bytes are shown colored differently (blue and green respectively), but this is
3518 solely for the purposes of illustration: they are all part of one Manager Packet and are all covered by one
3519 CRC.
3520 The Manager Packet is present in all types of Phase except for the ReadData Phase (where this absence is
3521 indicated by the Packet_Length being 0x00). The number of bytes in a Manager Packet is described
3522 explicitly by the Packet_Length fields, and this byte count identifies where the transport layer will then
3523 look for the two CRC bytes to be checked. If the CRC passes OK, then the Transport is considered to be
3524 free of errors. If the Command Transport Protocol interpreter subsequently finds problems with the
3525 Command information (e.g., describing a Command that would have needed a smaller or larger Manager
3526 Packet), then this is a Command Error rather than a Transport Error. These Peripheral Responses are
3527 described in Section 8.1.2.4.
3528 Figure 76 illustrates the general format of Manager Packets.
Packet_Length

Command Opcode Command Opcode

Command Info Command Info Packet_Length
... ...
... ...
Manager_CRC16_H Command Data
Manager_CRC16_L ...
...
...
Manager_CRC16_H
Manager_CRC16_L
3529
Figure 76 Manager Packets

182 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.2.4 Peripheral Response

3530 The Peripheral Response is transported using a Robust Token (see Section 7.1.4 and Section 8.1.12). The
3531 mapping of the Robust Token Number to Peripheral Responses is specified in Table 64. The Peripheral
3532 Response is used to indicate status and error conditions at several levels:
3533 Did the transport fail?
3534 • Bad 8b/10b symbols.
3535 • CRC errors.
3536 Is the Peripheral blocked from executing Commands?
3537 • Peripheral detached from & reattached to the bus.
3538 Was the protocol followed?
3539 • Phase not following the expected sequence, e.g., ReadData Phase when there is no Split Read
3540 Transfer in progress.
3541 What happened at the Command layer?
3542 • Unsupported Command.
3543 • No capacity to perform a remote write/read at this time.
3544 • The Peripheral is currently restricted from writing/reading remote addresses.
3545 • Command operation failed.
3546 • Peripheral not yet ready to provide read data.
3547 • Command accepted OK.
3548 Figure 77 illustrates the symbols used for Peripheral Responses in the figures in this Section (8).

Peripheral Responses when Peripheral Responses when Peripheral Responses when

Phase transport failed Phase transport was OK, Phase transport was OK,
but the Phase terminated and the Phase terminated
abnormally normally
TRANSPORT_ERROR COMMANDS_BLOCKED WRITE_OK

WRITE_FAILED
Peripheral: No Response COMMAND_ERROR
REMOTE_WRITE_BUFFERED

PROTOCOL_ERROR
READ_DATA_NOW

REMOTE_ACCE SS_DISABLED READ_FAILED

REMOTE_WRITE_BUSY REMOTE_READ_DE FE RRED

CALIBRATE_NOW

COMMIT_READY

COMMIT_NOT_READY
3549
Figure 77 Peripheral Responses

3550 Peripheral Responses are described in more detail in Section 8.1.4.

Copyright © 2019–2024 MIPI Alliance, Inc. 183

8.1.2.5 Peripheral Response to Multicast Commit Phases

3551 In the case of a multicast Commit Phase (see Section 8.1.10.1), the Peripheral Response section of the
3552 Phase is comprised of slots for 12 successive Peripheral Responses, one from each of the Peripheral Device
3553 Numbers that can exist on the bus.
3554 In Figure 78, the left column illustrates the general form of the Peripheral Response section of a multicast
3555 Commit Phase. The right column shows an example in which some of the Peripheral Response slots do not
3556 contain a valid response from a Peripheral. This might be expected by the Manager (when the
3557 corresponding Device Number is not selected in the Device Mask) or unexpected (e.g., when a selected
3558 Peripheral is no longer attached to the bus or has chosen not to generate a response because a transport
3559 error in the Header meant that it did not know when to generate the response).

Peripheral Responses in a Example Where Some

Multicast Commit Phase Slots Have No Response
Peripheral 0 Response Peripheral: No Response
Peripheral 1 Response Peripheral: No Response
Peripheral 2 Response Peripheral 2 Response

Peripheral 3 Response Peripheral 3 Response

Peripheral 4 Response Peripheral 4 Response
Peripheral 5 Response Peripheral 5 Response
Peripheral 6 Response Peripheral: No Response
Peripheral 7 Response Peripheral: No Response

Peripheral 8 Response Peripheral: No Response

Peripheral 9 Response Peripheral: No Response
Peripheral 10 Response Peripheral 10 Response

Peripheral 11 Response Peripheral: No Response

3560
Figure 78 Peripheral Responses to a Multicast Commit Phase

184 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.2.6 Peripheral Multicast Info

3561 The Peripheral Multicast Info section of a GetStatus Phase is comprised of slots for 12 successive
3562 Peripheral Info Robust Tokens, one from each of the Peripheral DeviceNumbers that might exist on the bus.
3563 3 Robust Tokens are assigned to reporting error conditions within the Command Transport Protocol
3564 (commands blocked, transport error, or command error), and the remaining 13 Robust Tokens are either
3565 reserved or assigned to reporting the status of the Peripheral (see Section 8.1.12.1).
3566 The source and meaning of the value in the Peripheral Info field is a function of the Command that is
3567 transported by the GetStatus Transfer (e.g., see Ping Command in Section 9.1.5).
3568 In Figure 79, the left column illustrates the general form of the Peripheral Multicast Info section of a
3569 GetStatus Phase. The right column shows an example in which some of the Peripheral Info slots do not
3570 contain a valid response from a Peripheral. This might be expected by the Manager (when the
3571 corresponding DeviceNumber is not selected in the Device Mask) or unexpected (e.g., when a selected
3572 Peripheral is no longer attached to the bus, or has chosen not to generate a response because a transport
3573 error in the Header meant that it did not know when to generate the response).

Peripheral Info Example Where Some

in GetStatus Phase Slots Have No Response
Peripheral 0 Info Peripheral 0 Info
Peripheral 1 Info Peripheral: No Response

Peripheral 2 Info Peripheral 2 Info

Peripheral 3 Info Peripheral 3 Info
Peripheral 4 Info Peripheral 4 Info
Peripheral 5 Info Peripheral 5 Info
Peripheral 6 Info Peripheral: No Response

Peripheral 7 Info Peripheral: No Response

Peripheral 8 Info Peripheral: No Response

Peripheral 9 Info Peripheral: No Response

Peripheral 10 Info Peripheral: No Response

Peripheral 11 Info Peripheral 11 Info

3574
Figure 79 Peripheral Multicast Info in GetStatus Phase

Copyright © 2019–2024 MIPI Alliance, Inc. 185

8.1.2.7 Peripheral Packet

3575 The Peripheral Packet contains data produced as the result of the Command in a Read Transfer and can
3576 appear in either a ReadSetup or a ReadData Phase.
3577 All bytes of the Peripheral Packet are transported as 8b/10b Normal data bytes (i.e., not Robust Tokens),
3578 see Section 8.1.1.1. The last two bytes of the Peripheral Packet contain a 16-bit CRC for the bytes in the
3579 packet. The CRC algorithm is described in Section 8.1.13.
3580 The number of bytes in the Peripheral packet is determined from Command Information in the ReadSetup
3581 Phase that initiated the Command, and this length-defining information is not repeated in any subsequent
3582 ReadData Phase(s) that the Manager might issue (see multi-phase Read Transfers in Section 8.1.8.1).
3583 Figure 80 illustrates the general format of Peripheral Packets.

Peripheral Data
...
...
...
Peripheral_CRC16_H
Peripheral_CRC16_L
3584
Figure 80 Peripheral Packet

186 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.2.8 Manager Response

3585 The Manager Response is transported using a Robust Token (see Section 7.1.4 and Section 8.1.12). The
3586 mapping of the Robust Token Number to Manager Responses is described in Table 63. The Manager
3587 Response is used to indicate status and error conditions at several levels:
3588 Did the transport fail?
3589 • Bad 8b/10b symbols.
3590 • CRC errors.
3591 What happened in the Command layer?
3592 • In Read Transfers: Did the Manager successfully receive read data from the Peripheral.
3593 • In Commit Transfers: After receiving responses from the Peripheral(s), did the Manager choose to
3594 confirm or to cancel the commit operation that was proposed.
3595 The Manager Response is used by the Manager to indicate whether it considers the Transfer to be
3596 completed successfully or not, or (for Read Transfers) possibly still pending.
3597 The Manager Responses are encoded using Robust Tokens (see Section 7.1.4 and Section 8.1.12). The
3598 mapping of the Robust Token Number to Manager Responses is described in Table 64.
3599 Figure 81 illustrates the possible Manager Responses.

Manager Responses to Manager Responses to

Commit Phase ReadSetup and
ReadData Phases
CONFIRM_COMMIT READ_DATA_OK

CANCEL_COMMIT READ_DATA_ERROR
3600
Figure 81 Manager Responses

3601 Manager Responses are described in more detail in Section 8.1.5.

8.1.2.9 Protocol Spacer

3602 The Protocol Spacer is a block of 10 CDS bits driven by the Manager at defined places within the sequence
3603 of a Phase to provide time for the Peripheral or Manager to calculate a reaction to the previous part of the
3604 Phase.
3605 A Protocol Spacer comprises a 10-bit idle sequence, i.e., “0101010101” (see Section 7.1.1.3), which is
3606 equivalent to a D10.2 symbol in the 8b10b encoding. The Peripheral does not check the bit pattern within a
3607 Protocol Spacer, but does continue to search for SPM during these CDS bits.
3608 Figure 82 illustrates the symbol used for the Protocol Spacer in Phase diagrams.

Protocol Spacer
3609
Figure 82 Protocol Spacer

Copyright © 2019–2024 MIPI Alliance, Inc. 187

8.1.2.10 Calibration Packet

3610 The Calibration Packet is a block of 30 bits on consecutive Rows (so these are consecutive in the Control
3611 Data Stream, but not consecutive in the bitstream on the bus). These bits are not encoded using
3612 8b10b-encoding. The structure is 10 sets of 3 bits, with each set of 3 bits representing 1 Calibration
3613 measurement. Each Calibration measurement comprises a 0 sent from the Peripheral to the Manager
3614 (shown in yellow), followed by a 2-bit response from the Manager to the Peripheral in which the bits are
3615 always complementary, i.e., either 01 or 10 (shown in purple).
3616 Figure 83 illustrates the general format of Calibration Packets.

0 RR 0 RR 0 RR 0

Calibration Packet
RR 0 RR 0 RR 0 R

Length
R 0 RR 0 RR 0 RR
...
Total of (N + 1) blocks
of 3 x10 bits
...
3617
Figure 83 Calibration Packet
3618 Note:
3619 This figure illustrates only the CDS bits: on the bus these are spread out to 1 bit per Row, and
3620 typically separated by many payload data bits.

8.1.2.11 Peripheral Calibration Result

3621 The Peripheral Calibration Result is transported using a Robust Token (see Section 7.1.4 and
3622 Section 8.1.12). The mapping of the Robust Token Number to Peripheral Calibration Results is described in
3623 Table 64.
3624 Figure 84 illustrates the symbols used for Peripheral Calibration Results in the figures in this Section (8).

PHY_CAL_GOOD

PHY_CAL_FAILED

TRANSPORT_ERROR
3625
Figure 84 Peripheral Calibration Results

188 Copyright © 2019–2024 MIPI Alliance, Inc.

3626 ###TODO-Author: maybe move this table to the Calibration Command in Section 9.2.10.

3627 Table 48 Summary of Peripheral Calibration Result

Peripheral Condition That
Name of Response Typical Manager Behavior
Provokes This Response
Mismatched Data in the Manager
part of the Calibration Block (i.e., Check PHY settings and/or retry
TRANSPORT_ERROR
R and not-R were not calibration.
complementary).
The Peripheral Calibration
Retry calibration with a larger
PHY_CAL_FAILED algorithm did not converge (see
iteration count.
Section 9.2.10.
Examine the peripheral signal
The Peripheral Calibration
timing during the evaluation
PHY_CAL_GOOD algorithm converged (see
phase to determine the quality
Section 9.2.10).
of calibration.

3628

8.1.3 Phase Flowcharts

3629 This Section (8.1.3) includes informative flowcharts illustrating the logical flow in each of the Manager and
3630 Peripheral processing the Phases that make up the Command Transport Protocol. Where possible, the
3631 corresponding Manager and Peripheral flows are presented side by side in the same figure. The normative
3632 behavior of Manager and Peripheral is specified in Section 8.2.4 and Section 8.2.3, respectively.
3633 Table 49 is a simple index relating PhaseID and Command to the relevant flowchart figure(s).
3634 Table 49 Index to Phase Flowcharts
Manager Peripheral
PhaseID Command
Flowchart Flowchart
Start of All Phases (when Peripheral is Attached) Figure 86 Figure 87
All Phases (when Peripheral is in Dormant State) — Figure 88
GetStatus Ping Figure 89
Announce SSPA, ExitDormant [1] Figure 90
Commit SSCR, DSCR [1] Figure 91
Unblock Figure 92
Write WriteA32 (Local Address) Figure 93
WriteA32 (Remote Address) [1] Figure 96
ReadSetup ReadA32 (Local Address) Figure 94
ReadSetup & ReadData [2] ReadA32 (Remote Address) [1] Figure 97 Figure 98
CalibratePhy [2] InitCal [1], TrimCal [1] Figure 95
3635 Notes:
1. Optional Command.
2. Optional PhaseID.

Copyright © 2019–2024 MIPI Alliance, Inc. 189

8.1.3.1 Flowchart Notation

3636 The following diagram conventions are used in the flowcharts, and are illustrated in Figure 85.
3637 • Colored rectangles represent protocol bytes that are inputs to the Manager or Peripheral, and
3638 colored parallelograms represent protocol bytes that are outputs. The colors for both the input and
3639 output shapes match those used in the descriptions of the protocol elements in Section 8.1.2 and
3640 elsewhere in this Specification (and illustrated in the leftmost column in Figure 85).
3641 • White rectangles represent other processing or actions in the Manager or Peripheral; the actions in
3642 red text are offline, i.e., they are decoupled from the timing of the protocol signaling.
3643 • Green downward pointing shapes and matching rounded rectangles represent connections to a
3644 continuation of the flowchart (in a diagram specific to one Phase type). Pink shapes connected by
3645 dotted lines represent signaling from one state machine to another.

Protocol Elements Symbols in Symbols in Miscellaneous

in Phase Diagrams Manager Flowcharts Peripheral Flowcharts
Manager to Peripheral Signal from one Peripheral state machine to
Start of Phase Marker
Send: Restart Header another
SPM Detector
Start New Phase
Send:
Header Byte Phase Header Get Header
(6 robust tokens) Restart
(6 robust tokens)
Header Detector

Manager Byte Send: Get Manager Packet

Manager Packet & CRC
Manager CRC Byte & CRC (N+2 normal bytes) Continuation of flowchart in another figure
(N+2 Normal bytes)

PHASE NAME
Protocol Spacer Send Protocol Spacer Skip over Protocol Spacer to continuation

Send Manager Response: Get Manager

Manager Response: RESPONSE_NAME Response (HD10) Phase Name
continuation

Peripheral to Manager
Get
Peripheral behavior Peripheral behavior
Peripheral Byte Send Peripheral Packet:
Peripheral Packet & Read data & CRC during this phase after this phase
Peripheral CRC Byte CRC
Processing step Processing step
Get Send Peripheral Response:
Peripheral Response RESPONSE_NAME
Peripheral Response
Decision Decision
Peripheral Response
Get 12 x
Peripheral Response
Peripheral Response
Peripheral Response End of Phase End of Command

Peripheral PingInfo[3..0]
Get 12 x Send Peripheral Info:
Peripheral PingInfo[3..0] PING_INFO Multi-way branch based on inputs
Peripheral Info
Peripheral PingInfo[3..0]

PhaseID
Peripheral Cal Result GetCalibration Result Send Calibration Result Command
& Address

Peripheral to Manager followed by Manager to Peripheral

DLV Calibration Block Receive / Send Send / Receive

(30 Bits) Calibration Block Calibration Block
3646
Figure 85 Key to Command Transport Protocol Flowcharts

190 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.3.2 Protocol Flow Common to All Phases (Manager)

3647 Figure 86 shows the protocol flow in the Manager that is common to all Phases. The green downward
3648 pointing shapes show where the phase-specific parts of the flow are continued on later figures.
3649 Note:
3650 Write Phases and Read Phases are continued on multiple phase-specific diagrams because the
3651 protocol flow varies with the Opcode (WriteA32 vs. Unblock) or the address (Local vs. Remote).

Manager Flow
(common to all Phases)
(runs continuously)

START

Ready to No Generate Idle pattern:

Start New Phase? Idle 0-1

Yes

Send:
SPM

Send:
Phase Header
(6 robust tokens)

PhaseID

ANNOUNCE GET_STATUS READ_SETUP READ_DATA

COMMIT WRITE
CALIBRATE_PHY
Optional (for remote addresses)
Send: Send: Send:
Manager Packet Manager Packet Manager Packet
& CRC & CRC & CRC
(N+2 Normal bytes) (N+2 Normal bytes) N = Packet_Length (N+2 Normal bytes)
from Header
Send Protocol Spacer Send Protocol Spacer Send Protocol Spacer

Get Get
PhaseID Peripheral Response Peripheral Response

ANNOUNCE GET_STATUS COMMIT Peripheral Peripheral

Response == Yes Response == Yes
COMMANDS_BLOCKED? End of Phase COMMANDS_BLOCKED? End of Phase

No No

Peripheral Peripheral
Response == Yes Response == Yes
End of Phase End of Phase
TRANSPORT_ERROR? PROTOCOL_ERROR?

No No

Peripheral
Response == Yes
End of Phase
COMMAND_ERROR?

PhaseID
Command
& Address

CALIBRATE_PHY WRITE WRITE READ_SETUP WRITE READ_SETUP READ_DATA

(unblock) local address local address remote address remote address remote address

3652
Figure 86 Protocol Flowchart: Common to All Phases (Manager)

Copyright © 2019–2024 MIPI Alliance, Inc. 191

8.1.3.3 Protocol Flow Common to All Phases (Peripheral)

3653 ###TODO-Author: add something to Figure 87 to show that the Peripheral does not count 8b10b
3654 errors in the Peripheral SPM Detector or Peripheral Header Detector, only in the “Peripheral Flow”
3655 part of this diagram.
3656 Figure 87 shows the protocol flow in the Peripheral that is common to all Phases. The green downward
3657 pointing shapes show where the phase-specific parts of the flow are continued on later figures. The generic
3658 Peripheral Responses shown in this figure are specified in Table 78.
3659 Note:
3660 Write Phases and Read Phases are continued on multiple phase-specific diagrams because the
3661 protocol flow varies with the Opcode (WriteA32 vs. Unblock) or the address (Local vs. Remote).

Peripheral
SPM Detector
(runs continuously)

Cold Reset or
Warm Reset

Peripheral
This Peripheral drove
previous CDS bit
Get first 9 CDS bits Header Detector
(restarts from here whenever the
SPM Detector indicates an SPM)
Restart Header
Get next CDS bit
Detector

Get Header
Most recent No (6 robust tokens)
10 bits
== SPM?

The checks on the Header include:

Yes • Bad Robust Tokens
Errors or Yes • Reserved PhaseID
• Unimplemented PhaseID
Invalid Header?
• Unexpected non-zero Packet_Length (ReadData Phases)
• Unexpected zero Packet_Length (all other Phases)
SPM Detected
Stop
No
Restart
Header Detector
No
Is this Device Selected? Device selection includes checking for:
• Multiple devices selected in a 1-device Phase

Stop Peripheral Flow

Yes
(common to all Phases)
Is the Peripheral in Critical Region of the Commit or
Yes (restarts from here whenever the Header
Get_Status Phase is between the valid
Critical Region of a Commit or
Manager CRC and the end of the Phase. Detector indicates Start New Phase)
GetStatus Phase? (see orange star, below).

Stop Start New Phase

Restart the Command

Confidence WatchDog

Is this a Yes
ReadData Phase?

Start New Phase

Get Manager Packet SPM detected

Stop & CRC
N = Packet_Length (N+2 normal bytes)
from Header

End of Phase

Yes Is this an Announce

Phase?

Skip over Protocol Spacer

Is this a Commit or Yes
GetStatus Phase? Start of Critical Region

(If there was no Transport Error in the Manager

Packet and the CRC was OK then after this
No point this Phase cannot be pre-empted by a
new Valid Phase Header)

Skip over 0– slots

for Responses from
other Peripherals
Optional (for remote addresses)

Yes Commands are Yes Commands are Commands are Yes Send Peripheral Response:

blocked? blocked? blocked? COMMANDS_BLOCKED

End of Phase
No No No End of Phase

i.e., Bit Error or CRC Error

Yes Transport Error in Transport Error in Yes Send Peripheral Response:
Transport Error in Yes Send Peripheral Response:
Manager Packet? Manager Packet? COMMANDS_BLOCKED Manager Packet? TRANSPORT_ERROR
(includes CRC error) (includes CRC error) (includes CRC error)

End of Phase
No No End of Phase No End of Phase

Yes Bad Command Info? Bad Command Info? Yes Send Peripheral Response: Bad Command Info? Yes Send Peripheral Response:
(e.g., Bad Opcode (e.g., Wrong Packet Length COMMANDS_BLOCKED (e.g., Bad Opcode COMMAND_ERROR
for this PhaseID) for Write(Unblock)) for this PhaseID)

End of Phase
No No End of Phase No End of Phase

Write Phase and No Send Peripheral Response:

Unblock Opcode? COMMANDS_BLOCKED

End of Phase
Yes

PhaseID
Command
& Address

ANNOUNCE WRITE GET_STATUS COMMIT CALIBRATE_PHY WRITE READ_SETUP WRITE READ_SETUP READ_DATA
(ExitDormant, (Unblock) (Ping) (SSCR / DSCR) local address local address remote address remote address

3662
SSPA)

Figure 87 Protocol Flowchart: Common to All Phases (Peripheral)

192 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.3.4 Protocol Flow for Phases when Peripheral is in Link State: Dormant
3663 Figure 88 shows the protocol flow for all PhaseIDs when the Peripheral is in the (optional) Link State:
3664 Dormant (see Figure 60). This flowchart follows on from the Peripheral Header Detector shown in
3665 Figure 87.

Peripheral Flow when in

Link State: Dormant
(common to all Phases)
(restarts from here whenever the Header
Detector indicates Start New Phase)

Start New Phase

Is this an No
Announce Phase?

End of Phase
Yes

Get Manager Packet SPM detected

& CRC
N = Packet_Length (N+2 normal bytes)
from Header

End of Phase

Transport Error in Yes

Manager Packet?
(includes CRC error)
End of Phase
No

Bad Command Info? Yes

(e.g., Bad Opcode
for this PhaseID)
End of Phase
No

Is this an No
Exit_Dormant
Command?
End of Phase
Yes

Start change of Link State

from Dormant to Syncing
(e.g., restart DLV Tx voltage)

End of Phase
3666
Figure 88 Protocol Flowchart: Peripheral in Link State: Dormant

Copyright © 2019–2024 MIPI Alliance, Inc. 193

8.1.3.5 Protocol Flow for GetStatus Phase (Ping Command)

3667 Figure 89 shows the protocol flow in the Manager and Peripheral for a Ping Phase. These flowcharts
3668 follow on from the generic Manager and Peripheral flow shown in Figure 86 and Figure 87. The
3669 Peripheral Responses shown in this figure are specified in normative Table 87.

Manager Peripheral
GET_STATUS GET_STATUS

Get 12 x Send Peripheral Info:

Peripheral Info PING_INFO

End of Phase End of Phase

3670
Figure 89 Protocol Flowchart: GetStatus Phase (Ping Command)

8.1.3.6 Protocol Flow for Announce Phase (SSPA & ExitDormant Commands)
3671 Figure 90 shows the protocol flow in the Manager and Peripheral for an Announce Phase. These flowcharts
3672 follow on from the generic Manager and Peripheral flow shown in Figure 86 and Figure 87.
3673 Note:
3674 This figure shows that a Peripheral in Link State: Attached can process an ExitDormant Command
3675 without error, but the ExitDormant Command is normally used when a Peripheral is in Link State:
3676 Dormant, for which the protocol flow is illustrated in Figure 88.

Manager Peripheral
ANNOUNCE ANNOUNCE

ExitDormant SSPA ExitDormant SSPA

Command
Command

Schedule the internal Skip Rows to Sync Point Skip Rows to Sync Point
Schedule the internal
SSP Event (Command:Row_Delay) (Command:Row_Delay –
SSP Event
SyncPointOffset register)

End of Phase End of Phase End of Phase End of Phase

Do SSP operation on Do SSP operation on
selected commit groups selected commit groups

End of Command
3677 End of Command

Figure 90 Protocol Flowchart: Announce Phase (SSPA & ExitDormant)

194 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.3.7 Protocol Flow for Commit Phase

3678 Figure 91 shows the protocol flow in the Manager and Peripheral for a Commit Phase. These flowcharts
3679 follow on from the generic Manager and Peripheral flow shown in Figure 86 and Figure 87. The
3680 Peripheral Responses shown in this figure are specified in normative Table 84, and the Manager Responses
3681 in normative Table 90.

Manager Peripheral
COMMIT COMMIT

Ready to accept No
a Commit now?

Yes
Get 12 x Send Peripheral Response: Send Peripheral Response:

Peripheral Response COMMIT_READY COMMIT_NOT_READY

Skip over 0– slots

for Responses from
other Peripherals

Send Protocol Spacer Skip over Protocol Spacer

Manager decides No
whether to proceed

Yes

Send Manager Response: Send Manager Response: Get Manager

CONFIRM_COMMIT CANCEL_COMMIT Response (HD10)

(Nearest HD10) CANCEL_COMMIT

Manager Response

End of Phase End of Phase

CONFIRM_COMMIT

Skip Rows to Sync Point

Schedule the internal Skip Rows to Sync Point Schedule the internal
(Command:RowDelay
Commit / SSP Event(s) (Command:RowDelay) Commit / SSP Event(s)
SyncPointOffset register)

End of Phase Do scheduled Commit Event End of Phase Do scheduled Commit Event
and SSP Event (only for SSCR) and SSP Event (only for SSCR)
on selected commit groups on selected commit groups

End of Command End of Command

3682
Figure 91 Protocol Flowchart: Commit Phase

Copyright © 2019–2024 MIPI Alliance, Inc. 195

8.1.3.8 Protocol Flow for Write Phase (Unblock Command)

3683 Figure 92 shows the protocol flow in the Manager and Peripheral for a Write Phase that contains an
3684 Unblock Command. These flowcharts follow on from the generic Manager and Peripheral flow shown in
3685 Figure 86 and Figure 87. The Peripheral Responses shown in this figure are specified in normative
3686 Table 80.

Manager Peripheral
Unblock WRITE Unblock WRITE

Bad Robust Token Yes i.e., Bit Error

Transport Error in
Peripheral Response?

End of Phase
No

Peripheral Unexpected Response Send Peripheral Response:

Invisible white box
Response WRITE_OK

WRITE_OK Clear the

Commands_blocked bit

End of Phase End of Phase End of Phase

3687
Figure 92 Protocol Flowchart: Write Phase (Unblock Command)

8.1.3.9 Protocol Flow for Write Phase (Local WriteA32 Command)

3688 Figure 93 shows the protocol flow in the Manager and Peripheral for a Local Write Phase (i.e., one where
3689 the address is Local, see Section ###XREF). These flowcharts follow on from the generic Manager and
3690 Peripheral flow shown in Figure 86 and Figure 87. The Peripheral Responses shown in this figure are
3691 specified in normative Table 81.

Manager Peripheral
Local WRITE Local WRITE

Bad Robust Token Yes i.e., Bit Error Yes

Did the Write
Transport Error in
Peripheral Response?
operation fail?

End of Phase
No No

WRITE_FAILED or
Peripheral Unexpected Response Send Peripheral Response: Send Peripheral Response:

Response WRITE_OK WRITE_FAILED

WRITE_OK

End of Phase End of Phase End of Phase End of Phase

3692
Figure 93 Protocol Flowchart: Write Phase (Local WriteA32 Command)

196 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.3.10 Protocol Flow for Local ReadSetup Phase

3693 Figure 94 shows the protocol flow in the Manager and Peripheral for a Local ReadSetup Phase (i.e., one
3694 where the address is Local, see Section Note:). These flowcharts follow on from the generic Manager and
3695 Peripheral flow shown in Figure 86 and Figure 87. The Peripheral Responses shown in this figure are
3696 specified in normative ###XREF, and the Manager Responses in normative ###XREF.

Manager Peripheral
READ_SETUP READ_SETUP
(local address) (local address)

Peripheral
Yes Did the read Yes
Response == End of Phase
Send Peripheral Response:

READ_FAILED? operation fail? READ_FAILED

No No End of Phase

i.e., Bit Error or

Peripheral
No Unexpected Response Send Peripheral Response:
Response == READ_DATA_NOW
READ_DATA_NOW?

Yes

Send Protocol Spacer Send Protocol Spacer Skip over Protocol Spacer

Get Skip space for Send Peripheral Packet:

Peripheral Packet & Peripheral Packet & Read data & CRC
CRC CRC

Send Protocol Spacer Send Protocol Spacer Skip over Protocol Spacer

Transport Error Yes

in Peripheral Packet
or CRC?

Fail
Check CRC

Pass

Send Manager Response: Send Manager Response: Send Manager Response: Get Manager
READ_DATA_OK READ_DATA_ERROR READ_DATA_ERROR Response (HD10)

End of Phase End of Phase End of Phase

(Nearest HD10) READ_DATA_ERROR
Manager Response

READ_DATA_OK

Enact any side effects (discard the

(e.g., arming IntClear) read data)

End of Phase End of Phase

3697
Figure 94 Protocol Flowchart: ReadSetup Phase (Local ReadA32 Command)

Copyright © 2019–2024 MIPI Alliance, Inc. 197

8.1.3.11 Protocol Flow for CalibratePhy Phase

3698 Figure 95 shows the protocol flow in the Manager and Peripheral for a CalibratePhy Phase. These
3699 flowcharts follow on from the generic Manager and Peripheral flow shown in Figure 86 and Figure 87.
3700 The Peripheral Responses shown in this figure are specified in normative Table 85 and the Peripheral
3701 Calibration Results in normative Table 86.

Manager Peripheral
CALIBRATE_PHY CALIBRATE_PHY

i.e., Bit Error or

Peripheral
No Unexpected Response
Response== Send Peripheral Response:

CALIBRATE_NOW? CALIBRATE_NOW

Yes
Send Protocol Spacer Send Protocol Spacer Skip over Protocol Spacer

Receive / Send Skip space for Send / Receive

Calibration Block Calibration Block Calibration Block

Send Protocol Spacer Send Protocol Spacer Skip over Protocol Spacer

Skip space for

GetCalibration Result Send Calibration Result
Calibration Result

End of Phase

Bad Robust Token Yes i.e., Bit Error

Transport Error?

End of Phase
No

TRANSPORT_ERROR or
PHY_CAL_FAILED Peripheral Unexpected Robust Token
Calibration Result?

PHY_CAL_GOOD

End of Phase End of Phase End of Phase End of Phase

3702
Figure 95 Protocol Flowchart: CalibratePhy Phase

198 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.3.12 Protocol Flow for Remote Write Phase

3703 Figure 96 shows the protocol flow in the Manager and Peripheral for a Remote Write Phase (i.e., one
3704 where the address is Remote, see Section Note:). These flowcharts follow on from the generic Manager and
3705 Peripheral flow shown in Figure 86 and Figure 87. The Peripheral Responses shown in this figure are
3706 specified in normative Table 81.
3707 Note:
3708 In the Manager the Remote Write Phase is effectively the same as the Local Write Phase shown in
3709 Figure 93, but is repeated here to be adjacent to the corresponding Peripheral Remote Write
3710 Phase.

Peripheral Peripheral Manager

Local WRITE Remote WRITE Remote WRITE

RemoteOpState = Yes Send Peripheral Response:

RemoteDisabled? REMOTE_ACCESS_DISABLED

No End of Phase Bad Robust Token Yes i.e., Bit Error

Transport Error in
Peripheral Response?

RemoteOpState = Yes Send Peripheral Response: No End of Phase

RemoteWriteBusy? REMOTE_WRITE_BUSY

No End of Phase

Any incomplete previously Peripheral

deferred read is discarded WRITE_BUFFERED Response? WRITE_FAILED or
REMOTE_WRITE_BUSY or
REMOTE_ACCESS_DISABLED or
WRITE_OK Unexpected Response

Write Command Yes Send Peripheral Response:

buffered for WRITE_BUFFERED End of Phase End of Phase End of Phase
later execution?

No
Set RemoteOpState = Buffered Write completes
RemoteWriteBusy some time later

End of Phase

Did the Write Yes Did the Write Yes Did the Write Yes
operation fail? operation fail? operation fail?

No No No

Send Peripheral Response: Send Peripheral Response: Send Peripheral Response: Send Peripheral Response:
WRITE_OK WRITE_FAILED WRITE_OK WRITE_FAILED

Set RemoteOpState = Set RemoteOpState = Set RemoteOpState =

Remote_Disabled Remote_Idle Remote_Disabled

End of Phase End of Phase End of Phase End of Phase End of Command End of Command

3711
Figure 96 Protocol Flowchart: Write Phase (Remote WriteA32 Command)

Copyright © 2019–2024 MIPI Alliance, Inc. 199

8.1.3.13 Protocol Flow for Remote ReadSetup & ReadData Phases (Manager)
3712 Figure 97 shows the protocol flow in the Manager for Remote ReadSetup and ReadData Phases (i.e., ones
3713 where the address is Remote, see Section Note:). These flowcharts follow on from the generic Manager and
3714 Peripheral flow shown in Figure 86 and Figure 87. The Manager Responses shown in this figure are
3715 specified in normative Table 88.
3716 Note:
3717 The Local ReadSetup Phase from Figure 94 is repeated in this diagram (with grey background) for
3718 easy comparison with the Remote ReadSetup Phase.

Manager Manager
READ_SETUP READ_SETUP
READ_DATA
(local address) (remote address)

Peripheral
Response = Yes
REMOTE_ACCESS_
End of Phase
DISABLED?

Peripheral
Response = Yes
REMOTE_WRITE_BUSY? End of Phase

Peripheral Peripheral
Yes Yes
Response == End of Phase Response = End of Phase
READ_FAILED? READ_FAILED?

No No

i.e., Bit Error or

Peripheral Peripheral Peripheral
No Unexpected Response No No
Response == Response = Response =
READ_DATA_NOW? READ_DATA_NOW? READ_DEFERRED? i.e., Bit Error or
Unexpected Response

Yes Yes Yes

Send Protocol Spacer Send Protocol Spacer Send Protocol Spacer Send Protocol Spacer

Get Skip space for Get Skip space for

Peripheral Packet & Peripheral Packet & Peripheral Packet & Peripheral Packet &
CRC CRC CRC CRC

Send Protocol Spacer Send Protocol Spacer Send Protocol Spacer Send Protocol Spacer

Transport Error Yes Transport Error Yes

in Peripheral Packet in Peripheral Packet
or CRC? or CRC?

No No

Fail Fail
Check CRC Check CRC

Pass Pass

Send Manager Response: Send Manager Response: Send Manager Response: Send Manager Response: Send Manager Response: Send Manager Response:
READ_DATA_OK READ_DATA_ERROR READ_DATA_ERROR READ_DATA_OK READ_DATA_ERROR READ_DATA_ERROR

End of Phase End of Phase End of Phase End of Phase End of Phase End of Phase End of Phase

Schedule a future Schedule a future Schedule a future

ReadData Phase ReadData Phase ReadData Phase
3719 to complete this read to complete this read to complete this read

Figure 97 Protocol Flowchart: Remote ReadSetup and ReadData Phases (Manager)

200 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.3.14 Protocol Flow for Remote ReadSetup & ReadData Phases (Peripheral)
3720 Figure 98 shows the protocol flow in the Peripheral for Remote ReadSetup and ReadData Phases (i.e., ones
3721 where the address is Remote, see Section Note:). These flowcharts follow on from the generic Manager and
3722 Peripheral flow shown in Figure 86 and Figure 87. The Peripheral Responses shown in this figure are
3723 specified in normative Table 82 and Table 83.
3724 Note:
3725 The Local ReadSetup Phase from Figure 94 is repeated in this diagram (with grey background) for
3726 easy comparison with the Remote ReadSetup Phase.

Peripheral Peripheral
READ_SETUP
READ_DATA
(remote address)

Peripheral
READ_SETUP RemoteOpState = Yes Send Peripheral Response: RemoteOpState = Yes Send Peripheral Response:

(local address) RemoteDisabled? REMOTE_ACCESS_DISABLED RemoteDisabled? REMOTE_ACCESS_DISABLED

End of Phase End of Phase

No No

RemoteOpState = Yes Send Peripheral Response:

RemoteWriteBusy? REMOTE_WRITE_BUSY

End of Phase
No
Discard any incomplete RemoteOpState = Yes Send Peripheral Response:

previously deferred read RemoteReadBusy READ_DEFERRED

Start the read operation

End of Phase
No

No RemoteOpState = No
Read operation Send Peripheral Response: Send Peripheral Response:

completed immediately? READ_DEFERRED RemoteReadDataReady? PROTOCOL_ERROR

Deferred read End of Phase

Yes Set RemoteOpState = Yes
operation completes
RemoteReadBusy
some time later

End of Phase

Read operation Yes Send Peripheral Response: Did the read Yes
failed immediately? READ_FAILED operation fail?

Yes No
Did the read Send Peripheral Response:
No
operation fail? READ_FAILED
Set RemoteOpState = Set RemoteOpState = Set RemoteOpState = Set RemoteOpState =
RemoteReadDataReady RemoteDisabled RemoteReadDataReady RemoteDisabled
No End of Phase
End of Phase End of Command End of Command

Send Peripheral Response: Send Peripheral Response:

READ_DATA_NOW READ_DATA_NOW

Skip over Protocol Spacer Skip over Protocol Spacer

Send Peripheral Packet: Send Peripheral Packet:

Read data & CRC Read data & CRC

Skip over Protocol Spacer Skip over Protocol Spacer

Get Manager Get Manager

Response (HD10) Response (HD10)

(Nearest HD10) READ_DATA_ERROR (Nearest HD10) READ_DATA_ERROR

Manager Response Manager Response

READ_DATA_OK READ_DATA_OK

Enact any side effects (discard the Enact any side effects Preserve the read
(e.g., arming IntClear) read data) Set RemoteOpState = data for a future
Remote_Idle ReadData Phase

End of Phase End of Phase

3727 End of Phase End of Phase

Figure 98 Protocol Flowchart: Remote ReadSetup and ReadData Phases (Peripheral)

Copyright © 2019–2024 MIPI Alliance, Inc. 201

8.1.4 Peripheral Responses in Detail

3728 The tables in this section describe the Peripheral Responses, grouped by type of Phase / Transfer. They
3729 describe both the Peripheral condition that causes each response to be generated and the typical Manager
3730 behavior when it receives that Peripheral Response. The tables use Peripheral Response names with
3731 prefixes showing that they are specific to particular phases (read, write, commit, etc.), but some of these
3732 names use the same Robust Token as specified in Table 64.

8.1.4.1 Generic Peripheral Responses

3733 Table 50 shows generic Peripheral Responses that can occur in any type of Phase. The responses are shown
3734 in order of priority (see Figure 87).
3735 Table 50 Summary of Peripheral Responses (Generic to All Phases)
Used in which Peripheral Condition That
Name of Response Typical Manager Behavior
Phase(s) Provokes This Response
Unrecognised PhaseID or
Retry the same Phase at
All Phases transport error in the Phase
least once.
Header.
In GetStatus and Commit
Phases this is the expected
No Response This Peripheral not
response from the
addressed by the Phase (or Peripherals that are not
All Phases multiple Peripherals are selected, so is not a fault
selected in a condition.
single-Peripheral Phase).
Otherwise: retry the same
Phase at least once.
Command execution has
been blocked because the
Peripheral detached from and
All Phases then reattached to the bus Send an Unblock Command
COMMANDS_BLOCKED except
AND in a Write Phase.
Announce
This is not a Write Phase
containing an Unblock
Command.
Transport error in the
All Phases
Manager Packet (i.e., Bad Retry the same Phase at
TRANSPORT_ERROR except
8b/10b symbol Error or CRC least once.
Announce
fail).
All Phases This is the result of sending
The Peripheral does not
except an incorrect Command from
COMMAND_ERROR support the Command
Announce the Manager, so typically a
operation that was specified.
and ReadData software fault.

3736

202 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.4.2 Peripheral Responses in Read Transfers

3737 Table 51 shows Peripheral Responses relating to Read Transfers that occur in ReadSetup or ReadData
3738 Phases.
3739 Table 51 Summary of Peripheral Responses (ReadSetup & ReadData Phases)
Used in
Peripheral Condition That
Name of Response which Typical Manager Behavior
Provokes This Response
Phase(s)
The Peripheral performed the
read operation specified by the
ReadSetup Capture the read data and then
READ_DATA_NOW Command, and will deliver the
ReadData move to next Command.
data in the Peripheral Read Data
Packet.
The Peripheral attempted to
perform the read operation Peripheral-specific error
READ_FAILED ReadSetup
specified by the Command and it handling.
failed.
This is the result of sending an
The Phase did not follow the incorrect sequence of Phases
PROTOCOL_ERROR ReadData
Command Transport Protocol. from the Manager, so typically a
software fault.
A previous remote read or remote
Clear the IntStat bit and perform
write operation has failed, and the
REMOTE_ ReadSetup peripheral-specific error
Manager has not yet
ACCESS_DISABLED ReadData handling using local or remote
acknowledged this by clearing the
reads/writes.
IntStat bit.
A previous remote write operation Retry the ReadSetup Phase
REMOTE_
ReadSetup has not yet completed, so this later (perhaps after some delay
WRITE_BUSY
remote read cannot be accepted. or checking status using Ping).
The Peripheral accepted the
remote read operation specified Perform a ReadData Phase to
by the Command. attempt to complete the data
REMOTE_ transfer (possibly using Ping
ReadSetup The Peripheral will attempt the
READ_DEFERRED first to check whether the
read operation later.
Device is no longer busy with
Read data is not currently the read operation).
available.
Perform another ReadData
The previously accepted remote
Phase to attempt to complete
read operation is still not
REMOTE_ the data transfer (possibly using
ReadData complete.
READ_DEFERRED Ping first to check whether the
Read data is not currently Device is no longer busy with
available. the read operation).

Copyright © 2019–2024 MIPI Alliance, Inc. 203

8.1.4.3 Peripheral Responses in Write Transfers

3740 Table 52 shows Peripheral Responses that occur in Write Phases.
3741 Table 52 Summary of Peripheral Responses (Write Phase)
Peripheral Condition That Provokes
Name of Response Typical Manager Behavior
This Response
WriteA32 Command: The Peripheral
performed the write operation specified
by the Write Command.
WRITE_OK Unblock Command: The Peripheral Move to next Command.
cleared its Commands_Blocked status
(see Section ###XREF), so will now
process all Phases normally.
The Peripheral attempted to perform the
Peripheral-specific error
WRITE_FAILED write operation specified by the
handling.
Command and it failed.
A previous remote read or remote write Clear the IntStat bit and
operation has failed, and the Manager perform peripheral-specific
REMOTE_ACCESS_DISABLED
has not yet acknowledged this by error handling using local or
clearing the IntStat bit. remote reads/writes.
A previous remote write operation has Retry the Write Phase later
REMOTE_WRITE_BUSY not yet completed, so this remote write (perhaps after some delay or
cannot be accepted. checking status using Ping).
The Peripheral accepted the remote
write operation and write data specified
by the Command.
REMOTE_WRITE_BUFFERED The Peripheral will attempt the write Move to next Command.
operation later (and report any failure
via the Remote Access State and
IntStat_Remote_Disabled).

8.1.4.4 Peripheral Responses in Commit Transfers

3742 Table 53 shows Peripheral Responses that occur in Commit Phases.
3743 Table 53 Summary of Peripheral Responses (Commit)
Peripheral Condition That
Name of Response Typical Manager Behavior
Provokes This Response
The Peripheral is ready to Examine the responses from all selected
perform the commit operation Peripherals and generate a Manager
specified by the SSCR/DSCR Response to confirm or cancel the
COMMIT_READY Command and will either discard commit operation.
it or schedule it for the future
After confirming the commit operation,
according to the subsequent
move to next Command.
Manager Response.
The Peripheral is not ready to Typically the Manager will generate a
perform the commit operation Manager Response to cancel the commit
specified by the SSCR/DSCR operation.
COMMIT_NOT_READY Command, but will still either
The Manager might then interrogate
discard it or schedule it for the
Peripheral status and/or retry the commit
future according to the
operation.
subsequent Manager Response.

204 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.4.5 Peripheral Responses in CalibratePhy Transfers

3744 Table 54 shows Peripheral Responses that occur in CalibratePhy Phases.
3745 Table 54 Summary of Peripheral Responses (CalibratePhy Phase)
Peripheral Condition That
Name of Response Typical Manager Behavior
Provokes This Response
A parameter in the Calibrate
Command was not valid, e.g.,
This is the result of sending an
• Block_Count > 64
incorrect Command from the
COMMAND_ERROR i.e., N > 0x3F Manager, so typically a software
• Adjust_Count > 10 x fault.
Block_Count
i.e., A > (10 × (N + 1)
The Peripheral will generate
CALIBRATE_NOW
calibration data.

3746
3747 ###TODO-Author: complete the updates to responses below this point.
3748
3749 The details of which Peripheral Responses are used for which error conditions in each Phase, and the
3750 prioritization of those conditions, are described in the informative Sections for each type of Transfer and
3751 specified in Section 8.2.3.

8.1.4.6 OLD: Detailed Description of Peripheral Responses

3752 ###TODO: merge/replace table form to simplify this?
3753 This Section contains a more detailed description of the Peripheral Responses that are summarized in
3754 Section 8.1.4.5.
3755 No Response: This is not an actively driven 8b/10b symbol, but is the result of the Manager interpreting
3756 the absence of any symbol driven by the Peripheral. This absence of a response is indicated in the figures
3757 by the grey colored “Peripheral: No Response”. This “passive” response relies on properties of the Control
3758 Data Stream and/or PHY in the Manager identifying that no valid response was actively generated (e.g., by
3759 knowing that a value of 10’b1111111111 is not a valid 8b/10b symbol, see Section 7.1.1.4).
3760 This Response can be (passively) generated by a Peripheral for two different reasons:
3761 • The Peripheral has not received Valid Phase Header information from the transport layer, so is not
3762 able to determine reliably the correct position in the bit sequence of the Control Data Stream to
3763 issue a Peripheral Response. E.g., if the 8b/10b symbol containing the PhaseID did not correspond
3764 to a valid Robust Token, the Peripheral does not know where the Response starts or whether this is
3765 a single-Peripheral or Multicast Response.
3766 • The Peripheral has received Valid Phase Header information, but is not selected by the
3767 DeviceMask Header field.
3768 The Manager might receive this Response for several reasons:
3769 • The Peripheral expected to drive the Response slot encountered one of the cases listed above.
3770 • In a single-Peripheral Phase (Write, ReadSetup, or ReadData Phase), the DeviceNumber identified
3771 by the DeviceAddress Header field is either not populated, or that Peripheral is currently not
3772 Attached to the bus (see ###XREF to Attached).
3773 • In a multicast Phase (GetStatus or Commit Phase), the DeviceNumber corresponding to that
3774 Response Slot within the Multicast Peripheral Response is either not populated, or that Peripheral
3775 is currently not Attached to the bus.

Copyright © 2019–2024 MIPI Alliance, Inc. 205

3776 TRANSPORT_ERROR: The Phase Header was received OK, so the Peripheral knows the position and
3777 type of Response that is expected, but there was a transport error in the Manager Packet (bad 8b/10b
3778 decoding or the CRC failed). The Peripheral will not perform the Command or operation that was described
3779 by the Phase.
3780 PROTOCOL_ERROR: The Peripheral has received unexpected Phase information from the transport
3781 layer, because this information did not follow the protocol (e.g., receiving a ReadData Phase when there is
3782 no ongoing multi-phase Read Transfer).
3783 COMMAND_ERROR: The Peripheral has received valid Phase information from the transport layer, but
3784 it does not support the Command operation that was specified in the Manager Packet. (e.g., the write byte
3785 count is too large for this Peripheral). This Response indicates that the Manager sent incorrect information.
3786 BUSY: (REMOTE_WRITE_BUSY, COMMIT_NOT_READY) The Peripheral has received valid Phase
3787 information from the transport layer (including the Manager Packet CRC passing OK), but it is currently
3788 unable to accept the Command operation that was specified, e.g. because some internal resource such as a
3789 write buffer is busy. The Peripheral will not perform the Command or operation that was described by the
3790 Phase.
3791 FAILED: (WRITE_FAILED, READ_FAILED) The Peripheral has received valid Phase information from
3792 the transport layer, and attempted to perform the Command operation, but this failed.
3793 DEFERRED: (REMOTE_READ_DEFERRED). The Peripheral has received valid Phase information
3794 from the transport layer.
3795 ReadSetup Phase: The Peripheral might or might not yet have started the operation described by
3796 the Phase, but it is not yet ready to deliver the Peripheral read data.
3797 ReadData Phase: The Peripheral might or might not yet have started the operation described by
3798 that Phase, but it is not yet ready to deliver the Peripheral read data.
3799
3800 OK: (WRITE_OK, READ_DATA_NOW, COMMIT_READY) The Peripheral has received valid Phase
3801 information from the transport layer, and will perform the Command operation.
3802 Note:
3803 For Commit Phases, COMMIT_READY indicates that this Peripheral is ready to accept the
3804 scheduled operation, but this might subsequently be cancelled by the Manager Response at the
3805 end of the Commit Phase.

8.1.4.6.1 Special Cases of Peripheral Responses to Read Transfers

3806 There is one special case of a Peripheral Responses to note:
3807 • For ReadData Phases, the Responses of REMOTE_READ_DEFERRED and
3808 READ_DATA_NOW refer to the Read Command described by the most recent ReadSetup Phase
3809 that had received a Peripheral Response of REMOTE_READ_DEFERRED.

206 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.5 Manager Responses in Detail

8.1.5.1 Manager Responses in Read Transfers

3810 Table 55 is a summary of the Manager Responses in ReadSetup and ReadData Phases, showing the
3811 Manager condition that causes them to be generated and the Peripheral behavior that results from receiving
3812 them.
3813 Table 55 Summary of Manager Responses in Read Transfers
Response Manager Condition Peripheral Behavior
The Manager received a Peripheral End the ongoing Read Transfer (or
READ_DATA_OK Response of READ_DATA_NOW and multi-phase Read Transfer) and
received read data with no transport errors. discard any local copy of read data.
The Manager received a Peripheral
Response containing transport errors[1] or
READ_DATA_ERROR a Peripheral Packet containing transport Retain any local copy of read data.
errors (Bad 8b/10b Symbol Error or CRC
Error).
1. When the Manager receives a Peripheral Response containing transport errors then it does not
know whether or not the Peripheral is actually providing a Peripheral Packet, but it drives this
Manager Response at the point in the Phase that it would drive it if the Peripheral had sent a
READ_DATA_NOW response, i.e., after the expected position of the Peripheral_CRC16_Low
byte. See Section 8.1.8.6 and Section 8.1.8.10.
3814 Note:
3815 ###TODO-Author: reword this to make it easier to read!
3816 Some of the error conditions that provoke READ_DATA_ERROR as a Manager Response would
3817 instead provoke No_Response from a Peripheral (e.g., Bad 8b/10b symbol Error in the Control
3818 Data Stream received by a Manager within a Peripheral Response versus the same type of error
3819 received by a Peripheral within a Phase Header). The Manager can provide this more positive
3820 indication of a transport error because it always knows the point in the sequence when the
3821 Peripheral would be expecting the Manager Response, if the Peripheral were expecting a Manager
3822 Response at all.

8.1.5.1.1 Manager Responses in Commit Transfers

3823 Table 56 is a summary of the Manager Responses in Commit Phases, showing the Manager condition that
3824 causes them to be generated and the Peripheral behavior that results from receiving them.
3825 Table 56 Summary of Manager Responses in Commit Transfers
Response Manager Condition Peripheral Behavior
(Typically) the Manager received a Peripheral
CONFIRM_COMMIT Response of COMMIT_READY from all Schedule the requested operation.
selected Peripherals.
(Typically) the Manager received a Peripheral
Response from at least one of the selected Do not schedule the requested
CANCEL_COMMIT
Peripherals that was not COMMIT_READY, or operation.
that suffered a transport error.

3826 ###TODO-Author: triage this old description and extract anything useful into the table.
3827 CONFIRM_COMMIT: The Manager is instructing the Peripherals selected in the Commit Phase that the
3828 Commit Transfer has completed successfully, so the Peripherals can now schedule the operation that was
3829 requested. Typically, this indicates that the Manager received Peripheral Responses of
3830 COMMAND_ACCEPTED from all of the Peripherals that were selected in the Commit Phase.

Copyright © 2019–2024 MIPI Alliance, Inc. 207

3831 CANCEL_COMMIT: The Manager is instructing the Peripherals selected in the Commit Phase that the
3832 Commit Transfer has not completed successfully, so the Peripherals abort the scheduling of the operation
3833 that was requested. Typically, this indicates that the Manager received a Peripheral Response from at least
3834 one of the selected Peripherals that was not COMMAND_ACCEPTED, or that contained a transport error
3835 (bad 8b/10b symbol).
3836 ###Question for Reviewers: are you happy that the Manager does NOT check for either of:
3837 • Response from unpopulated Peripheral DeviceNumbers being consistent with undriven
3838 response?
3839 • Response from populated but unselected Peripheral DeviceNumbers being consistent
3840 with undriven response?
3841
3842

208 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.6 GetStatus Transfer

3843 A GetStatus Transfer transports a GetStatus Command from the Manager to a set of Peripherals. GetStatus
3844 Command is a general term for all operations where a Command is transported from Manager to
3845 Peripheral(s) and each Peripheral then provides a small amount of information, e.g., 1 of 4 status conditions
3846 within a Ping Command. A GetStatus Transfer is comprised of one GetStatus Phase (see Section 8.1.6.1).
3847 The GetStatus Commands described in this version of the Specification are:
3848 • Ping, see Section 9.1.5.
3849 The Ping Command is a multicast Command, so it targets a set of 1 or more Peripherals.

8.1.6.1 GetStatus Phase

3850 The structure of a GetStatus Phase is shown in Figure 99. The first byte of the Manager Packet contains a
3851 Command Opcode identifying the Ping Command that is described by the Manager Packet. The Ping
3852 Command (see Section 9.1.5) has no additional Command Info after the Opcode.
3853 The Peripheral Multicast Info section of the Phase comprises one Robust Token from each Peripheral
3854 DeviceNumber that might exist on the bus. These tokens transport the status information from the
3855 Peripheral. The content of the information field is a function of the Command (e.g., Ping).

GetStatus Phase:
Ping Command
Start of Phase Marker
GET_STATUS
Device Mask_H
– devices
Device Mask_M
selected
Device Mask_L
Packet_Length_H=0x0
Packet_Length

Packet_Length_L=0x1
= 0x01

Opcode: Ping
Manager_CRC16_H
Manager_CRC16_L
Protocol Spacer
Peripheral 0 PingInfo[3..0]

Peripheral 1 PingInfo[3..0]

Peripheral 2 PingInfo[3..0]

Peripheral 3 PingInfo[3..0]

Peripheral 4 PingInfo[3..0]

Peripheral 5 PingInfo[3..0]

Peripheral 6 PingInfo[3..0]

Peripheral 7 PingInfo[3..0]

Peripheral 8 PingInfo[3..0]

Peripheral 9 PingInfo[3..0]

Peripheral 10 PingInfo[3..0]

Peripheral 11 PingInfo[3..0]
3856
Figure 99 GetStatus Phase & Ping Command

Copyright © 2019–2024 MIPI Alliance, Inc. 209

8.1.6.2 Peripheral Responses in GetStatus Phase

3857 The Peripheral Response is a Robust Token that is either a Command Transport Protocol error
3858 (TRANSPORT_ERROR or COMMAND_ERROR) or a Command-specific Robust Token (see, e.g., Ping
3859 Command in Section 9.1.5).
3860 ###TODO-Author: Triage the archived material for any further text.

8.1.6.3 GetStatus Transfer Errors in the Manager

3861 The Manager expects to receive Bad Robust Token Transport Errors in the response slot for any
3862 unpopulated or unselected Peripherals, because these bits are not driven. Typical Manager behavior in
3863 reaction to unexpected transport errors is to retry the Transfer. For the special case of a Ping Command, the
3864 Manager receiving a valid token in a slot where it expected No Response is not necessarily an error: this is
3865 how it discovers that a Device has become newly attached to the bus.

210 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.7 Announce Transfer

3866 An Announce Transfer transports an Announce Command from the Manager to a set of Peripherals.
3867 Announce Command is a general term for all operations where a Command is transported from Manager to
3868 Peripheral(s) without needing any response, e.g., an SSPA Command. An Announce Transfer is comprised
3869 of one Announce Phase (see Section 8.1.7.1).
3870 The Announce Commands described in this version of the Specification are:
3871 • SSPA, see Section 9.1.6.
3872 • ExitDormant, see Section 9.1.7.
3873 Both of these Commands are multicast Commands, meaning that they target a set of 1 or more Peripherals.

8.1.7.1 Announce Phase

3874 The structure of an Announce Phase is shown in Figure 100. The first byte of the Manager Packet contains
3875 a Command Opcode identifying which Command is described by the Manager Packet. The 2 Commands
3876 that use Announce Phases both have a fixed-length Manager Packet:
3877 • 3 bytes for the SSPA Command, see Section 9.1.6.
3878 • 1 byte for the ExitDormant Command, see Section 9.1.7.

Announce Phase: Announce Phase:

SSPA Command ExitDormant Command
Start of Phase Marker Start of Phase Marker
ANNOUNCE ANNOUNCE
Device Mask_H Device Mask_H
– devices – devices
Device Mask_M Device Mask_M
selected selected
Device Mask_L Device Mask_L

Packet_Length (0x01)
Packet_Length (0x03)

Packet_Length_H=0x0 Packet_Length_H=0x0

Packet_Length_L=0x3 Packet_Length_L=0x1

Opcode: SSPA Opcode: ExitDormant

Group Mask Manager_CRC16_H
Row Delay Manager_CRC16_L
Manager_CRC16_H
Manager_CRC16_L
3879
Figure 100 Announce Phases and SSPA & ExitDormant Commands

Copyright © 2019–2024 MIPI Alliance, Inc. 211

8.1.8 Read Transfer

3880 A Read Transfer transports a Read Command from the Manager to one Peripheral, and associated read data
3881 from that Peripheral to the Manager. Read Command is a general term for operations where the Command
3882 and any parameters are transferred from Manager to a Peripheral and the resulting data in the opposite
3883 direction, e.g., reading data from Peripheral registers. A Read Transfer is comprised of one ReadSetup
3884 Phase (see Section 8.1.8.2), which, in some cases, is followed by one or more ReadData Phases (see
3885 Section 8.1.8.7).
3886 A Read Transfer starts with the ReadSetup Phase. In some cases, the Peripheral will terminate the Transfer
3887 with an error or send the read data as part of this Phase, so the Transfer is completed as a “single-phase
3888 Read Transfer”. In other cases, the Peripheral will accept the Command during the ReadSetup Phase, but
3889 defer providing the read data until later, creating a “multi-phase Read Transfer” (see Section 8.1.8.1). This
3890 Transfer is then either completed in a later ReadData Phase (when the Peripheral either terminates the
3891 Transfer or provides read data), or aborted when the Manager starts a new Transfer to this Peripheral for a
3892 new Read or Write Command.
3893 Commands that use Read Transfers are:
3894 • ReadA32, see Section 9.1.8.
3895 ReadA32 is a directed Command, so it targets exactly 1 Peripheral.

8.1.8.1 Multi-Phase Read Transfer

3896 ###TODO-Author: rewrite to explain that any Transfer is accepted, but a remote write (Write
3897 Transfer) or remote read (ReadSetup transfer) will abort the pending read operation. (triage the old
3898 material).
3899 When a Peripheral cannot provide the read data in a ReadSetup Phase immediately, it issues a Peripheral
3900 Response of REMOTE_READ_DEFERRED, which creates an incomplete multi-phase Read Transfer in
3901 that Peripheral. The Peripheral retains the Read Command information and attempts to perform the
3902 requested read operation so that it will have the data to send in response to a subsequent ReadData Phase,
3903 and so complete the Read Transfer.

212 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.8.2 ReadSetup Phase

3904 The structure of a ReadSetup Phase, both with and without read data from the Peripheral, is shown in
3905 Figure 101.

ReadSetup Phase ReadSetup Phase ReadSetup Phase

when Peripheral when Peripheral read when Peripheral read
provides data immediately operation fails immediately defers providing data
Start of Phase Marker Start of Phase Marker Start of Phase Marker
READ_SETUP READ_SETUP READ_SETUP
Device Mask_H Device Mask_H Device Mask_H
1 device
Device Mask_M Device Mask_M Device Mask_M
selected
Device Mask_L Device Mask_L Device Mask_L
Packet_Length_H=0x0 Packet_Length_H=0x0 Packet_Length_H=0x0
Packet_Length_L=0x6 Packet_Length_L=0x6 Packet_Length_L=0x6
Packet_Length = 0x06

Opcode: ReadA32 Opcode: ReadA32 Opcode: ReadA32

Read Byte Count Read Byte Count Read Byte Count
Addr32[31:24] Addr32[31:24] Addr32[31:24]
Addr32[23:16] Addr32[23:16] Addr32[23:16]
Addr32[15:08] Addr32[15:08] Addr32[15:08]
Addr32[07:00] Addr32[07:00] Addr32[07:00]
Manager_CRC16_H Manager_CRC16_H Manager_CRC16_H
Manager_CRC16_L Manager_CRC16_L Manager_CRC16_L
Protocol Spacer Protocol Spacer Protocol Spacer
(derived from Read Byte Count)

READ_DATA_NOW READ_FAILED READ_DEFERRED

Peripheral Packet_Length

Protocol Spacer
Peripheral Data
...
...
...
Peripheral_CRC16_H
Peripheral_CRC16_L
Protocol Spacer
Manager Response
3906
Figure 101 ReadSetup Phase & ReadA32 Command

Copyright © 2019–2024 MIPI Alliance, Inc. 213

8.1.8.3 Manager Packet in ReadSetup Phase

3907 The Manager Packet contains the Command Info, which is a description of a Read Command operation that
3908 is to be performed. The first byte of the Manager Packet contains an Opcode identifying the ReadA32
3909 Command (see Section 9.1.8).

8.1.8.4 Peripheral Responses in ReadSetup Phase

3910 ###TODO-Author: Triage / Reinstate some of the archived material.

8.1.8.5 Peripheral Packet in ReadSetup Phase

3911 The Peripheral Packet contains the read data that resulted from the Peripheral performing the operation
3912 described in the Command Info. The size of this packet is inferred from the command information rather
3913 than being explicitly described by transport layer information within the Phase.
3914 The ReadA32 Command is described in Section 9.1.8.

8.1.8.6 Manager Responses in ReadSetup Phase

3915 ###TODO-Author: Triage / Reinstate some of the archived material.

8.1.8.7 ReadData Phase

3916 The structure of a ReadData Phase, both with and without read data from the Peripheral, is shown in
3917 Figure 102.

Read Data Phase Read Data Phase Read Data Phase

when Peripheral when Peripheral read when Peripheral
provides data operation fails late defers providing data
Start of Phase Marker Start of Phase Marker Start of Phase Marker
READ_DATA READ_DATA READ_DATA
Device Mask_H Device Mask_H Device Mask_H
1 device
Device Mask_M Device Mask_M Device Mask_M
selected
Device Mask_L Device Mask_L Device Mask_L
Packet_Length_H=0x0 Packet_Length_H=0x0 Packet_Length_H=0x0

Packet_Length_L=0x0 Packet_Length_L=0x0 Packet_Length_L=0x0

Protocol Spacer Protocol Spacer Protocol Spacer

READ_DATA_NOW READ_FAILED READ_DEFERRED
Peripheral Packet_Length
(derived from Read Byte

Protocol Spacer
ReadSetup Phase)
Count in original

Peripheral Data
...
...
...
Peripheral_CRC16_H
Peripheral_CRC16_L
Protocol Spacer
Manager Response
3918
Figure 102 ReadData Phase

214 Copyright © 2019–2024 MIPI Alliance, Inc.

3919 A ReadData Phase is an optional part of a Read Transfer that is used when the Peripheral has deferred the
3920 transport of read data from the original ReadSetup Phase (or from one or more ReadData Phases that
3921 followed it).
3922 The Packet_Length in the Phase Header is 0x00 to indicate that there is no Manager Packet (and hence no
3923 Manager_CRC).

8.1.8.8 Peripheral Responses in ReadData Phase

3924 ###TODO-Author: highlight that a Peripheral cannot respond to a ReadData Phase with
3925 READ_FAILED because the failure is deemed to occur either after the Peripheral chooses its
3926 response (which would thus have been REMOTE_READ_DEFERRED) or before it chooses its
3927 response (which would thus be REMOTE_ACCESS_DISABLED).
3928 ###TODO-Author: Triage / Reinstate some of the archived material.

8.1.8.9 Peripheral Packet in ReadData Phase

3929 The Peripheral Packet contains the read data that resulted from the Peripheral performing the operation
3930 described in the Command Info in the original ReadSetup Phase. The size of this packet is inferred from the
3931 command information rather than being explicitly described by transport layer information within the
3932 Phase.
3933 Read Commands and the expected size of read data for various Opcodes is described in Section ###XREF.

8.1.8.10 Manager Responses in ReadData Phase

3934 ###TODO-Author: Triage / Reinstate some of the archived material.
3935
3936

Copyright © 2019–2024 MIPI Alliance, Inc. 215

8.1.9 Write Transfer

3937 A Write Transfer transports a Write Command from the Manager to one Peripheral, along with the
3938 associated write data. Write Command is a general term for all operations where both the Command and
3939 any data are transferred from Manager to a Peripheral, e.g., writing data to Peripheral registers. A Write
3940 Transfer is comprised of one Write Phase (see Section 8.1.9.1).
3941 The Write Transfer transports the Command information to the Peripheral immediately, but the Peripheral
3942 might perform the operation described by the Command at some time after the Transfer has completed.
3943 The Write Commands described in this version of the Specification are:
3944 • WriteA32, see Section 9.1.9.
3945 • Unblock, see Section 9.1.11.
3946 WriteA32 and Unblock are directed Commands, so target exactly 1 Peripheral.

8.1.9.1 Write Phase

3947 The structure of a Write Phase is shown in Figure 103. The Manager Packet in a Write Phase has a length
3948 described by the Packet_Length field in the Phase Header, and contains data describing either the WriteA32
3949 Command (see Section 9.1.9) or the Unblock Command (see Section 9.1.11).

Write Phase: Write Phase:

WriteA32 Command Unblock Command
Start of Phase Marker Start of Phase Marker
WRITE WRITE
Device Mask_H Device Mask_H
1 device 1 device
Device Mask_M Device Mask_M
selected selected
Device Mask_L Device Mask_L Packet_Length =1
Packet_Length_H Packet_Length_H=0x0
Packet_Length_L Packet_Length_L=0x1

Opcode: WriteA32 Opcode: Unblock

Address[31:24] Manager_CRC16_H
(5 + data byte count)

Address[23:16] Manager_CRC16_L
Packet_Length

Address[15:08] Protocol Spacer

Address[07:00] Peripheral Response

Write Data
...
...
...
Manager_CRC16_H
Manager_CRC16_L
Protocol Spacer
Peripheral Response
3950
Figure 103 Write Phases and WriteA32 and Unblock Commands

216 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.9.2 Manager Packet in Write Phase

3951 The Manager Packet contains the Command Info, which is a description of a Write Command operation
3952 that is to be performed, and any write data that is consumed by that operation. The first byte of the
3953 Command is an Opcode that identifies the specific Command operation (e.g., WriteA32).
3954 Unblock Commands (see Section ###XREF) are effectively a “write operation”, in that they change the
3955 state of the Peripheral, but unlike WriteA32 Commands they do not need an address or write data bytes.

8.1.9.3 Errors in Write Transfers

3956 The Peripheral performs transport layer checks (e.g., CRC on the Manager Packet) and command error
3957 checks (e.g., does it support this length of write) during the Write Phase, and any transport error or
3958 command error is signaled immediately (i.e., in the Peripheral Response at the end of the Phase). For a
3959 Remote WriteA32 Command, the Peripheral does not always complete the write operation while the Write
3960 Phase is in progress, in which case it gives a Peripheral Response of REMOTE_WRITE_BUFFERED.
3961 After the Peripheral has indicated that the write was buffered, it has no further mechanism to indicate a
3962 problem with the data in the Manager Packet – the only conditions that can be indicated are about the write
3963 operation described by the Command:
3964 • Buffered write operation failed (by IntStat_RemoteDisabled or Peripheral Response of
3965 REMOTE_ACCESS_DISABLED to a subsequent Remote Read or Write), or
3966 • Buffered write operation still busy (Ping Response or Peripheral Response of
3967 REMOTE_WRITE_BUSY), or
3968 • Buffered write operation succeeded (implicitly by interrupts, Ping Response, or Peripheral
3969 Response not indicating failed or busy).
3970 The Peripheral sets the Remote Access State to Remote_Disabled in response to a Remote_Write
3971 Command that had initially received a Peripheral Response of REMOTE_WRITE_BUFFERED and then
3972 subsequently failed (see Section 9.1.4).

8.1.9.4 Peripheral Responses in Write Phase

3973 ###TODO-Author: Triage / Reinstate some of the archived material.

Copyright © 2019–2024 MIPI Alliance, Inc. 217

8.1.10 Commit Transfer

3974 A Commit Transfer transports a Commit Command from the Manager to a set of Peripherals, and includes
3975 the facility for the Manager to cancel the Command if some of the targeted Peripherals did not receive the
3976 information correctly.
3977 A Commit Transfer is comprised of one Commit Phase (see Section 8.1.10.1).
3978 Commit Commands are used to perform synchronized updates, and comprise:
3979 • SSCR (Stream-Synchronous Commit Request), see Section 9.1.10, and
3980 • DSCR (Device-Synchronous Commit Request), see Section ###XREF.
3981 The SSCR and DSCR Commands are multicast Commands, so they target a set of 1 or more Peripherals.

218 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.10.1 Commit Phase

3982 The structure of a Commit Phase is shown in Figure 104. The Manager Packet in a Commit Phase has a
3983 fixed length of 3 described by the Packet_Length field in the Phase Header, and contains data describing
3984 the SSCR Command (see Section 9.1.10), or DSCR Command (see ###XREF).

Commit Phase: Commit Phase:

SSCR Command DSCR Command
Start of Phase Marker Start of Phase Marker
COMMIT COMMIT
Device Mask_H Device Mask_H
– devices – devices
Device Mask_M Device Mask_M
selected selected
Device Mask_L Device Mask_L
Packet_Length_H=0x0 Packet_Length_H=0x0

Packet_Length_L=0x3
Packet_Length
Packet_Length_L=0x3

Packet_Length
Opcode: SSCR Opcode: DSCR
= 0x03

= 0x03
Group Mask Group Mask
Row Delay Row Delay
Manager_CRC16_H Manager_CRC16_H
Manager_CRC16_L Manager_CRC16_L
Protocol Spacer Protocol Spacer
Peripheral 0 Response Peripheral 0 Response
Peripheral 1 Response Peripheral 1 Response

Peripheral 2 Response Peripheral 2 Response

Peripheral 3 Response Peripheral 3 Response

Peripheral 4 Response Peripheral 4 Response
Peripheral 5 Response Peripheral 5 Response

Peripheral 6 Response Peripheral 6 Response

Peripheral 7 Response Peripheral 7 Response

Peripheral 8 Response Peripheral 8 Response
Peripheral 9 Response Peripheral 9 Response
Peripheral 10 Response Peripheral 10 Response

Peripheral 11 Response Peripheral 11 Response

Protocol Spacer Protocol Spacer

Manager Response Manager Response
3985
Figure 104 Commit Phase and SSCR & DSCR Commands

8.1.10.2 Manager Packet in Commit Phase

3986 The Manager Packet contains the Command Info, which is a description of a Commit Command operation
3987 that is to be performed. The first byte of the Command is an Opcode that identifies the specific Command
3988 operation (e.g., SSCR).

8.1.10.3 Multicast Peripheral Response in Commit Phase

3989 ###TODO-Author: Triage / Reinstate some of the archived material.
3990

Copyright © 2019–2024 MIPI Alliance, Inc. 219

8.1.10.4 Manager Response in Commit Phase

3991 ###TODO-Author: Triage / Reinstate some of the archived material.
3992

8.1.10.5 Examples of Peripheral Responses to Commit Commands

3993 Figure 105 illustrates 5 example sequences of Peripheral Responses to a Commit Phase, and the resulting
3994 Manager Response. In these examples, the system is populated with six Peripherals (Device Numbers: 0, 1,
3995 2, 3, 4, 5) and the Manager sends a Commit Transfer selecting Device Numbers 1, 2, 3, 4, and 5.
3996 Example 1: Peripherals 1 through 5 all respond with COMMIT_READY. The Manager is aware that
3997 Peripheral 0 was not selected, and that Peripherals 6 and 7 do not exist, so the five positive responses and
3998 three No Response Slots are as expected. Thus, the Manager responds with CONFIRM_COMMIT
3999 indicating to the Peripherals that they can perform the action associated with the Write Command that was
4000 transported by this Commit Transfer.
4001 Example 2: Peripheral 3 detects a transport error in the Manager Packet (e.g., a Bad 8b/10b symbol or a
4002 CRC error) so responds with TRANSPORT_ERROR to indicate that it is not ready to perform the Write
4003 Command. The Manager did not receive the expected positive responses from every populated selected
4004 Peripheral, so responds with CANCEL_COMMIT canceling the requested action in all Peripherals.
4005 Example 3: Peripheral 1 detects a transport error in the Phase Header (e.g., Bad Robust Token Error) so
4006 generates no response (because the incorrect Header means that it cannot determine the correct time to send
4007 an error response). The Manager did not receive the expected positive responses from every populated
4008 selected Peripheral, so responds with CANCEL_COMMIT canceling the requested action in all
4009 Peripherals.
4010 Example 4: Peripheral 2 indicates that it is not ready to perform the commit operation (e.g., because it has
4011 to do some pre-processing on values in some of the *_NEXT registers), so generates a
4012 COMMIT_NOT_READY response. The Manager did not receive the expected positive responses from
4013 every populated selected Peripheral, so responds with CANCEL_COMMIT canceling the requested action
4014 in all Peripherals.
4015 Example 5: All 5 of the Peripherals detected a problem with the Command (e.g. the SSCR Delay was an
4016 invalid value), so they generate a response of COMMAND_ERROR. The Manager did not receive the
4017 expected positive responses from every populated selected Peripheral, so responds with
4018 CANCEL_COMMIT canceling the requested action in all Peripherals.

Peripheral Responses Peripheral Responses Peripheral Responses Peripheral Responses Peripheral Responses
to a Commit Transfer to a Commit Transfer to a Commit Transfer to a Commit Transfer to a Commit Transfer
Example 1 Example 2 Example 3 Example 4 Example 5

P0: No Response P0: No Response P0: No Response P0: No Response P0: No Response
P1: COMMIT_READY P1: COMMIT_READY P1: No Response P1: COMMIT_READY P1: COMMAND_ERROR

P2: COMMIT_READY P2: COMMIT_READY P2: COMMIT_READY P2: COMMIT_NOT_READY P2: COMMAND_ERROR

P3: COMMIT_READY P3: TRANSPORT_ERROR P3: COMMIT_READY P3: COMMIT_READY P3: COMMAND_ERROR

P4: COMMIT_READY P4: COMMIT_READY P4: COMMIT_READY P4: COMMIT_READY P4: COMMAND_ERROR

P5: COMMIT_READY P5: COMMIT_READY P5: COMMIT_READY P5: COMMIT_READY P5: COMMAND_ERROR

P6: No Response P6: No Response P6: No Response P6: No Response P6: No Response
P7: No Response P7: No Response P7: No Response P7: No Response P7: No Response

Protocol Spacer Protocol Spacer Protocol Spacer Protocol Spacer Protocol Spacer

4019 CONFIRM_COMMIT CANCEL_COMMIT CANCEL_COMMIT CANCEL_COMMIT CANCEL_COMMIT

Figure 105 Examples of Peripheral Responses to Commit Transfer

4020 ###TODO-Author: amend Figure 105 to show 12 Peripheral Responses

220 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.11 CalibratePhy Transfer

4021 ###Note to Reviewers: See more material about CalibratePhy in Section 9.1.12.
4022 ###TODO-Author: consider moving some material about CalibratePhy phase from Section 9.1.12 to here.
4023 InitCal and TrimCal are directed Commands, so target exactly 1 Peripheral.
4024
4025 Figure 106 shows a CalibratePhy Transfer containing a InitCal Command.

CalibratePhy Phase when CalibratePhy Phases when measurements do not occur

measurements do occur E.g., CRC error in E.g., Unknown E.g., Transport Error
Manager Packet Opcode value in Phase Header
Start of Phase Marker Start of Phase Marker Start of Phase Marker Start of Phase Marker
CALIBRATE_PHY CALIBRATE_PHY CALIBRATE_PHY CALIBRATE_PHY
Device Mask_H Device Mask_H Device Mask_H Device Mask_H
1 device
Device Mask_M Device Mask_M Device Mask_M Device Mask_M
selected
Device Mask_L Device Mask_L Device Mask_L Device Mask_L
Packet_Length_H Packet_Length_H Packet_Length_H Packet_Length_H
Packet_Length

Packet_Length_L Packet_Length_L Packet_Length_L Packet_Length_L

Opcode=InitCal Opcode=InitCal Opcode=Reserved Opcode=InitCal
(0x03)

CalibrationLength=N CalibrationLength=N CalibrationLength=N CalibrationLength=N

AdjustLength=A AdjustLength=A AdjustLength=A AdjustLength=A
Manager_CRC16_H Manager_CRC16_H Manager_CRC16_H Manager_CRC16_H
Manager_CRC16_L Manager_CRC16_L Manager_CRC16_L Manager_CRC16_L
Protocol Spacer Protocol Spacer Protocol Spacer Protocol Spacer
CALIBRATE_NOW TRANSPORT_ERROR COMMAND_ERROR Peripheral: No Response

Protocol Spacer
0 RR 0 RR 0 RR 0
Calibration Packet

RR 0 RR 0 RR 0 R
Length

R 0 RR 0 RR 0 RR
...
Total of (N + 1) blocks
of 3 x10 bits
...
Protocol Spacer
Peripheral Cal Result
4026
Figure 106 Summary of CalibratePhy Transfer Containing a InitCal Command

8.1.12 Usage of Robust Tokens in Command Transport Protocol

4027 Robust Tokens in the Control Data Stream are described in Section 7.1.4.
4028 Robust Tokens are used for all bytes in the Command Transport Protocol that are not protected by CRCs,
4029 except for the Start of Phase Marker. These uses are:
4030 Manager to Peripheral in Phase Headers:
4031 PhaseID
4032 Device_Mask_High, Device_Mask_Mid, Device_Mask_Low
4033 Packet_Length_High, Packet_Length_Low

Copyright © 2019–2024 MIPI Alliance, Inc. 221

4034 Peripheral to Manager:

4035 Peripheral_Response (in all Phases except GetStatus)
4036 Peripheral_Info (in Phase: GetStatus)
4037 PHY_Calibration_Result (in Phase: CalibratePhy)
4038 Manager to Peripheral Response:
4039 Manager_Response (in Phases: ReadSetup, ReadData, and Commit)

8.1.12.1 Assignment of Robust Token Values in Command Transport Protocol

4040 The assignment of Robust Token values to bytes that are transmitted by the Manager is specified in
4041 normative Table 63, and the assignment for Peripherals in normative Table 64. Some Robust Tokens are
4042 shown in these tables as Reserved (depending on the context in which the Robust Token is used).
4043 If a Peripheral receives a Reserved value in a Phase Header then it ignores that Phase, and does not
4044 generate any Peripheral Response. The Manager will see the undriven bus as an unexpected value.
4045 If a Manager receives a Reserved value in a Peripheral Response (or a value that is not valid in the context
4046 of the current Phase) then it counts this as an UnexpectedRobustToken error (see ###XREF).
4047 In both cases, the Manager will then perform whatever error handling is chosen by higher layers in the
4048 stack, e.g., retry the Phase, send a Ping command to check status, or reset the bus.

222 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.13 CRC Checking in Command Transport Protocol

4049 Manager Packets and Peripheral Packets include a 16-bit Cyclic Redundancy Checksum used to detect
4050 when bit errors in the Control Data Stream have produced incorrect decoded data.
4051 The algorithm used for the calculating the CRC is …
4052 In both Manager and Peripheral Packets, the CRC generation calculation is performed on the unencoded
4053 8-bit bytes of the Packet data (i.e., before 8b/10b encoding for the Control Data Stream), and then the two
4054 bytes of CRC are 8b/10b-encoded and appended to the encoded bytes of the Packet data. The CRC check
4055 calculation at the receiving end is performed on decoded bytes after the 8b/10b decoding, and includes only
4056 the Packet data, not the two received CRC bytes. A successful CRC check is indicated by the value of the
4057 check calculation being equal to the value of the received CRC.

8.1.13.1 CRC Algorithm in Command Transport Protocol

4058 Both the Manager and Peripheral packets use a polynomial x16 + x15 + x13 + x9 + x7 + x6 + x5 + x3 + x + 1 to
4059 calculate the checksum, with the variable X[16:1] initialized to the value 0x0000 at the start of each
4060 calculation.
4061 Figure 107 shows an example circuit for implementing the CRC calculation using a serial 16-bit Galois
4062 LFSR with all state elements, Q[15:0], reset to 0 at the start of the calculation.
4063 To generate the checksum, the data is clocked in on “Data In”. Once all bits have been clocked into the
4064 circuit the calculated CRC value will be present in the 16 flops, with the first CRC bit, corresponding to the
4065 MSB, located in Q15. The two bytes of the CRC are transmitted in the Control Data Stream after the data
4066 bytes of the Manager or Peripheral Packet that was used to calculate the checksum. Each of the bytes in the
4067 Manager / Peripheral Packet and the CRC are 8b10b-encoded before being transmitted in the Control Data
4068 Stream.
4069 Similarly, when receiving a Manager or Peripheral Packet, the data is passed in on “Data In”. Once all bits
4070 have been clocked into the circuit the calculated CRC value will be present in the 16 flops, with the first
4071 CRC bit, corresponding to the MSB, located in Q15. The next 2 bytes that are received contain the 16-bit
4072 CRC from the transmitter, which is then compared to the CRC calculated in the receiver. If the values do
4073 not match, this is a CRC Transport Error. In the Peripheral this is indicated by sending a Peripheral
4074 Response of TRANSPORT_ERROR. In the Manager, this is indicated by sending a Manager Response of
4075 READ_DATA_ERROR.

Initial value of Q[15:0] (X16:1]) is b0000_0000_0000_0000 = 0x0000

CRC16_H [15:8] CRC16_L [7:0]

Q15 Q14 Q13 Q12 Q11 Q10 Q9 Q8 Q7 Q6 Q5 Q4 Q3 Q2 Q1 Q0

X(16) X(15) X(14) X(13) X(12) X(11) X(10) X(9) X(8) X(7) X(6) X(5) X(4) X(3) X(2) X(1) X(0)

4076 Data In

Figure 107 CRC Calculation in Command Transport Protocol

Copyright © 2019–2024 MIPI Alliance, Inc. 223

8.1.13.2 CRC Calculation Example

4077 Table 57 shows an example CRC calculation using the circuit from Figure 107. The rows in the table show
4078 the sequence of values in the state variable, Q[15:0], when presented with a Manager/Peripheral Packet
4079 containing 2 bytes: 0x80 then 0x35. The resulting CRC is 0xCC89, so the 2 bytes to be 8b10b-encoded and
4080 transmitted after those of the the Manager/Peripheral Packet would be CRC16_H=0xCC and then
4081 CRC16_L=0x89.
4082 Table 57 CRC Calculation Example

Bit Data In Data In Q[15:0]

Q[15:0] (binary) Notes
count (hex) (binary) (hex)

0 — — 0x0000 b0000_0000_0000_0000 Initialized to 0x0000.

1 0x80 1 0xA2EB b1010_0010_1110_1011 Clock in bit 7 of byte 0.

2 — 0 0xE73D b1110_0111_0011_1101 Clock in bit 6 of byte 0.

3 — 0 0x6C91 b0110_1100_1001_0001 …

4 — 0 0xD922 b1101_1001_0010_0010 …

5 0x80 0 0x10AF b0001_0000_1010_1111 …

6 — 0 0x215E b0010_0001_0101_1110 …

7 — 0 0x42BC b0100_0010_1011_1100 …

8 — 0 0x8578 b1000_0101_0111_1000 Clock in bit 0 of byte 0.

9 0x35 0 0xA81B b1010_1000_0001_1011 Clock in bit 7 of byte 1.

10 — 0 0xF2DD b1111_0010_1101_1101 …

11 — 1 0xE5BA b1110_0101_1011_1010 …

12 — 1 0xCB74 b1100_1011_0111_0100 …

13 0x35 0 0x3403 b0011_0100_0000_0011 …

14 — 1 0xCAED b1100_1010_1110_1101 …

15 — 0 0x3731 b0011_0111_0011_0001 Clock in bit 1 of byte 1.

Clock in bit 0 of byte 1.

Calculated CRC is
16 — 1 0xCC89 b1100_1100_1000_1001 0xCC89.
CRC16_High = 0xCC.
CRC16_Low = 0x89.

224 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.13.3 Scope of CRC Calculations

4083 Figure 108 illustrates that the scope of CRC generation and CRC checking calculations on a Manager
4084 Packet are the same, and Figure 109 similarly illustrates that the scope of CRC generation and CRC
4085 checking on a Peripheral Packet are the same.

Manager Packet

calculation (in Peripheral)

Command Opcode

Scope of CRC generator

calculation (in Manager)

Scope of CRC checker

Command Info
...
...
Manager Data
...
...
...
Manager_CRC16_H
Manager_CRC16_L
4086
Figure 108 Scope of CRC Calculations on Manager Packets
calculation (in Peripheral)
Scope of CRC generator

calculation (in Manager)

Peripheral Packet
Scope of CRC checker
Peripheral Data
...
...
...
Peripheral_CRC16_H
Peripheral_CRC16_L
4087
Figure 109 Scope of CRC Calculations on Peripheral Packets

8.1.14 Details of Local and Remote Accesses

4088 Local and Remote Addresses are introduced in Section ###XREF.

8.1.14.1 Buffered Writes (aka Posted Writes)

4089 When a Peripheral cannot determine the result (success or failure) of a remote write immediately, it issues a
4090 Peripheral Response of REMOTE_WRITE_BUFFERED, which indicates that the write data has been
4091 accepted and the operation will be completed later. This operation is referred to as a “buffered write” or
4092 sometimes a “posted write”. The Manager is decoupled from the time taken by the Peripheral to complete
4093 the operation and can proceed with other operations (e.g., local reads and writes to this Peripheral or any
4094 accesses to other Peripherals).
4095 The Command Transport Protocol does not guarantee exactly when the buffered write operation will occur
4096 and does not include explicit signaling of when it has completed (with either success or failure). The
4097 Manager can infer this information from responses to later remote writes and reads, or from the Peripheral
4098 status reported in a Ping Command.

Copyright © 2019–2024 MIPI Alliance, Inc. 225

8.1.14.2 Split Reads

4099 When a Peripheral cannot provide the read data for a remote read immediately, it issues a Peripheral
4100 Response of REMOTE_READ_DEFERRED, which creates an incomplete Split Read Transfer in that
4101 Peripheral. This operation is referred to as a “deferred read” or sometimes a “split read”. The Peripheral
4102 retains the Read Command information and attempts to perform the requested read operation so that it will
4103 have the data to send in response to a subsequent ReadData Phase, and so complete the Read Transfer.
4104 The Manager is decoupled from the time taken by the Peripheral to obtain the read data and can proceed
4105 with other operations (e.g., local reads and writes to this Peripheral, or any accesses to other Peripherals).
4106 The Manager uses a ReadData Phase to attempt to obtain the read data resulting from a split read.
4107 ReadData Phases can also be deferred (multiple times) while the Peripheral is still working on obtaining all
4108 of the read data requested by the original ReadSetup Phase. When the Peripheral does complete the remote
4109 read operation (with either success or failure) this is explicitly signaled in the Peripheral Response to a
4110 ReadData Phase.
4111 When a Split Read Transfer has been started in a Peripheral, this will eventually be either:
4112 • Completed, when the Manager receives a final response (e.g., OK or Failed) to a ReadData Phase
4113 targeting that Peripheral, or
4114 • Aborted, when the Manager initiates a new Transfer to a remote register in that Peripheral (using
4115 a ReadSetup or Remote Write Phase).
4116 Note: Aborting the outstanding split Read Transfer simplifies the design of a Peripheral because it
4117 does not have to manage the semantics of later write(s) overtaking earlier reads, and so updating a
4118 register before its previous value has been read.

8.1.14.3 Peripheral Resources for Remote Access

4119 The model used to describe Peripheral behavior has a single buffer that can be used for either 1 remote
4120 write or 1 remote read. If this buffer contains a buffered/posted write that has not yet completed then any
4121 remote write or read will receive a response of REMOTE_WRITE_BUSY.
4122 If any remote write or read fails (e.g., due to an internal bus error, or because the remote address domain
4123 currently has either no clock or no power) then remote accesses become disabled. Any new transfers that
4124 attempt to write or read the remote address space will receive a Peripheral Response of
4125 REMOTE_ACCESS_DISABLED. This condition continues until it is explicitly cleared by the Manager
4126 sending a local write that clears the Remote_Access_Restricted IntStat bit.
4127 The remote access disabled status affects only remote write and remote read Transfers. The Peripheral will
4128 still accept any other Phases (GetStatus, Commit, CalibratePhy, Local Read, and Local Write).

8.1.14.4 Manager Interleaving Transfers to Other Peripherals

4129 An incomplete Split Read Transfer in a Peripheral is not affected by any of:
4130 • GetStatus, Commit, CalibratePhy, Local Read, or Local Write Transfers that target any Peripheral
4131 (including this one).
4132 • Remote Read or Remote Write Transfers that target other Peripherals.
4133 The Manager might intentionally interleave Remote Transfers to some Peripherals to make efficient use of
4134 the Command channel while other Peripherals are performing the internal operations (e.g., storing write
4135 data or fetching read data) to complete their buffered write transfers or split read transfers.

8.1.15 Transaction Ordering

8.1.15.1 Between Local Addresses

4136 All local read and local write transfers complete strictly in order. Thus a local read will always see the
4137 result of any preceding local writes.

226 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.15.2 Between Local and Remote Addresses

4138 The Command Transport Protocol treats Local and Remote addresses as 2 separate spaces with no
4139 guarantee of ordering between them.
4140 Local read and write transfers can be performed while a buffered write operation or deferred read operation
4141 is still outstanding, and there is no guarantee of whether or not a local read will see the result of an earlier
4142 buffered remote write, or whether a deferred remote read will see the result of a local write that was issued
4143 (and completed) between the initial ReadSetup Phase and the final ReadData Phase.

8.1.15.3 Between Remote Addresses

4144 The Command Transport Protocol has at most one incomplete remote transfer (split read or buffered write)
4145 outstanding at any time.
4146 • When a buffered write has not yet completed, the Peripheral will reject any newly issued remote
4147 read or write with a Peripheral Response of REMOTE_WRITE_BUSY.
4148 • When a split read is still outstanding then any newly issued remote write will abort the outstanding
4149 read so that its read data will no longer become available to be delivered to the Manager.
4150 • When a split read is still outstanding then a newly issued second remote read will abort the first
4151 outstanding read and either complete immediately or become the new deferred remote read.
4152 If the Manager issues a ReadData Phase when there is no split read outstanding (e.g., because the split
4153 read has been aborted because of receiving another remote transfer) then the Peripheral signals this
4154 with a Response of PROTOCOL_ERROR.

8.1.16 Error Handling in the Command Transport Protocol

4155 Section 8.1.16.2 through Section 8.1.16.9 describe categories of errors that might result from transport
4156 layer bit errors. Each error is fed to the named saturating error counter (see Table 163 in Section 15.1.3),
4157 which can then generate interrupts to help with system debugging.

8.1.16.1 Reaction to Transport Errors During Potential Headers

4158 These apparent errors can occur when the Peripheral is observing data that has not actually been
4159 transmitted by the Manager (either when the Control Data Stream is driven by another Peripheral, or when
4160 it is not driven at all, e.g., in the Ping Response bits allocated to unpopulated Peripheral Device numbers).
4161 Thus, when these errors occur during a potential Command Header, they cause the Peripheral to abandon
4162 that Header, but they are not explicitly signaled to the Manager (via either the Protocol or interrupts), and
4163 they are not counted.

8.1.16.2 Bad 8b/10b Symbol Transport Error

4164 Some transport bit errors create a corrupted value that is not a valid 10-bit symbol. When an error is
4165 detected by the 8b/10b decoder in the Control Data Stream, this is named a “Bad 8b/10b Symbol Transport
4166 Error” (see Section 7.1.5.1 and Section 7.1.5.2).
4167 When a transport bit error produces a corrupted value that corresponds to a different, but validly encoded,
4168 10-bit symbol then the Control Data Stream layer will pass the decoded byte (with an incorrect value) to
4169 the Command Transport Protocol layer. The Command Transport Protocol incorporates two further features
4170 (Robust Tokens and CRCs) which can detect these unexpected values of bytes.

8.1.16.3 Bad Robust Token Transport Error

4171 Some bytes are transported using a sparse subset of the 8b/10b symbols, named Robust Tokens. When the
4172 protocol defines that one of these Robust Tokens is used, and the decoded symbol is not in the subset, then
4173 this is a “Bad Robust Token Transport Error” (see Section 7.1.5.3).
4174 The received symbol might also cause a Bad 8b/10b Symbol Transport Error.

Copyright © 2019–2024 MIPI Alliance, Inc. 227

8.1.16.4 Bad HD10 Token Transport Error

4175 Some bytes are transported using a sparse subset of 2 of the 8b/10b symbols, named HD10 Robust Tokens.
4176 When the protocol defines that one of these HD10 Robust Tokens is used, and the received symbol is not an
4177 exact match to one of the two in the subset, then this is a “Bad HD10 Token Transport Error” (see
4178 Section 7.1.5.3), though the Decoder will also pass to the Command Transport Protocol Layer an indication
4179 of which of the 2 expected symbols is the closest match to symbol that was received.

8.1.16.5 CRC Transport Error

4180 Robust Tokens effectively transport only 4 useful bits in a 10-bit symbol, so would not be efficient for large
4181 blocks of data within the protocol (i.e., Manager Packets and Peripheral Packets, see Section 8.1.2.3 and
4182 Section 8.1.2.7). The bytes in Manager Packets and Peripheral Packets are instead encoded as normal 8-bit
4183 D-codes within the 8b/10b-encoding, and then protected by 16-bit CRC values calculated on the decoded
4184 8-bit values (see Section 8.1.13). When this checksum fails it is a “CRC Transport Error”.

8.1.16.6 Bad PHY_Cal Data Transport Error

4185 In the Calibration Packet for the InitCal & TrimCal Commands (see ###XREF), the Manager sends a pair
4186 of unencoded bits that have complementary values (i.e., b01 or b10). If the Peripheral detects a different
4187 combination of bits (i.e., b00 or b11) then this is a “Bad PHY_Cal Data Transport Error”.

8.1.16.7 Unexpected Robust Token Protocol Error

4188 In some of the places where Robust Tokens are used, the set of values that is expected at that point in the
4189 Command Transport Protocol is smaller than the full set of 16. If a 10-bit symbol is decoded to a valid
4190 Robust Token byte value, but that Robust Token number is not expected at this point in the Command
4191 Transport Protocol then this is an “UnexpectedRobustToken Protocol Error” (see Section 8.1.12).
4192 In a Peripheral, this can only occur when receiving the 60 bits following an SPM that are being checked as
4193 a possible Valid Phase Header, and the Peripheral merely abandons the potential header without taking any
4194 other error handling action. The Peripheral does not have an associated Error Counter or IntStat bit for this
4195 error.
4196 In a Manager, this can only occur when receiving a Peripheral Response or Calibration Result. The
4197 Manager counts this as an UnexpectedRobustToken error and then handles the error as chosen by higher
4198 layers.

8.1.16.8 Unexpected Phase Protocol Error

4199 The Command Transport Protocol imposes some constraints on the pattern in which Phases can be
4200 arranged. When a correctly encoded Robust Token for a valid PhaseID is received at an inappropriate point
4201 in the sequence of Phases this is named an “Unexpected Phase Protocol Error”.

8.1.16.9 Unexpected New Header Protocol Error

4202 The Peripheral expects the Manager to generate only complete Phases. When a new error-free Valid Phase
4203 Header is detected while the Peripheral was processing an existing Phase then this is an
4204 “UnexpectedNewHeader Protocol Error”.
4205 Note:
4206 This error condition can occur as a result of the Peripheral sampling CDS data transmitted from
4207 other peripherals (a SWI3S system does not support Peripheral-to-Peripheral transmission of CDS
4208 data, so the Peripheral might be sampling the bus when the data from another Peripheral is not
4209 stable).
4210 When this error condition occurs, the associated Error Counter is incremented, and IntStat condition
4211 generated. If it occurs while the Peripheral is processing a Commit Phase (SSCR or DSCR Command) or
4212 GetStatus Phase (Ping Command), then the Peripheral continues with that Phase without any change. Apart

228 Copyright © 2019–2024 MIPI Alliance, Inc.

4213 from these 2 special cases, when this condition occurs the Peripheral will abandon the existing Phase and
4214 start interpreting the new Phase. The Peripheral makes an implementation-defined amount of effort to
4215 abandon the existing Phase cleanly, such as trying to reduce state changes that have occurred.

8.1.16.10 Abandoned Phase Protocol Error

4216 ###TODO-Author.
4217

Copyright © 2019–2024 MIPI Alliance, Inc. 229

8.1.17 Example Error Scenarios in Command Transport Protocol

8.1.17.1 Example Error Scenario: Ping Command with Missing Peripheral Response
4218 Figure 110 illustrates a GetStatus Phase containing a Ping Command where one of the selected Peripherals
4219 has not generated a response, for example because a transport error in the Header meant that the Peripheral
4220 will ignore the Phase.
4221 In this example:
4222 • The Manager knows that Peripheral DeviceNumbers 2, 3, and 11 are not populated in this system,
4223 so has generated a Ping Command that selects only devices 0, 1, and 4 through 10. The Manager
4224 expects to see No Response in slots 2, 3, and 11.
4225 • Peripheral #4 has suffered a transport error in the Header (e.g., a bit error in the Device_Mask_L
4226 byte in the Header). This is not an error-free Header, so Peripheral #4 does not generate any
4227 response.
4228 • The Manager sees 8 valid responses (Robust Tokens encoding Ping Status information) in the slots
4229 for Peripherals 0, 1, and 5 through 10, and 3 expected (and thus not counted) Bad 8b/10b_Symbol
4230 Transport Errors caused by the b1111111111 from the No Response in the slots for Peripherals 2,
4231 3, and 11. However, the Bad8b/10b_Symbol Transport Error in the slot for Peripheral 4 is
4232 unexpected, so is handled as a genuine error.

General Form of Expected Result Actual Result

Ping Command when Device Mask when Peripheral #4
Selects Peripherals Suffers a Transport
0, 1, 4 – 0 Error

Start of Phase Marker Start of Phase Marker Start of Phase Marker

GET_STATUS GET_STATUS GET_STATUS
Device Mask_H=b0111 Device Mask_H=b0111 Device Mask_H=b0111

Device Mask_M=b1111 Device Mask_M=b1111 Device Mask_M=b1111

Device Mask_L=b0011 Device Mask_L=b0011 Device Mask_L=b0011

Packet_Length

Packet_Length_H=0x0 Packet_Length_H=0x0 Packet_Length_H=0x0

Packet_Length_L=0x1 Packet_Length_L=0x1 Packet_Length_L=0x1

= 0x01

Opcode: Ping Opcode: Ping Opcode: Ping

Manager_CRC16_H Manager_CRC16_H Manager_CRC16_H
Manager_CRC16_L Manager_CRC16_L Manager_CRC16_L
Protocol Spacer Protocol Spacer Protocol Spacer
Peripheral 0 PingInfo[3..0] Peripheral 0 PingInfo[3..0] Peripheral 0 PingInfo[3..0]

Peripheral 1 PingInfo[3..0] Peripheral 1 PingInfo[3..0] Peripheral 1 PingInfo[3..0]

Peripheral 2 PingInfo[3..0] Peripheral: No Response Peripheral: No Response Expected

Peripheral 3 PingInfo[3..0] Peripheral: No Response Peripheral: No Response Expected
Peripheral 4 PingInfo[3..0] Peripheral 4 PingInfo[3..0] Peripheral: No Response Not expected
Peripheral 5 PingInfo[3..0] Peripheral 5 PingInfo[3..0] Peripheral 5 PingInfo[3..0]

Peripheral 6 PingInfo[3..0] Peripheral 6 PingInfo[3..0] Peripheral 6 PingInfo[3..0]

Peripheral 7 PingInfo[3..0] Peripheral 7 PingInfo[3..0] Peripheral 7 PingInfo[3..0]

Peripheral 8 PingInfo[3..0] Peripheral 8 PingInfo[3..0] Peripheral 8 PingInfo[3..0]

Peripheral 9 PingInfo[3..0] Peripheral 9 PingInfo[3..0] Peripheral 9 PingInfo[3..0]

Peripheral 10 PingInfo[3..0] Peripheral 10 PingInfo[3..0] Peripheral 10 PingInfo[3..0]

Peripheral 11 PingInfo[3..0] Peripheral: No Response Peripheral: No Response Expected

4233
Figure 110 Example Error Scenario: Ping Command with Missing Peripheral Response

230 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.17.2 Example Error Scenario: ReadSetup with Corrupted READ_DATA_NOW

4234 Figure 111 illustrates a ReadSetup Phase where the Peripheral has provided a Response of
4235 READ_DATA_NOW, followed by a Peripheral Packet containing the data bytes and CRC. A bit error has
4236 corrupted the Peripheral Response so that the Manager sees a Bad Robust Token Transport Error, and does
4237 not know which Peripheral Response has been provided.
4238 The Manager cannot determine whether or not the Peripheral has provided a Peripheral Packet, so it skips
4239 over the expected number of symbols that would form the Peripheral Packet (without decoding them)
4240 before driving a Manager Response of READ_DATA_ERROR and then moving on to a new Phase. The
4241 Manager behavior would be the same for any Peripheral Response that has been corrupted such that it is
4242 not an expected Robust Token.
4243 After issuing a Response of READ_DATA_NOW and a Peripheral Packet, the Peripheral will decode the
4244 following symbol and interpret it as a Manager Response. When it decodes the valid Robust Token symbol
4245 that corresponds to READ_DATA_ERROR, it will know that the Read Transfer has not yet completed
4246 successfully, so will retain the data for a possible subsequent ReadData Phase.

Peripheral view of ReadSetup Phase Manager view of ReadSetup Phase

when Peripheral Response of when Peripheral Response of
READ_DATA_NOW is corrupted READ_DATA_NOW is corrupted
Start of Phase Marker Start of Phase Marker
READ_SETUP READ_SETUP
Device Mask_H Device Mask_H
Device Mask_M Device Mask_M
Device Mask_L Device Mask_L
Packet_Length_H=0x0 Packet_Length_H=0x0

Packet_Length = 0x06
Packet_Length_L=0x6 Packet_Length_L=0x6
Packet_Length = 0x06

Opcode: ReadA32 Opcode: ReadA32

Read Byte Count=4 Read Byte Count=4
Addr32[31:24] Addr32[31:24]
Addr32[23:16] Addr32[23:16]
Addr32[15:08] Addr32[15:08]
Addr32[07:00] Addr32[07:00]
Manager_CRC16_H Manager_CRC16_H
Manager_CRC16_L Manager_CRC16_L
Protocol Spacer Protocol Spacer
(derived from Read Byte Count)
(derived from Read Byte Count)
Peripheral Packet_Length = 4

Peripheral Packet_Length = 4

READ_DATA_NOW Peripheral: BAD TOKEN

Protocol Spacer Protocol Spacer

Peripheral Data Ignore possible data

... Ignore possible data

Peripheral_CRC16_H Ignore possible CRC

Peripheral_CRC16_L Ignore possible CRC

Protocol Spacer Protocol Spacer

READ_DATA_ERROR READ_DATA_ERROR

Start of Phase Marker Start of Phase Marker

PhaseID: ... PhaseID: ...
4247

Copyright © 2019–2024 MIPI Alliance, Inc. 231

Figure 111 Example Error Scenario: ReadSetup with Corrupted READ_DATA_NOW

8.1.17.3 Example Error Scenario: ReadSetup with Corrupted

REMOTE_READ_DEFERRED
4248 Figure 112 illustrates a ReadSetup Phase where the Peripheral has provided a Response of
4249 REMOTE_READ_DEFERRED, and thus not generated any following Peripheral Packet. A bit error has
4250 corrupted the Peripheral Response so that the Manager sees a Bad Robust Token Transport Error, and does
4251 not know which Peripheral Response has been provided.
4252 The Manager cannot determine whether or not the Peripheral has provided a Peripheral Packet, so it skips
4253 over the expected number of symbols that would form the Peripheral Packet (without decoding them)
4254 before driving a Manager Response of READ_DATA_ERROR and then moving on to a new Phase. The
4255 Manager behavior would be the same for any Peripheral Response that has been corrupted such that it is
4256 not an expected Robust Token.
4257 After issuing the Peripheral Response of REMOTE_READ_DEFERRED, the Peripheral will examine the
4258 Control Data Stream at every bit boundary, waiting to detect a Start of Phase Marker, which it will detect
4259 when the Manager starts the new Phase. The Peripheral will not decode or react to the Manager Response
4260 of READ_DATA_ERROR.

Peripheral view of ReadSetup Phase Manager view of ReadSetup Phase

when Peripheral Response of when Peripheral Response of
REMOTE_READ_DEFERRED REMOTE_READ_DEFERRED
is corrupted is corrupted
Start of Phase Marker Start of Phase Marker
READ_SETUP READ_SETUP
Device Mask_H Device Mask_H
Device Mask_M Device Mask_M
Device Mask_L Device Mask_L
Packet_Length_H=0x0 Packet_Length_H=0x0
Packet_Length = 0x06

Packet_Length = 0x06
Packet_Length_L=0x6 Packet_Length_L=0x6

Opcode: ReadA32 Opcode: ReadA32

REMOTE_READ_DEFERRED Peripheral: BAD TOKEN

Protocol Spacer
Peripheral Ignore possible data
not driving Ignore possible data
read data
Ignore possible data

Waiting for SPM Ignore possible data

Ignore possible CRC
Ignore possible CRC

Protocol Spacer
READ_DATA_ERROR

Start of Phase Marker Start of Phase Marker

PhaseID: ... PhaseID: ...
4261
Figure 112 Example Error Scenario: ReadSetup with Corrupted
REMOTE_READ_DEFERRED

232 Copyright © 2019–2024 MIPI Alliance, Inc.

8.1.18 Examples of Error Handling

4262 ###TODO-Author: (2) create normative requirements for any of these error behaviors that are not already
4263 described, e.g., by the tables of Peripheral Responses,
4264 ###TODO: “UnexpectedRobustToken Error” is detected in this layer (Command Transport Protocol) not in
4265 the Control Data Stream decoding (Section ###XREF). Enumerate the cases when this can occur, or maybe
4266 just say “any Robust Token Value not described in the other requirements”.
4267 Table 58 Treatment of Command Transport Protocol Errors in Peripheral
Which Error
Location Description of Error Reaction
is Counted
Header [1] Unknown PhaseId Wait for SPM None
Invalid Device Mask (Either 0 or ≥ bits
Header [1] are set in the Mask for a Phase that Wait for SPM None
targets exactly 1 Peripheral).
Unexpected Packet Length for this
Header [1] Wait for SPM None
PhaseID (zero vs. non-zero)
Header [1] Bad 8b/10b symbol Wait for SPM None
Header [1] Bad Robust Token Wait for SPM None
Following the Peripheral sending a
Manager Apply HD10 correction
Response: READ_DATA_NOW, the
Response in (choose-nearest).
Manager Response is not a perfect EC_BadHD10
ReadSetup or Complete the Phase
match for either of the 2 HD10 Robust
ReadData Phase using the corrected value.
Tokens.
Following the Peripheral sending a
Response of either of: Apply HD10 correction
Manager
COMMIT_NOT_READY or (choose-nearest).
Response in EC_BadHD10
COMMIT_READY, the Manager Complete the Phase
Commit Phase
Response is not a perfect match for using the corrected value.
either of the 2 HD10 Robust Tokens.
Peripheral Response:
Manager Packet &
Bad 8b/10b symbol TRANSPORT_ERROR; EC_Bad8b10b
CRC
Wait for SPM

4268 Note:
1. The 5 Rows that describe errors in the Header correspond to “Bad Phase Header” in normative
Table 77 and Table 78.
4269 Note:
4270 In the special case of HD10 Robust Tokens (where the received 10-bit symbol is translated to a
4271 1-bit yes/no answer, but with the option of a Bad HD10 Token Transport Error), the receiver does
4272 not increment any other 8b10-related error counters (e.g., Bad_RT or Bad_8b10b) even of those
4273 error conditions are satisfied.
4274

Copyright © 2019–2024 MIPI Alliance, Inc. 233

4275 Table 59 Treatment of Command Transport Protocol Errors in Manager

Which Error
Location Description of Error Reaction
is Counted
Manager Response:
Peripheral READ_DATA_ERROR;
Packet & Bad 8b/10b symbol E.g., Retry the Read_Setup Phase or Bad8b10b
CRC (for remote reads) retry the Read_Data
Phase.
E.g.,:
• Read back the data to see if it
Peripheral The received symbol is not one of was written. BadRT
Response the 16 Robust Tokens • Retry the Phase.

E.g.,:
The received symbol is a
• Read back the data to see if it
Peripheral correctly encoded Robust Token, was written. UnexpectedRT
Response but the particular RT is not valid in • Retry the Phase.
this Phase.

4276

234 Copyright © 2019–2024 MIPI Alliance, Inc.

8.2 Specifications (normative)

8.2.1 Structure of Phases

4277 Note:
4278 Rules for Control Data Stream transport and 8b/10b encoding & decoding are in Section 7.2.
4279 ###TODO-Author: check for / resolve overlaps with Section 7.2.
4280 ###TODO-Author: Add a Manager requirement to generate Pings or other Commands at a minimum rate.
4281 ###TODO-Author: Possibly in Section 9.2.1:
4282 • Manager shall generate 1 Ping per <= 4096 Rows in the normal case.
4283 • Manager should generate 2 Pings per <= 896 Rows when helping Peripherals to rejoin.
4284 • Informative: Manager might change to Command-only when helping DLV Peripherals to rejoin.
4285 ###TODO-Author: review all normative material to check that the decision from Section 8.1.16.1 has been
4286 incorporated. (Do NOT count 8b10b errors until after a complete error-free header (SPM + 6 Robust
4287 Tokens) has been received.)
4288 ###TODO-Author: fix the “unexpected packet length” description in errors in Table 58. Niel says:This
4289 really an “Manager Packet existential crisis error”.

4290 Requirements
4291 1. {xx01} The Manager shall co-ordinate the Control Data Stream to be a continuous stream of either
4292 of:
4293 A. Two idle bits (0 and then 1) transmitted by the Manager, or
4294 B. A Command Transport Protocol Phase made up of an uninterrupted sequence of CDS bits
4295 transmitted by the Manager and Peripheral(s) as defined in the rules within this
4296 Section (8.2.1).

Copyright © 2019–2024 MIPI Alliance, Inc. 235

4297 2. {xx02} The Manager shall start the Phases described in Requirement 1B by transmitting a Phase
4298 Header formatted according to Table 60.
4299 Table 60 Command Transport Protocol Phase Header (All Phases)

Byte
Name Sent By Description
Number

Special 8b/10b token, see Section 7.2.2 Requirement 5C

0 SPM Manager
and 6C.

Robust Token (see Table 63) that identifies the Phase

1 PhaseId Manager pattern (and defines the interpretation of Opcodes within
the Manager Packet).

2 Device_Mask_H Manager Robust Token for selecting Device Numbers 11 through 8 [1]

3 Device_Mask_M Manager Robust Token for selecting Device Numbers 7 through 4 [1]

4 Device_Mask_L Manager Robust Token for selecting Device Numbers 3 through 0 [1]

Robust Token that indicates the 4 MSbs of the byte count

5 Packet_Length_H Manager
for the Manager Packet [2]

Robust Token that indicates the 4 LSbs of the byte count for
6 Packet_Length_L Manager
the Manager Packet [2]

4300 Note:
1. The Table for each Command defines whether the Device_Mask selects exactly 1 Peripheral or a
set of 1 to 12 Peripherals.
2. Phases that do not include a Manager Packet (e.g., ReadData Phase) have a Packet Length field
of 0x00.

236 Copyright © 2019–2024 MIPI Alliance, Inc.

4301 3. {7003} The Phases described in Requirement 1B shall be formatted according to the Table
4302 indicated in Table 61.
4303 Table 61 Index to Phase Definition Tables
PhaseId Command Phase Structure Phase/Command-Specific
(see Table 63) (i.e., Opcode in Manager Specified in: Peripheral Responses Specified in:
Packet, see Table 95) (see Section 8.2.3)
GetStatus Ping Table 68 Table 87
Announce SSPA Table 69 — [3]

Announce ExitDormant [1] Table 70 — [3]

SSCR
Commit Table 71 Table 84
DSCR [1]
Write WriteA32 Table 72 Table 81
Write Unblock Table 73 Table 80
ReadSetup ReadA32 Table 74 Table 82
[1] [2]
ReadData (ReadA32) Table 75 Table 83
InitCal
CalibratePhy [1] Table 76 Table 85
TrimCal

4304 Note:
1. Peripheral support for some Phases or Commands is optional or conditional, see Table 95 in
Section 9.2.1.
2. The ReadData Phase does not have a Manager Packet so does not have an Opcode, but is
associated with the incomplete ReadA32 Command from the previous ReadSetup Phase.
3. The Announce Phase does not include any Peripheral Responses.

Copyright © 2019–2024 MIPI Alliance, Inc. 237

4305 4. {xx04} The Manager shall select Devices in a Phase Header by creating a 12-bit Device Mask
4306 value according to Table 62 and then encoding:
4307 A. DeviceMask[11:8] in the Robust Token Number for Device_Mask_H, and
4308 B. DeviceMask[7:4] in the Robust Token Number for Device_Mask_M, and
4309 C. DeviceMask[3:0] in the Robust Token Number for Device_Mask_L.
4310 Table 62 Device Selection in Phase Headers
DeviceMask[11:0] Value to Select this Device [1]
Unicast Phases: Multicast Phases:
Write GetStatus
ReadSetup Commit
ReadData Announce(SSPA)
Device CalibratePhy Announce(ExitDormant):Optional[3]
Number Announce(ExitDormant)[2]
0 000000000001 xxxxxxxxxxx1
1 000000000010 xxxxxxxxxx1x
2 000000000100 xxxxxxxxx1xx
3 000000001000 xxxxxxxx1xxx
4 000000010000 xxxxxxx1xxxx
5 000000100000 xxxxxx1xxxxx
6 000001000000 xxxxx1xxxxxx
7 000010000000 xxxx1xxxxxxx
8 000100000000 xxx1xxxxxxxx
9 001000000000 xx1xxxxxxxxx
10 010000000000 x1xxxxxxxxxx
11 100000000000 1xxxxxxxxxxx
4311 Note:
1. ‘x’ in the Device Mask value for Multicast Phases means that either 0 or 1 is valid in that bit
position.
2. All Peripherals that implement ExitDormant will accept an ExitDormant Command in which they
are the only selected Device.
3. Some Peripherals also accept an ExitDormant Command in which other Devices are also
selected.

4312 5. {xx05} When the Peripheral detects an SPM (see Section 7.2.2 Requirement 5C and 6C) it shall
4313 decode the immediately following 60 CDS bits as a Valid Phase Header (see Table 60) provided
4314 that:
4315 A. The 60 bits correspond to 6 valid Robust Tokens, and
4316 B. The Peripheral implements the PhaseID, and
4317 C. The DeviceMask selects this Peripheral (see Requirement 4), and
4318 D. Either:
4319 i. The Packet_Length is zero (when PhaseID is ReadData), or
4320 ii. The Packet_Length is non-zero (when PhaseID is not ReadData).
4321 Note: if the Peripheral detects a second SPM that starts after the first bit of the first SPM then the
4322 first SPM cannot be the start of an error-free header, so the Peripheral abandons the first potential
4323 header and perform a new search using the 60 CDS bits following the second SPM.

238 Copyright © 2019–2024 MIPI Alliance, Inc.

4324 6. {xx06} If the Peripheral is part way through processing one Phase when it detects the Valid Phase
4325 Header according to Requirement 5 then it shall increment the EC_UnexpectedNewHeader error
4326 counter (see ###XREF: Section # Requirement #).
4327 Note:
4328 The EC_UnexpectedNewHeader counter counts _all_ instances of a new header, even if that
4329 Header is ignored because of Requirement 7. This contrasts with EC_AbandonedPhase,
4330 which counts only the Unexpected New Headers that are NOT rejected by Requirement 7.

4331 7. {xx07} A Peripheral shall ignore the new Phase Header (#2) detected according to Requirement 5
4332 when all of the following are true:
4333 A. The Peripheral is currently processing a Commit Phase (#1) or GetStatus Phase (#1), and
4334 B. The Peripheral saw no transport errors (either Bad_8b10b or CRC failure) in the Manager
4335 Packet in that Commit Phase (#1) or GetStatus Phase (#1), and
4336 C. The 60th bit of the new Phase Header (#2) described in Requirement 5 occurs more than 10
4337 bits after the last bit of the Manager_CRC_L symbol, and
4338 D. The 1st bit of the SPM in the new Phase Header (#2) (see Section 7.2.2 Requirement 5C and
4339 6C) occurs on or before either:
4340 i. For the Commit Phase (#1): the 10th bit of the Manager_Response symbol, or
4341 ii. For the Get_Status Phase(#1): the 10th bit of the Peripheral 11 PingInfo symbol.
4342 Note: the notation “(#1)” and “(#2)” in this requirement is used to help clarify which of the 2 Phases
4343 is the subject of each clause.

4344 8. {xx08} When the Peripheral detects a Valid Phase Header according to Requirement 5 and this
4345 Header is not ignored according to Requirement 7 then the Peripheral shall do all of:
4346 A. If the Peripheral is part way through processing one Phase then
4347 i. Increment the EC_AbandonedPhase error counter (see ###XREF: Section #
4348 Requirement #), and
4349 ii. Abandon the incomplete Phase and clean up as well as it can, and then
4350 B. Interpret the Header and any subsequent bytes according to the Table indicated in Table 61,
4351 and
4352 C. Generate a Peripheral Response that is: ###TODO-Author: need to skip this for Announce
4353 Phase
4354 i. Selected according to the Rules in Section 8.2.3, and
4355 ii. At the position in the Phase identified by PhaseID, Packet_Length, and DeviceNumber
4356 (###XREF to tables), and then:
4357 D. ###TODO-Author: rephrase this: <If that Peripheral Response was “positive”> obey the
4358 Command according to the rules in Section 9.2.
4359 Note: If the Peripheral transmits any Peripheral Response, this is always at the position indicated
4360 by the Packet_Length in the Header, even if this position is not what the Peripheral expected.
4361 However, the Peripheral will not transmit a Peripheral Response when the unexpected
4362 Packet_Length changes between zero and non-zero because this is not a Valid Phase Header (see
4363 Requirement 5D).

Copyright © 2019–2024 MIPI Alliance, Inc. 239

4364 9. {xx09} Where any of the rules in this Section (8.2.1) describe a byte being a Robust Token, this
4365 shall be:
4366 A. Selected from Robust Tokens 0 through 15 as indicated by the context columns in either:
4367 i. Table 63 for Robust Tokens transmitted by the Manager, or:
4368 ii. Table 64 for Robust Tokens transmitted by the Peripheral, and:
4369 B. Encoded using the symbol shown in Table 40 in Section 7.2.1 Requirement 9.
4370 Table 63 Assignment of Robust Token Numbers (Manager)

PhaseID Device_Mask_H[11:8] Packet_Length_H[7:4] Manager Response

Robust Device_Mask_M[7:4] Packet_Length_L[3:0] (HD10 Robust Tokens
Token Device_Mask_L[3:0] used in ReadSetup,
Number ReadData, & Commit
(decimal) Phases)

READ_DATA_OK
0 GET_STATUS 0000 0
CONFIRM_COMMIT

1 WRITE 0001 1 —

2 READ_SETUP 0010 2 —

3 READ_DATA 0011 3 —

4 COMMIT 0100 4 —

5 ANNOUNCE 0101 5 —

6 CALIBRATE_PHY 0110 6 —

7 — 0111 7 —

8 — 1000 8 —

9 — 1001 9 —

10 — 1010 10 —

11 — 1011 11 —

12 — 1100 12 —

13 — 1101 13 —

14 — 1110 14 —

READ_DATA_ERROR
15 — 1111 15
CANCEL_COMMIT

4371

240 Copyright © 2019–2024 MIPI Alliance, Inc.

4372 Table 64 Assignment of Robust Token Numbers (Peripheral)

Robust
Peripheral_Info Peripheral Response Calibration
Token
(GetStatus Phase for Ping (All Phases except SSPA, Result
Number
Command) ExitDormant, and GetStatus) (CalibratePhy Phase)
(decimal)

WRITE_OK
READ_DATA_NOW
0 PING_ATTACHED PHY_CAL_GOOD
COMMIT_READY
CALIBRATE_NOW

1 — — —

2 — COMMIT_NOT_READY —

3 — — —

WRITE_FAILED
4 — —
READ_FAILED

REMOTE_WRITE_BUFFERED
5 — —
REMOTE_READ_DEFERRED

6 PING_ATTACHED_BUSY REMOTE_WRITE_BUSY —

7 — REMOTE_ACCESS_DISABLED —

8 PING_ALERT — PHY_CAL_FAILED

9 — — —

10 PING_ALERT_BUSY — —

11 — — —

12 — PROTOCOL_ERROR —

13 COMMAND_ERROR COMMAND_ERROR —

14 TRANSPORT_ERROR TRANSPORT_ERROR TRANSPORT_ERROR

15 COMMANDS_BLOCKED COMMANDS_BLOCKED —

4373
4374
4375 10. ###TODO-Author: a rule that 8b/10b symbols encoded and decoded according to Section 7.2.1
4376 and Section 7.2.2.
4377 11. ###TODO-Author: describe Calibration Packets according to Section ###XREF.
4378 12. TODO extra DRUID number for Calibration Packets
4379 13. TODO extra DRUID number for Calibration Packets
4380

Copyright © 2019–2024 MIPI Alliance, Inc. 241

4381 14. Where the tables within this Section (i.e., Table 68 through Table 76) define a Protocol Spacer
4382 within the Phase structure, the Peripheral shall ignore the value received for a number of
4383 consecutive CDS bits according to Table 65.
4384 Table 65 Size of Protocol Spacer

Number of CDS Bits (Rows) in Spacer

ShortProtocolSpacer
(Register Field, see Manager to Peripheral to Peripheral to
Table 153) Peripheral (MP) Peripheral (PP) Manager (PM)

0 [1] 10 10 20

1 10 10 10

4385 Note:
1. Reset value of ShortProtocolSpacer is 0.

4386 15. Where the tables within this Section (i.e., Table 68 through Table 76) define a Protocol Spacer
4387 within the Phase structure, the Manager shall generate an idle pattern of alternating 0s and 1s for
4388 the number of consecutive CDS bits shown in Table 65.
4389 16. When the Peripheral executes an SSPA, SSCR, or DSCR Command, the Group Mask in the
4390 Command shall select Commit Group(s) according to Table 66.
4391 Table 66 Group Mask in SSPA, SSCR, and DSCR Commands

Bit in Group Mask What is Selected When That Bit is 1

All Registers, Data Ports, etc. that are members of Commit Group 0.
0
(includes PHY Control Registers and Link Control Registers).

1 All Registers, Data Ports, etc. that are members of Commit Group 1.

2 All Registers, Data Ports, etc. that are members of Commit Group 2.

3 All Registers, Data Ports, etc. that are members of Commit Group 3.

4–7 Reserved

4392 Note: When a Register, Data Port, etc. is a member of more than one Commit Group, this selection
4393 is an OR operation, i.e., the object is selected if any of the corresponding Group Mask bits is set: it
4394 does not require that all of the relevant bits are set.

242 Copyright © 2019–2024 MIPI Alliance, Inc.

4395 17. When the Peripheral executes an SSPA, SSCR, or DSCR Command, the Commit Sync Point
4396 and/or Stream Synchronization Point shall be delayed from the beginning of the Row that follows
4397 the 10th bit of the last 8b10b symbol in the Phase by a number of Rows indicated in Table 67.
4398 Note: for SSPA, the last symbol is Manager_CRC16_L; for SSCR and DSCR, the last symbol is
4399 Manager Response.

4400 Table 67 Sync Point Delay in SSPA, SSCR, and DSCR Commands

SyncPointOffset RowDelay Resulting Sync

(Register Field) (Command Parameter) Point Delay

0 15 15

0 14 14

1 15 14

1 14 13

2 15 13

2 14 12

3 15 12

3 14 11

4 15 11

4 14 10

5 15 10

5 14 9

4401
4402
4403
4404

Copyright © 2019–2024 MIPI Alliance, Inc. 243

4405 Table 68 GetStatus Phase for Ping Command

Byte
Name Sent By Details
Number

SPM + 6 Robust Tokens (see Table 63):

Header • PhaseId=GET_STATUS
0 to 6 Manager
(see Table 60) • DeviceMask selects from 1 to 12 Peripherals
• Packet_Length=0x01

Opcode=0x00 (Ping)
7 Manager Packet Manager
(see Section 9.2.8 Requirement ###XREF)

8 16-bit CRC calculated on the Manager Packet

Manager_CRC Manager
9 (byte 7)

10 bits of idle pattern (ignored by Peripheral) to

10 Protocol Spacer Manager
give the Peripheral time to react to the Header.

11 Peripheral 0

12 Peripheral 1

13 Peripheral 2

14 Peripheral 3

15 Peripheral 4

16 Peripheral Peripheral 5
One Robust Token from each Peripheral
PingInfo
(see Section 9.2.8 Requirement ###XREF)
17 (see Table 87) Peripheral 6

18 Peripheral 7

19 Peripheral 8

20 Peripheral 9

21 Peripheral 10

22 Peripheral 11

244 Copyright © 2019–2024 MIPI Alliance, Inc.

4406 Table 69 Announce Phase for SSPA Command

Byte
Name Sent By Details
Number

SPM + 6 Robust Tokens (see Table 63):

Header • PhaseId=ANNOUNCE
0 to 6 Manager
(see Table 60) • DeviceMask selects from 1 to 12 Peripherals
• Packet_Length=0x03

Opcode=0x00 (SSPA)
7
(see Section ###XREF Requirement ###XREF)

Manager Packet Manager Group Mask

8
(see Section ###XREF Requirement ###XREF)

9 Row Delay (see Table 67)

10 16-bit CRC calculated on the Manager Packet

Manager_CRC Manager
11 (bytes 7 through 9)

4407 Table 70 Announce Phase for ExitDormant Command

Byte
Name Sent By Details
Number

SPM + 6 Robust Tokens (see Table 63):

Header • PhaseId=ANNOUNCE
0 to 6 Manager
(see Table 60) • DeviceMask selects from 1 to 12 Peripherals
• Packet_Length=0x01

Opcode=0x01 (ExitDormant)
7 Manager Packet Manager
(see Section ###XREF Requirement ###XREF)

8 16-bit CRC calculated on the Manager Packet

Manager_CRC Manager
9 (byte 7)

Copyright © 2019–2024 MIPI Alliance, Inc. 245

4408 Table 71 Commit Phase for SSCR and DSCR Commands

Byte
Name Sent By Details
Number

SPM + 6 Robust Tokens (see Table 63):

Header • PhaseId=COMMIT
0 to 6 Manager
(see Table 60) • DeviceMask selects from 1 to 12 Peripherals
• Packet_Length=0x03

Opcode:
• 0x00 (SSCR) or
7
• 0x01 (DSCR)
(see Section 9.2.7 Requirement ###XREF)
Manager Packet Manager
Group Mask
8
(see Section 9.2.7 Requirement ###XREF)

9 Row Delay (see Table 67)

10 16-bit CRC calculated on the Manager Packet

Manager_CRC Manager
11 (bytes 7 through 9)

10 bits of idle pattern (ignored by Peripheral) to

12 Protocol Spacer Manager
give the Peripheral time to react to the Header.

13 Peripheral 0

14 Peripheral 1

15 Peripheral 2

16 Peripheral 3

17 Peripheral 4

Peripheral
18 Peripheral 5 One Robust Token from each Peripheral
Responses
(see Section 9.2.7 Requirement ###XREF)
(see Table 84)
19 Peripheral 6

20 Peripheral 7

21 Peripheral 8

22 Peripheral 9

23 Peripheral 10

24 Peripheral 11

246 Copyright © 2019–2024 MIPI Alliance, Inc.

Byte
Name Sent By Details
Number

10 bits of idle pattern (ignored by Peripheral) to

25 Protocol Spacer Manager
give the Manager time to react to the Responses.

Programmable extra 10 bits of idle pattern (ignored

[1] Extra Bits of PM by Peripheral) to give the Manager more time to
26 Manager
Protocol Spacer react to the Responses
(see Table 65 in Requirement 14).

26 or Manager One Robust Token

Manager
27 [1] Response (see Section 9.2.7 Requirement ###XREF).

1. When ShortProtocolSpacer=0, the Peripheral-to-Manager Protocol Spacer also occupies byte 26,
so the Manager Response is at byte 27.

Copyright © 2019–2024 MIPI Alliance, Inc. 247

4409 Table 72 Write Phase for WriteA32 Command

Byte Number Name Sent By Details

SPM + 6 Robust Tokens (see Table 63):

Header • PhaseId=WRITE
0 to 6 Manager • DeviceMask selects 1 Peripheral
(see Table 60)
• Packet_Length = (5 + WBC), where
WBC is the number of write data bytes.

7 Opcode=0x00 (WriteA32)

WriteAddress Bits 31:24

8
(see Section 9.2.3 Requirement ###XREF)

9 WriteAddress Bits 23:16

Manager Packet Manager
10 WriteAddress Bits 15:08

11 WriteAddress Bits 07:00

(11 + 1) Block of data bytes.

to
Number of bytes (WBC) = (PacketLength – 5)
(11 + WBC)

(12 + WBC) 16-bit CRC calculated on the Manager Packet

Manager_CRC Manager
(13 + WBC) (bytes 7 through (11 + WBC))

10 bits of idle pattern (ignored by Peripheral) to

(14 + WBC) Protocol Spacer Manager
give the Peripheral time to react to the Header.

Peripheral
One Robust Token from the selected Peripheral
(15 + WBC) Response Peripheral
(see Section 9.2.3 Requirement ###XREF)
(see Table 81)

248 Copyright © 2019–2024 MIPI Alliance, Inc.

4410 Table 73 Write Phase for Unblock Command

Byte Number Name Sent By Details

SPM + 6 Robust Tokens (see Table 63):

Header • PhaseId=WRITE
0 to 6 Manager
(see Table 60) • DeviceMask selects 1 Peripheral
• Packet_Length=0x01

7 Manager Packet Manager Opcode=0x01 (Unblock)

8 16-bit CRC calculated on the Manager Packet

Manager_CRC Manager
9 (byte 7)

10 bits of idle pattern (ignored by Peripheral) to

10 Protocol Spacer Manager
give the Peripheral time to react to the Header.

Peripheral
One Robust Token from the selected Peripheral
11 Response Peripheral
(see Section 9.2.9 Requirement ###XREF)
(see Table 80)

Copyright © 2019–2024 MIPI Alliance, Inc. 249

4411 Table 74 ReadSetup Phase for ReadA32 Command

Byte Number Name Sent By Details

SPM + 6 Robust Tokens (see Table 63):

Header • PhaseId=READ_SETUP
0 to 6 Manager
(see Table 60) • DeviceMask selects 1 Peripheral
• Packet_Length=0x06

7 Opcode=0x00 (ReadA32)

R: Excess-1 encoded value:

Actual Read Byte Count (RBC) = R + 1.
Total number of bytes to read.
8 R=0: RBC=1 byte
R=1: RBC=2 bytes
…
R=255: RBC=256 bytes.
Manager Packet Manager (see Section 9.2.4 Requirement ###XREF).

ReadAddress Bits 31:24

9
(see Section 9.2.4 Requirement ###XREF)

10 ReadAddress Bits 23:16

11 ReadAddress Bits 15:08

12 ReadAddress Bits 07:00

13 16-bit CRC calculated on the Manager Packet

Manager_CRC Manager
14 (bytes 7 through 12)

10 bits of idle pattern (ignored by Peripheral) to

15 Protocol Spacer Manager
give the Peripheral time to react to the Header.

Peripheral
One Robust Token from the selected Peripheral
16 Response [1, 2, 3] Peripheral
(see Section 9.2.4 Requirement ###XREF)
(see Table 82)

Phase terminates here after some Peripheral Responses [1, 2, 3]

10 bits of idle pattern (ignored by Peripheral) to

17 Protocol Spacer [4] Manager
give the Manager time to react to the Response.

(18 + 0)
(R + 1) bytes of read data from the selected
to Peripheral Packet Peripheral
Peripheral
(18 + R)

(19 + R) CRC calculated on the Peripheral Packet (bytes

Peripheral_CRC Peripheral
(20 + R) 18 through (18 + R))

10 bits of idle pattern (ignored by Peripheral) to

(21 + R) Protocol Spacer Manager
give the Manager time to react to the CRC.

250 Copyright © 2019–2024 MIPI Alliance, Inc.

Byte Number Name Sent By Details

Programmable extra 10 bits of idle pattern

Extra Bits of PM (ignored by Peripheral) to give the Manager more
(22 + R) [5] Manager
Protocol Spacer time to react to the CRC
(see Table 65 in Requirement 14).

(22 + R) or Manager One Robust Token

Manager
(23 + R) [5] Response (see Section 9.2.7 Requirement ###XREF)

1. If the Peripheral generates any Peripheral Response except for READ_DATA_NOW then it
considers the Phase to be complete after the Peripheral Response (byte #16).
2. If the Manager receives any defined Peripheral Response except for READ_DATA_NOW then it
considers the Phase to be complete after the Peripheral Response (byte #16).
3. If the Manager receives a Peripheral Response of READ_DATA_NOW or a bad or unexpected
Robust Token (i.e., one that is not a defined Peripheral Response) then it considers the Read
Phase to be complete after the Manager Response (byte #(22 + R)).
4. The Manager always owns the 10 bits following the Peripheral Response, and drives Idle Pattern
/ Protocol Spacer unless it has already recognized a Peripheral Response that ends the Phase, in
which case it might start driving an SPM during these 10 bits.
5. When ShortProtocolSpacer=0, the Peripheral-to-Manager Protocol Spacer also occupies byte
(22 + R), so the Manager Response is at (23 + R).

4412 ###TODO: add XREFs from these footnotes to the Manager Response table.
4413
4414 Table 75 ReadData Phase for Completing a ReadA32 Command

Byte Number Name Sent By Details

SPM + 6 Robust Tokens (see Table 63):

Header • PhaseId=READ_DATA
0 to 6 Manager
(see Table 60) • DeviceMask selects 1 Peripheral
• Packet_Length=0x00

10 bits of idle pattern (ignored by Peripheral) to

7 Protocol Spacer Manager
give the Peripheral time to react to the Header.

Peripheral
One Robust Token from the selected Peripheral
8 Response [1, 2, 3] Peripheral
(see Section 9.2.4 Requirement ###XREF)
(see Table 83)

Phase terminates here after some Peripheral Responses [1, 2, 3]

10 bits of idle pattern (ignored by Peripheral) to

9 Protocol Spacer [4] Manager
give the Manager time to react to the Response.

(10 + 0)
(R + 1)[5] bytes of read data from the selected
to Peripheral Packet Peripheral
Peripheral
(10 + R) [5]

(11 + R) [5] 16-bit CRC calculated on the Peripheral Packet

Peripheral_CRC Peripheral
(12 + R) [5] (bytes 10 through (10 + R))

Copyright © 2019–2024 MIPI Alliance, Inc. 251

Byte Number Name Sent By Details

10 bits of idle pattern (ignored by Peripheral) to

(13 + R) [5] Protocol Spacer Manager
give the Manager time to react to the CRC.

Programmable extra 10 bits of idle pattern

Extra Bits of PM (ignored by Peripheral) to give the Manager time
(14 + R) [5,6] Manager
Protocol Spacer to react to the CRC
(see Table 65 in Requirement 14).

(14 + R) or Manager One Robust Token

Manager
(15 + R) [5,6] Response (see Section 9.2.7 Requirement ###XREF)

1. If the Peripheral generates any Peripheral Response except for READ_DATA_NOW then it
considers the Phase to be complete after the Peripheral Response (byte #8).
2. If the Manager receives any defined Peripheral Response except for READ_DATA_NOW then it
considers the Phase to be complete after the Peripheral Response (byte #8).
3. If the Manager receives a Peripheral Response of READ_DATA_NOW or a bad or unexpected
Robust Token (i.e., one that is not a defined Peripheral Response) then it considers the Read
Phase to be complete after the Manager Response (byte #(14 + R)).
4. The Manager always owns the 10 bits following the Peripheral Response, and drives Idle Pattern
/ Protocol Spacer unless it has already recognized a Peripheral Response that ends the Phase, in
which case it might start driving an SPM during these 10 bits.
5. R is the encoded ReadByteCount parameter from the original ReadSetup Phase.
6. When ShortProtocolSpacer=0, the Peripheral-to-Manager Protocol Spacer also occupies byte
(14 + R) and the Manager Response is at (15 + R).

252 Copyright © 2019–2024 MIPI Alliance, Inc.

4415 Table 76 CalibratePhy Phase for InitCal and TrimCal Commands

Byte
Name Sent By Details
Number

SPM + 6 Robust Tokens (see Table 63):

Header • PhaseId=CALIBRATE_PHY
0 to 6 Manager
(see Table 60) • DeviceMask selects 1 Peripheral
• Packet_Length=0x03

Opcode:
• 0x00 (InitCal) or
7
• 0x01 (TrimCal)
(see Section 9.2.10 Requirement ###XREF)

Manager Packet Manager CalibrationLength (N)

8
(see Section 9.2.10 Requirement ###XREF)

AdjustLength (A)
9
(see Section 9.2.10 Requirement ###XREF)

10 16-bit CRC calculated on the 3 bytes of the

Manager_CRC Manager
11 Manager Packet (bytes 7 through 9).

10 bits of idle pattern (ignored by Peripheral) to

12 Protocol Spacer Manager
give the Peripheral time to react to the Header.

Peripheral Response One Robust Token from the Selected Peripheral

13 Peripheral
(see Table 85) (see Section 9.2.10 Requirement ###XREF)

Phase terminates here after some Peripheral Responses [1, 2, 3]

10 bits of idle pattern (ignored by Peripheral) to

14 Protocol Spacer [4] Manager
give the Manager time to react to the Response.

Conditional part of Phase [1, 2, 3]

The Calibration data consumes space of (30 × (N+1)) CDS bits, which is equivalent to (3 × (N+1))
8b/10b symbols.
See Section 9.2.10.

10 bits of idle pattern (ignored by Peripheral) to

15 +
Protocol Spacer Manager give the Peripheral time to react to the
(3 × (N+1))
calibration feedback.

Conditional part of Phase [1, 2, 3]

16 + Calibration Result
Peripheral One Robust Token from the Selected Peripheral
(3 × (N+1)) (see Table 86)
(see Section 9.2.10 Requirement ###XREF)

4416 Note:
1. If the Peripheral generates any Peripheral Response except for CALIBRATE_NOW then it
considers the CalibratePhy Phase to be complete after the Peripheral Response (byte #13).
2. If the Manager receives any defined Peripheral Response except for CALIBRATE_NOW then it
considers the CalibratePhy Phase to be complete after the Peripheral Response (byte #13).

Copyright © 2019–2024 MIPI Alliance, Inc. 253

3. If the Manager receives a Peripheral Response of CALIBRATE_NOW or a bad or unexpected

Robust Token (i.e., one that is not a defined Peripheral Response) then it considers the
CalibratePhy Phase to be complete after the Calibration Result (byte #(16 + (3 × (N+1)))).
4. The Manager always owns the 10 bits following the Peripheral Response, and drives Idle
Pattern/Prootocol Spacer unless it has already recognized a Peripheral Response that ends the
Phase, in which case it might start driving an SPM during these 10 bits.
4417 ###TODO: add XREFs from these footnotes to the Manager Response table.
4418
4419
4420 ###TODO-Author: consider where to put the boundary between portrait and landscape sections:
4421 A. Before the heading for Section 8.2 Specifications (normative)?
4422 B. Before the heading for Section 8.2.3 Peripheral Responses to Phases?
4423

4424 Permissions
4425 ###TODO-Author: add a permission for the Manager to drive an Idle Pattern in Rows that correspond to
4426 the Peripheral Response(s) from Peripheral(s) that is/are not selected in a Commit or Ping Phase.
4427 1. .
4428
4429

8.2.2 CRC for Command Transport Protocol

4430 Requirements
4431 1. When a Peripheral receives a Manager Packet, it shall calculate a CRC on the Manager Packet
4432 data bytes and check this against the Manager CRC from the last 2 bytes.
4433 2. When a Manager receives a Peripheral Packet, it shall calculate a CRC on the Peripheral Packet
4434 data bytes and check this against the Peripheral CRC from the last 2 bytes.
4435 3. When a Device receives a Packet according to Requirement 1 or 2, if any of the Packet data bytes
4436 or CRC bytes generated an 8b10b decoding error then the Device shall:
4437 A. Not check the CRC value (because the 8b10b error is already a Transport Error), and
4438 B. Not increment the EC_BadCRC counter (see Table 163).
4439 4. When calculating a CRC, a Device shall use the generator polynomial:
4440 x16 + x15 + x13 + x9 + x7 + x6 + x5 + x3 + x + 1
4441 with the variable, X, initialized to 0x0000 at the start of the calculation.
4442 5. When calculating a CRC, a Device shall re-initialize the state variable before processing the first
4443 bit of the Manager or Peripheral Packet.
4444 Note: i.e., each CRC is independent of all previous CRCs
4445 6. When calculating a CRC, a Device shall process 8-bit bytes, not 10-bit symbols.
4446 Note: i.e., before 8b10b encoding in the transmitter and after 8b10b decoding in the receiver.
4447 7. When calculating a CRC, a Device shall process the bytes in the order that they are transported.
4448 Note: i.e., lowest numbered bytes first.
4449 8. When calculating a CRC, a Device shall process the bits of a byte starting with bit 7 (MSb) and
4450 finishing with bit 0 (LSb).

254 Copyright © 2019–2024 MIPI Alliance, Inc.

8.2.3 Peripheral Responses to Phases

4451 Requirements
4452 1. {xxxx} When the Command Execution State is Blocked (see Section 9.2.1 Requirement 1), the Peripheral shall generate a Peripheral Response
4453 according to Table 77.
4454 Table 77 Peripheral Responses When Command Execution State is Blocked

Prioritized Conditions in Peripheral

Bad Phase Header Device is SPM Transport Error in This is an Bad Command Info in
i.e., one of: Correctly Selected Received Manager Packet [3] Unblock Manager Packet [3]
• Bad Robust Token by DeviceMask During i.e., one of: Command i.e.,
• Bad PhaseID [1] (see Table 62) Manager • Bad 8b/10b • Packet_Length
• Bad Packet_Length[2] Packet or Symbol not valid for
CRC • Bad CRC Unblock Opcode Peripheral Response

YES [4] X [5] X X X X No Response

NO [4] NO [4] X X X X No Response

NO YES YES X X X No Response

NO YES NO YES [6] X X COMMANDS_BLOCKED

NO YES NO NO NO X COMMANDS_BLOCKED

NO YES NO NO YES YES COMMANDS_BLOCKED

NO YES NO NO YES NO WRITE_OK

4455 Note:
1. Bad PhaseID includes both Reserved and unimplemented values of PhaseID (i.e., READ_DATA or CALIBRATE_PHY in a Peripheral that does not
support the corresponding phase types).
2. Bad Packet_Length means non-zero for ReadData Phase or zero for any other Phase.
3. There is no Manager Packet in a ReadData Phase.
4. Bad Phase Header and Not Selected are identical to the first 2 Rows in Table 78.
5. ‘X’ represents “don’t care”.
6. Note that COMMANDS_BLOCKED takes precedence over TRANSPORT_ERROR even when there is a transport error in the Manager Packet.
4456 Note: The prioritization of Peripheral Responses in Table 77 is illustrated in the informative flowchart in Figure 87.

Copyright © 2019–2024 MIPI Alliance, Inc. 255

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
4457 2. {xxxx} When the Command Execution State is Running (see Section 9.2.1 Requirement 1), the Peripheral shall generate a Peripheral Response
4458 according to Table 78.
4459 Table 78 Peripheral Responses Common to All Phases When Command Execution State is not Blocked

Prioritized Conditions in Peripheral

Bad Phase Header Device is SPM Transport Error in Bad Command Info in
i.e., one of: Correctly Received Manager Packet [3] Manager Packet [3]
• Bad Robust Token Selected by During i.e., one of: e.g.,
• Bad PhaseID[1] DeviceMask Manager • Bad 8b/10b • Bad Opcode
• Bad Packet_Length [2] (see Table 62) Packet or Symbol • Packet_Length not
CRC • Bad CRC valid for this Opcode [4]
• Parameters not valid
for this Opcode [5] or
Device [6] Peripheral Response

YES X [7] X X X No Response

NO NO X X X No Response

NO YES YES X X No Response

NO YES NO YES X TRANSPORT_ERROR [4]

NO YES NO NO YES COMMAND_ERROR [4]

See table that is specific to

NO YES NO NO NO Phase Type and Command (see
Table 79).

4460 Note:
1. Bad PhaseID includes both Reserved and unimplented values of PhaseID (i.e., READ_DATA or CALIBRATE_PHY in a Peripheral that does not support
the corresponding phase types).
2. Bad Packet_Length means non-zero for ReadData Phase or zero for any other Phase.
3. There is no Manager Packet in a ReadData Phase.
4. The Peripheral Response always occurs at the position identified by the Packet_Length field from the Header, even if that was not a valid packet length
for this Opcode (see Section ###XREF Requirement ###XREF).
5. E.g., Commit Delay not in the set {14, 15}.
6. E.g., An address in the remote region for Peripherals that do not implement remote writes and reads (see Section 9.2.3 Permission 2.A and
Section 9.2.4 Permission 2.A).
7. ‘X’ represents “don’t care”.

256 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
4461 Note: The prioritization of Peripheral Responses in Table 78 is illustrated in the informative flowchart in Figure 87.

Copyright © 2019–2024 MIPI Alliance, Inc. 257

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
4462 Table 79 Phase- and Command-Specific Responses When Commands are Not Blocked

Command(s) Phase/Command-Specific Informative Flowchart(s)

PhaseId
(Opcode in Manager Packet) Peripheral Responses Specified in: illustrating Peripheral Responses:

Write Unblock Table 80 Figure 92

Figure 93
Write WriteA32 Table 81
Figure 96

Figure 94
ReadSetup ReadA32 Table 82
Figure 98

ReadData (ReadA32) [1] Table 83 Figure 98

SSCR
Commit Table 84 Figure 91
DSCR

InitCal
CalibratePhy Table 85 Figure 95
TrimCal

GetStatus Ping Table 87 Figure 89

1. The ReadData Phase does not have a Manager Packet so does not have an Opcode but is associated with the incomplete ReadA32 Command from
the previous ReadSetup Phase.

4463 Table 80 Peripheral Responses Specific to a Write Phase (Unblock Command)

Response to Condition is Already Described Peripheral Response

in the Common Error Responses in Table 78

YES See Common Error Responses in Table 78.

No WRITE_OK [1]

1. The Unblock Command has no effect on the Peripheral when the Command Execution State is not Blocked.

258 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
4464 Table 81 Peripheral Responses Specific to a Write Phase (WriteA32 Command)

Peripheral Command Address is Remote Access State Remote Access This Write (Immediate) Result Peripheral Response
Interpreter Ignored Remote is Remote_Disabled[2] State is Operation of Write Operation
the Command (see Remote_Write_ is Buffered was Failed
Because of a Table 98) Busy[3] for Later e.g., internal error.
Common Error Execution (See Section 9.2.3
(see Table 78) Requirement 16.)

See Common Error

YES X X X X X
Responses in Table 78.

No No X X X YES WRITE_FAILED

No No X X X No WRITE_OK

No YES [1] YES X X X REMOTE_ACCESS_DISABLED [4]

No YES [1] No YES X X REMOTE_WRITE_BUSY [4]

No YES [1] No No YES X REMOTE_WRITE_BUFFERED [4]

No YES [1] No No No YES WRITE_FAILED

No YES [1] No No No No WRITE_OK

1. Remote Addresses are not used for any of the SWI3S Registers, but might be used for resources that are implementation-defined or are defined by
other Specifications.
2. Remote Access State of Remote_Disabled (see Section 9.2.2) occurs when a previous Remote Read or Remote Write ended in failure.
3. An unfinished remote write operation is not pre-empted by a new remote write, so it is non-destructive for the Manager to attempt the new remote write
without checking the status of the previously buffered remote write. This contrasts with a deferred remote read, which is pre-empted by either of a new
remote read or remote write (see Section 9.2.2).
4. The 3 responses: REMOTE_ACCESS_DISABLED, REMOTE_WRITE_BUSY, and REMOTE_WRITE_BUFFERED apply only to write commands to the
optional remote address space.

Copyright © 2019–2024 MIPI Alliance, Inc. 259

4465 Table 82 Peripheral Responses Specific to ReadSetup Phase

Peripheral Command Address is Remote Access Remote Access Read Operation Remote ReadData is Peripheral Response
Interpreter Ignored Remote State is State is Failed Immediately Ready Immediately [4]
the Command (see Table 101) Remote_Disabled Remote_Write_Busy e.g., internal error.
[2] [3]
Because of a
Common Error

See Common Error Responses

YES X X X X X
in Table 78.

No No X X YES X READ_FAILED

No No X X No X READ_DATA_NOW

No YES [1] YES X X X REMOTE_ACCESS_DISABLED [4]

No YES [1] No YES X X REMOTE_WRITE_BUSY [4]

No YES [1] No No YES X READ_FAILED

No YES [1] No No No YES READ_DATA_NOW

No YES [1] No No No No REMOTE_READ_DEFERRED [4]

1. Remote Addresses are not used for any of the SWI3S-defined Registers, but might be used for resources that are implementation-defined or are
defined by other Specifications.
2. Remote Access State of Remote_Disabled (see Section 9.2.2) occurs when a previous Remote Read or Remote Write ended in failure.
3. An unfinished Remote Write operation is NOT pre-empted by a new Remote Read, so it is non-destructive for the Manager to attempt the new Remote
Read without checking the status of the previously buffered Remote Write. This contrasts with a deferred Remote Read, which is pre-empted by either
of a new Remote Read or Remote Write (see Section 9.2.2).
4. The 3 responses: REMOTE_ACCESS_DISABLED, REMOTE_WRITE_BUSY, and REMOTE_ READ_DEFERRED apply only to read commands to the
optional remote read address space.
4466

260 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
4467 Table 83 Peripheral Responses Specific to ReadData Phase

Peripheral Command Remote Access Remote Access Remote Access

Interpreter Ignored the State is State is State is
Command Because of Remote_Disabled Remote_Read_Busy Remote_Read_
a Common Error (i.e., Peripheral not DataReady
Ready to Provide
Read Data) Peripheral Response

YES X X X See Common Error Responses in Table 78.

No YES X X REMOTE_ACCESS_DISABLED [1]

No No YES X REMOTE_READ_DEFERRED

No No No YES READ_DATA_NOW

No No No No PROTOCOL_ERROR [2]

4468 Note:
1. Deferred remote read operations are considered to occur outside of Phases (even if the actual operations overlap in time), Thus, if a deferred read
subsequently fails then the response to the ReadData Phase will either be REMOTE_ACCESS_DISABLED if the failure occurs before the response is
selected), or REMOTE_READ_DEFERRED (if the failure occurs after the response is selected). A ReadData Phase can never receive a
READ_FAILED response.
2. Devices that do not implement any remote addresses might still implement the ReadData Phase, in which case the Remote Access State is effectively
always Remote_Idle, and the Peripheral Response will be PROTOCOL_ERROR.

Copyright © 2019–2024 MIPI Alliance, Inc. 261

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
4469 Table 84 Peripheral Responses Specific to Commit Phase

Peripheral cannot Accept the SSCR/DSCR

Operation
Examples why a Peripheral might generate
Peripheral Command COMMIT_NOT_READY (all optional):
Interpreter Ignored the • A channel prepare operation is not complete
Command Because of a (PrepareCh<c> ≠ ReadyCh<c>).
Common Error • Remote_RW are disabled.
• Remote_RW_Buffer is not empty.
• Unsupported clock configuration in the
_NEXT Registers. [1]
• Other ImpDef fault conditions. Peripheral Response

YES X See Common Error Responses in Table 78.

No YES COMMIT_NOT_READY

No No COMMIT_READY

4470 Note:
1. Note: Detecting this is optional, see ###XREF.
4471 ###TODO-Author: Text for somewhere else … Some Devices will not check for unsupported clock configurations, so commiting an unsupported
4472 configuration might cause a Peripheral to detach from the bus and not reappear until it is reset.
4473 ###TODO-Author: add a note in the informative section that COMMIT_NOT_READY can happen for any ImpDef reason. There should be a way for the
4474 software to determine the condition and fix it (e.g., an overtemp interrupt in the amplifier).
4475
4476 Table 85 Peripheral Responses Specific to CalibratePhy Phase

Peripheral Command Interpreter

Ignored the Command Because
of a Common Error
Peripheral Response

YES See Common Error Responses in Table 78.

No CALIBRATE_NOW

4477

262 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
4478 Table 86 Peripheral Calibration Result to CalibratePhy Phase

Peripheral Received Invalid Peripheral PHY

Manager Feedback Data Calibration Algorithm
(i.e., Some R/not-R Values Were Failed to Calibrate
Not Complementary) Peripheral PHY Calibration Result

YES X TRANSPORT_ERROR

No YES PHY_CAL_FAILED [#1]

No No PHY_CAL_GOOD

1. A Calibration result of PHY_CAL_FAILED is typically followed by a InitCal Command.

4479
4480 Table 87 Peripheral Responses to GetStatus Phase

Peripheral Command Interpreter Peripheral Has An Active Peripheral has an

Ignored the Command Because Unmasked Interrupt incomplete Buffered Write [#1] or
of a Common Error incomplete Split Read [#2] Peripheral Response

YES X X See Common Error Responses in Table 78.

No YES YES PING_ALERT_BUSY

No YES No PING_ALERT

No No YES PING_ATTACHED_BUSY

No No No PING_ATTACHED

1. Incomplete Buffered Write means that the internal write operation has not yet reached one of success or failure.
2. Incomplete Split Read means that the internal read operation has not yet reached one of success or failure (this condition is NOT checking for whether
the read data has been delivered to the Manager).
4481
4482 ###notes:
4483 REQUIREMENT: When A Peripheral generates a Peripheral Response of READ_DATA_NOW in a ReadSetup or ReadData Phase it shall ###TODO: <follow
4484 this with a Peripheral Packet and CRC>.

Copyright © 2019–2024 MIPI Alliance, Inc. 263

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
4485 REQUIREMENT: When A Peripheral generates a Peripheral Response of REMOTE_READ_DEFERRED in a ReadSetup Phase it shall ###TODO: <set some
4486 state to indicate that a multi-phase Read Transfer is in progress>
4487 ###TODO: description of CalibratePhy Phase … generate a Calibration Result according to Table 86.
4488

264 Copyright © 2019–2024 MIPI Alliance, Inc.

8.2.4 Manager Responses to Phases

4489 Requirements
4490 ###Note for Reviewers: the prioritization of error conditions and responses is shown in the informative material in flowcharts (see Section 8.1.3).
4491 REQUIREMENT: A Manager shall generate a Manager Response in a ReadSetup Phase according to Table 88.
4492 Table 88 Manager Response in ReadSetup Phase

Bad Peripheral Peripheral Terminated the Peripheral not Ready Peripheral Transferred Peripheral Transferred
Response Read Transfer Properly to Provide Read Data Data with Transport Data Successfully [1]
i.e., one of i.e., Peripheral Response of: i.e., Peripheral Errors i.e., Peripheral
• Bad 8b/10b COMMANDS_BLOCKED Response of: i.e., Peripheral Response Response of:
Symbol TRANSPORT_ERROR REMOTE_READ_ of: READ_DATA_NOW
• Bad Robust COMMAND_ERROR DEFERRED READ_DATA_NOW
Token with no Transport Errors
REMOTE_ACCESS_DISABLED with one of:
• Unexpected
Robust REMOTE_WRITE_BUSY • Bad 8b/10b Symbol
Token READ_FAILED • CRC fail Manager Response

YES X X X X READ_DATA_ERROR

Terminate the Phase

after the Peripheral
No YES X X X Response. []
(No Manager
Response)

Terminate the Phase

after the Peripheral
No No YES X X Response.
(No Manager
Response)

No No No YES X READ_DATA_ERROR

No No No No (YES) [1] READ_DATA_OK

1. The condition in column 5 is the complement of the first 4 columns, i.e., after 4 “No” entries column 5 must be “YES”.
2. See Section # Requirement #.

Copyright © 2019–2024 MIPI Alliance, Inc. 265

4493 REQUIREMENT: A Manager shall generate a Manager Response in a ReadData Phase according to Table 89.
4494 Table 89 Manager Response in ReadData Phase

Bad Peripheral Peripheral Terminated the Peripheral not Ready Peripheral Transferred Peripheral Transferred
Response Read Transfer Properly to Provide Read Data Data with Transport Data Successfully
i.e., one of i.e., Peripheral Response of: i.e., Peripheral Errors i.e., Peripheral
• Bad 8b/10b COMMANDS_BLOCKED Response of: i.e., Peripheral Response of:
Symbol REMOTE_READ_ Response of: READ_DATA_NOW
PROTOCOL_ERROR
• Bad Robust DEFERRED READ_DATA_NOW
Token REMOTE_ACCESS_DISABLED with no Transport Errors
• Unexpected with one of:
Robust • Bad 8b/10b
Token Symbol
• CRC fail Manager Response

YES X X X X READ_DATA_ERROR

(No Manager
No YES X X X
Response)

(No Manager
No No YES X X
Response)

No No No YES X READ_DATA_ERROR

No No No No (YES) READ_DATA_OK

266 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
4495 REQUIREMENT: A Manager shall generate a Manager Response in a Commit Phase according to Table 90.
4496 Table 90 Manager Response in Commit Phase

Transport Error in One or more Responses Valid Response from a All Populated & Manager Response
Peripheral Response of not-Ready from a Peripheral Selected Peripherals
from a Peripheral Peripheral DeviceNumber that is are Ready
DeviceNumber that is DeviceNumber that is Populated but not i.e., Peripheral
Populated & Selected Populated & Selected Selected Responses of:
i.e., one of i.e., a Peripheral i.e., one of: COMMIT_READY
• Bad 8b/10b Symbol Response of anything COMMANDS_BLOCKED
• Bad Robust Token except for: TRANSPORT_ERROR
• Unexpected Robust COMMIT_READY COMMAND_ERROR
Token COMMIT_NOT_READY
COMMIT_READY

YES — — — CANCEL_COMMIT

No YES — — CANCEL_COMMIT

No No YES — CANCEL_COMMIT

No No No YES CONFIRM_COMMIT

4497 Permissions
4498 ###TODO-Author: rule relating to Read Command in Section 9.1.8:
4499 1. When the Manager terminates the Read Phase early as a result of the Peripheral Response (see Table 88) it may start a new Phase immediately after the
4500 Peripheral Response.

Copyright © 2019–2024 MIPI Alliance, Inc. 267

8.2.5 Command Transport Protocol Errors

4501 Requirements

268 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
9 Commands
4502 This section describes the control and status Commands used in SWI3S for managing the SWI3S link, the payload
4503 transport, and other functions within the Peripherals, and introduces the Register Model for how these Commands
4504 read and write registers. These Commands are transported between the Manager and Peripherals using the
4505 Command Transport Protocol. The position of Commands with respect to other layers is illustrated in Figure 113.
4506 (The complete version of this stack is shown in Figure 15 in Section 4.4.1). The Command Transport Protocol is
4507 described in Section 8 and the Control Data Stream in Section 7.

SWI3S Registers
Peripheral Command
Non-SWI3S Registers (local)
Model for Registers Non-SWI3S Registers (remote)

Ping, Unblock, SSPA, ExitDormant

ReadA32, WriteA32
Commands Stream-Synchronous Commit Request (SSCR)
Device Synchronous Commit Request (DSCR)
InitCal, TrimCal

Transfers
Command Transport Phases
Protocol Elements of Phases
Bytes

8b/10b Encoding (K-Codes & D-Codes)

Control Data Stream 30-bit PHY Calibration Blocks
Bits & Symbols Undriven Bits
Idle Bits

E.g.,
Impedance,
PHY, e.g., DLV Signaling Levels,
Signal Timing.
4508
Figure 113 Layer Stack: Commands and Register Model

9.1 Description (informative)

9.1.1 Overview of Commands

4509 A Command is the operation conveyed by the Command Transport Protocol. It describes an action to be performed
4510 in the Peripheral, along with parameters and/or a result. Commands can be categorized as:
4511 • Basic operations for link and peripheral status and control.
4512 • Read and write transactions for accessing address-mapped registers.
4513 • Synchronization operations for orchestrating simultaneous behavior in 1 or more Peripherals.
4514 • Special transactions to support dynamic calibration of low-level timing delays.
4515 Commands are transported using the Transfers defined in the Command Transport Protocol (see Section 8.1.1.3).
4516 The first byte of the Manager Packet within the Transfer is an Opcode that identifies the Command (see Table 95).
4517 Table 91 is a summary of the Commands, and which type of Transfer is used to transport them.
4518 ###TODO-Author: make this table fit onto one page.

Copyright © 2019–2024 MIPI Alliance, Inc. 269

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
4519 Table 91 Summary of Commands

Command Long Name Length Transfer Type Description

& Opcode (see Section) (in Rows) / PhaseId
Name (see Section)

Ping GetStatus Read back basic status info

Ping 230
9.1.5 8.1.6 from some or all Peripherals.

Indicate a Stream
SSPA Announce
SSPA 120 Synchronization Point to 1 or
9.1.6 8.1.7 more Peripherals.

Instruct 1 or more Peripherals

Exit Dormant Announce to exit from Link State:
ExitDormant 100
9.1.7 8.1.7 Dormant and re-attach to the
bus

Read Transfer
220 + Read 1 or more bytes of data
Address-Mapped (ReadSetup /
(N_bytes × 10) [#1] from address-mapped register
ReadA32 Read ReadData
###TODO / memory locations in 1
9.1.8 Phases)
[+10 for PM] Peripheral
8.1.8

Write data to 1 or more

Address-Mapped
160 + Write address-mapped Register /
WriteA32 Write
(N_bytes × 10) 8.1.9 memory locations in 1
9.1.9 Peripheral

Send a Control command to 1

Unblock Command
Write Peripheral to clear the
Unblock Engine 120
8.1.9 COMMANDS_BLOCKED
9.1.11 status.

Schedule both a Stream

Stream-Synchronous 270 Synchronization Point and a
Commit synchronized update of
SSCR Commit Request ###TODO
8.1.10 registers for transport and/or
9.1.10 [+10 for PM] PHY parameters in some or
all groups / Peripherals.

Device-Synchronous 270 Schedule a synchronized

Commit
DSCR Commit Request ###TODO update of registers in some or
8.1.10
9.1.10 [+10 for PM] all groups / Peripherals.

DLV PHY Initial

170 + CalibratePhy [###TODO: move some draft
InitCal Calibration
(Block_Count × 30) 8.1.11 material from Section 9.1.12]
9.1.12

270 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
Command Long Name Length Transfer Type Description
& Opcode (see Section) (in Rows) / PhaseId
Name (see Section)

DLV PHY Fine Trim

170 + CalibratePhy [###TODO: move some draft
TrimCal Calibration
(Block_Count × 30) 8.1.11 material from Section 9.1.12]
9.1.12

1. If a ReadSetup Phase is deferred and then zero or more ReadData Phases are deferred before data is
provided on the final ReadData Phase then the total length is:
170 + (N_ReadDataPhases_Deferred × 90) + 140 + (N_bytes × 10).

9.1.2 Peripheral Command Model

4520 Figure 114 illustrates a layered view of SWI3S Peripheral behavior relating to Commands.

Non-SWI3S Behavior
(other MIPI Specifications and/or
Remote Registers
Implementation-defined) On-chip infrastructure
& Memory (variable latency)
(can be buffered/deferred)

Remote address
Local Registers
Device Power & Memory Address?
(never buffered/deferred) Local address
Management

SWI3S Behavior
Peripheral Behavior Non-SWI3S address

Calibration Link Row Delay Standard Registers

Status Address?
Algorithm Management Counter (never buffered/deferred) Local address,
standard register

Unblock Cal_PHY Ping

Exit
SSPA
SSCR & Commands WriteA32, ReadA32
Dormant DSCR (Opcodes)

Command Transport
ReadSetup
Unblock Cal_PHY GetInfo Announce Commit Protocol Write ReadData
(Transfers & Phase Types)

Control Data Stream

(8b/10b coding and SPM detection)

PHY
(e.g., DLV signaling)

4521
Figure 114 Peripheral Command Model

Copyright © 2019–2024 MIPI Alliance, Inc. 271

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
9.1.3 Peripheral Command Execution State
4522 Figure 115 shows how a simple 2-state model represents the Command Execution State associated with the
4523 Commands layer in Figure 114. ###TODO-Author:

Cold Reset

Running

Peripheral unexpectedly
detached from the Bus
(i.e., the Link State changed from
Attached to Syncing)

Executed Unblock Command

Blocked

4524
Figure 115 Peripheral Command Execution State

4525 The Command Execution State of Blocked enables the Manager or Host Controller Interface (HCI) to manage
4526 Command queues that might be implemented in the Manager to improve performance.
4527 If a Peripheral detaches from the bus either:
4528 • By commiting a PM_Action of Force_Resync (see ###XREF), or:
4529 • In a way that is not directed by the Manager (i.e., due to sync errors or low command confidence),
4530 then it enters the Blocked state. If the Peripheral subsequently succeeds in re-Attaching to the bus, then it will
4531 discard all further Commands (or ReadData Phases) until it receives an error-free Unblock Command. The
4532 Peripheral generates a response of COMMANDS_BLOCKED to each Command (or ReadData Phase) that is
4533 discarded.
4534 This mechanism gives time for the Manager driver software to assess the results of a sequence of queued Commands
4535 that has been partially executed, and choose what new sequence of Commands to issue. The driver software can
4536 consider the first Command that received COMMANDS_BLOCKED and any instances of an absent (undriven)
4537 Peripheral Response to determine the last Command that was successfully passed to the Peripheral for execution
4538 before it detached from the bus. The Manager sends an Unblock Command to return the Peripheral to the Running
4539 state, and might issue further reads to interrogate the state of the Peripheral.
4540 The Manager can determine the Peripheral Command Execution State any time that it sends a Command to that
4541 Peripheral, because a Peripheral in the state Blocked prioritizes sending a response of COMMANDS_BLOCKED
4542 over any other response (even over signaling a Transport Error in the Manager Packet).

272 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
9.1.3.1 Peripheral Behavior when Command Execution State is Blocked
4543 When the Command Execution State is Blocked, the Peripheral will react to Phases in which it is selected as
4544 follows:
4545 • If the Peripheral detects a transport error in the Phase Header then it will not send any response (because, as
4546 is also true when Command Execution State is Running, the peripheral would not know where to send any
4547 error response), otherwise:
4548 • The Peripheral Info in a Ping Phase will be COMMANDS_BLOCKED.
4549 • The Peripheral Response in any of ReadSetup, ReadData, Commit, or CalibratePhy Phases or in a Write
4550 Phase that contains anything except an error-free Unblock Command will be COMMANDS_BLOCKED.
4551 • The Peripheral Response in a Write Phase that contains an error-free Unblock Command will be
4552 WRITE_OK and the Peripheral will change the Command Execution State to Running.

Copyright © 2019–2024 MIPI Alliance, Inc. 273

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
9.1.4 Peripheral Remote Access State
4553 The Remote Access State Machine (RAS_SM) in Figure 116 shows how a simple 5-state model represents the
4554 behavior associated with reading and writing remote addresses in the layer labeled “non-SWI3S behavior” in
4555 Figure 114.

Host indication:
• Ping Response is not Busy

ReadData Phase:
Warm Reset Per: READ_DEFERRED

Remote ReadSetup Phase: Remote ReadData Phase:

Remote Write Phase: Per read result: FAILED Per read result: SUCCEEDED
Per write result: FAILED Per: READ_FAILED
Read Per: READ_DATA_NOW
Per: WRITE_FAILED Data Ready Man: READ_DATA_ERROR

Remote Write Phase:

Per: REMOTE_WRITE_BUFFERED
Remote ReadSetup Phase:
Per: REMOTE_READ_DEFERRED

ReadData Phase:
Per: READ_DATA_NOW
Man: READ_DATA_OK

Remote ReadSetup Phase: Remote ReadSetup Phase:

Host indication: Per read result: SUCCEEDED Per read result: SUCCEEDED Host indication:
• Ping Response is Busy Per: READ_DATA_NOW Per: READ_DATA_NOW • Ping Response is Busy
Man: READ_DATA_ERROR Man: READ_DATA_OK
Execute deferred read:
Remote Write Phase:
Per read result: SUCCEEDED
Per write result: SUCCEEDED
ReadData Phase: Remote Write Phase:
Per: WRITE_OK
Per: REMOTE_READ_DEFERRED Per: REMOTE_WRITE_BUSY
Remote Write Phase:
Remote Per: REMOTE_WRITE_BUFFERED
Remote
Read Write
Remote ReadSetup Phase: Busy Remote Write Phase: Busy
Remote ReadSetup Phase:
Per: REMOTE_READ_DEFERRED Per write result: SUCCEEDED
Per: REMOTE_WRITE_BUSY
Per: WRITE_OK
Remote ReadSetup Phase:
Warm Reset Warm Reset
Per read result: SUCCEEDED
Execute deferred read: Per: READ_DATA_NOW
Per read result: FAILED Man: READ_DATA_OK
Remote ReadSetup Phase:
Execute buffered write Execute buffered write
Per read result: SUCCEEDED
Remote Write Phase: Per write result: SUCCEEDED Per write result: FAILED
Per: READ_DATA_NOW
Per write result: FAILED
Man: READ_DATA_ERROR
Per: WRITE_FAILED
Remote Write Phase:
Remote ReadSetup Phase: Per: REMOTE_WRITE_BUFFERED
Per read result: FAILED
Per: READ_FAILED

Remote ReadSetup Phase:

Per: REMOTE_READ_DEFERRED

Remote
Bus Reset Idle Remote Write Phase:
(part of Cold Start) Per write result: SUCCEEDED
Per: WRITE_OK
Remote ReadSetup Phase:
Remote Write Phase:
Per read result: SUCCEEDED
Per write result: FAILED
Per: READ_DATA_NOW
Per: WRITE_FAILED
Man: READ_DATA_OK
Remote ReadSetup Phase:
Per read result: FAILED
Per: READ_FAILED

Local Write Phase:

Write 1 to IntStat_RemoteDisabled bit
Per write result: SUCCEEDED
KEY to conditions that cause transitions Per WRITE_OK
between Remote Access States:
Initial state after Bus Reset Remote Write Phase:
Warm Reset resulting from Peripheral detaching Remote Per: REMOTE_ACCESS_DISABLED
from the bus (i.e., leaving Link State: Attached) Remote ReadSetup Phase:
Disabled Per: REMOTE_ACCESS_DISABLED
Phase, Opcode and Remote/Local Address ReadData Phase:
+ Peripheral Response (& Manager Response) Per: REMOTE_ACCESS_DISABLED
Result of Peripheral executing a deferred read
at some time after the ReadSetup Phase Host indications:
• Register Read from IntStat_RemoteDisabled bit is
Result of Peripheral executing a buffered write • Ping Response is Alert if (IntEn_RemoteDisabled=1).
at some time after the Write Phase • ReadData or Remote Read/Write Phases receive a
4556 Peripheral Response of REMOTE_ACCESS_DISABLED.

Figure 116 Peripheral Remote Access State

4557 The Remote_Idle state indicates that the Peripheral is not currently processing any remote read or write operation.
4558 If the Peripheral accepts a WriteA32 Command that targets a remote address (a Remote Write) but cannot complete
4559 the operation in time to deliver a definitive Peripheral Response of WRITE_OK or WRITE_FAILED, then it sends a
4560 response of REMOTE_WRITE_BUFFERED, stores the command information (address and data), and changes to
4561 Remote Access State: Remote_Write_Busy.

274 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
4562 The Specification does not place an upper bound on how long the Peripheral will take to complete execution of the
4563 the buffered remote write operation, but a device data sheet might define this to help software differentiate between
4564 legitimate delays and more catastrophic failures. While the Peripheral has not completed execution it remains in the
4565 Remote_Write_Busy state, and:
4566 • Responds to a Ping Command with a value indicating that the the remote access is busy (see
4567 Section 9.1.5.2).
4568 • Responds to a new Remote Write or Remote Read Command with REMOTE_WRITE_BUSY to indicate
4569 that it cannot be accepted.
4570 • Accepts any other Commands (including Local Writes and Local Reads) and processes them normally
4571 without without affecting the Remote Access State or the buffered write operation.
4572 When the Peripheral has completed processing the buffered write, the result of that operation (succeeded or failed)
4573 will change the Remote Access State to one of Remote_Idle or Remoted_Disabled. The Remote Access State of
4574 Remoted_Disabled enables the Manager or Host Controller Interface (HCI) to manage Command queues that might
4575 be implemented in the Manager to improve performance.
4576 In the Remote_Disabled state the Peripheral raises the IntStat_RemoteDisabled interrupt, and will reject all further
4577 Remote Read or Remote Write Commands with a Response of REMOTE_ACCESS_DISABLED. This behavior
4578 alerts the Manager to the fault condition and preserves the state of all of the remote access address space so that the
4579 Manager or software can interrogate the Peripheral to determine how to handle it. The Peripheral remains in this
4580 state until the Manager explicitly acknowledges it by writing a 1 to the IntStat_RemoteDisabled bit to clear the
4581 interrupt and send the Peripheral back to the Remote_Idle state.
4582 Note:
4583 There might be additional implementation-defined conditions (e.g., clock enables for the remote domain) that
4584 need to be handled to prevent the Remote Access State returning to Remote_Disabled immediately after
4585 the next Remote Read or Write.
4586 When the Peripheral is in the Remote_Idle state and accepts a ReadA32 Command that targets a remote address (a
4587 Remote Read) but cannot complete the operation in time to deliver a definitive Peripheral Response of
4588 READ_DATA_NOW or READ_FAILED, then it sends a response of REMOTE_READ_DEFERRED, stores the
4589 command information (address and read byte count), and changes to Remote Access State: Remote_Read_Busy.
4590 The Specification does not place an upper bound on how long the Peripheral will take to complete execution of the
4591 the deferred remote read operation but a device datasheet might define this. While the Peripheral has not completed
4592 the execution it remains in the Remote_Read_Busy state and:
4593 • Responds to a Ping Command with a value indicating that the the remote access is busy (see
4594 Section 9.1.5.2).
4595 • Responds to a ReadData Phase with REMOTE_READ_DEFERRED to indicate to the Manager that the
4596 data is not yet available.
4597 • Reacts to a new Remote Read or Remote Write Command by abandoning/discarding the previous
4598 incomplete deferred read operation and then behaving as if the Peripheral were already in Remote_Idle.
4599 • Accepts any other Commands (including Local Writes and Local Reads) and processes them normally
4600 without without affecting the Remote Access State or the deferred read operation.
4601 When the Peripheral has completed processing the deferred read, the result of that operation (succeeded or failed)
4602 will change the Remote Access State to one of Remote_Read_Data_Ready or Remoted_Disabled.

Copyright © 2019–2024 MIPI Alliance, Inc. 275

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
4603 While the Peripheral is in the Remote_Read_Data_Ready state it preserves the data from the completed remote
4604 read operation to be delivered to the Manager when requested. While in this state, the Peripheral:
4605 • Responds to a Ping Command with a value indicating that the the remote access is not busy (see
4606 Section 9.1.5.2).
4607 • Reacts to a new Remote Read or Remote Write Command by discarding the preserved data from the read
4608 operation and then behaving as if the Peripheral were already in Remote_Idle.
4609 • Accepts any other Commands (including Local Writes and Local Reads) and processes them normally
4610 without without affecting the Remote Access State or the deferred read operation.
4611 • Responds to a ReadData Phase with READ_DATA_NOW followed by data and a CRC, as described in
4612 ###XREF-to-section-9.1.8??? , and then reacts to the Manager Response:
4613 • If it receives READ_DATA_OK it will complete the Remote Read and return to state Remote_Idle.
4614 • If it receives READ_DATA_ERROR it will remain in state Remote_Read_Data_Ready and preserve
4615 the same data to be delivered again when requested by the Manager with a further ReadData Phase.
4616 Note: the Peripheral does not repeat the read operation after receiving a Manager Response of
4617 READ_DATA_ERROR.

9.1.4.1 Effect of Warm Reset on Peripheral Remote Access State

4618 When the Remote Access State is one of the states: Remote_Write_Busy, Remote_Read_Busy, or
4619 Remote_Read_Data_Ready, this indicates that there is a remote write or read operation that has not yet completed.
4620 While in these states, if a Device detaches from the bus (i.e. leaves Link State: Attached) then the Warm Reset (see
4621 ###XREF) associated with detaching causes the Remote Access State to change to Remote_Disabled. In contrast, if
4622 the Remote Access State is Remote_Idle, then Warm Reset has no effect on this state.
4623 Thus, when the Peripheral reattaches, either IntStat_RemoteDisabled or the differing Peripheral Responses
4624 associated with Remote Access State of Remote_Idle vs Remote_Disabled help the Manager to determine what
4625 operations had or had not completed at the time that the Peripheral became detached from the bus.

276 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
4626 ###Note to reviewers: please do not add review comments for Figure 117. This is a TEMPORARY copy of
4627 the older version (with corrections to logic that were suggested by reviewers) that is provided below only to
4628 simplify checking of the new Figure 116.

(ReadData or New Remote ReadSetup):

(Per:READ_DATA_NOW AND
Man:READ_DATA_ERROR)

Remote
Read Data
Ready Remote Write: WRITE_BUFFERED

New Remote ReadSetup:

READ_DEFERRED

Existing Deferred Read obtains data OR

New Remote ReadSetup: Remote Write: WRITE_OK OR
Per:READ_DATA_NOW AND (ReadData or New Remote ReadSetup):
Man:READ_DATA_ERROR (Per:READ_DATA_NOW AND
Host indication:
Man:READ_DATA_OK) Ping will report one of the 2 BUSY Peripheral Status values.

(ReadData or
New Remote ReadSetup):
READ_DEFERRED
Host indication:
Ping will report one of the 2 Remote Write: WRITE_BUFFERED
BUSY Peripheral Status values New Remote Write: REMOTE_WRITE_BUSY OR
Remote Bus Reset Remote Remote ReadSetup: REMOTE_WRITE_BUSY
Read (part of Cold Start Remote ReadSetup: Write
sequence) Per:READ_DATA_NOW AND
Busy Man: READ_DATA_ERROR Busy
Remote ReadSetup: READ_DEFERRED

Buffered Write succeeds later

Warm Reset OR
Remote Write: WRITE_OK OR
Remote Write: WRITE_FAILED OR Remote Write:
New Remote ReadSetup:
New Remote ReadSetup: READ_FAILED WRITE_BUFFERED Warm Reset OR
(Per:READ_DATA_NOW AND
Man:READ_DATA_OK) Buffered Write fails later

Warm Reset OR
Remote Write: WRITE_FAILED OR
New Remote ReadSetup: READ_FAILED OR
Existing Deferred Read operation fails Remote
Idle
Remote ReadSetup: Remote Write: WRITE_OK
Per: READ_DATA_NOW AND
Man: READ_DATA_OK

Remote Write: WRITE_FAILED OR

KEY: Remote ReadSetup: READ_FAILED
Register Write to clear
Initial state after Bus Reset IntStat_RemoteDisabled bit

State transition resulting from detaching from bus (Warm reset) Remote
Disabled
State transition not resulting directly from a Phase, i.e., from attempting to Host indications:
perform the Read or Write operation after the Command Transport Phase • Register Read from IntStat_RemoteDisabled bit is
• Ping Response is Alert if (IntEn_RemoteDisabled=1).
• ReadData or Remote Read/Write Phases receive Peripheral Response
of REMOTE_ACCESS_DISABLED.
State transition resulting from a Command Transport Protocol Phase
Phase Name: RESPONSE_NAME Remote ReadSetup: REMOTE_ACCESS_DISABLED OR
Remote Write: REMOTE_ACCESS_DISABLED OR
4629 ReadData: REMOTE_ACCESS_DISABLED

Figure 117 TEMP OLD VERSION TO BE DELETED: Peripheral Remote Access State

Copyright © 2019–2024 MIPI Alliance, Inc. 277

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
9.1.5 Ping Command
4630 The Ping Command gathers basic status information about some or all Peripherals on the link.

9.1.5.1 Ping Command Transport

4631 A Ping Command is transported using a GetStatus Transfer (see Section 8.1.6). The Manager Packet that describes
4632 the Ping Command has a fixed length of 1 byte plus the CRC (see Figure 99)
4633 The Manager Packet for a Ping Command has no further Command Info following the Command Opcode.
4634 The Peripheral Info section of the GetStatus Transfer contains one 4-bit Ping Status field from each Peripheral on
4635 the bus that is selected by the Device Mask in the Phase Header (see Section 8.1.1.5.1)

9.1.5.2 Ping Command Behavior

4636 The Peripheral returns a Robust Token containing Peripheral Status information, such as:
4637 • Alert status indicating that the Peripheral has 1 or more interrupts that are active (IntStat_XYZ=1) and
4638 enabled (IntEnable_XYZ=1).
4639 • Remote Access State indicating that the Peripheral is still processing a buffered remote write or a deferred
4640 remote read.
4641 The detailed Peripheral Status information is specified in normative Table 109.

9.1.5.3 Ping Command Errors

4642 The Peripheral can detect and report the normal Command Error conditions (bad opcode or incorrect packet body
4643 length) and Transport Error conditions described for a GetStatus Transfer in ###XREF ###TODO-Author: triage
4644 archived material to resolve this XREF.
4645 There are no Command Errors that are specific to a Ping Command.

9.1.5.4 Ping Info from Peripherals that are Not Attached or Not Present in the System
4646 When there is no Peripheral with a given Device Number on the bus, or that Peripheral is currently not Attached (see
4647 Section ###XREF) or not selected by the Device Mask in the Transfer, then the corresponding Peripheral Status
4648 “slot” will be undriven for the whole of the 8b/10b symbol. This would typically generate a Bad 8b/10b Symbol
4649 Error in the Control Data Stream layer in the Manager (see Section 8.1.16.2). However, the Control Data Stream
4650 uses PHY-specific behavior (see Section 7.1.1.4) to ensure that these undriven periods are actually decoded to a
4651 specific 8b10b pattern of 10’b1111111111, so a Manager might detect this particular pattern and exhibit different
4652 behavior to when occasional bit errors generate a Bad 8b/10b Symbol Error.
4653 When the missing Ping Response is unexpected (i.e., the Peripheral exists, was previously attached, and has not
4654 been put into a Dormant state), the initial Manager reaction might be to repeat the Ping Command to try to
4655 differentiate between the Peripheral having simply missed the first Ping Command due to a simple bit error or
4656 having completely detached from the bus.

9.1.5.5 Ping Command and Peripheral Link Operation State

4657 A Peripheral also uses Ping Commands as the initial indication that it is correctly synchronized to a Control Data
4658 Stream containing valid Command Transport Protocol (see Section 5.1.8).
4659 A Manager typically sends Ping Commands to all Peripherals as a low overhead method of satisfying the Peripherals
4660 that they are still correctly synchronized to a Control Data Stream containing valid Command Transport Protocol
4661 (see Section 5.1.8.4).

278 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
9.1.6 SSPA (Stream Synchronization Point Announcement) Command
4662 An SSPA (Stream Synchronization Point Announcement) Command schedules an SSP Indication Event to occur at a
4663 specified time in the future. These events synchronize payload operations in Data Ports which might be located in
4664 the same Peripheral, or spread across multiple Peripherals.

9.1.6.1 SSPA Command Transport

4665 The Manager Packet that describes an SSPA Command has a fixed length of 3 bytes plus the CRC (see Announce
4666 Phase in Figure 100).
4667 The Command parameters for SSPA are:
4668 • Transport Commit Group Mask, which identifies which Commit Group(s) within each selected device will
4669 receive an SSP indication. Commit Groups are described in Section 9.1.10.1.
4670 • RowDelay, which identifies when the SSP indication occurs with respect to the last symbol in the
4671 Announce Phase (see ###XREF).

9.1.6.2 SSPA Command Behavior

4672 The effect of SSP indications on Payload Transport are described in Section [###XREF to SSPs in Payload
4673 Transport Section].

9.1.6.3 SSPA Command Errors

4674 The Announce Phase does not include any Peripheral Response. Thus, if the Peripheral receives invalid parameters
4675 in an SSPA Command it fails silently, and merely ignores the Command.

Copyright © 2019–2024 MIPI Alliance, Inc. 279

9.1.7 ExitDormant Command

4676 An ExitDormant Command instructs 1 or more Peripherals that are in the optional Link State: Dormant (see
4677 Section 5.1.8) to attempt to re-attach to the bus.

9.1.7.1 ExitDormant Command Transport

4678 The Manager Packet that describes an ExitDormant Command has a fixed length of 1 byte plus the CRC (see
4679 Announce Phase in Figure 100). There are no Command parameters following the Opcode.

9.1.7.2 ExitDormant Command Behavior

4680 The Dormant state facilitates implementation-defined power savings in a Peripheral when it is not participating in
4681 any bus traffic (neither payload nor Commands). An example of power saving might be turning off the power supply
4682 for the transmitter in PHY3 (DLV).
4683 While in the Dormant state, a Peripheral does not process any received Commands except for the ExitDormant
4684 Command, which instructs it to fully re-attach to the bus.
4685 If a Peripheral is already attached then performing an ExitDormant Command has no effect.
4686 Some Peripherals only recognize ExitDormant Commands if they are the only Device selected, because this allows
4687 them to recognize a simple bit pattern while dormant rather than continue to parse the full Command Transport
4688 Protocol.
4689 When a Peripheral is in the dormant state, error counters (such as EC_BadCRC) might not be incremented.

9.1.7.3 ExitDormant Command Errors

4690 The Announce Phase does not include any Peripheral Response. Thus, if the Peripheral receives an invalid
4691 ExitDormant Command (e.g., a Packet_Length which is not the fixed value of 1) it fails silently, and merely ignores
4692 the Command.

280 Copyright © 2019–2024 MIPI Alliance, Inc.

9.1.8 ReadA32 Command: Address Mapped Read

4693 The ReadA32 (Address Mapped Read) Command is used for reading from Registers or memory in the Peripheral.
4694 The Peripheral Command Interpreter reads a specified number of bytes from addresses starting at the specified
4695 address and delivers the resulting data back to the Manager in a Peripheral Packet.

9.1.8.1 ReadA32 Command Transport

4696 A ReadA32 Command is transported using a Read Transfer (see Section 8.1.8) that uses a ReadSetup Phase and, for
4697 some reads, 1 or more ReadData Phases.
4698 The Manager Packet that describes a ReadA32 Command has a fixed length of 6 bytes plus the CRC (see ReadSetup
4699 Phase in Figure 101).
4700 The Command parameters for ReadA32 are:
4701 • R, Encoded Read Byte Count, which identifies how many bytes (RBC = R + 1) are to be read (where
4702 1 ≤ RBC ≤ 256).
4703 • Address (Addr32), which identifies the starting address for the bytes to be read.
4704 The data produced by the Read Command is transferred as Peripheral data bytes in the Read Transfer, using the
4705 Peripheral Packet in either the ReadSetup Phase (see Section 8.1.8.5) or a subsequent ReadData Phase (see
4706 Section 8.1.8.9).

9.1.8.1.1 Byte Counts for ReadA32

4707 Peripheral support for reads larger than 1 byte is optional, but if they do implement support for larger reads then this
4708 includes all integer values up to that Peripheral’s maximum, which simplifies the job of Manager software choosing
4709 the size of read operations.
4710 Manager support for reads larger than 4 bytes is optional, and might not be a continuous range of integers, e.g., a
4711 Manager might implement support for reads of sizes in: {1, 2, 3, 4, 8, 12, 16, 32, 64, 128, 256}.
4712
4713
4714 ###TODO-Author: extract some of the Local / Remote Address material from Section 8.1.8 to go here (or in
4715 a dedicated level-3 section that describes Local vs Remote addresses.
4716 Explain (or link to material about) local vs remote reads, REMOTE_READ_DEFERRED Peripheral
4717 response, etc. Including that the read data is transported in the Peripheral Packet that is part of _either_ the
4718 Read_Setup Phase _or_ the Read_Data Phase.
4719

9.1.8.1.2 ###TODO: Multi-byte Quantities above the SWI3S Interface

4720 ###TODO-Author: (after v0.6 is issued) flesh out this _informative_ description.
4721 • ###informative : Describe (at least in informative material) the possibility of multi-byte registers where
4722 several bytes need to be sampled simultaneously (e.g., a 16-bit counter).
4723 • This does not apply to any “standard” registers in this Spec (because none of these are multiple bytes),
4724 but would apply to, e.g., SDCA.
4725 • This is not the same thing as the size of a whole read command (which could be up to 256 bytes).
4726

Copyright © 2019–2024 MIPI Alliance, Inc. 281

9.1.9 WriteA32 Command: Address Mapped Write

4727 The Address Mapped Write Command is used for writing to Registers or memory in the Peripheral. The Peripheral
4728 Command Interpreter writes a specified number of bytes (taken from the data bytes in the Manager Packet) to
4729 addresses starting at the specified address.

9.1.9.1 WriteA32 Command Transport

4730 A WriteA32 Command is transported using a Write Phase (see Section 8.1.9).
4731 The Manager Packet that describes a WriteA32 Command to write N bytes has a length of N+5 bytes plus the CRC
4732 (see Write Phase in Figure 103).
4733 The Command parameters for WriteA32 are:
4734 • Address (Addr32), which identifies the starting address for the bytes to be written.
4735 • Write Data, which is the block of data bytes to be written.
4736 The Write Data occupies all of the Manager packet after the Address, so the number of bytes to be written (N, where
4737 1 ≤ N ≤ 250) can be inferred from the Packet_Length.

9.1.9.1.1 Byte Counts for WriteA32

4738 Peripheral support for writes larger than 1 byte is optional, but if they do implement support for larger writes then
4739 this includes all integer values up to their maximum, which simplifies the job of Manager software choosing the size
4740 of write operations.
4741 Manager support for writes larger than 4 bytes is optional, and might not be a continuous range of integers, e.g., a
4742 Manager might implement support for writes of sizes in: {1, 2, 3, 4, 8, 12, 16, 32, 48, 64}.
4743

9.1.9.2 Timing of Write Operations

4744 The exact timing of the write operation resulting from a WriteA32 Command is dependent upon the Peripheral
4745 Response and is also implementation-defined within some constraints.
4746 When a Write Phase completes with a Peripheral Response of WRITE_OK, this is an “immediate write” all bytes are
4747 written and any side-effects are completed starting from when the last bit of the 8b/10b symbol containing the
4748 Manager CRC_16_L and ending at the start of the Row that is 79 Rows after the Row containing the first bit of the
4749 Peripheral Response. When a WriteA32 Command writes multiple bytes, these might or might not be written
4750 simultaneously. E.g., A 64-byte WriteA32 Command might occur as 64 sequential 1-byte writes, or as 16 sequential
4751 4-byte writes.
4752 ###TODO-Author: insert a figure illustrating the window of opportunity for an immediate write to take effect.
4753
4754 ###TODO-Author: extract some of the Local / Remote Address material from Section 8.1.8 to go here (or in
4755 a dedicated level-3 section that describes Local vs Remote addresses.
4756 Explain (or link to material about) local vs remote reads, REMOTE_WRITE_BUFFERED Peripheral
4757 response, etc.

9.1.9.3 Executing WriteA32 Commands At-Risk (i.e., before the CRC is known)
4758 An implementation might have some parts of its address map that can be updated “at risk” by WriteA32 Commands
4759 prior to the CRC being checked. E.g., a scratch buffer used as a staging area for indirect writes to internal memories.

9.1.9.4 Determining the Status of Buffered Remote Writes

4760 There are multiple ways to determine the status of a remote write (#1) that was buffered
4761 (Peripheral_Response=REMOTE_WRITE_BUFFERED). The Manager can use Ping Commands to determine
4762 directly that a buffered write has completed or it can infer this from the next remote write in a sequence of
4763 Commands, and then use a Ping Command to check the last remote write in the sequence.

282 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
4764 Note:
4765 Which of these two methods results in larger throughput is dependent upon system properties, manager
4766 design, and the length of the remote writes that might have to be repeated.
4767
4768 ###TODO: notes on further detail of determining status.
4769 Using Ping:
4770 • A Ping Response of Attached or Attached_Alert (i.e., not busy) => buffered write #1 is complete.
4771 Note:
4772 The Manager would then need to check the IntStat_Remote_Disabled register bit to distinguish between
4773 successful and failed.
4774
4775 Using a Subsequent Remote Write or Remote Read
4776
4777 • A following remote write or read is accepted (WRITE_OK, REMOTE_WRITE_BUFFERED,
4778 WRITE_FAILED, …) => write #1 completed successfully.
4779 • A following remote write #2 or remote read #2 is blocked (REMOTE_ACCESS_DISABLED) => write #1
4780 was not performed.
4781
4782 ###TODO-Author: productise this informative material that was migrated from the Write Phase:
4783 Local WriteA32 Commands normally produce a Peripheral Response of Write_OK, but might produce Write_Failed
4784 in exceptional circumstances such as, e.g.:
4785 • A transient hardware failure.
4786 Remote WriteA32 Commands might fail because of, e.g.:
4787 • An internal bus error.
4788 • The remote write domain not being powered up.
4789 • The remote write domain having clocks disabled.
4790 • A transient hardware failure.
4791
4792
4793

Copyright © 2019–2024 MIPI Alliance, Inc. 283

9.1.10 SSCR & DSCR Commands: Synchronous Commit Requests

4794 A Synchronous Commit Request Command schedules a Commit Event to occur at a Commit Synchronization Point
4795 (CSP), which is a specified time a small number of Rows after the Command (see normative Table 67). These events
4796 synchronize changes to multiple Dual-ranked Registers (see Section 14.1.3) which might be located in the same
4797 Peripheral or spread across multiple Peripherals.
4798 There are 2 forms of Synchronous Commit Request Commands, with the only difference in command structure
4799 being the value of the Opcode byte:
4800 • A Device-Synchronous Commit Request (DSCR) updates the selected dual-ranked registers.
4801 • A Stream-Synchronous Commit Request (SSCR) updates the selected dual-ranked registers and also
4802 signals an SSP Event to the selected Data Ports.
4803 For both of these Commands, selection is defined by matching a Commit Group Mask in the Command against the
4804 Commit Group membership for the resource. E.g., for a Data Port, the payload circuit and all Registers associated
4805 with that Data Port are in the Commit Group(s) identified by the bits that are set in the CommitGroupMemb[3:0]
4806 register field within that Data Port.
4807 Note:
4808 Commit Events are not limited to the defined Registers within the SWI3S interface, they can also affect both
4809 Registers and/or other behavior outside the SWI3S interface.
4810
4811 ###TODO-Author: illustrate the minimum number of run-on Rows required when the SSCR is committing a
4812 PM_Action of Enter_Sleeping or Enter_Cold_Standby. (run-on before the earliest that the Manager is
4813 permitted to park the bus in the current PHY).
4814

9.1.10.1 Commit Group Membership

4815 The DSCR, SSCR, and SSPA Commands all contain a Commit Group Mask that identifies which 1 or more of the
4816 Commit Groups are affected by that Command.
4817 Some registers within the Peripheral have fixed group membership of just Commit Group 0, and some can be
4818 programmed via a bit mask to be members of any set of Commit Groups 0 through 3.
4819 The Peripheral includes a number of standard non-Data Port registers that respond to Commit Events and these are
4820 all fixed as members of Commit Group 0 within that Peripheral. These registers include:
4821 • The PM_Action Register (Specified in Table 151).
4822 • Dual-ranked registers within the System & Link Control Registers (Specified in Table 152).
4823 • Dual-ranked registers within the Command Data Stream Transport Registers (Specified in Table 155).
4824 • Dual-ranked registers within the PHY Control blocks (Specified in Table 158, Table 161, etc.).
4825 Each SWI3S Data Port is programmed independently via the Commit Group Membership bit mask (see
4826 CommitGroupMemb[3:0] in Table 150) to be a member of 0 or more Commit Groups.
4827 Implementation-defined blocks within the Peripheral, such as an SDCA Function (see [MIPI02]), might also be
4828 programmed via a bit mask to be a member of 0 or more Commit Groups, or might depend upon the membership of
4829 the associated Data Ports.

284 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
9.1.10.2 SSCR and DSCR Command Transport
4830 The Manager Packet that describes an SSCR or DSCR Command has a fixed length of 3 bytes plus the CRC (see
4831 Commit Phase in Figure 104).
4832 ###TODO-Author: move the following table will be moved to the normative material for these Commands.
4833 Table 92 defines the Command Info bytes used to describe the SSCR/DSCR Command to the Peripheral.
4834 Table 92 DRAFT: Command Info Bytes for SSCR & DSCR Commands

Field Name Number of Description

Bytes

0x00 (SSCR) or
Opcode 1
0x01 (DSCR).

4-bit mask identifying which groups are affected by this

Transport Commit Event.
Transport Commit Bit 0: TCG0 (includes PHY Control Registers and
1 Link Control Registers).
Group Mask
Bit 1: TCG1.
Bit 2: TCG2.
Bit 3: TCG3.

8-bit number identifying the row delay.

RowDelay 1
Valid values are: 14 or 15.

4835 ###…

9.1.10.3 SSCR Command Behavior

4836 ###TODO-Author: change this to say that the SSP effect of both SSPA and SSCR is filtered by BOTH
4837 Device_Mask AND Group Selection. Also that the delay is calculated and ranges from 9? to 15 Rows.
4838 The scheduled Transport Commit Event occurs after the specified RowDelay (14–15 Rows). This delay is measured
4839 in a similar way to that for DSCR Commands, and is explained in detail in Section 9.1.13.
4840 The Transport Commit Event causes the Peripheral to copy the *_NEXT registers to the corresponding *_CURR
4841 registers in all dual-ranked Registers (see Section 14.1.3) that are members of one or more of the set of Transport
4842 Commit Groups (see Section 9.1.10.4) selected by the Transport Commit Group Mask.
4843 The Transport Commit Event also causes an SSP Event in every Peripheral that is addressed by the SSCR
4844 Command. This SSP Event occurs independently of whether any Registers within that Peripheral are members of
4845 any of the Transport Commit Groups selected by the Transport Commit Group Mask, and even if the Transport
4846 Commit Group Mask has the value of zero, selecting no Groups.
4847 An SSP Event indicates to the Peripheral a point in time that is expected to be an SSP (see ###XREF). It forces the
4848 transport operations in every active Data Port in the Peripheral to be in phase.
4849 Note:
4850 When any Data Ports are active, the Manager schedules Transport Commit Events only at times that are
4851 coincident with Sampling Events in all active Data Ports, so that the implicit SSP Event does not perturb
4852 payload operation.
4853 If an already active Data Port receives an SSP Event at a time when it would not normally have generated a
4854 Sampling Event then this indicates that its sample counters were not in phase with the Manager’s expectations and is
4855 an error condition.
4856 ###TODO-Author: add info describing …
4857 • There is a mandatory counter (at least one bit) for this DP-related error condition? (Niel’s 1+bit saturating
4858 counters). this is 1 error bit per-DP (i.e., per-stream), NOT 1 bit per Peripheral.

Copyright © 2019–2024 MIPI Alliance, Inc. 285

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
4859 • There is an optional interrupt associated with these errors.
4860 • The register address for the counter and the interrupt number are standardized.
4861 ###TODO-Author: check Transport Commit Event and SSP vs. SSP Event in Glossary
4862

9.1.10.4 Transport Commit Groups (TCG0–3)

4863 A Peripheral has either 1 Transport Commit Group (named TCG0) or 4 groups (named TCG0 through TCG3).

9.1.10.4.1 Commit Group Membership for System Resources

4864 The following dual-ranked Registers that relate to system operation have fixed group membership, and are always
4865 members of TCG0:
4866 • PHY Control Registers, see tables in Section 14.2.
4867 • System and Link Control Registers (PM_Action, Columns_per_Row, etc.), see Table 153.

9.1.10.4.2 Commit Group Membership for Data Ports

4868 A Data Port is a member of a set of zero or more of Commit Groups TCG0 through TCG3, controlled by a 4-bit field
4869 (Commit_Group_Membership) in a Data Port Register (see ###XREF to list of DP Register fields). This group
4870 membership applies to all dual-ranked registers within that Data Port’s register block, i.e., both standard registers
4871 defined in this Specification and implementation-defined registers.
4872 After Cold Reset every Data Port is a member of exactly 1 Commit Group (TCG0), i.e., the
4873 Commit_Group_Membership field has the value b0001.
4874 Some simple Devices do not support changing the Commit Group membership from this reset value so they
4875 implement a read-only Commit_Group_Membership field with a value of b0001.

9.1.10.4.3 Commit Group Membership for non-SWI3S Resources

4876 Other (i.e., non-SWI3S) functionality within the Device has its own method of determining which Commit Group(s)
4877 it belongs to. This is typically a mask field similar to the Commit Group Membership field for a Data Port.

9.1.10.5 SSCR Command Errors

4878 If the Peripheral detects that the RowDelay is out of range (i.e., not one of 14 or 15) then this is signaled as a
4879 COMMAND_ERROR.

9.1.11 Unblock Command

4880 Normative rules relating to the Unblock Command are in Section 9.2.9.
4881 When a Peripheral “falls off the bus”, i.e., leaves Link State: Attached unexpectedly, it might miss some Commands
4882 from the Manager. If this Peripheral succeeds in reattaching to the bus, then it changes its Command Execution State
4883 to Blocked (see Section 9.1.3), which prevents it from executing any further Commands received from the Manager
4884 until the Manager has explicitly acknowledged this change in state by sending an Unblock Command (in a Write
4885 Phase). This gives the Manager (or its control software) the opportunity to clear any previously prepared queue of
4886 Commands and send new Commands to interrogate the state of the Peripheral and possibly determine the cause of
4887 the problem.
4888 Details of Peripheral behavior when it is in Command Execution State: Blocked are described in Section 9.1.3.1.

9.1.12 InitCal & TrimCal Commands Used for Peripheral PHY Calibration
4889 ###TODO-Author: expand these notes.
4890 ###TODO-Author: edit this diagram to indicate that the values that follow Manager_CRC16_L are “Peripheral
4891 Response” and are different to the “PHY Cal Result”.
4892 ###NOTE: this is only applicable to some PHYs (e.g., PHY3 (DLV))

286 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
9.1.12.1 Summary of InitCal & TrimCal Command Structure
4893 Following the Manager Packet and the Manager CRC, the Peripheral Response indicates whether the Phase is
4894 terminated early (after some error condition), or whether it continues with the Calibration Packet (yellow and purple
4895 checker board in Figure 106) and the Calibration Result (orange byte in the same figure).
4896 The Calibration Packet does not use the 8b/10b Control Data Stream encoding that is used in the other parts of the
4897 Command Protocol. Instead, it assigns the CDS bit positions on a group of 3 successive rows to be a PHY
4898 Calibration Measurement. The Calibration Packet combines 10 of these Measurements into a PHY Calibration
4899 Block, that occupies 30 CDS bits, which is the same space as 3 8b/10b-encoded bytes. Thus an integer number of
4900 these PHY Calibration Blocks does not perturb the cadence of CDS symbols before the final Calibration Result is
4901 sent from the Peripheral to the Manager.
4902 The number of Calibration Blocks is described by parameter N, (excess-1 encoded so that 0x00 through 0x3F
4903 corresponds to 1 through 64). Maximum value of N is 0x3F, which corresponds to a maximum of 640 measurements
4904 and 1920 Rows for the Calibration Packet. This is smaller than the longest Write Command, so it will not cause
4905 Peripherals to become detached due to bad Command Confidence.
4906 Note:
4907 If a Manager used these very long Calibration Commands then it might need to Ping all of the Peripherals
4908 before doing another long Calibration, to avoid the risk of bad Command Confidence.
4909
4910 ###TODO: ###notes from AudioWG FTF 20220311: with details from Niel/Eddie on 20221219
4911 The second parameter, A, indicates how many of the measurements (0, R, R’), are used by the peripheral algorithm
4912 for adjusting the timing. For the remainder of the measurements (i.e., (10 × (N + 1)) – A), the Peripheral use the time
4913 that resulted from the calibration algorithm without making any further adjustment, which enables the Manager to
4914 average the received value to determine the calibration accuracy.
4915
4916 Peripheral_Response at the end of the Manager Packet:
4917 • N > 0x3F => COMMAND_ERROR
4918 • A > (10 × (N + 1)) => either:
4919 • COMMAND_ERROR (and hence there will be no calibration packet), or
4920 • CALIBRATE_NOW and then drive 0s at the start of each group of 3 bits BUT make adjustments for any
4921 number between 0 and (10 × (N + 1)) of these measurements, and issue any CAL_RESULT, i.e.,
4922 {TRANSPORT_ERROR, CAL_GOOD, CAL_FAILED} at the end of the cal packet (but not
4923 necessarily an accurate result). Note: i.e., the Command Engine is driving Robust Tokens at the right
4924 point, but the Calibration machine might mess up the current timing.
4925 • A=0 => CALIBRATE_NOW.
4926 • (0 < A < Peripheral_min_A) => Peripheral_Response=COMMAND_ERROR.
4927 • If (A > Peripheral_max_A) then Peripheral_Response=CALIBRATE_NOW, but the Peripheral can choose
4928 to start the no_more_adjusting part of the calibration packet at Peripheral_max_A. … so the Peripheral
4929 might not need a full 8-bit counter for A.
4930
4931 Calibration_Result at the end of the Calibration Packet:
4932 • A=0 => TRANSPORT_ERROR or CAL_GOOD, never CAL_FAILED.
4933 • (0 < A < Peripheral_min_A) => there is no calibration packet and hence no Calibration_Result
4934 • Peripheral_minA <= A <= (10 × (N + 1)) => correct one of {TRANSPORT_ERROR, CAL_GOOD,
4935 CAL_FAILED}.
4936 • A > (10 × (N + 1)) => issue any CAL_RESULT, i.e., {TRANSPORT_ERROR, CAL_GOOD,
4937 CAL_FAILED}, not necessarily the _correct_ one.
4938

Copyright © 2019–2024 MIPI Alliance, Inc. 287

9.1.12.2 Calibration Opcodes & Parameters

4940 There are 2 valid Opcodes in a CalibratePhy Transfer:
4941 InitCal: The Peripheral starts by resetting its internal delay to its default value (latest possible Tx output)
4942 and typically uses coarse time steps.
4943 TrimCal: The Peripheral starts with the existing internal delay and typically uses fine time steps.
4944
4945 Table 93 Calibration Opcodes

Initial Manager Received Clock Minimum

Delay Slew Rate Jitter N used by
Value Range (Note: Manager the
Opcode (ns) + Channel Manager
Effects +
Peripheral
Behavior)

InitCal maximum 10

TrimCal current

4946
4947

9.1.12.3 Peripheral Response to PHY_Cal Phase

4948 Possible responses from the Peripheral to the Manager are:
4949 • COMMANDS_BLOCKED
4950 • TRANSPORT_ERROR
4951 • COMMAND_ERROR
4952 • CALIBRATE_NOW

9.1.12.4 PHY_Cal Measurement

4953 Peripheral Responsibility:
4954 • Launch 0 in its perception of the normal CDS bit position, which might be adjusted by the internal
4955 algorithm.
4956 • Receive the reflected data from the Manager, which will have some statistical distribution of 0 and 1
4957 relating to the output time from the Peripheral.
4958 Manager Responsibility:
4959 • Sample the Peripheral bit at the beginning of the normal CDS bit position instead of the normal data eye.
4960 • Reflect this as 2 successive CDS bit values (R and not-R)
4961 Note:
4962 The reason for the Manager sending 2 complementary bit values (R and not-R) is that the resulting
4963 bitstream will avoid triggering the SPM detector in other Peripherals.

288 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
9.1.12.5 PHY_Cal Result
4964 Possible values that the Peripheral can send to the Manager at the end of the Calibration Measurements.
4965 • TRANSPORT_ERROR (i.e., R/not_R mismatch)
4966 • PHY_CAL_FAILED
4967 • PHY_CAL_GOOD
4968
4969 ###AudioWG 20220111 decisions on PHY Cal (text updated 20221219)
4970 2 opcodes:
4971 • InitCal:
4972 • Manager shall use a larger value of Block_Count (minimum 10, i.e. N=0x09, but might be more, e.g.,
4973 when using very high bit rates or a more simplistic algorithm in the peripheral).
4974 • Excursion is limited by the PHY3_CalibrationDelayMin / Max registers.
4975 • Peripheral shall restart from the value of the PHY3_CalibrationDelayMax register.
4976 • Cold Reset value of min/max registers are: [–3, +63/64] × UI.
4977 • Peripheral shall give a cal result in {Good, Failed}
4978 • TrimCal:
4979 • Manager shall use any value of Block_Count (typically 1, i.e., N=0x00)
4980 • Excursion is limited by the PHY3_CalibrationDelayMin / Max registers (typically set to a closer limit
4981 than for InitCal).
4982 • Peripheral shall start from the existing delay
4983 • Peripheral shall give a result in {Good, Failed}
4984
4985 The Calibration algorithm is ImpDef but (a) it might adapt the step size to the min/max arrange and (b) it might
4986 adapt the step size to the opcode TrimCal vs. InitCal.
4987
4988 • PHY_CAL_FAILED (e.g., the algorithm did not converge).
4989 • PHY_CAL_GOOD (no specific quality is defined by the Spec, but this might be, e.g., the ratio of 0s to 1s
4990 is within 45% to 55%). The Manager can use the checking part of the CalibratePhy Phase to assess whether
4991 the calibration is good enough for that Peripheral to participate in payload transmission).
4992
4993

9.1.12.6 PHY Calibration Algorithm in the Peripheral

4994 #notes: Proprietary.
4995 Not known by Manager
4996 Constraints on excursion – ###TODO: figures showing Lock-16, Lock-25, Lior-16 with wide variability and then
4997 regular Fast-16 with very little scope for variability.
4998
4999 ###TODO figure: Example of different arrival times at Manager based on different Peripheral launch times, and the
5000 resulting two different values received.

9.1.12.7 Notes on InitCal vs TrimCal

5001 ###TODO-Author: flesh out this text (which was updated on 20231205).
5002 2 different opcodes:
5003 • InitCal: restart at max delay (+10 ns) and move the launch time earlier.

Copyright © 2019–2024 MIPI Alliance, Inc. 289

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
5004 • TrimCal: start at current delay and move +/- relative to that delay.
5005 Limits of excursion are controlled by Register fields PHY3_CalibrationDelay_Min and
5006 PHY3_CalibrationDelay_Max.
5007

9.1.12.8 Error Handling

5008 QUESTION: What happens if the Manager sees some bit errors in the Peripheral Response so that it cannot be
5009 sure whether the Peripheral is going to generate the test zeroes in the Calibration Packet?
5010 ANSWER: [Niel] presumably … the Manager should proceed with the requested Calibration Packet.
5011

290 Copyright © 2019–2024 MIPI Alliance, Inc.

9.1.13 Sync_Point_Delay in SSPA, SSCR, and DSCR Commands

5012 Each of the SSPA, SSCR or DSCR Commands use a Sync_Point_Delay which is calculated and measured using a
5013 common method:
5014 • The Peripheral subtracts the SyncPointOffset Register field (0 to 5) from the RowDelay field (14 or 15) to
5015 produce the Sync_Point_Delay, which is a number of Rows between 9 and 15.
5016 • The only valid values of the SyncPointOffset Register field are 0 through 5. If the Manager attempts to
5017 write any other value then the Peripheral will replace it by a value within the valid range.
5018 • The only valid values of the RowDelay field are 14 and 15. Any other values result in the Command
5019 not being executed and either receiving Command Error (for SSCR or DSCR) or being ignored (for
5020 SSPA).
5021 • The Command Reference Point for measuring the Sync_Point_Delay is the first Row Sync Point after the
5022 Row that transported the 10th (and final) bit of the final 8b10b symbol in the Phase, as shown in
5023 Figure 118.
5024 • For the SSCR and DSCR Commands (Commit Phase) the final 8b10b symbol is the Manager
5025 Response (which has a value of CONFIRM_COMMIT).
5026 • For the SSPA Command (Announce Phase) the final 8b10b symbol is the second byte of the Manager
5027 CRC.
5028 • The scheduled event (Stream Synchronization Point Indication or Commit Sync Point) occurs
5029 simultaneously with the Row Sync Point that is Sync_Point_Delay number of Rows after the Command
5030 Reference Point.

Commit Phase: Commit Phase: Announce Phase:

SSCR Command DSCR Command SSPA Command
Start of Phase Marker Start of Phase Marker Start of Phase Marker
COMMIT COMMIT ANNOUNCE
Device Mask_H Device Mask_H Device Mask_H
Device Mask_M Device Mask_M Device Mask_M
Device Mask_L Device Mask_L Device Mask_L
Packet_Length_H=0x0 Packet_Length_H=0x0 Packet_Length_H=0x0

Packet_Length_L=0x3 Packet_Length_L=0x3 Packet_Length_L=0x3

Opcode: SSCR Opcode: DSCR Opcode: SSPA

Group Mask Group Mask Group Mask
Row Delay Row Delay Row Delay
Manager_CRC16_H Manager_CRC16_H Manager_CRC16_H
Manager_CRC16_L Manager_CRC16_L Manager_CRC16_L
Protocol Spacer Protocol Spacer
Peripheral 0 Response Peripheral 0 Response
Peripheral 1 Response Peripheral 1 Response

Peripheral 2 Response Peripheral 2 Response

Peripheral 3 Response Peripheral 3 Response

Peripheral 4 Response Peripheral 4 Response
Peripheral 5 Response Peripheral 5 Response
Peripheral 6 Response Peripheral 6 Response

Peripheral 7 Response Peripheral 7 Response

Peripheral 8 Response Peripheral 8 Response

Peripheral 9 Response Peripheral 9 Response

Peripheral 10 Response Peripheral 10 Response
Peripheral 11 Response Peripheral 11 Response

Protocol Spacer Protocol Spacer

Manager Response Manager Response

5031
Figure 118 Command Reference Point for Measuring Row Delay

Copyright © 2019–2024 MIPI Alliance, Inc. 291

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
5032 Figure 119 (which is known to use an incorrect delay value) shows a detailed view of an example SSPA
5033 Command with a RowDelay of 11 in a system using the DLV PHY. The first Row Sync Point after the last bit of the
5034 CRC symbol is labeled in the figure as the Reference Edge. The corresponding point 11 rows further on is
5035 designated as the SSP.
5036 ###TODO-Author: redraw the detailed timing diagram for a Commit/SSCR Command with PHY3 (DLV), and
5037 illustrate the 2 possible SSCR delays of 14 and 15 Rows. Also show an SSCR command in PHY1 / #2
5038 (FBCSE).
5039 ###TODO-Author: produce new figures based on this diagram from Geert’s presentation. Perhaps two
5040 figures: one for DLV PHY and one for FBCSE PHY (where the SSP would be aligned with the left edge of
5041 the Control Data Stream bit).
5042 ###TODO-Author: draw the figure illustrating Commit Events as an alarm clock and a To-Do list next to it:
5043 • For SSPA, the To-Do list has SSP TCG0, SSP TCG3.
5044 • For SSCR, the To-Do list has SSP TCG0, Commit TCG0, SSP TCG1, Commit TCG1.
5045 • For DSCR, the To-Do list has, e.g., Commit TCG1, Commit TCG2.

5046
Figure 119 #INCORRECT#: SSP Timing Details (when using DLV PHY)

292 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
9.1.14 Decisions to be folded into this Section
5047 ###TODO-Author: check that remaining items in this list have been implemented.
5048
5049 • Change CG assignment to be CG0 for all standard registers and CG1–3 for the non-SWI3S behavior.
5050

Copyright © 2019–2024 MIPI Alliance, Inc. 293

9.2 Specifications (normative)

9.2.1 Command Processing

5051 Requirements
5052 1. {xx01} The Command Engine in the Peripheral shall be in one of the 2 Command Execution States shown
5053 in Table 94, which influence the Peripheral Responses in the Command Transport Protocol (see
5054 Section 8.2.3):
5055 Table 94 Summary of Command Execution States
Command Execution State Effect on Executing Commands
All Commands are executed normally.
Running
See Table 78.
Only Unblock Commands are executed.
(See Section 9.2.9 Requirement 2).
Blocked All other Commands receive a Response of
COMMANDS_BLOCKED.
See Table 77.
5056 2. {xx02} After a Cold Reset, the Command Execution State shall be set to Running.
5057 Note: Thus when the Peripheral first attaches to the bus after Cold_Standby, Command Execution will not
5058 be blocked.
5059 3. {xx03} When the Peripheral changes from Link State: Attached to Link State: Syncing (i.e., the Peripheral
5060 ‘detaches from the bus’, see Section 5.2.2 Requirement 14) the Peripheral Command Execution State shall
5061 change to Blocked.
5062 Note: If the Peripheral subsequently goes through a Sleep-Wake cycle (i.e. changes to Link State: Sleeping
5063 and then back to Syncing), the Execution State will still be Blocked.
5064 4. The first byte of the Manager Packet in a Phase shall contain an Opcode that identifies which Command is
5065 described by that Manager Packet, according to Table 95.
5066 5. A Peripheral shall implement Opcodes that are shown in Table 95 as either:
5067 A. Mandatory, or
5068 B. Conditional, and the Condition is true for that Peripheral.
5069 6. When a Peripheral that is in Command Execution State: Running receives a Command in a Phase that has
5070 not terminated with a common error (i.e., one of NoResponse, TRANSPORT_ERROR, or
5071 COMMAND_ERROR in Table 78), the Peripheral shall behave according to the rules in the Section
5072 indicated for that Command in Table 95.
5073 7. If a Peripheral receives a Valid Phase Header where the Opcode value is shown in Table 95 as Optional or
5074 Conditional and that Opcode is not implemented in the Peripheral, then the Peripheral shall do both:
5075 A. Discard the Command, and
5076 B. (For all PhaseIDs except for Announce): generate a Peripheral Response of COMMAND_ERROR
5077 (see Table 78).
5078 8. If a Peripheral receives a Valid Phase Header for any PhaseId except for Announce, and the Opcode value
5079 is shown in Table 95 as Reserved, then the Peripheral shall do both:
5080 A. Discard the Command, and
5081 B. (For all PhaseIDs except for Announce): generate a Peripheral Response of COMMAND_ERROR
5082 (see Table 78).

294 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
5083 Table 95 Opcodes for Commands

Opcode Rules in Used with Opcode Implemented Description / Notes

Name Section: PhaseId: Value when?

Gather basic status from set of

Ping 9.2.8 GetStatus 0x00 Mandatory
Peripherals

SSPA 9.2.5 Announce 0x00 Mandatory Announce an SSP

Instruct a Peripheral to exit the

ExitDormant 9.2.6 Announce 0x01 Conditional [1] dormant state and re-attach to the
bus.

Read 1 or more bytes from a

ReadA32 9.2.4 Read_Setup 0x00 Mandatory location specified by a 32-bit
address

Write 1 or more bytes to a location

WriteA32 9.2.3 Write 0x00 Mandatory
specified by a 32-bit address

Change to Command Execution

Unblock 9.2.9 Write 0x01 Mandatory
State: Running.

Stream-Synchronous Commit
SSCR 9.2.7 Commit 0x00 Mandatory
Request

Device-Synchronous Commit
DSCR 9.2.7 Commit 0x01 Optional [2]
Request

InitCal 9.2.10 CalibratePhy 0x00 Conditional [3] Used with PHY3 (DLV)

TrimCal 9.2.10 CalibratePhy 0x01 Conditional [3] Used with PHY3 (DLV)

9.2.1 GetStatus
Reserved 0x01 — Generates a Bad Opcode error
Rule 8 Read

9.2.1 0x02–
Reserved All PhaseIDs — Generates a Bad Opcode error
Rule 8 0xFF

1. ExitDormant is mandatory in a Peripheral that implements the Dormant Link State (see Section 5.2.2
Requirement 1).
2. DSCR is used only with dual-ranked registers that are implementation-defined, or defined in other
specifications. All of the dual-ranked registers specified within this Specification are normally updated
using SSCR.
3. InitCal and TrimCal are both mandatory in a Peripheral that implements PHY3 (DLV).

5084 Permissions
5085 1. A Peripheral may implement any Opcode that is shown in Table 95 as Optional.

Copyright © 2019–2024 MIPI Alliance, Inc. 295

9.2.2 Remote Read and Write Accesses (Optional)

5086 Requirements
5087 1. {xa01} A Peripheral Device that implements the optional Remote Read and Write Accesses (address value
5088 from 0x80000000 to 0xFFFFFFFF) shall follow the rules in this Section (9.2.2).
5089 2. {xa02} The Remote Access Engine in the Peripheral shall be in one of the 5 Remote Access States shown in
5090 Table 96, which influence the Peripheral Responses in the Command Transport Protocol (see Section 8.2.3)
5091 and the behavior of Commands:
5092 Table 96 Summary of Remote Access States
Ping IntStat_
Indicates RemoteDisabled
Remote Access State Description
Busy (see
(see informative Figure 116) (informative)
(see Requirements 5
Table 109) and 6)
The Peripheral is ready to start a
Remote_Idle No 0
remote read or write.
No remote read or remote write
Remote_Disabled No 1 can be executed until this
condition is cleared.
The Peripheral is temporarily busy
Remote_Write_Busy Yes 0
with a buffered write.
The Peripheral is attempting to
Remote_Read_Busy Yes 0
perform a deferred read.
The Peripheral is waiting for the
Remote_Read_Data_Ready No 0 Manager to collect the read data
from a previously deferred read.

5093 3. {xa03} After a Cold Reset, the Remote Access State shall be Remote_Idle.
5094 4. {xa04} When the Peripheral Link State (see Table 12 in Section 5.2.2) changes from Attached to any other
5095 state, if the Peripheral Remote Access State is not currently Remote_Idle then it shall change to
5096 Remote_Disabled.
5097 5. {xa05} When the Remote Access State changes to Remote_Disabled, IntStat_RemoteDisabled shall
5098 change to 1.
5099 6. {xa06} When the Remote Access State is Remote_Disabled and a 1 is written to the
5100 IntStat_RemoteDisabled bit, the Remote Access State shall change to Remote_Idle.

296 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
5101 7. {xa06} The Remote Access State shall change state according to Table 97.
5102 Table 97 Remote Access State Transitions
Command Opcode Peripheral Internal
Current or Phase Action New
Remote Access State Remote Access State
(Section & Rule) (Section & Rule)
Write result: Succeeded
Remote_Idle
(9.2.3 Requirement 16.A)
Remote_Idle Write result: Failed
Remote_Disabled
Remote_Read_Busy Remote WriteA32 (9.2.3 Requirement 16.B)
Remote_Read_Data_Ready
Peripheral Buffered
(9.2.3 Permission Remote_Write_Busy
#XREF)
Read result: Succeeded
Remote ReadA32
(9.2.4 Requirement Remote_Idle
Manager DataOK
#XREF)
Read result: Succeeded
Remote ReadA32
(9.2.4 Requirement Remote_Read_Data_Ready
Remote_Idle Manager DataError
#XREF)
Remote_Read_Busy
Remote_Read_Data_Ready Read result: Failed
Remote ReadA32 (9.2.4 Requirement Remote_Disabled
#XREF)
Peripheral Deferred
Remote ReadA32 (9.2.4 Requirement Remote_Read_Busy
#XREF)
ReadData Phase
— Remote_Idle
Manager DataOK
Remote_Read_Data_Ready
ReadData Phase
— Remote_Read_Data_Ready
Manager DataError
Read result: Succeeded
(9.2.4 Requirement Remote_Read_Data_Ready
#XREF)
Remote_Read_Busy —
Read result: Failed
(9.2.4 Requirement Remote_Disabled
#XREF)
Write result: Succeeded
Remote_Idle
(9.2.3 Requirement 16.A)
Remote_Write_Busy —
Write result: Failed
Remote_Disabled
(9.2.3 Requirement 16.B)
Local WriteA32
writing 1 to IntStat_ Write result: Succeeded
Remote_Disabled Remote_Idle
RemoteDisabled (9.2.3 Requirement 16.A)
(9.2.2 Requirement 6)
Peripheral Link State
Remote_Write_Busy
changes from Attached to
Remote_Read_Busy — Remote_Disabled
any other state
Remote_Read_Data_Ready
(9.2.2 Requirement 4)
Cold Reset
Any State — Remote_Idle
(9.2.2 Requirement 3)

5103 Note: The Remote Access State transitions in Table 97 are represented in informative Figure 116.
5104
5105 ###TODO-Author: add a note elsewhere in the informative error handling discussion: any Warm Reset
5106 (falling off the bus or intentionally going to Dormant or Sleep) discards any outstanding deferred read or
5107 buffered write (and sets Remote_Disabled if any were discarded). The Manager will always be using some
5108 kind of restart or error recovery from these conditions.”
5109

Copyright © 2019–2024 MIPI Alliance, Inc. 297

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
5110 Recommendations
5111 1. The Manager should check that a Peripheral is not busy with any Remote Write or Remote Read operations
5112 before causing the Peripheral to change its Link State from Attached (e.g., to Sleeping or Dormant).
5113 2. The Manager should handle and clear any IntStat_RemoteDisabled condition in a Peripheral before causing
5114 the Peripheral to change its Link State from Attached (e.g., to Sleeping or Dormant).
5115 3. The Manager should check that a Peripheral is not busy with any Remote Write or Remote Read operations
5116 before issuing a Commit operation that selects a Commit Group containing any of the values in the remote
5117 write or read operation.

298 Copyright © 2019–2024 MIPI Alliance, Inc.

9.2.3 WriteA32 Command

5118 Requirements
5119 1. The structure of the Write Phase that describes a WriteA32 Command shall be according to Table 72.
5120 2. A Peripheral shall use the Write_Address to determine whether a WriteA32 Command describes a Local
5121 Write or Remote Write, according to the Local/Remote Access column in Table 146.
5122 3. A Peripheral shall accept WriteA32 Commands that have a WriteByteCount that is within the range shown
5123 in Table 98.
5124 Table 98 Local & Remote Writes
Type of Write Range of WriteByteCount [1] Notes
Local Write 1 to Max_WBC_Local [2] —
Remote Write
1 to Max_WBC_Remote [2] Support for Remote Writes is optional
(see Section 9.2.2)

5125 Note:
1. WriteByteCount is calculated from (Packet_Size – 5), see Table 72.
2. The values of Max_WBC_Local and Max_WBC_Remote are implementation-defined and might be
reported in the datasheet and/or the DisCo data for the Peripheral Device.

5126 4. A Peripheral shall have a value of Max_WBC_Local that is between 1 and 250 inclusive.
5127 5. A Peripheral that supports Remote Writes shall have a value of Max_WBC_Remote that is between 1 and
5128 250 inclusive.
5129 6. A Manager shall be capable of generating WriteA32 Commands that have a WriteByteCount of every
5130 integer between 1 and 4.
5131 See also Permission 1 and Recommendation 1.
5132 7. A multi-byte WriteA32 Command to a SWI3S-defined Register address (see Table 146) shall access the set
5133 of bytes at adjacent increasing addresses starting at the 32-bit Write Address in the Manager Packet.
5134 Note: The set of bytes accessed by a multi-byte WriteA32 Command to a Device-defined address is
5135 implementation-defined and not necessarily the same as sequential incrementing addresses. The set of
5136 bytes accessed by a WriteA32 Command to an SDCA address is defined in [MIPI02].
5137 8. The Manager shall not generate WriteA32 Commands that address bytes in both the Local and Remote
5138 regions in Table 146.
5139 9. The Manager shall not generate WriteA32 Commands with addresses that wrap (i.e., that require the
5140 address to be incremented to (0xFFFFFFFF + 1)).

Copyright © 2019–2024 MIPI Alliance, Inc. 299

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
5141 10. The Peripheral shall interpret any of the conditions listed in Table 99 as a Command Error in a WriteA32
5142 Command (see Table 78 in Section 8.2.3 Requirement 2):
5143 Table 99 WriteA32 Command Errors
Notes
Error Name Condition
(informative)
Shortest write is 1 data byte which
needs Packet_Length of 6.
Invalid Manager Packet Size ≤ Header:PacketLength ≤ 5 Packet_Length of 0 is not a Valid
Header for PhaseID:Write, so
generates no Response.
(Header:PacketLength – 5) > Upper limit of WriteByteCount range is
WriteByteCount Too Large upper limit of WriteByteCount ImpDef and can be dependent on
Range shown in Table 98. Local Write versus Remote Write.
The address is in the ImpDef
region of the address map (see E.g., the ImpDef circuitry might accept
Bad Impdef Address
Table 146) AND is invalid in an only addresses that are 4-byte aligned.
implementation-defined way.
The address is in the SDCA
region of the address map (see
Bad SDCA Address Table 146) AND the SDCA —
Specification ([MIPI02]) indicates
a Command Error.
1 or more of the addresses The Peripheral might silently accept
[optional] covered by this command are in a writes even when 1 or more addresses
Unimplemented Address part of the address map that is are unimplemented.
detected as unimplemented. (See Permission 2.B.)

5144 11. When all of the bytes that are addressed in a WriteA32 Command are implemented, the Peripheral shall do
5145 both:
5146 A. Accept the Command, and
5147 B. Write each data byte to the corresponding address.
5148 Note: see also Permission 2.
5149 12. When a Peripheral is in Remote Access State: Remote_Disabled and attempts to execute an error-free
5150 WriteA32 Command to a Remote Address, it shall discard the Command and generate a Peripheral
5151 Response of REMOTE_ACCESS_DISABLED (see Table 81).
5152 13. When a Peripheral is in Remote Access State: Remote_Write_Busy and attempts to execute an error-free
5153 WriteA32 Command to a Remote Address, it shall discard the Command and generate a Peripheral
5154 Response of REMOTE_WRITE_BUSY (see Table 81).

300 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
5155 14. When a Peripheral executes an error-free WriteA32 Command, it shall behave according to Table 100:
5156 Table 100 WriteA32 Command Behavior
Region of Peripheral
Peripheral Write
Address Map Placed the Write Peripheral Response (see Table 81)
Result?
(see Table 146) in the Buffer? and
(see
(see Peripheral Action
Requirement 16)
Permission #)
WRITE_OK.
— Succeeded Write the bytes now (i.e., finishing before 79
Local Address Rows after the start of the Peripheral Response).

— Failed WRITE_FAILED.

WRITE_OK.
Write the bytes now (i.e., finishing before 79
No Succeeded Rows after the start of the Peripheral response).
Set Remote Access State to Remote_Idle (see
Section 9.2.2 Requirement ###XREF).
WRITE_FAILED.
Remote No Failed Set Remote Access State to Remote_Disabled
Address (see Section 9.2.2 Requirement ###XREF).
REMOTE_WRITE_BUFFERED.
Set Remote Access State to
Remote_Write_Busy (see Section 9.2.2
Yes —
Requirement ###XREF).
Attempt to write the bytes later (i.e., after an
implementation-defined delay).

5157 15. When a WriteA32 Command updates a SWI3S-defined Register in which some or all of the bits are
5158 Reserved, the Peripheral shall ignore the values written to the Reserved bits.
5159 Note: the Reserved bits will always read as zero.

5160 16. When the Peripheral attempts to perform a write operation it shall yield a result that is either:
5161 A. Succeeded, if every byte was successfully written to the corresponding address, or
5162 B. Failed, if 1 or more bytes were not successfully written to the corresponding address (e.g., due to an
5163 internal bus error).
5164 Note: in the case of a Remote Write that was buffered, this result occurs after the Peripheral produced its
5165 Response within the Write Phase, but will influence the Remote Access State (see Table 100).

5166 17. When a WriteA32 Command updates a SWI3S-defined Register in which some or all of the bits are
5167 Reserved, the Peripheral shall ignore the values written to the Reserved bits.
5168 Note: The Reserved bits will always read as zero.

Copyright © 2019–2024 MIPI Alliance, Inc. 301

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
5169 Permissions
5170 1. A Manager may be capable of generating WriteA32 Commands that have a WriteByteCount of up to 250.
5171 2. When 1 or more of the bytes addressed in a WriteA32 Command is/are Reserved or not implemented, the
5172 Peripheral may either:
5173 A. Reject the Command by responding with COMMAND_ERROR, or
5174 B. Accept the Command and
5175 i. Write the data bytes that correspond to implemented addresses, and
5176 ii. Discard the data bytes that correspond to unimplemented (or Reserved) addresses.
5177 Note: see also Requirement 11.
5178 Note: “unimplemented” in this Permission includes Remote Address space in a Peripheral that does not
5179 implement any of that space.

5180 3. When a WriteA32 Command stores a value in a SWI3S-defined Register that is not in the set of valid
5181 values for this Peripheral then the Peripheral may substitute a different value that is in the set of valid
5182 values.
5183 Note: A subsequent read will return the actual value that was stored.
5184 4. When a WriteA32 Command targets an address that is in a region defined in the address map (see
5185 Table 146) as Device-defined or SDCA, the Peripheral may store the values to the addressed bytes before
5186 having checked the ManagerCRC.
5187 Note: A Peripheral would perform these “speculative” writes only in regions that it knew to be scratch
5188 memories.

5189 Recommendations
5190 1. A Manager should be capable of generating WriteA32 Commands that have a WriteByteCount of up to 16.

302 Copyright © 2019–2024 MIPI Alliance, Inc.

9.2.4 ReadA32 Command

5191 ###TODO-Author: implement the following answer to Open item #109.
5192 Timing of the internal capture of the data to be delivered in a ReadA32 Command.
5193 AudioWG 20230822 ###decision: Spec will describe the bounds, and position within that is ImpDef.
5194 • Consider the earliest/latest times within the Phase when each byte of ReadData can be sampled internally.
5195 • Info1: ###TODO-Author check that this is in INFORMATIVE: Earliest: After the Peripheral has received
5196 sufficient of the address to know what to read. (but if reading before the CRC check then don’t do things
5197 that have side-effects!).
5198 • Info2: ###TODO-Author check that this is in INFORMATIVE: Latest: Just before each read data “byte”
5199 (10-bit symbol) is output.
5200 • Norm1: [###TODO-Author: normative rule Dresden FTF meeting added:] For a Read of more than 1 byte,
5201 the Peripheral SHALL NOT capture the value for a byte at a high address before sampling the data for a
5202 lower address. [“increment addresses monotonically”] … but it may sample multiple bytes simultaneously.
5203 • Perm1: [###TODO-Author: normative rule The “outside SWI3S” block may sample multiple bytes
5204 simultaneously.
5205 • Norm2: ###TODO-Author: normative rule: NOTE that side-effects are only formally committed after the
5206 Peripheral receives Manager Response of READ_DATA_OK.
5207 • Norm3: ###TODO-Author: normative rule: For remote addresses (not any registers described in this
5208 specification) if the Manager performs or repeats a READ_DATA Phase then the Peripheral SHALL deliver
5209 the _same_ data without re-sampling. i.e., the sampling operation occurs ONCE, in response to the
5210 ReadA32 Command in the READ_SETUP Phase.

5211 Requirements
5212 1. The structure of the ReadSetup Phase that describes a ReadA32 Command shall be according to Table 74.
5213 2. A Peripheral shall use the ReadAddress to determine whether a ReadA32 Command describes a Local Read
5214 or Remote Read, according to the Local/Remote column in Table 146.
5215 3. A Peripheral shall accept ReadA32 Commands that have a ReadByteCount (= R + 1) that is within the
5216 range shown in Table 101.
5217 Table 101 Local & Remote Reads
Type of Access Range of ReadByteCount Notes
Local Read 1 to Max_RBC_Local [1] —
Remote Read
1 to Max_RBC_Remote [1] Support for Remote Reads is optional
(see Section 9.2.2)

5218 Note:
1. The values of Max_RBC_Local and Max_RBC_Remote are implementation-defined and might be reported
in the datasheet and/or the DisCo data for the Peripheral Device.

5219 4. A Peripheral shall have a value of Max_RBC_Local that is between 1 and 256 inclusive.
5220 5. A Peripheral that supports Remote Reads shall have a value of Max_RBC_Remote that is between 1 and
5221 256 inclusive.
5222 6. A Manager shall be capable of generating ReadA32 Commands that have a ReadByteCount of every
5223 integer between 1 and 4.
5224 See also Permission 1 and Recommendation 1.

Copyright © 2019–2024 MIPI Alliance, Inc. 303

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
5225 7. A multi-byte ReadA32 Command from a SWI3S-defined Register address (see Table 146) shall access the
5226 set of bytes at adjacent increasing addresses starting at the 32-bit ReadAddress in the Manager Packet.
5227 Note: The set of bytes accessed by a multi-byte ReadA32 Command from a Device-defined address is
5228 implementation-defined and not necessarily the same as sequential incrementing addresses. The set of
5229 bytes accessed by a ReadA32 Command from an SDCA address is defined in [MIPI02].
5230 8. The Manager shall not generate ReadA32 Commands that address bytes in both the Local and Remote
5231 Regions in Table 146.
5232 9. The Manager shall not generate ReadA32 Commands with addresses that wrap (i.e., that require the
5233 address to be incremented to 0xFFFFFFFF + 1).
5234 10. The Peripheral shall interpret any of the conditions listed in Table 102 as a Command Error in a ReadA32
5235 Command (see Table 78 in Section 8.2.3 Requirement 2):
5236 Table 102 ReadA32 Command Errors
Notes
Error Name Condition
(informative)
Invalid Manager Packet Size Header:PacketLength ≠ 6 Manager Packet size is fixed at 6
Upper limit of ReadByteCount
ManagerPacket:RBC not within
range is ImpDef and can be
ReadByteCount Too Large ReadByteCount Range shown in
dependent on Local Read versus
Table 101.
Remote Read.
The address is in the
Device-defined region of the E.g., the ImpDef circuitry might
Bad Device-defined Address address map (see Table 146) accept only addresses that are
AND is invalid in an 4-byte aligned.
implementation-defined way.
The address is in the SDCA
region of the address map (see
Bad SDCA Address Table 146) AND the SDCA —
Specification ([MIPI02]) indicates
a Command Error.
The Peripheral might silently
1 or more of the addresses
accept reads even when 1 or
[optional] covered by this command are in a more addresses are
Unimplemented Address part of the address map that is unimplemented.
detected as unimplemented.
(See Permission 2.B.)

5237 11. When all of the bytes that are addressed in a ReadA32 Command are implemented, the Peripheral shall do
5238 both:
5239 A. Accept the Command and
5240 B. Return a valid data byte from each corresponding address.
5241 Note: see also Permission 2.
5242 12. When a Peripheral is in Remote Access State: Remote_Disabled and attempts to execute an error-free
5243 ReadA32 Command to a Remote Address, it shall discard the Command and generate a Peripheral
5244 Response of REMOTE_ACCESS_DISABLED (see Table 82).
5245 13. When a Peripheral is in Remote Access State: Remote_Write_Busy and attempts to execute an error-free
5246 ReadA32 Command to a Remote Address, it shall discard the ReadA32 Command and generate a
5247 Peripheral Response of REMOTE_WRITE_BUSY (see Table 81).

304 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
5248 14. When a Peripheral executes an error-free ReadA32 Command, it shall behave according to Table 103:
5249 Table 103 ReadA32 Command Behavior
Region of Peripheral Needs Read Peripheral Response (see Table 82)
Address Map More Time to Read Operation and
(see Table 146) All of the Bytes? Failed? [1] Peripheral Action
READ_DATA_NOW.
Local — No Attempt to deliver the bytes in a Peripheral Packet
(Non-deferable) followed by a CRC (see Requirement ###XREF) [#].
Address
— Yes [2] READ_FAILED.

READ_DATA_NOW.
Set Remote Access State to
Remote_Read_DataReady (see Section 9.2.2
Requirement ###XREF).
No No
Save the bytes for possible future retry in a
Read_Data Phase.
Attempt to deliver the bytes in a Peripheral Packet
Remote
followed by a CRC (see Requirement ###XREF) [#].
(Deferable)
Address READ_FAILED.
No Yes Set Remote Access State to Remote_Disabled
(see Section 9.2.2 Requirement ###XREF).
REMOTE_READ_DEFERRED.
Set Remote Access State to Remote_Read_Busy
Yes —
(see Section 9.2.2 Requirement ###XREF).
Attempt to perform the read operation later. [#]
1. “Failed” means that the internal Peripheral read operation failed (not the Command Transport Protocol).
2. A Local Read can fail only when it is reading from Registers in the ImpDef or SDCA spaces. A Read from
the SWI3S-defined Registers (see tables in Section 14.2) cannot result in a failure.

5250 15. ###TODO: Rules about interpreting the Manager Response (HD10): pick closest response (see
5251 Section 7.2.2 Requirement 13) and then …
5252 Deferable Address & READ_DATA_OK => state = Remote_Idle & retire the saved bytes and enact any side-effects
5253 (e.g., arming for IntClear).
5254 Deferable Address & READ_DATA_ERROR => state = Remote_Read_DataReady & retain the saved bytes and
5255 NOT enact any side-effects.
5256 ###TODO Author: Answers from AudioWG: for non-deferable (aka Local) reads, is the Peripheral behavior
5257 any different depending on the Manager Response of OK or Error? (yes, side-effects, see above)
5258 No, there should there NOT be an interrupt for reporting “Peripheral delivered this read data but the
5259 Manager rejected it so now it’s been discarded. If this was 5-9 bit errors in a READ_DATA_OK then the
5260 Peripheral will indicate BadHD10. If it was a clean READ_DATA_FAIL then the Manager knew what it was
5261 doing.
5262 16. ###TODO: Rules about the deferred read operation, which is asynchronous to the command transport
5263 protocol.
5264 Completed OK => set state = Remote_Read_DataReady.; enact any side-effects.
5265 Failure => set state = Remote_Disabled.; do not enact any side-effects.
5266
5267 17. ###TODO: Rules about the behavior of ReadData Phases.
5268

Copyright © 2019–2024 MIPI Alliance, Inc. 305

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
5269 Table 104 ###TODO: ReadA32 Command Behavior for ReadData Phases
Peripheral Response (see Table 82)
Remote Access State? [#] and
Peripheral Action
READ_DATA_NOW.
Remote_Read_DataReady Attempt to deliver the bytes in a Peripheral
Packet followed by a CRC (see
Requirement ###XREF) [#].
REMOTE_READ_DEFERRED.
Remote_Read_Busy Attempt to perform the read operation later.
[#]

5270 ###TODO:Author add note that if the read operation had failed then READ_DATA will see Remote Access
5271 State= Remote_Disabled and deliver Peeripheral response of REMOTE_DISABLED (see Table 83)
5272 18. {} When there is any internal side-effect of a read operation within the Peripheral, this shall happen
5273 synchronously with the Row Sync Point after the Row containing the 10th bit of the Manager Response
5274 symbol of READ_DATA_OK.
5275 19. {} For any bit shown in a Peripheral register as Reserved, the Peripheral shall return a 0 in the
5276 corresponding bit of the read data byte (see Permission 2).

5277 Permissions
5278 1. {} A Manager may be capable of generating ReadA32 Commands that have a ReadByteCount of up to 256.
5279 2. {} When 1 or more of the bytes addressed in a ReadA32 Command is/are Reserved or not implemented, the
5280 Peripheral may do either:
5281 A. Reject the Command by responding with COMMAND_ERROR, or
5282 B. Accept the Command (Requirement 11) and
5283 i. Return valid data for bytes that correspond to implemented addresses, and
5284 ii. Return data value zero for bytes that correspond to unimplemented or Reserved addresses.
5285 Note: “unimplemented” in this Permission includes Remote Address space in a Peripheral that does not
5286 implement any of that space.

5287 Recommendations
5288 1. {} A Manager should be capable of generating ReadA32 Commands that have a ReadByteCount of up to
5289 16.
5290

9.2.5 SSPA (Stream Synchronization Point Announcement) Command

5291 Requirements
5292 1. {} The Peripheral shall interpret any of the conditions listed in Table 105 as command encoding errors in an
5293 SSPA Command:
5294 Table 105 SSPA Command Errors
Notes
Error Name Condition
(informative)
Invalid Manager Packet Size Header:PacketLength ≠ 3 Fixed size of Manager Packet
ManagerPacket:RowDelay
Invalid Row Delay not in the set of valid values: ###
{14, 15}

306 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
5295 2. {} When the Peripheral detects a command encoding error shown in Table 105 it shall discard the
5296 command.
5297 Note: Announce Phases do not include a Peripheral Response, so this error is not signaled to the Manager
5298 within the Protocol.
5299 3. {} When the Peripheral executes an error-free SSPA Command it shall signal a Stream Synchronization
5300 Point at a time described by Section 8.2.1 Requirement 17 to all Data Ports that are members of any of the
5301 Commit Groups selected according to Section 8.2.1 Requirement 16.

Copyright © 2019–2024 MIPI Alliance, Inc. 307

9.2.6 ExitDormant Command

5302 Requirements
5303 1. {} The Peripheral shall interpret any of the conditions listed in Table 106 as command encoding errors in an
5304 ExitDormant Command:
5305 Table 106 ExitDormant Command Errors
Notes
Error Name Condition
(informative)
Invalid Manager Packet Size Header:PacketLength ≠ Fixed size of Manager Packet
ManagerPacket:Opcode is Duplicate of Section 9.2.1
ExitDormant Command not
0x01 (ExitDormant) and this Requirement 7.B shown here
implemented
Opcode is not implemented. for clarity.

5306 2. {} When the Peripheral detects a command encoding error shown in Table 106 it shall;
5307 A. Discard the command, and
5308 B. [optional when in state Dormant] Increment the Command Error counter.
5309 Note: Announce Phases do not include a Peripheral Response, so this error is not signaled to the Manager
5310 within the Protocol.
5311 3. {} When a Peripheral in Link State:Dormant detects an error-free ExitDormant Command, it shall re-attach
5312 to the bus (see Section 5.2.2 Requirement 21).

308 Copyright © 2019–2024 MIPI Alliance, Inc.

9.2.7 SSCR and DSCR Commands

5313 Requirements
5314 1. {} The Peripheral shall interpret any of the conditions listed in Table 107 as a Command Error in an SSCR
5315 or DSCR Command (see Table 78 in Section 8.2.3 Rule #2):
5316 Table 107 SSCR / DSCR Command Errors
Notes
Error Name Condition
(informative)
Invalid Manager Packet Size Header:PacketLength ≠ 3 Fixed size of Manager Packet
ManagerPacket:RowDelay
Invalid Row Delay not in the set of valid values: —
{14, 15}
ManagerPacket:Opcode is Duplicate of Section 9.2.1
DSCR not implemented 0x01 (DSCR) and this Requirement 7.B shown here
Opcode is not implemented. for clarity.

5317 2. {} When the Peripheral executes an error-free DSCR Command it shall issue a Commit Synchronization
5318 Point at a time described by Section 8.2.1 Requirement 17 to all Data Ports that are a member of 1 or more
5319 of the Commit Groups selected according to Section 8.2.1 Requirement 16.
5320
5321 3. {} When the Peripheral executes an error-free SSCR Command it shall issue a both a Commit
5322 Synchronization Point and a Stream Synchronization Point at a time described by Section 8.2.1
5323 Requirement 17 to all Data Ports that are a member of 1 or more of the Commit Groups selected according
5324 to Section 8.2.1 Requirement 16.
5325
5326 ###TODO-Author: Add a requirement describing effect of Commit Synchronization Point in the Register chapter.
5327 At a Commit Synchronization Point, the Peripheral shall copy the value of all selected *_NEXT Registers to the
5328 corresponding *_CURR Register.
5329 ###TODO-Author: check whether this statement about HD10 has been completely replaced by the special rules in
5330 the Command parsing about not abandoning Commands in the critical section.
5331 Explain that IF the Peripheral Phase Engine gets to the start of the Manager Response then the HD10 symbol
5332 detector will consume the next 10 CDS bits to make its go/no-go decision, even if the SPM detector fires part way
5333 through that symbol.
5334

9.2.7.1 Handling Detach Events during Commit Phases:

5335 ###TODO-Author: split this into some numbered requirements plus some informative material.
5336 IF the Peripheral Link State Machine detaches from the bus (e.g., because of PHY_RowSyncIsBad) after that
5337 Peripheral has sent a Peripheral Response of COMMIT_READY but before it has seen the 10th bit of the Manager
5338 Response then it shall perform the Commit action immediately (i.e., act as if it has received a Manager Response of
5339 CONFIRM_COMMIT and the Row Delay has just reached the specified value).
5340 Note:
5341 It is better to assume that a Commit is confirmed rather than cancelled because this is the far more common
5342 Manager action. The reason for doing this immediately rather than after the expected number of rows is that
5343 when the Peripheral has detached, it will begin searching for Command Sync and this search could be
5344 confused by a delayed change to the number of columns.

Copyright © 2019–2024 MIPI Alliance, Inc. 309

9.2.8 Ping Command

5345 Requirements
5346 1. {} The Peripheral shall interpret any of the conditions listed in Table 108 as a Command Error in a Ping
5347 Command (see Table 78 in Section 8.2.3 Rule #2):
5348 Table 108 Ping Command Errors
Notes
Error Name Condition
(informative)
Manager Packet is just 1 byte
Invalid Manager Packet Size Header:PacketLength ≠
(Opcode)

5349
5350 ###TODO-Author: missing requirement to introduce Table 109.
5351 Table 109 Peripheral Status Information in Ping Command

Alert Status
Remote Access State
(one or more Peripheral Info
is Remote_Write_Busy
enabled Robust Token Notes
or Remote_Read_Busy
interrupts are (See Table 64)
(see Table 96)
active)

Alert AND
PING_ALERT_BUSY
YES YES Remote Transaction in
10
Progress

PING_ALERT
YES No Alert
8

PING_ATTACHED_BUSY Remote Transaction in

No YES
6 Progress

PING_ATTACHED
No No Attached
0

5352
1. ###
5353 ###TODO-Author:
5354 Return status indicating:
5355 • whether or not the Peripheral has an alert status (i.e. at least one interrupt source has (IntStat_nn=1) AND
5356 (IntEn_nn=1).
5357 • for peripherals that implement remote accesses: whether the Remote Access State is busy, i.e. is there an
5358 incomplete buffered write operation or a split read transfer that is NOT yet ready to deliver its read data.
5359 Note:
5360 A split read for which data becomes ready will report Ping Info of simply Attached (or Alert): it is up to the
5361 Manager to know that it had issued a ReadSetup and thus that not being remote_busy means that the
5362 peripheral is ready for a READ_DATA Phase.
5363

310 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
5364 Recommendations
5365 1. When the Manager receives an undriven Ping Responses (i.e., a 10’b1111111111 input to the 8b/10b
5366 Decoder) from a Peripheral that:
5367 i. is selected in the Ping Command, and that:
5368 ii. was previously attached to the bus, and that:
5369 iii. has not been placed in a Dormant state, then
5370 A. The Manager should repeat the Ping Command at least once before it assumes that the Peripheral has
5371 become detached.

Copyright © 2019–2024 MIPI Alliance, Inc. 311

9.2.9 Unblock Command

5372 Requirements
5373 1. The Peripheral shall interpret any of the conditions listed in Table 110 as a Command Error in an Unblock
5374 Command (see Table 78 in Section 8.2.3 Rule #2):
5375 Table 110 Unblock Command Errors
Notes
Error Name Condition
(informative)
Manager Packet is just 1 byte
Invalid Manager Packet Size Header:PacketLength ≠
(Opcode)

5376 2. Executing an error-free Unblock Command sets the Command Execution State to Running. (See Table 94
5377 in Section 9.2.1 Requirement 1).
5378 Note: The Unblock Command does not affect the Remote Access State. If the Remote Access State is
5379 Remote_Disabled then this can be cleared to Remote_Idle by writing 1 to the RW1C bit:
5380 IntStat_RemoteDisabled (see Section 9.2.2 Requirement 6).

312 Copyright © 2019–2024 MIPI Alliance, Inc.

9.2.10 InitCal & TrimCal Commands

5381 Requirements
5382 1. The Peripheral shall interpret any of the conditions listed in Table 111 as a Command Error in a InitCal or
5383 TrimCal Command (see Table 78 in Section 8.2.3 Rule #2):
5384 Table 111 InitCal & TrimCal Command Errors
Notes
Error Name Condition
(informative)
Invalid Manager Packet
Header:PacketLength ≠ 3 Fixed length Manager Packet
Size
Maximum calibration packet
Bad Calibration Length ManagerPacket:CalibrationLength > 63
length is 64 × 30 = 1920 Rows.
min_adjust_length is imp-def,
ManagerPacket:AdjustLength <
Bad Adjust Length see Section 9.2.10
Peripheral_min_adjust_length
Rule ###XREF.

5385 #rules for 2 opcodes:

5386 ###TODO-Author: following Munich FTF:
5387 2 Opcodes
5388 • InitCal: SHALL start at the Cold Reset value of PHY3_CalibrationDelay (i.e., 0xA0= −1 UI).
5389 • TrimCal: SHALL start at current delay. MAY use a different algorithm to InitCal.
5390 After Opcode …
5391 Parameter N represents number of 30-bit Calibration Blocks. Excess-1 encoded (0 means 1 Block, etc.). (N+1) x3
5392 x10 Rows. (N+1) x 10 measurements. Valid range for N is 0..63. N >= 64 is not allowed, so generates Peripheral
5393 Response=COMMAND_ERROR.
5394 Parameter A represents number of 3-bit measurements during which the Peripheral ADJUSTS its timing. Naturally
5395 encoded (0 means 0 adjustment measurements, etc.). (10*(N+1)) - A is the number of checking measurements.
5396 INFORMATIVE: The algorithms for InitCal might not be identical, e.g., InitCal might start with large time steps
5397 and TrimCal might start with small time steps.
5398
5399
5400 NORMATIVE: Both commands: excursion is limited by the 2 register fields PHY3_CalibrationDelayMax and
5401 PHY3_CalibrationDelayMin (see Table 162) which are both 8-bit 2’s complement fields (sign, 3 integer, 4 fraction).
5402 NORMATIVE: If the peripheral does not implement all of the fraction bits then these are fixed at 0 (and read back
5403 as 0 so that the Manager can know this).
5404
5405
5406 NORMATIVE: There is a 1 byte register for reading and writing the current value of the Peripheral delay. So an
5407 alternative to InitCal is writing an approximately correct value followed by TrimCal.
5408
5409 DRAFT INFORMATIVE:
5410 Cold Reset value of Peripheral PHY3_CalibrationDelayMin/Max (see Table 162) delay limits are -6 UI and +1
5411 31/32 UI. The Min/max limits can be adjusted before a subsequent InitCal or TrimCal.
5412

Copyright © 2019–2024 MIPI Alliance, Inc. 313

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
5413 InitCal algorithm can move the delay over a wide range (>= +10 ns to -30 ns), so the Manager only issues InitCal
5414 when the combination of Clock Config and Transport pattern provides enough space for the Peripheral output not to
5415 clash with other Devices on the bus.
5416
5417 Decide on the limits of excursion in a peripheral: min guaranteed and max permitted. Placeholders/notes for adding
5418 timing parameters for the PHY3_CalDelay_CURR are at the start of Section 12.2.3.
5419 Niel has draft registers with:
5420 Cal upper and lower
5421 InitCal min/max of sign+1 integer+2 fractional bits.
5422 TrimCal min/max RELATIVE to current delay of
5423
5424 ###TODO-Author Add an informative figure showing how a calibration packet that is shown as a block of 30 bits in
5425 Figure 83 is actually 1 bit per Row, as they are not actually adjacent on the bus.
5426

314 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
10 Transport Pattern (Rows & Columns)
5427 This Section (10) describes the Clock Config and the Transport Pattern of data transported on a SWI3S interface.
5428 Section 12.3 contains more detail about how transport parameters in Link Control and Data Port Registers control
5429 the transport of Control Data Stream and payload data respectively.
5430 Note:
5431 The Transport Patterns in this section are examples used to illustrate how UIs might be assigned to different
5432 types of payload in a system. These Transport Patterns are used only to illustrate some of the possibilities,
5433 and many other arrangements of bits are possible.

10.1 Description (informative)

10.1.1.1 Preceding Material Related to Section 10

5434 The Technical Overview in Section 4 contains some introductory material about Rows and Columns including:
5435 Section 4.2.1: a brief introduction to the terminology used to describe Rows and Columns.
5436 Section 4.2.2: a general description of Rows of Unit Intervals, including a simple figure of 1 Row.

10.1.2 Transport Clocking and Unit Intervals

5437 The Manager generates a bit clock that divides the Row into an equal number of Unit Intervals (from 2 to 32). The
5438 way in which the Peripheral receives the bit clock is PHY-dependent:
5439 For the DLV PHY: The Manager generates Sync bits to indicate Row Sync Points, and the Peripheral
5440 recovers the bit clock using a DLL or PLL.
5441 For the FBCSE PHY: The Peripheral receives a forwarded bit clock from the Manager directly on an input
5442 pin.
5443 The Link Power Management methods described in Section 5 include entry and exit from Standby modes (when
5444 internal clocks within devices might stop).

10.1.3 Relation of Rows to Audio Clocking

5445 The Manager delivers clock edges to the Peripherals, including an edge (which is in the Clock or Data signal
5446 depending upon the selected PHY) indicating the Row Sync Point with timing properties (jitter, etc.) that are good
5447 enough for this edge to be used as an audio quality sampling clock.
5448 The signaling method for the Row Sync Point is PHY dependent:
5449 For the DLV PHY: The Row Sync Point is encoded as data transitions from a Sync0 bit to a Sync1 bit in
5450 the Row Sync Sequence. A Peripheral might use this transition directly as an audio sampling clock, rather
5451 than selecting the corresponding edge in the recovered bit clock.
5452 For the FBCSE PHY: The Row Sync Point is the transition in the bit clock that is associated with the start
5453 of Column 0, relating to the position of the Control Data Stream in the Row. A Peripheral can identify this
5454 particular edge within the sequence of bit clock edges by using its Column counter, which is synchronized
5455 by the Command Protocol Layer identifying the position of the Control Data Stream.
5456 The Peripheral typically uses the Row Sync Points as an audio sample clock (either directly or via a DLL or PLL).
5457 All Devices support the relationship between the Sample Rate and the Row Rate being either of:
5458 • 1 Sample per Row.
5459 • 1 Sample per N Rows, where N is integer.
5460 Some Devices (typically those transporting PCM streams) also support the relationship being:
5461 • 1 Sample per N or (N+1) Rows, where intervals between Samples are a mix of these two numbers to give a
5462 mean value that is (N + x/y), e.g., to use sample rates from the 44.1 kHz family with Row rates targeted at
5463 the 48 kHz family, see [###XREF to Payload Transport].

Copyright © 2019–2024 MIPI Alliance, Inc. 315

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
10.1.4 Wide Bits
5464 In some scenarios, the duration of a single Unit Interval does not provide sufficient time for the PHY to convey a
5465 reliable value from some Transmitters to some Receivers within the system. (E.g., when the uncertainty between the
5466 recovered bit clocks in two Peripherals combines with longer settling time for reflections in a complex physical
5467 medium).
5468 Rather than increasing the duration for all Unit Intervals in these scenarios (and so decreasing the bitrate), SWI3S
5469 provides a mechanism named Wide Bits, in which the Manager configures the Peripherals so that some of the
5470 streams use multiple consecutive Unit Intervals for the Transmitter to communicate a single data bit to the Receiver.

10.1.4.1 Wide Bits in the PHY Layer

5471 The Transmitter generates the same data value throughout a Wide Bit period. The Transmitter treats a Wide Bit as a
5472 single bit, so the drive impedance does not change at the UI boundaries within the Wide Bit in the way that it might
5473 change at the boundaries between bits or Wide Bits for some PHYs and PHY settings. The time at which the
5474 Receiver captures the data value from a Wide Bit will be dependent on the currently selected PHY and the PHY
5475 control settings.

10.1.4.2 Wide Bits in the Transport Layers

5476 In the Transport Layer, the multiple Unit Intervals allocated to a Wide Bit transport just one data bit of payload. E.g.,
5477 if a Data Port were allocated 8 columns in which to transport payload data using a BitWidth of 2 then it would
5478 transport 4 data bits within the 4 Wide Bits that fit within those columns, and the next data bits would flow into more
5479 Wide Bits in the same 8 Columns in the next Row in the same way that data bits flow in regular bits.
5480 The effect of Wide Bits on Payload Transport is discussed in more detail in Section 12.3.

316 Copyright © 2019–2024 MIPI Alliance, Inc.

10.1.5 Key to Bits Used in Transport Patterns

5481 This Section describes the bits used in the Transport Pattern and provides a key to the symbols used to represent
5482 them in the diagrams.

10.1.5.1 Wide Bits

5483 Figure 120 illustrates some examples of the symbols used to represent Wide Bits in the Transport Pattern diagrams.
5484 The labels: “x2”, “x3”, “x4”, etc. describe the number of UIs in the Wide Bit.

C D S0 x2

Bit name x2 C x2 D x2

Bit name x3 C x3 D x3

Bit name x4 C x4 D x4
5485
Figure 120 Key to Wide Bits in Transport Pattern Diagrams

10.1.5.2 Control Data Stream Bits

5486 Figure 121 illustrates the symbols used to represent parts of the Control Data Stream in the Transport Pattern
5487 diagrams.

CDS Control Data Stream CDS x2

CDS Control Data Special *CDS x2

S1 M-CDS
C HandOver (S1-to-CDS) M-CDS x2

Idle Control Data: Idle Idle x2

5488
Figure 121 Key to Control Data Stream Bits

5489 C: or CDS: represents a generic Control Data Stream bit that might be driven by either the Manager or a Peripheral
5490 (or indeed by undriven in some special cases). The rules for driving these bits are defined as part of the Command
5491 protocol Layer (see Section 8).
5492 Control Data Special: (with a grey dotted line above it) represents a PHY-specific special drive mode
5493 (passive-1-active-0) for the Control Data Stream that is used in the boot-up mode for some PHYs (see, e.g.,
5494 [###XREF to DLV PHY]).
5495 HandOver (S1-to-CDS): (for some PHYs, e.g., DLV) represents a special case that is either Manager CDS or
5496 HandOver (see Section 10.1.5.4.1).
5497 Idle: represents a Control Data Stream bit when the Manager is driving the Idle pattern (pairs of 0 and 1 bits).

Copyright © 2019–2024 MIPI Alliance, Inc. 317

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
10.1.5.3 Payload Bits
5498 Figure 122 illustrates the symbols used to represent Payload Data Stream bits in the Transport Pattern diagrams.

SSP (Stream Synchronization Point)

D Payload Datastream D x2

PD Datastream: Peripheral PD x2

MD Datastream: Manager MD x2

D1 Datastream Number 1 D1 x2

PD2 Datastream Number 2 PD2 x3

MD3 Datastream Number 3 MD3 x4

5499
Figure 122 Key to Payload Bits

5500 Blue Dot in Red Ring: represents a Stream Synchronization Point (SSP) when all of the streams shown in the figure
5501 would simultaneously experience a sampling event and the Transport Pattern starts its periodic repeat.
5502 D: represents a Payload bit from a Data Port, which might be driven by either the Manager or a Peripheral.
5503 PD: represents the specific case of a Payload bit from a Data Port that is known to be driven by the Peripheral.
5504 MD: represents the specific case of a Payload bit from a Data Port that is known to be driven by the Manager.
5505 D1, PD2, MD3, etc.: represent the case when different Data Ports and/or devices are driving Payload bits.

318 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
10.1.5.4 PHY-Related Bits and Unit Intervals
5506 Some types of bits and UIs relate to behavior of the PHY layer. Some of these are deployed according to
5507 system-specific conditions, or only when a system is built on a particular PHY. Figure 123 illustrates the symbols
5508 used to represent these PHY-related bits or UIs in the Transport Pattern diagrams.

Row Sync Point

<Bit in Column 0>

S0 S1 LVDS PHY: Sync 0 LVDS PHY: Sync 1

HandOver

M-CDS
HandOver (S1-to-CDS) M-CDS x2

K Bus Keeper

K0 Bus Keeper 0

K1 Bus Keeper 1

PHY: Tail

G(C) Guard Bit: CDS

G(D1) Guard Bit: Datastream1

G(D2) Guard Bit: Datastream2

5509
Figure 123 Key to PHY-Related Bits and Unit Intervals

5510 Red Arrow: represents the Row Sync Point that defines the start of the Row, i.e., the start of Column 0. How this is
5511 information is conveyed to the Peripherals is PHY-specific (see Section 4.2.4.2).
5512 S0: (for DLV PHY) represents a Sync0 bit driven by the Manager. The Manager drives one or more Sync0 bits prior
5513 to Sync1 in order to dampen any existing signal reflections on the bus and so reduce ISI impact on clock jitter of the
5514 following Row Sync Point.
5515 S1: (for DLV PHY) represents a Sync1 bit driven by the Manager. The signal transition from Sync0 to Sync1
5516 defines the Row Sync Point in this PHY.
5517 Two Black Arrows: represents a HandOver Unit Interval. These are allocated within a Transport Pattern to create
5518 undriven Unit Interval(s) to separate periods when the bus is driven by two different transmitters. This provides
5519 timing margin for the possible time offset (due to systematic error and jitter within devices) between when the two
5520 transmitters drive the bus, and for propagation delays between different transmitting and receiving devices.
5521 HandOver (S1-to-CDS): (for some PHYs, e.g., DLV PHY) represents a special case that is either Manager CDS or
5522 Handover (see Section 10.1.5.4.1).
5523 K: represents a Keeper Unit Interval. When no transmitter is driving the bus then a bus keeper circuit (in the PHY
5524 within the Manager) maintains the current signal level.
5525 K0: represents a Keeper Unit Interval when it is known that the bus keeper is maintaining the value 0 from a
5526 preceding Bit.

Copyright © 2019–2024 MIPI Alliance, Inc. 319

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
5527 K1: represents a Keeper Unit Interval when it is known that the bus keeper is maintaining the value 1 from a
5528 preceding Bit.
5529 Tail: represents a Tail bit that is a copy of the signal value in the previous Unit Interval, and that is configurably
5530 appended to a stream of bits by the PHY to dampen reflections on the medium before the undriven period associated
5531 with a HandOver, and to reduce EMC issues.
5532 G: represents a Guard Bit that is configurably appended to a stream of bits by a Data Port (or the Command Protocol
5533 Engine) to assist in removing data-dependent crosstalk (e.g., electrical or thermal) from one Transmitter to the next
5534 Transmitter.

10.1.5.4.1 Special Case of HandOver from Sync1 to Control Data Stream

5535 In some PHYs, e.g., DLV PHY, the Manager always drives the Sync1 Unit Interval(s), which are then followed by 1
5536 or more HandOver UIs before the CDS bit. The Manager orchestrates the use of the Control Data Stream, so always
5537 knows which device owns the CDS bit.
5538 • When the Manager owns the CDS bit then it drives the CDS value onto the bus during the HandOver UI(s).
5539 This gives an earlier stable CDS value for Peripherals to capture, which might help Peripherals to find the
5540 Control Data Stream more reliably, e.g., when their clock recovery circuitry is still settling.
5541 • When a Peripheral owns the CDS bits then the Manager behaves as for a normal HandOver, turning off its
5542 drive after the Sync1.

10.1.5.4.2 Keeper versus HandOver

5543 All Audio-mode PHYs in the Manager have a bus keeper circuit for maintaining the current physical signaling level
5544 on an active bus when there is no explicit owner to drive level. This bus keeper maintains the level both in the UI(s)
5545 explicitly allocated for HandOver between owners, and in runs of UIs that have not been allocated to any owner.
5546 Some Transport Pattern diagrams use the HandOver symbol to identify only the first, explicitly allocated, HandOver
5547 UI, and then the Keeper symbol for other instances of no owner. This is just a documentation convention, and
5548 behavior of the PHYs is not different between Handover and Keeper UIs. Showing these extra unallocated UIs as
5549 Keeper means that it is easier to see the spare bandwidth in a Transport Pattern.

320 Copyright © 2019–2024 MIPI Alliance, Inc.

10.1.6 Command-Only Transport Patterns

5550 Any Transport Pattern that has no bits allocated to audio payload is referred to as Command-Only. This type of
5551 Transport Pattern is used to enable the Peripheral(s) to find the Row Sync Points, during cold boot, sleep-wake, and
5552 (for some Peripherals) when they re-attach to the bus after they have lost sync.

10.1.6.1 Single Rising Edge for Command-Only Transport Patterns

5553 Figure 124 shows an example of a Command-Only Transport Pattern for the DLV PHY. The bus keeper maintains
5554 the value from the Control Data Stream bit during the HandOver in Column 3, and for the remainder of the Row
5555 leading up to the Row Sync Sequence (S0 and S1). When the Manager does not own the Control Data Stream data
5556 bit then the bus keeper also maintains the value of the Sync1 bit during the HandOver to the Peripheral Device in
5557 Column 1.

Row Sync Point

... 14 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0
... S0 x2 S1 M-C
C K K K K K K K K K K S0 x2 S1
5558
Figure 124 Command-Only Transport Pattern

5559 The effect of this Transport Pattern and the keeper behavior leads to a waveform on the bus that has a single rising
5560 edge (i.e., DLV-0 to DLV-1 transition) at the Row Sync Point, and a single falling edge at a position that is
5561 modulated by the owner and contents of the Control Data Stream, as shown in Figure 125.

Row Sync Point

... 14 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0
... S0 x2 S1 M-C
C0 K0 K0 K0 K0 K0 K0 K0 K0 K0 K0 S0 x2 S1

... S0 x2 S1 M-C
C1 K1 K1 K1 K1 K1 K1 K1 K1 K1 K1 S0 x2 S1

Manager CDS=0

Peripheral CDS=0

Manager or Peripheral CDS=1

Overlay of all cases showing that single rising edge

is at a constant position

5562
Figure 125 Command-Only Transport Pattern: Single Rising Edge

Copyright © 2019–2024 MIPI Alliance, Inc. 321

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
10.1.7 Initial Transport Patterns for DLV PHY

10.1.7.1 Initial Clock Config and Transport Pattern for DLV PHY after Cold Start (Safe-Lock-4)
5563 In systems that use the DLV PHY, the initial Clock Config after a Cold Start is compatible with Devices that have
5564 default values in their PHY control registers. This initial Clock Config operates at a “Safe Speed”, i.e., a bit rate with
5565 a unit interval large enough for signals to propagate reliably between the Manager and any Peripheral (in either
5566 direction) in any valid size of system and when the Transmitters in the PHYs have default edge rates and PHY
5567 timing calibration has not yet been completed.
5568 The initial Transport Pattern is a Command-Only pattern that facilitates Peripheral Devices locking their clock
5569 recovery circuits to the waveform; the combination of 4-Column Clock Config at a safe speed and Transport Pattern
5570 that facilitates PLL/DLL lock is named “Safe-Lock-4”.
5571 Figure 126 shows the Transport Pattern used in Safe-Lock-4. When the Peripheral owns the CDS bits it uses a
5572 special drive mode (passive 1, active 0) to avoid clashing with the subsequent Sync0 bit driven by the Manager. The
5573 Cold Reset values of the Peripheral UI Rate Range and Row Rate Range register fields allow for a range of possible
5574 frequencies in the actual Clock Config generated by the Manager. This figure illustrates 4 possibile Clock Configs:
5575 • 2.400 MRows/sec × 4 columns = 9.600 Mbps.
5576 • 2.8224 MRows/sec × 4 columns = 11.2896 Mbps.
5577 • 3.072 MRows/sec × 4 columns = 12.288 Mbps.
5578 • 3.200 MRows/sec × 4 columns = 12.800 Mbps.

Row Sync Point

0 1 2 3
S1 CDS-Special S0

UI rate 9.60 Mbps (104.167 ns)

Safe-Lock-4 @ 2.40 MRows/s

Row Sync Point

0 1 2 3
S1 CDS-Special S0

UI rate 11.2896 Mbps (88.58 ns)

Safe-Lock-4 @ 2.8224 MRows/s

Row Sync Point

0 1 2 3
S1 CDS-Special S0

UI rate 12.288 Mbps (81.38 ns)

Safe-Lock-4 @ 3.072 MRows/s

Row Sync Point

0 1 2 3
S1 CDS-Special S0

UI rate 12.80 Mbps (78.125 ns)

Safe-Lock-4 @ 3.20 MRows/s

5579
Figure 126 Initial Transport Pattern for PHY3 (DLV) – Safe-Lock-4

322 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
10.1.7.2 Initial Transport Patterns for DLV PHY during Warm Boot / Sleep-Wake (Lock-N)
5580 In systems that use the DLV PHY, the initial Transport Pattern in the warm boot (sleep-wake) sequence is a
5581 Command-Only Transport Pattern. This will be the content of the *_CURR Registers (which were copied from the
5582 *_NEXT Registers by the Commit operation that caused the Peripheral to go to sleep).
5583 The single rising edge of the Command-Only Transport Pattern facilitates clock recovery circuits (PLL/DLL)
5584 locking to the Clock Config, so this type of Transport Pattern is also used in the following 2 cases:
5585 • The second Clock Config used in a cold boot sequence, following Safe-Lock-4.
5586 • Any subsequent Clock Config if any of the Peripheral Devices in the specific system need to relock their
5587 clock recovery PLL/DLL.
5588 The exact details of the Transport Pattern will be system-dependent, but might be chosen to help Peripherals that
5589 have lost some of their fine timing calibration during the period of non-operation while the Link was in Standby.
5590 Figure 127 illustrates several example Command-Only Transport Patterns that might be used with the DLV PHY.

Row Sync Point

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-C
C S0

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-C
C S0 x2

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-C
C x2 S0 x2

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS x2 C x4 S0 x2

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS x4 *C x4 S0 x4

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
S1 M-C
C S0

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
S1 M-C
C S0 x2

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
S1 M-C
C x2 S0 x2
5591
Figure 127 Example Transport Patterns: Command-Only for DLV PHY (Lock-N)

5592
5593 ###TODO-AUTHOR: show Command-Only patterns that will be more typical for Sleep-Wake cycles, e.g., Row
5594 with some data, row with data removed which will be Command-Only, row with some or all of the data reinstated
5595 (maybe a 2-pase process with Mics beingf switched on immediately and amps a bit later after more re-initialization /
5596 preparation).
5597

Copyright © 2019–2024 MIPI Alliance, Inc. 323

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
10.1.8 Initial Transport Patterns for FBCSE PHY

10.1.8.1 Initial Transport Patterns for FBCSE PHY after Cold Boot or Warm Boot (Sleep-Wake)
5598 The FBCSE PHY uses a forwarded bit clock so that the Peripherals can unambiguously sample data bits from the
5599 bus. Thus the Command-Only Transport Patterns for this PHY are much simpler than the DLV PHY. Figure 128 and
5600 Figure 129 show some example Command-Only Transport Patterns that might be used with the FBCSE PHYs after
5601 either Cold Start (cold boot) or Warm Start (sleep-wake). The UIs allocated to the Control Data Stream are identical
5602 for both PHYs, and the only difference is whether UIs are reserved for HandOver:
5603 • FBCSE PHY2 (Figure 128) uses explicitly allocated HandOver UIs.
5604 • FBCSE PHY1 (Figure 129) uses self-timed intra-UI (“hidden”) HandOvers.

Row Sync Point

0 1
CDS

0 1 2 3
CDS

...
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
CDS
5605
Figure 128 Example Transport Patterns: Command-Only for FBCSE PHY2

Row Sync Point

0 1
CDS

0 1 2 3
CDS

...
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
CDS
5606
Figure 129 Example Transport Patterns: Command-Only for FBCSE PHY1

324 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
10.1.8.2 NRZS Encoding of Control Data Stream with FBCSE PHY
5607 The FBCSE PHY uses NRZS encoding of the Control Data Stream bit (relative to the UI in the final Column of the
5608 previous Row). This provides unambiguous detection of the column containing the Control Data Stream, even in a
5609 Command-Only Transport Pattern when the keeper will maintain the value of the CDS bit across every Column.
5610 Figure 130 shows a fragment of a Transport Pattern for the FBCSE PHY, and then the resulting signal levels after
5611 encoding each of CDS=0, CDS=1, and an undriven CDS UI.

Row Sync Point

N-2 N-1 0 1 2 3 4
Data Data Data Data Data
(N-2) (N-1) CDS (2) (3) (4) Fragment of Transport Pattern for FC-SE PHY

N-1 0
Data CDS=0 is encoded by inverting the data from
(N-1)
CDS
Column N-1 at the end of the previous Row
___
N-1 N-1
Decoded CDS=0

N-1 0
Data CDS=1 is encoded by repeating the data from
(N-1) CDS
Column N-1 at the end of the previous Row

N-1 N-1
Decoded CDS=1

N-1 0 When CDS is undriven (e.g., because a Peripheral is not yet responding to Ping),
Data
(N-1) CDS the bus-keeper maintains the data from Column N-1 at the end of the previous
Row, which is thus decoded as CDS=1.
N-1 (N-1)

5612 Decoded CDS=1

Figure 130 NRZS Coding of Control Data Stream with FBCSE PHY

10.1.8.2.1 Locating Column 0 in a Command-Only Transport Pattern

5613 Figure 131 shows 9 Rows of an example waveform on the Data signal when a system using the FBCSE PHY uses a
5614 Command-Only Transport Pattern. The NRZS encoding of the Control Data Stream causes transitions in the data
5615 value whenever CDS=0. There is no other active stream owning UIs in the Row, so the Bus Keeper maintains the
5616 data value until it is changed by a later encoded CDS=0. A Peripheral in search mode can easily identify the location
5617 of the CDS (and hence of Column 0) from these transitions.

Row Sync Points

C= 0 C= 0 C= 1 C= 1 C= 0 C= 1 C= 0 C= 0 C= 0
5618
Figure 131 Example of Data Waveform for Command-Only Transport Pattern for FBCSE PHY
5619 ###TODO-Author: illustrate (either here or in the FBCSE PHY chapter) that the FIRST rising edge on DP is
5620 the clock edge that starts column 0. This helps with instant start up. The first 10 CDS bits from the Manager

Copyright © 2019–2024 MIPI Alliance, Inc. 325

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
5621 (i.e., the first 10 Rows) shall be Idle bits (zebra pattern) before the start of the earliest possible SPM from the
5622 Manager. Explanation: This allows for Peripherals that might take a small number of clock cycles to recover
5623 from reset.
5624 Note: a Peripheral may choose to initialize its SPM detector sooner than the 11th row.
5625 Draw a simple diagram showing the transition from LC signaling to the first clock edge at the start of column 0.
5626 NOTES:
5627 After a Cold Start, the Column count is 2, so 10 Rows is the same as 10 clock cycles.
5628 After a Warm Start (sleep-wake), the Column count is unchanged from prior to sleep so can be any even number
5629 from 2 to 32, so 10 Rows is 10 to 160 clock cycles.

326 Copyright © 2019–2024 MIPI Alliance, Inc.

10.1.9 Examples of Transport Patterns for DLV PHY

5630 This Section (10.1.9) shows example Transport Patterns for the DLV PHY.

10.1.9.1 Example Transport Pattern for PCM Audio

5631 Figure 132 illustrates a typical Transport Pattern for transporting PCM audio data streams. All of the bits in a
5632 sample are driven by the same device, so they can be packed adjacent to each other across all of Columns 4
5633 through 13 in the Row. This block of bits from one source is separated from data from other sources (such as the
5634 Control Data Stream) with HandOvers to avoid any clash between the two transmitters. The need for these
5635 HandOvers is PHY-dependent, but applies to most of the PHYs.
5636 This example includes the PHY-specific Sync0 and Sync1 bits associated with the DLV PHY. This example has only
5637 one Sync0 bit because, e.g., the interface is operating at lower bit rate and/or over a short physical medium.
5638 The Clock Config in the example in Figure 132 is 3.072 MRows/sec × 16 columns = 49.152 Mbps.
5639 The audio streams in this Transport Pattern are:
5640 • 4 channels of 20 bits.
5641 • The sample rate and SSP rate depend on how frequently this block of 8 Rows repeats, e.g.:
5642 • Sample Rate and SSP Rate = 48 kHz when the repeat length is 64 Rows (meaning that these channels
5643 occupy 12.5% of potentially usable payload bandwidth).
5644 • Sample Rate and SSP Rate = 96 kHz when the repeat length is 32 Rows (meaning that these channels
5645 occupy 25% of potentially usable payload bandwidth).

Row Sync Point

Copyright © 2019–2024 MIPI Alliance, Inc. 327

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
10.1.9.2 Example Transport Patterns for PDM Microphones

10.1.9.2.1 PDM Transport with Lowest Latency

5647 Figure 133 illustrates a simple Transport Pattern for transporting PDM data streams, e.g., from digital microphones.
5648 The samples are both produced and transported at a rate of one per Row, which results in low latency, but also lower
5649 bandwidth efficiency because of many HandOvers.
5650 This example includes the PHY-specific Sync0 and Sync1 bits associated with the DLV PHY. There are two Sync0
5651 UIs that would lower ISI on the Sync edge, which is used as an audio sample clock. This could lower jitter in a
5652 system with more challenging signal reflections, e.g., high bit rate over a long physical medium.
5653 The Clock Config in the example in Figure 133 is 3.072 MRows/sec × 16 columns = 49.152 Mbps.
5654 The audio streams in this example Transport Pattern are:
5655 • 5 channels of 3.072 MHz × 1-bit PDM; Sample Grouping = 1, so latency = 326 nsec.
5656 The SSP Rate in this example is 3.072 MHz because the pattern repeats every Row.
Row Sync Point

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C D1 D2 D3 D4 D5 S0 x2

S1 M-CDS
C D1 D2 D3 D4 D5 S0 x2

S1 M-CDS
C D1 D2 D3 D4 D5 S0 x2
5657
Figure 133 Example TP: PDM Streams Without Sample Grouping (DLV PHY)

328 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
10.1.9.2.2 PDM Transport with Higher Bandwidth Efficiency
5658 Figure 134 illustrates another Transport Pattern for transporting PDM data streams, which uses sample grouping to
5659 make more efficient use of the bus than Figure 133 at the cost of a small increase in latency. The samples are
5660 produced at a rate of one per Row, but are transported as a group of 4 Samples that is repeated once every 4 Rows.
5661 The 2 groups of 4 Samples in the same Row are separated by a HandOver to avoid any clash between the two
5662 transmitters.
5663 The Clock Config in the example in Figure 134 is 3.072 MRows/sec × 16 columns = 49.152 Mbps.
5664 The audio streams in this Transport Pattern are:
5665 • 8 channels of 3.072 MHz × 1-bit PDM; Sample Grouping = 4, so latency = 1.30 µsec.
5666 The SSP Rate in this example is 768 kHz because the pattern repeats every 4 Rows.

Row Sync Point

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C D1 D1 D1 D1 D2 D2 D2 D2 S0 x2

S1 M-CDS
C D3 D3 D3 D3 D4 D4 D4 D4 S0 x2

S1 M-CDS
C D5 D5 D5 D5 D6 D6 D6 D6 S0 x2

S1 M-CDS
C D7 D7 D7 D7 D8 D8 D8 D8 S0 x2

S1 M-CDS
C D1 D1 D1 D1 D2 D2 D2 D2 S0 x2
5667
Figure 134 Example TP: PDM Streams with Sample Grouping (DLV PHY)

Copyright © 2019–2024 MIPI Alliance, Inc. 329

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
10.1.9.2.3 PDM Transport for 1 Microphone in Low-Power Mode
5668 Figure 135 illustrates a very simple scenario with 1 PDM microphone in Low-Power Mode (i.e., low Sample Rate).
5669 The Clock Config has 16 Columns but Columns 5 through 13 have no transitions in the signal level, so do not
5670 contribute anything to Link power consumption.
5671 The Clock Config in the example in Figure 135 is 768 kRows/sec × 16 columns = 12.288 Mbps.
5672 The audio stream in this Transport Pattern is:
5673 1 channels of 768 kHz × 1-bit PDM; Sample Grouping = 1, so latency = 1.30 µsec.
5674 The SSP Rate in this example is 768 kHz because the pattern repeats every Row.
5675 Note:
5676 In this example the unused UIs are shown with the “K” symbol to emphasize that the bus keeper would
5677 maintain an unchanging value on the physical link for most of the Row, so these unused UIs do not
5678 contribute to system power consumption.

Row Sync Point

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C D1 K K K K K K K K S0 x2

S1 M-CDS
C D1 K K K K K K K K S0 x2

S1 M-CDS
C D1 K K K K K K K K S0 x2
5679
Figure 135 Example TP: 1 Low-Power PDM Mic Stream (DLV PHY)

330 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
10.1.9.3 Example Transport Pattern with Higher Column Count
5680 Figure 136 shows an example Transport Pattern that both combines PDM and PCM streams, and uses a higher
5681 column count.
5682 This example also illustrates that careful arrangement of streams can reduce the bandwidth that is “wasted” on
5683 handover between transmitters. Here the Payload data stream from the Manager (MD in Columns 14 through 21) is
5684 positioned immediately adjacent to the first UI of the Row Sync signal (S0 in Column 22). MD and S0 are both
5685 driven by the Manager, so it is not necessary to insert a HandOver between them.
5686 The Clock Config in the example in Figure 136 is 3.072 MRows/sec × 24 columns = 73.728 Mbps.
5687 The audio streams in this example are:
5688 • 8 channels of 3.072 MHz × 1-bit PDM.
5689 • Sample Grouping = 4, so latency = 1.30 µsec.
5690 • 2 channels of 16 bits from the Manager.
5691 • The sample rate and hence the SSP rate depend on how frequently the block of bits from the Manager Data
5692 Ports repeats, e.g.:
5693 • Sample Rate and SSP Rate = 48 kHz when the repeat length is 64 Rows.
5694 • Sample Rate and SSP Rate = 96 kHz when the repeat length is 32 Rows.

Row Sync Point

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
S1 M-CDS
C D1 D1 D1 D1 D5 D5 D5 D5 MD1 MD1 MD1 MD1 MD1 MD1 MD1 MD1 S0 x2

S1 M-CDS
C D2 D2 D2 D2 D6 D6 D6 D6 MD1 MD1 MD1 MD1 MD1 MD1 MD1 MD1 S0 x2

S1 M-CDS
C D3 D3 D3 D3 D7 D7 D7 D7 MD2 MD2 MD2 MD2 MD2 MD2 MD2 MD2 S0 x2

S1 M-CDS
C D4 D4 D4 D4 D8 D8 D8 D8 MD2 MD2 MD2 MD2 MD2 MD2 MD2 MD2 S0 x2

S1 M-CDS
C D1 D1 D1 D1 D5 D5 D5 D5 S0 x2

S1 M-CDS
C D2 D2 D2 D2 D6 D6 D6 D6 S0 x2

S1 M-CDS
C D3 D3 D3 D3 D7 D7 D7 D7 S0 x2
5695
Figure 136 Example TP: 24 Columns (DLV PHY)

Copyright © 2019–2024 MIPI Alliance, Inc. 331

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
10.1.10 Examples of Transport Patterns for FBCSE PHY2
5696 This Section (10.1.10) shows example Transport Patterns for the Forwarded-Bit-Clock Single-Ended PHY with
5697 explicit HandOver UIs (FBCSE PHY2). In contrast to the DLV PHY:
5698 • The FBCSE PHY does not use Sync0 and Sync1 bits, so the Row Sync Point is defined by the position of
5699 the Control Data Stream.
5700 • The FBCSE PHY uses a forwarded bit clock, so the bit rate can be whatever is appropriate for the Traffic
5701 Pattern.
5702 Note:
5703 Some components might impose constraints on the bit rate so that they can easily derive internal sampling
5704 rates from the forwarded bit clock that are higher than the PCM sample rate.

10.1.10.1 Example Transport Pattern for PCM Audio (FBCSE PHY2)

5705 The Clock Config in the example in Figure 137 is 384 kRows/sec × 16 columns = 6.144 Mbps.
5706 The audio streams in this example Transport Pattern are:
5707 • Manager Data: 2 channels of 48 kHz × 16-bit PCM.
5708 • Peripheral 3 Data: 2 channels of 48 kHz × 16-bit PCM.
5709 • Peripheral 4 Data: 2 channels of 48 kHz × 16-bit PCM.
5710 The SSP Rate in this example is 48 kHz because the pattern repeats every 8 Rows.

Row Sync Point

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
C MD1 MD1 MD1 MD1 P3Da P3Da P3Da P3Da P3Da P3Da P3Da P3Da

C MD1 MD1 MD1 MD1 P3Da P3Da P3Da P3Da P3Da P3Da P3Da P3Da

C MD1 MD1 MD1 MD1 P3Db P3Db P3Db P3Db P3Db P3Db P3Db P3Db

C MD2 MD2 MD2 MD2 P4Da P4Da P4Da P4Da P4Da P4Da P4Da P4Da

C MD2 MD2 MD2 MD2 P4Db P4Db P4Db P4Db P4Db P4Db P4Db P4Db

C MD1 MD1 MD1 MD1 P3Da P3Da P3Da P3Da P3Da P3Da P3Da P3Da
5711
Figure 137 Example TP: PCM Streams (FBCSE PHY2)

10.1.10.2 Example Transport Patterns for PDM Audio (FBCSE PHY2)

10.1.10.2.1 PDM Transport with Lowest Latency

5712 Figure 138 shows a simple Transport Pattern for transporting PDM data streams, e.g., from digital microphones.
5713 The samples are both produced and transported at a rate of one per Row, which results in low latency, but also lower
5714 bandwidth efficiency because of many HandOvers.
5715 The Clock Config in the example in Figure 138 is 3.072 MRows/sec × 6 columns = 18.432 Mbps.
5716 The audio streams in this example Transport Pattern are:
5717 • 2 channels of 3.072 MHz × 1-bit PDM; Sample Grouping = 1, so latency = 326 nsec.

332 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
5718 The SSP Rate in this example is 3.072 MHz because the pattern repeats every Row.

Row Sync Point

0 1 2 3 4 5
C D1 D2
C D1 D2
C D1 D2
C D1 D2
5719
Figure 138 Example TP: PDM Streams Without Sample Grouping (FBCSE PHY2)

10.1.10.2.2 PDM Transport with Higher Bandwidth Efficiency (FBCSE PHY2)

5720 Figure 139 illustrates another Transport Pattern for transporting PDM data streams, which uses sample grouping to
5721 make more efficient use of the bus than Figure 138 at the cost of a small increase in latency. The samples are
5722 produced at a rate of one per Row, but are transported as a group of 3 Samples that is repeated once every 3 Rows.
5723 The Clock Config in the example in Figure 139 is 3.072 MRows/sec × 6 columns = 18.432 Mbps.
5724 The audio streams in this example Transport Pattern are:
5725 • 3 channels of 3.072 MHz × 1-bit PDM; Sample Grouping = 3, so latency = 977 nsec.
5726 The SSP Rate in this example is 1.024 MHz because the pattern repeats every 3 Row.

Row Sync Point

0 1 2 3 4 5
C D1 D1 D1
C D2 D2 D2
C D3 D3 D3
C D1 D1 D1
5727
Figure 139 Example TP: PDM Streams with Sample Grouping (FBCSE PHY2)

Copyright © 2019–2024 MIPI Alliance, Inc. 333

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
10.1.11 Example Transport Patterns for FBCSE PHY1
5728 This Section (10.1.11) shows example Transport Patterns for the Forwarded-Bit-Clock Single-Ended PHY with
5729 self-timed HandOver UIs (FBCSE PHY1).
5730 In contrast to the DLV PHY and the FBCSE PHY2:
5731 • The FBCSE PHY1 does not need any UIs to be assigned to explicit HandOver between one transmitter and
5732 the next.

10.1.11.1 Example Transport Patterns for PDM Audio (FBCSE PHY1)

10.1.11.1.1 PDM Transport with Lowest Latency

5733 Figure 140 illustrates that the absence of HandOver UIs with FBCSE PHY1 means that multiple streams can be
5734 packed efficiently without the need to increase bit clock frequency or use sample grouping, which would increase
5735 latency.
5736 The Clock Config in the example in Figure 140 is 768 kRows/sec × 2 columns = 1.536 Mbps.
5737 The audio streams in this example Transport Pattern are:
5738 • 1 streams of 768 kHz × 1-bit PDM.
5739 The SSP Rate in this example is 768 kHz because the pattern repeats every Row.

Row Sync Point

0 1
C D1
C D1
C D1
5740
Figure 140 Example TP: 1 Slow PDM Mic (FBCSE PHY1)

5741 Figure 141 illustrates that the absence of HandOver UIs with FBCSE PHY1 means that multiple streams can be
5742 packed efficiently without the need to use sample grouping, which would increase latency.
5743 The Clock Config in the example in Figure 141 is 3.072 MRows/sec × 4 columns = 12.288 Mbps.
5744 The audio streams in this example Transport Pattern are:
5745 • 3 streams of 3.072 MHz × 1-bit PDM.
5746 The SSP Rate in this example is 3.072 MHz because the pattern repeats every Row.

Row Sync Point

0 1 2 3
C D1 D2 D3
C D1 D2 D3
C D1 D2 D3
5747
Figure 141 Example TP: 3 PDM Mics (FBCSE PHY1)

334 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
10.1.12 Examples of Transport Patterns with Guard Bits

10.1.12.1 Example Transport Pattern with Guard Bits (DLV PHY)

5748 Figure 142 shows an example Transport Pattern that illustrates the use of Guard bits to protect Devices from
5749 crosstalk paths in the PHY that relate to the preceding state of the bus.
5750 In this example, the Devices that generate all of data streams D1 through D6 are vulnerable to crosstalk (e.g., they
5751 are microphones vulnerable to thermal crosstalk). To reduce this effect, the preceding transmitter for each of these
5752 streams is programmed to add a Guard bit at the end of each block of 1 or more bits that it owns. Thus, Guard bits
5753 are enabled for each of Control Data Stream in all Devices and Data Ports for streams D1 through D3.
5754 • The Guard bits in column 3 provide a known bus state for the potentially vulnerable devices D1 through D3
5755 that is independent of the data content of the preceding stream (CDS).
5756 • Similarly, the Guard bits in column 8 provide a known bus state for the potentially vulnerable devices D4
5757 through D6 that is independent of the data content of the preceding stream (D1 through D3).
5758 The polarity of the Guard bit is static for a given source, and can be selected within the Link Config Registers (for
5759 the CDS, see ###XREF) or Data Port Registers (see ###XREF). There is no need to add Guard bits after streams
5760 D4 through D6 because these are followed a UI owned by the Manager (S0), and the Manager in this example is not
5761 vulnerable to this crosstalk.
5762 The Clock Config in the example in Figure 142 is 3.072 MRows/sec × 16 columns = 49.152 Mbps.
5763 The audio streams in this Transport Pattern are:
5764 • 6 channels of 3.072 MHz × 1-bit PDM.
5765 • Sample Grouping = 3, so latency = 977 ns.
5766 The SSP Rate in this example is 1.024 MHz because the pattern repeats every 3 Rows.

Row Sync Point

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C G D1 D1 D1 G D4 D4 D4 S0 x2

S1 M-CDS
C G D2 D2 D2 G D5 D5 D5 S0 x2

S1 M-CDS
C G D3 D3 D3 G D6 D6 D6 S0 x2

S1 M-CDS
C G D1 D1 D1 G D4 D4 D4 S0 x2
5767
Figure 142 Example Traffic Pattern: Guard Bits

Copyright © 2019–2024 MIPI Alliance, Inc. 335

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
10.1.13 Examples of Transport Patterns with Wide Bits

10.1.13.1 Example Transport Pattern with Wide Bits (DLV PHY)

5768 Figure 143 shows an example Transport Pattern that illustrates the use of Wide Bits for Peripheral-to-Peripheral
5769 transfer in a system where transport within a single UI might be unreliable, e.g., because of the combination of bit
5770 rate and physical topology.
5771 The Clock Config in the example in Figure 143 is 3.072 MRows/sec × 16 columns = 49.152 Mbps.
5772 The audio streams in this Transport Pattern are:
5773 • 1 channel of 16-bit Peripheral-to-Peripheral data from Peripheral #1.
5774 • 1 channel of 16-bit Peripheral-to-Peripheral data from Peripheral #2.
5775 • 1 channel of 24-bit Manager-to-Peripheral data from Data Port #1.
5776 • 1 channel of 24-bit Manager-to-Peripheral data from Data Port #2.
5777 • The sample rate and hence the SSP rate depend on how frequently the block of bits from the Data Ports
5778 repeat, e.g.:
5779 • Sample Rate and SSP Rate = 48 kHz when the repeat length is 64 Rows.

Row Sync Point

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C P1-to-P P1-to-P MD1 MD1 MD1 MD1 MD1 S0 x2

S1 M-CDS
C P1-to-P P1-to-P MD1 MD1 MD1 MD1 MD1 S0 x2

S1 M-CDS
C P1-to-P P1-to-P MD1 MD1 MD1 MD1 S0 x2

S1 M-CDS
C P1-to-P P1-to-P MD2 MD2 MD2 MD2 MD2 S0 x2

S1 M-CDS
C P2-to-P P2-to-P MD2 MD2 MD2 MD2 MD2 S0 x2

S1 M-CDS
C P2-to-P P2-to-P MD2 MD2 MD2 MD2 S0 x2

S1 M-CDS
C P2-to-P P2-to-P S0 x2

S1 M-CDS
C S0 x2

S1 M-CDS
C S0 x2
... ... Total of 48 spare Rows ... ...
S1 M-CDS
C S0 x2

S1 M-CDS
C S0 x2

S1 M-CDS
C P1-to-P P1-to-P MD1 MD1 MD1 MD1 MD1 S0 x2

S1 M-CDS
C P1-to-P P1-to-P MD1 MD1 MD1 MD1 MD1 S0 x2
5780
Figure 143 Example Transport Pattern: Wide Bits

336 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
10.1.14 Examples of Transport Patterns with Tail Bits

10.1.14.1 Example Transport Patterns for PDM Audio with Tail Bits (DLV PHY)
5781 Figure 144 shows an example Transport Pattern similar to that in Figure 134, but including Tail bits. A Tail bit is
5782 inserted after the block of all bits transmitted from each component before the subsequent HandOver UI (i.e., in
5783 Columns 1, 4 and 12 in this example). The Sample Grouping has been increased to 6 to reduce the number of UIs
5784 used for Tail bits.
5785 The Clock Config in the example in Figure 134 is 3.072 MRows/sec × 16 columns = 49.152 Mbps.
5786 The audio streams in this Transport Pattern are:
5787 • 6 channels of 3.072 MHz × 1-bit PDM; Sample Grouping = 6, so latency = 1.95 µsec.
5788 The SSP Rate in this example is 512 kHz because the pattern repeats every 6 Rows.

Row Sync Point

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C D1 D1 D1 D1 D1 D1 S0 x2

S1 M-CDS
C D2 D2 D2 D2 D2 D2 S0 x2

S1 M-CDS
C D3 D3 D3 D3 D3 D3 S0 x2

S1 M-CDS
C D4 D4 D4 D4 D4 D4 S0 x2

S1 M-CDS
C D5 D5 D5 D5 D5 D5 S0 x2

S1 M-CDS
C D6 D6 D6 D6 D6 D6 S0 x2

S1 M-CDS
C D1 D1 D1 D1 D1 D1 S0 x2
5789
Figure 144 Example Transport Pattern: PDM Streams with PHY Tail Bits

5790 In contrast, Figure 145 shows the effects of adding PHY Tail bits to a Transport Pattern similar to Figure 133 that
5791 has 1-bit samples without using sample grouping. Here the “cost” of tails and handovers significantly reduces the
5792 usable bandwidth.
5793 The Clock Config in the example in Figure 145 is 3.072 MRows/sec × 16 columns = 49.152 Mbps.
5794 The audio streams in this Transport Pattern are:
5795 • 2 streams of 1 channel of 3.072 MHz × 1-bit PDM; Sample Grouping = 1, so latency = 326 nsec.
5796 The SSP Rate in this example is 3.072 MHz because the pattern repeats every Row.

Row Sync Point

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C D1 D2 S0 x2

S1 M-CDS
C D1 D2 S0 x2
5797
Figure 145 Example Transport Pattern: PDM Streams with PHY Tail Bits (No Sample Grouping)

Copyright © 2019–2024 MIPI Alliance, Inc. 337

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
5798 Figure 146 shows an example of trade-off between bandwidth and latency for PDM microphones in an environment
5799 that needs PHY Tail bits.
5800 The Clock Config in the example in Figure 146 is 3.072 MRows/sec × 16 columns = 49.152 Mbps.
5801 The audio streams in this Transport Pattern are:
5802 • 4 streams of 1 channel of 3.072 MHz × 1-bit PDM; Sample Grouping = 2, so latency = 650 nsec.
5803 The SSP Rate in this example is 1.536 MHz because the pattern repeats every 2 Rows.

Row Sync Point

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C D1 D1 D2 D2 S0 x2

S1 M-CDS
C D3 D3 D4 D4 S0 x2
5804
Figure 146 Example Transport Pattern: PDM Streams with PHY Tail Bits (Small Sample Grouping)

10.1.14.2 Example Transport Pattern for PCM Audio with Tail Bits
5805 Figure 147 shows an example Transport Pattern with PCM streams and PHY Tail bits. The Sync1 and Control Data
5806 Stream bits are followed by Tail bits in Columns 1 and 4 respectively. A run of 8 bits for the stream from a
5807 Peripheral is followed by a Tail bit in Column 14 before the HandOver UI in Column 15. The streams from the
5808 Manager have been allocated to Columns 16 to 21 because this avoids the need to waste columns on Handover UIs
5809 between payload data and the Manager Sync0 bits in Column 22.
5810 The Clock Config in the example in Figure 147 is 3.072 MRows/sec × 16 columns = 49.152 Mbps.
5811 The audio streams in the example Transport Pattern are:
5812 • Peripheral Tx: 3 streams of 1 channel of 16 bits.
5813 • Manager Tx: 1 stream of 2 channels of 18 bits.
5814 • The Sample rate for the Manager Tx and the SSP rate both depend on how frequently this block of 6 Rows
5815 repeats, e.g.:
5816 • Sample Rate and SSP Rate = 48 kHz when the repeat length is 64 Rows (meaning that these channels
5817 occupy ~9% of potentially usable payload bandwidth).
5818 • Sample Rate and SSP Rate = 96 kHz when the repeat length is 32 Rows (meaning that these channels
5819 occupy 19% of potentially usable payload bandwidth).

Row Sync Point

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
S1 M-CDS
C PD PD PD PD PD PD PD PD MD1 MD1 MD1 MD1 MD1 MD1 S0 x2

S1 M-CDS
C PD PD PD PD PD PD PD PD MD1 MD1 MD1 MD1 MD1 MD1 S0 x2

S1 M-CDS
C PD PD PD PD PD PD PD PD MD2 MD2 MD2 MD2 MD2 MD2 S0 x2

5820
Figure 147 Transport Pattern Example: PCM Streams with PHY Tail Bits

338 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
10.1.14.3 Example Transport Pattern for Mixed PCM & PDM Audio with Tail Bits
5821 Figure 148 shows an example Transport Pattern with mixed PCM and PDM streams with PHY Tail bits. The Sync1
5822 and Control Data Stream bits are followed by Tail bits in Columns 1 and 4 respectively. The Tail bits that would
5823 follow Manager datastream bits in column 17 are suppressed because the Manager owns the next UI (column 18 for
5824 Sync0). The Tail bit is present in column 10 of Row4 because the Manager is ending its ownership of the bus. The
5825 Peripheral datastream fitted into columns 12 through 15 of Row 4 is followed by a Tail bit before the bus is handed
5826 over to the Manager for the Sync0 in column 18.
5827 The Clock Config in the example in Figure 148 is 3.072 MRows/sec × 20 columns = 61.44 Mbps.
5828 The audio streams in the example Transport Pattern are:
5829 • Manager Tx: 1 stream of 2 channels of 20 bits, with Tails
5830 • Peripheral Tx: 1 stream of 1 channel of 3.072 MHz × 1-bit PDM using Sample Grouping=4, so
5831 latency = 1.30 µsec.
5832 • The SSP rate depends on how frequently the block of Manager data repeats, e.g.:
5833 • Sample Rate and SSP Rate = 48 kHz when the repeat length is 64 Rows.
5834 • Sample Rate and SSP Rate = 96 kHz when the repeat length is 32 Rows.

Row Sync Point

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
S1 M-CDS
C MD1 MD1 MD1 MD1 MD1 MD1 MD1 MD1 MD1 MD1 MD1 MD1 S0 x2

S1 M-CDS
C MD1 MD1 MD1 MD1 MD1 MD1 MD1 MD1 MD2 MD2 MD2 MD2 S0 x2

S1 M-CDS
C MD2 MD2 MD2 MD2 MD2 MD2 MD2 MD2 MD2 MD2 MD2 MD2 S0 x2

S1 M-CDS
C MD2 MD2 MD2 MD2 PD PD PD PD S0 x2

S1 M-CDS
C S0 x2

S1 M-CDS
C PD PD PD PD S0 x2
5835
Figure 148 Example Transport Pattern: PCM & PDM Streams with PHY Tail Bits

Copyright © 2019–2024 MIPI Alliance, Inc. 339

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
10.1.14.4 Tail Bits applied to Sync Sequence in DLV PHY
5836 Figure 149 shows the detail of Tail bits applied to the Sync sequence and Control Data Stream in the DLV PHY.
5837 The Sync1 bit in Column 0 is always owned by the Manager. The CDS bit is sometimes owned by the Peripheral,
5838 and sometimes by the Manager, dependent upon the Command Protocol, so there is sometimes a HandOver between
5839 Manager and Peripheral before Column 3.
5840 Row 1 in the figure uses the shorthand symbol in column 2 to indicate that this UI might be either a HandOver or an
5841 early copy of the Manager CDS bit, as described in Section ###XREF.
5842 Row 2 in the figure shows the case when the Peripheral owns the CDS bit. The Manager drives Sync1 in column 0
5843 and then a Tail bit in column 1; this is followed by a HandOver UI in column 2 before the Peripheral drives the CDS
5844 bit in column 3 and a Tail bit in column 4.
5845 Row 3 in the figure illustrates the case when the Manager owns the CDS bit. The Manager drives Sync1 in column 0
5846 and then a Tail bit in column 1; this is followed by the Manager driving the CDS bit in both columns 2 and 3 and
5847 then a Tail bit in column 4.

Row Sync Point

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C D1 D1 D1 D1 D1 D1 S0 x2

S1 P-CDS D1 D1 D1 D1 D1 D1 S0 x2

S1 M-CDS M-CDS D1 D1 D1 D1 D1 D1 S0 x2
5848
Figure 149 Example TP: Detail of DLV PHY Sync with PHY Tail Bits

340 Copyright © 2019–2024 MIPI Alliance, Inc.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
10.1.15 Half-Unit-Interval Granularity for Ends of Transport (EndHalfEarly)
5849 ###TODO-Author: reword this using the correct name of “EndHalfEarly” and removing “PHUI”.
5850 Some PHYs support the last bit in a block of consecutive bits having its drive terminated early by half a UI to
5851 provide the start of a handover period (controlled by Register field EndHalfEarly). This allows as few as zero UIs to
5852 be allocated for the handover. In systems where the physical medium is suitable (e.g., simple, short topologies), this
5853 flexibility can increase the usable bandwidth without having to double the bit rate.

10.1.15.1 EndHalfEarly Example #1

5854 Figure 150 shows a typical example of 2 PDM Mic streams in a system using the DLV PHY and 8 columns.
5855 Figure 151 shows the same streams using the “end-half-early” feature. The two benefits seen here are lower latency
5856 for the mic streams and more UIs available for Sync0, which could yield a better quality of Sync edge (and hence
5857 lower jitter in the audio sample clock).
5858 The Clock Config in the example in Figure 150 is 3.072 MRows/sec × 8 columns = 24.576 Mbps.
5859 The audio streams in this Transport Pattern are:
5860 2 streams of 3.072 MHz × 1-bit PDM; Sample Grouping = 2, so latency = 651 nsec.
5861 The SSP Rate in this example is 1.536 MHz because the pattern repeats every 2 Rows.

0 1 2 3 4 5 6 7
S1 M-CDS
C D1 D1 S0
S1 M-CDS
C D2 D2 S0
S1 M-CDS
C D1 D1 S0
S1 M-CDS
C D2 D2 S0
5862
Figure 150 Example TP: 2 PDM Mics in 8 Columns

5863 The Clock Config in the example in Figure 151 is 3.072 MRows/sec × 8 columns = 24.576 Mbps.
5864 The audio streams in this Transport Pattern are:
5865 2 streams of 3.072 MHz × 1-bit PDM; Sample Grouping = 1, so latency = 326 nsec.
5866 The SSP Rate in this example is 3.072 MHz because the pattern repeats every Row.

0 1 2 3 4 5 6 7
S1 M-CDS
C 1 2 S0 x2

S1 M-CDS
C 1 2 S0 x2
5867
Figure 151 Example TP: 2 PDM Mics in 8 Columns Using EndHalfEarly

Copyright © 2019–2024 MIPI Alliance, Inc. 341

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
10.1.16 Examples of Changing Transport Pattern at SSP
5868 These examples illustrate the basic principle of changes to the assignment of UIs in the Transport Pattern. An SSCR
5869 Command is used to make these changes synchronously to an existing SSP.
5870 Payload transport is described in more detail in Section 12.3, Stream Synchronization Points in
5871 Section ###XREF, and SSCR Commands in Section ###XREF.

10.1.16.1 Example Transport Pattern – Disabling PDM Streams

5872 Figure 152 shows the example Transport Pattern from Figure 134, with four of the eight PDM streams being
5873 disabled synchronously with the second SSP shown in the figure. After this change, the state of the bus during UIs
5874 that were being used for these streams are now maintained by the bus keeper.
5875 The Clock Config in the example in Figure 152 is 3.072 MRows/sec × 16 columns = 49.152 Mbps.
5876 The audio streams in this Transport Pattern before the change are:
5877 8 channels of 3.072 MHz × 1-bit PDM; Sample Grouping = 4, so latency = 1.30 µsec.
5878 The audio streams in this Transport Pattern after the change are:
5879 4 channels of 3.072 MHz × 1-bit PDM; Sample Grouping = 4, so latency = 1.30 µsec.
5880 The SSP Rate in this example is 768 kHz because the pattern repeats every 4 Rows.

Row Sync Point Commit Point for SSCR Command is at this SSP

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C D1 D1 D1 D1 D2 D2 D2 D2 S0 x2

S1 M-CDS
C D3 D3 D3 D3 D4 D4 D4 D4 S0 x2

S1 M-CDS
C D5 D5 D5 D5 D6 D6 D6 D6 S0 x2

S1 M-CDS
C D7 D7 D7 D7 D8 D8 D8 D8 S0 x2

S1 M-CDS
C D1 D1 D1 D1 D2 D2 D2 D2 S0 x2

S1 M-CDS
C D3 D3 D3 D3 D4 D4 D4 D4 S0 x2

S1 M-CDS
C D5 D5 D5 D5 D6 D6 D6 D6 S0 x2

S1 M-CDS
C D7 D7 D7 D7 D8 D8 D8 D8 S0 x2 S1
S0 S1 M-CDS
C D2 D2 D2 D2 S0 x2

S1 M-CDS
C D3 D3 D3 D3 S0 x2

S1 M-CDS
C S0 x2

S1 M-CDS
C D7 D7 D7 D7 D8 D8 D8 D8 S0 x2

S1 M-CDS
C D2 D2 D2 D2 S0 x2

S1 M-CDS
C D3 D3 D3 D3 S0 x2

S1 M-CDS
C S0 x2

S1 M-CDS
C D7 D7 D7 D7 D8 D8 D8 D8 S0 x2
5881
Figure 152 Example TP: Disabling PDM Streams

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
10.1.16.2 Example Transport Pattern – Adding a PCM Stream
5882 Figure 153 shows an example Transport Pattern similar to that from Figure 132, with one of the four PCM streams
5883 being added (i.e., enabled). The UIs in Rows 7 and 8 that are occupied by the newly added stream were previously
5884 being maintained by the bus keeper.
5885 The Clock Config in the example in Figure 153 is 768 kRows/sec × 16 columns = 12.288 Mbps.
5886 The audio streams in this Transport Pattern before the change are:
5887 • 3 channels of 16 bits at a sample rate of 96 kHz.
5888 The audio streams in this Transport Pattern after the change are:
5889 • 4 channels of 16 bits at a sample rate of 96 kHz.
5890 The SSP Rate in this example is 96 kHz because the pattern repeats every 8 Rows.

Row Sync Point Commit Point for SSCR Command is at this SSP

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
S1 M-CDS
C D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 S0
S1 M-CDS
C D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 S0
S1 M-CDS
C D2 D2 D2 D2 D2 D2 D2 D2 D2 D2 S0
S1 M-CDS
C D2 D2 D2 D2 D2 D2 D2 D2 D2 D2 S0
S1 M-CDS
C D3 D3 D3 D3 D3 D3 D3 D3 D3 D3 S0
S1 M-CDS
C D3 D3 D3 D3 D3 D3 D3 D3 D3 D3 S0
S1 M-CDS
C S0
S1 M-CDS
C S0 S1
S0 S1 M-CDS
C D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 S0
S1 M-CDS
C D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 S0
S1 M-CDS
C D2 D2 D2 D2 D2 D2 D2 D2 D2 D2 S0
S1 M-CDS
C D2 D2 D2 D2 D2 D2 D2 D2 D2 D2 S0
S1 M-CDS
C D3 D3 D3 D3 D3 D3 D3 D3 D3 D3 S0
S1 M-CDS
C D3 D3 D3 D3 D3 D3 D3 D3 D3 D3 S0
S1 M-CDS
C D4 D4 D4 D4 D4 D4 D4 D4 D4 D4 S0
S1 M-CDS
C D4 D4 D4 D4 D4 D4 D4 D4 D4 D4 S0
S1
5891
Figure 153 Example TP: Adding a PCM Channel

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
10.1.17 Examples of Changing Clock Config
5892 ###Note for Reviewers: this Section (10.1.17) is Work-in-Progress.
5893
5894 The combination of Row Rate and Column count is referred to as the Clock Config, and changing one or both of
5895 these parameters while the link remains operational is Dynamic Clock Config Switching.

10.1.17.1 ###TODO: Dynamic Clock Config Switching with the FBCSE PHY

10.1.17.1.1 ###TODO: Example #1: Changing number of columns at fixed ROW RATE to increase
payload bandwidth
5896 Increase payload BW, unchanged CDS BW
5897 From:
5898 2 columns: CDS+D1
5899 3.072 MRows/sec × 2 columns = 6.144 Mbps
5900 To:
5901 4 columns: CDS+D1+D2+D3
5902 3.072 MRows/sec × 4 columns = 12.288 Mbps
5903 ###NOTE: the columns in the “before” config will be 2x the width of columns in the “after” picture.

Row Sync Point SSPs

0 1
C D1
C D1
C D1
C D1
C D1
5904
Figure 154 ### Placeholder

5905
5906

10.1.17.1.2 ###TODO: Example #2: Changing number of columns at fixed bit rate to vary the
ratio of CDS to payload.
5907 Unchanged payload BW; decrease CDS BW
5908 From:
5909 2 columns: CDS+D1
5910 3.072 MRows/sec × 2 columns = 6.144 Mbps
5911 To:
5912 192 kHz × 32 columns= 6.144 Mbps
5913 CDS + 16x D1

0 1
C D1
C D1
C D1
C D1
C D1
5914
Figure 155 #DRAFT Single MIC (PHY1, FBCSE)

5915 ###TODO-Author: add some text to explain that Figure 156 shows the same microphone as Figure 155, but uses
5916 SRI (Sub-Row Intervals) so that there are fewer CDS bits, which would save power.
Row Sync Point

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
192 kRows/sec
6.144 Mbps C D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1
1 stream: C D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1
* 3.072 Mbps Mic1 C D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1 D1
5917 Latency 326 ns

Figure 156 #DRAFT Single Mic Using SRI for Reduced Control Bandwidth (PHY1, FBCSE)

10.1.17.1.3 ###TODO: Example #3: Changing both bit rate and row rate
5918 Increased payload BW; decreased CDS BW
5919 From:
5920 2 columns: CDS+D1
5921 3.072 MRows/sec × 2 columns = 6.144 Mbps
5922 To:
5923 8 columns: CDS+D1+D1+D2+D2+D3+D3+D4
5924 1.536 MRows/sec × 4 columns = 12.288 Mbps
5925 ###NOTE: the columns in the “before” config will be 2x the width of columns in the “after” picture.
5926
5927
5928
5929
5930 These 2 examples illustrate changing the column count while either Row Rate or Bit Rate remains constant, but it is
5931 also
5932
5933

10.1.17.2 Dynamic Clock Config Switching with the DLV PHY

5934 ###TODO-Author: explain that this is optional SOME Peripherals might support dynamic clock change
5935 (without detaching, and without needing the Manager to generate Command-Only). … for the DLV PHY,
5936 where Figure 65 (copied below as Figure 157) shows that any change in Clock Config reverts to a
5937 Command-Only Transport Pattern and waits for all Peripherals to have become re-attached.
5938
5939 Implementing Dynamic Clock Config Switching is optional. Devices that do implement it support basic changes (4x
5940 in Row rate while Column count remains unchanged) and might also support more complex changes (e.g., 2x in
5941 Row rate, or changing Columns from 16 to 24, or changing both Column count and Row Rate together).

Activate
PHY #1

Start_Link after
Hard Reset

Safe-
Lock-N
Lock-4

All_Peripherals_Attached
Command-Only
Row Structure

Normal

Key:
Three different cases for when
the Manager continues for long
5942 enough for Slaves to Sync

Figure 157 Start-Up Flow for Manager using DLV PHY

5943 ###TODO-Author: update the Manager/Peripheral language in Figure 157.

10.1.17.2.1 Example of Clock Config Switching by Reducing Row Rate (DLV PHY)
5944 Figure 158 shows an example of two Clock Configs that might be used in the same system under different operating
5945 conditions, with the Row Rate being scaled by a factor of 4. The upper line completely shows 1 Row and partly
5946 shows 3 more Rows of 16 Columns at a Row Rate of 3.072 MRows/s (bit rate of 49.152 Mb/s). The lower line
5947 partly shows 1 Row of 16 Columns at one quarter of the Row rate, i.e., 768 kRows/s (bit rate of 12.288 Mb/s).
5948 Figure 159 shows the detail of how UIs of the Clock Config #1 correspond to UIs of Clock Config #2.
5949 Clock Config #1 in the example in Figure 158 is 3.072 MRows/sec × 16 columns = 49.152 Mbps.
5950 Clock Config #2 in this example is 768 kRows/sec × 16 columns = 12.288 Mbps.
Row Sync Point

... 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4 ... 15 0 1 2 3 4 ... 15 0 1 2 3 4 ... 12 13 14 15 0

... S0 S1 M-CDS
C D S0 S1 M-CDS
C D ... S0 S1 M-CDS
C D ... S0 S1 M-CDS
C D ... S0 S1

15 0 1 2 3 4 ... ... ... ... 15 0

5951 S0 S1 M-CDS
C D ... ... ... ... S0 S1

Figure 158 Clock Config Example: Scaling Down Row Rate (DLV PHY)

... 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4 ...
... S0 S1 M-CDS
C D S0 S1 M-CDS
C D ...

... 15 0 1 2 3 4 ...
... S0 S1 M-CDS
C D ...
5952
Figure 159 Clock Config Example: Scaling Down Row Rate (DLV PHY) - Detail

10.1.17.2.2 Example of Clock Config Switching by Increasing Row Rate (DLV PHY)
5953 Figure 160 shows the complementary change to Figure 158 with the Row Rate being scaled up by a factor of 4.
5954 Clock Config #1 in the example in Figure 160 is 768 kRows/sec × 16 columns = 12.288 Mbps.
5955 Clock Config #2 in this example is 3.072 MRows/sec × 16 columns = 49.152 Mbps.
5956
Row Sync Point

... 15 0 1 2 3 4 ... ... ... ... 15 0

... S0 S1 M-CDS
C D ... ... ... ... S0 S1

... 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4 ... 15 0 1 2 3 4 ... 15 0 1 2 3 4 ... 12 13 14 15 0 ...

... ... ... ... ...
5957
S0 S1 M-CDS
C D S0 S1 M-CDS
C D S0 S1 M-CDS
C D S0 S1 M-CDS
C D S0 S1

Figure 160 ###TBD-not-DLV? Clock Config Example: Scaling Up Row Rate

10.1.17.2.3 Example of Clock Config Switching by Scaling Column Count

5958 Figure 161 shows an example of two Transport Patterns with Column counts of 16 and 20 that might be used at the
5959 same Row Rate. If the Row Rate were 3.0 MRows/s then these Clock Configs would have bit rates of 48.0 and 60.0
5960 Mb/s respectively.
5961 Some implementations support seamless switching between Clock Configs such as these that differ by something
5962 different to the basic mode switching condition of 4x in Row Rate. (See ###XREF).

Row Sync Point

... 14 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 ...
... S0 x2 S1 M-CDS
C D1 D1 D1 D1 D2 D2 D2 D2 S0 x2 S1 ...

... 14 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 0 ...
... S0 x2 S1 M-CDS
C D1 D1 D1 D1 D2 D2 D2 D2 MD MD MD MD S0 x2 S1 ...
5963
Figure 161 ###TBD-not-DLV? Clock Config Example: Changing Column Count

10.2 Specifications (Normative)

10.2.1 ###WIP Generic Rules for Transport

5964 Permissions
5965 1. {} A Manager may own any UIs in the Transport Pattern that it knows are either:
5966 A. CDS UIs that are allocated to a Peripheral that is known not to be Attached, or:
5967 B. UIs that are not allocated to any of Sync, CDS, or a Data Port.
5968 Note: It might choose to own only those that are easy to decode, such as completely empty columns.

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
5969 ###TODO-Author: add informative notes about the Manager typically driving data to maintain / create dc-balance.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
11 PHY1 & PHY2 Forwarded Bit Clock Single-Ended (FBCSE)
5970 ###Note to Reviewers: the material in this PHY Chapter has been re-ordered to be closer to ther final
5971 document, with the temporary WG-authored material being moved to the end and/or deleted. Thus we now
5972 have:
5973 Section 11.1 Description (informative) – this was “Section 12.2” up to draft v0.5 r13.
5974 Section 11.2 Specifications (normative) – this was “Section 12.3” up to draft v0.5 r13.
5975 Section 11.3 TEMP OLD DRAFT Tables from v0.5r11 PHY#1 and PHY#2 (FBCSE) – this was “Section
5976 12.1” up to draft v0.5 r13, and will soon be deleted.

11.1 Description (informative)

5977 Notes on updated PHY1&2 (FBCSE).
5978

5979 Output drive patterns that can be selected:

5980 G: a conductance ramp where both sides of the H-bridge are initially off and then one side ramps from off to on.
5981 V: a voltage ramp where one side of the H-bridge is initially on and this ramps towards off while the other side of
5982 the H-bridge ramps towards on.
5983 vV: a special case of V, where both sides of the H-bridge were previously off but we know the existing state of the
5984 bus, so the appropriate side of the H-bridge turns on as quickly as possible and then the behavior is as described for
5985 V.
5986 Raw-E (or Raw-G?): the raw behavior of the output pin when controlled by the Enable input (because the Data
5987 input is stable before Enable changes from 0 to 1). Both sides of the H-bridge are initially off and then one side turns
5988 on (this is typically fast, but not instant).
5989 Raw-D (or Raw-V?): the raw behavior of the output pin when controlled by the Data input (because the Enable
5990 input is 1 for both the previous UI and this UI, while the Data input changes). One side of the H-bridge is initially
5991 on, and this turns off then the other side turns on. (Is this guaranteed always to be break-before-make with zero
5992 shoot through?).
5993

5994 Initial bits vs. Adjacent bits

5995 When we consider both “initial” bit (i.e., when this Device did not drive the previous UI) and one or more
5996 subsequent “adjacent” bits (i.e., when this Device drove the UI immediately before the first UI of this bit) …
5997

5998 Matrix of possible behaviors

5999 In the current draft (as of v0.5r13) we had a matrix of 4 possible behaviors:
Row number Initial bit Adjacent bit(s) Notes
1 G GGG
2 G VVV
3 vV GGG This might be an odd choice
4 vV VVV

6000
6001 The additional rows using the “raw” I/O behavior discussed today look like:
Row number Initial bit Adjacent bit(s) Notes
5-PHY1 Raw-E Raw-E Raw-E Raw-E The new “simple PHY ” behavior
Raw-E for adjacent bits is odd
5-PHY2 Raw-E Raw-E Raw-E Raw-E
behavior for PHY2 (?)
PHY1 behavior is to disable output
6-PHY1 Raw-E Raw-D Raw-D Raw-D between bits, so Raw-D does not
make sense.
6-PHY2 Raw-E Raw-D Raw-D Raw-D The new “simple PHY ” behavior
Is there any value to add the
complexity of Raw-D for intial (which
7 Raw-D ***
would need something similar to the
“vV” behavior).
It seems weird to “half use” the
8 Raw-E VVV
controlled ramp time.
It seems weird to “half use” the
9 Raw-E GGG
controlled ramp time.
Raw-E It seems weird to “half use” the
10 G
controlled ramp time.
Raw-E It seems weird to “half use” the
11 vV
controlled ramp time.
Raw-D It seems weird to “half use” the
12 G
controlled ramp time.
Raw-D It seems weird to “half use” the
13 vV
controlled ramp time.

6002

11.1.1 # Single-Ended PHY Overview

6004 DDR

11.1.1.1 [Tentative] Summary of Features

6005 Features of the Single-ended PHY include:
6006 • 2-pin interface using full-swing single-ended signaling with control over slew time and output impedance.
6007 • Simple interface with low power receiver.
6008 • Simple clocking with one pin dedicated to a forwarded bit clock from the Manager to the Peripheral(s).
6009 • One data signal multiplexed between Manager and Peripherals.
6010 • Short handover duration (0 UIs for PHY1 and 1 UI for PHY2).
6011 • Handovers can be programmed to be longer for larger systems.
6012 • Supports a range of physical link topologies:
6013 • Trade-off between bandwidth, topology, and distance.
6014 • Distance typically up to 30cm
6015 • Multi-drop capability.
6016 • Supports a wide range of link speeds:
6017 • Raw transport bandwidth of, e.g., 64 kbps to 51.2 Mbps.
6018 • Row Rates to provide Control Data Stream bandwidth from, e.g., 2 kbps/s to 25.6 Mbps.
6019 • Link can easily switch between a wide range of speeds to support lower power operation for a range of
6020 systems scenarios.
6021 • Manager signaling includes a forwarded bit clock for Peripherals to:
6022 • Control transport.
6023 • Produce an audio quality sample clock, if desired.
6024 • Align higher layers with Row boundaries (by also observing the Command Protocol in the Control Data
6025 Stream).
6026 • The link can be used for transmission between any pair of devices including direct Peripheral to Peripheral.
6027 • Programmable “WideBits” for difficult timing in larger systems.
6028 • Power management
6029 • Supports a zero-exit-latency clock pause mode (in addition to the standard Sleep and Cold_Standby
6030 Link States).
6031

11.1.1.2 Block Diagram of FBCSE PHY Interface Pins in Manager

FClock TX DN

SlewControl
TxDriveEnabl
e

TxData TX

BusHoldEnable DP

hold

RxData RX

RxEnable

RxHysteresisControl SE IO

6032
Figure 162 Block Diagram of FBCSE PHY Interface Pins in Manager

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
11.1.1.2.1 Clock Pause
6033 The FBCSE PHY includes a Clock Pause condition, where time effectively stops because there are no transitions on
6034 the forwarded bit clock from the Manager. The Clock Pause condition is DN=1 and DP=1, which will be ignored by
6035 the Peripheral Bus Reset state machine (see ###XREF) so the Peripheral can tolerate this condition indefinitely.
6036 The Manager pauses the clock during column 0 in a Row when it owns the Control Data Stream bit (e.g., when it is
6037 generating the data=1 part of a CDS Idle condition, see ###XREF).
6038 The Manager restarts the clock by first changing DP from 1 to the correct value for the next CDS bit
6039 (NRZS-encoded from the last column of the previous row) then after a suitable setup time (typically most of a UI) it
6040 changes DN from 1 to 0 to generate the clock edge at the end of column 0.
6041 Note:
6042 If the Peripherals are performing a Commit operation then the Commit Synchronization Point will be a rising
6043 edge on DN (i.e., the bit clock), and the Manager might stop the clock immediately after that rising edge.

Clock signal
(DN pin)

tHold tSetup tHold

Data signal
(DP pin)

Column N-1 Column 0 Column 1

6044
Figure 163 Clock Pause in FBCSE

6045 Some examples of when Clock Pause might be used in a system are:
6046 • A bus containing only sensors, when the clock is only needed while they deliver a value.
6047 • When the bus is Command-Only, i.e., while no audio streams are running (e.g., while booting intermediate
6048 OSes).

11.1.1.3 CDS Encoding and Special Drive Type

6049 The NRZS encoding used for CDS bits with PHY1 and PHY2 (FBCSE):
6050 • CDS Logic 0: NRZS encoding sets the Data signal (DP) to the opposite physical value from the preceding
6051 UI (not the preceding CDS bit).
6052 • CDS Logic 1: NRZS encoding leaves the Data signal (DP) unchanged at the same physical value as the
6053 preceding UI (not the preceding CDS bit).
6054 When CDS_DriveType=0 (Special Drive Type): the passive drive keeps the output at high-Z so it is the
6055 bus-keeper that maintains this unchanged physical value. This special drive type might help to reduce
6056 power consumption in the output circuit.
6057 Note:
6058 When using Wide Bits (###XREF:CDS_Bit_Width > 0), the encoding is done once for the first UI of the CDS
6059 bit and then the same physical drive is applied in all subsequent UIs of that CDS bit.
6060 Note:
6061 This NRZS encoding is only for CDS bits: there is no PHY-specific encoding applied to Payload bits.
6062

11.1.2.1 Combinations of Clock Config and Transport Pattern for PHY1 or PHY2 (FBCSE)
6063 The Clock Config and Transport Pattern generated by the Manager with PHY1 or PHY2 (FBCSE) can be
6064 characterized into one of 2 groups. The ranges of parameters for these groups are summarized in Table 112 (for
6065 PHY1) and Table 113 (for PHY2).
6066 Safe-Lock-2 (see ###XREF) is a combination of Clock Config and Transport Pattern used when PHY1 or
6067 PHY2 is activated after a Cold Start. Peripherals use special drive for CDS bits to minimize the probability
6068 of drive clashes.
6069 Lock-N is a Command-Only Transport Pattern used when PHY1 or PHY2 is activated after Warm Reset
6070 (e.g., when waking from Sleep), and at any other times when it is desirable to make it easier for Peripherals
6071 to re-synchronize to Row boundaries. Peripherals might need non-default PHY settings and/or PHY timing
6072 calibration in order to operate in some parts of this range.
6073 Running is used after Lock-N when all Peripherals have responded correctly to a Ping Command. If the
6074 Transport Pattern assigns fewer UIs to the Control Data Stream (i.e., bits that are less wide) then this might
6075 need finer timing calibration than Lock-N.
6076 Table 112 Combinations of Clock Config and Transport Pattern for PHY1 (FBCSE)

Peripheral Transport
Nominal Row Rate Column PHY Pattern
Name Limitations Notes
UI Rate (kRows/s) Count Output Bit
kUI/s) Encoding

Cold All Peripherals support

0:Special
Start: 31.34 – Command- operation over this whole
2 (Passive 1
Safe- 6400 Only range using the default
/ Active 0)
Lock-2 PHY settings.

All Peripherals support

Command operation over
Command-
Lock-N 62.68 – this whole range provided
Only
12800 they have suitable PHY
2 – 32 settings.
1.96 –
(even 1:Normal Peripherals might not
6400
numbers) support audio payload
Any valid operation in all Clock
Running Transport Configs for which they
Pattern support Command
operation.

6077 Note:
1. ###.

Peripheral Transport
Nominal
Row Rate Column PHY Pattern
Name UI Rate Notes
(kRows/s) Count Output Bit Limitations
kUI/s) Encoding

Cold All Peripherals support

0:Special
Start: 31.34 – Command- operation over this whole
2 (Passive 1
Safe- 25600 Only range using the default PHY
/ Active 0)
Lock-2 settings.

All Peripherals support

Command operation over
Command-
Lock-N 62.68 – this whole range provided
Only
51200 they have suitable PHY
2 – 32 settings.
1.96 –
(even 1:Normal Peripherals might not
25600
numbers) support audio payload
Any valid operation in all Clock
Running Transport Configs for which they
Pattern support Command
operation.

6079 Note:
1. ###.

11.1.3 PHY1 & PHY2 (FBCSE) System Design Issues

6080 Note:
6081 Normative recommendations for the parameters related to these system design issues are specified in
6082 Section 11.2.4.

11.1.3.1 Bus Capacitance

6083 The bus capacitance seen by the interface is the sum of all of the devices plus the PCB traces and discrete
6084 capacitor(s) that might be added by the system designer to guarantee the minimum value in ultra-small systems.

11.1.3.2 Noise Margin

6085 There is some margin between the input and output voltgae levels for Devices to allow for system effects. It is a
6086 system design issue how much of that margin is consumed by noice coupled from the rest of the system and how
6087 much by ground offset between devices (caused by IR-drop in ground planes).
6088

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
11.2 Specifications (normative)
6089 Except where a PHY Number is stated, all Requirements, Permissions, and Recommendations in this Section (11.2)
6090 apply to both Audio-mode PHY1 and Audio-mode PHY2.

11.2.1 PHY1 & PHY2 (FBCSE): Link Control Behavior

6091 Requirements
6092 1. {} [PHY1 & PHY2] The Peripheral shall use values for the timing parameters named in this Section (11.2.1)
6093 that are between the lower and upper bounds in Table 114.
6094 Table 114 PHY1 & PHY2 (FBCSE): Timing Parameters for Peripheral Link Control

Parameter Min Typ Max Units Description

Limits on Peripheral Behavior

The time threshold that a Peripheral uses

when detecting PHY_Inactivity lies within
Per_tPhy_Inactivity_FBCSE 20 — 60 µs this Min/Max range.
See Requirement 2.

Per_nRowsToLockMax_FBCSE — — 6000 Rows See ###XREF

Limits on time between receiving PhyStart

falling edge on DP (at the end of Cold Start
or Warm Start) and the Peripheral starting
Per_tPhyStart_FBCSE — — 63 µs to observe Audio-mode PHY signaling
transitions from the Manager.
See Section 5.2.2 Requirement 10.A &
12.A.

Recommended Peripheral Behavior

Per_nRowsToLockTyp_FBCSE — — 1500 Rows

See ###XREF

6095 2. {} [PHY1 & PHY2] The Peripheral shall detect PHY_Inactivity (see Section 5.2.2 Requirement 20) when it
6096 detects a static condition of DN(Clock)=FBCSE:0 and DP(Data)=FBCSE:0 for a time of
6097 Per_tPhy_Inactivity_FBCSE.
6098
6099 ###NOTES
6100
6101 Manager Clock Pause generation: 11 for t < ∞.
6102 Periperal Clock Pause detection (implicit).
6103
6104 Peripheral: Long unchanging 01 or long unchanging 10 is also implicit clock pause
6105
6106
6107 ###TEMP ###XREF to tables of Register values in Section 5.2.4.

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
6108 ###TEMP ###XREF to FBCSE LC rules in Section 11.2.1.
6109 ###TEMP ###XREF to DLV LC rules in Section 12.2.1.
6110 ###TEMP ###XREF to description of RowRateRange and UI_RateRange at end of Table 153 just before
6111 Section 14.2.6.
6112 ###TEMP ###XREF to description of RowRateRange and UI_RateRange at end of Table 153 just before
6113 Section 14.2.6.
6114
6115
6116
6117
6118
6119 3. {} [PHY1 & PHY2] The Peripheral shall reattach within Per_nRowsToLockMax_FBCSE Rows by using
6120 the *_CURR values, provided that …
6121 A. The Manager is using the same values that are in *_CURR, and:
6122 B. One or both of:
6123 i. The Traffic Pattern is Command-Only, or:
6124 ii. The Number of columns is 2.
6125 Note: See also Permissions 1 and 2.
6126
6127 ###TBD-Niel ###Niel: check whether the second of these Notes is still true. Compare with REQ 4.
6128 Note: for FBCSE and 2 columns, the Manager does NOT need to change to Command-only.
6129 Note: for FBCSE and <existing column count>, the Manager does NOT need to change to Command-only.
6130 When the DisCo data reports that a Peripheral is capable of relocking to >2 Columns, this is for a scenario
6131 where the traffic is NOT required to be Command-only (i.e., the Peripheral can tolerate payload traffic).
6132
6133 4. {} [PHY1 & PHY2] When the Peripheral is attempting to attach to the bus (Section 5.2.2 Requirement 13),
6134 the Peripheral shall correctly identify Column 0 after a maximum of Per_nRowsToLockMax_FBCSE Rows
6135 from when all of the following conditions are satisfied:
6136 A. The Manager is generating Rows that match the values in the NumColumns and CDS_BitWidth[2:0]
6137 fields, and
6138 B. The Link traffic includes only the Control Data Stream.
6139 Note: see also Recommendation 1.
6140
6141 5. {} If the Peripheral reattaches according to Permission 1 or 2 then it shall update the values in the *_CURR
6142 register field to be the ones that it has used to attach to the bus.
6143
6144 6. {} … .
6145
6146 7. {} [Hot-join from Cold_Standby] [FBCSE and DLV] The Peripheral may be capable of attaching from Cold
6147 <similar to Step #1>
6148
6149 8. {} [FBCSE and DLV] The *_NEXT Registers shall be unchanged from before the Warm Reset.
6150

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
6151 9. {} [FBCSE] The Manager shall use values for the timing parameters named in this Section (11.2.1) that are
6152 between the lower and upper bounds in Table 115.
6153 Table 115 FBCSE PHY: Timing Parameters for Manager Link Control

Parameter Min Typ Max Units Description

Limits on Manager Behavior

Duration of the Manager driving FBCSE Idle

Man_tParkBus_FBCSE 62 — 64 µs condition when parking the bus.
See Requirement 10.

— — — µs

Recommended Manager Behavior

— — — µs

Range of Input Conditions within which the Manager Operates Correctly

— — — µs

6154 10. {} [FBCSE] The Manager shall park the bus (see Section 5.2.3 Requirement 5) by generating
6155 DN=FBCSE:0 and DP=FBCSE:0 for a time of Man_tParkBus_FBCSE.
6156 11. {} [FBCSE] When the Manager starts generating Rows after a Cold Start it shall use a combination of
6157 Safe-Lock Config (see Section 5.2.3 Requirement 9.G.ii) and Transport Pattern that have:
6158 A. Column_Count=2, and
6159 B. CDS_HorizontalStart=0, and
6160 C. CDS_BitWidth=1.
6161 12. {} [FBCSE] The Manager shall generate Rows (see Section 5.2.3 Requirement 12) that have:
6162 A. A ColumnCount that is an even number between 2 and 32 inclusive.
6163

6164 Permissions
6165 1. {} [PHY1 & PHY2] The Peripheral may reattach by using the *_NEXT register values, provided that:
6166 A. The Manager is using the same values that are in *_NEXT.
6167 Note: If the Peripheral fails to join using the *_CURR values (see Requirement 3) then it is possible that the
6168 Peripheral fell off the bus just as the Manager was changing to using the *_NEXT values, so these are a
6169 good candidate to try.
6170 2. {} [PHY1 & PHY2] The Peripheral may reattach by using values calculated by the Peripheral.
6171 Note: E.g., the Peripheral might try all possible Column Counts until it reattaches.
6172 3. {} … .
6173

6174 Recommendations
6175 1. {} [FBCSE] When the Peripheral is attempting to attach to the bus (Section 5.2.2 Requirement 13), the
6176 clock recovery circuitry should correctly identify Column 0 after a maximum of
6177 Per_nRowsToLockTyp_FBCSE Rows, provided that the conditions in Requirement 4 are satisfied.
6178 2. {} … .
6179

11.2.2 PHY1 & PHY2 (FBCSE): Electrical Parameters

6180 Requirements
6181 1. {} [PHY1 & PHY2] A Device that implements PHY1 and/or PHY2 (FBCSE) shall support at least one of
6182 the nominal VDD values shown in Table 116.
6183 Table 116 [PHY1 & PHY2] Supply Voltage for PHY1 / PHY2 Interface

Parameter Symbol Min Nom Max Units

VDD for Nominal 0.9 V Interface VDD_PHY1&2_0V9 0.900

VDD for Nominal 1.2 V Interface VDD_PHY1&2_1V2 −5 % 1.200 +5 % V

VDD for Nominal 1.8 V Interface VDD_PHY1&2_1V8 1.800

6184 2. {} [PHY1 & PHY2] The input and output electrical parameters for PHY1 and PHY2 (FBCSE) shall be
6185 within the ranges shown in Table 117.
6186 Table 117 [PHY1 & PHY2] Input and Output Voltage Parameters

Parameter Symbol Conditions Min Typ Max Units

VDD = 0.9 V: IOH= −3.3 mA

VDD = 1.2 V: IOH= −4.4 mA
Logic High Output
VOH_Phy1&2 VDD = 1.8 V: IOH= −6.6 mA 80 % — — VDD
Voltage
PHY1_DriveImpedance=4
PHY2_DriveImpedance=4

VDD= 0.9 V: IOL= +3.3 mA

VDD= 1.2 V: IOL= +4.4 mA
Logic Low Output
VOL_Phy1&2 VDD= 1.8 V: IOL= +6.6 mA — — 20 % VDD
Voltage
PHY1_DriveImpedance=4
PHY2_DriveImpedance=4

Logic High Input

VIH_Phy1&2 Same as VIH_LC (see Table 27) —
Threshold
Logic Low Input
VIL_Phy1&2 Same as VIL_LC (see Table 27) —
Threshold
Input Hysteresis VHYS_Ohy1&2 Same as VHYS_LC (see Table 27) —

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
6187 3. {} [PHY1 & PHY2] The output impedance for PHY1 and PHY2 (FBCSE) shall be within the ranges shown
6188 in Table 118.
6189 Table 118 [PHY1 & PHY2] Output Impedance

Settings
Parameter Symbol (PHYn_DriveImpedance, Conditions Min Typ Max Units
see Table 159)

0 [1] 20.0

1 [1] 24.5

2 [1] 30.0

3 [1] 36.5
Output IOL = 1 mA
ZOUT − 0% +20% Ω
Impedance[2] IOH = 1 mA
4 44.5

5 [1] 54.5

6 [1] 66.5

7 89.0

Impedance Ratio of ZOUT at

Excursion (VOUT = 50% VDD) to %
— 50 — 200
while voltage ZOUT at the end of the ZOUT
ramping. ramp.

6190 Note:
1. Drive Impedance settings 0, 1, 2, 3, 5, and 6 are optional (see ###XREF to register table).
2. ZOUT is the impedance at the end of the rise or fall time (i.e., either after 80% of the voltage ramp or
statically measured).
3. The overlap between ranges means that the function might be non-monotonic, i.e., a higher register
setting could map to lower impedance.
6191

6192 4. {} [PHY1 & PHY2] The electrical parameters for the Manager Bus Keeper shall be within the ranges shown
6193 in Table 119.
6194 Table 119 [PHY1 & PHY2] Bus Keeper Behavior

Parameter Symbol Conditions Min Typ Max Units

Bus Keeper impedance, Weak_Drive_Boost

ZKEEPER_Boost0 5.0 7.0 10.0 kΩ
normal mode Register Bit = 0

Bus Keeper impedance,

Weak_Drive_Boost
boost mode ZKEEPER_Boost1 2.5 3.5 5.0 kΩ
Register Bit = 1
(Optional)

Keeper
Response Time
Note: measured
from input crossing
tKeeper_Response — — — 3 ns
Vih/Vil to change in
sign of output
current.

6195
6196

11.2.3 PHY1 & PHY2 (FBCSE): Timing Parameters

6197 Requirements
6198 1. {####} [PHY1 & PHY2] A Device using PHY1 (FBCSE) shall tolerate a clock that is anywhere within the
6199 range shown in Table 120.
6200 Note: this is different to the clock frequency range for PHY2 (FBCSE), see ###XREF.

6201 Table 120 [PHY1 & PHY2] Clock

Parameter Symbol Conditions Min Typ Max Units

— 0.032 — — MHz
FCLK_Phy1
— — — 6.6 MHz

Clock Frequency — 0.032 — — MHz

FCLK_Phy2 — — — 13.2 MHz

Optional extended
frequency range — — 26.4 MHz

Clock Duty Cycle DCCLK — 45 — 55 %

6202 2. {} [PHY1 & PHY2] A Device ….

6203 ###TODO-Author: add a normative rule permitting the Manager to pause the clock in the well-defined way
6204 described informatively in ###XREF.
6205

6206 Recommendations
6207 1. {} [PHY3] When any Peripherals are using the Bus Clock edges as an audio clock, the Manager Bus Clock
6208 output jitter (LΦ_TX_MGR) should be within the limits in Table 121.
6209
6210 Table 121 PHY1&2: Jitter Parameters

Parameter Symbol Conditions Min Typ Max Units

Integrated Phase Noise in the start Condition1: high fidelity

of rising clock edges, measured from (###TBD-x dB — — 150 ps
100 Hz to half of the Bus Clock (i.e., THD+N)
a quarter of the UI Rate). LΦ_TX_MGR
Condition2: low fidelity
(Audio clock quality, see — — 1000 ps
(###TBD-y dB
Recommendation 1) THD+N)

6211
6212

11.2.4 PHY1 & PHY2: Recommended System Parameters

6213 Recommendations
6214 1. {} [PHY1 & PHY2] A system using PHY1 or PHY2 should use system parameters within the range shown
6215 in Table 122.
6216 Table 122 Recommended System Parameters [PHY1 & PHY2]

Parameter Symbol Conditions Min Typ Max Units

Recommended total
CBUS_Phy1 Using PHY1 — — 60 pF
bus capacitance seen
by a device including
the total pin
capacitance of the CBUS_Phy2 Using PHY2 — — 200 pF
devices on the bus.

Noise margin (sum of

VIN_NOISE_MARGIN_Phy1&2 — — — 10 % VDD
ground offset & noise)

11.2.5 PHY1 & PHY2 (FBCSE): Driving and Sampling Data

6217 Requirements
6218 1. {} When the Rules in Sections (###XREF to Section #) describe transmitting a CDS bit, the Device shall
6219 drive DP according to Table 123.
6220 Table 123 PHY1 & PHY2 (FBCSE): NRZS Encoding for CDS
Value on DP Pin Before Drive on DP when CDS_DriveType_CURR = …
CDS Bit to be the CDS Bit
Transmitted 1 (Normal) 0 (Special)
(see Requirements 2 & 3)
High-Z
0 0
(bus keeper maintains 0)
1
High-Z
1 1
(bus keeper maintains 1)
0 1
0
1 0

6221 2. {} The NRZS Encoder for the CDS bit shall use as the “Value on DP pin before the CDS Bit” in Table 123
6222 either:
6223 A. When this Device was driving the last UI before the CDS Bit, it uses the value that it was outputting to
6224 the DP Pin during that UI, or
6225 B. When this Device was not driving the last UI before the CDS Bit, it uses the value captured from the
6226 DP Pin in that UI.
6227 3. {} When a Device is programmed to use Wide Bits for the CDS (i.e., CDS_BitWidth ≠ 0), it shall perform
6228 the NRZS encoding in Table 123 exactly once for each CDS Bit and then use the same drive output for all
6229 subsequent UIs in that CDS Bit.
6230 Note: i.e., all UIs in a CDS Wide Bit are driven with the same value of 0, 1, or High-Z.
6231 4. {} When a Device using PHY1 is programmed to use Wide Bits (i.e., CDS_### or DP_ ###), the Peripheral
6232 shall not change its output to high impedance between the multiple UIs that transport a single bit.
6233 Note: i.e., a Wide Bit is driven as one continuous block.
6234 5. {} When the Rules in Sections (###XREF to Section #) describe receiving a CDS bit, the Device shall:
6235 A. Capture a value from DP in the last UI before the CDS Bit, and then:
6236 B. Capture a value from DP in the last UI of the CDS Bit, and then:
6237 C. Decode the the 2 values according to Table 124 to produce a CDS Bit.
6238 Table 124 PHY1 & PHY2 (FBCSE): NRZS Decoding for CDS

Value on DP Pin Value on DP Pin at the end

Decoded Value
Before the CDS Bit of the CDS Bit
for CDS Bit
(see Requirement 2)

0 1
1
1 0
0 0
0
1 1

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
6239 6. {} When the PHY implements the the ApertureAdjust field (see Permissions 1 & 2), the data capture point
6240 within a UI shall move according to the value shown in Table ###XREF.

6241 Permissions
6242 1. {} PHY1 may support the ApertureAdjust field (see Data Port Register fields in Section 14.2.3 and CDS
6243 Register fields in Section 14.2.5).
6244 2. {} PHY2 may support the ApertureAdjust field (see Data Port Register fields in Section 14.2.3 and CDS
6245 Register fields in Section 14.2.5).
6246

11.3 TEMP OLD DRAFT Tables from v0.5r11 PHY#1 and PHY#2 (FBCSE)
6247 ###NOTE to Reviewers: These tables are copied from the WG-authored material in the previous draft and
6248 are in the process of being migrated to the correct sections of the document and edited for style and content.
6249 Where the material has been migrated elsewhere, the table caption includes a cross-reference to the new
6250 table highlighted in light blue, and the old table is greyed out but left in the document to simplify comparison
6251 with the new material.
6252 Please DO NOT add any review comments in the greyed out tables.

6253 GRAVESTONE OF OLD Table 201 Supply and Ground Voltages [see new Table 26 and Table 122]
6254
6255 GRAVESTONE OF OLD Table 202 noise requirements [see new Table 122 and Table 31]

6256
6257 GRAVESTONE OF OLD Table 203 PHY#1 Timing Characteristics [see new Table 120]
6258
6259 Table 204 Electrical Characteristics (Voltage Requirements PHY1 & PHY2) [see new Table 117]
NOTE: The limits of the Logic Output voltage are reported at the default configuration for the ZO = 44.5Ω

Parameter Symbol Conditions Min Typ Max Units

VDD=0.9 V: IOH=3.3 mA
VDD=1.2 V: IOH=4.4 mA 80 % — — VDD
Logic High Output Voltage VOH VDD=1.8 V: IOH=6.6 mA

IOH= −11 uA 99 % — — VDD

VDD=0.9 V: IOL=3.3 mA
VDD=1.2 V: IOL=4.4 mA — — 20 % VDD
Logic Low Output Voltage VOL VDD=1.8 V: IOL=6.6 mA

IOL= +11 uA — — 1% VDD

Logic High Input Same as VIH_LC

VIH — — — —
Threshold (see XREF to Table)

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
NOTE: The limits of the Logic Output voltage are reported at the default configuration for the ZO = 44.5Ω

Parameter Symbol Conditions Min Typ Max Units

Logic Low Input Same as VIL_LC

VIL — — — —
Threshold (see XREF to Table)

Same as VHYS_LC
Input Hysteresis VHYS — — — —
(see XREF to Table)

VDD = 0.9 V VGND−0.340 — VDD+0.340 V

Overshoot tolerance
VOVER VDD = 1.2 V VGND−0.390 — VDD+0.390 V
from VDD (recommended)

VDD = 1.8 V VGND−0.585 — VDD+0.585 V

6260 Table 205 Bus Keeper (Manager Only)

Parameter Symbol Conditions Min Typ Max Units

Manager_Keeper_Control=0
Zkeeper_normal 5.0 7.0 10.0 kΩ
IOH / IOL = 11 µA
Keeper Impedance
Manager_Keeper_Control=1
ZKeeper_boost 2.5 3.5 5.0 kΩ
IOH / IOL = 27 µA

Keeper
Response Time
Note: measured
from input
tKeeper_Response — — — 3 ns
crossing Vih/Vil to
change in sign of
output current.

6261
6262
6263 Table 299 Electrical Characteristics (Voltage Requirements Link Control PHY)

Parameter Symbol Conditions Min Typ Max Units

Logic High Input Measured from VSS pin

VIH_LC 45 % — 65 % VDD
Threshold on the Device

Logic Low Input Measured from VSS pin

VIL_LC 35 % — 55 % VDD
Threshold on the Device

Measured from VSS pin

Input Hysteresis VHYS_LC 10 % — — VDD
on the Device

6264
6265

Parameter Symbol Conditions Min Typ Max Units

LC output impedance ZOUT_LC_Medium1

VO ≥ 80% Vdd 400 500 600 Ω
(logic 1) (Man & Per [])

LC output impedance ZOUT_LC_Medium0

VO ≤ 0% Vdd 400 500 600 Ω
(logic 0) (Man)

LC output impedance ZOUT_LC_Strong0

VO ≤ 0% Vdd 16.0 44.5 53.4 Ω
(strong logic 0) (Man)

ZOUT_LC_Weak0_a Normal mode []

5.0 7.0 10.0 kΩ
(Man) VO ≤ 0% Vdd
LC output impedance
(weak logic 0)
ZOUT_LC_Weak0_b Boost mode []
2.5 3.5 5.0 kΩ
(Man) VO ≤ 0% Vdd

6267 Note:
4. Peripheral only uses this if it can generate the optional LC_Requests (see ###XREF).
5. When using the LC_PHY, the Manager typically uses the Normal Mode output impedance for LC:Weak0
(ZOUT_LC_Weak0_a).
6268

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
6269 ###Note to Reviewers: we are awaiting updated material for Table 209 from PHY subgroup (Niel)
6270
6271 ###TODO-Author: Description and Conditions to be put in the table:
6272 Register value refers to the register fields:
6273 PHYn_RiseFallTime. X (V or G Ramp) x (First or AdjBit)
6274 Ramp time is measured from 20 to 80% of final (not nominal) GOUT.
6275 PHYn_DriveImpedance_CURR=4 and CExtLOAD = 5 pF and VDD = any supported voltage level.
6276
6277 Table 209 [FBCSE] Rise and Fall Time with Conductance and Voltage Ramping
Register value refers to the register field: PHYn_RiseFallTime.
Ramp time is measured from 20 to 80% of final (not nominal) GOUT.
PHYn_DriveImpedance_CURR=4 and CExtLOAD = 5 pF and VDD = any supported voltage
level.

Conditions / Min Max Units

Parameter Symbol Typ
Register value (−50%) (+50%)

0 (default) 1

1 (optional) 2

2 (optional) 3

3 (optional) 4

4 (optional) 5

5 (optional) 6

6 (optional) 7

7 (optional) 8
Rise and Fall
tRF ns
time
8 (optional) 9

9 (optional) 10

10 (optional) 11

11 (optional) 12

12 (optional) 13

13 (optional) 14

14 (optional) 15

15 (optional) 16

6279 Table 210 [FBCSE] Rise and Fall Time with Voltage Ramping
Register values refer to the register field PHYn_RiseFallTime_CURR
Ramp time is measured from 20 to 80% of final (not nominal) VOUT.

Rise time/fall time between 20% and 80% for both clock and data
PHYn_DriveImpedance_CURR=4 and CExtLOAD = 5 pF and VDD = any supported voltage level

0 (default) 0.3 0.5 0.7 ns

1 (optional) 0.5 1 1.6

2 (optional) 1.1 1.9 3.1

3 (optional) 1.5 2.9 4.5

4 (optional) 2.1 3.8 6

2.7 4.8 7.4

5 (optional)
3.1 4.9 7.5

6 (optional) 3.3 5.8 8.9

7 (optional) 3.9 6.7 10

Rise and Fall time tRF

8 (optional) 4.5 7.7 12

9 (optional) 5.1 8.7 13

10 (optional) 5.7 9.6 15

11 (optional) 6.3 10.6 16

12 (optional) 6.9 11.5 18

13 (optional) 7.5 12.5 19

14 (optional) 8.1 13.5 20

15 (optional) 8.7 14.4 22

VIH VIH
CLK
VIL VIL

tIH tIS tIH

VIH
VIH VIH
DATA 1
VIL VIL
VIL

tIS tIH tIS

VIH VIH VIH

DATA 2
VIL VIL VIL

6280

VIH
CLK
VIL

tZD tDZ

VOH VOH

DATA 1
VOL VOL

tDZ tZD

VOH VOH

DATA 2
VOL VOL

6281
6282
6283 Table 211 PHY#1 Inter-UI Handover
For the Time to valid DATA/DN use the condition column with the following register definition:
PHYn_RiseFallEnable_CURR=1 where not specified differently and value representing the
PHYn_RiseFallTime_CURR register value.

Time to enable
Both after positive or negative edge on
DATA/DN output tZD 14.1 — — ns
CLK/DP clock input signal
signal.

Time to disable Both after positive or negative edge on

DATA/DN output tDZ CLK/DP clock input signal (tDZ_MAX < — — 9.0 ns
signal. tZD_MIN)

PHYn_FirstBitRampType_CURR=0 or
— — 51.7
Time to valid PHYn_AdjBitRampType_CURR=0
DATA/DN output
signal after positive or 0 (fast ramp) — — 51.7
negative edge on
tOV ns
CLK/DP clock input 1 (medium fast ramp) — — 54.7
signal, PHY.Z_out =
4 (44.5 Ohms) 60pF 2 (optional) — — 57.7
load
3 (optional) — — 60.7

Time that a Peripheral

must hold its output
Per_tOH 4.4 — — ns
after Clock when it
owns two UIs

Manager Output Hold

time when it owns two Man_tOH 5.4 — — ns
bits in a row.

Setup time required

by a Device on its
DATA/DN input signal
before a positive or tIS — — — 2.0 ns
negative edge on its
CLK/DP clock input
signal

Hold time required by

a Device on its
DATA/DN input signal
after a positive or tIH — — — 2.0 ns
negative edge on its
CLK/DP clock input
signal

6284

0.8*VDD VDD

VCM

0.2*VDD

tR tF
6285
6286
6287
VIH VIH

tOV,max tOV
VIL VIL

tZD,min tOHC tOHD

VOH

VOL
6288
6289
6290
6291
6292 Table 213 PHY#2 Manager
###TODO: how do you measure you are still Z and not yet D? same way around too.

Time to enable tZD CLOAD=5pF 6.5 — — ns

Setup time tIS — — 3.0 ns

Hold time Input tIH — — — ns

Hold time Output tOH CLOAD=5pF 6.5 — — ns

6293 Table 214 PHY#2 Peripheral

Parameter Symbol Conditions Min Typ Max Units

Time to enable tZD CLOAD=5pF 2.0 — — ns

###TODO: explain
Setup time tIS — — 2.0 ns
“Max”

###TODO: explain
Hold time Input tIH — — 2.0 ns
“Max”

Time to disable tDZ CLOAD=5pF — — 8.2 ns

Hold time Output tOH CLOAD=5pF 2.2 — — ns

6294
6295 Table 215 PHY#2 Peripheral Output Delays
For the Time to valid DATA/DN use the condition column with the following register definition:
PHYn_RiseFallEnable_CURR=1 where not specified differently and value representing the
PHYn_RiseFallTime_CURR register value.

NOTE: no min value specified since we are interested in meeting the requirements, ###Author: Rise and Fall
time with Conductance Ramping is in table named: Rise and Fall time with Voltage Ramping.

Parameter Symbol Conditions / Register value Min Typ Max Units

Time to disable ns
DATA/DN output signal
after positive or
negative edge on
tDZ_PHY2M — — 10.8
CLK/DP clock input
signal of Manager (Eqn:
1/(4 x fCLK_PHY2L+1ns)
5pF load.

Time to valid DATA/DN PHYn_RiseFallEnable_CURR=0 — — 13.3

output signal after tOV_PHY2M ns
positive or negative 0 (default) — — 13.3

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
edge on CLK/DP clock 1 (optional) — — 16.3
pin output of the
Manager, PHY.Z_out = 2 (optional) — — 19.3
4.
Both clock and data are 22
measured with a 60pF
load and relative to
each other. The 60pF 3 (optional) — —
load is to get some
current through the pin.

Time to valid DATA/DN PHYn_RiseFallEnable_CURR=0 — — 10.7

output signal after
positive or negative 0 (default) — — 10.7
edge on CLK/DP clock
input signal of 1 (optional) — — 13.7
Peripheral, PHY.Z_out =
tOV_PHY2P ns
4 a 60pF load
2 (optional) — — 16.7
NOTE: 6.4ns internal
propagation delay plus
19.7
rise time. The 60pF
load is to get some 3 (optional) — —
current through the pin.

6296
6297 ###TODO-Author: remove this “page-break-before”

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
12 PHY3 Differential Low-Voltage (DLV)
6298 ###Note to Reviewers: the material in this PHY Chapter has been re-ordered to be closer to ther final
6299 document, with the temporary WG-authored material being moved to the end and/or deleted. Thus we now
6300 have:
6301 Section 12.1 Description (informative) – this was “Section 12.2” up to draft v0.5 r13
6302 Section 12.2 Specifications (normative) – this was “Section 12.3” up to draft v0.5 r13
6303 Section 12.3 TEMP OLD DRAFT Tables from v0.5r11 for PHY#3 (DLV) – this was “Section 12.1” up to
6304 draft v0.5 r13, and will soon be deleted.

12.1 Description (informative)

12.1.1 Overview of PHY3 (DLV)

6305 PHY3 is a differential low-voltage PHY. It supports multi-drop operation where all Devices (Manager and multiple
6306 Peripherals) are capable of driving the shared bus. It is source terminated and the DP and DN lines are typically laid
6307 out as a controlled impedance differential pair on a PCB.
6308 The output circuit is actually a complementary pair of single-ended low-voltage outputs that swing between 0V and
6309 a register-controlled output high voltage of a few hundred mV. The input circuit is a differential input with
6310 hysteresis.
6311 The signaling from the Manager includes a Row Sync edge at the beginning of every Row, and the Peripherals use
6312 this as both a phase reference for recovering a bit clock using a PLL or DLL and as a direct audio-quality clock
6313 (where the frequency can be selected by gating edges).
6314 Electrical parameters specified in normative Section # include:
6315 • Single-ended output level (VSEOS_NOM), see ###XREF.
6316 • …
6317 Timing parameters specified in normative Section # include:
6318 • ### Register-selected output rise/fall time
6319 • Integrated phase noise for Manager audio clock jitter, see ###XREF.
6320 • <clock jitter>
6321 • ###...
6322 • .
6323
6324 ###TODO-Author: explain the basic principles of locking to Sync Events.
6325

12.1.1.1 Tolerance of Missing Row Syncs

6326 The Peripheral clock recovery can tolerate occasional missing Row Syncs, which might result from electrical noise
6327 or contact bounce in connectors in the signal path.
6328 The tolerance is … ###TODO-Author: finish this sentence!
6329
6330 [###TODO-Author: explain that the reason for the min of 2 rows is to avoid dropping off after 1 usec when running
6331 at 600 kRows].

12.1.2 [DRAFT] PHY3 (DLV): Special Drive Type for CDS Bits
6332 The DLV PHY supports a special drive type, which is used after Cold Start when the Peripheral output timing might
6333 be inaccurate. At this time the Traffic pattern will be Command-only with no audio Payload, so there will be only 1
6334 rising edge per row (Sync0 to Sync1 transition) and only 1 falling edge per row (wither caused by CDS logic 0, or
6335 by the Sync0 immediately before the next Row).

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
6336 When CDS_DriveType=0 (Special Drive Type):
6337 • CDS Logic 0: active drive to physical 0 (DP=Low, DN=High).
6338 • CDS Logic 1: passive drive to physical 1 (DP=High, DN=Low). The bus-keeper maintains the physical 1
6339 value from the Sync1.
6340
6341

12.1.3 PHY3 (DLV) System Design Issues

6342 Note:
6343 Normative recommendations for the parameters related to these system design issues are specified in
6344 Section 12.2.4.

12.1.3.1 Bus Capacitance

6345 ###TODO: FBCSE -> DLV
6346 The bus capacitance seen by the interface is the sum of all of the devices plus the PCB traces and discrete
6347 capacitor(s) that might be added by the system designer to guarantee the minimum value in ultra-small systems.

12.1.3.2 Noise Margin

6348 ###TODO: FBCSE -> DLV. single-ended (noise and ground offset) & differential (only noise)
6349 There is some margin between the input and output voltgae levels for Devices to allow for system effects. It is a
6350 system design issue how much of that margin is consumed by noice coupled from the rest of the system and how
6351 much by ground offset between devices (caused by IR-drop in ground planes).
6352
6353
6354
6355

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
12.1.4 DRAFT: Peripheral DLV PHY Timing Calibration
6356 Note:
6357 There is a system-level requirement constraining the upper limit on time used for calibration: Manager has
6358 full communication with 4 Peripheral devices on a link within 1 msec.
6359 Figure 164 illustrates the principles of the method for calibrating the Peripheral DLV PHY timing, with the Manager
6360 sampling around the transition from DLV:1 to 0.

Row Sync Point

... 14 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 2 3 ...
... S0 S0 S1 S1 S1 S1 CDS-special S0 S0 S0 S0 S1 S1 S1 S1 ...

Manager sample aperture

during Calibration Packet

Manager sample aperture

for data communication
CDS

CDS

Keeper: on bus Peripheral: in CDS

after Sync1 in Calibration Packet
Peripheral is very late:
Manager samples are 100%

Peripheral is late:
Manager samples are 90%/10% 1/0

Peripheral is a small amount late:

Manager samples are 70%/30% 1/0

Peripheral is correctly adjusted:

Manager samples are 50%/50% 1/0

Peripheral is a small amount early:

Manager samples are 30%/70% 1/0

Peripheral is early:
Manager samples are 10%/90% 1/0

Peripheral is very early:

Manager samples are 100% 0

Peripheral view of Manager sampling

operation when Peripheral is correctly
adjusted.
6361
Figure 164 #DRAFT: DLV Timing Calibration

6362 ###TODO-Author: describe that the Manager (and Peripheral) aperture is the middle of the last UI (which is the
6363 only UI when not using wide bits). Also note that the Peripheral has ApertureAdjust.
6364 ###TODO-Author: modify this diagram to show Safe-Lock-4, i.e., 4 columns, 1xS0, 1xS1, 1xHO, 1xCDS-special.
6365

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
6366 ###TODO-Author: clean up the following description:
6367 1. Principle: that the launch timing of each Peripheral Tx is adjusted so that the arrival time for its bits at the
6368 Manager Rx is aligned (within tolerance) to some “golden phase” reference at the Manager.
6369 A. That golden phase is aligned with the Manager’s own Tx bits at some point in the system, but the
6370 location within the circuitry of this zero-offset might actually be somewhere inside the Manager. Thus
6371 there will be a location where a “virtual oscilloscope” would see Peripheral bits and Manager bits
6372 aligned with each other, but it is possible that a physical oscilloscope observing the Manager pins
6373 would see bits from all Peripherals received at one golden phase, and bits from the Manager
6374 transmitted later than this. [Noting that, depending on bus length and programmed edge transition time,
6375 the Manager bits might suffer from stair-step effects that make their timing difficult to observe at this
6376 point].
6377 2. At the lowest level there is the per-measurement behavior. The Peripheral Tx launches a known change in
6378 the value on the bus (from keeper-maintained-1 from the S1, to a Peripheral-output-0 in the CDS bit). The
6379 Manager samples this value at a special sampling point (moved to the beginning of the CDS bit so that it is
6380 intentionally centered around the transition point when the Peripheral is properly calibrated). The Manager
6381 echoes the value of this sample back to the Peripheral in the next 2 CDS bits (on the following 2 Rows),
6382 with the second reflected value being inverted. This set of three bits is a “Calibration measurement”.
6383 A. For the calibration payload bits, the sampling point of the Manager Rx is deliberately phase shifted
6384 from the normal position so that the Rx is sampling edges rather than the center of the eye. This phase
6385 shift in the Manager is 50% of whatever width the Peripheral CDS bits are set to.
6386 3. Above the bit-level there is statistical aggregation performed by the Peripheral on the values of the echoed
6387 bits. The assumption is that voltage noise and timing jitter will smear out the values received by the
6388 Manager Rx so that statistical calculations will give a continuous measure (or at least many bits rather than
6389 one bit) of where the sampling position is on the waveform with respect to the ideal point.
6390 4. The Peripheral Tx applies some tuning algorithm (perhaps imp-def or an imp-def choice of several methods
6391 suggested by the spec?) to adjust the timing of its Tx with the goal of converging on a launch timing that
6392 delivers a “nice” result from the statistical sampling.
6393 5. The Manager uses a Command (perhaps parameterized and/or split into several Commands) that clearly
6394 defines which UIs in the Transport Pattern and/or Command Column are allocated to the calibration
6395 payload bits (Peripheral Tx and Manager echo Tx) defined in Step #2.
6396 A. The calibration payload is within the Command Column, which is being monitored by all Devices
6397 looking for an SPM token. The Manager Tx echoes 2 bits (both the sample and its complement) to
6398 avoid ever generating a bit sequence that a Peripheral (either the one being tuned or another one)
6399 would detect as a false positive SPM.
6400 B. Depending on the efficiency of the Peripheral algorithm, the overhead in the Command (SPM, Header,
6401 Body) is between 33% and 100% on top of the bandwidth being spent on calibration payload.
6402 Currently, each Command addresses only a single Peripheral, but it’s technically possible to have
6403 Command parameters that mean a single Command allocates chunks of calibration payload to each of
6404 the Peripherals. Perhaps this would make sense for the “TrimCal” Command that periodically
6405 generates a few bits (maybe 10 bits in 30 Rows?) from each Peripheral just to maintain calibration.
6406 C. The Command parameters, and even the choice of allocating bandwidth in the Command Column
6407 versus normal “payload” columns, are pretty much independent of the discussion in steps #2 to #4.
6408 6. The principle of the calibration could be extended to support Peripheral-to-Peripheral transmission, e.g., by
6409 tuning Peripheral#1’s Tx output to arrive at the Manager with golden phase, and then tuning the point at
6410 which other Peripheral Rx’s sample the bits that are known to be transmitted by Peripheral #1.

12.1.5 DRAFT: DLV PHY Calibration in the Peripheral

6411 ##TEMP: Some of the material about the Calibrate Command in Section 9.1.12 will be migrated into this PHY
6412 section.

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
12.1.6 PHY3 (DLV) Clock Config and Transport Patterns
6413 ###TODO-Author: Need to check what normative support there is for the limits on ranges (Mandatory lower
6414 limit of 510 kRows, but optional maximum limit on rows).
6415 The Clock Config and Transport Pattern generated by the Manager with PHY3 (DLV) can be characterized into one
6416 of three groups. The ranges of parameters for these groups are summarized in Table 125.
6417 Safe-Lock-4 (see Section 10.1.7.1) is a combination of Clock Config and Transport Pattern used when
6418 PHY3 is activated after a Cold Start. Peripherals use special drive for CDS bits because the Transport
6419 Pattern has no Handover time between Control Data Stream and Sync-0.
6420 Lock-N is a Command-Only Transport Pattern used when PHY3 is activated after Warm Reset (e.g., when
6421 waking from Sleep), and at any other times when it is desirable to make it easier for Peripherals to
6422 re-synchronize to Row boundaries. Peripherals might need non-default PHY settings and/or PHY timing
6423 calibration in order to operate in some parts of this range.
6424 Running is used after Lock-N when all Peripherals have responded correctly to a Ping Command. If the
6425 Transport Pattern assigns fewer UIs to the Control Data Stream (i.e., uses CDS bits that are less wide) then
6426 this might need finer timing calibration than Lock-N.
6427 Table 125 Combinations of Clock Config and Transport Pattern for PHY3 (DLV)

Peripheral Transport
Nominal
Row Rate Column PHY Pattern
Name UI Rate Notes
(kRows/s) Count Output Bit Limitations
(Mbps) Encoding

All Peripherals support

Cold
0:Special operation over this whole
Start: 9.6 – Command-
2400 – 3200 4 (Passive 1 range using the default
Safe- 12.8 Only
/ Active 0) PHY settings and without
Lock-4
PHY timing calibration.

Peripherals might not

Command- support operation over all
Lock-N
Only of this range, or all
combinations of
Nominal 600 – parameters.
4.32 –
6500 4 – 32 1:Normal [1] Peripherals might not
76.8
510 – 7475 Any valid support audio payload
Running Transport operation in all Clock
Pattern Configs for which they
support Command
operation.

6428 Note:
1. Peripheral PHY Output encoding of “Special” will typically also work correctly, but for high UI rates this
might need to be verified with system simulations.

12.1.6.1 PHY-specific constraints on CDS Transport (PHY3, DLV)

6429 When using PHY3:
6430 • Column 0 is always allocated to Sync1, but Sync1 can be wider.
6431 • The Manager programs the Peripheral CDS_HorizontalStart Register field to indicate where the CDS is
6432 positioned within the Row (range is 2 through 31).
6433 • In Rows when the Manager owns the CDS bit, it will start driving the CDS bit value immediately after the
6434 column(s) allocated to Sync1, so that the CDS bit also occupies any columns allocated to Handover. This
6435 improves robustness of Manager to Peripheral communication by giving more setup time in the Peripheral.

12.2 Specifications (normative)

6436 The Requirements, Permissions, and Recommendations in this Section (12.2) apply to Managers and Peripherals
6437 when they are using Audio-mode PHY3 (DLV PHY).

12.2.1 PHY3 (DLV): Link Control Behavior

6438 Requirements
6439 1. {} [PHY3] The Peripheral shall use values for the timing parameters named in this Section (12.2.1) that are
6440 between the lower and upper bounds in Table 126.
6441 Table 126 DLV PHY: Timing Parameters for Peripheral Link Control

Parameter Min Typ Max Units Description

Limits on Peripheral Behavior

Limits on the number of missing Row

Syncs that a Peripheral uses when
Per_tRowSyncCount_DLV 2 — — Rows indicating missing RowSync.
See Requirement 2.A.

Limits on the actual time threshold

that a Peripheral uses when indicating
Per_tRowSyncMissing_DLV 1 — 6 µs missing RowSync.
See Requirement 2.A.

The time threshold that a Peripheral

uses when detecting PHY_Inactivity
Per_tPhy_Inactivity_DLV 20 — 60 µs lies within this Min/Max range.
See Requirement 3.

Upper limit on time to acquire Row

Sync when the input is
Per_nRowsToLock_DLV [1] — — 6000 Rows Command-Only.
See Requirement 4.

Required maximum value of

Per_tPhyStart.
Per_tPhyStart_DLV [2] — — 291 µs
See Section 5.2.2 Requirement 10.A
& 12.A.

Recommended Peripheral Behavior

Preferred upper limit on time to

acquire Row Sync when the input is
Per_nRowsToLock_DLV [1] — — 1500 Rows
Command-Only.
See Recommendation 1.

Recommended minimum value of

Per_tPhyStart that applies when
Peripheral clock recovery circuitry
might be sensitive to perceiving
Per_tPhyStart_DLV [2] 97 — — µs
LC_PHY signaling as incorrect DLV
PHY signals.
See Section 5.2.2 Requirement 10.A
& 12.A.

6442 Note:
1. There is both a required maximum and a recommended maximum for Per_nRowsToLock_DLV.
2. There is both a required maximum and (for Devices with particular behavior) a recommended minimum for
Per_tPhyStart_DLV.

6443 2. {} [PHY3] When the Peripheral is in Link State: Attached, the PHY shall generate a PHY_BadRowLock
6444 condition (Section 5.2.2 Requirement 14.C) if any of the following occur:
6445 A. The Clock recovery circuitry has both:
6446 i. Not seen a RowSync event for Per_tRowSyncCount number of Rows, and:
6447 ii. Not seen a RowSync event for a time of Per_tRowSyncMissing, or:
6448 B. The Clock recovery circuitry (e.g., PLL or DLL) is no longer correctly locked to the Row_Syncs from
6449 the Manager.
6450 3. {} [PHY3] The Peripheral shall indicate PHY_Inactivity (see Section 5.2.2 Requirement 20) when it
6451 detects no signal transitions for a time of Per_tPhy_Inactivity_DLV.
6452 4. {} [PHY3] When the Peripheral is attempting to attach to the bus (Section 5.2.2 Requirement 13), the clock
6453 recovery circuitry shall lock to the periodic Row Syncs after a maximum of Per_nRowsToLockMax_DLV
6454 Rows, provided that all of the following conditions are satisfied:
6455 A. The Manager is generating Rows that match the values in the RowRateRange (###XREF), Unit
6456 Interval Rate Range (see Table 127), and NumColumns (see Table 153) register fields, and
6457 B. The Link traffic includes only the Control Data Stream (i.e. Command-only).
6458 Note: see also Permission 1 and Recommendation 1.
6459
6460 ###TODO-Author: move to Section 5.2.4.
6461 Table 127 ###TODO PHY3 (DLV): Unit Interval Rate Range

UI Rate not needed by this

0 [1]
Peripheral
1 – 15 Reserved

16 4.585 — 6.484
MHz
17 5.453 — 7.711

18 6.484 — 9.170

19 7.711 — 10.905

20 9.170 — 12.968

21 10.905 — 15.422

22 12.968 — 18.340

23 15.422 — 21.810

24 18.340 — 25.937

25 21.810 — 30.844

26 25.937 — 36.680

27 30.844 — 43.620

28 36.680 — 51.874

29 [2] 43.620 — 61.688

30 [2] 51.874 — 73.360

31 [2] 61.688 — 87.241

6462 Note:
1. If the PHY3 implementation does not need Some PHYs (e.g., PHY1&2) do not have behavior that is
affected by the UI_RateRange Register. If the Device implements the Register because it has other PHYs
that do need it, , has other PHYs that do use the Register then when using PHY1&2 it will be
resetneed , so the Register is reset to 0 and the Manager will not write a value other than 0.
2. UI_RateRange settings 13, 14, and 15 are optional (see Table 153).

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
6463 5. {} [PHY3] The Manager shall use values for the timing parameters named in this Section (12.2.1) that are
6464 between the lower and upper bounds in Table 128.
6465 Table 128 PHY3 (DLV): Timing Parameters for Manager Link Control

Parameter Min Typ Max Units Description

Limits on Manager Behavior

Duration of Manager driving DLV:0 when

Man_tParkBus_DLV 65 — 100 µs parking the bus.
See Requirement 6.

Recommended Manager Behavior

— — — µs

Range of Input Conditions within which the Manager Operates Correctly

— — — µs

6466 6. {} [PHY3] The Manager shall park the bus (see Section 5.2.3 Requirement 5) by driving a value of DLV:0
6467 for a time of Man_tParkBus_DLV.
6468
6469 7. {} [PHY3] When the Manager starts generating Rows after a Cold Start it shall use a combination of
6470 Safe-Lock Config (see Section 5.2.3 Requirement 9.G.ii) and Transport Pattern that have:
6471 A. A Row Rate between 2.40 and 3.20 MRows/sec, and
6472 B. Column_Count=4 Columns, and
6473 C. CDS_HorizontalStart=Column 2, and
6474 D. CDS_HorizontalCount=1 UI, and
6475 E. CDS_BitWidth=1 UI, and
6476 F. CDS_DriveType=Special.
6477 8. {} [PHY3] The Manager shall generate Rows (see Section 5.2.3 Requirement 12) that have:
6478 A. A ColumnCount of 4 or more.
6479 B. A Sync0 symbol (1 or more Bit Periods of DLV:0), followed by
6480 C. A Sync1 symbol (1 or more Bit Periods of DLV:1 starting in Column 0), such that:
6481 D. The transition between the Sync0 and Sync1 symbols occur at a constant periodic interval defined by
6482 the Row Rate.

6483 Permissions
6484 1. {} [PHY3] When the Peripheral is attempting to attach to the bus but the condition in Requirement 4.B is
6485 not satisfied (i.e., there is some traffic on the bus in addition to the Control Data Stream), the clock
6486 recovery circuitry may take an Implementation-Defined number of Row Syncs to lock to the periodic Row
6487 Syncs.
6488 Note: the typical number of Rows, Per_nRowsToLockTyp_ActiveBus_DLV, is not constrained by the
6489 Specification, but could be reported in a device data sheet.
6490

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
6491 Recommendations
6492 1. {} [PHY3] When the Peripheral is attempting to attach to the bus (Section 5.2.2 Requirement 13), the clock
6493 recovery circuitry should lock to the periodic Row Syncs after a maximum of Per_nRowsToLockTyp_DLV
6494 Rows, provided that the conditions in Requirement 4 are satisfied.
6495 2. {} [PHY3] Before the Manager changes the Clock Config according to Section 5.2.3 Requirement 14
6496 and/or the Transport Pattern (e.g., Wide Bits), it should perform sufficient PHY Calibration Commands so
6497 that the Peripherals will be capable of transmitting and receiving data correctly with the new Clock Config
6498 and/or Transport Pattern.

12.2.2 PHY3 (DLV): Electrical Parameters

6499 Requirements
6500 1. {} [PHY3] The output voltage levels for PHY3 (DLV) shall be within the ranges shown in Table 129.
6501 Table 129 [PHY3] Single-Ended Output Swing

Settings
Parameter Symbol (PHY3_SEOutputSwing, Conditions Min Typ Max Units
see Table 162)

0 [1] 50

1 [1] 100

2 [1] 150

Single-ended 3 “Settled” 200

Output
VSEOS_NOM output high −5 % +5 % V
Swing
Voltage 4 [1] IOH = 50 uA 250

5 [1] 300

6 [1] 350

7 [1] 400

6502 Note:
1. VSEOS_NOM settings 0, 1, 2, 4, 5, 6, and 7 are each independently optional (see Table 162).
6503
6504 ###TODO-Author: add a rule to introduce Table 130.
6505 Table 130 [PHY3] Output Voltage Levels

Parameter Symbol Conditions Min Typ Max Units

Logic Low Most negative of − 0 mV Most positive of +10 mV

Output VOL_Phy3 IOL = ±10 uA or — or —
Voltage TX (−5 % of VSEOS_NOM) (+5 % of VSEOS_NOM)

Logic High
Output VOH_Phy3 IOH = ±10 uA (95 % of VSEOS_NOM) — (105 % of VSEOS_NOM) —
Voltage TX

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
6506
6507
6508 2. {} [PHY3] The output impedance for PHY3 (DLV) shall be within the ranges shown in Table 131.
6509 Table 131 [PHY3] Output Impedance

Settings
Parameter Symbol (PHY3_DriveImpedance, Conditions Min Typ Max Units
see Table 162)

0 [1] 20.0

1 [1] 24.5

2 [1] 30.0

3 [1] 36.5
Output IOL = 1 mA
ZOUT − 0% +20% Ω
Impedance[2] IOH = 1 mA
4 44.5

5 [1] 54.5

6 [1] 66.5

7 89.0

Single-ended
driver impedance
mismatch IOL = 1 mA
between DP and ∆ZDriver — −3 — +3 %
IOH = 1 mA
DN
(i.e., ZOUT_DP –
ZOUT_DN)

6510 Note:
1. Drive Impedance settings 0, 1, 2, 3, 5, and 6 are optional (see Table 162).
2. ZOUT is the single-ended output impedance measured separately on each output and at the end of the rise
or fall time (i.e., either after 80% of the voltage ramp or statically measured).
3. The overlap between ranges means that the function might be non-monotonic, i.e., a higher register
setting could map to lower impedance.

6511 3. {} [PHY3] The Receiver Parameters for PHY3 (DLV) shall be within the limits in Table 132.
6512 Table 132 [PHY3] Receiver Parameters

Parameter Symbol Settings Min Typ Max Units

Minimum Hysteresis, i.e.,

Receiver DC
VPhy3_RX_DC_OFFSET PHY3_HYSTERESIS=0 − 0 — +10 mV
Offset
(see Table 162)

Single-Ended
Input Voltage VPhy3_RX_SE_### — −100 — VSEOS + 100 mV
Range

Common Mode
(50% VSEO) (50% VSEOS) +
Input Voltage VPhy3_RX_Diff_### — — mV
− 100 100
Range

Common Mode
CMRRPhy3 — 20 — — dB
Rejection Ratio

6513
6514
6515 4. {} [PHY3] The electrical parameters for the PHY3 Bus Keeper in the Manager shall be within the ranges
6516 shown in Table 133.
6517 Table 133 [PHY3] (DLV) Bus Keeper Behavior

Parameter Symbol Conditions Min Typ Max Units

Bus Keeper
Keeper_Drive_Boost
impedance, normal ZDLV_Keeper_Boost0 2.5 3.5 5.0 kΩ
Register Bit = 0
mode

Bus Keeper
impedance, boost DLV_Keeper_Boost
ZDLV_Keeper_Boost1 1.0 1.4 [1] 2.0 kΩ
mode. Register Bit = 1
(Optional)

Keeper
Response Time
Note: measured
from input
tDLV_Keeper_Response — — — 3 ns
crossing Vih/Vil to
change in sign of
output current.

6518 Note:
1. The Bus Keeper impedance for PHY3 (DLV) is lower than some other PHYs because PHY3 uses smaller
input voltage swings, so can tolerate less voltage drop caused by the leakage current.

12.2.3 PHY3 (DLV): Timing Parameters

6519 … … how to specify the tolerance and or test conditions for the PHY3_CalDelay_CURR Register setting.
6520 ANSWER: the effect of PHY3_CalibrationDelay_CURR shall be monotonic.
6521 ANSWER: The largest step between delays for adjacent values of Delay_CURR shall be 10 % UI, i.e., The
6522 differential non-linearity (i.e., step size between the timing for adjacent values) in PHY3_CalibrationDelay_CURR
6523 shall be ≤ ( (10% UI) – 1 LSB).
6524
6525 When the Register setting is 0xC0 (nominal delay of 0.00 UI) and the Peripheral drives 2 consecutive bits with 0
6526 then 1, then the phase offset from the S0/S1 transition to this output transition should be 0 +/- ###TBD ns.
6527 Conditions: Safe-Lock-4, Vdd=nominal, temperature= 25 deg C.
6528 “Gain” parameter for the PHY3_CalDelay_CURR: When the current Clock Configuration matches the value in the
6529 UI_Range Register field then a change of 0x20 in PHY3_CalDelay_CURR shall correspond to 1.00 +/- ###TBD UI.

6531 Requirements
6532 1. {} [PHY3] The UI_RateRange field in ### introduce timing table .
6533
6534 ###TODO-Author:
6535 • Grey out the old tables from Stefano
6536 • Duplicate this table for FBCSE with the following changes:
6537 • Register names are PHYn not PHY3.
6538 • Add footnote that V and G ramp are optional.

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
6539 2. {} [PHY3] The rise or fall time of changes in the output on each of DP and DN pins shall be within the
6540 limits shown in Table 135.
6541 Table 134 PHY3 (DLV): Voltage Ramp Time
Register Settings (see Table 162)
PHY3_RiseFallTimeVRamp
PHY3_FirstBitRampType
(20% to 80% of VSEOS) Test Conditions Min Typ Max Units
or
or
PHY3_AdjBitRampType [1]
PHY3_RiseFallTimeGRamp [2]
(20% to 80% of G_NOM)

ZOUT = 4 (44.5 Ω)

0 (Simple Unramped Output) Load Capacitance

[3] — — — 0.7
CL_DP, = 5 pF
CL_DN = 5 pF
CL_DP_DN = 5 pF

0 0.3 0.5 0.8

1 ZOUT = 4 (44.5 Ω) 0.6 1.0 1.7

Load Capacitance
2 1.3 2.1 3.2
CL_DP, = 5 pF
CL_DN = 5 pF
3 CL_DP_DN = 5 pF 1.9 3.0 4.6

4 2.5 4.0 6.1

5 [4] 3.1 4.9 7.5

6 3.8 5.9 8.9 ns

1 (Voltage Ramp) 7 4.4 6.9 10

or
2 (Conductance Ramp) 8 5.0 7.8 12

9 ZOUT = 4 (44.5 Ω) 5.6 8.8 13

Load Capacitance
10 [4] 6.2 9.7 15
CL_DP, = 30 pF
CL_DN = 30 pF
11 CL_DP_DN = 30 pF 6.8 11 16

12 7.4 12 18

13 8.0 13 19

14 8.6 14 21

15 9.2 15 22

6542 Note:
1. FirstBitRampType setting applies when this Device was not driving the bus during the previous UI;
AdjBitRampType applies when it was driving in that UI.
2. RampType of 1 (Voltage Ramp) uses the RiseFallTimeVRamp setting; RampType of 2 (Conductance)
uses the RiseFallTimeGRamp setting.
3. RampType of 0 (simple unramped output) selects a basic output that simply drives towards the desired
output voltage (i.e., VSEOS or Ground).

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
4. RiseFallTime settings of 5 and 10 are mandatory to implement, settings of 0–4, 6–9, and 11–15 are each
optional.

6543 Table 135 PHY3: Voltage Ramp Time

Symbol Conditions Min Typ Max Units

6544
6545
6546 3. {} [PHY3] The Manager transport jitter (J_TX_MGR) shall be within the limits in Table 136.
6547 4. {} [PHY3] The Peripheral transport jitter (J_TX_PER) shall be within the limits in Table 136.
6548 Table 136 PHY3: Jitter Parameters

Parameter Symbol Conditions Min Typ Max Units

Peak jitter in of all Manager Tx

edges.
J_TX_MGR — — 10 % UI
(Transport clock quality, see
Requirement 3).

High fidelity.
Integrated Phase Noise in Row LΦ_TX_MGR_1 — — 150 ps
(e.g., 95 dB THD+N
Sync Edges, measured from
@ 20 kHz)
100 Hz to half of the Row Clock
(i.e., half of Row Rate).
Low fidelity
(Audio clock quality, see
LΦ_TX_MGR_2 (e.g., 72 dB THD+N — — 2000 ps
Recommendation 1).
@ 20 kHz)

Total Jitter (random + Condition: Total

deterministic) in all Peripheral Tx Jitter in
edges (peak). TJ_TX_PER zero-crossing of — — 7% UI
received Row Sync
(see Requirement 4)
Edge = 1 % UI.

Condition: Total
Random Jitter in all Peripheral Jitter in
Tx edges (RMS). RJ_TX_PER zero-crossing of — — 2.5 % UI
(see Requirement 4) received RowSync
Edge = 1 % UI.

Condition: Timing
###TBD Open Item #149:
Uncertainty in
resolve the definition of “timing
zero-crossing of
uncertainty” versus “jitter”. TU_TX_PER — — 65 % UI
Received Row
Timing Uncertainty in start time
Sync Edge
of all Peripheral Tx edges.
= 50 % UI.

6549 Note:
6550 All of the jitter parameters in Table 136 are measured at the zero crossing point of the differential signal.
6551
6552
6553

6554 Recommendations
6555 1. {} [PHY3] When any Peripherals are using the Row Sync edges as an audio clock, the Manager Row Sync
6556 output jitter (LΦ_TX_MGR) should be within the limits in Table 136.
6557

6558 Requirements
6559
6560
6561

12.2.4 PHY3: Recommended System Parameters

6562 1. {} [PHY3] A system using PHY3 should use system parameters within the range shown in Table 137.
6563 Table 137 Recommended System Parameters [PHY3]

Parameter Symbol Conditions Min Typ Max Units

Total bus capacitance seen by a

device including the total pin
capacitance of the devices on the CBUS_Phy3 — 5 — 200 pF
bus.
(Either DP or DN to Ground).

Total bus capacitance between DP

CDP_to_DN_Phy3 — — — 100 pF
and DN.

Mismatch in channel capacitance,

CBus_Mismatch_Phy3 — −5 — +5 pF
i.e., CDP − CDN

Noise margin (sum of ground VIN_NOISE_MARGIN_

— — — 100 mV
offset & common-mode noise) PHY3_CM

Noise margin (differential-mode VIN_NOISE_MARGIN_

— — — 25 mV
noise) PHY3_DIFF

6564
6565

12.2.5 Parameter Measurement Definitions and Test Circuits

6566
6567 In the test circuits in this section, the load capacitances include any capacitance of the probes and measuring
6568 equipment.
6569

12.2.5.1 PHY3 Test Circuit #1

6570 ###TODO-Author: Remove the numbers (5 pF) from this diagram and name these caps as CL_DP, CL_DN, CL_DP_DN.
6571 Figure 165 shows PHY3 Test Circuit #1.This circuit could be used for the following parameters:
6572 • PHY3 Rx DC Offset (see ###XREF)
6573 • ### …
6574 • ###...

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
.5 DP
+
CL
5 pF Differential
TX Measurement
CL Device
.5 DN 5 pF
–
6575
Figure 165 PHY3 Test Circuit #1

6576
6577 ###TODO-Author: replace picture in Figure 165 with the correct Visio source.
6578

12.2.5.2 PHY3 Measurement Waveform #1 (Differential Voltage)

6579 ###TBD Niel says: this figure is probably not going to be included.
6580 Figure 166 shows PHY3 Measurement Waveform #1 (Differential Voltage).This waveform is used for the following
6581 parameters:
6582 • ###TBD are there any normative _differential_ voltage parameters (maybe something about Rx input?).
6583 • ###TBD parameter name (see ###XREF)
6584
UI

0.8*VOD VOD(PP)

0.2*VOD

tR tF
6585
Figure 166 PHY3 Measurement Waveform #1 (###TBD-name)

6586 ###TODO-Author: replace picture in Figure 166 with the correct Visio source.
6587

12.3 TEMP OLD DRAFT Tables from v0.5r11 for PHY#3 (DLV)
6588 ###NOTE to Reviewers: These tables are copied from the WG-authored material in the previous draft and
6589 are in the process of being migrated to the correct sections of the document and edited for style and content.
6590 Where the material has been migrated elsewhere, the table caption includes a cross-reference to the new
6591 table highlighted in light blue, and the old table is greyed out but left in the document to simplify comparison
6592 with the new material.
6593 Please DO NOT add any review comments in the greyed out tables.
6594

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
6595 GRAVESTONE OF OLD Table 301 PHY3 Unit Interval (see new Table 127)
6596
6597
6598 Table 302 PHY3 Static Transmitter Electrical Specification

Parameter Symbol Conditions Min Typ Max Units

Most negative of Most positive of

− 0 mV +10 mV
Logic Low Output or or
VOL_Phy3 — —
Voltage TX IOL = ±10 uA (−5 % of (+5 % of
VSEOS_NOM) VSEOS_NOM)

Logic High (95 % of (105 % of

Output VOH_Phy3 IOH = ±10 uA VSEOS_NOM) — VSEOS_NOM) —
Voltage TX

6599
6600
6601
6602 Table 303 PHY3 Static Common Mode Offset Between Logic0 and Logic1 (∆VCM)

Settings
Parameter Symbol Conditions Typ Max Units
(PHY3_SEOutputSwing)

0 0 10.0

1 0 10.0

2 0 10.0
VCM mismatch
during static, 3 0 10.0
non-transient IOL = ±10 uA
∆VCM mV
signal IOH = ±10 uA
conditions. 4 0 12.5

5 0 15.0

6 0 17.5

7 0 20.0

6603
6604 ###TODO-Author: delete this TEMPORARY NOTE: VCM mismatch during static, non-transient signal
6605 conditions. ∆VCM is constant for register settings 0–3 because of measurement uncertainty, but then scales
6606 linearly for register settings 4-7.
6607
6608 ###TODO:PHY subgroup – find the missing spec for the dynamic/transient V_CM offset, is this named
6609 dynamic ∆VCM ?
6610
6611

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
6612 GRAVESTONE OF OLD Table 304 PHY3 Transmitter Electrical Single Ended Output Swing (VSEOS)
6613 (see new Table 129)

6615 Table ###TBD:308 PHY3 (DLV) Conductance Ramp Time

Parameter Symbol Register value Min Typ Max Units

PHYn_RiseFallEnable=0 0.7

0 (optional)AND Enable=1 0.3 0.5 0.8

1 (optional) AND Enable=1 0.6 1 1.7

2 (optional) AND Enable=1 1.3 2.1 3.2

3 (optional) AND Enable=1 1.9 3 4.6

tRF
4 (optional) AND Enable=1 2.5 4 6.1

5 (default) AND Enable=1 3.1 4.9 7.5

6 (optional) AND Enable=1 3.8 5.9 8.9

ns
tR, ramp time 7 (optional) AND Enable=1 4.4 6.9 10

8 (optional) AND Enable=1 5 7.8 12

9 (optional) AND Enable=1 5.6 8.8 13

10 (mandatory) AND
Enable=1 6.2 9.7 15

11 (optional) AND Enable=1 6.8 11 16

12 (optional) AND Enable=1 7.4 12 18

13 (optional) AND Enable=1 8 13 19

14 (optional) AND Enable=1 8.6 14 21

15 (optional) AND Enable=1 9.2 15 22

6616 Note:
6617 DLV PHY is a dual single-ended output, so Ramp Time for is measured individually on each of DP and DN
6618 outputs.

6620 Table ###TBD:307 PHY3 (DLV) Voltage Ramp Time

Settings 0 to 4: Load is 5pF and the driver set 44.5 Ohm impedance, measured single-ended on each of DP and DN
from 20% to 80% of VSEOS or 80% to 20% of VSEOS transition points of the settled measured output signal amplitude.
Settings 5 to 15: load = 30pF
Changing PHY.TR_F register setting shall result in monotonic changes in actual t and t measurements.
R F

This is further bounded by the Dynamic Common Mode requirements.

Settings Units
(PHY3_VRampEnable and
Parameter Symbol Min Typ Max
PHY3_RiseFallTimeVRamp,
see Table 162)

PHYn_RiseFallEnable=0 0.7

0 (optional)AND Enable=1 0.3 0.5 0.8

1 (optional) AND Enable=1 0.6 1.0 1.7

2 (optional) AND Enable=1 1.3 2.1 3.2

3 (optional) AND Enable=1 1.9 3.0 4.6

tRF
4 (optional) AND Enable=1 2.5 4.0 6.1

5 (default) AND Enable=1 3.1 4.9 7.5

Rise and Fall time
6 (optional) AND Enable=1 3.8 5.9 8.9
tR, Rise time
(20% to 80% of 7 (optional) AND Enable=1 4.4 6.9 10
VOD(PP))
or 8 (optional) AND Enable=1 5 7.8 12
tF, Fall time
(80% to 20% of VOD(PP)) 9 (optional) AND Enable=1 5.6 8.8 13

10 (mandatory) AND
Enable=1 6.2 9.7 15

11 (optional) AND Enable=1 6.8 11 16

12 (optional) AND Enable=1 7.4 12 18

13 (optional) AND Enable=1 8 13 19

14 (optional) AND Enable=1 8.6 14 21

15 (optional) AND Enable=1 9.2 15 22 ns

6621 Note:
6622 DLV PHY is a dual single-ended output, so Ramp Time for is measured individually on each of DP and DN
6623 outputs.

6624

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
13 [Draft] Payload Transport
6628 This section describes the Payload Transport Layer used for transporting audio streams in SWI3S.

13.1.1 Introduction to Data Ports

6629 A Data Port has 2 functions:
6630 • It transports the payload data to and/or from the SWI3S bus.
6631 • It provides control and status for the periodic sampling operations that typically reside in an audio function
6632 associated with the data port.
6633 The Data Port Registers include control bits for preparing and enabling Channels and status bits for indicating when
6634 Channels are ready. These are described in Section 13.1.2. The diagrams in Section 13.1.2 illustrate typical
6635 sequences for Prepare, Ready, and Enable signals.

13.1.2 #NEW# Sequences for Prepare, Ready, and Enable

6636 ###Note to Reviewers: Figure 169 through Figure 172 capture the updates to Prepare, Ready, and Enable
6637 from the San Diego FTF. These replace the old whiteboard figures of circuit diagrams, but these are
6638 temnporarily still included here to help with checking (see Figure 167 and Figure 168 below).

6639
Figure 167 #OLD# to be deleted: PortSyncOK

6640
Figure 168 #OLD# to be deleted: PortReady

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
13.1.2.1 Starting a Mic Capture Stream, Enable After Ready
6641 Figure 169 shows the control sequence for starting a Mic Capture Stream when the Host Software waits for the
6642 Peripheral to indicate that the Channels are Ready before enabling them.

Commit #1

Nch × PrepareCh<c>_NEXT

Nch × PrepareCh<c>_CURR

Nch × ReadyCh<c>

Nch × Prepare=ReadyCh<c>

(PortSyncOK=1) AND
PortReady (Nch × (Prepare=ReadyCh<c>) = 11...1111)
IntStat_PortReady

PortSyncOK
Commit #2

Nch × EnableCh<c>_NEXT

Nch × EnableCh<c>_CURR

Bus Data Output from Source DP

Audio Data
6643
Figure 169 Starting a Mic Capture Stream, Enable After Ready
6644 ###TODO-Author: consider whether the following notes should be moved to the description of ReadyCh<c>,
6645 PortReady, etc.
6646 Note:
6647 The blue dotted arrow from PortSyncOK to ReadyCh<c> shows the optional behavior that some devices
6648 (e.g., those with decimating filters) might need PortSyncOK=1 before the ReadyCh<c> inputs can change to
6649 1.
6650 Note:
6651 In some simpler Devices, there are no “prepare” actions, or these are completed instantly, so that
6652 ReadyCh<c> might never be observed as having a different value to PrepareCh<c>. However, even in these
6653 Data Port implementations, there is a notional delay in the ReadyCh<c> input so that there will be a short
6654 time when ReadyCh<c> ≠ PrepareCh<c>, and thus also a short time when PortReady=0 before returning to
6655 1. Thus, a change in the set of channels being Prepared will set the interrupt status for PortReady (and also
6656 for PortNotReady). ###TODO-Author: add one extra diagram showing that a change in the PrepareCh<…>
6657 vector causes both of these interrupts.

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
13.1.2.2 Starting a Mic Capture Stream, Enable Before Ready
6658 Figure 170 shows the control sequence for starting a Mic Capture Stream when the Host Software enables the
6659 Channels before the Peripheral indicates that the Channels are Ready.
6660 This diagram also illustrates that it is an implementation-specific choice exactly what status is indicated by the
6661 individual Channel Ready bits between:
6662 • (black colored traces for ReadyCh<c> etc.): ReadyCh<c>=1 indicates that data output on Channel c
6663 originates from the transducer rather than being artificially generated silence, but is of unknown fidelity, or:
6664 • (purple colored traces for ReadyCh<c> etc.): ReadyCh<c>=1 indicates that data output on Channel c is full
6665 fidelity audio data.
6666 Note:
6667 See also Section ###XREF Recommendation ###XREF (data should be silent

Commit #1

Nch × PrepareCh<c>_NEXT

Nch × PrepareCh<c>_CURR

PortSyncOK Commit #2

Nch × EnableCh<c>_NEXT

Nch × EnableCh<c>_CURR

Bus Data Output from Source DP

Silence Non-final fidelity Audio Data

Nch × ReadyCh<c>

Nch × (Prepare=ReadyCh<c>)

(PortSyncOK=1) AND
PortReady (Nch × (Prepare=ReadyCh<c>) = 11...1111)
IntStat_PortReady

Nch × ReadyCh<c>

Nch × (Prepare=ReadyCh<c>)

(PortSyncOK=1) AND
PortReady (Nch × (Prepare=ReadyCh<c>) = 11...1111)
IntStat_PortReady

Alternate version of Peripheral signals when Ready indicates full-fidelity data

6668
Figure 170 Starting a Mic Capture Stream, Enable Before Ready

13.1.2.3 Starting and Stopping an Amp Render Stream, with Host Fade Out
6669 Figure 171 shows the control sequence for starting and stopping an Amp Render Stream when it is the Host that fades out the signal.

Commit #1 Commit #3

Nch × PrepareCh<c>_NEXT

Nch × PreparecCh<c>_CURR

Nch × ReadyCh<c>

Nch × (Prepare=ReadyCh<c>)
IntStat_PortNotReady
(PortSyncOK=1) AND
PortReady (Nch × (Prepare=ReadyCh<c>) = 11...1111)
IntStat_PortReady IntStat_PortReady

PortSyncOK Host software reaction Host software reaction

after the interrupt after the interrupt
Commit #2
Commit #4

Nch × EnableCh<c>_NEXT

Nch × EnableCh<c>_CURR
Host software reaction after the data
source completes the fade out

Bus Data Input to Sink DP

Audio Data Fade Out Silence

Audio Output from Amp Device

Silence
6670
Figure 171 Starting and Stopping an Amp Render Stream, with Host Fade Out

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
13.1.2.4 Starting and Stopping an Amp Render Stream, with Peripheral Fade Out
6671 Figure 172 shows the control sequence for starting and stopping an Amp Render Stream when it is the Peripheral (Amplifier) that fades out the signal.

Commit #1 Commit #3

Nch × PrepareCh<c>_NEXT

Nch × PrepareCh<c>_CURR

Nch × ReadyCh<c>

Nch × (Prepare=ReadyCh<c>)
IntStat_PortNotReady

(PortSyncOK=1) AND
PortReady (Nch × (Prepare=ReadyCh<c>) = 11...1111)
IntStat_PortReady IntStat_PortReady

Host software reaction

PortSyncOK after the interrupt
Host software reaction
after the interrupt
Commit #2
Commit #4

Nch × EnableCh<c>_NEXT

Nch × EnableCh<c>_CURR

Bus Data Input to Sink DP

Audio Data

Audio Output from Amp Device

Silence Fade Out Silence
6672
Figure 172 Starting and Stopping an Amp Render Stream, with Peripheral Fade Out

6673

13.1.3 Payload Control and Status Bits

13.1.3.1 Data Port PortSyncOK

6674 The Registers for each Data Port include a DPn_PortSyncOK status bit that indicates that the Data Port has successfully synchronized its periodic payload
6675 operations (transport and/or sampling) to an SSP indication from the Manager. It is set to 1 by the first SSP indication on which one or more of the Channel
6676 Prepare and/or Channel Enable bits is equal to 1. It is cleared to 0 when either all channels have both Prepare and Enable bits 0 or when the Peripheral detaches
6677 from the bus (i.e., leaves Link State: Attached.
6678 DPn_PortSyncOK is an input to the DPn_PortReady status bit, and a change in this bit can provoke either the PortReady or PortNotReady interrupt.
6679 ###TODO-Author: maybe add a truth table (or similar) for PortSyncOK.

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
13.1.3.2 Data Port Transport Layer Behavior
6680 Table 138 describes when each channel in the Data Port transports data as a function of register bits:
6681 • DPn_PrepareCh<c>: writable control bit(s) – 1 per Channel.
6682 • DPn_EnableCh<c>: writable control bit(s) – 1 per Channel.
6683 • DPn_PortSyncOK: readable status bit – 1 per Data Port (see Section 13.1.3.1).
6684 Table 138 Data Port Transport Layer Behavior
Conditions Resulting Behavior
Row
Label PrepareCh<c> EnableCh<c> PortSyncOK Are Bits Transported
Description
(1 per Channel) (1 per Channel) (1 per DP) for this Channel?

A 0 0 — No Data Port is Disabled (e.g., clocks stopped)

B 1 0 1 No Data Port is Synchronized to SSPs

C 1 1 1 Yes Channel is Running

Source DP: Channel is Running at the transport layer.

(e.g., a Mic might continue to provide valid data or silence)
D 0 1 1 Yes Sink DP: Channel is Running but winding down.
(e.g., the audio function might fade out the signal received from the
transport layer)

E 1 0 0 No Waiting for SSP (e.g., recovering from Sleep-Wake or re-attaching to bus)

Waiting for SSP

F 1 1 0 No
(does not occur when Manager uses correct programming sequence)

Waiting for SSP

G 0 1 0 No
(does not occur when Manager uses correct programming sequence)

6685 The normal sequence of operations for starting channels is is A-B-C (or just A-C for devices that need zero time for Prepare-to-start).
6686 The normal sequence of operations for stopping channels is C-D-A (or just C-A for devices that need zero time for Prepare-to-stop).
6687 When a Peripheral that was running falls off the bus (or is sent to Sleep) then it changes from C to E.
6688 If the Peripheral re-attaches and sees an SSPA then it changes from E to B. When the Manager sees that the Peripheral is re-attached then it uses an SSCR to
6689 write EnableCh<c>=1 so changes it from B to C (or directly from E to C).
6690
6691 Audio_Ready is approximately “PrepareD”.

# Prepare[ch] Enable[ch] PortSyncOK

Ready[ch] Description
(Channel) (Channel) (Data Port)

A 0 0 X 0 External Circuitry Disabled (e.g., analog circuitry off)

B 0 0 X 1 External Circuitry Changing to Disabled (e.g., voltage regs & refs turning off)

External Circuitry Becoming Ready (e.g. voltage regs & refs ramping up)
C 1 0 0 0
Waiting for SSP (e.g., recovering from Sleep-Wake or re-attaching to bus)

External Circuitry Ready

D 1 0 0 1
Waiting for SSP (e.g., recovering from Sleep-Wake or re-attaching to bus)

E 1 0 1 0 External Circuitry Becoming Ready (e.g. voltage regs & refs ramping up)

F 1 0 1 1 External Circuitry Ready

G 1 1 0 0 No Data Transported – Waiting for SSP

H 1 1 0 1 No Data Transported – Waiting for SSP

External Circuitry Not Ready – Channel Transporting Possibly Invalid Samples

I 1 1 1 0 Note: Source-Sync and Sink-Sync DPs might use this to transmit Tx_Present and
Rx_Request bits to train the payload sense of time.

External Circuitry Ready

J 1 1 1 1 If Channel is transporting (see previous table) then …
Channel Transporting Valid Samples

External Circuitry Changing to Disabled (e.g., ramping amp gain down to zero)
K 0 1 1 1
Channel Transporting Valid Samples

External Circuitry Disabled

Source DP Channel Transporting Silent Samples
L 0 1 1 0
Note: data pattern for “silence” is dependent on the encoding (PCM, PDM, etc.)
Sink DP Channel is Ignoring Samples

External Circuitry Changing to Disabled.

No Data Transported
m 0 1 0 1
Waiting for SSP
(does not occur when Manager uses correct programming sequence)

External Circuitry Disabled (and no data transported)

n 0 1 0 0 Waiting for SSP
(does not occur when Manager uses correct programming sequence)

6693
6694 >>>>>>>>>>>>>>>>>>>>

6695
6696 <<<<<<<<<<<<<<<<<<<

6697 The “normal” sequences of operations are:

6698 start_stream() is: a-e-f-j or a-e-j

6699 1. Initial state is Prepare[ch]=0, Enable[ch]=0, PortSyncOK=0, and Ready[ch]=0. {Row a}.
6700 2. Manager sends an SSCR to write Prepare=1. {Row e}.
6701 A. The SSP implicit in the SSCR command causes PortSyncOK to go to 1.
6702 3. The Peripheral changes to Ready[ch]=1 {Row f} and hence also sets PortReadyIntStat=1.
6703 4. Manager sends an SSCR to write Enable[ch]=1 {Row j}
6704

6705 Insta_start_stream() is: a-i-j or a-j

6706 1. Initial state is Prepare[ch]=0, Enable[ch]=0, PortSyncOK=0, and Ready[ch]=0. {Row a}.
6707 2. Manager sends an SSCR to write Prepare=1 and Enable[ch]=1. {Row i}.
6708 A. The SSP implicit in the SSCR command causes PortSyncOK to go to 1.
6709 3. The Peripheral changes to Ready[ch]=1 {Row j} and hence also sets PortReadyIntStat=1.
6710

6711 stop_stream() is: j-k-L-a or j-k-a

6712 1. Initial state is Prepare[ch]=1, Enable[ch]=1, PortSyncOK=1, and Ready[ch]=1. {Row j}.
6713 2. Manager sends an SSCR to write Prepare=0. {Row k}.
6714 A. PortReadyIntStat in Peripheral changes to 0.
6715 3. The Peripheral changes to Ready[ch]=0 {Row L} and hence also sets PortReadyIntStat=1.
6716 4. Manager sends an SSCR to write Enable[ch]=0 {Row a}
6717

6718 restart_from_sleep() is: j-d-j or j-d-f-j or j-c-f-j or j-c-e-f-j or j-c-i-j or j-c-e-i-j

6719 1. Initial state is Prepare[ch]=1, Enable[ch]=1, PortSyncOK=1, and Ready[ch]=1. {Row j}.
6720 2. The Peripheral falls off the bus or the Manager sends an SSCR to Commit Enter_Sleeping, so
6721 A. The warm reset clears Enable to 0 and PortSyncOK to 0 {Row d}, and
6722 B. The Channel might also go non-ready {Row c}.
6723 3. If the Peripheral was in Sleep then the Manager issues a Warm Start.
6724 4. The Peripheral re-attaches to the bus.
6725 A. PortReadyIntStat in Peripheral changes to 0.
6726 5. If the Data Port receives an SSP then it sets PortSyncOK=1 {Row e or f}
6727 A. If the Channel becomes Ready {Row f} then it sets PortReadyIntStat=1.
6728 6. The Manager sends an SSCR to write Enable=1. {Row i or j}.
6729 A. If Ready[ch] was 0 {Row i} then after some delay, the Peripheral changes to Ready[ch]=1
6730 {Row j} and hence also sets PortReadyIntStat=1.
6731
6732

6733 Table 140 DRAFT: Data Port External Payload Interface Behavior (NORMAL SEQUENCE)

# Prepare[ch] Enable[ch] PortSyncOK

Ext_Ready[ch] Description
(Channel) (Channel) (Data Port)

External Circuitry Disabled

a 0 0 — 0
(e.g., analog circuitry off)

External Circuitry Becoming Ready

e 1 0 1 0
(e.g. voltage regs & refs ramping up)

f 1 0 1 1 External Circuitry Ready

External Circuitry Ready

j 1 1 1 1
Channel Transporting Valid Samples

External Circuitry Changing to Disabled

k 0 1 1 1 (e.g., ramping amp gain down to zero)
Channel Transporting Valid Samples

External Circuitry Disabled

L 0 1 1 0
Channel Transporting Silent Samples

6734

13.1.4 Relation Between Enabling Source DP and Sink DP

6735 Figure 173 illustrates that a Source DP could be enabled earlier than the corresponding Sink DP and/or
6736 disabled after that DP. Any data that is on the bus while Sink DP: EnableCh<c>=0 is ignored by the Sink
6737 DP.

Source DP Enable_Ch<c>

Bus Data consumed

Bus Data
by Sink DP

Sink DP Enable_Ch<c>
6738
Figure 173 Source DP Enabled Before and Disabled After the Sink DP

6739

13.1.5 Example Sequences for Prepare / Ready / Enable

13.1.5.1 Sink DP Example 1

6740 Figure 174 shows an example control sequence for starting a stream to a Sink DP when the Manager waits
6741 for Ready=1 before starting a render stream.

Prepare_Ch<n>

Ready_Ch<n>

Enable_Ch<n>

Bus Data Fed to DP Input

Audio Data
for Channel n
6742
Figure 174 Sink DP: Starting a Stream when the Manager Waits for Ready

13.1.5.2 Sink DP Example 2

6743 Figure 175 shows an example control sequence for a Sink DP when the Manager is stopping an audio
6744 stream and sends audio data until Peripheral Ready=0 indicates that the Peripheral has finished
6745 depreparing.

Prepare_Ch<n>

Ready_Ch<n>

Enable_Ch<n>

Bus Data Fed to DP Input

Audio Data
for Channel n
6746
Figure 175 Sink DP: Stopping a Stream when the Manager Waits for Ready

13.1.5.3 Source DP Example 1

6747 Figure 176 shows an example control sequence for starting a stream from a Source DP when the Manager
6748 waits for Ready=1 before starting a capture stream.

Prepare_Ch<n>

Ready_Ch<n>

Enable_Ch<n>

Bus Data
Audio Data
Output by DP
6749
Figure 176 Source DP: Starting a Stream, Wait for Ready

13.1.5.4 Source DP Example 2

6750 Figure 177 shows an example control sequence for starting a stream from a Source DP when the Manager
6751 starts the capture stream without waiting for Ready=1.

Prepare_Ch<n>

Ready_Ch<n>

Enable_Ch<n>

Bus Data
Output by DP Silence or Audio Data Audio Data
6752
Figure 177 Source DP: Starting a Stream, Without Waiting for Ready

6753

13.1.5.5 Pausing a Stream While Keeping the Channel Prepared

6754 Figure 178 shows an example control sequence for pausing a stream from a Source DP while keeping the
6755 Channels prepared.

Prepare_Ch<n>

Ready_Ch<n>

Enable_Ch<n> Pause Stream with Enable=0

DP Output
Audio Data Audio Data
to Channel n
6756
Figure 178 Source DP: Pausing a Stream

13.1.6 DRAFT: Description of Data Port Algorithm from the Python Visualizer
(Informative)
6757 The following sections are fragments the Python Visualizer program, v1.59:
6758 ###NOTE to Reviewers: two parts of the following are copies of the old v1.40 code but might not be
6759 significantly changed in v1.59.
6760 <###TODO-Author: TEMP: switch to landscape orientation>

13.1.6.1 [v1.59] Visualizer Source Code Fragment: class DataPort

6761 This fragment of code is from a previous version of the tool, and may be out of date
6762 Start of possibly out-of-date code >>>>>>
6763 class DataPort:
6764 def __init__(self):
6765 self.name = 'DP' + str(DataPort.count)
6766 self.number = DataPort.count
6767 self.device_number = 0
6768 # All variables that contain "_REG" correspond registers in the specification.
6769 # Where coding is unnatural, _X1 is suffixed to draw attention.
6770 # Example when the sample width is equal to 1 bit, sample_width_REG_X1 == 0.
6771 self.channels_REG = 1
6772 self.channel_grouping_REG = 0
6773 self.channel_group_spacing_REG = 0
6774 self.sample_width_REG = 1
6775 self.sample_grouping_REG = 1
6776 self.interval_REG = 1
6777 self.skipping_numerator_REG = 0
6778 self.offset_REG = 0
6779 self.h_start_REG = 4
6780 self.h_count_REG = 0
6781 self.tail_width_REG = 0
6782 self.bit_width_REG = 0
6783 self.source_REG = True
6784 self.handover = False
6785 self.tail_REG = False
6786 self.guard_REG = False
6787 self.sri_REG = False
6788
6789 <<<<<<< end of possibly out-of-date code.
6790
6791
6792 # The following variables are used for modeling with this tool and do not relate to actual implementation.
6793 self.enabled = False
6794 self.inManager = False
6795 self.sample_rate = 0
6796

6797 # The following variables might correpond closely to a real implementation

6798 self.current_offset_in_interval = -1
6799 self.current_channel = 0
6800 self.current_sample_index = 0
6801 self.samples_remaining_in_sample_group = 0
6802 self.accumulated_fraction = 0
6803 self.tails_left = 0
6804 self.guards_left = 0
6805 self.channel_group_is_spacing = 0
6806
6807 # effect_channel_grouping is a helper variable that is calculated from channel_grouping_REG and channels_REG
6808 self.effective_channel_group = 0
6809
6810 # These two variables are used for channel grouping. Simpler implementations might exist.
6811 self.channel_group_end = 0
6812 self.channel_group_base = 0
6813
6814 # The following variables are use for housekeeping
6815 # and error checking in this tools and would likely not exist in real implementations
6816 self.done_with_interval = False
6817 self.last_column_evaluated = -1
6818 self.last_row_evaluated = -1
6819 self.end_of_row = False
6820 self.started = False
6821 DataPort.count += 1

13.1.6.2 [v1.59] Visualizer Source Code Fragment: For Each Data Port
6822 # This is run for each DataPort.
6823 # Raster our frame
6824
6825 started = False
6826 Row = 0
6827 frac_accum = 0 # accumlate to decide when to skip this transport opportunity
6828 interval_counter = 0
6829 end_of_interval = False
6830
6831 if data_port.channel_grouping_REG == 0 or data_port.channel_grouping_REG > ( data_port.channels_REG + 1 ): # NDW check or
6832 data_port.sri_REG:
6833 effective_channel_group = data_port.channels_REG + 1

6834 else:
6835 effective_channel_group = data_port.channel_grouping_REG
6836
6837 data_port.reset()
6838
6839 # Row counter is not part of the needed data port mechanism but is to support drawing
6840 for row_counter in range( 0, self.rows_in_frame, 1 ) :
6841 Row += 1
6842 data_port.new_row( row_counter, self.interface.skipping_denominator_REG )
6843
6844
6845 last_bit_was_driven = 0
6846 column_counter = 0
6847 while column_counter < self.interface.columns_per_row :
6848 width, rrrr, sample_number_in_group = data_port.try_bit( row_counter, column_counter,
6849 self.interface.skipping_denominator_REG )
6850 if NOT_OWNED == rrrr :
6851 rrrr = data_port.get_guard_or_tails()
6852 if NOT_OWNED == rrrr :
6853 if last_bit_was_driven :
6854 if data_port.source_REG and data_port.handover :
6855 self.draw_handover( row_counter, column_counter, data_port.device_number)
6856 self.update_col_in_frame_model(row_counter, column_counter, data_port.number,
6857 data_port.source_REG, 0, 'HANDOVER', sample_number_in_group)
6858 last_bit_was_driven = False
6859 elif "tail" == rrrr :
6860 self.draw_tail( row_counter, column_counter, data_port.device_number, color )
6861 self.update_col_in_frame_model(row_counter, column_counter, data_port.number, data_port.source_REG,
6862 width, rrrr, 0 )
6863 last_bit_was_driven = True
6864 elif 'G' == rrrr :
6865 self.write_bit_slot( row_counter, column_counter, width, data_port.source_REG, rrrr, color,
6866 data_port.number ) #, data_port.sample_grouping_REG - data_port.samples_remaining_in_sample_group, data_port.current_channel,
6867 data_port.current_bit_in_sample )
6868 self.update_col_in_frame_model(row_counter, column_counter, data_port.number, data_port.source_REG,
6869 width, rrrr, 0)
6870 last_bit_was_driven = True
6871 else :
6872 error()

6873 else :
6874 self.write_bit_slot( row_counter, column_counter, width, data_port.source_REG, rrrr, color,
6875 data_port.number)
6876 self.update_col_in_frame_model(row_counter, column_counter, data_port.number, data_port.source_REG,
6877 width, rrrr, sample_number_in_group)
6878 last_bit_was_driven = True
6879 data_port.set_guards_and_tails() # A bit is owned so
6880 if data_port.source_REG:
6881 self.check_bus_clash(row_counter, column_counter, data_port.device_number, 'write')
6882 else:
6883 self.check_bus_clash(row_counter, column_counter, data_port.device_number, 'read')
6884 column_counter += width + 1

13.1.6.3 [v1.59] Visualizer Source Code Fragment: Helper Function: Reset

6885 This fragment of code is from a previous version of the tool, and may be out of date
6886 Start of possibly out-of-date code >>>>>>
6887 # These values are chosen mostly due to artifacts of this tool.
6888 def reset( self ):
6889 self.current_offset_in_interval = -1
6890 self.last_row_evaluated = -1
6891 self.started = False
6892 self.done_with_interval = False
6893 self.end_of_row = False
6894 # these two should move to the device
6895 self.tails_left = 0
6896
6897 self.guards_left = False
6898 print( "dataport reset called" )
6899 <<<<<<< end of possibly out-of-date code.
6900

13.1.6.4 [v1.59] Visualizer Source Code Fragment: Helper Function: startInterval

6901 # The initial values might be quite different in a real implementation.
6902 # These values are chosen mostly due to artifacts of this tool.
6903 # This sequence is done both when the port is enabled or when the port is prepared.
6904 def reset( self ):
6905 self.current_offset_in_interval = -1
6906 self.last_row_evaluated = -1
6907 self.started = False
6908 self.done_with_interval = False
6909 self.end_of_row = False
6910 # these two should move to the device
6911 self.tails_left = 0
6912 self.guards_left = False
6913 self.accumulated_fraction = 0
6914
6915 def startInterval( self ) :
6916 self.samples_remaining_in_sample_group = self.sample_grouping_REG
6917 self.channel_group_base = 0 # Like current_channel, starts at 0
6918 self.current_channel = 0

6919 if self.channel_grouping_REG == 0 or self.channel_grouping_REG > self.channels_REG : # or self.sri_REG:

6920 self.effective_channel_grouping = self.channels_REG + 1
6921 else:
6922 self.effective_channel_grouping = self.channel_grouping_REG
6923 # effective_channel_grouping is an intermediate variable for clarity
6924 self.channel_group_end = self.effective_channel_grouping
6925 # as soon as (just after last bit in sample) the current channel gets here, it is time for spacing.
6926
6927 self.current_bit_in_sample = self.sample_width_REG
6928 # TODO: this is where a call to fetch SampleGroup * Channels of audio from the file to playing out.

13.1.6.5 [v1.59] Visualizer Source Code Fragment: Data Port Behavior per UI
6929
6930 # This is called for each possible column that could start a bit (or wide bit). This is not called more than once per data
6931 bit.
6932 # try_bit returns a tuple containing
6933 # 1. the width (integer) of the "bit" (how many UIs) and
6934 # 2. the value to drive (a string coding ownership or the bit address withing the sample frames)
6935 def try_bit( self, row_number, column_number, denominator_REG ) :
6936 ret_value = 'error'
6937
6938
6939 if ( self.end_of_row or self.done_with_interval ) :
6940 return 0, NOT_OWNED, 0 # self.drive_guards_and_tails()
6941
6942 if self.last_column_evaluated == column_number :
6943 raise ValueError ( "This column was already evaluated " )
6944 self.last_column_evaluated = column_number
6945
6946 if self.started :
6947 # Rendering of bits starts when the column gets to horizontal_start
6948 if column_number == self.horizontal_start_REG :
6949 self.done_with_row = False
6950 if column_number < self.horizontal_start_REG :
6951 return 0, NOT_OWNED, 0
6952 if self.done_with_row or self.done_with_interval :
6953 return 0, NOT_OWNED, 0 # self.drive_guards_and_tails()
6954
6955 # Are we past the end of the row?

6956 elif column_number > self.horizontal_start_REG + self.horizontal_count_REG :

6957 self.done_with_row = True
6958 self.channel_group_is_spacing = 0;
6959 if self.sri_REG :
6960 self.started = False
6961 self.done_with_interval = True
6962 self.end_of_row = True
6963 return 0, NOT_OWNED, 0 # self.drive_guards_and_tails()
6964
6965 else : # In between HSTART and ( HSTART + HCOUNT ), inclusive.
6966 sample_number_in_group = self.sample_grouping_REG - self.samples_remaining_in_sample_group
6967 if self.channel_group_is_spacing > 0 :
6968 self.channel_group_is_spacing -= 1
6969 return 0, NOT_OWNED, 0 # self.drive_guards_and_tails()
6970
6971 # last_value_sent would be this value of this return <--- what the heck does this mean?
6972 else : # done with any bit widening
6973 if ( self.current_bit_in_sample >= 0 ) :
6974 ret_value = 'c' + str( self.current_channel ) + 'b' + str( self.current_bit_in_sample )
6975 self.current_bit_in_sample -= 1
6976 # ??? last_value_sent would be this value of this return
6977 if self.current_bit_in_sample < 0 :
6978 # Done will all bits in the current sample. Go to the next channel or frame
6979 self.current_channel += 1
6980 if self.channel_group_end <= self.current_channel : # are we at the end of the channel group
6981 self.samples_remaining_in_sample_group -= 1
6982 if 0 > self.samples_remaining_in_sample_group : # done with sample group ?
6983 if self.channel_group_end >= self.channels_REG + 1 : # Done with all channel groups
6984 if not self.sri_REG :
6985 self.done_with_interval = True
6986 self.end_of_row = True # NDW change for SRI
6987 self.started = False
6988 else :
6989 self.channel_group_is_spacing = self.channel_group_spacing_REG
6990 self.startInterval()
6991
6992 else : # we are not at the last channel and so need to go to the next channel group.
6993 self.channel_group_base += self.effective_channel_grouping
6994 self.channel_group_end += self.effective_channel_grouping

6995 # clip when last group of channels is smaller

6996 if self.channel_group_end > self.channels_REG :
6997 self.channel_group_end = self.channels_REG + 1
6998 # reset sample group counter
6999 self.samples_remaining_in_sample_group = self.sample_grouping_REG
7000 self.current_bit_in_sample = self.sample_width_REG
7001 self.channel_group_is_spacing = self.channel_group_spacing_REG
7002 if 0 == self.channel_group_spacing_REG : # 0 means next row.
7003 self.end_of_row = True
7004 else : # 1 for spacing means next column
7005 self.channel_group_is_spacing -= 1
7006 else : # continue with current group of channels starting at the first channel in the group
7007 self.current_bit_in_sample = self.sample_width_REG
7008 self.current_channel = self.channel_group_base
7009 else : # not the end of the channel group just go to the next channel
7010 self.current_bit_in_sample = self.sample_width_REG
7011 # TODO: This is where the output shift register would get loaded with a new sample
7012
7013
7014 else:
7015 ret_value = NOT_OWNED
7016
7017 if ( self.sri_REG ) :
7018 if ( column_number == self.horizontal_start_REG + self.horizontal_count_REG ) :
7019 # for SRI, these variable need to be reset so that things start the same each row.
7020 self.started = False
7021 self.done_with_interval = True
7022 self.end_of_row = True # NDW change for SRI???
7023 sample_number_in_group = self.sample_grouping_REG - self.samples_remaining_in_sample_group
7024 return self.bit_width_REG, ret_value, sample_number_in_group
7025
7026
7027 def new_row( self, row_number, denominator_REG ) :
7028 ret_value = 'error'
7029 if self.sri_REG :
7030 self.startInterval()
7031 self.end_of_row = False
7032 self.started = True
7033 self.done_with_interval = False

7034 self.channel_group_is_spacing = 0
7035 ret_value = 'started'
7036 else :
7037 self.last_row_evaluated = row_number
7038 self.last_column_evaluatted = -1
7039 self.end_of_row = False
7040 self.current_offset_in_interval += 1
7041 # Current_offset_in_interval should be 0 anytime an SSP occurs
7042 # and is reset when channels are enabled or prepared.
7043
7044 if self.current_offset_in_interval == ( self.interval_REG + 1 ) :
7045 self.current_offset_in_interval = 0
7046 self.done_with_interval = False
7047 if self.current_offset_in_interval == self.offset_REG:
7048 # These lines are for the optional skipping feature
7049 if ( self.skipping_numerator_REG != 0 ) :
7050 self.accumulated_fraction += self.skipping_numerator_REG
7051 if self.accumulated_fraction >= denominator_REG : # comment about skipping.
7052 self.done_with_interval = True
7053 self.accumulated_fraction -= denominator_REG
7054 ret_value = 'skipping'
7055 return
7056
7057
7058 self.started = True
7059 self.startInterval()
7060 ret_value = 'starting'
7061 return ret_value
7062
7063 <###TODO-Author: TEMP Note: switch to portrait orientation>

7064

13.1.7 Payload Data Scrambling

7065 ###TODO-Author: add a description of payload data scrambling. Scrambling and descrambling is
7066 per-channel; this allows for scatter/gather such as:
7067 • 1 × N-channel source DP in the Manager to N different peripherals with 1-channel sink DPs.
7068 • N × 1-channel source DPs from N different peripherals to 1 × N-channel sink DP in the Manager.
7069
7070 FTF-decision-20220308
7071 See “Self-Synchronizing No-Toggle Detecting Scrambler/Descrambler” in figures 3 & 4 in “Rod’s
7072 document”, Self-Synchronizing Scrambler_Descrambler v1.1.pdf.
7073 Filename: Self-synchronizing Scrambler_Descrambler v1.1.pdf
7074 https://members.mipi.org/wg/Audio-WG/document/89540
7075
7076
7077 ###NOTE to author: remember to specify these points about the scrambling:
7078 • In both Source DP and Sink DP, the scrambler LFSR for channel x is initialized to a defined value
7079 by the action of changing EnableCh<c> from 0 to 1. [reconfirmed in AudioWG on 13 June 2023.]
7080 • In the Sink DP, after any errors the LFSR is self-synchronizing after N (8 or 9?) bits, so that there
7081 can be a small error amplification.
7082 • Define the starting value of the scrambler circuit. Davide suggests that the referenced documents
7083 mention 2 alternatives: 010101010 and 101010101. No. see new reset value below.
7084
7085 ###NOTE to author: 20231018 AudioWG FTF Osaka: note that the minutes from 1 August 2023 confirmed
7086 that the reset value is 101010100, and includes a circuit picture.
7087

13.1.8 Flow Controlled Transport

7088 ###Note to Reviewers: For more detail about flow control, see the presentation at:
7089 https://members.mipi.org/wg/Audio-WG/document/86770
7090 ###TODO-Author: pictures and text to expand on the following bullet point description
7091 In any mode except for “Normal”:
7092 • DataValid bit attached to every sample in every channel.
7093
7094 4 modes:
7095 • 0: Normal flow (“bus synchronous”)
7096 • 1: Source-controlled (aka “source synchronous”): the source decides which transport opportunities
7097 are used.
7098 • 2: Sink-controlled (aka “sink synchronous”): when-and-only-when the sink requests data
7099 (DRQ=1), the source SHALL set the DataValid bit in the next[*] transport opportunity.
7100 • 3: Sink-Source-controlled (“fully flow controlled”): when-and-only-when the sink makes requests
7101 (DRQ=1), the source MAY set the DataValid bit in the next[*] transport opportunity.
7102 [*] “next” transport opportunity can be next-but-one, selected by the 1-bit FlowControlDelay field in
7103 the DP Registers.
7104

7105 When starting up in FlowMode 2 or 3, the Source assumes that it received 1 (or 2) DRQ bits with value 1
7106 prior to the channel starting, so that the first 1 (or 2) samples can contain DataValid=1, and real data
7107 samples.
7108 Note: the number of these phantom DRQ bits (1 or 2) is dependent upon the value of FlowModeDelay (0 or
7109 1).
7110 Note2: if adding channels on the fly then … be careful :-)
7111
7112 There are 3 kinds of Flow Control error, reported in error counter EC_FlowControlError and signaled in
7113 IntStat_FlowControlError:
7114 • (applies to any of Source-controlled, Sink-controlled, or Sink-Source-controlled modes): if the
7115 DataValid flags in all of the active channels are not identical.
7116 • (applies to Sink-controlled mode): if DRQ=1 and DataValid=0.
7117 • (applies to Sink-Source-controlled mode): if DRQ=0 and DataValid=1.
7118
7119 TODO: give some examples of when flow-controlled transport might be used:
7120 • A Data Port attached to an audio application that uses a sample clock that is asynchronous to the
7121 SWI3S bus clock (e.g., from a local crystal or a radio interface).
7122
7123 RULES:
7124 A Source DP shall use the same value of DataValid bits for all Channels of a Sample Frame.
7125 A Source DP may use a different value of DataValid bits for each of the Sample Frames within a Sample
7126 Group.
7127 When a Source DP transmits DataValid=0, it should transmit a data value of all zeroes in the corresponding
7128 samples. ###TODO-Author: AudioWG on 20240130 decided that the data value bits are NOT driven if
7129 DataValid=0.
7130 When a Sink DP receives DataValid=0, it should ignore the data value in the corresponding samples (apart
7131 from feeding all the bits from both DataValid and the samples through the descrambler). ###TODO-
7132 Author: AudioWG on 20240130 these bits are NOT fed to the scrambler.
7133

13.1.9 Programming Errors

7134 Software controlling the Manager is responsible for programming a consistent set of values in transport
7135 registers. Typical Peripheral devices do not include extra logic for detecting errors or resolving conflicts,
7136 such as Data Ports clashing with other Data Ports, the Control Data Stream, or the Row Sync Sequence.
7137 These conflicts could corrupt the Control Data Stream or Row synchronization, causing the bus to crash.
7138 Typical Host / Manager control software might use fixed patterns of payload transport that have been
7139 checked during the system debug phase. More sophisticated system debug software might include dynamic
7140 assertions for verifying the self-consistency of transport parameters.

13.1.10 Known TO-DO Items

7141 ###TODO-Author: For Sample Grouping we decided that for a sample width of 1 bit -> 8 samples
7142 of grouping are required. 2 bits -> 4 samples, 3 bits -> 3 samples, 4 bits -> 2 samples, 5 bits -> 2
7143 samples, 6 -> 2 samples, 7 -> 2 samples.
7144

13.1.11 Previous Draft Material …

7145 ###Note to Reviewers: this draft section contains notes based on the payload transport proposals
7146 embodied in the SWI3S Payload Visualizer Python program. This material will be expanded in a
7147 future draft.
7148
7149 Topics to be included in this section:
7150
7151 There are 3 bits in the DP registers for each Channel:
7152 • RW: Prepare
7153 • RW: Enable
7154 • RO: Ready.
7155 Writing Prepare==1 initializes all the transport counters & SWI3S FIFOs & also synchronizes the sample
7156 clock:
7157 • this is done using an SSCR (Stream Synchronous Commit Request) to align with the SSP.
7158 • In some designs it also enables analog circuits such as voltage references, or charge pumps.
7159
7160 Writing Enable==1 is the gate for data flow to/from the bus (but also reissues an SSP to the counter).
7161 • In a Source DP: Enable==0 means that the Data Port does not drive any data onto the bus. The
7162 Data Port accepts data at the programmed sample interval and merely discards it. If Enable is set
7163 to 1 before Ready==1 then the data delivered to the bus might be internally synthesized data (e.g.,
7164 silence, zeroes, garbage) rather than audio data.
7165 • In a Sink DP: Enable affects only what data values are fed to the circuit that consumes the samples
7166 (e.g., a DAC). Enable==1 feeds bus data. Enable==0 feeds an ImpDef internal stream (e.g.,
7167 “silence”, all zeroes, …).
7168 • This is done with an SSCR that is synchronous to the SSP.
7169 • It can be done with the same SSCR that sets Prepare==1.
7170 • Writing Enable==1 does NOT have to wait for Ready==1.
7171
7172 Meaning of Ready bit:
7173 • In a Source Data Port: Reading Ready==1 indicates that the data on the link will be audio data.
7174 • In a Sink Data Port: Reading Ready==1 indicates that (if Enable==1) then the circuit consuming
7175 data from the Sink Data port (e.g., a DAC) would render audio;
7176 reading ready==0 indicates that the signal path to the output is not ready to consume data.
7177 (Warning: if Enable is 1 while Ready==0 then when Ready later changes from 0 to 1 there could
7178 be audio artifacts).
7179
7180 The following detail belongs in the Payload Chapter, not the Register Chapter.
7181 Ready Ch<c>=1 => the audio circuit outside the SWI3S interface is ready to generate or consume valid
7182 audio samples.
7183 Ready Ch<c>=0 => the audio circuit outside the SWI3S interface is not ready to generate or consume valid
7184 audio samples (so a Source DP might produce invalid data or silence).
7185
7186 DRAFT Rules:
7187 1. When the Manager intends to change a Prepare Ch<c>_CURR bit from 0 to 1, it shall:
7188 A. Write Prepare Ch<c>_NEXT=1, and then:

7189 B. Issue an SSCR Command to commit the 1 to the _CURR register.

7190 2. When the Manager intends to change an Enable Ch<c>_CURR from 0 to 1, it should:
7191 A. Write Enable Ch<c>_NEXT=1, and then:
7192 B. Issue an SSCR Command to commit the 1 to the _Current register.
7193
7194 ###TODO-Author: enact the following WG decision from 6 March 2024 in Vienna:
7195 QUESTION Q220: How does Link Management interact with Channel Prepare, Enable, and Ready?
7196 Going to Sleep (or Cold reset) will change Enable to 0, but will NOT change Prepare. Waking from Sleep
7197 might result in Ready==0. The condition of Ready=1 might not occur until some time after the first SSP
7198 indication received by the Peripheral (i.e., SSPA or SSCR Commands), which causes PortSyncOK=1.
7199 Software would typically use a subsequent SSCR to Commit Enable Ch<c>==1.
7200 Cold Reset clears Enable==0 and Prepare==0 (and hence also Ready==0).
7201 ANSWER: “Ready can go ready after the appropriate amount of time but might not if the device needs
7202 synchronization information. Many device will need to see an SSPA (or workalike) before they will go
7203 ready. Some can just go ready.”
7204

7205 TEMP: Links to presentations:

7206 ###TODO-Author: remove/update this section at some point in time.
7207 Link to SWN Visualizer Python program when it has been uploaded.
7208 Visualizer folder for data files:
7209 Visualizer folder in Contributor WG: https://members.mipi.org/wg/Contributors/document/folder/13007
7210 Visualizer v1.19 (Python code): https://members.mipi.org/wg/Contributors/document/85852
7211 Visualizer data files: https://members.mipi.org/wg/Contributors/document/folder/14349
7212
7213
7214 ###TODO-Author: migrate these notes into the nice-to-have for v1.1 archive.

13.1.11.1 DRAFT: New Terminology that might be deployed, or repurposed for Data
Ports
7215 • A DataSlot is an opportunity to transport information that has a duration that can be programmed
7216 to be N (1 to 8) UIs. [###TODO: add somewhere: The TX drive for the last DataSlot in a group
7217 can be terminated half a UI early].
7218 • A Wide DataSlot is a special case of a DataSlot, when it has a duration longer than the “standard”
7219 1 UI.
7220 • A Bit is 1 bit of information (a 0 or a 1) transported by the PHY in 1 DataSlot.
7221 • A Wide Bit is a special case of a Bit, when it is transported in (N>1) UIs, i.e., a Wide DataSlot.
7222 • Transport parameters for HorizontalStart, HorizontalCount, BitWidth, and TailWidth are
7223 programmed in UIs (i.e., columns).
7224 • The transport parameter for sample size is programmed in “Bits”, which might be Wide Bits.
7225 • Sample grouping is counted in number of Sample Frames (register value of 0 => 1 Sample
7226 Frame?)
7227 • Channel grouping is counted in number of channels (register value of 0 => 1 channel)

7228 • A PHY Control conceptual signal, EndHalfEarly, which facilitates the active drive of the last Bit
7229 owned by a Manager or Peripheral ending on mid-UI boundary that is half a column before the
7230 end of the allocated UI(s).
7231
7232
7233
7234 Transport Period: 10.33/10.33/10.33 The periods in which one or more Samples are transmitted.
7235 Transport Interval: 11/10/10 The periods in which one or more Samples are transmitted.
7236 Period_Integer
7237 Period_Numerator
7238 Period_Denominator
7239 Sample Period = Transport Period / Sample Grouping
7240
7241 10.33/10.33/10.33
7242 Word#1: 11/10/10
7243 Word#1: 24/24/24
7244

13.1.11.2 Sample Interval concepts

7245 ###TODO: update this to describe skipping intervals in place of fractional intervals.
7246
7247 Row-based with skipping ...
7248 • Sample Clocks are derived from Row Start events (in the DLV PHY this is the S0 to S1 transition).
7249 • In typical cases the Sample Interval is an integer multiple of the Row Interval (including 1x for
7250 having a sample in every Row).
7251 • Some less trivial cases can be addressed by using a PLL to generate a Sample Rate from the
7252 periodic Row Start Events using a P/Q multiplier.
7253 • The Skipping Accumulator uses a 10-bit Denominator, so allows for typical values such as
7254 {12, 16, 18, 147, 160, 192} and a Numerator between 1 and the Denominator–1.
7255 …
7256 ###TODO: include 2 examples:
7257 • 44.1 kSamples/s on 3.072 MRows/sec ().
7258 • 48 kSamples/s on 3MRows/s (Transport Interval = 62.5 Rows).

13.1.11.3 Payload Transport Definitions

7259 Payload Transport in SWI3S is Row-based: data bits are transported in sequence within allocated UIs
7260 within some Rows.
7261 Some definitions:
7262 • A Channel Sample is <Sample_Size> number of data bits. (or a “Sample”).
7263 • A Sample Frame is a set of one Channel Sample from each of <Active_Channel_Count> number
7264 of Channels (i.e., <Active_Channel_Count> x <Sample_Size> bits).
7265 • A Sample Group is a set of <Sample_Group_Count> Sample Frames.
7266

7267 • A Channel Group is a sequence of <Channel_Group_Count> of the active Channels (e.g. 2 of the
7268 6 active Channels).
7269
7270 • A Channel Group Sub-Frame [name-TBD] is a sequence of one Channel Sample from each
7271 Channel within one Channel Group (i.e., <Channel_Group_Count> x <Sample_Size> bits).
7272 • A Sample Group Sub-Frame is a sequence of <Sample_Group_Count> Channel Group
7273 Sub-Frames (i.e., <Sample_Group_Count> x <Channel_Group_Count> x <Sample_Size> bits).
7274 • A Sample Group Frame is a sequence of one Sample Group Sub-Frame from each Channel
7275 Group (i.e., (<Active_Channel_Count>/<Channel_Group_Count>) x <Sample_Group_Count> x
7276 <Channel_Group_Count> x <Sample_Size> bits).
7277 Note: This is the same Channel Sample bits as <Sample_Group_Count> Sample Frames, but
7278 arranged in a different sequence.
7279
7280 Fan in:
7281 Rx: 12*34*56*78
7282 Tx1: 12---------
7283 Tx2: ---34------
7284 Tx3: ------56---
7285 Tx4: ---------78
7286
7287 Fan out:
7288 Tx: 12345678
7289 Rx1: 12------
7290 Rx2: --34----
7291 Rx3: ----56--
7292 Rx4: ------78
7293
7294 Niel:
7295 Fan-IN from 1-bit PDM Mics is common.
7296 Fan-OUT is better illustrated on a multi-channel PCM stream.
7297
7298 Remember that when picking off 1 channel from an n-channel sream, the Sink DP will take the first bit
7299 from Column HStrat, so the TX might need to use Channel Group Spacing==0 to start the new chnannel in
7300 column HorizontalStart.
7301
7302 ###TODO: need to add Wide Bits into these rules.
7303
7304 Sequence of data bits:
7305 1. Bits from one Sample Group Sub-Frame are packed into BitSlots from HSTART to (HSTART +
7306 HCOUNT) in adjacent Rows:
7307 A. Bits within one Channel Sample (MSb first).
7308 B. Channel Samples from one Channel Group Sub-Frame, i.e., <Channel_Group_Count>
7309 number of Channel Samples
7310 C. Channel Group Sub-Frames from one Sample Group Sub-Frame, i.e.,
7311 <Sample_Group_Count> number of Channel Samples from each Channel within that Channel
7312 Group.

7313 2. The Data Port skips past up to (<Channel Group Spacing> –1) number of BitSlots within the
7314 current Row.
7315 A. If the <Channel_Group_Spacing> is 0 then the Data Port starts the next Sample Group
7316 Sub-Frame in the HSTART column in the next Row, otherwise:
7317 B. If skipping the specified number of BitSlots would exceed the (HSTART + HCOUNT)
7318 Column then the Data Port starts the next Sample Group Sub-Frame in the HSTART column
7319 in the next Row, otherwise:
7320 C. (skipping the specified number of BitSlots will not exceed the (HSTART + HCOUNT)
7321 Column, so) the Data Port starts the next Sample Group Sub-Frame at the resulting BitSlot
7322 within the current Row.
7323 3. Sample Group Sub-Frames from subsequent Channel Groups, in the sequence specified in
7324 steps 1 & 2.
7325 4. After the complete Sample Group Frame, the Data Port calculates the number of Rows to be
7326 skipped from the Row_Interval. [###TODO-Author: correction: the interval is the period from the
7327 start of one Sample Group to the start of the next Sample Group, and should be called “Transport
7328 Interval”].
7329 A. If (Row_Interval==0) the Data Port will use the immediately following Row, otherwise:
7330 B. …
7331
7332 ###TODO: check that the rules are aligned with:
7333 • Bits in one sample
7334 • Then channels up to channel grouping
7335 • Then samples up to sample grouping
7336 • Then insert Channel Group Spacing number of columns
7337
7338 Channel Grouping is for fan in.
7339
7340

13.1.11.4 Transport Parameters

7341
7342 Table 141 #Draft Transport Parameters

TEMP: TEMP: Range Description

Name in Spec Name in Python
BitFitter Tool

Channel_Count — 1 to 16? Number of Channels in Data

Port

— Channels 0x0000 – 0xFFFF BitMask of active channels in

Data Port

Sample_Size Sample Width 1 – 64 number of bits in one sample

Channel_Group_Count Channel 0 / 1 – 16 ?
Grouping

TEMP: TEMP: Range Description

Name in Spec Name in Python
BitFitter Tool

Channel_Group_Spacing Channel Group

Spacing

7343

13.1.11.5 #WIP: Data Port Direction

7344 Data Ports operate as either producers (Source Data Ports) or consumers (Sink Data Ports) of data
7345 transported by SWI3S. Fixed direction Data Ports always operate in the same direction. Configurable
7346 direction Data Ports can operate in either direction, but the direction does not change while the port is
7347 active.
7348 This data direction is controlled and/or indicated by the PortDirection field in the ###XREF Register (see
7349 ###XREF). In fixed direction Data Ports this field is read only.
7350 b0: Source Data Port
7351 b1: Sink Data Port
7352 ###TODO-Author: add an input to the OR-gate that is (Something_is_enabled OR prepared) AND
7353 ((SRI_CURR=1) OR (Interval_CURR=0)). Note that the first OR gate in this list already exists as the 2
7354 OR-gates in the bottom left of this figure.
7355
7356
7357 # #
7358 # #
7359
7360

13.1.12 #DRAFT MAC Layer Rules

7361

13.1.12.1 Corner Case #1: How to combine Tail Enables from multiple DPs within the
same Peripheral?
7362 ###TODO-Author: turn the following discussion in to an illustrative example.
7363 ###TODO-Python-Author: check what the tool does when DPs are prgrammed like this. Are there any
7364 assertions that warn about unexpected combinations of parameters between multiple Data Ports?
7365 E.g., DP1 has 4 Tail bits in every Row.
7366 In some of the Rows, DP2 takes over immediately after DP1.

7367 What happens if DP2 ends its data while there are still tail bits outstanding for DP1?
7368 It's not useful to change the bus back to the echo of a long forgotten DP1 bit, but does DP1’s request for a
7369 Tail cause DP2’s value to be driven out until the end of DP1’s Tail-request?
7370 AudioWG FTF Vienna March 2024: Simplest & most natural is that the MAC layer simply ORs together
7371 the tail enables from all Data Ports and then, IF there are no data requests from any Data Port, plays out a
7372 copy of whatever it drove in the previous bit clock period.
7373
7374

13.1.13 DRAFT: Payload Transport with Interval Skipping

7375 The Transport Interval in the Data Port is programmed with a transport rate that is faster than the actual
7376 sample rate, e.g., 48 kHz Transport Intervals can be used to transport a stream at 44.1 kSamples/s.
7377 Two variables, N and D, are programmed to instruct the Data Port that N out of every D intervals are to be
7378 “skipped”. Eg., for 44.1/48, one set of values that would work is N=13, D=160 which means that 13/160
7379 intervals are skipped and 147/160 intervals will contain payload data.
7380 The algorithm is the same in both Source and Sink Data Ports, so that they agree on which intervals
7381 actually contain transported data. The counting algorithm distributes the skipped intervals as evenly as
7382 possible, so that the number of consecutive intervals that are used will always be either k or k+1. When N
7383 is ≥ D/2, there will always be exactly 1 interval skipped. The number of samples in the Sink DP FIFO will
7384 vary as the sequence progresses, and starts in its “most empty” condition, and the algorithm starts at the
7385 point in the sequence that has the longest run of “k+1”s.
7386 Note:
7387 See the Python Code relating to the numerator in Section 13.1.6.
7388 Note:
7389 The transport behavior of the Data Port supports all values of numerator (for test patterns) but
7390 typically the audio sample clock generation will only work for some particular values.

13.1.14 #SPARE Payload Transport Examples

13.1.14.1 ###WIP Example Traffic Pattern: Fan In

7391
7392 ###TODO: explain what fan in and fan out mean and that the DPs understand spacing around handovers.
7393
7394

13.1.14.2 ### Subsection

7395
7396 Sample Interval is used for spacing across multiple Rows, with optional Fractional Sample Interval
7397 (numerator and denominator) for Sample Intervals that are not an integer number of rows. These provide
7398 flexibility in the relationship between Sample Rates and Row Rates.
7399 E.g., Sample Interval of 64 Rows at 3.072 MRows/sec to give 48 kSamples/sec.
7400 E.g., Sample Interval of 69 Rows, Numerator=97, Denominator=147 at 3.072 MRows/sec to give a pattern
7401 that alternates between 69 Rows and 70 Rows and has an average transport rate that matches a stream
7402 sample rate of 44.1 kSamples/sec.
7403

13.1.14.3 ### Subsection

7404
7405 Channel Grouping and Channel Group Spacing: help with fan in from multi-channel Peripherals to the
7406 Manager.
7407 E.g., I- and V-sense streams from each of 4 amplifiers being collated into a single 8-channel Sink Data Port
7408 in the Manager.
7409 i1 – v1 – HO – i2 – v2 – HO – i3 – v3 – HO – i4 – v4
7410 ch1 ch2 ch3 ch4 ch5 ch6 ch7 ch8

7411 Sample Width = 1

7412
7413 E.g., Grouping 4 PDM mics into a single 4-channel Sink Data Port in the Manager.
7414
7415 E.g., each of 4 PDM microphones sending a group of 8 samples, once per 8 Rows.
7416

13.2 #WIP Specifications (normative)

13.2.1 Data Port: Prepare, Ready, and Enable

7417 Requirements
7418 1. DPn_PortSyncOK shall change to 1 when all of the following are true:
7419 A. The Peripheral is in Link State: Attached, and
7420 B. The Data Port receives an SSP indication from either an SSCR or SSPA Command, and
7421 C. Either or both of:
7422 i. 1 or more of DPn_EnableCh<c>_CURR==1, or
7423 ii. 1 or more of DPn_PrepareCh<c>_CURR==1.
7424 Note: An SSCR Command that commits a value of 1 to any of the EnableCh<c> or PrepareCh<c>
7425 bits will satisfy all of these conditions.
7426 2. DPn_PortSyncOK shall change to 0 when either:
7427 A. The Peripheral is not in Link State: Attached, or
7428 B. Both:
7429 i. All of DPn_EnableCh<c>_CURR bits are 0, and
7430 ii. All of DPn_PrepareCh<c>_CURR bits are 0.
7431 3. When the Data Port receives an SSP indication from either an SSCR or SSPA Command it shall
7432 behave as if the Sync Point identified by the Command is an SSP (i.e., the beginning of an
7433 Interval).
7434 Note: see EC_UnexpectedSSP in Table 164.
7435 4. DPn_PortReady shall be 1 when both:
7436 A. DPn_PortSyncOK==1, and
7437 B. For every channel that is implemented in the Data Port, either:
7438 i. (DPn_PrepareCh<c>==0) AND (DPn_ReadyCh<c>==0), or
7439 ii. (DPn_PrepareCh<c>==1) AND (DPn_ReadyCh<c>==1).
7440 ###TODO-Author: PortReady interrupts
7441 The IntStat_DPn_PortReady interrupt condition occurs when DPn_PortReady changes from 0 to 1.
7442 The IntStat_DPn_PortNotReady interrupt condition occurs when DPn_PortReady changes from 1 to 0.
7443
7444 5. DPn_PortReady shall not change from 0 to 1 when DPn_PrepareCh<n> is 0.
7445

7446 Permissions
7447 1. When DPn_PrepareCh<n> is 1, a Data Port may change DPn_ReadyCh<c> for any
7448 implementation-defined reason (e.g., a sample clock PLL losing lock).

7449 Recommendations
7450 1. A Manager should update DPn_EnableCh<c>_CURR and DPn_PrepareCh<c>_CURR only by
7451 using SSCR Commands to commit values from the corresponding _NEXT Registers.
7452 2. For Sink DPs that are not using Source-Synchronous or Sink-Synchronous flow control (see
7453 ###XREF), the Manager should not commit DPn_EnableCh<c> = 1 until the Channel is ready
7454 (e.g., after it has read DPn_ReadyCh<c> = 1).

7455 ###TODO-Author: A Source DP on a Mic: Recommend that if ((Ready Ch<c>=0) and (Enable Ch<c>=1))
7456 then the external Channel SHOULD produce a silent stream (where “silence” is an ImpDef encoding,
7457 known to the audio circuitry that is outside the SWI3S interface). NOTE THAT: this is only a
7458 recommendation, so devices DO NOT need to do this.

13.2.2 Data Port: FlowMode and Port Mode

7459 Requirements
7460 1. {…} A Sink DP shall transport an FCP_DRQ bit dependent upon the value of DPn_FlowMode
7461 according to Table 142 (see also Requirement 7).
7462 2. {…} A Source DP shall transport a Tx_Present bit dependent upon the value of DPn_FlowMode
7463 according to Table 142 (see also Requirement 7).
7464 3. {…} A Source DP shall transport Channel bits dependent upon the value of DPn_FlowMode
7465 according to Table 142 (see also Requirement 7).
7466 Table 142 Effect of DPn_FlowMode when DPn_PortMode is Normal
FCP DRQ Bit TxPresent Bit Are Channel Bits
DPn_FlowMode Name
from Sink DP from Source DP Transported? []
0 Normal Does not Exist Does not Exist Yes
Tx-Controlled /
1 Does not Exist SourceReady [2]
Source-Synchronous
Rx-Controlled / Copy of Only when
2 SinkReady [3]
Sink-Synchronous Earlier_FCP_DRQ [4] (TxPresent=1)
(SourceReady [2]
3 Asynchronous SinkReady [3] AND
Earlier_FCP_DRQ [4])
7467 Note:
1. “Not transported” means that the Source Data Port does not own the Channel bits so, e.g., for
PHY3 (DLV) the bus will not be driven.
2. SourceReady is a notional internal signal within the Source DP indicating that there is at least 1
Transport Interval’s worth of data for every channel that is ready to be transported.
3. SinkReady is a notional internal signal within the Sink DP indicating that the Sink DP will be ready
to receive 1 (or more) Sample Frames during the next (or next-but-one) Transport Interval (see
###XREF).
4. The Source DP uses the value of the FCP DRQ that was received either 1 or 2 Sample Intervals
earlier (see ###XREF).

7468 4. {…} When a Sink Data Port transports an FCP_DRQ bit, it shall use a value dependent upon
7469 DPn_PortMode according to Table 143.
7470 5. {…} When a Source Data Port transports a Tx_Present bit, it shall use a value dependent upon
7471 DPn_PortMode according to Table 143.
7472 6. {…} When a Source Data Port transports each Channel bit, it shall use a value dependent upon
7473 DPn_PortMode according to Table 143.
7474 Table 143 Effect of DPn_PortMode
Raw Value [1] in Each Bit (i.e., Before Any Scrambling)
Channel Bit TxPresent Bit FCP DRQ Bit
DPn_PortMode Name
(Source to Sink) (Source to Sink) (Sink to Source)
Next payload data SinkReady from internal
0 Normal See Table 142.
bit from a sample state of the Sink DP.
1 Reserved — — —
2 Test0 0 0 0
3 Test1 1 1 1
7475 Note:
1. Raw Value means before scrambling (if enabled) in the transmitting Device or after descrambling
in the receiving Device. See Section 13.2.3 Requirement ###XREF.

7476 7. {…} When DPn_PortMode indicates Test0 or Test1 (see Table 143), the effect of DPn_FlowMode
7477 shall be as shown in Table 144.
7478 Table 144 Effect of DPn_FlowMode when PortMode is a Test Mode
FCP DRQ Bit TxPresent Bit Are Channel Bits
DPn_FlowMode Name
from Sink DP from Source DP Transported?
0 Normal Does not Exist Does not Exist
Tx-Controlled /
1 Does not Exist Yes
Source-Synchronous
Fixed 0 or 1 [1] Fixed 0 or 1 [1]
Rx-Controlled /
2 Fixed 0 or 1 [1] (see Table 143) (see Table 143)
Sink-Synchronous
(see Table 143)
3 Asynchronous
7479 Note:
1. When DPn_PortMode is Test0 or Test1, the existence of Channel bits does not depend on the
value of TxPresent, and the value of TxPresent does not depend on the value of the received
FCP DRQ bit.
7480 8. {…} When DPn_PortMode indicates Test0 or Test1 (see Table 143), a Data Port shall treat each
7481 instance when the received bit does not match the fixed value described in Table 143 as a bit error
7482 (see ###XREF to ###TODO-Author: correct Error Counter name).
7483 Note: the Data Port checks the value after descrambling, if this is enabled.

13.2.3 #WIP: Data Port : Scrambler

7484 1. A Data Port shall have a separate instance of the Scrambler for each Channel in a Data Port.
7485 2. A Data Port that supports FlowModes 2 and/or 3 (see Table 142) shall have a separate instance of
7486 the Scrambler for the FCP channel.
7487 3. When DPn_ScramblerEn=1, a Data Port shall feed the Raw Values of any FCP_DRQ, TxPresent,
7488 or Channel bits (see Table 143) through the scrambler for that Channel before transmitting them
7489 on the bus.
7490 4. When DPn_ScramblerEn=1 and DPn_PortMode is Test0 or Test1 (see Table 143), a Data Port
7491 shall feed the received values of FCP_DRQ, TxPresent, or Channel bits through the Scrambler for
7492 that Channel before checking for bit errors as described in Section 13.2.2 Requirement 8.
7493 5. When DPn_ScramblerEn=1 and DPn_FlowMode is not Normal (see Table 142), a Sink Data Port
7494 shall feed the received value of TxPresent through the Scrambler for that Channel before
7495 determining whether the corresponding Channel bits exist.
7496 ###TODO-Author: add some rules for the Scrambler algorithm.
7497

14 Registers

14.1 Description (informative)

14.1.1 Address Map

7498 Normative Table 146 in Section 14.2.1 shows the top-level address map for the Peripheral, which is
7499 divided into regions at 256 MByte granularity.

14.1.1.1 Dual-Ranked Registers in SWI3S-defined Register Blocks

7500 The SWI3S-defined Peripheral Register region is divided into a number of 4K blocks (see detail in
7501 normative Table 147 in Section 14.2.1). Within each of these 4K Register blocks, the addresses are divided
7502 according to Table 145, where each dual-ranked Register comprises 1 address for the NVR (Next Value
7503 Register) and 1 address for the CVR (Current Value Register).
7504 Table 145 Peripheral Address Map for SWI3S Registers
Address Range Size Region
Base+0x00 – Base+0x7F 128 bytes Single-ranked Registers [1]
Base+0x80 – Base+0xBF 64 bytes *_NEXT part of dual-ranked Registers
Base+0xC0 – Base+0xFF 64 bytes *_CURR part of dual-ranked Registers
1. The name “single-ranked” is used here to differentiate these registers that occupy 1 address from
the dual-ranked registers that use 2 addresses (1 for the “Current” value and 1 for the “Next”
value).

14.1.1.2 SDCA-defined Registers

7505 The assignment of Peripheral Register addresses in the SDCA address regions is described in the SDCA
7506 Specification, [MIPI02].

14.1.1.3 Device-defined Registers

7507 The assignment of Peripheral Register addresses in the Device-defined address regions is chosen by the
7508 device implementor.

14.1.2 Registers

14.1.2.1 Register Maps and Bytes

7509 The Register Maps within normative Section 14.2 describe the position of Register Fields within
7510 individually addressable byte-wide registers.

14.1.2.2 Register Fields

7511 Groups of 1 or more bits in the registers are referred to as Register Fields. The Register Field definitions
7512 within Section 14.2 specify whether implementation of each field is:
7513 • Mandatory.
7514 • Conditional (i.e., mandatory if some condition is met).
7515 • Optional.
7516 Where fields are spread across multiple bytes, these can be written independently. For dual-ranked
7517 registers, all bits of a Current Value Register can be updated together by using a Commit Command (SSCR
7518 or DSCR).

14.1.2.3 Register Access

7519 A Register Field is specified to have 1 of the following Access types:
7520 RO: Read-Only. The Peripheral generates the value in the register, and an attempted write by the Manager
7521 will not change it.
7522 RW: Read-Write. The Manager writes the value and can read it back. If the Manager writes a value that is
7523 not supported by the Peripheral then the Peripheral changes it to one of the values that is supported, so that
7524 if the Manager reads back the Register it can determine how the Peripheral will behave.
7525 ###TODO-Author: Check that there is normative material describing this concept that after writing
7526 an unsupported value, the Peripheral will replace this with a supported value, and read back the
7527 field.
7528 RW1C: Read-and-Write-1-to-Clear. The Peripheral can change each bit in the register from 0 to 1, and
7529 these can be read by the Manager. When the Manager writes to the register, any 1 bits in the write data
7530 value cause the corresponding Register bit to be cleared to 0, and any 0 bits have no effect. RW1C bits used
7531 for Interrupt Status have special behavior where they can only be cleared if the interrupt condition has not
7532 reoccurred since the bit was last read (see ###XREF).
7533 Dual: Dual-ranked Register. Notation used in the normative tables in Section 14.2 for a field that can be
7534 either Dual-RO or Dual-RW.
7535 Dual-RO: Dual-ranked Register, Current is Read-Only. The Manager can read a Dual-RO Current
7536 Value Register that is part of a dual-ranked register, but cannot write it. The value is updated by a Commit
7537 Command that copies the value from the corresponding read-write Next Value Register (see Figure 179 in
7538 Section 14.1.3).
7539 Dual-RW: Dual-ranked Register, Read-Write. The Manager can both read and write a Dual-RW Current
7540 Value Register that is part of a dual-ranked register. The value can also be updated by a Commit Command
7541 that copies the value from the corresponding Next Value Register (see Figure 180 in Section 14.1.3).
7542 Note:
7543 Some Register Fields are specified to allow implementation with a choice of Access Types, e.g.,
7544 RO or RW.

14.1.2.4 Reserved Registers or Unimplemented bits

7545 When a Peripheral produces read data for a Reserved address, or for a register that is not implemented, it
7546 delivers a byte value of 0. When a Peripheral accepts write data for a Reserved address, or for a Register
7547 that is not implemented, it discards the write data byte. CRC calculations on the data bytes in read or write
7548 Commands include all bytes that are transferred, including any zero-valued data bytes corresponding to
7549 reserved addresses or unimplemented registers.
7550 When a Peripheral produces read data for a bit that is not implemented within a Register, it delivers a bit
7551 value of 0.

14.1.2.5 Reserved or Unimplemented Values in Registers

7552 For some Registers or Register fields, it is optional for the Peripheral to support the behavior associated
7553 with some of the values (e.g., PM_Action). When the Manager attempts to write a value that is
7554 unimplemented in the Peripheral, the Peripheral will select another value that it does implement and then
7555 store this in the Register. The Manager can determine the Peripheral behavior by reading back the actual
7556 value from the Register.
7557 Note:
7558 If a Device implements the behavior for only one possible value of a Register then it might actually
7559 implement that “writable” register as a read-only location.

14.1.3 Dual-Ranked Registers

7560 For some operations it is desirable to prepare updates to multiple registers and then commit those updates
7561 simultaneously. This Specification describes a mechanism to meet this need, named Dual-Ranked
7562 Registers, and Commands to initiate the commit operation, named SSCR and DSCR.
7563 Dual-Ranked Registers have a Current Value Register (CVR) that controls current operation of a Device,
7564 and a Next Value Register (NVR) which contains a value set up in advance of a simultaneous change to
7565 multiple control values. Each of CVR and NVR have separate addresses and can be accessed using Read
7566 Commands. NVRs, and some CVRs, can be accessed using Write Commands.
7567 Note:
7568 Fields in Current and Next Value Registers can be identified by their names ending in “_CURR” and
7569 “_NEXT” respectively.
7570 A Commit operation is used to copy the values from the Next Value Registers to the Current Value
7571 Registers. The scope of the Commit operation might be part or all of one Device, or part or all of multiple
7572 Devices within a system. The Commit operation is non-destructive to the Next Value Registers, so after a
7573 Commit operation the value of all NVRs will be the same as that in the corresponding CVRs. In this default
7574 condition, further Commit operations do not change the value of any CVRs, so do not change any of the
7575 Device behavior being controlled by the Dual-Ranked Registers. The SSCR and DSCR Commands used to
7576 generate Commit operations for Dual-Ranked Registers are described in Section 9.1.10.
7577 Some Dual-Ranked Registers support directly writing to of a CVR to obtain an immediate effect without
7578 waiting for a Commit operation (e.g., because a Commit affects a whole group of Dual-Ranked Registers
7579 and software might delay issuing the Commit until a consistent set of NVRs has been written). In this case,
7580 a direct write to the CVR causes the same value to be written also to the NVR to maintain the default
7581 condition of all NVRs having the same value as their corresponding CVRs.
7582 For Cold Reset, if CVRs have a defined reset value then the corresponding NVR is also reset, and to the
7583 same value. Warm Reset affects few Registers, and in a dual-ranked Register it affects only the CVR while
7584 the NVR is unchanged, which facilitates quicker reinstatement of existing state following a Warm Reset.
7585 Figure 179 illustrates the basic functionality of a Dual-Ranked Register, including a reset value common to
7586 both the NVR and CVR. For almost all dual-ranked registers, the values are only reset by a Cold Reset, and
7587 exceptions to this (such as the Ch_N_Enable bits) are called out in the normative Section. Figure 180
7588 shows the additional data multiplexing to support writing to a read-write CVR.

Next Current
Value Value
Register Register

Write Data from Control Value

Command to Function

Update

Update
Reset Value

Reset

Reset
Cold Reset

Warm Reset

Valid Write to NVR

Commit
7589
Figure 179 Dual-Ranked Register with Read-Only Current Value (Dual-RO)

Current
Value
Next Register
Value
Register
Control Value
0 to Function
Write Data from
Command
1
Update
Reset
Update

Reset Value
Reset

Cold Reset

Warm Reset

Valid Write to NVR

Valid Write to CVR

Commit
7590
Figure 180 Dual-Ranked Register with Read-Write Current Value (Dual-RW)

14.1.4 Some ###TBD items for Registers:

7591 ###TODO-Author: implement this ANSWER TO QUESTION from AudioWG FTF on 20231129
7592 (Columbia): can a Device choose not to implement LSBs of the UI_RateRange or RowRateRange Register
7593 Fields? If it does, then are the range definitions expanded somehow? ANSWER: a Peripheral may
7594 implement fewer bits in UI_RateRange and/or RowRateRange, and alias the written value onto a different

7595 stored value. It shall behave correctly (e.g., lock within the right time limit) provided that the Manager
7596 continues to generate a rate that matches the value that it wrote.
7597 Does this question apply to any other fields where some values are optional?
7598 Table 153 System and Link Control Register Fields (SLC_*): RowRateRange & UI_RateRange: (1) are
7599 the widths of these fields dependent upon which PHY is currently selected? (2) are any of the LSbs
7600 optional, e.g., if the Peripheral uses wider bins for its internal behavior? If so, how does the Manager
7601 understand when the Peripheral is saying “I have wide ranges” vs. “I don’t support that value”?
7602 Table 158 Peripheral Register Map for PHY1 and PHY2 Dual-Ranked Registers (PHY1_*_NEXT and
7603 Table 161: Stefano’s question about checking PHYn_DriveImpedance for each of the PHYs (bit width is
7604 shown as 3 for PHY1/2 and 4 for PHY3).
7605
7606 ###TODO-Author: when the PHY lists have been finalized, find and describe(!) a clean notation to
7607 represent which values in a list are mandatory and which are optional.

14.2 Specifications (normative)

7608 ###Note to reviewers: Some of the text in the “description and encoding” column in the tables of
7609 register fields has not yet been proof read / edited.

14.2.1 Peripheral Address Map

7610 Requirements
7611 1. A Peripheral shall divide up its address map according to Table 146.
7612 Table 146 Peripheral Top-Level Address Map
Local / Remote
Address Range Size Region Further Details
Access [1]
SWI3S-defined
0x00000000–0x0FFFFFFF 256 MB See Table 147
Registers [2]
3× Peripheral Device
0x10000000–0x3FFFFFFF Local Device-defined
256 MB Documentation
4×
0x40000000–0x7FFFFFFF SDCA See [MIPI02]
256 MB
0x80000000–0x8FFFFFFF 256 MB Reserved —
3× Remote Peripheral Device
0x90000000–0xBFFFFFFF Device-defined
256 MB (i.e., bufferable write Documentation
4× or deferrable read)
0xC0000000–0xFFFFFFFF SDCA See [MIPI02]
256 MB

1. The Local/Remote Access column defines whether accesses to this address are treated as a
Local Write or Remote Write (see Section 9.2.3 Requirement 2) or a Local Read or Remote
Read (see Section 9.2.4 Requirement 2).
2. The SWI3S-defined Registers have defined sequencing for multi-byte Writes (see Section 9.2.3
Requirement 7) and multi-byte Reads (see Section 9.2.4 Requirement 7).

7613 2. A Peripheral shall implement all of the following SWI3S-defined Registers at blocks of addresses
7614 specified in Table 147:
7615 A. A block of System & Link Control Registers specified in Section 14.2.4 and Section 14.2.5.
7616 B. A block of Control Data Stream Transport Registers specified in Section 14.2.6, and
7617 Section 14.2.7.
7618 C. 1 block of Peripheral PHY Registers described in the Table(s) listed in Table 147 for each of
7619 PHY0 through PHY15 that is implemented in the Peripheral (see Section 5.2.4
7620 Requirement 2).
7621 D. 1 block of Data Port Registers described in Section 14.2.2 and Section 14.2.3 for each of DP0
7622 through DP31 that is implemented in the Peripheral (see Section 5.2.4 Permission 1).
7623 Table 147 Peripheral Address Map Blocks for SWI3S Registers

Register Register Register Field

Address Range Size Region
Name Prefix Table(s) Definitions

Reserved for
0x00000000–0x000000FF 1 × 256 — — —
PHY0 Registers []

0x00000100–0x000001FF 1 × 256 PHY1 Registers [] PHY1_ Table 158 Table 159

0x00000200–0x000002FF 1 × 256 PHY2 Registers [] PHY2_ Table 158 Table 159

Table 160
0x00000300–0x000003FF 1 × 256 PHY3 Registers [] PHY3_ Table 162
Table 161

Reserved for
0x00000400–0x00000FFF 12 × 256 — — —
PHY4–15 Registers []

System & Link Control Table 151

0x00001000–0x000010FF 1 × 256 SLC_ Table 153
Registers Table 152

Control Data Stream

0x00001100–0x000011FF 1 ×256 CDS_ Table 155 Table 156
Transport Registers

0x00001200–0x00001FFF 14 × 256 Reserved — — —

DP0_
Data Port Registers for Table 148
0x00002000–0x00003FFF 32 × 256 … Table 150
DP0–31 Table 149
DP31_

Remainder
0x00004000–0x0FFFFFFF Reserved — — —
of 256MB

7624 Note:
1. It is implementation-defined whether the Registers for one PHY are accessible when a different
PHY is in use. It is possible to build a Device that re-uses the same flip-flops for Registers in the
address blocks for different PHYs (see Permission ###XREF).

7625 3. Within each of the blocks of Registers, a Peripheral shall implement all register fields that are
7626 specified as either:
7627 A. Mandatory, or:
7628 B. Conditional, and the specified implementation condition is true.
7629 Note: see also Permission 1.
7630 4. A Peripheral shall deliver a read data byte of 0 in response to a read from:
7631 A. A Register address that is specified as Reserved, or
7632 B. A Register address that is specified as Conditional or Optional, and the Register is not
7633 implemented.
7634 5. A Peripheral shall deliver a read data bit of 0 in response to a read from a Register that is
7635 implemented, but where:
7636 A. The bit is specified as Reserved, or
7637 B. The bit is specified as Conditional or Optional, and the bit is not implemented.

7638 Permissions
7639 1. Within each of the blocks of SWI3S-defined Registers, a Peripheral may implement any register
7640 field that is specified as either:
7641 A. Optional, or
7642 B. Conditional, and the specified implementation condition is not true.
7643 2. A Peripheral may implement Registers at any of the addresses shown as Device-defined in
7644 Table 146.
7645 3. A Peripheral may re-use the same flip-flops between 2 or more sets of PHY-specific Registers
7646 shown in Table 147.
7647 4. A Peripheral may implement Registers defined in the SDCA Specification, [MIPI02], at the
7648 blocks of addresses specified in Table 146.

14.2.2 Peripheral Data Port Registers

7649 Requirements
7650 1. A Data Port Register Block shall include Registers defined in Table 148 containing Register Fields described in Table 150.
7651 2. Each DPn_Register shall have an address calculated from the base address of the Data Port Region shown in Table 147 + (256 × the Data Port number)
7652 + the Address Offset from Table 148.
7653 Table 148 Peripheral Register Map for Data Port (DPn_*)
Address
Access Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Offset

IntStat_FlowContr IntStat_Unexpect IntStat_PortNotRe IntStat_PortRead

0x00 RW1C IntStat_ImpDef_1 IntStat_ImpDef_0 Reserved
olFail edSSP ady y
IntStat_TestFail

0x01–
— [ 3 x Reserved ]
0x03
DevStat_Receive
0x04 RW1C Reserved Reserved Reserved Reserved Reserved Reserved Reserved
dSSP

0x05 RO Reserved Reserved Reserved Reserved Reserved Reserved PortReady PortSyncOK

0x06 RO ReadyCh7 ReadyCh6 ReadyCh5 ReadyCh4 ReadyCh3 ReadyCh2 ReadyCh1 ReadyCh0

0x07 RO ReadyCh15 ReadyCh14 ReadyCh13 ReadyCh12 ReadyCh11 ReadyCh10 ReadyCh9 ReadyCh8

0x08 — Reserved

0x09 RW SampleGrouping[2:0] SampleSize[4:0]

0x0A RW Reserved Reserved Reserved Reserved CommitGroupMemb[3:0]

0x0B RW Reserved Reserved Reserved Reserved ScramblerEn PortDirection PortMode[1:0]

0x0C RW SkippingNumerator[7:0]

0x0D RW Reserved Reserved Reserved Reserved SkippingNumerator[11:8]

###TODO: FCP_
0x0E RW FlowControlDelay Reserved Reserved Reserved
ScramblerEn
Reserved FlowMode[1:0]

0x0F RW Reserved

IntEn_FlowContro IntEn_Unexpecte IntEn_PortNotRea

0x10 RW IntEn_ImpDef_1 IntEn_ImpDef_0 Reserved
lFail dSSP dy
IntEn_PortReady IntEn_TestFail

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
Address
Access Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Offset
0x11–
— [ 15 x Reserved ]
0x1F
0x20 RO EC_TestFail_Ch0[7:0]

0x21 RO EC_TestFail_Ch1[7:0]

0x22 RO EC_TestFail_Ch2[7:0]

0x23 RO EC_TestFail_Ch3[7:0]

0x24 RO EC_TestFail_Ch4[7:0]

0x25 RO EC_TestFail_Ch5[7:0]

0x26 RO EC_TestFail_Ch6[7:0]

0x27 RO EC_TestFail_Ch7[7:0]

0x28 RO EC_TestFail_Ch8[7:0]

0x29 RO EC_TestFail_Ch9[7:0]

0x2A RO EC_TestFail_Ch10[7:0]

0x2B RO EC_TestFail_Ch11[7:0]

0x2C RO EC_TestFail_Ch12[7:0]

0x2D RO EC_TestFail_Ch13[7:0]

0x2E RO EC_TestFail_Ch14[7:0]

0x2F RO EC_TestFail_Ch15[7:0]

0x30 RO EC_UnexpectedSSP[7:0]

0x31 RO EC_FlowControlFail[7:0]

0x32–
— [ 13 x Reserved ]
0x3E
0x3F RO COUNT_Received_SSP[7:0]

0x40–
— [ 48 × Reserved ]
0x6F

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
Address
Access Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Offset
0x70–
ImpDef [ 16 × ImpDef ]
0x7F

7654 3. A Data Port Register Block shall include dual-ranked Registers each comprising both:
7655 A. DPn_*_NEXT Registers defined in Table 149 containing DPn_*_NEXT Register Fields described in Table 150, and
7656 B. Corresponding DPn_*_CURR Registers containing DPn_*_CURR fields.
7657 4. Each DPn_*_NEXT Register shall have an address calculated from the base address of the Data Port Region shown in Table 147 + (256 × the Data Port
7658 number) + the Address Offset from Table 149.
7659 5. Each DPn_*_CURR Register shall have an address calculated from 0x40 + the address of the corresponding DPn_*_NEXT Register (from
7660 Requirement 4).
7661 Table 149 Peripheral Register Map for Data Port Dual-ranked Registers (DPn_*_NEXT)
Address
Access Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Offset

0x80 Dual BitWidth_NEXT[1:0] Reserved HorizontalStart_NEXT[4:0]

EnableCh0 PrepareCh0
0x81 Dual
_NEXT _NEXT
Reserved HorizontalCount_NEXT[4:0]

SubRowInterval
0x82 Dual TailWidth_NEXT[1:0]
_NEXT
Reserved Spacing_NEXT[3:0]

0x83 Dual Offset_NEXT[3:0] Interval_NEXT[3:0]

0x84 Dual Interval_NEXT[11:4]

0x85 Dual Offset_NEXT[11:4]

EndHalfEarly
0x86 Dual
_NEXT
Reserved Reserved Reserved ApertureAdjust_NEXT[3:0]

0x87 Dual Reserved Reserved Reserved Reserved ChannelGrouping_NEXT[3:0]

0x88 Dual ConverterClockDiv_NEXT[7:0]

0x89 Dual ConverterClockDiv_NEXT[15:8]

GuardEnable GuardPolarity
0x8A Dual Reserved Reserved Reserved Reserved Reserved Reserved
_NEXT _NEXT

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
Address
Access Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Offset
0x8B—
— [ 5 × Reserved ]
0x8F
EnableCh7 EnableCh6 EnableCh5 EnableCh4 EnableCh3 EnableCh2 EnableCh1
0x90 Dual
_NEXT _NEXT _NEXT _NEXT _NEXT _NEXT _NEXT
Reserved

EnableCh15 EnableCh14 EnableCh13 EnableCh12 EnableCh11 EnableCh10 EnableCh9 EnableCh8

0x91 Dual
_NEXT _NEXT _NEXT _NEXT _NEXT _NEXT _NEXT _NEXT

PrepareCh7 PrepareCh6 PrepareCh5 PrepareCh4 PrepareCh3 PrepareCh2 PrepareCh1

0x92 Dual
_NEXT _NEXT _NEXT _NEXT _NEXT _NEXT _NEXT
Reserved

PrepareCh15 PrepareCh14 PrepareCh13 PrepareCh12 PrepareCh11 PrepareCh10 PrepareCh9 PrepareCh8

0x93 Dual
_NEXT _NEXT _NEXT _NEXT _NEXT _NEXT _NEXT _NEXT

0x94—
— [ 12 × Reserved ]
0x9F
0xA0 Dual FCP_BitWidth_NEXT[1:0] Reserved FCP_HorizontalStart_NEXT[4:0]

0xA1 — Reserved

0xA2 Dual FCP_TailWidth_NEXT[1:0] Reserved Reserved Reserved Reserved Reserved Reserved

0xA3 Dual FCP_Offset_NEXT[3:0] Reserved Reserved Reserved Reserved

0xA4 — Reserved

0xA5 Dual FCP_Offset_NEXT[11:4]

FCP_EndHalfEarl
0xA6 Dual y Reserved Reserved Reserved FCP_ApertureAdjust_NEXT[3:0]
_NEXT

0xA7–
— [ 3 × Reserved ]
0xA9
FCP_GuardEnabl FCP_GuardPolari
0xAA Dual Reserved Reserved Reserved Reserved Reserved Reserved
e_NEXT ty_NEXT

0xAB–
— [ 5 × Reserved ]
0xAF
0xB0–
ImpDef [ 16 × ImpDef ]
0xBF

7662 Requirements
7663 1. The Data Port Register Fields shall be implemented according to Table 150.
7664 Note: the full names of all of these fields are preceded by “DPn_”, e.g., DPn_IntStat_TestFail.

7665 Table 150 Peripheral Data Port Register Fields (DPn_*)

Mandatory / Conditional / Cold Reset

Field Name Access Description & Encoding
Optional / … Value

One or more channels received incorrect data when

IntStat_TestFail RW1C Mandatory ’b0
the DP was in test mode.

Interrupt Enable for IntStat_TestFail.

IntEn_TestFail RW Mandatory ’b0 ’b0: This IntStat does not affect Ping Status.
’b : IntStat=1 will change Ping status to Alert.

EC_TestFailCh<c>[7:1]
Optional
Counter for the TestFail events. One for each
EC_TestFailCh<c>[7:0] RO EC_TestFailCh<c>[0] 8’b0
implemented Channel.
Conditional on Channel <N>
implemented in the DP.

This interrupt is set to 1 when the combinatorial

IntStat_PortReady RW1C Mandatory ’b0 PortReady function (a separate status register bit)
changes from 0 to 1.

Interrupt Enable for IntStat_PortReady.

IntEn_PortReady RW Mandatory ’b0 0: This IntStat does not affect Ping Status.
1: IntStat=1 will change Ping status to Alert.

This interrupt is set to 1 when the combinatorial

IntStat_PortNotReady RW1C Optional ’b0 PortReady function (a separate status register bit)
changes from 1 to 0.

Conditional Interrupt Enable for IntStat_PortNotReady.

IntEn_PortNotReady RW (IntStat_PortNotReady is ’b0 0: This IntStat does not affect Ping Status.
implemented) 1: IntStat=1 will change Ping status to Alert.

An unexpected SSP event has been detected.

The sources of SSP are SSPA and SSCR, receiving
an unexpected SSP is either a sign of being not in
IntStat_UnexpectedSSP RW1C Mandatory ’b0 sync with the Manager or the manager not
considering the correct interval for this dataport
assigned to a commit group.
###REF: unexpected SSP.

IntEn_UnexpectedSSP RW Mandatory ’b0 Interrupt Enable for IntStat_UnexpectedSSP.

EC_UnexpectedSSP[7:1]
Optional
EC_UnexpectedSSP[7:0] RO 8’b0 Counter for the UnexpectedSSP events.
EC_UnexpectedSSP[0]
Mandatory

A Received SSP event has been detected (SSCR or

SSPA Command).
This DevStat bit is useful for verifying the operation of
DevStat_Received_SSP RW1C Mandatory ’b0 SSPA Commands, which do not have any explicit
Peripheral Response to acknowledge the SSP
indication.
###XREF: SSP events and SSPA.

COUNT_Received_SSP[7:1]
Optional
COUNT_Received_SSP[7:0] RO 8’b0 Counter for the DevStat_Received_SSP events.
COUNT_Received_SSP[0]
Mandatory

Flow control has failed, i.e., one of:

• (In any of the 3 flow control modes) the Sink
DP received non-matching DataValid bits in
some of the Channels, or
Conditional (Sink DP that • (In Sink-controlled mode) the DataValid bits did
IntStat_FlowControlFail RW1C ’b0 not match the Data Request bit previously sent
supports flow control) by the Sink DP.
• (In Sink-Source-controlled mode) the Data
Valid bits were 1 when the Data Request bit
previously sent by the Sink DP was 0.
(See Section 13.1.8)

IntEn_FlowControlFail RO Conditional ’b0 Interrupt Enable for IntStat_FlowControlFail.

EC_FlowControlFail[7:1]
Optional
EC_FlowControlFail[7:0] RO EC_FlowControlFail[0]] 8’b0 Counter for FlowControlFail events.
Conditional (Sink DP that
supports flow control)

Indicates that the DataPort Interval machine is

synchronized.
PortSyncOK RO Mandatory ’b0 This happens in the following situations:
DP becomes aligned after any indication of an SSP
(SSPA or SSCR) or when the Transport Inteval is <=1.

PortReady is a combinatorial function of other state:

PortReady= PortSyncOK AND
PortReady RO Mandatory ’b0
(PrepareCh<c>_CURR==ReadyCh<c>) for all
channels in the Data Port.

One bit per channel indicating the state of that

channel's prepare state machine (preparing or de-
ReadyCh0 Mandatory Implementation-
ReadyCh<c> RO preparing).
ReadyCh<c> Optional Defined
A DP supports a contiguous set of channel numbers
starting from Channel 0.

Size of the Samples for the Dataport (excess-1

Implementation encoded, e.g., b01111 => 16 bits).
SampleSize[4:0] RW Mandatory
Defined DP might support any subset of SampleSizes from 1
to 32 bits.

b000: There is 1 sample frame per interval.

…
Conditional b111: There are 8 sample frame per interval.
It indicates the sample frames per Interval and how
(if DP can produce sample
SampleGrouping[2:0] RW b000 many sample frames occur consecutively.
frames that use fewer than 8
bits) Note that if a sample grouping cannot be fit a row, it
will take space in the following one, using the UIs as
per indication from HorizontalStart and
HorizontalCount.

0: Scrambler is not active.

ScramblerEn RW Mandatory 1 1: Scrambler is active.
###XREF to Scrambler definition.

A bit for each Commit Group that this Dataport is a

member of group named 0, 1, 2, 3, e.g.:
b0001: DP is in TCG0
CommitGroupMemb[3:0] RW Mandatory b0001
…
b1100: DP is in TCG3 and TCG2
A Dataport can be assigned to multiple groups.

Encoding:
0: Normal mode: payload data to/from the
audio function.
PortMode[1:0] RW Mandatory 0
1: Reserved.
2: Test mode: payload data is all 0s.
3: Test mode: payload data is all 1s.

RO
Encoding:
Conditional RW Implementation-
PortDirection Mandatory 0: Source: puts data on the bus.
(bidirectional Defined
1: Sink: reads data from the bus.
DP)

Number of samples to skip out of Skipping

Denominator number of of transport intervals.
SkippingNumerator[11:0] RW Optional 0
0: Use every Transport Interval (no skipping).
See ###XREF.

FlowMode controls the presence and use of the

DataValid bit in each output channel, and the
presence of the DRQ bit in the FCP stream (see
Conditional ###XREF).
(if Data Port supports any of Encoding:
FlowMode[1:0] Dual Modes 1, 2, or 3 for 0 0: Off (no DataValid bits transmitted).
flow-controlled Payload 1: Source-controlled.
transport). 2: Sink-controlled.
3: Sink-Source-Controlled.
Note: DP support for each of FlowModes 1, 2,
and 3 is optional.

FlowControlDelay applies to FlowModes 2 and 3.

It controls the latency between the Sink DP
DataRequest bit and the Source DP DataValid bits
(see Section 13.1.8).
Encoding:
Conditional (DP implements 0: DataRequest in Transport Interval N
FlowControlDelay RW 1 influences DataValid in the Transport Interval
FlowMode 2 or 3)
N+1.
1: DataRequest in Transport Interval N
influences DataValid in the Transport Interval
N+2.
Note: DP support for FlowModes 2 and 3 is
optional.

Number of rows between the start of the Transport

Interval and the start of payload transport.
0: Payload transport starts on the same Row
as the start of the Transport Interval.
1: Payload transport starts 1 row after the start
of the Transport Interval.
…
Offset[2:0] Mandatory 4095: Payload transport starts 4095 Rows
Offset_CURR[11:0] after the start of the Transport Interval.
Offset[11:3] Conditional Implementation-
Dual The Data Port implements contiguously numbered
Offset_NEXT[11:0] (on corresponding Interval Defined
bits from 0 upwards. The highest numbered Offset bit
bits).
is between 2 and 11 (and is the same as the highest
numbered Interval bit).
Note: Setting (Offset_CURR > Interval_CURR) is
a programming error that might cause the Data
Port to produce incorrect or no payload data.
###TODO-Author: move this note to payload
chapter.

HorizontalStart_CURR[4:0] First owned UI in the any row that meets interval

Dual Mandatory 0
HorizontalStart_NEXT[4:0] criteria.

Indicates how many UIs in the Row could be used by

the stream:
b00000: 1 UI (i.e., columns HStart to HStart+0)
b00001: 2 UI (i.e., columns HStart to HStart+1)
HorizontalCount_CURR[4:0] 0 …
Dual Mandatory
HorizontalCount_NEXT[4:0] (1 UI) b11111 : 32 UI (i.e., columns HStart to HStart+31)
Note:
It is a programming error to set values such that:
(HorizontalStart + HorizontalCount) >
NumColumns.

Enable bit for the alternate style of Intervals.

SubRowInterval_CURR 0: normal interval (Interval register indicates
Dual Optional 0 number of Rows).
SubRowInterval _NEXT
1: sub-row interval (Interval register indicates
number of UIs).

One bit per channel providing input(s) to the prepare

state machine(s). Prepare is generally used to start
any collateral electronics used by the Data Port
Ch0 Mandatory
PrepareCh<c>_CURR Implementation- stream (typically analog circuitry).
Dual Ch<N> Conditional (when
PrepareCh<c>_NEXT Defined Changing from 0 to 1 is called Preparing.
channel <N> exists)
Changing from 1 to 0 is called Depreparing.
A DP supports a contiguous set of channel numbers
starting from Channel 0.

Size of the Transport Interval (how often the DP

transports data). SubRowInterval field (###XREF)
controls whether this is quantized in Rows (maximum
4096) or in UIs (maximum is column count).
Interval_CURR[11:0] Interval[3:0] Mandatory Implementation- Excess-1 encoding, e.g.:
Dual
Interval[11:4] Optional Defined 3’b000: TransportInterval= .
Interval_NEXT[11:0]
3’b00 : TransportInterval= .
…
5’b : TransportInterval=3 .
…
’b : TransportInterval= 096.

Tails are counted after a transport segment (e.g.,

during InterChannelGroup spacing and after the end
of HCount BUT after any Guard). Not impacted by
TailWidth_CURR[1:0] Dual BitWidth.
Conditional (Source DP) ’b0
TailWidth_NEXT[1:0] ’b00: 0 UI
’b01: 1 UIs
’b 0: UIs
’b11: Reserved.

Conditional (on GuardEnable When GuardEnable is ’b :

GuardPolarity_CURR
Dual being implemented, per ’b0 ’b0: drive 0 as GuardBit.
GuardPolarity_NEXT
PHY) ’b1: drive 1 as GuardBit.

’b0: GuardBit are not active.

’b1: GuardBit are active.
Guard bits are always 1 UI (i.e., not affected by the
Optional (per PHY, and is WideBit setting).
GuardEnable_CURR
Dual only ever implemented in ’b0 Guard bits are not scrambled.
GuardEnable_NEXT
Source DPs). Guard bits occur after the last data bit in a contiguous
sequence of bits from the same Device (and only if
the last DP in that sequence of bits has Guard Bits
enabled).

’b0: drive to the end of the UI.

’b1: stop driving 1/2 UI early.
EndHalfEarly_CURR When releasing ownership of the bus (going to Hi-z,
Dual Optional ’b0
EndHalfEarly_NEXT the last bit of the latest of data or guard or tail), stop
driving one UI (1/2 column) early.
Note: some PHYs in the Device might ignore this bit.

When using
PHY1: excess one number of UIs:
2 × RO ’b00: 1 UI (fixed RO value when using PHY1)
BitWidth_CURR[1:0]
Mandatory 2’b0 ’b01: 2 UIs
BitWidth_NEXT[1:0]
When using ’b10: 3 UIs
PHY2 or PHY3: ’b11: Reserved.
Dual

Offset from the centre of the last UI of the bit (which is

the only UI when not using wide bits).
4-bit ’s complement number in / 6ths of a UI.
’b 000: –8/16 UI
’b 00 : –7/16 UI
Conditional on Sink Ports …
AND then: ’b : –1/16 UI
ApertureAdjust_CURR[3:0]
Dual Mandatory in PHY3:DLV or 4’b0000 ’b0000: +0 UI
ApertureAdjust_NEXT[3:0]
Optional in PHY1/#2:FBCSE ’b000 : + / 6 UI
Bits 2:0 are Optional. …
’b0 : +7/ 6 UI
Note:
An effective value of +8/16 UI can be achieved
by adding 1 to HorizontalStart and setting
ApertureAdjust to –8/16 UI.

How many Channels before adding

ChannelGroupSpacing.
ChannelGrouping_CURR[3:0] Conditional (DP supports ≥ ’b0000: send all Channels together.
Dual 4’b0000
ChannelGrouping_NEXT[3:0] Channels) ’b000 : insert spacing after every Channel
’b00 0: insert spacing after every Channels
…

Channel Grouping:
The spacing between the last bit of the last
sample of the last channel for a Sample Group
and the first bit of the first Channel for the next
Channel Group.
Additionally, when SubRowInterval = 1:
Spacing_CURR[3:0] The spacing between the last bit of the last
sample of the last Channel in the last Channel
Spacing_NEXT[3:0] Group in an Interval and the first bit of the first
Conditional: sample of the first Channel of the first Channel
###TODO-Author: Per Niel’s (DP supports ≥ Channels) Group in the next Interval.
suggestion: in a future draft: create Dual OR 0 Encoding:
an illustration of the mix of (DP supports 0: Next Row (see Note)
SampleSize>1, Channel Grouping, SubRowIntervals) 1: Immediately next Column
Sample Grouping, and 2: 1 Column left blank
SubRowIntervals. 3: 2 Columns left blank
…
15: 14 Columns left blank
Note:
When SubRowInterval=1 the next sample group
must be transmitted in the same Row, so a
Spacing value of 0 (Next Row) is Reserved.

Ratio between the PHY-dependent forwarded clock

(i.e., the Bit Clock in PHY1 & PHY2, and the Row
Clock in PHY3) and the ADC/DAC Converter clock for
this Data Port.
Encoding is excess-1, i.e.:
0: 1
N: div by (N+1)
ConverterClockDiv_CURR[15:0] Optional, and the DP implements at least enough bits
Dual Optional 0
ConverterClockDiv_NEXT[15:0]. for the ratio between fastest bit clock and the
converter clock for the slowest sample rate supported
by this DP.
Note: the ###TODO-Author explain “Bit Clock”.
Note: the ratio between converter clock and bus
sample rate is ImpDef (e.g., 1 for a simple PDM
device, or the oversampling ratio for a PCM Amp
with a sigma-delta converter).

Ch_<N>_Enable_CURR is cleared to ’b0 by both

Warm Reset and Cold Reset.
Ch0 Mandatory
EnableCh<c>_CURR Ch_<N>_Enable_NEXT is cleared to ’b0 only by
Dual Ch<N> Conditional (when ’b0
EnableCh<c>_NEXT Cold Reset.
channel <N> exists)
A DP supports a contiguous set of channel numbers
starting from Channel 0.

Same behavior as Offset for main DP stream.

Conditional (DP implements
FlowMode 2 or 3)
FCP_Offset_CURR[11:0] Implementation- The Data Port implements contiguously numbered
Dual
FCP_Offset_NEXT[11:0] Defined bits from 0 upwards. The highest numbered Offset bit
Offset[2:0] Mandatory
is between 2 and 11 (and is the same as the highest
Offset[11:3] Optional numbered Interval bit).

FCP_HorizontalStart_CURR[4:0] Conditional (DP implements Same behavior as HorizontalStart for main DP

Dual 5’b0
FCP_HorizontalStart_NEXT[4:0] FlowMode 2 or 3) stream.

FCP_BitWidth_CURR[1:0] Conditional (DP implements

Dual ’b0 Same behavior as BitWidth for main DP stream.
FCP_BitWidth_NEXT[1:0] FlowMode 2 or 3)

Conditional: (Sink DP AND

FCP_TailWidth_CURR[1:0]
Dual DP implements FlowMode 2 ’b0 Same behavior as TailWidth for main DP stream.
FCP_TailWidth_NEXT[1:0]
or 3)

Conditional: (Sink DP AND

FCP_GuardPolarity_CURR
Dual DP implements FlowMode 2 ’b0 Same behavior as GuardPolarity for main DP stream.
FCP_GuardPolarity_NEXT
or 3)

Conditional: (Sink DP AND

FCP_GuardEnable_CURR
Dual DP implements FlowMode 2 ’b0 Same behavior as GuardEnable for main DP stream.
FCP_GuardEnable_NEXT
or 3)

Optional AND
FCP_EndHalfEarly_CURR Conditional on (Sink DP AND
Dual ’b0 Same behavior as EndHalfEarly for main DP stream.
FCP_EndHalfEarly_NEXT (DP implements FlowMode 2
or 3))

Offset from the centre of the last UI of the bit (which is

the only UI when not using wide bits).
Conditional on (Source DP 4-bit ’s complement number in / 6ths of a UI.
AND (DP implements ’b 000: –8/16 UI
FlowMode 2 or 3) then: ’b 00 : –7/16 UI
…
FCP_ApertureAdjust_CURR[3:0] ’b : –1/16 UI
Bit 3 Mandatory in
Dual 4’b0000 ’b0000: +0 UI
FCP_ApertureAdjust_NEXT[3:0] PHY3:DLV or
’b000 : +1/16 UI
Bit 3 Optional in …
PHY1/#2:FBCSE ’b0 : +7/ 6 UI
Note:
Bits 2:0 are Optional. An effective value of +8/16 UI can be achieved
by adding 1 to HorizontalStart and setting
ApertureAdjust to –8/16 UI.

14.2.4 Peripheral System and Link Control Registers

7666 Requirements
7667 1. The System and Link Control Register Block shall include Registers defined in Table 151 containing Register Fields described in Table 153.
7668 2. Each SLC_ Register shall have an address calculated from the base address of the System & Link Control Region shown in Table 147 + the Address
7669 Offset from Table 151.
7670 Table 151 Peripheral Register Map for System and Link Control (SLC_*)
Address
Access Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Offset

0x00 RO Version[3:0] DeviceNumber[3:0]

0x01 RO ManufacturerID[15:8]

0x02 RO ManufacturerID[7:0]

0x03 RO PartID[15:8]

0x04 RO PartID[7:0]

0x05 RO Class[7:0]

0x06–
— [ 10 × Reserved]
0x0F
0x10 RW Reserved Reserved Reserved Reserved Reserved Reserved Reserved WakeReqEnable

0x11 RW Reserved Reserved Reserved Reserved PM_Action[3:0]

0x12 RW Reserved Reserved Reserved Reserved SkippingDenominator[11:8]

0x13 RW SkippingDenominator[7:0]

0x14 RW Reserved Reserved Reserved Reserved Reserved SyncPointOffset[2:0]

0x15–
— [15 × Reserved]
0x1F
Force
0x20 W1C Reserved Reserved Reserved Reserved Reserved Reserved Reserved
RemoteFail

DevStat_
DevStat_
0x21 RW1C Reserved Reserved Reserved Reserved Reserved Reserved
LostLock
BadCommandCo
nfidence

IntStat_
IntStat_ IntStat_ IntStat_Abandone IntStat_ IntStat_CalibrationR IntStat_ IntStat_
0x22 RW1C
RemoteDisabled BadCRC dPhase
UnexpectedNew
BadHD10 eq Bad8b10b MissedRowSync
Header

###TODO
0x23 RO Reserved Reserved Reserved Reserved Reserved Reserved Reserved
IntStat_BadRT[1]

0x24–
— [ 3 × Reserved ]
0x26
IntCascade
0x27 RO Reserved Reserved Reserved Reserved Reserved Reserved
_ImpDef
IntCascade_SDCA

0x28 RO IntCascade_DP7 IntCascade_DP6 IntCascade_DP5 IntCascade_DP4 IntCascade_DP3 IntCascade_DP2 IntCascade_DP1 IntCascade_DP0

0x29 RO IntCascade_DP15 IntCascade_DP14 IntCascade_DP13 IntCascade_DP12 IntCascade_DP11 IntCascade_DP10 IntCascade_DP9 IntCascade_DP8

0x2A RO IntCascade_DP23 IntCascade_DP22 IntCascade_DP21 IntCascade_DP20 IntCascade_DP19 IntCascade_DP18 IntCascade_DP11 IntCascade_DP16

0x2B RO IntCascade_DP31 IntCascade_DP30 IntCascade_DP29 IntCascade_DP28 IntCascade_DP27 IntCascade_DP26 IntCascade_DP25 IntCascade_DP24

0x2C–
— [ 6 × Reserved ]
0x31
IntEn_ IntEn_Abandoned IntEn_Unexpecte IntEn_CalibrationRe IntEn_
0x32 RW
RemoteDisabled
IntEn_BadCRC
Phase dNewHeader
IntEn_BadHD10
q
IntEn_Bad8b10b
MissedRowSync

0x33 RW Reserved Reserved Reserved Reserved Reserved Reserved Reserved IntEn_BadRT[1]

0x34–
— [ 12 × Reserved ]
0x3F
0x40 RW1C IntStat_SDCA07 IntStat_SDCA06 IntStat_SDCA05 IntStat_SDCA04 IntStat_SDCA03 IntStat_SDCA02 IntStat_SDCA01 IntStat_SDCA00

0x41 RW1C IntStat_SDCA15 IntStat_SDCA14 IntStat_SDCA13 IntStat_SDCA12 IntStat_SDCA11 IntStat_SDCA10 IntStat_SDCA09 IntStat_SDCA08

0x42 RW1C IntStat_SDCA23 IntStat_SDCA22 IntStat_SDCA21 IntStat_SDCA20 IntStat_SDCA19 IntStat_SDCA18 IntStat_SDCA17 IntStat_SDCA16

0x43 RW1C IntStat_SDCA31 IntStat_SDCA30 IntStat_SDCA29 IntStat_SDCA28 IntStat_SDCA27 IntStat_SDCA26 IntStat_SDCA25 IntStat_SDCA24

0x44 RW1C IntStat_SDCA39 IntStat_SDCA38 IntStat_SDCA37 IntStat_SDCA36 IntStat_SDCA35 IntStat_SDCA34 IntStat_SDCA33 IntStat_SDCA32

0x45 RW1C IntStat_SDCA47 IntStat_SDCA46 IntStat_SDCA45 IntStat_SDCA44 IntStat_SDCA43 IntStat_SDCA42 IntStat_SDCA41 IntStat_SDCA40

0x46 RW1C IntStat_SDCA55 IntStat_SDCA54 IntStat_SDCA53 IntStat_SDCA52 IntStat_SDCA51 IntStat_SDCA50 IntStat_SDCA49 IntStat_SDCA48

0x47 RW1C IntStat_SDCA63 IntStat_SDCA62 IntStat_SDCA61 IntStat_SDCA60 IntStat_SDCA59 IntStat_SDCA58 IntStat_SDCA57 IntStat_SDCA56

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
Address
Access Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Offset
0x48–
— [ 4 × Reserved ]
0x4B
0x4C RW1C IntStat_ImpDef07 IntStat_ImpDef06 IntStat_ImpDef05 IntStat_ImpDef04 IntStat_ImpDef03 IntStat_ImpDef02 IntStat_ImpDef01 IntStat_ImpDef00

0x4D RW1C IntStat_ImpDef15 IntStat_ImpDef14 IntStat_ImpDef13 IntStat_ImpDef12 IntStat_ImpDef11 IntStat_ImpDef10 IntStat_ImpDef09 IntStat_ImpDef08

0x4E RW1C IntStat_ImpDef23 IntStat_ImpDef22 IntStat_ImpDef21 IntStat_ImpDef20 IntStat_ImpDef19 IntStat_ImpDef18 IntStat_ImpDef17 IntStat_ImpDef16

0x4F RW1C IntStat_ImpDef31 IntStat_ImpDef30 IntStat_ImpDef29 IntStat_ImpDef28 IntStat_ImpDef27 IntStat_ImpDef26 IntStat_ImpDef25 IntStat_ImpDef24

0x50 RW IntEn_SDCA07 IntEn_SDCA06 IntEn_SDCA05 IntEn_SDCA04 IntEn_SDCA03 IntEn_SDCA02 IntEn_SDCA01 IntEn_SDCA00

0x51 RW IntEn_SDCA15 IntEn_SDCA14 IntEn_SDCA13 IntEn_SDCA12 IntEn_SDCA11 IntEn_SDCA10 IntEn_SDCA09 IntEn_SDCA08

0x52 RW IntEn_SDCA23 IntEn_SDCA22 IntEn_SDCA21 IntEn_SDCA20 IntEn_SDCA19 IntEn_SDCA18 IntEn_SDCA17 IntEn_SDCA16

0x53 RW IntEn_SDCA31 IntEn_SDCA30 IntEn_SDCA29 IntEn_SDCA28 IntEn_SDCA27 IntEn_SDCA26 IntEn_SDCA25 IntEn_SDCA24

0x54 RW IntEn_SDCA39 IntEn_SDCA38 IntEn_SDCA37 IntEn_SDCA36 IntEn_SDCA35 IntEn_SDCA34 IntEn_SDCA33 IntEn_SDCA32

0x55 RW IntEn_SDCA47 IntEn_SDCA46 IntEn_SDCA45 IntEn_SDCA44 IntEn_SDCA43 IntEn_SDCA42 IntEn_SDCA41 IntEn_SDCA40

0x56 RW IntEn_SDCA55 IntEn_SDCA54 IntEn_SDCA53 IntEn_SDCA52 IntEn_SDCA51 IntEn_SDCA50 IntEn_SDCA49 IntEn_SDCA48

0x57 RW IntEn_SDCA63 IntEn_SDCA62 IntEn_SDCA61 IntEn_SDCA60 IntEn_SDCA59 IntEn_SDCA58 IntEn_SDCA57 IntEn_SDCA56

0x58–
— [ 4 × Reserved ]
0x5B
0x5C RW1C IntEn_ImpDef07 IntEn_ImpDef06 IntEn_ImpDef05 IntEn_ImpDef04 IntEn_ImpDef03 IntEn_ImpDef02 IntEn_ImpDef01 IntEn_ImpDef00

0x5D RW1C IntEn_ImpDef15 IntEn_ImpDef14 IntEn_ImpDef13 IntEn_ImpDef12 IntEn_ImpDef11 IntEn_ImpDef10 IntEn_ImpDef09 IntEn_ImpDef08

0x5E RW1C IntEn_ImpDef23 IntEn_ImpDef22 IntEn_ImpDef21 IntEn_ImpDef20 IntEn_ImpDef19 IntEn_ImpDef18 IntEn_ImpDef17 IntEn_ImpDef16

0x5F RW1C IntEn_ImpDef31 IntEn_ImpDef30 IntEn_ImpDef29 IntEn_ImpDef28 IntEn_ImpDef27 IntEn_ImpDef26 IntEn_ImpDef25 IntEn_ImpDef24

0x60 RO EC_BadCommandConfidence[7:0]

0x61 RO EC_LostLock[7:0]

0x62 RO EC_MissedRowSync[7:0]

0x63 RO EC_Bad8b10b[7:0]

0x64 — Reserved

0x66 RO EC_UnexpectedNewHeader[7:0]

0x67 RO EC_AbandonedPhase [7:0]

0x68 RO EC_BadCRC[7:0]

0x69–
— [ 7 × Reserved ]
0x6F
0x70–
ImpDef [ 16 × ImpDef ]
0x7F

7671 Note:
1. IntStat_BadRT and IntEn_BadRT exist only in the Manager, not in the Peripheral.

7672 3. The System and Link Control Register Block shall include dual-ranked Registers each comprising both:
7673 A. SLC_*_NEXT Registers defined in Table 152 containing SLC_*_NEXT Register Fields described in Table 153, and
7674 B. Corresponding SLC_*_CURR Registers containing SLC_*_CURR fields.
7675 4. Each SLC_*_NEXT Register shall have an address calculated from the base address of the System & Link Control Region shown in Table 147 + the
7676 Address Offset from Table 152.
7677 5. Each SLC_*_CURR Register shall have an address calculated from 0x40 + the address of the corresponding SLC_*_NEXT Register (from
7678 Requirement 4).
7679 Table 152 Peripheral Register Map for System and Link Control Dual-Ranked Registers (SLC_*_NEXT)
Address
Access Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Offset

0x80 Dual Reserved Reserved Reserved Reserved UI_RateRange_NEXT[3:0]

0x81 Dual Reserved Reserved Reserved NumColumns_NEXT[4:0]

0x82 Dual RowRateRange_NEXT[7:0]

ShortProtocol
0x83 Dual Reserved Reserved Reserved Reserved Reserved Reserved Reserved
Spacer

0x84–
— [ 44 × Reserved ]
0xAF

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
Address
Access Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Offset
0xB0–
ImpDef [ 16 × ImpDef ]
0xBF

14.2.5 Peripheral System and Link Control Register Fields

7680 Requirements
7681 1. The System & Link Control Register Fields shall be implemented according to Table 153.
7682 Note: the full names of all of these fields are preceded by “SLC_”, e.g., SLC_DeviceNumber.

7683 Table 153 System and Link Control Register Fields (SLC_*)

Mandatory / Conditional / Cold Reset

Field Name Access Description & Encoding
Optional / … Value

Device Number. Valid value between 0 and 11.

DeviceNumber[3:0] RO Mandatory Imp-Def
(See Section 8.1.1.5.3).

Indicates which version of the SWI3S

Specification describes the behavior and
Registers of this Device:
’b 000: SWI3S v .0
Note:
This encoding is chosen to be
Version[3:0] RO Mandatory b1000
non-overlapping with the Version field
within SoundWire devices (see [MIPI01]),
which, as of SoundWire v1.2.1 were:
’b00 : SoundWire v .
’b00 0: SoundWire v .
’b000 : SoundWire v .0

MSByte of 2-byte MIPI manufacturer code

ManufacturerID[15:8] RO Mandatory Per Manufacturer
(see [MIPI04]).

LSByte of 2-byte MIPI manufacturer code

ManufacturerID[7:0] RO Mandatory Per Manufacturer
(see [MIPI04]).

Imp-Def coding interpreted in the context of

PartID[15:0] RO Mandatory Imp-Def
ManufacturerID.

0x00: No class information

0x01: This device implements SDCA
Class[7:0] RO Mandatory Imp-Def (see [MIPI02]).
0x02–0x0F: Reserved

Enables the Peripheral to use internal ImpDef

conditions as a trigger either:
• To exit from Link State:
Ready_for_Sleeping or Dormant (see
Section 5.2.2 Permission 9 and 7), or:
• To generate an LC_Request to the
Manager to exit from Link State:
Sleeping (see Section 5.2.2
Permission 2).
WakeReqEnable RW Optional 0 Note:
Support for exiting from Link State:
Ready_for_Sleeping is optional even in a
Peripheral that can exit from Dormant.
Note:
This bit does not control Cold Boot
Request (LC_Requests made when in
Link State: Cold_Standby).

Peripheral Management Action used by the

Manager to control Peripheral Link State (see
Section 5.2.2 Requirement ###XREF):
’b0000: Stay_Attached.
’b00 0: Force_Resync.
’b0 00: Enter_ Dormant.
b0000
PM_Action[3:0] RW Mandatory ’b 000: Enter_Sleeping.
(Stay_Attached) ’b 00: Enter_Cold_Standby.
Note:
Some of the effects of Enter_Sleeping &
Enter_Cold_Standby are deferred until
the Manager stops the Audio-mode PHY.

Used to control Interval Skipping in Data Ports

Implementation- (where the Sample Rate is not simply related
SkippingDenominator[11:0] RW SkippingDenominator[11:0] Optional
Defined to the Row Rate).
See ###XREF.

Number of Rows subtracted from RowDelay

parameter in SSPA, SSCR, and DSCR
SyncPointOffset[2:0] RW Mandatory 0
Commands (see Section ###XREF
Requirement ###XREF).

If the Peripheral is still busy with a remote

read or write operation then writing a 1 to this
Conditional (Peripheral implements bit changes the RemoteAccessState to
ForceRemoteFail W1C —
any remote registers) Remote_Disabled. (otherwise writing a 1 has
no effect).
Writing a 0 has no effect.

Indicates that the Peripheral had detached

from the bus due to losing Command
DevStat_BadCommandConfidence RW1C Mandatory ’b0 confidence.
###XREF:

EC_BadCommandConfidence [7:1]
Optional Counter for Bad Command Confidence
EC_BadCommandConfidence[7:0] RO 8’b0
EC_BadCommandConfidence [0] events.
Mandatory

Indicates that the Peripheral had detached

Conditional (when PHY3, DLV, is from the bus due to losing Clock recovery
DevStat_LostLock RW1C ’b0
implemented) (PLL/DLL).
###XREF: PHY3 / DLV

EC_LostLock[7:1] Optional
EC_LostLock[7:0] RO 8’b0 Counter for Lost Lock events.
EC_LostLock[0] Mandatory

Conditional (when PHY3, DLV, is 1 or more RowSync Sequences (S0/S1) was

IntStat_MissedRowSync RW1C ’b0
implemented) missing.

Conditional (when PHY3, DLV, is

IntEn_MissedRowSync RW ’b0 Interrupt Enable for IntStat_MissedRowSync.
implemented)

EC_MissedRowSync[7:1] Optional
EC_MissedRowSync[7:0] RO 8’b0 Counter for MissedRowSync events.
EC_MissedRowSync[0] Mandatory

CDS word cannot be mapped to a valid byte.

Note: this condition is not generated during
IntStat_Bad8b10b RW1C Mandatory ’b0
HD10 tokens, even if they are not a valid
8b10b symbol.

IntEn_Bad8b10b RW Mandatory ’b0 Interrupt Enable for IntStat_Bad8b10b.

EC_Bad8b10b[7:1] Optional
EC_Bad8b10b[7:0] RO 8’b0 Counter for Bad8b10b events.
EC_Bad8b10b[0] Mandatory

PHY3 is requesting that the Manager performs

Conditional (Peripheral implements a Calibration Command (e.g., because the
IntStat_CalibrationReq RW1C ’b0
PHY3, DLV). Device knows that its temperature has
changed).

Conditional (Peripheral implements

IntEn_CalibrationReq RW ’b0 Interrupt Enable for IntStat_CalibrationReq.
PHY3, DLV).

CDS word, expected HD10 has been received

IntStat_BadHD10 RW1C Mandatory ’b0 corrupted. The decoder decoded it anyway to
the closest HD10 word.

IntEn_BadHD10 RW Mandatory ’b0 Interrupt Enable for IntStat_BadHD10.

EC_BadHD10[7:1] Optional
EC_BadHD10[7:0] RO 8’b0 Counter for BadHD10 events.
EC_BadHD10[0] Mandatory

A Valid Phase Header (SPM + 6RT) has been

detected during an ongoing Phase.
IntStat_UnexpectedNewHeader RW1C Mandatory ’b0
Note this is not applicable to COMMIT Phases
waiting for peripheral responses.

Interrupt Enable for

IntEn_UnexpectedNewHeader RW Mandatory ’b0
IntStat_UnexpectedNewHeader.

EC_UnexpectedNewHeader [7:1]
Optional
EC_UnexpectedNewHeader[7:0] RO 8’b0 Counter for UnexpectedNewHeader events.
EC_UnexpectedNewHeader [0]
Mandatory

IntStat_AbandonedPhase RW1C Mandatory ’b0 ###TODO-Author.

IntEn_AbandonedPhase RW Mandatory ’b0 Interrupt Enable for IntStat_AbandonedPhase.

EC_AbandonedPhase [7:1]
Optional
EC_AbandonedPhase [7:0] RO 8’b0 Counter for AbandonedPhase events.
EC_AbandonedPhase [0]
Mandatory

Mismatch between the computed CRC and

IntStat_BadCRC RW1C Mandatory ’b0 the received CRC following either a Manager
Packet or a Peripheral Packet.

IntEn_BadCRC RW Mandatory ’b0 Interrupt Enable for IntStat_BadCRC.

EC_BadCRC[7:1] Optional
EC_BadCRC[7:0] RO 8’b0 Counter for BadCRC events.
EC_BadCRC[0] Mandatory

Conditional (Peripheral implements The Remote Access Status FSM has entered
IntStat_RemoteDisabled RW1C ’b0
any remote registers) state Remote_Disabled.

Conditional (Peripheral implements

IntEn_RemoteDisabled RW ’b0 Interrupt Enable for IntStat_RemoteDisabled.
any remote registers)

The Manager received a symbol in the CDS

Mandatory in a Manager.
IntStat_BadRT RW1C ’b0 that was not one of the 16 special D-codes
Not implemented in a Peripheral. assigned to Robust Tokens.

Mandatory in a Manager.
IntEn_BadRT RW ’b0 Interrupt Enable for IntStat_BadRT.
Not implemented in a Peripheral.

Conditional (Peripheral implements

Logical OR of the 64 IntStat_SDCAnn
IntCascade_SDCA RO at least one of —
interrupts.
IntStat_SDCA_63:00)

Conditional (Peripheral implements Logical OR of the interrupts from the

IntCascade_DPn (n=00…3 ) RO —
DPn) corresponding Data Port (i.e., DPn_IntStat_*).

Conditional (Peripheral implements

IntCascade_ImpDef RO — Logical OR of the IntStat_ImpDef_* interrupts.
any of IntStat_ImpDef_*).

DisCo data for the SDCA Peripheral identifies

Conditional (Peripheral implements
IntStat_SDCA_63:00 RW1C 0 the condition assigned to each numbered
SDCA and this interrupt number)
IntStat.

Conditional (Peripheral implements

IntEn_SDCA_63:00 RW the correspondingly numbered 0 Interrupt Enable for IntStat_SDCA_nn.
IntStat_SDCA_nn)

Conditional (Peripheral implements

IntStat_ImpDef_31:00 RW1C 0 Implementation-defined interupt condition.
this ImpDef interrupt number)

Conditional (Peripheral implements

IntEn_ImpDef_31:00 RW the correspondingly numbered 0 Interrupt Enable for IntStat_ImpDef_nn.
IntStat_ImpDef_nn)

Excess-1 encoded, e.g.:

b00001: 2 columns
Depends on which b01111: 16 columns
PHY has been b10111: 24 columns
NumColumns_CURR[4:0] selected: Number of columns is limited in some PHYs,
Dual Mandatory
NumColumns_NEXT[4:0] PHY1: 2 cols e.g., only even numbers in PHY1&2 (FBCSE).
PHY2: 2 cols Cold Reset values:
PHY3: 4 cols PHY1: Register: b00001 (2 Columns).
PHY2: Register: b00001 (2 Columns).
PHY3: Register: b00011 (4 Columns).

Depends on which
Depends on which PHY has been
PHY has been Unit Interval Rate Range, see Table 127.
RO selected:
UI_RateRange_CURR[4:0] selected: For some PHYs this is defined to be a
or PHY1: Read-only 0
UI_RateRange_NEXT[4:0] PHY1: RO:0 read-only 0 (and value 0 means Peripheral
Dual PHY2: Read-only 0
PHY2: RO:0 behavior is not dependent upon this register).
PHY3: either Dual or Read-only 0.
PHY3: 4 (or RO:0)

Encoding: see Table 25.

PHY1: 0
RO For PHYs where the Peripheral can operate
PHY2: 0
RowRateRange_CURR[7:0] (at least in Command-Only) without knowing
or Optional PHY3: 0x3A
RowRateRange_NEXT[7:0] the Row Rate (e.g., PHY1 & PHY2), the value
Dual (2.40–3.20 0 means that the Manager has not provided
MRows/s) row rate information to the Peripheral.

Controls the expected size of the

Peripheral-to-Manager Protocol Spacer (see
ShortProtocolSpacer_CURR 0
Dual Mandatory Section ###XREF Requirement ###XREF):
ShortProtocolSpacer_NEXT 0
0: PM Protocol Spacer is 20 Rows.
1: PM Protocol Spacer is 10 Rows.

14.2.6 Peripheral Control Data Stream Transport Registers

7684 Requirements
7685 1. The Control Data Stream Transport Register Block shall include Registers defined in Table 154.
7686 2. Each CDS_* Register shall have an address calculated from the base address of the Control Data Stream Transport Region shown in Table 147 + the
7687 Address Offset from Table 154.
7688 Table 154 Peripheral Register Map for Control Data Stream Registers (CDS_*)
Address
Access Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Offset
0x00–
— [ 112 × Reserved ]
0x6F
0x70–
ImpDef [ 16 × ImpDef ]
0x7F

7689 3. The Control Data Stream Transport Register Block shall include dual-ranked Registers each comprising both:
7690 A. CDS_*_NEXT Registers defined in Table 155 containing CDS_*_NEXT Register Fields described in ###XREF, and
7691 B. Corresponding CDS_*_CURR Registers containing CDS_*_CURR fields.
7692 4. Each CDS_*_NEXT Register shall have an address calculated from the base address of the Control Data Stream Transport Region shown in Table 147 +
7693 the Address Offset from Table 155.
7694 5. Each CDS_*_CURR Register shall have an address calculated from 0x40 + the address of the corresponding CDS_*_NEXT Register (from
7695 Requirement 4).
7696 Table 155 Peripheral Register Map for Control Data Stream Dual-Ranked Registers (CDS_*_NEXT)
Address
Access Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Offset
0x80–
— [ 4 × Reserved ]
0x83
0x84 Dual Reserved Reserved Reserved CDS_HorizontalStart_NEXT[4:0]

0x85 — Reserved

CDS_DriveType
0x86 Dual
_NEXT
Reserved Reserved Reserved Reserved Reserved Reserved Reserved

CDS_ CDS_ CDS_

0x87 Dual CDS_BitWidth_NEXT[2:0] EndHalfEarly GuardEnable GuardPolarity CDS_TailWidth_NEXT[1:0]
_NEXT _NEXT _NEXT

0x88 — Reserved

0x89 Dual CDS_ApertureAdjust_NEXT[3:0] Reserved Reserved Reserved Reserved

0x8A–
— [ 38 × Reserved ]
0xAF
0xB0–
ImpDef [ 16 × ImpDef ]
0xBF

14.2.7 Peripheral Control Data Stream Transport Register Fields

7697 ###Notes for reviewers:
7698 Stefano’s questions for reviewers are highlighted in yellow in this table.

7699 Requirements
7700 1. Control Data Stream Transport Register Fields shall be implemented according to Table 156.
7701 Table 156 Control Data Stream Transport Register Fields (CDS_*)

Mandatory / Cold Reset

Field Name Access Conditional / Description & Encoding
Value
Optional / …

PHY1 or #2:
RO, RO. First owned UI in the Row that is used for the CDS. Reset value and
CDS_HorizontalStart_CURR[4:0] PHY-depend valid values are both PHY-dependent.
Mandatory
CDS_HorizontalStart_NEXT[4:0] PHY3: ent value. • PHY1/2: Fixed at 0.
RO-Dual • PHY3: reset value=2 but Manager can re-program it.
RW-Dual

Conditional
(Required in a
Peripheral that
CDS_DriveType_CURR RO-Dual 0: Special (Passive 1, Active 0)
implements PHY3) 0
CDS_DriveType_NEXT RW-Dual 1: Normal (Active 1, Active 0)
Optional (when the
Peripheral does not
implement PHY3).

PHY1:
RO
RO Tails are counted after any Guard. Not impacted by BitWidth.
b00: 0 UI (fixed RO value when using PHY1)
CDS_TailWidth_CURR[1:0]
Mandatory 0 b01: 1 UIs
CDS_TailWidth_NEXT[1:0] PHY2 or b10: 2 UIs
PHY3: b11: Reserved.
RO-Dual
RW-Dual

Conditional (on
When GuardEnable is ’b :
CDS_GuardPolarity_CURR RO-Dual GuardEnable being
0 0: drive 0 as GuardBit.
CDS_GuardPolarity_NEXT RW-Dual implemented, per
1: drive 1 as GuardBit.
PHY).

’b0: GuardBit are not active.

CDS_GuardEnable_CURR RO-Dual ’b1: GuardBit are active. After driving the CDS bit, add GuardBit
Optional (per PHY) ’b0
CDS_GuardEnable_NEXT RW-Dual with the specified polarity.
Guard bits are not impacted by the CDS_BitWidth setting.

’b0: drive to the end of the UI.

Mandatory in DLV
’b1: stop driving 1/2 UI early.
CDS_EndHalfEarly_CURR RO-Dual (PHY3)
’b0 When releasing ownership of the bus (going to Hi-Z, after the last bit
CDS_EndHalfEarly_NEXT RW-Dual Optional in FBCSE
of the latest of data or guard or tail), stop driving one UI (1/2 column)
(PHY1/PHY2)
early.

All 3 bits are

Mandatory in DLV
Excess-1 number of UIs (similar to DP BitWidth_CURR[1:0]):
(PHY3)
b000: 1 UI
CDS_BitWidth_CURR[2:0] RO-Dual FBCSE (PHY1/2)
b001: 2 UIs
supports from 0 to 3 0
CDS_BitWidth_NEXT[2:0] RW-Dual b010: 3 UIs
register bits, i.e.,
…
values of either {1},
b111: 8 UIs
{1,2}, {1,2,3,4} or
{1,2,3,4,5,6,7,8}.

Offset from the centre of the last UI of the bit (which is the only UI
when not using wide bits).
4-bit ’s complement number in 1/16ths of a UI.
’b 000: –8/16 UI
Bit 3 Mandatory in ’b 00 : –7/16 UI
PHY3:DLV or …
CDS_ApertureAdjust_CURR[3:0] RO-Dual Bit 3 Optional in ’b : –1/16 UI
4’b0000 ’b0000: +0 UI
CDS_ApertureAdjust_NEXT[3:0] RW-Dual PHY1/#2:FBCSE
Bits 2:0 are always ’b000 : + / 6 UI
Optional. …
’b0 : +7/ 6 UI
Note:
For PHY3, an effective value of +8/16 UI can be achieved by
adding 1 to HorizontalStart and setting ApertureAdjust to –
8/16 UI.

14.2.8 Peripheral PHY1 and #2 (FBCSE) Registers

7702 Requirements
7703 1. The PHY1 Register Block shall include Registers defined in Table 157.
7704 2. The PHY2 Register Block shall include Registers defined in Table 157.
7705 3. Each PHY1_* or PHY2_* Register shall have an address calculated from the base address of the PHY1 or PHY2 Region shown in Table 147 + the
7706 Address Offset from Table 157.
7707 Table 157 Peripheral Register Map for PHY1 & PHY2 Registers (PHY1_*, PHY2_*)
Address
Access Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Offset
0x00–
— [ 112 × Reserved ]
0x6F
0x70–
ImpDef [ 16 × ImpDef ]
0x7F

7708 4. The PHY1 Register Block shall include dual-ranked Registers each comprising both:
7709 A. PHY1_*_NEXT Registers defined in Table 158 containing PHY1_*_NEXT Register Fields described in Table 159, and
7710 B. Corresponding PHY1_*_CURR Registers containing PHY1_*_CURR fields.
7711 5. The PHY2 Register Block shall include dual-ranked Registers each comprising both:
7712 A. PHY2_*_NEXT Registers defined in Table 158 containing PHY2_*_NEXT Register Fields described in Table 159, and
7713 B. Corresponding PHY2_*_CURR Registers containing PHY2_*_CURR fields.
7714 Note: A Peripheral that implements both PHY1 and PHY2 also implements PHY control registers in both blocks of addresses, but these are typically 2
7715 aliasses of the same storage locations, see Permission 1.
7716 6. Each PHY1_*_NEXT or PHY2_*_NEXT Register shall have an address calculated from the base address of the PHY1 or PHY2 Region shown in
7717 Table 147 + the Address Offset from Table 158.

All rights reserved.
Confidential
DRAFT Specification for SoundWire I3S Version 0.6 r01
21-Sep-2024
7718 7. Each PHY1_*_CURR or PHY2_*_CURR Register shall have an address calculated from 0x40 + the address of the corresponding PHY1_*_NEXT or
7719 PHY2_*_NEXT Register (from Requirement 6).
7720 Table 158 Peripheral Register Map for PHY1 and PHY2 Dual-Ranked Registers (PHY1_*_NEXT, PHY2_*_NEXT)
Address
Access Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Offset

0x80 Dual PHYn_RiseFallTimeGRamp_NEXT[3:0] PHYn_RiseFallTimeVRamp_NEXT[3:0]

0x81 Dual Reserved Reserved PHYn_DriveImpedance_NEXT[2:0] Reserved Reserved Reserved

0x82 Dual Reserved Reserved Reserved Reserved PHYn_FirstBitRampType_NEXT[1:0] PHYn_AdjBitRampType_NEXT[1:0]

0x83–
— [ 45 × Reserved ]
0xAF
0xB0–
ImpDef [ 16 × ImpDef ]
0xBF

7721 Note:
7722 In this Table, register fields with a name starting with “PHYn_” describe 2 fields with names starting with PHY1_ and PHY2_.

7723 Permissions
7724 1. A Peripheral may re-use the same register storage for the PHY1 and PHY2 Register Blocks.

7725 Requirements
7726 1. The PHY1 or PHY2 Register Fields shall be implemented according to Table 159.
7727 Table 159 Peripheral PHY1 or PHY2 (FBCSE) Register Fields (PHY1_*, PHY2_*)

Mandatory / Conditional / Reset

Field Name Access Description & Encoding
Optional / … Value

PHYn_RiseFallTimeVRamp_CURR[3:0] 5 Output Rise/Fall Time for Voltage Ramp.

Dual Mandatory
PHYn_RiseFallTimeVRamp_NEXT[3:0] (4–6 ns) ###XREF to PHY Table

PHYn_RiseFallTimeGRamp_CURR[3:0] 5 Output Rise/Fall Time for Conductance Ramp.

Dual Mandatory
PHYn_RiseFallTimeGRamp_NEXT[3:0] (4–6 ns) ###XREF to PHY Table

PHYn_DriveImpedance_CURR[2:0] 4 Series output resistance.

Dual Mandatory
PHYn_DriveImpedance_NEXT[2:0] (44.5 Ω) (see Table 118)

The type of Ramp used between 2 adjacent bits

that are owned by this Device:
PHYn_AdjBitRampType_CURR[1:0] Adjacent bits drive type.
Dual Mandatory 2 0: Disable Output Ramping.
PHYn_AdjBitRampType_NEXT[1:0]
1: Use Conductance ramp (G-Ramp).
2: Use Voltage-ramp (V-Ramp).
3: Reserved.

The type of Ramp used when the previous bit

was not owned by this Device:
PHYn_FirstBitRampType_CURR[1:0] 0: Disable Output Ramping.
Dual Mandatory 1
PHYn_FirstBitRampType_NEXT[1:0] 1: Use Conductance ramp (G-Ramp).
2: Use Voltage-ramp (V-Ramp).
3: Reserved.

7728 Note:
7729 In this Table, register fields with a name starting with “PHYn_” describe 2 fields with names starting with PHY1_ and PHY2_.

14.2.10 Peripheral PHY3 (DLV) Registers

7730 Requirements
7731 1. The PHY3 Register Block shall include Registers defined in Table 160 containing Register Fields described in Table 162.
7732 2. Each PHY3 Register shall have an address calculated from the base address of the PHY3 Region shown in Table 147 + the Address Offset from
7733 Table 160.
7734 Table 160 Peripheral Register Map for PHY3 (PHY3_*)
Address
Access Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Offset

0x00 RW PHY3_CalibrationDelayMin[07:00]

0x01 — Reserved

0x02 — Reserved

0x03 — Reserved

0x04 RW PHY3_CalibrationDelayMax[07:00]

0x05 — Reserved

0x06 — Reserved

0x07 — Reserved

0x08 RW PHY3_CalibrationImpDef[07:00]

0x09 RW PHY3_CalibrationImpDef[15:08]

0x0A–
— [ 102 × Reserved ]
0x6F
0x70–
ImpDef [ 16 × ImpDef ]
0x7F

All rights reserved.
Confidential
Version 0.6 r01 DRAFT Specification for SoundWire I3S
21-Sep-2024
7735 3. The PHY3 Register Block shall include dual-ranked Registers each comprising both:
7736 A. PHY3_*_NEXT Registers defined in Table 161 containing SLC_*_NEXT Register Fields described in Table 162, and
7737 B. Corresponding PHY3_*_CURR Registers containing PHY3_*_CURR fields.
7738 4. Each PHY3_*_NEXT Register shall have an address calculated from the base address of the PHY3 Region shown in Table 147 + the Address Offset
7739 from Table 161.
7740 5. Each PHY3_*_CURR Register shall have an address calculated from 0x40 + the address of the corresponding PHY3_*_NEXT Register (from
7741 Requirement 4).
7742 Table 161 Peripheral Register Map for PHY3 Dual-Ranked Registers (PHY3_*_NEXT)
Address
Access Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Offset

0x80 Dual PHY3_RiseFallTimeGRamp_NEXT[3:0] PHY3_RiseFallTimeVRamp_NEXT[3:0]

0x81 Dual PHY3_Hysteresis_NEXT[1:0] PHY3_DriveImpedance_NEXT[2:0] PHY3_SEOutputSwing_NEXT[2:0]

0x82 Dual Reserved Reserved Reserved Reserved PHY3_FirstBitRampType_NEXT[1:0] PHY3_AdjBitRampType_NEXT[1:0]

0x83–
— [ 5 × Reserved ]
0x87
0x88 Dual PHY3_CalibrationDelay_NEXT[07:00]

0x89–
— [ 39 × Reserved ]
0xAF
0x80–
ImpDef [ 16 × ImpDef ]
0xBF

7743 Requirements
7744 1. The PHY3 Register Fields shall be implemented according to Table 162.
7745 Table 162 Peripheral PHY3 (DLV) Register Fields (PHY3_*)

Mandatory /
Reset
Field Name Access Conditional / Optional / Description & Encoding
Value
…

PHY3_RiseFallTimeVRamp_CURR[3:0] 5 Output Rise/Fall Time for Voltage Ramp.

Dual Mandatory
PHY3_RiseFallTimeVRamp_NEXT[3:0] (4–6 ns) ###XREF to PHY Table

PHY3_RiseFallTimeGRamp_CURR[3:0] 5 Output Rise/Fall Time for Conductance Ramp.

Dual Mandatory
PHY3_RiseFallTimeGRamp_NEXT[3:0] (4–6 ns) ###XREF to PHY Table

Nominal single-ended output swing (VSEOS_NOM).

Mandatory,
(see Table 129).
PHY3_SEOutputSwing_CURR[2:0] but supporting each of 3 Note:
Dual values 0, 1, 2, 4, 5, 6,
PHY3_SEOutputSwing_NEXT[2:0] (200 mV) All values except 3 are optional, so these
and 7 is independently
registers could be implemented as read-only
optional.
value b011.

PHY3_DriveImpedance_CURR[2:0] Single Ended Series output resistance.

Dual Mandatory 4
PHY3_DriveImpedance_NEXT[2:0] (see Table 131).

Hysteresis control.
PHY3_Hysteresis_CURR[1:0] 0: Minimal
Dual Mandatory 1 1: (5–15%) of programmed VSEOS_NOM
PHY3_Hysteresis_NEXT[1:0]
2: (20–60%) of programmed VSEOS_NOM
3: Reserved

The type of Ramp used between 2 adjacent bits

that are owned by this Device:
PHY3_AdjBitRampType_CURR[1:0] Adjacent bits drive type.
Dual Mandatory 2 0: Disable Output Ramping.
PHY3_AdjBitRampType_NEXT[1:0]
1: Use Conductance ramp (G-Ramp).
2: Use Voltage-ramp (V-Ramp).
3: Reserved.

The type of Ramp used when the previous bit

was not owned by this Device:
PHY3_FirstBitRampType_CURR[1:0] 0: Disable Output Ramping.
Dual Mandatory 1
PHY3_FirstBitRampType_NEXT[1:0] 1: Use Conductance ramp (G-Ramp).
2: Use Voltage-ramp (V-Ramp).
3: Reserved.

CalibrationDelay_CURR is the delay value

currently in use in the Peripheral PHY.
8-bit unsigned number with 5 fractional bits,
i.e.,3.5, (of which the LSb is optionally read-only
0).
Bits 7, 6, 5: mandatory integer part.
PHY3_CalibrationDelay_CURR[7:0] Bits 4, 3, 2, 1: mandatory fractional part.
Dual Mandatory 0xA0 (−1.00 UI)
PHY3_CalibrationDelay_NEXT[7:0] Bit 0: optional fractional part.
Encoding is offset by 6 UI so that, e.g.:
000.00000: launch -6 UI early
101.00000: launch -1 UI early (reset value)
110.00000: +0 UI
110.00001: launch +1/32 UI late
111.111111: launch +1 and 31/32 UI

Same format of number as

PHY3_CalibrationDelayMin[7:0] RW Mandatory 0x00 (−6.00 UI)
PHY3_CalibrationDelay_CURR.

Same format of number as

PHY3_CalibrationDelayMax[7:0] RW Mandatory 0xFF (+1.F8 UI)
PHY3_CalibrationDelay_CURR.

PHY3_CalibrationImpDef[15:0] RW Optional ImpDef Impdef

15 [Draft Notes] Interrupts

7746 ###TODO-Author: Write a basic description of the interrupts based on SoundWire v1.2.1.

15.1 Description (informative)

15.1.1 Interrupt Model

15.1.1.1 Register Bits Associated with Interrupts

7747 Each interrupt source is associated with 2 register bits:
7748 IntStat_name: RW1C. Interrupt status (read/write 1 to clear).
7749 IntEn_name: RW interrupt mask. 1 => interrupt is enabled (i.e., Ping will report Alert if
7750 IntStat_name=1).
7751 The IntStat_name bit is the raw status and can be 1 even when IntEn_name=0.

7752 AlertStatus = (IntStat[0] AND IntEn[0]) OR

7753 (IntStat[1] AND IntEn[1]) OR
7754 ... OR
7755 (IntStat[N] AND IntEn[N]);

7756 Figure 181 shows an equivalent circuit for 1 IntStat chanel and the accompanying IntEn enable bit. The
7757 saturating counter register (colored red) is used for some error counters (EC_xyz).

Data written to IntEn_XYZ Read register containing IntEn_XYZ

D Q3

NOTE: Q1 and Q2 are synchronous SR flip-flops, IntActive_XYZ output feeds into

i.e., S and R are synchronous set and reset OR-tree that drives both:
inputs (not asynchronous preset and clear). • Cascade signal in register
• Alert_Status in Ping commands
Momentary detection
of fault condition XYZ
S Q1
Read register containing IntStat_XYZ
S Q2
Successful Read from R
register containing
IntStat_XYZ
R
CountUp
Successful Write of 1 to
register containing Saturating
IntStat_XYZ Counter
Output Read register containing Count_XYZ

Sync_Reset
7758
Figure 181 Interrupt Channel (with Optional Saturating Error Counter)
7759 ###TODO-Author in v0.7: add a simple waveform diagram illustrating successful and unsuccessful
7760 writes to the IntClear Register. Maybe include a >1-bit error counter in this.
7761 ###TODO-Author: (from AudioWG telco 26 September) clarify (somewhere) that DevStatClear has
7762 the same interlock behavior as IntStatClear: the only difference between DevStat and IntStat is that
7763 DevStat does not have an IntEnable_XYZ.

15.1.2 Interrupt Cascade Model

7764 ###TODO-Author in v0.7: expand on this:
7765 Cascade bits (e.g., IntCascade_DP0) are purely combinatorial and in separate registers.
7766

15.1.3 Error Counters

7767 ###TODO-Author: explain saturating error counters: 1 or more RW1C bits, IntStat_<X> is set when the
7768 value changes from zero to non-zero. Counter is cleared when the corresponding RW1C IntStat_ bit is
7769 cleared. In some corner cases, events can be underreported, but >=1 errors is never turned into zero errors.
7770 (###TODO-Author: add a Note: there is no error counter to indicate events that can easily be
7771 determined from the Command Protocol responses, e.g., a buffered write being abandoned that
7772 causes the Remote Access State to change to Remote_Disabled.

15.2 Specifications (normative)

15.2.1 Error Counters

7773 Requirements
7774 1. After any Cold Reset, every Error Counter that is implemented in a Peripheral or Manager shall be
7775 reset to 0.
7776 2. When an Error Counter is active (see Requirement ###XREF and Permission ###XREF) and the
7777 related Error Condition occurs (see Table 163 or Table 164), an Error Counter shall either:
7778 A. Increment by 1, or:
7779 B. Remain at the maximum value that can be represented by the number of bits that are
7780 implemented in the Error Counter (i.e., not wrap to 0), see Permission 3.
7781 Note: see also Section ###XREF Permission ###XREF.
7782 ###TODO-Author: Section # Permission # permits error counters to be deactivated while the Peripheral is
7783 Dormant. Need to describe somewhere that DP error counters are always deactivated except when one or
7784 more channels is enabled (so going to Dormant would always correctly deactivate them).
7785 3. A Peripheral shall implement all of the Error Counters for which Table 163 indicates “P” or “MP”.
7786 4. A Manager shall implement all of the Error Counters for which Table 163 indicates “M” or “MP”.
7787 Table 163 Summary of Error Counters

Error Count Manager or Section & Notes

Not a valid D-code or K-code (see

EC_Bad8b10bSymbol MP 7.2.2 Req 10
Section 8.1.16.2).

Not one of the 16 special D-codes

(this might also increment
EC_BadRobustToken MP 7.2.2 REQ 11
EC_Bad8b10bSymbol), see
Section 8.1.16.3.

Decoder had to apply correction to

EC_BadHD10 MP 7.2.2 REQ 12
HD10 Token, see Section 8.1.16.4.

8.2.2 REQ 1
CRC failure when checking
8.2.2 REQ 2
EC_BadCRC MP Manager/Peripheral Packet, see
(see also Section 8.1.16.5.
8.2.2 REQ 3.B)

Sometimes not all 16 Tokens are valid

within the Protocol, e.g., Peripheral
EC_UnexpectedRobustToken M ### REQ ###XREF
Responses or Calibration Result. (see
Sections 8.1.16.7 & 8.1.16.8).

R-notR mismatch, see

EC_BadPhyCalData P ### REQ ###XREF
Section 8.1.16.6.

Error Count Manager or Section & Notes

Manager error or sampling other

EC_UnexpectedNewHeader P 8.2.1 REQ 6 Peripheral’s Data, see
Section 8.1.16.9.

An existing Phase was abandoned

EC_AbandonedPhase P ### REQ ###XREF before the end due to a new valid
Header.

The Peripheral detached because of

EC_BadCommandConfidence P 5.2.2 REQ 14.D
Bad_Command_Confidence.

The Peripheral did not detect a Sync0

EC_DlvMissedRowSync P ### REQ ###XREF to Sync1 transition at what it believed
was the start of a Row.

EC_DlvLostLock P 5.2.2 REQ 14.C PLL / DLL lost lock to RowSync.

7788 5. For each Data Port, DPn, that is implemented in a Peripheral, the Peripheral shall implement all of
7789 the Error Counters for which Table 164 indicates “P” or “MP”.
7790 6. For each Data Port, DPn, that is implemented in a Manager, the Manager shall implement all of
7791 the Error Counters for which Table 164 indicates “M” or “MP” (see also Permission 1).
7792 ###TODO-Author: Somewhere in the informative description of Data Ports, explain that
7793 DPn_UnexpectedSSP and DPn_COUNT_ReceivedSSP in the Manager are optional, and would be
7794 checking an _internal_ sync signal.
7795 Table 164 Summary of Data Port Error Counters

Event Count Manager or Section & Notes

Applies to Sink Data Ports, and only

when PortMode= either 2 (all-0) or 3
(all-1).
DPn_EC_TestFail_Ch<N> MP ### REQ ###XREF A TestFail condition occurs for each
Payload bit received on Channel N
(and descrambled if enabled, see
###XREF) that does not match the
expected value.

An UnexpectedSSP condition occurs

each time that the Peripheral Data
Port receives an SSP indication on a
P ### REQ ###XREF
Row which the Data Port did not
already consider to be the start of an
Interval (see ###XREF).
DPn_EC_UnexpectedSSP
An UnexpectedSSP condition occurs
each time that the Manager Data Port
Optional: receives an internal sync indication on
### REQ ###XREF
M a Row which the Data Port did not
already consider to be the start of an
Interval (see ###XREF).

Event Count Manager or Section & Notes

Applies to Sink Data Ports When Flow

Mode is b00 (Normal), see Table 143.
A FlowControlFail condition occurs for
each DV_ChN bit (DataValid for
Channel N) received on Channel N
that does not meet the rules for the
current Flow Mode.
When FlowMode = 2
(Sink-Controlled):
DPn_EC_FlowControlFail_Ch<N> MP ### REQ ###XREF
((DREQ=0) AND (DV_ChN=1)) OR
((DREQ=1) AND (DV_ChN=0)).
When FlowMode = 3 (FullAsync):
((DREQ=0) AND (DV_ChN=1)).
When Flow Mode = 1, 2, or 3:
The set of DV_ChN bits has a
different value to
(see ###XREF).

7796 7. For each Data Port, DPn, that is implemented in a Peripheral, the Peripheral shall implement all of
7797 the Event Counters for which Table 165 indicates “P” or “MP”.
7798 Table 165 Summary of Data Port Event Counters

Event Count Manager or Section & Notes

Incremented each time that the Peripheral

P ### REQ ### Data Port receives an SSP indication (see
Section ###XREF)
DPn_COUNT_ReceivedSSP
Incremented each time that the Data Port
Optional:
### REQ ### receives an internal sync indication (see
M Section ###XREF)

7799 Permissions
7800 1. For each Data Port, DPn, that is implemented in a Manager, the Manager may implement all of the
7801 Error Counters for which Table 164 indicates “Optional: M” (see also Requirement 6).
7802 2. For each Data Port, DPn, that is implemented in a Manager, the Manager may implement all of the
7803 Event Counters for which Table 165 indicates “Optional: M”.
7804 3. Each Error counter that is implemented may have between 1 and 8 bits (see Requirement 2.B).

Annex A Hooks for Implementation-Defined Extensions

7805 ###TODO-Author: keep this section in a v1.0 Annex. <= 4 pages.
7806

A.1 System Control

7807 ImpDef_ColdReset
7808 ImpDef_ForceResync (new after v0.5 r07)
7809 Link State (Cold_Standby, Sleep, Attached, Dormant)

A.2 Registers & Address Space

7810 1.5 GBytes of address space (0x1–0x3 and 0x9–0xB).

A.3 Command Operations

7811 Write (local & remote)
7812 Read (local & remote)
7813 Commit events
7814 SSP events
7815 PHY Calibration

A.4 Interrupts
7816 32 IntStat_ImpDef bits in System & Link Control
7817 1 Calibration_Request interrupt in System & Link Control.
7818 2 IntStat_ImpDef bits per Data Port
7819

A.5 Audio Circuitry

7820 PrepareCh<c> output from DP and ReadyCh<c> input ot DP.
7821 Bus Clock, Bit Clock, Sample Clock from DP
7822 ConvertorClockDiv_CURR[..]
7823
7824

Annex B Example Calibration Algorithms for PHY3 (DLV)

7825 #*#NOTES: see flowcharts in Kristian’s presentation:
7826 Document Name: Dynamic Calibration Tutorial and update.pptx
7827 Causeway location https://members.mipi.org/wg/Audio-WG/document/86573
7828 Filename for the latest version: : Dynamic calibration - take 8B.pptx
7829
7830 #1: Manager chooses a number of Measurements (X) for which it expects the Peripheral not to have made
7831 any adjustment.
7832 #2: Manager directs the Peripheral to make a TrimCal with a number of Measurements (10 * N) that is
7833 larger than X.
7834 #3: the Peripheral reports how many measurements (Y) at the end of the (10*N) measurements it did not
7835 make any timing adjustment.
7836 #4: If Y > X then … (the Manager decides that the Calibration might be OK).
7837 #5: The Manager calculates the average value that it received during the last X measurements. The
7838 Manager compares how close this average is to 0.5. If it is “close enough” then the Manager decides that
7839 the Calibration is OK.
7840

B.1 Example Calibration Algorithm: 2-step based on N Previous Values

7841

B.2 Example Calibration Algorithm: Adaptive Step Control

Annex C PHY–Protocol Interface (PPI)

7842 This annex describes a suggested set of signals for an internal interface between parts of a Peripheral that
7843 implement the protocol and PHY behavior.
7844 ###TODO-Author: insert a figure similar to D-PHY 2.5 Figure 1.
7845
7846
7847

Annex D Cross Reference of Device Rule Unique Identifiers

(Informative)
7848 The tables in this section are an informative summary providing an index into the numbered Device Rule
7849 Unique Identifiers (DRUIDs) for quick reference when using the Specification.
7850 The term Rule is used as shorthand for requirement, permission or recommendation. When a Rule is added
7851 or deleted in a version of this Specification, the paragraph numbers for other Rules might change, but the
7852 unique identifier for those Rules will remain unchanged. Thus these unique identifiers are a suitable
7853 cross-reference for use in design and verification documentation that might apply to multiple versions of
7854 the Specification.

7855 Explanation of Table

7856 The abbreviations used in the Type column of the table are as follows:
7857 • REQ – requirement
7858 • PERM – permission
7859 • rec – recommendation.
7860 Entries in the Section and Para columns are hotlinks to the section or exact paragraph within the main body
7861 of the document.
7862 The Change column indicates the version and revision of the document in which the most recent material
7863 change to the Rule occurred (typographical corrections excepted).
7864 Table 166 Index of Device Rule Unique IDs
Rule Section Type Para Changed Rule Section Type Para Changed
6001 5.2.1 REQ 6116 5.2.2 REQ 16
6002 5.2.1 6117 5.2.2 REQ 17
6003 5.2.1 6118 5.2.2 REQ 18
6004 5.2.1 6119 5.2.2 REQ 19
6120 5.2.2 REQ 20
6101 5.2.2 REQ 1 6121 5.2.2 REQ 21
6102 5.2.2 REQ 2 6122 5.2.2 REQ 22
6103 5.2.2 REQ 3 6123 5.2.2 REQ 23
6104 5.2.2 REQ 4 6124 5.2.2 REQ 24
6105 5.2.2 REQ 5 6125 5.2.2 REQ 25
6106 5.2.2 REQ 6 6126 5.2.2 REQ 1
6107 5.2.2 REQ 7 6127 5.2.2 PERM 2
6108 5.2.2 REQ 8 6128 5.2.2 PERM 3
6109 5.2.2 REQ 9 6129 5.2.2 PERM 4
6110 5.2.2 REQ 10 6130 5.2.2 PERM 5
6111 5.2.2 REQ 11 6131 5.2.2 PERM 6
6112 5.2.2 REQ 12 6132 5.2.2 PERM 7
6113 5.2.2 REQ 13 6133 5.2.2 PERM 8
6114 5.2.2 REQ 14 6134 5.2.2 PERM 9
6115 5.2.2 REQ 15 6135 5.2.2 PERM 10

Rule Section Type Para Changed Rule Section Type Para Changed
6136 5.2.2 rec 1 ##02 6.2.2 REQ 2
6137 5.2.2 rec 2 ##03 6.2.2 rec 1
6138 5.2.2 rec 3

6201 5.2.3 REQ 1 ##01 6.2.3 REQ 1

6202 5.2.3 REQ 2 ##02 6.2.3 REQ 1
6203 5.2.3 REQ 3
6204 5.2.3 REQ 4
6205 5.2.3 REQ 5
6206 5.2.3 REQ 6
6207 5.2.3 REQ 7 6501 7.2.1 REQ 1
6208 5.2.3 REQ 8 6502 7.2.1 REQ 2
6209 5.2.3 REQ 9 6503 7.2.1 REQ 3
6210 5.2.3 REQ 10 6504 7.2.1 REQ 4
6211 5.2.3 REQ 11 6505 7.2.1 REQ 5
6212 5.2.3 REQ 12 6506 7.2.1 REQ 6
6213 5.2.3 REQ 13 6507 7.2.1 REQ 7
6214 5.2.3 REQ 14 6508 7.2.1 REQ 8
6215 5.2.3 REQ 5 6509 7.2.1 REQ 9
6216 5.2.3 REQ 15
6217 5.2.3 REQ 16 6601 7.2.2 REQ 1
6218 5.2.3 PERM 1 6602 7.2.2 REQ 2
6219 5.2.3 PERM 2 6603 7.2.2 REQ 3
6220 5.2.3 PERM 3 6604 7.2.2 REQ 4
6221 5.2.3 PERM 4 6605 7.2.2 REQ 5
6222 5.2.3 PERM 5 6606 7.2.2 REQ 6
6223 5.2.3 rec 1 6607 7.2.2 REQ 7
6224 5.2.3 rec 2 6608 7.2.2 REQ 8
6225 5.2.3 rec 3 6609 7.2.2 REQ 9
6226 5.2.3 rec 4 6610 7.2.2 REQ 10
6611 7.2.2 REQ 11
6301 5.2.4 REQ 1 6612 7.2.2 REQ 12
6302 5.2.4 REQ 2 6613 7.2.2 REQ 13
6303 5.2.4 REQ 5 6614 7.2.2 rec 1

##01 6.2.1 REQ 1 6701 7.2.3 REQ 1

##02 6.2.1 REQ 2 6702 7.2.3 REQ 2

##01 6.2.2 REQ 1 6801 7.2.4 REQ

Rule Section Type Para Changed Rule Section Type Para Changed

6901 7.2.5 REQ 7601 9.2.2

7001 8.2.1 REQ 1 7701 9.2.3

7002 8.2.1 REQ 2
7003 8.2.1 REQ 3 7801 9.2.4
7004 8.2.1 REQ 4
7005 8.2.1 REQ 5 7901 9.2.5
7006 8.2.1 REQ 6
7007 8.2.1 REQ 7 8001 9.2.6
7008 8.2.1 REQ 8
7009 8.2.1 REQ 9 8101 9.2.7
7010 8.2.1 REQ 10
7011 8.2.1 REQ 11 8201 9.2.8
7012 8.2.1 REQ 12
7013 8.2.1 REQ 13 8301 9.2.9
7014 8.2.1 REQ 14
7015 8.2.1 REQ 15 8401 9.2.10
7016 8.2.1 REQ 16
7017 8.2.1 REQ 17 8501 10.2.1
…
…
Spacing
of
7101 8.2.2 REQ 1
DRUIDs
8.2.2 REQ 2 in PHY
8.2.2 REQ 3 sections
is TBD
8.2.2 REQ 4
8.2.2 REQ 5
8601 11.2.1
8.2.2 REQ 6
8701 11.2.2
8.2.2 REQ 7
8801 11.2.3
8.2.2 REQ 8
##01 11.2.4

7201 8.2.3

8901 12.2.1
7301 8.2.4
12.2.2
12.2.3
7401 8.2.5

9001
7501 9.2.1

Rule Section Type Para Changed Rule Section Type Para Changed

9101 13.2.1

9201 13.2.2
# obsolete — — v0.# r#
9301 13.2.3 # REQ v0.# r#
# PERM v0.# r#
9401 14.2.1 # rec v0.# r#

9411 14.2.2
9421 14.2.3

9431 14.2.4
9441 14.2.5

9451 14.2.6
9461 14.2.7

9501 14.2.8
9511 14.2.9

9521 14.2.10
9531 14.2.11

9601 15.2.1

7865

Mipi D-PHY Specification v2-5 PDF
100% (1)
Mipi D-PHY Specification v2-5 PDF
234 pages
DisplayPort (DP) 协议标准 V1.4
No ratings yet
DisplayPort (DP) 协议标准 V1.4
866 pages
晶门科技SSD2832 1.5
No ratings yet
晶门科技SSD2832 1.5
178 pages
Mipi M-PHY Specification v5-0
No ratings yet
Mipi M-PHY Specification v5-0
234 pages
Mipi A PHY Specification v1 1 1
No ratings yet
Mipi A PHY Specification v1 1 1
262 pages
SMIA Functional Specification 1.0
No ratings yet
SMIA Functional Specification 1.0
195 pages
The Uganda National Numbering Plan (Under Review)
100% (1)
The Uganda National Numbering Plan (Under Review)
21 pages
All About MIPI C PHY and D PHY
No ratings yet
All About MIPI C PHY and D PHY
8 pages
SCP Manual en Iss2
No ratings yet
SCP Manual en Iss2
148 pages
Mipi C-PHY Specification v1-2 R04a
100% (1)
Mipi C-PHY Specification v1-2 R04a
199 pages
Mipi M-PHY Specification V4-1-Er01
100% (1)
Mipi M-PHY Specification V4-1-Er01
223 pages
Mipi UniPro Specification v1!40!00
0% (1)
Mipi UniPro Specification v1!40!00
397 pages
Er63311 Rev101 121112
No ratings yet
Er63311 Rev101 121112
331 pages
Accessory Design Guidelines PDF
No ratings yet
Accessory Design Guidelines PDF
222 pages
Mipi M-PHY Specification v2.0
No ratings yet
Mipi M-PHY Specification v2.0
96 pages
zxr10 PDF
No ratings yet
zxr10 PDF
100 pages
Intro To SLIMbus
No ratings yet
Intro To SLIMbus
220 pages
Mipi M-PHY Specification v3-0
No ratings yet
Mipi M-PHY Specification v3-0
206 pages
MIPI D-PHY Specification v01-00-00 PDF
No ratings yet
MIPI D-PHY Specification v01-00-00 PDF
125 pages
Camera Serial Interface CSI2 CSI3 Overview
No ratings yet
Camera Serial Interface CSI2 CSI3 Overview
29 pages
Mipi I3c Protocol
No ratings yet
Mipi I3c Protocol
13 pages
Mipi I3C Basic Specification v1 1 1
No ratings yet
Mipi I3C Basic Specification v1 1 1
446 pages
Mipi M-Phy PWM Data Rate
No ratings yet
Mipi M-Phy PWM Data Rate
2 pages
M-PHY Benefits Challenges - Publish
No ratings yet
M-PHY Benefits Challenges - Publish
11 pages
2022 MIPI DevCon Automotive SerDes A PHY
No ratings yet
2022 MIPI DevCon Automotive SerDes A PHY
30 pages
DP v1.4 Mem
No ratings yet
DP v1.4 Mem
873 pages
Mipi Csi2
0% (1)
Mipi Csi2
11 pages
HDMISpecification 13 A
No ratings yet
HDMISpecification 13 A
276 pages
p564094-OV8865 DS PDF
No ratings yet
p564094-OV8865 DS PDF
165 pages
Mipi Whitepaper
No ratings yet
Mipi Whitepaper
30 pages
Sharp Mipi Ls055d1sx04
No ratings yet
Sharp Mipi Ls055d1sx04
36 pages
OV9713 OmniVision
No ratings yet
OV9713 OmniVision
143 pages
Understanding of Mipi I3c White Paper v0.95
No ratings yet
Understanding of Mipi I3c White Paper v0.95
13 pages
Mipi Csi-2 32
No ratings yet
Mipi Csi-2 32
32 pages
Ov2640 DS PDF
100% (1)
Ov2640 DS PDF
47 pages
Digital Visual Interface & TMDS Extensions: White Paper
No ratings yet
Digital Visual Interface & TMDS Extensions: White Paper
32 pages
PIC 16f877a Data Transfer Instructions
No ratings yet
PIC 16f877a Data Transfer Instructions
9 pages
How To Verify MIPI Protocols
No ratings yet
How To Verify MIPI Protocols
6 pages
ArrowDevices MIPI UniPro Verification Checklist
No ratings yet
ArrowDevices MIPI UniPro Verification Checklist
833 pages
HDMI Report
100% (1)
HDMI Report
26 pages
Camara - OV7670
No ratings yet
Camara - OV7670
30 pages
Whitepaper CPHY Vs DPHY April 2016
No ratings yet
Whitepaper CPHY Vs DPHY April 2016
10 pages
Framework For Digital Camera in Linux-In Detail
No ratings yet
Framework For Digital Camera in Linux-In Detail
58 pages
OCP - DC-SCM - 2.1 - LTPI - Ver1.1 RC1
No ratings yet
OCP - DC-SCM - 2.1 - LTPI - Ver1.1 RC1
80 pages
Mt7621 Datasheet
No ratings yet
Mt7621 Datasheet
43 pages
80211bb 2023
No ratings yet
80211bb 2023
37 pages
8023ch 2020
No ratings yet
8023ch 2020
207 pages
Serial Digital Interface
No ratings yet
Serial Digital Interface
8 pages
802 11ac
No ratings yet
802 11ac
29 pages
PDW Definitions: Format 0 (Null) Format 1 (Full Setup)
No ratings yet
PDW Definitions: Format 0 (Null) Format 1 (Full Setup)
3 pages
World Largest Mobile Image Sensor With All Directional Phase Detection Auto Focus Function
No ratings yet
World Largest Mobile Image Sensor With All Directional Phase Detection Auto Focus Function
22 pages
Comapbroadband Resolved
No ratings yet
Comapbroadband Resolved
115 pages
DisplayPort-1 2
No ratings yet
DisplayPort-1 2
515 pages
Spi and I2c
100% (3)
Spi and I2c
11 pages
Mipi Csi2
No ratings yet
Mipi Csi2
11 pages
HDMI CTS V1.4a
No ratings yet
HDMI CTS V1.4a
807 pages
DisplayPort DevCon Presentation DP 1.2 Dec 2010 Rev 2b
No ratings yet
DisplayPort DevCon Presentation DP 1.2 Dec 2010 Rev 2b
34 pages
XDS3000 Dual-Channel Series Oscilloscopes SCPI Protocol - V1.4 (20180525) PDF
100% (1)
XDS3000 Dual-Channel Series Oscilloscopes SCPI Protocol - V1.4 (20180525) PDF
53 pages
Total MIPI Camera IP Solution - CSI 2 v2.1
No ratings yet
Total MIPI Camera IP Solution - CSI 2 v2.1
53 pages
Hdmi Technology (Shashank)
No ratings yet
Hdmi Technology (Shashank)
18 pages
Infiniband V2r1 2 1 Release
100% (1)
Infiniband V2r1 2 1 Release
834 pages
MIPI D-PHY Specification v1-1
No ratings yet
MIPI D-PHY Specification v1-1
121 pages
MIPI Alliance Standard For Display Bus Interface V2.0
No ratings yet
MIPI Alliance Standard For Display Bus Interface V2.0
65 pages
SDN Security Issues and Mitigation Techniques
No ratings yet
SDN Security Issues and Mitigation Techniques
10 pages
Aircrack Documentation Complete
No ratings yet
Aircrack Documentation Complete
14 pages
Daftar Harga Material Komputer
No ratings yet
Daftar Harga Material Komputer
12 pages
Service Manual: Model: MAXIDRIVE3.4
No ratings yet
Service Manual: Model: MAXIDRIVE3.4
42 pages
Research Article: 5G: Vision and Requirements For Mobile Communication System Towards Year 2020
No ratings yet
Research Article: 5G: Vision and Requirements For Mobile Communication System Towards Year 2020
9 pages
Gui 2021
No ratings yet
Gui 2021
18 pages
Walkthrough 1889
No ratings yet
Walkthrough 1889
12 pages
6ES7138 4DA04 0AB0 Datasheet en
No ratings yet
6ES7138 4DA04 0AB0 Datasheet en
4 pages
Unicable Datasheet 174
No ratings yet
Unicable Datasheet 174
6 pages
Digital TV User Manual
No ratings yet
Digital TV User Manual
64 pages
Lab No 9
No ratings yet
Lab No 9
6 pages
Electrical Testing (2) 4 Year Communications Lab of Lasers and Optical Communications
No ratings yet
Electrical Testing (2) 4 Year Communications Lab of Lasers and Optical Communications
16 pages
Switch# Configure Terminal
No ratings yet
Switch# Configure Terminal
5 pages
PLL-based Frequency Discriminator Using The Loop Filter As An Estimator - Izadi2002
No ratings yet
PLL-based Frequency Discriminator Using The Loop Filter As An Estimator - Izadi2002
7 pages
AZ Pricing - Gupshup
No ratings yet
AZ Pricing - Gupshup
78 pages
Shara F Aldin 2019
No ratings yet
Shara F Aldin 2019
8 pages
BRP069A42 4PEN359542-2S Installation Manual English
No ratings yet
BRP069A42 4PEN359542-2S Installation Manual English
12 pages
Fiber Optic Company Manager
No ratings yet
Fiber Optic Company Manager
3 pages
Determine Best Fit Topology
100% (2)
Determine Best Fit Topology
48 pages
Valid SMTP Good @BigDataCombo
No ratings yet
Valid SMTP Good @BigDataCombo
5 pages
IoT & Its Applications Unit-III
No ratings yet
IoT & Its Applications Unit-III
32 pages
G510－HD2U8951M原理图
No ratings yet
G510－HD2U8951M原理图
37 pages
MT8733 Data Sheet
No ratings yet
MT8733 Data Sheet
3 pages
Bekhoff Analog Ut kl4021 - kl4022
No ratings yet
Bekhoff Analog Ut kl4021 - kl4022
1 page
PL 990 English Quick Start
No ratings yet
PL 990 English Quick Start
2 pages
Alteon OS 22.0.2 Application Guide
No ratings yet
Alteon OS 22.0.2 Application Guide
744 pages
Acer Aspire 4560 4560G AMD (Wistron JE40-SB) PDF
No ratings yet
Acer Aspire 4560 4560G AMD (Wistron JE40-SB) PDF
102 pages