Mipi Csi 3.0

Specification for
Camera Serial Interface 2

(CSI-2SM)
Version 3.0
31 May 2019
MIPI Board Adopted 10 September 2019
This document is a MIPI Specification. MIPI member companies’ rights and obligations apply to this MIPI
Specification as defined in the MIPI Membership Agreement and MIPI Bylaws.
Further technical changes to this document are expected as work continues in the PHY Working Group.
Copyright © 2005-2019 MIPI Alliance, Inc.

All rights reserved.
Confidential
Specification for CSI-2 Version 3.0
31-May-2019
NOTICE OF DISCLAIMER
The material contained herein is provided on an “AS IS” basis. 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 Alliance Inc. (“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. ALSO, THERE IS NO
WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION,
CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD TO THIS
MATERIAL.
IN NO EVENT WILL ANY AUTHOR OR DEVELOPER OF THIS MATERIAL 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 RELATING TO
THIS MATERIAL, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE
POSSIBILITY OF SUCH DAMAGES.
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. Any license to use this material is granted
separately from this document. This material is 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, service marks, tradenames, and other intellectual property are the exclusive property of
MIPI Alliance Inc. and cannot be used without its express prior written permission. The use or
implementation of this material 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 material or
otherwise.
Without limiting the generality of the disclaimers stated above, users of this material are further notified that
MIPI: (a) does not evaluate, test or verify the accuracy, soundness or credibility of the contents of this
material; (b) does not monitor or enforce compliance with the contents of this material; and (c) does not
certify, test, or in any manner investigate products or services or any claims of compliance with MIPI
specifications or related material.
Questions pertaining to this material, or the terms or conditions of its provision, should be addressed to:
MIPI Alliance, Inc.
c/o IEEE-ISTO
445 Hoes Lane, Piscataway New Jersey 08854, United States
Attn: Managing Director
ii Copyright © 2005-2019 MIPI Alliance, Inc.

Confidential
Version 3.0 Specification for CSI-2
31-May-2019
Contents
Figures ........................................................................................................................ viii
Tables ..........................................................................................................................xv
Release History .............................................................................................................. xvii
1 Introduction .................................................................................................................1
1.1 Scope ............................................................................................................................... 1
1.2 Purpose ............................................................................................................................ 1
2 Terminology .................................................................................................................2
2.1 Use of Special Terms ....................................................................................................... 2
2.2 Definitions ....................................................................................................................... 2
2.3 Abbreviations................................................................................................................... 3
2.4 Acronyms ......................................................................................................................... 3
3 References ....................................................................................................................6
4 Overview of CSI-2 .......................................................................................................7
5 CSI-2 Layer Definitions ..............................................................................................9
6 Camera Control Interface (CCI) ............................................................................. 11
6.1 CCI (I2C) Data Transfer Protocol .................................................................................. 12
6.1.1 CCI (I2C) Message Type ............................................................................................. 12
6.1.2 CCI (I2C) Read/Write Operations ............................................................................... 13
6.2 CCI (I3C) Data Transfer Protocol.................................................................................. 19
6.2.1 CCI (I3C SDR) Data Transfer Protocol ...................................................................... 19
6.2.2 CCI (I3C DDR) Data Transfer Protocol ..................................................................... 27
6.3 CCI (I3C) Error Detection and Recovery ...................................................................... 37
6.3.1 CCI (I3C SDR) Error Detection and Recovery Method ............................................. 37
6.3.2 CCI (I3C DDR) Error Detection and Recovery Method ............................................ 39
6.3.3 Error Detection and Recovery for CCI (I3C) Master Devices.................................... 45
6.4 CCI (I2C) Slave Addresses............................................................................................. 45
6.5 CCI (I3C) Slave Addresses ............................................................................................ 45
6.6 CCI Multi-Byte Registers .............................................................................................. 46
6.6.1 Overview..................................................................................................................... 46
6.6.2 Transmission Byte Order for Multi-Byte Register Values .......................................... 48
6.6.3 Multi-Byte Register Protocol (Informative) ............................................................... 49
6.7 CCI I/O Electrical and Timing Specifications ............................................................... 53
7 Physical Layer ...........................................................................................................57
7.1 D-PHY Physical Layer Option ...................................................................................... 57
7.2 C-PHY Physical Layer Option....................................................................................... 58
7.3 PHY Support for the CSI-2 Unified Serial Link (USL) Feature.................................... 59
7.3.1 D-PHY Support Requirements for USL Feature......................................................... 59
7.3.2 C-PHY Support Requirements for USL Feature ......................................................... 60
Copyright © 2005-2019 MIPI Alliance, Inc. iii

Confidential
31-May-2019
8 Multi-Lane Distribution and Merging ....................................................................61

8.1 Lane Distribution for the D-PHY Physical Layer Option.............................................. 66
8.2 Lane Distribution for the C-PHY Physical Layer Option .............................................. 69
8.3 Multi-Lane Interoperability ........................................................................................... 71
8.3.1 C-PHY Lane De-Skew ................................................................................................ 73
9 Low Level Protocol....................................................................................................75
9.1 Low Level Protocol Packet Format ............................................................................... 76
9.1.1 Low Level Protocol Long Packet Format ................................................................... 76
9.1.2 Low Level Protocol Short Packet Format ................................................................... 81
9.2 Data Identifier (DI) ........................................................................................................ 82
9.3 Virtual Channel Identifier .............................................................................................. 82
9.4 Data Type (DT) .............................................................................................................. 84
9.5 Packet Header Error Correction Code for D-PHY Physical Layer Option .................... 85
9.5.1 General Hamming Code Applied to Packet Header.................................................... 85
9.5.2 Hamming-Modified Code ........................................................................................... 86
9.5.3 ECC Generation on TX Side....................................................................................... 90
9.5.4 Applying ECC on RX Side (Informative) .................................................................. 91
9.6 Checksum Generation .................................................................................................... 93
9.7 Packet Spacing ............................................................................................................... 95
9.8 Synchronization Short Packet Data Type Codes............................................................ 96
9.8.1 Frame Synchronization Packets .................................................................................. 96
9.8.2 Line Synchronization Packets ..................................................................................... 97
9.9 Generic Short Packet Data Type Codes ......................................................................... 99
9.10 Packet Spacing Examples Using the Low Power State ............................................... 100
9.11 Latency Reduction and Transport Efficiency (LRTE) ................................................. 103
9.11.1 Interpacket Latency Reduction (ILR) ....................................................................... 103
9.11.2 Using ILR and Enhanced Transport Efficiency Together ......................................... 113
9.11.3 LRTE Register Tables ............................................................................................... 114
9.12 Unified Serial Link (USL) ........................................................................................... 117
9.12.1 USL Technical Overview .......................................................................................... 118
9.12.2 USL Command Payload Constructs ......................................................................... 119
9.12.3 USL Operation Procedures ....................................................................................... 122
9.12.4 Monitoring USL Command Transport Integrity ....................................................... 124
9.12.5 USL Powerup / Reset, SNS Configuration, and Mode Switching ............................ 125
9.13 Data Scrambling .......................................................................................................... 137
9.13.1 CSI-2 Scrambling for D-PHY................................................................................... 138
9.13.2 CSI-2 Scrambling for C-PHY ................................................................................... 139
9.13.3 Scrambling Details .................................................................................................... 142
9.14 Smart Region of Interest (SROI) ................................................................................. 147
9.14.1 Overview of SROI Frame Format............................................................................. 147
9.14.2 Transmission of SROI Embedded Data Packet ........................................................ 149
9.14.3 SROI Packet Detection Options................................................................................ 150
9.14.4 SROI Use Cases (Informative) ................................................................................. 152
9.14.5 Format of SROI Embedded Data Packet (SEDP) ..................................................... 154
9.15 Packet Data Payload Size Rules .................................................................................. 157
9.16 Frame Format Examples .............................................................................................. 158
iv Copyright © 2005-2019 MIPI Alliance, Inc.

Confidential
31-May-2019
9.17 Data Interleaving ......................................................................................................... 161

9.17.1 Data Type Interleaving .............................................................................................. 161
9.17.2 Virtual Channel Identifier Interleaving ..................................................................... 164
10 Color Spaces.............................................................................................................165
10.1 RGB Color Space Definition ....................................................................................... 165
10.2 YUV Color Space Definition ....................................................................................... 165
11 Data Formats ...........................................................................................................167
11.1 Generic 8-bit Long Packet Data Types ........................................................................ 169
11.1.1 Null and Blanking Data ............................................................................................ 169
11.1.2 Embedded Information ............................................................................................. 170
11.1.3 Generic Long Packet Data Types 1 Through 4 ......................................................... 170
11.2 YUV Image Data ......................................................................................................... 171
11.2.1 Legacy YUV420 8-bit............................................................................................... 171
11.2.2 YUV420 8-bit ........................................................................................................... 174
11.2.3 YUV420 10-bit ......................................................................................................... 178
11.2.4 YUV422 8-bit ........................................................................................................... 180
11.2.5 YUV422 10-bit ......................................................................................................... 182
11.3 RGB Image Data.......................................................................................................... 184
11.3.1 RGB888 .................................................................................................................... 185
11.3.2 RGB666 .................................................................................................................... 187
11.3.3 RGB565 .................................................................................................................... 189
11.3.4 RGB555 .................................................................................................................... 191
11.3.5 RGB444 .................................................................................................................... 192
11.4 RAW Image Data ......................................................................................................... 193
11.4.1 RAW6 ....................................................................................................................... 194
11.4.2 RAW7 ....................................................................................................................... 195
11.4.3 RAW8 ....................................................................................................................... 196
11.4.4 RAW10 ..................................................................................................................... 197
11.4.5 RAW12 ..................................................................................................................... 199
11.4.6 RAW14 ..................................................................................................................... 200
11.4.7 RAW16 ..................................................................................................................... 202
11.4.8 RAW20 ..................................................................................................................... 203
11.4.9 RAW24 ..................................................................................................................... 205
11.5 User Defined Data Formats ......................................................................................... 206
12 Recommended Memory Storage ............................................................................209
12.1 General/Arbitrary Data Reception ............................................................................... 209
12.2 RGB888 Data Reception ............................................................................................. 210
12.7 YUV422 8-bit Data Reception .................................................................................... 212
12.8 YUV422 10-bit Data Reception .................................................................................. 213
12.9 YUV420 8-bit (Legacy) Data Reception ..................................................................... 214
12.10 YUV420 8-bit Data Reception .................................................................................... 215
12.11 YUV420 10-bit Data Reception .................................................................................. 216
12.12 RAW6 Data Reception................................................................................................. 217
Copyright © 2005-2019 MIPI Alliance, Inc. v

Confidential
31-May-2019

12.15 RAW10 Data Reception............................................................................................... 218
Annex A JPEG8 Data Format (informative).............................................................223
A.1 Introduction.................................................................................................................. 223
A.2 JPEG Data Definition .................................................................................................. 224
A.3 Image Status Information ............................................................................................ 225
A.4 Embedded Images ........................................................................................................ 227
A.5 JPEG8 Non-standard Markers ..................................................................................... 228
A.6 JPEG8 Data Reception ................................................................................................ 228
Annex B CSI-2 Implementation Example (informative) .........................................229
B.1 Overview...................................................................................................................... 229
B.2 CSI-2 Transmitter Detailed Block Diagram ................................................................ 230
B.3 CSI-2 Receiver Detailed Block Diagram..................................................................... 231
B.4 Details on the D-PHY Implementation ........................................................................ 232
B.4.1 CSI-2 Clock Lane Transmitter .................................................................................. 233
B.4.2 CSI-2 Clock Lane Receiver ...................................................................................... 234
B.4.3 CSI-2 Data Lane Transmitter .................................................................................... 235
B.4.4 CSI-2 Data Lane Receiver ........................................................................................ 237
Annex C CSI-2 Recommended Receiver Error Behavior (informative) ................239
C.1 Overview...................................................................................................................... 239
C.2 D-PHY Level Error ...................................................................................................... 240
C.3 Packet Level Error ....................................................................................................... 241
C.4 Protocol Decoding Level Error .................................................................................... 242
Annex D CSI-2 Sleep Mode (informative) .................................................................243
D.1 Overview...................................................................................................................... 243
D.2 SLM Command Phase ................................................................................................. 243
D.3 SLM Entry Phase ......................................................................................................... 244
D.4 SLM Exit Phase ........................................................................................................... 244
Annex E Data Compression for RAW Data Types (normative) ..............................245
E.1 Predictors ..................................................................................................................... 247
E.1.1 Predictor1 .................................................................................................................. 247
E.1.2 Predictor2 .................................................................................................................. 248
E.2 Encoders ...................................................................................................................... 249
E.2.1 Coder for 10–8–10 Data Compression ..................................................................... 249
E.2.4 Coder for 12-10-12 Data Compression ..................................................................... 257
vi Copyright © 2005-2019 MIPI Alliance, Inc.

Confidential
31-May-2019
E.3 Decoders ...................................................................................................................... 268

E.3.1 Decoder for 10–8–10 Data Compression .................................................................. 268
E.3.4 Decoder for 12–10–12 Data Compression ................................................................ 277
Annex F JPEG Interleaving (informative) ................................................................291
Annex G Scrambler Seeds for Lanes 9 and Above....................................................293
Annex H Guidance on CSI-2 Over C-PHY ALP and PPI ........................................295
H.1 CSI-2 with C-PHY ALP Mode .................................................................................... 295
H.1.1 Concepts of ALP Mode and Legacy LP Mode ......................................................... 295
H.1.2 Burst Examples Using ALP Mode ............................................................................ 298
H.1.3 Transmission and Reception of ALP Commands Through the PPI .......................... 303
H.1.4 Multi-Lane Operation Using ALP Mode .................................................................. 308
H.1.5 LP and ALP Operation .............................................................................................. 310
H.1.6 Bi-Directional Lane Turnaround ............................................................................... 310
Copyright © 2005-2019 MIPI Alliance, Inc. vii

Confidential
31-May-2019
Figures
Figure 1 Typical CSI-2 and CCI Transmitter and Receiver Interface for D-PHY............................ 7
Figure 2 Typical CSI-2 and CCI Transmitter and Receiver Interface for C-PHY ............................ 8
Figure 3 CSI-2 Layer Definitions ..................................................................................................... 9
Figure 4 CCI (I2C) Single Read from Random Location ............................................................... 13
Figure 5 CCI (I2C) Single Read from Current Location................................................................. 14
Figure 6 CCI (I2C) Sequential Read Starting from Random Location ........................................... 15
Figure 7 CCI (I2C) Sequential Read Starting from Current Location ............................................ 16
Figure 8 CCI (I2C) Single Write to Random Location ................................................................... 17
Figure 9 CCI (I2C) Sequential Write Starting from Random Location .......................................... 18
Figure 10 CCI (I3C SDR) Single Read from Random Location .................................................... 21
Figure 11 CCI (I3C SDR) Single Read from Current Location ..................................................... 22
Figure 12 CCI (I3C SDR) Sequential Read Starting from Random Location................................ 23
Figure 13 CCI (I3C SDR) Sequential Read Starting from Current Location ................................. 24
Figure 14 CCI (I3C SDR) Single Write to Random Location ........................................................ 25
Figure 15 CCI (I3C SDR) Sequential Write Starting from Random Location ............................... 26
Figure 16 CCI (I3C DDR) Sequential Read from Random Location: 8-bit LENGTH
& INDEX ....................................................................................................................... 30
Figure 17 CCI (I3C DDR) Sequential Read from Random Location: 16-bit LENGTH
& INDEX ....................................................................................................................... 31
Figure 18 CCI (I3C DDR) Concatenated Sequential Read, Random Location: 8-bit LENGTH
& INDEX ....................................................................................................................... 33
Figure 19 CCI (I3C DDR) Concatenated Sequential Read, Random Location: 16-bit LENGTH
& INDEX ....................................................................................................................... 34
Figure 20 CCI (I3C DDR) Sequential Write Starting from Random Location .............................. 36
Figure 21 Example of SS0 Error Detection .................................................................................... 38
Figure 22 Example of SD0 Error Detection ................................................................................... 40
Figure 23 Example of SD1 Error Detection ................................................................................... 42
Figure 24 Example of MD0 Error Detection .................................................................................. 44
Figure 25 Corruption of 32-bit Register During Read Message .................................................... 47
Figure 26 Corruption of 32-bit Register During Write Message .................................................... 47
Figure 27 Example 16-bit Register Write ....................................................................................... 48
Figure 28 Example 32-bit Register Write (Address Not Shown) ................................................... 48
Figure 29 Example 64-bit Register Write (Address Not Shown) ................................................... 48
Figure 30 Example 16-bit Register Read ....................................................................................... 49
Figure 31 Example 32-bit Register Read ....................................................................................... 50
viii Copyright © 2005-2019 MIPI Alliance, Inc.

Confidential
31-May-2019

Figure 34 CCI I/O Timing .............................................................................................................. 55
Figure 35 Conceptual Overview of the Lane Distributor Function for D-PHY ............................. 61
Figure 36 Conceptual Overview of the Lane Distributor Function for C-PHY ............................. 62
Figure 37 Conceptual Overview of the Lane Merging Function for D-PHY ................................. 63
Figure 38 Conceptual Overview of the Lane Merging Function for C-PHY ................................. 65
Figure 39 Two Lane Multi-Lane Example for D-PHY .................................................................. 66
Figure 40 Three Lane Multi-Lane Example for D-PHY ................................................................ 67
Figure 41 N-Lane Multi-Lane Example for D-PHY ...................................................................... 68
Figure 42 N-Lane Multi-Lane Example for D-PHY Short Packet Transmission ........................... 69
Figure 43 Two Lane Multi-Lane Example for C-PHY ................................................................... 70
Figure 44 Three Lane Multi-Lane Example for C-PHY ................................................................ 70
Figure 45 General N-Lane Multi-Lane Distribution for C-PHY .................................................... 70
Figure 46 One Lane Transmitter and N-Lane Receiver Example for D-PHY................................ 71
Figure 47 M-Lane Transmitter and N-Lane Receiver Example (M<N) for D-PHY ...................... 71
Figure 48 M-Lane Transmitter and One Lane Receiver Example for D-PHY ............................... 72
Figure 49 M-Lane Transmitter and N-Lane Receiver Example (N<M) for D-PHY ...................... 72
Figure 50 Example of Digital Logic to Align All RxDataHS......................................................... 73
Figure 51 Low Level Protocol Packet Overview ........................................................................... 75
Figure 52 Long Packet Structure for D-PHY Physical Layer Option ............................................ 76
Figure 53 Long Packet Structure for C-PHY Physical Layer Option............................................. 77
Figure 54 Packet Header Lane Distribution for C-PHY Physical Layer Option ............................ 78
Figure 55 Minimal Filler Byte Insertion Requirements for Three Lane C-PHY............................ 80
Figure 56 Short Packet Structure for D-PHY Physical Layer Option ............................................ 81
Figure 57 Short Packet Structure for C-PHY Physical Layer Option ............................................ 81
Figure 58 Data Identifier Byte ........................................................................................................ 82
Figure 59 Logical Channel Block Diagram (Receiver) .................................................................. 82
Figure 60 Interleaved Video Data Streams Examples .................................................................... 83
Figure 61 26-bit ECC Generation Example ................................................................................... 85
Figure 62 64-bit ECC Generation on TX Side ............................................................................... 90
Figure 63 26-bit ECC Generation on TX Side ............................................................................... 90
Figure 64 64-bit ECC on RX Side Including Error Correction ...................................................... 91
Figure 65 26-bit ECC on RX Side Including Error Correction ...................................................... 92
Figure 66 Checksum Transmission Byte Order.............................................................................. 93
Figure 67 Checksum Generation for Long Packet Payload Data ................................................... 93
Figure 68 Definition of 16-bit CRC Shift Register ........................................................................ 94
Figure 69 16-bit CRC Software Implementation Example ............................................................ 94
Copyright © 2005-2019 MIPI Alliance, Inc. ix

Confidential
31-May-2019
Figure 70 Packet Spacing ............................................................................................................... 95

Figure 71 Example Interlaced Frame Using LS/LE Short Packet and Line Counting ................... 98
Figure 72 Multiple Packet Example ............................................................................................. 100
Figure 73 Single Packet Example................................................................................................. 100
Figure 74 Line and Frame Blanking Definitions .......................................................................... 101
Figure 75 Vertical Sync Example ................................................................................................. 102
Figure 76 Horizontal Sync Example ............................................................................................ 102
Figure 77 Interpacket Latency Reduction Using LRTE EPD....................................................... 103
Figure 78 LRTE Efficient Packet Delimiter Example for CSI-2 Over C-PHY (2 Lanes) ............ 105
Figure 79 Example of LRTE EPD for CSI-2 Over D-PHY – Option 1........................................ 106
Figure 80 Example of LRTE EPD for CSI-2 Over D-PHY – Option 2........................................ 107
Figure 81 Enabling Robust Spacer Byte Detection: General Case............................................... 111
Figure 82 Enabling Robust Spacer Byte Detection: Special Case ............................................... 111
Figure 83 EoTp Usage Examples ................................................................................................. 112
Figure 84 Using EPD with LVLP or ALP Mode Signaling .......................................................... 113
Figure 85 USL System Diagram .................................................................................................. 117
Figure 86 USL Modes Link Transitions ....................................................................................... 130
Figure 87 Examples of USL ALP Mode Clock Lane Management During Sensor Vblank......... 134
Figure 88 System Diagram Showing Per-Lane Scrambling ......................................................... 137
Figure 89 Example of Data Bursts in Two Lanes Using the D-PHY Physical Layer................... 138
Figure 90 Example of Data Bursts in Two Lanes Using the C-PHY Physical Layer ................... 139
Figure 91 Generating Tx Sync Type as Seed Index (Single Lane View) ..................................... 140
Figure 92 Generating Tx Sync Type Using the C-PHY Physical Layer ....................................... 141
Figure 93 PRBS LFSR Serial Implementation Example.............................................................. 144
Figure 94 SROI Frame Format Example...................................................................................... 148
Figure 95 SROI Packet Option 1 .................................................................................................. 150
Figure 96 SROI Packet Option 2 .................................................................................................. 151
Figure 97 Use Case 1: SROI Embedded Data Packet Not Transmitted ....................................... 152
Figure 98 Use Case 2: SROI Embedded Data Packet Is Transmitted .......................................... 153
Figure 99 SROI Embedded Data Packet Format .......................................................................... 154
Figure 100 General Frame Format Example ................................................................................ 158
Figure 101 Digital Interlaced Video Example .............................................................................. 159
Figure 102 Digital Interlaced Video with Accurate Synchronization Timing Information .......... 160
Figure 103 Interleaved Data Transmission using Data Type Value .............................................. 161
Figure 104 Packet Level Interleaved Data Transmission ............................................................. 162
Figure 105 Frame Level Interleaved Data Transmission.............................................................. 163
Figure 106 Interleaved Data Transmission using Virtual Channels ............................................. 164
x Copyright © 2005-2019 MIPI Alliance, Inc.

Confidential
31-May-2019
Figure 107 Byte Packing Pixel Data to C-PHY Symbol Illustration ............................................ 168
Figure 108 Frame Structure with Embedded Data at the Beginning and End of the Frame ........ 170
Figure 109 Legacy YUV420 8-bit Transmission.......................................................................... 171
Figure 110 Legacy YUV420 8-bit Pixel to Byte Packing Bitwise Illustration............................. 172
Figure 111 Legacy YUV420 Spatial Sampling for H.261, H.263 and MPEG 1 .......................... 172
Figure 112 Legacy YUV420 8-bit Frame Format ........................................................................ 173
Figure 113 YUV420 8-bit Data Transmission Sequence.............................................................. 174
Figure 114 YUV420 8-bit Pixel to Byte Packing Bitwise Illustration ......................................... 175
Figure 115 YUV420 Spatial Sampling for H.261, H.263 and MPEG 1 ....................................... 176
Figure 116 YUV420 Spatial Sampling for MPEG 2 and MPEG 4 .............................................. 176
Figure 117 YUV420 8-bit Frame Format ..................................................................................... 177
Figure 118 YUV420 10-bit Transmission .................................................................................... 178
Figure 119 YUV420 10-bit Pixel to Byte Packing Bitwise Illustration ....................................... 179
Figure 120 YUV420 10-bit Frame Format ................................................................................... 179
Figure 121 YUV422 8-bit Transmission ...................................................................................... 180
Figure 122 YUV422 8-bit Pixel to Byte Packing Bitwise Illustration ......................................... 180
Figure 123 YUV422 Co-sited Spatial Sampling .......................................................................... 181
Figure 124 YUV422 8-bit Frame Format ..................................................................................... 181
Figure 125 YUV422 10-bit Transmitted Bytes ............................................................................ 182
Figure 126 YUV422 10-bit Pixel to Byte Packing Bitwise Illustration ....................................... 182
Figure 127 YUV422 10-bit Frame Format ................................................................................... 183
Figure 128 RGB888 Transmission ............................................................................................... 185
Figure 129 RGB888 Transmission in CSI-2 Bus Bitwise Illustration.......................................... 185
Figure 130 RGB888 Frame Format .............................................................................................. 186
Figure 131 RGB666 Transmission with 18-bit BGR Words ........................................................ 187
Figure 132 RGB666 Transmission on CSI-2 Bus Bitwise Illustration ......................................... 187
Figure 134 RGB565 Transmission with 16-bit BGR Words ........................................................ 189
Figure 139 RAW6 Transmission .................................................................................................. 194
Figure 140 RAW6 Data Transmission on CSI-2 Bus Bitwise Illustration ................................... 194
Figure 141 RAW6 Frame Format ................................................................................................. 194
Copyright © 2005-2019 MIPI Alliance, Inc. xi

Confidential
31-May-2019

Figure 148 RAW10 Transmission ................................................................................................ 197
Figure 149 RAW10 Data Transmission on CSI-2 Bus Bitwise Illustration ................................. 197
Figure 150 RAW10 Frame Format ............................................................................................... 198
Figure 152 RAW12 Transmission on CSI-2 Bus Bitwise Illustration .......................................... 199
Figure 166 User Defined 8-bit Data (128 Byte Packet) ............................................................... 206
Figure 167 User Defined 8-bit Data Transmission on CSI-2 Bus Bitwise Illustration................. 206
Figure 168 Transmission of User Defined 8-bit Data................................................................... 206
Figure 169 General/Arbitrary Data Reception ............................................................................. 209
Figure 170 RGB888 Data Format Reception ............................................................................... 210
Figure 175 YUV422 8-bit Data Format Reception ...................................................................... 212
Figure 176 YUV422 10-bit Data Format Reception .................................................................... 213
Figure 177 YUV420 8-bit Legacy Data Format Reception.......................................................... 214
Figure 178 YUV420 8-bit Data Format Reception ...................................................................... 215
Figure 179 YUV420 10-bit Data Format Reception .................................................................... 216
Figure 180 RAW6 Data Format Reception .................................................................................. 217
xii Copyright © 2005-2019 MIPI Alliance, Inc.

Confidential
31-May-2019

Figure 183 RAW10 Data Format Reception ................................................................................ 218
Figure 185 RAW 14 Data Format Reception ............................................................................... 219
Figure 189 JPEG8 Data Flow in the Encoder .............................................................................. 223
Figure 190 JPEG8 Data Flow in the Decoder .............................................................................. 223
Figure 191 EXIF Compatible Baseline JPEG DCT Format ......................................................... 224
Figure 192 Status Information Field in the End of Baseline JPEG Frame ................................... 226
Figure 193 Example of TN Image Embedding Inside the Compressed JPEG Data Block .......... 227
Figure 194 JPEG8 Data Format Reception .................................................................................. 228
Figure 195 Implementation Example Block Diagram and Coverage ........................................... 229
Figure 196 CSI-2 Transmitter Block Diagram ............................................................................. 230
Figure 197 CSI-2 Receiver Block Diagram ................................................................................. 231
Figure 198 D-PHY Level Block Diagram .................................................................................... 232
Figure 199 CSI-2 Clock Lane Transmitter ................................................................................... 233
Figure 200 CSI-2 Clock Lane Receiver ....................................................................................... 234
Figure 201 CSI-2 Data Lane Transmitter ..................................................................................... 235
Figure 202 CSI-2 Data Lane Receiver ......................................................................................... 237
Figure 203 SLM Synchronization ................................................................................................ 244
Figure 204 Data Compression System Block Diagram ................................................................ 246
Figure 205 Pixel Order of the Original Image .............................................................................. 247
Figure 206 Example Pixel Order of the Original Image .............................................................. 247
Figure 207 Data Type Interleaving: Concurrent JPEG and YUV Image Data ............................. 291
Figure 208 Virtual Channel Interleaving: Concurrent JPEG and YUV Image Data .................... 292
Figure 209 Example JPEG and YUV Interleaving Use Cases ..................................................... 292
Figure 210 Comparing Data Burst Timing of Legacy LP mode versus ALP Mode ..................... 295
Figure 211 ALP Mode General Burst Format .............................................................................. 296
Figure 212 High-Speed and ALP-Pause Wake Receiver Example............................................... 297
Figure 213 Examples of Bursts to Send High-Speed Data and ALP Commands ......................... 299
Figure 214 State Transitions for an HS Data Burst ...................................................................... 300
Figure 215 State Transitions to Enter the ULPS State.................................................................. 301
Figure 216 State Transitions to Exit from the ULPS State ........................................................... 302
Figure 217 PPI Example: HS Signals for Transmission of Data, Sync and ALP Commands ...... 303
Copyright © 2005-2019 MIPI Alliance, Inc. xiii

Confidential
31-May-2019
Figure 218 PPI Example Transmit Side Timing for an HS Data Burst ........................................ 304
Figure 219 PPI Example Receive Side Timing for an HS Data Burst.......................................... 305
Figure 220 PPI Example Transmit Side Timing to Enter the ULPS State.................................... 306
Figure 221 PPI Example Receive Side Timing to Enter the ULPS State ..................................... 306
Figure 222 PPI Example Transmit Side Timing to Exit from the ULPS State ............................. 307
Figure 223 PPI Example Receive Side Timing to Exit from the ULPS State .............................. 307
Figure 224 Example Showing a Data Transmission Burst using Three Lanes............................. 309
Figure 225 Example Showing an ALP Command Burst using Three Lanes ................................ 309
Figure 226 High-Level View of the Control Mode Lane Turnaround Procedure ........................ 310
Figure 227 High-Level View of ALP Mode with the Control Mode Lane
Turnaround Procedure .................................................................................................. 310
Figure 228 High-Level View of the Fast Lane Turnaround Procedure with ALP Mode .............. 311
Figure 229 High-Level View, Comparing Lane Turnaround Procedures ..................................... 312
Figure 230 Detailed View of the Fast Lane Turnaround Procedure ............................................. 313
Figure 231 State Transitions from ALP-Pause Stop to Turnaround ............................................. 314
Figure 232 State Transitions from Turnaround to Turnaround ..................................................... 315
Figure 233 State Transitions from Turnaround to ALP-Pause Stop ............................................. 316
Figure 234 Example Fast Lane Turnaround at the First Transmitting Device ............................. 317
Figure 235 Example Fast Lane Turnaround at the Second Transmitting Device ......................... 318
xiv Copyright © 2005-2019 MIPI Alliance, Inc.

Confidential
31-May-2019
Tables
Table 1 CCI (I2C) Read/Write Operations ...................................................................................... 13
Table 2 CCI (I3C SDR) Read/Write Operations ............................................................................ 20
Table 3 CCI (I3C DDR) Read/Write Operations ............................................................................ 28
Table 4 CCI (I3C DDR) Read/Write Operation Command Codes ................................................. 29
Table 5 CCI (I3C SDR) Slave Error Types .................................................................................... 37
Table 6 CCI (I3C DDR) Slave Error Types .................................................................................... 39
Table 7 CCI (I3C DDR) Master Error Type ................................................................................... 43
Table 8 CCI I/O Electrical Specifications ...................................................................................... 53
Table 9 CCI I/O Timing Specifications .......................................................................................... 54
Table 10 Data Type Classes ............................................................................................................ 84
Table 11 ECC Syndrome Association Matrix ................................................................................. 86
Table 12 ECC Parity Generation Rules .......................................................................................... 88
Table 13 Synchronization Short Packet Data Type Codes ............................................................. 96
Table 14 Generic Short Packet Data Type Codes ........................................................................... 99
Table 15 Minimum Spacer Bytes per Lane for ECC Calculation ................................................ 110
Table 16 LRTE Transmitter Registers for CSI-2 Over C-PHY .................................................... 114
Table 17 LRTE Transmitter Registers for CSI-2 Over D-PHY .................................................... 115
Table 18 Image Sensor LPDT LRTE Control Register ................................................................ 120
Table 19 USL Transport Control (USL_CTL) Bit Description .................................................... 121
Table 20 USL Transport Integrity ACK and NAK Registers with TSEQ .................................... 124
Table 21 USL BTA Switch Registers ........................................................................................... 127
Table 22 Register TX_USL_REV_FWD_ENTRY ...................................................................... 128
Table 23 Register TX_USL_SNS_BTA_ACK_TIMEOUT[15:0] ............................................... 129
Table 24 Register TX_USL_APP_BTA_ACK_TIMEOUT[15:0] ............................................... 129
Table 25 USL Operation Registers ............................................................................................... 131
Table 26 USL GPIO Registers...................................................................................................... 131
Table 27 USL Clock Lane Control Register ................................................................................. 134
Table 28 Symbol Sequence Values Per Sync Type ....................................................................... 140
Table 29 Fields That Are Not Scrambled ..................................................................................... 142
Table 30 D-PHY Scrambler PRBS Initial Seed Values for Lanes 1 Through 8 ........................... 142
Table 31 C-PHY Scrambler PRBS Initial Seed Values for Lanes 1 Through 8............................ 143
Table 32 Example of the PRBS Bit-at-a-Time Shift Sequence .................................................... 145
Table 33 Example PRBS LFSR Byte Sequence for D-PHY Physical Layer ............................... 145
Table 34 Example PRBS LFSR Byte Sequence for C-PHY Physical Layer................................ 146
Table 35 Transmission of SROI Embedded Data Packet ............................................................. 149
Copyright © 2005-2019 MIPI Alliance, Inc. xv

Confidential
31-May-2019
Table 36 ROI Element Information Field Format ........................................................................ 154

Table 37 ROI Element Type ID Definitions ................................................................................. 155
Table 38 Primary and Secondary Data Formats Definitions ........................................................ 167
Table 39 Generic 8-bit Long Packet Data Types .......................................................................... 169
Table 40 YUV Image Data Types ................................................................................................. 171
Table 41 Legacy YUV420 8-bit Packet Data Size Constraints .................................................... 171
Table 42 YUV420 8-bit Packet Data Size Constraints ................................................................. 174
Table 43 YUV420 10-bit Packet Data Size Constraints ............................................................... 178
Table 44 YUV422 8-bit Packet Data Size Constraints ................................................................. 180
Table 45 YUV422 10-bit Packet Data Size Constraints ............................................................... 182
Table 46 RGB Image Data Types ................................................................................................. 184
Table 47 RGB888 Packet Data Size Constraints .......................................................................... 185
Table 50 RAW Image Data Types ................................................................................................ 193
Table 51 RAW6 Packet Data Size Constraints ............................................................................. 194
Table 54 RAW10 Packet Data Size Constraints ........................................................................... 197
Table 60 User Defined 8-bit Data Types ...................................................................................... 207
Table 61 Status Data Padding ....................................................................................................... 225
Table 62 JPEG8 Additional Marker Codes Listing ...................................................................... 228
Table 63 Initial Seed Values for Lanes 9 through 32 .................................................................... 293
Table 64 ALP Code Definitions used by CSI-2 ............................................................................ 302
xvi Copyright © 2005-2019 MIPI Alliance, Inc.

Confidential
31-May-2019
Release History
Date Version Description
2005-11-29 v1.00 Initial Board approved release.
2010-11-09 v1.01.00 Board approved release.
2013-01-22 v1.1 Board approved release.
Copyright © 2005-2019 MIPI Alliance, Inc. xvii

Confidential
31-May-2019
This page intentionally left blank.
xviii Copyright © 2005-2019 MIPI Alliance, Inc.

Confidential
31-May-2019
1 Introduction
1.1 Scope
1 The Camera Serial Interface 2 Specification defines an interface between a peripheral device (camera) and a
2 host processor (baseband, application engine). The purpose of this document is to specify a standard interface
3 between a camera and a host processor for mobile applications.
4 This Revision of the Camera Serial Interface 2 Specification leverages C-PHY [MIPI02] and D-PHY
5 [MIPI01]. These enhancements enable higher interface bandwidth and more flexibility in channel layout.
6 The CSI-2 version 1.3 Specification was designed to ensure interoperability with CSI-2 version 1.2 when the
7 former uses the D-PHY physical layer. If the C-PHY physical layer only is used, then backwards
8 compatibility cannot be maintained.
9 In this document, the term ‘host processor’ refers to the hardware and software that performs essential core
10 functions for telecommunication or application tasks. The engine of a mobile terminal includes hardware and
11 the functions, which enable the basic operation of the mobile terminal. These include, for example, the printed
12 circuit boards, RF components, basic electronics, and basic software, such as the digital signal processing
13 software.
1.2 Purpose
14 Demand for increasingly higher image resolutions is pushing the bandwidth capacity of existing host
15 processor-to-camera sensor interfaces. Common parallel interfaces are difficult to expand, require many
16 interconnects, and consume relatively large amounts of power. Emerging serial interfaces address many of
17 the shortcomings of parallel interfaces while introducing their own problems. Incompatible, proprietary
18 interfaces prevent devices from different manufacturers from working together. This can raise system costs
19 and reduce system reliability by requiring “hacks” to force the devices to interoperate. The lack of a clear
20 industry standard can slow innovation and inhibit new product market entry.
21 CSI-2 provides the mobile industry a standard, robust, scalable, low-power, high-speed, cost-effective
22 interface that supports a wide range of imaging solutions for mobile devices.
Copyright © 2005-2019 MIPI Alliance, Inc. 1

Confidential
31-May-2019
2 Terminology
2.1 Use of Special Terms

23 The MIPI Alliance has adopted Section 13.1 of the IEEE Standards Style Manual, which dictates use of the
24 words “shall”, “should”, “may”, and “can” in the development of documentation, as follows:
25 The word shall is used to indicate mandatory requirements strictly to be followed in order
26 to conform to the Specification and from which no deviation is permitted (shall equals is
27 required to).
28 The use of the word must is deprecated and shall not be used when stating mandatory
29 requirements; must is used only to describe unavoidable situations.
30 The use of the word will is deprecated and shall not be used when stating mandatory
31 requirements; will is only used in statements of fact.
32 The word should is used to indicate that among several possibilities one is recommended
33 as particularly suitable, without mentioning or excluding others; or that a certain course of
34 action is preferred but not necessarily required; or that (in the negative form) a certain
35 course of action is deprecated but not prohibited (should equals is recommended that).
36 The word may is used to indicate a course of action permissible within the limits of the
37 Specification (may equals is permitted to).
38 The word can is used for statements of possibility and capability, whether material,
39 physical, or causal (can equals is able to).
40 All sections are normative, unless they are explicitly indicated to be informative.
2.2 Definitions
41 CCI (I C): CCI supporting I2C [NXP01].
2
42 CCI (I3C): CCI supporting I3C [MIPI03].

43 CCI (I3C SDR) means CCI supporting I3C SDR.
44 CCI (I3C DDR) means CCI supporting I3C DDR.
45 Filler: A CSI-2 protocol element that is inserted after CSI-2 Packets in order to ensure that data transmissions
46 on all Lanes end at the same time.
47 Lane: A unidirectional, point-to-point, 2- or 3-wire interface used for high-speed serial clock or data
48 transmission; the number of wires is determined by the PHY specification in use (i.e. either D-PHY or C-PHY,
49 respectively). A CSI-2 camera interface using the D-PHY physical layer consists of one clock Lane and one
50 or more data Lanes. A CSI-2 camera interface using the C-PHY physical layer consists of one or more Lanes,
51 each of which transmits both clock and data information. Note that when describing features or behavior
52 applying to both D-PHY and C-PHY, this specification sometimes uses the term data Lane to refer to both a
53 D-PHY data Lane and a C-PHY Lane.
54 Message: In CCI (I2C) or CCI (I3C SDR), a Message begins with a START or Repeated START condition,
55 followed by the address of the targeted slave(s), R/W bit, other data, and ends with either a STOP or Repeated
56 START condition. In the case of CCI (I3C SDR), a START or Repeated START condition followed by 7’h7E
57 may be added to the beginning. In CCI (I3C DDR), a Message begins with either the I3C ENTHDR0 CCC
58 or the I3C HDR Restart Pattern, followed by an HDR-DDR Command, HDR-DDR Data, and ends with either
59 the I3C HDR Exit Pattern or the I3C HDR Restart Pattern.
60 Operation: An Operation is composed of one or more Messages in order to read or write.
2 Copyright © 2005-2019 MIPI Alliance, Inc.

Confidential
31-May-2019
61 Packet: A group of bytes organized in a specified way to transfer data across the interface. All packets have
62 a minimum specified set of components. The byte is the fundamental unit of data from which packets are
63 made.
64 Payload: Application data only – with all sync, header, ECC and checksum and other protocol-related
65 information removed. This is the “core” of transmissions between application processor and peripheral.
66 Sleep Mode: Sleep mode (SLM) is a leakage level only power consumption mode.
67 Spacer: An optional CSI-2 protocol element that may be inserted after CSI-2 Packets and Fillers transmitted
68 using CSI-2 LRTE; not to be confused with the C-PHY “Spacer Code” defined in [MIPI02].
69 Transmission: The time during which high-speed serial data is actively traversing the bus. A transmission is
70 bounded by SoT (Start of Transmission) and EoT (End of Transmission) at beginning and end, respectively.
71 Virtual Channel: Multiple independent data streams for up to 32 peripherals are supported by this
72 Specification. The data stream for each peripheral may be a Virtual Channel. These data streams may be
73 interleaved and sent as sequential packets, with each packet dedicated to a particular peripheral or channel.
74 Packet protocol includes information that links each packet to its intended peripheral.
2.3 Abbreviations
75 e.g. For example (Latin: exempli gratia)
76 i.e. That is (Latin: id est)
2.4 Acronyms
77 ALP Alternate Low Power
78 BER Bit Error Rate
79 CCI Camera Control Interface
80 CIL Control and Interface Logic
81 CRC Cyclic Redundancy Check
82 CSI Camera Serial Interface
83 CSPS Chroma Shifted Pixel Sampling
84 DDR Dual Data Rate
85 DI Data Identifier
86 DT Data Type
87 ECC Error Correction Code
88 EoT End of Transmission
89 EoTp End of Transmission short packet
90 EPD Efficient Packet Delimiter (PHY and / or Protocol generated signaling used in LRTE)
91 EXIF Exchangeable Image File Format
92 FE Frame End
93 FS Frame Start
94 HS High Speed; identifier for operation mode
95 HS-LPS-LS High speed to Low Power State to High speed switching (includes LPS entry and exit latencies)

Confidential
31-May-2019
96 HS-RX High-Speed Receiver

97 HS-TX High-Speed Transmitter
98 I2C Inter-Integrated Circuit [NXP01]
99 ILR Interpacket Latency Reduction
100 JFIF JPEG File Interchange Format
101 JPEG Joint Photographic Expert Group
102 LE Line End
103 LFSR Linear Feedback Shift Register
104 LLP Low Level Protocol
105 LS Line Start
106 LSB Least Significant Bit
107 LSS Least Significant Symbol
108 LP Low-Power; identifier for operation mode
109 LP-RX Low-Power Receiver (Large-Swing Single Ended)
110 LP-TX Low-Power Transmitter (Large-Swing Single Ended)
111 LRTE Latency Reduction Transport Efficiency
112 LVLP Low Voltage Low Power
113 MSB Most Significant Bit
114 MSS Most Significant Symbol
115 PDQ Packet Delimiter Quick (PHY generated and consumed signaling used in LRTE)
116 PF Packet Footer
117 PH Packet Header
118 PI Packet Identifier
119 PT Packet Type
120 PHY Physical Layer
121 PPI PHY Protocol Interface
122 PRBS Pseudo-Random Binary Sequence
123 RGB Color representation (Red, Green, Blue)
124 RX Receiver
125 SCL Serial Clock (for CCI)
126 SDA Serial Data (for CCI)
127 SLM Sleep Mode
128 SoT Start of Transmission
129 TX Transmitter
130 ULPS Ultra Low Power State

Confidential
31-May-2019
131 VGA Video Graphics Array

132 YUV Color representation (Y for luminance, U & V for chrominance)

Confidential
31-May-2019
3 References
133 [NXP01] UM10204, I2C bus specification and user manual, Revision 6, NXP Semiconductors
134 N.V., 4 April 2014.
135 [MIPI01] MIPI Alliance Specification for D-PHY, version 2.5, MIPI Alliance, Inc., In press.
136 [MIPI02] MIPI Alliance Specification for C-PHY, version 2.0, MIPI Alliance, Inc., 28 May 2019.
137 [MIPI03] MIPI Alliance Specification for I3C (Improved Inter-Integrated Circuit), version 1.0,
138 MIPI Alliance, Inc., 31 December 2016.
139 [MIPI04] MIPI Alliance Specification for Camera Command Set (CCS), version 1.0, MIPI
140 Alliance, Inc., 24 October 2017.

Confidential
31-May-2019
4 Overview of CSI-2
141 The CSI-2 Specification defines standard data transmission and control interfaces between transmitter and
142 receiver. Two high-speed serial data transmission interface options are defined.
143 The first option, referred to in this specification as the “D-PHY physical layer option,” is typically a
144 unidirectional differential interface with one 2-wire clock Lane and one or more 2-wire data Lanes. The
145 physical layer of this interface is defined by the MIPI Alliance Specification for D-PHY [MIPI01]. Figure 1
146 illustrates the connections for this option between a CSI-2 transmitter and receiver, which typically are a
147 camera module and a receiver module, part of the mobile phone engine.
148 The second high-speed data transmission interface option, referred to in this specification as the “C-PHY
149 physical layer option,” typically consists of one or more unidirectional 3-wire serial data Lanes, each of
150 which has its own embedded clock. The physical layer of this interface is defined by the MIPI Alliance
151 Specification for C-PHY [MIPI02]. Figure 2 illustrates the CSI transmitter and receiver connections for this
152 option.
153 The Camera Control Interface (CCI) for both physical layer options is a bi-directional control interface
154 compatible with the I2C standard [NXP01].
155 Note that beginning with the CSI-2 v3.0 specification, Lane 1 of a D-PHY or C-PHY link interconnecting a
156 camera with a host or application processor (i.e., Data1+ / Data1- in Figure 1, or Data1_A / Data1_B /
157 Data1_C in Figure 2) is permitted to be bidirectional. For such links, there is no requirement to support a
158 physically separate CCI. See Section 9.12.
Device e.g. a Camera containing the Device e.g. an application engine or

CSI transmitter and CCI slave base band containing the CSI receiver
Unidirectional High and the CCI master
Speed Data Link
CSI Transmitter CSI Receiver
N 2-wire Data Lanes
DataN+ DataN+
DataN- DataN-
Data1+ Data1+
Data1- Data1-
One 2-wire Clock Lane
Clock+ Clock+
Clock- Clock-
400kHz Bidirectional
CCI Slave Control Link CCI Master
SCL SCL
SDA SDA
159
Figure 1 Typical CSI-2 and CCI Transmitter and Receiver Interface for D-PHY

Confidential
31-May-2019
Device e.g. a Camera containing the Device e.g. an application engine or

CSI transmitter and CCI slave base band containing the CSI receiver
and the CCI master
Unidirectional High
Speed Data Link
CSI Transmitter CSI Receiver
N 3-Wire Lanes
DataN_A DataN_A
DataN_B DataN_B
DataN_C DataN_C
Data1_A Data1_A
Data1_B Data1_B
Data1_C Data1_C
SCL SCL
SDA SDA
160
Figure 2 Typical CSI-2 and CCI Transmitter and Receiver Interface for C-PHY

Confidential
31-May-2019
5 CSI-2 Layer Definitions
Transmitter Receiver
Application Application
Pixel Control 6-, 7-, 8-, 10-, 12-, 14-, 15-, Pixel Control
16-, 18-, 20- or 24-bits
Pixel Control Data Formats Pixel Control
Pixel to Byte Byte to Pixel
Packing Formats Unpacking Formats
Data Control Data Control
8-bits 8-bits
Data Control Packet Based Protocol Data Control
Low Level Protocol Arbitrary Data Support Low Level Protocol

Data Control Data Control
8-bits 8-bits
Lane Management Lane Distribution/Lane Merging Lane Management

Layer Layer
N * n-bits n = 8 for D-PHY; n = 16 for C-PHY N * n-bits
Data Control Generation / Detection of packet start Data Control
and stop signaling
PHY Layer Serializer / Deserializer PHY Layer
Clock Generation / Recovery (DDR)
Electrical Layer
High Speed Unidirectional Clock (only applies to D-PHY)
High Speed Unidirectional Lane 1
High Speed Unidirectional Lane N

161
Figure 3 CSI-2 Layer Definitions
162 Figure 3 defines the conceptual layer structure typically used in CSI-2. The layers can be characterized as
163 follows:
164 • PHY Layer. The PHY Layer specifies the transmission medium (electrical conductors), the
165 input/output circuitry and the clocking mechanism that captures “ones” and “zeroes” from the
166 serial bit stream. This part of the Specification documents the characteristics of the transmission
167 medium, electrical parameters for signaling and for the D-PHY physical layer option, the timing
168 relationship between clock and data Lanes.
169 The mechanism for signaling Start of Transmission (SoT) and End of Transmission (EoT) is
170 specified as well as other “out of band” information that can be conveyed between transmitting
171 and receiving PHYs. Bit-level and byte-level synchronization mechanisms are included as part of
172 the PHY.
173 The PHY layer is described in [MIPI01] and [MIPI02].

Confidential
31-May-2019
174 • Protocol Layer. The Protocol layer is composed of several layers, each with distinct
175 responsibilities. The CSI-2 protocol enables multiple data streams using a single interface on the
176 host processor. The Protocol layer specifies how multiple data streams may be tagged and
177 interleaved so each data stream can be properly reconstructed.
178 • Pixel/Byte Packing/Unpacking Layer. The CSI-2 specification supports image applications
179 with varying pixel formats. In the transmitter this layer packs pixels from the Application layer
180 into bytes before sending the data to the Low Level Protocol layer. In the receiver this layer
181 unpacks bytes from the Low Level Protocol layer into pixels before sending the data to the
182 Application layer. Eight bits per pixel data is transferred unchanged by this layer.
183 • Low Level Protocol. The Low Level Protocol (LLP) includes the means of establishing bit-
184 level and byte-level synchronization for serial data transferred between SoT (Start of
185 Transmission) and EoT (End of Transmission) events and for passing data to the next layer. The
186 minimum data granularity of the LLP is one byte. The LLP also includes assignment of bit-value
187 interpretation within the byte, i.e. the “Endian” assignment.
188 • Lane Management. CSI-2 is Lane-scalable for increased performance. The number of data
189 Lanes is not limited by this specification and may be chosen depending on the bandwidth
190 requirements of the application. The transmitting side of the interface distributes (“distributor”
191 function) bytes from the outgoing data stream to one or more Lanes. On the receiving side, the
192 interface collects bytes from the Lanes and merges (“merger” function) them together into a
193 recombined data stream that restores the original stream sequence. For the C-PHY physical
194 layer option, this layer exclusively distributes or collects byte pairs (i.e. 16-bits) to or from the
195 data Lanes. Scrambling on a per-Lane basis is an optional feature, which is specified in detail in
196 Section 9.17.
197 Data within the Protocol layer is organized as packets. The transmitting side of the interface
198 appends header and error-checking information on to data to be transmitted at the Low Level
199 Protocol layer. On the receiving side, the header is stripped off at the Low Level Protocol layer
200 and interpreted by corresponding logic in the receiver. Error-checking information may be used to
201 test the integrity of incoming data.
202 • Application Layer. This layer describes higher-level encoding and interpretation of data
203 contained in the data stream and is beyond the scope of this specification. The CSI-2 Specification
204 describes the mapping of pixel values to bytes.
205 The normative sections of the Specification only relate to the external part of the Link, e.g. the data and bit
206 patterns that are transferred across the Link. All internal interfaces and layers are purely informative.

Confidential
31-May-2019
6 Camera Control Interface (CCI)

207 CCI is a two-wire, bi-directional, half duplex, serial interface for controlling the transmitter. CCI is
208 compatible with I2C Fast-mode (Fm) or Fast-mode Plus (Fm+) [NXP01] variants, and with the I3C [MIPI03]
209 interface’s Single Data Rate (SDR) or Double Data Rate (DDR) protocols. CCI shall support up to 400kbps
210 (Fm) operation and 7-bit slave addressing. In addition, CCI can optionally support up to 1Mbps (Fm+),
211 12.5Mbps (SDR), or 25Mbps (DDR).
212 This Section uses the following terms:
213 • CCI (I2C) means CCI supporting I2C
214 • CCI (I3C) means CCI supporting I3C
215 • CCI (I3C SDR) means CCI supporting I3C SDR
216 • CCI (I3C DDR) means CCI supporting I3C DDR
217 • CCI alone (without following parentheses) means both CCI (I2C) and CCI (I3C).
218 CCI can be used with or without CSI-2 over C/D-PHY. When CCI is used as part of a CSI-2 bus, a CSI-2
219 receiver shall be configured as a master and a CSI-2 transmitter shall be configured as a slave. When CCI is
220 used without CSI-2 over C/D-PHY, the host should be used as a master. CCI is capable of handling multiple
221 slaves on the bus.
222 In CCI (I2C), multi-master mode is not supported. Any I2C commands not described in this section shall be
223 ignored, and shall not cause unintended device operation.
224 In CCI (I3C), any I3C mandatory functions and ‘Required’ CCC commands shall be supported, and any I3C
225 optional functions and commands may be supported (e.g. Multi-Master, In-Band Interrupt, Hot-Join).
226 Note:
227 Do not confuse the CCI terms master and slave with similar terms in the C-PHY or D-PHY
228 Specifications; they are not related.
229 Typically, there is a dedicated CCI interface between the transmitter and the receiver.
230 CCI is a subset of the I2C or I3C protocol that includes the minimum combination of obligatory features for
231 I2C/I3C slave devices specified in the I2C or I3C specification. Therefore, transmitters complying with the
232 CCI specification can also be connected to the system I2C or I3C bus. However, care must be taken so that
233 I2C or I3C masters do not attempt to use I2C or I3C features not supported by CCI masters or slaves.
234 A CCI transmitter may have additional features to support I2C or I3C, but that is implementation-dependent.
235 Further details can be found on a particular device’s data sheet.
236 This specification does not attempt to define the contents of control Messages sent by the CCI master.
237 Therefore, it is the responsibility of the implementer to define a set of control Messages and corresponding
238 frame timing and any I2C or I3C latency requirements that the CCI master must meet when sending such
239 control Messages to the CCI slave.
240 CCI defines an additional data protocol layer on top of I2C or I3C, as specified in the following sections.

Confidential
31-May-2019
6.1 CCI (I2C) Data Transfer Protocol

241 The CCI (I2C) data transfer protocol follows the I2C specification. The START, REPEATED START, and
242 STOP conditions, and the data transfer protocol, are all specified in [NXP01].
6.1.1 CCI (I2C) Message Type

243 A basic CCI (I2C) Message consists of:
244 • START or Repeated START condition
245 • Slave address with read/write bit
246 • Acknowledge from slave
247 • Sub address (INDEX) for pointing at a register inside the slave device (not used in Single Read
248 from Current Location)
249 • Acknowledge signal from slave (not used in Single Read from Current Location)
250 And then either:
251 • For a write operation:
252 • Data byte from master
253 • Acknowledge/negative acknowledge from slave, and
254 • STOP or Repeated START condition
255 Or:
256 • For a read operation:
257 • Repeated START condition (not used in Single Read from Current Location)
258 • slave address with read bit (not used in Single Read from Current Location)
259 • acknowledge signal from slave (not used in Single Read from Current Location)
260 • data byte from the slave
261 • acknowledge or negative acknowledge from the master, and
262 • STOP or Repeated START condition.
263 A CCI Slave may support back-to-back Messages by using Repeated START between CCI Messages instead
264 of START and/or STOP as shown in this Section.
265 The slave address in CCI (I2C) is 7 bits long.
266 CCI (I2C) supports an 8-bit INDEX with 8-bit data, or a 16-bit INDEX with 8-bit data. The slave device in
267 question defines what Message type is used.

Confidential
31-May-2019
6.1.2 CCI (I2C) Read/Write Operations

268 A CCI (I2C) compatible device shall support the four read operations and two write operations shown in
269 Table 1, as detailed in the following sub-sections:
270 Table 1 CCI (I2C) Read/Write Operations
Type Operation Section
Read Single Read from Random Location 6.1.2.1
Sequential Read from Random Location 6.1.2.2
Single Read from Current Location 6.1.2.3
Sequential Read from Current Location 6.1.2.4
Write Single Write to Random Location 6.1.2.5
Sequential Write Starting from Random Location 6.1.2.6
271 The INDEX in the slave device must be auto-incremented after each read/write operation. This is also
272 explained in the following sections.
6.1.2.1 CCI (I2C) Single Read from Random Location

273 In a single read from a random location (see Figure 4) the master does a dummy write operation to the desired
274 INDEX, issues a Repeated START condition, and then addresses the slave again with the read operation.
275 After acknowledging its slave address, the slave starts to output data onto the SDA line. The master terminates
276 the read operation by setting a negative acknowledge and a STOP or Repeated START condition.
CCI (I2C) Single Read from Random Location with 8-bit index and 8-bit data (7-bit address)
Previous Index value, K Index M Index M +1
S SLAVE SUB ADDRESS S SLAVE P

0 A A 1 A DATA A
Sr ADDRESS [7:0] r ADDRESS Sr
INDEX, value M
CCI (I2C) Single Read from Random Location with 16-bit index and 8-bit data (7-bit address)
S SLAVE SUB ADDRESS SUB ADDRESS S SLAVE P

0 A A A 1 A DATA A
Sr ADDRESS [15:8] [7:0] r ADDRESS Sr
INDEX, value M
From slave to master S = START condition A = Acknowledge
From master to slave P = STOP condition A = Negative acknowledge
Sr = REPEATED START condition

277
Figure 4 CCI (I2C) Single Read from Random Location

Confidential
31-May-2019
6.1.2.2 CCI (I2C) Single Read from Current Location

278 It is also possible to read from the last used INDEX, by addressing the slave with a read operation (see Figure
279 5). The slave responds by sending the data from the last used INDEX to the SDA line. The master terminates
280 the read operation by setting a negative acknowledge and a STOP or Repeated START condition.
Previous Index value, K Index K+1 Index K +2
S SLAVE P S SLAVE P
1 A DATA A 1 A DATA A
Sr ADDRESS Sr Sr ADDRESS Sr
281
Figure 5 CCI (I2C) Single Read from Current Location

Confidential
31-May-2019
6.1.2.3 CCI (I2C) Sequential Read Starting from Random Location

282 Sequential read starting from a random location is illustrated in Figure 6. The master does a dummy write to
283 the desired INDEX, issues a Repeated START condition after an acknowledge from the slave, and then
284 addresses the slave again with a read operation. If a master issues an acknowledge after receiving data, this
285 acts as a signal to the slave that the read operation is to continue from the next INDEX. When the master has
286 read the last data byte, it issues a negative acknowledge and a STOP or Repeated START condition.
CCI (I2C) Sequential Read Starting from a Random Location with 8-bit index and 8-bit data (7-bit address)
Index Index
Previous Index value, K Index M
(M +L-1) M+L
S SUB P
SLAVE S SLAVE
0 A ADDRESS A 1 A DATA A DATA A
Sr ADDRESS r ADDRESS Sr
[7:0]
INDEX, value M L bytes of data
CCI (I2C) Sequential Read Starting from a Random Location with 16-bit index and 8-bit data (7-bit address)
Index Index
(M +L-1) M+L
S SUB SUB P
SLAVE S SLAVE
0 A ADDRESS A ADDRESS A 1 A DATA A DATA A
Sr ADDRESS r ADDRESS Sr
[15:8] [7:0]
287
Figure 6 CCI (I2C) Sequential Read Starting from Random Location

Confidential
31-May-2019
6.1.2.4 CCI (I2C) Sequential Read Starting from Current Location

288 A sequential read starting from the current location (see Figure 7) is similar to a sequential read from a
289 random location. The only exception is there is no dummy write operation. The master terminates the read
290 operation by issuing a negative acknowledge, and a STOP or Repeated START condition.
Index Index
Previous Index value, K Index K+1
(K +L-1) K+L
S SLAVE P
1 A DATA A DATA A DATA A
Sr ADDRESS Sr
L bytes of data
291
Figure 7 CCI (I2C) Sequential Read Starting from Current Location

Confidential
31-May-2019
6.1.2.5 CCI (I2C) Single Write to Random Location

292 A write operation to a random location is illustrated in Figure 8. The master issues a write operation to the
293 slave, then issues the INDEX and data after the slave has acknowledged the write operation. The write
294 operation is terminated with a stop or Repeated START condition from the master.
CCI (I2C) Single Write to a Random Location with 8-bit index and 8-bit data (7-bit address)
Previous Index value, K Index M Index M+1
SUB
S SLAVE A/ P
0 A ADDRESS A DATA
Sr ADDRESS [7:0]
A Sr
INDEX, value M
CCI (I2C) Single Write to a Random Location with 16-bit index and 8-bit data (7-bit address)
Previous Index value, K Index M Index M+1
SUB SUB
S SLAVE A/ P
0 A ADDRESS A ADDRESS A DATA
Sr ADDRESS A Sr
[15:8] [7:0]
INDEX, value M
295
Figure 8 CCI (I2C) Single Write to Random Location

Confidential
31-May-2019
6.1.2.6 CCI (I2C) Sequential Write Starting from Random Location

296 The Sequential Write Starting from Random Location operation is illustrated in Figure 9. The slave auto-
297 increments the INDEX after each data byte is received. The Sequential Write Starting from Random Location
298 operation is terminated with a STOP or Repeated START condition from the master.
CCI (I2C) Sequential Write Starting from a Random Location with 8-bit index and 8-bit data (7-bit address)
Index Index
(M+L+1) M+L
SUB
S SLAVE A/ P
0 A ADDRESS A DATA A DATA
Sr ADDRESS [7:0]
A Sr
CCI (I2C) Sequential Write Starting from a Random Location with 16-bit index and 8-bit data (7-bit address)
Index Index
(M+L+1) M+L
SUB SUB
S SLAVE A/ P
0 A ADDRESS A ADDRESS A DATA A DATA
Sr ADDRESS [15:8] [7:0]
A Sr
L bytes of data
INDEX, value M
299
Figure 9 CCI (I2C) Sequential Write Starting from Random Location

Confidential
31-May-2019
6.2 CCI (I3C) Data Transfer Protocol

300 The CCI (I3C) data transfer protocol follows the I3C Specification. The START, Repeated START, and
301 STOP conditions, as well as data transfer protocol, are specified in [MIPI03].
302 If CCI (I3C) is supported, then CCI (I3C SDR) shall be supported and CCI (I3C DDR) may be supported.
303 The master shall get the slave’s Max Read Length (MRL) and Max Write Length (MWL) via transmitting
304 I3C CCCs GETMRL and GETMWL prior to CCI (I3C) data transfer.
6.2.1 CCI (I3C SDR) Data Transfer Protocol
6.2.1.1 CCI (I3C SDR) Message Type

305 The CCI (I3C SDR) master normally should start a Message with 7’h7E, and may choose to start a Message
306 with a slave address.
307 A basic CCI (I3C SDR) Message starting a Message with 7’h7E consists of:
308 • START condition
309 • 7’h7E with write bit
311 • Repeated START condition
314 • Sub-address (INDEX) of a register inside the slave device (not used in Single Read from Current
315 Location)
316 • Transition bit (Parity bit) from master (not used in Single Read from Current Location)
320 • Transition bit (Parity bit) from master
321 • STOP or Repeated START condition;
322 Or
325 • Slave address with read bit (not used in Single Read from Current Location)
326 • Acknowledge from slave (not used in Single Read from Current Location)
327 • Data byte from slave
328 • Transition bit (End-of-Data) from master or slave

Confidential
31-May-2019
330 Other CCI (I3C SDR) Messages starting a Message with a slave address consist of:
331 • START or Repeated START condition
334 • Sub-address (INDEX) of a register inside the slave device (not used in Single Read from Current
335 Location)
336 • Transition bit (Parity bit) from master (not used in Single Read from Current Location)
340 • Transition bit (Parity bit) from master
341 • STOP or Repeated START condition;
342 Or:
345 • Slave address with read bit (not used in Single Read from Current Location)
346 • Acknowledge from slave (not used in Single Read from Current Location)
347 • Data byte from slave
348 • Transition bit (End-of-Data) from master or slave
350 The slave address in CCI (I3C SDR) is 7 bits long.
351 CCI (I3C SDR) supports an 8-bit INDEX with 8-bit data, or a 16-bit INDEX with 8-bit data. The slave
352 device in question defines what Message type is used.
6.2.1.2 CCI (I3C SDR) Read/Write Operations

353 A CCI (I3C SDR) compatible device shall support the four read operations and two write operations shown
354 in Table 2, as detailed in the following sub-sections:
355 Table 2 CCI (I3C SDR) Read/Write Operations
Read Single Read from Random Location 6.2.1.2.1
Single Read from Current Location 6.2.1.2.2
Sequential Read from Random Location 6.2.1.2.3
Sequential Read from Current Location 6.2.1.2.4
Write Single Write to Random Location 6.2.1.2.5
Sequential Write Starting from Random Location 6.2.1.2.6

Confidential
31-May-2019
6.2.1.2.1 CCI (I3C SDR) Single Read from Random Location

358 In a single read from a random location (Figure 10), the master does a dummy write operation to the desired
359 INDEX, issues a Repeated START condition, and then addresses the slave again with the read operation.
360 After acknowledging its slave address, the slave starts to output data onto the SDA line. The master aborts
361 the read operation by setting a Transition bit, and a STOP or Repeated START condition.
CCI (I3C SDR) Single Read from Random Location with 8-bit index and 8-bit data with 7'h7E Address
I3C Reserved SLAVE SUB ADDRESS SLAVE P

S 0 A Sr 0 A T Sr 1 A DATA T
Byte (7'h7E) ADDRESS [7:0] ADDRESS Sr
INDEX, value M
CCI (I3C SDR) Single Read from Random Location with 8-bit index and 8-bit data without 7'h7E Address
S SLAVE SUB ADDRESS SLAVE P

0 A T Sr 1 A DATA T
Sr ADDRESS [7:0] ADDRESS Sr
INDEX, value M
CCI (I3C SDR) Single Read from Random Location with 16-bit index and 8-bit data with 7'h7E Address
I3C Reserved SLAVE SUB ADDRESS SUB ADDRESS SLAVE P

S 0 A Sr 0 A T T Sr 1 A DATA T
Byte (7'h7E) ADDRESS [15:8] [7:0] ADDRESS Sr
INDEX, value M
CCI (I3C SDR) Single Read from Random Location with 16-bit index and 8-bit data without 7'h7E Address
S SLAVE SUB ADDRESS SUB ADDRESS SLAVE P

0 A T T Sr 1 A DATA T
Sr ADDRESS [15:8] [7:0] ADDRESS Sr
INDEX, value M
From slave to master

S = START condition
From master to slave Sr = Repeated START condition
P = STOP condition
Transition Bit (Parity Bit for Write Data) A = Acknowledge
T = Transition Bit alternative to ACK/NACK
Transition Bit (End-of-Data for Read Data)
362
Figure 10 CCI (I3C SDR) Single Read from Random Location

Confidential
31-May-2019
6.2.1.2.2 CCI (I3C SDR) Single Read from Current Location

363 It is also possible to read from the last used INDEX by addressing the slave with a read operation (Figure
364 11). The slave responds by setting the data from last used INDEX to SDA line. The master aborts the read
365 operation by setting a Transition bit, and a STOP or Repeated START condition.
CCI (I3C SDR) Single Read from Current Location with 7'h7E Address
Previous Index value, K Index K + 1 Index K + 2
I3C Reserved SLAVE P I3C Reserved SLAVE P

S 0 A Sr 1 A DATA T S 0 A Sr 1 A DATA T
Byte (7'h7E) ADDRESS Sr Byte (7'h7E) ADDRESS Sr
CCI (I3C SDR) Single Read from Current Location without 7'h7E Address
Previous Index value, K Index K + 1 Index k +2
S SLAVE P S SLAVE P
1 A DATA T 1 A DATA T
Sr ADDRESS Sr Sr ADDRESS Sr

S = START condition
P = STOP condition
366
Figure 11 CCI (I3C SDR) Single Read from Current Location

Confidential
31-May-2019
6.2.1.2.3 CCI (I3C SDR) Sequential Read from Random Location

367 The sequential read starting from a random location is illustrated in Figure 12. The master does a dummy
368 write operation to the desired INDEX, issues a Repeated START condition, and then addresses the slave
369 again with the read operation. After acknowledging its slave address, the slave starts to output data onto the
370 SDA line. If a master doesn’t abort the read transaction by using the transition bit, this acts as a signal for the
371 slave to continue a read operation from the next INDEX. When the master has read the last data byte, it can
372 abort a read transaction by setting the transition bit and then issuing a STOP or Repeated START condition.
373 Furthermore, when the master reads a large amount of data exceeding the Max Read Length (MRL) limit
374 (see the I3C Specification [MIPI03]), the slave can also terminate a read transaction by setting the transition
375 bit.
376 Note:
377 When selecting a suitable value for MRL, the designer of the slave device and the system designer
378 should take into account the needs of the payload that the CCI will carry. For example, in the CCS
379 Data Transfer Interface [MIPI04], it is beneficial to support an MRL of 64 bytes or larger (i.e. 64 bytes
380 for Data payload).
CCI (I3C SDR) Sequential Read Starting from a Random Location with 8-bit index and 8-bit data with 7'h7E Address
Index Index
(M + L - 1) M+L
I3C Reserved SLAVE SUB ADDRESS SLAVE P

S 0 A Sr 0 A T Sr 1 A DATA T DATA T
Byte (7'h7E) ADDRESS [7:0] ADDRESS Sr
CCI (I3C SDR) Sequential Read Starting from a Random Location with 8-bit index and 8-bit data without 7'h7E Address
Index Index
(M + L - 1) M+L
S SLAVE SUB ADDRESS SLAVE P

0 A T Sr 1 A DATA T DATA T
Sr ADDRESS [7:0] ADDRESS Sr
CCI (I3C SDR) Sequential Read Starting from a Random Location with 16-bit index and 8-bit data with 7'h7E Address
Index Index
(M + L - 1) M+L
I3C Reserved SLAVE SUB ADDRESS SUB ADDRESS SLAVE P

S 0 A Sr 0 A T T Sr 1 A DATA T DATA T
Byte (7'h7E) ADDRESS [15:8] [7:0] ADDRESS Sr
L bytes of data
INDEX, value M
CCI (I3C SDR) Sequential Read Starting from a Random Location with 16-bit index and 8-bit data without 7'h7E Address
Index Index
(M + L - 1) M+L
S SLAVE SUB ADDRESS SUB ADDRESS SLAVE P

0 A T T Sr 1 A DATA T DATA T
Sr ADDRESS [15:8] [7:0] ADDRESS Sr
L bytes of data
INDEX, value M
S = START condition
P = STOP condition
381
Figure 12 CCI (I3C SDR) Sequential Read Starting from Random Location

Confidential
31-May-2019
6.2.1.2.4 CCI (I3C SDR) Sequential Read from Current Location

382 A sequential read starting from the current location (Figure 13) is similar to a sequential read from a random
383 location. The only exception is when there is no dummy write operation. The master or slave terminates a
384 read transaction by setting the transition bit, and then issues a STOP or Repeated START condition.
CCI (I3C SDR) Sequential Read Starting from the Current Location with 7'h7E Address
Index Index
Previous Index value, K
(K + L - 1) K+L
I3C Reserved SLAVE P

S 0 A Sr 1 A DATA T DATA T
Byte (7'h7E) ADDRESS Sr
L bytes of data
CCI (I3C SDR) Sequential Read Starting from the Current Location without 7'h7E Address
Index Index
(K + L-1) K+L
S SLAVE P
1 A DATA T DATA T
Sr ADDRESS Sr
L bytes of data

S = START condition
P = STOP condition
385
Figure 13 CCI (I3C SDR) Sequential Read Starting from Current Location

Confidential
31-May-2019
6.2.1.2.5 CCI (I3C SDR) Single Write to Random Location

386 A write operation to a random location is illustrated in Figure 14. The master issues a write operation to the
387 slave, then issues the INDEX and data after the slave has acknowledged the write operation. The write
CCI (I3C SDR) Single Write to a Random Location with 8-bit index and 8-bit data with 7'h7E Address
Previous Index value, K Index M Index M + 1
I3C Reserved SLAVE SUB ADDRESS P

S 0 A Sr 0 A T DATA T
Byte (7'h7E) ADDRESS [7:0] Sr
INDEX, value M
CCI (I3C SDR) Single Write to a Random Location with 8-bit index and 8-bit data without 7'h7E Address
S SLAVE SUB ADDRESS P

0 A T DATA T
Sr ADDRESS [7:0] Sr
INDEX, value M
CCI (I3C SDR) Single Write to a Random Location with 16-bit index and 8-bit data with 7'h7E Address
I3C Reserved SLAVE SUB ADDRESS SUB ADDRESS P

S 0 A Sr 0 A T T DATA T
Byte (7'h7E) ADDRESS [15:8] [7:0] Sr
INDEX, value M
CCI (I3C SDR) Single Write to a Random Location with 16-bit index and 8-bit data without 7'h7E Address
S SLAVE SUB ADDRESS SUB ADDRESS P

0 A T T DATA T
Sr ADDRESS [15:8] [7:0] Sr
INDEX, value M

S = START condition
P = STOP condition
389
Figure 14 CCI (I3C SDR) Single Write to Random Location

Confidential
31-May-2019
6.2.1.2.6 CCI (I3C SDR) Sequential Write Starting from Random Location
390 The Sequential Write Starting from Random Location operation is illustrated in Figure 15. The slave auto-
391 increments the INDEX after each data byte is received. The Sequential Write Starting from Random Location
CCI (I3C SDR) Sequential Write Starting from a Random Location with 8-bit index and 8-bit data with 7'h7E Address
Index
Previous Index value, K Index M Index (M + L + 1)
M+L
I3C Reserved SLAVE SUB ADDRESS P

S 0 A Sr 0 A T DATA T DATA T
Byte (7'h7E) ADDRESS [7:0] Sr
CCI (I3C SDR) Sequential Write Starting from a Random Location with 8-bit index and 8-bit data without 7'h7E Address
Index
M+L
S SLAVE SUB ADDRESS P

0 A T DATA T DATA T
Sr ADDRESS [7:0] Sr
CCI (I3C SDR) Sequential Write Starting from a Random Location with 16-bit index and 8-bit data with 7'h7E Address
Index
M+L
I3C Reserved SLAVE SUB ADDRESS SUB ADDRESS P

S 0 A Sr 0 A T T DATA T DATA T
Byte (7'h7E) ADDRESS [15:8] [7:0] Sr
CCI (I3C SDR) Sequential Write Starting from a Random Location with 16-bit index and 8-bit data without 7'h7E Address
Index
M+L
S SLAVE SUB ADDRESS SUB ADDRESS P

0 A T T DATA T DATA T
Sr ADDRESS [15:8] [7:0] Sr

S = START condition
P = STOP condition
393
Figure 15 CCI (I3C SDR) Sequential Write Starting from Random Location

Confidential
31-May-2019
6.2.2 CCI (I3C DDR) Data Transfer Protocol
6.2.2.1 CCI (I3C DDR) Message Type

394 The CCI (I3C DDR) master shall start a DDR Message with either the I3C ENTHDR0 CCC, or the I3C
395 HDR Restart Pattern. The CCI (I3C DDR) master shall end a DDR Message by issuing either the I3C HDR
396 Restart Pattern, or the I3C HDR Exit Pattern.
397 Two Message types are defined for DDR Messages: DDR Write Message and DDR Read Message.
398 CCI (I3C DDR) supports either:
399 • 8-bit LENGTH and 8-bit INDEX with 8-bit data
400 Both the LENGTH and the INDEX shall be included in the first data word of the DDR
401 Write Message.
402 or:
403 • 16-bit LENGTH and 16-bit INDEX with 8-bit data
404 The LENGTH shall be included in the first data word of the DDR Write Message, and the
405 INDEX shall be included in the second data word of the DDR Write Message.
406 The slave device in question defines what Message type is used.
407 The LENGTH field defines the number of 8-bit data bytes in the Read or Write Data Words. The LENGTH
408 field is zero-based, i.e. if the master wishes to read or write N bytes, then the value in the LENGTH field
409 must be N–1.
Examples:
410 • 0 LENGTH means 1 byte
411 • 255 LENGTH means 256 bytes
412 When a multi-byte register is accessed via CCI (I3C DDR), the transmission byte order described in
413 Section 6.6 shall be the same as for CCI (I2C) and CCI (I3C SDR).
Example:
414 For the 16-bit register read shown in Figure 17, the DATA0 byte contains bits Data[15:8] and the
415 DATA1 byte contains bits Data[7:0].

Confidential
31-May-2019
6.2.2.2 CCI (I3C DDR) Read/Write Operations

416 A CCI (I3C DDR) compatible device shall support the two read operations and one write operation shown
417 in Table 3, as detailed in the following sub-sections:
418 Table 3 CCI (I3C DDR) Read/Write Operations
Read Sequential Read from Random Location 6.2.2.2.2
Concatenated Sequential Read from Random Location 6.2.2.2.3
Write Sequential Write Starting from Random Location 6.2.2.2.4
6.2.2.2.1 CCI (I3C DDR) Command Definitions

421 As defined in the I3C Specification [MIPI03], bit[15] of the HDR-DDR Command Word is the R/W bit and
422 bits[14:8] contain the Command Code. Command Code values are reserved per application, and CCI (I3C
423 DDR) defines one such Command Code: 7’b0000000.
424 This single Command Code is sufficient, because the slave can still distinguish between three different R/W
425 operations. Consider the example of 16-bit LENGTH and 16-bit INDEX:
426 • If the slave receives a Data Word greater than 4 bytes, then the operation is “Sequential Write
427 Starting from Random Location”.
428 • If the slave receives a Data Word of 4 bytes before the HDR Restart Pattern, then there are two
429 possibilities:
430 • If the value of the LENGTH field is ≤ MRL–1, then the operation is “Sequential Read Starting
431 from a Random Location”.
432 • If the value of the LENGTH field is > MRL–1, then the operation is “Concatenated Sequential
433 Read Starting from a Random Location”.

Confidential
31-May-2019
434 Table 4 defines the I3C HDR-DDR Command Codes (including R/W bit) for each CCI (I3C DDR)
435 Read/Write operation.
436 For CCI (I3C DDR), the slave address is 7 bits long, and appears in bits[7:1] of the HDR-DDR Command
437 Word.
438 Table 4 CCI (I3C DDR) Read/Write Operation Command Codes
R/W Bit
and
Type Operation Command Code Position Command Section
Code
See Note 1
Write Sequential Write Command Word
0x00 6.2.2.2.4
Starting from Random Location
Read Sequential Read Command Word for
0x00
Starting from Random Location LENGTH & INDEX 6.2.2.2.2
Command Word for ReadData 0x80
Concatenated Sequential Read Command Word for
0x00
Starting from Random Location LENGTH & INDEX 6.2.2.2.3
Command Word for ReadData 0x80
Note:
1. In all five cases, the 7-bit Command Code in the low seven bits is 7’b0000000. Only the R/W bit,
which is the high bit of the byte, changes.
6.2.2.2.2 CCI (I3C DDR) Sequential Read From Random Location

439 In a sequential read from a random location (Figure 16 and Figure 17):
440 • The master shall transmit:
441 • The HDR-DDR Command Word for LENGTH and INDEX
442 • The HDR-DDR Data Word, including LENGTH and INDEX
443 • The HDR-DDR CRC Word
444 • The HDR Restart Pattern
445 • The HDR-DDR Command Word for ReadData
446 • Then the slave shall send one or more HDR-DDR Read Data Words followed by the HDR-DDR
447 CRC Word
448 • Finally the master shall send either the HDR Restart Pattern or the HDR Exit Pattern.
449 If the number of 8-bit data words read is odd (i.e. the value in the LENGTH field is even), then the slave
450 shall insert one padding byte in the second byte of the last data word, with value 8’h00. The slave shall not
451 increment INDEX by the padding byte. The master shall take into account that the data includes the padding
452 byte in odd transfers, and that the INDEX is not incremented by the padding byte.
453 The master shall load the Sub Address into the INDEX and auto-increment the INDEX after each data byte
454 is received. The master can identify the padding byte from the value of the LENGTH field and the number
455 of the received 8-bit data words, and shall ignore the padding byte. Note that the INDEX is not incremented
456 by the padding byte.

Confidential
31-May-2019
CCI (I3C DDR) Sequential Read Starting from a Random Location with 8-bit length and 8-bit index ( even byte read transfer)
Index Index Index Index Index
M M+1 M+L-2 M+L-1 M+L
Command Word for Data Word for Command Word Data Word Data Word
CRC Word CRC Word
LENGTH & INDEX LENGTH & INDEX for ReadData for ReadData for ReadData
HDR
ENTHDR SLAVE
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
DDR SLAVE SUB HDR DDR
LENGTH ADDRESS DATA DATA DATA DATA Exit
Parity
Parity
Parity
Parity
Parity
setup
setup
HDR
Command ADDRESS
[7:0]
ADDRESS 4'hC CRC5
Restart
Command
/ Read Parity 0 1 … L-2 L-1
4'hC CRC5
HDR
(Write) / 1'b0 [7:0] (Read)
Adjustment
Restart Restart
LENGTH, INDEX,
L bytes of data
value L-1 value M
CCI (I3C DDR) Sequential Read Starting from a Random Location with 8-bit length and 8-bit index ( odd byte read transfer )
Index Index Index Index
M M+1 M+L-1 M+L
CRC Word CRC Word
HDR
ENTHDR SLAVE
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
DDR SLAVE SUB HDR DDR padding
LENGTH ADDRESS DATA DATA DATA Exit
Parity
Parity
Parity
Parity
Parity
setup
setup
HDR
Command ADDRESS
[7:0]
ADDRESS 4'hC CRC5
Restart
Command
/ Read Parity 0 1 … L-1
byte 4'hC CRC5
HDR
(Write) / 1'b0 [7:0] (Read) 0x00
Adjustment
Restart Restart
LENGTH, INDEX,
L bytes of data
value L-1 value M
From master to slave From slave to master

457
Figure 16 CCI (I3C DDR) Sequential Read from Random Location: 8-bit LENGTH & INDEX

Confidential
31-May-2019
CCI (I3C DDR) Sequential Read Starting from a Random Location with 16-bit length and 16-bit index ( even byte read transfer)
M M+1 M+L-2 M+L-1 M+L
Command Word for Data Word for Data Word for Command Word Data Word Data Word
CRC Word CRC Word
LENGTH & INDEX LENGTH INDEX for ReadData for ReadData for ReadData
HDR
ENTHDR SLAVE
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
DDR SLAVE SUB SUB HDR DDR
LENGTH LENGTH ADDRESS DATA DATA DATA DATA Exit
Parity
Parity
Parity
Parity
Parity
Parity
setup
setup
HDR
Command ADDRESS
[15:8] [7:0]
ADDRESS ADDRESS 4'hC CRC5
Restart
Command
/ Read Parity 0 1 … L-2 L-1
4'hC CRC5
HDR
(Write) / 1'b0 [15:8] [7:0] (Read)
Adjustment
Restart Restart
LENGTH, INDEX,
L bytes of data
value L-1 value M
CCI (I3C DDR) Sequential Read Starting from a Random Location with 16-bit length and 16-bit index ( odd byte read transfer )
M M+1 M+L-1 M+L
Command Word for Data Word for Data Word for Command Word Data Word Data Word
CRC Word CRC Word
LENGTH & INDEX LENGTH INDEX for ReadData for ReadData for ReadData
HDR
ENTHDR SLAVE
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
DDR SLAVE SUB SUB HDR DDR padding

LENGTH LENGTH ADDRESS DATA DATA DATA Exit
Parity
Parity
Parity
Parity
Parity
Parity
setup
setup
HDR
Command ADDRESS
[15:8] [7:0]
ADDRESS ADDRESS 4'hC CRC5
Restart
Command
/ Read Parity 0 1 … L-1
byte 4'hC CRC5
HDR
(Write) / 1'b0 [15:8] [7:0] (Read) 0x00
Adjustment
Restart Restart
LENGTH, INDEX,
L bytes of data
value L-1 value M

458
Figure 17 CCI (I3C DDR) Sequential Read from Random Location: 16-bit LENGTH & INDEX

Confidential
31-May-2019
6.2.2.2.3 CCI (I3C DDR) Concatenated Sequential Read from Random Location
459 When the master desires to read data longer than the slave’s I3C Max Read Length (MRL) [MIPI03], the
460 master can divide the data into multiple units, and efficiently read the data using the Concatenated Sequential
461 Read from Random Location operation (Figure 18 and Figure 19). The master shall divide the data into
462 multiple units, where all units except the last unit shall use the MRL size, and the last unit shall use a size
463 less than or equal to the MRL. The MRL size is programmable.
464 In a Concatenated Sequential Read Starting from Random Location:
465 • The master shall first transmit the total LENGTH for the data to be read.
466 • The master shall use multiple read Messages. The slave shall transmit the initial read Messages to
467 the master using the programmed MRL data bytes. And the slave may use no more than the
468 programmed MRL data bytes to transfer the last Message.
469 • If the full amount of requested data has not been received yet, then the master shall transmit
470 another read Message, but without LENGTH and INDEX.
471 • After receiving the read Message without LENGTH and INDEX, the slave shall continue
472 transmission of the read data to the master, resuming from the previous LENGTH and INDEX.
473 The master shall continue to transmit read Messages without LENGTH and INDEX multiple times, until the
474 last data is received.
475 Note:
476 When selecting a suitable value for MRL, the designer of the slave device and the system designer
478 Data Transfer Interface [MIPI04], it is beneficial to support an MRL of 64 bytes or larger (i.e. 64 bytes
479 for Data payload).

Confidential
31-May-2019
CCI (I3C DDR) Concatenated Sequential Read Starting from a Random Location with 8-bit length and 8-bit index
Index
M
Command Word for Data Word for

CRC Word
LENGTH & INDEX LENGTH & INDEX
ENTHDR
Preamble
Preamble
Preamble
DDR SLAVE SUB HDR
LENGTH
Parity
Parity
setup
Command ADDRESS ADDRESS 4'hC CRC5
HDR (Write) / 1'b0
[7:0]
[7:0] Restart
Restart
LENGTH, INDEX,
value L-1 value M

M M+1 M+X-2 M+X-1 M+X
Command Word Data Word Data Word

CRC Word
for ReadData for ReadData for ReadData
SLAVE
Preamble
Preamble
Preamble
Preamble
HDR DDR HDR
ADDRESS DATA DATA DATA DATA
Parity
Parity
Parity
setup
Restart
Command
/ Read Parity 0 1 … X-2 X-1
4'hC CRC5
Restart
(Read)
Adjustment
X bytes of data

M+X M+X+1 M+X+Y-2 M+X+Y-1 M+X+Y

CRC Word
SLAVE
Preamble
Preamble
Preamble
Preamble
HDR DDR HDR
X+Y+Z
Parity
Parity
Parity
setup
Restart
Command
/ Read Parity X X+1 … X+Y-2 X+Y-1
4'hC CRC5
Restart
(Read)
Adjustment =L
Y bytes of data

M+X+Y M+X+Y+1 M+X+Y+Z-1 M+X+Y+Z

CRC Word
SLAVE HDR
Preamble
Preamble
Preamble
Preamble
HDR DDR padding

ADDRESS DATA DATA DATA Exit
Parity
Parity
Parity
setup
Restart
Command
/ Read Parity X+Y X+Y+1 … X+Y+Z-1
byte 4'hC CRC5
HDR
(Read) 0x00
Adjustment
Restart
Z bytes of data

480
Figure 18 CCI (I3C DDR) Concatenated Sequential Read, Random Location:
8-bit LENGTH & INDEX

Confidential
31-May-2019
CCI (I3C DDR) Concatenated Sequential Read Starting from a Random Location with 16-bit length and 16-bit index
Index
M
Command Word for Data Word for Data Word for

CRC Word
LENGTH & INDEX LENGTH INDEX
ENTHDR
Preamble
Preamble
Preamble
Preamble
DDR SLAVE SUB SUB HDR
LENGTH LENGTH
Parity
Parity
Parity
setup
Command ADDRESS ADDRESS ADDRESS 4'hC CRC5
HDR (Write) / 1'b0
[15:8] [7:0]
[15:8] [7:0] Restart
Restart
LENGTH, INDEX,
value L-1 value M

M M+1 M+X-2 M+X-1 M+X

CRC Word
SLAVE
Preamble
Preamble
Preamble
Preamble
HDR DDR HDR
Parity
Parity
Parity
setup
Restart
Command
/ Read Parity 0 1 … X-2 X-1
4'hC CRC5
Restart
(Read)
Adjustment
X bytes of data

M+X M+X+1 M+X+Y-2 M+X+Y-1 M+X+Y

CRC Word
SLAVE
Preamble
Preamble
Preamble
Preamble
HDR DDR HDR
X+Y+Z
Parity
Parity
Parity
setup
Restart
Command
/ Read Parity X X+1 … X+Y-2 X+Y-1
4'hC CRC5
Restart
(Read)
Adjustment =L
Y bytes of data

M+X+Y M+X+Y+1 M+X+Y+Z-1 M+X+Y+Z

CRC Word
SLAVE HDR
Preamble
Preamble
Preamble
Preamble
HDR DDR padding

ADDRESS DATA DATA DATA Exit
Parity
Parity
Parity
setup
Restart
Command
/ Read Parity X+Y X+Y+1 … X+Y+Z-1
byte 4'hC CRC5
HDR
(Read) 0x00
Adjustment
Restart
Z bytes of data

481
Figure 19 CCI (I3C DDR) Concatenated Sequential Read, Random Location:
16-bit LENGTH & INDEX

Confidential
31-May-2019
6.2.2.2.4 CCI (I3C DDR) Sequential Write Starting from Random Location
482 In a Sequential Write Starting from Random Location (Figure 20), the master shall transmit:
483 • The HDR-DDR Command Word
484 • The HDR-DDR Data Word including LENGTH and INDEX
485 • One or more HDR-DDR Write Data Words, and
486 • The HDR-DDR CRC Word.
487 If the number of 8-bit data words written is odd (i.e. the value in the LENGTH field is even), then the master
488 shall insert one padding byte in the second byte of the last data word, with value 8’h00. When the slave
489 receives the Sub Address, the slave loads it into the INDEX and auto-increments the INDEX after each data
490 byte is received.
491 The slave can identify the padding byte from the value of the LENGTH field and the number of 8-bit data
492 words received, and shall ignore the padding byte. Note that the INDEX is not incremented by the padding
493 byte.
494 In a Sequential Write Starting from Random Location, the value of LENGTH shall be set such that the master
495 does not exceed the maximum data byte length limit defined by the slave’s I3C Max Write Length (MWL)
496 [MIPI03]. Note that the total number of bytes of “Data Word for INDEX”, “Data Word for LENGTH”, and
497 “Data Word for Write Data” shall not exceed MWL.
Example:
498 For a slave with MWL of 8 bytes, using 16-bit INDEX (so “Data Word for INDEX” is 2 bytes)
499 and 16-bit LENGTH (so “Data Word for LENGTH” is 2 bytes), the maximum number of “Data
500 Word for Write Data” is 8 – (2 + 2) bytes = 4 bytes. Since the LENGTH field is zero-based, it
501 would contain the value 3 (16’d3).
502 The slave cannot terminate the DDR Write Message, and shall receive all HDR-DDR Write Data sent by the
503 master.
504 Note:
505 When selecting a suitable value for MWL, the designer of the slave device and the system designer
507 Data Transfer Interface [MIPI04], it is beneficial to support an MWL of 68 bytes or larger (i.e. 64 bytes
508 for Data payload + 2 bytes for a Data Word for INDEX + 2 bytes for a Data Word for LENGTH).

Confidential
31-May-2019
CCI (I3C DDR) Sequential Write to a Random Location with 8-bit length and 8-bit index ( even byte write transfer)
M M+1 M+L-2 M+L-1 M+L
Data Word for Data Word Data Word

Command Word CRC Word
LENGTH & INDEX for WriteData for WriteData
HDR
ENTHDR
Preamble
Preamble
Preamble
Preamble
Preamble
DDR SLAVE SUB
LENGTH DATA DATA DATA DATA Exit
Parity
Parity
Parity
Parity
setup
HDR
Command ADDRESS
[7:0]
ADDRESS
0 1 … L-2 L-1
4'hC CRC5
HDR
(Write) / 1'b0 [7:0]
Restart Restart
LENGTH, INDEX,
L bytes of data
value L-1 value M
Data Word for LENGTH + Data Word for INDEX + Data Word for Write Data ≤ MWL
CCI (I3C DDR) Sequential Write to a Random Location with 8-bit length and 8-bit index ( odd write byte transfer )
M M+1 M+L-1 M+L
Data Word for Data Word Data Word

LENGTH & INDEX for WriteData for WriteData
HDR
ENTHDR
Preamble
Preamble
Preamble
Preamble
Preamble
DDR SLAVE SUB padding
LENGTH DATA DATA DATA Exit
Parity
Parity
Parity
Parity
setup
HDR
Command ADDRESS
[7:0]
ADDRESS
0 1 … L-1
byte 4'hC CRC5
HDR
(Write) / 1'b0 [7:0] 0x00
Restart Restart
LENGTH, INDEX,
L bytes of data
value L-1 value M
CCI (I3C DDR) Sequential Write to a Random Location with 16-bit length and 16-bit index ( even byte write transfer)
M M+1 M+L-2 M+L-1 M+L
Data Word Data Word Data Word Data Word

for LENGTH for INDEX for WriteData for WriteData
HDR
ENTHDR
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
DDR SLAVE SUB SUB
LENGTH LENGTH DATA DATA DATA DATA Exit
Parity
Parity
Parity
Parity
Parity
setup
HDR
Command ADDRESS
[15:8] [7:0]
ADDRESS ADDRESS
0 1 … L-2 L-1
4'hC CRC5
HDR
(Write) / 1'b0 [15:8] [7:0]
Restart Restart
LENGTH, INDEX,
L bytes of data
value L-1 value M
CCI (I3C DDR) Sequential Write to a Random Location with 16-bit length and 16-bit index ( odd write byte transfer )
M M+1 M+L-1 M+L
Data Word Data Word Data Word Data Word

for LENGTH for INDEX for WriteData for WriteData
HDR
ENTHDR
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
DDR SLAVE SUB SUB padding

LENGTH LENGTH DATA DATA DATA Exit
Parity
Parity
Parity
Parity
Parity
setup
HDR
Command ADDRESS
[15:8] [7:0]
ADDRESS ADDRESS
0 1 … L-1
byte 4'hC CRC5
HDR
(Write) / 1'b0 [15:8] [7:0] 0x00
Restart Restart
LENGTH, INDEX,
L bytes of data
value L-1 value M

509
Figure 20 CCI (I3C DDR) Sequential Write Starting from Random Location

Confidential
31-May-2019
6.3 CCI (I3C) Error Detection and Recovery
6.3.1 CCI (I3C SDR) Error Detection and Recovery Method

510 The error detection and recovery methods specified in this Section are provided in order to avoid fatal
511 conditions when errors occur. The CCI (I3C SDR) error detection and recovery methods follow the I3C
512 Specification. The I3C error detection and recovery method for the Slave and Master are specified in
513 [MIPI03]. A CCI (I3C SDR) compatible device shall support both the methods defined by I3C and the
514 methods defined in this Section regarding CCI (I3C SDR), respectively.
6.3.1.1 Error Detection and Recovery Method for CCI (I3C SDR) Slave Devices
515 The SS0 error summarized in Table 5 shall be supported for all CCI (I3C SDR) Slave Devices. If the CCI
516 Slave detects the SS0 error, the CCI Slave shall set to 1’b1 in Protocol Error Flag of GETSTATUS. Details
517 of the SS0 error are described in Section 6.3.1.1.2.
518 Table 5 CCI (I3C SDR) Slave Error Types
Error
Description Error Detection Method Error Recovery Method
Type
SS0 Read without INDEX Error Detect an error if the Slave Enable STOP or Repeated
receives the Slave’s Dynamic START detector and neglect
Address (except 7’h7E) with a other patterns.
Read (R/W bit is 1) correctly
but it does not have the INDEX.
6.3.1.1.1 Clearing the INDEX After Detecting I3C Error

519 The CCI (I3C SDR) Slave shall clear the INDEX value when the I3C Slave detects S2 [MIPI03] or S6
520 ([MIPI03], optional) during the “CCI (I3C SDR) Read/Write Operations” in Table 2. Note that this rule shall
521 not be applicable to other Operations (e.g., I3C CCC Transfers). As defined in the I3C specification, the I3C
522 Slave sets to 1’b1 in the Protocol Error Flag of GETSTATUS (defined in the I3C specification) when the I3C
523 Slave detects an error.
524 Clearing the INDEX due to S2 and S6 errors in the CCI (I3C SDR) Write Operations (Single Write to Random
525 Location, Sequential Write Starting from Random Location) is described below:
526 • If an S2 error occurs in the CCI (I3C SDR) Write Operations, the CCI Slave cannot count up the
527 INDEX because the CCI Slave cannot receive the correct write data. As a result, the INDEX in the
528 CCI Slave may be different from the INDEX value that the Master is expecting. In order to avoid
529 this situation, the CCI Slave shall clear the INDEX value.
530 • When the I3C Master doesn’t have the collision detector and the I3C Slave has it, the INDEX in
531 the CCI Slave may be different from the INDEX value that the Master is expecting in case of an
532 S6 error. This is because the CCI Master assumes the INDEX counter in the Slave to be counting
533 up, but the CCI Slave stops the counter. In order to avoid this situation, the CCI Slave shall clear
534 the INDEX value.
535 Clearing the INDEX due to an S2 error in the CCI (I3C SDR) Read Operations (Single/Sequential Read to
536 Random Location) is described below:
537 • If an S2 error occurs in the CCI (I3C SDR) Single/Sequential Read from Random Location during
538 sub address, the CCI Slave cannot update the value of INDEX because the I3C Slave cannot get
539 the correct sub address. This could cause slave to send undefined or wrong data. In order to avoid
540 this situation, the CCI Slave shall clear the INDEX value.

Confidential
31-May-2019
6.3.1.1.2 SS0 Error

541 The CCI Slave shall detect an SS0 error if the CCI Slave receives the slave address (except 7’h7E) with a
542 Read (R/W bit is 1) correctly but it does not have the INDEX value. After detecting the SS0 error, the CCI
543 Slave shall replace ACK generated by the I3C Slave with NACK during SS0 error and then wait for STOP
544 or Repeated START. Figure 21 illustrates how NACK is generated in CCI (I3C SDR) Sequential Read from
545 Random Location, when SS0 error occurs during this Message.
CCI (I3C SDR) Sequential Read Starting from a Random
Location with 8-bit index and 8-bit data without 7'h7E Address Retry
SLAVE SUB ADDRESS SLAVE SLAVE SUB ADDRESS SLAVE

Sr 0 A T Sr 1 N Sr 0 A T Sr 1 A
ADDRESS [7:0] ADDRESS ADDRESS [7:0] ADDRESS
INDEX, value M Parity Recovered INDEX, value M

Error by Sr
I3C Slave S2
Normal Normal
Status Error
The I3C Slave neglects all
NACK
received data until Sr or P
The CCI Slave clears

the value of INDEX
CCI Slave
Previous INDEX value, K No INDEX INDEX M
INDEX
Read w/o INDEX Recovered by Sr
CCI Slave SS0

Normal Normal
Status Error
The CCI Slave neglects all
received data until Sr or P
From Slave to Master
S = START condition
From Master to Slave Sr = Repeated START condition
P = STOP condition
N = Not acknowledge
Transition Bit (End-of-Data for Read Data) T = Transition Bit alternative to ACK/NACK
546
Figure 21 Example of SS0 Error Detection

Confidential
31-May-2019
6.3.2 CCI (I3C DDR) Error Detection and Recovery Method

547 The error detection and recovery methods specified in this Section are provided in order to avoid fatal
548 conditions when errors occur. The CCI (I3C DDR) error detection and recovery methods follow the I3C
549 Specification. The I3C error detection and recovery method for the Slave and Master are specified in
550 [MIPI03]. A CCI (I3C DDR) compatible device shall support both the methods defined by I3C and the
551 methods defined in this section regarding CCI (I3C DDR) respectively.
6.3.2.1 Error Detection and Recovery Method for CCI (I3C DDR) Slave Devices
552 The two Error Types summarized in Table 6 shall be supported for all CCI (I3C DDR) Slave Devices. Each
553 Error Type is further explained below the table. If the Slave detects an SD0 or SD1 error, the Slave shall set
554 the Protocol Error Flag in GETSTATUS (defined in the I3C specification) to 1’b1. Details of the SD0 and
555 SD1 errors are described in Section 6.3.2.1.2 and Section 6.3.2.1.3, respectively.
556 Table 6 CCI (I3C DDR) Slave Error Types
Error
Type
SD0 Read without INDEX Error Detect an error if the Slave Enable HDR Exit or HDR
receives the DDR command Restart detector and neglect
Word[15] = 1 (Read) correctly, but other patterns
it does not have the INDEX
SD1 Write over LENGTH Error Detect an error if the value of Clear INDEX value. Enable
Preamble following LENGTH +1 HDR Exit or HDR Restart
bytes of the Write Data is 2b11 detector and neglect other
patterns
6.3.2.1.1 Clearing INDEX After Detecting I3C Error

557 The CCI Slave shall clear the INDEX value when the I3C Slave detects an I3C DDR error defined in the I3C
558 specification (Framing Error, Parity Error, CRC5 Error, or optional Monitoring Error) during the “CCI (I3C
559 DDR) Read/Write Operations” in Table 3. Note that this rule shall not be applicable to other Operations (e.g.,
560 I3C CCC Transfers). As defined in the I3C specification, when the I3C Slave detects an error it sets the
561 Protocol Error Flag in GETSTATUS (defined in the I3C specification) to 1’b1.
562 If a parity error occurs during the sub address in a CCI (I3C DDR) Read Operation (i.e. Sequential or
563 Concatenated Sequential Read from Random Location), the CCI Slave cannot update the value of INDEX
564 because the I3C Slave cannot get the correct sub address. This could cause slave to send undefined or wrong
565 data. In order to avoid this situation, the CCI Slave shall clear the INDEX value.
6.3.2.1.2 SD0 Error

566 The CCI Slave shall detect an SD0 error if the CCI Slave receives a DDR command with Read (DDR
567 command Word[15] = 1) correctly, but no INDEX value. After detecting the SD0 error, the CCI Slave shall
568 replace the ACK generated by the I3C Slave with a NACK during SD0 error, and then wait for HDR Exit or
569 HDR Restart. Figure 22 illustrates how NACK is generated in a CCI (I3C DDR) Sequential Read from
570 Random Location.

Confidential
31-May-2019
571
CCI (I3C DDR) Sequential Read Starting from a
Random Location with 8-bit length and 8-bit index Retry
Command Word for Data Word for Command Word Command Word for
CRC Word
LENGTH & INDEX LENGTH & INDEX for ReadData LENGTH & INDEX
ENTHDR SLAVE
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
DDR SLAVE SUB HDR DDR HDR DDR SLAVE
LENGTH ADDRESS 19 SCL
Parity
Parity
Parity
Parity
setup
Command ADDRESS ADDRESS 4'hC CRC5 Command Command ADDRESS
HDR (Write) / 1'b0
[7:0]
[7:0] Restart (Read)
/ Read Parity clock Restart (Write) / 1'b0
Adjustment
Restart
LENGTH, INDEX, Parity Error Recovered by
NACK
value L-1 value M HDR Restart
I3C Slave
Normal Parity Error Normal
Status
The I3C Slave neglects all received
data until HDR Restart or HDR Exit
The CCI Slave clears
the value of INDEX
CCI Slave Previous Index value, K No INDEX
INDEX
Recovered by
Read w/o INDEX HDR Restart or HDR Exit
CCI Slave
Normal SD0 Error Normal
Status
The CCI Slave neglects all received
data until HDR Restart or HDR Exit
From Master to Slave From Slave to Master
572
Figure 22 Example of SD0 Error Detection

Confidential
31-May-2019
6.3.2.1.3 SD1 Error

573 In CCI (I3C DDR), the LENGTH is included in the structure. If the CCI Slave receives data exceeding the
574 LENGTH, the Slave shall discard the extra data and detect this as an error condition.
575 In order to inform the Master of the error condition, the CCI Slave shall detect the SD1 error if the CCI Slave
576 receives a Preamble with value 2’b11 after receiving L bytes of WriteData. After detecting the SD1 error, the
577 CCI Slave shall clear the value of INDEX and then wait for HDR Exit or HDR Restart. Figure 23 illustrates
578 how INDEX is cleared in CCI (I3C DDR) Sequential Write to Random Location.

Confidential
31-May-2019
579
CCI (I3C DDR) Sequential Write to a Random Location with 8-bit length and 8-bit index
Data Word for Data Word Data Word Data Word
LENGTH & INDEX for WriteData for WriteData for WriteData
HDR
ENTHDR Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
DDR SLAVE SUB
LENGTH DATA DATA DATA DATA DATA DATA Exit
Parity
Parity
Parity
Parity
Parity
setup
HDR
Command ADDRESS
[7:0]
ADDRESS
0 1 … L-2 L-1 L L+1 … 4'hC CRC5
HDR
(Write) / 1'b0 [7:0]
Restart Restart
LENGTH, INDEX, E bytes of data

L bytes of data
value L-1 value M (Illegal write data over the
number of LENGTH)
I3C Slave
Normal
Status
Recovered by
HDR Restart or
HDR Exit
CCI Slave Previous Index value, K
No INDEX
INDEX M M+1 M+L-2 M+L-1 M+L
Write over LENGTH Clear the value of INDEX

CCI Slave
Normal SD1 Error Normal
Status

580
Figure 23 Example of SD1 Error Detection

Confidential
31-May-2019
6.3.2.2 Error Detection and Recovery Method for CCI (I3C DDR) Master Devices
581 The MD0 Error Type summarized in Table 7 may be supported for all CCI (I3C DDR) Master Devices. Each
582 Error Type is further explained below Table 7. Details of MD0 error are described in Section 6.3.2.2.1.
583 Table 7 CCI (I3C DDR) Master Error Type
Error
Type
MD0 Read over LENGTH Error Detect an error if the value of Send Master Abort and then
(optional) Preamble[1] following LENGTH +1 HDR Exit or HDR Restart
bytes of the Read Data is 1b1
6.3.2.2.1 MD0 Error

584 In CCI (I3C DDR), the LENGTH is included in the structure. If the CCI Master receives read data exceeding
585 the LENGTH, it might cause big issues because memory leakage may occur, depending on the
586 implementation. In order to avoid fatal problems, the CCI Master may detect the MD0 error if the CCI Master
587 receives Preamble[1]=1’b1 after receiving LENGTH+1 bytes of ReadData. After detecting the MD0 Error,
588 the CCI Master may send Master Abort, and then send HDR Exit or HDR Restart, as illustrated in Figure
589 24.

Confidential
31-May-2019
590
CCI (I3C DDR) Sequential Read Starting from a Random Location with 8-bit length and 8-bit index
CRC Word
HDR
Preamble[1]
Preamble[0]
ENTHDR SLAVE
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
DDR SLAVE SUB HDR DDR
LENGTH ADDRESS DATA DATA DATA DATA Exit
Parity
Parity
Parity
Parity
Parity
setup
HDR
Command ADDRESS ADDRESS 4'hC CRC5
Restart
Command … HDR
HDR Restart or HDR Exit

[7:0] / Read Parity 0 1 L-2 L-1
(Write) / 1'b0 [7:0] (Read)
Adjustment
Restart Restart
LENGTH, INDEX,
L bytes of data
value L-1 value M
Recovered by
Master Abort
I3C Master
Status Normal
Read over LENGTH

CCI Master MD0
Normal Normal
Status Error

591
Figure 24 Example of MD0 Error Detection

Confidential
31-May-2019
6.3.3 Error Detection and Recovery for CCI (I3C) Master Devices
592 In many cases, the Master can detect an error inside the Slave by receiving NACK. However, for example in
593 case of an S2 or S6 error in the CCI (I3C SDR) Write Operations, the Master cannot detect it by receiving
594 NACK because there is no chance for the Slave to send NACK by the end of the operation (STOP or Repeated
595 START). Therefore if high reliability is required, the Master may transmit GETSTATUS (defined in the I3C
596 specification) at each important point.
597 Note:
598 E.g., the important point is that after critical CCI (I3C SDR) Write Operations, after CCI (I3C SDR)
599 Write Operations before moving to CCI (I3C DDR), after multiple CCI (I3C SDR) Read/Write
600 Operations before long pause if the last message is CCI (I3C SDR) Write Operations.
601 As a result, the Master can detect each error by the following methods:
602 1. Slave’s error by receiving NACK
603 2. Slave’s error during CCI (I3C SDR) or CCI (I3C DDR) Write Operations by sending
604 GETSTATUS
605 3. Master’s I3C SDR Error defined in the I3C specification (M0, M1 or M2 error)
606 4. Master’s I3C DDR Error defined in the I3C specification (including the Master sending HDR Exit
607 or HDR Restart pattern)
608 After detecting an error, the Master should try the following error recovery method:
609 1. The Master may retry sending the same CCI (I3C SDR) Read/Write Operations or CCI (I3C DDR)
610 Read/Write Operations again.
611 2. The Master may send certain other CCI (I3C SDR) Read/Write Operations or CCI (I3C DDR)
612 Read/Write Operations, except CCI (I3C SDR) Single/Sequential Read From Current Location
613 because the Slave would generate NACK again due to an SS0 or SD0 error.
614 In addition to, or instead of, a retry, the Master may read GETSTATUS, or try Escalation Handling as defined
615 in the I3C specification.
6.4 CCI (I2C) Slave Addresses

616 For camera modules having only raw Bayer output the 7-bit slave address should be 7’b011011X, where
617 X = either 1’b0 or 1’b1. For all other camera modules the 7-bit slave address should be 7’b011110X.
6.5 CCI (I3C) Slave Addresses

618 All camera modules shall use their own Dynamic Address as assigned by the I3C Master.

Confidential
31-May-2019
6.6 CCI Multi-Byte Registers

619 The description in this Section applies to both CCI (I2C) and CCI (I3C).
6.6.1 Overview
620 Peripherals contain a wide range of different register widths for various control and setup purposes. This
621 Specification supports the following register widths:
622 • 8-bit: Generic setup registers
623 • 16-bit: Parameters like line-length, frame-length and exposure values
624 • 32-bit: High precision setup values
625 • 64-bit: For needs of future sensors
626 In general, the byte-oriented access protocols described in the previous sections provide an efficient means
627 to access multi-byte registers. However, the registers should reside in a byte-oriented address space, and the
628 address of a multi-byte register should be the address of its first byte. Thus, addresses of contiguous multi-
629 byte registers will not be contiguous. For example, a 32-bit register with its first byte at address 0x8000 can
630 be read by means of a sequential read of four bytes, starting at random address 0x8000. If there is an additional
631 4-byte register with its first byte at 0x8004, then it could then be accessed using a four-byte Sequential Read
632 from the Current Location protocol.
633 The motivation for a generalized multi-byte protocol (rather than fixing register widths at 16 bits) is
634 flexibility. The protocol described below provides a way of transferring 16-bit, 32-bit, or 64-bit values over
635 a 16-bit INDEX, 8-bit data, two-wire serial link while ensuring that the bytes of data transferred for a multi-
636 byte register value are always consistent (temporally coherent).
637 Using this protocol, a single CCI Message can contain one, two, or all of the different register widths used
638 within a device.
639 The MS byte of a multi-byte register shall be located at the lowest address, and the LS byte shall be located
640 at the highest address.
641 The address of the first byte of a multi-byte register is not necessarily related to register size (i.e., not required
642 to be an integer multiple of register size in bytes). Register address alignment represents an implementation
643 choice between processing-optimized vs. bandwidth-optimized organizations. There are no restrictions on
644 the number or mix of multi-byte registers within the available 64K by 8-bit INDEX space, with the exception
645 of certain rules for the valid locations for the MS bytes and LS bytes of registers.
646 Partial access to multi-byte registers is not allowed. A multi-byte register shall only be accessed by a single
647 sequential Message. When a multi-byte register is accessed, its bytes shall be accessed in ascending address
648 order (i.e. first byte is accessed first, second byte is accessed second, etc.).
649 When a multi-byte register is accessed, the following re-timing rules shall be followed:
650 • For a Write operation, the updating of the register shall be deferred to a time when the last bit of
651 the last byte has been received.
652 • For a Read operation, the value read shall reflect the status of all bytes at the time that the first bit
653 of the first byte was read.
654 Section 6.6.3 describes example re-timing behavior for multi-byte register accesses.
655 Figure 25 and Figure 26 illustrate that without re-timing, data could be corrupted.

Confidential
31-May-2019
Internal 32-bit Register Value (Locations M, M+1, M+2 and M+3)

0xFC FD FE FF 0x01 02 03 04
Register Values updated by internal logic
(For example only)
Register Index
Index M Index M+1 Index M+2 Index M+3
SLAVE
S 1 A DATA = 0xFC A DATA=0xFD A DATA=0x03 A DATA=0x04 A P
ADDRESS
MS Data Byte LS Data Byte
0xFC 0xFD 0x03 0x04
DATA[31:24] DATA[23:16] DATA[15:8] DATA[7:0]
DATA[31:0]

656
Figure 25 Corruption of 32-bit Register During Read Message

0xFC FD FE FF 0x01 FD FE FF 0x01 02 FE FF 0x01 02 03 FF 0x01 02 03 04
Internal logic
reads register
value
(For example
Register Index only)
SLAVE
S 0 A DATA=0x01 A DATA=0x02 A DATA=0x03 A DATA=0x04 A P
ADDRESS
0x01 0x02 0x03 0x04
DATA[31:0]

657
Figure 26 Corruption of 32-bit Register During Write Message

Confidential
31-May-2019
6.6.2 Transmission Byte Order for Multi-Byte Register Values

658 Figure 27, Figure 28, and Figure 29 illustrate the requirement that the first byte of a CCI Message shall
659 always be the MS byte of a multi-byte register, and the last byte of the CCI Message shall always be the LS
660 byte of the multi-byte register.
DATA[15:0]
SLAVE SUB
S 0 A A DATA[15:8] A DATA[7:0] A P
ADDRESS ADDRESS
Index Value,
M
Index M Index M+1
661
Figure 27 Example 16-bit Register Write
Register Index
A/
A DATA A DATA A DATA A DATA
A
DATA[31:0]
662
Figure 28 Example 32-bit Register Write (Address Not Shown)
Register Index
A/
A DATA A DATA A A DATA A DATA
A
DATA[63:0]
663
Figure 29 Example 64-bit Register Write (Address Not Shown)

Confidential
31-May-2019
6.6.3 Multi-Byte Register Protocol (Informative)

664 Each device may have both single-byte registers and multi-byte registers. Internally a device must understand
665 what addresses correspond to the different register widths.
6.6.3.1 Reading Multi-Byte Registers

666 To ensure that the value read from a multi-byte register is consistent (i.e., that all of the transmitted bytes are
667 temporally coherent), the device can internally transfer the register contents into a temporary buffer at the
668 time when the register’s MS byte is read. The contents of the temporary buffer can then be sent out as a
669 sequence of bytes on the SDA line. Figure 30 and Figure 31 illustrate multi-byte register read operations.
670 The temporary buffer is always updated, except in the case of a read operation that is incremental within the
671 same multi-byte register.
Internal 16-bit Register Value (Locations M and M+1)

0xFC FD 0x01 02
Internal 16-bit Register Value (Locations M+2 and M+3)

0xFE FF 0x03 04
Register Index (For example only)
Temporary Buffer
0x00 00 0xFC FD 0x03 04
A read from MS byte of the register Incremental read within the same
causes the whole register value to multi-byte register.
be transferred into a temporary Temporary Buffer not updated
buffer
SLAVE
S 1 A DATA = 0xFC A DATA=0xFD A DATA=0x03 A DATA=0x04 A P
ADDRESS
MS Data Byte LS Data Byte MS Data Byte LS Data Byte
0xFC 0xFD 0x03 0x04
DATA[15:0] DATA[15:0]

672
Figure 30 Example 16-bit Register Read
673 In this definition no distinction is made between a register being accessed incrementally via multiple separate
674 single-byte read Messages with no intervening data writes, vs. a register being accessed via a single multi-
675 location read Message. This protocol purely relates to the behavior of the INDEX value.

Confidential
31-May-2019
676 Examples of when the temporary buffer is updated include:

677 • When the MS byte of a register is accessed
678 • When the INDEX has crossed a multi-byte register boundary
679 • Successive single-byte reads from the same INDEX location
680 • When the INDEX value for the byte about to be read is ≤ the previous INDEX
681 Note that the values read back are only guaranteed to be consistent if the contents (bytes) of the multi-byte
682 register are accessed in an incremental manner.
683 The contents of the temporary buffer are reset to zero by START and STOP conditions.

0xFC FD FE FF 0x01 02 03 04
Register Index (For example only)
Temporary Buffer
0x00 00 00 00 0xFC FD FE FF
A read from MS byte of the register Incremental read within the same
causes the whole register value to multi-byte register.
be transferred into a temporary Temporary Buffer not updated
buffer
SLAVE
S 1 A DATA = 0xFC A DATA=0xFD A DATA=0xFE A DATA=0xFF A P
ADDRESS
0xFC 0xFD 0xFE 0xFF
DATA[31:0]

684
Figure 31 Example 32-bit Register Read

Confidential
31-May-2019
6.6.3.2 Writing Multi-Byte Registers

685 To ensure that the value written is consistent, the bytes of data from a multi-byte register are written into a
686 temporary buffer. Only after the LS byte of the register is written is the full multi-byte value transferred into
687 the internal register location.
688 Figure 32 and Figure 33 illustrate multi-byte register write operations.
689 CCI Messages that only write to the LS or MS byte of a multi-byte register are not allowed. Single byte
690 writes to a multi-byte register addresses may cause undesirable behavior in the device.
Internal 16-bit Register Value (Locations M and M+1)

0xFC FD 0x01 02
Internal 16-bit Register Value (Locations M+2 and M+3)

0xFE FF 0x03 04
Register Index
Temporary Buffer
0x00 00 0x01 00 0x00 00 0x03 00 0x00 00
A write to the LS byte of the

register causes the contents of the
temporary buffer to be transferred
onto the register location
SLAVE
ADDRESS
MS Data Byte LS Data Byte MS Data Byte LS Data Byte
0x01 0x02 0x03 0x04
DATA[15:0] DATA[15:0]

691

Confidential
31-May-2019

0xFC FD FE FF 0x01 02 03 04
Register Index
Temporary Buffer
0x00 00 00 00 0x01 00 00 00 0x01 02 00 00 0x01 02 03 00 0x00 00 00 00
A write to the LS byte of the

register causes the contents of the
temporary buffer to be transferred
onto the register location
SLAVE
ADDRESS
0x01 0x02 0x03 0x04
DATA[31:0]

692

Confidential
31-May-2019
6.7 CCI I/O Electrical and Timing Specifications

693 The CCI I/O stages electrical specifications (Table 8) and timing specifications (Table 9) conform to I2C
694 Fast-mode and Fast-mode Plus devices. Information presented in Table 8 is from [NXP01].
695 The CCI timings specified in Table 9 are illustrated in Figure 34.
696 Table 8 CCI I/O Electrical Specifications
Fast-mode Fast-mode Plus
Parameter Symbol Unit
Min. Max. Min. Max.
LOW level input voltage VIL -0.5 0.3 VDD -0.5 0.3 VDD V
HIGH level input voltage VIH 0.7VDD Note 1 0.7VDD Note 1 V
Hysteresis of Schmitt trigger
VHYS 0.05VDD - 0.05VDD - V
inputs
LOW level output voltage (open
drain) at 2mA sink current
V
VDD > 2V VOL1 0 0.4 0 0.4
VDD < 2V VOL3 0 0.2VDD 0 0.2VDD
Output fall time from VIHmin to
20 x (VDD / 20 x (VDD /
VILmax with bus capacitance from tOF 250 120 ns
5.5 V) 5.5 V)
10 pF to 400 pF
Pulse width of spikes which shall
tSP 0 50 0 50 ns
be suppressed by the input filter
Input current each I/O pin with an
-10 10 -10 10
input voltage between 0.1 VDD and II μA
Note 2 Note 2 Note 2 Note 2
0.9 VDD
Input/Output capacitance (SDA) CI/O - 10 - 10 pF
Input capacitance (SCL) CI - 10 - 10 pF
Note:
1. Maximum VIH = VDDmax + 0.5V
2. I/O pins of Fast-mode and Fast-mode Plus devices shall not obstruct the SDA and SCL line if VDD
is switched off

Confidential
31-May-2019
697 Table 9 CCI I/O Timing Specifications

Fast-mode Fast-mode Plus
Parameter Symbol Unit
Min. Max. Min. Max.
SCL clock frequency fSCL 0 400 0 1000 kHz
Hold time (repeated) START
condition. After this period, the tHD;STA 0.6 - 0.26 - μs
first clock pulse is generated
LOW period of the SCL clock tLOW 1.3 - 0.5 - μs
HIGH period of the SCL clock tHIGH 0.6 - 0.26 - μs
Setup time for a repeated START
tSU;STA 0.6 - 0.26 - μs
condition
Data hold time 0 -
tHD;DAT 0 - μs
Note 2 Note 3
Data set-up time 100
tSU;DAT - 50 - ns
Note 4
Rise time of both SDA and SCL
tR 20 300 - 120 ns
signals
Fall time of both SDA and SCL 20 x (VDD 20 x (VDD
tF 300 120 ns
signals / 5.5 V) / 5.5 V)
Set-up time for STOP condition tSU;STO 0.6 - 0.26 - μs
Bus free time between a STOP
tBUF 1.3 - 0.5 - μs
and START condition
Capacitive load for each bus line CB - 400 - 550 pF
Data valid time 0.9 0.45
tVD;DAT - - μs
Note 5 Note 3 Note 3
Data valid acknowledge time 0.9 0.45
tVD;ACK - - μs
Note 6 Note 3 Note 3
Noise margin at the LOW level for
each connected device (including VnL 0.1 x VDD - 0.1 x VDD - V
hysteresis)
Noise margin at the HIGH level for
each connected device (including VnH 0.2 x VDD - 0.2 x VDD - V
hysteresis)
Note:
1. All values referred to VIHmin = 0.7VDD and VILmax = 0.3VDD
2. A device shall internally provide a hold time of at least 300 ns for the SDA signal (referred to the
VIHmin of the SCL signal) to bridge the undefined region of the falling edge of SCL
3. The maximum tHD;DAT could be 0.9 µs and 0.45 µs for Fast-mode and Fast-mode Plus, but must be
less than the maximum of tVD;DAT or tVD;ACK by a transition time. This maximum must only be met if
the device does not stretch the LOW period (tLOW) of the SCL signal. If the clock stretches the SCL,
then the data must be valid by the set-up time before it releases the clock.
4. A Fast-mode I2C-bus device can be used in a Standard-mode I2C-bus system, but the requirement
tSU:DAT ≥ 250 ns shall be then met. This will be automatically the case if the device does not stretch
the LOW period of the SCL signal. If such device does stretch the low period of SCL signal, it shall
output the next data bit to the SDA line trMAX + tSU:DAT = 1000 + 250 = 1250 ns (according to the
Standard-mode I2C Bus specification [NXP01]) before the SCL line is released.
5. tVD;DAT = time for data signal from SCL LOW to SDA output (HIGH or LOW, whichever is worse).
6. tVD;ACK = time for Acknowledgement signal from SCL LOW to SDA output (HIGH or LOW, whichever
is worse)

Confidential
31-May-2019
START Repeated-START STOP

tBUF tVD;DAT
SDA
tR
tF
tSU;STA
tSU;DAT tVD;ACK tSU;STO
tHD;DAT tHD;STA
SCL
tLOW 9th clock
tHIGH
tHD;STA
tSP
698
Figure 34 CCI I/O Timing

Confidential
31-May-2019

Confidential
31-May-2019
7 Physical Layer
699 The CSI-2 lane management layer interfaces with the D-PHY and/or C-PHY physical layers described in
700 [MIPI01] and [MIPI02], respectively. A device shall implement either the C-PHY 2.0 or the D-PHY 2.5
701 physical layer and may implement both. A practical constraint is that the PHY technologies used at both ends
702 of the Link need to match: a D-PHY transmitter cannot operate with a C-PHY receiver, or vice versa.
7.1 D-PHY Physical Layer Option

703 The D-PHY physical layer for a CSI-2 implementation is typically composed of a number of unidirectional
704 data Lanes and one clock Lane. All CSI-2 transmitters and receivers implementing the D-PHY physical layer
705 shall support continuous clock behavior on the Clock Lane, and optionally may support non-continuous clock
706 behavior.
707 For continuous clock behavior the Clock Lane remains in high-speed mode, generating active clock signals
708 between the transmissions of data packets.
709 For non-continuous clock behavior the Clock Lane enters the LP-11 state between the transmissions of data
710 packets.
711 The minimum D-PHY physical layer requirement for a CSI-2 transmitter is
712 • Data Lane Module: Unidirectional master, HS-TX, LP-TX and a CIL-MFEN function
713 • Clock Lane Module: Unidirectional master, HS-TX, LP-TX and a CIL-MCNN function
714 The minimum D-PHY physical layer requirement for a CSI-2 receiver is
715 • Data Lane Module: Unidirectional slave, HS-RX, LP-RX, and a CIL-SFEN function
716 • Clock Lane Module: Unidirectional slave, HS-RX, LP-RX, and a CIL-SCNN function
717 All CSI-2 implementations supporting the D-PHY physical layer option shall support forward escape ULPS
718 on all D-PHY Data Lanes.
719 To enable higher data rates and higher number of lanes the physical layer described in [MIPI01] includes an
720 independent deskew mechanism in the Receive Data Lane Module. To facilitate deskew calibration at the
721 receiver the transmitter Data Lane Module provides a deskew sequence pattern.
722 Since deskew calibration is only valid at a given transmit frequency:
723 For initial calibration sequence the Transmitter shall be programmed with the desired frequency for
724 calibration. It will then transmit the deskew calibration pattern and the Receiver will autonomously detect
725 this pattern and tune the deskew function to achieve optimum performance.
726 For any transmitter frequency changes the deskew calibration shall be rerun.
727 Some transmitters and/or receivers may require deskew calibration to be rerun periodically and it is suggested
728 that it can be optimally done within vertical or frame blanking periods.
729 For low transmit frequencies or when a receiver described in [MIPI01] is paired with a previous version
730 transmitter not supporting the deskew calibration pattern the receiver may be instructed to bypass the deskew
731 mechanism.
732 The D-PHY v2.5 physical layer [MIPI01] provides both Alternate Low Power (ALP) Mode and Low Voltage
733 Low Power (LVLP) signaling, either of which may optionally replace the legacy Low Power State (LPS).
734 Use of ALP Mode or LVLP signaling can help alleviate current leakage and electrical overstress issues with
735 image sensors and applications processors. ALP Mode can also help achieve longer reach for CSI-2 imaging
736 interface channels, and is also central to the CSI-2 Unified Serial Link (USL) feature described in
737 Section 9.12. USL D-PHY support requirements are described in Section 7.3.1.

Confidential
31-May-2019
7.2 C-PHY Physical Layer Option

738 The C-PHY physical layer for a CSI-2 implementation is typically composed of one or more unidirectional
739 Lanes.
740 The minimum C-PHY physical layer requirement for a CSI-2 transmitter Lane module is:
741 • Unidirectional master, HS-TX, LP-TX and a CIL-MFEN function
742 • Support for Sync Word insertion during data payload transmission
743 The minimum C-PHY physical layer requirement for a CSI-2 receiver Lane module is:
744 • Unidirectional slave, HS-RX, LP-RX, and a CIL-SFEN function
745 • Support for Sync Word detection during data payload reception
746 All CSI-2 implementations supporting the C-PHY physical layer option shall support forward escape ULPS
747 on all C-PHY Lanes.
748 The C-PHY Physical Layer provides both Alternate Low Power (ALP) Mode and Low Voltage Low Power
749 (LVLP) signaling, either of which may optionally replace the legacy Low Power State (LPS). Use of ALP
750 Mode or LVLP signaling can help alleviate current leakage and electrical overstress issues with image sensors
751 and applications processors. ALP Mode (which replaces LVLP or legacy LP signaling through the use of
752 high-speed embedded codes) can also help achieve longer reach for CSI-2 imaging interface channels before
753 re-drivers and re-timers become necessary. ALP Mode is also central to the CSI-2 Unified Serial Link (USL)
754 feature described in Section 9.12. USL C-PHY support requirements are described in Section 7.3.2.

Confidential
31-May-2019
7.3 PHY Support for the CSI-2 Unified Serial Link (USL) Feature
755 The CSI-2 USL feature, as described in Section 9.12, requires the D-PHY and C-PHY physical layers to
756 support bidirectional data communications on Lane 1 plus additional features as described below in
757 Section 7.3.1 and Section 7.3.2, respectively. In case of any conflict between this Section 7.3 and Section 7.1
758 or Section 7.2, this section takes precedence. The physical layers of all USL implementations shall support
759 PHY LP and/or LVLP Mode signaling and should support ALP Mode signaling.
7.3.1 D-PHY Support Requirements for USL Feature

760 The D-PHY physical layer for a CSI-2 USL implementation is composed of one bidirectional data Lane (i.e.,
761 data Lane 1), zero or more unidirectional data Lanes, and one clock Lane. All CSI-2 transmitters and receivers
762 implementing the D-PHY physical layer for the USL feature shall support continuous clock behavior on the
763 clock Lane, and optionally may support non-continuous clock behavior.
764 For continuous clock behavior, the clock Lane remains in high-speed mode, generating active clock signals
765 between data packet transmissions.
766 For non-continuous clock behavior, the clock Lane may enter the Stop state between data packet
767 transmissions as determined by the image sensor and controlled by the host processor.
768 The minimum D-PHY LP/LVLP Mode physical layer requirement for a USL image sensor is:
769 • Clock Lane Module: Unidirectional master, HS-TX, LP-TX, and CIL-MCNN function
770 • Data Lane 1 Module: Bidirectional master, HS-TX, LP-TX, LP-RX, LP-CD, and CIL-MFAA
771 function; Escape Mode LPDT shall be supported in both the forward and reverse direction
772 • Data Lane n Module (for n > 1): Unidirectional master, HS-TX, LP-TX, and CIL-MFEN
773 function
774 The minimum D-PHY LP/LVLP Mode physical layer requirement for a USL host is:
775 • Clock Lane Module: Unidirectional slave, HS-RX, LP-RX, and CIL-SCNN function
776 • Data Lane 1 Module: Bidirectional slave, HS-RX, LP-TX, LP-RX, LP-CD, and CIL-SFAA
777 function; Escape Mode LPDT shall be supported in both the forward and reverse direction
778 • Data Lane n Module (for n > 1): Unidirectional slave, HS-RX, LP-RX, and CIL-SFEN function
779 For USL implemented using D-PHY LP/LVLP Mode, forward direction Escape Mode LPDT transmissions
780 shall use data Lane 1 only, and all reverse direction transmissions shall only use data Lane 1 and LPDT. The
781 USL host shall be capable of receiving both LPDT and High Speed (HS) transmissions. Note that
782 transmission bandwidth is substantially reduced when transmitting using LPDT.
783 The minimum D-PHY ALP Mode physical layer requirement for a USL image sensor is:
784 • Clock Lane Module: Unidirectional master, HS-TX and CIL-MCNN function
785 • Data Lane 1 Module: Bidirectional master, HS-TX, HS-RX, ALP-ED, and CIL-MREN function
786 (CIL-MREE with ALP-ULPS in both forward and reverse direction is recommended)
787 • Data Lane n Module (for n > 1): Unidirectional master, HS-TX and CIL-MFEN function
788 The minimum D-PHY ALP Mode physical layer requirement for a USL host is:
789 • Clock Lane Module: Unidirectional slave, HS-RX, ALP-ED, and CIL-SCNN function
790 • Data Lane 1 Module: Bidirectional slave, HS-TX, HS-RX, ALP-ED, and CIL-SREN function
791 (CIL-SREE with ALP-ULPS in both forward and reverse direction is recommended)
792 • Data Lane n Module (for n > 1): Unidirectional slave, HS-RX, ALP-ED, and CIL-SFEN function
793 Note that D-PHY ALP Mode does not define a contention detection function for bidirectional Lane modules.
794 All USL implementations supporting the D-PHY physical layer option shall support forward direction ULPS
795 on all data Lanes. For data Lane 1, support for both reverse direction ULPS and the reverse direction ALP-
796 wake pulse transmission is recommended; see Section 9.12.5.6 and Section 9.12.5.8 for additional guidance.

Confidential
31-May-2019
7.3.2 C-PHY Support Requirements for USL Feature

797 The C-PHY physical layer for a CSI-2 USL implementation is composed of one bidirectional Lane (i.e., Lane
798 1) and zero or more unidirectional Lanes.
799 The minimum C-PHY LP/LVLP Mode physical layer requirement for a USL image sensor is:
800 • Lane 1 Module: Bidirectional master, HS-TX, LP-TX, LP-RX, LP-CD, and CIL-MFAA function;
801 Escape Mode LPDT shall be supported in both the forward and reverse direction
802 • Lane n Module (for n > 1): Unidirectional master, HS-TX, LP-TX, and CIL-MFEN function
803 The minimum C-PHY LP/LVLP Mode physical layer requirement for a USL host is:
804 • Lane 1 Module: Bidirectional slave, HS-RX, LP-TX, LP-RX, LP-CD, and CIL-SFAA function;
805 Escape Mode LPDT shall be supported in both the forward and reverse direction
806 • Lane n Module (for n > 1): Unidirectional slave, HS-RX, LP-RX, and CIL-SFEN function
807 For USL implemented using C-PHY LP/LVLP Mode, forward direction Escape Mode LPDT transmissions
808 shall use Lane 1 only, and all reverse direction transmissions shall only use Lane 1 and LPDT. The USL host
809 shall be capable of receiving both LPDT and High Speed (HS) transmissions. Note that transmission
810 bandwidth is substantially reduced when transmitting using LPDT.
811 The minimum C-PHY ALP Mode physical layer requirement for a USL image sensor is:
812 • Lane 1 Module: Bidirectional master, HS-TX, HS-RX, and CIL-MREN function (CIL-MREE
813 with ALP-ULPS in both forward and reverse direction is recommended)
814 • Lane n Module (for n > 1): Unidirectional master, HS-TX and CIL-MFEN function
815 The minimum C-PHY ALP Mode physical layer requirement for a USL host is:
816 • Lane 1 Module: Bidirectional slave, HS-TX, HS-RX, and CIL-SREN function (CIL-SREE with
817 ALP-ULPS in both forward and reverse direction is recommended)
818 • Lane n Module (for n > 1): Unidirectional slave, HS-RX and CIL-SFEN function
819 Note that C-PHY ALP Mode does not define a contention detection function for bidirectional Lane modules.
820 All CSI-2 USL implementations supporting the C-PHY physical layer option shall support forward direction
821 ULPS on all Lanes. For Lane 1, additional C-PHY ALP Mode support for reverse direction ULPS is
822 recommended; see Section 9.12.5.8 for additional guidance.
823

Confidential
31-May-2019
8 Multi-Lane Distribution and Merging

824 CSI-2 is a Lane-scalable specification. Applications requiring more bandwidth than that provided by one data
825 Lane, or those trying to avoid high clock rates, can expand the data path to a higher number of Lanes and
826 obtain approximately linear increases in peak bus bandwidth. The mapping between data at higher layers and
827 the serial bit or symbol stream is explicitly defined to ensure compatibility between host processors and
828 peripherals that make use of multiple data Lanes.
829 Conceptually, between the PHY and higher functional layers is a layer that handles multi-Lane
830 configurations. As shown in Figure 35 and Figure 36 for the D-PHY and C-PHY physical layer options,
831 respectively, the CSI-2 transmitter incorporates a Lane Distribution Function (LDF) which accepts a
832 sequence of packet bytes from the low level protocol layer and distributes them across N Lanes, where each
833 Lane is an independent unit of physical-layer logic (serializers, etc.) and transmission circuitry. Similarly, as
834 shown in Figure 37 and Figure 38 for the D-PHY and C-PHY physical layer options, respectively,the CSI-
835 2 receiver incorporates a Lane Merging Function (LMF) which collects incoming bytes from N Lanes and
836 consolidates (merges) them into complete packets to pass into the packet decomposer in the receiver’s low
837 level protocol layer.
•••• ••••
Byte 5 Byte 5
Byte 4 Byte 4
Byte Stream
Byte 3 (Conceptual) Byte 3
Byte 2 Byte 2
Byte 1 Byte 1
Byte 0 Byte 0
LDF Lane Distribution Function (LDF)
Byte 3
Byte 2 •••• •••• •••• ••••
Byte 1 Byte N Byte N+1 •••• Byte 2N-2 Byte 2N-1
Byte 0 Byte 0 Byte 1 Byte N-2 Byte N-1
SerDes SerDes SerDes •••• SerDes SerDes
Lane 1 Lane 1 Lane 2 •••• Lane N-1 Lane N
Single Lane N Lane Link

838
Link
Figure 35 Conceptual Overview of the Lane Distributor Function for D-PHY

Confidential
31-May-2019
839
Figure 36 Conceptual Overview of the Lane Distributor Function for C-PHY

Confidential
31-May-2019
Single Lane
Link N Lane Link
Lane 1 Lane 1 Lane 2 •••• Lane N-1 Lane N
SerDes SerDes SerDes •••• SerDes SerDes
•••• •••• •••• •••• ••••
Byte 3 Byte N Byte N+1 •••• Byte 2N-2 Byte 2N-1
Byte 2 Byte 0 Byte 1 Byte N-2 Byte N-1
Byte 1
Byte 0 Lane Merging Function (LMF)
LMF ••••
Byte 5 Byte 5
Byte 4 Byte 4
Byte Stream
Byte 3 (Conceptual) Byte 3
Byte 2 Byte 2
Byte 1 Byte 1
Byte 0 Byte 0
840
Figure 37 Conceptual Overview of the Lane Merging Function for D-PHY

Confidential
31-May-2019
Single Lane Link N Lane Link
• ••
Lane 1 Lane 1 Lane 2 Lane N-1 Lane N
SerDes SerDes SerDes • •• SerDes SerDes
• •• • • •• • • •• • • •• • • •• •
Byte 7 Byte 2N +1 Byte 2N +3 • •• Byte 4N -3 Byte 4N -1
Byte 6 Byte 2N Byte 2N +2 Byte 4N -4 Byte 4N -2
Byte 5 Byte 1 Byte 3 Byte 2N -3 Byte 2N -1
Byte 3
Byte 2
Byte 1
Byte 0
Lane Merging Function (LMF)
LMF • •• •
Byte 5 Byte 5
Byte 4 Conceptual Byte Stream Byte 4

To Low Level Protocol
Byte 3 Byte 3
Byte 2 Byte 2
Byte 1 Byte 1
Byte 0 Byte 0
841

Confidential
31-May-2019
Single Lane Link N Lane Link
• ••
Lane 1 Lane 1 Lane 2 Lane N-1 Lane N
SerDes SerDes SerDes • •• SerDes SerDes
• •• • • •• • • •• • • •• • • •• •
Byte 7 Byte 2N +1 Byte 2N +3 • •• Byte 4N -3 Byte 4N -1
Byte 6 Byte 2N Byte 2N +2 Byte 4N -4 Byte 4N -2
Byte 3
Byte 2
Byte 1
Byte 0
Lane Merging Function (LMF)
LMF • •• •
Byte 5 Byte 5
Byte 4 Conceptual Byte Stream Byte 4

To Low Level Protocol
Byte 3 Byte 3
Byte 2 Byte 2
Byte 1 Byte 1
Byte 0 Byte 0
842
Figure 38 Conceptual Overview of the Lane Merging Function for C-PHY
843 The Lane distributor takes a transmission of arbitrary byte length, buffers up N*b bytes (where N = number
844 of Lanes and b = 1 or 2 for the D-PHY or C-PHY physical layer option, respectively), and then sends groups
845 of N*b bytes in parallel across N Lanes with each Lane receiving b bytes. Before sending data, all Lanes
846 perform the SoT sequence in parallel to indicate to their corresponding receiving units that the first byte of a
847 packet is beginning. After SoT, the Lanes send groups of successive bytes from the first packet in parallel,
848 following a round-robin process.

Confidential
31-May-2019
8.1 Lane Distribution for the D-PHY Physical Layer Option

849 Examples are shown in Figure 39, Figure 40, Figure 41, and Figure 42:
850 • 2-Lane system (Figure 39): byte 0 of the packet goes to Lane 1, byte 1 goes to Lane 2, byte 2 to
851 Lane 1, byte 3 goes to Lane 2, byte 4 goes to Lane 1, and so on.
852 • 3-Lane system (Figure 40): byte 0 of the packet goes to Lane 1, byte 1 goes to Lane 2, byte 2 to
853 Lane 3, byte 3 goes to Lane 1, byte 4 goes to Lane 2, and so on.
854 • N-Lane system (Figure 41): byte 0 of the packet goes to Lane 1, byte 1 goes to Lane 2, byte N-1
855 goes to Lane N, byte N goes to Lane 1, byte N+1 goes to Lane 2, and so on.
856 • N-lane system (Figure 42) with N>4 short packet (4 bytes) transmission: byte 0 of the packet goes
857 to Lane 1, byte 1 goes to Lane 2, byte 2 goes to Lane 3, byte 3 goes to Lane 4, and Lanes 5 to N
858 do not receive bytes and stay in LPS state.
859 At the end of the transmission, there may be “extra” bytes since the total byte count may not be an integer
860 multiple of the number of Lanes, N. One or more Lanes may send their last bytes before the others. The Lane
861 distributor, as it buffers up the final set of less-than-N bytes in parallel for sending to N data Lanes, de-asserts
862 its “valid data” signal into all Lanes for which there is no further data. For systems with more than 4 data
863 Lanes sending a short packet constituted of 4 bytes the Lanes which do not receive a byte for transmission
864 shall stay in LPS state.
865 Each D-PHY data Lane operates autonomously.
866 Although multiple Lanes all start simultaneously with parallel “start packet” codes, they may complete the
867 transaction at different times, sending “end packet” codes one cycle (byte) apart.
868 The N PHYs on the receiving end of the link collect bytes in parallel, and feed them into the Lane-merging
869 layer. This reconstitutes the original sequence of bytes in the transmission, which can then be partitioned into
870 individual packets for the packet decoder layer.
Number of Bytes, B, transmitted is an integer multiple of the number of lanes:
All Data Lanes finish at the same time
LANE 1: SoT Byte 0 Byte 2 Byte 4 Byte B-6 Byte B-4 Byte B-2 EoT
Number of Bytes, B, transmitted is NOT an integer multiple of the number of lanes:
Data Lane 2 finishes 1 byte earlier than Data Lane 1
LANE 2: SoT Byte 1 Byte 3 Byte 5 Byte B-4 Byte B-2 EoT LPS
KEY:
871
LPS – Low Power State SoT – Start of Transmission EoT – End of Transmission
Figure 39 Two Lane Multi-Lane Example for D-PHY

Confidential
31-May-2019
Number of Bytes, B, transmitted is an integer multiple of the number of lanes:
Number of Bytes, B, transmitted is NOT an integer multiple of the number of lanes (Example 1):
Data Lanes 2 & 3 finish 1 byte earlier than Data Lane 1
Number of Bytes, B, transmitted is NOT an integer multiple of the number of lanes (Example 2):
Data Lane 3 finishes 1 byte earlier than Data Lanes 1 & 2
KEY:
872
Figure 40 Three Lane Multi-Lane Example for D-PHY

Confidential
31-May-2019
Number of Bytes, B, transmitted is an integer multiple of the number of lanes, N:
LANE 1: SoT Byte 0 Byte N Byte B-2N Byte B-N EoT
LANE 2: SoT Byte 1 Byte N+1 Byte B-2N+1 Byte B-N+1 EoT
•••
•••
•••
•••
•••
LANE N-1: SoT Byte N-2 Byte 2N-2 Byte B-N-2 Byte B-2 EoT
LANE N: SoT Byte N-1 Byte 2N-1 Byte B-N-1 Byte B-1 EoT
Number of Bytes, B, transmitted is NOT an integer multiple of the number of lanes, N:
Data Lanes K+1 to N finish 1 byte earlier than Data Lanes 1 to K
LANE 1: SoT Byte 0 Byte N Byte B-N-K Byte B-K EoT

•••
•••
•••
•••
•••
LANE K: SoT Byte K-1 Byte N+K-1 Byte B-N-1 Byte B-1 EoT
LANE K+1: SoT Byte K Byte N+K Byte B-N EoT LPS
•••
•••
•••
•••
•••
LANE N: SoT Byte N-1 Byte 2N-1 Byte B-K-1 EoT LPS
KEY:
873
Figure 41 N-Lane Multi-Lane Example for D-PHY

Confidential
31-May-2019
Short packet of 4 bytes Transmitted on N lanes > 4

Bytes distributed on Lanes 1 to 4,
Lanes 5 to N stay in LPS
LANE 1: SoT Byte 0 EoT LPS
•••
LANE 4: SoT Byte 3 EoT LPS
LANE 5: LPS
LANE N: ••• LPS
KEY:
874
Figure 42 N-Lane Multi-Lane Example for D-PHY Short Packet Transmission
8.2 Lane Distribution for the C-PHY Physical Layer Option

875 Examples are shown in Figure 43 and Figure 44:
876 • 2-Lane system (Figure 43): bytes 1 and 0 of the packet are sent as a 16-bit word to the Lane 1
877 C-PHY module, bytes 3 and 2 are sent to Lane 2, bytes 5 and 4 are sent to Lane 1, bytes 7 and 6
878 are sent to Lane 2, bytes 9 and 8 are sent to Lane 1, and so on.
879 • 3-Lane system (Figure 44): bytes 1 and 0 of the packet are sent as a 16-bit word to the Lane 1
880 C-PHY module, bytes 3 and 2 are sent to Lane 2, bytes 5 and 4 are sent to Lane 3, bytes 7 and 6
881 are sent to Lane 1, bytes 9 and 8 are sent to Lane 2, and so on.
882 Figure 45 illustrates normative behavior for an N-Lane system where N ≥ 1: bytes 1 and 0 of the packet are
883 sent as a 16-bit word to the Lane 1 C-PHY module, bytes 3 and 2 are sent to Lane 2, bytes 2N-1 and 2N-2
884 are sent to Lane N, bytes 2N+1 and 2N are sent to Lane 1, and so on. The last two bytes B-1 and B-2 are sent
885 to Lane N, where B is the total number of bytes in the packet.
886 For an N-Lane transmitter, the C-PHY module for Lane n (1 ≤ n ≤ N) shall transmit the following sequence
887 of {ms byte : ls byte} byte pairs from a B-byte packet generated by the low level protocol layer: {Byte
888 2*(k*N+n)-1 : Byte 2*(k*N+n)-2}, for k = 0, 1, 2, …, B/(2N) - 1, where Byte 0 is the first byte in the packet.
889 The low level protocol shall guarantee that B is an integer multiple of 2N.
890 That is, at the end of the packet transmission, there shall be no “extra” bytes since the total byte count is
891 always an even multiple of the number of Lanes, N. The Lane distributor, after sending the final set of 2N
892 bytes in parallel to the N Lanes, simultaneously de-asserts its “valid data” signal to all Lanes, signaling to
893 each C-PHY Lane module that it may start its EoT sequence.
894 Each C-PHY Lane module operates autonomously, but packet data transmission starts and stops at the same
895 time on all Lanes.
896 The N C-PHY receiver modules on the receiving end of the link collect byte pairs in parallel, and feed them
897 into the Lane-merging layer. This reconstitutes the original sequence of bytes in the transmission, which can
898 then be partitioned into individual packets for the packet decoder layers.

Confidential
31-May-2019
All Lanes start and stop at the same time
Bytes B-11: Bytes B-7: Bytes B-3:

LANE 1: SoT Bytes 1:0 Bytes 5:4 Bytes 9:8
B-12 B-8 B-4 EoT

B-10 B-6 B-2 EoT
KEY:
899
Figure 43 Two Lane Multi-Lane Example for C-PHY

B-18 B-12 B-6
EoT

B-16 B-10 B-4 EoT

B-14 B-8 B-2
EoT
KEY:
900
Figure 44 Three Lane Multi-Lane Example for C-PHY

Bytes 2N+1: Bytes 4N+1: Bytes B-6N+1: Bytes B-4N+1: Bytes B-2N+1:
LANE 1: SoT Bytes 1:0
2N 4N B-6N B-4N B-2N EoT
Bytes 2N+3: Bytes 4N+3: Bytes B-6N+3: Bytes B-4N+3: Bytes B-2N+3:
LANE 2: SoT Bytes 3:2
2N+2 4N+2 B-6N+2 B-4N+2 B-2N+2 EoT
•••
•••
•••
•••
•••
•••
Bytes 2N-3: Bytes 4N-3: Bytes 6N-3: Bytes B-4N-3: Bytes B-2N-3: Bytes B-3:
LANE N-1: SoT 2N-4 4N-4 6N-4 B-4N-4 B-2N-4 B-4 EoT
Bytes 2N-1: Bytes 4N-1: Bytes 6N-1: Bytes B-4N-1: Bytes B-2N-1: Bytes B-1:
LANE N: SoT 2N-2 4N-2 6N-2 B-4N-2 B-2N-2 B-2 EoT
KEY:
901
Figure 45 General N-Lane Multi-Lane Distribution for C-PHY

Confidential
31-May-2019
8.3 Multi-Lane Interoperability

902 The Lane distribution and merging layers shall be reconfigurable via the Camera Control Interface when
903 more than one data Lane is used.
904 An "N" data Lane receiver shall be connected with an "M" data Lane transmitter, by CCI configuration of
905 the Lane distribution and merging layers within the CSI-2 transmitter and receiver when more than one data
906 Lane is used. Thus, if M<=N a receiver with N data Lanes shall work with transmitters with M data Lanes.
907 Likewise, if M>=N a transmitter with M Lanes shall work with receivers with N data Lanes. Transmitter
908 Lanes 1 to M shall be connected to the receiver Lanes 1 to N.
909 Two cases:
910 • If M<=N then there is no loss of performance – the receiver has sufficient data Lanes to match the
911 transmitter (Figure 46 and Figure 47).
912 • If M> N then there may be a loss of performance (e.g. frame rate) as the receiver has fewer data
913 Lanes than the transmitter (Figure 48 and Figure 49).
914 • Note that while the examples shown are for the D-PHY physical layer option, the C-PHY physical
915 layer option is handled similarly, except there is no clock Lane.
1 lane N lane
Transmitter PHY Receiver PHY
Lane Distribution Function
Lane Merging Function

SerDes 8-bit
•••
•••
•••
8-bit SerDes Lane 1 SerDes 8-bit
Clock DDR Clock Clock

Byte Byte
Clock Clock
916
Figure 46 One Lane Transmitter and N-Lane Receiver Example for D-PHY
M lane N lane
SerDes 8-bit

•••
•••
•••
8-bit SerDes Lane M SerDes 8-bit

•••
•••
•••
•••
•••
•••
•••

Byte Byte
Clock Clock
917
Figure 47 M-Lane Transmitter and N-Lane Receiver Example (M<N) for D-PHY

Confidential
31-May-2019
M lane 1 lane

8-bit SerDes
•••
•••
•••

Byte Byte
Clock Clock
918
Figure 48 M-Lane Transmitter and One Lane Receiver Example for D-PHY
M lane N lane
8-bit SerDes

•••
•••
•••
8-bit SerDes Lane N SerDes 8-bit

•••
•••
•••
•••
•••
•••
•••

Byte Byte
Clock Clock
919
Figure 49 M-Lane Transmitter and N-Lane Receiver Example (N<M) for D-PHY

Confidential
31-May-2019
8.3.1 C-PHY Lane De-Skew

920 The PPI definition in the C-PHY Specification [MIPI02] defines one RxWordClkHS per Lane, and does not
921 address the use of a common receive RxWordClkHS for all Lanes within a Link. Figure 50 shows a
922 mechanism for clocking data from the elastic buffers, in order to align (De-Skew) all RxDataHS to one
923 RxWordClkHS.
Serial
PPI
Data
C-PHY C-PHY CSI Receiver
Clk RxDataHS_N[15:0] Elast

Lane N Data
RxWordClkHS_N Store
Decoder
•••
Clk RxDataHS_1[15:0]
Lane
Lane 0
1
Elast Merging Internal
Data
Decoder
RxWordClkHS_1 Store Function Logic
•••
Clk RxDataHS_0[15:0] Elast

Lane 0 Data
Decoder
RxWordClkHS_0 Store
Elast Store Read Clock
924
Figure 50 Example of Digital Logic to Align All RxDataHS

Confidential
31-May-2019

Confidential
31-May-2019
9 Low Level Protocol

925 The Low Level Protocol (LLP) is a byte orientated, packet based protocol that supports the transport of
926 arbitrary data using Short and Long packet formats. For simplicity, all examples in this section are single
927 Lane configurations unless specified otherwise.
928 Basic Low Level Protocol Features:
929 • Transport of arbitrary data (Payload independent)
930 • 8-bit word size
931 • Support for up to sixteen interleaved virtual channels on the same D-PHY Link, or up to 32
932 interleaved virtual channels on the same C-PHY Link
933 • Special packets for frame start, frame end, line start and line end information
934 • Descriptor for the type, pixel depth and format of the Application Specific Payload data
935 • 16-bit Checksum Code for error detection.
936 • 6-bit Error Correction Code for error detection and correction (D-PHY physical layer only)
DATA:
Short Long Long Short
Packet Packet Packet Packet
ST SP ET LPS ST PH DATA PF ET LPS ST PH DATA PF ET LPS ST SP ET
KEY:
LPS – Low Power State PH – Packet Header
ET – End of Transmission PF – Packet Footer + Filler (if applicable)
937
ST – Start of Transmission
Figure 51 Low Level Protocol Packet Overview

Confidential
31-May-2019
9.1 Low Level Protocol Packet Format

938 As shown in Figure 51, two packet structures are defined for low-level protocol communication: Long
939 packets and Short packets. The format and length of Short and Long Packets depends on the choice of
940 physical layer. For each packet structure, exit from the low power state followed by the Start of Transmission
941 (SoT) sequence indicates the start of the packet. The End of Transmission (EoT) sequence followed by the
942 low power state indicates the end of the packet.
9.1.1 Low Level Protocol Long Packet Format

943 Figure 52 shows the structure of the Low Level Protocol Long Packet for the D-PHY physical layer option.
944 A Long Packet shall be identified by Data Types 0x10 to 0x38. See Table 10 for a description of the Data
945 Types. A Long Packet for the D-PHY physical layer option shall consist of three elements: a 32-bit Packet
946 Header (PH), an application specific Data Payload with a variable number of 8-bit data words, and a 16-bit
947 Packet Footer (PF). The Packet Header is further composed of four elements: an 8-bit Data Identifier, a 16-
948 bit Word Count field, a 2-bit Virtual Channel Extension field, and a 6-bit ECC. The Packet footer has one
949 element, a 16-bit checksum (CRC). See Section 9.2 through Section 9.5 for further descriptions of the packet
950 elements.
8-bit DATA IDENTIFIER (DI):

Contains the 2-bit Virtual Channel (VC) and the 6-bit Data Type (DT) Information.
VC (bits 7:6) is the least significant two bits of the 4-bit Virtual Channel Identifier for the D-PHY physical
layer option. DT (bits 5:0) denotes the format/content of the Application Specific Payload Data. Used by
the application specific layer.
16-bit WORD COUNT (WC):

The receiver reads the next WC data words independent of their values. The
receiver is NOT looking for any embedded sync sequences within the payload
data. The receiver uses the WC value to determine the end of the Packet Payload.
6-bit Error Correction Code (ECC) + 2-bit Virtual Channel Extension (VCX):
ECC (bits 5:0) enables 1-bit errors within the packet header to be corrected and 2-bit errors
to be detected. VCX (bits 7:6) is the most significant two bits of the 4-bit Virtual Channel
Identifier for the D-PHY physical layer option.
APPLICATION SPECIFIC PAYLOAD CHECKSUM/CRC (CS)

(l.s. byte first)
(l.s. byte first)

VCX + ECC
Word Count
Data WC-4
Data WC-3
Data WC-2
Data WC-1
Checksum
Data ID
Data 0
Data 1
Data 2
Data 3
16-Bit
16-bit
LPS SoT EoT LPS
32-bit PACKET DATA: 16-bit

PACKET Length = Word Count (WC) * Data Word PACKET
HEADER Width (8-bits). There are NO restrictions FOOTER
(PH) on the values of the data words (PF)
951
Figure 52 Long Packet Structure for D-PHY Physical Layer Option

Confidential
31-May-2019
952 Figure 53 shows the Long Packet structure for the C-PHY physical layer option; it shall consist of four
953 elements: a Packet Header (PH), an application specific Data Payload with a variable number of 8-bit data
954 words, a 16-bit Packet Footer (PF), and zero or more Filler bytes (FILLER). The Packet Header is 6N x 16-
955 bits long, where N is the number of C-PHY physical layer Lanes. As shown in Figure 53, the Packet Header
956 consists of two identical 6N-byte halves, where each half consists of N sequential copies of each of the
957 following fields: a 16-bit field containing five Reserved bits, a 3-bit Virtual Channel Extension (VCX) field,
958 and the 8-bit Data Identifier (DI); the 16-bit Packet Data Word Count (WC); and a 16-bit Packet Header
959 checksum (PH-CRC) which is computed over the previous four bytes. The value of each Reserved bit shall
960 be zero. The Packet Footer consists of a 16-bit checksum (CRC) computed over the Packet Data using the
961 same CRC polynomial as the Packet Header CRC and the Packet Footer used in the D-PHY physical layer
962 option. Packet Filler bytes are inserted after the Packet Footer, if needed, to ensure that the Packet Footer
963 ends on a 16-bit word boundary and that each C-PHY physical layer Lane transports the same number of 16-
964 bit words (i.e. byte pairs).
5-bit Reserved Field (RES) + 3-bit Virtual Channel Extension (VCX) field:
RES (bits 7:3) is set to zero and reserved for future use.
VCX (bits 2:0) is the most significant three bits of the 5-bit Virtual Channel Identifier for the C-PHY physical layer option.
8-bit DATA IDENTIFIER (DI):
Contains the 2-bit Virtual Channel (VC) and the 6-bit Data Type (DT) Information.
VC (bits 7:6) is the least significant two bits of the 5-bit Virtual Channel Identifier for the C-PHY physical layer option. DT
(bits 5:0) denotes the format/content of the Application Specific Payload Data. Used by the application specific layer.
16-bit WORD COUNT (WC):
The receiver reads the next WC 8-bit data words following the Packet Header.
The receiver uses the WC value to determine the end of the Packet Payload.
16-bit Cyclic Redundancy Check Code (PH-CRC):
16-bit CRC code for the Packet Header; computed over the
Reserved, Data ID, and Word Count fields (4 bytes). Enables
multi-bit errors to be detected. 16-Bit Packet Data CRC:
Computed over WC
CSI-2 “Insert Sync Word” PPI Command: Packet Data Words
The physical layer simultaneously inserts an Sync Word on all N
Lanes at this point as a result of executing a CSI-2 PPI command. Set to Set to
“0” “0”
WC PH-CRC APPLICATION SPECIFIC PAYLOAD
PH Checksum
PD Checksum
PH Checksum
Word Count
RES + VCX
Word Count
RES + VCX
Data WC-4
Data WC-3
Data WC-2
Data WC-1
(l.s. byte first)
(l.s. byte first)
(l.s. byte first)

(l.s. byte first)
(l.s. byte first)
Filler FC-1
Data ID
Data ID
Filler 0
Data 0
Data 1
Data 2
Data 3
16-Bit
16-Bit
16-Bit
16-Bit
16-Bit
LPS SoT EoT LPS
N Copies N Copies N Copies N Copies N Copies N Copies PACKET DATA: 16-bit FILLER:
Length = Word Count (WC) * Data Word PACKET FC 8-bit bytes added to
PACKET HEADER (PH): 6N x 16-bits Width (8-bits). There are NO restrictions FOOTER ensure that all Lanes
(N = Physical Layer Lane Count) on the values of the data words (PF) transport the same number of
965 16-bit words; FC may be 0.
Figure 53 Long Packet Structure for C-PHY Physical Layer Option

Confidential
31-May-2019
966 As shown in Figure 54, the Packet Header structure depicted in Figure 53 effectively results in the C-PHY
967 Lane Distributor broadcasting the same six 16-bit words to each of N Lanes. Furthermore, the six words per
968 Lane are split into two identical three-word groups which are separated by a mandatory C-PHY Sync Word
969 as described in [MIPI02]. The Sync Word is inserted by the C-PHY physical layer in response to a CSI-2
970 protocol transmitter PPI command.
16-BIT WORD TRANSMISSION ORDER TO C-PHY PHYSICAL LAYER

WORD 1 WORD 2 WORD 3 WORD 4 WORD 5 WORD 6
Data ID VCX Word Count Word Count Checksum Checksum Data ID VCX Word Count Word Count Checksum Checksum
LANE 1: Reserved Reserved
(8 Bits) (5 Bits)
(3 Bits) (MS Byte) (LS Byte) (MS Byte) (LS Byte) (8 Bits) (5 Bits)
(3 Bits) (MS Byte) (LS Byte) (MS Byte) (LS Byte)
ms bit ls bit ms bit ls bit
● ●
C-PHY physical layer inserts a 7-symbol Sync Word
To Lane 1 C-PHY TX
● here on each Lane in response to a CSI-2 PPI command ● To Lane 1 C-PHY TX
● ●
Data ID VCX Word Count Word Count Checksum Checksum Data ID Reserved VCX Word Count Word Count Checksum Checksum
LANE N:
Reserved
(5 Bits) (5 Bits)
(8 Bits) (MS Byte)
(3 Bits) (LS Byte) (MS Byte) (LS Byte) (8 Bits) (MS Byte)
(3 Bits) (LS Byte) (MS Byte) (LS Byte)
ms bit ls bit ms bit ls bit
971 To Lane N C-PHY TX To Lane N C-PHY TX
Figure 54 Packet Header Lane Distribution for C-PHY Physical Layer Option
972 For both physical layer options, the 8-bit Data Identifier field defines the 2-bit Virtual Channel (VC) and the
973 Data Type for the application specific payload data. The Virtual Channel Extension (VCX) field is also
974 common to both options, but is a 2-bit field for D-PHY and a 3-bit field for C-PHY. Together, the VC and
975 VCX fields comprise the 4- or 5-bit Virtual Channel Identifier field which determines the Virtual Channel
976 number associated with the packet (see Section 9.3).
977 For both physical layer options, the 16-bit Word Count (WC) field defines the number of 8-bit data words in
978 the Data Payload between the end of the Packet Header and the start of the Packet Footer. No Packet Header,
979 Packet Footer, or Packet Filler bytes shall be included in the Word Count.
980 For the D-PHY physical layer option, the 6-bit Error Correction Code (ECC) allows single-bit errors to be
981 corrected and 2-bit errors to be detected in the Packet Header. This includes the Data Identifier, Word Count,
982 and Virtual Channel Extension field values.
983 The ECC field is not used by the C-PHY physical layer option because a single symbol error on a C-PHY
984 physical link can cause multiple bit errors in the received CSI-2 Packet Header, rendering an ECC ineffective.
985 Instead, a CSI-2 protocol transmitter for the C-PHY physical layer option computes a 16-bit CRC over the
986 four bytes composing the Reserved, Virtual Channel Extension, Data Identifier, and Word Count Packet
987 Header fields and then transmits multiple copies of all these fields, including the CRC, to facilitate their
988 recovery by the CSI-2 protocol receiver in the event of one or more C-PHY physical link errors. The multiple
989 Sync Words inserted into the Packet Header by the C-PHY physical layer (as shown in Figure 54) also
990 facilitate Packet Header data recovery by enabling the C-PHY receiver to recover from lost symbol clocks;
991 see [MIPI02] for further information about the C-PHY Sync Word and symbol clock recovery.
992 For both physical layer options, the CSI-2 receiver reads the next WC 8-bit data words of the Data Payload
993 following the Packet Header. While reading the Data Payload the receiver shall not look for any embedded
994 sync codes. Therefore, there are no limitations on the value of an 8-bit payload data word. In the generic case,
995 the length of the Data Payload shall always be a multiple of 8-bit data words. In addition, each Data Type
996 may impose additional restrictions on the length of the Data Payload, e.g. require a multiple of four bytes.
997 For both physical layer options, once the CSI-2 receiver has read the Data Payload, it then reads the 16-bit
998 checksum (CRC) in the Packet Footer and compares it against its own calculated checksum to determine if
999 any Data Payload errors have occurred.
1000 Filler bytes are only inserted by the CSI-2 transmitter’s low level protocol layer in conjunction with the
1001 C-PHY physical layer option. The value of any Filler byte shall be zero. If the Packet Data Word Count (WC)
1002 is an odd number (i.e. LSB is “1”), the CSI-2 transmitter shall insert one Packet Filler byte after the Packet
1003 Footer to ensure that the Packet Footer ends on a 16-bit word boundary. The CSI-2 transmitter shall also

Confidential
31-May-2019
1004 insert additional Filler bytes, if needed, to ensure that each C-PHY Lane transports the same number of 16-
1005 bit words. The latter rules require the total number of Filler bytes, FC, to be greater than or equal to (WC
1006 mod 2) + {{N - (([WC + 2 + (WC mod 2)] / 2) mod N)} mod N} * 2, where N is the number of Lanes. Note
1007 that it is possible for FC to be zero.
1008 Figure 55 illustrates the Lane distribution of the minimal number of Filler bytes required for packets of
1009 various lengths transmitted over three C-PHY Lanes. The total number of Filler bytes required per packet
1010 ranges from 0 to 5, depending on the value of the Packet Data Word Count (WC). In general, the minimal
1011 number of Filler bytes required per packet ranges from 0 to 2N-1 for an N-Lane C-PHY system.
1012 For the D-PHY physical layer option, the CSI-2 Lane Distributor function shall pass each byte to the physical
1013 layer which then serially transmits it least significant bit first.
1014 For the C-PHY physical layer option, the Lane Distributor function shall group each pair of consecutive bytes
1015 2n and 2n+1 (for n ≥ 0) received from the Low Level Protocol into a 16-bit word (whose least significant
1016 byte is byte 2n) and then pass this word to a physical layer Lane module. The C-PHY Lane module maps
1017 each 16-bit word into a 7-symbol word which it then serially transmits least significant symbol first.
1018 For both physical layer options, payload data may be presented to the Lane Distributor function in any byte
1019 order restricted only by data format requirements. Multi-byte protocol elements such as Word Count,
1020 Checksum and the Short packet 16-bit Data Field shall be presented to the Lane Distributor function least
1021 significant byte first.
1022 After the EoT sequence the receiver begins looking for the next SoT sequence.

Confidential
31-May-2019
Total Packet Data Word Count (WC) = 6n

Lane 1 SoT PH SYN PH Byte 1 Byte 0 Byte 6n-5 Byte 6n-6 PF (MSB) PF (LSB) EoT
Lane 2 SoT PH SYN PH Byte 3 Byte 2 Byte 6n-3 Byte 6n-4 Filler Filler EoT
Total Packet Data Word Count (WC) = 6n+1

Lane 1 SoT PH SYN PH Byte 1 Byte 0 Byte 6n-5 Byte 6n-6 PF (LSB) Byte 6n EoT
Lane 2 SoT PH SYN PH Byte 3 Byte 2 Byte 6n-3 Byte 6n-4 Filler PF (MSB) EoT

Lane 1 SoT PH SYN PH Byte 1 Byte 0 Byte 6n-5 Byte 6n-6 Byte 6n+1 Byte 6n EoT

Lane 2 SoT PH SYN PH Byte 3 Byte 2 Byte 6n-3 Byte 6n-4 PF (LSB) Byte 6n+2 EoT
Lane 3 SoT PH SYN PH Byte 5 Byte 4 Byte 6n-1 Byte 6n-2 Filler PF (MSB) EoT

Lane 2 SoT PH SYN PH Byte 3 Byte 2 Byte 6n-3 Byte 6n-4 Byte 6n+3 Byte 6n+2 EoT

Lane 1 SoT PH SYN PH Byte 1 Byte 0 Byte 6n+1 Byte 6n Filler PF (MSB) EoT
Lane 2 SoT PH SYN PH Byte 3 Byte 2 Byte 6n+3 Byte 6n+2 Filler Filler EoT
Lane 3 SoT PH SYN PH Byte 5 Byte 4 PF (LSB) Byte 6n+4 Filler Filler EoT
KEY:
SoT – Start of Transmission EoT – End of Transmission PF – Packet Footer
1023
SYN – 7-Symbol Sync Word PH – Packet Header (6 Bytes) (2 Bytes)
Figure 55 Minimal Filler Byte Insertion Requirements for Three Lane C-PHY

Confidential
31-May-2019
9.1.2 Low Level Protocol Short Packet Format

1024 Figure 56 and Figure 57 show the Low Level Protocol Short Packet structures for the D-PHY and C-PHY
1025 physical layer options, respectively. For each option, the Short Packet structure matches the Packet Header
1026 of the corresponding Low Level Protocol Long Packet structure with the exception that the Packet Header
1027 Word Count (WC) field shall be replaced by the Short Packet Data Field. A Short Packet shall be identified
1028 by Data Types 0x00 to 0x0F. See Table 10 for a description of the Data Types. A Short Packet shall contain
1029 only a Packet Header; neither Packet Footer nor Packet Filler bytes shall be present.
1030 For Frame Synchronization Data Types the Short Packet Data Field shall be the frame number. For Line
1031 Synchronization Data Types the Short Packet Data Field shall be the line number. See Table 13 for a
1032 description of the Frame and Line synchronization Data Types.
1033 For Generic Short Packet Data Types the content of the Short Packet Data Field shall be user defined.
1034 For the D-PHY physical layer option, the Error Correction Code (ECC) field allows single-bit errors to be
1035 corrected and 2-bit errors to be detected in the Short Packet. For the C-PHY physical layer option, the 16-bit
1036 Checksum (CRC) allows one or more bit errors to be detected in the Short Packet but does not support error
1037 correction; the latter is facilitated by transmitting multiple copies of the various Short Packet fields and by
1038 C-PHY Sync Word insertion on all Lanes.
Short Packet
VCX + ECC
Data Field
Data ID
16-Bit
LPS SoT EoT LPS
32-bit SHORT PACKET (SH)

Data Type (DT) = 0x00 – 0x0F
1039
Figure 56 Short Packet Structure for D-PHY Physical Layer Option
CSI-2 “Insert Sync Word” PPI Command:

The physical layer simultaneously inserts a 7-symbol Sync Word on all
N Lanes at this point in response to a single CSI-2 PPI command.
VCX field is LS 3 bits;
all RES bits are zero
Short Packet
Short Packet
RES + VCX
RES + VCX
Checksum*
Checksum*
Data Field*
Data Field*
(PH-CRC)
(PH-CRC)
Data ID
Data ID
16-Bit
16-Bit
16-Bit
16-Bit
LPS SoT EoT LPS
N Copies N Copies N Copies N Copies N Copies N Copies

*16-bit word which is
SHORT PACKET: 6N x 16-bits
presented l.s. byte first to the
Lane Distributor function (N = Physical Layer Lane Count)
1040
Figure 57 Short Packet Structure for C-PHY Physical Layer Option

Confidential
31-May-2019
9.2 Data Identifier (DI)

1041 The Data Identifier byte contains the Virtual Channel (VC) and Data Type (DT) fields as illustrated in Figure
1042 58. The Virtual Channel field is contained in the two MS bits of the Data Identifier Byte. The Data Type field
1043 is contained in the six LS bits of the Data Identifier Byte.
Data Identifier (DI) Byte
DI7 DI6 DI5 DI4 DI3 DI2 DI1 DI0

VC DT
Virtual Channel Data Type

(VC) (DT)
1044
Figure 58 Data Identifier Byte
9.3 Virtual Channel Identifier

1045 The purpose of the 4- or 5-bit Virtual Channel Identifier is to provide a means for designating separate logical
1046 channels for different data flows that are interleaved in the data stream.
1047 As shown in Figure 59, the least significant two bits of the Virtual Channel Identifier shall be copied from
1048 the 2-bit VC field, and the most significant two or three bits shall be copied from the VCX field. The VCX
1049 field is located in the Packet Header as shown in Figure 52 and Figure 53, respectively, for the D-PHY and
1050 C-PHY physical layer options. The Receiver shall extract the Virtual Channel Identifier from incoming
1051 Packet Headers and de-multiplex the interleaved video data streams to their appropriate channel. A maximum
1052 of N data streams is supported, where N = 16 or 32, respectively, for the D-PHY or C-PHY physical layer
1053 option; valid channel identifiers are 0 to N-1. The Virtual Channel Identifiers in peripherals should be
1054 programmable to allow the host processor to control how the data streams are de-multiplexed.
1055 Host processors receiving packets from peripherals conforming to previous CSI-2 Specification versions not
1056 supporting the VCX field shall treat the received value of VCX in all such packets as zero. Similarly,
1057 peripherals conforming to this CSI-2 Specification version shall set the VCX field to zero in all packets
1058 transmitted to host processors conforming with previous versions not supporting the VCX field. The means
1059 by which host processors and peripherals meet these requirements are outside the scope of this Specification.
N-Bit Virtual Channel Identifier

(N = 4 for D-PHY, 5 for C-PHY) Channel Configuration
MS Bits LS Bits
(Bits (N-1):2) (Bits 1:0) Channel 0
Logical Channel Control
VCX VC
Channel 1
Channel 2
Packet Data In
Channel
Channel 3
Detect
Channel 4
●●●
Channel 2N-1
1060
Figure 59 Logical Channel Block Diagram (Receiver)

Confidential
31-May-2019
1061 Figure 60 illustrates an example of data streams utilizing virtual channel support.
SoT PH RGB 6:6:6 PF EoT LPS SoT PH YUV 4:2:2 PF EoT LPS SoT PH RGB 6:6:6 PF EoT
Virtual Channel 0 Virtual Channel 1 Virtual Channel 0
SoT PH RGB 5:6:5 PF EoT LPS SoT PH JPEG8 PF EoT LPS SoT PH RGB 5:6:5 PF EoT
SoT PH RGB 6:6:6 PF EoT LPS SoT PH MPEG4 PF EoT LPS SoT PH RGB 6:6:6 PF EoT
KEY:
SoT – Start of Transmission PF – Packet Footer + Filler (if applicable)
1062
EoT – End of Transmission
Figure 60 Interleaved Video Data Streams Examples

Confidential
31-May-2019
9.4 Data Type (DT)

1063 The Data Type value specifies the format and content of the payload data. A maximum of sixty-four data
1064 types are supported.
1065 There are eight different data type classes as shown in Table 10. Within each class there are up to nine
1066 different data type definitions. The first two classes denote short packet data types. The remaining six classes
1067 denote long packet data types.
1068 For details on the short packet data type classes refer to Section 9.8.
1069 For details on the five long packet data type classes refer to Section 11.
1070 Table 10 Data Type Classes
Data Type Description
0x00 to 0x07 Synchronization Short Packet Data Types
0x08 to 0x0F Generic Short Packet Data Types
0x10 to 0x17 Generic Long Packet Data Types
0x18 to 0x1F YUV Data
0x20 to 0x26 RGB Data
0x27 to 0x2F RAW Data
0x30 to 0x37 User Defined Byte-based Data
0x38 USL Commands (See Section 9.12)
0x39 to 0x3E Reserved for future use
0x3F For CSI-2 over C-PHY: Reserved for future use
For CSI-2 over D-PHY: Unavailable (0x3F is used for LRTE EPD Spacer)

Confidential
31-May-2019
9.5 Packet Header Error Correction Code for D-PHY Physical Layer
Option
1071 The correct interpretation of the Data Identifier, Word Count, and Virtual Channel Extension fields is vital to
1072 the packet structure. The 6-bit Packet Header Error Correction Code (ECC) allows single-bit errors in the
1073 latter fields to be corrected, and two-bit errors to be detected for the D-PHY physical layer option; the ECC
1074 is not available for the C-PHY physical layer option. A 26-bit subset of the Hamming-Modified code
1075 described in Section 9.5.2 shall be used. The error state results of ECC decoding shall be available at the
1076 Application layer in the receiver.
1077 The Data Identifier field DI[7:0] shall map to D[7:0] of the ECC input, the Word Count LS Byte (WC[7:0])
1078 to D[15:8], the Word Count MS Byte (WC[15:8]) to D[23:16], and the Virtual Channel Extension (VCX)
1079 field to D[25:24]. This mapping is shown in Figure 61, which also serves as an ECC calculation example.
32-bit
PACKET HEADER
(PH)
VCX[1:0] = 1
Word Count
Data ID
Data 0
ECC
(WC)
LPS SoT
VCX
Data ID = 0x37 WC LS Byte = 0xF0 WC MS Byte = 0x01 ECC = 0x02 VCX
DOUT 1 1 1 0 1 1 0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0
L M L M L M L M
S S S S S S S S
B B B B B B B B
ECC Calculation ECC
1 1 1 0 1 1 0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0
D D P0 P1 P2 P3 P4 P5
0 2
5
1080
Figure 61 26-bit ECC Generation Example
9.5.1 General Hamming Code Applied to Packet Header

1081 The number of parity or error check bits required is given by the Hamming rule, and is a function of the
1082 number of bits of information transmitted. The Hamming rule is expressed by the following inequality:
1083 d + p + 1 ≤ 2p, where d is the number of data bits and p is the number of parity bits.
1084 The result of appending the computed parity bits to the data bits is called the Hamming code word. The size
1085 of the code word c is obviously d + p, and a Hamming code word is described by the ordered set (c, d). A
1086 Hamming code word is generated by multiplying the data bits by a generator matrix G. The resulting product
1087 is the code-word vector (c1, c2, c3 … cn), consisting of the original data bits and the calculated parity bits.
1088 The generator matrix G used in constructing Hamming codes consists of I (the identity matrix) and a parity
1089 generation matrix A:

Confidential
31-May-2019
1090 G=[I|A]
1091 The packet header plus the ECC code can be obtained as: PH = p*G where p represents the header (26 or 64
1092 bits) and G is the corresponding generator matrix.
1093 Validating the received code word r, involves multiplying it by a parity check to form s, the syndrome or
1094 parity check vector: s = H*PH where PH is the received packet header and H is the parity check matrix:
1095 H = [ AT | I ]
1096 If all elements of s are zero, the code word was received correctly. If s contains non-zero elements, then at
1097 least one error is present. If a single bit error is encountered then the syndrome s is one of the elements of H
1098 which will point to the bit in error. Further, in this case, if the bit in error is one of the parity bits, then the
1099 syndrome will be one of the elements on I, else it will be the data bit identified by the position of the syndrome
1100 in AT.
9.5.2 Hamming-Modified Code

1101 The error correcting code used is a 7+1 bits Hamming-modified code (72,64) and the subset of it is 5+1 bits
1102 or (32,26). Hamming codes use parity to correct one error or detect two errors, but they are not capable of
1103 doing both simultaneously, thus one extra parity bit is added. The code used allows the same 6-bit syndromes
1104 to correct the first 26-bits of a 64-bit sequence. To specify a compact encoding of parity and decoding of
1105 syndromes, the matrix shown in Table 11 is used:
1106 Table 11 ECC Syndrome Association Matrix
d2d1d0
d5d4d3 0b000 0b001 0b010 0b011 0b100 0b101 0b110 0b111

0b000 0x07 0x0B 0x0D 0x0E 0x13 0x15 0x16 0x19
0b001 0x1A 0x1C 0x23 0x25 0x26 0x29 0x2A 0x2C
0b010 0x31 0x32 0x34 0x38 0x1F 0x2F 0x37 0x3B
0b011 0x3D 0x3E 0x46 0x49 0x4A 0x4C 0x51 0x52
0b100 0x54 0x58 0x61 0x62 0x64 0x68 0x70 0x83
0b101 0x85 0x86 0x89 0x8A 0x43 0x45 0x4F 0x57
0b110 0x8C 0x91 0x92 0x94 0x98 0xA1 0xA2 0xA4
0b111 0xA8 0xB0 0xC1 0xC2 0xC4 0xC8 0xD0 0xE0
1107 Each cell in the matrix represents a syndrome, and the first 26 cells (the orange cells) use the first three or
1108 five bits to build the syndrome. Each syndrome in the matrix is MSB left aligned:
1109 e.g. 0x07 = 0b0000_0111 = P7 P6 P5 P4 P3 P2 P1 P0
1110 The top row defines the three LSB of data position bit, and the left column defines the three MSB of data
1111 position bit (there are 64-bit positions in total).
1112 e.g. 37th bit position is encoded 0b100_101 and has the syndrome 0x68.

Confidential
31-May-2019
1113 To derive the parity P0 for 26-bits, the P0’s in the orange cells will define whether the corresponding bit
1114 position is used in P0 parity or not.
1115 e.g. P024-bits = D0^D1^D2^D4^D5^D7^D10^D11^D13^D16^D20^D21^D22^D23^D24
1116 Similarly, to derive the parity P0 for 64-bits, all P0’s in Table 12 will define the corresponding bit positions
1117 to be used.
1118 To correct a single data bit error, the syndrome must be one of the syndromes in Table 11. These syndromes
1119 identify the bit position in error. The syndrome is calculated as:
1120 S = PSEND ^ PRECEIVED, where PSEND is the 8/6-bit ECC field in the header and PRECEIVED is the
1121 calculated parity of the received header.
1122 Table 12 represents the same information as the matrix in Table 11, organized so as to provide better insight
1123 into the way in which parity bits are formed out of data bits. The orange area of the table is used to form the
1124 ECC needed to protect a 26-bit header, whereas the whole table must be used to protect a 64-bit header.
1125 Previous CSI-2 specification versions not supporting the Virtual Channel Extension (VCX) field utilize a 30-
1126 bit Hamming-modified code word with 24 data bits and 5+1 parity bits based on the first 24 bit positions of
1127 Table 12 [i.e. a (30,24) ECC]. Packet Header bits 24 and 25 are set to zero by transmitters, and ignored by
1128 receivers conforming to such Specifications.
1129 When receiving Packet Headers with a (30,24) ECC, receivers conforming to this CSI-2 Specification version
1130 shall ignore the contents of bits 24 and 25 in such Packet Headers. The intent is for such receivers to ignore
1131 any errors occurring at these bit positions, in order to match the behavior of previous receivers. (See Section
1132 9.5.4 for implementation recommendations.)

Confidential
31-May-2019
1133 Table 12 ECC Parity Generation Rules

Bit P7 P6 P5 P4 P3 P2 P1 P0 Hex
0 0 0 0 0 0 1 1 1 0x07
1 0 0 0 0 1 0 1 1 0x0B
2 0 0 0 0 1 1 0 1 0x0D
3 0 0 0 0 1 1 1 0 0x0E
4 0 0 0 1 0 0 1 1 0x13
5 0 0 0 1 0 1 0 1 0x15
6 0 0 0 1 0 1 1 0 0x16
7 0 0 0 1 1 0 0 1 0x19
8 0 0 0 1 1 0 1 0 0x1A
9 0 0 0 1 1 1 0 0 0x1C
10 0 0 1 0 0 0 1 1 0x23
11 0 0 1 0 0 1 0 1 0x25
12 0 0 1 0 0 1 1 0 0x26
13 0 0 1 0 1 0 0 1 0x29
14 0 0 1 0 1 0 1 0 0x2A
15 0 0 1 0 1 1 0 0 0x2C
16 0 0 1 1 0 0 0 1 0x31
17 0 0 1 1 0 0 1 0 0x32
18 0 0 1 1 0 1 0 0 0x34
19 0 0 1 1 1 0 0 0 0x38
20 0 0 0 1 1 1 1 1 0x1F
21 0 0 1 0 1 1 1 1 0x2F
22 0 0 1 1 0 1 1 1 0x37
23 0 0 1 1 1 0 1 1 0x3B
24 0 0 1 1 1 1 0 1 0x3D
25 0 0 1 1 1 1 1 0 0x3E
26 0 1 0 0 0 1 1 0 0x46
27 0 1 0 0 1 0 0 1 0x49
28 0 1 0 0 1 0 1 0 0x4A
29 0 1 0 0 1 1 0 0 0x4C
30 0 1 0 1 0 0 0 1 0x51
31 0 1 0 1 0 0 1 0 0x52

Confidential
31-May-2019
Bit P7 P6 P5 P4 P3 P2 P1 P0 Hex
32 0 1 0 1 0 1 0 0 0x54
33 0 1 0 1 1 0 0 0 0x58
34 0 1 1 0 0 0 0 1 0x61
35 0 1 1 0 0 0 1 0 0x62
36 0 1 1 0 0 1 0 0 0x64
37 0 1 1 0 1 0 0 0 0x68
38 0 1 1 1 0 0 0 0 0x70
39 1 0 0 0 0 0 1 1 0x83
40 1 0 0 0 0 1 0 1 0x85
41 1 0 0 0 0 1 1 0 0x86
42 1 0 0 0 1 0 0 1 0x89
43 1 0 0 0 1 0 1 0 0x8A
44 0 1 0 0 0 0 1 1 0x43
45 0 1 0 0 0 1 0 1 0x45
46 0 1 0 0 1 1 1 1 0x4F
47 0 1 0 1 0 1 1 1 0x57
48 1 0 0 0 1 1 0 0 0x8C
49 1 0 0 1 0 0 0 1 0x91
50 1 0 0 1 0 0 1 0 0x92
51 1 0 0 1 0 1 0 0 0x94
52 1 0 0 1 1 0 0 0 0x98
53 1 0 1 0 0 0 0 1 0xA1
54 1 0 1 0 0 0 1 0 0xA2
55 1 0 1 0 0 1 0 0 0xA4
56 1 0 1 0 1 0 0 0 0xA8
57 1 0 1 1 0 0 0 0 0xB0
58 1 1 0 0 0 0 0 1 0xC1
59 1 1 0 0 0 0 1 0 0xC2
60 1 1 0 0 0 1 0 0 0xC4
61 1 1 0 0 1 0 0 0 0xC8
62 1 1 0 1 0 0 0 0 0xD0
63 1 1 1 0 0 0 0 0 0xE0

Confidential
31-May-2019
9.5.3 ECC Generation on TX Side

1134 This is an informative section.
1135 The ECC can be easily implemented using a parallel approach as depicted in Figure 62 for a 64-bit header.
Data Data Data Data Data Data Data Data

P
(8 Bits)
Byte Byte Byte Byte Byte Byte Byte Byte
7 6 5 4 3 2 1 0
Parity Generator
1136
Figure 62 64-bit ECC Generation on TX Side
1137 And Figure 63 for a 26-bit header:
2 Data Bits
Data Data Data
P Byte Byte Byte
(6 Bits) 2 1 0
Parity
Generator
1138
Figure 63 26-bit ECC Generation on TX Side
1139 The parity generators are based on Table 12.
1140 e.g. P326-bit = D1^D2^D3^D7^D8^D9^D13^D14^D15^D19^D20^D21^D23^D24^D25
1141 For backwards-compatibility, transmitters conforming to this CSI-2 Specification version should always set
1142 Packet Header bits 24 and 25 (the VCX field) to zero in any packets sent to receivers conforming to previous
1143 CSI-2 Specification versions incorporating a (30,24) ECC.

Confidential
31-May-2019
9.5.4 Applying ECC on RX Side (Informative)

1144 Applying ECC on RX side involves generating a new ECC for the received Packet Header, computing the
1145 syndrome using the new ECC and the received ECC, decoding the syndrome to find if a single-error has
1146 occurred, and if so, correcting it. Figure 64 depicts ECC processing for 64 received Packet Header data bits,
1147 using 8 parity bits.
Combinational
Received ECC Logic Block
Rec’d No error
ECC
8-Bit
Corrected Error
XOR SYN Syndrome
Decoder Error
8-Bit Parity Calc’d
Received ECC
Generator
72-Bit
Packet Corrected 64
Packet Header
Header
ECC Data Bits
Byte
Byte Byte
XOR
7 7
Byte Byte
XOR
6 6
Byte Byte
XOR
5 5
Byte Byte
XOR
4 4
Byte Byte
XOR
3 3
Byte Byte
XOR
2 2
Byte Byte
XOR
1 1
Byte Byte
XOR
0 0
1148
Figure 64 64-bit ECC on RX Side Including Error Correction
1149 Decoding the syndrome has four possible outcomes:

1150 1. If the syndrome is 0, no errors are present.
1151 2. If the syndrome matches one of the matrix entries in the Table 11, then a single bit error has
1152 occurred and the corresponding bit position may be corrected by inverting it (e.g. by XORing with
1153 ‘1’).
1154 3. If the syndrome has only one bit set, then a single bit error has occurred at the parity bit located at
1155 that syndrome bit position, and the rest of the received packet header bits are error-free.
1156 4. If the syndrome does not fit any of the other outcomes, then an uncorrectable error has occurred,
1157 and an error flag should be set (indicating that the Packet Header is corrupted).
1158 The 26-bit implementation shown in Figure 65 uses fewer terms to calculate the parity, and thus the syndrome
1159 decoding block is much simpler than the 64-bit implementation.
1160 Receivers conforming to this CSI-2 Specification version that receive Packet Headers from transmitters
1161 without the VCX field should forcibly set received bits 24 and 25 to zero in such Packet Headers prior to any
1162 parity generation or syndrome decoding (this is the function of the “VCX Override” block shown in Figure
1163 65). This guarantees that the receiver will properly ignore any errors occurring at bit positions 24 and 25, in
1164 order to match the behavior of receivers conforming to previous versions of this Specification.

Confidential
31-May-2019
Combinational
Received
Logic Block
6-bit ECC
Rec’d No error
ECC
6-Bit
Corrected Error
XOR SYN Syndrome
Received Decoder
32-Bit Error
Packet 6-Bit Parity Calc’d Corrected 26
Generator ECC
Packet Header
Header
Data Bits
ECC
Byte 3 VCX
VCX XOR
VCX (2 bits)
Override
Byte Byte
XOR
2 2
Byte Byte
XOR
1 1
Byte Byte
XOR
0 0
1165
Figure 65 26-bit ECC on RX Side Including Error Correction

Confidential
31-May-2019
9.6 Checksum Generation

1166 To detect possible errors in transmission, a checksum is calculated over the WC bytes composing the Packet
1167 Data of every Long Packet; a similar checksum is calculated over the four bytes composing the Reserved,
1168 Virtual Channel Extension, Data Identifier, and Word Count fields of every Packet Header for the C-PHY
1169 physical layer option. In all cases, the checksum is realized as 16-bit CRC based on the generator polynomial
1170 x16+x12+x5+x0 and is computed over bytes in the order in which they are presented to the Lane Distributor
1171 function by the low level protocol layer as shown in Figure 52, Figure 53, and Figure 57.
1172 The order in which the checksum bytes are presented to the Lane Distributor function is illustrated in Figure
1173 66.
16-bit Checksum
CRC LS Byte CRC MS Byte

1174
Figure 66 Checksum Transmission Byte Order
1175 When computed over the Packet Data words of a Long Packet, the 16-bit checksum sequence is transmitted
1176 as part of the Packet Footer. When the Word Count is zero, the CRC shall be 0xFFFF. When computed over
1177 the Reserved, Virtual Channel Extension, Data Identifier, and Word Count fields of a Packet Header for the
1178 C-PHY physical layer option, the 16-bit checksum sequence is transmitted as part of the Packet Header CRC
1179 (PH-CRC) field.
Included in the Checksum Checksum
VCX
DI WC ECC Payload Data – Packet 1 CS
VCX
DI WC ECC Payload Data – Packet 2 CS
VCX
DI WC ECC Payload Data – Packet N CS
32-bit PACKET 16-bit PACKET

HEADER (PH) FOOTER (PF)
1180
Figure 67 Checksum Generation for Long Packet Payload Data
1181 The definition of a serial CRC implementation is presented in Figure 68. The CRC implementation shall be
1182 functionally equivalent with the C code presented in Figure 69. The CRC shift register is initialized to
1183 0xFFFF at the beginning of each packet. Note that for the C-PHY physical layer option, if the same circuitry
1184 is used to compute both the Packet Header and Packet Footer CRC, the CRC shift register shall be initialized
1185 twice per packet, i.e. once at the beginning of the packet and then again following the computation of the
1186 Packet Header CRC. After all payload data has passed through the CRC circuitry, the CRC circuitry contains
1187 the checksum. The 16-bit checksum produced by the C code in Figure 69 equals the final contents of the
1188 C[15:0] shift register shown in Figure 68. The checksum is then transmitted by the CSI-2 physical layer to
1189 the CSI-2 receiver to verify that no errors have occurred in the transmission.

Confidential
31-May-2019
C15 C14 C13 C12 C11 C10 C9 C8 C7 C6 C5 C4 C3 C2 C1 C0
Polynomial: x16 + x12 + x5 + x0

1190
Note: C15 represents x0, C0 represents x15
Figure 68 Definition of 16-bit CRC Shift Register
#define POLY 0x8408 /* 1021H bit reversed */

unsigned short crc16(char *data_p, unsigned short length)
{
unsigned char i;
unsigned int data;
unsigned int crc = 0xffff;
if (length == 0)
return (unsigned short)(crc);
do
{
for (i=0, data=(unsigned int)0xff & *data_p++;
i < 8;i++, data >>= 1)
{
if ((crc & 0x0001) ^ (data & 0x0001))
crc = (crc >> 1) ^ POLY;
else
crc >>= 1;
}
} while (--length);
// Uncomment to change from little to big Endian

// crc = ((crc & 0xff) << 8) | ((crc & 0xff00) >> 8);
return (unsigned short)(crc);
1191
}
Figure 69 16-bit CRC Software Implementation Example
1192 Beginning with index 0, the contents of the input data array in Figure 69 are given by WC 8-bit payload data
1193 words for packet data CRC computations and by the four 8-bit [Reserved, VCX], Data Identifier, WC (LS
1194 byte), and WC (MS byte) fields for packet header CRC computations.
1195
1196 CRC computation examples:

1197 Input Data Bytes:
1198 FF 00 00 02 B9 DC F3 72 BB D4 B8 5A C8 75 C2 7C 81 F8 05 DF FF 00 00 01
1199 Checksum LS byte and MS byte:
1200 F0 00
1201
1202 Input Data Bytes:
1203 FF 00 00 00 1E F0 1E C7 4F 82 78 C5 82 E0 8C 70 D2 3C 78 E9 FF 00 00 01
1204 Checksum LS byte and MS byte:
1205 69 E5

Confidential
31-May-2019
9.7 Packet Spacing

1206 All CSI-2 implementations shall support a transition into and out of the Low Power State (LPS) between
1207 Low Level Protocol packets; however, implementations may optionally remain in the High Speed State
1208 between packets as described in Section 9.11. Figure 70 illustrates the packet spacing with the LPS.
1209 The packet spacing illustrated in Figure 70 does not have to be a multiple of 8-bit data words, as the receiver
1210 will resynchronize to the correct byte boundary during the SoT sequence prior to the Packet Header of the
1211 next packet.
SHORT / LONG PACKET SPACING:

Variable - always a LPS between packets
ST PH DATA PF ET LPS ST PH DATA PF ET
ST SP ET LPS ST SP ET LPS ST PH DATA PF ET
KEY:
ST – Start of Transmission PF – Packet Footer + Filler (if applicable)
1212
ET – End of Transmission SP – Short Packet
Figure 70 Packet Spacing

Confidential
31-May-2019
9.8 Synchronization Short Packet Data Type Codes

1213 Short Packet Data Types shall be transmitted using only the Short Packet format. See Section 9.1.2 for a
1214 format description.
1215 Table 13 Synchronization Short Packet Data Type Codes
0x00 Frame Start Code
0x01 Frame End Code
0x02 Line Start Code (Optional)
0x03 Line End Code (Optional)
0x04 End of Transmission Code (Optional)
See Section 9.11.1.2.5 for description.
0x05 to 0x07 Reserved
9.8.1 Frame Synchronization Packets

1216 Each image frame shall begin with a Frame Start (FS) Packet containing the Frame Start Code. The FS Packet
1217 shall be followed by one or more long packets containing image data and zero or more short packets
1218 containing synchronization codes. Each image frame shall end with a Frame End (FE) Packet containing the
1219 Frame End Code. See Table 13 for a description of the synchronization code data types.
1220 For FS and FE synchronization packets the Short Packet Data Field shall contain a 16-bit frame number. This
1221 frame number shall be the same for the FS and FE synchronization packets corresponding to a given frame.
1222 The 16-bit frame number, when used, shall be non-zero to distinguish it from the use-case where frame
1223 number is inoperative and remains set to zero.
1224 The behavior of the 16-bit frame number shall be one of the following:
1225 • Frame number is always zero – frame number is inoperative.
1226 • Frame number increments by 1 or 2 for every FS packet with the same Virtual Channel and is
1227 periodically reset to one; e.g. 1, 2, 1, 2, 1, 2, 1, 2 or 1, 2, 3, 4, 1, 2, 3, 4 or 1, 3, 5, 1, 3, 5 or 1, 2, 4,
1228 1, 3, 4. Frame number may be incremented by 2 only when an image frame is masked (i.e. not
1229 transmitted) due to corruption. To accommodate such cases, increments by 1 or 2 may be freely
1230 intermixed within a sequence of frame numbers as needed.

Confidential
31-May-2019
9.8.2 Line Synchronization Packets

1231 Line synchronization short packets are optional on a per-image-frame basis. If an image frame includes Line
1232 Start (LS) and Line End (LE) line synchronization short packets with one long packet having a given data
1233 type and virtual channel number, then it shall include LS and LE short packets with all long packets having
1234 that same data type and virtual channel number within the same image frame.
1235 For LS and LE synchronization packets, the Short Packet Data Field shall contain a 16-bit line number. This
1236 line number shall be the same for the LS and LE packets corresponding to a given line. Line numbers are
1237 logical line numbers and are not necessarily equal to the physical line numbers.
1238 The 16-bit line number, when used, shall be non-zero to distinguish it from the case where line number is
1239 inoperative and remains set to zero.
1240 The behavior of the 16-bit line number within the same Data Type and Virtual Channel shall be one of the
1241 following.
1242 Either:
1243 1. Line number is always zero – line number is inoperative.
1244 Or:
1245 2. Line number increments by one for every LS packet within the same Virtual Channel and the same
1246 Data Type. The line number is periodically reset to one for the first LS packet after a FS packet.
1247 The intended usage is for progressive scan (non- interlaced) video data streams. The line number
1248 must be a non-zero value.
1249 Or:
1250 3. Line number increments by the same arbitrary step value greater than one for every LS packet
1251 within the same Virtual Channel and the same Data Type. The line number is periodically reset to
1252 a non-zero arbitrary start value for the first LS packet after a FS packet. The arbitrary start value
1253 may be different between successive frames. The intended usage is for interlaced video data
1254 streams.
1255 Figure 71 contains examples for the use of optional LS/LE packets within an interlaced frame with pixel
1256 data and additional embedded types. The Figure illustrates the use cases:
1257 1. VC0 DT2 Interlaced frame with line counting incrementing by two. Frame1 starting at 1 and
1258 Frame2 starting at 2.
1259 2. VC0 DT1 Progressive scan frame with line counting.
1260 3. VC0 DT4 Progressive scan frame with non-operative line counting.
1261 4. VC0 DT3 No LS/LE operation.

Confidential
31-May-2019
VC0 FS
VC0 DT3 VC0 DT3 Payload CRC
VC0 LS1 VC0 DT1 VC0 DT1Payload CRC VC0 LE1

VC0 LS2 VC0 DT1 VC0 DT1Payload CRC VC0 LE2
VC0 LS1 VC0 DT2 VC0 DT2 Payload CRC VC0 LE1
VC0 LS2n+1 VC0 DT2 VC0 DT2 Payload CRC VC0 LE2n+1
VC0 LSm-1 VC0 DT1 VC0 DT1 Payload CRC VC0 LEm-1
VC0 LSm VC0 DT1 VC0 DT1 Payload CRC VC0 LEm
VC0 FE
VC0 FS
VC0 LS VC0 DT4 VC0 DT4Payload CRC VC0 LE

VC0 LS VC0 DT4 VC0 DT4Payload CRC VC0 LE
VC0 LS2n+2 VC0 DT2 VC0 DT2 Payload CRC VC0 LE2n+2
VC0 LS VC0 DT4 VC0 DT4 Payload CRC VC0 LE
VC0 LS VC0 DT4 VC0 DT4 Payload CRC VC0 LE
VC0 FE
Note:
• For VC0 DT2 Odd Frames LS2n+1 and Even Frames LS2n+2 (where n=0,1,2,3...) the first line n=0
• For VC0 DT1 LSm+1(where m=0,1,2,3...) the first line m=0
1262
Figure 71 Example Interlaced Frame Using LS/LE Short Packet and Line Counting

Confidential
31-May-2019
9.9 Generic Short Packet Data Type Codes

1263 Table 14 lists the Generic Short Packet Data Types.
1264 Table 14 Generic Short Packet Data Type Codes
0x08 Generic Short Packet Code 1
0x09 Generic Short Packet Code 2
0x0A Generic Short Packet Code 3
0x0B Generic Short Packet Code 4
0x0C Generic Short Packet Code 5
0x0D Generic Short Packet Code 6
0x0E Generic Short Packet Code 7
0x0F Generic Short Packet Code 8
1265 The intention of the Generic Short Packet Data Types is to provide a mechanism for including timing
1266 information for the opening/closing of shutters, triggering of flashes, etc., within the data stream. The intent
1267 of the 16-bit User defined data field in the generic short packets is to pass a data type value and a 16-bit data
1268 value from the transmitter to application layer in the receiver. The CSI-2 receiver shall pass the data type
1269 value and the associated 16-bit data value to the application layer.

Confidential
31-May-2019
9.10 Packet Spacing Examples Using the Low Power State

1270 Packets discussed in this section are separated by an EoT, LPS, SoT sequence as defined in [MIPI01] for the
1271 D-PHY physical layer option and [MIPI02] for the C-PHY physical layer option.
1272 Figure 72 and Figure 73 contain examples of data frames composed of multiple packets and a single packet,
1273 respectively.
1274 Note that the VVALID, HVALID and DVALID signals in the figures in this section are only concepts to help
1275 illustrate the behavior of the frame start/end and line start/end packets. The VVALID, HVALID and DVALID
1276 signals do not form part of the Specification.
Frame Start First Packet Last Packet Frame End

Packet of Data of Data Packet
SoT FS EoT LPS SoT PH Data PF EoT SoT PH Data PF EoT LPS SoT FE EoT
VVALID
HVALID
DVALID
KEY:
SoT – Start of Transmission EoT – End of Transmission LPS – Low Power State
PH – Packet Header PF – Packet Footer + Filler (if applicable)
FS – Frame Start FE – Frame End
1277
LS – Line Start LE – Line End
Figure 72 Multiple Packet Example
Frame Start Frame End

Packet Packet
SoT FS EoT LPS SoT PH Data PF EoT LPS SoT FE EoT
VVALID
HVALID
DVALID
KEY:
1278
Figure 73 Single Packet Example

Confidential
31-May-2019
1 Line 1 Line
SoT PH Data PF EoT LPS SoT PH Data PF EoT LPS SoT PH Data PF EoT
Long Packet Long Packet Long Packet

Line Blanking Line Blanking
Last Packet of Frame End Frame Start First Packet of

Data Packet Packet Data
SoT PH Data PF EoT LPS SoT FE EoT LPS SoT FS EoT LPS SoT PH Data PF EoT
Long Packet Long Packet

Frame Blanking
KEY:
1279
Figure 74 Line and Frame Blanking Definitions
1280 The period between the end of the Packet Footer (or the Packet Filler, if present) of one long packet and the
1281 Packet Header of the next long packet is called the Line Blanking Period.
1282 The period between the Frame End packet in frame N and the Frame Start packet in frame N+1 is called the
1283 Frame Blanking Period (Figure 74).
1284 The Line Blanking Period is not fixed and may vary in length. The receiver should be able to cope with a
1285 near zero Line Blanking Period as defined by the minimum inter-packet spacing defined in [MIPI01] or
1286 [MIPI02], as appropriate. The transmitter defines the minimum time for the Frame Blanking Period. The
1287 Frame Blanking Period duration should be programmable in the transmitter.
1288 Frame Start and Frame End packets shall be used.
1289 Recommendations (informative) for frame start and end packet spacing:
1290 • The Frame Start packet to first data packet spacing should be as close as possible to the minimum
1291 packet spacing
1292 • The last data packet to Frame End packet spacing should be as close as possible to the minimum
1293 packet spacing
1294 The intention is to ensure that the Frame Start and Frame End packets accurately denote the start and end of
1295 a frame of image data. A valid exception is when the positions of the Frame Start and Frame End packets are
1296 being used to convey pixel level accurate vertical synchronization timing information.
1297 The positions of the Frame Start and Frame End packets can be varied within the Frame Blanking Period in
1298 order to provide pixel level accurate vertical synchronization timing information. See Figure 75.
1299 If pixel level accurate horizontal synchronization timing information is required, Line Start and Line End
1300 packets should be used to achieve it.
1301 The positions of the Line Start and Line End packets, if present, can be varied within the Line Blanking
1302 Period in order to provide pixel accurate horizontal synchronization timing information. See Figure 76.

Confidential
31-May-2019
VIDEO
DATA
Black Level
Blanking Level
Sync Level
DVALID
VVALID
SoT FE EoT LPS SoT FS EoT LPS SoT PH Data PF EoT LPS SoT PH Data PF EoT
Frame End Frame Start Valid Video Data Valid Video Data
Packet Packet
1303
Figure 75 Vertical Sync Example
VIDEO
DATA
Black Level
Blanking Level
Sync Level
DVALID
HVALID
PF EoT LPS SoT LE EoT LPS SoT LS EoT LPS SoT PH Data PF EoT LPS SoT LE EoT
Line End Line Start Valid Video Data Line End

1304 Packet Packet Packet
Figure 76 Horizontal Sync Example

Confidential
31-May-2019
9.11 Latency Reduction and Transport Efficiency (LRTE)

1305 Latency Reduction and Transport Efficiency (LRTE) is an optional CSI-2 feature that facilitates optimal
1306 transport, in order to support a number of emerging imaging applications.
1307 LRTE has two parts, further detailed in this Section:
1308 • Interpacket Latency Reduction (ILR)
1309 • Enhanced Transport Efficiency
9.11.1 Interpacket Latency Reduction (ILR)

1310 As per [MIPI01] for the D-PHY physical layer option, and [MIPI02] for the C-PHY physical layer option,
1311 CSI-2 Short Packets and Long Packets are separated by EoT, LPS, and SoT packet delimiters. Advanced
1312 imaging applications, PDAF (Phase Detection Auto Focus), Sensor Aggregation, and Machine Vision can
1313 substantially benefit from the effective speed increases produced by reducing the overhead of these
1314 delimiters.
1315 As shown in Figure 77, interpacket latency reduction may be used to replace legacy EoT, LPS, and SoT
1316 packet delimiters with a more Efficient Packet Delimiter (EPD) signaling mechanism that avoids the need
1317 for HS-LPS-HS transitions. An EPD consists of PHY layer and/or protocol layer elements. The PHY-
1318 generated EPD element is referred to as “Packet Delimiter Quick” (PDQ). Protocol-generated EPD elements
1319 are called Spacers and may optionally precede PDQs.
Packet Transfers using Legacy EoT, LPS, and SoT Delimiters

SoT SP EoT LPS SoT PH Data PF EoT LPS SoT PH Data PF EoT LPS SoT SP EoT
KEY:
SoT – Start of Transmission
LRTE replaces legacy EoT, LPS, SoT with EPD
LPS – Low Power State
PH – Packet Header
EPD – Efficient Packet Delimiter
SoT SP EPD PH Data PF EPD PH Data PF EPD SP EoT
Packet Transfers using LRTE EPD

1320
Figure 77 Interpacket Latency Reduction Using LRTE EPD
1321 As shown in Figure 77, LRTE requires an EPD to be inserted between adjacent CSI-2 packets during PHY
1322 high-speed signaling, but does not permit an EPD to be inserted after a CSI-2 packet just prior to PHY EoT.
1323 However, as described later in this section, it is possible under certain conditions to insert Spacers, but without
1324 PHY-generated PDQ signaling, after a CSI-2 packet just prior to PHY EoT.

Confidential
31-May-2019
9.11.1.1 EPD for C-PHY Physical Layer Option

1325 The EPD for the C-PHY physical layer option consists of one or more instances of the PHY-generated and
1326 PHY-consumed 7-UI Sync Word for the Packet Delimiter Quick (PDQ) signaling, optionally preceded by
1327 CSI-2 protocol-generated and protocol-consumed Spacer Words. The PDQ is generated and consumed by the
1328 transmitter and receiver physical layers, respectively, and as a result serves as a robust CSI-2 packet delimiter.
1329 An image sensor should reuse “TxSendSyncHS” at the PPI in order to generate the PDQ control code by the
1330 C-PHY transmitter. Upon reception of the PDQ control code by the C-PHY receiver, an application processor
1331 should reuse “RxSyncHS” at the PPI in order to notify the CSI-2 protocol layer. The duration of the 7-UI
1332 PDQ control code is directly proportional to the C-PHY Symbol rate.
1333 The EPD for C-PHY receivers can also benefit from optional CSI-2 protocol-generated and CSI-2 protocol-
1334 consumed Spacer insertion(s) prior to PDQ, because it facilitates optimal interpacket latency for imaging
1335 applications. The value of the Spacer Word for CSI-2 over C-PHY shall be 0xFFFF, and when present, Spacer
1336 Words shall be generated across all Lanes within a Link.
1337 The image sensor (transmitter) shall include the following two 16-bit registers, in order to facilitate the
1338 optimal interpacket latency for imaging applications:
1339 1. TX_REG_CSI_EPD_EN_SSP (EPD Enable and Short Packet Spacer) Register
1340 • The MS bit of this register shall be used to enable EPD with 7-UI PDQ (Sync Word) insertion
1341 between two CSI-2 packets and optional Spacer insertions for Short Packets and Long Packets.
1342 • 1’b0: C-PHY legacy EoT, LPS, SoT Packet Delimiter
1343 • 1’b1: Enable C-PHY EPD (Efficient Packet Delimiter)
1344 • If C-PHY EPD is enabled, the remaining 15 bits of this register (bits [14:0]) shall specify the
1345 minimum number (up to 32,767) of Spacer Word insertions per Lane following CSI-2 Short
1346 Packets.
1347 2. TX_REG_CSI_EPD_OP_SLP (Long Packet Spacer) Register
1348 • The MS bit of this register is reserved for future use.
1349 • If C-PHY EPD is enabled, the remaining 15 bits of this register (bits [14:0]) shall specify the
1350 minimum number (up to 32,767) of Spacer Word insertions per Lane following CSI-2 Long
1351 Packets.
1352 If the C-PHY EPD is enabled, then the following applies to the fifteen least significant bits of both EPD
1353 registers:
1354 • A register value of 15’d0 generates zero or more Spacers.
1355 • A register value of 15’d5 generates at least 5 Spacers, resulting in a minimum duration of 5 x 7 UI.
1356 • The maximum register value of 15’d32,767 generates at least 32,767 Spacers, resulting in a
1357 minimum duration of 32,767 x 7 UI.
1358 The transmitter shall support at least one non-zero value of the Spacer insertion count field in each of the
1359 TX_REG_CSI_EPD_EN_SSP and TX_REG_CSI_EPD_OP_SLP registers.
1360 Spacer Words without PDQ signaling may be inserted after CSI-2 packets just prior to C-PHY EoT only if
1361 C-PHY EPD is enabled and bit 7 of the TX_REG_CSI_EPD_MISC_OPTIONS register is set to 1; see
1362 Table 16. If this register bit is not implemented by an image sensor, its contents shall be treated as 0 by this
1363 specification. The minimum number of Spacer Word insertions just prior to C-PHY EoT is determined by the
1364 fifteen least significant bits of the TX_REG_CSI_EPD_EN_SSP and TX_REG_CSI_EPD_OP_SLP
1365 registers.
1366 Note that C-PHY EPDs and Spacer Words without PDQ signaling are completely compatible with C-PHY
1367 ALP Mode high speed burst transmissions as described in [MIPI02].

Confidential
31-May-2019
EPD
Total Packet Byte Count = 4n
Lane 1 SoT PH SYN PH Byte 1 Byte 0 Byte 4n-7 Byte 4n-8 Byte 4n-3 Byte 4n-4 Spacer SYN PH SYN PH Byte 1 Byte 0
Lane 2 SoT PH SYN PH Byte 3 Byte 2 Byte 4n-5 Byte 4n-6 Byte 4n-1 Byte 4n-2 Spacer SYN PH SYN PH Byte 3 Byte 2
Total Packet Byte Count = 4n+1

Lane 1 SoT PH SYN PH Byte 1 Byte 0 Byte 4n-3 Byte 4n-4 Filler Byte 4n Spacer SYN PH SYN PH Byte 1 Byte 0
Lane 2 SoT PH SYN PH Byte 3 Byte 2 Byte 4n-1 Byte 4n-2 Filler Filler Spacer SYN PH SYN PH Byte 3 Byte 2
Total Packet Byte Count = 4n+2 • ••
Lane 1 SoT PH SYN PH Byte 1 Byte 0 Byte 4n-3 Byte 4n-4 Byte 4n+1 Byte 4n Spacer SYN PH SYN PH Byte 1 Byte 0
Lane 2 SoT PH SYN PH Byte 3 Byte 2 Byte 4n-1 Byte 4n-2 Filler Filler Spacer SYN PH SYN PH Byte 3 Byte 2
Total Packet Byte Count = 4n+3

Lane 1 SoT PH SYN PH Byte 1 Byte 0 Byte 4n-3 Byte 4n-4 Byte 4n+1 Byte 4n Spacer SYN PH SYN PH Byte 1 Byte 0
Lane 2 SoT PH SYN PH Byte 3 Byte 2 Byte 4n-1 Byte 4n-2 Filler Byte 4n+2 Spacer SYN PH SYN PH Byte 3 Byte 2
First Packet Second Packet
KEY:
SoT – Start of Transmission EoT – End of Transmission EPD – Efficient Packet Delimiter contains optional Spacer
word insertion followed by a mandatory
SYN – Sync Word PH – Packet Header PDQ (Sync Word). An EPD consisting of single
1368 Spacer followed by one PDQ shown for illustration.
Figure 78 LRTE Efficient Packet Delimiter Example for CSI-2 Over C-PHY (2 Lanes)

Confidential
31-May-2019
9.11.1.2 EPD for D-PHY Physical Layer Option

1369 There are two EPD options for CSI-2 over the D-PHY physical layer option, as detailed in the following sub-
1370 sections.
1371 When EPD is enabled, CSI-2 over the D-PHY physical layer option shall align all Lanes corresponding to a
1372 Link using the minimum number of Filler byte(s) for both options. The value of the Filler byte shall be 0x00.
1373 The process of aligning Lanes within a Link through the use of Filler bytes is similar to native EOT alignment
1374 of CSI-2 over C-PHY.
9.11.1.2.1 D-PHY EPD Option 1

1375 D-PHY EPD Option 1 consists of PHY-generated and PHY-consumed D-PHY HS-Idle Packet Delimiter
1376 Quick (PDQ) signaling, optionally preceded by CSI-2 protocol-generated and protocol-consumed Filler bytes
1377 (as needed) plus zero or more Spacer bytes. The value of the Spacer byte for CSI-2 over D-PHY shall be
1378 0xFF, and when present, Spacer bytes shall be generated across all Lanes within a Link. The PDQ is generated
1379 and consumed by the transmitter and receiver physical layers, respectively, and as a result serves as a robust
1380 CSI-2 packet delimiter. D-PHY receivers can benefit from protocol-generated and protocol-consumed
1381 Spacer(s), because additional clock cycles might be needed to flush the payload content through the pipelines
1382 before the forwarded clock is disabled for PDQ signaling. Note that D-PHY HS-Idle is not supported by ALP
1383 mode in [MIPI01].
1384 Under D-PHY Option 1, an EPD may not be inserted after a CSI-2 packet just prior to D-PHY EoT, but
1385 Spacer Bytes without PDQ signaling may be inserted after such packets if bit 7 of the
1386 TX_REG_CSI_EPD_MISC_OPTIONS register is 1. The minimum number of Spacer byte insertions just
1387 prior to D-PHY EoT is determined by the fifteen least significant bits of the TX_REG_CSI_EPD_EN_SSP
1388 and TX_REG_CSI_EPD_OP_SLP registers. See Table 17.
1389 The image sensor should use “TxHSIdleClkHS” at the PPI in order to generate the PDQ sequence by the
1390 D-PHY transmitter. Upon reception of the PDQ sequence by the D-PHY receiver, an application processor
1391 should use “RXSyncHS” at the PPI to notify the CSI-2 protocol layer. Additionally, “RxClkActiveHS” may
1392 also be used to provide an advance indication of the EPD.
Number of Bytes, B, transmitted is NOT an integer multiple of the number of lanes, N with alignment using Filler bytes for packet transfers using
PHY generated and consumed PDQ. One optional Spacer byte insertion included for illustration.

EPD
LANE 1: SoT Byte 0 Byte N Byte B-N-K Byte B-K Spacer PDQ Byte 0
• ••
• ••
• ••
• ••
• ••
• ••
LANE K: SoT Byte K-1 Byte N+K-1 Byte B-N-1 Byte B-1 Spacer PDQ Byte K-1
• ••
LANE K+1: SoT Byte K Byte N+K Byte B-N Filler Spacer PDQ Byte K
• ••
• ••
• ••
• ••
• ••
• ••
LANE N: SoT Byte N-1 Byte 2N-1 Byte B-K-1 Filler Spacer PDQ Byte N-1
KEY:
PDQ – PHY generated and consumed Packet Delimiter Quick EPD – Efficient Packet Delimiter
1393
Figure 79 Example of LRTE EPD for CSI-2 Over D-PHY – Option 1

Confidential
31-May-2019
9.11.1.2.2 D-PHY EPD Option 2

1394 D-PHY EPD Option 2 is limited to the insertion of CSI-2 protocol-generated and CSI-2 protocol-consumed
1395 Filler bytes (as needed) plus zero or more Spacer bytes for use between multiple back-to-back packet transfers
1396 within the same D-PHY high-speed burst transfer (i.e., there is no use of PHY-generated and PHY-consumed
1397 PDQ). Option 2 is primarily intended for use with D-PHYs supporting legacy LP or LVLP mode that don’t
1398 support Option 1; however, it may also be used with ALP Mode as described in [MIPI01]. Depending on the
1399 use case (i.e., the sizes and number of CSI-2 packets being concatenated), the lack of D-PHY-generated and
1400 D-PHY-consumed packet delimiters could compromise CSI-2 link integrity. Option 2 is not intended to
1401 completely eliminate D-PHY LP, LVLP, or ALP Mode packet delimiters. It is also recommended that one or
1402 more Spacers be included following a Short Packet or a Long Packet when using D-PHY EPD Option 2.
1403 D-PHY EPD Option 2 may also be applied to packets transmitted using C-PHY or D-PHY Escape Mode
1404 LPDT in connection with the Unified Serial Link (USL) feature described in Section 9.12.
1405 Under D-PHY Option 2, an EPD (i.e., one or more Spacers) shall not be inserted immediately after the last
1406 CSI-2 short or long packet in any high-speed burst or LPDT payload, including after the EoTp short packet
1407 described in Section 9.11.1.2.5.
Number of Bytes, B, transmitted is NOT an integer multiple of the number of lanes, N with alignment using Filler
bytes for back-to-back transfers. Two optional Spacer byte insertions included for illustration.

EPD
LANE 1: SoT Byte 0 Byte N Byte B-N-K Byte B-K Spacer Spacer Byte 0
• ••
• ••
• ••
• ••
• ••
• ••
LANE K: SoT Byte K-1 Byte N+K-1 Byte B-N-1 Byte B-1 Spacer Spacer Byte K-1
• ••
LANE K+1: SoT Byte K Byte N+K Byte B-N Filler Spacer Spacer Byte K
• ••
• ••
• ••
• ••
• ••
• ••
LANE N: SoT Byte N-1 Byte 2N-1 Byte B-K-1 Filler Spacer Spacer Byte N-1
KEY:
EPD – Efficient Packet Delimiter
1408
Figure 80 Example of LRTE EPD for CSI-2 Over D-PHY – Option 2

Confidential
31-May-2019
9.11.1.2.3 D-PHY EPD Specifications (for EPD Options 1 and 2)

1409 The image sensor (transmitter) shall include the following two 16-bit registers, in order to facilitate the
1410 optimal interpacket latency for imaging applications:
1411 1. TX_REG_CSI_EPD_EN_SSP (EPD Enable and Short Packet Spacer) Register
1412 • The MS bit of this register shall be used to enable EPD insertion between two CSI-2 packets.
1413 • 1’b0: D-PHY legacy EoT, LPS, SoT Packet Delimiter
1414 • 1’b1: Enable D-PHY EPD (Efficient Packet Delimiter)
1415 • Variable-length Spacer insertions following Short Packets:
1416 If D-PHY EPD is enabled and either Option 1 is selected (i.e., bit 15 of register
1417 TX_REG_CSI_EPD_OP_SLP is 0) or Option 2 is selected with bit 5 or bit 4 of register
1418 TX_REG_CSI_EPD_MISC_OPTIONS in Table 17 set to 1, then bits [14:0] of register
1419 TX_REG_CSI_EPD_EN_SSP shall specify the minimum number (up to 32,767) of Spacer
1420 insertions per Lane following CSI-2 Short Packets. The number of Spacers actually inserted per
1421 Lane may vary from one Short Packet to another. For D-PHY EPD Option 2, both the contents of
1422 register TX_REG_CSI_EPD_EN_SSP and the actual number of Spacers inserted per Lane shall
1423 be multiples of the value selected in bits [5:4] of register
1424 TX_REG_CSI_EPD_MISC_OPTIONS.
1425 • Fixed-length Spacer Insertions following Short Packets:
1426 If D-PHY EPD is enabled, and Option 2 is selected (i.e., bit 15 of register
1427 TX_REG_CSI_EPD_OP_SLP is 1) with bit 5 and bit 4 of register
1428 TX_REG_CSI_EPD_MISC_OPTIONS set to 0, then bits [14:0] of register
1429 TX_REG_CSI_EPD_EN_SSP shall specify the exact number (up to 32,767) of Spacer insertions
1430 per Lane following CSI-2 Short Packets. The number of Spacers inserted shall not vary from one
1431 Short Packet to another.
1432 2. TX_REG_CSI_EPD_OP_SLP (EPD Option and Long Packet Spacer) Register
1433 • The MS bit of this register shall be used to select the D-PHY EPD option.
1434 • 1’b0: D-PHY EPD Option 1
1435 • 1’b1: D-PHY EPD Option 2
1436 • Variable-length Spacer insertions following Long Packets:
1437 If D-PHY EPD is enabled and either Option 1 is selected (i.e., bit 15 of register
1438 TX_REG_CSI_EPD_OP_SLP is 0) or Option 2 is selected with bit 5 or bit 4 of register
1440 TX_REG_CSI_EPD_OP_SLP shall specify the minimum number (up to 32,767) of Spacer
1441 insertions per Lane following CSI-2 Long Packets. The number of Spacers actually inserted per
1442 Lane may vary from one Long Packet to another. For D-PHY EPD Option 2, both the contents of
1443 register TX_REG_CSI_EPD_EN_SLP and the actual number of Spacers inserted per Lane shall
1444 be multiples of the value selected in bits [5:4] of register
1445 TX_REG_CSI_EPD_MISC_OPTIONS.
1446 • Fixed-length Spacer insertions following Long Packets:
1447 If D-PHY EPD is enabled, and Option 2 is selected (i.e., bit 15 of register
1448 TX_REG_CSI_EPD_OP_SLP is 1), with bit 5 and bit 4 of register
1450 TX_REG_CSI_EPD_OP_SLP shall specify the exact number (up to 32,767) of Spacer insertions
1451 per Lane following CSI-2 Long Packets. The number of Spacers inserted shall not vary from one
1452 Long Packet to another.

Confidential
31-May-2019
1453 The following examples apply to the least significant fifteen bits of the two EPD registers:
1454 • For variable-length Spacer insertions:
1455 • A register value of 15’d0 generates zero or more Spacers.
1456 • A register value of 15’d5 generates at least 5 Spacers.
1457 • A register value of 15’d32,767 generates at least 32,767 Spacers.
1458 • For fixed-length Spacer insertions:
1459 • A register value of 15’d0 generates no Spacers.
1460 • A register value of 15’d5 generates exactly 5 Spacers.
1461 • A register value of 15’32,767 generates exactly 32,767 Spacers.
1462 The transmitter shall support at least one non-zero value of the Spacer insertion count field in each of the
1463 TX_REG_CSI_EPD_EN_SSP and TX_REG_CSI_EPD_OP_SLP registers. The duration of the PDQ
1464 sequence is directly proportional to the D-PHY Link rate, and is configured using the HS-Idle timing
1465 parameters defined in [MIPI01] for the D-PHY physical layer option.
1466 For D-PHY EPD, the TX_REG_CSI_EPD_MISC_OPTIONS register is required for image sensors
1467 (transmitters) supporting the insertion of Spacers-without-PDQ under Option 1 or the insertion of EoTp (see
1468 Section 9.11.1.2.5) or a variable number of Spacer bytes under Option 2. If this register is not implemented,
1469 then its value shall be treated as zero by this specification.
1470 Note that registers TX_REG_CSI_EPD_EN_SSP, TX_REG_CSI_EPD_OP_SLP, and
1471 TX_REG_CSI_EPD_MISC_OPTIONS are not intended to control image sensor LRTE when applied to
1472 USL packets transmitted using Escape Mode LPDT; see Section 9.12.

Confidential
31-May-2019
9.11.1.2.4 Robust Variable-Length Spacer Detection under D-PHY EPD Option 2

(Informative)
1473 CSI-2 transmitters inserting a variable number of Spacer bytes per Lane between packets under D-PHY EPD
1474 Option 2 require CSI-2 receivers to examine, rather than simply count, potential Spacer bytes in order not to
1475 confuse them with packet header bytes. Since Spacer bytes are required to be distributed across all data Lanes
1476 beginning with Lane 1, CSI-2 receivers may detect them by scanning for bytes with the value 0xFF between
1477 packets only on Lane 1. However, truly reliable detection also requires these bytes to be error-free because a
1478 bit error in an intended Spacer byte (with value 0xFF) on Lane 1 can cause it to appear as a packet header
1479 Data Identifier byte. Conversely, a bit error in an intended packet header Data Identifier byte can cause it to
1480 appear as a Spacer byte.
1481 If Lane-merged groups of four sequential Spacer bytes are processed as potential 32-bit packet headers by a
1482 CSI-2 receiver, then the results of the ECC calculation can be used to detect and correct errors in the Spacer
1483 bytes just as it does in packet header bytes. This is possible because the value 0x3F in the least significant
1484 six bits of each transmitted group of four Spacer bytes also happens to be the 6-bit ECC of the value
1485 0x3FFFFFF in the most significant 26 bits.
1486 Spacer byte insertion and detection schemes leveraging the latter principle may vary, depending upon the
1487 total number of data Lanes (N) in the link. Requiring the CSI-2 transmitter to insert Spacers in multiples of
1488 M = LCM(N,4) / N bytes per Lane, where LCM is the least common multiple function, always guarantees
1489 that the CSI-2 receiver will observe an integer multiple of four Spacer bytes between packets. As shown in
1490 Table 15, only values of M equal to 1, 2, and 4 are possible and programmable on the CSI-2 transmitter using
1491 bits 5:4 of the TX_REG_CSI_EPD_MISC_OPTIONS register shown in Table 17.
1492 Table 15 Minimum Spacer Bytes per Lane for ECC Calculation
Minimum Spacer Bytes per Lane
Number of Data Lanes (N)
M = LCM(N, 4) / N
1 + 4n 4
2 + 4n 2
3 + 4n 4
4 + 4n 1
Note:
n = 0, 1, 2, …

Confidential
31-May-2019
1493 Note that the CSI-2 receiver only needs to check the data integrity of one out of every M potential Spacer
1494 bytes on Lane 1; i.e., once the first byte in a group of M bytes on Lane 1 has been confirmed as a Spacer
1495 byte, then the remaining M-1 bytes can be safely ignored by the CSI-2 receiver because it knows in advance
1496 that Spacer bytes are being inserted in groups of M. See Figure 81.
General Case: Spacer bytes are inserted in groups of M on each Lane; Lane-merged Spacer bytes are ECC-
processed by CSI-2 receiver; results are used to confirm the integrity and presence of at least every M-th
Spacer byte on Lane 1
M = LCM(N,4)/N Bytes L can change with every packet
LANE 1: SoT Byte 0 Byte B-K Spacer 1 Spacer M Spacer M+1 Spacer L*M Byte 0
•••
•••
•••
•••
•••
•••
•••
•••
•••
•••
LANE K: SoT Byte K-1 Byte B-1 Spacer 1 Spacer M Spacer M+1 Spacer L*M Byte K-1
•••
LANE K+1: SoT Byte K Filler Spacer 1 Spacer M Spacer M+1 Spacer L*M Byte K
•••
•••
•••
•••
•••
•••
•••
•••
•••
•••
LANE N: SoT Byte N-1 Filler Spacer 1 Spacer M Spacer M+1 Spacer L*M Byte N-1
KEY: SoT – Start of Transmission LCM – Least Common Multiple

1497
Figure 81 Enabling Robust Spacer Byte Detection: General Case
1498 However, for N > 4, it is possible to program the CSI-2 transmitter to always insert an arbitrary number of
1499 Spacer bytes per Lane (i.e., to set M = 1) if the CSI-2 receiver examines bytes from the first four Lanes and,
1500 upon confirming a Spacer byte in Lane 1, ignores bytes from the remaining Lanes. See Figure 82.
Special Case for N > 4: Lane-merged Spacer bytes on Lanes 1 to 4 are ECC-processed first by
CSI-2 receiver; if byte on Lane 1 is a confirmed Spacer, then bytes on Lanes 5 to N can be ignored
L can change with every packet
LANE 1: SoT Byte 0 Byte B-N-4 Byte B-4 Spacer 1 Spacer L Byte 0
•••
•••
•••
•••
•••
•••
•••
•••
LANE 4: SoT Byte 3 Byte B-N-1 Byte B-1 Spacer 1 Spacer L Byte 3
•••
LANE 5: SoT Byte 4 Byte B-N Filler Spacer 1 Spacer L Byte 4

•••
•••
•••
•••
•••
•••
•••
•••
LANE N: SoT Byte N-1 Byte B-5 Filler Spacer 1 Spacer L Byte N-1
KEY: SoT – Start of Transmission LCM – Least Common Multiple

1501
Figure 82 Enabling Robust Spacer Byte Detection: Special Case

Confidential
31-May-2019
9.11.1.2.5 End-of-Transmission Short Packet (EoTp)

1502 When multiple CSI-2 packets are transmitted in a single D-PHY high-speed (HS) burst payload using D-
1503 PHY EPD Option 2, proper operation requires the host to be able to reliably detect the last CSI-2 packet in
1504 the burst under all circumstances. In many implementations, this requires the CSI-2 host protocol receiver to
1505 perform additional End-of-Transmission (EoT) processing on HS trailer and other bits passed to it from the
1506 D-PHY physical layer receiver.
1507 Such EoT processing can be even more complex if HS trailer bits are followed by a small but potentially
1508 unknown number of bits with indeterminate values sampled, for instance, during the D-PHY HS to LP or
1509 LVLP voltage transition.
1510 For D-PHY EPD Option 2, the End-of-Transmission short packet (EoTp) removes the need for the CSI-2
1511 protocol receiver to perform EoT processing by unambiguously signaling the last CSI-2 packet in a D-PHY
1512 high-speed burst payload.
1513 EoTp has the following short packet field definitions:
1514 • DT shall be set to 0x04.
1515 • All VC, VCX, and WC bits shall be set to zero.
1516 Other rules pertaining to EoTp are as follows:
1517 • EoTp generation or detection is mandatory for all devices conforming to this version of the CSI-2
1518 specification that also support D-PHY EPD Option 2 for HS transmissions. EoTp shall not be used
1519 in conjunction with C-PHY EPD, D-PHY EPD Option 1, or packet transmissions using Escape
1520 Mode LPDT (see Section 9.12).
1521 • Devices conforming to CSI-2 specification v2.1 or earlier do not support EoTp. In order to ensure
1522 interoperability with earlier devices, EoTp-supporting devices shall provide a means to enable or
1523 disable EoTp generation or detection; for image sensors, this capability shall be supplied via bit 6
1524 of the TX_REG_CSI_EPD_MISC_OPTIONS register shown in Table 17. This permits the
1525 EoTp feature to be effectively disabled by the system designer whenever a device on either side of
1526 the Link does not support EoTp.
1527 • When the EoTp feature is enabled, exactly one EoTp shall be present in every high-speed burst
1528 payload as the last CSI-2 packet following all other short and/or long packets, including payloads
1529 with only one CSI-2 short or long packet in addition to the EoTp short packet itself.
1530 • Spacers are not permitted after an EoTp because this packet is always immediately followed by
1531 D-PHY EoT, and never by another CSI-2 packet.
1532 • The contents of EoTp VC, VCX, and WC fields shall be ignored by CSI-2 protocol receivers.
1533 See Figure 83 for EoTp usage examples.
Frame-Start Image Data Image Data PDAF Data Frame-End

Short Packet Long Packet Long Packet Long Packet Short Packet
≈
LPS SoT SoF EoTp EoT LPS SoT PH RAW Data PF EoTp EoT LPS SoT PH RAW Data PF PH RAW Data PF EoF EoTp EoT LPS
≈
Optional No Spacers (EPD) Optional No Spacers (EPD) Optional Optional Optional No Spacers (EPD)
Spacers because of EoT Spacers because of EoT Spacers Spacers Spacers because of EoT
KEY: SoT – D-PHY Start of Transmission PF – CSI-2 Packet Footer

EoT – D-PHY End of Transmission PH – CSI-2 Packet Header
LPS – D-PHY Low Power State EoTp – CSI-2 End-of-Transmission Short Packet
1534
Figure 83 EoTp Usage Examples

Confidential
31-May-2019
9.11.2 Using ILR and Enhanced Transport Efficiency Together

1535 EPD may be used together with LVLP or ALP Mode signaling in many imaging applications in order to
1536 benefit from CSI-2 ILR and enhanced channel transport.
Packet Transfers using Legacy EoT, LPS, and SoT Delimiters

LPS SoT SP EoT LPS SoT PH Data PF EoT LPS SoT PH Data PF EoT LPS SoT SP EoT LPS
KEY:
SoT – Legacy Start of Transmission
Reduce interpacket latency by replacing legacy EoT, LPS, SoT with EPD, and
EoT – Legacy End of Transmission
enhance CSI-2 transport channel with LVLP or ALP Mode signaling
LPS – Legacy Low Power State
LVLP – Low Voltage Low Power
ASoT – Alternate Start of Transmission
Short Long Long Short AEoT – Alternate End of Transmission
Packet Packet Packet Packet ALPM – Alternate Low Power Mode
PH – Packet Header
ALPM ASoT SP EPD PH Data PF EPD PH Data PF EPD SP AEoT ALPM EPD – Efficient Packet Delimiter
Packet Transfers using LRTE EPD & ALP Mode

1537
Figure 84 Using EPD with LVLP or ALP Mode Signaling

Confidential
31-May-2019
9.11.3 LRTE Register Tables

1538 The CSI-2 over C-PHY Spacer Words and the CSI-2 over D-PHY Spacer Bytes shall be generated across all
1539 Lanes within a Link as specified in Table 16 and Table 17.
1540 Table 16 LRTE Transmitter Registers for CSI-2 Over C-PHY
Transmitter Register Description
TX_REG_CSI_EPD_EN_SSP [15:0] Write-only. Required.
Bit [15]: Value 1’b0: Disable Efficient Packet CSI-2 over C-PHY EPD operation
Enable or disable Efficient Packet Delimiter uses PHY-generated and PHY-
Delimiter using PHY-generated and Value 1’b1: Enable Efficient Packet consumed PDQ (7-UI Sync Word).
PHY-consumed PDQ with optional Delimiter Optional minimum Spacers may be
minimum Spacer Insertion(s) Inserted for Short Packets and
Long Packets.
See Figure 78.
Bits [14:0]: The minimum number of Spacer Words The Short Packet Spacers
EPD Short Packet Spacers per Lane following a Short packet. insertions are enabled by the
Examples: C-PHY EPD
(TX_REG_CSI_EPD_EN_SSP[15]).
Value 15’d0: Zero or more
Spacer Words
…
Value 15’d7: At least 7 Spacer Words
…
Value 15’d32767: At least 32,767
Spacer Words
TX_REG_CSI_EPD_OP_SLP [15:0] Write-only. Required
Bit [15]: Reserved Reserved Reserved for future use
Bits [14:0]: The minimum number of Spacer Words The Long Packet Spacers
EPD Long Packet Spacers per Lane following a Long packet. insertions are enabled by the
Examples: C-PHY EPD
(TX_REG_CSI_EPD_EN_SSP[15]).
Value 15’d0: Zero or more
Spacer Words
…
Value 15’d7: At least 7 Spacer Words
…
Spacer Words
TX_REG_CSI_EPD_MISC_OPTIONS [7:0] Write-only. Optional.
Bit [7]: Value 1’b0: Disable Spacers Required for image sensors
Enable insertion of Spacers- without-PDQ (default) supporting C-PHY EPD with
without-PDQ after CSI-2 packets Value 1’b1: Enable Spacers Spacers-without-PDQ.
just prior to C-PHY EoT. without-PDQ
Bits [6:0]: – –
Reserved

Confidential
31-May-2019
1541 Table 17 LRTE Transmitter Registers for CSI-2 Over D-PHY

TX_REG_CSI_EDP_EN_SSP [15:0] Write-only. Required
Bit [15]: Value 1’b0: Disable EPD See Figure 79.
Enable or disable EPD Value 1’b1: Enable EPD If EPD is enabled, the D-PHY EPD
(Efficient Packet Delimiter) Options are determined by
operation TX_REG_CSI_EPD_OP_SLP[15].
Bits [14:0]: For D-PHY EPD Option 1 The Short Packet Spacers insertions are
EPD Short Packet Spacers -or- enabled by the D-PHY EPD
For Option 2 with Variable Spacers: (TX_REG_CSI_EPD_EN_SSP[15]).
Minimum number of Spacer Bytes per See Figure 79 and Figure 80.
Lane following a Short packet.
Examples:
Value 15’d0: Zero or more Spacer Bytes
…
Value 15’d7: At least 7 Spacer Bytes
…
Spacer Bytes
Otherwise, for D-PHY EPD Option 2:
Fixed number of Spacer Bytes per Lane
following a Short packet.
TX_REG_CSI_EPD_OP_SLP [15:0] Write-only. Required.
Bit [15]: D-PHY EPD Value 1’b0: D-PHY EPD Option 1 D-PHY EPD Option 1:
Option Select Value 1’b1: D-PHY EPD Option 2 CSI-2 over D-PHY EPD operation using
PHY-generated and PHY-consumed PDQ
(using forwarded clock signaling) and
optional Spacer Insertion(s). See Figure
79.
D-PHY EPD Option 2:
CSI-2 over D-PHY EPD operation using
optional Spacer Insertion(s). See Figure
80.
Bits [14:0]: For D-PHY EPD Option 1 The Long Packet Spacers insertions are
Long Packet Spacers -or- enabled by the D-PHY EPD
For Option 2 with Variable Spacers: (TX_REG_CSI_EPD_EN_SSP[15]).
Minimum number of Spacer Bytes per See Figure 79 and Figure 80.
Lane following a Long packet.
Examples:
Value 15’d0: Zero or more Spacer Bytes
…
Value 15’d7: At least 7 Spacer Bytes
…
Spacer Bytes
Otherwise, for D-PHY EPD Option 2:
Fixed number of Spacer Bytes per Lane
following a Long packet.

Confidential
31-May-2019

TX_REG_CSI_EPD_MISC_OPTIONS [7:0] Write-only. Optional.
Bit [7]: Value 1’b0: Disable Spacers Required for image sensors supporting
For D-PHY EPD Option 1: without-PDQ (default) D-PHY EPD Option 1 with Spacers-
Value 1’b1: Enable Spacers-without-PDQ without-PDQ.
Enable insertion of
Spacers-without-PDQ after
CSI-2 packets just prior to
D-PHY EoT
Bit [6]: Value 1’b0: Disable EoTp (default) Required for image sensors supporting
For D-PHY EPD Option 2: Value 1’b1: Enable EoTp D-PHY EPD Option 2 with EoTp short
Enable EoTp packets.
Bit [5:4]: Value 2’b00: Enable fixed-length Spacers Required for image sensors supporting
For D-PHY EPD Option 2: (default) D-PHY EPD Option 2 with variable-length
Enable variable-length Value 2’b01: Enable variable-length Spacers.
Spacer insertions with a Spacers with n = 1
multiple of n Spacer bytes
Value 2’b10: Enable variable-length
per Lane
Spacers with n = 2
Value 2’b11: Enable variable-length
Spacers with n = 4
Bits [3:0]: – –
Reserved

Confidential
31-May-2019
9.12 Unified Serial Link (USL)

1542 Unified Serial Link (USL, see Figure 85) is an optional CSI-2 feature that reduces the number of interface
1543 wires and helps to natively support longer reach.
1544 USL builds upon the benefits provided by the LRTE features (Section 9.11). USL alleviates the need to use
1545 any additional I2C, I3C, and/or SPI interconnect for the Camera Command Interface (CCI), or GPIO wires
1546 for camera module control signaling. This is accomplished by using CSI-2 encapsulation with the Bus Turn
1547 Around (BTA) capabilities of the natively supported C-PHY 2.0 (or beyond) and D-PHY v2.5 (or beyond)
1548 transport layer options.
1549 MIPI PHY bandwidths are many orders of magnitude greater than those provided by the I2C-compatible
1550 2-wire bi-directional control bus. Moreover, there are natural blanking intervals (i.e., idle cycles) between
1551 transferring horizontal rows (i.e., horizontal blanking), and between transferring frames (i.e., vertical
1552 blanking), that can be used to update the image sensor shadow registers.
1553 In this Section:
1554 • The term SNS refers to an image sensor, or an image sensor module comprising a CMOS image
1555 sensor plus additional complementary devices (i.e., non-imaging devices).
1556 • The term APP refers to an SoC application processor (AP) containing any combination of
1557 computer vision engine(s) and/or image processing unit(s), or to a host processor.
1558 The reverse link throughput from an APP to a SNS does not require high bandwidth, which substantially
1559 relaxes timing constraints and margins for receiver implementations on the SNS transceiver. Mapping all
1560 CSI-2 transactions via MIPI C-PHY/D-PHY can reduce the number of wires, support long reach, help secure
1561 channel implementations, and reduce engineering development costs.
Image Application
Sensor Unidirectional Transfer Processor
Using MIPI PHY
(High Bandwidth)
CSI-2 PHY CSI-2
PHY
TX TX RX
RX
Bi-Directional I2C Compatible 2-Wire Control & GPIO Wires

(Low Bandwidth)
Image Application
Sensor Bi-Directional Transfer Processor
Using MIPI PHY
(High Bandwidth)
CSI-2 PHY PHY CSI-2
TX TRX TRX RX
PPI
Interface
1562
Figure 85 USL System Diagram

Confidential
31-May-2019
9.12.1 USL Technical Overview

1563 Lane Usage: The vast majority of imaging applications using USL are expected to be mapped to a conduit
1564 with a single bi-directional lane (Lane 1). However, if a conduit requires multiple Lanes, then the first Lane
1565 (Lane 1) shall be bi-directional, and the remaining Lanes shall be uni-directional and configured as TX for
1566 image sensors. In multi-Lane conduits, all Lanes within a link are utilized for USL_FWD Mode operations,
1567 and only the first Lane (Lane 1) is utilized for USL_REV Mode operations. Transceiver functionality is
1568 always limited to one Lane (Lane 1). USL physical layer requirements are detailed in Section 7.3.
1569 USL Commands and Transactions: The 0x38 PH Data Type (see Table 10) and the CSI-2 Long Packet
1570 Format shall be used for USL command operations and transactions. A “USL packet” is any long packet with
1571 Data Type 0x38.
1572 Virtual Channels: In order to facilitate sensor aggregation on system platforms, the SNS shall support USL
1573 packets with Virtual Channel Identifiers ranging from 0 to 15 for D-PHY, and 0 to 31 for C-PHY. CSI-2
1574 Frame Start and Frame End short packets shall not be transmitted for any Virtual Channel Identifiers used
1575 exclusively in USL packets. Virtual Channel Identifiers used in USL packets are permitted to be used in CSI-2
1576 packets with Data Type codes other than 0x38 (i.e., non-USL packets). However, a pair of CSI-2 Frame Start
1577 and Frame End short packets is required to enclose all non-USL packets for each shared Virtual Channel
1578 Identifier within each image frame.

Confidential
31-May-2019
9.12.2 USL Command Payload Constructs

1579 All USL transport operations shall use the existing CSI-2 Long Packet (LgP) constructs. The encapsulated
1580 USL payload fields (Size_Bytes, Slave_Address, Sub_Address, Write_data, Read_data, USL_CTL, TSEQ)
1581 shall map LSB data to Bit0 (see Figure 3). All multi-byte USL payload fields shall be transmitted least
1582 significant byte first.
1583 USL Commands are used to map register Read/Write requests from the APP to the SNS, and read completions
1584 from the SNS to the APP, using the CSI-2 LgP. The LgP Packet Header Data Type field shall be set to the
1585 value 0x38 when an APP or SNS generates USL Command register R/W requests or completions,
1586 respectively. For all C-PHY or D-PHY high-speed (HS) Mode transmissions, the encapsulated R/W requests
1587 are mapped into the LgP Packet Data Field Application Specific Payload of USL packets, per Figure 52 for
1588 the D-PHY physical layer option, and per Figure 53 for the C-PHY physical layer option. The Long Packet
1589 Padding and Filler insertions shall be preserved for the C/D-PHYs as defined in Section 9.1.
1590 As described in Section 7.3, all USL implementations shall support PHY LP or LVLP Mode signaling, and
1591 should support ALP Mode signaling. USL systems are normally configured prior to power-up to support one
1592 of these signaling Modes under either D-PHY or C-PHY.
1593 If USL is configured to use C-PHY or D-PHY LP/LVLP Mode, then all USL packets transmitted using
1594 forward or reverse direction Escape Mode LPDT have the same format as USL packets transmitted using
1595 D-PHY HS Mode; each byte is also transmitted least significant bit first. The APP shall be capable of
1596 receiving USL packets both as HS Mode transmissions distributed over all active Lanes, and as Escape Mode
1597 LPDT Transmissions driven only over Lane 1.
1598 During USL_REV Mode, the SNS shall support buffering for a minimum of 32 register read requests (single
1599 and contiguous) from an APP. During USL_REV Mode, the SNS shall support a minimum of 64 register
1600 write requests (single and contiguous) with a minimum of 1024 bits of write data from an APP.
1601 If USL is configured to use C-PHY or D-PHY ALP Mode, then while in USL_REV Mode, the APP may
1602 concatenate multiple USL packets into a single HS burst transmission over Lane 1 using C-PHY EPD or
1603 D-PHY EPD Option 2, respectively, provided the applicable LRTE EPD features are supported (see
1604 Section 9.11). SNS HS Mode receiver LRTE capabilities may be understood from the SNS datasheet, or
1605 discovered in some other fashion. Similarly, while in USL_FWD Mode, the SNS may concatenate multiple
1606 USL and/or non-USL packets into a single HS burst transmission distributed over all active Lanes using one
1607 of the latter EPD alternatives.
1608 If USL is configured to use C-PHY or D-PHY LP/LVLP Mode, then while in USL_FWD Mode, the SNS
1609 may concatenate multiple USL and/or non-USL packets into a single HS burst transmission distributed over
1610 all active Lanes using any supported C-PHY or D-PHY LRTE EPD feature (including D-PHY EPD Option
1611 1). While in either USL_FWD or USL_REV Mode, LRTE D-PHY EPD Option 2 may be used to concatenate
1612 multiple USL packets transmitted using Escape Mode LPDT, but only with zero or more fixed length Spacers
1613 between packets and without the insertion of EoTp short packets. SNS Spacer generation for USL packets
1614 transmitted using LPDT may be controlled by the APP using the register in Table 18. SNS LP/LVLP Mode
1615 receiver LRTE capabilities may be understood from the SNS datasheet, or discovered in some other fashion.
1616 The existing LgP 16-bit Checksum shall be used to preserve transport integrity for all USL transitions. USL
1617 Command transactions do not require the legacy CCI “S” (Start), “P” (Stop), and “A” (Acks), because the
1618 LgP transport handles these functions.
1619 A 16-bit Size_Bytes field contains the number of sequential bytes of data to write or read. A Read_Data field
1620 contains the byte based read data.
1621 A Write_Data field contains the byte based write data.
1622 A 7-bit Slave_Address field contains the device address where the commands are to be send or to be received.
1623 For example, CCI (I2C) Slave Address e.g. 0x6C was used to communicate with an image sensor and
1624 similarly with USL the same e.g. 0x6C would apply. This field is transmitted as the most significant 7 bits of
1625 a byte whose LSB is analogous to the CCI R/W bit.

Confidential
31-May-2019
1626 A 16-bit Sub_Address field is used for pointing at a register inside the slave device. Product-specific imaging
1627 systems may use an 8-bit and/or 16-bit Sub_Address on an as-needed basis, since Sub_Address is device-
1628 specific and is known at platform level. Note that systems using a single USL link to communicate with
1629 multiple devices, e.g. via local I2C bus, may require using both 8-bit and 16-bit indexes, depending on the
1630 devices.
1631 An 8-bit USL Control (USL_CTL) (Table 19) is used to ensure transport integrity with guaranteed delivery
1632 of commands from the APP to the SNS using ACK, and to improve transport efficiency with support for
1633 contiguous R/W operations often used for imaging and vision firmware uploads from APP to SNS.
1634 A 16-bit Transaction Sequence (TSEQ) field contains a unique non-zero USL command identification
1635 number generated by the SNS and APP. The SNS and APP generate and clear the Transaction Sequence field
1636 upon successful reception of a USL Packet (as detailed in sections below).
1637 Table 18 Image Sensor LPDT LRTE Control Register
Register Name Type RW Comment
SNS_USL_LPDT_LRTE 8-bit RW Bit 7
unsigned 1: Enable image sensor LRTE for USL packets
integer transmitted using Escape Mode LPDT
Bits 6-0
If LRTE is enabled, specifies the fixed number of
Spacers inserted between all USL packets (0 to 127)

Confidential
31-May-2019
Table 19 USL Transport Control (USL_CTL) Bit Description
USL_CTL[7:0] Name Description Initiator

Bits [1:0] ACK_NAK_INT Values: SNS
Generation 2’b01: ACK generation.
SNS transmits the TSEQ of the last
successful reception an USL
command.
2’b10: NAK generation.
SNS transmits the TSEQ of the R/W
command resulting in an illegal or
invalid operation.
2’b00: Neither ACK nor NAK generation
(i.e., Read completions)
2’b11: In-band interrupt
Bit [2] Force Values: APP
Command 1’b0: The requested command from APP
shall not be executed by the SNS if a
prior command request was NAK’ed
during USL_REV_Mode.
1’b1: Force command operation even if a
prior command was NAK’ed during
USL_REV_mode.
Bit [3] Sequential Values: APP
R/W Enable 1’b1: USL command includes sequential
R/W request or response.
The requested size (in bytes) shall be
determined from Size_Bytes[15:0]
field.
1’b0: USL command includes single R/W
request or response.
Bit [4] Initiate BTA Values: APP during
1’b1: Command bit used to turn around the USL_REV Mode,
bus. SNS during
Generated by the Initiator. USL_FWD Mode
1’b0: NOP
Bits [7:5] Reserved for Reserved for future use –
future use
1638 Note:
1639 The USL_CTL[7:5] bits are reserved for future expansion.

Confidential
31-May-2019
9.12.3 USL Operation Procedures

1640 For simplification, the following examples show:
1641 • A 16-bit Sub_Address[15:0]
1642 • A 16-bit Transaction Sequence (TSEQ) containing a unique non-zero USL command identification
1643 number generated by the APP
9.12.3.1 APP Initiated USL Transactions

1644 This example procedure illustrates the APP initiating four valid USL Command transactions (USL_REV
1645 Mode).
1646 1. ACK Generation
1647 TSEQ is used by the system to ensure guaranteed delivery of USL commands. An APP shall
1648 include a 16-bit register to store the last successful TSEQ received from the SNS during
1649 USL_FWD Mode. Upon entering USL_REV Mode, the APP shall generate ACK twice
1650 immediately using the following format:
1651 • LgP Packet Header Data ID = 0x38
1652 • LgP Packet Data format for ACK generation:
1653 {USL_CTL[7:0], TSEQ[15:0]}
1654 2. Register Write Request with Write Data
1656 • LgP Packet Data format for all writes:
1657 {USL_CTL[7:0], TSEQ[15:0], Size_Bytes[15:0],
1658 Slave_Address[7:1],[W=0],
1659 Sub_Address[15:0],
1660 Write_Data [16’d Size_Bytes-1:0]}
1661 3. Register Read Request
1663 • LgP Packet Data format for all read requests:
1665 Slave_Address[7:1],[R=1],
1666 Sub_Address[15:0]}
1667 4. Initiate BTA
1668 Upon completing the R/W register commands, the APP shall generate the Initiate BTA packet
1669 twice to switch the link from USL_REV to USL_FWD mode.
1670 The Initiate BTA bit in the USL_CTL shall be set to 1’b1.
1672 • LgP Packet Data format for initializing BTA, and switch from USL_REV to USL_FWD:
1673 {USL_CTL[7:0], TSEQ[15:0]}

Confidential
31-May-2019
9.12.3.2 SNS Initiated USL Transactions

1674 This example procedure illustrates the SNS initiating five valid USL Command transactions (USL_FWD
1675 Mode).
1676 1. NAK Generation
1677 If an Image Sensor (SNS) receives an invalid or an illegal USL Command request from the
1678 Application Processor (APP), then the SNS shall generate a Negative Acknowledgement (NAK).
1679 By default, the SNS shall not execute any following R/W USL command requests from the APP
1680 after a NAK during an USL_REV_Mode, unless the USL_CTL Force Command bit is enabled by
1681 the APP. The SNS shall generate negative acknowledgement (NAK) for the first illegal or failed
1682 R/W request from an APP. The SNS may optionally generate additional NAKs resulting from
1683 “Force Command” requests. The NAK shall be transmitted twice to the APP immediately upon
1684 switching to USL_FWD_Mode using the following format:
1686 • LgP Packet Data format for NAK generation:
1687 {USL_CTL[7:0], TSEQ[15:0]}
1688 2. ACK Generation
1689 TSEQ is used by the product imaging system to ensure guaranteed delivery of R/W commands
1690 from APP to SNS. An Image Sensor shall include a 16-bit register to store the last successful
1691 TSEQ received from the APP during USL_REV Mode. Upon entering USL_FWD Mode, the SNS
1692 shall generate ACK twice immediately following any NAK generation(s) using the following
1693 format:
1695 • LgP Packet Data format for ACK generation:
1696 {USL_CTL[7:0], TSEQ[15:0]}
1697 3. Register Read Completion
1699 • LgP Packet Data format for all read completions:
1701 Read_Data [16’d Size_Bytes-1:0]}
1702 4. Interrupt Generation
1703 Upon completing ACK/NAK generations, the SNS may generate in-band interrupt using
1704 USL_CTL[1:0] in the USL_FWD mode. It is strongly recommended for the SNS to prioritize and
1705 generate the interrupt notification at the earliest opportunity.
1706 The following format shall be used to also include optional information pertaining to the interrupt:
1708 • LgP Packet Data format for In-Band Interrupt generation:
1709 {USL_CTL[7:0], Slave_Address[15:0], Interrupt_Information[15:0]}
1710 5. Initiate BTA
1711 The SNS shall generate the Initiate BTA packet twice prior to switching the link from USL_FWD
1712 to USL_REV mode. The Initiate BTA bit in the USL_CTL shall be set to 1’b1. The TSEQ shall be
1713 the 16-bit value from REG_USL_ACK_TSEQ.
1715 • LgP Packet Data format for initializing BTA, and switch from USL_REV to USL_FWD:
1716 {USL_CTL[7:0], TSEQ[15:0]}

Confidential
31-May-2019
9.12.4 Monitoring USL Command Transport Integrity

1717 This section presents a stepwise procedure for monitoring the integrity of the USL Command Transport,
1718 using TSEQ and the two SNS registers defined in Table 20.
1719 1. [System Reset] [Power Cycle]
1720 • The SNS shall reset registers REG_USL_ACK_TSEQ[15:0] and REG_USL_NAK_TSEQ[15:0]
1721 to the value 16’d0. The APP shall reset internal register APP_REG_USL_ACK_TSEQ[15:0].
1722 2. [USL_REV Mode]
1723 • Upon entering USL_FWD Mode, APP shall generate ACK twice using the 16-bit TSEQ from
1724 internal register APP_REG_USL_ACK_TSEQ[15:0].
1725 • The APP shall generate a 16-bit, non-zero TSEQ value that increments with each USL
1726 Command R/W request it sends to the SNS.
1727 • The SNS shall store the TSEQ of the last successful USL command into register
1728 REG_USL_TSEQ_ACK[15:0].
1729 • The SNS shall store the TSEQ of the first illegal USL command into register
1730 REG_USL_TSEQ_NAK[15:0].
1731 3. [USL_REV Mode Exit]
1732 • The APP shall reset internal register APP_REG_USL_ACK_TSEQ[15:0] to the value 16’d0.
1733 4. [USL_FWD Mode]
1734 • Upon entering USL_FWD Mode, if any illegal operation was encountered in the prior
1735 USL_REV Mode, the SNS shall generate NAK twice using the 16-bit TSEQ from register
1736 REG_USL_TSEQ_NAK[15:0].
1737 • Next, the SNS shall generate ACK twice using the 16-bit TSEQ from register
1738 REG_USL_TSEQ_ACK[15:0].
1739 • An ACK with TSEQ value of 16’d0 shall be generated by the SNS if no USL commands were
1740 successfully received from the APP during USL_REV Mode.
1741 Note:
1742 SNS shall reset the internal state(s) used to block execution of subsequent command
1743 operations after a NAK.
1744 5. [USL_FWD Mode Exit]
1745 The SNS shall reset registers REG_USL_ACK_TSEQ[15:0] and REG_USL_NAK_TSEQ[15:0]
1746 to the value 16’d0.
1747 Table 20 USL Transport Integrity ACK and NAK Registers with TSEQ
SNS USL Transport Integrity Registers Description
REG_USL_ACK_TSEQ[15:0] Required. Write / Read.
See Above.
REG_USL_NAK_TSEQ[15:0] Required. Write / Read.
See Above.

Confidential
31-May-2019
9.12.5 USL Powerup / Reset, SNS Configuration, and Mode Switching

1748 This section details the various stages of USL operations. Note that the current TX shall always initiate the
1749 BTA when switching USL modes.
9.12.5.1 USL Link Modes

1750 The USL link is in USL Reverse Mode (USL_REV) when:
1751 • SNS is configured as RX
1752 • APP is configured as TX
1753 • The channel is established to transfer payloads from APP to SNS
1754 The USL link is in USL Forward Mode (USL_FWD) when:
1755 • SNS is configured as TX
1756 • APP is configured as RX
1757 • The channel is established to transfer payloads from SNS to APP
9.12.5.2 USL Power-up / Reset

1758 The link comes up in USL_FWD Mode after power-up or reset:
1759 • The SNS shall initially configure each PHY Lane (including clock Lane, if present) as a
1760 transmitter (TX).
1761 • The APP shall initially configure each PHY Lane (including clock Lane, if present) as a receiver
1762 (RX).
1763 • The SNS and APP shall then initialize their Lane 1 PHYs following the appropriate PHY-defined
1764 procedure; all other Lanes are unidirectional and should remain uninitialized until needed.
1765 • If USL is configured to use D-PHY ALP Mode, then the clock Lane shall also be initialized and
1766 started following its initialization in order to facilitate ALP Mode fast BTA and high-speed
1767 bidirectional data transfers over data Lane 1; see Section 9.12.5.6 for additional guidance.
1768 • If USL is configured to use D-PHY LP/LVLP Mode, then initialization and start-up of the clock
1769 Lane may be delayed until the SNS is first required to transmit packets to the APP using HS Mode.
1770 Note that in this case, all USL packet transmissions from the APP to the SNS over data Lane 1 use
1771 Escape Mode LPDT and don’t require the clock Lane to be running.
1772 • Once the SNS has completed internal power-up / reset calibration, the SNS shall initiate BTA on
1773 Lane 1 using the steps outlined in Section 9.12.3.2. The SNS may optionally send the contents of
1774 TX_USL_SNS_BTA_ACK_TIMEOUT[15:0] using the read completion format from
1775 Section 9.12.3.2 prior to initiating BTA.
1776 • Upon completion of the BTA, the link is configured as USL_REV Mode to enable the APP to
1777 configure the SNS using Lane 1.
1778 • During SNS configuration, the APP may select the total number of active Lanes in order to enable
1779 the correct number of unidirectional Lanes to be initialized and put into service when image
1780 streaming is started.

Confidential
31-May-2019
9.12.5.3 USL SNS Configuration

1781 The APP may configure the SNS when the link is in USL_REV Mode using steps outlined in
1782 Section 9.12.3.1.
1783 • Once the APP has completed one or more SNS configuration operations, the APP shall initiate
1784 BTA using steps outlined in Section 9.12.3.1.
1785 • Upon completion of the BTA, the link is configured as USL_FWD Mode.
9.12.5.4 USL Mode Switching SNS Configuration

1786 Upon entering USL_FWD Mode, the SNS generates the USL NAK (if needed) followed by the USL ACK
1787 using the steps outlined in Section 9.12.3.1. The SNS generates the USL read completions as the content
1788 becomes available, and may be interleaved with non-USL payloads during USL_FWD Mode.
1789 The SNS shall support the two 16-bit USL BTA Switch registers defined in Table 21 and Table 22. The APP
1790 shall configure these registers during USL_REV Mode.
1791 The USL BTA switch may be initiated during vertical blanking for traditional photography and video
1792 applications, or after predefined LgPs (intra-frame) for more advanced vision applications. CSI-2 Imaging
1793 and Vision systems will require fast BTA durations mapped to the PHYs. Figure 86 illustrates the USL_REV
1794 and USL_FWD State Diagram for both the APP and the SNS.
1795 When a system is powered up, the SNS is configured as an RX (receiver) and the APP is configured as a TX
1796 (transmitter). Five USL modes are allowed for imaging applications, along with the transition arcs as defined
1797 in Figure 86.
1798 A USL SNS shall support the 16-bit Operational Register shown in Table 25.
1799 A USL SNS shall support one or more 16-bit GPIO Registers, per Table 26.

Confidential
31-May-2019
1800 Table 21 USL BTA Switch Registers

SNS USL BTA Registers Description
TX_USL_REV_ENTRY [15:0] Required. Write / Read.
Enable USL_REV Mode Entry after the specified number
of non-USL LgPs, non-USL Frames, or PPI Word/Byte
clocks.
Bit [15:10]: Bit[15]: Increment Clock Counter using PPI Word/Byte clock in
Select Mode Clock Counter USL_FWD Mode.
Switch Switch to USL_REV mode when Clock Counter expires.
Triggers Reinitialize the Clock Counter when exiting USL_FWD
mode.
Bit[14]: Increment LgP Counter using non-USL LgPs in USL_FWD
LgP Counter Mode.
Switch to USL_REV mode when LgP Counter expires.
Reinitialize the LgP Counter when exiting USL_FWD
mode.
Bit[13]: Increment Frame Counter using non-USL FEs in
Frame Counter USL_FWD Mode.
Switch to USL_REV mode when Frame Counter expires.
Reinitialize the Frame Counter and LgP Counter when
exiting the USL_FWD mode.
Bit[12]: The Chronological (duration in µs) Timer is initiated with
Chronological Timer the first non-USL transmission in USL_FWD mode.
Switch to USL_REV mode once Chronological Duration
timer expires and any inflight packet has completed
transmission.
Reinitialize the timer when exiting USL_FWD mode.
Bit[11]: Enable SNS to switch to REV_MODE immediately after
Configure SNS the USL transmissions are completed (i.e., read
completion, ACK, NAK).
Non-USL (pixel data) transmissions are not allowed during
the USL_FWD Mode.
Bit[10]: Enable SNS to switch to REV_MODE autonomously
Smart SNS based on smart features. Smart SNS capability is optional
for the SNS.
Bit[9-0]: Reserved for future use
TX_USL_Clock Counter Required. Write / Read.
[15:0] Counter used to trigger SNS switch from USL_FWD Mode
to USL_REV Mode.
TX_USL_LGP Counter Required. Write / Read.
to USL_REV Mode.
TX_USL_Frame Counter Required. Write / Read.
to USL_REV Mode.
TX_USL_Chronological Timer Required. Write / Read.
to USL_REV Mode.

Confidential
31-May-2019
1801 Table 22 Register TX_USL_REV_FWD_ENTRY

SNS USL BTA Register Description
TX_USL_FWD_ENTRY [15:0] Required. Write / Read.
Enable USL_FWD Mode Entry after the
specified number of PPI Word/Byte
clocks.
Bit [15]: Value 1’b0: USL_REV Mode:
FWD_Switch_En Disable Upon completing the R/W requests,
Value 1’b1: the APP shall initiate switching to
Initiate switch to USL_FWD Mode USL_FWD mode by writing 1’b1 to
once the REV_MODE PPI Word / FWD_Switch_En
Byte clock counts match USL_FWD Mode or SNS Reset:
FWD_Counter [14:0] The SNS shall reset FWD Switch_En
bit by writing 1’b0.
Bits [14:0]: Value 15’d0: USL_REV Mode:
FWD_Counter Initiate switch to USL_FWD mode Increment FWD_Counter using the
immediately after APP writes 1’b1 to USL_REV PPI Byte / Word clock
FWD_Switch_En. when APP writes 1’b1 to USL_FWD
… Switch_En.
Value 15’d7: USL_FWD Mode or SNS Reset:
Increment FWD_Counter using The SNS may optionally reset the
USL_REV Mode PPI Word / Byte FWD_Counter by writing 15’d0.
clock when APP writes 1’b1 to
USL_FWD Switch_En.
Initiate switch to USL_FWD mode
when FWD_Counter[14:0] = 15’d7.
…
Value 15’d32767:
Increment FWD_Counter using
USL_REV Mode PPI Word / Byte
clock when APP writes 1’b1 to
USL_FWD Switch_En.
Initiate switch to USL_FWD mode
when FWD_Counter[14:0] =
15’d32767.
1802

Confidential
31-May-2019
9.12.5.5 ALP Fast BTA Timeout Support

1803 Since the target device PHY does not provide an acknowledgement electrical signaling upon receiving an
1804 “Initiate BTA” USL command request from an initiator, the following SNS timeout registers are utilized by
1805 the APP to alleviate potential deadlocks.
1806 Table 23 Register TX_USL_SNS_BTA_ACK_TIMEOUT[15:0]
TX_USL_SNS_BTA_ACK_TIMEOUT[15:0] Required.
Read Only.
Maximum time (in ns) required by SNS to

send ACK in the USL_FWD Mode upon SNS
receiving “Initiate BTA” USL command from
APP in USL_REV Mode.
Value of 16’d0 implies the timeout is disabled.
Value of 16’d500 implies the SNS shall send

ACK in the USL_FWD Mode within 500 ns
upon reception of “Initiate BTA” USL
command from APP in USL_REV Mode.
Table 24 Register TX_USL_APP_BTA_ACK_TIMEOUT[15:0]

TX_USL_APP_BTA_ACK_TIMEOUT[15:0] Required.
Write Only.
Maximum time (in ns) required by APP to

send ACK in the USL_REV Mode upon APP
receiving “Initiate BTA” USL command from
SNS in USL_FWD Mode.
Value of 16’d0 implies the timeout is disabled.
Value of 16’d500 implies the APP shall send

ACK in the USL_REV Mode within 500 ns
upon reception of “Initiate BTA” USL
command from SNS in USL_FWD Mode.

Confidential
31-May-2019
USL_REV Mode (PARK) USL_REV Mode (Exit PARK)

PARK
APP_TX SNS APP_TX
BTA
SIGNALING
ALP ●●● ALP
BTA
SIGNALING
●●●
SNS_RX SNS_RX
USL_FWD Mode USL_REV Mode

RESET APP_RX APP_TX
BTA
SIGNALING
SNS transmits packets to APP
BTA
SIGNALING
APP transmits packets to SNS
BTA
SIGNALING
●●●
SNS_TX SNS_RX
USL_FWD Mode (PARK) USL_FWD Mode (Exit PARK)

APP_RX APP_RX
BTA
SIGNALING
ALP ●●● ALP
BTA
SIGNALING
●●●
SNS_TX SNS_TX
PARK
SNS
1807
Figure 86 USL Modes Link Transitions

Confidential
31-May-2019
1808 Table 25 USL Operation Registers

SNS USL Operational Register Description
TX_USL_Operation [15:0] Required. Write / Read.
General purpose register
mapped SNS operations
Bit [0]: SNS Reset Values: In-band register mapped SNS
1’b0: NOP reset
1’b1: Reset SNS
Bit [15:1]: Reserved Reserved Reserved for future use
1809 Table 26 USL GPIO Registers

Bit [15:0]: SNS USL GPIO Register0 Description
TX_USL_GPIO [15:0] Required. Write / Read.
General purpose register
mapped GPIO operations
Bit [0]: GPIO_0 Values: In-band register mapped
Configuration 1’b0: Low GPIO_0 configuration
1’b1: High
…
1’b1: High
…
1’b1: High

Confidential
31-May-2019
9.12.5.6 USL Clock Lane Management Under D-PHY ALP Mode (Informative)
1810 When USL is configured to use D-PHY ALP Mode as described in [MIPI01], a running high-speed clock
1811 Lane is required for any active data communications between SNS and APP. Such communications include
1812 the usual forward-direction SNS pixel streaming, as well as any bidirectional transactions on data Lane 1
1813 related to USL packet transmissions (with DT code 0x38), or any low-level PHY fast BTA or ULPS entry
1814 commands initiated by either the SNS or APP. When USL is configured to use D-PHY LP or LVLP Mode,
1815 the clock Lane is only required to be running during SNS pixel streaming.
9.12.5.6.1 System Power-Up and/or Reset (Informative)

1816 Following SNS ALP Mode TX and RX PHY initialization, the SNS will start up the clock Lane at some
1817 initial, implementation-dependent frequency prior to switching to USL_REV mode. For example, it may be
1818 advantageous to set this frequency equal to the SNS external reference clock frequency (or a submultiple
1819 thereof) since this avoids the need to start and lock a PLL, potentially saving hundreds of microseconds of
1820 start-up latency. Care must be taken to ensure that the selected clock Lane frequency is at least twice the
1821 minimum bit rate required by the D-PHY specification, since the D-PHY high-speed reverse-direction data
1822 transmissions used by USL occur at one-fourth the bit rate of forward-direction data transmissions. For
1823 example, a 2 MHz clock Lane frequency corresponds to a forward-direction bit rate of 4 Mbps and a reverse-
1824 direction bit rate of 1 Mbps.
1825 Once the clock Lane is running, the SNS can use the USL protocol to switch to USL_REV mode in order to
1826 enable the APP to configure SNS CCI registers as needed, including the PLL control registers used for setting
1827 the clock Lane frequency required for image streaming. The last action taken by the APP will be to request
1828 the start of image streaming by writing to the appropriate CCI control register and then switching to
1829 USL_FWD mode; the SNS, in response, will stop the clock Lane, lock all PLLs to their configured
1830 frequencies, restart the clock Lane, and only then actually start image streaming.

Confidential
31-May-2019
9.12.5.6.2 Dynamic Clock Control (Informative)

1831 As with legacy CSI-2 non-continuous clock mode, USL permits the clock Lane to be stopped during periods
1832 in which the system application either doesn’t support or doesn’t immediately anticipate data
1833 communications between SNS and APP.
1834 Examples of such periods include:
1835 • One or more of the “horizontal line blanking” (hblank) periods between image lines during image
1836 streaming (assuming such periods are sufficiently long enough to include the timing overhead
1837 entailed in stopping and then restarting the clock).
1838 • All or part of the “vertical frame blanking” (vblank) period between image frames during image
1839 streaming.
1840 • “Hard standby” periods during which image sensor power consumption is at a minimum and no
1841 CCI register accesses are possible. Hard standby entry and exit is typically controlled using a
1842 separate control signal (e.g., the XSHUTDOWN signal defined in [MIPI04]).
1843 • All or part of “soft standby” periods during which image streaming is temporarily halted to enable
1844 the APP to reconfigure CCI registers concerning fundamental SNS operating characteristics, such
1845 as output image resolution, pixel depth, frame rate, bit rate, active Lane count, etc.
1846 Stopping and restarting the clock Lane may be performed by the SNS either automatically following
1847 conventions understood in advance by the APP, or in response to the APP triggering the SNS in an ad hoc
1848 manner. For example, when the clock Lane is running during USL_REV mode, the APP may command the
1849 SNS to stop the clock by writing to a special CCI control register on the SNS. Conversely, when the clock
1850 Lane is stopped during USL_REV mode (meaning no CCI register accesses are possible), the APP may
1851 request the SNS to restart the clock by transmitting a short D-PHY ALP Mode PHY-to-PHY Wake pulse to
1852 the SNS (as described in [MIPI01]).
1853 Note that changing the clock Lane frequency requires the SNS to stop the clock Lane, internally adjust the
1854 frequency (which may involve relocking a PLL), and then restart the clock Lane in accordance with the
1855 D-PHY specification. Needless to say, the latter actions can be collectively time consuming and are best
1856 avoided when switching from USL_FWD mode to USL_REV mode and then back again during relatively
1857 short time periods such as hblank. In other words, if the APP needs to access SNS CCI registers during
1858 hblank, then the ideal situation is one in which both the SNS and APP can support reverse-direction
1859 transmissions at one-fourth of the full bit rate used for streaming pixel data packets, thereby avoiding the
1860 need to change the clock Lane frequency twice during hblank.

Confidential
31-May-2019
1861 Figure 87 illustrates examples of USL ALP Mode clock Lane management during the image streaming
1862 vblank period. Beginning at time “A” in the figure, the SNS automatically keeps the clock Lane running after
1863 transmitting the CSI-2 Frame End short packet and uses the USL protocol to enter USL_REV mode in order
1864 to enable the APP to start accessing SNS CCI registers. At this point, the APP may also wish to start an
1865 internal timer to warn it when the vblank period is about to end. At time “B”, when the APP is at least
1866 temporarily finished with CCI register accesses, the last access it performs is a write to the
1867 TX_USL_ALP_CTRL register (Table 27), for example, which commands the SNS to turn-off the clock Lane
1868 but also to expect a request to restart it at a later time. USL_REV mode is then maintained (with all D-PHY
1869 clock and data Lanes in the Stop state) until time “C” when the APP requests the clock Lane to be restarted
1870 by transmitting a short ALP Mode PHY-to-PHY Wake pulse to the SNS. In response, the SNS restarts the
1871 clock Lane and keeps it running while the APP performs more CCI accesses as needed. When finished at
1872 time “D”, the APP finally switches back to USL_FWD mode prior to the SNS having to transmit the Frame
1873 Start short packet at the beginning of the next image frame.
Frame Blanking
FS Zero or more lines of embedded data
Packet Header, PH
Packet Footer, PF
Line Blanking Frame of Arbitrary Pixel and/or User-

hblank
Defined Byte-Based Data
Zero or more lines of embedded data
FE A
Clock Running
vblank
Frame Blanking
C
Clock Running
D FS
Next Frame
PH
PF
hblank
KEY:
PH – Packet Header PF – Packet Footer
1874 FS – Frame Start FE – Frame End
Figure 87 Examples of USL ALP Mode Clock Lane Management During Sensor Vblank
Table 27 USL Clock Lane Control Register
Register Name Type RW Comment
TX_USL_ALP_CTRL 16-bit RW Bit 0

unsigned 1: Shall trigger image sensor to pause the
integer D-PHY clock Lane during ALP mode. The image
sensor shall auto-clear the register after stopping
the clock.
Other bits
Reserved for future use

Confidential
31-May-2019
9.12.5.7 USL Hard Standby Mode (Informative)

1875 USL hard standby entry and exit may be controlled in essentially the same manner as with legacy non-USL
1876 image sensors. During hard standby mode, all Lanes (including the clock Lane, if applicable) are typically in
1877 the forward-direction ULPS state, and the APP cannot access any SNS CCI registers.
1878 SNS entry into hard standby is usually triggered by a hardware input signal (e.g., XSHUTDOWN) which
1879 may be asserted asynchronously with respect to image streaming. Each Lane transitions to the forward-
1880 direction ULPS state more-or-less immediately; i.e., any in-progress image streaming simply terminates and
1881 no PHY ULPS entry command is transmitted. However, the APP normally puts the SNS into soft standby
1882 mode beforehand in order to cleanly stop image streaming and put the interface into the Stop state or ULPS.
1883 Lane 1 on both the SNS and APP should also be automatically switched to the forward direction when hard
1884 standby is triggered.
1885 Exit from hard standby is triggered by the de-assertion of the same hardware input (e.g., XSHUTDOWN)
1886 used to trigger hard standby entry, causing each Lane to transition to the Stop state in accordance with
1887 applicable PHY initialization procedures in [MIPI01] and [MIPI02].

Confidential
31-May-2019
9.12.5.8 USL Soft Standby Mode and ULPS Entry/Exit (Informative)

1888 Similar to legacy non-USL image sensors, USL supports SNS entry into soft standby mode by the APP
1889 writing to a CCI control register causing image streaming to be halted in an orderly manner. For USL, this
1890 CCI write operation must occur while in USL_REV mode during an hblank or vblank period. The APP then
1891 uses the USL protocol to switch back to USL_FWD mode, in order to enable the SNS to output all or part of
1892 the image frame that was in progress at the moment the control register was written, ending with all data
1893 Lanes in the Stop state (and the clock Lane still running in the D-PHY ALP Mode case). The SNS then
1894 switches to USL_REV mode to enable the APP to issue further commands to the SNS.
1895 Once streaming is halted, the APP can choose different courses of action. For example, if performing a time-
1896 critical SNS mode change, the APP can then immediately update the required SNS CCI registers, concluding
1897 the process by writing to a CCI control register that requests the restart of image streaming, and then
1898 switching back to USL_FWD mode using the USL protocol. Once returned to USL_FWD mode, and prior
1899 to actually restarting image streaming, the SNS may have to disable, reconfigure, and relock one or more
1900 internal PLLs, possibly requiring the SNS to automatically stop and restart the clock Lane, if applicable.
1901 Another possible course of action is for the APP to put the SNS into an extended sleep state while awaiting
1902 further commands from the APP. The preferred method for accomplishing this is for the APP to first transmit
1903 a PHY ULPS entry command to the SNS on Lane 1 followed by the SNS, in turn, transmitting the PHY
1904 ULPS entry command to the APP on all forward-direction data Lanes. This method is preferred because Lane
1905 1 remains in USL_REV mode throughout ULPS, thereby enabling the APP to subsequently transmit ULPS
1906 wakeup signaling to the SNS over Lane 1 when needed; this is also the reason why “reverse direction ULPS”
1907 support is recommended for both D-PHY and C-PHY Lane 1 in Section 7.3. With D-PHY ALP Mode, the
1908 SNS then stops the clock Lane and puts it into ULPS after all data Lanes have been put into ULPS. At this
1909 point, the SNS can internally power-down unnecessary circuitry while still retaining internal register states
1910 and remaining in USL_REV mode.
1911 For D-PHY ALP mode, ULPS wakeup while in soft standby mode requires the APP to transmit a long ALP
1912 Wake pulse to the SNS as described in [MIPI01]. Once the SNS starts receiving the latter pulse on data Lane
1913 1 (as signaled by the PPI, for example), it can then start transmitting a long ALP Wake pulse to the APP on
1914 each unidirectional data Lane, resulting in a total round-trip wakeup latency which is about the same as the
1915 latency in either the forward or reverse direction. The SNS also wakes-up the clock Lane to the Stop state
1916 and then restarts it in order to enable the APP to access SNS CCI registers.
1917 For C-PHY ALP mode, ULPS wakeup while in soft standby mode requires the APP to transmit an extended
1918 ALP-Pause Wake wire state to the SNS followed by an ALP “Stop” command as described in [MIPI02]. At
1919 this point, the SNS can similarly signal ULPS wakeup on each unidirectional Lane. However, this results in
1920 a total round-trip wakeup latency which is about the twice the latency in either the forward or reverse
1921 direction. The impact of this can be reduced or eliminated by the APP performing more transactions (e.g.,
1922 CCI register accesses) using Lane 1 while wakeup is in-progress on the other Lanes, effectively hiding the
1923 additional latency. Another possible solution is put either C-PHY Lane 1 or all the other Lanes into ULPS,
1924 but not both. For example, the APP could request ULPS by writing to a CCI control register using Lane 1;
1925 the SNS would then put all unidirectional Lanes into ULPS while leaving Lane 1 in the Stop state. Conversely,
1926 the APP could request ULPS by putting only Lane 1 into ULPS, with the SNS leaving all unidirectional Lanes
1927 in the Stop state.

Confidential
31-May-2019
9.13 Data Scrambling

1928 The purpose of Data Scrambling is to mitigate the effects of EMI and RF self-interference by spreading the
1929 information transmission energy of the Link over a possibly large frequency band, using a data randomization
1930 technique. The scrambling feature described in this Section is optional and normative: If a CSI-2
1931 implementation includes support for scrambling, then the scrambling feature shall be implemented as
1932 described in this Section. The benefits of data scrambling are well-known, and it is strongly recommended
1933 to implement this data scrambling capability in order to minimize radiated emissions in the system.
1934 Data Scrambling shall be applied on a per-Lane basis, as illustrated in Figure 88. Each output of the Lane
1935 Distribution Function shall be individually scrambled by a separate scrambling function dedicated to that
1936 Lane, before the Lane data is sent to the PHY function over the Tx PPI.
Per-Lane Scrambling Tx Rx
Tx PPI Rx PPI
Byte/Word Byte/Word Lane 1 PHY De- Byte/Word
Scrambling
Stream Stream (TxàChanàRx) Scrambling Stream
Lane Merge Function

Scrambling
CSI-2
Stream Stream (TxàChanàRx) Scrambling Stream CSI-2
Byte Stream
Protocol Tx De- Protocol Rx
Byte/Word Byte/Word Lane 3 PHY Byte/Word
Scrambling

Scrambling
1937
Figure 88 System Diagram Showing Per-Lane Scrambling

Confidential
31-May-2019
9.13.1 CSI-2 Scrambling for D-PHY

1938 Figure 89 shows the format of a burst transmission of two packets over two Lanes when the D-PHY physical
1939 layer is used. After the Start of Transmission, HS-ZERO and HS-SYNC are transmitted, the Packet Header
1940 and data payload are distributed across the two Lanes.
1941 If the D-PHY physical layer is used, then the scrambler Linear Feedback Shift Register (LFSR) in each Lane
1942 shall be initialized with the Lane seed value under any of the following conditions:
1943 1. At the beginning of the burst, which occurs immediately prior to the first byte transmitted
1944 following the HS-Sync that is generated by the D-PHY (applicable to both D-PHY EPD Option1
1945 and Option 2).
1946 2. Prior to the first byte transmitted following the HS-Sync that is generated whenever the optional
1947 D-PHY EPD Option 1 HS-Idle is transmitted.
1948 The scrambler is not reinitialized between CSI-2 packets when using the optional D-PHY EPD Option 2.
1949 When the scrambler is initialized, the LFSR shall be initialized using the sixteen-bit seed value assigned to
1950 each Lane.
Scrambled, Packet #1 Header & Data Scrambled, Packet #2 Header & Data
Lane 1 HS
HS-ZERO Sync P1H P1H P1 P1 P1 P1 P1 P1 P1 HS-Idle- HS-Idle HS-Idle- HS P2H P2H P2 P2 P2 P2 P2 P2 P2
B0 B2 B0 B2 B4 B6 B8 Bn-4 Bn-2
Post Pre Sync B0 B2 B0 B2 B4 B6 B8 Bn-4 Bn-2 HS-TRAIL
TxWordValidHS[0]
TxHSIdleClkHS
Lane 2 HS
HS-ZERO Sync P1H P1H P1 P1 P1 P1 P1 P1 P1 HS-Idle- HS-Idle HS-Idle- HS P2H P2H P2 P2 P2 P2 P2 P2 P2
B1 B3 B1 B3 B5 B7 B9 Bn-3 Bn-1
Post Pre Sync B1 B3 B1 B3 B5 B7 B9 Bn-3 Bn-1 HS-TRAIL
TxWordValidHS[0]
TxHSIdleClkHS
Re-initialize the
Scrambler PRBS
1951 Note: The Packet Footer at the end of every packet is scrambled.
Figure 89 Example of Data Bursts in Two Lanes Using the D-PHY Physical Layer

Confidential
31-May-2019
9.13.2 CSI-2 Scrambling for C-PHY

1952 Figure 90 shows the format of a burst transmission of two packets over two Lanes when the C-PHY physical
1953 layer is used. After the Start of Transmission, Preamble, and Sync are transmitted, the Packet Header is
1954 replicated twice on each Lane, and data payloads of each packet are distributed across the two Lanes. If the
1955 C-PHY physical layer is used, then the scrambler LFSR in each Lane shall be initialized at the beginning of
1956 every Long Packet Header or Short Packet, using one of the sixteen-bit seed values assigned to each Lane.
1957 This initialization takes place each time the Sync Word is transmitted.
Packet #1 Header Packet #2 Header

Scrambled Scrambled, Packet #1 Header & Data Scrambled Scrambled, Packet #2 Header & Data
Lane 1 Preamble Sync P1H P1H P1H Sync P1H P1H P1H B0 B4 B8 Bn-8 Bn-4
Sync P2H P2H P2H Sync P2H P2H P2H B0 B4 B8
Bn-8 Bn-4
W0 W1 W2 W0 W1 W2 B1 B5 B9 Bn-7 Bn-3 W0 W1 W2 W0 W1 W2 B1 B5 B9 Bn-7 Bn-3 Post
TxSendSyncHS[0]
TxSyncTypeHS0[2:0] ST ST ST
TxWordValidHS[0]
Lane 2 Preamble Sync P1H P1H P1H Sync P1H P1H P1H B2 B6 B10 Bn-6 Bn-2
Sync P2H P2H P2H Sync P2H P2H P2H B2 B6 B10
Bn-6 Bn-2
W0 W1 W2 W0 W1 W2 B3 B7 B11 Bn-5 Bn-1 W0 W1 W2 W0 W1 W2 B3 B7 B11 Bn-5 Bn-1 Post
TxSendSyncHS[0]
TxSyncTypeHS0[2:0] ST ST ST
TxWordValidHS[0]
Re-initialize the
Scrambler PRBS
~TxWordValidHS[0] | TxSendSyncHS[0]
Note: The Packet Footer at the end of every packet is scrambled.
1958
Figure 90 Example of Data Bursts in Two Lanes Using the C-PHY Physical Layer
1959 In some cases, images may cause repetitive transmission of Long Packets having the same or similar Long
1960 Packet Header and the same pixel data (for example: all dark pixels, or all white pixels). If the scrambler is
1961 initialized with the same seed value at the beginning of every packet, coinciding with the beginning of every
1962 pixel row, then the scrambled pseudo-random sequence will repeat at the rate that rows of identical image
1963 data are transmitted. This can cause the emissions to be less random, and instead have peaks at frequencies
1964 equivalent to the rate at which the image data rows are transmitted.
1965 To mitigate this issue, a different seed value is selected by the transmitter every time a Packet Header is
1966 transmitted. The Sync Word in the Packet Header encodes a small amount of data, so that the transmitter can
1967 inform the receiver which starting seed to use to descramble the packet. This small amount of data in the
1968 Sync Word is sent by transmitting a Sync Type that the CSI-2 protocol transmitter chooses. This Sync Type
1969 value is also used to select the starting seed in the scrambler and descrambler.

Confidential
31-May-2019
1970 Table 28 shows the five possible Sync Types that the C-PHY supports. The Sync Word values are normatively
1971 specified in the C-PHY Specification and duplicated in Table 28 for convenience. The CSI-2 protocol uses
1972 only the first four out of the five possible Sync Types, which simplifies the implementation.
1973 Table 28 Symbol Sequence Values Per Sync Type
Scrambler and
TxSyncTypeHS0[2:0],
Sync Type Sync Value Descrambler
TxSyncTypeHS1[2:0]
Seed Index
Type 0 3444440 0 0
Type 1 3444441 1 1
Type 2 3444442 2 2
Type 3 3444443 3 3
Type 4 3444444 4 N/A
1974 Note:
1975 When a single seed value is used, Sync Type 3 is the default Sync Word value.
1976 Figure 91 shows the architecture of the scrambling in a single Lane. The pseudo-random number generated
1977 by the PRBS shall be used as the seed index to select the initial seed value from the seed list prior to sending
1978 the packet. This seed index shall also be sent to the C-PHY using the PPI signals TxSyncTypeHS0[1:0].
1979 TxSyncTypeHS0[2] is always zero. TxSyncTypeHS1 [2:0] is used similarly for a 32-bit data path. The C-
1980 PHY ensures that the very first packet in a burst begins with a Sync Word using Sync Type 3.
Lane 1 Seed 0 Lane 1 Seed 0

4 seeds 4 seeds
1 seed Lane 1 Seed 3 Tx Rx 1 seed Lane 1 Seed 3
Tx PPI Rx PPI
Word Word Lane 1 C-PHY Word De- Word
Scrambling
Stream Stream (TxàChanàRx) Stream Scrambling Stream
TxINIT PRBS
TxSyncTypeHS0[1:0] RxSyncTypeHS0[1:0]
1981
Figure 91 Generating Tx Sync Type as Seed Index (Single Lane View)
1982 The seed list may contain either one or four initial seed values. Transmitters and receivers shall have the
1983 capability to select exactly one seed value from a list of seeds. When a single seed value is used, that seed
1984 shall be identified as Seed 3 and the transmitter shall always transmit Sync Type 3. Transmitters and receivers
1985 should also have the capability to select a seed value from a list of four seed values, as shown in Figure 91.
1986 When a list of four seed values is used then Sync Type 0 through Sync Type 3 shall be used to convey the
1987 seed index value from the transmitter to the receiver.
1988 When the list of four seeds is used, the two-bit seed index shall be generated in the transmitter using a pseudo
1989 random generator (e.g., PRBS).
1990 Slight differences in the implementation of the PRBS generator will not affect the interoperability of the
1991 transmitter and receiver, because the receiver responds to the seed index chosen in the transmitter and
1992 conveyed to the receiver using the Sync Type.

Confidential
31-May-2019
1993 At the receiver, the C-PHY decodes the Sync Word and passes the 2-bit Sync Type value to the CSI-2 protocol
1994 logic. The CSI-2 protocol logic uses the two-bit value as a seed index to select one of four seed values to
1995 initialize the descrambler. This concept is shown in the single Lane diagram in Figure 91. Figure 88 shows
1996 the use of the PPI signals to select which seed value was used to initialize the scrambler and descrambler.
1997 Since the seed selection field is transmitted via the Sync Word, no other mechanism is needed to coordinate
1998 the choice of specific descrambler initial seed values at the receiver.
Per-Lane Scrambling Tx Rx
Tx PPI Rx PPI
Scrambling
Lane Distribution
PRBS TxSyncTypeHS0[2:0] RxSyncTypeHS0[2:0]
Lane Merge
CSI-2 CSI-2
Function
Function
Byte Word Word Lane 2 C-PHY Word De- Word Byte
Protocol Stream Scrambling Protocol
Stream Stream (TxàChanàRx) Stream Scrambling Stream Stream
Tx Rx

Scrambling
1999
Figure 92 Generating Tx Sync Type Using the C-PHY Physical Layer

Confidential
31-May-2019
9.13.3 Scrambling Details

2000 The Long Packet Header, Data Payload, Long Packet Footer (which may include a Filler Byte), and Short
2001 Packets shall be scrambled. Special data fields generated by the PHY that are beyond the control of the CSI-
2002 2 protocol shall not be scrambled. For clarity, Table 29 lists all of the fields that are not scrambled.
2003 Table 29 Fields That Are Not Scrambled
PHY PHY-Generated CSI-2-Protocol-Generated
• HS-Zero • LP Mode transactions for SoT, EoT and
• Sync Word (aka Leader Sequence) ULPS
• HS Trail
• SoT
• EoT
• HS-Idle
D-PHY
• All fields of the deskew sequence
(aka deskew burst) including:
• HS-Zero
• Deskew sync pattern
• ‘01010101’ data
• HS-Trail
• Preamble (including t3-PREBEGIN • Sync Word inserted via PPI command
t3-PROGSEQ and t3-PREEND) • LP Mode transactions for SoT, EoT and
• Sync Word ULPS
C-PHY • Post
• SoT
• EoT
2004 The data scrambler and descrambler pseudo-random binary sequence (PRBS) shall be generated using the
2005 Galois form of an LFSR implementing the generator polynomial:
2006 (x) = x 16 + x5 + x4 + x3 + 1
2007 The initial D-PHY seed values in Table 30 should be used to initialize the D-PHY scrambler LFSR in Lanes
2008 1 through 8.
2009 Table 30 D-PHY Scrambler PRBS Initial Seed Values for Lanes 1 Through 8
Lane Initial Seed Value
1 0x0810
2 0x0990
3 0x0a51
4 0x0bd0
5 0x0c30
6 0x0db0
7 0x0e70
8 0x0ff0
2010

Confidential
31-May-2019
2011 The initial C-PHY seed values in Table 31 should be used to initialize the C-PHY scrambler LFSR in Lanes
2012 1 through 8. The table provides initial seed values for each of the four possible Sync Type values per Lane
2013 number. If only a single Sync Type is used, then it shall default to Sync Type 3.
2014 Table 31 C-PHY Scrambler PRBS Initial Seed Values for Lanes 1 Through 8
Initial Seed Value
Lane
Sync Type 0 Sync Type 1 Sync Type 2 Sync Type 3
1 0x0810 0x0001 0x1818 0x1008
2 0x0990 0x0180 0x1998 0x1188
3 0x0a51 0x0240 0x1a59 0x1248
4 0x0bd0 0x03c0 0x1bd8 0x13c8
5 0x0c30 0x0420 0x1c38 0x1428
6 0x0db0 0x05a0 0x1db8 0x15a8
7 0x0e70 0x0660 0x1e79 0x1668
8 0x0ff0 0x07e0 0x1ff8 0x17e8
2015 For D-PHY and C-PHY systems requiring more than eight Lanes, Annex G provides 24 additional seed
2016 values for Lanes 9 through 32, as well as a mechanism for finding seed values for Lanes 33 and higher. For
2017 each seed value, the LSB corresponds to scrambler PRBS register bit Q0 and the MSB corresponds to bit
2018 Q15.
2019 The LFSR shall generate an eight-bit sequence at G(x) for every byte of Payload data to be scrambled, starting
2020 from its initial seed value. The LFSR shall generate new bit sequences of G(x) by advancing eight bit cycles
2021 for each subsequent Payload data byte.
2022 Scrambling shall be achieved by modulo-2 bit-wise addition (X-OR) of a sequence of eight bits G(x) with
2023 the CSI-2 Payload data to be scrambled.

Confidential
31-May-2019
2024 Implementation Tip: the 8-bit value from the PRBS is the flip of bits Q15:Q8 of the PRBS LFSR register
2025 on every 8th bit clock. The designer might choose to implement the PRBS LFSR in parallel form to shift the
2026 equivalent of 8 places in a single byte clock, or the PRBS LFSR might even be configured to shift a multiple
2027 of 8 places in a single word clock.
2028 For the example shown in Figure 93, Q[15:8] are captured in a temporary register, then the PRBS LFSR is
2029 shifted eight times before Q[15:8] are captured again. The scrambling is performed as follows:
2030 • TxD[7] = PktD[7] ⊕ Q’[8];
2031 • TxD[6] = PktD[6] ⊕ Q’[9];
2032 • TxD[5] = PktD[5] ⊕ Q’[10];
2033 • TxD[4] = PktD[4] ⊕ Q’[11];
2034 • TxD[3] = PktD[3] ⊕ Q’[12];
2035 • TxD[2] = PktD[2] ⊕ Q’[13];
2036 • TxD[1] = PktD[1] ⊕ Q’[14];
2037 • TxD[0] = PktD[0] ⊕ Q’[15];
PRBS Byte Capture & Modulo-2 Sum

PktD0
PktD1
PktD2
PktD3
PktD4
PktD5
PktD6
PktD7
TxD7
TxD6
TxD5
TxD4
TxD3
TxD2
TxD1
TxD0
D Q D Q D Q D Q D Q D Q D Q D Q
SET SET SET SET SET SET SET SET
CLR CLR CLR CLR CLR CLR CLR CLR

Byte Clock
PRBS LFSR
G(x)
Q8 Q9 Q10 Q11 Q12 Q13 Q14 Q15
Reset
Bit Clock
Q0 Q1 Q2 Q3 Q4 Q5 Q6 Q7
2038
Figure 93 PRBS LFSR Serial Implementation Example

Confidential
31-May-2019
2039 Table 32 illustrates the sequence of the PRBS register one bit at a time, starting with the initial seed value for
2040 Lane 2. The data scrambling sequence is the output G(x). The first bit output from the scrambler is the value
2041 output from G(x) (also Q15 of the register in Figure 93) when the register contains the initial seed value.
2042 Table 32 Example of the PRBS Bit-at-a-Time Shift Sequence
t Q15 Q14 Q13 Q12 Q11 Q10 Q9 Q8 Q7 Q6 Q5 Q4 Q3 Q2 Q1 Q0 LFSR
0 0 0 0 1 0 0 0 1 1 0 0 0 1 0 0 0 0x1188
1 0 0 1 0 0 0 1 1 0 0 0 1 0 0 0 0 0x2310
2 0 1 0 0 0 1 1 0 0 0 1 0 0 0 0 0 0x4620
3 1 0 0 0 1 1 0 0 0 1 0 0 0 0 0 0 0x8C40
4 0 0 0 1 1 0 0 0 1 0 1 1 1 0 0 1 0x18B9
5 0 0 1 1 0 0 0 1 0 1 1 1 0 0 1 0 0x3172
6 0 1 1 0 0 0 1 0 1 1 1 0 0 1 0 0 0x62E4
7 1 1 0 0 0 1 0 1 1 1 0 0 1 0 0 0 0xC5C8
8 1 0 0 0 1 0 1 1 1 0 1 0 1 0 0 1 0x8BA9
9 0 0 0 1 0 1 1 1 0 1 1 0 1 0 1 1 0x176B
10 0 0 1 0 1 1 1 0 1 1 0 1 0 1 1 0 0x2ED6
11 0 1 0 1 1 1 0 1 1 0 1 0 1 1 0 0 0x5DAC
12 1 0 1 1 1 0 1 1 0 1 0 1 1 0 0 0 0xBB58
13 0 1 1 1 0 1 1 0 1 0 0 0 1 0 0 1 0x7689
14 1 1 1 0 1 1 0 1 0 0 0 1 0 0 1 0 0xED12
15 1 1 0 1 1 0 1 0 0 0 0 1 1 1 0 1 0xDA1D
16 1 0 1 1 0 1 0 0 0 0 0 0 0 0 1 1 0xB403
2043 Table 33 shows the first ten PRBS Byte Outputs produced by the PRBS LFSR in Lane 2 when the D-PHY
2044 physical layer is being used.
2045 Table 33 Example PRBS LFSR Byte Sequence for D-PHY Physical Layer
Scrambling Sequence PRBS Register PRBS Byte Input Byte Output Byte
Initial Seed, Byte 0 0x0990 0x90 0x2b 0xbb
Byte 1 0x91f1 0x89 0x0d 0x84
Byte 2 0xee29 0x77 0x63 0x14
Byte 3 0x3dbe 0xbc 0x00 0xbc
Byte 4 0xbba5 0xdd 0x00 0xdd
Byte 5 0xbcb3 0x3d 0x00 0x3d
Byte 6 0xaa1c 0x55 0x19 0x4c
Byte 7 0x061a 0x60 0x41 0x21
Byte 8 0x1a96 0x58 0x22 0x7a
Byte 9 0x942a 0x29 0x53 0x7a

Confidential
31-May-2019
2046 Table 34 shows an example of the PRBS Word Outputs at the beginning of a packet, that are produced by the
2047 PRBS LFSR in Lane 2 when the C-PHY physical layer is being used.
2048 Table 34 Example PRBS LFSR Byte Sequence for C-PHY Physical Layer
Scrambling Sequence Word # PRBS Register PRBS Word Input Word Output Word
Initial Seed, Header[47:32] 0x0990 0x8990 0x2b00 0xa290
Header[31:16] 0xee29 0xbc77 0x13b0 0xafc7
Header[15:0] 0xbba5 0x3ddd 0x31c8 0x0c15
Sync Word 0xaa1c 0x6055 0xxxxx 0xxxxx
Re-initialized Seed, Header[47:32] 0x1188 0xd188 0x2b00 0xfa88
Header[31:16] 0xb403 0xd82d 0x13b0 0xcb9d
Header[15:0] 0xd613 0x406b 0x31c8 0x71a3
Word 0 0xc672 0x0663 0xd000 0xd663
Word 1 0x5f60 0x36fa 0x1360 0x259a
Word 2 0xbf4c 0xaafd 0x094c 0xa3b1
Word 3 0x5a0d 0x805a 0x100b 0x9051
Word 4 0x6a39 0x8c56 0x5fb8 0xd3ee
Word 5 0xde89 0x997b 0xd030 0x494b
Word 6 0x10e1 0x4708 0x0003 0x470b
Word 7 0x8592 0x71a1 0xd039 0xa198
Word 8 0x40de 0x0b02 0xa35b 0xa859
Word 9 0x5150 0xba8a 0x00ea 0xba60

Confidential
31-May-2019
9.14 Smart Region of Interest (SROI)

2049 The Smart Region of Interest (SROI) feature supports the adaptive transfer of rectangular Regions of Interest
2050 (ROI). SROI can be used to reduce data bandwidth by selectively transmitting one or more smaller ROIs
2051 carved out from the original picture, such as a human face or a license plate. SROI has use cases in cameras
2052 for computer vision, and machine vision applications beyond mobile markets including industry,
2053 surveillance, and IoT.
2054 In addition to reducing data bandwidth, SROI benefits include:
2055 • High Frame Rate / Low Latency: Data reduction can increase the sensor frame rate and reduce
2056 processing workloads for application processors.
2057 • High Resolution: A high-resolution image can be extracted by capturing the necessary
2058 information without increasing the amount of data transferred.
2059 • Low Power Dissipation: Processing workload reductions can save system power.
9.14.1 Overview of SROI Frame Format

2060 As shown in Figure 94, each rectangular ROI is defined by position (X, Y coordinates of ROI rectangle
2061 upper left-hand corner pixel), size (Height and Width of ROI rectangle, in pixels), and other metadata (e.g.,
2062 ADC bit depth; see Table 37).
2063 Each ROI has corresponding a ROI Information field with values for position, size, and other items (see
2064 Section 9.14.5). ROI Information values either are determined by a detection function integrated into an AP
2065 or image sensor, or for some use cases such as factory automation are set in advance. The method of detecting
2066 an ROI is out of scope for this specification.
2067 The maximum number of ROI is also out of scope for this specification, because it is implementation-
2068 specific. However, prior to the SROI transfer the application processor and the image sensor shall agree on
2069 the maximum number of ROI.
2070 SROI Frames use three data packet types:
2071 • SROI Short Packet is used for transmitting a Frame Start (FS) Packet and a Frame End (FE)
2072 Packet in an image frame with the SROI Long Packet.
2073 If Line synchronization packets are needed, then Line Start (LS) Packets and Line End (LE)
2074 Packets are also permitted as SROI Short Packets.
2075 • SROI Embedded Data Packet is used for transmitting ROI Information, as detailed in
2076 Section 9.14.5.
2077 If the SROI Embedded Data Packet is present in an image frame, it shall be located at the
2078 beginning of the image frame.
2079 • SROI Long Packet (excludes the SROI Embedded Data Packet) is used for transmitting ROI
2080 image data for an image frame.
2081 The SROI Long Packet should use the same image Data Type used to transmit the image frame’s
2082 normal, non-SROI image lines (e.g., RAW10), however a User-Defined Data Type is also
2083 permitted. For SROI transfers, it is not required for all SROI Long Packets within a given image
2084 frame to have equal length.
2085 When there are multiple ROIs within one line of original image data, all ROI data shall be merged
2086 together into a single SROI Long Packet, with no blanking between the regions. See example of
2087 A(0) and D(0) in Figure 94.
2088 Any image region overlapped by multiple ROIs, for example A(n-2) and B(0) in Figure 94, shall
2089 be transmitted only once (i.e., shall not be transmitted multiple times, one per ROI). As a result,
2090 each overlapped image region shall be counted only once when calculating the value of the SROI
2091 Long Packet Word Count field (i.e., shall not be counted multiple times, one per ROI).
2092 The term SROI Packet means any SROI Short Packet, SROI Embedded Data Packet, or SROI Long Packet.

Confidential
31-May-2019
Origin (0, 0)
X
WA Overlapped region
(XA, YA) (XD, YD)

Y
HA A
D
(XB, YB)
B
(XC, YC)
C
FS
PH SROI Embedded Data Packet PF

PH SROI Embedded Data Packet PF
PH A(0) D(0) PF
PH A(1) D(1) PF
No interval between A and D
……
Overlapped region between A

and B is sent only one time.
PH A(n-2) B(0) D(p-k-2) PF
PH A(n-1) B(1) D(p-k-1) PF
PH B(2) D(p-k) PF
…
PH B(m-2) D(p-1) PF
PH B(m-1) PF
PH C(0) PF The total number of line:

ROI A = n
…
ROI B = m
ROI C = q
PH C(q-1) PF ROI D = p
FE
2093
Figure 94 SROI Frame Format Example

Confidential
31-May-2019
9.14.2 Transmission of SROI Embedded Data Packet

2094 This Section specifies when the image sensor is required to send the SROI Embedded Data Packet (SEDP)
2095 in the image frame.
2096 This depends upon whether the application processor (AP) knows, vs. does not know, all required ROI
2097 Information (see Table 35). When the image sensor does send the SEDP, the AP’s method of detecting SROI
2098 Packets depends upon the SROI Packet Option (Option 1 vs. Option 2, see Section 9.14.3) that the AP and
2099 image sensor have agreed to use.
2100 • If the application processor already knows all ROI information required to receive an SROI
2101 Packet, then the image sensor is not required to transmit the SEDP. However, the image sensor
2102 may optionally transmit the SEDP.
2103 If SEDP is sent and SROI Packet Option 1 is used, then the AP can detect SROI Packets in the
2104 image frame by inspecting the Virtual Channel value (see Section 9.14.3.1).
2105 • If the application processor does not already know all ROI information required to receive an
2106 SROI Packet, then the image sensor shall transmit the SEDP.
2107 The method the AP uses to detect SROI Packets in an image frame depends upon which SROI
2108 Packet Option is in use: by Virtual Channel for Option 1 (see Section 9.14.3.1), or by Data Type
2109 for Option 2 (see Section 9.14.3.2).
2110 Example use cases are shown in Section 9.14.4.
2111 Table 35 Transmission of SROI Embedded Data Packet
AP Knowledge of All Required ROI Information
AP Knows AP Does Not Know
(See Section 9.14.4.1) (See Section 9.14.4.2)
SEDP Required No Yes
Option 1 AP either
SROI Packet Option
AP can detect
(See Section 9.14.3.1) knows SROI Packet,
SROI Packet
or can detect SROI Packet
by Virtual Channel
by Virtual Channel
Option 2 AP can detect
(See Section 9.14.3.2) SROI Packet
AP knows SROI Packet
by Data Type

Confidential
31-May-2019
9.14.3 SROI Packet Detection Options

2112 The following sub-sections detail the two options for distinguishing the SROI Packets in an image frame
2113 from the non-SROI Packets.
2114 Prior to the SROI transfer, the application processor and the image sensor shall agree on which of the two
2115 options (i.e., Option 1 vs. Option 2) will be used.
9.14.3.1 SROI Packet Option 1

2116 Option 1 distinguishes SROI Packets from non-SROI packets by using a different Virtual Channel value.
2117 For Option 1, all SROI Packets for a given image frame shall use the same Virtual Channel, and this SROI
2118 Virtual Channel shall be different from the Virtual Channel used in the image frame’s non-SROI Packets (see
2119 Figure 95). Virtual Channel Interleaving may be used.
2120 An image frame that includes SROI Packets may use Data Type Interleaving, but only if the Data Type used
2121 in the SROI Long Packet is different from the Data Type used in the non-SROI Long Packet (e.g., PDAF).
The Virtual Channel of SROI Packet is different from that of non-SROI packets.
SROI Short Packet

FS(VC1)
PH(VC1) SROI Embedded Data Packet PF
PH(VC1) SROI Long Packet (DT0) PF PH(VC1) PDAF (DT1) PF
FE(VC1)
SROI Short Packet If the Data Type of SROI Packet is different from that of
non-SROI Packet, Data Type Interleaving can be used.
FS(VC0)
PH(VC0) Normal Embedded Data PF
FS(VC1)
PH(VC0) NormaI Image Data (DT0) PF


PH(VC1) SROI Long Packet (DT0) PF

FE(VC1)
By using different Virtual Channel, Virtual Channel
FE(VC0) Interleaving can be used.
SROI Short Packet
FS(VC1)

KEY:
FS(VCn) : Frame Start containing Virtual Channel n
PH(VC1) SROI Long Packet (DT0) PF FE(VCn) : Frame End containing Virtual Channel n
PH(VCn) : Packet Header containing Virtual Channel n
PH(VC1) SROI Long Packet (DT0) PF PF : Packet Footer
DTn : Data Type n
PDAF : Phase Detection Auto Focus
FE(VC1)
2122
Figure 95 SROI Packet Option 1

Confidential
31-May-2019
9.14.3.2 SROI Packet Option 2

2123 Option 2 distinguishes SROI Packets from non-SROI packets by Data Type; in particular, by detecting the
2124 presence of the SROI Embedded Data Packet in the image frame.
2125 For Option 2, all SROI Packets for a given image frame shall use the same Virtual Channel that the non-
2126 SROI Packets use (see Figure 96).
2127 An image frame that includes SROI Packets may use Data Type Interleaving, but only if the Data Type used
2128 in the SROI Long Packet is different from the Data Type used in the non-SROI Long Packet (e.g., PDAF).
The Virtual Channel of SROI Packet is the same as that of non-SROI Packet.
SROI Short Packet AP can detect SROI Packet by detecting SROI

FS(VC0) Embedded Data Packet.
FE(VC0)
SROI Short Packet
If the Data Type of SROI Packet is different from that of
FS(VC0) non-SROI Packet, Data Type Interleaving can be used.
PH(VC0) Normal Embedded Data PF

FE(VC0)
FS(VC0)
PH(VC0) SROI Long Packet (DT0) PF KEY:

FS(VCn) : Frame Start containing Virtual Channel n
FE(VCn) : Frame End containing Virtual Channel n
PH(VC0) SROI Long Packet (DT0) PF PH(VCn) : Packet Header containing Virtual Channel n
PF : Packet Footer
PH(VC0) SROI Long Packet (DT0) PF DTn : Data Type n
PDAF : Phase Detection Auto Focus
FE(VC0)
2129
Figure 96 SROI Packet Option 2

Confidential
31-May-2019
9.14.4 SROI Use Cases (Informative)

2130 This Section presents informative use cases illustrating ways in which the SROI feature can be used.
9.14.4.1 Use Case 1: ROI Detection by the Application Processor

2131 If the AP is responsible for detecting an ROI, or has ROI information that is set in advance, then the image
2132 sensor is not required to transmit the SROI Embedded Data Packet. An example is shown in Figure 97.
2133 In this use case, the AP detects a ROI (e.g., a human face), and then sends the ROI’s position and size to an
2134 image sensor through the CCI (see Section 6). The image sensor then just carves out the ROI, based on the
2135 ordered position and size, and then keeps sending SROI Long Packets for the same image region.
2136 In this case the SROI Embedded Data Packet is not transmitted, because it would be unnecessary: the
2137 application processor already knows all ROI information (e.g., the ROI position and size) required to receive
2138 the SROI Packets.
AP detects “human face” and sends the AP orders to get Full image
position (X0, Y0, H0, W0) to ImageSensor
AP Detecting ROI Idle Ordering Idle
CCI
Bus Idle Bus Idle Bus Idle
(AP->ImageSensor)
activate activate
Status Normal Carving out ROI from the position(X0, Y0, H0, W0) Normal
Image
Sensor
Position
Don’t care X0, Y0, H0, W0 Don’t care
of ROI(0)
CSI-2 Output Invalid SROI frame SROI frame SROI frame Invalid Full image
Full image frame
(ImageSensor->AP) frame Image Image Image frame frame
SROI Embedded Data Packet is not transmitted

2139
Figure 97 Use Case 1: SROI Embedded Data Packet Not Transmitted

Confidential
31-May-2019
9.14.4.2 Use Case 2: ROI Detection by the Image Sensor

2140 If the image sensor is responsible for detecting an ROI, then the image sensor is required to transmit the
2141 SROI Embedded Data Packet as illustrated in Figure 98.
2142 The AP orders the image sensor to get an ROI (e.g., a human face). The image sensor detects the ROI and
2143 carves it out, and then keeps tracking the ROI.
2144 In this case the SROI Embedded Data Packet is (and must be) transmitted, because the application processor
2145 doesn’t know all of the ROI information (e.g., position and size) required to receive the SROI Packets.
AP orders Image Sensor to get “human face” AP orders Image Sensor to get Full image
AP Ordering Idle Ordering Idle
CCI
Bus Idle Bus Idle Bus Idle
(AP->ImageSensor)
activate activate
Status Normal Detecting, carving out ROI and tracking Normal

Image
update update
Sensor
Position
of ROI(0) Don’t care X0, Y0, H0, W0 X1, Y1, H1, W1 Xt, Yt, Ht, Wt Don’t care
CSI-2 Output Invalid SROI frame SROI frame SROI frame Invalid Full image
Full image frame
(ImageSensor->AP) frame Emb Image Emb Image Emb Image frame frame
SROI Embedded Data Packet shall be transmitted

2146
Figure 98 Use Case 2: SROI Embedded Data Packet Is Transmitted

Confidential
31-May-2019
9.14.5 Format of SROI Embedded Data Packet (SEDP)

2147 For SROI transfers, the Embedded Data Format is based on the definition in the MIPI CCS specification
2148 [MIPI04]. The Embedded Data Format Code for SROI frames is 0x0D (1 byte).
2149 The SROI Embedded Data Packet (see Figure 99) is composed of multiple ROI Information fields, each
2150 containing ROI Information about one extracted image region. Every ROI Information field shall start with
2151 the ROI ID, followed by the ROI Element Information field defined by Table 36. Table 37 defines the
2152 allocation and assignment of values for the Type ID sub-field used in the ROI Element Information field.
2153 At the end of the embedded data line, the End of Line shall be inserted after the end of the last ROI
2154 Information field.
2155 The length of the SROI Embedded Data Packet line shall not exceed the length of the full-resolution image
2156 data line. After the End of Line, the remainder of the line should be padded with 0x07 characters if the SROI
2157 Embedded Data Packet line is shorter than the length of the full-resolution image data line.
Data
1st ROI Info. 2nd ROI Info. Nth ROI Info. End of Padding
PH Format PF
(variable) (variable) (variable) Line (0x07,…,0x07)
Code
……
ROI ID ROI Element Info. ROI ID End of Line
Type ID Type
Length
0 0x01 ROI ID=0 Specific 0 0x01 ROI ID=1 0 0x07 0x07
PS ID (optional)
Payload
Beginning of ROI info. Beginning of ROI Info.
Payload Size
2158
Figure 99 SROI Embedded Data Packet Format
2159 Table 36 ROI Element Information Field Format

Size
Field Name Description
(bits)
Type ID Payload 2 Size of the Type Specific Payload field:
Size 0: 1 byte
1: 2 bytes
2: 4 bytes
3: Size is given by the Length field (below)
ID 6 Type Identifier (bottom bits of first byte):
0x00 – 0x1F MIPI Defined ID
0x20 – 0x3E User Defined ID

0x3F MIPI Defined ID
Length 8 If Payload Size is 3 (2’b11):
(optional) Number of 8-bit data bytes in the Type Specific Payload field
Example: A value of 0x20 in the Length field indicates that the
Type Specific Payload contains 32 bytes
If Payload size is 0, 1, or 2:
Length field is not included in the ROI Element Information
field
Type Specific Payload Variable The payload data is byte-based, i.e., the data size shall be
divisible by 8 bits.

Confidential
31-May-2019
2160 Table 37 ROI Element Type ID Definitions

Type ID Name Description
MIPI Defined IDs
Payload Size = 1 Byte
8’b00_0_00000 Reserved Reserved for future use
8’b00_0_00001 ROI ID Identification number (1 Byte) of each ROI. (Mandatory)
8’b00_0_00010 ADC Bit Depth Bit depth of Analog Digital Converter of each ROI
8’b00_0_00011
through Reserved Reserved for future use
8’b00_0_00110
The end of SROI Embedded Data line.
8’b00_0_00111 End of Line
The value of Type Specific Payload is 0x07.
8’b00_0_01000
8’b00_0_11111
Payload Size = 2 Bytes
8’b01_0_00001 ROI ID (2 Bytes) Identification number (2 Bytes) of each ROI. (Optional)
8’b01_0_00010
8’b01_0_00111
8’b01_0_01000 X X coordinate of upper left of region [pixel]
8’b01_0_01001 Y Y coordinate of upper left of region [pixel]
8’b01_0_01010 Height Height of region [pixels]
8’b01_0_01011 Width Width of region [pixels]
8’b01_0_01100
8’b01_0_11111
8’b10_0_00000
8’b10_0_11111
Payload Size = Length
8’b11_0_00000
8’b11_0_11111

Confidential
31-May-2019
Type ID Name Description

User Defined IDs
Payload Size = 1 Byte
8’b00_1_00000
through User Defined ID Reserved for user definition
8’b00_1_11111
8’b01_1_00000
8’b01_1_11111
8’b10_1_00000
8’b10_1_11111
Payload Size = Length
8’b11_1_00000
8’b11_1_11110
MIPI Defined ID

Confidential
31-May-2019
9.15 Packet Data Payload Size Rules

2161 For YUV, RGB or RAW data types, one long packet shall contain one line of image data. Each long packet
2162 of the same Data Type shall have equal length when packets are within the same Virtual Channel and when
2163 packets are within the same frame. An exception to this rule is the YUV420 data type which is defined in
2164 Section 11.2.2.
2165 For User Defined Byte-based Data Types, the USL Data Type (code 0x38), and Data Types for SROI Long
2166 Packet, long packets can have arbitrary length. The spacing between packets can also vary.
2167 The total size of payload data within a long packet for all data types shall be a multiple of eight bits. However,
2168 it is also possible that a data types payload data transmission format, as defined elsewhere in this
2169 Specification, imposes additional constraints on payload size. In order to meet these constraints it may
2170 sometimes be necessary to add some number of "padding" pixels to the end of a payload e.g., when a packet
2171 with the RAW10 data type contains an image line whose length is not a multiple of four pixels as required
2172 by the RAW10 transmission format as described in Section 11.4.4. The values of such padding pixels are not
2173 specified.

Confidential
31-May-2019
9.16 Frame Format Examples

2174 This is an informative section.
2175 This section contains three examples to illustrate how the CSI-2 features can be used.
2176 • General Frame Format Example, Figure 100
2177 • Digital Interlaced Video Example, Figure 101
2178 • Digital Interlaced Video with accurate synchronization timing information, Figure 102
Frame Blanking
Packet Header, PH
Packet Footer, PF
Line Blanking Frame of Arbitrary Pixel and/or User-

Defined Byte-Based Data
FE
Frame Blanking

Packet Header, PH
Packet Footer, PF
Frame of Arbitrary Pixel and/or User-

Line Blanking Defined Byte-Based Data
FE
Frame Blanking
Data per line is a multiple of 8-bits

KEY:
2179
Figure 100 General Frame Format Example

Confidential
31-May-2019
Blanking Lines
FS
Frame 1
Line Blanking (Odd, Frame Number = 1)
YUV422 Image Data
Packet Header, PH
Packet Footer, PF
FE
Blanking Lines
FS
Frame 2
Line Blanking (Even, Frame Number = 2)
YUV422 Image Data
FE
Blanking Lines
Data per line is a multiple of 16-bits (YUV422)

KEY:
2180
Figure 101 Digital Interlaced Video Example

Confidential
31-May-2019
Blanking Lines
FS
Line Blanking
Frame 1
(Odd, Frame Number = 1)
YUV422 Image Data
Packet Header, PH
Packet Footer, PF
FE
Line Start, LS
Line End, LE
Blanking Lines
FS
Line Blanking
Frame 2
(Even, Frame Number = 2)
YUV422 Image Data
FE
Blanking Lines
Data per line is a multiple of 16-bits (YUV422)

KEY:
2181
Figure 102 Digital Interlaced Video with Accurate Synchronization Timing Information

Confidential
31-May-2019
9.17 Data Interleaving

2182 The CSI-2 supports the interleaved transmission of different image data formats within the same video data
2183 stream.
2184 There are two methods to interleave the transmission of different image data formats:
2185 • Data Type
2186 • Virtual Channel Identifier
2187 The preceding methods of interleaved data transmission can be combined in any manner.
9.17.1 Data Type Interleaving

2188 The Data Type value uniquely defines the data format for that packet of data. The receiver uses the Data Type
2189 value in the packet header to de-multiplex data packets containing different data formats as illustrated in
2190 Figure 103. Note, in the figure the Virtual Channel Identifier is the same in each Packet Header.
2191 The packet payload data format shall agree with the Data Type code in the Packet Header as follows:
2192 • For defined image data types – any non-reserved codes in the range 0x18 to 0x3F – only the single
2193 corresponding MIPI-defined packet payload data format shall be considered correct
2194 • Reserved image data types – any reserved codes in the range 0x18 to 0x3F – shall not be used. No
2195 packet payload data format shall be considered correct for reserved image data types
2196 • For generic long packet data types (codes 0x10 thru 0x17) and user-defined, byte-based (codes
2197 0x30 – 0x37), any packet payload data format shall be considered correct
2198 • Generic long packet data types (codes 0x10 thru 0x17) and user-defined, byte-based (codes 0x30 –
2199 0x37), should not be used with packet payloads that meet any MIPI image data format definition
2200 • Synchronization short packet data types (codes 0x00 thru 0x07) shall consist of only the header
2201 and shall not include payload data bytes
2202 • Generic short packet data types (codes 0x08 thru 0x0F) shall consist of only the header and shall
2203 not include payload data bytes
2204 Data formats are defined further in Section 11.
Frame Start Packet Embedded Data Embedded Data Data Type 1 Image Data
SoT FS EoT LPS SoT PH Embed Data PF EoT LPS SoT PH Embed Data PF EoT LPS SoT PH Data Type 1 PF EoT
Data Type 1 Image Data Data Type 2 Image Data Data Type 1 Image Data
LPS SoT PH Data Type 1 PF EoT LPS SoT PH Data Type 2 PF EoT LPS SoT PH Data Type 1 PF EoT
Data Type 2 Image Data Data Type 1 Image Data Frame End Packet
LPS SoT PH Data Type 2 PF EoT LPS SoT PH Data Type 1 PF EoT LPS SoT FE EoT
KEY:
LPS – Low Power State FS – Frame Start Packet PH – Packet Header
SoT – Start of Transmission FE – Frame End Packet PF – Packet Footer + Filler (if applicable)
2205
Figure 103 Interleaved Data Transmission using Data Type Value
2206 All of the packets within the same virtual channel, independent of the Data Type value, share the same frame
2207 start/end and line start/end synchronization information. By definition, all of the packets, independent of data

Confidential
31-May-2019
2208 type, between a Frame Start and a Frame End packet within the same virtual channel belong to the same
2209 frame.
2210 Packets of different data types may be interleaved at either the packet level as illustrated in Figure 104 or
2211 the frame level as illustrated in Figure 105. Data formats are defined in Section 11.
FS ED Zero or more lines of Embedded Data PF

D1 Data Type 1 Image Data PF

Line
Blanking
ED Zero or more lines of Embedded Data PF FE
Frame Blanking
Line
Blanking
Frame Blanking
Data Type 1 Payload Size
Embedded Data Payload Size

KEY:
LPS – Low Power State ED – Packet Header containing Embedded Data type code
FS – Frame Start D1 – Packet Header containing Data Type 1 Image Data Code
FE – Frame End D2 – Packet Header containing Data Type 2 Image Data Code
2212
PF – Packet Footer + Filler (if applicable)
Figure 104 Packet Level Interleaved Data Transmission

Confidential
31-May-2019
Line
Blanking
Frame Blanking
Line
Blanking
ED Zero of more lines of Embedded Data PF FE
Frame Blanking
Embedded Data Payload Size

KEY:
LPS – Low Power State ED – Packet Header containing Embedded Data type code
FS – Frame Start D1 – Packet Header containing Data Type 1 Image Data Code
FE – Frame End D2 – Packet Header containing Data Type 2 Image Data Code
2213
PF – Packet Footer + Filler (if applicable)
Figure 105 Frame Level Interleaved Data Transmission

Confidential
31-May-2019
9.17.2 Virtual Channel Identifier Interleaving

2214 The Virtual Channel Identifier allows different data types within a single data stream to be logically separated
2215 from each other. Figure 106 illustrates data interleaving using the Virtual Channel Identifier.
2216 Each virtual channel has its own Frame Start and Frame End packet (except for virtual channels used
2217 exclusively with USL Packets; see Section 9.12). Therefore, it is possible for different virtual channels to
2218 have different frame rates, though the data rate for both channels would remain the same.
2219 In addition, Data Type value Interleaving can be used for each virtual channel, allowing different data types
2220 within a virtual channel and a second level of data interleaving.
2221 Therefore, receivers should be able to de-multiplex different data packets based on the combination of the
2222 Virtual Channel Identifier and the Data Type value. For example, data packets containing the same Data Type
2223 value but transmitted on different virtual channels are considered to belong to different frames (streams) of
2224 image data.
Frame Start Packet Embedded Data Frame Start Packet Embedded Data
Virtual Channel 0 Virtual Channel 0 Virtual Channel 1 Virtual Channel 1
SoT FS EoT LPS SoT PH Embedded Data PF EoT LPS SoT FS EoT LPS SoT PH Embedded Data PF EoT
Data Type 1 Image Data Data Type 2 Image Data Data Type 1 Image Data
LPS SoT PH Data Type 1 PF EoT LPS SoT PH Data Type 2 PF EoT LPS SoT PH Data Type 1 PF EoT
Data Type 2 Image Data Frame End Packet Data Type 1 Image Data Frame End Packet
LPS SoT PH Data Type 2 PF EoT LPS SoT FE EoT LPS SoT PH Data Type 1 PF EoT LPS SoT FE EoT
KEY:
LPS – Low Power State FS – Frame Start Packet PH – Packet Header
SoT – Start of Transmission FE – Frame End Packet PF – Packet Footer + Filler (if applicable)
2225
Figure 106 Interleaved Data Transmission using Virtual Channels

Confidential
31-May-2019
10 Color Spaces
2226 The color space definitions in this section are simply references to other standards. The references are
2227 included only for informative purposes and not for compliance. The color space used is not limited to the
2228 references given.
10.1 RGB Color Space Definition

2229 In this Specification, the abbreviation RGB means the nonlinear sRGB color space in 8 -bit representation
2230 based on the definition of sRGB in IEC 61966.
2231 The 8-bit representation results as RGB888. The conversion to the more commonly used RGB565 format is
2232 achieved by scaling the 8-bit values to five bits (blue and red) and six bits (green). The scaling can be done
2233 either by simply dropping the LSBs or rounding.
10.2 YUV Color Space Definition

2234 In this Specification, the abbreviation YUV refers to the 8-bit gamma corrected YCBCR color space defined
2235 in ITU-R BT601.4.

Confidential
31-May-2019

Confidential
31-May-2019
11 Data Formats
2236 The intent of this section is to provide a definitive reference for data formats typically used in CSI-2
2237 applications. Table 38 summarizes the formats, followed by individual definitions for each format. Generic
2238 data types not shown in the table are described in Section 11.1. For simplicity, all examples are single Lane
2239 configurations.
2240 The formats most widely used in CSI-2 applications are distinguished by a “primary” designation in Table
2241 38. Transmitter implementations of CSI-2 should support at least one of these primary formats. Receiver
2242 implementations of CSI-2 should support all of the primary formats.
2243 The packet payload data format shall agree with the Data Type value in the Packet Header. See Section 9.4
2244 for a description of the Data Type values.
2245 Table 38 Primary and Secondary Data Formats Definitions
Data Format Primary Secondary
YUV420 8-bit (legacy) S
YUV420 8-bit S
YUV420 10-bit S
YUV420 8-bit (CSPS) S
YUV420 10-bit (CSPS) S
YUV422 8-bit P
YUV422 10-bit S
RGB888 P
RGB666 S
RGB565 P
RGB555 S
RGB444 S
RAW6 S
RAW7 S
RAW8 P
RAW10 P
RAW12 S
RAW14 S
RAW16 S
RAW20 S
RAW24 S
Generic 8-bit Long Packet Data Types P
User Defined Byte-based Data (Note 1) P
USL Packet Data (See Section 9.12) S
Note:
1. Compressed image data should use the user defined, byte-based data type codes

Confidential
31-May-2019
2246 For clarity the Start of Transmission and End of Transmission sequences in the figures in this section have
2247 been omitted.
2248 The balance of this section details how sequences of pixels and other application data conforming to each of
2249 the data types listed in Table 38 are converted into equivalent byte sequences by the CSI-2 Pixel to Byte
2250 Packing Formats layer shown in Figure 3.
2251 Various figures in this section depict these byte sequences as shown at the top of Figure 107, where Byte n
2252 always precedes Byte m for n < m. Also note that even though each byte is shown in LSB-first order, this is
2253 not meant to imply that the bytes themselves are bit-reversed by the Pixel to Byte Packing Formats layer
2254 prior to output.
2255 For the D-PHY physical layer option, each byte in the sequence is serially transmitted LSB-first, whereas for
2256 the C-PHY physical layer option, successive byte pairs in the sequence are encoded and then serially
2257 transmitted LSS-first. Figure 107 illustrates these options for a single-Lane system.
Formatted Pixel/Application Data Bytes Generated By Upper CSI-2 Layers

(b0 = Least Significant Bit)
D-PHY Physical Layer Byte n* Byte n+1 Byte n+2 Byte n+3
serializes each byte
b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7
and transmits it least
significant bit first
C-PHY Physical Layer B0 C-PHY 16 bit to 7 Symbol Mapper B15 B0 C-PHY 16 bit to 7 Symbol Mapper B15
Mapper composes 7
(B0 = Input LSB, S0 = Output LSS) (B0 = Input LSB, S0 = Output LSS)
symbols from 16-bit
word and transmits S0 S1 S2 S3 S4 S5 S6 S0 S1 S2 S3 S4 S5 S6
least significant symbol * For the C-PHY physical layer option, n = 2k, for k = 0, 1, 2, ...
2258 first
Figure 107 Byte Packing Pixel Data to C-PHY Symbol Illustration

Confidential
31-May-2019
11.1 Generic 8-bit Long Packet Data Types

2259 Table 39 defines the generic 8-bit Long packet data types.
2260 Table 39 Generic 8-bit Long Packet Data Types
Data Type Description See Section
0x10 Null
11.1.1
0x11 Blanking Data
0x12 Embedded 8-bit non Image Data 11.1.2
0x13 Generic long packet data type 1
11.1.3
0x17 Reserved –
11.1.1 Null and Blanking Data

2261 For both the null and blanking data types the receiver must ignore the content of the packet payload data.
2262 A blanking packet differs from a null packet in terms of its significance within a video data stream. A null
2263 packet has no meaning whereas the blanking packet may be used, for example, as the blanking lines between
2264 frames in an ITU-R BT.656 style video stream.

Confidential
31-May-2019
11.1.2 Embedded Information

2265 It is possible to embed extra lines containing additional information to the beginning and to the end of each
2266 picture frame as presented in the Figure 108. If embedded information exists, then the lines containing the
2267 embedded data must use the embedded data code in the data identifier.
2268 There may be zero or more lines of embedded data at the start of the frame. These lines are termed the frame
2269 header.
2270 There may be zero or more line of embedded data at the end of the frame. These lines are termed the frame
2271 footer.
FS Zero or more lines of Embedded Data
(and Filler if required for C-PHY)

PH (Packet Header)
CS (Checksum)
Frame of Arbitrary Pixel and/or Line
User-Defined Byte-Based Data Blanking
Zero or more lines of Embedded Data FE
Frame Blanking
Payload Data per packet must be a multiple of 8-bits

KEY:
LPS – Low Power State DI – Data Identifier WC – Word Count
ECC – Error Correction Code CS – Checksum FS – Frame Start
FE – Frame End LS – Line Start LE – Line End
2272
Figure 108 Frame Structure with Embedded Data at the Beginning and End of the Frame
11.1.3 Generic Long Packet Data Types 1 Through 4

2273 These codes have no specific definitions and may be used, for example, to identify various types of vendor-
2274 specific metadata packets transmitted within an image frame.

Confidential
31-May-2019
11.2 YUV Image Data

2275 Table 40 defines the data type codes for YUV data formats described in this section. The number of lines
2276 transmitted for the YUV420 data type shall be even.
2277 YUV420 data formats are divided into legacy and non-legacy data formats. The legacy YUV420 data format
2278 is for compatibility with existing systems. The non-legacy YUV420 data formats enable lower cost
2279 implementations.
2280 Table 40 YUV Image Data Types
0x18 YUV420 8-bit
0x19 YUV420 10-bit
0x1A Legacy YUV420 8-bit
0x1B Reserved
0x1C YUV420 8-bit (Chroma Shifted Pixel Sampling)
0x1D YUV420 10-bit (Chroma Shifted Pixel Sampling)
0x1E YUV422 8-bit
0x1F YUV422 10-bit
11.2.1 Legacy YUV420 8-bit

2281 Legacy YUV420 8-bit data transmission is performed by transmitting UYY… / VYY… sequences in odd /
2282 even lines. U component is transferred in odd lines (1, 3, 5 …) and V component is transferred in even lines
2283 (2, 4, 6 …). This sequence is illustrated in Figure 109.
2284 Table 41 specifies the packet size constraints for YUV420 8-bit packets. Each packet must be a multiple of
2285 the values in the table.
2286 Table 41 Legacy YUV420 8-bit Packet Data Size Constraints
Pixels Bytes Bits
2 3 24
2287 Bit order in transmission follows the general CSI-2 rule, LSB first. The pixel to byte mapping is illustrated
2288 in Figure 110.
Line Start: Packet Header U1[7:0] Y1[7:0] Y2[7:0] U3[7:0] Y3[7:0] Y4[7:0]
(Odd line)
Line End:
U637[7:0] Y637[7:0] Y638[7:0] U639[7:0] Y639[7:0] Y640[7:0] Packet Footer
(Odd Line)
Line Start:
Packet Header V1[7:0] Y1[7:0] Y2[7:0] V3[7:0] Y3[7:0] Y4[7:0]
(Even Line)
Line End:
V637[7:0] Y637[7:0] Y638[7:0] V639[7:0] Y639[7:0] Y640[7:0] Packet Footer
2289
(Even Line)
Figure 109 Legacy YUV420 8-bit Transmission

Confidential
31-May-2019
B7 B0 B7 B0 B7 B0 B7 B0
Pixel Data V1[7:0] Y1[7:0] Y2[7:0] V3[7:0]
Pixel to Byte Data Packing
B7 B0 B7 B0 B7 B0 B7 B0
Byte Data V1[7:0] Y1[7:0] Y2[7:0] V3[7:0]
B7 B0 B7 B0 B7 B0
V1[7:0] Y1[7:0] Y2[7:0]
Data Transmitted LS Bit First

B0 B7 B0 B7 B0 B7
Data V0 V1 V2 V3 V4 V5 V6 V7 Y0 Y1 Y2 Y3 Y4 Y5 Y6 Y7 Y0 Y1 Y2 Y3 Y4 Y5 Y6 Y7
Byte n Byte n+1 Byte n+2
b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7
2290
Figure 110 Legacy YUV420 8-bit Pixel to Byte Packing Bitwise Illustration
2291 There is one spatial sampling option

2292 • H.261, H.263 and MPEG1 Spatial Sampling (Figure 111).
Y1 Y2 Y3 Y4 Y5 Y6 Y7 Y8
Line 1
Line 2
Line 3
Line 4
Line 5
Luminance Sample, Y Calculated Chrominance sample, Cb & Cr

2293
Figure 111 Legacy YUV420 Spatial Sampling for H.261, H.263 and MPEG 1

Confidential
31-May-2019
FS U Y Y U Y Y …. U Y Y
V Y Y V Y Y …. V Y Y
U Y Y U Y Y …. U Y Y
Y Y Y Y …. Y Y
Packet Header, PH
V V V
Packet Footer, PF
V Y Y V Y Y …. V Y Y FE
2294
Figure 112 Legacy YUV420 8-bit Frame Format

Confidential
31-May-2019
11.2.2 YUV420 8-bit

2295 YUV420 8-bit data transmission is performed by transmitting YYYY… / UYVYUYVY… sequences in odd
2296 / even lines. Only the luminance component (Y) is transferred for odd lines (1, 3, 5…) and both luminance
2297 (Y) and chrominance (U and V) components are transferred for even lines (2, 4, 6…). The format for the
2298 even lines (UYVY) is identical to the YUV422 8-bit data format. The data transmission sequence is illustrated
2299 in Figure 113.
2300 The payload data size, in bytes, for even lines (UYVY) is double the payload data size for odd lines (Y). This
2301 is exception to the general CSI-2 rule that each line shall have an equal length.
2302 Table 42 specifies the packet size constraints for YUV420 8-bit packets. Each packet must be a multiple of
2303 the values in the table.
2304 Table 42 YUV420 8-bit Packet Data Size Constraints
Odd Lines (1, 3, 5...) Even Lines (2, 4, 6…)
Luminance Only, Y Luminance and Chrominance, UYVY
Pixels Bytes Bits Pixels Bytes Bits
2 2 16 2 4 32
2306 in Figure 114.
Line Start: Packet

Y1[7:0] Y2[7:0] Y3[7:0] Y4[7:0]
(Odd line) Header
Line End: Packet

Y637[7:0] Y638[7:0] Y639[7:0] Y640[7:0]
(Odd Line) Footer
Line Start: Packet

U1[7:0] Y1[7:0] V1[7:0] Y2[7:0] U3[7:0] Y3[7:0] V3[7:0]
(Even Line) Header
Line End: Packet

Y637[7:0] V637[7:0] Y638[7:0] U639[7:0] Y639[7:0] V639[7:0] Y640[7:0]
2307
(Even Line) Footer
Figure 113 YUV420 8-bit Data Transmission Sequence

Confidential
31-May-2019
Odd lines:
Y1[7:0] (A) Y2[7:0] (B) Y3[7:0] (C) Y4[7:0] (D)
Data A0 A1 A2 A3 A4 A5 A6 A7 B0 B1 B2 B3 B4 B5 B6 B7 C0 C1 C2 C3 C4 C5 C6 C7 D0 D1 D2 D3 D4 D5 D6 D7
8-bits 8-bits 8-bits 8-bits

Byte Values Transmitted LS Bit First
Byte n Byte n+1 Byte n+2 Byte n+3

Even lines:
U1[7:0] (A) Y1[7:0] (B) V1[7:0] (C) Y2[7:0] (D)


2308
Figure 114 YUV420 8-bit Pixel to Byte Packing Bitwise Illustration
2309 There are two spatial sampling options

2310 • H.261, H.263 and MPEG1 Spatial Sampling (Figure 115).
2311 • Chroma Shifted Pixel Sampling (CSPS) for MPEG2, MPEG4 (Figure 116).
2312 Figure 117 shows the YUV420 frame format.

Confidential
31-May-2019
Y1 Y2 Y3 Y4 Y5 Y6 Y7 Y8
Line 1
Line 2
Line 3
Line 4
Line 5

2313
Figure 115 YUV420 Spatial Sampling for H.261, H.263 and MPEG 1
Y1 Y2 Y3 Y4 Y5 Y6 Y7 Y8
Line 1
Line 2
Line 3
Line 4
Line 5

2314
Figure 116 YUV420 Spatial Sampling for MPEG 2 and MPEG 4

Confidential
31-May-2019
FS Y Y Y Y …. Y U Y V Y U Y V Y …. V Y
Y Y Y Y …. Y U Y V Y U Y V Y …. V Y
Packet Header, PH Y Y Y Y …. Y U Y Y U Y Y …. Y
Packet Header, PH
V V V
Packet Footer, PF
Packet Footer, PF
Y Y Y Y …. Y U Y V Y U Y V Y …. V Y FE
Odd lines (1, 3, 5, ..): Even lines (2, 4, 6, ..):

Luminance only, Y Luminance and Chrominance, UYVY
2315
Figure 117 YUV420 8-bit Frame Format

Confidential
31-May-2019
11.2.3 YUV420 10-bit

2316 YUV420 10-bit data transmission is performed by transmitting YYYY… / UYVYUYVY… sequences in
2317 odd / even lines. Only the luminance component (Y) is transferred in odd lines (1, 3, 5…) and both luminance
2318 (Y) and chrominance (U and V) components transferred in even lines (2, 4, 6…). The format for the even
2319 lines (UYVY) is identical to the YUV422 –10-bit data format. The sequence is illustrated in Figure 118.
2320 The payload data size, in bytes, for even lines (UYVY) is double the payload data size for odd lines (Y). This
2321 is exception to the general CSI-2 rule that each line shall have an equal length.
2322 Table 43 specifies the packet size constraints for YUV420 10-bit packets. The length of each packet must be
2323 a multiple of the values in the table.
Odd Lines (1, 3, 5...) Even Lines (2, 4, 6…)
Luminance Only, Y Luminance and Chrominance, UYVY
Pixels Bytes Bits Pixels Bytes Bits
4 5 40 4 10 80
2325 Bit order in transmission follows the general CSI-2 rule, LSB first. The pixel-to-byte mapping is illustrated
2326 in Figure 119.
LSB’s
Line Start: Packet Y4 Y3 Y2 Y1

Y1[9:2] Y2[9:2] Y3[9:2] Y4[9:2]
(Odd line) Header [1:0] [1:0] [1:0] [1:0]
Line End: Y640 Y639 Y638 Y637 Packet

Y637[9:2] Y638[9:2] Y639[9:2] Y640[9:2]
(Odd Line) [1:0] [1:0] [1:0] [1:0] Footer
LSB’s
Line Start: Packet Y2 V1 Y1 U1

U1[9:2] Y1[9:2] V1[9:2] Y2[9:2] U3[9:2]
(Even Line) Header [1:0] [1:0] [1:0] [1:0]
LSB’s
Line End:
(Even Line) Y638 V637 Y637 U637 Y640 V639 Y639 U639 Packet
U639[9:2] Y639[9:2] V639[9:2] Y640[9:2]
[1:0] [1:0] [1:0] [1:0] [1:0] [1:0] [1:0] [1:0] Footer
LSB’s LSB’s
2327
Figure 118 YUV420 10-bit Transmission

Confidential
31-May-2019
Odd lines: Y1 Y2 Y3 Y4
Y1[9:2] (A) Y2[9:2] (B) Y3[9:2] (C) Y4[9:2] (D) [1:0] [1:0] [1:0] [1:0]
Data A2 A3 A4 A5 A6 A7 A8 A9 B2 B3 B4 B5 B6 B7 B8 B9 C2 C3 C4 C5 C6 C7 C8 C9 D2 D3 D4 D5 D6 D7 D8 D9 A0 A1 B0 B1 C0 C1 D0 D1
8-bits 8-bits 8-bits 8-bits 8-bits

Byte n Byte n+1 Byte n+2 Byte n+3 Byte n+4

b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7
Even lines: U1 Y1 V1 Y2
U1[9:2] (A) Y1[9:2] (B) V1[9:2] (C) Y2[9:2] (D) [1:0] [1:0] [1:0] [1:0]
Data A2 A3 A4 A5 A6 A7 A8 A9 B2 B3 B4 B5 B6 B7 B8 B9 C2 C3 C4 C5 C6 C7 C8 C9 D2 D3 D4 D5 D6 D7 D8 D9 A0 A1 B0 B1 C0 C1 D0 D1
8-bits 8-bits 8-bits 8-bits 8-bits

Byte n Byte n+1 Byte n+2 Byte n+3 Byte n+4

b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7
2328
2329 The pixel spatial sampling options are the same as for the YUV420 8-bit data format.
FS Y Y Y Y LSB …. Y LSB U Y V Y LSB U Y V Y LSB …. V Y LSB

Y Y Y Y LSB …. Y LSB U Y V Y LSB U Y V Y LSB …. V Y LSB
Y Y Y Y LSB …. Y LSB U Y Y LSB U Y Y LSB …. Y LSB
Packet Header, PH
Packet Header, PH
V V V
Packet Footer, PF
Packet Footer, PF
Y Y Y Y LSB …. Y LSB U Y V Y LSB U Y V Y LSB …. V Y LSB FE
Odd lines (1, 3, 5, ..): Even lines (2, 4, 6, ..):

2330
Luminance only, Y Luminance and Chrominance, UYVY

Confidential
31-May-2019
11.2.4 YUV422 8-bit

2331 YUV422 8-bit data transmission is performed by transmitting a UYVY sequence. This sequence is illustrated
2332 in Figure 121.
2333 Table 44 specifies the packet size constraints for YUV422 8-bit packet. The length of each packet must be a
2334 multiple of the values in the table.
Pixels Bytes Bits
2 4 32
2337 in Figure 122.
Line Start: Packet Header U1[7:0] Y1[7:0] V1[7:0] Y2[7:0] U3[7:0]
Line End: Y638[7:0] U639[7:0] Y639[7:0] V639[7:0] Y640[7:0] Packet Footer

2338
Figure 121 YUV422 8-bit Transmission
B7 B0 B7 B0 B7 B0 B7 B0
Pixel Data U1[7:0] Y1[7:0] V1[7:0] Y2[7:0]
B7 B0 B7 B0 B7 B0 B7 B0
Byte Data U1[7:0] Y1[7:0] V1[7:0] Y2[7:0]
B7 B0 B7 B0 B7 B0
U1[7:0] Y1[7:0] V1[7:0]

B0 B7 B0 B7 B0 B7
Data U0 U1 U2 U3 U4 U5 U6 U7 Y0 Y1 Y2 Y3 Y4 Y5 Y6 Y7 V0 V1 V2 V3 V4 V5 V6 V7
2339

Confidential
31-May-2019
Y1 Y2 Y3 Y4 Y5 Y6 Y7 Y8
Line 1
Line 2
Line 3
Line 4
Line 5

2340
Figure 123 YUV422 Co-sited Spatial Sampling
2341 The pixel spatial alignment is the same as in CCIR-656 standard. The frame format for YUV422 is presented
2342 in Figure 124.
FS U Y V Y U …. Y U Y V Y
U Y V Y U …. Y U Y V Y
U Y Y U …. Y U Y Y
Packet Header, PH
V V
Packet Footer, PF
U Y V Y U …. Y U Y V Y FE
2343

Confidential
31-May-2019
11.2.5 YUV422 10-bit

2344 YUV422 10-bit data transmission is performed by transmitting a UYVY sequence. This sequence is
2345 illustrated in Figure 125.
2346 Table 45 specifies the packet size constraints for YUV422 10-bit packet. The length of each packet must be
Pixels Bytes Bits
2 5 40
2350 in Figure 126.
Line Start Packet Header U1[9:2] Y1[9:2] V1[9:2] Y2[9:2] LSB’s
Line End U639[9:2] Y639[9:2] V639[9:2] Y640[9:2] LSB’s Packet Footer

2351
Figure 125 YUV422 10-bit Transmitted Bytes
Pixel Data:
B9 B0 B9 B0 B9 B0 B9 B0
U1[9:0] Y1[9:0] V1[9:0] Y2[9:0]

Byte Data:
B7 B0 B7 B0 B7 B0 B7 B0 B7 B0
U1[9:2] Y1[9:2] V1[9:2] Y2[9:2] Y2[1:0] V1[1:0] Y1[1:0] U1[1:0]
LSB’s
B7 B0 B7 B0 B7 B6 B5 B4 B3 B2 B1 B0
V1[9:2] Y2[9:2] Y2[1:0] V1[1:0] Y1[1:0] U1[1:0]

B0 B7 B0 B7 B0 B7
Data V2 V3 V4 V5 V6 V7 V8 V9 Y2 Y3 Y4 Y5 Y6 Y7 Y8 Y9 U0 U1 Y0 Y1 V0 V1 Y0 Y1
2352
2353 The pixel spatial alignment is the same as in the YUV422 8-bit data case. The frame format for YUV422 is
2354 presented in the Figure 127.

Confidential
31-May-2019
FS U Y V Y LSBs U …. U Y V Y LSBs
U Y V Y LSBs U …. U Y V Y LSBs
Packer Header, PH
Packer Footer, PF
U Y V Y LSBs U …. U Y V Y LSBs FE
2355

Confidential
31-May-2019
11.3 RGB Image Data

2356 Table 46 defines the data type codes for RGB data formats described in this section.
2357 Table 46 RGB Image Data Types
0x20 RGB444
0x21 RGB555
0x22 RGB565
0x23 RGB666
0x24 RGB888
0x25 Reserved
0x26 Reserved

Confidential
31-May-2019
11.3.1 RGB888
2358 RGB888 data transmission is performed by transmitting a BGR byte sequence. This sequence is illustrated
2359 in Figure 128. The RGB888 frame format is illustrated in Figure 130.
2360 Table 47 specifies the packet size constraints for RGB888 packets. The length of each packet must be a
2362 Table 47 RGB888 Packet Data Size Constraints
Pixels Bytes Bits
1 3 24
2364 in Figure 129.
Line Start Packet Header B1[7:0] G1[7:0] R1[7:0] B2[7:0] G2[7:0] R2[7:0]
Line End B639[7:0] G639[7:0] R639[7:0] B640[7:0] G640[7:0] R640[7:0] Packet Footer
2365
Figure 128 RGB888 Transmission
24-bit RGB pixel
B7 B0 B7 B0 B7 B0
B1[7:0] G1[7:0] R1[7:0]

B0 B7 B0 B7 B0 B7
Data B0 B1 B2 B3 B4 B5 B6 B7 G0 G1 G2 G3 G4 G5 G6 G7 R0 R1 R2 R3 R4 R5 R6 R7
2366
Figure 129 RGB888 Transmission in CSI-2 Bus Bitwise Illustration

Confidential
31-May-2019
24-bit
FS B G R B G R …. B G R
B G R B G R …. B G R
Packet Header, PH
Packet Footer, PF
…. …. …. …. …. …. …. …. …. ….
…. …. …. …. …. …. …. …. …. ….
B G R B G R …. B G R FE
2367
Figure 130 RGB888 Frame Format

Confidential
31-May-2019
11.3.2 RGB666
2368 RGB666 data transmission is performed by transmitting a B0…5, G0…5, and R0…5 (18-bit) sequence. This
2369 sequence is illustrated in Figure 131. The frame format for RGB666 is presented in the Figure 133.
Pixels Bytes Bits
4 9 72
2373 Bit order in transmission follows the general CSI-2 rule, LSB first. In RGB666 case the length of one data
2374 word is 18-bits, not eight bits. The word-wise flip is done for 18-bit BGR words; i.e. instead of flipping each
2375 byte (8-bits), each 18-bits pixel value is flipped. This is illustrated in Figure 132.
Line Start Packet Header BGR1[17:0] BGR2[17:0] BGR3[17:0]
Line End BGR638[17:0] BGR639[17:0] BGR640[17:0] Packet Footer

2376
Figure 131 RGB666 Transmission with 18-bit BGR Words
18-bit RGB pixel
B17 B12 B11 B6 B5 B0

R1[5:0] G1[5:0] B1[5:0]
18-bit Data Transmitted LS Bit First
B0 B5 B6 B11 B12 B17

Data B0 B1 B2 B3 B4 B5 G0 G1 G2 G3 G4 G5 R0 R1 R2 R3 R4 R5
2377
b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 ...
Figure 132 RGB666 Transmission on CSI-2 Bus Bitwise Illustration

Confidential
31-May-2019
8b 8b 8b 8b 8b 8b 8b 8b 8b
FS BGR BGR BGR BGR …. BGR BGR

BGR BGR BGR BGR …. BGR BGR
Packer Header, PH
Packer Footer, PF
…. …. …. …. …. …. ….
…. …. …. …. …. …. ….
BGR BGR BGR BGR …. BGR BGR FE
18-bit
2378

Confidential
31-May-2019
11.3.3 RGB565
2379 RGB565 data transmission is performed by transmitting B0…B4, G0…G5, R0…R4 in a 16-bit sequence.
2380 This sequence is illustrated in Figure 134. The frame format for RGB565 is presented in the Figure 136.
Pixels Bytes Bits
1 2 16
2386 byte (8-bits), each two bytes (16-bits) are flipped. This is illustrated in Figure 135.
Line Start Packet Header BGR1[15:0] BGR2[15:0] BGR3[15:0]
Line End BGR638[15:0] BGR639[15:0] BGR640[15:0] Packet Footer

2387
Figure 134 RGB565 Transmission with 16-bit BGR Words
16-bit RGB pixel
B15 B11 B10 B5 B4 B0

R1[4:0] G1[5:0] B1[4:0]
16-bit Data Transmitted LS

Bit First
B0 B4 B5 B10 B11 B15
Data B0 B1 B2 B3 B4 G0 G1 G2 G3 G4 G5 R0 R1 R2 R3 R4
Byte n Byte n+1
b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7
2388

Confidential
31-May-2019
16-bit
FS BGR BGR BGR …. BGR BGR

BGR BGR BGR …. BGR BGR
Packer Header, PH
Packer Footer, PF
…. …. …. …. …. ….
…. …. …. …. …. ….
BGR BGR BGR …. BGR BGR FE
2389

Confidential
31-May-2019
11.3.4 RGB555
2390 RGB555 data can be transmitted over a CSI-2 bus with some special arrangements. The RGB555 data should
2391 be made to look like RGB565 data. This can be accomplished by inserting padding bits to the LSBs of the
2392 green color component as illustrated in Figure 137.
2393 Both the frame format and the package size constraints are the same as the RGB565 case.
15-bit RGB pixel padded to 16-bits
B15 B11 B10 B5 B4 B0

R1[4:0] G1[4:0] 0 B1[4:0]
16-bit Data Transmitted

LS Bit First
B0 B4 B5 B10 B11 B15
Data B0 B1 B2 B3 B4 0 G0 G1 G2 G3 G4 R0 R1 R2 R3 R4
Byte n Byte n+1
2397

Confidential
31-May-2019
11.3.5 RGB444
2398 RGB444 data can be transmitted over a CSI-2 bus with some special arrangements. The RGB444 data should
2399 be made to look like RGB565 data. This can be accomplished by inserting padding bits to the LSBs of each
2400 color component as illustrated in Figure 138.
2401 Both the frame format and the package size constraints are the same as the RGB565 case.
12-bit RGB pixel padded to 16-bits
B15 B11 B10 B5 B4 B0

R1[3:0] 1 G1[3:0] 1 0 B1[3:0] 1
16-bit Data Transmitted

LS Bit First
B0 B4 B5 B10 B11 B15
Data 1 B0 B1 B2 B3 0 1 G0 G1 G2 G3 1 R0 R1 R2 R3
Byte n Byte n+1
2405

Confidential
31-May-2019
11.4 RAW Image Data

2406 The RAW 6/7/8/10/12/14/16/20/24 modes are used for transmitting Raw image data from the image sensor.
2407 The intent is that Raw image data is unprocessed image data (i.e. Raw Bayer data) or complementary color
2408 data, but RAW image data is not limited to these data types.
2409 It is possible to transmit e.g. light shielded pixels in addition to effective pixels. This leads to a situation
2410 where the line length is longer than sum of effective pixels per line. The line length, if not specified otherwise,
2411 has to be a multiple of word (32 bits).
2412 Table 50 defines the data type codes for RAW data formats described in this section.
2413 Table 50 RAW Image Data Types
0x27 RAW24
0x28 RAW6
0x29 RAW7
0x2A RAW8
0x2B RAW10
0x2C RAW12
0x2D RAW14
0x2E RAW16
0x2F RAW20

Confidential
31-May-2019
11.4.1 RAW6
2414 The 6-bit Raw data transmission is done by transmitting the pixel data over CSI-2 bus. This sequence is
2415 illustrated in Figure 139 (VGA case). Table 51 specifies the packet size constraints for RAW6 packets. The
2416 length of each packet must be a multiple of the values in the table.
2417 Table 51 RAW6 Packet Data Size Constraints
Pixels Bytes Bits
4 3 24
2418 Each 6-bit pixel is sent LSB first. This is an exception to general CSI-2 rule byte wise LSB first.
Packet
Line Start P1[5:0] P2[5:0] P3[5:0] P4[5:0] P5[5:0] P6[5:0] P7[5:0]
Header
Packet
Line End P634[5:0] P635[5:0] P636[5:0] P637[5:0] P638[5:0] P639[5:0] P640[5:0]
Footer
2419
Figure 139 RAW6 Transmission
P1[5:0] (A) P2[5:0] (B) P3[5:0] (C) P4[5:0] (D)
Data A0 A1 A2 A3 A4 A5 B0 B1 B2 B3 B4 B5 C0 C1 C2 C3 C4 C5 D0 D1 D2 D3 D4 D5

6-bit Pixel Values Transmitted LS Bit First

2420
Figure 140 RAW6 Data Transmission on CSI-2 Bus Bitwise Illustration
8-b 8-b 8-b
FS P1 P2 P3 P4 P5 …. P637 P638 P639 P640

P1 P2 P3 P4 P5 …. P637 P638 P639 P640
P1 P2 P3 P4 P5 …. P637 P638 P639 P640
Packer Header, PH
P1 P2 P3 P4 P5 …. P637 P638 P639 P640

Packer Footer, PF
P1 P2 P3 P4 P5 …. P637 P638 P639 P640

P1 P2 P3 P4 P5 …. P637 P638 P639 P640
P1 P2 P3 P4 P5 …. P637 P638 P639 P640
P1 P2 P3 P4 P5 …. P637 P638 P639 P640
P1 P2 P3 P4 P5 …. P637 P638 P639 P640
P1 P2 P3 P4 P5 …. P637 P638 P639 P640
P1 P2 P3 P4 P5 …. P637 P638 P639 P640
P1 P2 P3 P4 P5 …. P637 P638 P639 P640 FE
6-bit Pixel Value

2421
Figure 141 RAW6 Frame Format

Confidential
31-May-2019
11.4.2 RAW7
2422 The 7-bit Raw data transmission is done by transmitting the pixel data over CSI-2 bus. This sequence is
2423 illustrated in Figure 142 (VGA case). Table 52 specifies the packet size constraints for RAW7 packets. The
2424 length of each packet must be a multiple of the values in the table.
Pixels Bytes Bits
8 7 56
2426 Each 7-bit pixel is sent LSB first. This is an exception to general CSI-2 rule byte-wise LSB first.
Packet
Header
Packet
Line End P634[6:0] P635[6:0] P636[6:0] P637[6:0] P638[6:0] P639[6:0] P640[6:0]
Footer
2427
P1[6:0] (A) P2[6:0] (B) P3[6:0] (C) P4[6:0] (D)
Data A0 A1 A2 A3 A4 A5 A6 B0 B1 B2 B3 B4 B5 B6 C0 C1 C2 C3 C4 C5 C6 D0 D1 D2 D3 D4 D5 D6

7-bit Pixel Values Transmitted LS Bit First
2428
b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 ...
8-b 8-b 8-b 8-b 8-b 8-b 8-b
FS P1 P2 P3 P4 P5 P6 P7 P8 …. P638 P639 P640

P1 P2 P3 P4 P5 P6 P7 P8 …. P638 P639 P640
P1 P2 P3 P4 P5 P6 P7 P8 …. P638 P639 P640
Packer Header, PH
P1 P2 P3 P4 P5 P6 P7 P8 …. P638 P639 P640

Packer Footer, PF
P1 P2 P3 P4 P5 P6 P7 P8 …. P638 P639 P640

P1 P2 P3 P4 P5 P6 P7 P8 …. P638 P639 P640
P1 P2 P3 P4 P5 P6 P7 P8 …. P638 P639 P640
P1 P2 P3 P4 P5 P6 P7 P8 …. P638 P639 P640
P1 P2 P3 P4 P5 P6 P7 P8 …. P638 P639 P640
P1 P2 P3 P4 P5 P6 P7 P8 …. P638 P639 P640
P1 P2 P3 P4 P5 P6 P7 P8 …. P638 P639 P640
P1 P2 P3 P4 P5 P6 P7 P8 …. P638 P639 P640 FE
7-bit Pixel Value

2429

Confidential
31-May-2019
11.4.3 RAW8
2430 The 8-bit Raw data transmission is done by transmitting the pixel data over a CSI-2 bus. Table 53 specifies
2431 the packet size constraints for RAW8 packets. The length of each packet must be a multiple of the values in
2432 the table.
Pixels Bytes Bits
1 1 8
2434 This sequence is illustrated in Figure 145 (VGA case).

2435 Bit order in transmission follows the general CSI-2 rule, LSB first.
Packet
Header
Packet
Line End P634[7:0] P635[7:0] P636[7:0] P637[7:0] P638[7:0] P639[7:0] P640[7:0]
Footer
2436
P1[7:0] (A) P2[7:0] (B) P3[7:0] (C) P4[7:0] (D)


2437
FS P1 P2 P3 P4 P5 …. P637 P638 P639 P640

P1 P2 P3 P4 P5 …. P637 P638 P639 P640
P1 P2 P3 P4 P5 …. P637 P638 P639 P640
Packer Header, PH
P1 P2 P3 P4 P5 …. P637 P638 P639 P640

Packer Footer, PF
P1 P2 P3 P4 P5 …. P637 P638 P639 P640

P1 P2 P3 P4 P5 …. P637 P638 P639 P640
P1 P2 P3 P4 P5 …. P637 P638 P639 P640
P1 P2 P3 P4 P5 …. P637 P638 P639 P640
P1 P2 P3 P4 P5 …. P637 P638 P639 P640
P1 P2 P3 P4 P5 …. P637 P638 P639 P640
P1 P2 P3 P4 P5 …. P637 P638 P639 P640
P1 P2 P3 P4 P5 …. P637 P638 P639 P640 FE
2438

Confidential
31-May-2019
11.4.4 RAW10
2439 The transmission of 10-bit Raw data is done by packing the 10-bit pixel data to look like 8-bit data format.
2440 Table 54 specifies the packet size constraints for RAW10 packets. The length of each packet must be a
Pixels Bytes Bits
4 5 40

2444 Bit order in transmission follows the general CSI-2 rule: LSB first.
LSB’s
Packet P4 P3 P2 P1
Line Start P1[9:2] P2[9:2] P3[9:2] P4[9:2] P5[9:2] P6[9:2]
Header [1:0] [1:0] [1:0] [1:0]
P636 P635 P634 P633 P640 P639 P638 P637 Packet

Line End P637[9:2] P638[9:2] P639[9:2] P640[9:2]
[1:0] [1:0] [1:0] [1:0] [1:0] [1:0] [1:0] [1:0] Footer
2445
LSB’s LSB’s
P1[9:2] (A) P2[9:2] (B) P3[9:2] (C) P4[9:2] (D)
P1 P2 P3 P4
[1:0] [1:0] [1:0] [1:0] P5[9:2] (E) P6[9:2] (F) P7[9:2] (G)
A0 A1 B0 B1 C0 C1 D0 D1 E2 E3 E4 E5 E6 E7 E8 E9 F2 F3 F4 F5 F6 F7 F8 F9 G2 G3 G4 G5 G6 G7 G8 G9


2446

Confidential
31-May-2019
FS P1 P2 P3 P4 LSBs P5 …. P637 P638 P639 P640 LSBs

P1 P2 P3 P4 LSBs P5 …. P637 P638 P639 P640 LSBs
Packer Header, PH
Packer Footer, PF
P1 P2 P3 P4 LSBs P5 …. P637 P638 P639 P640 LSBs FE
2447

Confidential
31-May-2019
11.4.5 RAW12
2448 The transmission of 12-bit Raw data is done by packing the 12-bit pixel data to look like 8-bit data format.
Pixels Bytes Bits
2 3 24

LSB’s LSB’s
Packet P2 P1 P4 P3
Line Start P1[11:4] P2[11:4] P3[11:4] P4[11:4] P5[11:4]
Header [3:0] [3:0] [3:0] [3:0]
P636 P635 P638 P637 P640 P639 Packet

Line End P637[11:4] P638[11:4] P639[11:4] P640[11:4]
[3:0] [3:0] [3:0] [3:0] [3:0] [3:0] Footer
2454
LSB’s LSB’s LSB’s
P1[11:4] (A) P2[11:4] (B) P1[3:0] (A) P2[3:0 (B)] P3[11:4] (C)
Data A4 A5 A6 A7 A8 A9 A10 A11 B4 B5 B6 B7 B8 B9 B10 B11 A0 A1 A2 A3 B0 B1 B2 B3 C4 C5 C6 C7 C8 C9 C10 C11


2455
Figure 152 RAW12 Transmission on CSI-2 Bus Bitwise Illustration
FS P1 P2 LSBs P3 P4 LSBs …. P638 LSBs P639 P640 LSBs

P1 P2 LSBs P3 P4 LSBs …. P638 LSBs P639 P640 LSBs
Packer Header, PH

Packer Footer, PF

P1 P2 LSBs P3 P4 LSBs …. P638 LSBs P639 P640 LSBs FE
2456

Confidential
31-May-2019
11.4.6 RAW14
2457 The transmission of 14-bit Raw data is done by packing the 14-bit pixel data in 8-bit slices. For every four
2458 pixels, seven bytes of data is generated. Table 56 specifies the packet size constraints for RAW14 packets.
2459 The length of each packet must be a multiple of the values in the table.
Pixels Bytes Bits
4 7 56
2461 The sequence is illustrated in Figure 154 (VGA case).

2462 The LS bits for P1, P2, P3, and P4 are distributed in three bytes as shown in Figure 154 and Figure 155. The
2463 same is true for the LS bits for P637, P638, P639, and P640. The bit order during byte transmission follows
2464 the general CSI-2 rule, i.e. LSB first.
2465 Note:
2466 Figure 154 has been modified relative to the figures shown in the CSI-2 Specification version 2.0
2467 and earlier, in order to more clearly correspond with Figure 155. The RAW14 byte packing and
2468 transmission formats themselves have not changed relative to earlier CSI-2 Specification versions.
Line Start
LSB’s
Packet P2 P1 P3 P2 P4 P3
P1[13:6] P2[13:6] P3[13:6] P4[13:6]
Header [1:0] [5:0] [3:0] [5:2] [5:0] [5:4]
Byte Byte Byte
P638 P637 P639 P638 P640 P639 Packet
Line End P637[13:6] P638[13:6] P639[13:6] P640[13:6]
[1:0] [5:0] [3:0] [5:2] [5:0] [5:4] Footer
2469
P1[13:6] (A) P2[13:6] (B) P3[13:6] (C) P4[13:6] (D)
P1[5:0] (A) P2[5:0] (B) P3[5:0] (C) P4[5:0] (D) P5[13:6] (E)
A0 A1 A2 A3 A4 A5 B0 B1 B2 B3 B4 B5 C0 C1 C2 C3 C4 C5 D0 D1 D2 D3 D4 D5 E6 E7 E8 E9 E10 E11 E12 E13


2470

Confidential
31-May-2019
8-b 8-b 8-b 8-b 8-b 8-b
FS P1 P2 P3 P4 LSBs LSBs LSBs LSBs …. P640 LSBs LSBs LSBs LSBs

P1 P2 P3 P4 LSBs LSBs LSBs LSBs …. P640 LSBs LSBs LSBs LSBs
Packer Header, PH
Packer Footer, PF
P1 P2 P3 P4 LSBs LSBs LSBs LSBs …. P640 LSBs LSBs LSBs LSBs FE
2471

Confidential
31-May-2019
11.4.7 RAW16
2472 The transmission of 16-bit Raw data is done by packing the 16-bit pixel data to look like the 8-bit data format.
Pixels Bytes Bits
1 2 16

Packet
Header
Packet
Line End P637[7:0] P638[15:8] P638[7:0] P639[15:8] P639[7:0] P640[15:8] P640[7:0]
2478 Footer
P1[15:8] (A) P1[7:0] (A) P2[15:8] (B) P2[7:0] (B)
Data A8 A9 A10 A11 A12 A13 A14 A15 A0 A1 A2 A3 A4 A5 A6 A7 B8 B9 B10 B11 B12 B13 B14 B15 B0 B1 B2 B3 B4 B5 B6 B7


2479
FS P1 P1 P2 P2 P3 …. P63 9 P63 9 P64 0 P64 0

P1 P1 P2 P2 P3 …. P63 9 P63 9 P64 0 P64 0
P1 P1 P2 P2 P3 …. P63 9 P63 9 P64 0 P64 0
Packer Header, PH
P1 P1 P2 P2 P3 …. P63 9 P63 9 P64 0 P64 0

Packer Footer, PF
P1 P1 P2 P2 P3 …. P63 9 P63 9 P64 0 P64 0

P1 P1 P2 P2 P3 …. P63 9 P63 9 P64 0 P64 0
P1 P1 P2 P2 P3 …. P63 9 P63 9 P64 0 P64 0
P1 P1 P2 P2 P3 …. P63 9 P63 9 P64 0 P64 0
P1 P1 P2 P2 P3 …. P63 9 P63 9 P64 0 P64 0
P1 P1 P2 P2 P3 …. P63 9 P63 9 P64 0 P64 0
P1 P1 P2 P2 P3 …. P63 9 P63 9 P64 0 P64 0
P1 P1 P2 P2 P3 …. P63 9 P63 9 P64 0 P64 0 FE
2480

Confidential
31-May-2019
11.4.8 RAW20
2481 The transmission of 20-bit Raw data is done by packing the 20-bit pixel data to look like the 10-bit data
2482 format. Table 58 specifies the packet size constraints for RAW20 packets. The length of each packet must be
Pixels Bytes Bits
2 5 40

LSB’s
Packet
Line Start P1[19:12] P1[9:2] P2[19:12] P2[9:2] P2 P2 P1 P1
P3[19:12] P3[9:2]
Header [1:0] [11:10] [1:0] [11:10]
Packet
Line End P 638 P 638 P 637 P 637
P639[19:12] P639[9:2] P640[19:12] P640[9:2] P 640 P 640 P 639 P 639
[1:0] [11:10] [1:0] [11:10] [1:0] [11:10] [1:0] [11:10]
Footer
2487 LSB’s LSB’s

P1[19:12] (A) P1[9:2] (A) P2[19:12] (B) P2[9:2] (B)
Data A12 A13 A14 A15 A16 A17 A18 A19 A2 A3 A4 A5 A6 A7 A8 A9 B12 B13 B14 B15 B16 B17 B18 B19 B2 B3 B4 B5 B6 B7 B8 B9
P1 P1 P2 P2
[11:10] [1:0] [11:10] [1:0] P3[19:12] (C) P3[9:2] (C) P4[19:12] (D)
A10 A11 A0 A1 B10 B11 B0 B1 C12 C13 C14 C15 C16 C17 C18 C19 C2 C3 C4 C5 C6 C7 C8 C9 D12 D13 D14 D15 D16 D17 D18 D19


2488

Confidential
31-May-2019
FS P1 P1 P2 P2 LSBs P3 …. P639 P639 P640 P640 LSBs

Packer Header, PH P1 P1 P2 P2 LSBs P3 …. P639 P639 P640 P640 LSBs
Packer Footer, PF
P1 P1 P2 P2 LSBs P3 …. P639 P639 P640 P640 LSBs FE
2489

Confidential
31-May-2019
11.4.9 RAW24
2490 The transmission of 24-bit Raw data is done by packing the 24-bit pixel data to look like the 12-bit data
2491 format. Table 59 specifies the packet size constraints for RAW24 packets. The length of each packet must be
Pixels Bytes Bits
1 3 24

LSB’s LSB’s
Packet P1 P1 P2 P2
Line Start P1[23:16] P1[11:4] P2[23:16] P2[11:4] P3[23:16]
Header [3:0] [15:12] [3:0] [15:12]
P638 P638 P639 P639 P640 P640 Packet

Line End P639[23:16] P639[11:4] P640[23:16] P640[11:4]
[3:0] [15:12] [3:0] [15:12] [3:0] [15:12] Footer
2496
LSB’s LSB’s LSB’s
P1[23:16] (A) P1[11:4] (A) P1[15:12] (A) P1[3:0] (A) P2[23:16] (B)
Data A16 A17 A18 A19 A20 A21 A22 A23 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15 A0 A1 A2 A3 B16 B17 B18 B19 B20 B21 B22 B23


2497
FS P1 P1 LSBs P2 P2 LSBs …. P639 LSBs P640 P640 LSBs

Packer Header, PH

Packer Footer, PF

P1 P1 LSBs P2 P2 LSBs …. P639 LSBs P640 P640 LSBs FE
2498

Confidential
31-May-2019
11.5 User Defined Data Formats

2499 The User Defined Data Type values shall be used to transmit arbitrary data, such as JPEG and MPEG4 data,
2500 over the CSI-2 bus. Data shall be packed so that the data length is divisible by eight bits. If data padding is
2501 required, the padding shall be added before data is presented to the CSI-2 protocol interface.
2502 Bit order in transmission follows the general CSI-2 rule, LSB first.
Packet
Line Start B1[7:0] B2[7:0] B3[7:0] B4[7:0] B5[7:0] B6[7:0] B7[7:0]
Header
Packet
Line End B121[7:0] B122[7:0] B123[7:0] B124[7:0] B125[7:0] B126[7:0] B127[7:0]
Footer
2503
Figure 166 User Defined 8-bit Data (128 Byte Packet)
Byte1[7:0] (A) Byte2[7:0] (B) Byte3[7:0] (C) Byte4[7:0] (D)


2504
Figure 167 User Defined 8-bit Data Transmission on CSI-2 Bus Bitwise Illustration
2505 The packet data size in bits shall be divisible by eight, i.e. a whole number of bytes shall be transmitted.
2506 For User Defined data:
2507 • The frame is transmitted as a sequence of arbitrary sized packets.
2508 • The packet size may vary from packet to packet.
2509 • The packet spacing may vary between packets.
Variable Packet Spacing

Frame Start Frame End
Packet Variable Packet Size Packet
SoT FS EoT LPS SoT PH Data PF EoT LPS SoT PH Data PF EoT LPS SoT FE EoT
VVALID
HVALID
DVALID
KEY:
PH – Packet Header PF – Packet Footer
2510 LE – Line End
Figure 168 Transmission of User Defined 8-bit Data

Confidential
31-May-2019
2511 Eight different User Defined data type codes are available as shown in Table 60.
2512 Table 60 User Defined 8-bit Data Types
0x30 User Defined 8-bit Data Type 1

Confidential
31-May-2019

Confidential
31-May-2019
12 Recommended Memory Storage

2513 This section is informative.
2514 The CSI-2 data protocol requires certain behavior from the receiver connected to the CSI transmitter. The
2515 following sections describe how different data formats should be stored inside the receiver. While
2516 informative, this section is provided to ease application software development by suggesting a common data
2517 storage format among different receivers.
12.1 General/Arbitrary Data Reception

2518 In the generic case and for arbitrary data the first byte of payload data transmitted maps the LS byte of the
2519 32-bit memory word and the fourth byte of payload data transmitted maps to the MS byte of the 32-bit
2520 memory word.
2521 Figure 169 shows the generic CSI-2 byte to 32-bit memory word mapping rule.
Data on CSI-2 bus
Byte1[7:0] Byte2[7:0] Byte3[7:0] Byte4[7:0]

Data a0 a1 a2 a3 a4 a5 a6 a7 b0 b1 b2 b3 b4 b5 b6 b7 c0 c1 c2 c3 c4 c5 c6 c7 d0 d1 d2 d3 d4 d5 d6 d7

e0 e1 e2 e3 e4 e5 e6 e7 f0 f1 f2 f3 f4 f5 f6 f7 g0 g1 g2 g3 g4 g5 g6 g7 h0 h1 h2 h3 h4 h5 h6 h7

i0 i1 i2 i3 i4 i5 i6 i7 j0 j1 j2 j3 j4 j5 j6 j7 k0 k1 k2 k3 k4 k5 k6 k7 l0 l1 l2 l3 l4 l5 l6 l7
Buffer Data in receiver's buffer

Addr
MSB Byte4[7:0] Byte3[7:0] Byte2[7:0] Byte1[7:0] LSB
00h d7 d6 d5 d4 d3 d2 d1 d0 c7 c6 c5 c4 c3 c2 c1 c0 b7 b6 b5 b4 b3 b2 b1 b0 a7 a6 a5 a4 a3 a2 a1 a0
01h h7 h6 h5 h4 h3 h2 h1 h0 g7 g6 g5 g4 g3 g2 g1 g0 f7 f6 f5 f4 f3 f2 f1 f0 e7 e6 e5 e4 e3 e2 e1 e0
02h l7 l6 l5 l4 l3 l2 l1 l0 k7 k6 k5 k4 k3 k2 k1 k0 j7 j6 j5 j4 j3 j2 j1 j0 i7 i6 i5 i4 i3 i2 i1 i0
2522
32-bit standard memory width
Figure 169 General/Arbitrary Data Reception

Confidential
31-May-2019
12.2 RGB888 Data Reception

2523 The RGB888 data format byte to 32-bit memory word mapping follows the generic CSI-2 rule.
Data on CSI-2 bus

B1[7:0] G1[7:0] R1[7:0] B2[7:0]
G2[7:0] R2[7:0] B3[7:0] G3[7:0]


Addr
MSB B2[7:0] R1[7:0] G1[7:0] B1[7:0] LSB
G3[7:0] B3[7:0] R2[7:0] G2[7:0]
2524
Figure 170 RGB888 Data Format Reception
Data on CSI-2 bus

B1[5:0] G1[5:0] R1[5:0] B2[5:0] G2[5:0] R2
Data a0 a1 a2 a3 a4 a5 b0 b1 b2 b3 b4 b5 c0 c1 c2 c3 c4 c5 d0 d1 d2 d3 d4 d5 e0 e1 e2 e3 e4 e5 f0 f1
R2 B3[5:0] G3[5:0] R3[5:0] B4[5:0] G4

f2 f3 f4 f5 g0 g1 g2 g3 g4 g5 h0 h1 h2 h3 h4 h5 i0 i1 i2 i3 i4 i5 j0 j1 j2 j3 j4 j5 k0 k1 k2 k3
G4 R4[5:0] B5[5:0] G5[5:0] R5[5:0] B6[5:0]

k4 k5 l0 l1 l2 l3 l4 l5 m0 m1 m2 m3 m4 m5 n0 n1 n2 n3 n4 n5 o0 o1 o2 o3 o4 o5 p0 p1 p2 p3 p4 p5

Addr
MSB R2 G2[5:0] B2[5:0] R1[5:0] G1[5:0] B1[5:0] LSB
00h f1 f0 e5 e4 e3 e2 e1 e0 d5 d4 d3 d2 d1 d0 c5 c4 c3 c2 c1 c0 b5 b4 b3 b2 b1 b0 a5 a4 a3 a2 a1 a0
G4 B4[5:0] R3[5:0] G3[5:0] B3[5:0] R2
01h k3 k2 k1 k0 j5 j4 j3 j2 j1 j0 i5 i4 i3 i2 i1 i0 h5 h4 h3 h2 h1 h0 g5 g4 g3 g2 g1 g0 f5 f4 f3 f2
B6[5:0] R5[5:0] G5[5:0] B5[5:0] R4[5:0] G4
02h p5 p4 p3 p2 p1 p0 o5 o4 o3 o2 o1 o0 n5 n4 n3 n2 n1 n0 m5 m4 m3 m2 m1 m0 l5 l4 l3 l2 l1 l0 k5 k4
2525

Confidential
31-May-2019
Data on CSI-2 bus
B1[4:0] G1[5:0] R1[4:0] B2[4:0] G2[5:0] R2[4:0]

Data a0 a1 a2 a3 a4 b0 b1 b2 b3 b4 b5 c0 c1 c2 c3 c4 d0 d1 d2 d3 d4 e0 e1 e2 e3 e4 e5 f0 f1 f2 f3 f4
B3[4:0] G3[5:0] R3[4:0] B4[4:0] G4[5:0] R4[4:0]

g0 g1 g2 g3 g4 h0 h1 h2 h3 h4 h5 i0 i1 i2 i3 i4 j0 j1 j2 j3 j4 k0 k1 k2 k3 k4 k5 l0 l1 l2 l3 l4

Addr
MSB R2[4:0] G2[5:0] B2[4:0] R1[4:0] G1[5:0] B1[4:0] LSB
00h f4 f3 f2 f1 f0 e5 e4 e3 e2 e1 e0 d4 d3 d2 d1 d0 c4 c3 c2 c1 c0 b5 b4 b3 b2 b1 b0 a4 a3 a2 a1 a0
R4[4:0] G4[5:0] B4[4:0] R3[4:0] G3[5:0] B3[4:0]
01h l4 l3 l2 l1 l0 k5 k4 k3 k2 k1 k0 j4 j3 j2 j1 j0 i4 i3 i2 i1 i0 h5 h4 h3 h2 h1 h0 g4 g3 g2 g1 g0
2526
Data on CSI-2 bus

B1[4:0] G1[4:0] R1[4:0] B2[4:0] G2[4:0] R2[4:0]
Data a0 a1 a2 a3 a4 0 b0 b1 b2 b3 b4 c0 c1 c2 c3 c4 d0 d1 d2 d3 d4 0 e0 e1 e2 e3 e4 f0 f1 f2 f3 f4
B3[4:0] G3[4:0] R3[4:0] B4[4:0] G4[4:0] R4[4:0]

g0 g1 g2 g3 g4 0 h0 h1 h2 h3 h4 i0 i1 i2 i3 i4 j0 j1 j2 j3 j4 0 k0 k1 k2 k3 k4 l0 l1 l2 l3 l4

Addr
MSB R2[4:0] G2[4:0] B2[4:0] R1[4:0] G1[4:0] B1[4:0] LSB
00h f4 f3 f2 f1 f0 e4 e3 e2 e1 e0 0 d4 d3 d2 d1 d0 c4 c3 c2 c1 c0 b4 b3 b2 b1 b0 0 a4 a3 a2 a1 a0
R4[4:0] G4[4:0] B4[4:0] R3[4:0] G3[4:0] B3[4:0]
01h l4 l3 l2 l1 l0 k4 k3 k2 k1 k0 0 j4 j3 j2 j1 j0 i4 i3 i2 i1 i0 h4 h3 h2 h1 h0 0 g4 g3 g2 g1 g0
2527

Confidential
31-May-2019

2528 The RGB444 data format byte to 32-bit memory word mapping has a special transform as shown in Figure
2529 174.
Data on CSI-2 bus

B1[3:0] G1[3:0] R1[3:0] B2[3:0] G2[3:0] R2[3:0]
Data 1 a0 a1 a2 a3 0 1 b0 b1 b2 b3 1 c0 c1 c2 c3 1 d0 d1 d2 d3 0 1 e0 e1 e2 e3 1 f0 f1 f2 f3
B3[3:0] G3[3:0] R3[3:0] B4[3:0] G4[3:0] R4[3:0]

1 g0 g1 g2 g3 0 1 h0 h1 h2 h3 1 i0 i1 i2 i3 1 j0 j1 j2 j3 0 1 k0 k1 k2 k3 1 l0 l1 l2 l3

Addr
MSB R2[3:0] G2[3:0] B2[3:0] R1[3:0] G1[3:0] B1[3:0] LSB
00h X X X X f3 f2 f1 f0 e3 e2 e1 e0 d3 d2 d1 d0 X X X X c3 c2 c1 c0 b3 b2 b1 b0 a3 a2 a1 a0
R4[3:0] G4[3:0] B4[3:0] R3[3:0] G3[3:0] B3[3:0]
01h X X X X l3 l2 l1 l0 k3 k2 k1 k0 j3 j2 j1 j0 X X X X i3 i2 i1 i0 h3 h2 h1 h0 g3 g2 g1 g0
2530
12.7 YUV422 8-bit Data Reception

2531 The YUV422 8-bit data format the byte to 32-bit memory word mapping does not follow the generic CSI-2
2532 rule.
2533 For YUV422 8-bit data format the first byte of payload data transmitted maps the MS byte of the 32-bit
2534 memory word and the fourth byte of payload data transmitted maps to the LS byte of the 32-bit memory
2535 word.
Data on CSI-2 bus

U1 Y1 V1 Y2
U3 Y3 V3 Y4

Addr
MSB U1 Y1 V1 Y2 LSB
00h a7 a6 a5 a4 a3 a2 a1 a0 b7 b6 b5 b4 b3 b2 b1 b0 c7 c6 c5 c4 c3 c2 c1 c0 d7 d6 d5 d4 d3 d2 d1 d0
U3 Y3 V3 Y4
01h e7 e6 e5 e4 e3 e2 e1 e0 f7 f6 f5 f4 f3 f2 f1 f0 g7 g6 g5 g4 g3 g2 g1 g0 h7 h6 h5 h4 h3 h2 h1 h0
2536
Figure 175 YUV422 8-bit Data Format Reception

Confidential
31-May-2019

2537 The YUV422 10-bit data format the byte to 32-bit memory word mapping follows the generic CSI-2 rule.
Data on CSI-2 bus

U1[9:2] Y1[9:2] V1[9:2] Y2[9:2]
U1[1:0] Y1[1:0] V1[1:0] Y2[1:0] U3[9:2] Y3[9:2] V3[9:2]

a0 a1 b0 b1 c0 c1 d0 d1 e2 e3 e4 e5 e6 e7 e8 e9 f2 f3 f4 f5 f6 f7 f8 f9 g2 g3 g4 g5 g6 g7 g8 g9
Y4[9:2] U3[1:0] Y3[1:0] V3[1:0] Y4[1:0] U5[9:2] Y5[9:2]

h2 h3 h4 h5 h6 h7 h8 h9 e0 e1 f0 f1 g0 g1 h0 h1 i2 i3 i4 i5 i6 i7 i8 i9 j2 j3 j4 j5 j6 j7 j8 j9

Addr MSB Y2[9:2] V1[9:2] Y1[9:2] U1[9:2] LSB
V3[9:2] Y3[9:2] U3[9:2] Y2[1:0] V1[1:0] Y1[1:0] U1[1:0]

01h g9 g8 g7 g6 g5 g4 g3 g2 f9 f8 f7 f6 f5 f4 f3 f2 e9 e8 e7 e6 e5 e4 e3 e2 d1 d0 c1 c0 b1 b0 a1 a0
Y5[9:2] U5[9:2] Y4[1:0] V3[1:0] Y3[1:0] U3[1:0] Y4[9:2]

02h j9 j8 j7 j6 j5 j4 j3 j2 i9 i8 i7 i6 i5 i4 i3 i2 h1 h0 g1 g0 f1 f0 e1 e0 h9 h8 h7 h6 h5 h4 h3 h2
2538

Confidential
31-May-2019
12.9 YUV420 8-bit (Legacy) Data Reception

2539 The YUV420 8-bit (legacy) data format the byte to 32-bit memory word mapping does not follow the generic
2540 CSI-2 rule.
2541 For YUV422 8-bit (legacy) data format the first byte of payload data transmitted maps the MS byte of the
2542 32-bit memory word and the fourth byte of payload data transmitted maps to the LS byte of the 32-bit memory
2543 word.
Data on CSI-2 bus (Odd Line)

U1 Y1 Y2 U3
Y3 Y4 U5 Y5
Buffer
Data in receiver's buffer
Addr
MSB U1 Y1 Y2 U3 LSB
00h a7 a6 a5 a4 a3 a2 a1 a0 b7 b6 b5 b4 b3 b2 b1 b0 c7 c6 c5 c4 c3 c2 c1 c0 d7 d6 d5 d4 d3 d2 d1 d0
Y3 Y4 U5 Y5
01h e7 e6 e5 e4 e3 e2 e1 e0 f7 f6 f5 f4 f3 f2 f1 f0 g7 g6 g5 g4 g3 g2 g1 g0 h7 h6 h5 h4 h3 h2 h1 h0
Data on CSI-2 bus (Even Line)

V1 Y1 Y2 V3
Y3 Y4 V5 Y5
e
e1 e2 e3 e4 e5 e6 e7 f0 f1 f2 f3 f4 f5 f6 f7 g0 g1 g2 g3 g4 g5 g6 g7 h0 h1 h2 h3 h4 h5 h6 h7
0
Buffer
Data in receiver's buffer
Addr
MSB V1 Y1 Y2 V3 LSB
N a7 a6 a5 a4 a3 a2 a1 a0 b7 b6 b5 b4 b3 b2 b1 b0 c7 c6 c5 c4 c3 c2 c1 c0 d7 d6 d5 d4 d3 d2 d1 d0
Y3 Y4 V5 Y5
N+1 e7 e6 e5 e4 e3 e2 e1 e0 f7 f6 f5 f4 f3 f2 f1 f0 g7 g6 g5 g4 g3 g2 g1 g0 h7 h6 h5 h4 h3 h2 h1 h0
2544
Figure 177 YUV420 8-bit Legacy Data Format Reception

Confidential
31-May-2019


Y1 Y2 Y3 Y4
Y5 Y6 Y7 Y8

Addr
MSB Y4 Y3 Y2 Y1 LSB
Y8 Y7 Y6 Y5

U1 Y1 V1 Y2
U3 Y3 V3 Y4

Addr
MSB Y2 V1 Y1 U1 LSB
N d7 d6 d5 d4 d3 d2 d1 d0 c7 c6 c5 c4 c3 c2 c1 c0 b7 b6 b5 b4 b3 b2 b1 b0 a7 a6 a5 a4 a3 a2 a1 a0
Y4 V3 Y3 U3
N+1 h7 h6 h5 h4 h3 h2 h1 h0 g7 g6 g5 g4 g3 g2 g1 g0 f7 f6 f5 f4 f3 f2 f1 f0 e7 e6 e5 e4 e3 e2 e1 e0
2546

Confidential
31-May-2019


Y1[9:2] Y2[9:2] Y3[9:2] Y4[9:2]
Y1[1:0] Y2[1:0] Y3[1:0] Y4[1:0] Y5[9:2] Y6[9:2] Y7[9:2]

Y8[9:2] Y5[1:0] Y6[1:0] Y7[1:0] Y8[1:0] Y9[9:2] Y10[9:2]


Addr
MSB Y4[9:2] Y3[9:2] Y2[9:2] Y1[9:2] LSB
Y7[9:2] Y6[9:2] Y5[9:2] Y4[1:0] Y3[1:0] Y21:0] Y1[1:0]

Y10[9:2] Y9[9:2] Y8[1:0] Y7[1:0] Y6[1:0] Y5[1:0] Y8[9:2]


U1[9:2] Y1[9:2] V1[9:2] Y2[9:2]
U1[1:0] Y1[1:0] V1[1:0] Y2[1:0] U3[9:2] Y3[9:2] V3[9:2]

Y4[9:2] U3[1:0] Y3[1:0] V3[1:0] Y4[1:0] U5[9:2] Y5[9:2]


Addr
MSB Y2[9:2] V1[9:2] Y1[9:2] U1[9:2] LSB
N d9 d8 d7 d6 d5 d4 d3 d2 c9 c8 c7 c6 c5 c4 c3 c2 b9 b8 b7 b6 b5 b4 b3 b2 a9 a8 a7 a6 a5 a4 a3 a2
V3[9:2] Y3[9:2] U3[9:2] Y2[1:0] V1[1:0] Y1[1:0] U1[1:0]

N+1 g9 g8 g7 g6 g5 g4 g3 g2 f9 f8 f7 f6 f5 f4 f3 f2 e9 e8 e7 e6 e5 e4 e3 e2 d1 d0 c1 c0 b1 b0 a1 a0
Y5[9:2] U5[9:2] Y4[1:0] V3[1:0] Y3[1:0] U3[1:0] Y4[9:2]

N+2 j9 j8 j7 j6 j5 j4 j3 j2 i9 i8 i7 i6 i5 i4 i3 i2 h1 h0 g1 g0 f1 f0 e1 e0 h9 h8 h7 h6 h5 h4 h3 h2
2548

Confidential
31-May-2019
12.12 RAW6 Data Reception
Data on CSI-2 bus

P1 P2 P3 P4 P5 P6
Data a0 a1 a2 a3 a4 a5 b0 b1 b2 b3 b4 b5 c0 c1 c2 c3 c4 c5 d0 d1 d2 d3 d4 d5 e0 e1 e2 e3 e4 e5 f0 f1
P6 P7 P8 P9 P10 P11
f2 f3 f4 f5 g0 g1 g2 g3 g4 g5 h0 h1 h2 h3 h4 h5 i0 i1 i2 i3 i4 i5 j0 j1 j2 j3 j4 j5 k0 k1 k2 k3

Addr
MSB P5 P4 P3 P2 P1 LSB
00h f1 f0 e5 e4 e3 e2 e1 e0 d5 d4 d3 d2 d1 d0 c5 c4 c3 c2 c1 c0 b5 b4 b3 b2 b1 b0 a5 a4 a3 a2 a1 a0
P11 P10 P9 P8 P7 P6
01h k3 k2 k1 k0 j5 j4 j3 j2 j1 j0 i5 i4 i3 i2 i1 i0 h5 h4 h3 h2 h1 h0 g5 g4 g3 g2 g1 g0 f5 f4 f3 f2
2549
Figure 180 RAW6 Data Format Reception
Data on CSI-2 bus

P1 P2 P3 P4 P5
Data a0 a1 a2 a3 a4 a5 a6 b0 b1 b2 b3 b4 b5 b6 c0 c1 c2 c3 c4 c5 c6 d0 d1 d2 d3 d4 d5 d6 e0 e1 e2 e3
P5 P6 P7 P8 P9 P10
e4 e5 e6 f0 f1 f2 f3 f4 f5 f6 g0 g1 g2 g3 g4 g5 g6 h0 h1 h2 h3 h4 h5 h6 i0 i1 i2 i3 i4 i5 i6 j0

Addr
MSB P5 P4 P3 P2 P1 LSB
00h e3 e2 e1 e0 d6 d5 d4 d3 d2 d1 d0 c6 c5 c4 c3 c2 c1 c0 b6 b5 b4 b3 b2 b1 b0 a6 a5 a4 a3 a2 a1 a0
P10 P9 P8 P7 P6 P5
01h j0 i6 i5 i4 i3 i2 i1 i0 h6 h5 h4 h3 h2 h1 h0 g6 g5 g4 g3 g2 g1 g0 f6 f5 f4 f3 f2 f1 f0 e6 e5 e4
2550

Confidential
31-May-2019

2551 The RAW8 data format the byte to 32-bit memory word mapping follows the generic CSI-2 rule.
Data on CSI-2 bus

P1 P2 P3 P4
P5 P6 P7 P8

Addr
MSB P4 P3 P2 P1 LSB
P8 P7 P6 P5
2552

Data on CSI-2 bus:

P1[9:2] P2[9:2] P3[9:2] P4[9:2]
P1[1:0] P2[1:0] P3[1:0] P4[1:0] P5[9:2] P6[9:2] P7[9:2]

P8[9:2] P5[1:0] P6[1:0] P7[1:0] P8[1:0] P9[9:2] P10[9:2]

Buffer
Data in receiver's buffer:
Addr
MSB P4[9:2] P3[9:2] P2[9:2] P1[9:2] LSB
P7[9:2] P6[9:2] P5[9:2] P4[1:0] P3[1:0] P2[1:0] P1[1:0]

P10[9:2] P9[9:2] P8[1:0] P7[1:0] P6[1:0] P5[1:0] P8[9:2]

2554

Confidential
31-May-2019

Data on CSI-2 bus

P1[11:4] P2[11:4] P1[3:0] P2[3:0] P3[11:4]
Data a4 a5 a6 a7 a8 a9 a10 a11 b4 b5 b6 b7 b8 b9 b10 b11 a0 a1 a2 a3 b0 b1 b2 b3 c4 c5 c6 c7 c8 c9 c10 c11
P4[11:4] P3[3:0] P4[3:0] P5[11:4] P6[11:4]

d4 d5 d6 d7 d8 d9 d10 d11 c0 c1 c2 c3 d0 d1 d2 d3 e4 e5 e6 e7 e8 e9 e10 e11 f4 f5 f6 f7 f8 f9 f 10 f 11
P5[3:0] P6[3:0] P7[11:4] P8[11:4] P7[3:0] P8[3:0]

e0 e1 e2 e3 f0 f1 f2 f3 g4 g5 g6 g7 g8 g9 g10g11 h4 h5 h6 h7 h8 h9
j2 h10 h11 g0 g1 g2 g3 h0 h1 h2 h3

Addr
MSB P3[11:4] P2[3:0] P1[3:0] P2[11:4] P1[11:4] LSB
00h c11 c10 c9 c8 c7 c6 c5 c4 b3 b2 b1 b0 a3 a2 a1 a0 b11 b10 b9 b8 b7 b6 b5 b4 a11 a10 a9 a8 a7 a6 a5 a4
P6[11:4] P5[11:4] P4[3:0] P3[3:0] P4[11:4]

01h f 11 f 10 f9 f8 f7 f6 f5 f4 e11 e10 e9 e8 e7 e6 e5 e4 d3 d2 d1 d0 c3 c2 c1 c0 d11 d10 d9 d8 d7 d6 d5 d4
P8[3:0] P7[3:0] P8[11:4] P7[11:4] P6[3:0] P5[3:0]

02h h3 h2 h1 h0 g3 g2 g1 g0 h11 h10 h9 h8 h7 h6 h5 h4 g11g10 g9 g8 g7 g6 g5 g4 f3 f2 f1 f0 e3 e2 e1 e0
2556
Data on CSI-2 bus

P1[13:6] P2[13:6] P3[13:6] P4[13:6]
P1[5:0] P2[5:0] P3[5:0] P4[5:0] P5[13:6]

a0 a1 a2 a3 a4 a5 b0 b1 b2 b3 b4 b5 c0 c1 c2 c3 c4 c5 d0 d1 d2 d3 d4 d5 e6 e7 e8 e9 e10 e11 e12 e13
P6[13:6] P7[13:6] P8[13:6] P5[5:0] P6[5:0]

f6 f7 f8 f9 f10 f11 f12 f13 g6 g7 g8 g9 g10 g11 g12 g13 h6 h7 h8 h9 h10 h11 h12 h13 e0 e1 e2 e3 e4 e5 f0 f1
P6[5:0] P7[5:0] P8[5:0]

f2 f3 f4 f5 g0 g1 g2 g3 g4 g5 h0 h1 h2 h3 h4 h5

Addr
MSB P4[13:6] P3[13:6] P2[13:6] P1[13:6] LSB
P5[13:6] P4[5:0] P3[5:0] P2[5:0] P1[5:0]
01h e13 e12 e11 e10 e9 e8 e7 e6 d5 d4 d3 d2 d1 d0 c5 c4 c3 c2 c1 c0 b5 b4 b3 b2 b1 b0 a5 a4 a3 a2 a1 a0
P6[5:0] P5[5:0] P8[13:6] P7[13:6] P6[13:6]

02h f1 f0 e5 e4 e3 e2 e1 e0 h13 h12 h11 h10 h9 h8 h7 h6 g13g12 g11g10 g9 g8 g7 g6 f13 f12 f11 f10 f9 f8 f7 f6
P8[5:0] P7[5:0] P6[5:0]
03h h5 h4 h3 h2 h1 h0 g5 g4 g3 g2 g1 g0 f5 f4 f3 f2
32-bit standardmemory width

2557
Figure 185 RAW 14 Data Format Reception

Confidential
31-May-2019

2558 The RAW16 data format byte to 32-bit memory word mapping follows the generic CSI-2 rule.
Data on CSI-2 bus

P1[15:8] P1[7:0] P2[15:8] P2[7:0]
Data a8 a9 a10a11a12a13a14a15 a0 a1 a2 a3 a4 a5 a6 a7 b8 b9 b10b11b12b13b14b15 b0 b1 b2 b3 b4 b5 b6 b7
P3[15:8] P3[7:0] P4[15:8] P4[7:0]

c8 c9 c10c11c12c13c14c15 c0 c1 c2 c3 c4 c5 c6 c7 d8 d9 d10d11d12d13d14d15 d0 d1 d2 d3 d4 d5 d6 d7

Addr
MSB P2[7:0] P2[15:8] P1[7:0] P1[15:8] LSB
00h b7 b6 b5 b4 b3 b2 b1 b0 b15b14b13b12b11b10 b9 b8 a7 a6 a5 a4 a3 a2 a1 a0 a15a14a13a12a11a10 a9 a8
P4[7:0] P4[15:8] P3[7:0] P3[15:8]
01h d7 d6 d5 d4 d3 d2 d1 d0 d15d14d13d12d11d10 d9 d8 c7 c6 c5 c4 c3 c2 c1 c0 c15c14c13c12c11c10 c9 c8
2559 32-bit standard memory width

Data on CSI-2 bus:

P1[19:12] P1[9:2] P2[19:12] P2[9:2]
Data a12a13a14a15a16a17a18a19 a2 a3 a4 a5 a6 a7 a8 a9 b12b13b14b15b16b17b18b19 b2 b3 b4 b5 b6 b7 b8 b9
P1[11:10] P1[1:0] P2[11:10] P2[1:0] P3[19:12] P3[9:2] P4[19:12]

a10a11 a0 a1 b10b11 b0 b1 c12c13c14c15c16c17 c18c19 c2 c3 c4 c5 c6 c7 c8 c9 d12d13d14d15d16d17 d18d19
P4[9:2] P3[11:10] P3[1:0] P4[11:10] P4[1:0] P5[19:12] P5[9:2]

d2 d3 d4 d5 d6 d7 d8 d9 c10 c11 c0 c1 d10d11 d0 d1 e12e13e14e15e16e17e18e19 e2 e3 e4 e5 e6 e7 e8 e9
Buffer
Data in receiver's buffer:
Addr
MSB P2[9:2] P2[19:12] P1[9:2] P1[19:12] LSB
00h b9 b8 b7 b6 b5 b4 b3 b2 b19b18 b17b16b15b14b13b12 a9 a8 a7 a6 a5 a4 a3 a2 a19a18 a17a16a15a14a13a12
P4[19:12] P3[9:2] P3[19:12] P2[1:0] P2[11:10] P1[1:0] P1[11:10]
01h d19d18 d17d16d15d14d13d12 c9 c8 c7 c6 c5 c4 c3 c2 c19c18 c17c16c15c14c13c12 b1 b0 b11b10 a1 a0 a11a10
P5[9:2] P5[19:12] P4[1:0] P4[11:10] P3[1:0] P3[11:10] P4[9:2]

02h e9 e8 e7 e6 e5 e4 e3 e2 e19 e18 e17 e16 e15 e14 e13 e12 d1 d0 d11d10 c1 c0 c11 c10 d9 d8 d7 d6 d5 d4 d3 d2
2561 32-bit standard memory width

Confidential
31-May-2019

Data on CSI-2 bus

P1[23:16] P1[11:4] P1[15:12] P1[3:0] P2[23:16]
Data a16 a17 a18 a19 a20 a21 a22 a23 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a0 a1 a2 a3 b16b17b18b19b20b21 b22b23
P2[11:4] P2[15:12] P2[3:0] P3[23:16] P3[11:4]

b4 b5 b6 b7 b8 b9 b10 b11b12b13 b14b15 b0 b1 b2 b3 c16 c17 c18 c19 c20 c21 c22 c23 c4 c5 c6 c7 c8 c9 c10 c11
P3[15:12] P3[3:0] P4[23:16] P4[11:4] P4[15:12] P4[3:0]

c12 c13 c14 c15 c0 c1 c2 c3 d16d17d18d19 d20d21d22d23 d4 d5 d6 d7 d8 d9 d10 d11 d12d13 d14d15 d0 d1 d2 d3

Addr
MSB P2[23:16] P1[3:0] P1[15:12] P1[11:4] P1[23:16] LSB
00h b23b22b21b20 b19b18b17b16 a3 a2 a1 a0 a15 a14 a13 a12 a11 a10 a9 a8 a7 a6 a5 a4 a23 a22 a21 a20 a19 a18 a17 a16
P3[11:4] P3[23:16] P2[3:0] P2[15:12] P2[11:4]

01h c11 c10 c9 c8 c7 c6 c5 c4 c23 c22 c21 c20 c19 c18 c17 c16 b3 b2 b1 b0 b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4
P4[3:0] P4[15:12] P4[11:4] P4[23:16] P3[3:0] P3[15:12]

02h d3 d2 d1 d0 d15 d14 d13 d12 d11 d10 d9 d8 d7 d6 d5 d4 d23d22 d21d20 d19d18d17d16 c3 c2 c1 c0 c15 c14 c13 c12
2563

Confidential
31-May-2019

2564

Confidential
31-May-2019
Annex A JPEG8 Data Format (informative)

A.1 Introduction
2565 This Annex contains an informative example of the transmission of compressed image data format using the
2566 arbitrary Data Type values.
2567 JPEG8 has two non-standard extensions:
2568 • Status information (mandatory)
2569 • Embedded Image information e.g. a thumbnail image (optional)
2570 Any non-standard or additional data inside the baseline JPEG data structure has to be removed from JPEG8
2571 data before it is compliant with e.g. standard JPEG image viewers in e.g. a personal computer.
2572 The JPEG8 data flow is illustrated in Figure 189 and Figure 190.
JPEG encoding
Camera image according to SOSI, EOSI, SOEI and
data processing baseline JPEG EOEI marker application CSI
(color separation, DCT with JPEG8 and additional data transmitter
AWB, etc.) additional embedding
definitions
Thumbnail image
scaling and sRGB
conversion
Image status
information
2573
Figure 189 JPEG8 Data Flow in the Encoder
Additional data
Addition of EXIF
CSI extraction based on
information,
receiver SOSI, EOSI, SOEI
Storing into a file
and EOEI markers
Thumbnail image
Image status
information
2574
Figure 190 JPEG8 Data Flow in the Decoder

Confidential
31-May-2019
A.2 JPEG Data Definition

2575 The JPEG data generated in camera module is baseline JPEG DCT format defined in ISO/IEC 10918-1, with
2576 following additional definitions or modifications:
2577 • sRGB color space shall be used. The JPEG is generated from YCbCr format after sRGB to YCbCr
2578 conversion.
2579 • The JPEG metadata has to be EXIF compatible, i.e. metadata within application segments has to
2580 be placed in beginning of file, in the order illustrated in Figure 191.
2581 • A status line is added in the end of JPEG data as defined in Section A.3.
2582 • If needed, an embedded image is interlaced in order which is free of choice as defined in Section
2583 A.4.
2584 • Prior to storing into a file, the CSI-2 JPEG data is processed by the data separation process
2585 described in Section A.1.
Start of Image (SOI)

JFIF / EXIF Data
Quantization Table (DQT)
Huffman Table (DHT)
Frame Header (SOF)
Scan Header
Compressed Data
End Of Image (EOI)

2586
Figure 191 EXIF Compatible Baseline JPEG DCT Format

Confidential
31-May-2019
A.3 Image Status Information

2587 Information of at least the following items has to be stored in the end of the JPEG sequence as illustrated in
2588 Figure 192:
2589 • Image exposure time
2590 • Analog & digital gains used
2591 • White balancing gains for each color component
2592 • Camera version number
2593 • Camera register settings
2594 • Image resolution and possible thumbnail resolution
2595 The camera register settings may include a subset of camera’s registers. The essential information needed for
2596 JPEG8 image is the information needed for converting the image back to linear space. This is necessary e.g.
2597 for printing service. An example of register settings is following:
2598 • Sample frequency
2599 • Exposure
2600 • Analog and digital gain
2601 • Gamma
2602 • Color gamut conversion matrix
2603 • Contrast
2604 • Brightness
2605 • Pre-gain
2606 The status information content has to be defined in the product specification of each camera module
2607 containing the JPEG8 feature. The format and content is manufacturer specific.
2608 The image status data should be arranged so that each byte is split into two 4-bit nibbles and “1010” padding
2609 sequence is added to MSB, as presented in Table 61. This ensures that no JPEG escape sequences (0xFF
2610 0x00) are present in the status data.
2611 The SOSI and EOSI markers are defined in Section A.5.
2612 Table 61 Status Data Padding
Data Word After Padding
D7D6D5D4 D3D2D1D0 1010D7D6D5D4 1010D3D2D1D0

Confidential
31-May-2019

JFIF / EXIF Data
Huffman Table (DHT)
Frame Header (SOF)
Scan Header
Compressed Data
End Of Image (EOI)

Start of Status Information (SOSI)
Image Status Information
End of Status Information (EOSI)
2613
Figure 192 Status Information Field in the End of Baseline JPEG Frame

Confidential
31-May-2019
A.4 Embedded Images

2614 An image may be embedded inside the JPEG data, if needed. The embedded image feature is not compulsory
2615 for each camera module containing the JPEG8 feature. An example of embedded data is a 24-bit RGB
2616 thumbnail image.
2617 The philosophy of embedded / interleaved thumbnail additions is to minimize the needed frame memory. The
2618 EI (Embedded Image) data can be included in any part of the compressed image data segment and in as many
2619 pieces as needed. See Figure 193.
2620 Embedded Image data is separated from compressed data by SOEI (Start Of Embedded Image) and EOEI
2621 (End Of Embedded Image) non-standard markers, which are defined in Section A.5. The amount of fields
2622 separated by SOEI and EOEI is not limited.
2623 The pixel to byte packing for image data within an EI data field should be as specified for the equivalent CSI-
2624 2 data format. However there is an additional restriction; the embedded image data must not generate any
2625 false JPEG marker sequences (0xFFXX).
2626 The suggested method of preventing false JPEG marker codes from occurring within the embedded image
2627 data it to limit the data range for the pixel values. For example
2628 • For RGB888 data the suggested way to solve the false synchronization code issue is to constrain
2629 the numerical range of R, G and B values from 1 to 254.
2630 • For RGB565 data the suggested way to solve the false synchronization code issue is to constrain
2631 the numerical range of G component from 1-62 and R component from 1-30.
2632 Each EI data field is separated by the SOEI / EOEI markers, and has to contain an equal amount bytes and a
2633 complete number of pixels. An EI data field may contain multiple lines or a full frame of image data.
2634 The embedded image data is decoded and removed apart from the JPEG compressed data prior to writing the
2635 JPEG into a file. In the process, EI data fields are appended one after each other, in order of occurrence in
2636 the received JPEG data.

JFIF / EXIF Data
Compressed Data
Huffman Table (DHT)
Frame Header (SOF)
SOEI
Scan Header
Embedded Image data
EOEI
Compressed Data Compressed Data
SOEI
Embedded Image data
End Of Image (EOI)
EOEI
Start of Status Information (SOSI)
Compressed Data
Image Status Information
End of Status Information (EOSI)
2637
Figure 193 Example of TN Image Embedding Inside the Compressed JPEG Data Block

Confidential
31-May-2019
A.5 JPEG8 Non-standard Markers

2638 JPEG8 uses the reserved JPEG data markers for special purposes, marking the additional segments inside the
2639 data file. These segments are not part of the JPEG, JFIF [0], EXIF [0] or any other specifications; instead
2640 their use is specified in this document in Section A.3 and Section A.4.
2641 The use of the non-standard markers is always internal to a product containing the JPEG8 camera module,
2642 and these markers are always removed from the JPEG data before storing it into a file.
2643 Table 62 JPEG8 Additional Marker Codes Listing
Non-standard Marker Symbol Marker Data Code
SOSI 0xFF 0xBC
EOSI 0xFF 0xBD
SOEI 0xFF 0xBE
EOEI 0xFF 0xBF
A.6 JPEG8 Data Reception

2644 The compressed data format the byte to 32-bit memory word mapping follows the generic CSI-2 rule.
Data on CSI-2 bus

B1 B2 B3 B4
B5 B6 B7 B8

Addr
MSB B4 B3 B2 B1 LSB
B8 B7 B6 B5

2645
Figure 194 JPEG8 Data Format Reception

Confidential
31-May-2019
Annex B CSI-2 Implementation Example (informative)

B.1 Overview
2646 The CSI-2 implementation example assumes that the interface comprises of D-PHY unidirectional Clock and
2647 Data, with forward Escape Mode and optional deskew functionality. The scope in this implementation
2648 example refers only to the unidirectional data link without any references to the CCI interface, as it can be
2649 seen in Figure 195. This implementation example varies from the informative PPI example in [MIPI01].
Device e.g. Camera containing the Device e.g. an application Engine or

CSI transmitter and CCI slave Unidirectional High a Base Band containing the CSI
Speed Data Link receiver and CCI master
Coverage of this
CSI Transmitter 2 Data Lanes CSI Receiver implementation
Data2+ Data2+ example
Data2- Data2-
Data1+ Data1+
Data1- Data1-
Clock+ Clock+
Clock- Clock-
SCL SCL
SDA SDA
2650
Figure 195 Implementation Example Block Diagram and Coverage
2651 For this implementation example a layered structure is described with the following parts:
2652 • D-PHY implementation details
2653 • Multi lane merger details
2654 • Protocol layer details
2655 This implementation example refers to a RAW8 data type only; hence no packing/unpacking or byte
2656 clock/pixel clock timing will be referenced as for this type of implementation they are not needed.
2657 No error recovery mechanism or error processing details will be presented, as the intent of the document is
2658 to present an implementation from the data flow perspective.

Confidential
31-May-2019
B.2 CSI-2 Transmitter Detailed Block Diagram

2659 Using the layered structure described in the overview the CSI-2 transmitter could have the block diagram in
2660 Figure 196.
TxDDRClkHS-Q
TxDDRClkHS-I TxDDRClkHS-Q LP-TX Cp
Clock HS-TX
TxByteClkHS CIL-MCNN
management unit TxRequestHS Cn
TxByteClk TxReadyHS
TxClkEsc D-PHY
ShutdownClk
PHY Handshake TxUlpmClk
elasticity FIFO
Clock Lane
TxByteClk
FrameValid Protocol level
control logic TxDDRClkHS-I LP-TX D2p
LineValid
HS-TX
TxByteClkHS CIL-MFEN D2n
TxByteDataHS[7:0] TxDataHS[7:0]
Fixed ID
(RAW8) ECC[7:0] TxWriteHS TxRequestHS D-PHY
ECC generator
TxReadyHS
Shutdown2
WC[15:0] TxUlpm
CSI2 packet PH[7:0] TxWrite
VC[1:0] TxClkEsc
header (PH)
TxByteData[7:0]
Data Lane 2
TxDDRClkHS-I LP-TX D1p

HS-TX
RAW8_Data[7:0] Payload[7:0] CIL-MFEN
TxByteClkHS D1n
TxByteDataHS[7:0] TxDataHS[7:0]
TxWriteHS D-PHY
TxReadyHS
16bit MISR (LFSR)
Shutdown1
Packet header Lane TxUlpm
insertion CRC[7:0]
Payload distributor TxClkEsc
elasticity FIFO CRC control logic
Data Lane 1
CSI-2 Protocol Level Lane Distributor Level D-PHY Level
If two Data Lanes

2661 TxByteClkHs=TxByteClk/2
Figure 196 CSI-2 Transmitter Block Diagram

Confidential
31-May-2019
B.3 CSI-2 Receiver Detailed Block Diagram

2662 Using the layered structure described in the overview, the CSI-2 receiver could have the block diagram in
2663 Figure 197.
Cp LP-RX RxDDRClkHS
HS-RX
Cn CIL-SCNN
RxClkActiveHS
D-PHY
StopstateClk
ShutdownClk
RxUlpmClk
PHY delay FIFO
Clock Lane
LP-RX RxDDRClkHS
D2p HS-RX
CIL-SFEN RxByteClkHS
RxDataHS[7:0] RxByteDataHS[7:0]
D2n
RxSyncHS
RxValidHS
RxActiveHS
Packet header ECC
D-PHY Stopstate2 ECC decode elasticity FIFO
Shutdown2 and correct
ErrSotHS
ErrSotSyncHS
RxByteDataHS[7:0] RAW8_Data[7:0]
WC1
WC0
ECC
ErrControl
ID
RxUlpmEsc
ErrEsc
CSI2 packet VC[1:0]
Data Lane 2 header/footer WC[15:0]
ECC generator processing
LP-RX RxDDRClkHS
D1p HS-RX RxByteClkHS
CIL-SFEN RxByteDataHS[7:0]
RxDataHS[7:0] 16-bit MISR (LFSR)
D1n
RxSyncHS
RxValidHS Receiver Payload CRC error
RxActiveHS Error control CRC detect
block
Stopstate1 AppErrors[n:0]
D-PHY
Shutdown1
ErrSotHS Stopstate
ErrSotSyncHS Lane merger ErrSotSyncHS RxByteClk
control logic ErrSotHS FrameValid
ErrControl
(including ErrControl Protocol level LineValid
RxUlpmEsc
PHY control/ RxValidHS1 control logic
ErrEsc
error signals) RxValidHS2
RxByteClk
Data Lane 1
ErrEsc
D-PHY level Lane Merger Level CSI2 Protocol Level
If two Data Lanes

2664 RxByteClk=RxByteClkHS*2
Figure 197 CSI-2 Receiver Block Diagram

Confidential
31-May-2019
B.4 Details on the D-PHY Implementation

2665 The PHY level of implementation has the top level structure as seen in Figure 198.
TxDDRClkHS-Q LP-TX Cp Cp LP-RX RxDDRClkHS

HS-TX HS-RX
TxRequestHS CIL-MCNN Cn Cn CIL-SCNN
TxReadyHS RxClkActiveHS
D-PHY D-PHY
RxUlpmClk
Shutdown Stopstate
TxUlpmClk Shutdown
Clock Lane
LP-RX RxDDRClkHS
TxDDRClkHS-I LP-TX D1p D1p HS-RX RxByteClkHS
HS-TX CIL-SFEN
CIL-MFEN RxDataHS[7:0]
TxByteClkHS D1n D1n
TxDataHS[7:0] RxSyncHS
RxValidHS
TxRequestHS D-PHY RxActiveHS
TxReadyHS
RxUlpmEsc
D-PHY
Shutdown Stopstate
TxUlpm Shutdown
TxClkEsc
ErrSotHS
ErrSotSyncHS
ErrEsc
ErrControl
Data Lane 1
LP-RX RxDDRClkHS
TxDDRClkHS-I LP-TX D2p D2p HS-RX RxByteClkHS
HS-TX CIL-SFEN
CIL-MFEN RxDataHS[7:0]
TxByteClkHS D2n D2n
TxDataHS[7:0] RxSyncHS
RxValidHS
TxRequestHS D-PHY RxActiveHS
TxReadyHS
RxUlpmEsc
D-PHY
Shutdown Stopstate
TxUlpm Shutdown
TxClkEsc
ErrSotHS
ErrSotSyncHS
ErrEsc
ErrControl
Data Lane 2
CSI-2 Transmitter Side CSI-2 Receiver Side

2666
Figure 198 D-PHY Level Block Diagram
2667 The components can be categorized as:

2668 • CSI-2 Transmitter side:
2669 • Clock lane (Transmitter)
2670 • Data1 lane (Transmitter)
2671 • Data2 lane (Transmitter)
2672 • CSI-2 Receiver side:
2673 • Clock lane (Receiver)
2674 • Data1 lane (Receiver)
2675 • Data2 lane (Receiver)

Confidential
31-May-2019
B.4.1 CSI-2 Clock Lane Transmitter

2676 The suggested implementation can be seen in Figure 199.
Low-power Function
Cp
TX Ctrl Logic
LP-TX
Cn
TxDDRClkHS-Q HS-TX
TxRequestHS
TX Ctrl IF Logic
TxReadyHS High-speed Function

Shutdown
TX State
Machine
TxUlpmClk
CIL-MCNN
Lane Control and Interface Logic
2677
Figure 199 CSI-2 Clock Lane Transmitter
2678 The modular D-PHY components used to build a CSI-2 clock lane transmitter are:
2679 • LP-TX for the Low-power function
2680 • HS-TX for the High-speed function
2681 • CIL-MCNN for the Lane control and interface logic
2682 The PPI interface signals to the CSI-2 clock lane transmitter are:
2683 • TxDDRClkHS-Q (Input): High-Speed Transmit DDR Clock (Quadrature).
2684 • TxRequestHS (Input): High-Speed Transmit Request. This active high signal causes the lane
2685 module to begin transmitting a high-speed clock.
2686 • TxReadyHS (Output): High-Speed Transmit Ready. This active high signal indicates that the
2687 clock lane is transmitting HS clock.
2688 • Shutdown (Input): Shutdown Lane Module. This active high signal forces the lane module into
2689 “shutdown”, disabling all activity. All line drivers, including terminators, are turned off when
2690 Shutdown is asserted. When Shutdown is high, all other PPI inputs are ignored and all PPI outputs
2691 are driven to the default inactive state. Shutdown is a level sensitive signal and does not depend on
2692 any clock.
2693 • TxUlpmClk (Input): Transmit Ultra Low-Power mode on Clock Lane This active high signal is
2694 asserted to cause a Clock Lane module to enter the Ultra Low-Power mode. The lane module
2695 remains in this mode until TxUlpmClk is de-asserted.

Confidential
31-May-2019
B.4.2 CSI-2 Clock Lane Receiver

High-speed Function
RxDDRClkHS HS-RX RT
Cp
RX Ctrl Decoder
LP-RX
Cn
RX Ctrl IF Logic
RxUlpmEsc RX State
RxClkActiveHS Low-power Function
Machine
Stopstate
Shutdown
CIL-SCNN
2697
Figure 200 CSI-2 Clock Lane Receiver
2698 The modular D-PHY components used to build a CSI-2 clock lane receiver are:
2699 • LP-RX for the Low-power function
2700 • HS-RX for the High-speed function
2701 • CIL-SCNN for the Lane control and interface logic
2702 The PPI interface signals to the CSI-2 clock lane receiver are:
2703 • RxDDRClkHS (Output): High-Speed Receive DDR Clock used to sample the data in all data
2704 lanes.
2705 • RxClkActiveHS (Output): High-Speed Reception Active. This active high signal indicates that the
2706 clock lane is receiving valid clock. This signal is asynchronous.
2707 • Stopstate (Output): Lane is in Stop state. This active high signal indicates that the lane module is
2708 currently in Stop state. This signal is asynchronous.
2711 Shutdown is asserted. When Shutdown is high, all PPI outputs are driven to the default inactive
2712 state. Shutdown is a level sensitive signal and does not depend on any clock.
2713 • RxUlpmEsc (Output): Escape Ultra Low Power (Receive) mode. This active high signal is
2714 asserted to indicate that the lane module has entered the Ultra Low-Power mode. The lane module
2715 remains in this mode with RxUlpmEsc asserted until a Stop state is detected on the lane
2716 interconnect.

Confidential
31-May-2019
B.4.3 CSI-2 Data Lane Transmitter

Low-power Function
Esc ULPS Encoder
TX Ctrl Logic
Dp
TX Data IF Logic
LP-TX
TxDDRClkHS-I
Dn
TxByteClkHS
HS-Serialize
TxDataHS[7:0]
Sync sequence HS-TX
Deskew sequence
High-speed Function
TxRequestHS
TxReadyHS
TX Ctrl IF Logic
Shutdown
TxRequestEsc TX State
Machine
TxUlpm TxUlpmEsc
TxClkEsc
CIL-MFEN

2718
Figure 201 CSI-2 Data Lane Transmitter
2719 The modular D-PHY components used to build a CSI-2 data lane transmitter are:
2720 • LP-TX for the Low-power function
2721 • HS-TX for the High-speed function
2722 • CIL-MFEN for the Lane control and interface logic. For optional deskew calibration support, the
2723 data lane transmitter transmits a deskew sequence. The deskew sequence transmission is enabled
2724 by a mechanism out of the scope of this specification.
2725 The PPI interface signals to the CSI-2 data lane transmitter are:
2726 • TxDDRClkHS-I (Input): High-Speed Transmit DDR Clock (in-phase).
2727 • TxByteClkHS (Input): High-Speed Transmit Byte Clock. This is used to synchronize PPI signals
2728 in the high-speed transmit clock domain. It is recommended that both transmitting data lane
2729 modules share one TxByteClkHS signal. The frequency of TxByteClkHS must be exactly 1/8 the
2730 high-speed bit rate.
2731 • TxDataHS[7:0] (Input): High-Speed Transmit Data. Eight bit high-speed data to be transmitted.
2732 The signal connected to TxDataHS[0] is transmitted first. Data is registered on rising edges of
2733 TxByteClkHS.
2734 • TxRequestHS (Input): High-Speed Transmit Request. A low-to-high transition on TxRequestHS
2735 causes the lane module to initiate a Start-of-Transmission sequence. A high-to-low transition on
2736 TxRequest causes the lane module to initiate an End-of-Transmission sequence. This active high
2737 signal also indicates that the protocol is driving valid data on TxByteDataHS to be transmitted.
2738 The lane module accepts the data when both TxRequestHS and TxReadyHS are active on the same
2739 rising TxByteClkHS clock edge. The protocol always provides valid transmit data when
2740 TxRequestHS is active. Once asserted, TxRequestHS should remain high until the all the data has
2741 been accepted.

Confidential
31-May-2019
2742 • TxReadyHS (Output): High-Speed Transmit Ready. This active high signal indicates that
2743 TxDataHS is accepted by the lane module to be serially transmitted. TxReadyHS is valid on rising
2744 edges of TxByteClkHS. Valid data has to be provided for the whole duration of active
2745 TxReadyHS.
2748 Shutdown is asserted. When Shutdown is high, all other PPI inputs are ignored and all PPI outputs
2749 are driven to the default inactive state. Shutdown is a level sensitive signal and does not depend on
2750 any clock.
2751 • TxUlpmEsc (Input): Escape Mode Transmit Ultra Low Power. This active high signal is asserted
2752 with TxRequestEsc to cause the lane module to enter the Ultra Low-Power mode. The lane
2753 module remains in this mode until TxRequestEsc is de-asserted.
2754 • TxRequestEsc (Input): This active high signal, asserted together with TxUlpmEsc is used to
2755 request entry into Escape Mode. Once in Escape Mode, the lane stays in Escape Mode until
2756 TxRequestEsc is de-asserted. TxRequestEsc is only asserted by the protocol while TxRequestHS
2757 is low.
2758 • TxClkEsc (Input): Escape Mode Transmit Clock. This clock is directly used to generate escape
2759 sequences. The period of this clock determines the symbol time for low power signals. It is
2760 therefore constrained by the normative part of the [MIPI01].

Confidential
31-May-2019
B.4.4 CSI-2 Data Lane Receiver

High-speed Function
RX Data IF Logic
RxDDRClkHS
RxByteClkHS
HS-Deskew
RxDataHS[7:0]
HS-Deserialize HS-RX RT
RxUlpmEsc Dp
RX Esc ULPS Decoder
LP-RX
RX Ctrl Decoder Dn
RxValidHS
RxActiveHS
Low-power Function
RxSyncHS
RX State
RX Ctrl IF Logic
Stopstate Machine
Shutdown
ErrSotHS
ErrSotSyncHS
ErrControl
ErrEsc
CIL-SFEN

2762
Figure 202 CSI-2 Data Lane Receiver
2763 The modular D-PHY components used to build a CSI-2 data lane receiver are:
2764 • LP-RX for the Low-power function
2765 • HS-RX for the High-speed function
2766 • CIL-SFEN for the Lane control and interface logic. For optional deskew calibration support the
2767 data lane receiver detects a transmitted deskew calibration pattern and performs optimum deskew
2768 of the Data with respect to the RxDDRClkHS Clock.
2769 The PPI interface signals to the CSI-2 data lane receiver are:
2770 • RxDDRClkHS (Input): High-Speed Receive DDR Clock used to sample the date in all data lanes.
2771 This signal is supplied by the CSI-2 clock lane receiver.
2772 • RxByteClkHS (Output): High-Speed Receive Byte Clock. This signal is used to synchronize
2773 signals in the high-speed receive clock domain. The RxByteClkHS is generated by dividing the
2774 received RxDDRClkHS.
2775 • RXDataHS[7:0] (Output): High-Speed Receive Data. Eight bit high-speed data received by the
2776 lane module. The signal connected to RxDataHS[0] was received first. Data is transferred on
2777 rising edges of RxByteClkHS.
2778 • RxValidHS (Output): High-Speed Receive Data Valid. This active high signal indicates that the
2779 lane module is driving valid data to the protocol on the RxDataHS output. There is no
2780 “RxReadyHS” signal, and the protocol is expected to capture RxDataHS on every rising edge of
2781 RxByteClkHS where RxValidHS is asserted. There is no provision for the protocol to slow down
2782 (“throttle”) the receive data.

Confidential
31-May-2019
2783 • RxActiveHS (Output): High-Speed Reception Active. This active high signal indicates that the
2784 lane module is actively receiving a high-speed transmission from the lane interconnect.
2785 • RxSyncHS (Output): Receiver Synchronization Observed. This active high signal indicates that
2786 the lane module has seen an appropriate synchronization event. In a typical high-speed
2787 transmission, RxSyncHS is high for one cycle of RxByteClkHS at the beginning of a high-speed
2788 transmission when RxActiveHS is first asserted. This signal missing is signaled using
2789 ErrSotSyncHS.
2790 • RxUlpmEsc (Output): Escape Ultra Low Power (Receive) mode. This active high signal is
2791 asserted to indicate that the lane module has entered the Ultra Low-Power mode. The lane module
2792 remains in this mode with RxUlpmEsc asserted until a Stop state is detected on the lane
2793 interconnect.
2794 • Stopstate (Output): Lane is in Stop state. This active high signal indicates that the lane module is
2795 currently in Stop state. This signal is asynchronous.
2798 Shutdown is asserted. When Shutdown is high, all PPI outputs are driven to the default inactive
2799 state. Shutdown is a level sensitive signal and does not depend on any clock.
2800 • ErrSotHS (Output): Start-of-Transmission (SoT) Error. If the high-speed SoT leader sequence is
2801 corrupted, but in such a way that proper synchronization can still be achieved, this error signal is
2802 asserted for one cycle of RxByteClkHS. This is considered to be a “soft error” in the leader
2803 sequence and confidence in the payload data is reduced.
2804 • ErrSotSyncHS (Output): Start-of-Transmission Synchronization Error. If the high-speed SoT
2805 leader sequence is corrupted in a way that proper synchronization cannot be expected, this error is
2806 asserted for one cycle of RxByteClkHS.
2807 • ErrControl (Output): Control Error. This signal is asserted when an incorrect line state sequence
2808 is detected.
2809 • ErrEsc (Output): Escape Entry Error. If an unrecognized escape entry command is received, this
2810 signal is asserted and remains high until the next change in line state. The only escape entry
2811 command supported by the receiver is the ULPS.

Confidential
31-May-2019
Annex C CSI-2 Recommended Receiver Error Behavior

(informative)
C.1 Overview
2812 This section proposes one approach to handling error conditions at the receiving side of a CSI-2 Link.
2813 Although the section is informative and therefore does not affect compliance for CSI-2, the approach is
2814 offered by the MIPI Camera Working Group as a recommended approach. The CSI-2 receiver assumes the
2815 case of a CSI-2 Link comprised of unidirectional Lanes for D-PHY Clock and Data Lanes with Escape Mode
2816 functionality on the Data Lanes and a continuously running clock. This Annex does not discuss other cases,
2817 including those that differ widely in implementation, where the implementer should consider other potential
2818 error situations.
2819 Because of the layered structure of a compliant CSI-2 receiver implementation, the error behavior is
2820 described in a similar way with several “levels” where errors could occur, each requiring some
2821 implementation at the appropriate functional layer of the design:
2822 • D-PHY Level errors
2823 Refers to any PHY related transmission error and is unrelated to the transmission’s contents:
2824 • Start of Transmission (SoT) errors, which can be:
2825 • Recoverable, if the PHY successfully identifies the Sync code but an error was detected.
2826 • Unrecoverable, if the PHY does not successfully identify the sync code but does detect a HS
2827 transmission.
2828 • Control Error, which signals that the PHY has detected a control sequence that should not be
2829 present in this implementation of the Link.
2830 • Packet Level errors
2831 This type of error refers strictly to data integrity of the received Packet Header and payload data:
2832 • Packet Header errors, signaled through the ECC code, that result in:
2833 • A single bit-error, which can be detected and corrected by the ECC code
2834 • Two bit-errors in the header, which can be detected but not corrected by the ECC code,
2835 resulting in a corrupt header
2836 • Packet payload errors, signaled through the CRC code
2837 • Protocol Decoding Level errors
2838 This type of error refers to errors present in the decoded Packet Header or errors resulting from an
2839 incomplete sequence of events:
2840 • Frame Sync Error, caused when a FS could not be successfully paired with a FE on a given
2841 virtual channel
2842 • Unrecognized ID, caused by the presence of an unimplemented or unrecognized ID in the
2843 header
2844 The proposed methodology for handling errors is signal based, since it offers an easy path to a viable CSI-2
2845 implementation that handles all three error levels. Even so, error handling at the Protocol Decoding Level
2846 should implement sequential behavior using a state machine for proper operation.

Confidential
31-May-2019
C.2 D-PHY Level Error

2847 The recommended behavior for handling this error level covers only those errors generated by the Data
2848 Lane(s), since an implementation can assume that the Clock Lane is running reliably as provided by the
2849 expected BER of the Link, as discussed in [MIPI01]. Note that this error handling behavior assumes
2850 unidirectional Data Lanes without Escape Mode functionality. Considering this, and using the signal names
2851 and descriptions from the [MIPI01], PPI Annex, signal errors at the PHY-Protocol Interface (PPI) level
2852 consist of the following:
2853 • ErrSotHS: Start-of-Transmission (SoT) Error. If the high-speed SoT leader sequence is corrupted,
2854 but in such a way that proper synchronization can still be achieved, this error signal is asserted for
2855 one cycle of RxByteClkHS. This is considered to be a “soft error” in the leader sequence and
2856 confidence in the payload data is reduced.
2857 • ErrSotSyncHS: Start-of-Transmission Synchronization Error. If the high-speed SoT leader
2858 sequence is corrupted in a way that proper synchronization cannot be expected, this error signal is
2859 asserted for one cycle of RxByteClkHS.
2860 • ErrControl: Control Error. This signal is asserted when an incorrect line state sequence is
2861 detected. For example, if a Turn-around request or Escape Mode request is immediately followed
2862 by a Stop state instead of the required Bridge state, this signal is asserted and remains high until
2863 the next change in line state.
2864 The recommended receiver error behavior for this level is:
2865 • ErrSotHS should be passed to the Application Layer. Even though the error was detected and
2866 corrected and the Sync mechanism was unaffected, confidence in the data integrity is reduced and
2867 the application should be informed. This signal should be referenced to the corresponding data
2868 packet.
2869 • ErrSotSyncHS should be passed to the Protocol Decoding Level, since this is an unrecoverable
2870 error. An unrecoverable type of error should also be signaled to the Application Layer, since the
2871 whole transmission until the first D-PHY Stop state should be ignored if this type of error occurs.
2872 • ErrControl should be passed to the Application Layer, since this type of error doesn’t normally
2873 occur if the interface is configured to be unidirectional. Even so, the application should be aware
2874 of the error and configure the interface accordingly through other, implementation specific-means
2875 that are out of scope for this specification.
2876 Also, it is recommended that the PPI StopState signal for each implemented Lane should be propagated to
2877 the Application Layer during configuration or initialization to indicate the Lane is ready.

Confidential
31-May-2019
C.3 Packet Level Error

2878 The recommended behavior for this error level covers only errors recognized by decoding the Packet
2879 Header’s ECC field and computing the CRC of the data payload.
2880 Decoding and applying the ECC field of the Packet Header should signal the following errors:
2881 • ErrEccDouble: Asserted when an ECC syndrome was computed and two bit-errors are detected
2882 in the received Packet Header.
2883 • ErrEccCorrected: Asserted when an ECC syndrome was computed and a single bit-error in the
2884 Packet Header was detected and corrected.
2885 • ErrEccNoError: Asserted when an ECC syndrome was computed and the result is zero
2886 indicating a Packet Header that is considered to be without errors or has more than two bit-errors.
2887 CSI-2’s ECC mechanism cannot detect this type of error.
2888 Also, computing the CRC code over the whole payload of the received packet could generate the following
2889 errors:
2890 • ErrCrc: Asserted when the computed CRC code is different than the received CRC code.
2891 • ErrID: Asserted when a Packet Header is decoded with an unrecognized or unimplemented data
2892 ID.
2894 • ErrEccDouble should be passed to the Application Layer since assertion of this signal proves that
2895 the Packet Header information is corrupt, and therefore the WC is not usable, and thus the packet
2896 end cannot be estimated. Commonly, this type of error will be accompanied with an ErrCrc. This
2897 type of error should also be passed to the Protocol Decoding Level, since the whole transmission
2898 until D-PHY Stop state should be ignored.
2899 • ErrEccCorrected should be passed to the Application Layer since the application should be
2900 informed that an error had occurred but was corrected, so the received Packet Header was
2901 unaffected, although the confidence in the data integrity is reduced.
2902 • ErrEccNoError can be passed to the Protocol Decoding Level to signal the validity of the current
2903 Packet Header.
2904 • ErrCrc should be passed to the Protocol Decoding Level to indicate that the packet’s payload data
2905 might be corrupt.
2906 • ErrID should be passed to the Application Layer to indicate that the data packet is unidentified
2907 and cannot be unpacked by the receiver. This signal should be asserted after the ID has been
2908 identified and de-asserted on the first Frame End (FE) on same virtual channel.

Confidential
31-May-2019
C.4 Protocol Decoding Level Error

2909 The recommended behavior for this error level covers errors caused by decoding the Packet Header
2910 information and detecting a sequence that is not allowed by the CSI-2 protocol or a sequence of detected
2911 errors by the previous layers. CSI-2 implementers will commonly choose to implement this level of error
2912 handling using a state machine that should be paired with the corresponding virtual channel. The state
2913 machine should generate at least the following error signals:
2914 • ErrFrameSync: Asserted when a Frame End (FE) is not paired with a Frame Start (FS) on the
2915 same virtual channel. An ErrSotSyncHS should also generate this error signal.
2916 • ErrFrameData: Asserted after a FE when the data payload received between FS and FE contains
2917 errors.
2919 • ErrFrameSync should be passed to the Application Layer with the corresponding virtual channel,
2920 since the frame could not be successfully identified. Several error cases on the same virtual
2921 channel can be identified for this type of error.
2922 • If a FS is followed by a second FS on the same virtual channel, the frame corresponding to the
2923 first FS is considered in error.
2924 • If a Packet Level ErrEccDouble was signaled from the Protocol Layer, the whole transmission
2925 until the first D-PHY Stop-state should be ignored since it contains no information that can be
2926 safely decoded and cannot be qualified with a data valid signal.
2927 • If a FE is followed by a second FE on the same virtual channel, the frame corresponding to the
2928 second FE is considered in error.
2929 • If an ErrSotSyncHS was signaled from the PHY Layer, the whole transmission until the first
2930 D-PHY Stop state should be ignored since it contains no information that can be safely decoded
2931 and cannot be qualified with a data valid signal.
2932 • ErrFrameData: should be passed to the Application Layer to indicate that the frame contains data
2933 errors. This signal should be asserted on any ErrCrc and de-asserted on the first FE.

Confidential
31-May-2019
Annex D CSI-2 Sleep Mode (informative)

D.1 Overview
2934 Since a camera in a mobile terminal spends most of its time in an inactive state, implementers need a way to
2935 put the CSI-2 Link into a low power mode that approaches, or may be as low as, the leakage level. This
2936 section proposes one approach for putting a CSI-2 Link in a “Sleep Mode” (SLM). Although the section is
2937 informative and therefore does not affect compliance for CSI-2, the approach is offered by the MIPI Camera
2938 Working Group as a recommended approach.
2939 This approach relies on an aspect of a D-PHY or C-PHY transmitter’s behavior that permits regulators to be
2940 disabled safely when LP-00 (Space state) is on the Link. Accordingly, this will be the output state for a CSI-
2941 2 camera transmitter in SLM.
2942 SLM can be thought of as a three-phase process:
2943 1. SLM Command Phase. The ‘ENTER SLM’ command is issued to the TX side only, or to both
2944 sides of the Link.
2945 2. SLM Entry Phase. The CSI-2 Link has entered, or is entering, the SLM in a controlled or
2946 synchronized manner. This phase is also part of the power-down process.
2947 3. SLM Exit Phase. The CSI-2 Link has exited the SLM and the interface/device is operational. This
2948 phase is also part of the power-up process.
2949 In general, when in SLM, both sides of the interface will be in ULPS, as defined in [MIPI01] or [MIPI02].
D.2 SLM Command Phase

2950 For the first phase, initiation of SLM occurs by a mechanism outside the scope of CSI-2. Of the many
2951 mechanisms available, two examples would be:
2952 1. An External SLEEP signal input to the CSI-2 transmitter and optionally also to the CSI-2
2953 Receiver. When at logic 0, the CSI-2 Transmitter and the CSI Receiver (if connected) will enter
2954 Sleep mode. When at logic 1, normal operation will take place.
2955 2. A CCI control command, provided on the I2C control Link, is used to trigger ULPS.

Confidential
31-May-2019
D.3 SLM Entry Phase

2956 For the second phase, consider one option:
2957 Only the TX side enters SLM and propagates the ULPS to the RX side by sending a D-PHY or C-PHY
2958 ‘ULPS’ command on each Lane. In Figure 203, only the Data Lane ‘ULPS’ command is used as an example.
2959 The D-PHY Dp, Dn, and C-PHY Data_A, Data_C are logical signal names and do not imply specific
2960 multiplexing on dual mode (combined D-PHY and C-PHY) implementations.
Using signal XSHUTDOWN to confirm entry and exit from “Sleep” mode
External Signal External Signal External Signal

(XSHUTDOWN) (XSHUTDOWN) (XSHUTDOWN)
Or Or Or
CCI Command CCI Command CCI Command
“Sleep” “Normal” “Sleep” “Normal”

Mode Operation Mode Operation
Using the ULPS Sequence on Data Lane to confirm entry and exit from “Sleep” mode
Dp (D-PHY) or
Data_A (C-PHY)
Dn (D-PHY) or
Data_C (C-PHY)
LP-00 Exit LP-11 Escape Ultra-Low Power LP-00 Exit LP-11

D-PHY Space Sequence Stop Mode State Command Space Sequence Stop
State State Entry 00011110 State State
C-PHY LP-000 Exit

Space Sequence
LP-111
Stop
Escape
Mode
Ultra-Low Power
State Command
LP-000
Space
Exit
Sequence
LP-111
Stop
State State Entry 00011110 State State
Initial
2961 State
Figure 203 SLM Synchronization
D.4 SLM Exit Phase

2962 For the third phase, three options are presented and assume the camera peripheral is in ULPS or Sleep mode
2963 at power-up:
2964 1. Use a SLEEP signal to power-up both sides of the interface.
2965 2. Detect any CCI activity on the I2C control Link, which was in the 00 state ({SCL, SDA}), after
2966 receiving the I2C instruction to enter ULPS command as per Section D.2, option 2. Any change on
2967 those lines should wake up the camera peripheral. The drawback of this method is that I2C lines
2968 are used exclusively for control of the camera.
2969 3. Detect a wake-up sequence on the I2C lines. This sequence, which may vary by implementation,
2970 shall not disturb the I2C interface so that it can be used by other devices. One example sequence is:
2971 StopI2C-StartI2C-StopI2C. See Section 6 for details on CCI.
2972 A handshake using the ‘ULPS’ mechanism as described in [MIPI01] or [MIPI02], as appropriate, should be
2973 used for powering up the interface.

Confidential
31-May-2019
Annex E Data Compression for RAW Data Types (normative)

2974 A CSI-2 implementation using RAW data types may support compression on the interface to reduce the data
2975 bandwidth requirements between the host processor and a camera module. Data compression is not mandated
2976 by this Specification. However, if data compression is used, it shall be implemented as described in this
2977 annex.
2978 Data compression schemes use an X–Y–Z naming convention where X is the number of bits per pixel in the
2979 original image, Y is the encoded (compressed) bits per pixel and Z is the decoded (uncompressed) bits per
2980 pixel.
2981 The following data compression schemes are defined:
2982 • 12-10-12
2983 • 12–8–12
2984 • 12–7–12
2985 • 12–6–12
2986 • 10–8–10
2987 • 10–7–10
2988 • 10–6–10
2989 To identify the type of data on the CSI-2 interface, packets with compressed data shall have a User Defined
2990 Data Type value as indicated in Table 60. Note that User Defined data type codes are not reserved for
2991 compressed data types. Therefore, a CSI-2 device shall be able to communicate over the CCI the data
2992 compression scheme represented by a particular User Defined data type code for each scheme supported by
2993 the device. Note that the method to communicate the data compression scheme to Data Type code mapping
2994 is beyond the scope of this document.
2995 The number of bits in a packet shall be a multiple of eight. Therefore, implementations with data compression
2996 schemes that result in each pixel having other than eight encoded bits per pixel shall transfer the encoded
2997 data in a packed pixel format. For example, the 12–7–12 data compression scheme uses a packed pixel format
2998 as described in Section 11.4.2 except the Data Type value in the Packet Header is a User Defined data type
2999 code.
3000 The data compression schemes in this annex are lossy and designed to encode each line independent of the
3001 other lines in the image.
3002 The following definitions are used in the description of the data compression schemes:
3003 • Xorig is the original pixel value
3004 • Xpred is the predicted pixel value
3005 • Xdiff is the difference value (Xorig - Xpred)
3006 • Xenco is the encoded value
3007 • Xdeco is the decoded pixel value

Confidential
31-May-2019
3008 The data compression system consists of encoder, decoder and predictor blocks as shown in Figure 204.
Codec
Selector and
Encoder Encoded Encoded
Symbols Symbols Decoded
+ DPCM1 Symbols
Σ ... Decoder
Unencoded DPCMN
- PCM
Symbols M-pixel
Memory
M-pixel
Predictor Decoder
Memory Predictor
3009
Figure 204 Data Compression System Block Diagram
3010 The encoder uses a simple algorithm to encode the pixel values. A fixed number of pixel values at the
3011 beginning of each line are encoded without using prediction. These first few values are used to initialize the
3012 predictor block. The remaining pixel values on the line are encoded using prediction.
3013 If the predicted value of the pixel (Xpred) is close enough to the original value of the pixel (Xorig)
3014 (abs(Xorig - Xpred) < difference limit), its difference value (Xdiff) is quantized using a DPCM codec.
3015 Otherwise, Xorig is quantized using a PCM codec. The quantized value is combined with a code word
3016 describing the codec used to quantize the pixel and the sign bit, if applicable, to create the encoded value
3017 (Xenco).

Confidential
31-May-2019
E.1 Predictors
3018 In order to have meaningful data transfer, both the transmitter and the receiver need to use the same predictor
3019 block.
3020 The order of pixels in a raw image is shown in Figure 205.
C00 C11 C02 C13 C04 C15 C06 C17
C20 C31 C22 C33 C24 C35 C26 C37
3021
Figure 205 Pixel Order of the Original Image
3022 Figure 206 shows an example of the pixel order with RGB data.
G0 R1 G2 R3 G4 R5 G6 R7
B0 G1 B2 G3 B4 G5 B6 G7
3023
Figure 206 Example Pixel Order of the Original Image
3024 Two predictors are defined for use in the data compression schemes.
3025 Predictor1 uses a very simple algorithm and is intended to minimize processing power and memory size
3026 requirements. Typically, this predictor is used when the compression requirements are modest and the original
3027 image quality is high. Predictor1 should be used with 10–8–10, 10–7–10, 12-10-12, and 12–8–12 data
3028 compression schemes.
3029 The second predictor, Predictor2, is more complex than Predictor1. This predictor provides slightly better
3030 prediction than Predictor1 and therefore the decoded image quality can be improved compared to Predictor1.
3031 Predictor2 should be used with 10–6–10, 12–7–12, and 12–6–12 data compression schemes.
3032 Both receiver and transmitter shall support Predictor1 for all data compression schemes.
E.1.1 Predictor1
3033 Predictor1 uses only the previous same color component value as the prediction value. Therefore, only a
3034 two-pixel deep memory is required.
3035 The first two pixels (C00, C11 / C20, C31 or as in example G0, R1 / B0, G1) in a line are encoded without
3036 prediction.
3037 The prediction values for the remaining pixels in the line are calculated using the previous same color
3038 decoded value, Xdeco. Therefore, the predictor equation can be written as follows:
3039 Xpred( n ) = Xdeco( n-2 )

Confidential
31-May-2019
E.1.2 Predictor2
3040 Predictor2 uses the four previous pixel values, when the prediction value is evaluated. This means that also
3041 the other color component values are used, when the prediction value has been defined. The predictor
3042 equations can be written as shown in the following formulas.
3043 Predictor2 uses all color components of the four previous pixel values to create the prediction value.
3044 Therefore, a four-pixel deep memory is required.
3045 The first pixel (C00 / C20, or as in example G0 / B0) in a line is coded without prediction.
3046 The second pixel (C11 / C31 or as in example R1 / G1) in a line is predicted using the previous decoded
3047 different color value as a prediction value. The second pixel is predicted with the following equation:
3049 The third pixel (C02 / C22 or as in example G2 / B2) in a line is predicted using the previous decoded same
3050 color value as a prediction value. The third pixel is predicted with the following equation:
3052 The fourth pixel (C13 / C33 or as in example R3 / G3) in a line is predicted using the following equation:
3053 if ((Xdeco( n-1 ) <= Xdeco( n-2 ) AND Xdeco( n-2 ) <= Xdeco( n-3 )) OR
3054 (Xdeco( n-1 ) >= Xdeco( n-2 ) AND Xdeco( n-2 ) >= Xdeco( n-3 ))) then
3056 else
3058 endif
3059 Other pixels in all lines are predicted using the equation:
3060 if ((Xdeco( n-1 ) <= Xdeco( n-2 ) AND Xdeco( n-2 ) <= Xdeco( n-3 )) OR
3063 else if ((Xdeco( n-1 ) <= Xdeco( n-3 ) AND Xdeco( n-2 ) <= Xdeco( n-4 )) OR
3066 else
3067 Xpred( n ) = (Xdeco( n-2 ) + Xdeco( n-4 ) + 1) / 2
3068 endif

Confidential
31-May-2019
E.2 Encoders
3069 There are seven different encoders available, one for each data compression scheme.
3070 For all encoders, the formula used for non-predicted pixels (beginning of lines) is different than the formula
3071 for predicted pixels.
E.2.1 Coder for 10–8–10 Data Compression

3072 The 10–8–10 coder offers a 20% bit rate reduction with very high image quality.
3073 Pixels without prediction are encoded using the following formula:
3074 Xenco( n ) = Xorig( n ) / 4
3075 To avoid a full-zero encoded value, the following check is performed:
3076 if (Xenco( n ) == 0) then
3077 Xenco( n ) = 1
3078 endif
3079 Pixels with prediction are encoded using the following formula:
3080 if (abs(Xdiff( n )) < 32) then
3081 use DPCM1
3082 else if (abs(Xdiff( n )) < 64) then
3083 use DPCM2
3085 use DPCM3
3086 else
3087 use PCM
3088 endif
E.2.1.1 DPCM1 for 10–8–10 Coder

3089 Xenco( n ) has the following format:
3090 Xenco( n ) = “00 s xxxxx”
3091 where,
3092 “00” is the code word
3093 “s” is the sign bit
3094 “xxxxx” is the five bit value field
3095 The coder equation is described as follows:
3096 if (Xdiff( n ) <= 0) then
3097 sign = 1
3098 else
3099 sign = 0
3100 endif
3101 value = abs(Xdiff( n ))
3102 Note: Zero code has been avoided (0 is sent as -0).

Confidential
31-May-2019

3104 Xenco( n ) = “010 s xxxx”
3105 where,
3108 “xxxx” is the four bit value field
3110 if (Xdiff( n ) < 0) then
3111 sign = 1
3112 else
3113 sign = 0
3114 endif
3115 value = (abs(Xdiff( n )) - 32) / 2

3117 Xenco( n ) = “011 s xxxx”
3118 where,
3124 sign = 1
3125 else
3126 sign = 0
3127 endif
3128 value = (abs(Xdiff( n )) - 64) / 4
E.2.1.4 PCM for 10–8–10 Coder

3130 Xenco( n ) = “1 xxxxxxx”
3131 where,
3133 the sign bit is not used
3134 “xxxxxxx” is the seven bit value field
3136 value = Xorig( n ) / 8

Confidential
31-May-2019

3137 The 10–7–10 coder offers 30% bit rate reduction with high image quality.
3139 Xenco( n ) = Xorig( n ) / 8
3142 Xenco( n ) = 1
3145 use DPCM1
3147 use DPCM2
3149 use DPCM3
3151 use DPCM4
3152 else
3153 use PCM
3154 endif

3156 Xenco( n ) = “000 s xxx”
3157 where,
3160 “xxx” is the three bit value field
3163 sign = 1
3164 else
3165 sign = 0
3166 endif

Confidential
31-May-2019

3170 Xenco( n ) = “0010 s xx”
3171 where,
3174 “xx” is the two bit value field
3177 sign = 1
3178 else
3179 sign = 0
3180 endif
3181 value = (abs(Xdiff( n )) - 8) / 2

3183 Xenco( n ) = “0011 s xx”
3184 where,
3190 sign = 1
3191 else
3192 sign = 0
3193 endif
3194 value = (abs(Xdiff( n )) - 16) / 4

3196 Xenco( n ) = “01 s xxxx”
3197 where,
3203 sign = 1
3204 else
3205 sign = 0
3206 endif
3207 value = (abs(Xdiff( n )) - 32) / 8

Confidential
31-May-2019

3209 Xenco( n ) = “1 xxxxxx”
3210 where,
3213 “xxxxxx” is the six bit value field
3215 value = Xorig( n ) / 16

Confidential
31-May-2019

3216 The 10–6–10 coder offers 40% bit rate reduction with acceptable image quality.
3218 Xenco( n ) = Xorig( n ) / 16
3221 Xenco( n ) = 1
3222 endif
3225 use DPCM1
3227 use DPCM2
3229 use DPCM3
3231 use DPCM4
3233 use DPCM5
3234 else
3235 use PCM
3236 endif

3238 Xenco( n ) = “00000 s”
3239 where,
3242 the value field is not used
3244 sign = 1

3247 Xenco( n ) = “00001 s”
3248 where,
3254 sign = 1
3255 else
3256 sign = 0
3257 endif


Confidential
31-May-2019
3259 Xenco( n ) = “0001 s x”

3260 where,
3263 “x” is the one bit value field
3266 sign = 1
3267 else
3268 sign = 0
3269 value = (abs(Xdiff( n )) - 3) / 4
3270 endif

3272 Xenco( n ) = “001 s xx”
3273 where,
3279 sign = 1
3280 else
3281 sign = 0
3282 endif
3283 value = (abs(Xdiff( n )) - 11) / 8

3285 Xenco( n ) = “01 s xxx”
3286 where,
3292 sign = 1
3293 else
3294 sign = 0
3295 endif
3296 value = (abs(Xdiff( n )) - 43) / 16

Confidential
31-May-2019

3298 Xenco( n ) = “1 xxxxx”
3299 where,
3304 value = Xorig( n ) / 32

Confidential
31-May-2019
E.2.4 Coder for 12-10-12 Data Compression

3305 The 12–10–12 coder offers a 16.7% bit rate reduction with very high image quality.
3307 Xenco( n ) = Xorig( n ) / 4
3310 Xenco( n ) = 1
3311 endif
3314 use DPCM1
3316 use DPCM2
3318 use DPCM3
3319 else
3320 use PCM
3321 endif

3323 Xenco( n ) = “00 s xxxxxxx”
3324 where,
3330 sign = 1
3331 else
3332 sign = 0
3333 endif
3335 Note:
3336 Zero code has been avoided (0 is sent as -0).

Confidential
31-May-2019

3338 Xenco( n ) = “010 s xxxxxx”
3339 where,
3345 sign = 1
3346 else
3347 sign = 0
3348 endif
3349 value = (abs(Xdiff( n )) - 128) / 2

3352 where,
3358 sign = 1
3359 else
3360 sign = 0
3361 endif
3362 value = (abs(Xdiff( n )) - 256) / 4

3364 Xenco( n ) = “1 xxxxxxxxx”
3365 where,
3368 “xxxxxxxxx” is the nine bit value field
3370 value = Xorig( n ) / 8

Confidential
31-May-2019

3371 The 12–8–12 coder offers 33% bit rate reduction with very high image quality.
3373 Xenco( n ) = Xorig( n ) / 16
3376 Xenco( n ) = 1
3377 endif
3380 use DPCM1
3382 use DPCM2
3384 use DPCM3
3386 use DPCM4
3388 use DPCM5
3389 else
3390 use PCM

3392 Xenco( n ) = “0000 s xxx”
3393 where,
3399 sign = 1
3400 else
3401 sign = 0
3402 endif

Confidential
31-May-2019

3406 Xenco( n ) = “011 s xxxx”
3407 where,
3413 sign = 1
3414 else
3415 sign = 0
3416 endif
3417 value = (abs(Xdiff( n )) - 8) / 2

3419 Xenco( n ) = “010 s xxxx”
3420 where,
3426 sign = 1
3427 else
3428 sign = 0
3429 endif
3430 value = (abs(Xdiff( n )) - 40) / 4

3432 Xenco( n ) = “001 s xxxx”
3433 where,
3439 sign = 1
3440 else
3441 sign = 0
3442 endif
3443 value = (abs(Xdiff( n )) - 104) / 8

Confidential
31-May-2019

3445 Xenco( n ) = “0001 s xxx”
3446 where,
3452 sign = 1
3453 else
3454 sign = 0
3455 endif
3456 value = (abs(Xdiff( n )) - 232) / 16

3459 where,
3464 value = Xorig( n ) / 32

Confidential
31-May-2019

3465 The 12–7–12 coder offers 42% bit rate reduction with high image quality.
3467 Xenco( n ) = Xorig( n ) / 32
3470 Xenco( n ) = 1
3471 endif
3474 use DPCM1
3476 use DPCM2
3478 use DPCM3
3480 use DPCM4
3482 use DPCM5
3484 use DPCM6
3485 else
3486 use PCM
3487 endif

3489 Xenco( n ) = “0000 s xx”
3490 where,
3496 sign = 1
3497 else
3498 sign = 0
3499 endif

Confidential
31-May-2019

3503 Xenco( n ) = “0001 s xx”
3504 where,
3510 sign = 1
3511 else
3512 sign = 0
3513 endif
3514 value = (abs(Xdiff( n )) - 4) / 2

3516 Xenco( n ) = “0010 s xx”
3517 where,
3523 sign = 1
3524 else
3525 sign = 0
3526 endif
3527 value = (abs(Xdiff( n )) - 12) / 4

3529 Xenco( n ) = “010 s xxx”
3530 where,
3536 sign = 1
3537 else
3538 sign = 0
3539 endif
3540 value = (abs(Xdiff( n )) - 28) / 8

Confidential
31-May-2019

3542 Xenco( n ) = “011 s xxx”
3543 where,
3549 sign = 1
3550 else
3551 sign = 0
3552 endif
3553 value = (abs(Xdiff( n )) - 92) / 16

3555 Xenco( n ) = “0011 s xx”
3556 where,
3562 sign = 1
3563 else
3564 sign = 0
3565 endif
3566 value = (abs(Xdiff( n )) - 220) / 32

3569 where,
3574 value = Xorig( n ) / 64

Confidential
31-May-2019

3575 The 12–6–12 coder offers 50% bit rate reduction with acceptable image quality.
3577 Xenco( n ) = Xorig( n ) / 64
3580 Xenco( n ) = 1
3581 endif
3584 use DPCM1
3586 use DPCM3
3588 use DPCM4
3590 use DPCM5
3592 use DPCM6
3594 use DPCM7
3595 else
3596 use PCM
3597 endif
3598 Note: DPCM2 is not used.

3600 Xenco( n ) = “0000 s x”
3601 where,
3607 sign = 1
3608 else
3609 sign = 0
3610 endif

Confidential
31-May-2019

3614 Xenco( n ) = “0001 s x”
3615 where,
3621 sign = 1
3622 else
3623 sign = 0
3624 endif
3625 value = (abs(Xdiff( n )) - 2) / 4

3627 Xenco( n ) = “010 s xx”
3628 where,
3634 sign = 1
3635 else
3636 sign = 0
3637 endif
3638 value = (abs(Xdiff( n )) - 10) / 8

3640 Xenco( n ) = “0010 s x”
3641 where,
3647 sign = 1
3648 else
3649 sign = 0
3650 endif
3651 value = (abs(Xdiff( n )) - 42) / 16

Confidential
31-May-2019

3653 Xenco( n ) = “011 s xx”
3654 where,
3660 sign = 1
3661 else
3662 sign = 0
3663 endif
3664 value = (abs(Xdiff( n )) - 74) / 32

3666 Xenco( n ) = “0011 s x”
3667 where,
3673 sign = 1
3674 else
3675 sign = 0
3676 endif
3677 value = (abs(Xdiff( n )) - 202) / 64

3680 where,
3685 value = Xorig( n ) / 128

Confidential
31-May-2019
E.3 Decoders
3686 There are six different decoders available, one for each data compression scheme.
3687 For all decoders, the formula used for non-predicted pixels (beginning of lines) is different than the formula
3688 for predicted pixels.
E.3.1 Decoder for 10–8–10 Data Compression

3689 Pixels without prediction are decoded using the following formula:
3690 Xdeco( n ) = 4 * Xenco( n ) + 2
3691 Pixels with prediction are decoded using the following formula:
3692 if (Xenco( n ) & 0xc0 == 0x00) then
3693 use DPCM1
3694 else if (Xenco( n ) & 0xe0 == 0x40) then
3695 use DPCM2
3697 use DPCM3
3698 else
3699 use PCM
3700 endif
E.3.1.1 DPCM1 for 10–8–10 Decoder

3702 Xenco( n ) = “00 s xxxxx”
3703 where,
3707 The decoder equation is described as follows:
3708 sign = Xenco( n ) & 0x20
3709 value = Xenco( n ) & 0x1f
3710 if (sign > 0) then
3711 Xdeco( n ) = Xpred( n ) - value
3712 else
3713 Xdeco( n ) = Xpred( n ) + value
3714 endif

Confidential
31-May-2019

3716 Xenco( n ) = “010 s xxxx”
3717 where,
3722 sign = Xenco( n ) & 0x10
3723 value = 2 * (Xenco( n ) & 0xf) + 32
3726 else
3728 endif

3730 Xenco( n ) = “011 s xxxx”
3731 where,
3736 sign = Xenco( n ) & 0x10
3737 value = 4 * (Xenco( n ) & 0xf) + 64 + 1
3740 if (Xdeco( n ) < 0) then
3741 Xdeco( n ) = 0
3742 endif
3743 else
3745 if (Xdeco( n ) > 1023) then
3746 Xdeco( n ) = 1023
3747 endif
3748 endif

Confidential
31-May-2019
E.3.1.4 PCM for 10–8–10 Decoder

3751 where,
3755 The codec equation is described as follows:
3756 value = 8 * (Xenco( n ) & 0x7f)
3757 if (value > Xpred( n )) then
3758 Xdeco( n ) = value + 3
3759 endif
3760 else
3762 endif

Confidential
31-May-2019

3764 Xdeco( n ) = 8 * Xenco( n ) + 4
3766 if (Xenco( n ) & 0x70 == 0x00) then
3767 use DPCM1
3768 else if (Xenco( n ) & 0x78 == 0x10) then
3769 use DPCM2
3771 use DPCM3
3773 use DPCM4
3774 else
3775 use PCM
3776 endif

3778 Xenco( n ) = “000 s xxx”
3779 where,
3784 sign = Xenco( n ) & 0x8
3785 value = Xenco( n ) & 0x7
3788 else
3790 endif

3792 Xenco( n ) = “0010 s xx”
3793 where,
3798 sign = Xenco( n ) & 0x4
3799 value = 2 * (Xenco( n ) & 0x3) + 8
3802 else
3804 endif

Confidential
31-May-2019

3806 Xenco( n ) = “0011 s xx”
3807 where,
3812 sign = Xenco( n ) & 0x4
3813 value = 4 * (Xenco( n ) & 0x3) + 16 + 1
3817 Xdeco( n ) = 0
3818 endif
3819 else
3821 if (Xdeco( n ) > 1023) then
3822 Xdeco( n ) = 1023
3823 endif
3824 endif

3826 Xenco( n ) = “01 s xxxx”
3827 where,
3832 sign = Xenco( n ) & 0x10
3833 value = 8 * (Xenco( n ) & 0xf) + 32 + 3
3837 Xdeco( n ) = 0
3838 endif
3839 else
3841 if (Xdeco( n ) > 1023) then
3842 Xdeco( n ) = 1023
3843 endif
3844 endif

Confidential
31-May-2019

3847 where,
3852 value = 16 * (Xenco( n ) & 0x3f)
3855 else
3857 endif

Confidential
31-May-2019

3859 Xdeco( n ) = 16 * Xenco( n ) + 8
3861 if (Xenco( n ) & 0x3e == 0x00) then
3862 use DPCM1
3863 else if (Xenco( n ) & 0x3e == 0x02) then
3864 use DPCM2
3865 else if (Xenco( n ) & 0x3c == 0x04) then
3866 use DPCM3
3868 use DPCM4
3870 use DPCM5
3871 else
3872 use PCM
3873 endif

3875 Xenco( n ) = “00000 s”
3876 where,
3881 Xdeco( n ) = Xpred( n )

3883 Xenco( n ) = “00001 s”
3884 where,
3889 sign = Xenco( n ) & 0x1
3890 value = 1
3893 else
3895 endif

Confidential
31-May-2019

3897 Xenco( n ) = “0001 s x”
3898 where,
3903 sign = Xenco( n ) & 0x2
3904 value = 4 * (Xenco( n ) & 0x1) + 3 + 1
3908 Xdeco( n ) = 0
3909 endif
3910 else
3912 if (Xdeco( n ) > 1023) then
3913 Xdeco( n ) = 1023
3914 endif
3915 endif

3917 Xenco( n ) = “001 s xx”
3918 where,
3923 sign = Xenco( n ) & 0x4
3924 value = 8 * (Xenco( n ) & 0x3) + 11 + 3
3928 Xdeco( n ) = 0
3929 endif
3930 else
3932 if (Xdeco( n ) > 1023) then
3933 Xdeco( n ) = 1023
3934 endif
3935 endif

Confidential
31-May-2019

3937 Xenco( n ) = “01 s xxx”
3938 where,
3943 sign = Xenco( n ) & 0x8
3944 value = 16 * (Xenco( n ) & 0x7) + 43 + 7
3948 Xdeco( n ) = 0
3949 endif
3950 else
3952 if (Xdeco( n ) > 1023) then
3953 Xdeco( n ) = 1023
3954 endif
3955 endif

3958 where,
3963 value = 32 * (Xenco( n ) & 0x1f)
3965 Xdeco( n ) = value + 15
3966 else
3967 Xdeco( n ) = value + 16
3968 endif

Confidential
31-May-2019

3970 Xdeco( n ) = 4 * Xenco( n ) + 2
3972 if (Xenco( n ) & 0x300 == 0x000) then
3973 use DPCM1
3975 use DPCM2
3977 use DPCM3
3978 else
3979 use PCM
3980 endif

3982 Xenco( n ) = “00 s xxxxxxx”
3983 where,
3988 sign = Xenco( n ) & 0x80
3989 value = Xenco( n ) & 0x7f
3992 else
3994 endif

Confidential
31-May-2019

3997 where,
4002 sign = Xenco( n ) & 0x40
4003 value = 2 * (Xenco( n ) & 0x3f) + 128
4006 else
4008 endif

4011 where,
4016 sign = Xenco( n ) & 0x40
4017 value = 4 * (Xenco( n ) & 0x3f) + 256 + 1
4021 Xdeco( n ) = 0
4022 endif
4023 else
4025 if (Xdeco( n ) > 4095) then
4026 Xdeco( n ) = 4095
4027 endif
4028 endif

Confidential
31-May-2019

4030 Xenco( n ) = “1 xxxxxxxxx”
4031 where,
4034 “xxxxxxxxx” is the nine bit value field
4036 value = 8 * (Xenco( n ) & 0x1ff)
4039 endif
4040 else
4042 endif

Confidential
31-May-2019

4044 Xdeco( n ) = 16 * Xenco( n ) + 8
4046 if (Xenco( n ) & 0xf0 == 0x00) then
4047 use DPCM1
4049 use DPCM2
4051 use DPCM3
4053 use DPCM4
4054 else if (Xenco( n ) & 0xf0 == 0x10) then
4055 use DPCM5
4056 else
4057 use PCM
4058 endif

4060 Xenco( n ) = “0000 s xxx”
4061 where,
4066 sign = Xenco( n ) & 0x8
4070 else
4072 endif

4074 Xenco( n ) = “011 s xxxx”
4075 where,
4080 sign = Xenco( n ) & 0x10
4081 value = 2 * (Xenco( n ) & 0xf) + 8
4084 else
4086 endif

Confidential
31-May-2019

4088 Xenco( n ) = “010 s xxxx”
4089 where,
4094 sign = Xenco( n ) & 0x10
4095 value = 4 * (Xenco( n ) & 0xf) + 40 + 1
4099 Xdeco( n ) = 0
4100 endif
4101 else
4103 if (Xdeco( n ) > 4095) then
4104 Xdeco( n ) = 4095
4105 endif
4106 endif

4108 Xenco( n ) = “001 s xxxx”
4109 where,
4114 sign = Xenco( n ) & 0x10
4115 value = 8 * (Xenco( n ) & 0xf) + 104 + 3
4119 Xdeco( n ) = 0
4120 endif
4121 else
4123 if (Xdeco( n ) > 4095)
4124 Xdeco( n ) = 4095
4125 endif
4126 endif

Confidential
31-May-2019

4128 Xenco( n ) = “0001 s xxx”
4129 where,
4134 sign = Xenco( n ) & 0x8
4135 value = 16 * (Xenco( n ) & 0x7) + 232 + 7
4139 Xdeco( n ) = 0
4140 endif
4141 else
4143 if (Xdeco( n ) > 4095) then
4144 Xdeco( n ) = 4095
4145 endif
4146 endif

4149 where,
4154 value = 32 * (Xenco( n ) & 0x7f)
4156 Xdeco( n ) = value + 15
4157 else
4158 Xdeco( n ) = value + 16
4159 endif

Confidential
31-May-2019

4161 Xdeco( n ) = 32 * Xenco( n ) + 16
4163 if (Xenco( n ) & 0x78 == 0x00) then
4164 use DPCM1
4166 use DPCM2
4168 use DPCM3
4170 use DPCM4
4172 use DPCM5
4174 use DPCM6
4175 else
4176 use PCM
4177 endif

4179 Xenco( n ) = “0000 s xx”
4180 where,
4185 sign = Xenco( n ) & 0x4
4189 else
4191 endif

Confidential
31-May-2019

4193 Xenco( n ) = “0001 s xx”
4194 where,
4199 sign = Xenco( n ) & 0x4
4200 value = 2 * (Xenco( n ) & 0x3) + 4
4203 else
4205 endif

4207 Xenco( n ) = “0010 s xx”
4208 where,
4213 sign = Xenco( n ) & 0x4
4214 value = 4 * (Xenco( n ) & 0x3) + 12 + 1
4218 Xdeco( n ) = 0
4219 endif
4220 else
4222 if (Xdeco( n ) > 4095) then
4223 Xdeco( n ) = 4095
4224 endif
4225 endif

Confidential
31-May-2019

4227 Xenco( n ) = “010 s xxx”
4228 where,
4233 sign = Xenco( n ) & 0x8
4234 value = 8 * (Xenco( n ) & 0x7) + 28 + 3
4238 Xdeco( n ) = 0
4239 endif
4240 else
4242 if (Xdeco( n ) > 4095) then
4243 Xdeco( n ) = 4095
4244 endif
4245 endif

4247 Xenco( n ) = “011 s xxx”
4248 where,
4253 sign = Xenco( n ) & 0x8
4254 value = 16 * (Xenco( n ) & 0x7) + 92 + 7
4258 Xdeco( n ) = 0
4259 endif
4260 else
4262 if (Xdeco( n ) > 4095) then
4263 Xdeco( n ) = 4095
4264 endif
4265 endif

Confidential
31-May-2019

4267 Xenco( n ) = “0011 s xx”
4268 where,
4273 sign = Xenco( n ) & 0x4
4274 value = 32 * (Xenco( n ) & 0x3) + 220 + 15
4278 Xdeco( n ) = 0
4279 endif
4280 else
4282 if (Xdeco( n ) > 4095) then
4283 Xdeco( n ) = 4095
4284 endif
4285 endif

4288 where,
4293 value = 64 * (Xenco( n ) & 0x3f)
4295 Xdeco( n ) = value + 31
4296 else
4297 Xdeco( n ) = value + 32
4298 endif

Confidential
31-May-2019

4300 Xdeco( n ) = 64 * Xenco( n ) + 32
4302 if (Xenco( n ) & 0x3c == 0x00) then
4303 use DPCM1
4305 use DPCM3
4307 use DPCM4
4309 use DPCM5
4311 use DPCM6
4312 else if (Xenco( n ) & 0x3c == 0x0c) then
4313 use DPCM7
4314 else
4315 use PCM
4316 endif
4317 Note: DPCM2 is not used.

4319 Xenco( n ) = “0000 s x”
4320 where,
4325 sign = Xenco( n ) & 0x2
4329 else
4331 endif

Confidential
31-May-2019

4333 Xenco( n ) = “0001 s x”
4334 where,
4339 sign = Xenco( n ) & 0x2
4340 value = 4 * (Xenco( n ) & 0x1) + 2 + 1
4344 Xdeco( n ) = 0
4345 endif
4346 else
4348 if (Xdeco( n ) > 4095) then
4349 Xdeco( n ) = 4095
4350 endif
4351 endif

4353 Xenco( n ) = “010 s xx”
4354 where,
4359 sign = Xenco( n ) & 0x4
4360 value = 8 * (Xenco( n ) & 0x3) + 10 + 3
4364 Xdeco( n ) = 0
4365 endif
4366 else
4368 if (Xdeco( n ) > 4095) then
4369 Xdeco( n ) = 4095
4370 endif
4371 endif

Confidential
31-May-2019

4373 Xenco( n ) = “0010 s x”
4374 where,
4379 sign = Xenco( n ) & 0x2
4380 value = 16 * (Xenco( n ) & 0x1) + 42 + 7
4384 Xdeco( n ) = 0
4385 endif
4386 else
4388 if (Xdeco( n ) > 4095) then
4389 Xdeco( n ) = 4095
4390 endif
4391 endif

4393 Xenco( n ) = “011 s xx”
4394 where,
4399 sign = Xenco( n ) & 0x4
4400 value = 32 * (Xenco( n ) & 0x3) + 74 + 15
4404 Xdeco( n ) = 0
4405 endif
4406 else
4408 if (Xdeco( n ) > 4095) then
4409 Xdeco( n ) = 4095
4410 endif
4411 endif

Confidential
31-May-2019

4413 Xenco( n ) = “0011 s x”
4414 where,
4419 sign = Xenco( n ) & 0x2
4420 value = 64 * (Xenco( n ) & 0x1) + 202 + 31
4424 Xdeco( n ) = 0
4425 endif
4426 else
4428 if (Xdeco( n ) > 4095) then
4429 Xdeco( n ) = 4095
4430 endif
4431 endif

4434 where,
4439 value = 128 * (Xenco( n ) & 0x1f)
4441 Xdeco( n ) = value + 63
4442 else
4443 Xdeco( n ) = value + 64
4444 endif

Confidential
31-May-2019
Annex F JPEG Interleaving (informative)

4445 This annex illustrates how the standard features of the CSI-2 protocol should be used to interleave (multiplex)
4446 JPEG image data with other types of image data, e.g. RGB565 or YUV422, without requiring a custom JPEG
4447 format such as JPEG8.
4448 The Virtual Channel Identifier and Data Type value in the CSI-2 Packet Header provide simple methods of
4449 interleaving multiple data streams or image data types at the packet level. Interleaving at the packet level
4450 minimizes the amount of buffering required in the system.
4451 The Data Type value in the CSI-2 Packet Header should be used to multiplex different image data types at
4452 the CSI-2 transmitter and de-multiplex the data types at the CSI-2 receiver.
4453 The Virtual Channel Identifier in the CSI-2 Packet Header should be used to multiplex different data streams
4454 (channels) at the CSI-2 transmitter and de-multiplex the streams at the CSI-2 receiver.
4455 The main difference between the two interleaving methods is that images with different Data Type values
4456 within the same Virtual Channel use the same frame and line synchronization information, whereas multiple
4457 Virtual Channels (data streams) each have their own independent frame and line synchronization information
4458 and thus potentially each channel may have different frame rates.
4459 Since the predefined Data Type values represent only YUV, RGB and RAW data types, one of the User
4460 Defined Data Type values should be used to represent JPEG image data.
4461 Figure 207 illustrates interleaving JPEG image data with YUV422 image data using Data Type values.
4462 Figure 208 illustrates interleaving JPEG image data with YUV422 image data using both Data Type values
4463 and Virtual Channel Identifiers.
Frame Start Packet YUV422 Data Type User Defined Data Type
LPS SoT FS EoT LPS SoT PH YUV422 Data PF EoT LPS SoT PH JPEG Data PF EoT
YUV422 Data Type YUV422 Data Type User Defined Data Type
LPS SoT PH YUV422 Data PF EoT LPS SoT PH YUV422 Data PF EoT LPS SoT PH JPEG Data PF EoT
YUV422 Data Type User Defined Data Type Frame End Packet
LPS SoT PH YUV422 Data PF EoT LPS SoT PH JPEG Data PF EoT LPS SoT FE EoT LPS
KEY:
LPS – Low Power State PH – Packet Header FS – Frame Start Packet
SoT – Start of Transmission PF – Packet Footer FE – Frame End Packet
4464
Figure 207 Data Type Interleaving: Concurrent JPEG and YUV Image Data

Confidential
31-May-2019

Frame Start Packet User Defined Data Type Frame Start Packet YUV422 Data Type
SoT FS EoT LPS SoT PH JPEG Data PF EoT LPS SoT FS EoT LPS SoT PH YUV422 Data PF EoT

User Defined Data Type YUV422 Data Type User Defined Data Type
LPS SoT PH JPEG Data PF EoT LPS SoT PH YUV422 Data PF EoT LPS SoT PH JPEG Data PF EoT

YUV422 Data Type Frame End Packet User Defined Data Type Frame End Packet
LPS SoT PH YUV422 Data PF EoT LPS SoT FE EoT LPS SoT PH JPEG Data PF EoT LPS SoT FE EoT
KEY:
LPS – Low Power State PH – Packet Header FS – Frame Start Packet
SoT – Start of Transmission PF – Packet Footer FE – Frame End Packet
4465
Figure 208 Virtual Channel Interleaving: Concurrent JPEG and YUV Image Data
4466 Both Figure 207 and Figure 208 can be similarly extended to the interleaving of JPEG image data with any
4467 other type of image data, e.g. RGB565.
4468 Figure 209 illustrates the use of Virtual Channels to support three different JPEG interleaving usage cases:
4469 • Concurrent JPEG and YUV422 image data.
4470 • Alternating JPEG and YUV422 output - one frame JPEG, then one frame YUV
4471 • Streaming YUV22 with occasional JPEG for still capture
4472 Again, these examples could also represent interleaving JPEG data with any other image data type.
Use Case 1: Concurrent JPEG output with YUV data
JPEG JPEG JPEG JPEG 1 Frame 1 Frame JPEG JPEG JPEG JPEG
VC0 Frame VC0
CSI-2 RX
CSI-2 TX
Frame Frame Frame Frame Frame Frame Frame

YJYJ YJYJ YJYJ YJYJ
YUV YUV YUV YUV YUV YUV YUV YUV
VC1 Frame Packet interleaved JPEG and VC1
Frame Frame Frame Frame Frame Frame Frame
YUV data
Use Case 2: Alternating JPEG and YUV output – one frame JPEG, then one frame YUV
JPEG JPEG JPEG JPEG

VC0 VC0
CSI-2 RX
CSI-2 TX
Frame Frame Frame Frame

YUV JPEG YUV JPEG
YUV YUV YUV YUV
VC1 Frame CSI-2 RX uses the Virtual VC1
Frame Frame Frame
Channel and Data Type
codes to de-multiplex data
Use Case 3: Streaming YUV with occasional JPEG still capture
JPEG JPEG
VC0 VC0
CSI-2 RX
CSI-2 TX
Frame Frame
YUV YUV JPEG YUV
YUV YUV YUV YUV YUV YUV

VC1 Frame VC1
Frame Frame Frame Frame Frame
4473
Figure 209 Example JPEG and YUV Interleaving Use Cases

Confidential
31-May-2019
Annex G Scrambler Seeds for Lanes 9 and Above

4474 (See also: Section 9.12).
4475 For Links of 9 to 32 Lanes, the Scrambler PRBS registers of Lanes 9 through 32 should be initialized with
4476 the initial seed values as listed in Table 63.
4477 For Links of more than 32 Lanes, the Scrambler PRBS registers of Lanes 33 and higher shall use the same
4478 initial seed value that is used for the Lane number modulo 32. (See Section 9.12 and Table 63.)
4479 Examples:
4480 • Lane 33 shall use the same initial seed value as Lane 1
4484 Table 63 Initial Seed Values for Lanes 9 through 32
Lane Initial Seed Value
9 0x1818
10 0x1998
11 0x1a59
12 0x1bd8
13 0x1c38
14 0x1db8
15 0x1e78
16 0x1ff8
17 0x0001
18 0x0180
19 0x0240
20 0x03c0
21 0x0420
22 0x05a0
23 0x0660
24 0x07e0
25 0x0810
26 0x0990
27 0x0a51
28 0x0bd0
29 0x0c30
30 0x0db0
31 0x0e70
32 0x0ff0
4485 Note that the binary representation of each initial seed value is symmetrical with respect to the forwards and
4486 backwards directions, with the exceptions of Lanes 11, 17, and 27. The initial seed values can be created
4487 easily using a Lane index value (i.e., Lane number minus one).

Confidential
31-May-2019

4488

Confidential
31-May-2019
Annex H Guidance on CSI-2 Over C-PHY ALP and PPI

H.1 CSI-2 with C-PHY ALP Mode
4489 C-PHY Alternate Low Power (ALP) Mode is an alternative to the legacy LP mode of C-PHY. ALP Mode
4490 uses solely High-Speed signaling with a special state where the signals can cease toggling and collapse to
4491 zero. The legacy LP Mode signaling and escape sequences have equivalent ALP Mode functions so that the
4492 high-voltage low power signaling can be replaced by ALP Mode signaling if that is beneficial in specific
4493 systems. ALP Mode replaces the legacy LP Mode line levels by the transmission of unique code words that
4494 are used only for Lane signaling events. These unique codes are never produced by the 3-Phase mapping
4495 function, so there is never ambiguity in the interpretation of these codes at the receiver.
4496 Reasons to replace the legacy LP mode with equivalent ALP Mode functions are to begin a transitionary path
4497 to the future so that legacy LP mode might someday be eliminated in some devices. Another reason to choose
4498 ALP Mode over Legacy LP mode is to support systems that have long interconnect between the Master and
4499 Slave devices.
H.1.1 Concepts of ALP Mode and Legacy LP Mode

4500 In ALP mode, the conventional LP receivers are not used to detect signaling states. Instead, all
4501 communication is performed using High-Speed signaling levels. The system level functions performed by
4502 ALP signaling are quite similar to the functional behavior of legacy LP mode. The intent of this is to cause
4503 the least amount of disruption to systems that support both ALP Mode and legacy LP mode. Figure 210
4504 shows a comparison of a High-Speed data burst with LP Mode versus ALP Mode. The purpose of this diagram
4505 is to show that each of the intervals in the High-Speed data burst with LP mode correspond to similar intervals
4506 in the High-Speed data burst with ALP mode.
HS Data Burst with LP Mode

t3-PREAMBLE
A/B/C tLPX t3-PREPARE
t3-PREBEGIN t3-PREEND t3-SYNC
3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 3 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
Packet t3-POST tHS-EXIT

Preamble Sync Word
Data Post
LP-111 LP-001 LP-000 LP-111
HS Data Burst with ALP Mode

HS Burst
ALP-Pause ALP-Pause
Preamble, Sync & Data ALP Command ALP-Pause Stop
Stop Wake
A/B/C +x state Packet Stop Stop
Preamble Sync Word Post1 Post2
VA = V B = V C Data Code Code VA = V B = V C
4507
Figure 210 Comparing Data Burst Timing of Legacy LP mode versus ALP Mode
4508 ALP Mode supports the transmission of High-Speed data bursts as well as the transmission of control
4509 sequences that are traditionally transmitted using legacy LP mode Escape Mode sequences. The format of all
4510 ALP mode bursts is like the timing diagram in Figure 211.
4511 The burst begins and ends in an ALP-Pause state. There are two types of ALP-Pause: ALP-Pause Stop and
4512 ALP-Pause ULPS. ALP-Pause Stop is analogous to the legacy LP mode Stop state; ALP-Pause ULPS is
4513 analogous to the legacy LP mode ULPS state. The only difference between these two types of ALP-Pause
4514 states is the time allowed to wake up from each, which is the duration of the ALP-Pause Wake interval. The
4515 nominal time allowed to wake from ALP-Pause Stop is 100 ns, which is about the same time as the duration
4516 of the LP-001 and LP-000 states at the beginning of a HS Data Burst using legacy LP mode. The nominal
4517 time to wake from the ALP-Pause ULPS state is 1 msec, which is approximately the time allowed in legacy
4518 LP mode for tWAKEUP. (The time that a transmitter drives a Mark-1 state prior to a Stop state to initiate an exit
4519 from ULPS.) The longer wake-up time from ALP-Pause ULPS compared to ALP-Pause Stop allows a lower
4520 power consumption while in the ALP-Pause ULPS state.

Confidential
31-May-2019
4521 The ALP-Pause Stop and ALP-Pause ULPS line states are defined by the following relationships of the Line
4522 levels: VA = VB = VC, and VOD_AB = VOD_BC = VOD_CA = 0. Examples of the ALP-Pause and the ALP-Pause
4523 Wake states are illustrated at the beginning and end of the waveform in Figure 211. The ALP-Pause Wake
4524 state, which is very long compared to a High-Speed Unit Interval, is detected by the low-power wake-up
4525 receiver. This causes the system to leave one of the ALP-Pause states and to begin receiving a High-Speed
4526 signal.
ALP-Pause Stop or ALP-Pause Stop or

ALP-Pause Wake Preamble Post2
ALP-Pause ULPS ALP-Pause ULPS
7 UI
High A
Mid C ...
Low
VA = V B = V C B VA = VB = VC
Post2
“+x” state 3's or 1's Sequence
t3-ALP-PAUSE t3-ALP-PAUSE-WAKE t3-POST2 t3-ALP-PAUSE
4527
Figure 211 ALP Mode General Burst Format
4528 To minimize power consumption while Lane activity has ceased during one of the ALP-Pause states, a special
4529 low-speed and low-power differential receiver circuit is present, in addition to the three High-Speed
4530 differential receivers for A-B, B-C and C-A. This special low-speed and low-power differential receiver has
4531 a nominal +80 mV offset input threshold voltage that detects the difference in differential levels between the
4532 ALP-Pause state (VOD = 0) and ALP-Pause Wake state (VOD = |VOD| Strong). This allows the line signals to
4533 collapse to zero with the 100Ω ZID termination still connected, and still have a well-defined method to detect
4534 the difference between the ALP-Pause and ALP-Pause Wake line conditions. Collapsing to zero with the
4535 terminations still connected makes it possible for implementations to have very low power consumption
4536 during the ALP-Pause states. The ALP-Pause Wake pulse is very long compared to a High-Speed Unit
4537 Interval so that the wake receiver can be slow and consume very little power compared to the High-Speed
4538 differential receivers.

Confidential
31-May-2019
4539 An example of the differential receiver circuit to support ALP mode is shown in Figure 212. Two different
4540 offset receivers are shown for wake from stop versus wake from ULPS, because the power consumption in
4541 the ALP-Pause ULPS state is expected to be lower than in ALP-Pause Stop state. The ALP-Pause Wake pulse
4542 from the ULPS state can be longer than waking from ALP-Pause Stop, so the ALP ULPS receiver can be
4543 slower and consume less power compared to the ALP Stop receiver.
LP Rx
HS
A + Rx_AB
ZTERM
50Ω - LP Rx
HS
B + Rx_BC
ZTERM
50Ω - LP Rx
HS
C + Rx_CA
ZTERM
50Ω -
CCP
ALP_Stop
+ ALP_Pause_Wake_from_Stop
VOFFSET
+80mV
-
ALP_ULPS
+ ALP_Pause_Wake_from_ULPS
VOFFSET
+80mV
-
4544
Figure 212 High-Speed and ALP-Pause Wake Receiver Example
4545 The C-PHY specification defines thirteen unique 7-symbol ALP Code Words that are the functional
4546 equivalent of the LP pulse sequences of legacy LP mode. In some cases, a single 7-symbol ALP Code Word
4547 can replace the transmission of a long sequence of legacy LP mode pulses, such as for the transmission of
4548 Escape Mode triggers or low-power data transmission. The CSI-2 specification needs only three of these LP
4549 mode pulse sequences to emulate the functionality of legacy LP mode: Stop Code, ULPS Code, and Post. A
4550 fourth code, the TAC Code, is used for Fast Bus Turnaround.
4551 Exit from and entry into the ALP-Pause state, which is the functional equivalent of the legacy LP mode Stop
4552 state, requires a special ALP Mode sequence consisting of one or more Stop Codes or ULPS codes followed
4553 by a string of Post codes followed by setting the voltage of all three Lines of a Lane to the same value.
4554 As illustrated in Figure 210, the burst starting sequence of the legacy LP mode consisting of: LP-111, LP-
4555 001, and LP-000 followed by preamble, has a functional equivalent sequence in ALP Mode consisting of:
4556 ALP-Pause Stop followed by ALP Pause Wake followed by preamble. Similarly, the burst ending sequence
4557 of legacy LP mode consisting of Post sequence followed by LP-111, has a functional equivalent sequence in
4558 ALP Mode consisting of: the Post1 field by two or more Stop Codes followed by the Post2 field followed by
4559 ALP-Pause Stop.

Confidential
31-May-2019
H.1.2 Burst Examples Using ALP Mode

4560 Figure 213 shows examples of the three types of High-Speed bursts that can be sent in ALP mode. Many
4561 combinations of ALP code sequences are possible, but Figure 213 shows three sequences that adequately
4562 perform the functions necessary to support CSI-2 that are currently performed using legacy LP mode. The
4563 ALP state machine from the C-PHY Specification has been highlighted in Figure 214, Figure 215, and
4564 Figure 216 to show how transmission of these three sequences should occur.
4565 For interop sake, only these three types of sequences are required to support CSI-2. Note that all bursts begin
4566 in the same manner with the assertion of ALP-Pause Wake followed by a Preamble. The words that follow
4567 the Preamble determine the type of burst that is being transmitted. All bursts end in the same manner with
4568 multiple Stop Codes followed by the Post2 field, or multiple ULPS Codes followed by the Post2 field. The
4569 Post 1 and Post2 fields are the same as Post (4444444), described in the C-PHY specification for burst
4570 transmission using legacy LP mode. The only difference is that the Post1 and Post2 fields are transmitted as
4571 a result of signaling over the PPI from the CSI-2 Tx to the C-PHY Tx.
4572 The last ALP code sent in the burst determines whether the system enters the ALP-Pause Stop or the ALP-
4573 Pause ULPS state.

Confidential
31-May-2019
High Speed Data Burst

ALP-Pause HS Burst
ALP-Pause Stop ALP Command ALP-Pause Stop
Wake
Lane +x state Packet Packet High-Speed Stop Stop
Signals Preamble Sync Sync Post1 Post2
VA = V B = V C Header Header Forward Data Code Code VA = V B = V C
Command to Enter ULPS

ALP Pause
ALP-Pause Stop ALP Command ALP-Pause ULPS
Wake
Lane +x state ULPS ULPS
Signals Preamble Post2
VA = V B = V C Code Code VA = V B = V C
Command to Exit from ULPS

ALP-Pause ULPS ALP-Pause Wake (from ULPS, ~1 msec) ALP Command ALP-Pause Stop
Lane +x state Stop Stop
Signals Preamble Code Code Post2
VA = V B = V C VA = V B = V C
4574
Figure 213 Examples of Bursts to Send High-Speed Data and ALP Commands

Confidential
31-May-2019
4575 Figure 214 shows the ALP state machine transitions (highlighted in red) necessary to transmit a High-Speed
4576 data burst in ALP mode. States and state transitions that are not used by CSI-2 for any type of burst are shown
4577 using dashed lines. The red highlighted states and transitions indicate the path required to transmit and receive
4578 the High-Speed Data Burst example in Figure 213.
Power-up +x state
ALP-Pause Wake
HS Burst
ALP Post2 ALP-Pause
Preamble
ULPS Code to ULPS ULPS
from ULPS
ALP Codes
(not Stop
LP or ULPS)
Stop State +x state
ALP-Pause Wake
HS Burst
ALP-Pause HS Sync ALP
Preamble HS Data Post1
Stop Word Stop Code
from Stop
HS Cal. HS Cal.
HS Cal. Post2
Alt. Seq. Alternate
Preamble to Stop
Identifier Sequence
HS Cal.
HS Cal.
User-
UD Seq.
Defined
Identifier
Seq.
4579
Figure 214 State Transitions for an HS Data Burst

Confidential
31-May-2019
4580 Figure 215 shows the ALP state machine transitions (highlighted in red) necessary to enter the ALP-Pause
4581 ULPS state.
Power-up +x state
ALP-Pause Wake
HS Burst
ALP Post2 ALP-Pause
Preamble
from ULPS
ALP Codes
(not Stop
LP or ULPS)
Stop State +x state
ALP-Pause Wake
HS Burst
Stop Word Stop Code
from Stop
HS Cal. HS Cal.
HS Cal. Post2
Alt. Seq. Alternate
Preamble to Stop
Identifier Sequence
HS Cal.
HS Cal.
User-
UD Seq.
Defined
Identifier
Seq.
4582
Figure 215 State Transitions to Enter the ULPS State

Confidential
31-May-2019
4583 Figure 216 shows the ALP state machine transitions (highlighted in red) necessary to enter the ALP-Pause
4584 Stop state.
Power-up +x state
ALP-Pause Wake
HS Burst
ALP Post2 ALP-Pause
Preamble
from ULPS
ALP Codes
(not Stop
LP or ULPS)
Stop State +x state
ALP-Pause Wake
HS Burst
Stop Word Stop Code
from Stop
HS Cal. HS Cal.
HS Cal. Post2
Alt. Seq. Alternate
Preamble to Stop
Identifier Sequence
HS Cal.
HS Cal.
User-
UD Seq.
Defined
Identifier
Seq.
4585
Figure 216 State Transitions to Exit from the ULPS State
4586 Table 64 describes the 7-symbol codes transmitted in ALP mode. The corresponding LP mode or Escape
4587 mode function is described, where applicable.
4588 Table 64 ALP Code Definitions used by CSI-2
Symbol PPI ALP
ALP Code Corresponding LP State or Escape Mode Sequence
Sequence Code
Stop Code 0244440 0b0000 LP-111 (End of Transmission, or EoT)
ULPS Code 0244441 0b0001 Escape Mode Entry + Ultra-Low Power State (ULPS)
Post1 No equivalent legacy LP mode sequence exists. The CSI-2
4444444 0b1011 TX can cause the Post sequence to be transmitted by
Post2 sending this code.
2144441 0b1100 No equivalent legacy LP mode sequence exists,
Turnaround
although TAC triggers a Fast Lane Turnaround that is
Code (TAC)
functionally similar to Control Mode Turnaround.

Confidential
31-May-2019
H.1.3 Transmission and Reception of ALP Commands Through the PPI

4589 In ALP mode there are three types of code words transmitted by the PHY:
4590 • Data: Data words received from the CSI-2 Tx are mapped through the C-PHY mapper, encoded,
4591 and transmitted over the Lane.
4592 • Sync Words: The CSI-2 Tx can cause the C-PHY Tx to transmit a Sync Word in place of a data
4593 word created by the C-PHY mapper. Sync Words can have one of five different values which are
4594 defined as Sync Types.
4595 • ALP Codes: The CSI-2 Tx can cause the C-PHY Tx to transmit a specific ALP code which is one
4596 of the 7-symbol sequences defined in Table 64.
4597 These three different types of code words comprise a high speed burst while in ALP mode. Figure 217
4598 highlights the control signals that facilitate the transmission of each of these three different types of code
4599 words.
Data
TxDataHS[15:0] RxDataHS[15:0]
TxWordValidHS[0] RxInvalidCodeHS[0]
RxValidHS[0]
Sync Codes
TxSyncTypeHS0[2:0] RxSyncTypeHS0[2:0]
TxSendSyncHS[0] RxSyncHS[0]
A
ALP Codes B
CSI-2 TX TxALPCodeHS0[3:0] C-PHY TX C-PHY RX RxALPCode0[3:0] CSI-2 RX
C
TxSendALPHS[0] RxALPValidHS[0]
TxALPNibble0[3:0] RxALPNibble0[3:0]
TxRequestHS
TxReadyHS RxActiveHS
TxWordClkHS RxWordClkHS
4600
Figure 217 PPI Example: HS Signals for Transmission of Data, Sync and ALP Commands
4601 Figure 218 and Figure 219 show examples of PPI signals and the corresponding PHY data for transmission
4602 and reception of high speed data in ALP mode. These figures show additional detail of the High-Speed Data
4603 Burst waveform in Figure 213.
4604 The signal TxRequestHS is asserted simultaneously with TxWordValidHS to request that a high speed burst
4605 be transmitted. The PHY will know to send a data burst because TxWordValidHS is asserted early in the burst
4606 timing. This will cause the C-PHY Tx to transmit the first Sync Word at the end of the Preamble. Note that
4607 the first Sync Word is transmitted autonomously by the C-PHY Tx, and has the default Sync Type value of
4608 3. Subsequent Sync Words transmitted in a burst are sent as a result of asserting the TxSendSyncHS[0] signal,
4609 and the associated Sync Type is defined by the TxSyncTypeHS0[2:0] signals.
4610 The end of burst in the Transmitter functions differently for ALP mode compared to the non-ALP high-speed
4611 mode. In the non-ALP high-speed mode, the end of burst is signaled to the PHY by pulling TxRequestHS
4612 low, as described in Annex A of the C-PHY specification. After TxRequestHS goes low, the C-PHY Tx will
4613 generate the Post sequence of length determined by a PHY configuration parameter that sets the length of
4614 Post.
4615 In ALP mode, the protocol transmit unit generates all fields of the burst after the first sync word, including
4616 the packet headers, data burst, Stop Code, ULPS Code, Post1, and Post2. The burst is ended by pulling
4617 TxRequestHS low, and no additional data is transmitted on the Lane after this time.

Confidential
31-May-2019
Transmit a HS Data Burst
HS Burst
ALP-Pause ALP-Pause
ALP-Pause Stop ALP Command
Wake Stop
Lane +x state Preamble Sync
Packet
Sync
Packet High-Speed
Post1
Stop Stop
Post2
Header Header Forward Data Code Code
Signals
VA = VB = VC VA = VB = VC
PH PH PH PH PH PH
TxDataHS[X:0] dc W1 W2 W3 dc W1 W2 W3 W4 W5 Wn dc
TxWordValidHS
TxSendSyncHS
TxSendALPHS
Stop Stop
TxALPCodeHS[3:0] dc Post1
Code Code
Post2 dc
TxRequestHS
TxReadyHS
4618
Figure 218 PPI Example Transmit Side Timing for an HS Data Burst

Confidential
31-May-2019
Receive a HS Data Burst
HS Burst
ALP-Pause ALP-Pause ALP-Pause
Stop Wake ALP Command
Stop
Lane +x state Preamble Sync
Packet
Sync
Packet High-Speed
Post1
Stop Stop
Post2
Header Header Forward Data Code Code
Signals
PH PH PH PH PH PH W4 W5
RxDataHS[X:0] dc W1 W2 W3 dc W1 W2 W3 Wn dc
RxValidHS
RxSyncHS
RxALPValidHS dc
Stop Stop
RxALPCode[3:0] dc Post1
Code Code
Post2 dc
RxActiveHS dc
4619
Figure 219 PPI Example Receive Side Timing for an HS Data Burst

Confidential
31-May-2019
4620 Figure 220, Figure 221, Figure 222, and Figure 223 show examples of PPI signals and the corresponding
4621 PHY data for transmission and reception ALP Commands to enter into and exit from the ALP-Pause ULPS
4622 state in ALP mode. These figures show additional detail of the Command to Enter ULPS and the Command
4623 to Exit from ULPS waveforms in Figure 213.
4624 The signal TxRequestHS is asserted simultaneously with TxSendALPHS to request that a high speed burst
4625 be transmitted. The PHY will know to send a ALP commands in the burst rather than the Sync Word because
4626 TxSendALPHS is asserted early in the burst timing, and TxWordValidHS is not asserted.
Transmit a Command to Enter ULPS
ALP-Pause
ALP-Pause Stop Preamble ALP Command ALP-Pause ULPS
Wake
Lane +x state Preamble
ULPS ULPS
Post2
Code Code
Signals
TxDataHS[X:0] dc
TxWordValidHS
TxSendSyncHS
TxSendALPHS
TxALPCodeHS[3:0] dc ULPS Post2 dc
TxRequestHS
TxReadyHS
4627
Figure 220 PPI Example Transmit Side Timing to Enter the ULPS State
Receive a Command to Enter ULPS
ALP-Pause
ALP-Pause Stop Preamble ALP Command ALP-Pause ULPS
Wake
Lane +x state Preamble
ULPS ULPS
Code Code
Post2
Signals
RxDataHS[X:0] dc
RxValidHS
RxSyncHS
RxALPValidHS
ULPS ULPS
RxALPCode[3:0] dc Code Code
Post2 dc
RxActiveHS dc
4628
Figure 221 PPI Example Receive Side Timing to Enter the ULPS State

Confidential
31-May-2019
Transmit a Command to Exit from ULPS
ALP-Pause Wake
ALP-Pause ULPS Preamble ALP Command ALP-Pause Stop
(from ULPS, ~1 msec)
Lane +x state Preamble Stop Stop
Post2
Code Code
Signals
TxDataHS[X:0]
TxWordValidHS
TxSendSyncHS
TxSendALPSHS
TxALPCodeHS[3:0] dc Stop Post2 dc
TxRequestHS
TxReadyHS
4629
Figure 222 PPI Example Transmit Side Timing to Exit from the ULPS State
Receive a Command to Exit from ULPS
ALP-Pause Wake
ALP-Pause ULPS Preamble ALP Command ALP-Pause Stop
(from ULPS, ~1 msec)
Lane +x state Preamble Stop Stop
Post2
Code Code
Signals
TxDataHS[X:0] dc
RxValidHS
RxSyncHS
RxALPValidHS dc
Stop Stop
RxALPCode[3:0] dc Code Code Post2 dc
RxActiveHS dc
4630
Figure 223 PPI Example Receive Side Timing to Exit from the ULPS State

Confidential
31-May-2019
H.1.4 Multi-Lane Operation Using ALP Mode

4631 Figure 224 and Figure 225 show examples of three Lanes operating together in a Link in ALP mode. The
4632 High-Speed data burst in Figure 224 begins with identical packet headers (consisting of PH W0, PH W1,
4633 and PH W2) transmitted twice on each of the three Lanes. The Packet Headers are followed by packet data
4634 (consisting of DW 0 through DW n-1) striped across the three Lanes by the CSI-2 Lane Distribution Function.
4635 The burst starts and ends in the manner described in Section H.1.2 above. The example of Figure 225
4636 showing the command to enter ULPS has identical data on each of the three Lanes.
4637 The example also shows that the assertion of the +x state for ALP-Pause Wake can be staggered in time on
4638 each of the lanes. This is shown to highlight a particular implementation where the system designer might
4639 prefer to enable the high speed drivers for each of the Lanes at a slightly different time.

Confidential
31-May-2019
High Speed Data Burst, Three Lanes

ALP-Pause ALP
ALP-Pause Stop Wake HS Burst Command ALP-Pause Stop
Lane 1 +x state Sync PH PH PH Sync PH PH PH DW DW DW DW DW Stop Stop
Preamble Post1 Post2
Signals VA = V B = V C W0 W1 W2 W0 W1 W2 0 3 6 9 n-3 Code Code
VA = V B = V C
ALP-Pause ALP
VA = V B = V C
ALP-Pause ALP
VA = V B = V C
4640
Figure 224 Example Showing a Data Transmission Burst using Three Lanes
Command to Enter ULPS, Three Lanes

ALP-Pause ALP
ALP-Pause Stop Wake Command ALP-Pause ULPS
Lane 1 +x state ULPS ULPS
VA = VB = VC Code Code VA = VB = VC
ALP-Pause ALP
ALP-Pause ALP
4641
Figure 225 Example Showing an ALP Command Burst using Three Lanes

Confidential
31-May-2019
H.1.5 LP and ALP Operation

4642 Section 6.4.5.8 of [MIPI02] describes support of LP and ALP operation. The transmitter and receiver can be
4643 configured for LP-only operation, or ALP-only operation using the PPI signals TxALP-LPSelect and RxALP-
4644 LPSelect, respectively. Devices can use a variety of means such as a register, an I/O pin, or a non-volatile
4645 storage element to determine the initial state of these two PPI signals
H.1.6 Bi-Directional Lane Turnaround

4646 The transmission direction of a Bi-Directional Lane can be swapped by performing a Lane Turnaround
4647 procedure. This procedure enables information transfer in the opposite direction of the current direction. The
4648 procedure is the same for either a change from Forward Direction to Reverse Direction, or a change from
4649 Reverse Direction to Forward Direction. Notice that the roles of Master and Slave are not changed as a result
4650 of performing the Turnaround procedure.
4651 The Turnaround procedure can be performed in two ways: one is via a Control Mode Lane Turnaround that
4652 uses LP Mode signaling, and the other is via a Fast Lane Turnaround.
4653 Control Mode Lane Turnaround occurs by going to the Exit state (Control Mode) where LP Mode signaling
4654 is used to perform the Control Mode Turnaround procedure, as shown in Figure 226.
Control Mode Lane Turnaround

High-Speed High-Speed High-Speed
Sync
Sync
Sync
Preamble Post Preamble Post Preamble Post
Forward Data Reverse Data Forward Data
High-Speed Forward Data Turnaround High-Speed Reverse Data Turnaround High-Speed Forward Data
SoT EoT SoT EoT SoT EoT
Master is Driving Slave is Driving
Master is Driving
4655
Figure 226 High-Level View of the Control Mode Lane Turnaround Procedure
4656 A somewhat less likely configuration is to combine ALP mode and Control Mode Lane Turnaround if optional
4657 Dynamic LP and ALP operation is supported by the C-PHY, and if the electrical specifications can be met
4658 with the transmission channel being used in the system. An example is shown in Figure 227.
ALP with Control Mode Lane Turnaround

Post1
Post2
Stop
+x state Preamble
Sync
Sync
Sync
Post Preamble Post Preamble

High-Speed Forward Data Turnaround High-Speed Reverse Data Turnaround High-Speed Forward Data
EoT SoT EoT SoT
Master is Driving Slave is Driving
Master is Driving
4659
Figure 227 High-Level View of ALP Mode with the Control Mode Lane Turnaround
Procedure

Confidential
31-May-2019
4660 Fast Lane Turnaround is the most likely method to be used with the CSI-2 USL feature. Fast Lane Turnaround
4661 is performed without having to return to LP mode. This reduces the latency to change the transmission
4662 direction of a Bi-directional lane. Fast Lane Turnaround is handled completely in High-Speed mode. One or
4663 more Turnaround Codes (TAC) is transmitted near the end of the burst (between Post1 and Post 2) to inform
4664 the receiver that the Lane is about to change the transmission direction. A small Turnaround Gap (TGAP)
4665 exists between Post2 from the First Transmitting Device and the Preamble from the Second Transmitting
4666 Device to allow the Master and Slave to swap roles as transmitter and receiver. Figure 228 shows a high-
4667 level view of the Fast Lane Turnaround Procedure with ALP Mode. It is anticipated that the Fast Lane
4668 Turnaround will most often be used with ALP Mode, and infrequently with Control Mode.
Fast Lane Turnaround

High-Speed Post1 High-Speed High-Speed
Post2
Post1
Post2
Post1
Post2
Sync
Stop
+x state Preamble TGAP TGAP
Sync
Sync
TAC
TAC
Preamble Preamble
Master is Driving Slave is Driving Master is Driving
4669
Figure 228 High-Level View of the Fast Lane Turnaround Procedure with ALP Mode

Confidential
31-May-2019
4670 Figure 229 is a comparison of events that occur in the Fast Lane Turnaround Procedure versus the Control
4671 Mode Lane Turnaround Procedure. Fields that are the same color are either the same field in the two
4672 waveforms, or have comparable durations. Post1 + TAC + Post2 in the Fast Lane Turnaround is like Post in
4673 the Control Mode Lane Turnaround. The Preambles are the same duration and Syncs are the same duration.
4674 Fields that cause the durations of the two Turnaround methods to be different are highlighted with “Time
4675 difference between Fast Lane Turnaround and Control Mode Lane Turnaround” in the figure. In this case,
4676 the TGAP (nominally 14 UI) in the Fast Lane Turnaround waveform is usually much shorter in duration
4677 compared to the LP signaling (EoT + Turnaround + SoT, in the Control Mode Lane Turnaround waveform).
Fast Lane Turnaround

Post1
Post2
Post1
Post2
Post1
Post2
Stop
+x state Preamble TGAP TGAP
Sync
Sync
Sync
TAC
TAC
Preamble Preamble
Master is Driving Master is Driving
Slave is Driving
Fast Lane Turnaround Fast Lane Turnaround
Time Reduction Time Reduction
Control Mode Lane Turnaround

Sync
Sync
Sync
Preamble Post Preamble Post Preamble Post
SoT Transmitting High-Speed Forward Data Turnaround SoT Transmitting High-Speed Reverse Data Turnaround SoT Transmitting High-Speed Forward Data
EoT EoT EoT
Master is Driving Master is Driving
Slave is Driving
4678
Figure 229 High-Level View, Comparing Lane Turnaround Procedures
4679 The Fast Lane Turnaround Procedure is triggered by the transmission of a sequence of ALP codes at the end
4680 of a burst.

Confidential
31-May-2019
4681 Figure 230 shows the detailed sequence of events that occur during the Fast Lane Turnaround Procedure.
4682 The transmitting C-PHY ends the data burst by sending Post1, followed by the TAC symbol sequence,
4683 followed by Post2. TAC is the symbol sequence “2144441”, which is an unmapped sequence of seven
4684 symbols. The least significant symbol of TAC (“1”) is transmitted first and the most significant symbol (“2”)
4685 is transmitted last, which is the same convention used for transmitting any ALP code word. TAC may be
4686 transmitted multiple times for improved system reliability, to increase the probability that TAC will be
4687 detected by the receiver. The Post1 + TAC + Post2 is somewhat similar to the end of a burst in ALP mode,
4688 except that the TAC Code is sent instead of the Stop Code. The protocol receiver can easily identify the end
4689 of Packet Data when it detects Post1. The duration of the TAC and Post2 are programmable in the transmitter,
4690 and this duration is determined by the protocol layer. The protocol layer enables the transmission of Post1,
4691 TAC, and Post2 via the PPI signals TxSendALPHS[1:0], TxALPCodeHS0[3:0], and TxALPCodeHS1[3:0].
4692 The purpose of Post1 is to indicate the end of the burst and provide a sufficient number of word clock intervals
4693 so the protocol layer can gracefully stop transmitting and receiving packet data that is sent prior to Post1.
4694 Post2 exists so the C-PHY transmitter and receiver has a sufficient number of clock intervals following TAC
4695 to be able to shut down transmitter and receiver circuitry and change the direction of transmission.
4696 A Turnaround Gap (TGAP) exists to allow one transmitter to be disabled before the other is enabled. This
4697 avoids contention between the two drivers. The First Transmitting Device that sent the TAC disables its
4698 output by placing the driver into a high-impedance state just after the last symbol of Post2. The C-PHY
4699 ensures that the transmitter in the First Transmitting Device is completely disabled at the end of TGAP. The
4700 Second Transmitting Device begins to enable its output after TGAP at the beginning of the Preamble.
4701 When the Second Transmitting Device receives TAC, it starts a timer that is used to determine when the end
4702 of TGAP, and the beginning of Preamble, should occur. It is necessary for the Second Transmitting Device
4703 to identify this interval using a timer, because there are no transmissions during TGAP to identify when the
4704 Second Transmitting Device needs to begin transmitting the Preamble. The number of words of TAC and
4705 duration of Post2 can be stored in registers in both the First Transmitting Device and Second Transmitting
4706 Device, so the C-PHY can determine the proper t3-TAC_TO_TX time. This is so the Second Transmitting Device
4707 starts transmitting Preamble at the proper time at the end of TGAP. The number of words of TAC and duration
4708 of Post2 can be different when transmission changes from Master to Slave, versus from Slave to Master.
4709 Therefore, it is necessary for the Master and Slave to have registers related to the TAC duration and Post2
4710 duration for both types of turnaround (Master-to-Slave and Slave-to-Master).
4711 An interval t3-TA-SETTLE exists to allow the driver transmitting the Preamble to have sufficient time to stabilize
4712 before it is used by the receiver for symbol clock recovery. The t3-TA-SETTLE interval is a time during which
4713 the HS receiver in the C-PHY will ignore any HS transitions on the Lane. This concept is very similar to the
4714 t3-SETTLE time at the beginning of a HS burst from LP mode.
Transmission from Transmission from

First Transmitting Device Second Transmitting Device
7 to 224 UI ≥ 7 UI 7 to 224 UI 14 UI 7+7 to 448+7 UI

Fwd. High-Speed TGAP Preamble = High-Speed
Sync
TAC
TAC
TAC
to Post1 Post2
Rev. Forward Data PreBegin + ProgSeq + PreEnd Reverse Data
Rev. High-Speed TGAP Preamble = High-Speed

Sync
TAC
TAC
TAC
to Post1 Post2
Fwd. Reverse Data PreBegin + ProgSeq + PreEnd Forward Data
t3-TA-SETTLE
t3-TAC-TO-TX
First Transmitting Device disabled Second Transmitting Device enabled
4715
Figure 230 Detailed View of the Fast Lane Turnaround Procedure

Confidential
31-May-2019
4716 Figure 231 shows an example of ALP state machine transitions (highlighted in red) that occur when a burst
4717 begins in the conventional manner with an ALP-Pause Wake pulse and finishes by performing a Fast Lane
4718 Turnaround Procedure. This is the sequence of events that occur during the first “Master is Driving” interval
4719 shown in Figure 228. The highlighted sequence begins from the ALP-Pause Stop state, and ends when the
4720 turnaround event occurs during the HS-BTA Rx Wait state. This state diagram presents a high-level view of
4721 events. It can be interpreted to illustrate states that occur in the transmitter as well as the receiver.
Power-up +x state
ALP-Pause Wake
HS Burst
ALP Post2 ALP-Pause
Preamble
from ULPS
ALP Codes
(not Stop
LP or ULPS)
Stop State +x state
ALP-Pause Wake
ALP-Pause HS Burst HS Sync ALP

HS Data Post1
Stop Preamble Word Stop Code
HS Cal. HS Cal.
HS Cal.
Alt. Seq. Alternate
TAC
Preamble
Identifier Sequence
Code
HS-BTA
Rx Wait HS Cal.
HS Cal.
Post2
User- Post2
UD Seq.
Defined
to to Stop
Identifier
Seq.
HS-BTA
4722
Figure 231 State Transitions from ALP-Pause Stop to Turnaround

Confidential
31-May-2019
4723 Figure 232 shows an example of ALP state machine transitions (highlighted in red) that occur between two
4724 Fast Lane Turnaround events. This is the sequence of events that occur during the “Slave is Driving” interval
4725 shown in Figure 228.
Power-up +x state
ALP-Pause Wake
HS Burst
ALP Post2 ALP-Pause
Preamble
from ULPS
ALP Codes
(not Stop
LP or ULPS)
Stop State +x state
ALP-Pause Wake

HS Data Post1
HS Cal. HS Cal.
HS Cal.
Alt. Seq. Alternate
TAC
Preamble
Identifier Sequence
Code
HS-BTA
Rx Wait HS Cal.
HS Cal.
Post2
User- Post2
UD Seq.
Defined
to to Stop
Identifier
Seq.
HS-BTA
4726
Figure 232 State Transitions from Turnaround to Turnaround

Confidential
31-May-2019
4727 Figure 233 shows an example of ALP state machine transitions (highlighted in red) that occur, starting from
4728 a Fast Lane Turnaround Procedure (the HS-BTA Rx Wait state) and finishing when the burst ends and there
4729 is a transition to the ALP-Pause Stop state. This is the sequence of events that occur during the second “Master
4730 is Driving” interval shown in Figure 228.
Power-up +x state
ALP-Pause Wake
HS Burst
ALP Post2 ALP-Pause
Preamble
from ULPS
ALP Codes
(not Stop
LP or ULPS)
Stop State +x state
ALP-Pause Wake

HS Data Post1
HS Cal. HS Cal.
HS Cal.
Alt. Seq. Alternate
TAC
Preamble
Identifier Sequence
Code
HS-BTA
Rx Wait HS Cal.
HS Cal.
Post2
User- Post2
UD Seq.
Defined
to to Stop
Identifier
Seq.
HS-BTA
4731
Figure 233 State Transitions from Turnaround to ALP-Pause Stop
4732 The PPI signals that support ALP functions are used to perform a Fast Lane Turnaround. The first transmitting
4733 device stops transmission in much the same way as a transmitter signals the end of an ALP burst, except that
4734 a TAC code is sent instead of a Stop code. The first transmitting device becomes a receiver after it ceases
4735 transmission, so it can immediately switch to receive mode. In this case, the device that becomes a receiver
4736 does not need to be triggered by a long ALP Pause Wake pulse prior to the preamble. Instead, the trigger for
4737 assuming the role of a receiver is the transmission of the TAC code prior to the TGAP interval.

Confidential
31-May-2019
4738 Figure 234 shows an example of the of the transmitter and receiver PPI signaling in the first transmitting
4739 device when a Fast Lane Turnaround occurs.
Fast Lane Turnaround – Signals in the First Transmitting Device
Transmission from First Transmitting Device TGAP Transmission from Second Transmitting Device
High-Speed TAC TAC Packet Packet High-Speed

Lane Signals Forward Data Post1 Code Code
Post2 Preamble Sync
Header Sync
Header Forward Data
TxDataHS[X:0] Wn dc
TxWordValidHS
TxSendSyncHS
TxSendALPHS
TAC TAC
TxALPCodeHS[3:0] dc Post1
Code Code
Post2 dc
TxRequestHS
TxReadyHS
Direction
(First Transmitting Device)
RxDataHS[X:0] dc W1 W2 W3 dc W1 W2 W3
RxValidHS
RxSyncHS
RxALPValidHS
RxALPCode[3:0] dc
RxActiveHS
4740
Figure 234 Example Fast Lane Turnaround at the First Transmitting Device

Confidential
31-May-2019
4741 Figure 235 shows an example of the of the receiver and transmitter PPI signaling in the second transmitting
4742 device when a Fast Lane Turnaround occurs.
Fast Lane Turnaround – Signals in the Second Transmitting Device
Transmission from First Transmitting Device TGAP Transmission from Second Transmitting Device
High-Speed TAC TAC Packet Packet High-Speed

Lane Signals Forward Data Post1 Code Code
Post2 Preamble Sync
Header Sync
Header Forward Data
RxDataHS[X:0] Wn dc
RxValidHS
RxSyncHS
RxALPValidHS dc
TAC TAC
RxALPCode[3:0] dc Post1
Code Code
Post2 dc
RxActiveHS dc
Direction
(Second Transmitting Device)
TxDataHS[X:0] W1 W2 W3 dc W1 W2 W3
TxWordValidHS
TxSendSyncHS
TxSendALPHS
TxALPCodeHS[3:0] dc
TxRequestHS
TxReadyHS
4743
Figure 235 Example Fast Lane Turnaround at the Second Transmitting Device

Confidential
31-May-2019
Participants
The list below includes those persons who participated in the Working Group that developed this
Specification and who consented to appear on this list.
Sakari Ailus, Intel Corporation Mikko Muukki, HiSilicon Technologies Co. Ltd.
Rob Anhofer, MIPI Alliance (staff) Manuel Ortiz, Intel Corporation
Radha Krishna Atukula, NVIDIA Josh Pan, MediaTek Inc.
Uwe Beutnagel-Buchner, Robert Bosch GmbH Prachi Patel, Cadence Design Systems, Inc.
Gyeonghan Cha, Samsung Electronics, Co. Allan Paul, Cadence Design Systems, Inc.
Eric Ching, Microchip Technology Radu Pitigoi-Aron, Qualcomm Incorporated
Niharika Singh Chouhan, L&T Technology Services Kondalarao Polisetti, Xilinx Inc.
Teong Rong Chua, Sony Corporation Quan Lin Qiu, NVIDIA
Zhang Chunrong, Advanced Micro Devices, Inc. Rahul R, L&T Technology Services
Tomer Cohen, Samsung Electronics, Co. Matthew Ronning, Sony Corporation
Al Czamara, Test Evolution Yon Jun Shin, Samsung Electronics, Co.
Chris Grigg, MIPI Alliance (staff) Richard Sproul, Cadence Design Systems, Inc.
Jason Hawken, Advanced Micro Devices, Inc. Vinoth Srinivasan, L&T Technology Services
Hsiehchang Ho, MediaTek Inc. Hiroo Takahashi, Sony Corporation
Toshihisa Hyakudai, Sony Corporation Haran Thanigasalam, Intel Corporation
Kai Ruben Josefsen, OmniVision Technologies, Inc. Rick Wietfeldt, Qualcomm Incorporated
Tom Kopet, ON Semiconductor George Wiley, Qualcomm Incorporated
Mark Lewis, Cadence Design Systems, Inc. David Woolf, University of New Hampshire
Kenneth Ma, HiSilicon Technologies Co. Ltd. InterOperability Lab (UNH-IOL)
Kumaravel Manickam, L&T Technology Services Charles Wu, OmniVision Technologies, Inc.
Cedric Marta, Synopsys, Inc. Long Wu, Synopsys, Inc.
Past Contributors to v2.1:

Sakari Ailus, Intel Corporation Mikko Muukki, HiSilicon Technologies Co. Ltd.
Rob Anhofer, MIPI Alliance (staff) Manuel Ortiz, Intel Corporation
Radha Krishna Atukula, NVIDIA Prachi Patel, Cadence Design Systems, Inc.
Chua Teong Rong, Sony Corporation Matthew Ronning, Sony Corporation
Gyeonghan Cha, Samsung Electronics, Co. Yacov Simhony, Cadence Design Systems, Inc.
Zhang Chunrong, Advanced Micro Devices, Inc. Richard Sproul, Cadence Design Systems, Inc.
Chris Grigg, MIPI Alliance (staff) Hiroo Takahashi, Sony Corporation
Jason Hawken, Advanced Micro Devices, Inc. Haran Thanigasalam, Intel Corporation
Tom Kopet, ON Semiconductor George Wiley, Qualcomm Incorporated
Cedric Marta, Synopsys, Inc.

Confidential
31-May-2019
Past Contributors to v2.0:

Hirofumi Adachi, Teradyne Inc. Tom Kopet, ON Semiconductor
Sakari Ailus, Intel Corporation Thomas Krause, Texas Instruments Incorporated
Rob Anhofer, MIPI Alliance Yoav Lavi, VLSI Plus Ltd.
Radha Krishna Atukula, NVIDIA Cedric Marta, Synopsys, Inc.
Kaberi Banerjee, Lattice Semiconductor Corp. Mikko Muukki, HiSilicon Technologies Co. Ltd.
Thierry Berdah, Cadence Design Systems, Inc. Raj Kumar Nagpal, Synopsys, Inc.
Thomas Blon, Silicon Line GmbH Amir Naveed, Qualcomm Incorporated
Teong Rong Chua, Sony Corporation Laurent Pinchart, Google, Inc.
Zhang Chunrong, Advanced Micro Devices, Inc. Alex Qiu, NVIDIA
Tatsuyuki Fukushima, Teradyne Inc. Matthew Ronning, Sony Corporation
Karan Galhotra, Synopsys, Inc. Yaron Schwartz, Cadence Design Systems, Inc.
Vaibhav Gupta, Mentor Graphics Sho Sengoku, Qualcomm Incorporated
Mattias Gustafsson, OmniVision Technologies, Inc. Yacov Simhony, Cadence Design Systems, Inc.
Mohamed Hafed, Introspect Test Technology Inc. Gaurav Singh, Synopsys, Inc.
Will Harris, Advanced Micro Devices, Inc. Richard Sproul, Cadence Design Systems, Inc.
Jason Hawken, Advanced Micro Devices, Inc. Tatsuya Sugioka, Sony Corporation
Hsieh Chang Ho, MediaTek Inc. Hiroo Takahashi, Sony Corporation
Norihiro Ichimaru, Sony Corporation Haran Thanigasalam, Intel Corporation
Henrik Icking, Intel Corporation Bruno Trematore, Toshiba Corporation
Yukichi Inoue, Teradyne Inc. Rick Wietfeldt, Qualcomm Incorporated
Kayoko Ishiwata, Toshiba Corporation George Wiley, Qualcomm Incorporated
Grant Jennings, Lattice Semiconductor Corp. Charles Wu, OmniVision Technologies, Inc.
Jacob Joseph, NVIDIA Hirofumi Yoshida, Sony Corporation
Mrudula Kanuri, NVIDIA MinJun Zhao, HiSilicon Technologies Co. Ltd
Nadine Kolment, Introspect Test Technology Inc.

Confidential

Mipi Csi 3.0

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mipi Csi 3.0

Uploaded by

Copyright:

Available Formats

Specification for

Camera Serial Interface 2

MIPI Board Adopted 10 September 2019

Copyright © 2005-2019 MIPI Alliance, Inc.

ii Copyright © 2005-2019 MIPI Alliance, Inc.

Copyright © 2005-2019 MIPI Alliance, Inc. iii

8 Multi-Lane Distribution and Merging ....................................................................61

iv Copyright © 2005-2019 MIPI Alliance, Inc.

9.17 Data Interleaving ......................................................................................................... 161

Copyright © 2005-2019 MIPI Alliance, Inc. v

12.13 RAW7 Data Reception................................................................................................. 217

vi Copyright © 2005-2019 MIPI Alliance, Inc.

E.3 Decoders ...................................................................................................................... 268

Copyright © 2005-2019 MIPI Alliance, Inc. vii

viii Copyright © 2005-2019 MIPI Alliance, Inc.

Figure 33 Example 32-bit Register Write ....................................................................................... 52

Copyright © 2005-2019 MIPI Alliance, Inc. ix

Figure 70 Packet Spacing ............................................................................................................... 95

x Copyright © 2005-2019 MIPI Alliance, Inc.

Copyright © 2005-2019 MIPI Alliance, Inc. xi

Figure 144 RAW7 Frame Format ................................................................................................. 195

xii Copyright © 2005-2019 MIPI Alliance, Inc.

Figure 181 RAW7 Data Format Reception .................................................................................. 217

Copyright © 2005-2019 MIPI Alliance, Inc. xiii

xiv Copyright © 2005-2019 MIPI Alliance, Inc.

Copyright © 2005-2019 MIPI Alliance, Inc. xv

Table 36 ROI Element Information Field Format ........................................................................ 154

xvi Copyright © 2005-2019 MIPI Alliance, Inc.

2005-11-29 v1.00 Initial Board approved release.

2010-11-09 v1.01.00 Board approved release.

2013-01-22 v1.1 Board approved release.

2014-09-10 v1.2 Board approved release.

2014-10-07 v1.3 Board approved release.

2017-03-28 v2.0 Board approved release.

2018-04-09 v2.1 Board approved release.

2019-09-10 v3.0 Board approved release.

Copyright © 2005-2019 MIPI Alliance, Inc. xvii

This page intentionally left blank.

xviii Copyright © 2005-2019 MIPI Alliance, Inc.

Copyright © 2005-2019 MIPI Alliance, Inc. 1

2.1 Use of Special Terms

42 CCI (I3C): CCI supporting I3C [MIPI03].

2 Copyright © 2005-2019 MIPI Alliance, Inc.

Copyright © 2005-2019 MIPI Alliance, Inc. 3

96 HS-RX High-Speed Receiver

4 Copyright © 2005-2019 MIPI Alliance, Inc.

131 VGA Video Graphics Array

Copyright © 2005-2019 MIPI Alliance, Inc. 5

6 Copyright © 2005-2019 MIPI Alliance, Inc.

Device e.g. a Camera containing the Device e.g. an application engine or

Copyright © 2005-2019 MIPI Alliance, Inc. 7

Device e.g. a Camera containing the Device e.g. an application engine or

8 Copyright © 2005-2019 MIPI Alliance, Inc.

5 CSI-2 Layer Definitions

Low Level Protocol Arbitrary Data Support Low Level Protocol

Lane Management Lane Distribution/Lane Merging Lane Management

High Speed Unidirectional Clock (only applies to D-PHY)

High Speed Unidirectional Lane 1

High Speed Unidirectional Lane N

Copyright © 2005-2019 MIPI Alliance, Inc. 9

10 Copyright © 2005-2019 MIPI Alliance, Inc.

6 Camera Control Interface (CCI)