Mipi CSI 2 Specification v4 0 1

Specification for
Camera Serial Interface 2

(CSI-2®)
Version 4.0.1
23 May 2022
MIPI Board Adopted 14 November 2022
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 Camera Working
Group.
Copyright © 2005–2022 MIPI Alliance, Inc.

All rights reserved.
Confidential
Specification for CSI-2 Version 4.0.1
23-May-2022
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–2022 MIPI Alliance, Inc.

Confidential
Version 4.0.1 Specification for CSI-2
23-May-2022
Contents
Figures .......................................................................................................................... ix
Tables ...................................................................................................................... xviii
Release History ............................................................................................................... xxi
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................................................................................................................... 4
2.4 Acronyms......................................................................................................................... 5
3 References ....................................................................................................................7
4 Overview of CSI-2 .......................................................................................................9
5 CSI-2 Layer Definitions ............................................................................................ 11
6 Camera Control Interface (CCI) .............................................................................13
6.1 CCI (I2C) Data Transfer Protocol .................................................................................. 14
6.1.1 CCI (I2C) Message Type ............................................................................................. 14
6.1.2 CCI (I2C) Read/Write Operations ............................................................................... 15
6.2 CCI (I3C) Data Transfer Protocol.................................................................................. 21
6.2.1 CCI (I3C SDR) Data Transfer Protocol ...................................................................... 21
6.2.2 CCI (I3C DDR) Data Transfer Protocol ..................................................................... 29
6.3 CCI (I3C) Error Detection and Recovery ...................................................................... 39
6.3.1 CCI (I3C SDR) Error Detection and Recovery Method ............................................. 39
6.3.2 CCI (I3C DDR) Error Detection and Recovery Method ............................................ 41
6.3.3 Error Detection and Recovery for CCI (I3C) Controller Devices .............................. 47
6.4 CCI (I2C) Target Addresses............................................................................................ 47
6.5 CCI (I3C) Target Addresses ........................................................................................... 47
6.6 CCI Multi-Byte Registers .............................................................................................. 48
6.6.1 Overview..................................................................................................................... 48
6.6.2 Transmission Byte Order for Multi-Byte Register Values .......................................... 50
6.6.3 Multi-Byte Register Protocol (Informative) ............................................................... 51
6.7 CCI I/O Electrical and Timing Specifications ............................................................... 56
7 Physical Layer ...........................................................................................................59
7.1 D-PHY Physical Layer Option ...................................................................................... 59
7.2 C-PHY Physical Layer Option....................................................................................... 60
7.3 PHY Support for the CSI-2 Unified Serial Link (USL) Feature.................................... 61
7.3.1 D-PHY Support Requirements for USL Feature......................................................... 61
7.3.2 C-PHY Support Requirements for USL Feature ......................................................... 62
Copyright © 2005–2022 MIPI Alliance, Inc. iii

Confidential
23-May-2022
8 Multi-Lane Distribution and Merging ....................................................................63

8.1 Lane Distribution for the D-PHY Physical Layer Option.............................................. 67
8.2 Lane Distribution for the C-PHY Physical Layer Option .............................................. 70
8.3 Multi-Lane Interoperability ........................................................................................... 72
8.3.1 C-PHY Lane Deskew .................................................................................................. 74
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 ......................................... 114
9.11.3 LRTE Register Tables ............................................................................................... 115
9.12 Unified Serial Link (USL) ........................................................................................... 118
9.12.1 USL Technical Overview .......................................................................................... 119
9.12.2 USL Command Payload Constructs ......................................................................... 120
9.12.3 USL Operation Procedures ....................................................................................... 123
9.12.4 Monitoring USL Command Transport Integrity ....................................................... 125
9.12.5 USL Powerup / Reset, SNS Configuration, and Mode Switching ............................ 126
9.13 Data Scrambling .......................................................................................................... 138
9.13.1 CSI-2 Scrambling for D-PHY................................................................................... 139
9.13.2 CSI-2 Scrambling for C-PHY ................................................................................... 140
9.13.3 Scrambling Details .................................................................................................... 143
9.14 Smart Region of Interest (SROI) ................................................................................. 148
9.14.1 Overview of SROI Frame Format............................................................................. 149
9.14.2 Transmission of SROI Embedded Data Packet ........................................................ 151
9.14.3 SROI Packet Detection Options................................................................................ 153
9.14.4 SROI Use Cases (Informative) ................................................................................. 155
9.14.5 Format of SROI Embedded Data Packet (SEDP) ..................................................... 157
9.15 Packet Data Payload Size Rules .................................................................................. 160
9.16 Frame Format Examples .............................................................................................. 161
iv Copyright © 2005–2022 MIPI Alliance, Inc.

Confidential
23-May-2022
9.17 Data Interleaving ......................................................................................................... 164

9.17.1 Data Type Interleaving .............................................................................................. 164
9.17.2 Virtual Channel Identifier Interleaving ..................................................................... 167
10 Color Spaces.............................................................................................................169
10.1 RGB Color Space Definition ....................................................................................... 169
10.2 YUV Color Space Definition ....................................................................................... 169
11 Data Formats ...........................................................................................................171
11.1 Generic 8-bit Long Packet Data Types ........................................................................ 173
11.1.1 Null and Blanking Data ............................................................................................ 173
11.1.2 Embedded Information ............................................................................................. 174
11.1.3 Generic Long Packet Data Types 1 Through 4 ......................................................... 174
11.2 YUV Image Data ......................................................................................................... 175
11.2.1 Legacy YUV420 8-bit............................................................................................... 176
11.2.2 YUV420 8-bit ........................................................................................................... 178
11.2.3 YUV420 10-bit ......................................................................................................... 182
11.2.4 YUV422 8-bit ........................................................................................................... 184
11.2.5 YUV422 10-bit ......................................................................................................... 186
11.3 RGB Image Data.......................................................................................................... 188
11.3.1 RGB888 .................................................................................................................... 189
11.3.2 RGB666 .................................................................................................................... 191
11.3.3 RGB565 .................................................................................................................... 193
11.3.4 RGB555 .................................................................................................................... 195
11.3.5 RGB444 .................................................................................................................... 196
11.4 RAW Image Data ......................................................................................................... 197
11.4.1 RAW6 ....................................................................................................................... 198
11.4.2 RAW7 ....................................................................................................................... 199
11.4.3 RAW8 ....................................................................................................................... 200
11.4.4 RAW10 ..................................................................................................................... 201
11.4.5 RAW12 ..................................................................................................................... 203
11.4.6 RAW14 ..................................................................................................................... 204
11.4.7 RAW16 ..................................................................................................................... 206
11.4.8 RAW20 ..................................................................................................................... 207
11.4.9 RAW24 ..................................................................................................................... 209
11.4.10 RAW28 ..................................................................................................................... 211
11.5 User Defined Data Formats ......................................................................................... 212
12 Recommended Memory Storage ............................................................................215
12.1 General/Arbitrary Data Reception ............................................................................... 215
12.2 RGB888 Data Reception ............................................................................................. 216
12.7 YUV422 8-bit Data Reception .................................................................................... 218
12.8 YUV422 10-bit Data Reception .................................................................................. 219
12.9 YUV420 8-bit (Legacy) Data Reception ..................................................................... 220
12.10 YUV420 8-bit Data Reception .................................................................................... 221
12.11 YUV420 10-bit Data Reception .................................................................................. 222
Copyright © 2005–2022 MIPI Alliance, Inc. v

Confidential
23-May-2022
12.12 RAW6 Data Reception................................................................................................. 223

12.15 RAW10 Data Reception............................................................................................... 224
13 Always-On Sentinel Conduit (AOSC) ...................................................................229
13.1 Introduction.................................................................................................................. 229
13.1.1 VDSP and APP In-Band Communication ................................................................. 231
13.1.2 AOSC SNS Features and Capabilities ...................................................................... 232
13.1.3 VDSP and APP Switching and Graceful Failure ...................................................... 232
13.1.4 Support for Privacy ................................................................................................... 233
13.2 Optimal Transport Mode (OTM) Overview ................................................................ 234
13.2.1 Protocol Overview .................................................................................................... 237
13.2.2 SNS FIFO Requirement ............................................................................................ 239
13.2.3 VDSP Initiated Commands to the SNS..................................................................... 239
13.2.4 SNS Status Communication to VDSP Using IBI ...................................................... 240
13.2.5 Support for On-Demand Frame and Streaming Frames ........................................... 241
13.2.6 Support for Frame Squelching .................................................................................. 241
13.2.7 Support for Interconnect Synchronization and Dynamic ISPB Insertion ................. 242
13.2.8 OTM Errors Detected by the VDSP ......................................................................... 243
13.3 Smart Transport Mode (STM) Overview..................................................................... 244
Annex A JPEG8 Data Format (informative).............................................................249
A.1 Introduction.................................................................................................................. 249
A.2 JPEG Data Definition .................................................................................................. 250
A.3 Image Status Information ............................................................................................ 251
A.4 Embedded Images........................................................................................................ 253
A.5 JPEG8 Non-standard Markers ..................................................................................... 254
A.6 JPEG8 Data Reception ................................................................................................ 254
Annex B CSI-2 Implementation Example (informative) .........................................255
B.1 Overview...................................................................................................................... 255
B.2 CSI-2 Transmitter Detailed Block Diagram ................................................................ 256
B.3 CSI-2 Receiver Detailed Block Diagram..................................................................... 257
B.4 Details on the D-PHY Implementation ........................................................................ 258
B.4.1 CSI-2 Clock Lane Transmitter .................................................................................. 259
B.4.2 CSI-2 Clock Lane Receiver ...................................................................................... 260
B.4.3 CSI-2 Data Lane Transmitter .................................................................................... 261
B.4.4 CSI-2 Data Lane Receiver ........................................................................................ 263
vi Copyright © 2005–2022 MIPI Alliance, Inc.

Confidential
23-May-2022
Annex C CSI-2 Recommended Receiver Error Behavior (informative) ................265

C.1 Overview...................................................................................................................... 265
C.2 D-PHY Level Error ...................................................................................................... 266
C.3 Packet Level Error ....................................................................................................... 267
C.4 Protocol Decoding Level Error .................................................................................... 268
Annex D CSI-2 Sleep Mode (informative) .................................................................269
D.1 Overview...................................................................................................................... 269
D.2 SLM Command Phase ................................................................................................. 269
D.3 SLM Entry Phase ......................................................................................................... 270
D.4 SLM Exit Phase ........................................................................................................... 270
Annex E Data Compression for RAW Data Types (normative) ..............................271
E.1 Predictors ..................................................................................................................... 273
E.1.1 Predictor1 .................................................................................................................. 273
E.1.2 Predictor2 .................................................................................................................. 274
E.2 Encoders ...................................................................................................................... 275
E.2.1 Coder for 10–8–10 Data Compression ..................................................................... 275
E.2.4 Coder for 12-10-12 Data Compression ..................................................................... 283
E.3 Decoders ...................................................................................................................... 294
E.3.1 Decoder for 10–8–10 Data Compression .................................................................. 294
E.3.4 Decoder for 12–10–12 Data Compression ................................................................ 303
Annex F JPEG Interleaving (informative) ................................................................317
Annex G Scrambler Seeds for Lanes 9 and Above ....................................................321
Annex H Guidance on CSI-2 Over C-PHY ALP and PPI ........................................323
H.1 CSI-2 with C-PHY ALP Mode .................................................................................... 323
H.1.1 Concepts of ALP Mode and Legacy LP Mode ......................................................... 323
H.1.2 Burst Examples Using ALP Mode ............................................................................ 326
H.1.3 Transmission and Reception of ALP Commands Through the PPI .......................... 331
H.1.4 Multi-Lane Operation Using ALP Mode .................................................................. 336
H.1.5 LP and ALP Operation .............................................................................................. 338
H.1.6 Bi-Directional Lane Turnaround ............................................................................... 338
Copyright © 2005–2022 MIPI Alliance, Inc. vii

Confidential
23-May-2022
Annex I Multi-Pixel Compression (MPC) ................................................................347

I.1 MPC for Bayer Image Sensor ...................................................................................... 352
I.1.1 Reference Pixels for Prediction (Bayer) ................................................................... 353
I.1.2 Basic Prediction Mode (Bayer) ................................................................................. 356
I.1.3 Advanced Prediction Mode (Bayer) ......................................................................... 364
I.2 MPC for Tetra-Cell Image Sensor ............................................................................... 372
I.2.1 Reference Pixels for Prediction (Tetra-Cell) ............................................................. 373
I.2.2 Basic Prediction Mode (Tetra-Cell) .......................................................................... 376
I.2.3 Advanced Prediction Mode (Tetra-Cell) ................................................................... 388
I.2.4 Low Resolution Image Generation (Tetra-Cell) ....................................................... 400
I.2.5 Adjustment of Compression Ratio (Tetra-Cell) ........................................................ 401
I.3 MPC for Nona-Cell Image Sensor ............................................................................... 404
I.3.1 Reference Pixels for Prediction (Nona-Cell) ............................................................ 405
I.3.2 Basic Prediction Mode (Nona-Cell).......................................................................... 407
I.3.3 Advanced Prediction Mode (Nona-Cell) .................................................................. 413
I.3.4 Low Resolution Image Generation (Nona-Cell) ....................................................... 427
I.3.5 Adjustment of Compression Ratio (Nona-Cell)........................................................ 428
I.4 MPC for N x N Multi-Pixel Image Sensor [Informative] ............................................ 430
viii Copyright © 2005–2022 MIPI Alliance, Inc.

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

Confidential
23-May-2022
Figure 34 CCI I/O Timing..................................................................................................................... 58

Figure 35 Conceptual Overview of the Lane Distributor Function for D-PHY .................................... 63
Figure 36 Conceptual Overview of the Lane Distributor Function for C-PHY .................................... 64
Figure 37 Conceptual Overview of the Lane Merging Function for D-PHY ........................................ 65
Figure 38 Conceptual Overview of the Lane Merging Function for C-PHY ........................................ 66
Figure 39 Two Lane Multi-Lane Example for D-PHY ......................................................................... 67
Figure 40 Three Lane Multi-Lane Example for D-PHY ....................................................................... 68
Figure 41 N-Lane Multi-Lane Example for D-PHY ............................................................................. 69
Figure 42 N-Lane Multi-Lane Example for D-PHY Short Packet Transmission.................................. 70
Figure 43 Two Lane Multi-Lane Example for C-PHY ......................................................................... 71
Figure 44 Three Lane Multi-Lane Example for C-PHY ....................................................................... 71
Figure 45 General N-Lane Multi-Lane Distribution for C-PHY .......................................................... 71
Figure 46 One Lane Transmitter and N-Lane Receiver Example for D-PHY ...................................... 72
Figure 47 M-Lane Transmitter and N-Lane Receiver Example (M<N) for D-PHY ............................. 72
Figure 48 M-Lane Transmitter and One Lane Receiver Example for D-PHY...................................... 73
Figure 49 M-Lane Transmitter and N-Lane Receiver Example (N<M) for D-PHY ............................. 73
Figure 50 Example of Digital Logic to Align All RxDataHS ............................................................... 74
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
Figure 70 Packet Spacing...................................................................................................................... 95
x Copyright © 2005–2022 MIPI Alliance, Inc.

Confidential
23-May-2022
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 .............................................. 107
Figure 80 Example of LRTE EPD for CSI-2 Over D-PHY – Option 2 .............................................. 108
Figure 81 Enabling Robust Spacer Byte Detection: General Case ..................................................... 112
Figure 82 Enabling Robust Spacer Byte Detection: Special Case ...................................................... 112
Figure 83 EoTp Usage Examples........................................................................................................ 113
Figure 84 Using EPD with LVLP or ALP Mode Signaling................................................................. 114
Figure 85 USL System Diagram ......................................................................................................... 118
Figure 86 USL Modes Link Transitions .............................................................................................. 131
Figure 87 Examples of USL ALP Mode Clock Lane Management During Sensor Vblank ............... 135
Figure 88 System Diagram Showing Per-Lane Scrambling ............................................................... 138
Figure 89 Example of Data Bursts in Two Lanes Using the D-PHY Physical Layer ......................... 139
Figure 90 Example of Data Bursts in Two Lanes Using the C-PHY Physical Layer.......................... 140
Figure 91 Generating Tx Sync Type as Seed Index (Single Lane View) ............................................ 141
Figure 92 Generating Tx Sync Type Using the C-PHY Physical Layer ............................................. 142
Figure 93 PRBS LFSR Serial Implementation Example .................................................................... 145
Figure 94 ISROI System Supporting Multi-Stack SNS with Integrated SROI VDSP ........................ 148
Figure 95 ESROI System Supporting Standard SNS with an External SROI VDSP ......................... 148
Figure 96 SROI Frame Format Example ............................................................................................ 150
Figure 97 SROI Packet Option 1 ........................................................................................................ 153
Figure 98 SROI Packet Option 2 ........................................................................................................ 154
Figure 99 Use Case 1: SROI Embedded Data Packet Not Transmitted .............................................. 155
Figure 100 Use Case 2: SROI Embedded Data Packet Is Transmitted ............................................... 156
Figure 101 SROI Embedded Data Packet Format .............................................................................. 157
Figure 102 General Frame Format Example ....................................................................................... 161
Figure 103 Digital Interlaced Video Example..................................................................................... 162
Figure 104 Digital Interlaced Video with Accurate Synchronization Timing Information ................. 163
Figure 105 Interleaved Data Transmission using Data Type Value..................................................... 164
Figure 106 Packet Level Interleaved Data Transmission .................................................................... 165
Figure 107 Frame Level Interleaved Data Transmission .................................................................... 166
Copyright © 2005–2022 MIPI Alliance, Inc. xi

Confidential
23-May-2022
Figure 108 Interleaved Data Transmission using Virtual Channels .................................................... 167
Figure 109 Byte Packing Pixel Data to C-PHY Symbol Illustration .................................................. 172
Figure 110 Frame Structure with Embedded Data at the Beginning and End of the Frame ............... 174
Figure 111 Legacy YUV420 8-bit Transmission................................................................................. 176
Figure 112 Legacy YUV420 8-bit Pixel to Byte Packing Bitwise Illustration ................................... 176
Figure 113 Legacy YUV420 Spatial Sampling for H.261, H.263 and MPEG 1 ................................. 177
Figure 114 Legacy YUV420 8-bit Frame Format ............................................................................... 177
Figure 115 YUV420 8-bit Data Transmission Sequence .................................................................... 178
Figure 116 YUV420 8-bit Pixel to Byte Packing Bitwise Illustration ................................................ 179
Figure 117 YUV420 Spatial Sampling for H.261, H.263 and MPEG 1 ............................................. 180
Figure 118 YUV420 Spatial Sampling for MPEG 2 and MPEG 4 ..................................................... 180
Figure 119 YUV420 8-bit Frame Format............................................................................................ 181
Figure 120 YUV420 10-bit Transmission ........................................................................................... 182
Figure 121 YUV420 10-bit Pixel to Byte Packing Bitwise Illustration .............................................. 183
Figure 122 YUV420 10-bit Frame Format ......................................................................................... 183
Figure 123 YUV422 8-bit Transmission ............................................................................................. 184
Figure 124 YUV422 8-bit Pixel to Byte Packing Bitwise Illustration ................................................ 184
Figure 125 YUV422 Co-sited Spatial Sampling ................................................................................. 185
Figure 126 YUV422 8-bit Frame Format............................................................................................ 185
Figure 127 YUV422 10-bit Transmitted Bytes ................................................................................... 186
Figure 128 YUV422 10-bit Pixel to Byte Packing Bitwise Illustration .............................................. 186
Figure 129 YUV422 10-bit Frame Format ......................................................................................... 187
Figure 130 RGB888 Transmission ...................................................................................................... 189
Figure 131 RGB888 Transmission in CSI-2 Bus Bitwise Illustration ................................................ 189
Figure 132 RGB888 Frame Format .................................................................................................... 190
Figure 133 RGB666 Transmission with 18-bit BGR Words ............................................................... 191
Figure 134 RGB666 Transmission on CSI-2 Bus Bitwise Illustration ............................................... 191
Figure 136 RGB565 Transmission with 16-bit BGR Words ............................................................... 193
Figure 141 RAW6 Transmission ......................................................................................................... 198
Figure 142 RAW6 Data Transmission on CSI-2 Bus Bitwise Illustration .......................................... 198
Figure 143 RAW6 Frame Format........................................................................................................ 198
xii Copyright © 2005–2022 MIPI Alliance, Inc.

Confidential
23-May-2022
Figure 150 RAW10 Transmission ....................................................................................................... 201
Figure 151 RAW10 Data Transmission on CSI-2 Bus Bitwise Illustration ........................................ 201
Figure 152 RAW10 Frame Format...................................................................................................... 202
Figure 154 RAW12 Transmission on CSI-2 Bus Bitwise Illustration ................................................. 203
Figure 171 User Defined 8-bit Data (128 Byte Packet) ...................................................................... 212
Figure 172 User Defined 8-bit Data Transmission on CSI-2 Bus Bitwise Illustration ....................... 212
Figure 173 Transmission of User Defined 8-bit Data ......................................................................... 212
Figure 174 General/Arbitrary Data Reception .................................................................................... 215
Figure 175 RGB888 Data Format Reception ...................................................................................... 216
Figure 180 YUV422 8-bit Data Format Reception ............................................................................. 218
Figure 181 YUV422 10-bit Data Format Reception ........................................................................... 219
Copyright © 2005–2022 MIPI Alliance, Inc. xiii

Confidential
23-May-2022
Figure 182 YUV420 8-bit Legacy Data Format Reception ................................................................ 220
Figure 183 YUV420 8-bit Data Format Reception ............................................................................. 221
Figure 184 YUV420 10-bit Data Format Reception ........................................................................... 222
Figure 185 RAW6 Data Format Reception ......................................................................................... 223
Figure 188 RAW10 Data Format Reception ....................................................................................... 224
Figure 190 RAW 14 Data Format Reception ...................................................................................... 225
Figure 195 Point-To-Point AOSC Systems with USL Solutions ........................................................ 229
Figure 196 Point-To-Point AOSC Systems with Non-USL Solutions ................................................ 230
Figure 197 System Supporting AOSC and CCI Operations Over Multi-Drop I3C ............................ 230
Figure 198 System Supporting Discrete Multicontrollers Mapped to Single SNS I3C Target Port.... 231
Figure 199 AOSC Optimal Transport Mode (OTM) Operation .......................................................... 235
Figure 200 Example OTM RAW10 Format Transport (with I3C SDR Bit Transmission Order) ....... 237
Figure 201 SNS OTM FIFO ............................................................................................................... 239
Figure 202 AOSC IBI MDB Codes .................................................................................................... 241
Figure 203 OTM ISPB Insertion and Frame Start IBI T_RESP Parameter ........................................ 242
Figure 204 AOSC Smart Transport Mode (STM) Operation for the D-PHY Generic STM Types .... 244
Figure 205 Example AOSC STM RAW10 Data Bitwise Transport Illustration with the D-PHY
Generic STM Types ........................................................................................................... 247
Figure 206 JPEG8 Data Flow in the Encoder ..................................................................................... 249
Figure 207 JPEG8 Data Flow in the Decoder ..................................................................................... 249
Figure 208 EXIF Compatible Baseline JPEG DCT Format................................................................ 250
Figure 209 Status Information Field in the End of Baseline JPEG Frame.......................................... 252
Figure 210 Example of TN Image Embedding Inside the Compressed JPEG Data Block ................. 253
Figure 211 JPEG8 Data Format Reception ......................................................................................... 254
Figure 212 Implementation Example Block Diagram and Coverage ................................................. 255
Figure 213 CSI-2 Transmitter Block Diagram .................................................................................... 256
Figure 214 CSI-2 Receiver Block Diagram ........................................................................................ 257
Figure 215 D-PHY Level Block Diagram........................................................................................... 258
Figure 216 CSI-2 Clock Lane Transmitter .......................................................................................... 259
Figure 217 CSI-2 Clock Lane Receiver .............................................................................................. 260
xiv Copyright © 2005–2022 MIPI Alliance, Inc.

Confidential
23-May-2022
Figure 218 CSI-2 Data Lane Transmitter ............................................................................................ 261

Figure 219 CSI-2 Data Lane Receiver ................................................................................................ 263
Figure 220 SLM Synchronization ....................................................................................................... 270
Figure 221 Data Compression System Block Diagram ...................................................................... 272
Figure 222 Pixel Order of the Original Image .................................................................................... 273
Figure 223 Example Pixel Order of the Original Image ..................................................................... 273
Figure 224 Data Type Interleaving: Concurrent JPEG and YUV Image Data .................................... 317
Figure 225 Virtual Channel Interleaving: Concurrent JPEG and YUV Image Data ........................... 318
Figure 226 Example JPEG and YUV Interleaving Use Cases ............................................................ 319
Figure 227 Comparing Data Burst Timing of Legacy LP Mode versus ALP Mode ........................... 323
Figure 228 ALP Mode General Burst Format ..................................................................................... 324
Figure 229 High-Speed and ALP-Pause Wake Receiver Example ..................................................... 325
Figure 230 Examples of Bursts to Send High-Speed Data and ALP Commands ............................... 327
Figure 231 State Transitions for an HS Data Burst ............................................................................. 328
Figure 232 State Transitions to Enter the ULPS State ........................................................................ 329
Figure 233 State Transitions to Exit from the ULPS State.................................................................. 330
Figure 234 PPI Example: HS Signals for Transmission of Data, Sync and ALP Commands ............. 331
Figure 235 PPI Example Transmit Side Timing for an HS Data Burst ............................................... 332
Figure 236 PPI Example Receive Side Timing for an HS Data Burst ................................................ 333
Figure 237 PPI Example Transmit Side Timing to Enter the ULPS State .......................................... 334
Figure 238 PPI Example Receive Side Timing to Enter the ULPS State............................................ 334
Figure 239 PPI Example Transmit Side Timing to Exit from the ULPS State.................................... 335
Figure 240 PPI Example Receive Side Timing to Exit from the ULPS State ..................................... 335
Figure 241 Example Showing a Data Transmission Burst using Three Lanes ................................... 337
Figure 242 Example Showing an ALP Command Burst using Three Lanes ...................................... 337
Figure 243 High-Level View of the Control Mode Lane Turnaround Procedure ............................... 338
Figure 244 High-Level View of ALP Mode with the Control Mode Lane Turnaround Procedure ..... 338
Figure 245 High-Level View of the Fast Lane Turnaround Procedure with ALP Mode..................... 339
Figure 246 High-Level View, Comparing Lane Turnaround Procedures............................................ 340
Figure 247 Detailed View of the Fast Lane Turnaround Procedure .................................................... 341
Figure 248 State Transitions from ALP-Pause Stop to Turnaround .................................................... 342
Figure 249 State Transitions from Turnaround to Turnaround............................................................ 343
Figure 250 State Transitions from Turnaround to ALP-Pause Stop .................................................... 344
Figure 251 Example Fast Lane Turnaround at the First Transmitting Device .................................... 345
Figure 252 Example Fast Lane Turnaround at the Second Transmitting Device ................................ 346
Figure 253 MPC Data Compression Schemes .................................................................................... 347
Figure 254 RAW10 Transmission for MPC for Bayer Image Sensors ............................................... 348
Copyright © 2005–2022 MIPI Alliance, Inc. xv

Confidential
23-May-2022
Figure 255 RAW10/12/14 Transmission for MPC for Tetra-Cell Image Sensors ............................... 349
Figure 256 RAW10/12/14 Transmission for MPC for Nona-Cell Image Sensors .............................. 350
Figure 257 MPC Data Compression System....................................................................................... 351
Figure 258 MPC Packet Structures for Bayer Compression Modes ................................................... 352
Figure 259 Reference Pixel Relative Coordinate Indexes (Bayer) ..................................................... 354
Figure 260 MPC Packet Structure for Compression Mode PD........................................................... 356
Figure 261 MPC Packet Structure for Compression Mode DGD (Bayer) .......................................... 359
Figure 262 MPC Packet Structure for Compression Mode FNR (Bayer) ........................................... 361
Figure 263 Decoded and Reference Pixel of Outlier Pixel (Bayer) .................................................... 362
Figure 264 MPC Packet Structure for Compression Mode OUT (Bayer) .......................................... 362
Figure 265 MPC Packet Structure for Compression Mode eDGD ..................................................... 364
Figure 266 MPC Packet Structure for Compression Mode ePD ......................................................... 366
Figure 267 MPC Packet Structure for Compression Mode eSHV (Bayer) ......................................... 369
Figure 268 MPC Packet Structures for Tetra-Cell Compression Modes............................................. 372
Figure 269 Tetra-Cell Multi-Pixel Indexing........................................................................................ 373
Figure 270 Reference Pixel Relative Coordinate Indexes (Tetra-Cell) ............................................... 374
Figure 271 MPC Packet Structure for Compression Mode AD .......................................................... 376
Figure 272 MPC Packet Structure for Compression Mode OD .......................................................... 378
Figure 273 MPC Packet Structure for Compression Mode FNR (Tetra-Cell) .................................... 385
Figure 274 Decoded and Reference Pixel of Outlier Pixel (Tetra) ..................................................... 386
Figure 275 MPC Packet Structure for Compression Mode OUT (Tetra-Cell) .................................... 386
Figure 276 MPC Packet Structure for Compression Mode eMPD (Tetra-Cell).................................. 388
Figure 277 MPC Packet Structure for Compression Mode eHVD (Tetra-Cell).................................. 391
Figure 278 Pixel Couplet Definitions for eHVA Mode ....................................................................... 393
Figure 279 MPC Packet Structure for Compression Mode eHVA ...................................................... 394
Figure 280 MPC Packet Structure for Compression Mode eOUT...................................................... 396
Figure 281 Low Resolution Image Generation by Pbyr (Tetra-Cell) ................................................... 400
Figure 282 MPC Packet Structures for Compression Ratio 10:6 (Tetra-Cell) .................................... 402
Figure 283 MPC Packet Structures for Compression Ratio 10:7 (Tetra-Cell) .................................... 402
Figure 284 Quantization Bits for Compression Ratios (Tetra-Cell) .................................................... 403
Figure 285 MPC Packet Structures for Nona-Cell Compression Modes ............................................ 404
Figure 286 Nona-Cell Multi-Pixel Indexing ....................................................................................... 405
Figure 287 Reference Pixel Relative Coordinate Indexes (Nona-Cell) .............................................. 406
Figure 288 MPC Packet Structure for Compression Mode AD (Nona-Cell) ...................................... 407
Figure 289 MPC Packet Structure for Compression Mode DGD (Nona-Cell) ................................... 409
Figure 290 MPC Packet Structure for Compression Mode FNR (Nona-Cell) .................................... 412
Figure 291 MPC Packet Structure for Compression Mode eAD (Nona-Cell) .................................... 413
xvi Copyright © 2005–2022 MIPI Alliance, Inc.

Confidential
23-May-2022
Figure 292 MPC Packet Structure for Compression Mode eHVD (Nona-Cell) ................................. 415
Figure 293 Pixel Triplet Definitions for eHVI Mode .......................................................................... 418
Figure 294 MPC Packet Structure for Compression Mode eHVI ....................................................... 419
Figure 295 MPC Packet Structure for Compression Mode eSHV (Nona-Cell) .................................. 420
Figure 296 MPC Packet Structure for Compression Mode eMPD (Nona-Cell) ................................. 423
Figure 297 Low Resolution Image Generation by Pbyr (Nona-Cell) ................................................... 427
Figure 298 MPC Packet Structures for Compression Ratio 10:6 (Nona-Cell) ................................... 428
Figure 299 MPC Packet Structures for Compression Ratio 10:7 (Nona-Cell) ................................... 428
Figure 300 Quantization Bits for Compression Ratios (Nona-Cell) ................................................... 429
Figure 301 Pixel Order Change from 4x4 Multi-Pixel to Tetra-Cell .................................................. 430
Copyright © 2005–2022 MIPI Alliance, Inc. xvii

Confidential
23-May-2022
Tables
Table 1 CCI (I2C) Read/Write Operations ............................................................................................ 15
Table 2 CCI (I3C SDR) Read/Write Operations ................................................................................... 22
Table 3 CCI (I3C DDR) Read/Write Operations .................................................................................. 30
Table 4 CCI (I3C DDR) Read/Write Operation Command Codes ....................................................... 31
Table 5 CCI (I3C SDR) Target Error Types .......................................................................................... 39
Table 6 CCI (I3C DDR) Target Error Types ......................................................................................... 41
Table 7 CCI (I3C DDR) Controller Error Type..................................................................................... 45
Table 8 CCI I/O Electrical Specifications ............................................................................................. 56
Table 9 CCI I/O Timing Specifications ................................................................................................. 57
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 ........................................................111
Table 16 LRTE Transmitter Registers for CSI-2 Over C-PHY ........................................................... 115
Table 17 LRTE Transmitter Registers for CSI-2 Over D-PHY........................................................... 116
Table 18 Image Sensor LPDT LRTE Control Register ....................................................................... 121
Table 19 USL Transport Control (USL_CTL) Bit Description ........................................................... 122
Table 20 USL Transport Integrity ACK and NAK Registers with TSEQ ........................................... 125
Table 21 USL BTA Switch Registers .................................................................................................. 128
Table 22 Register TX_USL_REV_FWD_ENTRY ............................................................................. 129
Table 23 Register TX_USL_SNS_BTA_ACK_TIMEOUT[15:0] ...................................................... 130
Table 24 Register TX_USL_APP_BTA_ACK_TIMEOUT[15:0] ...................................................... 130
Table 25 USL Operation Registers ...................................................................................................... 132
Table 26 USL GPIO Registers ............................................................................................................ 132
Table 27 USL Clock Lane Control Register ....................................................................................... 135
Table 28 Symbol Sequence Values Per Sync Type ............................................................................. 141
Table 29 Fields That Are Not Scrambled ............................................................................................ 143
Table 30 D-PHY Scrambler PRBS Initial Seed Values for Lanes 1 Through 8 .................................. 143
Table 31 C-PHY Scrambler PRBS Initial Seed Values for Lanes 1 Through 8 .................................. 144
Table 32 Example of the PRBS Bit-at-a-Time Shift Sequence ........................................................... 146
Table 33 Example PRBS LFSR Byte Sequence for D-PHY Physical Layer ...................................... 146
Table 34 Example PRBS LFSR Byte Sequence for C-PHY Physical Layer ...................................... 147
xviii Copyright © 2005–2022 MIPI Alliance, Inc.

Confidential
23-May-2022
Table 35 Transmission of SROI Embedded Data Packet .................................................................... 152

Table 36 ROI Element Information Field Format ............................................................................... 157
Table 37 ROI Element Type ID Definitions ........................................................................................ 158
Table 38 Primary and Secondary Data Formats Definitions ............................................................... 171
Table 39 Generic 8-bit Long Packet Data Types ................................................................................. 173
Table 40 YUV Image Data Types........................................................................................................ 175
Table 41 Legacy YUV420 8-bit Packet Data Size Constraints ........................................................... 176
Table 42 YUV420 8-bit Packet Data Size Constraints ........................................................................ 178
Table 43 YUV420 10-bit Packet Data Size Constraints ...................................................................... 182
Table 44 YUV422 8-bit Packet Data Size Constraints ........................................................................ 184
Table 45 YUV422 10-bit Packet Data Size Constraints ...................................................................... 186
Table 46 RGB Image Data Types ........................................................................................................ 188
Table 47 RGB888 Packet Data Size Constraints ................................................................................ 189
Table 50 RAW Image Data Types ....................................................................................................... 197
Table 51 RAW6 Packet Data Size Constraints .................................................................................... 198
Table 54 RAW10 Packet Data Size Constraints .................................................................................. 201
Table 61 User Defined 8-bit Data Types ............................................................................................. 213
Table 62 SNS Registers Required to Support OTM............................................................................ 236
Table 63 OTM Bitwise Transport Mapping for All Frame Formats ................................................... 238
Table 64 AOSC Operation CCC and Defining Byte Values................................................................ 239
Table 65 AOSC OTM Low-Latency Mandatory IBI MDB Codes ..................................................... 240
Table 66 Header Definitions for AOSC Smart Transport Mode (STM) ............................................. 246
Table 67 Status Data Padding ............................................................................................................. 251
Table 68 JPEG8 Additional Marker Codes Listing ............................................................................. 254
Table 69 Initial Seed Values for Lanes 9 through 32 .......................................................................... 321
Table 70 ALP Code Definitions used by CSI-2................................................................................... 330
Table 71 MPC Bits Per Block and CSI-2 Image Data Format ............................................................ 348
Copyright © 2005–2022 MIPI Alliance, Inc. xix

Confidential
23-May-2022
Table 72 MPC Compression Modes for Bayer Image Sensors ........................................................... 352
Table 73 Decoder for Compression Mode PD .................................................................................... 357
Table 74 Decoder for Compression Mode DGD (Bayer).................................................................... 360
Table 75 Decoder for Compression Mode FNR (Bayer) .................................................................... 361
Table 76 Decoder for Compression Mode OUT (Bayer) .................................................................... 363
Table 77 Decoder for Compression Mode eDGD ............................................................................... 365
Table 78 Decoder for Compression Mode ePD .................................................................................. 367
Table 79 Decoder for Compression Mode eSHV (Bayer)................................................................... 370
Table 80 MPC Compression Modes for Tetra-Cell Image Sensors..................................................... 372
Table 81 Decoder for Compression Mode AD .................................................................................... 377
Table 82 Decoder for Compression Mode OD.................................................................................... 379
Table 83 Decoder for Compression Mode FNR (Tetra-Cell) .............................................................. 385
Table 84 Decoder for Compression Mode OUT (Tetra-Cell) ............................................................. 387
Table 85 Decoder for Compression Mode eMPD (Tetra-Cell) ........................................................... 389
Table 86 Decoder for Compression Mode eHVD (Tetra-Cell) ........................................................... 392
Table 87 Decoder for Compression Mode eHVA ............................................................................... 394
Table 88 Decoder for Compression Mode eOUT ............................................................................... 397
Table 89 Decoder for Compression Mode OUT (Tetra-Cell) with 10:7 Compression Ratio .............. 401
Table 90 MPC Compression Modes for Nona-Cell Image Sensors .................................................... 404
Table 91 Decoder for Compression Mode AD (Nona-Cell)................................................................ 408
Table 92 Decoder for Compression Mode DGD (Nona-Cell) ............................................................ 410
Table 93 Decoder for Compression Mode FNR (Nona-Cell) ............................................................. 412
Table 94 Decoder for Compression Mode eAD (Nona-Cell).............................................................. 414
Table 95 Decoder for Compression Mode eHVD (Nona-Cell) ........................................................... 416
Table 96 Decoder for Compression Mode eHVI ................................................................................ 419
Table 97 Decoder for Compression Mode eSHV (Nona-Cell) ........................................................... 420
Table 98 Decoder for Compression Mode eMPD (Nona-Cell) ........................................................... 423
xx Copyright © 2005–2022 MIPI Alliance, Inc.

Confidential
23-May-2022
Release History
Date Version Description
29-Nov-2005 v1.00 Initial Board approved release.
09-Nov-2010 v1.01.00 Board approved release.
22-Jan-2013 v1.1 Board approved release.
10-Sep-2014 v1.2 Board approved release.
07-Oct-2014 v1.3 Board approved release.
28-Mar-2017 v2.0 Board approved release.
09-Apr-2018 v2.1 Board approved release.
10-Sep-2019 v3.0 Board approved release.
08-Dec-2021 v4.0 Board approved release.
2022-11-14 v4.0.1 Board approved release.
Copyright © 2005–2022 MIPI Alliance, Inc. xxi

Confidential
23-May-2022
This page intentionally left blank.
xxii Copyright © 2005–2022 MIPI Alliance, Inc.

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

Confidential
23-May-2022
2 Terminology
2.1 Use of Special Terms

24 The MIPI Alliance has adopted Section 13.1 of the IEEE Standards Style Manual, which dictates use of the
25 words “shall”, “should”, “may”, and “can” in the development of documentation, as follows:
26 The word shall is used to indicate mandatory requirements strictly to be followed in order
27 to conform to the Specification and from which no deviation is permitted (shall equals is
28 required to).
29 The use of the word must is deprecated and shall not be used when stating mandatory
30 requirements; must is used only to describe unavoidable situations.
31 The use of the word will is deprecated and shall not be used when stating mandatory
32 requirements; will is only used in statements of fact.
33 The word should is used to indicate that among several possibilities one is recommended
34 as particularly suitable, without mentioning or excluding others; or that a certain course of
35 action is preferred but not necessarily required; or that (in the negative form) a certain
36 course of action is deprecated but not prohibited (should equals is recommended that).
37 The word may is used to indicate a course of action permissible within the limits of the
38 Specification (may equals is permitted to).
39 The word can is used for statements of possibility and capability, whether material,
40 physical, or causal (can equals is able to).
41 All sections are normative, unless they are explicitly indicated to be informative.
2.2 Definitions
42 AOSC Transfer Mode: Either OTM, LTM, or STM; see Section 13.2.
43 CCI (I2C): CCI supporting I2C [NXP01].
44 CCI (I3C): CCI supporting I3C [MIPI03].
45 CCI (I3C SDR) means CCI supporting I3C SDR.
46 CCI (I3C DDR) means CCI supporting I3C DDR.
47 Controller: An I2C or I3C Device that is capable of controlling an I 2C or I3C Bus, respectively.
48 Note:
49 In previous versions of the CSI-2 Specification, a Controller Device was called a “Master Device”.
50 This version of the CSI-2 Specification has deprecated the term “Master”, and now uses the updated
51 normative term “Controller.” Please note that the technical definition of such a Device, and its Role
52 on an I2C or I3C Bus, are unchanged.
53 Filler: A CSI-2 protocol element that is inserted after CSI-2 Packets in order to ensure that data transmissions
54 on all Lanes end at the same time.
55 Lane: A unidirectional, point-to-point, 2- or 3-wire interface used for high-speed serial clock or data
56 transmission; the number of wires is determined by the PHY specification in use (i.e. either D-PHY or C-PHY,
57 respectively). A CSI-2 camera interface using the D-PHY physical layer consists of one clock Lane and one
58 or more data Lanes. A CSI-2 camera interface using the C-PHY physical layer consists of one or more Lanes,
59 each of which transmits both clock and data information. Note that when describing features or behavior
60 applying to both D-PHY and C-PHY, this specification sometimes uses the term data Lane to refer to both a
61 D-PHY data Lane and a C-PHY Lane.
2 Copyright © 2005–2022 MIPI Alliance, Inc.

Confidential
23-May-2022
62 Message: In CCI (I2C) or CCI (I3C SDR), a Message begins with a START or Repeated START condition,
63 followed by the address of the Target(s), R/W bit, other data, and ends with either a STOP or Repeated START
64 condition. In the case of CCI (I3C SDR), a START or Repeated START condition followed by 7’h7E may
65 be added to the beginning. In CCI (I3C DDR), a Message begins with either the I3C ENTHDR0 CCC or the
66 I3C HDR Restart Pattern, followed by an HDR-DDR Command, HDR-DDR Data, and ends with either the
67 I3C HDR Exit Pattern or the I3C HDR Restart Pattern.
68 Multi-Pixel: An N x N pixel structure with the same color filter array for all of its pixels. A Tetra-Cell and a
69 Nona-Cell are both Multi-Pixel structures.
70 Nona-Cell: A 3 x 3 Multi-Pixel (i.e., 9 pixels). That is, a 3 x 3 pixel structure with the same color filter array
71 on each of its pixels.
72 Operation: An Operation is composed of one or more Messages in order to read or write.
73 Packet: A group of bytes organized in a specified way to transfer data across the interface. All packets have
74 a minimum specified set of components. The byte is the fundamental unit of data from which packets are
75 made.
76 Payload: Application data only – with all sync, header, ECC and checksum and other protocol-related
77 information removed. This is the “core” of transmissions between application processor and peripheral.
78 Primary: The Primary is the PHY on the side of a Link that is the main data source. The Primary transmits
79 data in the Forward Direction and receives data in the Reverse Direction. In some Bi-directional systems the
80 functions of the Primary and Secondary are nearly equivalent. The difference between being Primary or
81 Secondary is simply that one side is identified as the Primary, and the other side is identified as the Secondary.
82 The side that is defined as the Primary does not change after the system is initialized.
83 Note:
84 In previous versions of the CSI-2 Specification, a Primary PHY was called a “Master PHY”. This
85 version of the CSI-2 Specification has deprecated the term “Master”, and now uses the updated
86 normative term “Primary.” Please note that the technical definition of such a PHY, and its Role on a
87 Link, are unchanged.
88 Secondary: The Secondary is the PHY on the side of a Link that is the main data sink. The Secondary
89 receives data in the Forward Direction and transmits data in the Reverse Direction. In some Bi-directional
90 systems the functions of the Primary and Secondary are nearly equivalent. The difference between being
91 Primary or Secondary is simply that one side is identified as the Primary, and the other side is identified as
92 the Secondary. The side that is defined as the Secondary does not change after the system is initialized.
93 Note:
94 In previous versions of the CSI-2 Specification, a Secondary PHY was called a “Slave PHY”. This
95 version of the CSI-2 Specification has deprecated the term “Slave”, and now uses the updated
96 normative term “Secondary.” Please note that the technical definition of such a PHY, and its Role on
97 a Link, are unchanged.
98 Sleep Mode: Sleep mode (SLM) is a leakage level only power consumption mode.
99 Spacer: An optional CSI-2 protocol element that may be inserted after CSI-2 Packets and Fillers transmitted
100 using CSI-2 LRTE; not to be confused with the C-PHY “Spacer Code” defined in [MIPI02].
101 Target: A Device on an I2C or I3C Bus that can only respond to commands from a Controller.
102 Note:
103 In previous versions of the CSI-2 Specification, a Target Device was called a “Slave Device”. This
104 version of the CSI-2 Specification has deprecated the term “Slave”, and now uses the updated
105 normative term “Target.” Please note that the technical definition of such a Device, and its Role on
106 an I2C or I3C Bus, are unchanged.
107 Tetra-Cell: A 2 x 2 Multi-Pixel (i.e., 4 pixels). That is, a 2 x 2 pixel structure with the same color filter array
108 on each of its pixels.

Confidential
23-May-2022
109 Transmission: The time during which high-speed serial data is actively traversing the bus. A transmission is
110 bounded by SoT (Start of Transmission) and EoT (End of Transmission) at beginning and end, respectively.
111 Virtual Channel: Multiple independent data streams for up to 32 peripherals are supported by this
112 Specification. The data stream for each peripheral may be a Virtual Channel. These data streams may be
113 interleaved and sent as sequential packets, with each packet dedicated to a particular peripheral or channel.
114 Packet protocol includes information that links each packet to its intended peripheral.
2.3 Abbreviations
115 APP AOSC host processor
116 e.g. For example (Latin: exempli gratia)
117 i.e. That is (Latin: id est)
118 SNS AOSC peripheral device

Confidential
23-May-2022
2.4 Acronyms
119 ALP Alternate Low Power
120 AOSC Always-On Sentinel Conduit
121 BER Bit Error Rate
122 CCI Camera Control Interface
123 CIL Control and Interface Logic
124 CRC Cyclic Redundancy Check
125 CSF Continuously Streaming Frames
126 CSI Camera Serial Interface
127 CSPS Chroma Shifted Pixel Sampling
128 DDR Dual Data Rate
129 DI Data Identifier
130 DT Data Type
131 ECC Error Correction Code
132 EoT End of Transmission
133 EoTp End of Transmission short packet
134 EPD Efficient Packet Delimiter (PHY and / or Protocol generated signaling used in LRTE)
135 EXIF Exchangeable Image File Format
136 FE Frame End
137 FOV Field of View
138 FS Frame Start
139 HS High-Speed; identifier for operation mode
140 HS-LPS-LS High-Speed to Low Power State to High-Speed switching (includes LPS entry and exit
141 latencies)
142 HS-RX High-Speed Receiver
143 HS-TX High-Speed Transmitter
144 I2C Inter-Integrated Circuit [NXP01]
145 ILR Interpacket Latency Reduction
146 JFIF JPEG File Interchange Format
147 JPEG Joint Photographic Expert Group
148 LE Line End
149 LFSR Linear Feedback Shift Register
150 LLP Low Level Protocol
151 LP Low-Power; identifier for operation mode
152 LP-RX Low-Power Receiver (Large-Swing Single Ended)

Confidential
23-May-2022
153 LP-TX Low-Power Transmitter (Large-Swing Single Ended)

154 LRTE Latency Reduction Transport Efficiency
155 LS Line Start
156 LSB Least Significant Bit
157 LSS Least Significant Symbol
158 LTM Legacy Transport Mode
159 LVLP Low Voltage Low Power
160 MPC Multi-Pixel Compression
161 MSB Most Significant Bit
162 MSS Most Significant Symbol
163 ODF On-Demand Frame
164 OTM Optimal Transfer Mode
165 PDQ Packet Delimiter Quick (PHY generated and consumed signaling used in LRTE)
166 PF Packet Footer
167 PH Packet Header
168 PHY Physical Layer
169 PI Packet Identifier
170 PPI PHY Protocol Interface
171 PRBS Pseudo-Random Binary Sequence
172 PT Packet Type
173 RGB Color representation (Red, Green, Blue)
174 RX Receiver
175 SCL Serial Clock (for CCI)
176 SDA Serial Data (for CCI)
177 SLM Sleep Mode
178 SoT Start of Transmission
179 STM Smart Transport Mode
180 TX Transmitter
181 ULPS Ultra Low Power State
182 VDSP Vision Digital Signal Processor\
183 VGA Video Graphics Array
184 YUV Color representation (Y for luminance, U & V for chrominance)

Confidential
23-May-2022
3 References
185 [NXP01] UM10204, I2C bus specification and user manual, Revision 6,
186 NXP Semiconductors N.V., 4 April 2014.
187 [MIPI01] MIPI Alliance Specification for D-PHY, version 3.0, MIPI Alliance, Inc., 8 June 2021.
188 [MIPI02] MIPI Alliance Specification for C-PHY, version 2.1, MIPI Alliance, Inc., 1 April 2021.
189 [MIPI03] MIPI Alliance Specification for I3C (Improved Inter-Integrated Circuit), version 1.1.1,
190 MIPI Alliance, Inc., 8 June 2021.
191 [MIPI04] MIPI Alliance Specification for Camera Command Set (CCS), version 1.1,
192 MIPI Alliance, Inc., 12 December 2019.
193 [MIPI05] MIPI Alliance Specification for Camera Service Extensions (CSE), version 1.0,
194 MIPI Alliance, Inc., 27 July 2021.
195 [MIPI06] MIPI Alliance Specification for A-PHY, version 1.0, MIPI Alliance, Inc., 6 August 2020.
196 [MIPI07] MIPI Multi Pixel Compression (MPC) Example Code,
197 <https://members.mipi.org/wg/All-Members/document/folder/14072>,
198 MIPI Alliance, Inc., last accessed 8 December 2021.

Confidential
23-May-2022

Confidential
23-May-2022
4 Overview of CSI-2
199 The CSI-2 Specification defines standard data transmission and control interfaces between transmitter and
200 receiver. Two high-speed serial data transmission interface options are defined.
201 The first option, referred to in this specification as the “D-PHY physical layer option,” is typically a
202 unidirectional differential interface with one 2-wire clock Lane and one or more 2-wire data Lanes. The
203 physical layer of this interface is defined by the MIPI Alliance Specification for D-PHY [MIPI01]. Figure 1
204 illustrates the connections for this option between a CSI-2 transmitter and receiver, which typically are a
205 camera module and a receiver module, part of the mobile phone engine.
206 The second high-speed data transmission interface option, referred to in this specification as the “C-PHY
207 physical layer option,” typically consists of one or more unidirectional 3-wire serial data Lanes, each of
208 which has its own embedded clock. The physical layer of this interface is defined by the MIPI Alliance
209 Specification for C-PHY [MIPI02]. Figure 2 illustrates the CSI transmitter and receiver connections for this
210 option.
211 The Camera Control Interface (CCI) for both physical layer options is a bi-directional control interface
212 compatible with the I2C standard [NXP01] and/or the MIPI I3C Specification [MIPI03].
213 Note that beginning with the CSI-2 v3.0 specification, Lane 1 of a D-PHY or C-PHY link interconnecting a
214 camera with a host or application processor (i.e., Data1+ / Data1- in Figure 1, or Data1_A / Data1_B /
215 Data1_C in Figure 2) is permitted to be bidirectional. For such links, there is no requirement to support a
216 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 target Unidirectional base band containing the CSI receiver
High-Speed and the CCI controller
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 Target Control Link CCI Controller
SCL SCL
SDA SDA
217
Figure 1 Typical CSI-2 and CCI Transmitter and Receiver Interface for D-PHY

Confidential
23-May-2022
Device e.g. a Camera containing the Device e.g. an application engine or

CSI transmitter and CCI target base band containing the CSI receiver
Unidirectional and the CCI controller
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
218
Figure 2 Typical CSI-2 and CCI Transmitter and Receiver Interface for C-PHY

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

Lane Distribution / Lane Merging
Layer Layer
n=16 for Option C (C-PHY)
N x n-bits N x n-bits
n=8 for Option D (D-PHY)
Generation / Detection of Packet Start & Stop Signaling
Serializer / Deserializer
PHY Layer Clock Generation / Recovery (DDR) PHY Layer
Electrical Layer
High-Speed Unidirectional Clock

applies to D Option only
High-Speed Unidirectional Lane 1
219
High-Speed Unidirectional Lane N
Figure 3 CSI-2 Layer Definitions
220 Figure 3 defines the conceptual layer structure typically used in CSI-2. The layers can be characterized as
221 follows:
222 • PHY Layer. The PHY Layer specifies the transmission medium (electrical conductors), the
223 input/output circuitry and the clocking mechanism that captures “ones” and “zeroes” from the
224 serial bit stream. This part of the Specification documents the characteristics of the transmission
225 medium, electrical parameters for signaling and for the D-PHY physical layer option, the timing
226 relationship between clock and data Lanes.
227 The mechanism for signaling Start of Transmission (SoT) and End of Transmission (EoT) is
228 specified as well as other “out of band” information that can be conveyed between transmitting
229 and receiving PHYs. Bit-level and byte-level synchronization mechanisms are included as part of
230 the PHY.
231 The PHY layer is described in [MIPI01] and [MIPI02].

Confidential
23-May-2022
232 • Protocol Layer. The Protocol layer is composed of several layers, each with distinct
233 responsibilities. The CSI-2 protocol enables multiple data streams using a single interface on the
234 host processor. The Protocol layer specifies how multiple data streams may be tagged and
235 interleaved so each data stream can be properly reconstructed.
236 • Pixel/Byte Packing/Unpacking Layer. The CSI-2 specification supports image applications
237 with varying pixel formats. In the transmitter this layer packs pixels from the Application layer
238 into bytes before sending the data to the Low Level Protocol layer. In the receiver this layer
239 unpacks bytes from the Low Level Protocol layer into pixels before sending the data to the
240 Application layer. Eight bits per pixel data is transferred unchanged by this layer.
241 • Low Level Protocol. The Low Level Protocol (LLP) includes the means of establishing bit-
242 level and byte-level synchronization for serial data transferred between SoT (Start of
243 Transmission) and EoT (End of Transmission) events and for passing data to the next layer. The
244 minimum data granularity of the LLP is one byte. The LLP also includes assignment of bit-value
245 interpretation within the byte, i.e. the “Endian” assignment.
246 • Lane Management. CSI-2 is Lane-scalable for increased performance. The number of data
247 Lanes is not limited by this specification and may be chosen depending on the bandwidth
248 requirements of the application. The transmitting side of the interface distributes (“distributor”
249 function) bytes from the outgoing data stream to one or more Lanes. On the receiving side, the
250 interface collects bytes from the Lanes and merges (“merger” function) them together into a
251 recombined data stream that restores the original stream sequence. For the C-PHY physical
252 layer option, this layer exclusively distributes or collects byte pairs (i.e. 16-bits) to or from the
253 data Lanes. Scrambling on a per-Lane basis is an optional feature, which is specified in detail in
254 Section 9.17.
255 Data within the Protocol layer is organized as packets. The transmitting side of the interface
256 appends header and error-checking information on to data to be transmitted at the Low Level
257 Protocol layer. On the receiving side, the header is stripped off at the Low Level Protocol layer
258 and interpreted by corresponding logic in the receiver. Error-checking information may be used to
259 test the integrity of incoming data.
260 • Application Layer. This layer describes higher-level encoding and interpretation of data contained
261 in the data stream and is beyond the scope of this specification. The CSI-2 Specification describes
262 the mapping of pixel values to bytes.
263 The normative sections of the Specification only relate to the external part of the Link, e.g. the data and bit
264 patterns that are transferred across the Link. All internal interfaces and layers are purely informative.

Confidential
23-May-2022
6 Camera Control Interface (CCI)

265 CCI is a two-wire, bi-directional, half duplex, serial interface for controlling the transmitter. CCI is
266 compatible with I2C Fast-mode (Fm) or Fast-mode Plus (Fm+) [NXP01] variants, and with the I3C [MIPI03]
267 interface’s Single Data Rate (SDR) or Double Data Rate (DDR) protocols. CCI shall support up to 400kbps
268 (Fm) operation and 7-bit Target addressing. In addition, CCI can optionally support up to 1Mbps (Fm+),
269 12.5Mbps (SDR), or 25Mbps (DDR).
270 This Section uses the following terms:
271 • CCI (I2C) means CCI supporting I2C
272 • CCI (I3C) means CCI supporting I3C
273 • CCI (I3C SDR) means CCI supporting I3C SDR
274 • CCI (I3C DDR) means CCI supporting I3C DDR
275 • CCI alone (without following parentheses) means both CCI (I2C) and CCI (I3C).
276 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
277 receiver shall be configured as a Controller and a CSI-2 transmitter shall be configured as a Target. When
278 CCI is used without CSI-2 over C/D-PHY, the host should be used as a Controller. CCI is capable of handling
279 multiple Targets on the bus.
280 In CCI (I2C), multi-controller mode is not supported. Any I2C commands not described in this section shall
281 be ignored, and shall not cause unintended device operation.
282 In CCI (I3C), any I3C mandatory functions and ‘Required’ CCC commands shall be supported, and any I3C
283 optional functions and commands may be supported (e.g., Multi-Controller, In-Band Interrupt, Hot-Join).
284 Typically, there is a dedicated CCI interface between the transmitter and the receiver.
285 CCI is a subset of the I2C or I3C protocol that includes the minimum combination of obligatory features for
286 I2C/I3C Target devices specified in the I2C or I3C specification. Therefore, transmitters complying with the
287 CCI specification can also be connected to the system I 2C or I3C bus. However, care must be taken so that
288 I2C or I3C Controllers do not attempt to use I2C or I3C features not supported by CCI Controllers or Targets.
289 A CCI transmitter may have additional features to support I 2C or I3C, but that is implementation-dependent.
290 Further details can be found on a particular device’s data sheet.
291 This specification does not attempt to define the contents of control Messages sent by the CCI Controller.
292 Therefore, it is the responsibility of the implementer to define a set of control Messages and corresponding
293 frame timing and any I2C or I3C latency requirements that the CCI Controller must meet when sending such
294 control Messages to the CCI Target.
295 CCI defines an additional data protocol layer on top of I 2C or I3C, as specified in the following sections.

Confidential
23-May-2022
6.1 CCI (I2C) Data Transfer Protocol

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

298 A basic CCI (I2C) Message consists of:
299 • START or Repeated START condition
300 • Target address with read/write bit
301 • Acknowledge from Target
302 • Sub address (INDEX) for pointing at a register inside the Target device (not used in Single Read
303 from Current Location)
304 • Acknowledge signal from Target (not used in Single Read from Current Location)
305 And then either:
306 • For a write operation:
307 • Data byte from Controller
308 • Acknowledge/negative acknowledge from Target, and
309 • STOP or Repeated START condition
310 Or:
311 • For a read operation:
312 • Repeated START condition (not used in Single Read from Current Location)
313 • Target address with read bit (not used in Single Read from Current Location)
314 • acknowledge signal from Target (not used in Single Read from Current Location)
315 • data byte from the Target
316 • acknowledge or negative acknowledge from the Controller, and
317 • STOP or Repeated START condition.
318 A CCI Target may support back-to-back Messages by using Repeated START between CCI Messages instead
319 of START and/or STOP as shown in this Section.
320 The Target address in CCI (I2C) is 7 bits long.
321 CCI (I2C) supports an 8-bit INDEX with 8-bit data, or a 16-bit INDEX with 8-bit data. The Target device in
322 question defines what Message type is used.

Confidential
23-May-2022
6.1.2 CCI (I2C) Read/Write Operations

323 A CCI (I2C) compatible device shall support the four read operations and two write operations shown in
324 Table 1, as detailed in the following sub-sections:
325 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
326 The INDEX in the Target device must be auto-incremented after each read/write operation. This is also
327 explained in the following sections.
6.1.2.1 CCI (I2C) Single Read from Random Location

328 In a single read from a random location (see Figure 4) the Controller does a dummy write operation to the
329 desired INDEX, issues a Repeated START condition, and then addresses the Target again with the read
330 operation. After acknowledging its Target address, the Target starts to output data onto the SDA line. The
331 Controller terminates the read operation by setting a negative acknowledge and a STOP or Repeated START
332 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 TARGET SUB ADDRESS S TARGET 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 TARGET SUB ADDRESS SUB ADDRESS S TARGET P

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

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

Confidential
23-May-2022
6.1.2.2 CCI (I2C) Single Read from Current Location

334 It is also possible to read from the last used INDEX, by addressing the Target with a read operation (see
335 Figure 5). The Target responds by sending the data from the last used INDEX to the SDA line. The Controller
336 terminates 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 TARGET P S TARGET P
1 A DATA A 1 A DATA A
Sr ADDRESS Sr Sr ADDRESS Sr
337
Figure 5 CCI (I2C) Single Read from Current Location

Confidential
23-May-2022
6.1.2.3 CCI (I2C) Sequential Read Starting from Random Location

338 Sequential read starting from a random location is illustrated in Figure 6. The Controller does a dummy write
339 to the desired INDEX, issues a Repeated START condition after an acknowledge from the Target, and then
340 addresses the Target again with a read operation. If a Controller issues an acknowledge after receiving data,
341 this acts as a signal to the Target that the read operation is to continue from the next INDEX. When the
342 Controller has read the last data byte, it issues a negative acknowledge and a STOP or Repeated START
343 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
TARGET S TARGET
0 A ADDRESS A 1 A DATA A DATA A
Sr ADDRESS [7:0]
r ADDRESS Sr
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
TARGET S TARGET
0 A ADDRESS A ADDRESS A 1 A DATA A DATA A
Sr ADDRESS [15:8] [7:0]
r ADDRESS Sr
344
Figure 6 CCI (I2C) Sequential Read Starting from Random Location

Confidential
23-May-2022
6.1.2.4 CCI (I2C) Sequential Read Starting from Current Location

345 A sequential read starting from the current location (see Figure 7) is similar to a sequential read from a
346 random location. The only exception is there is no dummy write operation. The Controller terminates the
347 read 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 TARGET P
1 A DATA A DATA A DATA A
Sr ADDRESS Sr
L bytes of data
348
Figure 7 CCI (I2C) Sequential Read Starting from Current Location

Confidential
23-May-2022
6.1.2.5 CCI (I2C) Single Write to Random Location

349 A write operation to a random location is illustrated in Figure 8. The Controller issues a write operation to
350 the Target, then issues the INDEX and data after the Target has acknowledged the write operation. The write
351 operation is terminated with a stop or Repeated START condition from the Controller.
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
STARGET 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
STARGET A/ P
0 A ADDRESS A ADDRESS A DATA
Sr ADDRESS A Sr
[15:8] [7:0]
INDEX, value M
352
Figure 8 CCI (I2C) Single Write to Random Location

Confidential
23-May-2022
6.1.2.6 CCI (I2C) Sequential Write Starting from Random Location

353 The Sequential Write Starting from Random Location operation is illustrated in Figure 9. The Target auto-
354 increments the INDEX after each data byte is received. The Sequential Write Starting from Random Location
355 operation is terminated with a STOP or Repeated START condition from the Controller.
CCI (I2C) Sequential Write Starting from a Random Location with 8-bit index and 8-bit data (7-bit address)
Index
Previous Index value, K Index M Index (M+L-1)
M+L
SUB
S TARGET 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
Previous Index value, K Index M Index (M+L-1)
M+L
SUB SUB
S TARGET 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
356
Figure 9 CCI (I2C) Sequential Write Starting from Random Location

Confidential
23-May-2022
6.2 CCI (I3C) Data Transfer Protocol

357 The CCI (I3C) data transfer protocol follows the I3C Specification. The START, Repeated START, and
358 STOP conditions, as well as data transfer protocol, are specified in [MIPI03].
359 If CCI (I3C) is supported, then CCI (I3C SDR) shall be supported and CCI (I3C DDR) may be supported.
360 The Controller shall get the Target’s Max Read Length (MRL) and Max Write Length (MWL) via
361 transmitting 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

362 The CCI (I3C SDR) Controller normally should start a Message with 7’h7E, and may choose to start a
363 Message with a Target address.
364 A basic CCI (I3C SDR) Message starting a Message with 7’h7E consists of:
365 • START condition
366 • 7’h7E with write bit
368 • Repeated START condition
371 • Sub-address (INDEX) of a register inside the Target device (not used in Single Read from Current
372 Location)
373 • Transition bit (Parity bit) from Controller (not used in Single Read from Current Location)
377 • Transition bit (Parity bit) from Controller
378 • STOP or Repeated START condition;
379 Or
383 • Acknowledge from Target (not used in Single Read from Current Location)
384 • Data byte from Target
385 • Transition bit (End-of-Data) from Controller or Target

Confidential
23-May-2022
387 Other CCI (I3C SDR) Messages starting a Message with a Target address consist of:
388 • START or Repeated START condition
391 • Sub-address (INDEX) of a register inside the Target device (not used in Single Read from Current
392 Location)
393 • Transition bit (Parity bit) from Controller (not used in Single Read from Current Location)
397 • Transition bit (Parity bit) from Controller
398 • STOP or Repeated START condition;
399 Or:
403 • Acknowledge from Target (not used in Single Read from Current Location)
404 • Data byte from Target
405 • Transition bit (End-of-Data) from Controller or Target
407 The Target address in CCI (I3C SDR) is 7 bits long.
408 CCI (I3C SDR) supports an 8-bit INDEX with 8-bit data, or a 16-bit INDEX with 8-bit data. The Target
409 device in question defines what Message type is used.
6.2.1.2 CCI (I3C SDR) Read/Write Operations

410 A CCI (I3C SDR) compatible device shall support the four read operations and two write operations shown
411 in Table 2, as detailed in the following sub-sections:
412 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
23-May-2022
6.2.1.2.1 CCI (I3C SDR) Single Read from Random Location

415 In a single read from a random location (Figure 10), the Controller does a dummy write operation to the
416 desired INDEX, issues a Repeated START condition, and then addresses the Target again with the read
417 operation. After acknowledging its Target address, the Target starts to output data onto the SDA line. The
418 Controller aborts 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 TARGET SUB ADDRESS TARGET 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 TARGET SUB ADDRESS TARGET 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 TARGET SUB ADDRESS SUB ADDRESS TARGET 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 TARGET SUB ADDRESS SUB ADDRESS TARGET P

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

S = START condition
From Controller to Target 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)
419
Figure 10 CCI (I3C SDR) Single Read from Random Location

Confidential
23-May-2022
6.2.1.2.2 CCI (I3C SDR) Single Read from Current Location

420 It is also possible to read from the last used INDEX by addressing the Target with a read operation (Figure
421 11). The Target responds by setting the data from last used INDEX to SDA line. The Controller aborts the
422 read 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 TARGET P I3C Reserved TARGET 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 TARGET P S TARGET P
1 A DATA T 1 A DATA T
Sr ADDRESS Sr Sr ADDRESS Sr

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

Confidential
23-May-2022
6.2.1.2.3 CCI (I3C SDR) Sequential Read from Random Location

424 The sequential read starting from a random location is illustrated in Figure 12. The Controller does a dummy
425 write operation to the desired INDEX, issues a Repeated START condition, and then addresses the Target
426 again with the read operation. After acknowledging its Target address, the Target starts to output data onto
427 the SDA line. If a Controller doesn’t abort the read transaction by using the transition bit, this acts as a signal
428 for the Target to continue a read operation from the next INDEX. When the Controller has read the last data
429 byte, it can abort a read transaction by setting the transition bit and then issuing a STOP or Repeated START
430 condition. Furthermore, when the Controller reads a large amount of data exceeding the Max Read Length
431 (MRL) limit (see the I3C Specification [MIPI03]), the Target can also terminate a read transaction by setting
432 the transition bit.
433 Note:
434 When selecting a suitable value for MRL, the designer of the Target device and the system designer
435 should take into account the needs of the payload that the CCI will carry. For example, in the CCS
436 Data Transfer Interface [MIPI04], it is beneficial to support an MRL of 64 bytes or larger (i.e. 64 bytes
437 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 TARGET SUB ADDRESS TARGET 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 TARGET SUB ADDRESS TARGET 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 TARGET SUB ADDRESS SUB ADDRESS TARGET 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 TARGET SUB ADDRESS SUB ADDRESS TARGET 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
438
Figure 12 CCI (I3C SDR) Sequential Read Starting from Random Location

Confidential
23-May-2022
6.2.1.2.4 CCI (I3C SDR) Sequential Read from Current Location

439 A sequential read starting from the current location (Figure 13) is similar to a sequential read from a random
440 location. The only exception is when there is no dummy write operation. The Controller or Target terminates
441 a 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 TARGET 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 TARGET P
1 A DATA T DATA T
Sr ADDRESS Sr
L bytes of data

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

Confidential
23-May-2022
6.2.1.2.5 CCI (I3C SDR) Single Write to Random Location

443 A write operation to a random location is illustrated in Figure 14. The Controller issues a write operation to
444 the Target, then issues the INDEX and data after the Target 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 TARGET 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 TARGET 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 TARGET 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 TARGET 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
446
Figure 14 CCI (I3C SDR) Single Write to Random Location

Confidential
23-May-2022
6.2.1.2.6 CCI (I3C SDR) Sequential Write Starting from Random Location
447 The Sequential Write Starting from Random Location operation is illustrated in Figure 15. The Target auto-
448 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 TARGET 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 TARGET 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 TARGET 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 TARGET 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
450
Figure 15 CCI (I3C SDR) Sequential Write Starting from Random Location

Confidential
23-May-2022
6.2.2 CCI (I3C DDR) Data Transfer Protocol
6.2.2.1 CCI (I3C DDR) Message Type

451 The CCI (I3C DDR) Controller shall start a DDR Message with either the I3C ENTHDR0 CCC, or the I3C
452 HDR Restart Pattern. The CCI (I3C DDR) Controller shall end a DDR Message by issuing either the I3C
453 HDR Restart Pattern, or the I3C HDR Exit Pattern.
454 Two Message types are defined for DDR Messages: DDR Write Message and DDR Read Message.
455 CCI (I3C DDR) supports either:
456 • 8-bit LENGTH and 8-bit INDEX with 8-bit data
457 Both the LENGTH and the INDEX shall be included in the first data word of the DDR
458 Write Message.
459 or:
460 • 16-bit LENGTH and 16-bit INDEX with 8-bit data
461 The LENGTH shall be included in the first data word of the DDR Write Message, and the
462 INDEX shall be included in the second data word of the DDR Write Message.
463 The Target device in question defines what Message type is used.
464 The LENGTH field defines the number of 8-bit data bytes in the Read or Write Data Words. The LENGTH
465 field is zero-based, i.e. if the Controller wishes to read or write N bytes, then the value in the LENGTH field
466 must be N–1.
Examples
467 • 0 LENGTH means 1 byte
468 • 255 LENGTH means 256 bytes
469 When a multi-byte register is accessed via CCI (I3C DDR), the transmission byte order described in
470 Section 6.6 shall be the same as for CCI (I2C) and CCI (I3C SDR).
Example
471 For the 16-bit register read shown in Figure 17, the DATA0 byte contains bits Data[15:8] and the
472 DATA1 byte contains bits Data[7:0].

Confidential
23-May-2022
6.2.2.2 CCI (I3C DDR) Read/Write Operations

473 A CCI (I3C DDR) compatible device shall support the two read operations and one write operation shown
474 in Table 3, as detailed in the following sub-sections:
475 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

478 As defined in the I3C Specification [MIPI03], bit[15] of the HDR-DDR Command Word is the R/W bit and
479 bits[14:8] contain the Command Code. Command Code values are reserved per application, and CCI (I3C
480 DDR) defines one such Command Code: 7’b0000000.
481 This single Command Code is sufficient, because the Target can still distinguish between three different R/W
482 operations. Consider the example of 16-bit LENGTH and 16-bit INDEX:
483 • If the Target receives a Data Word greater than 4 bytes, then the operation is “Sequential Write
484 Starting from Random Location”.
485 • If the Target receives a Data Word of 4 bytes before the HDR Restart Pattern, then there are two
486 possibilities:
487 • If the value of the LENGTH field is ≤ MRL–1, then the operation is “Sequential Read Starting
488 from a Random Location”.
489 • If the value of the LENGTH field is > MRL–1, then the operation is “Concatenated Sequential
490 Read Starting from a Random Location”.

Confidential
23-May-2022
491 Table 4 defines the I3C HDR-DDR Command Codes (including R/W bit) for each CCI (I3C DDR)
492 Read/Write operation.
493 For CCI (I3C DDR), the Target address is 7 bits long, and appears in bits[7:1] of the HDR-DDR Command
494 Word.
495 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

496 In a sequential read from a random location (Figure 16 and Figure 17):
497 • The Controller shall transmit:
498 • The HDR-DDR Command Word for LENGTH and INDEX
499 • The HDR-DDR Data Word, including LENGTH and INDEX
500 • The HDR-DDR CRC Word
501 • The HDR Restart Pattern
502 • The HDR-DDR Command Word for ReadData
503 • Then the Target shall send one or more HDR-DDR Read Data Words followed by the HDR-DDR
504 CRC Word
505 • Finally the Controller shall send either the HDR Restart Pattern or the HDR Exit Pattern.
506 If the number of 8-bit data words read is odd (i.e. the value in the LENGTH field is even), then the Target
507 shall insert one padding byte in the second byte of the last data word, with value 8’h00. The Target shall not
508 increment INDEX by the padding byte. The Controller shall take into account that the data includes the
509 padding byte in odd transfers, and that the INDEX is not incremented by the padding byte.
510 The Controller shall load the Sub Address into the INDEX and auto-increment the INDEX after each data
511 byte is received. The Controller can identify the padding byte from the value of the LENGTH field and the
512 number of the received 8-bit data words, and shall ignore the padding byte. Note that the INDEX is not
513 incremented by the padding byte.

Confidential
23-May-2022
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
TARGET HDR
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
ENTHDR DDR TARGET SUB DDR
HDR
Parity
Parity
Parity
Parity
Parity
Exit
setup
setup
LENGTH ADDRESS DATA DATA DATA DATA
Command ADDRESS ADDRESS 4'hC CRC5 Command 4'hC CRC5
HDR (Write) / 1'b0
[7:0]
[7:0] Restart (Read)
/ Read Parity 0 1 L-2 L-1 HDR
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
TARGET HDR
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
ENTHDR DDR TARGET SUB DDR padding
HDR
Parity
Parity
Parity
Parity
Parity
Exit
setup
setup
LENGTH ADDRESS DATA DATA DATA
Command ADDRESS ADDRESS 4'hC CRC5 Command byte 4'hC CRC5
HDR (Write) / 1'b0
[7:0]
/ Read Parity 0 1 L-1
0x00 HDR
Adjustment
Restart Restart
LENGTH, INDEX,
L bytes of data
value L-1 value M
From Controller to Target From Target to Controller

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

Confidential
23-May-2022
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
TARGET HDR
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
ENTHDR DDR TARGET SUB SUB DDR
HDR
Parity
Parity
Parity
Parity
Parity
Parity
Exit
setup
setup
LENGTH LENGTH ADDRESS DATA DATA DATA DATA
Command ADDRESS ADDRESS ADDRESS 4'hC CRC5 Command 4'hC CRC5
HDR (Write) / 1'b0
[15:8] [7:0]
[15:8] [7:0] Restart (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
TARGET HDR
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
ENTHDR DDR TARGET SUB SUB DDR padding

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

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

Confidential
23-May-2022
6.2.2.2.3 CCI (I3C DDR) Concatenated Sequential Read from Random Location
516 When the Controller desires to read data longer than the Target’s I3C Max Read Length (MRL) [MIPI03],
517 the Controller can divide the data into multiple units, and efficiently read the data using the Concatenated
518 Sequential Read from Random Location operation (Figure 18 and Figure 19). The Controller shall divide
519 the data into multiple units, where all units except the last unit shall use the MRL size, and the last unit shall
520 use a size less than or equal to the MRL. The MRL size is programmable.
521 In a Concatenated Sequential Read Starting from Random Location:
522 • The Controller shall first transmit the total LENGTH for the data to be read.
523 • The Controller shall use multiple read Messages. The Target shall transmit the initial read
524 Messages to the Controller using the programmed MRL data bytes. And the Target may use no
525 more than the programmed MRL data bytes to transfer the last Message.
526 • If the full amount of requested data has not been received yet, then the Controller shall transmit
527 another read Message, but without LENGTH and INDEX.
528 • After receiving the read Message without LENGTH and INDEX, the Target shall continue
529 transmission of the read data to the Controller, resuming from the previous LENGTH and
530 INDEX.
531 The Controller shall continue to transmit read Messages without LENGTH and INDEX multiple times, until
532 the last data is received.
533 Note:
534 When selecting a suitable value for MRL, the designer of the Target device and the system designer
536 Data Transfer Interface [MIPI04], it is beneficial to support an MRL of 64 bytes or larger (i.e. 64 bytes
537 for Data payload).

Confidential
23-May-2022
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
Preamble
Preamble
Preamble
ENTHDR DDR TARGET SUB
HDR
Parity
Parity
setup
LENGTH
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
TARGET
Preamble
Preamble
Preamble
Preamble
HDR DDR
HDR
Parity
Parity
Parity
setup
ADDRESS DATA DATA DATA DATA
Command 4'hC CRC5
Restart / Read Parity 0 1 X-2 X-1 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
TARGET
Preamble
Preamble
Preamble
Preamble
HDR DDR HDR
Parity
Parity
Parity
setup
Command
/ Read Parity X X+1 X+Y-2 X+Y-1
4'hC CRC5 X+Y+Z
Restart (Read) Restart
Adjustment =L
Y bytes of data

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

CRC Word
TARGET HDR
Preamble
Preamble
Preamble
Preamble
HDR DDR padding

Parity
Parity
Parity
Exit
setup
ADDRESS DATA DATA DATA

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

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

Confidential
23-May-2022
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
Preamble
Preamble
Preamble
Preamble
ENTHDR DDR TARGET SUB SUB
HDR
Parity
Parity
Parity
setup
LENGTH LENGTH
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
TARGET
Preamble
Preamble
Preamble
Preamble
DDR
HDR HDR
Parity
Parity
Parity
setup
Command 4'hC CRC5
Restart / Read Parity 0 1 X-2 X-1 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
TARGET
Preamble
Preamble
Preamble
Preamble
DDR
HDR HDR
Parity
Parity
Parity
setup
Command
/ Read Parity X X+1 X+Y-2 X+Y-1
4'hC CRC5 X+Y+Z
Restart (Read) Restart
Adjustment =L
Y bytes of data

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

CRC Word
TARGET HDR
Preamble
Preamble
Preamble
Preamble
DDR padding
HDR
Parity
Parity
Parity
Exit
setup
ADDRESS DATA DATA DATA

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

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

Confidential
23-May-2022
6.2.2.2.4 CCI (I3C DDR) Sequential Write Starting from Random Location
540 In a Sequential Write Starting from Random Location (Figure 20), the Controller shall transmit:
541 • The HDR-DDR Command Word
542 • The HDR-DDR Data Word including LENGTH and INDEX
543 • One or more HDR-DDR Write Data Words, and
544 • The HDR-DDR CRC Word.
545 If the number of 8-bit data words written is odd (i.e. the value in the LENGTH field is even), then the
546 Controller shall insert one padding byte in the second byte of the last data word, with value 8’h00. When the
547 Target receives the Sub Address, the Target loads it into the INDEX and auto-increments the INDEX after
548 each data byte is received.
549 The Target can identify the padding byte from the value of the LENGTH field and the number of 8-bit data
550 words received, and shall ignore the padding byte. Note that the INDEX is not incremented by the padding
551 byte.
552 In a Sequential Write Starting from Random Location, the value of LENGTH shall be set such that the
553 Controller does not exceed the maximum data byte length limit defined by the Target’s I3C Max Write Length
554 (MWL) [MIPI03]. Note that the total number of bytes of “Data Word for INDEX”, “Data Word for
555 LENGTH”, and “Data Word for Write Data” shall not exceed MWL.
Example
556 For a Target with MWL of 8 bytes, using 16-bit INDEX (so “Data Word for INDEX” is 2 bytes)
557 and 16-bit LENGTH (so “Data Word for LENGTH” is 2 bytes), the maximum number of “Data
558 Word for Write Data” is 8 – (2 + 2) bytes = 4 bytes. Since the LENGTH field is zero-based, it
559 would contain the value 3 (16’d3).
560 The Target cannot terminate the DDR Write Message, and shall receive all HDR-DDR Write Data sent by
561 the Controller.
562 Note:
563 When selecting a suitable value for MWL, the designer of the Target device and the system designer
565 Data Transfer Interface [MIPI04], it is beneficial to support an MWL of 68 bytes or larger (i.e. 64 bytes
566 for Data payload + 2 bytes for a Data Word for INDEX + 2 bytes for a Data Word for LENGTH).

Confidential
23-May-2022
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
Preamble
Preamble
Preamble
Preamble
Preamble
ENTHDR DDR TARGET SUB
Parity
Parity
Parity
Parity
Exit
setup
LENGTH DATA DATA DATA DATA
HDR (Write) / 1'b0
[7:0]
[7:0]
0 1 L-2 L-1 HDR
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
Preamble
Preamble
Preamble
Preamble
Preamble
ENTHDR DDR TARGET SUB padding

Parity
Parity
Parity
Parity
Exit
setup
LENGTH DATA DATA DATA
Command ADDRESS ADDRESS byte 4'hC CRC5
HDR (Write) / 1'b0
[7:0]
[7:0]
0 1 L-1
0x00 HDR
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
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
ENTHDR DDR TARGET SUB SUB

Parity
Parity
Parity
Parity
Parity
Exit
setup
LENGTH LENGTH DATA DATA DATA DATA
Command ADDRESS ADDRESS ADDRESS 4'hC CRC5
HDR (Write) / 1'b0
[15:8] [7:0]
[15:8] [7:0]
0 1 L-2 L-1 HDR
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
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
ENTHDR DDR TARGET SUB SUB padding

Parity
Parity
Parity
Parity
Parity
Exit
setup
LENGTH LENGTH DATA DATA DATA

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

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

Confidential
23-May-2022
6.3 CCI (I3C) Error Detection and Recovery
6.3.1 CCI (I3C SDR) Error Detection and Recovery Method

568 The error detection and recovery methods specified in this Section are provided in order to avoid fatal
569 conditions when errors occur. The CCI (I3C SDR) error detection and recovery methods follow the I3C
570 Specification. The I3C error detection and recovery method for the Target and Controller are specified in
571 [MIPI03]. A CCI (I3C SDR) compatible device shall support both the methods defined by I3C and the
572 methods defined in this Section regarding CCI (I3C SDR), respectively.
6.3.1.1 Error Detection and Recovery Method for CCI (I3C SDR) Target Devices
573 The SS0 error summarized in Table 5 shall be supported for all CCI (I3C SDR) Target Devices. If the CCI
574 Target detects the SS0 error, the CCI Target shall set to 1’b1 in Protocol Error Flag of GETSTATUS. Details
575 of the SS0 error are described in Section 6.3.1.1.2.
576 Table 5 CCI (I3C SDR) Target Error Types
Error
Description Error Detection Method Error Recovery Method
Type
SS0 Read without INDEX Error Detect an error if the Target Enable STOP or Repeated
receives the Target’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

577 The CCI (I3C SDR) Target shall clear the INDEX value when the I3C Target detects S2 [MIPI03] or S6
578 ([MIPI03], optional) during the “CCI (I3C SDR) Read/Write Operations” in Table 2. Note that this rule shall
579 not be applicable to other Operations (e.g., I3C CCC Transfers). As defined in the I3C specification, the I3C
580 Target sets to 1’b1 in the Protocol Error Flag of GETSTATUS (defined in the I3C specification) when the
581 I3C Target detects an error.
582 Clearing the INDEX due to S2 and S6 errors in the CCI (I3C SDR) Write Operations (Single Write to Random
583 Location, Sequential Write Starting from Random Location) is described below:
584 • If an S2 error occurs in the CCI (I3C SDR) Write Operations, the CCI Target cannot count up the
585 INDEX because the CCI Target cannot receive the correct write data. As a result, the INDEX in
586 the CCI Target may be different from the INDEX value that the Controller is expecting. In order to
587 avoid this situation, the CCI Target shall clear the INDEX value.
588 • When the I3C Controller doesn’t have the collision detector and the I3C Target has it, the INDEX
589 in the CCI Target may be different from the INDEX value that the Controller is expecting in case
590 of an S6 error. This is because the CCI Controller assumes the INDEX counter in the Target to be
591 counting up, but the CCI Target stops the counter. In order to avoid this situation, the CCI Target
592 shall clear the INDEX value.
593 Clearing the INDEX due to an S2 error in the CCI (I3C SDR) Read Operations (Single/Sequential Read to
594 Random Location) is described below:
595 • If an S2 error occurs in the CCI (I3C SDR) Single/Sequential Read from Random Location during
596 sub address, the CCI Target cannot update the value of INDEX because the I3C Target cannot get
597 the correct sub address. This could cause Target to send undefined or wrong data. In order to avoid
598 this situation, the CCI Target shall clear the INDEX value.

Confidential
23-May-2022
6.3.1.1.2 SS0 Error

599 The CCI Target shall detect an SS0 error if the CCI Target receives the Target address (except 7’h7E) with a
600 Read (R/W bit is 1) correctly but it does not have the INDEX value. After detecting the SS0 error, the CCI
601 Target shall replace ACK generated by the I3C Target with NACK during SS0 error and then wait for STOP
602 or Repeated START. Figure 21 illustrates how NACK is generated in CCI (I3C SDR) Sequential Read from
603 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
TARGET SUB ADDRESS TARGET TARGET SUB ADDRESS TARGET

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
S2
Target Normal Normal
Error
Status
The I3C Target neglects all
NACK
received data until Sr or P
The CCI Target clears

the value of INDEX
CCI
Target Previous INDEX value, K No INDEX INDEX M
INDEX
Read w/o INDEX Recovered by Sr
CCI
SS0
Target Normal Normal
Error
Status
The CCI Target neglects all
received data until Sr or P
S = START condition
P = STOP condition
N = Not acknowledge
Transition Bit (End-of-Data for Read Data) T = Transition Bit alternative to ACK/NACK
604
Figure 21 Example of SS0 Error Detection

Confidential
23-May-2022
6.3.2 CCI (I3C DDR) Error Detection and Recovery Method

605 The error detection and recovery methods specified in this Section are provided in order to avoid fatal
606 conditions when errors occur. The CCI (I3C DDR) error detection and recovery methods follow the I3C
607 Specification. The I3C error detection and recovery method for the Target and Controller are specified in
608 [MIPI03]. A CCI (I3C DDR) compatible device shall support both the methods defined by I3C and the
609 methods defined in this section regarding CCI (I3C DDR) respectively.
6.3.2.1 Error Detection and Recovery Method for CCI (I3C DDR) Target Devices
610 The two Error Types summarized in Table 6 shall be supported for all CCI (I3C DDR) Target Devices. Each
611 Error Type is further explained below the table. If the Target detects an SD0 or SD1 error, the Target shall set
612 the Protocol Error Flag in GETSTATUS (defined in the I3C specification) to 1’b1. Details of the SD0 and
613 SD1 errors are described in Section 6.3.2.1.2 and Section 6.3.2.1.3, respectively.
614 Table 6 CCI (I3C DDR) Target Error Types
Error
Type
SD0 Read without INDEX Error Detect an error if the Target 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 2'b11 detector and neglect other
patterns
6.3.2.1.1 Clearing INDEX After Detecting I3C Error

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

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

Confidential
23-May-2022
629
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
TARGET
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
ENTHDR DDR TARGET SUB DDR DDR TARGET
HDR HDR
Parity
Parity
Parity
Parity
setup
LENGTH ADDRESS 19 SCL
Command ADDRESS ADDRESS 4'hC CRC5 Command Command ADDRESS
HDR (Write) / 1'b0
[7:0]
/ Read Parity clock Restart (Write) / 1'b0
Adjustment
Restart
LENGTH, INDEX, Parity Error Recovered by
NACK
value L-1 value M HDR Restart
I3C
Target Normal Parity Error Normal
Status
The I3C Target neglects all received
data until HDR Restart or HDR Exit
The CCI Target clears
CCI the value of INDEX
Target Previous Index value, K No INDEX
INDEX Recovered by
Read w/o INDEX HDR Restart or HDR Exit
CCI
Target Normal SD0 Error Normal
Status
The CCI Target neglects all received
data until HDR Restart or HDR Exit
630
Figure 22 Example of SD0 Error Detection

Confidential
23-May-2022
6.3.2.1.3 SD1 Error

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

Confidential
23-May-2022
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
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
ENTHDR DDR TARGET Parity SUB
Parity
Parity
Parity
Parity
Exit
setup
LENGTH DATA DATA DATA DATA DATA DATA
HDR (Write) / 1'b0
[7:0]
[7:0]
0 1 L-2 L-1 L L+1 HDR
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
Target Normal
Status
Recovered by
HDR Restart or
HDR Exit
CCI
Target Previous Index value, K No INDEX
M M+1 M+L-2 M+L-1 M+L
INDEX
Write over LENGTH Clear the value of INDEX
CCI
Target Normal SD1 Error Normal
Status

637
Figure 23 Example of SD1 Error Detection

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

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

Confidential
23-May-2022
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]
TARGET
Preamble
Preamble
Preamble
Preamble
Preamble
Preamble
ENTHDR DDR TARGET SUB DDR
HDR
Parity
Parity
Parity
Parity
Parity
Exit
setup
LENGTH ADDRESS DATA DATA DATA DATA
Command ADDRESS ADDRESS 4'hC CRC5 Command
HDR Restart or HDR Exit

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

CCI
Controller MD0
Normal Normal
Status Error

647
Figure 24 Example of MD0 Error Detection

Confidential
23-May-2022
6.3.3 Error Detection and Recovery for CCI (I3C) Controller Devices
648 In many cases, the Controller can detect an error inside the Target by receiving NACK. However, for example
649 in case of an S2 or S6 error in the CCI (I3C SDR) Write Operations, the Controller cannot detect it by
650 receiving NACK because there is no chance for the Target to send NACK by the end of the operation (STOP
651 or Repeated START). Therefore if high reliability is required, the Controller may transmit GETSTATUS
652 (defined in the I3C specification) at each important point.
653 Note:
654 E.g., the important point is that after critical CCI (I3C SDR) Write Operations, after CCI (I3C SDR)
655 Write Operations before moving to CCI (I3C DDR), after multiple CCI (I3C SDR) Read/Write
656 Operations before long pause if the last message is CCI (I3C SDR) Write Operations.
657 As a result, the Controller can detect each error by the following methods:
658 1. Target’s error by receiving NACK
659 2. Target’s error during CCI (I3C SDR) or CCI (I3C DDR) Write Operations by sending
660 GETSTATUS
661 3. Controller’s I3C SDR Error defined in the I3C specification (M0, M1 or M2 error)
662 4. Controller’s I3C DDR Error defined in the I3C specification (including the Controller sending
663 HDR Exit or HDR Restart pattern)
664 After detecting an error, the Controller should try the following error recovery method:
665 1. The Controller may retry sending the same CCI (I3C SDR) Read/Write Operations or CCI (I3C
666 DDR) Read/Write Operations again.
667 2. The Controller may send certain other CCI (I3C SDR) Read/Write Operations or CCI (I3C DDR)
668 Read/Write Operations, except CCI (I3C SDR) Single/Sequential Read From Current Location
669 because the Target would generate NACK again due to an SS0 or SD0 error.
670 In addition to, or instead of, a retry, the Controller may read GETSTATUS, or try Escalation Handling as
671 defined in the I3C specification.
6.4 CCI (I2C) Target Addresses

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

674 All camera modules shall use their own Dynamic Address as assigned by the I3C Controller.

Confidential
23-May-2022
6.6 CCI Multi-Byte Registers

675 The description in this Section applies to both CCI (I2C) and CCI (I3C).
6.6.1 Overview
676 Peripherals contain a wide range of different register widths for various control and setup purposes. This
677 Specification supports the following register widths:
678 • 8-bit: Generic setup registers
679 • 16-bit: Parameters like line length, frame length, and exposure values
680 • 32-bit: High precision setup values
681 • 64-bit: For needs of future sensors
682 In general, the byte-oriented access protocols described in the previous sections provide an efficient means
683 to access multi-byte registers. However, the registers should reside in a byte-oriented address space, and the
684 address of a multi-byte register should be the address of its first byte. Thus, addresses of contiguous multi-
685 byte registers will not be contiguous. For example, a 32-bit register with its first byte at address 0x8000 can
686 be read by means of a sequential read of four bytes, starting at random address 0x8000. If there is an additional
687 4-byte register with its first byte at 0x8004, then it could then be accessed using a four-byte Sequential Read
688 from the Current Location protocol.
689 The motivation for a generalized multi-byte protocol (rather than fixing register widths at 16 bits) is
690 flexibility. The protocol described below provides a way of transferring 16-bit, 32-bit, or 64-bit values over
691 a 16-bit INDEX, 8-bit data, two-wire serial link while ensuring that the bytes of data transferred for a multi-
692 byte register value are always consistent (temporally coherent).
693 Using this protocol, a single CCI Message can contain one, two, or all of the different register widths used
694 within a device.
695 The MS byte of a multi-byte register shall be located at the lowest address, and the LS byte shall be located
696 at the highest address.
697 The address of the first byte of a multi-byte register is not necessarily related to register size (i.e., not required
698 to be an integer multiple of register size in bytes). Register address alignment represents an implementation
699 choice between processing-optimized vs. bandwidth-optimized organizations. There are no restrictions on
700 the number or mix of multi-byte registers within the available 64K by 8-bit INDEX space, with the exception
701 of certain rules for the valid locations for the MS bytes and LS bytes of registers.
702 Partial access to multi-byte registers is not allowed. A multi-byte register shall only be accessed by a single
703 sequential Message. When a multi-byte register is accessed, its bytes shall be accessed in ascending address
704 order (i.e. first byte is accessed first, second byte is accessed second, etc.).
705 When a multi-byte register is accessed, the following re-timing rules shall be followed:
706 • For a Write operation, the updating of the register shall be deferred to a time when the last bit of
707 the last byte has been received.
708 • For a Read operation, the value read shall reflect the status of all bytes at the time that the first bit
709 of the first byte was read.
710 Section 6.6.3 describes example re-timing behavior for multi-byte register accesses.
711 Figure 25 and Figure 26 illustrate that without re-timing, data could be corrupted.

Confidential
23-May-2022
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
TARGET
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]

712
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)
TARGET
S 0 A DATA=0x01 A DATA=0x02 A DATA=0x03 A DATA=0x04 A P
ADDRESS
0x01 0x02 0x03 0x04
DATA[31:0]

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

Confidential
23-May-2022
6.6.2 Transmission Byte Order for Multi-Byte Register Values

714 Figure 27, Figure 28, and Figure 29 illustrate the requirement that the first byte of a CCI Message shall
715 always be the MS byte of a multi-byte register, and the last byte of the CCI Message shall always be the LS
716 byte of the multi-byte register.
DATA[15:0]
TARGET SUB
S 0 A A DATA[15:8] A DATA[7:0] A P
ADDRESS ADDRESS
Index Value,
M
Index M Index M+1
717
Figure 27 Example 16-bit Register Write
Register Index
A/
A DATA A DATA A DATA A DATA
A
DATA[31:0]
718
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]
719
Figure 29 Example 64-bit Register Write (Address Not Shown)

Confidential
23-May-2022
6.6.3 Multi-Byte Register Protocol (Informative)

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

722 To ensure that the value read from a multi-byte register is consistent (i.e., that all of the transmitted bytes are
723 temporally coherent), the device can internally transfer the register contents into a temporary buffer at the
724 time when the register’s MS byte is read. The contents of the temporary buffer can then be sent out as a
725 sequence of bytes on the SDA line. Figure 30 and Figure 31 illustrate multi-byte register read operations.
726 The temporary buffer is always updated, except in the case of a read operation that is incremental within the
727 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
TARGET
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]

728
Figure 30 Example 16-bit Register Read

Confidential
23-May-2022
729 In this definition no distinction is made between a register being accessed incrementally via multiple separate
730 single-byte read Messages with no intervening data writes, vs. a register being accessed via a single multi-
731 location read Message. This protocol purely relates to the behavior of the INDEX value.

Confidential
23-May-2022
732 Examples of when the temporary buffer is updated include:

733 • When the MS byte of a register is accessed
734 • When the INDEX has crossed a multi-byte register boundary
735 • Successive single-byte reads from the same INDEX location
736 • When the INDEX value for the byte about to be read is ≤ the previous INDEX
737 Note that the values read back are only guaranteed to be consistent if the contents (bytes) of the multi-byte
738 register are accessed in an incremental manner.
739 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
TARGET
S 1 A DATA = 0xFC A DATA=0xFD A DATA=0xFE A DATA=0xFF A P
ADDRESS
0xFC 0xFD 0xFE 0xFF
DATA[31:0]

740
Figure 31 Example 32-bit Register Read

Confidential
23-May-2022
6.6.3.2 Writing Multi-Byte Registers

741 To ensure that the value written is consistent, the bytes of data from a multi-byte register are written into a
742 temporary buffer. Only after the LS byte of the register is written is the full multi-byte value transferred into
743 the internal register location.
744 Figure 32 and Figure 33 illustrate multi-byte register write operations.
745 CCI Messages that only write to the LS or MS byte of a multi-byte register are not allowed. Single byte
746 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
TARGET
ADDRESS
MS Data Byte LS Data Byte MS Data Byte LS Data Byte
0x01 0x02 0x03 0x04
DATA[15:0] DATA[15:0]

747

Confidential
23-May-2022

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
TARGET
ADDRESS
0x01 0x02 0x03 0x04
DATA[31:0]

748

Confidential
23-May-2022
6.7 CCI I/O Electrical and Timing Specifications

749 The CCI I/O stages electrical specifications (Table 8) and timing specifications (Table 9) conform to I2C
750 Fast-mode and Fast-mode Plus devices. Information presented in Table 8 is from [NXP01].
751 The CCI timings specified in Table 9 are illustrated in Figure 34.
752 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 V DD
is switched off

Confidential
23-May-2022
753 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
23-May-2022
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
754
Figure 34 CCI I/O Timing

Confidential
23-May-2022
7 Physical Layer
755 The CSI-2 specification shall always be used in combination with one or more MIPI physical layer
756 specifications, such as A-PHY [MIPI06], C-PHY [MIPI02], or D-PHY [MIPI01]. The CSI-2 specification
757 shall not be used in combination with non-MIPI physical layers, unless expressly authorized by the MIPI
758 Alliance Board of Directors. Any other use of the CSI-2 specification is strictly prohibited unless approved
759 in advance by the MIPI Alliance Board of Directors.
760 Note:
761 In this specification version, D-PHY “CIL-Mxxx” Lane type descriptors have been replaced with
762 “CIL-Pxxx” in anticipation of them being similarly updated in a forthcoming D-PHY specification.
7.1 D-PHY Physical Layer Option

763 The D-PHY physical layer for a CSI-2 implementation is typically composed of a number of unidirectional
764 data Lanes and one clock Lane. All CSI-2 transmitters and receivers implementing the D-PHY physical layer
765 shall support continuous clock behavior on the Clock Lane, and optionally may support non-continuous clock
766 behavior.
767 For continuous clock behavior the Clock Lane remains in high-speed mode, generating active clock signals
768 between the transmissions of data packets.
769 For non-continuous clock behavior the Clock Lane enters the LP-11 state between the transmissions of data
770 packets.
771 The minimum D-PHY physical layer requirement for a CSI-2 transmitter is:
772 • Data Lane Module: Unidirectional Primary, HS-TX, LP-TX and a CIL-PFEN function
773 • Clock Lane Module: Unidirectional Primary, HS-TX, LP-TX and a CIL-PCNN function
774 The minimum D-PHY physical layer requirement for a CSI-2 receiver is:
775 • Data Lane Module: Unidirectional Secondary, HS-RX, LP-RX, and a CIL-SFEN function
776 • Clock Lane Module: Unidirectional Secondary, HS-RX, LP-RX, and a CIL-SCNN function
777 All CSI-2 implementations supporting the D-PHY physical layer option shall support forward escape ULPS
778 on all D-PHY Data Lanes.
779 To enable higher data rates and higher number of lanes the physical layer described in [MIPI01] includes an
780 independent deskew mechanism in the Receive Data Lane Module. To facilitate deskew calibration at the
781 receiver the transmitter Data Lane Module provides a deskew sequence pattern.
782 Since deskew calibration is only valid at a given transmit frequency:
783 For initial calibration sequence the Transmitter shall be programmed with the desired frequency for
784 calibration. It will then transmit the deskew calibration pattern and the Receiver will autonomously detect
785 this pattern and tune the deskew function to achieve optimum performance.
786 For any transmitter frequency changes the deskew calibration shall be re-run.
787 Some transmitters and/or receivers may require deskew calibration to be rerun periodically and it is suggested
788 that it can be optimally done within vertical or frame blanking periods.
789 For low transmit frequencies or when a receiver described in [MIPI01] is paired with a previous version
790 transmitter not supporting the deskew calibration pattern the receiver may be instructed to bypass the deskew
791 mechanism.
792 The D-PHY v2.5 physical layer [MIPI01] provides both Alternate Low Power (ALP) Mode and Low Voltage
793 Low Power (LVLP) signaling, either of which may optionally replace the legacy Low Power State (LPS).
794 Use of ALP Mode or LVLP signaling can help alleviate current leakage and electrical overstress issues with
795 image sensors and applications processors. ALP Mode can also help achieve longer reach for CSI-2 imaging

Confidential
23-May-2022
796 interface channels, and is also central to the CSI-2 Unified Serial Link (USL) feature described in
797 Section 9.12. USL D-PHY support requirements are described in Section 7.3.1.
7.2 C-PHY Physical Layer Option

798 The C-PHY physical layer for a CSI-2 implementation is typically composed of one or more unidirectional
799 Lanes.
800 The minimum C-PHY physical layer requirement for a CSI-2 transmitter Lane module is:
801 • Unidirectional Primary, HS-TX, LP-TX and a CIL-PFEN function
802 • Support for Sync Word insertion during data payload transmission
803 The minimum C-PHY physical layer requirement for a CSI-2 receiver Lane module is:
804 • Unidirectional Secondary, HS-RX, LP-RX, and a CIL-SFEN function
805 • Support for Sync Word detection during data payload reception
806 All CSI-2 implementations supporting the C-PHY physical layer option shall support forward escape ULPS
807 on all C-PHY Lanes.
808 The C-PHY Physical Layer provides both Alternate Low Power (ALP) Mode and Low Voltage Low Power
809 (LVLP) signaling, either of which may optionally replace the legacy Low Power State (LPS). Use of ALP
810 Mode or LVLP signaling can help alleviate current leakage and electrical overstress issues with image sensors
811 and applications processors. ALP Mode (which replaces LVLP or legacy LP signaling through the use of
812 high-speed embedded codes) can also help achieve longer reach for CSI-2 imaging interface channels before
813 re-drivers and re-timers become necessary. ALP Mode is also central to the CSI-2 Unified Serial Link (USL)
814 feature described in Section 9.12. USL C-PHY support requirements are described in Section 7.3.2.

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

820 The D-PHY physical layer for a CSI-2 USL implementation is composed of one bidirectional data Lane (i.e.,
821 data Lane 1), zero or more unidirectional data Lanes, and one clock Lane. All CSI-2 transmitters and receivers
822 implementing the D-PHY physical layer for the USL feature shall support continuous clock behavior on the
823 clock Lane, and optionally may support non-continuous clock behavior.
824 For continuous clock behavior, the clock Lane remains in high-speed mode, generating active clock signals
825 between data packet transmissions.
826 For non-continuous clock behavior, the clock Lane may enter the Stop state between data packet
827 transmissions as determined by the image sensor and controlled by the host processor.
828 The minimum D-PHY LP/LVLP Mode physical layer requirement for a USL image sensor is:
829 • Clock Lane Module: Unidirectional Primary, HS-TX, LP-TX, and CIL-PCNN function
830 • Data Lane 1 Module: Bidirectional Primary, HS-TX, LP-TX, LP-RX, LP-CD, and CIL-PFAA
831 function; Escape Mode LPDT shall be supported in both the forward and reverse direction
832 • Data Lane n Module (for n > 1): Unidirectional Primary, HS-TX, LP-TX, and CIL-PFEN function
833 The minimum D-PHY LP/LVLP Mode physical layer requirement for a USL host is:
834 • Clock Lane Module: Unidirectional Secondary, HS-RX, LP-RX, and CIL-SCNN function
835 • Data Lane 1 Module: Bidirectional Secondary, HS-RX, LP-TX, LP-RX, LP-CD, and CIL-SFAA
837 • Data Lane n Module (for n > 1): Unidirectional Secondary, HS-RX, LP-RX, and CIL-SFEN
838 function
839 For USL implemented using D-PHY LP/LVLP Mode, forward direction Escape Mode LPDT transmissions
840 shall use data Lane 1 only, and all reverse direction transmissions shall only use data Lane 1 and LPDT. The
841 USL host shall be capable of receiving both LPDT and High-Speed (HS) transmissions. Note that
842 transmission bandwidth is substantially reduced when transmitting using LPDT.
843 The minimum D-PHY ALP Mode physical layer requirement for a USL image sensor is:
844 • Clock Lane Module: Unidirectional Primary, HS-TX and CIL-PCNN function
845 • Data Lane 1 Module: Bidirectional Primary, HS-TX, HS-RX, ALP-ED, and CIL-PREN function
846 (CIL-PREE with ALP-ULPS in both forward and reverse direction is recommended)
847 • Data Lane n Module (for n > 1): Unidirectional Primary, HS-TX and CIL-PFEN function
848 The minimum D-PHY ALP Mode physical layer requirement for a USL host is:
849 • Clock Lane Module: Unidirectional Secondary, HS-RX, ALP-ED, and CIL-SCNN function
850 • Data Lane 1 Module: Bidirectional Secondary, HS-TX, HS-RX, ALP-ED, and CIL-SREN
851 function (CIL-SREE with ALP-ULPS in both forward and reverse direction is recommended)
852 • Data Lane n Module (for n > 1): Unidirectional Secondary, HS-RX, ALP-ED, and CIL-SFEN
853 function
854 Note that D-PHY ALP Mode does not define a contention detection function for bidirectional Lane modules.
855 All USL implementations supporting the D-PHY physical layer option shall support forward direction ULPS
856 on all data Lanes. For data Lane 1, support for both reverse direction ULPS and the reverse direction ALP-
857 wake pulse transmission is recommended; see Section 9.12.5.6 and Section 9.12.5.8 for additional guidance.

Confidential
23-May-2022
7.3.2 C-PHY Support Requirements for USL Feature

858 The C-PHY physical layer for a CSI-2 USL implementation is composed of one bidirectional Lane (i.e., Lane
859 1) and zero or more unidirectional Lanes.
860 The minimum C-PHY LP/LVLP Mode physical layer requirement for a USL image sensor is:
861 • Lane 1 Module: Bidirectional Primary, HS-TX, LP-TX, LP-RX, LP-CD, and CIL-PFAA function;
862 Escape Mode LPDT shall be supported in both the forward and reverse direction
863 • Lane n Module (for n > 1): Unidirectional Primary, HS-TX, LP-TX, and CIL-PFEN function
864 The minimum C-PHY LP/LVLP Mode physical layer requirement for a USL host is:
865 • Lane 1 Module: Bidirectional Secondary, HS-RX, LP-TX, LP-RX, LP-CD, and CIL-SFAA
867 • Lane n Module (for n > 1): Unidirectional Secondary, HS-RX, LP-RX, and CIL-SFEN function
868 For USL implemented using C-PHY LP/LVLP Mode, forward direction Escape Mode LPDT transmissions
869 shall use Lane 1 only, and all reverse direction transmissions shall only use Lane 1 and LPDT. The USL host
870 shall be capable of receiving both LPDT and High-Speed (HS) transmissions. Note that transmission
871 bandwidth is substantially reduced when transmitting using LPDT.
872 The minimum C-PHY ALP Mode physical layer requirement for a USL image sensor is:
873 • Lane 1 Module: Bidirectional Primary, HS-TX, HS-RX, and CIL-PREN function (CIL-PREE
874 with ALP-ULPS in both forward and reverse direction is recommended)
875 • Lane n Module (for n > 1): Unidirectional Primary, HS-TX and CIL-PFEN function
876 The minimum C-PHY ALP Mode physical layer requirement for a USL host is:
877 • Lane 1 Module: Bidirectional Secondary, HS-TX, HS-RX, and CIL-SREN function (CIL-SREE
878 with ALP-ULPS in both forward and reverse direction is recommended)
879 • Lane n Module (for n > 1): Unidirectional Secondary, HS-RX and CIL-SFEN function
880 Note that C-PHY ALP Mode does not define a contention detection function for bidirectional Lane modules.
881 All CSI-2 USL implementations supporting the C-PHY physical layer option shall support forward direction
882 ULPS on all Lanes. For Lane 1, additional C-PHY ALP Mode support for reverse direction ULPS is
883 recommended; see Section 9.12.5.8 for additional guidance.

Confidential
23-May-2022
8 Multi-Lane Distribution and Merging

884 CSI-2 is a Lane-scalable specification. Applications requiring more bandwidth than that provided by one data
885 Lane, or those trying to avoid high clock rates, can expand the data path to a higher number of Lanes and
886 obtain approximately linear increases in peak bus bandwidth. The mapping between data at higher layers and
887 the serial bit or symbol stream is explicitly defined to ensure compatibility between host processors and
888 peripherals that make use of multiple data Lanes.
889 Conceptually, between the PHY and higher functional layers is a layer that handles multi-Lane
890 configurations. As shown in Figure 35 and Figure 36 for the D-PHY and C-PHY physical layer options,
891 respectively, the CSI-2 transmitter incorporates a Lane Distribution Function (LDF) which accepts a
892 sequence of packet bytes from the low level protocol layer and distributes them across N Lanes, where each
893 Lane is an independent unit of physical-layer logic (serializers, etc.) and transmission circuitry. Similarly, as
894 shown in Figure 37 and Figure 38 for the D-PHY and C-PHY physical layer options, respectively,the CSI-
895 2 receiver incorporates a Lane Merging Function (LMF) which collects incoming bytes from N Lanes and
896 consolidates (merges) them into complete packets to pass into the packet decomposer in the receiver’s low
897 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

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

Confidential
23-May-2022
899
Figure 36 Conceptual Overview of the Lane Distributor Function for C-PHY

Confidential
23-May-2022
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
900
Figure 37 Conceptual Overview of the Lane Merging Function for D-PHY

Confidential
23-May-2022
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 4 Byte 0 Byte 2 Byte 2N -4 Byte 2N -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
901
Figure 38 Conceptual Overview of the Lane Merging Function for C-PHY
902 The Lane distributor takes a transmission of arbitrary byte length, buffers up N*b bytes (where N = number
903 of Lanes and b = 1 or 2 for the D-PHY or C-PHY physical layer option, respectively), and then sends groups
904 of N*b bytes in parallel across N Lanes with each Lane receiving b bytes. Before sending data, all Lanes
905 perform the SoT sequence in parallel to indicate to their corresponding receiving units that the first byte of a
906 packet is beginning. After SoT, the Lanes send groups of successive bytes from the first packet in parallel,
907 following a round-robin process.

Confidential
23-May-2022
8.1 Lane Distribution for the D-PHY Physical Layer Option

908 Examples are shown in Figure 39, Figure 40, Figure 41, and Figure 42:
909 • 2-Lane system (Figure 39): byte 0 of the packet goes to Lane 1, byte 1 goes to Lane 2, byte 2 to
910 Lane 1, byte 3 goes to Lane 2, byte 4 goes to Lane 1, and so on.
911 • 3-Lane system (Figure 40): byte 0 of the packet goes to Lane 1, byte 1 goes to Lane 2, byte 2 to
912 Lane 3, byte 3 goes to Lane 1, byte 4 goes to Lane 2, and so on.
913 • N-Lane system (Figure 41): byte 0 of the packet goes to Lane 1, byte 1 goes to Lane 2, byte N-1
914 goes to Lane N, byte N goes to Lane 1, byte N+1 goes to Lane 2, and so on.
915 • N-lane system (Figure 42) with N>4 short packet (4 bytes) transmission: byte 0 of the packet goes
916 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
917 do not receive bytes and stay in LPS state.
918 At the end of the transmission, there may be “extra” bytes since the total byte count may not be an integer
919 multiple of the number of Lanes, N. One or more Lanes may send their last bytes before the others. The Lane
920 distributor, as it buffers up the final set of less-than-N bytes in parallel for sending to N data Lanes, de-asserts
921 its “valid data” signal into all Lanes for which there is no further data. For systems with more than 4 data
922 Lanes sending a short packet constituted of 4 bytes the Lanes which do not receive a byte for transmission
923 shall stay in LPS state.
924 Each D-PHY data Lane operates autonomously.
925 Although multiple Lanes all start simultaneously with parallel “start packet” codes, they may complete the
926 transaction at different times, sending “end packet” codes one cycle (byte) apart.
927 The N PHYs on the receiving end of the link collect bytes in parallel, and feed them into the Lane-merging
928 layer. This reconstitutes the original sequence of bytes in the transmission, which can then be partitioned into
929 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:
LPS – Low Power State SoT – Start of Transmission EoT – End of Transmission
930
Figure 39 Two Lane Multi-Lane Example for D-PHY

Confidential
23-May-2022
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:
931
Figure 40 Three Lane Multi-Lane Example for D-PHY

Confidential
23-May-2022
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:
932
Figure 41 N-Lane Multi-Lane Example for D-PHY

Confidential
23-May-2022
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:
933
Figure 42 N-Lane Multi-Lane Example for D-PHY Short Packet Transmission
8.2 Lane Distribution for the C-PHY Physical Layer Option

934 Examples are shown in Figure 43 and Figure 44:
935 • 2-Lane system (Figure 43): Bytes 1 and 0 of the packet are sent as a 16-bit word to the Lane 1
936 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
937 are sent to Lane 2, bytes 9 and 8 are sent to Lane 1, and so on.
938 • 3-Lane system (Figure 44): Bytes 1 and 0 of the packet are sent as a 16-bit word to the Lane 1
939 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
940 are sent to Lane 1, bytes 9 and 8 are sent to Lane 2, and so on.
941 Figure 45 illustrates normative behavior for an N-Lane system where N ≥ 1: bytes 1 and 0 of the packet are
942 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
943 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
944 to Lane N, where B is the total number of bytes in the packet.
945 For an N-Lane transmitter, the C-PHY module for Lane n (1 ≤ n ≤ N) shall transmit the following sequence
946 of {ms byte : ls byte} byte pairs from a B-byte packet generated by the low level protocol layer: {Byte
947 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.
948 The low level protocol shall guarantee that B is an integer multiple of 2N.
949 That is, at the end of the packet transmission, there shall be no “extra” bytes since the total byte count is
950 always an even multiple of the number of Lanes, N. The Lane distributor, after sending the final set of 2N
951 bytes in parallel to the N Lanes, simultaneously de-asserts its “valid data” signal to all Lanes, signaling to
952 each C-PHY Lane module that it may start its EoT sequence.
953 Each C-PHY Lane module operates autonomously, but packet data transmission starts and stops at the same
954 time on all Lanes.
955 The N C-PHY receiver modules on the receiving end of the link collect byte pairs in parallel, and feed them
956 into the Lane-merging layer. This reconstitutes the original sequence of bytes in the transmission, which can
957 then be partitioned into individual packets for the packet decoder layers.

Confidential
23-May-2022
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:
958
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:
959
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:
960
Figure 45 General N-Lane Multi-Lane Distribution for C-PHY

Confidential
23-May-2022
8.3 Multi-Lane Interoperability

961 The Lane distribution and merging layers shall be reconfigurable via the Camera Control Interface when
962 more than one data Lane is used.
963 An "N" data Lane receiver shall be connected with an "M" data Lane transmitter, by CCI configuration of
964 the Lane distribution and merging layers within the CSI-2 transmitter and receiver when more than one data
965 Lane is used. Thus, if M ≤ N a receiver with N data Lanes shall work with transmitters with M data Lanes.
966 Likewise, if M ≥ N a transmitter with M Lanes shall work with receivers with N data Lanes. Transmitter
967 Lanes 1 to M shall be connected to the receiver Lanes 1 to N.
968 Two cases:
969 • If M ≤ N then there is no loss of performance – the receiver has sufficient data Lanes to match the
970 transmitter (Figure 46 and Figure 47).
971 • If M > N then there may be a loss of performance (e.g. frame rate) as the receiver has fewer data
972 Lanes than the transmitter (Figure 48 and Figure 49).
973 • Note that while the examples shown are for the D-PHY physical layer option, the C-PHY physical
974 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
975
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
976
Figure 47 M-Lane Transmitter and N-Lane Receiver Example (M<N) for D-PHY

Confidential
23-May-2022
M lane 1 lane

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

Byte Byte
Clock Clock
977
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
978
Figure 49 M-Lane Transmitter and N-Lane Receiver Example (N<M) for D-PHY

Confidential
23-May-2022
8.3.1 C-PHY Lane Deskew

979 The PPI definition in the C-PHY Specification [MIPI02] defines one RxWordClkHS per Lane, and does not
980 address the use of a common receive RxWordClkHS for all Lanes within a Link. Figure 50 shows a
981 mechanism for clocking data from the elastic buffers, in order to align (Deskew) all RxDataHS to one
982 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_2[15:0]
Lane
Lane 0
2
Elast Merging Internal
Data
Decoder
RxWordClkHS_2 Store Function Logic
•••
Clk RxDataHS_1[15:0] Elast

Lane 0
1 Data
Decoder
RxWordClkHS_1 Store
Elast Store Read Clock
983
Figure 50 Example of Digital Logic to Align All RxDataHS

Confidential
23-May-2022
9 Low Level Protocol

984 The Low Level Protocol (LLP) is a byte orientated, packet based protocol that supports the transport of
985 arbitrary data using Short and Long packet formats. For simplicity, all examples in this section are single
986 Lane configurations unless specified otherwise.
987 Basic Low Level Protocol Features:
988 • Transport of arbitrary data (Payload independent)
989 • 8-bit word size
990 • Support for up to sixteen interleaved virtual channels on the same D-PHY Link, or up to 32
991 interleaved virtual channels on the same C-PHY Link
992 • Special packets for frame start, frame end, line start and line end information
993 • Descriptor for the type, pixel depth and format of the Application Specific Payload data
994 • 16-bit Checksum Code for error detection.
995 • 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)
996
ST – Start of Transmission
Figure 51 Low Level Protocol Packet Overview

Confidential
23-May-2022
9.1 Low Level Protocol Packet Format

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

1002 Figure 52 shows the structure of the Low Level Protocol Long Packet for the D-PHY physical layer option.
1003 A Long Packet shall be identified by Data Types 0x10 to 0x38. See Table 10 for a description of the Data
1004 Types. A Long Packet for the D-PHY physical layer option shall consist of three elements: a 32-bit Packet
1005 Header (PH), an application specific Data Payload with a variable number of 8-bit data words, and a 16-bit
1006 Packet Footer (PF). The Packet Header is further composed of four elements: an 8-bit Data Identifier, a 16-
1007 bit Word Count field, a 2-bit Virtual Channel Extension field, and a 6-bit ECC. The Packet footer has one
1008 element, a 16-bit checksum (CRC). See Section 9.2 through Section 9.5 for further descriptions of the packet
1009 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-3
Data WC-2
Data WC-4
Data WC-1
Checksum
Data ID
Data 0
Data 3
Data 1
Data 2
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)
1010
Figure 52 Long Packet Structure for D-PHY Physical Layer Option

Confidential
23-May-2022
1011 Figure 53 shows the Long Packet structure for the C-PHY physical layer option; it shall consist of four
1012 elements: a Packet Header (PH), an application specific Data Payload with a variable number of 8-bit data
1013 words, a 16-bit Packet Footer (PF), and zero or more Filler bytes (FILLER). The Packet Header is 6N x 16-
1014 bits long, where N is the number of C-PHY physical layer Lanes. As shown in Figure 53, the Packet Header
1015 consists of two identical 6N-byte halves, where each half consists of N sequential copies of each of the
1016 following fields: a 16-bit field containing five Reserved bits, a 3-bit Virtual Channel Extension (VCX) field,
1017 and the 8-bit Data Identifier (DI); the 16-bit Packet Data Word Count (WC); and a 16-bit Packet Header
1018 checksum (PH-CRC) which is computed over the previous four bytes. The value of each Reserved bit shall
1019 be zero. The Packet Footer consists of a 16-bit checksum (CRC) computed over the Packet Data using the
1020 same CRC polynomial as the Packet Header CRC and the Packet Footer used in the D-PHY physical layer
1021 option. Packet Filler bytes are inserted after the Packet Footer, if needed, to ensure that the Packet Footer
1022 ends on a 16-bit word boundary and that each C-PHY physical layer Lane transports the same number of 16-
1023 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
1024 16-bit words; FC may be 0.
Figure 53 Long Packet Structure for C-PHY Physical Layer Option

Confidential
23-May-2022
1025 As shown in Figure 54, the Packet Header structure depicted in Figure 53 effectively results in the C-PHY
1026 Lane Distributor broadcasting the same six 16-bit words to each of N Lanes. Furthermore, the six words per
1027 Lane are split into two identical three-word groups which are separated by a mandatory C-PHY Sync Word
1028 as described in [MIPI02]. The Sync Word is inserted by the C-PHY physical layer in response to a CSI-2
1029 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 Reserved VCX Word Count Word Count Checksum Checksum Data ID Reserved VCX Word Count Word Count Checksum Checksum
LANE 1: (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 Reserved VCX Word Count Word Count Checksum Checksum Data ID Reserved VCX Word Count Word Count Checksum Checksum
LANE N: (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
1030 To Lane N C-PHY TX To Lane N C-PHY TX
Figure 54 Packet Header Lane Distribution for C-PHY Physical Layer Option
1031 For both physical layer options, the 8-bit Data Identifier field defines the 2-bit Virtual Channel (VC) and the
1032 Data Type for the application specific payload data. The Virtual Channel Extension (VCX) field is also
1033 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
1034 VCX fields comprise the 4- or 5-bit Virtual Channel Identifier field which determines the Virtual Channel
1035 number associated with the packet (see Section 9.3).
1036 For both physical layer options, the 16-bit Word Count (WC) field defines the number of 8-bit data words in
1037 the Data Payload between the end of the Packet Header and the start of the Packet Footer. No Packet Header,
1038 Packet Footer, or Packet Filler bytes shall be included in the Word Count.
1039 For the D-PHY physical layer option, the 6-bit Error Correction Code (ECC) allows single-bit errors to be
1040 corrected and 2-bit errors to be detected in the Packet Header. This includes the Data Identifier, Word Count,
1041 and Virtual Channel Extension field values.
1042 The ECC field is not used by the C-PHY physical layer option because a single symbol error on a C-PHY
1043 physical link can cause multiple bit errors in the received CSI-2 Packet Header, rendering an ECC ineffective.
1044 Instead, a CSI-2 protocol transmitter for the C-PHY physical layer option computes a 16-bit CRC over the
1045 four bytes composing the Reserved, Virtual Channel Extension, Data Identifier, and Word Count Packet
1046 Header fields and then transmits multiple copies of all these fields, including the CRC, to facilitate their
1047 recovery by the CSI-2 protocol receiver in the event of one or more C-PHY physical link errors. The multiple
1048 Sync Words inserted into the Packet Header by the C-PHY physical layer (as shown in Figure 54) also
1049 facilitate Packet Header data recovery by enabling the C-PHY receiver to recover from lost symbol clocks;
1050 see [MIPI02] for further information about the C-PHY Sync Word and symbol clock recovery.
1051 For both physical layer options, the CSI-2 receiver reads the next WC 8-bit data words of the Data Payload
1052 following the Packet Header. While reading the Data Payload the receiver shall not look for any embedded
1053 sync codes. Therefore, there are no limitations on the value of an 8-bit payload data word. In the generic case,
1054 the length of the Data Payload shall always be a multiple of 8-bit data words. In addition, each Data Type
1055 may impose additional restrictions on the length of the Data Payload, e.g. require a multiple of four bytes.
1056 For both physical layer options, once the CSI-2 receiver has read the Data Payload, it then reads the 16-bit
1057 checksum (CRC) in the Packet Footer and compares it against its own calculated checksum to determine if
1058 any Data Payload errors have occurred.
1059 Filler bytes are only inserted by the CSI-2 transmitter’s low level protocol layer in conjunction with the
1060 C-PHY physical layer option. The value of any Filler byte shall be zero. If the Packet Data Word Count (WC)
1061 is an odd number (i.e. LSB is “1”), the CSI-2 transmitter shall insert one Packet Filler byte after the Packet
1062 Footer to ensure that the Packet Footer ends on a 16-bit word boundary. The CSI-2 transmitter shall also

Confidential
23-May-2022
1063 insert additional Filler bytes, if needed, to ensure that each C-PHY Lane transports the same number of 16-
1064 bit words. The latter rules require the total number of Filler bytes, FC, to be greater than or equal to (WC
1065 mod 2) + {{N - (([WC + 2 + (WC mod 2)] / 2) mod N)} mod N} * 2, where N is the number of Lanes. Note
1066 that it is possible for FC to be zero.
1067 Figure 55 illustrates the Lane distribution of the minimal number of Filler bytes required for packets of
1068 various lengths transmitted over three C-PHY Lanes. The total number of Filler bytes required per packet
1069 ranges from 0 to 5, depending on the value of the Packet Data Word Count (WC). In general, the minimal
1070 number of Filler bytes required per packet ranges from 0 to 2N-1 for an N-Lane C-PHY system.
1071 For the D-PHY physical layer option, the CSI-2 Lane Distributor function shall pass each byte to the physical
1072 layer which then serially transmits it least significant bit first.
1073 For the C-PHY physical layer option, the Lane Distributor function shall group each pair of consecutive bytes
1074 2n and 2n+1 (for n ≥ 0) received from the Low Level Protocol into a 16-bit word (whose least significant
1075 byte is byte 2n) and then pass this word to a physical layer Lane module. The C-PHY Lane module maps
1076 each 16-bit word into a 7-symbol word which it then serially transmits least significant symbol first.
1077 For both physical layer options, payload data may be presented to the Lane Distributor function in any byte
1078 order restricted only by data format requirements. Multi-byte protocol elements such as Word Count,
1079 Checksum and the Short packet 16-bit Data Field shall be presented to the Lane Distributor function least
1080 significant byte first.
1081 After the EoT sequence the receiver begins looking for the next SoT sequence.

Confidential
23-May-2022
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
SYN – 7-Symbol Sync Word PH – Packet Header (6 Bytes) (2 Bytes)
1082
Figure 55 Minimal Filler Byte Insertion Requirements for Three Lane C-PHY

Confidential
23-May-2022
9.1.2 Low Level Protocol Short Packet Format

1083 Figure 56 and Figure 57 show the Low Level Protocol Short Packet structures for the D-PHY and C-PHY
1084 physical layer options, respectively. For each option, the Short Packet structure matches the Packet Header
1085 of the corresponding Low Level Protocol Long Packet structure with the exception that the Packet Header
1086 Word Count (WC) field shall be replaced by the Short Packet Data Field. A Short Packet shall be identified
1087 by Data Types 0x00 to 0x0F. See Table 10 for a description of the Data Types. A Short Packet shall contain
1088 only a Packet Header; neither Packet Footer nor Packet Filler bytes shall be present.
1089 For Frame Synchronization Data Types the Short Packet Data Field shall be the frame number. For Line
1090 Synchronization Data Types the Short Packet Data Field shall be the line number. See Table 13 for a
1091 description of the Frame and Line synchronization Data Types.
1092 For Generic Short Packet Data Types the content of the Short Packet Data Field shall be user defined.
1093 For the D-PHY physical layer option, the Error Correction Code (ECC) field allows single-bit errors to be
1094 corrected and 2-bit errors to be detected in the Short Packet. For the C-PHY physical layer option, the 16-bit
1095 Checksum (CRC) allows one or more bit errors to be detected in the Short Packet but does not support error
1096 correction; the latter is facilitated by transmitting multiple copies of the various Short Packet fields and by
1097 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

Data Type (DT) = 0x00 – 0x0F
1098
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)
1099
Figure 57 Short Packet Structure for C-PHY Physical Layer Option

Confidential
23-May-2022
9.2 Data Identifier (DI)

1100 The Data Identifier byte contains the Virtual Channel (VC) and Data Type (DT) fields as illustrated in Figure
1101 58. The Virtual Channel field is contained in the two MS bits of the Data Identifier Byte. The Data Type field
1102 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)
1103
Figure 58 Data Identifier Byte
9.3 Virtual Channel Identifier

1104 The purpose of the 4- or 5-bit Virtual Channel Identifier is to provide a means for designating separate logical
1105 channels for different data flows that are interleaved in the data stream.
1106 As shown in Figure 59, the least significant two bits of the Virtual Channel Identifier shall be copied from
1107 the 2-bit VC field, and the most significant two or three bits shall be copied from the VCX field. The VCX
1108 field is located in the Packet Header as shown in Figure 52 and Figure 53, respectively, for the D-PHY and
1109 C-PHY physical layer options. The Receiver shall extract the Virtual Channel Identifier from incoming
1110 Packet Headers and de-multiplex the interleaved video data streams to their appropriate channel. A maximum
1111 of N data streams is supported, where N = 16 or 32, respectively, for the D-PHY or C-PHY physical layer
1112 option; valid channel identifiers are 0 to N-1. The Virtual Channel Identifiers in peripherals should be
1113 programmable to allow the host processor to control how the data streams are de-multiplexed.
1114 Host processors receiving packets from peripherals conforming to previous CSI-2 Specification versions not
1115 supporting the VCX field shall treat the received value of VCX in all such packets as zero. Similarly,
1116 peripherals conforming to this CSI-2 Specification version shall set the VCX field to zero in all packets
1117 transmitted to host processors conforming with previous versions not supporting the VCX field. The means
1118 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
1119
Figure 59 Logical Channel Block Diagram (Receiver)

Confidential
23-May-2022
1120 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)
1121
EoT – End of Transmission
Figure 60 Interleaved Video Data Streams Examples

Confidential
23-May-2022
9.4 Data Type (DT)

1122 The Data Type value specifies the format and content of the payload data. A maximum of sixty-four data
1123 types are supported.
1124 There are eight different data type classes as shown in Table 10. Within each class there are up to nine
1125 different data type definitions. The first two classes denote short packet data types. The remaining six classes
1126 denote long packet data types.
1127 For details on the short packet data type classes refer to Section 9.8.
1128 For details on the five long packet data type classes refer to Section 11.
1129 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 0x25 RGB Data
0x26 to 0x2F RAW Data
0x30 to 0x37 User Defined Byte-based Data
0x38 USL Commands (See Section 9.12)
0x39 Reserved for MIPI CSE Specification [MIPI05]
0x3A to 0x3D Reserved for future use
0x3E Service Extension Packet as described in MIPI CSE Specification [MIPI05]
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
23-May-2022
9.5 Packet Header Error Correction Code for D-PHY Physical Layer
Option
1130 The correct interpretation of the Data Identifier, Word Count, and Virtual Channel Extension fields is vital to
1131 the packet structure. The 6-bit Packet Header Error Correction Code (ECC) allows single-bit errors in the
1132 latter fields to be corrected, and two-bit errors to be detected for the D-PHY physical layer option; the ECC
1133 is not available for the C-PHY physical layer option. A 26-bit subset of the Hamming-Modified code
1134 described in Section 9.5.2 shall be used. The error state results of ECC decoding shall be available at the
1135 Application layer in the receiver.
1136 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])
1137 to D[15:8], the Word Count MS Byte (WC[15:8]) to D[23:16], and the Virtual Channel Extension (VCX)
1138 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)
VCX
LPS SoT
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
1139
Figure 61 26-bit ECC Generation Example
9.5.1 General Hamming Code Applied to Packet Header

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

Confidential
23-May-2022
1149 G=[I|A]
1150 The packet header plus the ECC code can be obtained as: PH = p*G where p represents the header (26 or 64
1151 bits) and G is the corresponding generator matrix.
1152 Validating the received code word r, involves multiplying it by a parity check to form s, the syndrome or
1153 parity check vector: s = H*PH where PH is the received packet header and H is the parity check matrix:
1154 H = [ AT | I ]
1155 If all elements of s are zero, the code word was received correctly. If s contains non-zero elements, then at
1156 least one error is present. If a single bit error is encountered then the syndrome s is one of the elements of H
1157 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
1158 syndrome will be one of the elements on I, else it will be the data bit identified by the position of the syndrome
1159 in AT.
9.5.2 Hamming-Modified Code

1160 The error correcting code used is a 7+1 bits Hamming-modified code (72,64) and the subset of it is 5+1 bits
1161 or (32,26). Hamming codes use parity to correct one error or detect two errors, but they are not capable of
1162 doing both simultaneously, thus one extra parity bit is added. The code used allows the same 6-bit syndromes
1163 to correct the first 26-bits of a 64-bit sequence. To specify a compact encoding of parity and decoding of
1164 syndromes, the matrix shown in Table 11 is used:
1165 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
1166 Each cell in the matrix represents a syndrome, and the first 26 cells (the orange cells) use the first three or
1167 five bits to build the syndrome. Each syndrome in the matrix is MSB left aligned:
1168 e.g. 0x07 = 0b0000_0111 = P7 P6 P5 P4 P3 P2 P1 P0
1169 The top row defines the three LSB of data position bit, and the left column defines the three MSB of data
1170 position bit (there are 64-bit positions in total).
1171 e.g. 37th bit position is encoded 0b100_101 and has the syndrome 0x68.

Confidential
23-May-2022
1172 To derive the parity P0 for 26-bits, the P0’s in the orange cells will define whether the corresponding bit
1173 position is used in P0 parity or not.
1174 e.g. P024-bits = D0^D1^D2^D4^D5^D7^D10^D11^D13^D16^D20^D21^D22^D23^D24
1175 Similarly, to derive the parity P0 for 64-bits, all P0’s in Table 12 will define the corresponding bit positions
1176 to be used.
1177 To correct a single data bit error, the syndrome must be one of the syndromes in Table 11. These syndromes
1178 identify the bit position in error. The syndrome is calculated as:
1179 S = PSEND ^ PRECEIVED, where PSEND is the 8/6-bit ECC field in the header and PRECEIVED is the
1180 calculated parity of the received header.
1181 Table 12 represents the same information as the matrix in Table 11, organized so as to provide better insight
1182 into the way in which parity bits are formed out of data bits. The orange area of the table is used to form the
1183 ECC needed to protect a 26-bit header, whereas the whole table must be used to protect a 64-bit header.
1184 Previous CSI-2 specification versions not supporting the Virtual Channel Extension (VCX) field utilize a 30-
1185 bit Hamming-modified code word with 24 data bits and 5+1 parity bits based on the first 24 bit positions of
1186 Table 12 [i.e. a (30,24) ECC]. Packet Header bits 24 and 25 are set to zero by transmitters, and ignored by
1187 receivers conforming to such Specifications.
1188 When receiving Packet Headers with a (30,24) ECC, receivers conforming to this CSI-2 Specification version
1189 shall ignore the contents of bits 24 and 25 in such Packet Headers. The intent is for such receivers to ignore
1190 any errors occurring at these bit positions, in order to match the behavior of previous receivers. (See Section
1191 9.5.4 for implementation recommendations.)

Confidential
23-May-2022
1192 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
23-May-2022
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
23-May-2022
9.5.3 ECC Generation on TX Side

1193 This is an informative section.
1194 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 Byte Byte Byte Byte Byte Byte Byte Byte
(8 Bits)
7 6 5 4 3 2 1 0
Parity Generator
1195
Figure 62 64-bit ECC Generation on TX Side
1196 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
1197
Figure 63 26-bit ECC Generation on TX Side
1198 The parity generators are based on Table 12.
1199 e.g. P326-bit = D1^D2^D3^D7^D8^D9^D13^D14^D15^D19^D20^D21^D23^D24^D25
1200 For backwards-compatibility, transmitters conforming to this CSI-2 Specification version should always set
1201 Packet Header bits 24 and 25 (the VCX field) to zero in any packets sent to receivers conforming to previous
1202 CSI-2 Specification versions incorporating a (30,24) ECC.

Confidential
23-May-2022
9.5.4 Applying ECC on RX Side (Informative)

1203 Applying ECC on RX side involves generating a new ECC for the received Packet Header, computing the
1204 syndrome using the new ECC and the received ECC, decoding the syndrome to find if a single-error has
1205 occurred, and if so, correcting it. Figure 64 depicts ECC processing for 64 received Packet Header data bits,
1206 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
1207
Figure 64 64-bit ECC on RX Side Including Error Correction
1208 Decoding the syndrome has four possible outcomes:

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

Confidential
23-May-2022
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
Header Packet 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
1224
Figure 65 26-bit ECC on RX Side Including Error Correction

Confidential
23-May-2022
9.6 Checksum Generation

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

1233
Figure 66 Checksum Transmission Byte Order
1234 When computed over the Packet Data words of a Long Packet, the 16-bit checksum sequence is transmitted
1235 as part of the Packet Footer. When the Word Count is zero, the CRC shall be 0xFFFF. When computed over
1236 the Reserved, Virtual Channel Extension, Data Identifier, and Word Count fields of a Packet Header for the
1237 C-PHY physical layer option, the 16-bit checksum sequence is transmitted as part of the Packet Header CRC
1238 (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)
1239
Figure 67 Checksum Generation for Long Packet Payload Data
1240 The definition of a serial CRC implementation is presented in Figure 68. The CRC implementation shall be
1241 functionally equivalent with the C code presented in Figure 69. The CRC shift register is initialized to
1242 0xFFFF at the beginning of each packet. Note that for the C-PHY physical layer option, if the same circuitry
1243 is used to compute both the Packet Header and Packet Footer CRC, the CRC shift register shall be initialized
1244 twice per packet, i.e. once at the beginning of the packet and then again following the computation of the
1245 Packet Header CRC. After all payload data has passed through the CRC circuitry, the CRC circuitry contains
1246 the checksum. The 16-bit checksum produced by the C code in Figure 69 equals the final contents of the
1247 C[15:0] shift register shown in Figure 68. The checksum is then transmitted by the CSI-2 physical layer to
1248 the CSI-2 receiver to verify that no errors have occurred in the transmission.

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

1249
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);
1250
}
Figure 69 16-bit CRC Software Implementation Example
1251 Beginning with index 0, the contents of the input data array in Figure 69 are given by WC 8-bit payload data
1252 words for packet data CRC computations and by the four 8-bit [Reserved, VCX], Data Identifier, WC (LS
1253 byte), and WC (MS byte) fields for packet header CRC computations.
1254
1255 CRC Computation Examples:

1256 Input Data Bytes:
1257 FF 00 00 02 B9 DC F3 72 BB D4 B8 5A C8 75 C2 7C 81 F8 05 DF FF 00 00 01
1258 Checksum LS byte and MS byte:
1259 F0 00
1260
1261 Input Data Bytes:
1262 FF 00 00 00 1E F0 1E C7 4F 82 78 C5 82 E0 8C 70 D2 3C 78 E9 FF 00 00 01
1263 Checksum LS byte and MS byte:
1264 69 E5

Confidential
23-May-2022
9.7 Packet Spacing

1265 All CSI-2 implementations shall support a transition into and out of the Low Power State (LPS) between
1266 Low Level Protocol packets; however, implementations may optionally remain in the High-Speed State
1267 between packets as described in Section 9.11. Figure 70 illustrates the packet spacing with the LPS.
1268 The packet spacing illustrated in Figure 70 does not have to be a multiple of 8-bit data words, as the receiver
1269 will resynchronize to the correct byte boundary during the SoT sequence prior to the Packet Header of the
1270 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)
1271
ET – End of Transmission SP – Short Packet
Figure 70 Packet Spacing

Confidential
23-May-2022
9.8 Synchronization Short Packet Data Type Codes

1272 Short Packet Data Types shall be transmitted using only the Short Packet format. See Section 9.1.2 for a
1273 format description.
1274 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

1275 Each image frame shall begin with a Frame Start (FS) Packet containing the Frame Start Code. The FS Packet
1276 shall be followed by one or more long packets containing image data and zero or more short packets
1277 containing synchronization codes. Each image frame shall end with a Frame End (FE) Packet containing the
1278 Frame End Code. See Table 13 for a description of the synchronization code data types.
1279 For FS and FE synchronization packets the Short Packet Data Field shall contain a 16-bit frame number. This
1280 frame number shall be the same for the FS and FE synchronization packets corresponding to a given frame.
1281 The 16-bit frame number, when used, shall be non-zero to distinguish it from the use-case where frame
1282 number is inoperative and remains set to zero.
1283 The behavior of the 16-bit frame number shall be one of the following:
1284 • Frame number is always zero – frame number is inoperative.
1285 • Frame number increments by 1 or 2 for every FS packet with the same Virtual Channel and is
1286 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,
1287 1, 3, 4. Frame number may be incremented by 2 only when an image frame is masked (i.e. not
1288 transmitted) due to corruption. To accommodate such cases, increments by 1 or 2 may be freely
1289 intermixed within a sequence of frame numbers as needed.

Confidential
23-May-2022
9.8.2 Line Synchronization Packets

1290 Line synchronization short packets are optional on a per-image-frame basis. If an image frame includes Line
1291 Start (LS) and Line End (LE) line synchronization short packets with one long packet having a given data
1292 type and virtual channel number, then it shall include LS and LE short packets with all long packets having
1293 that same data type and virtual channel number within the same image frame.
1294 For LS and LE synchronization packets, the Short Packet Data Field shall contain a 16-bit line number. This
1295 line number shall be the same for the LS and LE packets corresponding to a given line. Line numbers are
1296 logical line numbers and are not necessarily equal to the physical line numbers.
1297 The 16-bit line number, when used, shall be non-zero to distinguish it from the case where line number is
1298 inoperative and remains set to zero.
1299 The behavior of the 16-bit line number within the same Data Type and Virtual Channel shall be one of the
1300 following.
1301 Either:
1302 1. Line number is always zero – line number is inoperative.
1303 Or:
1304 2. Line number increments by one for every LS packet within the same Virtual Channel and the same
1305 Data Type. The line number is periodically reset to one for the first LS packet after a FS packet.
1306 The intended usage is for progressive scan (non- interlaced) video data streams. The line number
1307 must be a non-zero value.
1308 Or:
1309 3. Line number increments by the same arbitrary step value greater than one for every LS packet
1310 within the same Virtual Channel and the same Data Type. The line number is periodically reset to
1311 a non-zero arbitrary start value for the first LS packet after a FS packet. The arbitrary start value
1312 may be different between successive frames. The intended usage is for interlaced video data
1313 streams.
1314 Figure 71 contains examples for the use of optional LS/LE packets within an interlaced frame with pixel
1315 data and additional embedded types. The Figure illustrates the use cases:
1316 1. VC0 DT2 Interlaced frame with line counting incrementing by two. Frame1 starting at 1 and
1317 Frame2 starting at 2.
1318 2. VC0 DT1 Progressive scan frame with line counting.
1319 3. VC0 DT4 Progressive scan frame with non-operative line counting.
1320 4. VC0 DT3 No LS/LE operation.

Confidential
23-May-2022
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
1321
Figure 71 Example Interlaced Frame Using LS/LE Short Packet and Line Counting

Confidential
23-May-2022
9.9 Generic Short Packet Data Type Codes

1322 Table 14 lists the Generic Short Packet Data Types.
1323 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
1324 The intention of the Generic Short Packet Data Types is to provide a mechanism for including timing
1325 information for the opening/closing of shutters, triggering of flashes, etc., within the data stream. The intent
1326 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
1327 value from the transmitter to application layer in the receiver. The CSI-2 receiver shall pass the data type
1328 value and the associated 16-bit data value to the application layer.

Confidential
23-May-2022
9.10 Packet Spacing Examples Using the Low Power State

1329 Packets discussed in this section are separated by an EoT, LPS, SoT sequence as defined in [MIPI01] for the
1330 D-PHY physical layer option and [MIPI02] for the C-PHY physical layer option.
1331 Figure 72 and Figure 73 contain examples of data frames composed of multiple packets and a single packet,
1332 respectively.
1333 Note that the VVALID, HVALID and DVALID signals in the figures in this section are only concepts to help
1334 illustrate the behavior of the frame start/end and line start/end packets. The VVALID, HVALID and DVALID
1335 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
1336
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:
1337
Figure 73 Single Packet Example

Confidential
23-May-2022
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:
1338
Figure 74 Line and Frame Blanking Definitions
1339 The period between the end of the Packet Footer (or the Packet Filler, if present) of one long packet and the
1340 Packet Header of the next long packet is called the Line Blanking Period.
1341 The period between the Frame End packet in frame N and the Frame Start packet in frame N+1 is called the
1342 Frame Blanking Period (Figure 74).
1343 The Line Blanking Period is not fixed and may vary in length. The receiver should be able to cope with a
1344 near zero Line Blanking Period as defined by the minimum inter-packet spacing defined in [MIPI01] or
1345 [MIPI02], as appropriate. The transmitter defines the minimum time for the Frame Blanking Period. The
1346 Frame Blanking Period duration should be programmable in the transmitter.
1347 Frame Start and Frame End packets shall be used.
1348 Recommendations (informative) for frame start and end packet spacing:
1349 • The Frame Start packet to first data packet spacing should be as close as possible to the minimum
1350 packet spacing
1351 • The last data packet to Frame End packet spacing should be as close as possible to the minimum
1352 packet spacing
1353 The intention is to ensure that the Frame Start and Frame End packets accurately denote the start and end of
1354 a frame of image data. A valid exception is when the positions of the Frame Start and Frame End packets are
1355 being used to convey pixel level accurate vertical synchronization timing information.
1356 The positions of the Frame Start and Frame End packets can be varied within the Frame Blanking Period in
1357 order to provide pixel level accurate vertical synchronization timing information. See Figure 75.
1358 If pixel level accurate horizontal synchronization timing information is required, Line Start and Line End
1359 packets should be used to achieve it.
1360 The positions of the Line Start and Line End packets, if present, can be varied within the Line Blanking
1361 Period in order to provide pixel accurate horizontal synchronization timing information. See Figure 76.

Confidential
23-May-2022
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
1362
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

Packet Packet Packet
1363
Figure 76 Horizontal Sync Example

Confidential
23-May-2022
9.11 Latency Reduction and Transport Efficiency (LRTE)

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

1369 As per [MIPI01] for the D-PHY physical layer option, and [MIPI02] for the C-PHY physical layer option,
1370 CSI-2 Short Packets and Long Packets are separated by EoT, LPS, and SoT packet delimiters. Advanced
1371 imaging applications, PDAF (Phase Detection Auto Focus), Sensor Aggregation, and Machine Vision can
1372 substantially benefit from the effective speed increases produced by reducing the overhead of these
1373 delimiters.
1374 As shown in Figure 77, interpacket latency reduction may be used to replace legacy EoT, LPS, and SoT
1375 packet delimiters with a more Efficient Packet Delimiter (EPD) signaling mechanism that avoids the need
1376 for HS-LPS-HS transitions. An EPD consists of PHY layer and/or protocol layer elements. The PHY-
1377 generated EPD element is referred to as “Packet Delimiter Quick” (PDQ). Protocol-generated EPD elements
1378 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

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

Confidential
23-May-2022
9.11.1.1 EPD for C-PHY Physical Layer Option

1384 The EPD for the C-PHY physical layer option consists of one or more instances of the PHY-generated and
1385 PHY-consumed 7-UI Sync Word for the Packet Delimiter Quick (PDQ) signaling, optionally preceded by
1386 CSI-2 protocol-generated and protocol-consumed Spacer Words. The PDQ is generated and consumed by the
1387 transmitter and receiver physical layers, respectively, and as a result serves as a robust CSI-2 packet delimiter.
1388 An image sensor should reuse “TxSendSyncHS” at the PPI in order to generate the PDQ control code by the
1389 C-PHY transmitter. Upon reception of the PDQ control code by the C-PHY receiver, an application processor
1390 should reuse “RxSyncHS” at the PPI in order to notify the CSI-2 protocol layer. The duration of the 7-UI
1391 PDQ control code is directly proportional to the C-PHY Symbol rate.
1392 The EPD for C-PHY receivers can also benefit from optional CSI-2 protocol-generated and CSI-2 protocol-
1393 consumed Spacer insertion(s) prior to PDQ, because it facilitates optimal interpacket latency for imaging
1394 applications. The value of the Spacer Word for CSI-2 over C-PHY shall be 0xFFFF, and when present, Spacer
1395 Words shall be generated across all Lanes within a Link.
1396 The image sensor (transmitter) shall include the following two 16-bit registers, in order to facilitate the
1397 optimal interpacket latency for imaging applications:
1398 1. TX_REG_CSI_EPD_EN_SSP (EPD Enable and Short Packet Spacer) Register
1399 • The MS bit of this register shall be used to enable EPD with 7-UI PDQ (Sync Word) insertion
1400 between two CSI-2 packets and optional Spacer insertions for Short Packets and Long Packets.
1401 • 1’b0: C-PHY legacy EoT, LPS, SoT Packet Delimiter
1402 • 1’b1: Enable C-PHY EPD (Efficient Packet Delimiter)
1403 • If C-PHY EPD is enabled, the remaining 15 bits of this register (bits [14:0]) shall specify the
1404 minimum number (up to 32,767) of Spacer Word insertions per Lane following CSI-2 Short
1405 Packets.
1406 2. TX_REG_CSI_EPD_OP_SLP (Long Packet Spacer) Register
1407 • The MS bit of this register is reserved for future use.
1408 • If C-PHY EPD is enabled, the remaining 15 bits of this register (bits [14:0]) shall specify the
1409 minimum number (up to 32,767) of Spacer Word insertions per Lane following CSI-2 Long
1410 Packets.
1411 If the C-PHY EPD is enabled, then the following applies to the fifteen least significant bits of both EPD
1412 registers:
1413 • A register value of 15’d0 generates zero or more Spacers.
1414 • A register value of 15’d5 generates at least 5 Spacers, resulting in a minimum duration of 5 x 7 UI.
1415 • The maximum register value of 15’d32,767 generates at least 32,767 Spacers, resulting in a
1416 minimum duration of 32,767 x 7 UI.
1417 The transmitter shall support at least one non-zero value of the Spacer insertion count field in each of the
1418 TX_REG_CSI_EPD_EN_SSP and TX_REG_CSI_EPD_OP_SLP registers.
1419 Spacer Words without PDQ signaling may be inserted after CSI-2 packets just prior to C-PHY EoT only if
1420 C-PHY EPD is enabled and bit 7 of the TX_REG_CSI_EPD_MISC_OPTIONS register is set to 1; see Table
1421 16. If this register bit is not implemented by an image sensor, its contents shall be treated as 0 by this
1422 specification. The minimum number of Spacer Word insertions just prior to C-PHY EoT is determined by the
1423 fifteen least significant bits of the TX_REG_CSI_EPD_EN_SSP and TX_REG_CSI_EPD_OP_SLP registers.
1424 Note that C-PHY EPDs and Spacer Words without PDQ signaling are completely compatible with C-PHY
1425 ALP Mode high-speed burst transmissions as described in [MIPI02].

Confidential
23-May-2022
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
1426 Spacer followed by one PDQ shown for illustration.
Figure 78 LRTE Efficient Packet Delimiter Example for CSI-2 Over C-PHY (2 Lanes)

Confidential
23-May-2022
9.11.1.2 EPD for D-PHY Physical Layer Option

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

1433 D-PHY EPD Option 1 consists of PHY-generated and PHY-consumed D-PHY HS-Idle Packet Delimiter
1434 Quick (PDQ) signaling, optionally preceded by CSI-2 protocol-generated and protocol-consumed Filler bytes
1435 (as needed) plus zero or more Spacer bytes. The value of the Spacer byte for CSI-2 over D-PHY shall be
1436 0xFF, and when present, Spacer bytes shall be generated across all Lanes within a Link. The PDQ is generated
1437 and consumed by the transmitter and receiver physical layers, respectively, and as a result serves as a robust
1438 CSI-2 packet delimiter. D-PHY receivers can benefit from protocol-generated and protocol-consumed
1439 Spacer(s), because additional clock cycles might be needed to flush the payload content through the pipelines
1440 before the forwarded clock is disabled for PDQ signaling. Note that D-PHY HS-Idle is not supported by ALP
1441 mode in [MIPI01].
1442 Under D-PHY Option 1, Filler bytes shall be inserted as needed following all short and long packets
1443 transmitted between D-PHY SoT and EoT sequences. For example, if a short packet is the last packet
1444 transmitted before EoT in an 8-Lane link, then a Filler byte is transmitted on each of Lanes 4 through 8 for
1445 that packet.
1446 Under D-PHY Option 1, an EPD may not be inserted after a CSI-2 packet just prior to D-PHY EoT, but
1447 Spacer Bytes without PDQ signaling may be inserted after such packets if bit 7 of the
1448 TX_REG_CSI_EPD_MISC_OPTIONS register is 1. The minimum number of Spacer byte insertions just prior
1449 to D-PHY EoT is determined by the fifteen least significant bits of the TX_REG_CSI_EPD_EN_SSP and
1450 TX_REG_CSI_EPD_OP_SLP registers. See Table 17.
1451 The image sensor should use “TxHSIdleClkHS” at the PPI in order to generate the PDQ sequence by the
1452 D-PHY transmitter. Upon reception of the PDQ sequence by the D-PHY receiver, an application processor
1453 should use “RXSyncHS” at the PPI to notify the CSI-2 protocol layer. Additionally, “RxClkActiveHS” may
1454 also be used to provide an advance indication of the EPD.

Confidential
23-May-2022
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
1455
Figure 79 Example of LRTE EPD for CSI-2 Over D-PHY – Option 1

Confidential
23-May-2022
9.11.1.2.2 D-PHY EPD Option 2

1456 D-PHY EPD Option 2 is limited to the insertion of CSI-2 protocol-generated and CSI-2 protocol-consumed
1457 Filler bytes (as needed) plus zero or more Spacer bytes for use between multiple back-to-back packet transfers
1458 within the same D-PHY high-speed burst transfer (i.e., there is no use of PHY-generated and PHY-consumed
1459 PDQ). Option 2 is primarily intended for use with D-PHYs supporting legacy LP or LVLP mode that don’t
1460 support Option 1; however, it may also be used with ALP Mode as described in [MIPI01]. Depending on the
1461 use case (i.e., the sizes and number of CSI-2 packets being concatenated), the lack of D-PHY-generated and
1462 D-PHY-consumed packet delimiters could compromise CSI-2 link integrity. Option 2 is not intended to
1463 completely eliminate D-PHY LP, LVLP, or ALP Mode packet delimiters. It is also recommended that one or
1464 more Spacers be included following a Short Packet or a Long Packet when using D-PHY EPD Option 2.
1465 D-PHY EPD Option 2 may also be applied to packets transmitted using C-PHY or D-PHY Escape Mode
1466 LPDT in connection with the Unified Serial Link (USL) feature described in Section 9.12.
1467 Under D-PHY Option 2, Filler bytes shall be inserted as needed following all short and long packets
1468 transmitted between D-PHY SoT and EoT sequences except for possibly the last packet before EoT. For the
1469 last packet, Filler bytes are required if Spacer bytes are inserted before EoT, and optional otherwise. For
1470 example, if a short packet is the last packet transmitted before EoT in an 8-Lane link, and no Spacer bytes
1471 are inserted before EoT, then Filler bytes are not required for Lanes 4 through 8 and EoT may start earlier on
1472 these Lanes.
1473 Under D-PHY Option 2, an EPD (i.e., one or more Spacers) shall not be inserted immediately after the last
1474 CSI-2 short or long packet in any high-speed burst or LPDT payload, including after the EoTp short packet
1475 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
1476
Figure 80 Example of LRTE EPD for CSI-2 Over D-PHY – Option 2

Confidential
23-May-2022
9.11.1.2.3 D-PHY EPD Specifications (for EPD Options 1 and 2)

1477 The image sensor (transmitter) shall include the following two 16-bit registers, in order to facilitate the
1478 optimal interpacket latency for imaging applications:
1479 1. TX_REG_CSI_EPD_EN_SSP (EPD Enable and Short Packet Spacer) Register
1480 • The MS bit of this register shall be used to enable EPD insertion between two CSI-2 packets.
1481 • 1’b0: D-PHY legacy EoT, LPS, SoT Packet Delimiter
1482 • 1’b1: Enable D-PHY EPD (Efficient Packet Delimiter)
1483 • Variable-length Spacer insertions following Short Packets:
1484 If D-PHY EPD is enabled and either Option 1 is selected (i.e., bit 15 of register
1485 TX_REG_CSI_EPD_OP_SLP is 0) or Option 2 is selected with bit 5 or bit 4 of register
1486 TX_REG_CSI_EPD_MISC_OPTIONS in Table 17 set to 1, then bits [14:0] of register
1487 TX_REG_CSI_EPD_EN_SSP shall specify the minimum number (up to 32,767) of Spacer
1488 insertions per Lane following CSI-2 Short Packets. The number of Spacers actually inserted per
1489 Lane may vary from one Short Packet to another. For D-PHY EPD Option 2, both the contents of
1490 register TX_REG_CSI_EPD_EN_SSP and the actual number of Spacers inserted per Lane shall be
1491 multiples of the value selected in bits [5:4] of register TX_REG_CSI_EPD_MISC_OPTIONS.
1492 • Fixed-length Spacer Insertions following Short Packets:
1493 If D-PHY EPD is enabled, and Option 2 is selected (i.e., bit 15 of register
1494 TX_REG_CSI_EPD_OP_SLP is 1) with bit 5 and bit 4 of register
1495 TX_REG_CSI_EPD_MISC_OPTIONS set to 0, then bits [14:0] of register
1496 TX_REG_CSI_EPD_EN_SSP shall specify the exact number (up to 32,767) of Spacer insertions
1497 per Lane following CSI-2 Short Packets. The number of Spacers inserted shall not vary from one
1498 Short Packet to another.
1499 2. TX_REG_CSI_EPD_OP_SLP (EPD Option and Long Packet Spacer) Register
1500 • The MS bit of this register shall be used to select the D-PHY EPD option.
1501 • 1’b0: D-PHY EPD Option 1
1502 • 1’b1: D-PHY EPD Option 2
1503 • Variable-length Spacer insertions following Long Packets:
1504 If D-PHY EPD is enabled and either Option 1 is selected (i.e., bit 15 of register
1505 TX_REG_CSI_EPD_OP_SLP is 0) or Option 2 is selected with bit 5 or bit 4 of register
1507 TX_REG_CSI_EPD_OP_SLP shall specify the minimum number (up to 32,767) of Spacer
1508 insertions per Lane following CSI-2 Long Packets. The number of Spacers actually inserted per
1509 Lane may vary from one Long Packet to another. For D-PHY EPD Option 2, both the contents of
1510 register TX_REG_CSI_EPD_EN_SLP and the actual number of Spacers inserted per Lane shall be
1511 multiples of the value selected in bits [5:4] of register TX_REG_CSI_EPD_MISC_OPTIONS.
1512 • Fixed-length Spacer insertions following Long Packets:
1513 If D-PHY EPD is enabled, and Option 2 is selected (i.e., bit 15 of register
1514 TX_REG_CSI_EPD_OP_SLP is 1), with bit 5 and bit 4 of register
1516 TX_REG_CSI_EPD_OP_SLP shall specify the exact number (up to 32,767) of Spacer insertions
1517 per Lane following CSI-2 Long Packets. The number of Spacers inserted shall not vary from one
1518 Long Packet to another.

Confidential
23-May-2022
1519 The following examples apply to the least significant fifteen bits of the two EPD registers:
1520 • For variable-length Spacer insertions:
1521 • A register value of 15’d0 generates zero or more Spacers.
1522 • A register value of 15’d5 generates at least 5 Spacers.
1523 • A register value of 15’d32,767 generates at least 32,767 Spacers.
1524 • For fixed-length Spacer insertions:
1525 • A register value of 15’d0 generates no Spacers.
1526 • A register value of 15’d5 generates exactly 5 Spacers.
1527 • A register value of 15’32,767 generates exactly 32,767 Spacers.
1528 The transmitter shall support at least one non-zero value of the Spacer insertion count field in each of the
1529 TX_REG_CSI_EPD_EN_SSP and TX_REG_CSI_EPD_OP_SLP registers. The duration of the PDQ
1530 sequence is directly proportional to the D-PHY Link rate, and is configured using the HS-Idle timing
1531 parameters defined in [MIPI01] for the D-PHY physical layer option.
1532 For D-PHY EPD, the TX_REG_CSI_EPD_MISC_OPTIONS register is required for image sensors
1533 (transmitters) supporting the insertion of Spacers-without-PDQ under Option 1 or the insertion of EoTp (see
1534 Section 9.11.1.2.5) or a variable number of Spacer bytes under Option 2. If this register is not implemented,
1535 then its value shall be treated as zero by this specification.
1536 Note that registers TX_REG_CSI_EPD_EN_SSP, TX_REG_CSI_EPD_OP_SLP, and
1537 TX_REG_CSI_EPD_MISC_OPTIONS are not intended to control image sensor LRTE when applied to USL
1538 packets transmitted using Escape Mode LPDT; see Section 9.12.

Confidential
23-May-2022
9.11.1.2.4 Robust Variable-Length Spacer Detection under D-PHY EPD Option 2

(Informative)
1539 CSI-2 transmitters inserting a variable number of Spacer bytes per Lane between packets under D-PHY EPD
1540 Option 2 require CSI-2 receivers to examine, rather than simply count, potential Spacer bytes in order not to
1541 confuse them with packet header bytes. Since Spacer bytes are required to be distributed across all data Lanes
1542 beginning with Lane 1, CSI-2 receivers may detect them by scanning for bytes with the value 0xFF between
1543 packets only on Lane 1. However, truly reliable detection also requires these bytes to be error-free because a
1544 bit error in an intended Spacer byte (with value 0xFF) on Lane 1 can cause it to appear as a packet header
1545 Data Identifier byte. Conversely, a bit error in an intended packet header Data Identifier byte can cause it to
1546 appear as a Spacer byte.
1547 If Lane-merged groups of four sequential Spacer bytes are processed as potential 32-bit packet headers by a
1548 CSI-2 receiver, then the results of the ECC calculation can be used to detect and correct errors in the Spacer
1549 bytes just as it does in packet header bytes. This is possible because the value 0x3F in the least significant
1550 six bits of each transmitted group of four Spacer bytes also happens to be the 6-bit ECC of the value
1551 0x3FFFFFF in the most significant 26 bits.
1552 Spacer byte insertion and detection schemes leveraging the latter principle may vary, depending upon the
1553 total number of data Lanes (N) in the link. Requiring the CSI-2 transmitter to insert Spacers in multiples of
1554 M = LCM(N,4) / N bytes per Lane, where LCM is the least common multiple function, always guarantees
1555 that the CSI-2 receiver will observe an integer multiple of four Spacer bytes between packets. As shown in
1556 Table 15, only values of M equal to 1, 2, and 4 are possible and programmable on the CSI-2 transmitter using
1557 bits 5:4 of the TX_REG_CSI_EPD_MISC_OPTIONS register shown in Table 17.
1558 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
23-May-2022
1559 Note that the CSI-2 receiver only needs to check the data integrity of one out of every M potential Spacer
1560 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
1561 byte, then the remaining M-1 bytes can be safely ignored by the CSI-2 receiver because it knows in advance
1562 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

1563
Figure 81 Enabling Robust Spacer Byte Detection: General Case
1564 However, for N > 4, it is possible to program the CSI-2 transmitter to always insert an arbitrary number of
1565 Spacer bytes per Lane (i.e., to set M = 1) if the CSI-2 receiver examines bytes from the first four Lanes and,
1566 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

1567
Figure 82 Enabling Robust Spacer Byte Detection: Special Case

Confidential
23-May-2022
9.11.1.2.5 End-of-Transmission Short Packet (EoTp)

1568 When multiple CSI-2 packets are transmitted in a single D-PHY high-speed (HS) burst payload using D-
1569 PHY EPD Option 2, proper operation requires the host to be able to reliably detect the last CSI-2 packet in
1570 the burst under all circumstances. In many implementations, this requires the CSI-2 host protocol receiver to
1571 perform additional End-of-Transmission (EoT) processing on HS trailer and other bits passed to it from the
1572 D-PHY physical layer receiver.
1573 Such EoT processing can be even more complex if HS trailer bits are followed by a small but potentially
1574 unknown number of bits with indeterminate values sampled, for instance, during the D-PHY HS to LP or
1575 LVLP voltage transition.
1576 For D-PHY EPD Option 2, the End-of-Transmission short packet (EoTp) removes the need for the CSI-2
1577 protocol receiver to perform EoT processing by unambiguously signaling the last CSI-2 packet in a D-PHY
1578 high-speed burst payload.
1579 EoTp has the following short packet field definitions:
1580 • DT shall be set to 0x04.
1581 • All VC, VCX, and WC bits shall be set to zero.
1582 Other rules pertaining to EoTp are as follows:
1583 • EoTp generation or detection is mandatory for all devices conforming to this version of the CSI-2
1584 specification that also support D-PHY EPD Option 2 for HS transmissions. EoTp shall not be used
1585 in conjunction with C-PHY EPD, D-PHY EPD Option 1, or packet transmissions using Escape
1586 Mode LPDT (see Section 9.12).
1587 • Devices conforming to CSI-2 specification v2.1 or earlier do not support EoTp. In order to ensure
1588 interoperability with earlier devices, EoTp-supporting devices shall provide a means to enable or
1589 disable EoTp generation or detection; for image sensors, this capability shall be supplied via bit 6
1590 of the TX_REG_CSI_EPD_MISC_OPTIONS register shown in Table 17. This permits the EoTp
1591 feature to be effectively disabled by the system designer whenever a device on either side of the
1592 Link does not support EoTp.
1593 • When the EoTp feature is enabled, exactly one EoTp shall be present in every high-speed burst
1594 payload as the last CSI-2 packet following all other short and/or long packets, including payloads
1595 with only one CSI-2 short or long packet in addition to the EoTp short packet itself.
1596 • Spacers are not permitted after an EoTp because this packet is always immediately followed by
1597 D-PHY EoT, and never by another CSI-2 packet.
1598 • The contents of EoTp VC, VCX, and WC fields shall be ignored by CSI-2 protocol receivers.
1599 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
1600
Figure 83 EoTp Usage Examples

Confidential
23-May-2022
9.11.2 Using ILR and Enhanced Transport Efficiency Together

1601 EPD may be used together with LVLP or ALP Mode signaling in many imaging applications in order to
1602 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

1603
Figure 84 Using EPD with LVLP or ALP Mode Signaling

Confidential
23-May-2022
9.11.3 LRTE Register Tables

1604 The CSI-2 over C-PHY Spacer Words and the CSI-2 over D-PHY Spacer Bytes shall be generated across all
1605 Lanes within a Link as specified in Table 16 and Table 17.
1606 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 uses
Enable or disable Efficient Delimiter PHY-generated and PHY-consumed
Packet Delimiter using PHY- Value 1’b1: Enable Efficient Packet PDQ (7-UI Sync Word). Optional
generated and PHY-consumed Delimiter minimum Spacers may be Inserted for
PDQ with optional minimum Short Packets and Long Packets.
Spacer Insertion(s) See Figure 78.
Bits [14:0]: The minimum number of Spacer Words The Short Packet Spacers insertions are
EPD Short Packet Spacers per Lane following a Short packet. enabled by the C-PHY EPD
Examples: (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 insertions are
EPD Long Packet Spacers per Lane following a Long packet. enabled by the C-PHY EPD
Examples: (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 supporting
Enable insertion of Spacers- without-PDQ (default) C-PHY EPD with Spacers-without-PDQ.
without-PDQ after CSI-2 Value 1’b1: Enable Spacers
packets just prior to C-PHY without-PDQ
EoT.
Bits [6:0]: – –
Reserved

Confidential
23-May-2022
1607 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
23-May-2022

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
23-May-2022
9.12 Unified Serial Link (USL)

1608 Unified Serial Link (USL, see Figure 85) is an optional CSI-2 feature that reduces the number of interface
1609 wires and helps to natively support longer reach.
1610 USL builds upon the benefits provided by the LRTE features (Section 9.11). USL alleviates the need to use
1611 any additional I2C, I3C, and/or SPI interconnect for the Camera Command Interface (CCI), or GPIO wires
1612 for camera module control signaling. This is accomplished by using CSI-2 encapsulation with the Bus Turn
1613 Around (BTA) capabilities of the natively supported C-PHY 2.0 (or beyond) and D-PHY v2.5 (or beyond)
1614 transport layer options.
1615 MIPI PHY bandwidths are many orders of magnitude greater than those provided by the I2C-compatible
1616 2-wire bi-directional control bus. Moreover, there are natural blanking intervals (i.e., idle cycles) between
1617 transferring horizontal rows (i.e., horizontal blanking), and between transferring frames (i.e., vertical
1618 blanking), that can be used to update the image sensor shadow registers.
1619 In this Section:
1620 • The term SNS refers to an image sensor, or an image sensor module comprising a CMOS image
1621 sensor plus additional complementary devices (i.e., non-imaging devices).
1622 • The term APP refers to an SoC application processor (AP) containing any combination of
1623 computer vision engine(s) and/or image processing unit(s), or to a host processor.
1624 The reverse link throughput from an APP to a SNS does not require high bandwidth, which substantially
1625 relaxes timing constraints and margins for receiver implementations on the SNS transceiver. Mapping all
1626 CSI-2 transactions via MIPI C-PHY/D-PHY can reduce the number of wires, support long reach, help secure
1627 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
1628
Figure 85 USL System Diagram

Confidential
23-May-2022
9.12.1 USL Technical Overview

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

Confidential
23-May-2022
9.12.2 USL Command Payload Constructs

1645 All USL transport operations shall use the existing CSI-2 Long Packet (LgP) constructs. The encapsulated
1646 USL payload fields (Size_Bytes, Target_Address, Sub_Address, Write_data, Read_data, USL_CTL, TSEQ)
1647 shall map LSB data to Bit0 (see Figure 3). All multi-byte USL payload fields shall be transmitted least
1648 significant byte first.
1649 USL Commands are used to map register Read/Write requests from the APP to the SNS, and read completions
1650 from the SNS to the APP, using the CSI-2 LgP. The LgP Packet Header Data Type field shall be set to the
1651 value 0x38 when an APP or SNS generates USL Command register R/W requests or completions,
1652 respectively. For all C-PHY or D-PHY high-speed (HS) Mode transmissions, the encapsulated R/W requests
1653 are mapped into the LgP Packet Data Field Application Specific Payload of USL packets, per Figure 52 for
1654 the D-PHY physical layer option, and per Figure 53 for the C-PHY physical layer option. The Long Packet
1655 Padding and Filler insertions shall be preserved for the C/D-PHYs as defined in Section 9.1.
1656 As described in Section 7.3, all USL implementations shall support PHY LP or LVLP Mode signaling, and
1657 should support ALP Mode signaling. USL systems are normally configured prior to power-up to support one
1658 of these signaling Modes under either D-PHY or C-PHY.
1659 If USL is configured to use C-PHY or D-PHY LP/LVLP Mode, then all USL packets transmitted using
1660 forward or reverse direction Escape Mode LPDT have the same format as USL packets transmitted using
1661 D-PHY HS Mode; each byte is also transmitted least significant bit first. The APP shall be capable of
1662 receiving USL packets both as HS Mode transmissions distributed over all active Lanes, and as Escape Mode
1663 LPDT Transmissions driven only over Lane 1. Note that data scrambling (Section 9.13) does not apply to
1664 LPDT Transmissions.
1665 During USL_REV Mode, the SNS shall support buffering for a minimum of 32 register read requests (single
1666 and contiguous) from an APP. During USL_REV Mode, the SNS shall support a minimum of 64 register
1667 write requests (single and contiguous) with a minimum of 1024 bits of write data from an APP.
1668 If USL is configured to use C-PHY or D-PHY ALP Mode, then while in USL_REV Mode, the APP may
1669 concatenate multiple USL packets into a single HS burst transmission over Lane 1 using C-PHY EPD or
1670 D-PHY EPD Option 2, respectively, provided the applicable LRTE EPD features are supported (see
1671 Section 9.11). SNS HS Mode receiver LRTE capabilities may be understood from the SNS datasheet, or
1672 discovered in some other fashion. Similarly, while in USL_FWD Mode, the SNS may concatenate multiple
1673 USL and/or non-USL packets into a single HS burst transmission distributed over all active Lanes using one
1674 of the latter EPD alternatives.
1675 If USL is configured to use C-PHY or D-PHY LP/LVLP Mode, then while in USL_FWD Mode, the SNS
1676 may concatenate multiple USL and/or non-USL packets into a single HS burst transmission distributed over
1677 all active Lanes using any supported C-PHY or D-PHY LRTE EPD feature (including D-PHY EPD Option
1678 1). While in either USL_FWD or USL_REV Mode, LRTE D-PHY EPD Option 2 may be used to concatenate
1679 multiple USL packets transmitted using Escape Mode LPDT, but only with zero or more fixed length Spacers
1680 between packets and without the insertion of EoTp short packets. SNS Spacer generation for USL packets
1681 transmitted using LPDT may be controlled by the APP using the register in Table 18. SNS LP/LVLP Mode
1682 receiver LRTE capabilities may be understood from the SNS datasheet, or discovered in some other fashion.
1683 The existing LgP 16-bit Checksum shall be used to preserve transport integrity for all USL transitions. USL
1684 Command transactions do not require the legacy CCI “S” (Start), “P” (Stop), and “A” (Acks), because the
1685 LgP transport handles these functions.
1686 A 16-bit Size_Bytes field contains the number of sequential bytes of data to write or read. A Read_Data field
1687 contains the byte based read data.
1688 A Write_Data field contains the byte based write data.
1689 A 7-bit Target_Address field contains the device address where the commands are to be send or to be received.
1690 For example, CCI (I2C) Target Address e.g. 0x6C was used to communicate with an image sensor and

Confidential
23-May-2022
1691 similarly with USL the same e.g. 0x6C would apply. This field is transmitted as the most significant 7 bits of
1692 a byte whose LSB is analogous to the CCI R/W bit.
1693 A 16-bit Sub_Address field is used for pointing at a register inside the Target device. Product-specific imaging
1694 systems may use an 8-bit and/or 16-bit Sub_Address on an as-needed basis, since Sub_Address is device-
1695 specific and is known at platform level. Note that systems using a single USL link to communicate with
1696 multiple devices, e.g. via local I2C bus, may require using both 8-bit and 16-bit indexes, depending on the
1697 devices.
1698 An 8-bit USL Control (USL_CTL) (Table 19) is used to ensure transport integrity with guaranteed delivery
1699 of commands from the APP to the SNS using ACK, and to improve transport efficiency with support for
1700 contiguous R/W operations often used for imaging and vision firmware uploads from APP to SNS.
1701 A 16-bit Transaction Sequence (TSEQ) field contains a unique non-zero USL command identification
1702 number generated by the SNS and APP. The SNS and APP generate and clear the Transaction Sequence field
1703 upon successful reception of a USL Packet (as detailed in sections below).
1704 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
23-May-2022
1705 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
1706 Note:
1707 The USL_CTL[7:5] bits are reserved for future expansion.

Confidential
23-May-2022
9.12.3 USL Operation Procedures

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

1712 This example procedure illustrates the APP initiating four valid USL Command transactions (USL_REV
1713 Mode).
1714 1. ACK Generation
1715 TSEQ is used by the system to ensure guaranteed delivery of USL commands. An APP shall
1716 include a 16-bit register to store the last successful TSEQ received from the SNS during
1717 USL_FWD Mode. Upon entering USL_REV Mode, the APP shall generate ACK twice
1718 immediately using the following format:
1719 • LgP Packet Header Data ID = 0x38
1720 • LgP Packet Data format for ACK generation:
1721 {USL_CTL[7:0], TSEQ[15:0]}
1722 2. Register Write Request with Write Data
1724 • LgP Packet Data format for all writes:
1725 {USL_CTL[7:0], TSEQ[15:0], Size_Bytes[15:0],
1726 Target_Address[7:1],[W=0],
1727 Sub_Address[15:0],
1728 Write_Data [16’d Size_Bytes-1:0]}
1729 3. Register Read Request
1731 • LgP Packet Data format for all read requests:
1733 Target_Address[7:1],[R=1],
1734 Sub_Address[15:0]}
1735 4. Initiate BTA
1736 Upon completing the R/W register commands, the APP shall generate the Initiate BTA packet
1737 twice to switch the link from USL_REV to USL_FWD mode.
1738 The Initiate BTA bit in the USL_CTL shall be set to 1’b1.
1740 • LgP Packet Data format for initializing BTA, and switch from USL_REV to USL_FWD:
1741 {USL_CTL[7:0], TSEQ[15:0]}

Confidential
23-May-2022
9.12.3.2 SNS Initiated USL Transactions

1742 This example procedure illustrates the SNS initiating five valid USL Command transactions (USL_FWD
1743 Mode).
1744 1. NAK Generation
1745 If an Image Sensor (SNS) receives an invalid or an illegal USL Command request from the
1746 Application Processor (APP), then the SNS shall generate a Negative Acknowledgement (NAK).
1747 By default, the SNS shall not execute any following R/W USL command requests from the APP
1748 after a NAK during an USL_REV_Mode, unless the USL_CTL Force Command bit is enabled by
1749 the APP. The SNS shall generate negative acknowledgement (NAK) for the first illegal or failed
1750 R/W request from an APP. The SNS may optionally generate additional NAKs resulting from
1751 “Force Command” requests. The NAK shall be transmitted twice to the APP immediately upon
1752 switching to USL_FWD_Mode using the following format:
1754 • LgP Packet Data format for NAK generation:
1755 {USL_CTL[7:0], TSEQ[15:0]}
1756 2. ACK Generation
1757 TSEQ is used by the product imaging system to ensure guaranteed delivery of R/W commands
1758 from APP to SNS. An Image Sensor shall include a 16-bit register to store the last successful
1759 TSEQ received from the APP during USL_REV Mode. Upon entering USL_FWD Mode, the SNS
1760 shall generate ACK twice immediately following any NAK generation(s) using the following
1761 format:
1763 • LgP Packet Data format for ACK generation:
1764 {USL_CTL[7:0], TSEQ[15:0]}
1765 3. Register Read Completion
1767 • LgP Packet Data format for all read completions:
1769 Read_Data [16’d Size_Bytes-1:0]}
1770 4. Interrupt Generation
1771 Upon completing ACK/NAK generations, the SNS may generate in-band interrupt using
1772 USL_CTL[1:0] in the USL_FWD mode. It is strongly recommended for the SNS to prioritize and
1773 generate the interrupt notification at the earliest opportunity.
1774 The following format shall be used to also include optional information pertaining to the interrupt:
1776 • LgP Packet Data format for In-Band Interrupt generation:
1777 {USL_CTL[7:0], Target_Address[15:0], Interrupt_Information[15:0]}
1778 5. Initiate BTA
1779 The SNS shall generate the Initiate BTA packet twice prior to switching the link from USL_FWD
1780 to USL_REV mode. The Initiate BTA bit in the USL_CTL shall be set to 1’b1. The TSEQ shall be
1781 the 16-bit value from REG_USL_ACK_TSEQ.
1783 • LgP Packet Data format for initializing BTA, and switch from USL_REV to USL_FWD:
1784 {USL_CTL[7:0], TSEQ[15:0]}

Confidential
23-May-2022
9.12.4 Monitoring USL Command Transport Integrity

1785 This section presents a stepwise procedure for monitoring the integrity of the USL Command Transport,
1786 using TSEQ and the two SNS registers defined in Table 20.
1787 1. [System Reset] [Power Cycle]
1788 • The SNS shall reset registers REG_USL_ACK_TSEQ[15:0] and REG_USL_NAK_TSEQ[15:0]
1789 to the value 16’d0. The APP shall reset internal register APP_REG_USL_ACK_TSEQ[15:0].
1790 2. [USL_REV Mode]
1791 • Upon entering USL_FWD Mode, APP shall generate ACK twice using the 16-bit TSEQ from
1792 internal register APP_REG_USL_ACK_TSEQ[15:0].
1793 • The APP shall generate a 16-bit, non-zero TSEQ value that increments with each USL
1794 Command R/W request it sends to the SNS.
1795 • The SNS shall store the TSEQ of the last successful USL command into register
1796 REG_USL_TSEQ_ACK[15:0].
1797 • The SNS shall store the TSEQ of the first illegal USL command into register
1798 REG_USL_TSEQ_NAK[15:0].
1799 3. [USL_REV Mode Exit]
1800 • The APP shall reset internal register APP_REG_USL_ACK_TSEQ[15:0] to the value 16’d0.
1801 4. [USL_FWD Mode]
1802 • Upon entering USL_FWD Mode, if any illegal operation was encountered in the prior
1803 USL_REV Mode, the SNS shall generate NAK twice using the 16-bit TSEQ from register
1804 REG_USL_TSEQ_NAK[15:0].
1805 • Next, the SNS shall generate ACK twice using the 16-bit TSEQ from register
1806 REG_USL_TSEQ_ACK[15:0].
1807 • An ACK with TSEQ value of 16’d0 shall be generated by the SNS if no USL commands were
1808 successfully received from the APP during USL_REV Mode.
1809 Note:
1810 SNS shall reset the internal state(s) used to block execution of subsequent command
1811 operations after a NAK.
1812 5. [USL_FWD Mode Exit]
1813 The SNS shall reset registers REG_USL_ACK_TSEQ[15:0] and REG_USL_NAK_TSEQ[15:0] to
1814 the value 16’d0.
1815 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
23-May-2022
9.12.5 USL Powerup / Reset, SNS Configuration, and Mode Switching

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

1818 The USL link is in USL Reverse Mode (USL_REV) when:
1819 • SNS is configured as RX
1820 • APP is configured as TX
1821 • The channel is established to transfer payloads from APP to SNS
1822 The USL link is in USL Forward Mode (USL_FWD) when:
1823 • SNS is configured as TX
1824 • APP is configured as RX
1825 • The channel is established to transfer payloads from SNS to APP
9.12.5.2 USL Power-up / Reset

1826 The link comes up in USL_FWD Mode after power-up or reset:
1827 • The SNS shall initially configure each PHY Lane (including clock Lane, if present) as a
1828 transmitter (TX).
1829 • The APP shall initially configure each PHY Lane (including clock Lane, if present) as a receiver
1830 (RX).
1831 • The SNS and APP shall then initialize their Lane 1 PHYs following the appropriate PHY-defined
1832 procedure; all other Lanes are unidirectional and should remain uninitialized until needed.
1833 • If USL is configured to use D-PHY ALP Mode, then the clock Lane shall also be initialized and
1834 started following its initialization in order to facilitate ALP Mode fast BTA and high-speed
1835 bidirectional data transfers over data Lane 1; see Section 9.12.5.6 for additional guidance.
1836 • If USL is configured to use D-PHY LP/LVLP Mode, then initialization and start-up of the clock
1837 Lane may be delayed until the SNS is first required to transmit packets to the APP using HS Mode.
1838 Note that in this case, all USL packet transmissions from the APP to the SNS over data Lane 1 use
1839 Escape Mode LPDT and don’t require the clock Lane to be running.
1840 • Once the SNS has completed internal power-up / reset calibration, the SNS shall initiate BTA on
1841 Lane 1 using the steps outlined in Section 9.12.3.2. The SNS may optionally send the contents of
1842 TX_USL_SNS_BTA_ACK_TIMEOUT[15:0] using the read completion format from
1843 Section 9.12.3.2 prior to initiating BTA.
1844 • Upon completion of the BTA, the link is configured as USL_REV Mode to enable the APP to
1845 configure the SNS using Lane 1.
1846 • During SNS configuration, the APP may select the total number of active Lanes in order to enable
1847 the correct number of unidirectional Lanes to be initialized and put into service when image
1848 streaming is started.

Confidential
23-May-2022
9.12.5.3 USL SNS Configuration

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

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

Confidential
23-May-2022
1868 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
23-May-2022
1869 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.
1870

Confidential
23-May-2022
9.12.5.5 ALP Fast BTA Timeout Support

1871 Since the target device PHY does not provide an acknowledgement electrical signaling upon receiving an
1872 “Initiate BTA” USL command request from an initiator, the following SNS timeout registers are utilized by
1873 the APP to alleviate potential deadlocks.
1874 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.
1875 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
23-May-2022
USL_REV Mode (PARK) USL_REV Mode (Exit PARK)

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

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

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

Confidential
23-May-2022
1877 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
1878 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
23-May-2022
9.12.5.6 USL Clock Lane Management Under D-PHY ALP Mode (Informative)
1879 When USL is configured to use D-PHY ALP Mode as described in [MIPI01], a running high-speed clock
1880 Lane is required for any active data communications between SNS and APP. Such communications include
1881 the usual forward-direction SNS pixel streaming, as well as any bidirectional transactions on data Lane 1
1882 related to USL packet transmissions (with DT code 0x38), or any low-level PHY fast BTA or ULPS entry
1883 commands initiated by either the SNS or APP. When USL is configured to use D-PHY LP or LVLP Mode,
1884 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)

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

Confidential
23-May-2022
9.12.5.6.2 Dynamic Clock Control (Informative)

1900 As with legacy CSI-2 non-continuous clock mode, USL permits the clock Lane to be stopped during periods
1901 in which the system application either doesn’t support or doesn’t immediately anticipate data
1902 communications between SNS and APP.
1903 Examples of such periods include:
1904 • One or more of the “horizontal line blanking” (hblank) periods between image lines during image
1905 streaming (assuming such periods are sufficiently long enough to include the timing overhead
1906 entailed in stopping and then restarting the clock).
1907 • All or part of the “vertical frame blanking” (vblank) period between image frames during image
1908 streaming.
1909 • “Hard standby” periods during which image sensor power consumption is at a minimum and no
1910 CCI register accesses are possible. Hard standby entry and exit is typically controlled using a
1911 separate control signal (e.g., the XSHUTDOWN signal defined in [MIPI04]).
1912 • All or part of “soft standby” periods during which image streaming is temporarily halted to enable
1913 the APP to reconfigure CCI registers concerning fundamental SNS operating characteristics, such
1914 as output image resolution, pixel depth, frame rate, bit rate, active Lane count, etc.
1915 Stopping and restarting the clock Lane may be performed by the SNS either automatically following
1916 conventions understood in advance by the APP, or in response to the APP triggering the SNS in an ad hoc
1917 manner. For example, when the clock Lane is running during USL_REV mode, the APP may command the
1918 SNS to stop the clock by writing to a special CCI control register on the SNS. Conversely, when the clock
1919 Lane is stopped during USL_REV mode (meaning no CCI register accesses are possible), the APP may
1920 request the SNS to restart the clock by transmitting a short D-PHY ALP Mode PHY-to-PHY Wake pulse to
1921 the SNS (as described in [MIPI01]).
1922 Note that changing the clock Lane frequency requires the SNS to stop the clock Lane, internally adjust the
1923 frequency (which may involve relocking a PLL), and then restart the clock Lane in accordance with the
1924 D-PHY specification. Needless to say, the latter actions can be collectively time consuming and are best
1925 avoided when switching from USL_FWD mode to USL_REV mode and then back again during relatively
1926 short time periods such as hblank. In other words, if the APP needs to access SNS CCI registers during
1927 hblank, then the ideal situation is one in which both the SNS and APP can support reverse-direction
1928 transmissions at one-fourth of the full bit rate used for streaming pixel data packets, thereby avoiding the
1929 need to change the clock Lane frequency twice during hblank.

Confidential
23-May-2022
1930 Figure 87 illustrates examples of USL ALP Mode clock Lane management during the image streaming
1931 vblank period. Beginning at time A in the figure, the SNS automatically keeps the clock Lane running after
1932 transmitting the CSI-2 Frame End short packet and uses the USL protocol to enter USL_REV mode in order
1933 to enable the APP to start accessing SNS CCI registers. At this point, the APP may also wish to start an
1934 internal timer to warn it when the vblank period is about to end. At time B, when the APP is at least
1935 temporarily finished with CCI register accesses, the last access it performs is a write to the
1936 TX_USL_ALP_CTRL register (Table 27), for example, which commands the SNS to turn-off the clock Lane
1937 but also to expect a request to restart it at a later time. USL_REV mode is then maintained (with all D-PHY
1938 clock and data Lanes in the Stop state) until time C when the APP requests the clock Lane to be restarted by
1939 transmitting a short ALP Mode PHY-to-PHY Wake pulse to the SNS. In response, the SNS restarts the clock
1940 Lane and keeps it running while the APP performs more CCI accesses as needed. When finished at time D,
1941 the APP finally switches back to USL_FWD mode prior to the SNS having to transmit the Frame Start short
1942 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
PH
Next Frame
PF
hblank
KEY:
PH – Packet Header PF – Packet Footer
1943 FS – Frame Start FE – Frame End
Figure 87 Examples of USL ALP Mode Clock Lane Management During Sensor Vblank
1944 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
23-May-2022
9.12.5.7 USL Hard Standby Mode (Informative)

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

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

1958 Similar to legacy non-USL image sensors, USL supports SNS entry into soft standby mode by the APP
1959 writing to a CCI control register causing image streaming to be halted in an orderly manner. For USL, this
1960 CCI write operation must occur while in USL_REV mode during an hblank or vblank period. The APP then
1961 uses the USL protocol to switch back to USL_FWD mode, in order to enable the SNS to output all or part of
1962 the image frame that was in progress at the moment the control register was written, ending with all data
1963 Lanes in the Stop state (and the clock Lane still running in the D-PHY ALP Mode case). The SNS then
1964 switches to USL_REV mode to enable the APP to issue further commands to the SNS.
1965 Once streaming is halted, the APP can choose different courses of action. For example, if performing a time-
1966 critical SNS mode change, the APP can then immediately update the required SNS CCI registers, concluding
1967 the process by writing to a CCI control register that requests the restart of image streaming, and then
1968 switching back to USL_FWD mode using the USL protocol. Once returned to USL_FWD mode, and prior
1969 to actually restarting image streaming, the SNS may have to disable, reconfigure, and relock one or more
1970 internal PLLs, possibly requiring the SNS to automatically stop and restart the clock Lane, if applicable.
1971 Another possible course of action is for the APP to put the SNS into an extended sleep state while awaiting
1972 further commands from the APP. The preferred method for accomplishing this is for the APP to first transmit
1973 a PHY ULPS entry command to the SNS on Lane 1 followed by the SNS, in turn, transmitting the PHY
1974 ULPS entry command to the APP on all forward-direction data Lanes. This method is preferred because Lane
1975 1 remains in USL_REV mode throughout ULPS, thereby enabling the APP to subsequently transmit ULPS
1976 wakeup signaling to the SNS over Lane 1 when needed; this is also the reason why “reverse direction ULPS”
1977 support is recommended for both D-PHY and C-PHY Lane 1 in Section 7.3. With D-PHY ALP Mode, the
1978 SNS then stops the clock Lane and puts it into ULPS after all data Lanes have been put into ULPS. At this
1979 point, the SNS can internally power-down unnecessary circuitry while still retaining internal register states
1980 and remaining in USL_REV mode.
1981 For D-PHY ALP mode, ULPS wakeup while in soft standby mode requires the APP to transmit a long ALP
1982 Wake pulse to the SNS as described in [MIPI01]. Once the SNS starts receiving the latter pulse on data Lane
1983 1 (as signaled by the PPI, for example), it can then start transmitting a long ALP Wake pulse to the APP on
1984 each unidirectional data Lane, resulting in a total round-trip wakeup latency which is about the same as the
1985 latency in either the forward or reverse direction. The SNS also wakes-up the clock Lane to the Stop state
1986 and then restarts it in order to enable the APP to access SNS CCI registers.
1987 For C-PHY ALP mode, ULPS wakeup while in soft standby mode requires the APP to transmit an extended
1988 ALP-Pause Wake wire state to the SNS followed by an ALP “Stop” command as described in [MIPI02]. At
1989 this point, the SNS can similarly signal ULPS wakeup on each unidirectional Lane. However, this results in
1990 a total round-trip wakeup latency which is about the twice the latency in either the forward or reverse
1991 direction. The impact of this can be reduced or eliminated by the APP performing more transactions (e.g.,
1992 CCI register accesses) using Lane 1 while wakeup is in-progress on the other Lanes, effectively hiding the
1993 additional latency. Another possible solution is put either C-PHY Lane 1 or all the other Lanes into ULPS,
1994 but not both. For example, the APP could request ULPS by writing to a CCI control register using Lane 1;
1995 the SNS would then put all unidirectional Lanes into ULPS while leaving Lane 1 in the Stop state. Conversely,
1996 the APP could request ULPS by putting only Lane 1 into ULPS, with the SNS leaving all unidirectional Lanes
1997 in the Stop state.

Confidential
23-May-2022
9.13 Data Scrambling

1998 The purpose of Data Scrambling is to mitigate the effects of EMI and RF self-interference by spreading the
1999 information transmission energy of the Link over a possibly large frequency band, using a data randomization
2000 technique. The scrambling feature described in this Section is optional and normative: If a CSI-2
2001 implementation includes support for scrambling, then the scrambling feature shall be implemented as
2002 described in this Section. The benefits of data scrambling are well-known, and it is strongly recommended
2003 to implement this data scrambling capability in order to minimize radiated emissions in the system.
2004 Data Scrambling shall be applied on a per-Lane basis, as illustrated in Figure 88. Each output of the Lane
2005 Distribution Function shall be individually scrambled by a separate scrambling function dedicated to that
2006 Lane, before the Lane data is sent to the PHY function over the Tx PPI.
Tx Rx
Per-Lane Scrambling 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

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

Stream
Scrambling Stream (Tx→Chan→Rx) Scrambling Stream
2007
Figure 88 System Diagram Showing Per-Lane Scrambling

Confidential
23-May-2022
9.13.1 CSI-2 Scrambling for D-PHY

2008 Figure 89 shows the format of a burst transmission of two packets over two Lanes when the D-PHY physical
2009 layer is used. After the Start of Transmission, HS-ZERO and HS-SYNC are transmitted, the Packet Header
2010 and data payload are distributed across the two Lanes.
2011 If the D-PHY physical layer is used, then the scrambler Linear Feedback Shift Register (LFSR) in each Lane
2012 shall be initialized with the Lane seed value under any of the following conditions:
2013 1. At the beginning of the burst, which occurs immediately prior to the first byte transmitted
2014 following the HS-Sync that is generated by the D-PHY (applicable to both D-PHY EPD Option1
2015 and Option 2).
2016 2. Prior to the first byte transmitted following the HS-Sync that is generated whenever the optional
2017 D-PHY EPD Option 1 HS-Idle is transmitted.
2018 The scrambler is not reinitialized between CSI-2 packets when using the optional D-PHY EPD Option 2.
2019 When the scrambler is initialized, the LFSR shall be initialized using the sixteen-bit seed value assigned to
2020 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
2021 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
23-May-2022
9.13.2 CSI-2 Scrambling for C-PHY

2022 Figure 90 shows the format of a burst transmission of two packets over two Lanes when the C-PHY physical
2023 layer is used. After the Start of Transmission, Preamble, and Sync are transmitted, the Packet Header is
2024 replicated twice on each Lane, and data payloads of each packet are distributed across the two Lanes. If the
2025 C-PHY physical layer is used, then the scrambler LFSR in each Lane shall be initialized at the beginning of
2026 every Long Packet Header or Short Packet, using one of the sixteen-bit seed values assigned to each Lane.
2027 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]
2028 Note: The Packet Footer at the end of every packet is scrambled.
Figure 90 Example of Data Bursts in Two Lanes Using the C-PHY Physical Layer
2029 In some cases, images may cause repetitive transmission of Long Packets having the same or similar Long
2030 Packet Header and the same pixel data (for example: all dark pixels, or all white pixels). If the scrambler is
2031 initialized with the same seed value at the beginning of every packet, coinciding with the beginning of every
2032 pixel row, then the scrambled pseudo-random sequence will repeat at the rate that rows of identical image
2033 data are transmitted. This can cause the emissions to be less random, and instead have peaks at frequencies
2034 equivalent to the rate at which the image data rows are transmitted.
2035 To mitigate this issue, a different seed value is selected by the transmitter every time a Packet Header is
2036 transmitted. The Sync Word in the Packet Header encodes a small amount of data, so that the transmitter can
2037 inform the receiver which starting seed to use to descramble the packet. This small amount of data in the
2038 Sync Word is sent by transmitting a Sync Type that the CSI-2 protocol transmitter chooses. This Sync Type
2039 value is also used to select the starting seed in the scrambler and descrambler.

Confidential
23-May-2022
2040 Table 28 shows the five possible Sync Types that the C-PHY supports. The Sync Word values are normatively
2041 specified in the C-PHY Specification and duplicated in Table 28 for convenience. The CSI-2 protocol uses
2042 only the first four out of the five possible Sync Types, which simplifies the implementation.
2043 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
2044 Note:
2045 When a single seed value is used, Sync Type 3 is the default Sync Word value.
2046 Figure 91 shows the architecture of the scrambling in a single Lane. The pseudo-random number generated
2047 by the PRBS shall be used as the seed index to select the initial seed value from the seed list prior to sending
2048 the packet. This seed index shall also be sent to the C-PHY using the PPI signals TxSyncTypeHS0[1:0].
2049 TxSyncTypeHS0[2] is always zero. TxSyncTypeHS1 [2:0] is used similarly for a 32-bit data path. The C-
2050 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]
2051
Figure 91 Generating Tx Sync Type as Seed Index (Single Lane View)
2052 The seed list may contain either one or four initial seed values. Transmitters and receivers shall have the
2053 capability to select exactly one seed value from a list of seeds. When a single seed value is used, that seed
2054 shall be identified as Seed 3 and the transmitter shall always transmit Sync Type 3. Transmitters and receivers
2055 should also have the capability to select a seed value from a list of four seed values, as shown in Figure 91.
2056 When a list of four seed values is used then Sync Type 0 through Sync Type 3 shall be used to convey the
2057 seed index value from the transmitter to the receiver.
2058 When the list of four seeds is used, the two-bit seed index shall be generated in the transmitter using a pseudo
2059 random generator (e.g., PRBS).
2060 Slight differences in the implementation of the PRBS generator will not affect the interoperability of the
2061 transmitter and receiver, because the receiver responds to the seed index chosen in the transmitter and
2062 conveyed to the receiver using the Sync Type.
2063 At the receiver, the C-PHY decodes the Sync Word and passes the 2-bit Sync Type value to the CSI-2 protocol
2064 logic. The CSI-2 protocol logic uses the two-bit value as a seed index to select one of four seed values to

Confidential
23-May-2022
2065 initialize the descrambler. This concept is shown in the single Lane diagram in Figure 91. Figure 88 shows
2066 the use of the PPI signals to select which seed value was used to initialize the scrambler and descrambler.
2067 Since the seed selection field is transmitted via the Sync Word, no other mechanism is needed to coordinate
2068 the choice of specific descrambler initial seed values at the receiver.
Per-Lane Scrambling Tx Rx
Tx PPI Rx PPI
Stream
Scrambling Stream Stream
(Tx→Chan→Rx) Scrambling Stream
Lane Distribution
PRBS TxSyncTypeHS0[2:0] RxSyncTypeHS0[2:0]
Lane Merge
Function
Function
CSI-2 CSI-2
Byte Word Word Lane 2 C-PHY Word De- Word Byte
Protocol Stream Stream
Protocol
(Tx→Chan→Rx) Scrambling Stream Stream
Tx Rx

Stream
(Tx→Chan→Rx) Scrambling Stream
2069
Figure 92 Generating Tx Sync Type Using the C-PHY Physical Layer

Confidential
23-May-2022
9.13.3 Scrambling Details

2070 The Long Packet Header, Data Payload, Long Packet Footer (which may include a Filler Byte), and Short
2071 Packets shall be scrambled. Special data fields generated by the PHY that are beyond the control of the CSI-
2072 2 protocol shall not be scrambled. For clarity, Table 29 lists all of the fields that are not scrambled.
2073 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
2074 The data scrambler and descrambler pseudo-random binary sequence (PRBS) shall be generated using the
2075 Galois form of an LFSR implementing the generator polynomial:
2076 G(x) = x16 + x5 + x4 + x3 + 1
2077 The initial D-PHY seed values in Table 30 should be used to initialize the D-PHY scrambler LFSR in Lanes
2078 1 through 8.
2079 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
2080

Confidential
23-May-2022
2081 The initial C-PHY seed values in Table 31 should be used to initialize the C-PHY scrambler LFSR in Lanes
2082 1 through 8. The table provides initial seed values for each of the four possible Sync Type values per Lane
2083 number. If only a single Sync Type is used, then it shall default to Sync Type 3.
2084 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
2085 For D-PHY and C-PHY systems requiring more than eight Lanes, Annex G provides 24 additional seed
2086 values for Lanes 9 through 32, as well as a mechanism for finding seed values for Lanes 33 and higher. For
2087 each seed value, the LSB corresponds to scrambler PRBS register bit Q0 and the MSB corresponds to bit
2088 Q15.
2089 The LFSR shall generate an eight-bit sequence at G(x) for every byte of Payload data to be scrambled, starting
2090 from its initial seed value. The LFSR shall generate new bit sequences of G(x) by advancing eight bit cycles
2091 for each subsequent Payload data byte.
2092 Scrambling shall be achieved by modulo-2 bit-wise addition (X-OR) of a sequence of eight bits G(x) with
2093 the CSI-2 Payload data to be scrambled.

Confidential
23-May-2022
2094 Implementation Tip: the 8-bit value from the PRBS is the flip of bits Q15:Q8 of the PRBS LFSR register on
2095 every 8th bit clock. The designer might choose to implement the PRBS LFSR in parallel form to shift the
2096 equivalent of 8 places in a single byte clock, or the PRBS LFSR might even be configured to shift a multiple
2097 of 8 places in a single word clock.
2098 For the example shown in Figure 93, Q[15:8] are captured in a temporary register, then the PRBS LFSR is
2099 shifted eight times before Q[15:8] are captured again. The scrambling is performed as follows:
2100 • TxD[7] = PktD[7]  Q’[8];
2101 • TxD[6] = PktD[6]  Q’[9];
2102 • TxD[5] = PktD[5]  Q’[10];
2103 • TxD[4] = PktD[4]  Q’[11];
2104 • TxD[3] = PktD[3]  Q’[12];
2105 • TxD[2] = PktD[2]  Q’[13];
2106 • TxD[1] = PktD[1]  Q’[14];
2107 • 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
SET SET SET SET SET SET SET SET

D Q D Q D Q D Q D Q D Q D Q D Q
CLR CLR CLR CLR CLR CLR CLR CLR

Byte Clock
PRBS LFSR

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

Confidential
23-May-2022
2109 Table 32 illustrates the sequence of the PRBS register one bit at a time, starting with the initial seed value for
2110 Lane 2. The data scrambling sequence is the output G(x). The first bit output from the scrambler is the value
2111 output from G(x) (also Q15 of the register in Figure 93) when the register contains the initial seed value.
2112 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
2113 Table 33 shows the first ten PRBS Byte Outputs produced by the PRBS LFSR in Lane 2 when the D-PHY
2114 physical layer is being used.
2115 Table 33 Example PRBS LFSR Byte Sequence for D-PHY Physical Layer
Scrambling Sequence PRBS Register PRBS Byte Input Byte Output Byte
Byte #Byte 0
Initial Seed, 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
23-May-2022
2116 Table 34 shows an example of the PRBS Word Outputs at the beginning of a packet, that are produced by the
2117 PRBS LFSR in Lane 2 when the C-PHY physical layer is being used. In this example, the initial seed value
2118 used for transmitting the first copy of the packet header corresponds to Sync Type 3 for Lane 2. The initial
2119 seed value used for transmitting the second copy of the packet header corresponds to Sync Type 0 for Lane
2120 2. As described in Section 9.13.2, the C-PHY ensures that the very first packet in a burst begins with a Sync
2121 Type 3 sync word. For all subsequent sync words transmitted in a burst, such as when LRTE is enabled, the
2122 CSI-2 protocol layer selects any of Sync Type 0 through Sync Type 3.
2123 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] 0x1188 0xd188 0x2b00 0xfa88
Header[31:16] 0xb403 0xd82d 0x13b0 0xcb9d
Header[15:0] 0xd613 0x406b 0x31c8 0x71a3
Sync Word 0xc672 0x0663 0xxxxx
0xxxxx
(see Note 1 below)
Re-initialized Seed, Header[47:32] 0x0990 0x8990 0x2b00 0xa290
Header[31:16] 0xee29 0xbc77 0x13b0 0xafc7
Header[15:0] 0xbba5 0x3ddd 0x31c8 0x0c15
Word 0 0xaa1c 0x6055 0xd000 0xb055
Word 1 0x1a96 0x2958 0x1360 0x3a38
Word 2 0x35f4 0x0fac 0x094c 0x06e0
Word 3 0x7b70 0xdede 0x100b 0xced5
Word 4 0x7873 0x1e1e 0x5fb8 0x41a6
Word 5 0x3338 0x3ccc 0xd030 0xecfc
Word 6 0xfe9c 0xd17f 0x0003 0xd17c
Word 7 0x3303 0xe0cc 0xd039 0x30f5
Word 8 0xfbaf 0x1ddf 0xa35b 0xbe84
Word 9 0xeaf8 0x3757 0x00ea 0x37bd
2124 Note:
1. The Output Word is irrelevant in this word clock cycle because the CSI-2 protocol layer asserts one
of the TxSendSyncHS PPI signals with a valid selection on the corresponding TxSyncTypeHS
signals to transmit a sync word instead of a scrambled data word.

Confidential
23-May-2022
9.14 Smart Region of Interest (SROI)

2125 The Smart Region of Interest (SROI) feature supports the adaptive transfer of rectangular Regions of Interest
2126 (ROI). SROI can be used to reduce data bandwidth by selectively transmitting one or more smaller ROIs
2127 carved out from the original picture, such as a human face or a license plate. SROI has use cases in cameras
2128 for computer vision, and machine vision applications beyond mobile markets including industry,
2129 surveillance, and IoT.
2130 In addition to reducing data bandwidth, SROI benefits include:
2131 • High Frame Rate / Low Latency: Data reduction can increase the sensor frame rate and reduce
2132 processing workloads for application processors.
2133 • High Resolution: A high-resolution image can be extracted by capturing the necessary
2134 information without increasing the amount of data transferred.
2135 • Low Power Dissipation: Processing workload reductions can save system power.
2136 Product platforms may facilitate SROI capability using:
2137 1. Integrated SROI (ISROI) System (Figure 94): By integrating Vision Digital Signal Predecessor
2138 (VDSP) within a multi-stack image sensor module (SNS) to generate SROI data.
2139 2. External SROI (ESROI) System (Figure 95): By utilizing an external SROI VDSP component or
2140 integrated VDSP within an APP to generate SROI data.
V
D CSI-2 SROI Frame
SNS S APP
P
2141
Figure 94 ISROI System Supporting Multi-Stack SNS with Integrated SROI VDSP
V
CSI-2 Frame D CSI-2 SROI Frame
SNS S APP
P
2142
Figure 95 ESROI System Supporting Standard SNS with an External SROI VDSP

Confidential
23-May-2022
9.14.1 Overview of SROI Frame Format

2143 As shown in Figure 96, each rectangular ROI is defined by position (X, Y coordinates of ROI rectangle
2144 upper left-hand corner pixel), size (Height and Width of ROI rectangle, in pixels), and other metadata (e.g.,
2145 ADC bit depth; see Table 37).
2146 Each ROI has corresponding a ROI Information field with values for position, size, and other items (see
2147 Section 9.14.5). ROI Information values either are determined by a detection function integrated into an APP
2148 or image sensor, or for some use cases such as factory automation are set in advance. The method of detecting
2149 an ROI is out of scope for this specification.
2150 The maximum number of ROI is also out of scope for this specification, because it is implementation-
2151 specific. However, prior to the SROI transfer the application processor and the image sensor shall agree on
2152 both the maximum number of ROI and the ROI ID format in Table 37. ROI ID (1 byte) and ROI ID (2 byte)
2153 cannot both coexist.
2154 SROI Frames use three data packet types:
2155 • SROI Short Packet is used for transmitting a Frame Start (FS) Packet and a Frame End (FE)
2156 Packet in an image frame with the SROI Long Packet.
2157 If Line synchronization packets are needed, then Line Start (LS) Packets and Line End (LE)
2158 Packets are also permitted as SROI Short Packets.
2159 • SROI Embedded Data Packet is used for transmitting ROI Information, as detailed in
2160 Section 9.14.5.
2161 If the SROI Embedded Data Packet is present in an image frame, it shall be located at the
2162 beginning of the image frame.
2163 • SROI Long Packet (excludes the SROI Embedded Data Packet) is used for transmitting ROI
2164 image data for an image frame.
2165 The SROI Long Packet should use the same image Data Type used to transmit the image frame’s
2166 normal, non-SROI image lines (e.g., RAW10), however a User-Defined Data Type is also
2167 permitted. For SROI transfers, it is not required for all SROI Long Packets within a given image
2168 frame to have equal length.
2169 When there are multiple ROIs within one line of original image data, all ROI data shall be merged
2170 together into a single SROI Long Packet, with no blanking between the regions. See example of
2171 A(0) and D(0) in Figure 96.
2172 Any image region overlapped by multiple ROIs, for example A(n-2) and B(0) in Figure 96, shall
2173 be transmitted only once (i.e., shall not be transmitted multiple times, one per ROI). As a result,
2174 each overlapped image region shall be counted only once when calculating the value of the SROI
2175 Long Packet Word Count field (i.e., shall not be counted multiple times, one per ROI).
2176 The term SROI Packet means any SROI Short Packet, SROI Embedded Data Packet, or SROI Long Packet.

Confidential
23-May-2022
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
2177
Figure 96 SROI Frame Format Example

Confidential
23-May-2022
9.14.2 Transmission of SROI Embedded Data Packet

2178 This Section specifies when the image sensor is required to send the SROI Embedded Data Packet (SEDP)
2179 in the image frame.
2180 This depends upon whether the application processor (APP) knows, vs. does not know, all required ROI
2181 Information (see Table 35). When the image sensor does send the SEDP, the AP’s method of detecting SROI
2182 Packets depends upon the SROI Packet Option (Option 1 vs. Option 2, see Section 9.14.3) that the AP and
2183 image sensor have agreed to use.
2184 • If the application processor is aware of all ROI information, then the VDSP may be configured
2185 by the APP to optionally transmit the SEDP.
2186 If SEDP is sent and SROI Packet Option 1 is used, then the APP can detect SROI Packets in the
2187 image frame by inspecting the Virtual Channel value (see Section 9.14.3.1).
2188 • If the application processor is unaware of ROI information, then the VDSP shall generate the
2189 ROI data.
2190 The VDSP supporting SROI shall support a 16-bit control register, REG_SROI_CONTROL[15:0].
2191 The SROI features and capabilities are detailed in the sections below. The unused bits are reserved
2192 for future developments.
2193 The following four bits are used to configure the ROI data generation by the VDSP:
2194 • REG_SROI_CONTROL[0] (field SROI_EN) shall be used to enable SROI capability:
2195 • 1’b0: Disable SROI
2196 • 1’b1: Enable SROI
2197 • REG_SROI_CONTROL[1] (field ROI_AWARE) shall be used to select APP or VDSP as the ROI
2198 aware generator:
2199 • 1’b0: APP is not aware of the ROI. Enable VDSP to internally generate and transmit the
2200 SROI.
2201 • 1’b1: APP is aware of the ROI. Enable VDSP to transmit SROI predetermined by APP.
2202 • REG_SROI_CONTROL[4:3] (field ROI_GEN) shall be used to configure the ROI data
2203 generation:
2204 • 2’b00: VDSP generates ROI Meta Data (SEDP.)
2205 • 2’b01: VDSP generates ROI Meta Data (SEDP) with the captured CSI-2 frame
2206 • 2’b10: VDSP generates ROI Meta Data (SEDP) and ROI Pixel Data
2207 • 2’b11: VDSP generates ROI Meta Data (SEDP) and ROI Pixel Data with the captured CSI-2
2208 frame
2209 The method the APP uses to detect SROI Packets in an image frame depends upon which SROI
2210 Packet Option is in use: by Virtual Channel for Option 1 (see Section 9.14.3.1), or by Data Type
2211 for Option 2 (see Section 9.14.3.2). The VDSP shall transport ROI data using a predefined Data
2212 Type or a VC.
2213 • REG_SROI_CONTROL[2] (field DT_VC_SEL) shall be used to transmit ROI data using DT or
2214 VC:
2215 • 1’b0: VDSP transports ROI Meta Data and Pixel Data using Data Type.
2216 • 1’b1: VDSP transports ROI Meta Data and Pixel Data using a unique VC.
2217 • REG_SROI_CONTROL[15:8] (field UNIQUE_SROI_ID) shall be used to configure DT or VC
2218 for SROI generation by VDSP.
2219 • REG_SROI_CONTROL[7:5] bits are reserved for future use.
2220 Example use cases are shown in Section 9.14.4.

Confidential
23-May-2022
2221 Table 35 Transmission of SROI Embedded Data Packet

APP Knowledge of All Required ROI Information
APP Knows APP Does Not Know
(See Section 9.14.4.1) (See Section 9.14.4.2)
SEDP Required No Yes
Option 1 APP either
SROI Packet Option
APP 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 APP can detect
(See Section 9.14.3.2) SROI Packet
APP knows SROI Packet
by Data Type

Confidential
23-May-2022
9.14.3 SROI Packet Detection Options

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

2226 Option 1 distinguishes SROI Packets from non-SROI packets by using a different Virtual Channel value.
2227 For Option 1, all SROI Packets for a given image frame shall use the same Virtual Channel, and this SROI
2228 Virtual Channel shall be different from the Virtual Channel used in the image frame’s non-SROI Packets (see
2229 Figure 97). Virtual Channel Interleaving may be used.
2230 An image frame that includes SROI Packets may use Data Type Interleaving, but only if the Data Type used
2231 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)
2232
Figure 97 SROI Packet Option 1

Confidential
23-May-2022
9.14.3.2 SROI Packet Option 2

2233 Option 2 distinguishes SROI Packets from non-SROI packets by Data Type; in particular, by detecting the
2234 presence of the SROI Embedded Data Packet in the image frame.
2235 For Option 2, all SROI Packets for a given image frame shall use the same Virtual Channel that the non-
2236 SROI Packets use (see Figure 98).
2237 An image frame that includes SROI Packets may use Data Type Interleaving, but only if the Data Type used
2238 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)
2239
Figure 98 SROI Packet Option 2

Confidential
23-May-2022
9.14.4 SROI Use Cases (Informative)

2240 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

2241 If the APP is responsible for detecting an ROI, or has ROI information that is set in advance, then the image
2242 sensor is not required to transmit the SROI Embedded Data Packet. An example is shown in Figure 99.
2243 In this use case, the APP detects a ROI (e.g., a human face), and then sends the ROI’s position and size to an
2244 image sensor through the CCI (see Section 6). The image sensor then just carves out the ROI, based on the
2245 ordered position and size, and then keeps sending SROI Long Packets for the same image region.
2246 In this case the SROI Embedded Data Packet is not transmitted, because it would be unnecessary: the APP
2247 already knows all ROI information (e.g., the ROI position and size) required to receive 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

2248
Figure 99 Use Case 1: SROI Embedded Data Packet Not Transmitted

Confidential
23-May-2022
9.14.4.2 Use Case 2: ROI Detection by the Image Sensor

2249 If the image sensor is responsible for detecting an ROI, then the image sensor is required to transmit the
2250 SROI Embedded Data Packet as illustrated in Figure 100.
2251 The APP orders the image sensor to get an ROI (e.g., a human face). The image sensor detects the ROI and
2252 carves it out, and then keeps tracking the ROI.
2253 In this case the SROI Embedded Data Packet is (and must be) transmitted, because the APP doesn’t know all
2254 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

2255
Figure 100 Use Case 2: SROI Embedded Data Packet Is Transmitted

Confidential
23-May-2022
9.14.5 Format of SROI Embedded Data Packet (SEDP)

2256 For SROI transfers, the Embedded Data Format is based on the definition in the MIPI CCS specification
2257 [MIPI04]. The Embedded Data Format Code for SROI frames is 0x0D (1 byte).
2258 The SROI Embedded Data Packet (see Figure 101) is composed of multiple ROI Information fields, each
2259 containing ROI Information about one extracted image region. Every ROI Information field shall start with
2260 the ROI ID, followed by the ROI Element Information field defined by Table 36. Table 37 defines the
2261 allocation and assignment of values for the Type ID sub-field used in the ROI Element Information field.
2262 At the end of the embedded data line, the End of Line shall be inserted after the end of the last ROI
2263 Information field.
2264 The length of the SROI Embedded Data Packet line shall not exceed the length of the full-resolution image
2265 data line. After the End of Line, the remainder of the line should be padded with 0x07 characters if the SROI
2266 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
2267
Figure 101 SROI Embedded Data Packet Format
2268 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
23-May-2022
2269 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
23-May-2022
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
23-May-2022
9.15 Packet Data Payload Size Rules

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

Confidential
23-May-2022
9.16 Frame Format Examples

2283 This is an informative section.
2284 This section contains three examples to illustrate how the CSI-2 features can be used.
2285 • General Frame Format Example, Figure 102
2286 • Digital Interlaced Video Example, Figure 103
2287 • Digital Interlaced Video with accurate synchronization timing information, Figure 104
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:
2288
Figure 102 General Frame Format Example

Confidential
23-May-2022
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:
2289
Figure 103 Digital Interlaced Video Example

Confidential
23-May-2022
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:
2290
Figure 104 Digital Interlaced Video with Accurate Synchronization Timing Information

Confidential
23-May-2022
9.17 Data Interleaving

2291 The CSI-2 supports the interleaved transmission of different image data formats within the same video data
2292 stream.
2293 There are two methods to interleave the transmission of different image data formats:
2294 • Data Type
2295 • Virtual Channel Identifier
2296 The preceding methods of interleaved data transmission can be combined in any manner.
9.17.1 Data Type Interleaving

2297 The Data Type value uniquely defines the data format for that packet of data. The receiver uses the Data Type
2298 value in the packet header to de-multiplex data packets containing different data formats as illustrated in
2299 Figure 105. Note, in the figure the Virtual Channel Identifier is the same in each Packet Header.
2300 The packet payload data format shall agree with the Data Type code in the Packet Header as follows:
2301 • For defined image data types – any non-reserved codes in the range 0x18 to 0x3F – only the single
2302 corresponding MIPI-defined packet payload data format shall be considered correct
2303 • Reserved image data types – any reserved codes in the range 0x18 to 0x3F – shall not be used. No
2304 packet payload data format shall be considered correct for reserved image data types
2305 • For generic long packet data types (codes 0x10 thru 0x17) and user-defined, byte-based (codes
2306 0x30 – 0x37), any packet payload data format shall be considered correct
2307 • Generic long packet data types (codes 0x10 thru 0x17) and user-defined, byte-based (codes 0x30 –
2308 0x37), should not be used with packet payloads that meet any MIPI image data format definition
2309 • Synchronization short packet data types (codes 0x00 thru 0x07) shall consist of only the header
2310 and shall not include payload data bytes
2311 • Generic short packet data types (codes 0x08 thru 0x0F) shall consist of only the header and shall
2312 not include payload data bytes
2313 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)
2314
Figure 105 Interleaved Data Transmission using Data Type Value
2315 All of the packets within the same virtual channel, independent of the Data Type value, share the same frame
2316 start/end and line start/end synchronization information. By definition, all of the packets, independent of data

Confidential
23-May-2022
2317 type, between a Frame Start and a Frame End packet within the same virtual channel belong to the same
2318 frame.
2319 Packets of different data types may be interleaved at either the packet level as illustrated in Figure 106 or
2320 the frame level as illustrated in Figure 107. 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
2321
PF – Packet Footer + Filler (if applicable)
Figure 106 Packet Level Interleaved Data Transmission

Confidential
23-May-2022
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
2322
PF – Packet Footer + Filler (if applicable)
Figure 107 Frame Level Interleaved Data Transmission

Confidential
23-May-2022
9.17.2 Virtual Channel Identifier Interleaving

2323 The Virtual Channel Identifier allows different data types within a single data stream to be logically separated
2324 from each other. Figure 108 illustrates data interleaving using the Virtual Channel Identifier.
2325 Each virtual channel has its own Frame Start and Frame End packet (except for virtual channels used
2326 exclusively with USL Packets; see Section 9.12). Therefore, it is possible for different virtual channels to
2327 have different frame rates, though the data rate for both channels would remain the same.
2328 In addition, Data Type value Interleaving can be used for each virtual channel, allowing different data types
2329 within a virtual channel and a second level of data interleaving.
2330 Therefore, receivers should be able to de-multiplex different data packets based on the combination of the
2331 Virtual Channel Identifier and the Data Type value. For example, data packets containing the same Data Type
2332 value but transmitted on different virtual channels are considered to belong to different frames (streams) of
2333 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)
2334
Figure 108 Interleaved Data Transmission using Virtual Channels

Confidential
23-May-2022

Confidential
23-May-2022
10 Color Spaces
2335 The color space definitions in this section are simply references to other standards. The references are
2336 included only for informative purposes and not for compliance. The color space used is not limited to the
2337 references given.
10.1 RGB Color Space Definition

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

2343 In this Specification, the abbreviation YUV refers to the 8-bit gamma corrected Y'CBCR color space defined
2344 in ITU-R BT601.4.

Confidential
23-May-2022

Confidential
23-May-2022
11 Data Formats
2345 The intent of this section is to provide a definitive reference for data formats typically used in CSI-2
2346 applications. Table 38 summarizes the formats, followed by individual definitions for each format. Generic
2347 data types not shown in the table are described in Section 11.1. For simplicity, all examples are single Lane
2348 configurations.
2349 The formats most widely used in CSI-2 applications are distinguished by a “primary” designation in Table
2350 38. Transmitter implementations of CSI-2 should support at least one of these primary formats. Receiver
2351 implementations of CSI-2 should support all of the primary formats.
2352 The packet payload data format shall agree with the Data Type value in the Packet Header. See Section 9.4
2353 for a description of the Data Type values.
2354 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
RAW28 – 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
23-May-2022
2355 For clarity the Start of Transmission and End of Transmission sequences in the figures in this section have
2356 been omitted.
2357 The balance of this section details how sequences of pixels and other application data conforming to each of
2358 the data types listed in Table 38 are converted into equivalent byte sequences by the CSI-2 Pixel to Byte
2359 Packing Formats layer shown in Figure 3.
2360 Various figures in this section depict these byte sequences as shown at the top of Figure 109, where Byte n
2361 always precedes Byte m for n < m. Also note that even though each byte is shown in LSB-first order, this is
2362 not meant to imply that the bytes themselves are bit-reversed by the Pixel to Byte Packing Formats layer
2363 prior to output.
2364 For the D-PHY physical layer option, each byte in the sequence is serially transmitted LSB-first, whereas for
2365 the C-PHY physical layer option, successive byte pairs in the sequence are encoded and then serially
2366 transmitted LSS-first. Figure 109 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, ...
first
2367
Figure 109 Byte Packing Pixel Data to C-PHY Symbol Illustration

Confidential
23-May-2022
11.1 Generic 8-bit Long Packet Data Types

2368 Table 39 defines the generic 8-bit Long packet data types.
2369 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

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

Confidential
23-May-2022
11.1.2 Embedded Information

2374 It is possible to embed extra lines containing additional information to the beginning and to the end of each
2375 picture frame as presented in the Figure 110. If embedded information exists, then the lines containing the
2376 embedded data must use the embedded data code in the data identifier.
2377 There may be zero or more lines of embedded data at the start of the frame. These lines are termed the frame
2378 header.
2379 There may be zero or more line of embedded data at the end of the frame. These lines are termed the frame
2380 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
2381
Figure 110 Frame Structure with Embedded Data at the Beginning and End of the Frame
11.1.3 Generic Long Packet Data Types 1 Through 4

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

Confidential
23-May-2022
11.2 YUV Image Data

2384 Table 40 defines the data type codes for YUV data formats described in this section. The number of lines
2385 transmitted for the YUV420 data type shall be even.
2386 YUV420 data formats are divided into legacy and non-legacy data formats. The legacy YUV420 data format
2387 is for compatibility with existing systems. The non-legacy YUV420 data formats enable lower cost
2388 implementations.
2389 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

Confidential
23-May-2022
11.2.1 Legacy YUV420 8-bit

2390 Legacy YUV420 8-bit data transmission is performed by transmitting UYY… / VYY… sequences in odd /
2391 even lines. U component is transferred in odd lines (1, 3, 5 …) and V component is transferred in even lines
2392 (2, 4, 6 …). This sequence is illustrated in Figure 111.
2393 Table 41 specifies the packet size constraints for YUV420 8-bit packets. Each packet must be a multiple of
2394 the values in the table.
2395 Table 41 Legacy YUV420 8-bit Packet Data Size Constraints
Pixels Bytes Bits
2 3 24
2396 Bit order in transmission follows the general CSI-2 rule, LSB first. The pixel to byte mapping is illustrated
2397 in Figure 112.
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
2398
(Even Line)
Figure 111 Legacy YUV420 8-bit Transmission
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
2399
Figure 112 Legacy YUV420 8-bit Pixel to Byte Packing Bitwise Illustration

Confidential
23-May-2022
2400 There is one spatial sampling option

2401 • H.261, H.263 and MPEG1 Spatial Sampling (Figure 113).
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

2402
Figure 113 Legacy YUV420 Spatial Sampling for H.261, H.263 and MPEG 1
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
Packet Header, PH
V Y Y V Y Y …. V Y Y Packet Footer, PF
V Y Y V Y Y …. V Y Y FE
2403
Figure 114 Legacy YUV420 8-bit Frame Format

Confidential
23-May-2022
11.2.2 YUV420 8-bit

2404 YUV420 8-bit data transmission is performed by transmitting YYYY… / UYVYUYVY… sequences in odd
2405 / even lines. Only the luminance component (Y) is transferred for odd lines (1, 3, 5…) and both luminance
2406 (Y) and chrominance (U and V) components are transferred for even lines (2, 4, 6…). The format for the
2407 even lines (UYVY) is identical to the YUV422 8-bit data format. The data transmission sequence is illustrated
2408 in Figure 115.
2409 The payload data size, in bytes, for even lines (UYVY) is double the payload data size for odd lines (Y). This
2410 is an exception to the general CSI-2 rule that each line shall have an equal length.
2411 Table 42 specifies the packet size constraints for YUV420 8-bit packets. Each packet must be a multiple of
2412 the values in the table.
2413 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
2415 in Figure 116.
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]
(Even Line) Footer
2416
Figure 115 YUV420 8-bit Data Transmission Sequence

Confidential
23-May-2022
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)


2417
Figure 116 YUV420 8-bit Pixel to Byte Packing Bitwise Illustration
2418 There are two spatial sampling options

2419 • H.261, H.263 and MPEG1 Spatial Sampling (Figure 117).
2420 • Chroma Shifted Pixel Sampling (CSPS) for MPEG2, MPEG4 (Figure 118).
2421 Figure 119 shows the YUV420 frame format.

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

2422
Figure 117 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

2423
Figure 118 YUV420 Spatial Sampling for MPEG 2 and MPEG 4

Confidential
23-May-2022
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
Packet Header, PH
…. ….
Packet Footer, PF
Packet Footer, PF
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 FE
Odd lines (1, 3, 5, ..): Even lines (2, 4, 6, ..):

Luminance only, Y Luminance and Chrominance, UYVY
2424
Figure 119 YUV420 8-bit Frame Format

Confidential
23-May-2022
11.2.3 YUV420 10-bit

2425 YUV420 10-bit data transmission is performed by transmitting YYYY… / UYVYUYVY… sequences in
2426 odd / even lines. Only the luminance component (Y) is transferred in odd lines (1, 3, 5…) and both luminance
2427 (Y) and chrominance (U and V) components transferred in even lines (2, 4, 6…). The format for the even
2428 lines (UYVY) is identical to the YUV422 –10-bit data format. The sequence is illustrated in Figure 120.
2429 The payload data size, in bytes, for even lines (UYVY) is double the payload data size for odd lines (Y). This
2430 is an exception to the general CSI-2 rule that each line shall have an equal length.
2431 Table 43 specifies the packet size constraints for YUV420 10-bit packets. The length of each packet must be
2432 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
2434 Bit order in transmission follows the general CSI-2 rule, LSB first. The pixel-to-byte mapping is illustrated
2435 in Figure 121.
LSB’s
Line Start: Packet Y4 Y3 Y2 Y1

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

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

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

Confidential
23-May-2022
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
2437
2438 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
Packet Header, PH
Packet Header, PH
…. ….
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
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, ..):

2439
Luminance only, Y Luminance and Chrominance, UYVY

Confidential
23-May-2022
11.2.4 YUV422 8-bit

2440 YUV422 8-bit data transmission is performed by transmitting a UYVY sequence. This sequence is illustrated
2441 in Figure 123.
2442 Table 44 specifies the packet size constraints for YUV422 8-bit packet. The length of each packet must be a
2443 multiple of the values in the table.
Pixels Bytes Bits
2 4 32
2446 in Figure 124.
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

2447
Figure 123 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
2448

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

2449
Figure 125 YUV422 Co-sited Spatial Sampling
2450 The pixel spatial alignment is the same as in CCIR-656 standard. The frame format for YUV422 is presented
2451 in Figure 126.
FS U Y V Y U …. Y U Y V Y
U Y V Y U …. Y U Y V Y
Packet Header, PH
….
Packet Footer, PF
U Y V Y U Y U Y V Y
U Y V Y U …. Y U Y V Y FE
2452

Confidential
23-May-2022
11.2.5 YUV422 10-bit

2453 YUV422 10-bit data transmission is performed by transmitting a UYVY sequence. This sequence is
2454 illustrated in Figure 127.
2455 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
2459 in Figure 128.
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

2460
Figure 127 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
2461
2462 The pixel spatial alignment is the same as in the YUV422 8-bit data case. The frame format for YUV422 is
2463 presented in Figure 129.

Confidential
23-May-2022
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
U Y V Y LSBs U …. U Y V Y LSBs FE
2464

Confidential
23-May-2022
11.3 RGB Image Data

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

Confidential
23-May-2022
11.3.1 RGB888
2467 RGB888 data transmission is performed by transmitting a BGR byte sequence. This sequence is illustrated
2468 in Figure 130. The RGB888 frame format is illustrated in Figure 132.
2469 Table 47 specifies the packet size constraints for RGB888 packets. The length of each packet must be a
2471 Table 47 RGB888 Packet Data Size Constraints
Pixels Bytes Bits
1 3 24
2473 in Figure 131.
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
2474
Figure 130 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
2475
Figure 131 RGB888 Transmission in CSI-2 Bus Bitwise Illustration

Confidential
23-May-2022
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
2476
Figure 132 RGB888 Frame Format

Confidential
23-May-2022
11.3.2 RGB666
2477 RGB666 data transmission is performed by transmitting a B0…5, G0…5, and R0…5 (18-bit) sequence. This
2478 sequence is illustrated in Figure 133. The frame format for RGB666 is presented in the Figure 135.
Pixels Bytes Bits
4 9 72
2482 Bit order in transmission follows the general CSI-2 rule, LSB first. In RGB666 case the length of one data
2483 word is 18-bits, not eight bits. The word-wise flip is done for 18-bit BGR words; i.e. instead of flipping each
2484 byte (8-bits), each 18-bits pixel value is flipped. This is illustrated in Figure 134.
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

2485
Figure 133 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
2486
b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 b2 b3 b4 b5 b6 b7 b0 b1 ...
Figure 134 RGB666 Transmission on CSI-2 Bus Bitwise Illustration

Confidential
23-May-2022
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
…. …. …. …. …. …. ….
…. …. …. …. …. …. ….
BGR BGR BGR BGR …. BGR BGR FE
18-bit
2487

Confidential
23-May-2022
11.3.3 RGB565
2488 RGB565 data transmission is performed by transmitting B0…B4, G0…G5, R0…R4 in a 16-bit sequence.
2489 This sequence is illustrated in Figure 136. The frame format for RGB565 is presented in the Figure 138.
Pixels Bytes Bits
1 2 16
2493
2496 byte (8-bits), each two bytes (16-bits) are flipped. This is illustrated in Figure 137.
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

2497
Figure 136 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
2498

Confidential
23-May-2022
16-bit
FS BGR BGR BGR …. BGR BGR

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

Confidential
23-May-2022
11.3.4 RGB555
2500 RGB555 data can be transmitted over a CSI-2 bus with some special arrangements. The RGB555 data should
2501 be made to look like RGB565 data. This can be accomplished by inserting padding bits to the LSBs of the
2502 green color component as illustrated in Figure 139.
2503 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
2507

Confidential
23-May-2022
11.3.5 RGB444
2508 RGB444 data can be transmitted over a CSI-2 bus with some special arrangements. The RGB444 data should
2509 be made to look like RGB565 data. This can be accomplished by inserting padding bits to the LSBs of each
2510 color component as illustrated in Figure 140.
2511 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
2515

Confidential
23-May-2022
11.4 RAW Image Data

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

Confidential
23-May-2022
11.4.1 RAW6
2525 The 6-bit Raw data transmission is done by transmitting the pixel data over CSI-2 bus. This sequence is
2526 illustrated in Figure 141 (VGA case). Table 51 specifies the packet size constraints for RAW6 packets. The
2527 length of each packet must be a multiple of the values in the table.
2528 Table 51 RAW6 Packet Data Size Constraints
Pixels Bytes Bits
4 3 24
2529 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
2530
Figure 141 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

2531
Figure 142 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
….
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
P1 P2 P3 P4 P5 …. P637 P638 P639 P640 FE
6-bit Pixel Value

2532
Figure 143 RAW6 Frame Format

Confidential
23-May-2022
11.4.2 RAW7
2533 The 7-bit Raw data transmission is done by transmitting the pixel data over CSI-2 bus. This sequence is
2534 illustrated in Figure 144 (VGA case). Table 52 specifies the packet size constraints for RAW7 packets. The
2535 length of each packet must be a multiple of the values in the table.
Pixels Bytes Bits
8 7 56
2537 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
2538
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
2539
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
….
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
P1 P2 P3 P4 P5 P6 P7 P8 …. P638 P639 P640 FE
7-bit Pixel Value

2540

Confidential
23-May-2022
11.4.3 RAW8
2541 The 8-bit Raw data transmission is done by transmitting the pixel data over a CSI-2 bus. Table 53 specifies
2542 the packet size constraints for RAW8 packets. The length of each packet must be a multiple of the values in
2543 the table.
Pixels Bytes Bits
1 1 8
2545 This sequence is illustrated in Figure 147 (VGA case).

2546 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
2547
P1[7:0] (A) P2[7:0] (B) P3[7:0] (C) P4[7:0] (D)


2548
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
….
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
P1 P2 P3 P4 P5 …. P637 P638 P639 P640 FE
2549

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

2555 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] [1:0] [1:0] [1:0] [1:0] P5[9:2] P6[9:2]
Header
P636 P635 P634 P633 P640 P639 P638 P637 Packet

Line End [1:0] [1:0] [1:0] [1:0] P637[9:2] P638[9:2] P639[9:2] P640[9:2] [1:0] [1:0] [1:0] [1:0] Footer
2556
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


2557

Confidential
23-May-2022
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
P1 P2 P3 P4 LSBs P5 …. P637 P638 P639 P640 LSBs FE
2558

Confidential
23-May-2022
11.4.5 RAW12
2559 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
2565
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


2566
Figure 154 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

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

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

2573 The LS bits for P1, P2, P3, and P4 are distributed in three bytes as shown in Figure 156 and Figure 157. The
2574 same is true for the LS bits for P637, P638, P639, and P640. The bit order during byte transmission follows
2575 the general CSI-2 rule, i.e. LSB first.
2576 Note:
2577 Figure 156 has been modified relative to the figures shown in the CSI-2 Specification version 2.0
2578 and earlier, in order to more clearly correspond with Figure 157. The RAW14 byte packing and
2579 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
2580
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


2581

Confidential
23-May-2022
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
P1 P2 P3 P4 LSBs LSBs LSBs LSBs …. P640 LSBs LSBs LSBs LSBs FE
2582

Confidential
23-May-2022
11.4.7 RAW16
2583 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]
2589 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


2590
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
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
P1 P1 P2 P2 P3 P63 9 P63 9 P64 0 P64 0 FE
2591

Confidential
23-May-2022
11.4.8 RAW20
2592 The transmission of 20-bit Raw data is done by packing the 20-bit pixel data to look like the 10-bit data
2593 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
[1:0]
P2
[11:10]
P1
[1:0]
P1
[11:10] P3[19:12] P3[9:2]
Header
Packet
Line End P 638
[1:0]
P 638
[11:10]
P 637
[1:0]
P 637
[11:10] P639[19:12] P639[9:2] P640[19:12] P640[9:2] P 640
[1:0]
P 640
[11:10]
P 639
[1:0]
P 639
[11:10]
Footer
2598 LSB s LSB s

P1[19:12] (A) P1[9:2] (A) P2[19:12] (B) P2[9:2] (B)
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


2599

Confidential
23-May-2022
FS P1 P1 P2 P2 LSBs P3 . P639 P639 P640 P640 LSBs

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
2600

Confidential
23-May-2022
11.4.9 RAW24
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
2607
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


2608

Confidential
23-May-2022
FS P1 P1 LSBs P2 P2 LSBs …. P639 LSBs P640 P640 LSBs

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

Confidential
23-May-2022
11.4.10 RAW28
Pixels Bytes Bits
2 7 56

Line Start
LSB s
Packet P1 P1 P2 P1 P2 P2
P1[27:20] P1[13:6] P2[27:20] P2[13:6] [19:18]
Header [1:0] [19:14] [17:14] [5:2] [5:0]
Byte Byte Byte
P639 P639 P640 P639 P640 P640 Packet
Line End P639[27:20] P639[13:6] P640[27:20] P640[13:6]
[1:0] [19:14] [17:14] [5:2] [5:0] [19:18] Footer
2616
P1[27:20] (A) P1[13:6] (A) P2[27:20] (B) P2[13:6] (B)
P1 P2
P1[19:14] (A) [1:0] P1[5:2] (A) P2[17:14] (B) [19:18] P2[5:0] (B) P3[27:20] (C)
A14 A15 A16 A17 A18 A19 A0 A1 A2 A3 A4 A5 B14 B15 B16 B17 B18 B19 B0 B1 B2 B3 B4 B5 C20 C21 C22 C23 C24 C25 C26 C27


2617
FS P1 P1 P2 P2 LSBs LSBs LSBs P639 P639 P640 P640 LSBs LSBs LSBs
P1 P1 P2 P2 LSBs LSBs LSBs P639 P639 P640 P640 LSBs LSBs LSBs
Packer Header, PH
Packer Footer, PF
P1 P1 P2 P2 LSBs LSBs LSBs P639 P639 P640 P640 LSBs LSBs LSBs FE
2618

Confidential
23-May-2022
11.5 User Defined Data Formats

2619 The User Defined Data Type values shall be used to transmit arbitrary data, such as JPEG and MPEG4 data,
2620 over the CSI-2 bus. Data shall be packed so that the data length is divisible by eight bits. If data padding is
2621 required, the padding shall be added before data is presented to the CSI-2 protocol interface.
2622 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
2623
Figure 171 User Defined 8-bit Data (128 Byte Packet)
Byte1[7:0] (A) Byte2[7:0] (B) Byte3[7:0] (C) Byte4[7:0] (D)


2624
Figure 172 User Defined 8-bit Data Transmission on CSI-2 Bus Bitwise Illustration
2625 The packet data size in bits shall be divisible by eight, i.e. a whole number of bytes shall be transmitted.
2626 For User Defined data:
2627 • The frame is transmitted as a sequence of arbitrary sized packets.
2628 • The packet size may vary from packet to packet.
2629 • 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
2630
LE – Line End
Figure 173 Transmission of User Defined 8-bit Data

Confidential
23-May-2022
2631 Eight different User Defined data type codes are available as shown in Table 61.
2632 Table 61 User Defined 8-bit Data Types
0x30 User Defined 8-bit Data Type 1

Confidential
23-May-2022

Confidential
23-May-2022
12 Recommended Memory Storage

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

2638 In the generic case and for arbitrary data the first byte of payload data transmitted maps the LS byte of the
2639 32-bit memory word and the fourth byte of payload data transmitted maps to the MS byte of the 32-bit
2640 memory word.
2641 Figure 174 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
2642
32-bit standard memory width
Figure 174 General/Arbitrary Data Reception

Confidential
23-May-2022
12.2 RGB888 Data Reception

2643 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]
2644
Figure 175 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
2645

Confidential
23-May-2022
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
2646
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
2647

Confidential
23-May-2022

2648 The RGB444 data format byte to 32-bit memory word mapping has a special transform as shown in Figure
2649 179.
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
2650
12.7 YUV422 8-bit Data Reception

2651 The YUV422 8-bit data format the byte to 32-bit memory word mapping does not follow the generic CSI-2
2652 rule.
2653 For YUV422 8-bit data format the first byte of payload data transmitted maps the MS byte of the 32-bit
2654 memory word and the fourth byte of payload data transmitted maps to the LS byte of the 32-bit memory
2655 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
2656
Figure 180 YUV422 8-bit Data Format Reception

Confidential
23-May-2022

2657 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
2658

Confidential
23-May-2022
12.9 YUV420 8-bit (Legacy) Data Reception

2659 The YUV420 8-bit (legacy) data format the byte to 32-bit memory word mapping does not follow the generic
2660 CSI-2 rule.
2661 For YUV422 8-bit (legacy) data format the first byte of payload data transmitted maps the MS byte of the
2662 32-bit memory word and the fourth byte of payload data transmitted maps to the LS byte of the 32-bit memory
2663 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
2664
Figure 182 YUV420 8-bit Legacy Data Format Reception

Confidential
23-May-2022


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
2666

Confidential
23-May-2022


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

2668

Confidential
23-May-2022
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
2669
Figure 185 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

2670

Confidential
23-May-2022

2671 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
2672

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]

2674

Confidential
23-May-2022

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
2676
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

2677
Figure 190 RAW 14 Data Format Reception

Confidential
23-May-2022

2678 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
2679 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
2681 32-bit standard memory width

Confidential
23-May-2022

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
2683

Data on CSI-2 bus:

P1[27:20] P1[13:6] P2[27:20] P2[13:6]
Data a20a21 a22a23 a24a25 a26 a27 a6 a7 a8 a9 a10a11 a12a13 b20b21 b22b23 b24b25 b26b27 b6 b7 b8 b9 b10b11 b12b13
P1[19:14] P1[1:0] P1[5:2] P2[17:14] P2[19:18] P2[5:0] P3[27:20]
a14a15 a16a17 a18a19 a0 a1 a2 a3 a4 a5 b14b15 b16 b17 b18 b19 b0 b1 b2 b3 b4 b5 c20c21 c22c23 c24c25 c26c27
P3[13:6] P4[27:20] P4[13:6] P3[19:14] P3[1:0]
c6 c7 c8 c9 c10c11 c12 c13 d20d21 d22d23 d24d25 d26d27 d6 d7 d8 d9 d10d11 d12 d13 c14c15 c16c17 c18c19 c0 c1
Buffer Data in receiver's buffer:

Addr
MSB P2[13:6] P2[27:20] P1[13:6] P1[27:20] LSB
00h b13b12 b11b10 b9 b8 b7 b6 b27 b26 b25 b24b23b22b21b20 a13a12 a11a10 a9 a8 a7 a6 a27a26 a25a24a23a22 a21a20
P3[27:20] {P2[5:0], P2[19:18]} {P2[17:14], P1[5:2]} {P1[1:0], P1[19:14]}

01h c27c26 c25c24c23 c22c21 c20 b5 b4 b3 b2 b1 b0 b19b18 b17b16 b15b14 a5 a4 a3 a2 a1 a0 a19b18 a17 a16 a15 a14
{P3[1:0], P3[19:14]} P4[13:6] P4[27:20] P3[13:6]

02h c1 c0 c19 c18 c17 c16 c15 c14 d13 d12 d11 d10 d9 d8 d7 d6 d27d26d25d24 d23d22 d21d20 c13 c12 c11c10 c9 c8 c7 c6

2685

Confidential
23-May-2022

Confidential
23-May-2022
13 Always-On Sentinel Conduit (AOSC)
13.1 Introduction
2686 Always-On Sentinel Conduit (AOSC) is an optional normative feature. AOSC provides an ultra-low power
2687 imaging conduit solution for broad range of always-on and always-aware applications using Vision Digital
2688 Signal Processor (VDSP). The AOSC solution entails CSI-2 protocol transport using I3C I/O, in which the
2689 VDSP is the I3C Controller, and SNS is the I3C Target. The CSI-2 Specification defines an interface between
2690 a peripheral device (SNS) and a host processor (APP) using MIPI D-PHY [MIPI01] or MIPI C-PHY
2691 [MIPI02] as the physical layer. AOSC defines how the CSI-2 protocol may instead be used with MIPI I3C
2692 [MIPI03] as the physical layer for the purpose of transporting low data rate pixels and/or other data from a
2693 SNS to a VDSP. AOSC shall support the I3C SDR and HDR-DDR data rates, and may optionally support the
2694 HDR-BT data rate. Imaging solutions requiring higher throughput should utilize Dual Mode and Quad Mode
2695 I3C Multi-Lane capabilities with bitwise striping.
2696 A key difference between image transport as described in AOSC and traditional CSI-2 is that in AOSC, the
2697 host (VDSP) reads (or “pulls”) pixel data from an image sensor (SNS), whereas in CSI-2 the host passively
2698 receives pixel data transmitted (or “pushed”) to it by a SNS.
2699 AOSC product solutions may include:
2700 • SNS connected to an APP supporting VDSP functionality,
2701 • SNS connected to an VDSP, or
2702 • SNS connected to an APP and an external VDSP,
2703 where APP and VDSP operations may or may not be mutually exclusive as illustrated in Figure 195 through
2704 Figure 197.
AOSC using I3C

(Point-To-Point)
VDSP
SNS
CSI-2 over C/D-PHY APP
(USL)
VDSP
AOSC using I3C

(Point-To-Point)
SNS CSI-2 over C/D-PHY

APP
(USL)
2705
Figure 195 Point-To-Point AOSC Systems with USL Solutions

Confidential
23-May-2022
AOSC using I3C

(Point-To-Point)
VDSP
SNS CSI-2 over C/D-PHY
APP
2
CCI over I C / I3C
VDSP
AOSC using I3C

(Point-To-Point)
2
CCI over I C / I3C
SNS APP
CSI-2 over C/D-PHY
2706
Figure 196 Point-To-Point AOSC Systems with Non-USL Solutions
AOSC using I3C

VDSP
CCI over I3C
SNS
APP
CSI-2 over C/D-PHY
2707
Figure 197 System Supporting AOSC and CCI Operations Over Multi-Drop I3C

Confidential
23-May-2022
AOSC using I3C

VDSP
CCI over I3C

SNS
CSI-2 over C/D-PHY

APP
2708
Figure 198 System Supporting Discrete Multicontrollers Mapped to Single SNS I3C Target
Port
2709 • The Figure 195 system illustrates the USL (Unified Serial Link) encapsulated solution for APP
2710 and SNS communications as defined in Section 9.11.
2711 • The Figure 196 non-USL solution requires additional I2C / I3C / SPI wires for APP-initiated CCI
2712 operations to the SNS; in such operations, the SNS shall be designated as the Target and APP as
2713 the Controller.
2714 • The Figure 198 system enables non-integrated or discrete VDSP and APP supporting I3C host
2715 arbitration and handshake on the platform using Multi-Controller topology.
2716 An AOSC SNS supporting CSI-2 transport over I3C and C/D-PHY may provide respective dedicated control
2717 registers (i.e., 3A control registers). An AOSC SNS may support simultaneous and mutually exclusive CSI-2
2718 frame transport operations over I3C and C/D-PHY (as illustrated in the above figures). An AOSC SNS limited
2719 to low resolution operations may only support CSI-2 transport over I3C.
13.1.1 VDSP and APP In-Band Communication

2720 Mailbox registers are utilized for systems with separate VDSP silicon and an APP silicon connected to an
2721 SNS, as illustrated in Figure 195 and Figure 196. The SNS should provide two 32-bit mailbox registers for
2722 VDSP and APP in-band communications. Any possible sideband communication between VDSP and APP is
2723 implementation-specific and beyond the scope of this specification.
2724 The two Mailbox registers are:
2725 • REG_AOSC_MAILBOX_VDSP_APP [31:0] for VDSP-to-APP commands
2726 • REG_AOSC_MAILBOX_APP_VDSP [31:0] for APP-to-VDSP commands

Confidential
23-May-2022
13.1.2 AOSC SNS Features and Capabilities

2727 The SNS supporting AOSC shall support a 16-bit control register, REG_AOSC_CONTROL[15:0]. The AOSC
2728 features and capabilities are detailed in the sections below and mapped to bits REG_AOSC_CONTROL[8:0].
2729 The remaining bits are reserved for future developments. The AOSC SNS may support multiple of 8-bit width
2730 register addressing.
2731 • Bit REG_AOSC_CONTROL[0] (field ENABLE_AOSC) shall be used to enable the AOSC feature:
2732 • 1’b0: AOSC feature disabled
2733 • 1’b1: AOSC feature enabled
2734 This specification defines two AOSC Transport Modes:
2735 • Optimal Transport Mode (OTM) is intended to provide an optimal power-efficient AOSC
2736 transport solution for inference processing. Each LP shall map to a horizontal row of the photon
2737 collectors. The OTM shall be supported, see Section 13.2.
2738 • Smart Transport Mode (STM) is intended for smart inferencing SNS solutions where the transport
2739 payload is limited to the I3C IBI. The STM should be supported, see Section 13.3.
2740 For both OTM and STM, each image frame is transported over I3C as a predetermined number of fixed-
2741 length “long packets” (LPs), each of which consists of the pixels from a single image line. For the OTM, an
2742 LP may also be terminated by a variable number of “Interconnect Synchronizing Padding Bytes” (ISPB)
2743 which may be inserted by the SNS for bit rate synchronization purposes.
2744 • Bits REG_AOSC_CONTROL[7:6] (field AOSC_TRANSPORT_MODE) shall be used to select the
2745 AOSC Transport Mode:
2746 • 2’b00: OTM
2747 • 2’b01: STM
2748 • 2’b10–2’b11: Values reserved for future AOSC Transport Modes
13.1.3 VDSP and APP Switching and Graceful Failure

2749 The SNS should switch between VDSP and APP at CSI-2 frame boundaries, and the SNS should complete
2750 transmission of the present CSI-2 frame in flight prior to switching. In the event of an internal error within
2751 an SNS, any LP payload in transmission should be completed using multiples of 8’d0 padding; and any
2752 remaining LPs mapped to the CSI-2 frame shall be flushed. Upon flushing while in OTM, the SNS shall
2753 generate an IBI indicating an Internal Error as described in Section 13.2.4.

Confidential
23-May-2022
13.1.4 Support for Privacy

2754 The SNS shall support privacy provisions to facilitate an electronic slider for always-on and always-aware
2755 imaging applications. An SNS targeting secure product platforms should support physical GPIO pin override
2756 to enable privacy. A platform may disable PRIVACY using GPIO or CCI as defined in this Section.
2757 The GPIO pin HIGH signaling maps to PRIVACY_ENABLED functionality as defined in the paragraph below.
2758 CCI accessible register REG_AOSC_CONTROL is used to define privacy when GPIO pin signaling is
2759 configured to LOW. Physical GPIO privacy is disabled by default, and the SNS module should include the
2760 pull-down provision within the pad as appropriate.
2761 Privacy changes made to the SNS using the physical GPIO pin or CCI registers shall not impact any frame(s)
2762 presently in transport by the SNS; and the privacy changes shall apply to the subsequent frame(s).
2763 If PRIVACY is Enabled using the physical GPIO pin, then no digital representation(s) or interpretation(s) of
2764 streaming or still image frame(s) from the SNS photon collectors shall be made available.
2765 If PRIVACY is Enabled using CCI accessible register REG_AOSC_CONTROL[2:1] (field PRIVACY), then
2766 permissible SNS operations include:
2767 • 2’b00: PRIVACY_ DISABLED: Digital representation(s) or interpretation(s) of streaming or still
2768 image frame(s) from the SNS photon collectors may be made available to the VDSP and/or APP.
2769 • 2’b01: PRIVACY_ ENABLED_EVENT_DET_BYPASS: No digital representation(s) of streaming
2770 or still image frame(s) from the SNS photon collectors shall be made available to the VDSP nor to
2771 the APP. Digital interpretation(s) of streaming or still image frame(s) from the SNS photon
2772 collectors may be made available to the VDSP and/or to the APP (i.e., Event Detection via I3C
2773 IBI).
2774 System example of an event detection operation (hypothetical):
2775 1. AOSC SNS detects an object of interest passing confidence threshold
2776 2. AOSC SNS generates an I3C IBI to the VDSP/APP
2777 3. VDSP/APP may optionally update PRIVACY configuration
2778 4. VDSP or APP may optionally read the ROI Image Frame(s) via I3C or C/D-PHY
2779 respectively
2780 • 2’b10: PRIVACY_ ENABLED: No digital representation(s) or interpretation(s) of streaming or still
2781 image frame(s) from the SNS photon collectors shall be made available.
2782 • 2’b11: PRIVACY_RESERVED: This value is reserved.

Confidential
23-May-2022
13.2 Optimal Transport Mode (OTM) Overview

2783 The OTM is intended for transporting static CSI-2 frames configured by the VDSP or APP. The number of
2784 pixel bytes transported in each OTM LP by the SNS shall be determined by the CSI-2 Frame resolution and
2785 bits-per-pixel configured by the VDSP or APP as part of the SNS bring-up. The implementation specific SNS
2786 datasheet may be used to configure the SNS by the VDSP or APP. For example, a RAW10 format, 300
2787 Horizontal Pixel by 320 Vertical Pixel CSI-2 Frame shall require 3,000 pixel bits (or 375 pixel bytes) per
2788 OTM LP. The SNS shall transport 320 LPs corresponding to each CSI-2 Frame.
2789 The long packet 16-bit CRC checksum described in Section 13.2.8 is optional for OTM image frames, in
2790 order to provide “ultra-low-power always-on” SNS and VDSP more flexibility in minimizing power. The
2791 OTM CRC does not apply to I3C HDR-BT mode. The SNS shall support generation of the OTM CRC for
2792 the I3C SDR and HDR-DDR modes.
2793 • Bit REG_AOSC_CONTROL[8] (field OTM_CRC_GEN) shall be used to enable or disable the
2794 generation of the OTM CRC:
2795 • 1’b0: The SNS shall not generate the 16-bit CRC.
2796 • 1’b1: The SNS shall generate a single 16-bit CRC for all LP Payloads corresponding to an
2797 image frame, and shall append the 16-bit CRC to the last LP comprising an image frame.
2798 An OTM SNS may optionally provide a register to enable the VDSP to configure the EHDR link rate in Bits
2799 Per Second as part of the power up configuration. The VDSP should configure register
2800 REG_AOSC_EHDR_RATE_BPS with an I3C supported data rate. The effective read data rate may be lower
2801 than the I3C link rate. The VDSP should ensure that the link rate is supported by the AOSC SNS as defined
2802 in the data sheet.
2803 Example settings of REG_AOSC_EHDR_RATE_BPS[31:0] showing the targeted data rate (in Bits per
2804 Second) at which the VDSP will read the SNS FIFO (see Section 13.2.2):
2805 32’d0: The VDSP hasn’t configured the SNS with the EHDR data rate
2806 32’d1: The VDSP should read the FIFO at 1 bps after EHDR
2807 …
2808 32’d12_500_000: The VDSP should read the FIFO at 12.5 Mbps
2809 …
2810 32’d25_000_000: The VDSP should read the FIFO at 25 Mbps

Confidential
23-May-2022
Optimal Transport Mode (OTM)
VDSP ODF EHDR TPP XHDR

SDA
SNS IBI LPP 1 ... LPP N CRC
SCL
2811
Figure 199 AOSC Optimal Transport Mode (OTM) Operation
2812 Figure 199 illustrates OTM operation:

2813 • Note that OTM operations in the dotted boxes are optional
2814 • ODF: On-Demand Frame command to initiate frame exposure
2815 • IBI: In-Band Interrupt generated by the SNS at the beginning of an image frame
2816 • EHDR: The VDSP may optionally enter into an I3C HDR Mode that supports a higher data rate
2817 • TPP: The VDSP generates a Transmit Packet Payload command to the SNS
2818 • LPP 1 through LPP N: The VDSP reads all Long Packets (1 to N) encompassing an image frame from
2819 the SNS. ISPB may be appended to select Long Packets.
2820 • CRC: The VDSP reads the 16-bit CRC from the SNS if the OTM_CRC_GEN was enabled
2821 • XHDR: The VDSP shall exit I3C HDR Mode (see EHDR step above)
2822 OTM control registers are summarized in Table 62. Note that some register bits also apply to STM.

Confidential
23-May-2022
2823 Table 62 SNS Registers Required to Support OTM

Description
SNS OTM Registers and Values
RO: Read Only See Section
Bits marked with * also apply to STM
RW: Read / Write
REG_AOSC_CONTROL[15:0] RW –
1’b0: AOSC feature disabled
Bit [0]* – 13.1.2
1’b1: AOSC feature enabled
2’b00: Privacy disabled
2’b01: Privacy enabled with event detection
Bit [2:1]* – 13.1.4
2’b10: Privacy enabled
2’b01: Reserved
1’b0: ODF Mode
Bit [3] – 13.2.5
1’b1: CSF Mode
1’b0: The SNS shall not squelch Frame Start IBI
Bit [4] – 13.2.6
1’b1: The SNS shall squelch Frame Start IBI
1’b0: Dynamic ISPB insertion disabled
Bit [5] – 13.2.7
1’b1: Dynamic ISPB insertion enabled
2’b00: OTM
2’b01: STM
Bit [7:6]* – 13.1.2
2’b10: Reserved for future AOSC Transport Mode
2’b11: Reserved for future AOSC Transport Mode
1’b0: 16-bit CRC disabled
Bit [8] – 13.2
1’b1: 16-bit CRC enabled
REG_AOSC_MAILBOX_VDSP_APP [31:0]* RW 13.1.1
REG_AOSC_MAILBOX_APP_VDSP [31:0]* RW 13.1.1
REG_AOSC_SQ_FS_IBI [15:0] RW 13.2.6
REG_AOSC_ISPB_IBI_WM[15:0] RW 13.2.7
REG_AOSC_EHDR_RATE_BPS[31:0] RW 13.2

Confidential
23-May-2022
13.2.1 Protocol Overview

2824 As shown in Figure 200 and Table 63, pixel bits in each OTM LP are mapped into I3C bytes in LS-bit-first
2825 order; the bit transmission order of each byte on the I3C bus is determined by the I3C specification for the
2826 selected I3C transfer mode. OTM line transport shall follow the formats defined in Table 63 which are derived
2827 from Section 11 but generally relax the latter’s pixel granularity rules; i.e. OTM simply requires lines to
2828 consist of an integer number of pixels, with any remaining non-pixel bits in the last byte of a line being set
2829 to zero.
2830 For example, an OTM line could consist of 130 RAW10 pixels transported in 163 bytes (i.e., not a multiple
2831 of four pixels or five bytes as described in Section 11.4.4), with the final byte consisting of the four MS bits
2832 of the last pixel followed by four zero bits.
Byte 1 Byte 0
...
SNS ... P2[9] P2[8] P2[7] P2[6] P2[5] P2[4] P2[3] P2[2] P2[1] P2[0] P1[9] P1[8] P1[7] P1[6] P1[5] P1[4] P1[3] P1[2] P1[1] P1[0] DOUT
P2[9:0] P1[9:0]
2833
Figure 200 Example OTM RAW10 Format Transport (with I3C SDR Bit Transmission Order)
2834 Table 63 provides comprehensive OTM SNS bitwise transmission mapping for all frame formats. These are
2835 mapped into data bytes for I3C read transfers, which shall be transmitted in the appropriate order based on
2836 the I3C Mode.
2837 The SNS shall use an appropriate byte format and protocol for the chosen I3C Mode.
2838 For example:
2839 • In I3C SDR Mode the bytes shall be sent in the defined order, one byte at a time, starting with
2840 Byte 0 and using a T-Bit after each byte. The bits within each byte shall be sent in MSb-first order,
2841 per standard SDR Mode protocol (see [MIPI03] at Section 5.1.2.3).
2842 • In I3C HDR-DDR Mode the bytes shall be sent in 2-byte HDR-DDR Data Words, starting with
2843 Bytes 0 and 1. The bits within each byte shall be sent according to the HDR-DDR Mode protocol
2844 (see [MIPI03] at Section 5.2.2.1). However, HDR-DDR Multi-Lane transfers might use additional
2845 Data Lanes and a modified protocol, per the configured I3C ML Frame Format and Data Transfer
2846 Coding (see [MIPI03] at Section 5.3.2.2).
2847 • In I3C HDR-BT Mode the bytes shall be sent in 32-byte HDR-BT Data Blocks, unless the end of
2848 the data is ‘ragged’ and requires a Last Data Block. The protocol for HDR-BT data is a function of
2849 the number of additional Data Lanes (see [MIPI03] at Section 5.2.4.1), which depends on the
2850 configured I3C ML Frame Format and Data Transfer Coding (see [MIPI03] at Section 5.3.2.4).

Confidential
23-May-2022
2851 Table 63 OTM Bitwise Transport Mapping for All Frame Formats
2852

Confidential
23-May-2022
13.2.2 SNS FIFO Requirement

2853 As shown Figure 201, the SNS internally stores LP(s) using first-in first-out (FIFO) memory. The FIFO
2854 serves to decouple the rate at which the SNS internally produces pixel-bearing CSI-2 packets from the rate
2855 at which the VDSP is able to read them using the I3C bus. FIFO implementation details and storage capacity
2856 are beyond the scope of this specification.
I3C Bus
OTM LPs FIFO VDSP
2857
Figure 201 SNS OTM FIFO
2858 The FIFO shall be empty prior to the start of image streaming. After the SNS finishes writing all the pixel
2859 bytes from an LP payload into the FIFO, and the total payload consists of an odd number of bytes, then the
2860 SNS shall also write one additional “padding” byte with value 0x00 to the FIFO. The VDSP is able to detect
2861 and discard this padding byte upon reception because it knows in advance how many pixel bytes are
2862 transported by each OTM LP.
2863 Because the I3C HDR-DDR word size is 16 bits, there is no byte granularity with 16-bit transport for
2864 HDR-DDR.
13.2.3 VDSP Initiated Commands to the SNS

2865 As shown in Table 64, the following VDSP commands are used to initiate exposure, and to clear and read the
2866 SNS FIFO:
2867 • TPP: Transmit Packet Payload (Mandatory)
2868 • OTM: The VDSP reads all LP payloads corresponding to a single frame from the SNS.
2869 • DPF: Discard Present Frame (Mandatory)
2870 • OTM: The VDSP uses DPF to direct the SNS to internally discard all remaining, unread bytes of
2871 a packet payload, including all payload bytes currently in the FIFO, as well as all payload bytes
2872 which have not yet been written to the FIFO. In addition, the DPF shall also discard any
2873 remaining payload corresponding to the present image frame. The time the image sensor
2874 requires to execute this command is implementation-dependent, but should in general be shorter
2875 than the time that the VDSP requires to read the data being discarded. The SNS shall ignore
2876 (i.e., shall NACK) any TPP command(s) received while a DPF command is executing; and the
2877 SNS shall also notify the VDSP once the DPF command execution has finished, using IBI.
2878 • ODF: On-Demand Frame (Mandatory)
2879 • OTM: The VDSP uses ODF to direct the SNS to initiate frame exposure, and subsequently the
2880 SNS generates the Frame Start IBI.
2881 In the I3C specification [MIPI03], CCC values 0xC0 through 0xC3 have been reserved for CSI-2 AOSC
2882 applications, as summarized in Table 64.
2883 Table 64 AOSC Operation CCC and Defining Byte Values
CCC Value 0xC0: Imaging & Vision Applications
Defining Byte Value 0x00: Reserved
0x01: TPP
0x02: DPF
0x03: ODF
0x04 – 0xFF: Reserved

Confidential
23-May-2022
13.2.4 SNS Status Communication to VDSP Using IBI

2884 The SNS shall notify the VDSP via IBI when any of the following events occurs:
2885 1. An image frame is available to be read by the VDSP
2886 2. FIFO overflow, resulting in irretrievable loss of data
2887 3. FIFO underflow, resulting from a fast VDSP-generated I3C clock
2888 4. When a previously received DPF command has finished executing
2889 5. A serious command-related error that will interfere with the SNS’ ability to reliably continue
2890 transporting image frame data
2891 The SNS shall support I3C IBI “Mandatory Data Byte” (MDB[7:5] = 3’b010) to communicate the IBI status.
2892 The SNS Mandatory Data Byte provides the VDSP additional information about the IBI. The SNS shall use
2893 the MDB[4:0]=5’h00 for OTM and subsequent payload(s) for the six mandatory operations and one optional
2894 operation (see Table 65). Upon generation of an IBI, the SNS may also provide status via CCI-compliant
2895 registers accessible by the VDSP.
2896 Table 65 AOSC OTM Low-Latency Mandatory IBI MDB Codes
Payload
MDB[7:0] (Interrupt Field Support Description
Group ID)
Frame start indication from SNS, applicable only

8’h00 Frame Start Mandatory
for new image frame transfer.
Indication from SNS that DPF command has
DPF
8’h01 Mandatory successfully completed and the internal pipelines
Complete
are flushed.
Indication from SNS that an internal error occurred,
Internal
8’h02 Mandatory and any remaining LPs mapped to the present
Error
frame will be flushed.
Indication from SNS transmission of a new frame
Frame
8’h03 Mandatory after completing DPF or encountering an internal
Restart
error.
8’h40 Indication from SNS that the circular FIFO has

FIFO
8’h04 Mandatory encountered an underrun condition. Present frame
Underrun
transport may be paused.
Indication from SNS that the circular FIFO has
encountered an overrun condition. Such a
FIFO
8’h05 Mandatory condition may manifest as a result of slower VDSP
Overrun
bus transfer rate. This notification may be deemed
as fatal by VDSP, due to loss of data.
One or more payload bytes to follow the Interrupt
Manufacturer Group ID, to specify Manufacturer Defined
8’h06 Optional
Defined Interrupts which may include Motion detection, ALS
trigger, and FIFO hysteresis information.
8’h07 –8’hFF Reserved – –

Confidential
23-May-2022
VDSP
SDA
SNS IBI
Payload Payload Payload

S DA/R A/N MDB T 0 T 1 T ... N T P
MDB[7:5] = 3'b010 (MIPI) MDB[4:0] = 5'h00 (CSI-2 OTM)
MDB[7] MDB[6] MDB[5] MDB[4] MDB[3] MDB[2] MDB[1] MDB[0]

2897
Figure 202 AOSC IBI MDB Codes
13.2.5 Support for On-Demand Frame and Streaming Frames

2898 The SNS shall provide the option to generate either an On-Demand Frame (ODF) or Continuously Streaming
2899 Frames (CSF) to the VDSP. If the ODF option is enabled, then the SNS shall wait for an ODF command from
2900 the VDSP prior to initiating exposure and generating an In-Band-Interrupt (IBI) mapped to beginning of an
2901 image frame transfer (see Figure 199).
2902 • Bit REG_AOSC_CONTROL[3] (field EXPOSURE_CSF_ODF) shall be used to select between
2903 ODF and CSF operation:
2904 • 1’b0: ODF Mode: The SNS requires an ODF command from the VDSP to begin exposure
2905 • 1’b1: CSF Mode: The SNS does not require an ODF command from the VDSP to begin
2906 exposure
13.2.6 Support for Frame Squelching

2907 The frame squelching feature facilitates dynamic frame exposure duration. The SNS shall provide the option
2908 to squelch frames while in CSF mode, by generating interleaved Frame Start (FS) IBI as defined below. The
2909 SNS does not provide the option to squelch frames while in ODF mode. The VDSP shall handle frame slip(s)
2910 while the SNS is squelching frames. There may be frame slips due to PVT variations or jitter accumulation
2911 in the SNS.
2912 • Bit REG_AOSC_CONTROL[4] (field SQUELCH_FRAMES) is used to enable frame squelching
2913 while in CSF mode:
2914 • 1’b1: The SNS shall squelch Frame Start IBI as defined by register
2915 REG_AOSC_SQ_FS_IBI[7:0] (below).
2916 • 1’b0: The SNS shall not squelch Frame Start IBI.
2917 • Bits REG_AOSC_SQ_FS_IBI[7:0] (field SQUELCH_FRAME_START_IBI) control when the SNS
2918 generates an FS IBI:
2919 • 8’d0: The SNS shall generate an FS IBI every second frame
2920 • 8’d1: The SNS shall generate an FS IBI every third frame
2921 …
2922 • 8’dN: The SNS shall generate an FS IBI every (N+2) frames
2923 …
2924 • 8’d255: SNS shall generate FS IBI every 257th frame
2925 • Bits REG_AOSC_SQ_FS_IBI[15:8] are reserved for future use.

Confidential
23-May-2022
13.2.7 Support for Interconnect Synchronization and Dynamic ISPB Insertion

2926 An SNS supporting OTM shall support Dynamic Interconnect Synchronizing Padding Bytes (ISPB)
2927 insertion. The SNS may generate the ISPB using the same (pixel) clock that is used to generate the OTM
2928 Long Packet. The system may optionally utilize the ISPB capability to help align the SNS-generated pixel
2929 clock with the VDSP-generated I3C clock.
2930 • Bit REG_AOSC_CONTROL[5] (field ISPB_Insertion) shall be used to enable ISPB:
2931 • 1’b0: Dynamic ISPB insertion is disabled
2932 • 1’b1: Dynamic ISPB insertion is enabled
2933 The dynamic ISPB consists of zero, or a non-zero even number of, 8’h00 bytes, immediately followed by
2934 two 8’hFF bytes. When enabled, the SNS shall generate a dynamic ISPB (which may consist of only the two
2935 8’hFF bytes) after each LP in an image frame except for the last LP (see Figure 203). Due to the LP padding
2936 byte defined in Section 13.2.2, the beginning of the ISPB is always 16-bit word-aligned. The length of the
2937 dynamic ISPB shall be determined by the SNS. The number of ISPB bytes transmitted after each LP may be
2938 automatically varied by the SNS as needed in order to prevent FIFO underrun or overrun.
2939 Once the OTM Frame Start IBI is initiated, the VDSP shall initiate TPP within the T_RESP duration as
2940 illustrated in Figure 203. The duration of T_RESP is implementation specific and should be included in the
2941 AOSC SNS data sheet.
T_RESP
VDSP ODF EHDR TPP XHDR

SDA
SNS IBI LPP1 ISPB LPP2 ISPB
... LPPN CRC
8'h00 8'h00 ... 8'hFF 8'hFF
2942
Figure 203 OTM ISPB Insertion and Frame Start IBI T_RESP Parameter
2943 The AOSC SNS should support REG_AOSC_ISPB_IBI_WM[15:0] to help facilitate appropriate VDSP
2944 transport link rate. The VDSP configures REG_AOSC_ISPB_IBI_WM[15:0] (field ISPB IBI WATERMARK)
2945 with one of the FIFO watermark levels shown below in order to direct the SNS as to when it should generate
2946 the frame-start IBI, based on FIFO fullness. An SNS datasheet may restrict watermark support to only a
2947 subset of these levels:
2948 {12’d0, 4’b0000}: The SNS shall generate an IBI when FIFO is not empty
2949 {12’d0, 4’b0001}: The SNS shall generate an IBI when FIFO WATERMARK is 1/16 th full
2950 {12’d0, 4’b0010}: The SNS shall generate an IBI when FIFO WATERMARK is 2/16 th full
2951 …
2952 {4’b0100, 12’d0}: The SNS shall generate IBI when FIFO WATERMARK is 15/16 th full
2953 {4’b1000, 12’d0}: The SNS shall generate IBI when FIFO is full

Confidential
23-May-2022
13.2.8 OTM Errors Detected by the VDSP

2954 The VDSP may use the CSI-2 16-bit CRC described in Section 9.6 to detect packet payload errors; however,
2955 this form of error detection, while highly reliable, requires the VDSP to wait until the CRC has been received
2956 at the end of the payload before determining whether an error occurred.
2957 When the OTM CRC is enabled, the SNS initializes it to 0xFFFF at the start of every image frame and
2958 updates it with every pixel byte, padding byte, and ISPB read by the VDSP during the frame. The CRC is
2959 conceptually updated one byte at a time over the entire image frame using the serial algorithm shown in the
2960 C-code function of Figure 69; note that each byte is conceptually shifted LS-bit-first into the corresponding
2961 CRC shift register shown in Figure 68. The SNS transfers the calculated CRC over the I3C Bus in MS-byte-
2962 first order.
2963 The OTM CRC shall not be generated by the SNS if the HDR-BT mode is selected for I3C transfers. This is
2964 because the HDR-BT mode includes its own mandatory 16-bit CRC and optional 32-bit CRC calculations.

Confidential
23-May-2022
13.3 Smart Transport Mode (STM) Overview

2965 AOSC STM support is optional. STM allows the SNS to transport payload over a single I3C IBI without the need for a Read Request from the VDSP. The AOSC
2966 STM is limited to the I3C SDR data rate. As shown in Figure 204, the structure for STM may include the equivalent of the Long Packet Structure for D-PHY
2967 Physical Layer Option shown in Figure 52, but here the structure is considered solely as payload, with the D-PHY generic STM types where STM Type is set to
2968 D-PHY Generic Use 0 or D-PHY Generic Use 1 as shown in Table 66.
2969 Note that the BCR[2] bit in the I3C SNS’s BCR register shall be set to 1’b1 in order to take advantage of transporting one or more data bytes (MDB).
2970 Figure 204 illustrates STM operation for the D-PHY generic STM types.
2971 Note:
2972 • The MDB defined for STM in Table 66 differs from the one shown in Table 65 for OTM.
2973 • STM operations in the dotted boxes are optional.
VDSP
SDA
SNS IBI
S DA/R A/N HD0 T HD1 T HD2 T DT0 T DT1 T DT3 T DT4 T DTN T CRC T CRC T P
(l.s. byte first)
VCX + ECC
Word Count
Data WC-3
Data WC-4
Data WC-2
Data WC-1
Checksum
(l.s. byte
Data ID
Data 2
Data 0
Data 1
Data 3
16-Bit
16-bit
first)
LPS SoT EoT LPS
S = START condition
P = STOP condition
Interrupt Group Identifier Specific Interrupt Identifier A/N = ACK/NACK
MDB[7] MDB[6] MDB[5] MDB[4] MDB[3] MDB[2] MDB[1] MDB[0] T = Transition Bit alternative to ACK/NACK
2974
2975 Figure 204 AOSC Smart Transport Mode (STM) Operation for the D-PHY Generic STM Types

Confidential
23-May-2022
2976 • IBI: In-Band Interrupt generated by the SNS at the beginning of an image line or frame
2977 The IBI consists of the following data:
2978 • DA/R: The Dynamic Address with RnW bit set to 1’b1 (i.e., READ)
2979 • HD0: MDB as the first Header Byte for STM shown in Table 66
2980 • MDB: The Mandatory Data Byte of the IBI payload is the data that follows the Dynamic
2981 Address when the SNS sends an IBI request:
2982 • MDB[7:5]: Interrupt Group Identifier
2983 • 3’b010: MIPI Groups
2984 • MDB[4:0]: Specific Interrupt Identifier Value
2985 • 5’h01: AOSC Transport Mode for STM
2986 • HD1: The second Header Byte that defines the Word Count Extension Enable ( WCX_EN) and
2987 the STM Type for the STM specific payload data, which provides some flexibility depending on
2988 the applications:
2989 • Bit[7]: Reserved for future use
2990 • WCX_EN[6]: Word Count Extension Enable
2991 • 1'b0: The Word Count Extension is disabled, so the next Header Byte HD2 may be omitted.
2992 Only DT1 and DT2 are valid as 16-bit Word Count (WC).
2993 • 1'b1: the Word Count Extension is enabled, so the next Header Byte HD2 represents the
2994 most significant byte of the 24-bit Word Count (WC) along with DT1 and DT2
2995 • STMTYP[5:0]: STM Type
2996 • 6'h00: Reserved for future use
2997 • 6'h01–6'h1F: User Defined 1–31
2998 • 6’h20: D-PHY Generic Use 0, which is equivalent to Long Packet Structure for D-PHY
2999 Physical Layer Option shown in Figure 52, while the 32-bit Packet Header (PH) element is
3000 considered as payload in STM. The Word Count Extension (WCX_EN[6]) is ignored in this
3001 case, or handled as 1’b0 as if it’s disabled so that the following third Header Byte (HD2) is
3002 omitted.
3003 • 6’h21: D-PHY Generic Use 1, which is defined as an extension of D-PHY Generic Use 0
3004 above that allows the Word Count Extension, making the Word Count (WC) a 24-bit (not
3005 16-bit) field in order to support transport of more data than D-PHY Generic Use 0.
3006 • 6'h22–6'h3F: Reserved for future use
3007 • HD2: The third Header Byte, which defines the most significant byte of the 24-bit Word Count
3008 (WC) along with DT1 and DT2 when WCX_EN[6] = 1’b1
3009 • WCX[7:0]: The most significant byte of the 24-bit Word Count (WC)
3010 • DT0: The 8-bit Data Identifier (DI) as the first byte of the 32-bit Packet Header (PH) shown in
3011 Figure 52 when STMTYP[5:0] = 6’h20 or 6’h21
3012 • VC[7:6]: The 2-bit Virtual Channel (VC) that defines the least significant two bits of the 4-bit
3013 Virtual Channel Identifier for the D-PHY physical layer option
3014 • DT[5:0]: The 6-bit Data Type that denotes the format/content of the Application Specific
3015 Payload Data used by the application specific layer
3016 • DT1: The least significant byte of the 16-bit or 24-bit Word Count (WC) as the second byte of
3017 the 32-bit Packet Header (PH) shown in Figure 52 when STMTYP[5:0] = 6’h20 or 6’h21
3018 • WC[7:0]: The least significant byte of the 16-bit or 24-bit Word Count (WC)
3019 • DT2: The second least significant byte of the 16-bit or 24-bit Word Count (WC) as the third byte
3020 of the 32-bit Packet Header (PH) shown in Figure 52 when STMTYP[5:0] = 6’h20 or 6’h21
3021 • WC[15:8]: The second least significant byte of the 16-bit or 24-bit Word Count (WC)

Confidential
23-May-2022
3022 • DT3: The 6-bit Error Correction Code (ECC) and the 2-bit Virtual Channel Extension (VCX) as
3023 the fourth byte of the 32-bit Packet Header (PH) shown in Figure 52 when STMTYP[5:0] =
3024 6’h20 or 6’h21
3025 • ECC[5:0]: The 6-bit ECC enables 1-bit errors within the packet header to be corrected, and
3026 2-bit errors to be detected
3027 • VCX[1:0]: The 2-bit Virtual Channel Extension (VCX) that defines the most significant two
3028 bits of the 4-bit Virtual Channel Identifier for the D-PHY physical layer option
3029 • DT4–DTN: The SNS transports the Application Specific Payload Data shown in Figure 52 when
3030 STMTYP[5:0] = 6’h20 or 6’h21
3031 • CRC: The SNS generates the 16-bit Checksum/CRC (the least significant byte first) shown in
3032 Figure 52 when STMTYP[5:0] = 6’h20 or 6’h21
3033 See Section 9.1.1 for further descriptions.
3034 Table 66 Header Definitions for AOSC Smart Transport Mode (STM)
Header
Bits Field Values
Byte
0 MDB Interrupt Group
MDB[7:5] 3’b010: MIPI Groups
(HD0) Identifier
5’h00: AOSC Transport Mode for OTM
5’h01: AOSC Transport Mode for STM
MDB Specific Interrupt
MDB[4:0] 5’h02–5’h1B: MIPI Alliance Reserved
Identifier Value
5’h1C–5’h1D: MIPI Alliance Debug WG Reserved
5’h1E–5’h1F: MIPI Alliance Reserved
1 Bit[7] – Reserved
(HD1)
Word Count Extension 1'b0: Word Count Extension Disabled
WCX_EN[6]
Enable 1'b1: Word Count Extension Enabled
6'h00: Reserved
6'h01–6'h1F: User Defined 1 - 31
STMTYP[5:0] STM Type 6'h20: D-PHY Generic Use 0
6'h21: D-PHY Generic Use 1
6'h22–6'h3F: Reserved
2
8’h00–8’hFF: Most significant byte of the 24-bit
(HD2: WCX[7:0] Word Count Extension
Word Count when WCX_EN[6] = 1'b1
Optional)

Confidential
23-May-2022
3035 AOSC STM shall follow the data packing defined in Section 11 with the D-PHY generic STM types, when
3036 STMTYP[5:0] = 6’h20 or 6’h21.
3037 Figure 205 illustrates an example of RAW10 format bitwise transport with the D-PHY generic STM types
3038 above.
3039 Note:
3040 Data packing for the D-PHY generic STM types differs from that shown in Table 63 for OTM.
P1[9:2] P2[9:2] P3[9:2] P4[9:2]
P1 P2 P3 P4
[1:0] [1:0] [1:0] [1:0] P5[9:2] P6[9:2] P7[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
8 bits 8 bits 8 bits 8 bits

I3C Physical Layer b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0
3041
Figure 205 Example AOSC STM RAW10 Data Bitwise Transport Illustration with the D-PHY
Generic STM Types

Confidential
23-May-2022

Confidential
23-May-2022
Annex A JPEG8 Data Format (informative)

A.1 Introduction
3042 This Annex contains an informative example of the transmission of compressed image data format using the
3043 arbitrary Data Type values.
3044 JPEG8 has two non-standard extensions:
3045 • Status information (mandatory)
3046 • Embedded Image information e.g. a thumbnail image (optional)
3047 Any non-standard or additional data inside the baseline JPEG data structure has to be removed from JPEG8
3048 data before it is compliant with e.g. standard JPEG image viewers in e.g. a personal computer.
3049 The JPEG8 data flow is illustrated in Figure 206 and Figure 207.
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
3050
Figure 206 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
3051
Figure 207 JPEG8 Data Flow in the Decoder

Confidential
23-May-2022
A.2 JPEG Data Definition

3052 The JPEG data generated in camera module is baseline JPEG DCT format defined in ISO/IEC 10918-1, with
3053 following additional definitions or modifications:
3054 • sRGB color space shall be used. The JPEG is generated from YCbCr format after sRGB to YCbCr
3055 conversion.
3056 • The JPEG metadata has to be EXIF compatible, i.e. metadata within application segments has to
3057 be placed in beginning of file, in the order illustrated in Figure 208.
3058 • A status line is added in the end of JPEG data as defined in Section A.3.
3059 • If needed, an embedded image is interlaced in order which is free of choice as defined in Section
3060 A.4.
3061 • Prior to storing into a file, the CSI-2 JPEG data is processed by the data separation process
3062 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)

3063
Figure 208 EXIF Compatible Baseline JPEG DCT Format

Confidential
23-May-2022
A.3 Image Status Information

3064 Information of at least the following items has to be stored in the end of the JPEG sequence as illustrated in
3065 Figure 209:
3066 • Image exposure time
3067 • Analog & digital gains used
3068 • White balancing gains for each color component
3069 • Camera version number
3070 • Camera register settings
3071 • Image resolution and possible thumbnail resolution
3072 The camera register settings may include a subset of camera’s registers. The essential information needed for
3073 JPEG8 image is the information needed for converting the image back to linear space. This is necessary e.g.
3074 for printing service. An example of register settings is following:
3075 • Sample frequency
3076 • Exposure
3077 • Analog and digital gain
3078 • Gamma
3079 • Color gamut conversion matrix
3080 • Contrast
3081 • Brightness
3082 • Pre-gain
3083 The status information content has to be defined in the product specification of each camera module
3084 containing the JPEG8 feature. The format and content is manufacturer specific.
3085 The image status data should be arranged so that each byte is split into two 4-bit nibbles and “1010” padding
3086 sequence is added to MSB, as presented in Table 67. This ensures that no JPEG escape sequences (0xFF
3087 0x00) are present in the status data.
3088 The SOSI and EOSI markers are defined in Section A.5.
3089 Table 67 Status Data Padding
Data Word After Padding
D7D6D5D4 D3D2D1D0 1010D7D6D5D4 1010D3D2D1D0

Confidential
23-May-2022

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)
3090
Figure 209 Status Information Field in the End of Baseline JPEG Frame

Confidential
23-May-2022
A.4 Embedded Images

3091 An image may be embedded inside the JPEG data, if needed. The embedded image feature is not compulsory
3092 for each camera module containing the JPEG8 feature. An example of embedded data is a 24-bit RGB
3093 thumbnail image.
3094 The philosophy of embedded / interleaved thumbnail additions is to minimize the needed frame memory. The
3095 EI (Embedded Image) data can be included in any part of the compressed image data segment and in as many
3096 pieces as needed. See Figure 210.
3097 Embedded Image data is separated from compressed data by SOEI (Start Of Embedded Image) and EOEI
3098 (End Of Embedded Image) non-standard markers, which are defined in Section A.5. The amount of fields
3099 separated by SOEI and EOEI is not limited.
3100 The pixel to byte packing for image data within an EI data field should be as specified for the equivalent CSI-
3101 2 data format. However there is an additional restriction; the embedded image data must not generate any
3102 false JPEG marker sequences (0xFFXX).
3103 The suggested method of preventing false JPEG marker codes from occurring within the embedded image
3104 data it to limit the data range for the pixel values. For example
3105 • For RGB888 data the suggested way to solve the false synchronization code issue is to constrain
3106 the numerical range of R, G and B values from 1 to 254.
3107 • For RGB565 data the suggested way to solve the false synchronization code issue is to constrain
3108 the numerical range of G component from 1-62 and R component from 1-30.
3109 Each EI data field is separated by the SOEI / EOEI markers, and has to contain an equal amount bytes and a
3110 complete number of pixels. An EI data field may contain multiple lines or a full frame of image data.
3111 The embedded image data is decoded and removed apart from the JPEG compressed data prior to writing the
3112 JPEG into a file. In the process, EI data fields are appended one after each other, in order of occurrence in
3113 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)
3114
Figure 210 Example of TN Image Embedding Inside the Compressed JPEG Data Block

Confidential
23-May-2022
A.5 JPEG8 Non-standard Markers

3115 JPEG8 uses the reserved JPEG data markers for special purposes, marking the additional segments inside the
3116 data file. These segments are not part of the JPEG, JFIF [0], EXIF [0] or any other specifications; instead
3117 their use is specified in this document in Section A.3 and Section A.4.
3118 The use of the non-standard markers is always internal to a product containing the JPEG8 camera module,
3119 and these markers are always removed from the JPEG data before storing it into a file.
3120 Table 68 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

3121 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

3122
Figure 211 JPEG8 Data Format Reception

Confidential
23-May-2022
Annex B CSI-2 Implementation Example (informative)

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

Unidirectional
CSI transmitter and CCI target a Base Band containing the CSI
High-Speed
receiver and CCI controller
Data Link
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
3127
Figure 212 Implementation Example Block Diagram and Coverage
3128 For this implementation example a layered structure is described with the following parts:
3129 • D-PHY implementation details
3130 • Multi lane merger details
3131 • Protocol layer details
3132 This implementation example refers to a RAW8 data type only; hence no packing/unpacking or byte
3133 clock/pixel clock timing will be referenced as for this type of implementation they are not needed.
3134 No error recovery mechanism or error processing details will be presented, as the intent of the document is
3135 to present an implementation from the data flow perspective.

Confidential
23-May-2022
B.2 CSI-2 Transmitter Detailed Block Diagram

3136 Using the layered structure described in the overview the CSI-2 transmitter could have the block diagram in
3137 Figure 213.
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
TxDDRClkHS-I LP-TX D2p
LineValid control logic
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

3138 TxByteClkHs=TxByteClk/2
Figure 213 CSI-2 Transmitter Block Diagram

Confidential
23-May-2022
B.3 CSI-2 Receiver Detailed Block Diagram

3139 Using the layered structure described in the overview, the CSI-2 receiver could have the block diagram in
3140 Figure 214.
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

3141 RxByteClk=RxByteClkHS*2
Figure 214 CSI-2 Receiver Block Diagram

Confidential
23-May-2022
B.4 Details on the D-PHY Implementation

3142 The PHY level of implementation has the top level structure as seen in Figure 215.
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

3143
Figure 215 D-PHY Level Block Diagram
3144 The components can be categorized as:

3145 • CSI-2 Transmitter side:
3146 • Clock lane (Transmitter)
3147 • Data1 lane (Transmitter)
3148 • Data2 lane (Transmitter)
3149 • CSI-2 Receiver side:
3150 • Clock lane (Receiver)
3151 • Data1 lane (Receiver)
Confidential
23-May-2022
3152 • Data2 lane (Receiver)
B.4.1 CSI-2 Clock Lane Transmitter

3153 The suggested implementation can be seen in Figure 216.
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
3154
Figure 216 CSI-2 Clock Lane Transmitter
3155 The modular D-PHY components used to build a CSI-2 clock lane transmitter are:
3156 • LP-TX for the Low-power function
3157 • HS-TX for the High-speed function
3158 • CIL-MCNN for the Lane control and interface logic
3159 The PPI interface signals to the CSI-2 clock lane transmitter are:
3160 • TxDDRClkHS-Q (Input): High-Speed Transmit DDR Clock (Quadrature).
3161 • TxRequestHS (Input): High-Speed Transmit Request. This active high signal causes the lane
3162 module to begin transmitting a high-speed clock.
3163 • TxReadyHS (Output): High-Speed Transmit Ready. This active high signal indicates that the
3164 clock lane is transmitting HS clock.
3165 • Shutdown (Input): Shutdown Lane Module. This active high signal forces the lane module into
3166 “shutdown”, disabling all activity. All line drivers, including terminators, are turned off when
3167 Shutdown is asserted. When Shutdown is high, all other PPI inputs are ignored and all PPI outputs
3168 are driven to the default inactive state. Shutdown is a level sensitive signal and does not depend on
3169 any clock.
3170 • TxUlpmClk (Input): Transmit Ultra Low-Power mode on Clock Lane This active high signal is
3171 asserted to cause a Clock Lane module to enter the Ultra Low-Power mode. The lane module
3172 remains in this mode until TxUlpmClk is de-asserted.

Confidential
23-May-2022
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 Machine Low-power Function
Stopstate
Shutdown
CIL-SCNN
3174
Figure 217 CSI-2 Clock Lane Receiver
3175 The modular D-PHY components used to build a CSI-2 clock lane receiver are:
3176 • LP-RX for the Low-power function
3177 • HS-RX for the High-speed function
3178 • CIL-SCNN for the Lane control and interface logic
3179 The PPI interface signals to the CSI-2 clock lane receiver are:
3180 • RxDDRClkHS (Output): High-Speed Receive DDR Clock used to sample the data in all data
3181 lanes.
3182 • RxClkActiveHS (Output): High-Speed Reception Active. This active high signal indicates that the
3183 clock lane is receiving valid clock. This signal is asynchronous.
3184 • Stopstate (Output): Lane is in Stop state. This active high signal indicates that the lane module is
3185 currently in Stop state. This signal is asynchronous.
3188 Shutdown is asserted. When Shutdown is high, all PPI outputs are driven to the default inactive
3189 state. Shutdown is a level sensitive signal and does not depend on any clock.
3190 • RxUlpmEsc (Output): Escape Ultra Low Power (Receive) mode. This active high signal is
3191 asserted to indicate that the lane module has entered the Ultra Low-Power mode. The lane module
3192 remains in this mode with RxUlpmEsc asserted until a Stop state is detected on the lane
3193 interconnect.

Confidential
23-May-2022
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
TX Ctrl IF Logic
TxReadyHS
Shutdown
TxRequestEsc TX State
Machine
TxUlpm TxUlpmEsc
TxClkEsc
CIL-MFEN

3195
Figure 218 CSI-2 Data Lane Transmitter
3196 The modular D-PHY components used to build a CSI-2 data lane transmitter are:
3197 • LP-TX for the Low-power function
3198 • HS-TX for the High-speed function
3199 • CIL-MFEN for the Lane control and interface logic. For optional deskew calibration support, the
3200 data lane transmitter transmits a deskew sequence. The deskew sequence transmission is enabled
3201 by a mechanism out of the scope of this specification.
3202 The PPI interface signals to the CSI-2 data lane transmitter are:
3203 • TxDDRClkHS-I (Input): High-Speed Transmit DDR Clock (in-phase).
3204 • TxByteClkHS (Input): High-Speed Transmit Byte Clock. This is used to synchronize PPI signals
3205 in the high-speed transmit clock domain. It is recommended that both transmitting data lane
3206 modules share one TxByteClkHS signal. The frequency of TxByteClkHS must be exactly 1/8 the
3207 high-speed bit rate.
3208 • TxDataHS[7:0] (Input): High-Speed Transmit Data. Eight bit high-speed data to be transmitted.
3209 The signal connected to TxDataHS[0] is transmitted first. Data is registered on rising edges of
3210 TxByteClkHS.
3211 • TxRequestHS (Input): High-Speed Transmit Request. A low-to-high transition on TxRequestHS
3212 causes the lane module to initiate a Start-of-Transmission sequence. A high-to-low transition on
3213 TxRequest causes the lane module to initiate an End-of-Transmission sequence. This active high
3214 signal also indicates that the protocol is driving valid data on TxByteDataHS to be transmitted.
3215 The lane module accepts the data when both TxRequestHS and TxReadyHS are active on the same
3216 rising TxByteClkHS clock edge. The protocol always provides valid transmit data when
3217 TxRequestHS is active. Once asserted, TxRequestHS should remain high until the all the data has
3218 been accepted.

Confidential
23-May-2022
3219 • TxReadyHS (Output): High-Speed Transmit Ready. This active high signal indicates that
3220 TxDataHS is accepted by the lane module to be serially transmitted. TxReadyHS is valid on rising
3221 edges of TxByteClkHS. Valid data has to be provided for the whole duration of active
3222 TxReadyHS.
3225 Shutdown is asserted. When Shutdown is high, all other PPI inputs are ignored and all PPI outputs
3226 are driven to the default inactive state. Shutdown is a level sensitive signal and does not depend on
3227 any clock.
3228 • TxUlpmEsc (Input): Escape Mode Transmit Ultra Low Power. This active high signal is asserted
3229 with TxRequestEsc to cause the lane module to enter the Ultra Low-Power mode. The lane
3230 module remains in this mode until TxRequestEsc is de-asserted.
3231 • TxRequestEsc (Input): This active high signal, asserted together with TxUlpmEsc is used to
3232 request entry into Escape Mode. Once in Escape Mode, the lane stays in Escape Mode until
3233 TxRequestEsc is de-asserted. TxRequestEsc is only asserted by the protocol while TxRequestHS
3234 is low.
3235 • TxClkEsc (Input): Escape Mode Transmit Clock. This clock is directly used to generate escape
3236 sequences. The period of this clock determines the symbol time for low power signals. It is
3237 therefore constrained by the normative part of the [MIPI01].

Confidential
23-May-2022
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 Ctrl IF Logic
RX State
Stopstate Machine
Shutdown
ErrSotHS
ErrSotSyncHS
ErrControl
ErrEsc
CIL-SFEN

3239
Figure 219 CSI-2 Data Lane Receiver
3240 The modular D-PHY components used to build a CSI-2 data lane receiver are:
3241 • LP-RX for the Low-power function
3242 • HS-RX for the High-speed function
3243 • CIL-SFEN for the Lane control and interface logic. For optional deskew calibration support the
3244 data lane receiver detects a transmitted deskew calibration pattern and performs optimum deskew
3245 of the Data with respect to the RxDDRClkHS Clock.
3246 The PPI interface signals to the CSI-2 data lane receiver are:
3247 • RxDDRClkHS (Input): High-Speed Receive DDR Clock used to sample the date in all data lanes.
3248 This signal is supplied by the CSI-2 clock lane receiver.
3249 • RxByteClkHS (Output): High-Speed Receive Byte Clock. This signal is used to synchronize
3250 signals in the high-speed receive clock domain. The RxByteClkHS is generated by dividing the
3251 received RxDDRClkHS.
3252 • RXDataHS[7:0] (Output): High-Speed Receive Data. Eight bit high-speed data received by the
3253 lane module. The signal connected to RxDataHS[0] was received first. Data is transferred on
3254 rising edges of RxByteClkHS.
3255 • RxValidHS (Output): High-Speed Receive Data Valid. This active high signal indicates that the
3256 lane module is driving valid data to the protocol on the RxDataHS output. There is no
3257 “RxReadyHS” signal, and the protocol is expected to capture RxDataHS on every rising edge of
3258 RxByteClkHS where RxValidHS is asserted. There is no provision for the protocol to slow down
3259 (“throttle”) the receive data.

Confidential
23-May-2022
3260 • RxActiveHS (Output): High-Speed Reception Active. This active high signal indicates that the
3261 lane module is actively receiving a high-speed transmission from the lane interconnect.
3262 • RxSyncHS (Output): Receiver Synchronization Observed. This active high signal indicates that
3263 the lane module has seen an appropriate synchronization event. In a typical high-speed
3264 transmission, RxSyncHS is high for one cycle of RxByteClkHS at the beginning of a high-speed
3265 transmission when RxActiveHS is first asserted. This signal missing is signaled using
3266 ErrSotSyncHS.
3267 • RxUlpmEsc (Output): Escape Ultra Low Power (Receive) mode. This active high signal is
3268 asserted to indicate that the lane module has entered the Ultra Low-Power mode. The lane module
3269 remains in this mode with RxUlpmEsc asserted until a Stop state is detected on the lane
3270 interconnect.
3271 • Stopstate (Output): Lane is in Stop state. This active high signal indicates that the lane module is
3272 currently in Stop state. This signal is asynchronous.
3275 Shutdown is asserted. When Shutdown is high, all PPI outputs are driven to the default inactive
3276 state. Shutdown is a level sensitive signal and does not depend on any clock.
3277 • ErrSotHS (Output): Start-of-Transmission (SoT) Error. If the high-speed SoT leader sequence is
3278 corrupted, but in such a way that proper synchronization can still be achieved, this error signal is
3279 asserted for one cycle of RxByteClkHS. This is considered to be a “soft error” in the leader
3280 sequence and confidence in the payload data is reduced.
3281 • ErrSotSyncHS (Output): Start-of-Transmission Synchronization Error. If the high-speed SoT
3282 leader sequence is corrupted in a way that proper synchronization cannot be expected, this error is
3283 asserted for one cycle of RxByteClkHS.
3284 • ErrControl (Output): Control Error. This signal is asserted when an incorrect line state sequence
3285 is detected.
3286 • ErrEsc (Output): Escape Entry Error. If an unrecognized escape entry command is received, this
3287 signal is asserted and remains high until the next change in line state. The only escape entry
3288 command supported by the receiver is the ULPS.

Confidential
23-May-2022
Annex C CSI-2 Recommended Receiver Error Behavior

(informative)
C.1 Overview
3289 This section proposes one approach to handling error conditions at the receiving side of a CSI-2 Link.
3290 Although the section is informative and therefore does not affect compliance for CSI-2, the approach is
3291 offered by the MIPI Camera Working Group as a recommended approach. The CSI-2 receiver assumes the
3292 case of a CSI-2 Link comprised of unidirectional Lanes for D-PHY Clock and Data Lanes with Escape Mode
3293 functionality on the Data Lanes and a continuously running clock. This Annex does not discuss other cases,
3294 including those that differ widely in implementation, where the implementer should consider other potential
3295 error situations.
3296 Because of the layered structure of a compliant CSI-2 receiver implementation, the error behavior is
3297 described in a similar way with several “levels” where errors could occur, each requiring some
3298 implementation at the appropriate functional layer of the design:
3299 • D-PHY Level errors
3300 Refers to any PHY related transmission error and is unrelated to the transmission’s contents:
3301 • Start of Transmission (SoT) errors, which can be:
3302 • Recoverable, if the PHY successfully identifies the Sync code but an error was detected.
3303 • Unrecoverable, if the PHY does not successfully identify the sync code but does detect a HS
3304 transmission.
3305 • Control Error, which signals that the PHY has detected a control sequence that should not be
3306 present in this implementation of the Link.
3307 • Packet Level errors
3308 This type of error refers strictly to data integrity of the received Packet Header and payload data:
3309 • Packet Header errors, signaled through the ECC code, that result in:
3310 • A single bit-error, which can be detected and corrected by the ECC code
3311 • Two bit-errors in the header, which can be detected but not corrected by the ECC code,
3312 resulting in a corrupt header
3313 • Packet payload errors, signaled through the CRC code
3314 • Protocol Decoding Level errors
3315 This type of error refers to errors present in the decoded Packet Header or errors resulting from an
3316 incomplete sequence of events:
3317 • Frame Sync Error, caused when a FS could not be successfully paired with a FE on a given
3318 virtual channel
3319 • Unrecognized ID, caused by the presence of an unimplemented or unrecognized ID in the
3320 header
3321 The proposed methodology for handling errors is signal based, since it offers an easy path to a viable CSI-2
3322 implementation that handles all three error levels. Even so, error handling at the Protocol Decoding Level
3323 should implement sequential behavior using a state machine for proper operation.

Confidential
23-May-2022
C.2 D-PHY Level Error

3324 The recommended behavior for handling this error level covers only those errors generated by the Data
3325 Lane(s), since an implementation can assume that the Clock Lane is running reliably as provided by the
3326 expected BER of the Link, as discussed in [MIPI01]. Note that this error handling behavior assumes
3327 unidirectional Data Lanes without Escape Mode functionality. Considering this, and using the signal names
3328 and descriptions from the [MIPI01], PPI Annex, signal errors at the PHY-Protocol Interface (PPI) level
3329 consist of the following:
3330 • ErrSotHS: Start-of-Transmission (SoT) Error. If the high-speed SoT leader sequence is corrupted,
3331 but in such a way that proper synchronization can still be achieved, this error signal is asserted for
3332 one cycle of RxByteClkHS. This is considered to be a “soft error” in the leader sequence and
3333 confidence in the payload data is reduced.
3334 • ErrSotSyncHS: Start-of-Transmission Synchronization Error. If the high-speed SoT leader
3335 sequence is corrupted in a way that proper synchronization cannot be expected, this error signal is
3336 asserted for one cycle of RxByteClkHS.
3337 • ErrControl: Control Error. This signal is asserted when an incorrect line state sequence is
3338 detected. For example, if a Turn-around request or Escape Mode request is immediately followed
3339 by a Stop state instead of the required Bridge state, this signal is asserted and remains high until
3340 the next change in line state.
3341 The recommended receiver error behavior for this level is:
3342 • ErrSotHS should be passed to the Application Layer. Even though the error was detected and
3343 corrected and the Sync mechanism was unaffected, confidence in the data integrity is reduced and
3344 the application should be informed. This signal should be referenced to the corresponding data
3345 packet.
3346 • ErrSotSyncHS should be passed to the Protocol Decoding Level, since this is an unrecoverable
3347 error. An unrecoverable type of error should also be signaled to the Application Layer, since the
3348 whole transmission until the first D-PHY Stop state should be ignored if this type of error occurs.
3349 • ErrControl should be passed to the Application Layer, since this type of error doesn’t normally
3350 occur if the interface is configured to be unidirectional. Even so, the application should be aware
3351 of the error and configure the interface accordingly through other, implementation specific-means
3352 that are out of scope for this specification.
3353 Also, it is recommended that the PPI StopState signal for each implemented Lane should be propagated to
3354 the Application Layer during configuration or initialization to indicate the Lane is ready.

Confidential
23-May-2022
C.3 Packet Level Error

3355 The recommended behavior for this error level covers only errors recognized by decoding the Packet
3356 Header’s ECC field and computing the CRC of the data payload.
3357 Decoding and applying the ECC field of the Packet Header should signal the following errors:
3358 • ErrEccDouble: Asserted when an ECC syndrome was computed and two bit-errors are detected in
3359 the received Packet Header.
3360 • ErrEccCorrected: Asserted when an ECC syndrome was computed and a single bit-error in the
3361 Packet Header was detected and corrected.
3362 • ErrEccNoError: Asserted when an ECC syndrome was computed and the result is zero indicating
3363 a Packet Header that is considered to be without errors or has more than two bit-errors. CSI-2’s
3364 ECC mechanism cannot detect this type of error.
3365 Also, computing the CRC code over the whole payload of the received packet could generate the following
3366 errors:
3367 • ErrCrc: Asserted when the computed CRC code is different than the received CRC code.
3368 • ErrID: Asserted when a Packet Header is decoded with an unrecognized or unimplemented data
3369 ID.
3371 • ErrEccDouble should be passed to the Application Layer since assertion of this signal proves that
3372 the Packet Header information is corrupt, and therefore the WC is not usable, and thus the packet
3373 end cannot be estimated. Commonly, this type of error will be accompanied with an ErrCrc. This
3374 type of error should also be passed to the Protocol Decoding Level, since the whole transmission
3375 until D-PHY Stop state should be ignored.
3376 • ErrEccCorrected should be passed to the Application Layer since the application should be
3377 informed that an error had occurred but was corrected, so the received Packet Header was
3378 unaffected, although the confidence in the data integrity is reduced.
3379 • ErrEccNoError can be passed to the Protocol Decoding Level to signal the validity of the current
3380 Packet Header.
3381 • ErrCrc should be passed to the Protocol Decoding Level to indicate that the packet’s payload data
3382 might be corrupt.
3383 • ErrID should be passed to the Application Layer to indicate that the data packet is unidentified and
3384 cannot be unpacked by the receiver. This signal should be asserted after the ID has been identified
3385 and de-asserted on the first Frame End (FE) on same virtual channel.

Confidential
23-May-2022
C.4 Protocol Decoding Level Error

3386 The recommended behavior for this error level covers errors caused by decoding the Packet Header
3387 information and detecting a sequence that is not allowed by the CSI-2 protocol or a sequence of detected
3388 errors by the previous layers. CSI-2 implementers will commonly choose to implement this level of error
3389 handling using a state machine that should be paired with the corresponding virtual channel. The state
3390 machine should generate at least the following error signals:
3391 • ErrFrameSync: Asserted when a Frame End (FE) is not paired with a Frame Start (FS) on the
3392 same virtual channel. An ErrSotSyncHS should also generate this error signal.
3393 • ErrFrameData: Asserted after a FE when the data payload received between FS and FE contains
3394 errors.
3396 • ErrFrameSync should be passed to the Application Layer with the corresponding virtual channel,
3397 since the frame could not be successfully identified. Several error cases on the same virtual
3398 channel can be identified for this type of error.
3399 • If a FS is followed by a second FS on the same virtual channel, the frame corresponding to the
3400 first FS is considered in error.
3401 • If a Packet Level ErrEccDouble was signaled from the Protocol Layer, the whole transmission
3402 until the first D-PHY Stop-state should be ignored since it contains no information that can be
3403 safely decoded and cannot be qualified with a data valid signal.
3404 • If a FE is followed by a second FE on the same virtual channel, the frame corresponding to the
3405 second FE is considered in error.
3406 • If an ErrSotSyncHS was signaled from the PHY Layer, the whole transmission until the first
3407 D-PHY Stop state should be ignored since it contains no information that can be safely decoded
3408 and cannot be qualified with a data valid signal.
3409 • ErrFrameData: should be passed to the Application Layer to indicate that the frame contains data
3410 errors. This signal should be asserted on any ErrCrc and de-asserted on the first FE.

Confidential
23-May-2022
Annex D CSI-2 Sleep Mode (informative)

D.1 Overview
3411 Since a camera in a mobile terminal spends most of its time in an inactive state, implementers need a way to
3412 put the CSI-2 Link into a low power mode that approaches, or may be as low as, the leakage level. This
3413 section proposes one approach for putting a CSI-2 Link in a “Sleep Mode” (SLM). Although the section is
3414 informative and therefore does not affect compliance for CSI-2, the approach is offered by the MIPI Camera
3415 Working Group as a recommended approach.
3416 This approach relies on an aspect of a D-PHY or C-PHY transmitter’s behavior that permits regulators to be
3417 disabled safely when LP-00 (Space state) is on the Link. Accordingly, this will be the output state for a CSI-
3418 2 camera transmitter in SLM.
3419 SLM can be thought of as a three-phase process:
3420 1. SLM Command Phase. The ‘ENTER SLM’ command is issued to the TX side only, or to both
3421 sides of the Link.
3422 2. SLM Entry Phase. The CSI-2 Link has entered, or is entering, the SLM in a controlled or
3423 synchronized manner. This phase is also part of the power-down process.
3424 3. SLM Exit Phase. The CSI-2 Link has exited the SLM and the interface/device is operational. This
3425 phase is also part of the power-up process.
3426 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

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

Confidential
23-May-2022
D.3 SLM Entry Phase

3433 For the second phase, consider one option:
3434 Only the TX side enters SLM and propagates the ULPS to the RX side by sending a D-PHY or C-PHY
3435 ‘ULPS’ command on each Lane. In Figure 220, only the Data Lane ‘ULPS’ command is used as an example.
3436 The D-PHY Dp, Dn, and C-PHY Data_A, Data_C are logical signal names and do not imply specific
3437 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
LP-000 Exit LP-111 Escape Ultra-Low Power LP-000 Exit LP-111

C-PHY Space Sequence Stop Mode State Command Space Sequence Stop
State State Entry 00011110 State State
Initial
3438 State
Figure 220 SLM Synchronization
D.4 SLM Exit Phase

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

Confidential
23-May-2022
Annex E Data Compression for RAW Data Types (normative)

3451 A CSI-2 implementation using RAW data types may support compression on the interface to reduce the data
3452 bandwidth requirements between the host processor and a camera module. Data compression is not mandated
3453 by this Specification. However, if data compression is used, it shall be implemented as described in this
3454 annex.
3455 Data compression schemes use an X–Y–Z naming convention where X is the number of bits per pixel in the
3456 original image, Y is the encoded (compressed) bits per pixel and Z is the decoded (uncompressed) bits per
3457 pixel.
3458 The following data compression schemes are defined:
3459 • 12-10-12
3460 • 12–8–12
3461 • 12–7–12
3462 • 12–6–12
3463 • 10–8–10
3464 • 10–7–10
3465 • 10–6–10
3466 To identify the type of data on the CSI-2 interface, packets with compressed data shall have a User Defined
3467 Data Type value as indicated in Table 61. Note that User Defined data type codes are not reserved for
3468 compressed data types. Therefore, a CSI-2 device shall be able to communicate over the CCI the data
3469 compression scheme represented by a particular User Defined data type code for each scheme supported by
3470 the device. Note that the method to communicate the data compression scheme to Data Type code mapping
3471 is beyond the scope of this document.
3472 The number of bits in a packet shall be a multiple of eight. Therefore, implementations with data compression
3473 schemes that result in each pixel having other than eight encoded bits per pixel shall transfer the encoded
3474 data in a packed pixel format. For example, the 12–7–12 data compression scheme uses a packed pixel format
3475 as described in Section 11.4.2 except the Data Type value in the Packet Header is a User Defined data type
3476 code.
3477 The data compression schemes in this annex are lossy and designed to encode each line independent of the
3478 other lines in the image.
3479 The following definitions are used in the description of the data compression schemes:
3480 • Xorig is the original pixel value
3481 • Xpred is the predicted pixel value
3482 • Xdiff is the difference value (Xorig - Xpred)
3483 • Xenco is the encoded value
3484 • Xdeco is the decoded pixel value

Confidential
23-May-2022
3485 The data compression system consists of encoder, decoder and predictor blocks as shown in Figure 221.
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
3486
Figure 221 Data Compression System Block Diagram
3487 The encoder uses a simple algorithm to encode the pixel values. A fixed number of pixel values at the
3488 beginning of each line are encoded without using prediction. These first few values are used to initialize the
3489 predictor block. The remaining pixel values on the line are encoded using prediction.
3490 If the predicted value of the pixel (Xpred) is close enough to the original value of the pixel (Xorig)
3491 (abs(Xorig - Xpred) < difference limit), its difference value (Xdiff) is quantized using a DPCM codec.
3492 Otherwise, Xorig is quantized using a PCM codec. The quantized value is combined with a code word
3493 describing the codec used to quantize the pixel and the sign bit, if applicable, to create the encoded value
3494 (Xenco).

Confidential
23-May-2022
E.1 Predictors
3495 In order to have meaningful data transfer, both the transmitter and the receiver need to use the same predictor
3496 block.
3497 The order of pixels in a raw image is shown in Figure 222.
C00 C11 C02 C13 C04 C15 C06 C17
C20 C31 C22 C33 C24 C35 C26 C37
3498
Figure 222 Pixel Order of the Original Image
3499 Figure 223 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
3500
Figure 223 Example Pixel Order of the Original Image
3501 Two predictors are defined for use in the data compression schemes.
3502 Predictor1 uses a very simple algorithm and is intended to minimize processing power and memory size
3503 requirements. Typically, this predictor is used when the compression requirements are modest and the original
3504 image quality is high. Predictor1 should be used with 10–8–10, 10–7–10, 12-10-12, and 12–8–12 data
3505 compression schemes.
3506 The second predictor, Predictor2, is more complex than Predictor1. This predictor provides slightly better
3507 prediction than Predictor1 and therefore the decoded image quality can be improved compared to Predictor1.
3508 Predictor2 should be used with 10–6–10, 12–7–12, and 12–6–12 data compression schemes.
3509 Both receiver and transmitter shall support Predictor1 for all data compression schemes.
E.1.1 Predictor1
3510 Predictor1 uses only the previous same color component value as the prediction value. Therefore, only a
3511 two-pixel deep memory is required.
3512 The first two pixels (C00, C11 / C20, C31 or as in example G0, R1 / B0, G1) in a line are encoded without
3513 prediction.
3514 The prediction values for the remaining pixels in the line are calculated using the previous same color
3515 decoded value, Xdeco. Therefore, the predictor equation can be written as follows:
3516 Xpred( n ) = Xdeco( n-2 )

Confidential
23-May-2022
E.1.2 Predictor2
3517 Predictor2 uses the four previous pixel values, when the prediction value is evaluated. This means that also
3518 the other color component values are used, when the prediction value has been defined. The predictor
3519 equations can be written as shown in the following formulas.
3520 Predictor2 uses all color components of the four previous pixel values to create the prediction value.
3521 Therefore, a four-pixel deep memory is required.
3522 The first pixel (C00 / C20, or as in example G0 / B0) in a line is coded without prediction.
3523 The second pixel (C11 / C31 or as in example R1 / G1) in a line is predicted using the previous decoded
3524 different color value as a prediction value. The second pixel is predicted with the following equation:
3526 The third pixel (C02 / C22 or as in example G2 / B2) in a line is predicted using the previous decoded same
3527 color value as a prediction value. The third pixel is predicted with the following equation:
3529 The fourth pixel (C13 / C33 or as in example R3 / G3) in a line is predicted using the following equation:
3530 if ((Xdeco( n-1 ) <= Xdeco( n-2 ) AND Xdeco( n-2 ) <= Xdeco( n-3 )) OR
3531 (Xdeco( n-1 ) >= Xdeco( n-2 ) AND Xdeco( n-2 ) >= Xdeco( n-3 ))) then
3533 else
3535 endif
3536 Other pixels in all lines are predicted using the equation:
3537 if ((Xdeco( n-1 ) <= Xdeco( n-2 ) AND Xdeco( n-2 ) <= Xdeco( n-3 )) OR
3540 else if ((Xdeco( n-1 ) <= Xdeco( n-3 ) AND Xdeco( n-2 ) <= Xdeco( n-4 )) OR
3543 else
3544 Xpred( n ) = (Xdeco( n-2 ) + Xdeco( n-4 ) + 1) / 2
3545 endif

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

3549 The 10–8–10 coder offers a 20% bit rate reduction with very high image quality.
3550 Pixels without prediction are encoded using the following formula:
3551 Xenco( n ) = Xorig( n ) / 4
3552 To avoid a full-zero encoded value, the following check is performed:
3553 if (Xenco( n ) == 0) then
3554 Xenco( n ) = 1
3555 endif
3556 Pixels with prediction are encoded using the following formula:
3557 if (abs(Xdiff( n )) < 32) then
3558 use DPCM1
3559 else if (abs(Xdiff( n )) < 64) then
3560 use DPCM2
3562 use DPCM3
3563 else
3564 use PCM
3565 endif
E.2.1.1 DPCM1 for 10–8–10 Coder

3566 Xenco( n ) has the following format:
3567 Xenco( n ) = “00 s xxxxx”
3568 where,
3569 “00” is the code word
3570 “s” is the sign bit
3571 “xxxxx” is the five bit value field
3572 The coder equation is described as follows:
3573 if (Xdiff( n ) <= 0) then
3574 sign = 1
3575 else
3576 sign = 0
3577 endif
3578 value = abs(Xdiff( n ))
3579 Note: Zero code has been avoided (0 is sent as -0).

Confidential
23-May-2022

3581 Xenco( n ) = “010 s xxxx”
3582 where,
3585 “xxxx” is the four bit value field
3587 if (Xdiff( n ) < 0) then
3588 sign = 1
3589 else
3590 sign = 0
3591 endif
3592 value = (abs(Xdiff( n )) - 32) / 2

3594 Xenco( n ) = “011 s xxxx”
3595 where,
3601 sign = 1
3602 else
3603 sign = 0
3604 endif
3605 value = (abs(Xdiff( n )) - 64) / 4
E.2.1.4 PCM for 10–8–10 Coder

3607 Xenco( n ) = “1 xxxxxxx”
3608 where,
3610 the sign bit is not used
3611 “xxxxxxx” is the seven bit value field
3613 value = Xorig( n ) / 8

Confidential
23-May-2022

3614 The 10–7–10 coder offers 30% bit rate reduction with high image quality.
3616 Xenco( n ) = Xorig( n ) / 8
3619 Xenco( n ) = 1
3622 use DPCM1
3624 use DPCM2
3626 use DPCM3
3628 use DPCM4
3629 else
3630 use PCM
3631 endif

3633 Xenco( n ) = “000 s xxx”
3634 where,
3637 “xxx” is the three bit value field
3640 sign = 1
3641 else
3642 sign = 0
3643 endif

Confidential
23-May-2022

3647 Xenco( n ) = “0010 s xx”
3648 where,
3651 “xx” is the two bit value field
3654 sign = 1
3655 else
3656 sign = 0
3657 endif
3658 value = (abs(Xdiff( n )) - 8) / 2

3660 Xenco( n ) = “0011 s xx”
3661 where,
3667 sign = 1
3668 else
3669 sign = 0
3670 endif
3671 value = (abs(Xdiff( n )) - 16) / 4

3673 Xenco( n ) = “01 s xxxx”
3674 where,
3680 sign = 1
3681 else
3682 sign = 0
3683 endif
3684 value = (abs(Xdiff( n )) - 32) / 8

Confidential
23-May-2022

3686 Xenco( n ) = “1 xxxxxx”
3687 where,
3690 “xxxxxx” is the six bit value field
3692 value = Xorig( n ) / 16

Confidential
23-May-2022

3693 The 10–6–10 coder offers 40% bit rate reduction with acceptable image quality.
3695 Xenco( n ) = Xorig( n ) / 16
3698 Xenco( n ) = 1
3699 endif
3702 use DPCM1
3704 use DPCM2
3706 use DPCM3
3708 use DPCM4
3710 use DPCM5
3711 else
3712 use PCM
3713 endif

3715 Xenco( n ) = “00000 s”
3716 where,
3719 the value field is not used
3721 sign = 1

3724 Xenco( n ) = “00001 s”
3725 where,
3731 sign = 1
3732 else
3733 sign = 0
3734 endif

Confidential
23-May-2022

3736 Xenco( n ) = “0001 s x”
3737 where,
3740 “x” is the one bit value field
3743 sign = 1
3744 else
3745 sign = 0
3746 value = (abs(Xdiff( n )) - 3) / 4
3747 endif

3749 Xenco( n ) = “001 s xx”
3750 where,
3756 sign = 1
3757 else
3758 sign = 0
3759 endif
3760 value = (abs(Xdiff( n )) - 11) / 8

3762 Xenco( n ) = “01 s xxx”
3763 where,
3769 sign = 1
3770 else
3771 sign = 0
3772 endif
3773 value = (abs(Xdiff( n )) - 43) / 16

Confidential
23-May-2022

3775 Xenco( n ) = “1 xxxxx”
3776 where,
3781 value = Xorig( n ) / 32

Confidential
23-May-2022
E.2.4 Coder for 12-10-12 Data Compression

3782 The 12–10–12 coder offers a 16.7% bit rate reduction with very high image quality.
3784 Xenco( n ) = Xorig( n ) / 4
3787 Xenco( n ) = 1
3788 endif
3791 use DPCM1
3793 use DPCM2
3795 use DPCM3
3796 else
3797 use PCM
3798 endif

3800 Xenco( n ) = “00 s xxxxxxx”
3801 where,
3807 sign = 1
3808 else
3809 sign = 0
3810 endif
3812 Note:
3813 Zero code has been avoided (0 is sent as -0).

Confidential
23-May-2022

3815 Xenco( n ) = “010 s xxxxxx”
3816 where,
3822 sign = 1
3823 else
3824 sign = 0
3825 endif
3826 value = (abs(Xdiff( n )) - 128) / 2

3829 where,
3835 sign = 1
3836 else
3837 sign = 0
3838 endif
3839 value = (abs(Xdiff( n )) - 256) / 4

3841 Xenco( n ) = “1 xxxxxxxxx”
3842 where,
3845 “xxxxxxxxx” is the nine bit value field
3847 value = Xorig( n ) / 8

Confidential
23-May-2022

3848 The 12–8–12 coder offers 33% bit rate reduction with very high image quality.
3850 Xenco( n ) = Xorig( n ) / 16
3853 Xenco( n ) = 1
3854 endif
3857 use DPCM1
3859 use DPCM2
3861 use DPCM3
3863 use DPCM4
3865 use DPCM5
3866 else
3867 use PCM

3869 Xenco( n ) = “0000 s xxx”
3870 where,
3876 sign = 1
3877 else
3878 sign = 0
3879 endif

Confidential
23-May-2022

3883 Xenco( n ) = “011 s xxxx”
3884 where,
3890 sign = 1
3891 else
3892 sign = 0
3893 endif
3894 value = (abs(Xdiff( n )) - 8) / 2

3896 Xenco( n ) = “010 s xxxx”
3897 where,
3903 sign = 1
3904 else
3905 sign = 0
3906 endif
3907 value = (abs(Xdiff( n )) - 40) / 4

3909 Xenco( n ) = “001 s xxxx”
3910 where,
3916 sign = 1
3917 else
3918 sign = 0
3919 endif
3920 value = (abs(Xdiff( n )) - 104) / 8

Confidential
23-May-2022

3922 Xenco( n ) = “0001 s xxx”
3923 where,
3929 sign = 1
3930 else
3931 sign = 0
3932 endif
3933 value = (abs(Xdiff( n )) - 232) / 16

3936 where,
3941 value = Xorig( n ) / 32

Confidential
23-May-2022

3942 The 12–7–12 coder offers 42% bit rate reduction with high image quality.
3944 Xenco( n ) = Xorig( n ) / 32
3947 Xenco( n ) = 1
3948 endif
3951 use DPCM1
3953 use DPCM2
3955 use DPCM3
3957 use DPCM4
3959 use DPCM5
3961 use DPCM6
3962 else
3963 use PCM
3964 endif

3966 Xenco( n ) = “0000 s xx”
3967 where,
3973 sign = 1
3974 else
3975 sign = 0
3976 endif

Confidential
23-May-2022

3980 Xenco( n ) = “0001 s xx”
3981 where,
3987 sign = 1
3988 else
3989 sign = 0
3990 endif
3991 value = (abs(Xdiff( n )) - 4) / 2

3993 Xenco( n ) = “0010 s xx”
3994 where,
4000 sign = 1
4001 else
4002 sign = 0
4003 endif
4004 value = (abs(Xdiff( n )) - 12) / 4

4006 Xenco( n ) = “010 s xxx”
4007 where,
4013 sign = 1
4014 else
4015 sign = 0
4016 endif
4017 value = (abs(Xdiff( n )) - 28) / 8

Confidential
23-May-2022

4019 Xenco( n ) = “011 s xxx”
4020 where,
4026 sign = 1
4027 else
4028 sign = 0
4029 endif
4030 value = (abs(Xdiff( n )) - 92) / 16

4032 Xenco( n ) = “0011 s xx”
4033 where,
4039 sign = 1
4040 else
4041 sign = 0
4042 endif
4043 value = (abs(Xdiff( n )) - 220) / 32

4046 where,
4051 value = Xorig( n ) / 64

Confidential
23-May-2022

4052 The 12–6–12 coder offers 50% bit rate reduction with acceptable image quality.
4054 Xenco( n ) = Xorig( n ) / 64
4057 Xenco( n ) = 1
4058 endif
4061 use DPCM1
4063 use DPCM3
4065 use DPCM4
4067 use DPCM5
4069 use DPCM6
4071 use DPCM7
4072 else
4073 use PCM
4074 endif
4075 Note: DPCM2 is not used.

4077 Xenco( n ) = “0000 s x”
4078 where,
4084 sign = 1
4085 else
4086 sign = 0
4087 endif

Confidential
23-May-2022

4091 Xenco( n ) = “0001 s x”
4092 where,
4098 sign = 1
4099 else
4100 sign = 0
4101 endif
4102 value = (abs(Xdiff( n )) - 2) / 4

4104 Xenco( n ) = “010 s xx”
4105 where,
4111 sign = 1
4112 else
4113 sign = 0
4114 endif
4115 value = (abs(Xdiff( n )) - 10) / 8

4117 Xenco( n ) = “0010 s x”
4118 where,
4124 sign = 1
4125 else
4126 sign = 0
4127 endif
4128 value = (abs(Xdiff( n )) - 42) / 16

Confidential
23-May-2022

4130 Xenco( n ) = “011 s xx”
4131 where,
4137 sign = 1
4138 else
4139 sign = 0
4140 endif
4141 value = (abs(Xdiff( n )) - 74) / 32

4143 Xenco( n ) = “0011 s x”
4144 where,
4150 sign = 1
4151 else
4152 sign = 0
4153 endif
4154 value = (abs(Xdiff( n )) - 202) / 64

4157 where,
4162 value = Xorig( n ) / 128

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

4166 Pixels without prediction are decoded using the following formula:
4167 Xdeco( n ) = 4 * Xenco( n ) + 2
4168 Pixels with prediction are decoded using the following formula:
4169 if (Xenco( n ) & 0xc0 == 0x00) then
4170 use DPCM1
4171 else if (Xenco( n ) & 0xe0 == 0x40) then
4172 use DPCM2
4174 use DPCM3
4175 else
4176 use PCM
4177 endif
E.3.1.1 DPCM1 for 10–8–10 Decoder

4179 Xenco( n ) = “00 s xxxxx”
4180 where,
4184 The decoder equation is described as follows:
4185 sign = Xenco( n ) & 0x20
4186 value = Xenco( n ) & 0x1f
4187 if (sign > 0) then
4188 Xdeco( n ) = Xpred( n ) - value
4189 else
4190 Xdeco( n ) = Xpred( n ) + value
4191 endif

Confidential
23-May-2022

4193 Xenco( n ) = “010 s xxxx”
4194 where,
4199 sign = Xenco( n ) & 0x10
4200 value = 2 * (Xenco( n ) & 0xf) + 32
4203 else
4205 endif

4207 Xenco( n ) = “011 s xxxx”
4208 where,
4213 sign = Xenco( n ) & 0x10
4214 value = 4 * (Xenco( n ) & 0xf) + 64 + 1
4217 if (Xdeco( n ) < 0) then
4218 Xdeco( n ) = 0
4219 endif
4220 else
4222 if (Xdeco( n ) > 1023) then
4223 Xdeco( n ) = 1023
4224 endif
4225 endif

Confidential
23-May-2022
E.3.1.4 PCM for 10–8–10 Decoder

4228 where,
4232 The codec equation is described as follows:
4233 value = 8 * (Xenco( n ) & 0x7f)
4234 if (value > Xpred( n )) then
4235 Xdeco( n ) = value + 3
4236 endif
4237 else
4239 endif

Confidential
23-May-2022

4241 Xdeco( n ) = 8 * Xenco( n ) + 4
4243 if (Xenco( n ) & 0x70 == 0x00) then
4244 use DPCM1
4245 else if (Xenco( n ) & 0x78 == 0x10) then
4246 use DPCM2
4248 use DPCM3
4250 use DPCM4
4251 else
4252 use PCM
4253 endif

4255 Xenco( n ) = “000 s xxx”
4256 where,
4261 sign = Xenco( n ) & 0x8
4262 value = Xenco( n ) & 0x7
4265 else
4267 endif

4269 Xenco( n ) = “0010 s xx”
4270 where,
4275 sign = Xenco( n ) & 0x4
4276 value = 2 * (Xenco( n ) & 0x3) + 8
4279 else
4281 endif

Confidential
23-May-2022

4283 Xenco( n ) = “0011 s xx”
4284 where,
4289 sign = Xenco( n ) & 0x4
4290 value = 4 * (Xenco( n ) & 0x3) + 16 + 1
4294 Xdeco( n ) = 0
4295 endif
4296 else
4298 if (Xdeco( n ) > 1023) then
4299 Xdeco( n ) = 1023
4300 endif
4301 endif

4303 Xenco( n ) = “01 s xxxx”
4304 where,
4309 sign = Xenco( n ) & 0x10
4310 value = 8 * (Xenco( n ) & 0xf) + 32 + 3
4314 Xdeco( n ) = 0
4315 endif
4316 else
4318 if (Xdeco( n ) > 1023) then
4319 Xdeco( n ) = 1023
4320 endif
4321 endif

Confidential
23-May-2022

4324 where,
4329 value = 16 * (Xenco( n ) & 0x3f)
4332 else
4334 endif

Confidential
23-May-2022

4336 Xdeco( n ) = 16 * Xenco( n ) + 8
4338 if (Xenco( n ) & 0x3e == 0x00) then
4339 use DPCM1
4340 else if (Xenco( n ) & 0x3e == 0x02) then
4341 use DPCM2
4342 else if (Xenco( n ) & 0x3c == 0x04) then
4343 use DPCM3
4345 use DPCM4
4347 use DPCM5
4348 else
4349 use PCM
4350 endif

4352 Xenco( n ) = “00000 s”
4353 where,
4358 Xdeco( n ) = Xpred( n )

4360 Xenco( n ) = “00001 s”
4361 where,
4366 sign = Xenco( n ) & 0x1
4367 value = 1
4370 else
4372 endif

Confidential
23-May-2022

4374 Xenco( n ) = “0001 s x”
4375 where,
4380 sign = Xenco( n ) & 0x2
4381 value = 4 * (Xenco( n ) & 0x1) + 3 + 1
4385 Xdeco( n ) = 0
4386 endif
4387 else
4389 if (Xdeco( n ) > 1023) then
4390 Xdeco( n ) = 1023
4391 endif
4392 endif

4394 Xenco( n ) = “001 s xx”
4395 where,
4400 sign = Xenco( n ) & 0x4
4401 value = 8 * (Xenco( n ) & 0x3) + 11 + 3
4405 Xdeco( n ) = 0
4406 endif
4407 else
4409 if (Xdeco( n ) > 1023) then
4410 Xdeco( n ) = 1023
4411 endif
4412 endif

Confidential
23-May-2022

4414 Xenco( n ) = “01 s xxx”
4415 where,
4420 sign = Xenco( n ) & 0x8
4421 value = 16 * (Xenco( n ) & 0x7) + 43 + 7
4425 Xdeco( n ) = 0
4426 endif
4427 else
4429 if (Xdeco( n ) > 1023) then
4430 Xdeco( n ) = 1023
4431 endif
4432 endif

4435 where,
4440 value = 32 * (Xenco( n ) & 0x1f)
4442 Xdeco( n ) = value + 15
4443 else
4444 Xdeco( n ) = value + 16
4445 endif

Confidential
23-May-2022

4447 Xdeco( n ) = 4 * Xenco( n ) + 2
4449 if (Xenco( n ) & 0x300 == 0x000) then
4450 use DPCM1
4452 use DPCM2
4454 use DPCM3
4455 else
4456 use PCM
4457 endif

4459 Xenco( n ) = “00 s xxxxxxx”
4460 where,
4465 sign = Xenco( n ) & 0x80
4466 value = Xenco( n ) & 0x7f
4469 else
4471 endif

Confidential
23-May-2022

4474 where,
4479 sign = Xenco( n ) & 0x40
4480 value = 2 * (Xenco( n ) & 0x3f) + 128
4483 else
4485 endif

4488 where,
4493 sign = Xenco( n ) & 0x40
4494 value = 4 * (Xenco( n ) & 0x3f) + 256 + 1
4498 Xdeco( n ) = 0
4499 endif
4500 else
4502 if (Xdeco( n ) > 4095) then
4503 Xdeco( n ) = 4095
4504 endif
4505 endif

Confidential
23-May-2022

4507 Xenco( n ) = “1 xxxxxxxxx”
4508 where,
4511 “xxxxxxxxx” is the nine bit value field
4513 value = 8 * (Xenco( n ) & 0x1ff)
4516 endif
4517 else
4519 endif

Confidential
23-May-2022

4521 Xdeco( n ) = 16 * Xenco( n ) + 8
4523 if (Xenco( n ) & 0xf0 == 0x00) then
4524 use DPCM1
4526 use DPCM2
4528 use DPCM3
4530 use DPCM4
4531 else if (Xenco( n ) & 0xf0 == 0x10) then
4532 use DPCM5
4533 else
4534 use PCM
4535 endif

4537 Xenco( n ) = “0000 s xxx”
4538 where,
4543 sign = Xenco( n ) & 0x8
4547 else
4549 endif

4551 Xenco( n ) = “011 s xxxx”
4552 where,
4557 sign = Xenco( n ) & 0x10
4558 value = 2 * (Xenco( n ) & 0xf) + 8
4561 else
4563 endif

Confidential
23-May-2022

4565 Xenco( n ) = “010 s xxxx”
4566 where,
4571 sign = Xenco( n ) & 0x10
4572 value = 4 * (Xenco( n ) & 0xf) + 40 + 1
4576 Xdeco( n ) = 0
4577 endif
4578 else
4580 if (Xdeco( n ) > 4095) then
4581 Xdeco( n ) = 4095
4582 endif
4583 endif

4585 Xenco( n ) = “001 s xxxx”
4586 where,
4591 sign = Xenco( n ) & 0x10
4592 value = 8 * (Xenco( n ) & 0xf) + 104 + 3
4596 Xdeco( n ) = 0
4597 endif
4598 else
4600 if (Xdeco( n ) > 4095)
4601 Xdeco( n ) = 4095
4602 endif
4603 endif

Confidential
23-May-2022

4605 Xenco( n ) = “0001 s xxx”
4606 where,
4611 sign = Xenco( n ) & 0x8
4612 value = 16 * (Xenco( n ) & 0x7) + 232 + 7
4616 Xdeco( n ) = 0
4617 endif
4618 else
4620 if (Xdeco( n ) > 4095) then
4621 Xdeco( n ) = 4095
4622 endif
4623 endif

4626 where,
4631 value = 32 * (Xenco( n ) & 0x7f)
4633 Xdeco( n ) = value + 15
4634 else
4635 Xdeco( n ) = value + 16
4636 endif

Confidential
23-May-2022

4638 Xdeco( n ) = 32 * Xenco( n ) + 16
4640 if (Xenco( n ) & 0x78 == 0x00) then
4641 use DPCM1
4643 use DPCM2
4645 use DPCM3
4647 use DPCM4
4649 use DPCM5
4651 use DPCM6
4652 else
4653 use PCM
4654 endif

4656 Xenco( n ) = “0000 s xx”
4657 where,
4662 sign = Xenco( n ) & 0x4
4666 else
4668 endif

Confidential
23-May-2022

4670 Xenco( n ) = “0001 s xx”
4671 where,
4676 sign = Xenco( n ) & 0x4
4677 value = 2 * (Xenco( n ) & 0x3) + 4
4680 else
4682 endif

4684 Xenco( n ) = “0010 s xx”
4685 where,
4690 sign = Xenco( n ) & 0x4
4691 value = 4 * (Xenco( n ) & 0x3) + 12 + 1
4695 Xdeco( n ) = 0
4696 endif
4697 else
4699 if (Xdeco( n ) > 4095) then
4700 Xdeco( n ) = 4095
4701 endif
4702 endif

Confidential
23-May-2022

4704 Xenco( n ) = “010 s xxx”
4705 where,
4710 sign = Xenco( n ) & 0x8
4711 value = 8 * (Xenco( n ) & 0x7) + 28 + 3
4715 Xdeco( n ) = 0
4716 endif
4717 else
4719 if (Xdeco( n ) > 4095) then
4720 Xdeco( n ) = 4095
4721 endif
4722 endif

4724 Xenco( n ) = “011 s xxx”
4725 where,
4730 sign = Xenco( n ) & 0x8
4731 value = 16 * (Xenco( n ) & 0x7) + 92 + 7
4735 Xdeco( n ) = 0
4736 endif
4737 else
4739 if (Xdeco( n ) > 4095) then
4740 Xdeco( n ) = 4095
4741 endif
4742 endif

Confidential
23-May-2022

4744 Xenco( n ) = “0011 s xx”
4745 where,
4750 sign = Xenco( n ) & 0x4
4751 value = 32 * (Xenco( n ) & 0x3) + 220 + 15
4755 Xdeco( n ) = 0
4756 endif
4757 else
4759 if (Xdeco( n ) > 4095) then
4760 Xdeco( n ) = 4095
4761 endif
4762 endif

4765 where,
4770 value = 64 * (Xenco( n ) & 0x3f)
4772 Xdeco( n ) = value + 31
4773 else
4774 Xdeco( n ) = value + 32
4775 endif

Confidential
23-May-2022

4777 Xdeco( n ) = 64 * Xenco( n ) + 32
4779 if (Xenco( n ) & 0x3c == 0x00) then
4780 use DPCM1
4782 use DPCM3
4784 use DPCM4
4786 use DPCM5
4788 use DPCM6
4789 else if (Xenco( n ) & 0x3c == 0x0c) then
4790 use DPCM7
4791 else
4792 use PCM
4793 endif
4794 Note: DPCM2 is not used.

4796 Xenco( n ) = “0000 s x”
4797 where,
4802 sign = Xenco( n ) & 0x2
4806 else
4808 endif

Confidential
23-May-2022

4810 Xenco( n ) = “0001 s x”
4811 where,
4816 sign = Xenco( n ) & 0x2
4817 value = 4 * (Xenco( n ) & 0x1) + 2 + 1
4821 Xdeco( n ) = 0
4822 endif
4823 else
4825 if (Xdeco( n ) > 4095) then
4826 Xdeco( n ) = 4095
4827 endif
4828 endif

4830 Xenco( n ) = “010 s xx”
4831 where,
4836 sign = Xenco( n ) & 0x4
4837 value = 8 * (Xenco( n ) & 0x3) + 10 + 3
4841 Xdeco( n ) = 0
4842 endif
4843 else
4845 if (Xdeco( n ) > 4095) then
4846 Xdeco( n ) = 4095
4847 endif
4848 endif

Confidential
23-May-2022

4850 Xenco( n ) = “0010 s x”
4851 where,
4856 sign = Xenco( n ) & 0x2
4857 value = 16 * (Xenco( n ) & 0x1) + 42 + 7
4861 Xdeco( n ) = 0
4862 endif
4863 else
4865 if (Xdeco( n ) > 4095) then
4866 Xdeco( n ) = 4095
4867 endif
4868 endif

4870 Xenco( n ) = “011 s xx”
4871 where,
4876 sign = Xenco( n ) & 0x4
4877 value = 32 * (Xenco( n ) & 0x3) + 74 + 15
4881 Xdeco( n ) = 0
4882 endif
4883 else
4885 if (Xdeco( n ) > 4095) then
4886 Xdeco( n ) = 4095
4887 endif
4888 endif

Confidential
23-May-2022

4890 Xenco( n ) = “0011 s x”
4891 where,
4896 sign = Xenco( n ) & 0x2
4897 value = 64 * (Xenco( n ) & 0x1) + 202 + 31
4901 Xdeco( n ) = 0
4902 endif
4903 else
4905 if (Xdeco( n ) > 4095) then
4906 Xdeco( n ) = 4095
4907 endif
4908 endif

4911 where,
4916 value = 128 * (Xenco( n ) & 0x1f)
4918 Xdeco( n ) = value + 63
4919 else
4920 Xdeco( n ) = value + 64
4921 Endif

Confidential
23-May-2022
Annex F JPEG Interleaving (informative)

4922 This annex illustrates how the standard features of the CSI-2 protocol should be used to interleave (multiplex)
4923 JPEG image data with other types of image data, e.g. RGB565 or YUV422, without requiring a custom JPEG
4924 format such as JPEG8.
4925 The Virtual Channel Identifier and Data Type value in the CSI-2 Packet Header provide simple methods of
4926 interleaving multiple data streams or image data types at the packet level. Interleaving at the packet level
4927 minimizes the amount of buffering required in the system.
4928 The Data Type value in the CSI-2 Packet Header should be used to multiplex different image data types at
4929 the CSI-2 transmitter and de-multiplex the data types at the CSI-2 receiver.
4930 The Virtual Channel Identifier in the CSI-2 Packet Header should be used to multiplex different data streams
4931 (channels) at the CSI-2 transmitter and de-multiplex the streams at the CSI-2 receiver.
4932 The main difference between the two interleaving methods is that images with different Data Type values
4933 within the same Virtual Channel use the same frame and line synchronization information, whereas multiple
4934 Virtual Channels (data streams) each have their own independent frame and line synchronization information
4935 and thus potentially each channel may have different frame rates.
4936 Since the predefined Data Type values represent only YUV, RGB and RAW data types, one of the User
4937 Defined Data Type values should be used to represent JPEG image data.
4938 Figure 224 illustrates interleaving JPEG image data with YUV422 image data using Data Type values.
4939 Figure 225 illustrates interleaving JPEG image data with YUV422 image data using both Data Type values
4940 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
4941
Figure 224 Data Type Interleaving: Concurrent JPEG and YUV Image Data

Confidential
23-May-2022

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
4942
Figure 225 Virtual Channel Interleaving: Concurrent JPEG and YUV Image Data
4943 Both Figure 224 and Figure 225 can be similarly extended to the interleaving of JPEG image data with any
4944 other type of image data, e.g. RGB565.
4945 Figure 226 illustrates the use of Virtual Channels to support three different JPEG interleaving usage cases:
4946 • Concurrent JPEG and YUV422 image data.
4947 • Alternating JPEG and YUV422 output - one frame JPEG, then one frame YUV
4948 • Streaming YUV22 with occasional JPEG for still capture
4949 Again, these examples could also represent interleaving JPEG data with any other image data type.

Confidential
23-May-2022
Use Case 1: Concurrent JPEG output with YUV data
JPEG JPEG JPEG JPEG 1 Frame 1 Frame JPEG JPEG JPEG JPEG
CSI-2 RX
VC0 Frame VC0
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
CSI-2 RX
VC0
CSI-2 TX
VC0 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
CSI-2 RX
VC0
CSI-2 TX
VC0 Frame Frame

YUV YUV JPEG YUV
YUV YUV YUV YUV YUV YUV

VC1 Frame VC1
Frame Frame Frame Frame Frame
4950
Figure 226 Example JPEG and YUV Interleaving Use Cases

Confidential
23-May-2022

Confidential
23-May-2022
Annex G Scrambler Seeds for Lanes 9 and Above

4951 (See also: Section 9.12).
4952 For Links of 9 to 32 Lanes, the Scrambler PRBS registers of Lanes 9 through 32 should be initialized with
4953 the initial seed values as listed in Table 69.
4954 For Links of more than 32 Lanes, the Scrambler PRBS registers of Lanes 33 and higher shall use the same
4955 initial seed value that is used for the Lane number modulo 32. (See Section 9.12 and Table 69.)
4956 Examples
4957 • Lane 33 shall use the same initial seed value as Lane 1
4961 Table 69 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
4962 Note that the binary representation of each initial seed value is symmetrical with respect to the forwards and
4963 backwards directions, with the exceptions of Lanes 11, 17, and 27. The initial seed values can be created
4964 easily using a Lane index value (i.e., Lane number minus one).

Confidential
23-May-2022

4965

Confidential
23-May-2022
Annex H Guidance on CSI-2 Over C-PHY ALP and PPI

H.1 CSI-2 with C-PHY ALP Mode
4966 C-PHY Alternate Low Power (ALP) Mode is an alternative to the legacy LP mode of C-PHY. ALP Mode
4967 uses solely High-Speed signaling with a special state where the signals can cease toggling and collapse to
4968 zero. The legacy LP Mode signaling and escape sequences have equivalent ALP Mode functions so that the
4969 high-voltage low power signaling can be replaced by ALP Mode signaling if that is beneficial in specific
4970 systems. ALP Mode replaces the legacy LP Mode line levels by the transmission of unique code words that
4971 are used only for Lane signaling events. These unique codes are never produced by the 3-Phase mapping
4972 function, so there is never ambiguity in the interpretation of these codes at the receiver.
4973 Reasons to replace the legacy LP mode with equivalent ALP Mode functions are to begin a transitionary path
4974 to the future so that legacy LP mode might someday be eliminated in some devices. Another reason to choose
4975 ALP Mode over Legacy LP mode is to support systems that have long interconnect between the Primary and
4976 Secondary devices.
H.1.1 Concepts of ALP Mode and Legacy LP Mode

4977 In ALP mode, the conventional LP receivers are not used to detect signaling states. Instead, all
4978 communication is performed using High-Speed signaling levels. The system level functions performed by
4979 ALP signaling are quite similar to the functional behavior of legacy LP mode. The intent of this is to cause
4980 the least amount of disruption to systems that support both ALP Mode and legacy LP mode. Figure 227
4981 shows a comparison of a High-Speed data burst with LP Mode versus ALP Mode. The purpose of this diagram
4982 is to show that each of the intervals in the High-Speed data burst with LP mode correspond to similar intervals
4983 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 Data Post1 Code Code Post2
VA = VB = VC VA = VB = VC
4984
Figure 227 Comparing Data Burst Timing of Legacy LP Mode versus ALP Mode
4985 ALP Mode supports the transmission of High-Speed data bursts as well as the transmission of control
4986 sequences that are traditionally transmitted using legacy LP mode Escape Mode sequences. The format of all
4987 ALP mode bursts is like the timing diagram in Figure 228.
4988 The burst begins and ends in an ALP-Pause state. There are two types of ALP-Pause: ALP-Pause Stop and
4989 ALP-Pause ULPS. ALP-Pause Stop is analogous to the legacy LP mode Stop state; ALP-Pause ULPS is
4990 analogous to the legacy LP mode ULPS state. The only difference between these two types of ALP-Pause
4991 states is the time allowed to wake up from each, which is the duration of the ALP-Pause Wake interval. The
4992 nominal time allowed to wake from ALP-Pause Stop is 100 ns, which is about the same time as the duration
4993 of the LP-001 and LP-000 states at the beginning of a HS Data Burst using legacy LP mode. The nominal
4994 time to wake from the ALP-Pause ULPS state is 1 msec, which is approximately the time allowed in legacy
4995 LP mode for tWAKEUP. (The time that a transmitter drives a Mark-1 state prior to a Stop state to initiate an exit
4996 from ULPS.) The longer wake-up time from ALP-Pause ULPS compared to ALP-Pause Stop allows a lower
4997 power consumption while in the ALP-Pause ULPS state.

Confidential
23-May-2022
4998 The ALP-Pause Stop and ALP-Pause ULPS line states are defined by the following relationships of the Line
4999 levels: VA = VB = VC, and VOD_AB = VOD_BC = VOD_CA = 0. Examples of the ALP-Pause and the ALP-Pause
5000 Wake states are illustrated at the beginning and end of the waveform in Figure 228. The ALP-Pause Wake
5001 state, which is very long compared to a High-Speed Unit Interval, is detected by the low-power wake-up
5002 receiver. This causes the system to leave one of the ALP-Pause states and to begin receiving a High-Speed
5003 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 ...
Niedrig
VA = V B = V C B VA = V B = V C
Post2
“+x” state 3's or 1's Sequence
t3-ALP-PAUSE t3-ALP-PAUSE-WAKE t3-POST2 t3-ALP-PAUSE
5004
Figure 228 ALP Mode General Burst Format
5005 To minimize power consumption while Lane activity has ceased during one of the ALP-Pause states, a special
5006 low-speed and low-power differential receiver circuit is present, in addition to the three High-Speed
5007 differential receivers for A-B, B-C and C-A. This special low-speed and low-power differential receiver has
5008 a nominal +80 mV offset input threshold voltage that detects the difference in differential levels between the
5009 ALP-Pause state (VOD = 0) and ALP-Pause Wake state (VOD = |VOD| Strong). This allows the line signals to
5010 collapse to zero with the 100 ZID termination still connected, and still have a well-defined method to detect
5011 the difference between the ALP-Pause and ALP-Pause Wake line conditions. Collapsing to zero with the
5012 terminations still connected makes it possible for implementations to have very low power consumption
5013 during the ALP-Pause states. The ALP-Pause Wake pulse is very long compared to a High-Speed Unit
5014 Interval so that the wake receiver can be slow and consume very little power compared to the High-Speed
5015 differential receivers.

Confidential
23-May-2022
5016 An example of the differential receiver circuit to support ALP mode is shown in Figure 229. Two different
5017 offset receivers are shown for wake from stop versus wake from ULPS, because the power consumption in
5018 the ALP-Pause ULPS state is expected to be lower than in ALP-Pause Stop state. The ALP-Pause Wake pulse
5019 from the ULPS state can be longer than waking from ALP-Pause Stop, so the ALP ULPS receiver can be
5020 slower and consume less power compared to the ALP Stop receiver.
LP Rx
A + HS Rx_AB
ZTERM
50 - LP Rx
B + HS Rx_BC
ZTERM
50 - LP Rx
C + HS Rx_CA
ZTERM
50 -
CCP
+ ALP_Stop
ALP_Pause_Wake_from_Stop
VOFFSET
+80mV
-
+ ALP_ULPS
ALP_Pause_Wake_from_ULPS
VOFFSET
+80mV
-
5021
Figure 229 High-Speed and ALP-Pause Wake Receiver Example
5022 The C-PHY specification defines thirteen unique 7-symbol ALP Code Words that are the functional
5023 equivalent of the LP pulse sequences of legacy LP mode. In some cases, a single 7-symbol ALP Code Word
5024 can replace the transmission of a long sequence of legacy LP mode pulses, such as for the transmission of
5025 Escape Mode triggers or low-power data transmission. The CSI-2 specification needs only three of these LP
5026 mode pulse sequences to emulate the functionality of legacy LP mode: Stop Code, ULPS Code, and Post. A
5027 fourth code, the TAC Code, is used for Fast Bus Turnaround.
5028 Exit from and entry into the ALP-Pause state, which is the functional equivalent of the legacy LP mode Stop
5029 state, requires a special ALP Mode sequence consisting of one or more Stop Codes or ULPS codes followed
5030 by a string of Post codes followed by setting the voltage of all three Lines of a Lane to the same value.
5031 As illustrated in Figure 227, the burst starting sequence of the legacy LP mode consisting of: LP-111, LP-
5032 001, and LP-000 followed by preamble, has a functional equivalent sequence in ALP Mode consisting of:
5033 ALP-Pause Stop followed by ALP Pause Wake followed by preamble. Similarly, the burst ending sequence
5034 of legacy LP mode consisting of Post sequence followed by LP-111, has a functional equivalent sequence in
5035 ALP Mode consisting of: the Post1 field by two or more Stop Codes followed by the Post2 field followed by
5036 ALP-Pause Stop.

Confidential
23-May-2022
H.1.2 Burst Examples Using ALP Mode

5037 Figure 230 shows examples of the three types of High-Speed bursts that can be sent in ALP mode. Many
5038 combinations of ALP code sequences are possible, but Figure 230 shows three sequences that adequately
5039 perform the functions necessary to support CSI-2 that are currently performed using legacy LP mode. The
5040 ALP state machine from the C-PHY Specification has been highlighted in Figure 231, Figure 232, and
5041 Figure 233 to show how transmission of these three sequences should occur.
5042 For interop sake, only these three types of sequences are required to support CSI-2. Note that all bursts begin
5043 in the same manner with the assertion of ALP-Pause Wake followed by a Preamble. The words that follow
5044 the Preamble determine the type of burst that is being transmitted. All bursts end in the same manner with
5045 multiple Stop Codes followed by the Post2 field, or multiple ULPS Codes followed by the Post2 field. The
5046 Post 1 and Post2 fields are the same as Post (4444444), described in the C-PHY specification for burst
5047 transmission using legacy LP mode. The only difference is that the Post1 and Post2 fields are transmitted as
5048 a result of signaling over the PPI from the CSI-2 Tx to the C-PHY Tx.
5049 The last ALP code sent in the burst determines whether the system enters the ALP-Pause Stop or the ALP-
5050 Pause ULPS state.

Confidential
23-May-2022
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 Header Sync Header Forward Data Post1 Code Code Post2
Command to Enter ULPS

ALP Pause
ALP-Pause Stop ALP Command ALP-Pause ULPS
Wake
Lane +x state ULPS ULPS
Signals Preamble Code Code Post2
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
5051
Figure 230 Examples of Bursts to Send High-Speed Data and ALP Commands

Confidential
23-May-2022
5052 Figure 231 shows the ALP state machine transitions (highlighted in red) necessary to transmit a High-Speed
5053 data burst in ALP mode. States and state transitions that are not used by CSI-2 for any type of burst are shown
5054 using dashed lines. The red highlighted states and transitions indicate the path required to transmit and receive
5055 the High-Speed Data Burst example in Figure 230.
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.
5056
Figure 231 State Transitions for an HS Data Burst

Confidential
23-May-2022
5057 Figure 232 shows the ALP state machine transitions (highlighted in red) necessary to enter the ALP-Pause
5058 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.
5059
Figure 232 State Transitions to Enter the ULPS State

Confidential
23-May-2022
5060 Figure 233 shows the ALP state machine transitions (highlighted in red) necessary to enter the ALP-Pause
5061 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.
5062
Figure 233 State Transitions to Exit from the ULPS State
5063 Table 70 describes the 7-symbol codes transmitted in ALP mode. The corresponding LP mode or Escape
5064 mode function is described, where applicable.
5065 Table 70 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
23-May-2022
H.1.3 Transmission and Reception of ALP Commands Through the PPI

5066 In ALP mode there are three types of code words transmitted by the PHY:
5067 • Data: Data words received from the CSI-2 Tx are mapped through the C-PHY mapper, encoded,
5068 and transmitted over the Lane.
5069 • Sync Words: The CSI-2 Tx can cause the C-PHY Tx to transmit a Sync Word in place of a data
5070 word created by the C-PHY mapper. Sync Words can have one of five different values which are
5071 defined as Sync Types.
5072 • ALP Codes: The CSI-2 Tx can cause the C-PHY Tx to transmit a specific ALP code which is one
5073 of the 7-symbol sequences defined in Table 70.
5074 These three different types of code words comprise a high-speed burst while in ALP mode. Figure 234
5075 highlights the control signals that facilitate the transmission of each of these three different types of code
5076 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
5077
Figure 234 PPI Example: HS Signals for Transmission of Data, Sync and ALP Commands
5078 Figure 235 and Figure 236 show examples of PPI signals and the corresponding PHY data for transmission
5079 and reception of high-speed data in ALP mode. These figures show additional detail of the High-Speed Data
5080 Burst waveform in Figure 230.
5081 The signal TxRequestHS is asserted simultaneously with TxWordValidHS to request that a high-speed burst
5082 be transmitted. The PHY will know to send a data burst because TxWordValidHS is asserted early in the burst
5083 timing. This will cause the C-PHY Tx to transmit the first Sync Word at the end of the Preamble. Note that
5084 the first Sync Word is transmitted autonomously by the C-PHY Tx, and has the default Sync Type value of
5085 3. Subsequent Sync Words transmitted in a burst are sent as a result of asserting the TxSendSyncHS[0] signal,
5086 and the associated Sync Type is defined by the TxSyncTypeHS0[2:0] signals.
5087 The end of burst in the Transmitter functions differently for ALP mode compared to the non-ALP high-speed
5088 mode. In the non-ALP high-speed mode, the end of burst is signaled to the PHY by pulling TxRequestHS
5089 low, as described in Annex A of the C-PHY specification. After TxRequestHS goes low, the C-PHY Tx will
5090 generate the Post sequence of length determined by a PHY configuration parameter that sets the length of
5091 Post.
5092 In ALP mode, the protocol transmit unit generates all fields of the burst after the first sync word, including
5093 the packet headers, data burst, Stop Code, ULPS Code, Post1, and Post2. The burst is ended by pulling
5094 TxRequestHS low, and no additional data is transmitted on the Lane after this time.

Confidential
23-May-2022
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
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
5095
Figure 235 PPI Example Transmit Side Timing for an HS Data Burst

Confidential
23-May-2022
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
RxDataHS[X:0] dc W1 W2 W3 dc W1 W2 W3 W4 W5 Wn dc
RxValidHS
RxSyncHS
RxALPValidHS dc
Stop Stop
RxALPCode[3:0] dc Post1
Code Code
Post2 dc
RxActiveHS dc
5096
Figure 236 PPI Example Receive Side Timing for an HS Data Burst

Confidential
23-May-2022
5097 Figure 237, Figure 238, Figure 239, and Figure 240 show examples of PPI signals and the corresponding
5098 PHY data for transmission and reception ALP Commands to enter into and exit from the ALP-Pause ULPS
5099 state in ALP mode. These figures show additional detail of the Command to Enter ULPS and the Command
5100 to Exit from ULPS waveforms in Figure 230.
5101 The signal TxRequestHS is asserted simultaneously with TxSendALPHS to request that a high-speed burst
5102 be transmitted. The PHY will know to send a ALP commands in the burst rather than the Sync Word because
5103 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
5104
Figure 237 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
5105
Figure 238 PPI Example Receive Side Timing to Enter the ULPS State

Confidential
23-May-2022
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
5106
Figure 239 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
5107
Figure 240 PPI Example Receive Side Timing to Exit from the ULPS State

Confidential
23-May-2022
H.1.4 Multi-Lane Operation Using ALP Mode

5108 Figure 241 and Figure 242 show examples of three Lanes operating together in a Link in ALP mode. The
5109 High-Speed data burst in Figure 241 begins with identical packet headers (consisting of PH W0, PH W1,
5110 and PH W2) transmitted twice on each of the three Lanes. The Packet Headers are followed by packet data
5111 (consisting of DW 0 through DW n-1) striped across the three Lanes by the CSI-2 Lane Distribution Function.
5112 The burst starts and ends in the manner described in Section H.1.2 above. The example of Figure 242
5113 showing the command to enter ULPS has identical data on each of the three Lanes.
5114 The example also shows that the assertion of the +x state for ALP-Pause Wake can be staggered in time on
5115 each of the lanes. This is shown to highlight a particular implementation where the system designer might
5116 prefer to enable the high-speed drivers for each of the Lanes at a slightly different time.

Confidential
23-May-2022
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 Code Code Post2
Signals VA = VB = VC W0 W1 W2 W0 W1 W2 0 3 6 9 n-3
VA = VB = VC
ALP
ALP-Pause Stop HS Burst Command ALP-Pause Stop
VA = VB = VC
ALP-Pause ALP
ALP-Pause Stop Wake HS Burst Command ALP-Pause Stop
VA = VB = VC
5117
Figure 241 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 = V B = V C VA = VB = VC
ALP-Pause ALP
ALP-Pause ALP
5118
Figure 242 Example Showing an ALP Command Burst using Three Lanes

Confidential
23-May-2022
H.1.5 LP and ALP Operation

5119 Section 6.4.5.8 of [MIPI02] describes support of LP and ALP operation. The transmitter and receiver can be
5120 configured for LP-only operation, or ALP-only operation using the PPI signals TxALP-LPSelect and RxALP-
5121 LPSelect, respectively. Devices can use a variety of means such as a register, an I/O pin, or a non-volatile
5122 storage element to determine the initial state of these two PPI signals
H.1.6 Bi-Directional Lane Turnaround

5123 The transmission direction of a Bi-Directional Lane can be swapped by performing a Lane Turnaround
5124 procedure. This procedure enables information transfer in the opposite direction of the current direction. The
5125 procedure is the same for either a change from Forward Direction to Reverse Direction, or a change from
5126 Reverse Direction to Forward Direction. Notice that the roles of Primary and Secondary are not changed as
5127 a result of performing the Turnaround procedure.
5128 The Turnaround procedure can be performed in two ways: one is via a Control Mode Lane Turnaround that
5129 uses LP Mode signaling, and the other is via a Fast Lane Turnaround.
5130 Control Mode Lane Turnaround occurs by going to the Exit state (Control Mode) where LP Mode signaling
5131 is used to perform the Control Mode Turnaround procedure, as shown in Figure 243.
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
Primary is Driving Primary is Driving
Secondary is Driving
5132
Figure 243 High-Level View of the Control Mode Lane Turnaround Procedure
5133 A somewhat less likely configuration is to combine ALP mode and Control Mode Lane Turnaround if optional
5134 Dynamic LP and ALP operation is supported by the C-PHY, and if the electrical specifications can be met
5135 with the transmission channel being used in the system. An example is shown in Figure 244.
ALP with Control Mode Lane Turnaround
Post1
Post2
Stop
Sync
Sync
Sync
+x state Preamble Post Preamble Post Preamble

High-Speed Forward Data Turnaround High-Speed Reverse Data Turnaround High-Speed Forward Data
EoT SoT EoT SoT
5136
Figure 244 High-Level View of ALP Mode with the Control Mode Lane Turnaround
Procedure

Confidential
23-May-2022
5137 Fast Lane Turnaround is the most likely method to be used with the CSI-2 USL feature. Fast Lane Turnaround
5138 is performed without having to return to LP mode. This reduces the latency to change the transmission
5139 direction of a Bi-directional lane. Fast Lane Turnaround is handled completely in High-Speed mode. One or
5140 more Turnaround Codes (TAC) is transmitted near the end of the burst (between Post1 and Post 2) to inform
5141 the receiver that the Lane is about to change the transmission direction. A small Turnaround Gap (TGAP)
5142 exists between Post2 from the First Transmitting Device and the Preamble from the Second Transmitting
5143 Device to allow the Primary and Secondary to swap roles as transmitter and receiver. Figure 245 shows a
5144 high-level view of the Fast Lane Turnaround Procedure with ALP Mode. It is anticipated that the Fast Lane
5145 Turnaround will most often be used with ALP Mode, and infrequently with Control Mode.
Fast Lane Turnaround
Post2
Post1
Post1
Post2
Post1
Post2
Sync
Stop
Sync
Sync
TAC
TAC
+x state Preamble TGAP TGAP
Preamble Preamble
Primary is Driving Secondary is Driving Primary is Driving
5146
Figure 245 High-Level View of the Fast Lane Turnaround Procedure with ALP Mode

Confidential
23-May-2022
5147 Figure 246 is a comparison of events that occur in the Fast Lane Turnaround Procedure versus the Control
5148 Mode Lane Turnaround Procedure. Fields that are the same color are either the same field in the two
5149 waveforms, or have comparable durations. Post1 + TAC + Post2 in the Fast Lane Turnaround is like Post in
5150 the Control Mode Lane Turnaround. The Preambles are the same duration and Syncs are the same duration.
5151 Fields that cause the durations of the two Turnaround methods to be different are highlighted with “Time
5152 difference between Fast Lane Turnaround and Control Mode Lane Turnaround” in the figure. In this case,
5153 the TGAP (nominally 14 UI) in the Fast Lane Turnaround waveform is usually much shorter in duration
5154 compared to the LP signaling (EoT + Turnaround + SoT, in the Control Mode Lane Turnaround waveform).
Fast Lane Turnaround
Post1
Post1
Post2
Post2
Post1
Post2
Stop
Sync
Sync
Sync
TAC
TAC
+x state Preamble TGAP TGAP
Preamble Preamble
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
5155
Figure 246 High-Level View, Comparing Lane Turnaround Procedures
5156 The Fast Lane Turnaround Procedure is triggered by the transmission of a sequence of ALP codes at the end
5157 of a burst.

Confidential
23-May-2022
5158 Figure 247 shows the detailed sequence of events that occur during the Fast Lane Turnaround Procedure.
5159 The transmitting C-PHY ends the data burst by sending Post1, followed by the TAC symbol sequence,
5160 followed by Post2. TAC is the symbol sequence “2144441”, which is an unmapped sequence of seven
5161 symbols. The least significant symbol of TAC (“1”) is transmitted first and the most significant symbol (“2”)
5162 is transmitted last, which is the same convention used for transmitting any ALP code word. TAC may be
5163 transmitted multiple times for improved system reliability, to increase the probability that TAC will be
5164 detected by the receiver. The Post1 + TAC + Post2 is somewhat similar to the end of a burst in ALP mode,
5165 except that the TAC Code is sent instead of the Stop Code. The protocol receiver can easily identify the end
5166 of Packet Data when it detects Post1. The duration of the TAC and Post2 are programmable in the transmitter,
5167 and this duration is determined by the protocol layer. The protocol layer enables the transmission of Post1,
5168 TAC, and Post2 via the PPI signals TxSendALPHS[1:0], TxALPCodeHS0[3:0], and TxALPCodeHS1[3:0].
5169 The purpose of Post1 is to indicate the end of the burst and provide a sufficient number of word clock intervals
5170 so the protocol layer can gracefully stop transmitting and receiving packet data that is sent prior to Post1.
5171 Post2 exists so the C-PHY transmitter and receiver has a sufficient number of clock intervals following TAC
5172 to be able to shut down transmitter and receiver circuitry and change the direction of transmission.
5173 A Turnaround Gap (TGAP) exists to allow one transmitter to be disabled before the other is enabled. This
5174 avoids contention between the two drivers. The First Transmitting Device that sent the TAC disables its
5175 output by placing the driver into a high-impedance state just after the last symbol of Post2. The C-PHY
5176 ensures that the transmitter in the First Transmitting Device is completely disabled at the end of TGAP. The
5177 Second Transmitting Device begins to enable its output after TGAP at the beginning of the Preamble.
5178 When the Second Transmitting Device receives TAC, it starts a timer that is used to determine when the end
5179 of TGAP, and the beginning of Preamble, should occur. It is necessary for the Second Transmitting Device
5180 to identify this interval using a timer, because there are no transmissions during TGAP to identify when the
5181 Second Transmitting Device needs to begin transmitting the Preamble. The number of words of TAC and
5182 duration of Post2 can be stored in registers in both the First Transmitting Device and Second Transmitting
5183 Device, so the C-PHY can determine the proper t3-TAC_TO_TX time. This is so the Second Transmitting Device
5184 starts transmitting Preamble at the proper time at the end of TGAP. The number of words of TAC and duration
5185 of Post2 can be different when transmission changes from Primary to Secondary, versus from Secondary to
5186 Primary. Therefore, it is necessary for the Primary and Secondary to have registers related to the TAC duration
5187 and Post2 duration for both types of turnaround (Primary-to-Secondary and Secondary-to-Primary).
5188 An interval t3-TA-SETTLE exists to allow the driver transmitting the Preamble to have sufficient time to stabilize
5189 before it is used by the receiver for symbol clock recovery. The t 3-TA-SETTLE interval is a time during which
5190 the HS receiver in the C-PHY will ignore any HS transitions on the Lane. This concept is very similar to the
5191 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
5192
Figure 247 Detailed View of the Fast Lane Turnaround Procedure

Confidential
23-May-2022
5193 Figure 248 shows an example of ALP state machine transitions (highlighted in red) that occur when a burst
5194 begins in the conventional manner with an ALP-Pause Wake pulse and finishes by performing a Fast Lane
5195 Turnaround Procedure. This is the sequence of events that occur during the first “Primary is Driving” interval
5196 shown in Figure 245. The highlighted sequence begins from the ALP-Pause Stop state, and ends when the
5197 turnaround event occurs during the HS-BTA Rx Wait state. This state diagram presents a high-level view of
5198 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
5199
Figure 248 State Transitions from ALP-Pause Stop to Turnaround

Confidential
23-May-2022
5200 Figure 249 shows an example of ALP state machine transitions (highlighted in red) that occur between two
5201 Fast Lane Turnaround events. This is the sequence of events that occur during the “Secondary is Driving”
5202 interval shown in Figure 245.
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
5203
Figure 249 State Transitions from Turnaround to Turnaround

Confidential
23-May-2022
5204 Figure 250 shows an example of ALP state machine transitions (highlighted in red) that occur, starting from
5205 a Fast Lane Turnaround Procedure (the HS-BTA Rx Wait state) and finishing when the burst ends and there
5206 is a transition to the ALP-Pause Stop state. This is the sequence of events that occur during the second
5207 “Primary is Driving” interval shown in Figure 245.
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
5208
Figure 250 State Transitions from Turnaround to ALP-Pause Stop
5209 The PPI signals that support ALP functions are used to perform a Fast Lane Turnaround. The first transmitting
5210 device stops transmission in much the same way as a transmitter signals the end of an ALP burst, except that
5211 a TAC code is sent instead of a Stop code. The first transmitting device becomes a receiver after it ceases
5212 transmission, so it can immediately switch to receive mode. In this case, the device that becomes a receiver
5213 does not need to be triggered by a long ALP Pause Wake pulse prior to the preamble. Instead, the trigger for
5214 assuming the role of a receiver is the transmission of the TAC code prior to the TGAP interval.

Confidential
23-May-2022
5215 Figure 251 shows an example of the of the transmitter and receiver PPI signaling in the first transmitting
5216 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)
PH PH PH PH PH PH
RxDataHS[X:0] dc W1 W2 W3 dc W1 W2 W3 W4 W5
RxValidHS
RxSyncHS
RxALPValidHS
RxALPCode[3:0] dc
RxActiveHS
5217
Figure 251 Example Fast Lane Turnaround at the First Transmitting Device

Confidential
23-May-2022
5218 Figure 252 shows an example of the of the receiver and transmitter PPI signaling in the second transmitting
5219 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)
PH PH PH PH PH PH
TxDataHS[X:0] W1 W2 W3 dc W1 W2 W3 W4 W5
TxWordValidHS
TxSendSyncHS
TxSendALPHS
TxALPCodeHS[3:0] dc
TxRequestHS
TxReadyHS
5220
Figure 252 Example Fast Lane Turnaround at the Second Transmitting Device

Confidential
23-May-2022
Annex I Multi-Pixel Compression (MPC)

5221 Multi-Pixel image sensors such as Tetra-Cell and Nona-Cell image sensors have been developed as image
5222 resolution has increased. As the amount of data being transmitted has increased, the importance of efficient
5223 transmission has grown. For improved efficiency, CSI-2 supports the MPC (Multi-Pixel Compression) data
5224 compression scheme for Multi-Pixel images.
5225 MPC can compress not only Multi-Pixel images, but also the common Bayer pattern image. Compared with
5226 the common Bayer pattern image, a Multi-Pixel image has additional compression opportunities because
5227 neighboring pixels with the same color filter are highly correlated. MPC outperforms conventional
5228 compression by utilizing this redundancy.
5229 MPC is specified for Bayer, Tetra-Cell, and Nona-Cell image sensors, as shown in Figure 253. MPC provides
5230 three compression schemes having 10:5, 10:6, and 10:7 compression ratios for Tetra-Cell, and Nona-Cell
5231 image sensors. Bayer image sensors have only a single compression scheme with a 10:5 compression ratio.
MPC SPECIFICATION
MPC for Bayer MPC for Tetra-Cell MPC for Nona-Cell

Image Sensor Image Sensor Image Sensor
10:5 10:5 10:5

Compression Ratio Compression Ratio Compression Ratio
10:6 10:6
Compression Ratio Compression Ratio
10:7 10:7
Compression Ratio Compression Ratio
5232
Figure 253 MPC Data Compression Schemes
5233 To support high image quality even at high compression ratios, MPC features the following two Prediction
5234 Mode types:
5235 • Basic Prediction Mode includes a simple algorithm to handle image details oriented in a specific
5236 direction, or basic cases of differences between neighboring pixels.
5237 • Advanced Prediction Mode has a more extensive algorithm for better direction awareness.
5238 MPC Packet data is identified using one of the User Defined data type codes in Table 61. Note that User
5239 Defined data type codes are not reserved for compressed data types. Therefore, it is recommended that the
5240 assignment of specific User Defined data type codes to compression schemes be communicated to the image
5241 sensor via the CCI. The protocol and CCI register address to map a data compression scheme to a Data Type
5242 code are beyond the scope of this specification.
5243 The number of bits in an MPC Packet shall be a multiple of eight. Therefore, implementations with data
5244 compression schemes that result in each pixel having other than eight encoded bits per pixel shall transfer
5245 the encoded data using a packed pixel format. For example, the 10–5–10 data compression scheme cannot
5246 use the RAW6, RAW7, or RAW8 packed pixel formats described in Section 11.4. For this example, the RAW
5247 10 format described in Section 11.4.2 is appropriate, except that the Data Type value in the Packet Header is
5248 a User Defined data type code. MPC with a Tetra-Cell sensor uses the RAW10, RAW12, or RAW14 formats
5249 depending on the data compression ratio. MPC with a Nona-Cell image sensor uses the RAW10, RAW12, or
5250 RAW14 formats by concatenating two MPC Blocks of encoded data.

Confidential
23-May-2022
5251 The MPC encoded data stream shall consist of a series of Blocks, where each Block represents one
5252 compression processing unit. Each Block shall consist of a 4-bit Header and a Payload whose length shall
5253 depend upon the image sensor type (i.e., Bayer, Tetra-Cell, or Nona-Cell) and the data compression ratio as
5254 defined by Table 71. The number of pixels encoded per Block shall be 4 (1x4) for Bayer image sensors, 4
5255 (2x2) for Tetra-Cell image sensors, and 9 (3x3) for Nona-Cell image sensors.
5256 Example: The MPC Packet for Tetra-Cell image sensors always has 4 compressed pixels per Block and a 4-
5257 bit Header. The Payload size is either 16 bits for compression ratio 10:5, or 20 bits for 10:6 compression, or
5258 24 bits for 10:7 compression.
5259 Table 71 MPC Bits Per Block and CSI-2 Image Data Format
Bits Per Block
Image Pixels CSI-2 RAW Image Data Format
Header Payload Size
Sensor Per
Size (bits)
Type Block
(bits) 10:5 10:6 10:7 10:5 10:6 10:7
RAW10
Bayer 1x4 4 16 N/A N/A N/A N/A
User Defined
RAW10 RAW12 RAW14
Tetra-Cell 2x2 4 16 20 24
User Defined User Defined User Defined
RAW10 (2 Blocks) RAW12 (2 Blocks) RAW14 (2 Blocks)
Nona-Cell 3x3 4 41 50 59
User Defined User Defined User Defined
5260 Figure 254 illustrates the RAW10 transmission scheme for MPC with Bayer image sensors. The MPC
5261 encoded data stream from the Bayer pixel array includes the Header and the Payload, which can be divided
5262 into STR n and STR n+1 to fit into the RAW10 transmission format: STR n includes the Header and some
5263 of the Payload, and STR n+1 includes the rest of the Payload.
* P : Pixel
P00 P01 P02 P03 P04 P05 P06 P07
P10 P11 P12 P13 P14 P15 P16 P17
P20 P21 P22 P23 P24 P25 P26 P27
P30 P31 P32 P33 P34 P35 P36 P37
Pixel array of Bayer
Line Start / Data P00 P01 P0n P0n+1 P0n+2 P0n+3 P0n+4
Encoded data stream

Header Payload 10 : 5 / Encoded data stream : 20 bits
(STR n : 10 bits / STR n+1 : 10 bits) RAW 10 transmission
STR n STR n+1
After compression
Line Start / Data STR 0 STR 1 STR n STR n+1 STR n+2 STR n+3 STR n+4 RAW 10 transmission
5264
Figure 254 RAW10 Transmission for MPC for Bayer Image Sensors

Confidential
23-May-2022
5265 Figure 255 illustrates the RAW10/12/14 transmission scheme for MPC for Tetra-Cell image sensors. The
5266 MPC encoded data stream from the Tetra-Cell pixel array includes the Header and the Payload, which can
5267 be divided into STR n and STR n+1 to fit into the RAW10/12/14 transmission format. STR n includes the
5268 Header and some of Payload, and STR n+1 includes the rest of the Payload.
* P : Pixel
P00 P01 P02 P03 P04 P05 P06 P07
P10 P11 P12 P13 P14 P15 P16 P17
P20 P21 P22 P23 P24 P25 P26 P27
P30 P31 P32 P33 P34 P35 P36 P37
Pixel array of Tetra-cell
Line Start: 0/ Data P00 P01 P0n P0n+1 P0n+2 P0n+3 P0n+4 0 line
Line Start: 1/ Data P10 P11 P1n P1n+1 P1n+2 P1n+3 P1n+4 1 line
Encoded data stream 10 : 5 / Encoded data stream : 20 bits

Header Payload
10 : 6 / Encoded data stream : 24 bits
STR n STR n+1 (STR n : 12 bits / STR n+1 : 12 bits) RAW 12 transmission

After compression
Line Start / Data STR 0 STR 1 STR n STR n+1 STR n+2 STR n+3 STR n+4 RAW 10/12/14 transmission
5269
Figure 255 RAW10/12/14 Transmission for MPC for Tetra-Cell Image Sensors

Confidential
23-May-2022
5270 Figure 256 illustrates the RAW10/12/14 transmission scheme for MPC for Nona-Cell image sensors. The
5271 MPC encoded data stream from the Nona-Cell pixel array includes the Header and the Payload, which can
5272 be divided into the series STR n, STR n+1, …, STR n+8 to fit into the RAW10/12/14 transmission format.
5273 With this division method, STR n, STR n+4, and STR n+5 each include a Header and some of the Payload,
5274 and STR n+1, STR n+2, STR n+3, STR n+6, STR n+7, and STR n+8 include the rest of the Payload.
* P : Pixel
P00 P01 P02 P03 P04 P05 P06 P07 P08 P09 P010 P011
P10 P11 P12 P13 P14 P15 P16 P17 P18 P19 P110 P111
P20 P21 P22 P23 P24 P25 P26 P27 P28 P29 P210 P211
P30 P31 P32 P33 P34 P35 P36 P37 P38 P39 P310 P311
P40 P41 P42 P43 P44 P45 P46 P47 P48 P49 P410 P411
P50 P51 P52 P53 P54 P55 P56 P57 P58 P59 P510 P511
Pixel array of Nona-cell
Line Start: 0 / Data P00 P0n P0n+1 P0n+2 P0n+3 P0n+4 P0n+5 0 line
1 block 1 block
10 : 5 / Encoded data stream : 90bit
MSB LSB
(STR n : 10 bits / STR n+1 : 10 bits / STR n+2 : 10 bits)
Encoded data stream Encoded data stream (STR n+3 : 10 bits / STR n+4 : 10 bits / STR n+5 : 10 bits) RAW 10 transmission
(STR n+6 : 10 bits / STR n+7 : 10 bits / STR n+8 : 10 bits)
Header Payload Header Payload
Ratio/ 10:5 40bit 10bit 40bit
Ratio/ 10:6 48bit 12bit 48bit (STR n : 12 bits / STR n+1 : 12 bits / STR n+2 : 12 bits)
Ratio/ 10:7 56bit 14bit 56bit (STR n+3 : 12 bits / STR n+4 : 12 bits / STR n+5 : 12 bits) RAW 12 transmission
(STR n+6 : 12 bits / STR n+7 : 12 bits / STR n+8 : 12 bits)
STR STR STR STR STR STR STR STR STR
n n+1 n+2 n+3 n+4 n+5 n+6 n+7 n+8 10 : 7 / Encoded data stream : 126 bits
(STR n : 14 bits / STR n+1 : 14 bits / STR n+2 : 14 bits)
Ratio/ 10:5 10bit (STR n+3 : 14 bits / STR n+4 : 14 bits / STR n+5 : 14 bits) RAW 14 transmission
Ratio/ 10:6 12bit (STR n+6 : 14 bits / STR n+7 : 14 bits / STR n+8 : 14 bits)
Ratio/ 10:7 14bit
After compression
Line Start / Data STR 0 STR 1 STR n STR n+1 STR n+2 STR n+8 STR n+9 RAW 10/12/14 transmission
5275
Figure 256 RAW10/12/14 Transmission for MPC for Nona-Cell Image Sensors

Confidential
23-May-2022
5276 The MPC data compression system consists of an MPC Encoder and an MPC Decoder as shown in Figure
5277 257.
Encoder Decoder
Encoded
Original pixel data
Pixel data Mode
Quantization Difference Decoder Decoded
Prediction value
Selection pixel data
Prediction value
Quantized
Quantized
Prediction Decoder Prediction
5278
Figure 257 MPC Data Compression System
5279 To maintain constant bandwidth, MPC encodes data differences using a lossy scheme. The MPC Encoder
5280 uses a variety of defined Compression Modes to improve image quality for object edge patterns. In the MPC
5281 Encoder, each Compression Mode encodes the original pixel data based on direction awareness. The MPC
5282 Encoder uses direction awareness to automatically select the Compression Mode that is the best choice for
5283 minimizing data loss. Pixel values at the beginning of the first image line are encoded using simple prediction.
5284 These first few pixels can use User Control Parameters for boundary fill (see Section I.1.1.1, Section I.2.1.1,
5285 and Section I.3.1.1), so prediction does not need to be initialized for them. The remaining pixel values except
5286 for the first image line are then encoded using normal prediction methods.
5287 The first step in MPC decoding is to calculate the prediction value, based on the Compression Mode that the
5288 MPC Encoder used. In the MPC Packet, this is indicated via Header fields PredictionIDX and ModeIDX.
5289 When performing prediction, previously decoded pixels are used as reference pixels and the image is
5290 reconstructed using difference values relative to those reference pixels. After the prediction the reference
5291 pixel is quantized, again based on the Compression Mode that the MPC Encoder used. The value after
5292 quantization is added to the difference value (i.e., the incoming compressed data for that pixel). The MPC
5293 Decoder’s final output is the reconstructed image, i.e., the decoded image after de-quantization.
5294 The following sections define the MPC Compression Modes for each image sensor type (i.e., Bayer, Tetra-
5295 Cell, and Nona-Cell), and describe the decoding process for each Compression Mode.
5296 Note:
5297 Example code implementing MPC decompression is available from the MIPI Members site [MIPI07].

Confidential
23-May-2022
I.1 MPC for Bayer Image Sensor

5298 MPC for Bayer image sensors supports the seven Compression Modes that are defined in this Section and
5299 summarized in Table 72. If MPC is supported, then all seven MPC decoder Data Compression Modes shall
5300 be supported. Each Compression Mode uses either Basic Prediction Mode or Advanced Prediction Mode.
5301 Figure 258 summarizes the MPC Packet Structures used for Bayer Compression Modes.
5302 Table 72 MPC Compression Modes for Bayer Image Sensors
Compression Defined in
Mode Description
Mode Name Section
Basic Prediction Mode:
PD Pixel-based Directional Differential Mode I.1.2.1
DGD DiaGonal Direction-based Differential Mode I.1.2.1
FNR Fixed Quantization and No-Reference Mode I.1.2.3
OUT OUTlier compensation Mode I.1.2.3
Advanced Prediction Mode:
eDGD extended DiaGonal Direction-based Differential Mode I.1.3.1
ePD extended Pixel-based Directional Differential Mode I.1.3.2
extended Slanted Horizontal or Vertical
eSHV I.1.3.3
Direction-based Differential Mode
5303
Figure 258 MPC Packet Structures for Bayer Compression Modes

Confidential
23-May-2022
I.1.1 Reference Pixels for Prediction (Bayer)

5304 MPC compresses each pixel by referring to neighboring pixels. The reference pixels are selected according
5305 to the Compression Mode and the color of the current pixel.
5306 In a Bayer image, a given pixel is expressed as p(i, j), where:
5307 • i: Horizontal index of the pixel
5308 • j: Vertical index of the pixel
5309 For a current pixel p(h, v), coordinates relative to a reference pixel are expressed as:
5310 • The Horizontal relative index from the current pixel to the reference pixel
5311 • Reference pixels to the left of the current pixel have negative h indexes
5312 • Reference pixels directly above or below the current pixel have zero h indexes
5313 • Reference pixels to the right of the current pixel have positive h indexes
5314 and
5315 • The Vertical relative index from the current pixel to the reference pixel
5316 • Reference pixels located in image lines above the current pixel have negative v indexes
5317 • Reference pixels in the same image line as the current pixel have zero v indexes
5318 Examples:
5319 p(h, v–1) Pixel immediately above the current pixel
5320 p(h–1, v) Pixel immediately to the left of the current pixel
5321 p(h+1, v−1) Pixel immediately above and immediately to the right of the current pixel
5322 p(h–1, v–1) Pixel immediately above and immediately to the left of the current pixel
5323 In the following sub-sections, all reference pixel coordinates are expressed using this notation.

Confidential
23-May-2022
5324 Using this notation, the relative coordinates of reference pixels are as illustrated in Figure 259, where the
5325 color of each square indicates the color filter of the corresponding pixel.
Green Pixel First
Pixels to be Encoded
Blue Pixel First
Not Shown: Red Pixel First
5326
Figure 259 Reference Pixel Relative Coordinate Indexes (Bayer)
5327 For a Bayer image sensor, the four highlighted pixels in the bottom row will be encoded. This corresponds
5328 to pixel coordinates p(h, v) (i.e., the current pixel), p(h+1, v), p(h+2, v), and p(h+3, v). The other colored
5329 squares represent the previously decoded pixels, which are available to be used as reference data.

Confidential
23-May-2022
I.1.1.1 User Control Parameters for Boundary Fill

5330 At the boundary of the image frame, no neighboring reference pixels exist. As a result, difference calculations
5331 for pixels at the image boundary cannot depend upon the values of neighbor pixels. To handle this case, MPC
5332 allows the boundary to be filled with user control parameters. This feature makes prediction possible at the
5333 image boundary despite the absence of actual prediction pixels. The user control parameter should be
5334 calculated before the start of a new image frame by using sensor information such as the luminance value of
5335 the image, or the gain value of the sensor. For example, the user control parameter can be set to the value 64
5336 in low-light conditions or the value 128 for normal conditions.

Confidential
23-May-2022
I.1.2 Basic Prediction Mode (Bayer)

5337 For Bayer image sensors, Basic Prediction Mode:
5338 • Compresses the image using a simple algorithm to handle image details oriented in a specific
5340 • Supports Compression Modes PD, DGD, FNR, and OUT as defined below.
I.1.2.1 Standard Mode 0: PD (Pixel-based Directional Differential Mode)

5341 Figure 260 defines the packet structure for Compression Mode PD. For this Compression Mode, Header
5342 field Prediction IDX shall contain 0, and the high bit of Header field Mode IDX shall contain 0.
5343 The Payload shall contain compressed data for four pixels:
5344 • Field Qstep shall indicate the quantization step size.
5345 • Fields Diff0 through Diff3 shall contain the encoded data, i.e., for each pixel, the difference
5346 between the predicted pixel and each original pixel.
5347 Table 73 shows pseudo-code for decoding an MPC Packet for Compression Mode PD.
5348
Figure 260 MPC Packet Structure for Compression Mode PD

Confidential
23-May-2022
5349 Note:
5350 This pseudo-code assumes that the Green pixel appears first in the image. If the first pixel in the
5351 image is Red or Blue then the processing sequence must be changed, but compression is performed
5352 in the same way for each color.
5353 Table 73 Decoder for Compression Mode PD

1: // Quantization step
2: shift0 = (Qstep==0) ? 0 : (Qstep==1) ? 1 : (Qstep==2) ? 2 : 3
3: // For decoding the pixel p(h,v)
4: if (Line count < 2) // Vertical line counter, Boundary condition
5: q(h,v) = p(h-2,v)
6: else if (unit count == 0) // unit count is for processing unit block, boundary condition
7: q(h,v) = p(h,v-2)
8: else //Prediction value q of the preview pixel
9: if p(h-2,v-2) >= max{p(h,v-2), p(h-2,v)}
10: q(h,v) = min{p(h,v-2), p(h-2,v)}
11: else if p(h-2,v-2) <= min{p(h,v-2), p(h-2,v)}
12: q(h,v) = max{p(h,v-2), p(h-2,v)}
13: else
14: q(h,v) = p(h-2,v) + p(h,v-2) - p(h-2,v-2)
15: end if
16: end if
17: p(h,v) = ((q(h,v) >> shift0 + Diff0) << shift0) + (1 << (shift0 -1))
18: // For decoding the pixel p(h+1,v)
20: q(h+1,v) = p(h-1,v)
22: q(h+1,v) = p(h+1,v-2)
24: if p(h-1,v-2) >= max{p(h+1,v-2), p(h-1,v)}
25: q(h+1,v) = min{p(h+1,v-2), p(h-1,v)}
26: else if p(h-1,v-2) <= min{p(h+1,v-2), p(h-1,v)}
27: q(h+1,v) = max{p(h+1,v-2), p(h-1,v)}
28: else
29: q(h+1,v) = p(h-1,v) + p(h+1,v-2) - p(h-1,v-2)
30: end if
31: end if
32: p(h+1,v) = ((q(h+1,v) >> shift0 + Diff1) << shift0) + (1 << (shift0 -1))
35: q(h+2,v) = p(h,v)
37: q(h+2,v) = p(h+2,v-2)
38: else

Confidential
23-May-2022
39: if p(h,v-2) >= max{p(h+2,v-2), p(h,v)} //Prediction value q of the preview pixel
40: q(h+2,v) = min {p(h+2,v-2), p(h,v)}
41: else if p(h,v-2) <= min{p(h+2,v-2), p(h,v)}
42: q(h+2,v) = max{p(h+2,v-2), p(h,v)}
43: else
44: q(h+2,v) = p(h,v) + p(h+2,v-2) - p(h,v-2)
45: end if
46: end if
50: q(h+3,v) = p(h+1,v)
52: q(h+3,v) = p(h+3,v-2)
53: else
54: if p(h+1,v-2) < min{p(h+3,v-2), p(h+1,v)} //Prediction value q of the preview pixel
55: q(h+3,v) = max{p(h+3,v-2), p(h+1,v)}
56: else if p(h+1,v-2) > max{p(h+3,v-2), p(h+1,v)}
57: q(h+3,v) = min{p(h+3,v-2), p(h+1,v)}
58: else
59: q(h+3,v) = p(h+3,v-2) + p(h+1,v) - p(h+1,v-2)
60: end if
61: end if

Confidential
23-May-2022
I.1.2.2 Standard Mode 1: DGD (DiaGonal Direction-based Differential Mode)

5354 Compression Mode DGD references pixels that are located along diagonal directions. It gets the diagonal
5355 direction information using only Green pixels.
5356 Figure 261 defines the packet structure for Compression Mode DGD (Bayer). For this Compression Mode,
5357 Header field Prediction IDX shall contain 0, and the high two bits of Header field Mode IDX shall contain
5358 2’b10.
5361 • Fields Diff0 through Diff3 shall contain the encoded data, i.e., for each pixel, the difference
5362 between the predicted pixel and each original pixel.
5363 Table 74 shows pseudo-code for decoding an MPC Packet for Compression Mode DGD (Bayer).
5364
Figure 261 MPC Packet Structure for Compression Mode DGD (Bayer)

Confidential
23-May-2022
5365 Note:
5366 This pseudo-code assumes that the Green pixel appears first. If the first pixel is Red or Blue then the
5367 processing sequence must be changed, but compression is performed in the same way for each
5368 color. The Red- or Blue-first case is described in comments.
5369 Table 74 Decoder for Compression Mode DGD (Bayer)
2: shift0 = (Qstep==0) ? 0 : 1
3: // direction for p(h,v)
4: ldiff0 = abs(p(h-2,v-2) - p(h-1,v-1)) // color pixel first: ldiff0 = abs(p(h-1,v-2) - p(h,v-1))
5: ldiff1 = abs(p(h,v-2) - p(h+1,v-1)) // color pixel first: ldiff1 = abs(p(h+1,v-2) - p(h+2,v-1))
6: ldiff2 = abs(p(h+2,v-2) - p(h+3,v-1)) // color pixel first: ldiff2 = abs(p(h+3,v-2) - p(h+4,v-1))
7: rdiff0 = abs(p(h,v-2) - p(h-1,v-1)) // color pixel first: rdiff0 = abs(p(h-1,v-2) - p(h-2,v-1))
8: rdiff1 = abs(p(h+2,v-2) - p(h+1,v-1)) // color pixel first: rdiff1 = abs(p(h+1,v-2) - p(h,v-1))
9: rdiff2 = abs(p(h+4,v-2) - p(h+3,v-1)) // color pixel first: rdiff2 = abs(p(h+3,v-2) - p(h+2,v-1))
10: diff0 = rdiff0 + rdiff1
11: diff1 = ldiff0 + ldiff1
12: diff2 = abs(diff0 - diff1)
13: rup_diff = (diff2 <= 10) ? (diff0 + rdiff2) : diff0
14: lup_diff = (diff2 <= 10) ? (diff1 + ldiff2) : diff1
15: q(h,v) = (rup_diff < lup_diff) ? p(h+1,v-1) : p(h-1,v-1) // Prediction pixel
16: q(h+1,v) = (rup_diff < lup_diff) ? p(h+3,v-2) : p(h-1,v-2) // Prediction pixel
17: // color pixel first: q(h,v) = (rup_diff < lup_diff) ? p(h+2,v-2) : p(h-2,v-2)
18: // color pixel first: q(h+1,v) = (rup_diff < lup_diff) ? p(h+2,v-1) : p(h,v-1)
19: // direction for p(h+1,v)
20: ldiff0 = abs(p(h,v-2) - p(h+1,v-1)) // color pixel first: ldiff0 = abs(p(h-1,v-2) - p(h,v-1))
25: rdiff2 = abs(p(h,v-2) - p(h-1,v-1)) // color pixel first: rdiff2 = abs(p(h+1,v-2) - p(h,v-1))
31: q(h+2,v) = (rup_diff < lup_diff) ? p(h+3,v-1) : p(h+1,v-1) // Prediction pixel
34: // color pixel first: q(h+3,v) = (rup_diff < lup_diff) ? p(h+4,v-1) : p(h+2,v-1)
35: // For decoding the pixel p(h+i,v), i={0,1,2,3}

Confidential
23-May-2022
I.1.2.3 Standard Mode 2: FNR (Fixed Quantization and No-Reference Mode)

5370 If the difference between the current pixel and the reference pixel is large, then the pixel should be
5371 compressed by fixed quantization. In Compression Mode FNR, the data is compressed using just
5372 quantization; no difference operation is involved.
5373 Figure 262 defines the packet structure for Compression Mode FNR (Bayer). For this Compression Mode,
5374 Header field Prediction IDX shall contain 0, and Header field Mode IDX shall contain 3’b110.
5376 • Fields Pixel0 through Pixel3 shall contain the quantization result for each pixel.
5377 Table 75 shows pseudo-code for decoding an MPC Packet for Compression Mode FNR (Bayer).
5378
Figure 262 MPC Packet Structure for Compression Mode FNR (Bayer)
5379 Note:
5380 In this pseudo-code, any color pixel can appear first.
5381 Table 75 Decoder for Compression Mode FNR (Bayer)

2: shift0 = 6
4: p(h,v) = (Pixel0<< shift0) + (1 << (shift0 -1))
5: p(h+1,v) = (Pixel1<< shift0) + (1 << (shift0 -1))

Confidential
23-May-2022
I.1.2.4 Standard Mode 3: OUT (OUTlier compensation Mode)

5382 Compression Mode OUT performs compression when there is one outlier pixel in the current pixel p(h+i, v).
5383 It can only handle a maximum of one outlier pixel out of the four consecutive pixels. The OUT packet informs
5384 the MPC Decoder which pixel (out of the four) is the outlier pixel.
5385 Decoded pixels are usually used as reference pixels. However, the decoded pixels and reference pixels are
5386 different from each other for the outlier pixels in OUT mode (see Figure 263). Meanwhile, for the other three
5387 pixels, decoded pixels are the same as reference pixels. The MPC Decoder replaces the outlier pixel with the
5388 average of the candidates for prediction pixel (i.e., k0) which is added to the threshold value to get the decoded
5389 pixel. The decoded pixel is expressed as p(h+i, v), and the reference pixel is expressed as pq(h+i, v).
5390 • k0 shall contain the average of the candidates for prediction pixel which are not outlier pixels. It
5391 shall be a reference pixel of the outlier pixel, and enables the MPC Decoder to ignore the outlier
5392 pixels when the prediction pixels are received.
5393 p0, p1, p2, and p3 in Figure 263 correspond to p(h,v), p(h+1,v), p(h+2,v), and p(h+3,v) (i.e., the
5394 “Pixels to be Encoded”) in the “Green Pixel First” or “Blue Pixel First” portion of Figure 259.
5395 If p0 or p2 is the outlier pixel in Figure 263, then:
5396 k0 shall be the average of p(h−2,v−2), p(h,v−2), p(h+2,v−2), and p(h+4,v−2)
5397 Otherwise, if p1 or p3 is the outlier pixel, then:
5398 k0 shall be the average of p(h−1,v−2), p(h+1,v−2), p(h+3,v−2), and p(h+5,v−2)
k0 Threshold
value
Replace
p0 p1 p2 p3 p0 pq0 Decoded
pixel value
Outlier Reference
pixel pixel value
5399
Figure 263 Decoded and Reference Pixel of Outlier Pixel (Bayer)
5400 Figure 264 defines the packet structure for Compression Mode OUT (Bayer). For this Compression Mode,
5401 Header field Prediction IDX shall contain 0, and Header field Mode IDX shall contain 3’b111.
5402 The Payload shall contain:
5403 • The location of the outlier pixel in field Pos.
5404 • The quantization step size in field Qstep.
5405 • Encoded data for the three good pixels in fields Diff1 through Diff3 (i.e., for each good pixel, the
5406 difference between the predicted pixel and the original pixel).
5407 Table 76 shows pseudo-code for decoding an MPC Packet for Compression Mode OUT (Bayer).
5408
Figure 264 MPC Packet Structure for Compression Mode OUT (Bayer)

Confidential
23-May-2022
5409 Note:
5412 color.
5413 Table 76 Decoder for Compression Mode OUT (Bayer)
3: // Prediction value
4: if (Pos == 0)
5: q0 = p(h+1,v-2) // color pixel first: q0 = (p(h,v-1) + p(h+2,v-1)) >> 1
6: q1= (p(h+1,v-1) + p(h+3,v-1)) >> 1 // color pixel first: q1 = p(h+2,v-2)
7: q2= p(h+3,v-2) // color pixel first: q2 = (p(h+4,v-1) + p(h+2,v-1)) >> 1
8: else if (Pos == 1)
9: q0 = (p(h-1,v-1) + p(h+1,v-1)) >> 1 // color pixel first: q0 = p(h,v-2)
12: else if (Pos == 2)
14: q1= p(h+1,v-2) // color pixel first: q1 = (p(h,v-1) + p(h+2,v-1)) >> 1
16: else
18: q1= p(h+1,v-2) // color pixel first: q1 = (p(h,v-1) + p(h+2,v-1)) >> 1
20: end if
21: k0= (p(h-2,v-2) + p(h,v-2) + p(h+2,v-2) + p(h+4,v-2) )>>2
22: // color pixel first: k0= (p(h-1,v-2) + p(h+1,v-2) + p(h+3,v-2) + p(h+5,v-2) )>>2
23: k1 = ((q0>> shift0 + Diff1) << shift0) + (1 << (shift0 -1))
26: k`0= (k0 + outlier_thresh) > 1023 ? 1023 : (k0 + outlier_thresh)
27: // outlier_thresh is user control parameter to detect outlier pixel with threshold value
28: // According to outlier pixel position Pos, decoded data mapping
29: // pq (h+i,v) is not output data but prediction pixel for using as reference pixel
30: pq (h,v) = (Pos == 0) ? k0 : k1
31: pq (h+1,v) = (Pos == 1) ? k0 : (Pos <1) ? k1 : k2
32: pq (h+2,v) = (Pos == 2) ? k0 : (Pos <2) ? k2 : k3
33: pq (h+3,v) = (Pos == 3) ? k0 : k3
34: // p(h+i,v) is output data, p and pq are different (basically these are same in other mode)
35: p (h,v) = (Pos == 0) ? k`0 : k1
36: p (h+1,v) = (Pos == 1) ? k`0 : (Pos <1) ? k1 : k2
37: p (h+2,v) = (Pos == 2) ? k`0 : (Pos <2) ? k2 : k3
38: p (h+3,v) = (Pos == 3) ? k`0 : k3

Confidential
23-May-2022
I.1.3 Advanced Prediction Mode (Bayer)

5414 For Bayer image sensors, Advanced Prediction Mode:
5415 • Compresses the image using more extensive direction-aware algorithms to minimize image quality
5416 loss.
5417 • Supports Compression Modes ePD, eDGD, and eSHV as defined below.
I.1.3.1 Extended Mode 0: eDGD (extended DiaGonal Direction-based differential mode)

5418 Compression Mode eDGD extends Compression Mode DGD by adding more quantization levels.
5419 Figure 265 defines the packet structure for Compression Mode eDGD. For this Compression Mode, Header
5423 • Fields Diff0 through Diff3 shall contain the encoded data (i.e., for each pixel, the difference
5424 between the predicted pixel and each original pixel).
5426
Figure 265 MPC Packet Structure for Compression Mode eDGD

Confidential
23-May-2022
5427 Note:
Table 77 Decoder for Compression Mode eDGD
3: // direction for p(h,v)
4: ldiff0 = abs(p(h-2,v-2) - p(h-1,v-1)) // color pixel first: ldiff0 = abs(p(h-1,v-2) - p(h,v-1))
5: ldiff1 = abs(p(h,v-2) - p(h+1,v-1)) // color pixel first: ldiff1 = abs(p(h+1,v-2) - p(h+2,v-1))
7: rdiff0 = abs(p(h,v-2) - p(h-1,v-1)) // color pixel first: rdiff0 = abs(p(h-1,v-2) - p(h-2,v-1))
8: rdiff1 = abs(p(h+2,v-2) - p(h+1,v-1)) // color pixel first: rdiff1 = abs(p(h+1,v-2) - p(h,v-1))
15: q(h,v) = (rup_diff < lup_diff) ? p(h+1,v-1) : p(h-1,v-1) // Prediction pixel
16: q(h+1,v) = (rup_diff < lup_diff) ? p(h+3,v-2) : p(h-1,v-2) // Prediction pixel
17: // color pixel first: q(h,v) = (rup_diff < lup_diff) ? p(h+2,v-2) : p(h-2,v-2)
19: // direction for p(h+1,v)
20: ldiff0 = abs(p(h,v-2) - p(h+1,v-1)) // color pixel first: ldiff0 = abs(p(h-1,v-2) - p(h,v-1))
25: rdiff2 = abs(p(h,v-2) - p(h-1,v-1)) // color pixel first: rdiff2 = abs(p(h+1,v-2) - p(h,v-1))
34: // color pixel first: q(h+3,v) = (rup_diff < lup_diff) ? p(h+4,v-1) : p(h+2,v-1)

Confidential
23-May-2022
I.1.3.2 Extended Mode 1: ePD (extended Pixel-based Directional Differential Mode)

5431 Compression Mode ePD extends Compression Mode PD by adding more quantization levels.
5432 Figure 266 defines the packet structure for Compression Mode ePD. For this Compression Mode, Header
5433 field Prediction IDX shall contain 1, and the two high bits of Header field Mode IDX shall contain 2’b10.
5438 Table 78 shows pseudo-code for decoding an MPC Packet for Compression Mode ePD.
5439
Figure 266 MPC Packet Structure for Compression Mode ePD

Confidential
23-May-2022
5440 Note:
5443 color.
5444 Table 78 Decoder for Compression Mode ePD

2: shift0 = (Qstep==0) ? 4 : 5
3: // For decoding the pixel p(h,v)
5: q(h,v) = p(h-2,v)
7: q(h,v) = p(h,v-2)
9: if p(h-2,v-2) >= max{p(h,v-2), p(h-2,v)}
10: q(h,v) = min{p(h,v-2), p(h-2,v)}
11: else if p(h-2,v-2) <= min{p(h,v-2), p(h-2,v)}
12: q(h,v) = max{p(h,v-2), p(h-2,v)}
13: else
14: q(h,v) = p(h-2,v) + p(h,v-2) - p(h-2,v-2)
15: end if
16: end if
20: q(h+1,v) = p(h-1,v)
22: q(h+1,v) = p(h+1,v-2)
24: if p(h-1,v-2) >= max{p(h+1,v-2), p(h-1,v)}
25: q(h+1,v) = min{p(h+1,v-2), p(h-1,v)}
26: else if p(h-1,v-2) <= min{p(h+1,v-2), p(h-1,v)}
27: q(h+1,v) = max{p(h+1,v-2), p(h-1,v)}
28: else
29: q(h+1,v) = p(h-1,v) + p(h+1,v-2) - p(h-1,v-2)
30: end if
31: end if
35: q(h+2,v) = p(h,v)
37: q(h+2,v) = p(h+2,v-2)
38: else

Confidential
23-May-2022
39: if p(h,v-2) >= max{p(h+2,v-2), p(h,v)} //Prediction value q of the preview pixel
40: q(h+2,v) = min {p(h+2,v-2), p(h,v)}
41: else if p(h,v-2) <= min{p(h+2,v-2), p(h,v)}
42: q(h+2,v) = max{p(h+2,v-2), p(h,v)}
43: else
44: q(h+2,v) = p(h,v) + p(h+2,v-2) - p(h,v-2)
45: end if
46: end if
50: q(h+3,v) = p(h+1,v)
52: q(h+3,v) = p(h+3,v-2)
53: else
54: if p(h+1,v-2) < min{p(h+3,v-2), p(h+1,v)} //Prediction value q of the preview pixel
55: q(h+3,v) = max{p(h+3,v-2), p(h+1,v)}
56: else if p(h+1,v-2) > max{p(h+3,v-2), p(h+1,v)}
57: q(h+3,v) = min{p(h+3,v-2), p(h+1,v)}
58: else
59: q(h+3,v) = p(h+3,v-2) + p(h+1,v) - p(h+1,v-2)
60: end if
61: end if

Confidential
23-May-2022
I.1.3.3 Extended Mode 2: eSHV (extended Slanted Horizontal or Vertical Direction-

based Differential Mode)
5445 Compression Mode eSHV references pixels that are located along the slanted horizontal or vertical direction.
5446 Figure 267 defines the packet structure for Compression Mode eSHV. For this Compression Mode, Header
5447 field Prediction IDX shall contain 1, and the high two bits of Header field Mode IDX shall contain 2’b11.
5452 Table 79 shows pseudo-code for decoding an MPC Packet for Compression Mode eSHV.
5453
Figure 267 MPC Packet Structure for Compression Mode eSHV (Bayer)

Confidential
23-May-2022
5454 Note:
5458 Table 79 Decoder for Compression Mode eSHV (Bayer)

2: shift0 = (Qstep==0) ? 2 : 3
3: // Prediction value q(h,v) from DGD mode for p(h+i,v), i={0,1}
4: if (q(h,v) == p(h-1,v-1)) // color pixel first: if (q(h+1,v) == p(h,v-1))
5: left_en(h,v) = 1; left_en(h+1,v) = 1
6: else
7: left_en(h,v) = 0; left_en(h+1,v) = 0
8: end if
9: offset(h,v) = left_en(h,v) ? 0 : (p(h,v-2) > p(h+1,v-1)) ? (p(h+1,v-1) – 40) : (p(h+1,v-1) + 40)
10: /* color pixel first: offset(h,v) = left_en(h,v) ? 0 :
11: (p(h+1,v-2) > p(h+2,v-1)) ? (p(h+2,v-2) – 40) : (p(h+2,v-2) + 40) */
12: offset(h+1,v) = left_en(h+1,v) ? 0 : (p(h,v-2) > p(h+1,v-1)) ? (p(h+3,v-2) – 40) : (p(h+3,v-2) + 40)
13: /* color pixel first: offset(h+1,v) = left_en(h+1,v) ? 0 :
14: (p(h+1,v-2) > p(h+2,v-1)) ? (p(h+2,v-1) – 40) : (p(h+2,v-1) + 40) */
15: offset(h,v) = (offset(h,v) > 1023) ? 0 : (offset(h,v) < 0) ? 0 : offset(h,v)
16: offset(h+1,v) = (offset(h+1,v) > 1023) ? 0 : (offset(h+1,v) < 0) ? 0 : offset(h+1,v)
17: // Prediction for high
18: qh(h,v) = left_en(h,v) ? (p(h-1,v-1) + p(h,v-2)) >> 1 : (p(h,v-2) + p(h+1,v-1)) >> 1
19: // color pixel first: qh(h,v) = left_en(h,v) ? (p(h-2,v-2) + p(h,v-2)) >> 1 : (p(h,v-2) + p(h+2,v-2)) >> 1
20: qh(h+1,v) = left_en(h,v) ? (p(h-1,v-1) + p(h+1,v-2)) >> 1 : (p(h+1,v-2) + p(h+3,v-2)) >> 1
21: /* color pixel first: qh(h+1,v) = left_en(h+1,v) ? (p(h,v-1) + p(h+1,v-2)) >> 1 :
22: (p(h+1,v-2) + p(h+2,v-1)) >> 1 */
23: // Prediction for low
24: ql(h,v) = left_en(h,v) ? (p(h-1,v-1) + p(h-2,v)) >> 1 : offset(h,v)
25: // color pixel first: ql(h,v) = left_en(h,v) ? (p(h-2,v-2) + p(h-2,v)) >> 1 : offset(h,v)
26: ql(h+1,v) = left_en(h,v) ? (p(h-1,v-2) + p(h-1,v)) >> 1 : offset(h+1,v)
27: // color pixel first: ql(h+1,v) = left_en(h,v) ? (p(h-1,v-2) + p(h-1,v)) >> 1 : offset(h+1,v)
28: // Recon
29: low0 = left_en(h,v) ? p(h-2,v) : offset(h,v)
30: // color pixel first: low0 = left_en(h,v) ? p(h-1,v) : offset(h+1,v)
31: cent0 = left_en(h,v) ? p(h-1,v-1) : p(h+1,v-1)
32: // color pixel first: cent0 = left_en(h,v) ? p(h,v-1) : offset(h+2,v-1)
33: high0 = p(h,v-2) // color pixel first: high0 = p(h+1,v-2)
34: ldiff0 = abs(cent0 - low0)
35: hdiff0 = abs(cent0 - high0)
36: q(h,v) = (ldiff0 < hdiff0) ? ql(h,v) : qh(h,v)
37: q(h+1,v) = (ldiff0 < hdiff0) ? ql(h+1,v) : qh(h+1,v)

Confidential
23-May-2022
40: // Prediction value q(h,v) from DGD mode for p(h+i,v), i={2,3}
41: if (q(h+2,v) == p(h+1,v-1)) // color pixel first: if (q(h+3,v) == p(h+2,v-1))
42: left_en(h+2,v) = 1; left_en(h+3,v) = 1
43: else
44: left_en(h+2,v) = 0; left_en(h+3,v) = 0
45: end if
46: offset(h+2,v) = left_en(h+2,v) ? 0 : (p(h+2,v-2) > p(h+3,v-1)) ? (p(h+3,v-1) – 40) : (p(h+3,v-1) + 40)
48: (p(h+3,v-2) > p(h+4,v-1)) ? (p(h+4,v-2) – 40) : (p(h+4,v-2) + 40) */
49: offset(h+3,v) = left_en(h+2,v) ? 0 : (p(h+2,v-2) > p(h+3,v-1)) ? (p(h+5,v-2) – 40) : (p(h+5,v-2) + 40)
51: (p(h+3,v-2) > p(h+4,v-1)) ? (p(h+4,v-1) – 40) : (p(h+4,v-1) + 40) */
54: // Prediction for high
55: qh(h+2,v) = left_en(h+2,v) ? (p(h+1,v-1) + p(h+2,v-2)) >> 1 : (p(h+2,v-2) + p(h+3,v-1)) >> 1
56: /* color pixel first: qh(h+2,v) = left_en(h+2,v) ? (p(h,v-2) + p(h+2,v-2)) >> 1 :
57: (p(h+2,v-2) + p(h+4,v -2)) >> 1 */
58: qh(h+3,v) = left_en(h+2,v) ? (p(h+1,v-2) + p(h+3,v-2)) >> 1 : (p(h+3,v-2) + p(h+5,v-2)) >> 1
59: /* color pixel first: qh(h+3,v) = left_en(h+3,v) ? (p(h+2,v-1) + p(h+3,v-2)) >> 1 :
60: : (p(h+3,v-2) + p(h+4,v-1)) >> 1 */
61: // Prediction for low
62: ql(h+2,v) = left_en(h+2,v) ? (p(h+1,v-1) + p(h,v)) >> 1 : offset(h+2,v)
63: // color pixel first: ql(h+2,v) = left_en(h+2,v) ? (p(h,v-2) + p(h,v)) >> 1 : offset(h+2,v)
64: ql(h+3,v) = left_en(h+2,v) ? (p(h+1,v-2) + p(h+1,v)) >> 1 : offset(h+3,v)
65: // color pixel first: ql(h+3,v) = left_en(h+3,v) ? (p(h+2,v-1) + p(h+1,v)) >> 1 : offset(h+3,v)
66: // Recon
67: low2 = left_en(h+2,v) ? p(h,v) : offset(h+2,v)
68: // color pixel first: low2 = left_en(h+2,v) ? p(h+1,v) : offset(h+3,v)
69: cent2 = left_en(h+2,v) ? p(h+1,v-1) : p(h+3,v-1)
70: // color pixel first: cent2 = left_en(h+2,v) ? p(h+2,v-1) : p(h+4,v-1)
71: high2 = p(h+2,v-2) // color pixel first: high2 = p(h+3,v-2)
72: ldiff2 = abs(cent2 - low2)
73: hdiff2 = abs(cent2 - high2)

Confidential
23-May-2022
I.2 MPC for Tetra-Cell Image Sensor

5459 MPC for Tetra-Cell image sensors supports the eight Compression Modes that are defined in this Section and
5460 summarized in Table 80. If MPC is supported, then all eight MPC decoder Data Compression Modes shall
5461 be supported. Each Compression Mode uses either Basic Prediction Mode or Advanced Prediction Mode.
5462 Figure 268 summarizes the MPC Packet Structures used for Tetra-Cell Compression Modes.
5463 Table 80 MPC Compression Modes for Tetra-Cell Image Sensors
Mode Description
Mode Name Section
AD Average-based Directional Differential Mode I.2.2.1
OD Oblique Direction-based Differential Mode I.2.2.1
OUT OUTlier Compensation Mode I.2.2.1
eMPD extended Multi-Pixel-based Directional Differential Mode I.2.3.1
extended Horizontal or Vertical Direction-based Differential
eHVD I.2.3.1
Mode
extended Horizontal or Vertical Average-based Differential
eHVA I.2.3.1
Mode
eOUT extended OUTlier Compensation Mode I.2.3.1
5464
Figure 268 MPC Packet Structures for Tetra-Cell Compression Modes

Confidential
23-May-2022
I.2.1 Reference Pixels for Prediction (Tetra-Cell)

5467 In a Tetra-Cell image, each cell consists of four Multi-Pixels in a 2x2 matrix.
5468 A given pixel is expressed as pk(i, j), where:
5469 • k: The Multi-Pixel index within the Tetra-Cell, i.e., 0, 1, 2, or 3 as shown in Figure 269:
5470 • p0 is the upper left Multi-Pixel
5471 • p1 is the upper right Multi-Pixel
5472 • p2 is the lower left Multi-Pixel
5473 • p3 is the lower right Multi-Pixel.
p0 p1
p2 p3
5474
Figure 269 Tetra-Cell Multi-Pixel Indexing
5475 • i: Horizontal index of the Tetra-Cell where the Multi-Pixel is located

5476 • j: Vertical index of the Tetra-Cell where the Multi-Pixel is located
5477 For a current Tetra-Cell p(h, v), the coordinates are relative to a reference Tetra-Cell and are expressed as:
5478 • The Horizontal relative index from the current Tetra-Cell to the reference Tetra-Cell,
5479 • Reference Tetra-Cells to the left of the current Tetra-Cell have negative h indexes
5480 • Reference Tetra-Cells directly above or below the current Tetra-Cell have zero h indexes
5481 • Reference Tetra-Cells to the right of the current Tetra-Cell have positive h indexes.
5482 and
5483 • The Vertical relative index from the current Tetra-Cell to the reference Tetra-Cell
5484 • Reference Tetra-Cells located above the current Tetra-Cell have negative v indexes
5485 • Reference Tetra-Cells in the same image line as the current cell have zero v indexes.
5486 Examples:
5487 p(h, v–1) Tetra-Cell immediately above the current Tetra-Cell
5488 p(h–1, v) Tetra-Cell immediately to the left of the current Tetra-Cell
5489 p(h+1, v−1) Tetra-Cell immediately above and immediately to the right of the current Tetra-Cell
5490 p(h–1, v–1) Tetra-Cell immediately above and immediately to the left of the current Tetra-Cell

Confidential
23-May-2022
Green Pixel First
Blue Pixel First
5494 Not Shown: Red Pixel First
Figure 270 Reference Pixel Relative Coordinate Indexes (Tetra-Cell)
5495 For a Tetra-Cell image sensor, the eight highlighted pixels in the bottom two rows will be encoded. This
5496 corresponds to Tetra-Cell coordinates p(h, v) (i.e., the current Tetra-Cell) and p(h+1, v). The other colored

Confidential
23-May-2022

5498 At the boundary of the image frame, no neighboring reference pixels exist. As a result, difference calculations
5504 in low-light conditions or the value128 for normal conditions.

Confidential
23-May-2022
I.2.2 Basic Prediction Mode (Tetra-Cell)

5505 For Tetra-Cell image sensors, Basic Prediction Mode:
5508 • Supports Compression Modes AD, OD, FNR, and OUT as defined below.
I.2.2.1 Standard Mode 0: AD (Average-based Directional Differential Mode)

5509 Compression Mode AD is efficient for compressing pixels located on horizontal and vertical edges. An AD
5510 packet transmits one prediction pixel and three reference pixels. The prediction pixel is either the combination
5511 of the three reference pixels, or the reference pixel itself.
5512 Figure 271 defines the packet structure for Compression Mode AD. For this Compression Mode, Header
5514 The Payload shall contain compressed data for the four pixels of a Tetra-Cell:
5516 • Field ByrDiff shall contain the quantized difference between a prediction and the average of the
5517 four pixels.
5518 Field ByrDiff is used both for decoding fields MltDiff0 through MltDiff3, and for
5519 generating the Bayer image (see Section I.3.4).
5520 • Fields MltDiff0 through MltDiff3 shall contain the encoded data, i.e., for each pixel, the encoded
5521 data between the averaged pixel and each Multi-Pixel.
5522 Table 81 shows pseudo-code for decoding an MPC Packet for Compression Mode AD.
5523
Figure 271 MPC Packet Structure for Compression Mode AD

Confidential
23-May-2022
5524 Note:
5527 color.
5528 Note also that this pseudo-code only describes 2x2 pixels pk (h, v) to be compressed. These should
5529 be Green or Red/Blue pixels.
5530 Table 81 Decoder for Compression Mode AD

4: // For decoding the pixel pi(h,v), i={0,1,2,3}
6: q = p1 (h-2,v)
8: q = p2 (h,v-2)
10: if p3(h-2,v-2) >= max{p2(h,v-2), p1(h-2,v)}
11: q = min{p2(h,v-2), p1(h-2,v)}
12: else if p3(h-2,v-2) <= min{p2(h,v-2), p1(h-2,v)}
13: q = max{p2(h,v-2), p1(h-2,v)}
14: else
15: q = p2(h,v-2) + p1(h-2,v) - p3(h-2,v-2)
16: end if
17: end if
18: pbyr(h,v) = q >>shift0 + ByrDiff // Bayer pixel pbyr
19: p0(h,v) = ((pbyr>>shift1 + MltDiff0) << shift1) + (1 << (shift1-1))
20: p1(h,v) = ((pbyr>> shift1 + MltDiff1) << shift1) + (1 << (shift1-1))

Confidential
23-May-2022
I.2.2.2 Standard Mode 1: OD (Oblique Direction-based Differential Mode)

5531 Compression Mode OD references pixels that are located along oblique directions.
5532 Figure 272 defines the packet structure for Compression Mode OD. For this Compression Mode, Header
5535 • 1-bit field Dir shall indicate the reference direction:
5536 If Dir contains 0 then the reference direction is the Slash Direction, i.e., rising to the right
5537 like a slash character: /
5538 If Dir contains 1 then the reference direction is the Backslash Direction, i.e., rising to the
5539 left like a backslash character: \
5541 • Fields ByrDiff and MltDiff0 through MltDiff3 shall contain the encoded data, i.e., for each pixel, the
5542 difference between the predicted pixel and each original pixel.
5543 Field ByrDiff can also be regarded as MltDiff0; it is used for generation of the Bayer
5544 image, see Section I.3.4.
5545 Table 82 shows pseudo-code for decoding an MPC Packet for Compression Mode OD.
5546
Figure 272 MPC Packet Structure for Compression Mode OD

Confidential
23-May-2022
5547 Note:
5551 Note also that this pseudo-code describes each case of 2x2 Green pk (h, v) and 2x2 Red/Blue
5552 pk (h+1, v) pixels.
Table 82 Decoder for Compression Mode OD

1: /****************** For decoding the first 2x2 pixel pk(h,v), k={0,1,2,3}********************/
3: shift0 = (Qstep == 0) ? 2 : (Qstep == 1) ? 3 : (Qstep == 2) ? 4 : 5
4: // Extracting prediction mode
5: th = 50
6: if Dir == 1 // Back-slash direction
7: if abs(abs(p2(h-1,v-1) - p3(h-1,v-1)) - abs(p1(h-1,v-1) - p3(h-1,v-1))) >= th
8: // color pixel first: abs(abs(p2(h-2,v-2) - p3(h-2,v-2)) - abs(p1(h-2,v-2) - p3(h-2,v-2))) >= th
9: if abs(p2(h-1,v-1) - p3(h-1,v-1)) >= (abs(p1(h-1,v-1) - p3(h-1,v-1))*2)
10: // color pixel first: abs(p2(h-2,v-2) - p3(h-2,v-2)) >= (abs(p1(h-2,v-2) - p3(h-2,v-2))*2)
11: mode = 3
12: else if abs(p1(h-1,v-1) - p3(h-1,v-1)) >= (abs(p2(h-1,v-1) - p3(h-1,v-1))*2)
13: // color pixel first: abs(p1(h-2,v-2) - p3(h-2,v-2)) >= (abs(p2(h-2,v-2) - p3(h-2,v-2))*2)
14: mode = 4
15: else if abs(p2(h-1,v-1) - p3(h-1,v-1)) >= abs(p1(h-1,v-1) - p3(h-1,v-1))
16: // color pixel first: abs(p2(h-2,v-2) - p3(h-2,v-2)) >= abs(p1(h-2,v-2) - p3(h-2,v-2))
17: mode = 1
18: else
19: mode = 2
20: end if
21: else
22: mode = 0
23: end if
24: else // Slash direction
25: if abs(abs(p2(h+1,v-1) - p3(h+1,v-1)) - abs(p0(h+1,v-1) - p2(h+1,v-1))) >= th
26: // color pixel first: abs(abs(p2(h+2,v-2) - p3(h+2,v-2)) - abs(p0(h+2,v-2) - p2(h+2,v-2))) >= th
27: if abs(p2(h+1,v-1) - p3(h+1,v-1)) >= (abs(p0(h+1,v-1) - p2(h+1,v-1))*2)
28: // color pixel first: abs(p2(h+2,v-2) - p3(h+2,v-2)) >= (abs(p0(h+2,v-2) - p2(h+2,v-2))*2)
29: mode = 8
30: else if abs(p0(h+1,v-1) - p2(h+1,v-1)) >= (abs(p2(h+1,v-1) - p3(h+1,v-1))*2)
32: mode = 9
33: else if abs(p2(h+1,v-1) - p3(h+1,v-1)) >= abs(p0(h+1,v-1) - p2(h+1,v-1))
34: // color pixel first: abs(p2(h+2,v-2) - p3(h+2,v-2)) >= abs(p0(h+2,v-2) - p2(h+2,v-2))
35: mode = 6
36: else

Confidential
23-May-2022
37: mode = 7
38: end if
39: else
40: mode = 5
41: end if
42: end if
43: // Decoding process
44: if mode == 0
45: q0 = p3(h-1, v-1) // color pixel first: q0 = p3(h-2, v-2)
48: p0(h,v) = ((q0>>shift0 + ByrDiff) << shift0) + (1 << (shift0-1))
49: p1(h,v) = ((q1>>shift0 + MltDiff1) << shift0) + (1 << (shift0-1))
51: p3(h,v) = ((p0(h,v)>>shift0 + MltDiff3) << shift0) + (1 << (shift0-1))
52: else if mode == 1
55: q2 = (p2(h-1, v-1) +p3(h-1, v-1)) >> 1 // color pixel first: q2 = (p2(h-2, v-2) +p3(h-2, v-2)) >> 1
62: q1 = (p1(h-1, v-1) +p3(h-1, v-1)) >> 1 // color pixel first: q1 = (p1(h-2, v-2) +p3(h-2, v-2)) >> 1
70: q1 = (p2(h, v-2) +p1(h-1, v-1)) >> 1 // color pixel first: q1 = p1(h-2, v-2)

Confidential
23-May-2022

85: q0 = p0(h+1, v-1) // color pixel first: q0 = p0(h+2, v-2)
95: q3 = (p2(h+1, v-1) + p3(h+1, v-1)) >> 1 // color pixel first: q3 = (p2(h+2, v-2) + p3(h+2, v-2)) >> 1
109: q0 = (p3(h, v-2) + p0(h+1, v-1)) >> 1 // color pixel first: q0 = p0(h+2, v-2)

Confidential
23-May-2022

124: end if
125: /***************** For decoding the second 2x2 pixel pk(h+1,v), k={0,1,2,3}****************/
128: // Extracting prediction mode
129: th = 50
130: if Dir == 1 // Back-slash direction
131: if abs(abs(p2(h-1,v-2) - p3(h-1,v-2)) - abs(p1(h-1,v-2) - p3(h-1,v-2))) >= th
132: // color pixel first: abs(abs(p2(h,v-1) - p3(h,v-1)) - abs(p1(h,v-1) - p3(h,v-1))) >= th
133: if abs(p2(h-1,v-2) - p3(h-1,v-2)) >= (abs(p1(h-1,v-2) - p3(h-1,v-2))*2)
134: // color pixel first: abs(p2(h,v-1) - p3(h,v-1)) >= (abs(p1(h,v-1) - p3(h,v-1))*2)
135: mode = 3
136: else if abs(p1(h-1,v-2) - p3(h-1,v-2)) >= (abs(p2(h-1,v-2) - p3(h-1,v-2))*2)
137: // color pixel first: abs(p1(h,v-1) - p3(h,v-1)) >= (abs(p2(h,v-1) - p3(h,v-1))*2)
138: mode = 4
139: else if abs(p2(h-1,v-2) - p3(h-1,v-2)) >= abs(p1(h-1,v-2) - p3(h-1,v-2))
140: // color pixel first: abs(p2(h,v-1) - p3(h,v-1)) >= abs(p1(h,v-1) - p3(h,v-1))
141: mode = 1
142: else
143: mode = 2
144: end if
145: else
146: mode = 0
147: end if
148: else // Slash direction
149: if abs(abs(p2(h+3,v-2) - p3(h+3,v-2)) - abs(p0(h+3,v-2) - p2(h+3v-2))) >= th
150: // color pixel first: abs(abs(p2(h+2,v-1) - p3(h+2,v-1)) - abs(p0(h+2,v-1) - p2(h+2,v-1))) >= th
151: if abs(p2(h+3,v-2) - p3(h+3,v-2)) >= (abs(p0(h+3,v-2) - p2(h+3,v-2))*2)
153: mode = 8
154: else if abs(p0(h+3,v-2) - p2(h+3,v-2)) >= (abs(p2(h+3,v-2) - p3(h+3,v-2))*2)
156: mode = 9
157: else if abs(p2(h+3,v-2) - p3(h+3,v-2)) >= abs(p0(h+3,v-2) - p2(h+3,v-2))
158: // color pixel first: abs(p2(h+2,v-1) - p3(h+2,v-1)) >= abs(p0(h+2,v-1) - p2(h+2,v-1))
159: mode = 6
160: else
161: mode = 7
162: end if
163: else
164: mode = 5
165: end if

Confidential
23-May-2022
166: end if
167: // Decoding process
168: if mode == 0
169: q0 = p3(h-1, v-2) // color pixel first: q0 = p3(h, v-1)
172: p0(h+1,v) = ((q0>>shift0 + ByrDiff) << shift0) + (1 << (shift0-1))
173: p1(h+1,v) = ((q1>>shift0 + MltDiff1) << shift0) + (1 << (shift0-1))
175: p3(h+1,v) = ((p0(h+1,v)>>shift0 + MltDiff3) << shift0) + (1 << (shift0-1))
179: q2 = (p2(h-1, v-2) + p3(h-1, v-2)) >> 1 // color pixel first: q2 = (p2(h, v-1) +p3(h, v-1)) >> 1
186: q1 = (p1(h-1, v-2) +p3(h-1, v-2)) >> 1 // color pixel first: q1 = (p1(h, v-1) +p3(h, v-1)) >> 1
191: p3(h+1,v) = ((p0(h+1,v)>> shift0 + MltDiff2) << shift0) + (1 << (shift0-1))
194: q1 = p1(h-1, v-2) // color pixel first: q1 = (p1(h, v-1) + p2(h+1, v-2)) >> 1

Confidential
23-May-2022

233: q0 = p0(h+3, v-2) // color pixel first: q0 = (p3(h+1, v-2) + p0(h+2, v-1)) >> 1
248: end if
249: // p1(h,v),…, p3(h,v) should be p1(h,v),…, p3(h,v) = p0(h,v), when you want to get the pbyr(h,v)
250: pbyr(h,v)= p0(h,v) // Bayer green pixel pbyr(h,v)
251: pbyr(h+1,v)= p0(h+1,v) // Bayer red/blue pixel pbyr(h+1,v)

Confidential
23-May-2022

5553 If the difference between the current pixel and the reference pixel is large, then the pixel should be
5554 compressed by fixed quantization. In Compression Mode FNR, the data is compressed using only
5555 quantization, with no difference operation.
5556 Figure 272 defines the packet structure for Compression Mode FNR (Tetra-Cell). For this Compression
5557 Mode, Header field Prediction IDX shall contain 0, and Header field Mode IDX shall contain 3’b110.
5560 • Fields MltPixel1 through MltPixel3 shall contain the quantization results for each Multi-Pixel.
5562 image, for more information, see Section I.3.4.
5564
Figure 273 MPC Packet Structure for Compression Mode FNR (Tetra-Cell)
5565 Note:
Table 83 Decoder for Compression Mode FNR (Tetra-Cell)

2: shift0 = 6
3: // For decoding the pixel pk , k={0,1,2,3}
4: p0(h,v) = (ByrPixel << shift0) + (1 << (shift0 -1))
5: p1(h,v) = (MltPixel1 << shift0) + (1 << (shift0 -1))
9: pbyr(h,v) = p0(h,v) // Bayer pixel pbyr(h,v)

Confidential
23-May-2022
I.2.2.4 Standard Mode 3: OUT (OUTlier compensation Mode)

5569 Compression Mode OUT performs compression when there is one outlier pixel in current pixel pk (h+i, v).
5570 It can only handle a maximum of one outlier pixel out of the four Multi-Pixels clustered within the same
5571 color filter. The OUT packet informs the MPC Decoder which pixel (out of the four) is the outlier pixel.
5572 Decoded pixels are usually used as reference pixels. However, the decoded pixels and reference pixels are
5573 different from each other for the outlier pixels in OUT mode (see Figure 274). Meanwhile, for the other three
5574 pixels, decoded pixels are the same as reference pixels. The MPC Decoder replaces the outlier pixel with the
5575 average of the candidates for prediction pixel (i.e., k0) which is added to the threshold value to get the decoded
5576 pixel. The decoded pixel is expressed as Tetra-cell p(h, v), and the reference pixel is expressed as Tetra-cell
5577 pq(h, v).
5578 • k0 shall contain average of the candidates for prediction pixel which are not outlier pixels. It shall
5579 be a reference pixel of the outlier pixel and enables the MPC Decoder to ignore the outlier pixels
5580 when the prediction pixels are received.
5581 If p0(h,v) through p3(h,v) in Figure 270 are green or blue, and one of them is the outlier pixel,
5582 then:
5583 k0 shall be the average of p (h−2,v−2), p (h,v−2) , p (h,v−2) , and p (h+2,v−2)
3 2 3 2
5584 If p0(h+1,v) through p3(h+1,v) in Figure 270 are red or green, and one of them is the outlier
5585 pixel, then:
5586 k0 shall be the average of p (h−1,v−2), p (h+1,v−2), p (h+1,v−2), and p (h+3,v−2)
3 2 3 2
Outlier k0 Threshold
pixel value
Replace
p0 p1 p0 pq0 Decoded
pixel value
p2 p3 Reference
pixel value
5587
Figure 274 Decoded and Reference Pixel of Outlier Pixel (Tetra)
5588 Figure 275 defines the packet structure for Compression Mode OUT (Tetra-Cell). For this Compression
5591 • The location of the outlier pixel in field Pos
5592 • The quantization step size in field Qstep
5593 • Encoded data for the three good pixels in fields MltDiff1 through MltDiff3 (i.e., for each good
5594 pixel, the difference between the predicted pixel and the original pixel).
5595 For Compression Mode OUT, the Bayer image is generated by averaging neighboring
5596 pixels.
5597 Table 84 shows pseudo-code for decoding an MPC Packet for Compression Mode OUT (Tetra-Cell).
5598
Figure 275 MPC Packet Structure for Compression Mode OUT (Tetra-Cell)

Confidential
23-May-2022
5599 Note:
5602 color.
Table 84 Decoder for Compression Mode OUT (Tetra-Cell)

3: // For decoding pk(h,v), k={0,1,2,3}
5: q = p1 (h-2,v)
7: q = p2 (h,v-2)
9: if p3(h-2,v-2) >= max{p2(h,v-2), p1(h-2,v)}
10: q = min{p2(h,v-2), p1(h-2,v)}
12: q = max{p2(h,v-2), p1(h-2,v)}
13: else
14: q = p2(h,v-2) + p1(h-2,v) - p3(h-2,v-2)
15: end if
16: end if
17: k0= (p3(h-2,v-2) + p2(h,v-2) + p3(h,v-2) + p2(h+2,v-2) )>>2
18: k1 = ((q>> shift0 + MltDiff1) << shift0) + (1 << (shift0 -1))
22: // outlier_thresh is user control parameter to detect outlier pixel with threshold value
24: // pkq (h,v) is not output data but prediction pixel for using as reference pixel
25: p0q(h,v) = (Pos == 0) ? k0 : k1
26: p1q(h,v) = (Pos == 1) ? k0 : (Pos <1) ? k1 : k2
27: p2q(h,v) = (Pos == 2) ? k0 : (Pos <2) ? k2 : k3
28: p3q(h,v) = (Pos == 3) ? k0 : k3
29: // pk(h,v) is output data, p and pq are different (basically these are same in other mode)
30: p0(h,v) = (Pos == 0) ? k`0 : k1
31: p1(h,v) = (Pos == 1) ? k`0 : (Pos <1) ? k1 : k2
32: p2(h,v) = (Pos == 2) ? k`0 : (Pos <2) ? k2 : k3
33: p3(h,v) = (Pos == 3) ? k`0 : k3
34: // p1(h,v),…, p3(h,v) should be p1(h,v),…, p3(h,v) = k0, when you want to get the pbyr(h,v)
35: pbyr(h,v) = k`0 // Bayer pixel pbyr(h,v)

Confidential
23-May-2022
I.2.3 Advanced Prediction Mode (Tetra-Cell)

5605 For Tetra-Cell image sensors, Advanced Prediction Mode:
5607 loss.
5608 • Supports Compression Modes eMPD, eHVD, eHVA, and eOUT as defined below.
I.2.3.1 Extended Mode 0: eMPD (extended Multi-Pixel-based Directional Differential

Mode)
5609 Compared to Standard Compression Mode AD (which uses Basic Prediction Mode), Compression Mode
5610 eMPD references more pixels and allocates one more bit to each Multi-Pixel in the MPC Packet.
5611 Figure 276 defines the packet structure for Compression Mode eMPD (Tetra-Cell). For this Compression
5612 Mode, Header field Prediction IDX shall contain 1, and the high bit of Header field Mode IDX shall contain
5613 0.
5616 • Fields ByrDiff and MltDiff1 through MltDiff3 shall contain the quantized differences between the
5617 predicted value and each pixel.
5620 Table 85 shows pseudo-code for decoding an MPC Packet for Compression Mode eMPD (Tetra-Cell).
5621
Figure 276 MPC Packet Structure for Compression Mode eMPD (Tetra-Cell)

Confidential
23-May-2022
5622 Note:
5628 Table 85 Decoder for Compression Mode eMPD (Tetra-Cell)

3: // Preprocessing reference data
4: threshold = green pixel ?10 : 20
5: href = abs(p3(h-2,v-2) – p2(h,v-2))
6: vref = abs(p3(h-2,v-2) – p1(h-2,v))
7: mref = href – vref
8: diag_ref =green pixel ? p3(h-1,v-1) : p3(h-1,v-2)
9: // color pixel first: green pixel ? p3(h,v-1) : p3(h-2,v-2)
10: // For decoding p0(h,v)
12: q0 = p1 (h-2,v)
14: q0 = p2 (h,v-2)
15: else //Prediction value q
16: if (mref < threshold)
17: q0 = diag_ref
18: else
19: if p3(h-2,v-2) >= max{p2(h,v-2), p1(h-2,v)}
20: q0 = min{p2(h,v-2), p1(h-2,v)}
22: q0 = max{p2(h,v-2), p1(h-2,v)}
23: else
24: q0 = p2(h,v-2) + p1(h-2,v) - p3(h-2,v-2)
25: end if
26: end if
27: end if
28: p0 (h,v)= ((q0 >> shift0 + ByrDiff) << shift0) + (1 << (shift0 -1))
31: q1 = p0(h,v)
33: q1 = p3(h,v-2)
35: if p2(h,v-2) >= max{p3(h,v-2), p0(h,v)} // Prediction value q1 of p1(h,v)
36: q1 = min{p3(h,v-2), p0(h,v)}
37: else if p2(h,v-2) <= min{p3(h,v-2), p0(h,v)}

Confidential
23-May-2022
38: q1 = max{p3(h,v-2), p0(h,v)}

39: else
40: q1 = p3(h,v-2) + p0(h,v) - p2(h,v-2)
41: end if
42: end if
43: p1 (h,v)= ((q1 >> shift0 + MltDiff1) << shift0) + (1 << (shift0 -1))
45: if q0 == p2(h,v-2)
46: q2 = p0(h,v)
47: else
48: q2 = (p1(h-2,v) + p3(h-2,v))>>1
49: end if
52: if q1 == p0(h,v)
53: q3 = p2(h,v)
54: else if q1 == p3(h,v-2)
55: q3 = p1(h,v)
56: else
57: q3 = p0(h,v)
58: end if

Confidential
23-May-2022
I.2.3.2 Extended Mode 1: eHVD (extended Horizontal or Vertical Direction-based

Differential Mode)
5629 Compression Mode eHVD references pixels that are located along the horizontal or vertical direction.
5630 Figure 277 defines the packet structure for Compression Mode eHVD (Tetra-Cell). For this Compression
5631 Mode, Header field Prediction IDX shall contain 1, and the high two bits of Header field Mode IDX shall
5632 contain 2’b10.
5635 If Dir contains 0 then the reference direction is the vertical direction
5636 If Dir contains 1 then the reference direction is the horizontal direction
5642 Table 86 shows pseudo-code for decoding an MPC Packet for Compression Mode eVHD (Tetra-Cell).
5643
Figure 277 MPC Packet Structure for Compression Mode eHVD (Tetra-Cell)

Confidential
23-May-2022
5644 Note:
5647 color.
Table 86 Decoder for Compression Mode eHVD (Tetra-Cell)

4: if Dir == 1 // Horizontal direction
5: q0 = p1(h-2,v)
6: q2 = p3(h-2,v)
9: q1 = p0(h,v)
10: q3 = p2(h,v)
13: else // Vertical direction
14: q0 = p2(h,v-2)
15: q1 = p3(h,v-2)
18: q2 = p0(h,v)
19: q3 = p1(h,v)
22: end if

Confidential
23-May-2022
I.2.3.3 Extended Mode 2: eHVA (extended Horizontal or Vertical Average-based

Differential Mode)
5650 Compression Mode eHVA takes the horizontal or vertical averages of the four Multi-Pixels in the Tetra-Cell.
5651 Figure 279 defines the packet structure for Compression Mode eHVA. For this Compression Mode, Header
5652 field Prediction IDX shall contain 1, and Header field Mode IDX shall contain 3’b110.
5653 The Payload shall contain compressed data for the four pixels of a Tetra-Cell, organized as two 2-pixel
5654 couplets (see Figure 278):
5655 • 1-bit field Dir shall the indicate the compression orientation for this MPC Packet. The value of
5656 field Dir shall determine how all of the other fields are interpreted.
5657 If Dir contains 0: The orientation shall be vertical, and each decoded pixel couplet shall be 1x2
5658 pixels. The first pixel couplet shall be p0(h, v) and p2(h, v), and the second pixel couplet shall be
5659 p1(h, v) and p3(h, v).
5660 If Dir contains 1: The orientation shall be horizontal, and each decoded pixel couplet shall be 2x1
5661 pixels. The first pixel couplet shall be p0(h, v) and p1(h, v), and the second pixel couplet shall be
5662 p2(h, v) and p3(h, v).
Vertical Orientation Horizontal Orientation
Field Dir = 0 Field Dir = 1
First
p0 p1 p0 p1 Pixel
Couplet
Second
p2 p3 p2 p3 Pixel
Couplet
First Second
Pixel Pixel
5663 Couplet Couplet
Figure 278 Pixel Couplet Definitions for eHVA Mode
5664 • Field ByrDiff shall contain the quantized differences between the predicted value and the average
5665 of the two pixels in the first pixel couplet. Field MltDiff shall contain the quantized differences
5666 between the predicted value and the average of the two pixels in the second pixel couplet.
5667 Note:
5668 Field ByrDiff can also be regarded as MltDiff; it is used for generation of the Bayer image,
5669 see Section I.3.4).
5670 That is,
5671 If field Dir indicates vertical orientation (value 0), then:
5672 • Field ByrDiff shall contain the average of p0(h, v) and p2(h, v)
5673 • Field MltDiff shall contain the average of p1(h, v) and p3(h, v)
5674 If field Dir indicates horizontal orientation (value 1), then:
5675 • Field ByrDiff shall contain the average of p0(h, v) and p1(h, v)
5676 • Field MltDiff shall contain the average of p2(h, v) and p3(h, v)

Confidential
23-May-2022
5677 • 1-bit field Slope shall indicate, for both pixel couplets, whether the slope of the gradient is
5678 increasing or decreasing in the Dir direction.
5679 If Slope contains 0, then the gradient slope is decreasing and the MPC packet shall be decoded
5680 as:
5681 First pixel couplet = (ByrDiff + alpha, ByrDiff − alpha)
5682 Second pixel couplet = (MltDiff + beta, MltDiff − beta)
5683 If Slope contains 1, then the gradient slope is increasing and the MPC Packet shall be decoded as:
5684 First pixel couplet = (ByrDiff − alpha, ByrDiff + alpha)
5685 Second pixel couplet = (MltDiff − beta, MltDiff + beta)
5686 Where alpha and beta are both defined as:
5687 4 for compression ratio 10:5, or
5688 1 for compression ratio 10:6, or
5689 0 for compression ratio 10:7
5690 • 1-bit fields Detail[0] and Detail[1] shall determine, for each pixel couplet, whether the pixel value
5691 variations alpha and beta shown above shall be (value 1) or shall not be (value 0) replaced with
5692 the difference from the neighboring pixels.
5693 Example: Assume that field Slope indicates decreasing slope (value 0). If field Detail[0]
5694 contains 1, then the first pixel couplet shall be decoded not as (MltDiff + alpha, MltDiff −
5695 alpha) as shown above, but rather as: (MltDiff + delta, MltDiff − delta) (where delta is the
5696 difference from the neighboring pixels).
5697 Table 87 shows pseudo-code for decoding an MPC Packet for Compression Mode eHVA.
5698
Figure 279 MPC Packet Structure for Compression Mode eHVA
5699 Note:
5702 color.
Table 87 Decoder for Compression Mode eHVA

2: shift0 = 4
3: average0 = (ByrDiff << shift0) + (1 << (shift0-1))
4: average1 = (MltDiff<< shift0) + (1 << (shift0-1))
5: if Dir == 0 // Vertical direction
6: q0 = p0(h,v-2)
7: q1 = p2(h,v-2)
8: q2 = p1(h,v-2)
9: q3 = p3(h,v-2)
10: else // Horizontal direction, Dir == 1 case
11: q0 = p0(h-2,v)
12: q1 = p2(h-2,v)

Confidential
23-May-2022
13: q2 = p1(h-2,v)
14: q3 = p3(h-2,v)
15: end if
16: if Detail[1] == 0 // for Horizontal direction p0(h,v), p1(h,v) or Vertical direction p0(h,v), p2(h,v)
17: diff0 = abs(q0 – q1) >> 1
18: >> 1
else
19: diff0 = 4
20: end if
21: if Detail[0] == 0 // for Horizontal direction p2(h,v), p3(h,v) or Vertical direction p1(h,v), p3(h,v)
22: diff1 = abs(q2 – q3) >> 1
23: >> 1
else
24: diff1 = 4
25: end if
27: if Slope == 1
28: p0(h,v) = average0 – diff0
29: p1(h,v) = average0 + diff0
32: else
37: end if
39: if Slope == 1
44: else
49: end if
50: p0(h,v) = (p0(h,v) > 1023) ? 1023 : (p0(h,v) < 0) ? 0 : p0(h,v)
51: p1(h,v) = (p1(h,v) > 1023) ? 1023 : (p1(h,v) < 0) ? 0 : p1(h,v)
52: p2(h,v) = (p2(h,v) > 1023) ? 1023 : (p2(h,v) < 0) ? 0 : p2(h,v)
53: p3(h,v) = (p3(h,v) > 1023) ? 1023 : (p3(h,v) < 0) ? 0 : p3(h,v)
54: // p1(h,v),…, p3(h,v) should be p1(h,v),…, p3(h,v) = average0, when you want to get the pbyr(h,v)
55: pbyr(h,v) = average0 // Bayer pixel pbyr(h,v)

Confidential
23-May-2022
I.2.3.4 Extended Mode 3: eOUT (extended OUTlier Compensation Mode)

5705 Compression Mode eOUT is intended for compressing pixels that are located at the corners of object edge
5706 pattern.
5707 Figure 280 defines the packet structure for Compression Mode eOUT. For this Compression Mode, Header
5710 • 1-bit field Opt shall indicate whether to invert the value of the prediction pixel:
5711 • 0: Normal Reference Value: The actual value of the prediction pixel shall be used.
5712 • 1: Inverse Reference Value: The inverse of the value of the prediction pixel shall be used. That
5713 is, the magnitude of the prediction pixel value shall be inverted, using the formula:
5714 reference value = 1023 – prediction pixel value
5719 Table 88 shows pseudo-code for decoding an MPC Packet for Compression Mode eOUT.
5720
Figure 280 MPC Packet Structure for Compression Mode eOUT

Confidential
23-May-2022
5721 Note:
5724 color.
5725 Note also that this pseudo-code describes each case of 2x2 Green pk (h, v) and 2x2 Red/Blue
5726 pk (h+1, v) pixels.
Table 88 Decoder for Compression Mode eOUT

1: /****************** For decoding the green pixel pk(h,v), k={0,1,2,3}********************/
3: shift0 = 4
4: shift1 = 5
5: // Offset value definition
6: offset1= 64
7: offset2= 32
8: offset3= 64
9: // Prediction pixel value definition
10: q1= (p2(h+1,v-1) + offset1)
11: q1= (q1 > 1023) ? 1023 : (q1< 0) ? 0 : q1
12: if Qpt == 1
13: q_inv1=1023 – q1
14: q1= (q_inv1 == 0) ? q1 : q_inv1
15: end if
16: p1 (h,v) = ((q1>>shift1 + MltDiff2) << shift1) + (1 << (shift1-1))
18: q3= (p3(h+1,v-1) + offset3)
19: )q3= (q3 > 1023) ? 1023 : (q3< 0) ? 0 : q3
20: if Qpt == 1
21: q_inv3=1023 – q3
22: q3= (q_inv3 == 0) ? q3 : q_inv3
23: end if
24: p3 (h,v) = ((q3>>shift0+ ByrDiff) << shift0) + (1 << (shift0-1))
26: q0= (p1 (h,v) > p3 (h,v)) ? p1 (h,v) : p3 (h,v)
27: p0 (h,v) = ((q0>>shift0+ MltDiff1) << shift0) + (1 << (shift0-1))
29: if (Line count < 4) // Vertical line counter, boundary condition
30: q2 = p2 (h,v)
32: q2 = p1 (h,v)
34: if p0(h,v) >= max{ p1(h,v), p2(h,v)}
35: q2 = min{ p1(h,v), p2 (h,v)}
36: else if p0(h,v) <= min{ p1(h,v), p2(h,v)}

Confidential
23-May-2022
37: q2 = max{ p1(h,v), p2 (h,v)}

38: else
39: q2 = p1(h,v)+ p2 (h,v) – p0 (h,v)
40: end if
41: end if
42: q2= q2+ offset2
43: q2= (q2 > 1023) ? 1023 : (q2< 0) ? 0 : q2
44: p2 (h,v) = ((q2>>shift1+ MltDiff3) << shift1) + (1 << (shift1-1))
47: /****************** For decoding the red/blue pixel pi(h+1,v),
48: i={0,1,2,3}*******************/
// Quantization step
49: shift0 = 4
50: shift1 = 5
51: // Offset value definition
46: offset1= 64
47: offset2= 32
48: offset3= 64
50: q1= (p3(h+1,v-2) + offset1)
51: q1= (q1 > 1023) ? 1023 : (q1< 0) ? 0 : q1
52: if Qpt == 1
53: q_inv1=1023 – q1
54: q1= (q_inv1 == 0) ? q1 : q_inv1
55: end if
56: p1 (h+1,v) = ((q1>>shift1 + MltDiff2) << shift1) + (1 << (shift1-1))
58: q3= (p3(h+1,v-2) + offset3)
59: q3= (q3 > 1023) ? 1023 : (q3< 0) ? 0 : q3
60: if Qpt == 1
61: q_inv3=1023 – q3
62: q3= (q_inv3 == 0) ? q3 : q_inv3
63: end if
64: p3 (h+1,v) = ((q3>>shift0+ ByrDiff) << shift0) + (1 << (shift0-1))
66: q0= (p1 (h,v) > p3 (h,v)) ? p1 (h,v) : p3 (h,v)
67: p0 (h+1,v) = ((q0>>shift0+ MltDiff1) << shift0) + (1 << (shift0-1))
69: if p0(h,v) < min{ p1(h,v), p2(h,v)}
70: q2 = max{ p1(h,v), p2 (h,v)}
71: else if p0(h,v) > max{ p1(h,v), p2(h,v)}
72: q2 = min{ p1(h,v), p2 (h,v)}
73: else

Confidential
23-May-2022
74: q2 = p1(h,v)+ p2 (h,v) – p0 (h,v)

75: end if
76: q2= q2+ offset2
77: q2= (q2 > 1023) ? 1023 : (q2< 0) ? 0 : q2
78: p2 (h+1,v) = ((q2>>shift1+ MltDiff3) << shift1) + (1 << (shift1-1))
79: // p1(h+1,v),…, p3(h+1,v) should be p1(h+1,v),…, p3(h+1,v) = p0(h+1,v),
80: // when you want to get the pbyr(h+1,v)
81: pbyr(h+1,v) = p0(h+1,v) // Bayer pixel pbyr(h+1,v)

Confidential
23-May-2022
I.2.4 Low Resolution Image Generation (Tetra-Cell)

5727 The MPC architecture for Tetra-Cell image sensors supports an additional low-resolution Bayer image. The
5728 Bayer image is reconstructed by pbyr which is described in the Compression Mode Decoder pseudo-code in
5729 Section I.2.2.1 through Section I.2.3.4.
5730 For all Tetra-Cell Compression Modes, the Bayer image can be generated using only the information that is
5731 present in the first half of the MPC Packet. This is shown in Figure 281.
5732 • For Compression Mode OUT, the Bayer image is generated by averaging neighboring pixels (see
5733 Section I.2.2.1).
5734 • For all other Compression Modes, the Bayer image is generated using field ByrDiff or ByrPixel.
5735
Figure 281 Low Resolution Image Generation by Pbyr (Tetra-Cell)

Confidential
23-May-2022
I.2.5 Adjustment of Compression Ratio (Tetra-Cell)

5736 The MPC architecture for Tetra-Cell image sensors supports three compression ratios: 10:5, 10:6, and 10:7.
5737 Decoding uses the same algorithm for all Compression Ratios (with one exception: Compression Mode OUT
5738 with Compression Ratio 10:7 has a different decoding process, bit allocation, and the shift amount). Higher
5739 Compression Ratios are achieved by extending the bit allocation and the shift amount (i.e., field Qstep).
5740 Table 89 shows pseudo-code for decoding an MPC Packet for Compression Mode OUT (Tetra-Cell) with the
5741 10:7 Compression Ratio.
Table 89 Decoder for Compression Mode OUT (Tetra-Cell) with 10:7 Compression Ratio
2: shift0 = 2, shift1 = 3
3: // For decoding pk(h,v), k={0,1,2,3}
11: k0= (p3(h-2,v-2) + p2(h,v-2) + p3(h,v-2) + p2(h+2,v-2) )>>2
12: k1 = (MltDiff1 << shift0) + (1 << (shift0 -1))
17: // pkq (h,v) is not output data but prediction pixel for using as reference pixel
18: p0q(h,v) = (Pos == 0) ? k0 : k1
19: p1q(h,v) = (Pos == 1) ? k0 : (Pos <1) ? k1 : k2
20: p2q(h,v) = (Pos == 2) ? k0 : (Pos <2) ? k2 : k3
21: p3q(h,v) = (Pos == 3) ? k0 : k3
22: // pk(h,v) is output data, p and pq are different (basically these are same in other mode)
23: p0(h,v) = (Pos == 0) ? k`0 : k1
24: p1(h,v) = (Pos == 1) ? k`0 : (Pos <1) ? k1 : k2
25: p2(h,v) = (Pos == 2) ? k`0 : (Pos <2) ? k2 : k3
26: p3(h,v) = (Pos == 3) ? k`0 : k3
27: pbyr(h,v) = k`0 // Bayer pixel pbyr(h,v)

Confidential
23-May-2022
5742 Figure 282 and Figure 283 define the Packet structures for Compression Ratios 10:6 and 10:7, respectively,
5743 for Tetra-Cell. Differences in the bit allocations are highlighted in red.
5744
Figure 282 MPC Packet Structures for Compression Ratio 10:6 (Tetra-Cell)
5745
Figure 283 MPC Packet Structures for Compression Ratio 10:7 (Tetra-Cell)

Confidential
23-May-2022
5746 Figure 284 defines the values of shift0 and shift1 to use (i.e., in the respective Decoder pseudo-code per
5747 Compression Mode) for each combination of Tetra-Cell Compression Mode, value of field Qstep, and
5748 Compression Ratio.
5749
Figure 284 Quantization Bits for Compression Ratios (Tetra-Cell)

Confidential
23-May-2022
I.3 MPC for Nona-Cell Image Sensor

5750 MPC for Nona-Cell image sensors supports the eight Compression Modes that are defined in this Section
5751 and summarized in Table 90. If MPC is supported, then all eight MPC decoder Data Compression Modes
5752 shall be supported. Each Compression Mode uses either Basic Prediction Mode or Advanced Prediction
5753 Mode. Figure 285 summarizes the MPC Packet structures used for Nona-Cell Compression Modes.
5754 Table 90 MPC Compression Modes for Nona-Cell Image Sensors
Mode Description
Mode Name Section
AD Average-based Directional Differential Mode I.3.2.1
DGD DiaGonal Direction-based Differential Mode I.3.2.1
eAD extended Average-based Directional Differential Mode I.3.3.1
extended Horizontal or Vertical Direction-based Differential
eHVD I.3.3.2
Mode
extended Horizontal or Vertical Average-based Intra-Cell
eHVI I.3.3.2
Differential Mode
extended Slanted Horizontal or Vertical Direction-based
eSHV I.3.3.2
Differential Mode
eMPD extended Multi-Pixel-based Directional Differential Mode I.3.3.5
5755
Figure 285 MPC Packet Structures for Nona-Cell Compression Modes

Confidential
23-May-2022
I.3.1 Reference Pixels for Prediction (Nona-Cell)

5758 In a Nona-Cell image, each cell consists of nine Multi-Pixels in a 3x3 matrix.
5759 A given pixel is expressed as pk(i, j), where:
5760 • k: The Multi-Pixel index within the Nona-Cell, i.e., 0–8 as shown in Figure 286.
5761 For example:
5762 • p0 is the upper left Multi-pixel
5763 • p4 is the center Multi-Pixel, and
5764 • p8 is the lower right Multi-Pixel.
p0 p1 p2
p3 p4 p5
p6 p7 p8
5765
Figure 286 Nona-Cell Multi-Pixel Indexing
5766 • i: Horizontal index of the Nona-Cell where the Multi-Pixel is located.

5767 • j: Vertical index of the Nona-Cell where the Multi-Pixel is located.
5768 For a current Nona-Cell p(h, v), the coordinates are relative to a reference Nona-Cell and are expressed as:
5769 • The Horizontal relative index from the current Nona-Cell to the reference Nona-Cell,
5770 Reference Nona-Cells to the left of the current Nona-Cell have negative h indexes,
5771 reference Nona-Cells directly above or below the current Nona-Cell have zero h indexes,
5772 and reference Nona-Cells to the right of the current Nona-Cell have positive h indexes.
5773 and
5774 • The Vertical relative index from the current Nona-Cell to the reference Nona-Cell
5775 Reference Nona-Cell located above the current Nona-Cell have negative v indexes, and
5776 reference Nona-Cell in the same image line as the current Nona-Cell have zero v indexes.
5777 Examples:
5778 p(h, v–1) Nona-Cell immediately above the current Nona-Cell
5779 p(h–1, v) Nona-Cell immediately to the left of the current Nona-Cell
5780 p(h+1, v−1) Nona-Cell immediately above and immediately to the right of the current Nona-Cell
5781 p(h–1, v–1) Nona-Cell immediately above and immediately to the left of the current Nona-Cell

Confidential
23-May-2022
Green Pixel First
Blue Pixel First
5785 Not Shown: Red Pixel First
Figure 287 Reference Pixel Relative Coordinate Indexes (Nona-Cell)
5786 For a Nona-Cell image sensor, the eighteen highlighted pixels in the bottom three rows will be encoded. This
5787 corresponds to Nona-Cell coordinates p(h, v) (i.e., the current Nona-Cell) and p(h+1, v). The other colored

5789 At the boundary of the image frame no neighboring reference pixels exist. As a result, difference calculations
5795 in low-light conditions or the value 128 for normal conditions.

Confidential
23-May-2022
I.3.2 Basic Prediction Mode (Nona-Cell)

5796 For Nona-Cell image sensors, Basic Prediction Mode:
5799 • Supports Compression Modes AD, DGD, and FNR as defined below.
I.3.2.1 Standard Mode 0: AD (Average-based Directional Differential Mode)

5800 Compression Mode AD is efficient for compressing pixels located on horizontal and vertical edges. An AD
5801 packet transmits one prediction pixel and three reference pixels. The prediction pixel is either the combination
5802 of the three reference pixels, or the reference pixel itself.
5803 Figure 288 defines the packet structure for Compression Mode AD (Nona-Cell). For this Compression Mode,
5804 Header field Prediction IDX shall contain 0, and the high bit of Header field Mode IDX shall contain 0.
5805 The Payload shall contain compressed data for the nine pixels of a Nona-Cell:
5808 nine pixels, and is also used for generation of the Bayer image (see Section I.3.4).
5809 • Fields MltDiff0 through MltDiff8 shall contain the encoded data between the averaged pixel and
5810 each Multi-Pixel.
5811 Table 91 shows pseudo-code for decoding an MPC Packet for Compression Mode AD (Nona-Cell).
5812
Figure 288 MPC Packet Structure for Compression Mode AD (Nona-Cell)

Confidential
23-May-2022
5813 Note:
5816 color.
Table 91 Decoder for Compression Mode AD (Nona-Cell)

4: // For decoding the pixel pk(h,v), k={0,1,…,8}
6: q = p2 (h-2,v)
8: q = p6 (h,v-2)
10: if p8(h-2,v-2) >= max{p2(h,v-2), p6(h-2,v)}
11: q = min{p2(h,v-2), p6(h-2,v)}
13: q = max{p2(h,v-2), p6(h-2,v)}
14: else
15: q = p2(h,v-2) + p6(h-2,v) - p8(h-2,v-2)
16: end if
17: end if
18: pbyr(h,v) = ((q >>shift0 + ByrDiff) << shift0 ) + (1 << (shift0-1)) // Bayer pixel pbyr

Confidential
23-May-2022
I.3.2.2 Standard Mode 1: DGD (DiaGonal Direction-based Differential Mode)

5819 Compression Mode DGD references pixels that are located along diagonal directions.
5820 Figure 289 defines the packet structure for Compression Mode DGD (Nona-Cell). For this Compression
5824 • Fields ByrDiff and MltDiff1 through MltDiff8 shall contain the encoded data between the predicted
5825 pixel and each original pixel.
5828 Table 92 shows pseudo-code for decoding an MPC Packet for Compression Mode DGD (Nona-Cell).
5829
Figure 289 MPC Packet Structure for Compression Mode DGD (Nona-Cell)

Confidential
23-May-2022
5830 Note:
Table 92 Decoder for Compression Mode DGD (Nona-Cell)

3: // direction for pk(h,v)
4: ldiff0 = abs(p3(h-1,v-1) – p7(h-1,v-1)) // color pixel first: abs(p3(h,v-1) – p7(h,v-1))
6: ldiff2 = abs(p3(h+1,v-1) – p7(h+1,v-1)) // color pixel first: abs(p3(h,v-1) – p7(h,v-1))
8: rdiff0 = abs(p4(h-1,v-1) – p6(h-1,v-1)) // color pixel first: abs(p4(h+2,v-1) – p6(h+2,v-1))
10: rdiff2 = abs(p4(h+1,v-1) – p6(h+1,v-1)) // color pixel first: abs(p4(h+2,v-1) – p6(h+2,v-1))
12: ldiff = ldiff0 + ldiff1 + ldiff2 + ldiff3
13: rdiff = rdiff0 + rdiff1 + rdiff2 + rdiff3
14: left_en = (ldiff < rdiff) ? 1 : 0
15: // For decoding the green pixel pk(h,v), k={0,1,..,8}
16: if left_en == 1
17: // Prediction pixel
18: q0(h,v) = p8(h-1,v-1) // color pixel first: q0(h,v) = p8(h-2,v-2)
23: // For decoding the pixel
24: p0(h,v) = ((q0(h,v) >> shift0 + ByrDiff) << shift0) + (1 << (shift0 -1))
25: p1(h,v) = ((q1(h,v) >> shift0 + MltPixel1) << shift0) + (1 << (shift0 -1))
30: q4(h,v) = p0(h,v) // color pixel first: q4(h,v) = p0(h,v)

Confidential
23-May-2022

40: else // Right diagonal direction
42: q2(h,v) = p6(h+1,v-1) // color pixel first: q2(h,v) = p6(h+2,v-2)
62: q6(h,v) = p4(h,v)
65: pbyr(h,v)= p0(h,v) // Bayer green pixel pbyr(h,v)

Confidential
23-May-2022

5836 If the difference between the current pixel and reference pixel is large, then the pixel should be compressed
5837 by fixed quantization. In Compression Mode FNR the data is compressed using only quantization, with no
5838 difference operation.
5839 Figure 290 defines the packet structure for Compression Mode FNR (Nona-Cell). For this Compression
5842 • Fields ByrPixel and MltPixel1 through MltPixel8 shall contain the quantization results of each
5843 Multi-Pixel.
5844 Field ByrPixel can also be regarded as MltPixel0; it is used for generation of the Bayer
5847
Figure 290 MPC Packet Structure for Compression Mode FNR (Nona-Cell)
5848 Note:
5850 Note also that this pseudo-code only describes 3x3 pixels pk(h, v) to be compressed. These should
Table 93 Decoder for Compression Mode FNR (Nona-Cell)

2: shift0 = 5
3: shift1 = 6
5: p0(h,v) = (ByrPixel << shift0) + (1 << (shift0 -1))
14 // p1(h,v),…, p8(h,v) should be p1(h,v),…, p8(h,v) = p0(h,v), when you want to get the pbyr(h,v)

Confidential
23-May-2022
I.3.3 Advanced Prediction Mode (Nona-Cell)

5852 For Nona-Cell image sensors, Advanced Prediction Mode:
5854 loss.
5855 • Supports Compression Modes eAD, eMPD, eHVD, eHVI, and eSHV as defined below.
I.3.3.1 Extended Mode 0: eAD (extended Average-based Directional Differential Mode)

5856 Compression Mode eAD extends Standard Compression Mode AD (which uses Basic Prediction Mode) by
5857 increasing the number of quantization levels.
5858 Figure 291 defines the packet structure for Compression Mode eAD (Nona-Cell). For this Compression
5862 • 1-bit field Qstep shall indicate the quantization step size.
5864 nine pixels, and is also used for generation of the Bayer image (see Section I.3.4).
5865 • Fields MltDiff0 through MltDiff8 shall contain the quantized differences between the average and
5866 each Multi-Pixel.
5867 Table 94 shows pseudo-code for decoding an MPC Packet for Compression Mode eAD (Nona-Cell).
5868
Figure 291 MPC Packet Structure for Compression Mode eAD (Nona-Cell)

Confidential
23-May-2022
5869 Note:
Table 94 Decoder for Compression Mode eAD (Nona-Cell)

2: shift0 = 5
3: shift1 = (Qstep==0) ? 4 : 5
6: q = p2 (h-2,v)
8: q = p6 (h,v-2)
10: if p8(h-2,v-2) >= max{p2(h,v-2), p6(h-2,v)}
11: q = min{p2(h,v-2), p6(h-2,v)}
13: q = max{p2(h,v-2), p6(h-2,v)}
14: else
15: q = p2(h,v-2) + p6(h-2,v) - p8(h-2,v-2)
16: end if
17: end if
19: pbyr(h,v) = ((q >>shift0 + ByrDiff) << shift0 ) + (1 << (shift0-1)) // Bayer pixel pbyr

Confidential
23-May-2022
I.3.3.2 Extended Mode 1: eHVD (extended Horizontal or Vertical Direction-based

Differential Mode)
5875 Compression Mode eHVD references pixels that are located along the horizontal or vertical direction.
5876 Figure 292 defines the packet structure for Compression Mode eHVD (Nona-Cell). For this Compression
5881 If Dir contains 0 then the reference direction is the vertical direction
5882 If Dir contains 1 then the reference direction is the horizontal direction
5886 Field ByrPixel can also be regarded as MltDiff0; it is used for generation of the Bayer
5888 Table 95 shows pseudo-code for decoding an MPC Packet for Compression Mode eHVD (Nona-Cell).
5889
Figure 292 MPC Packet Structure for Compression Mode eHVD (Nona-Cell)

Confidential
23-May-2022
5890 Note:
Table 95 Decoder for Compression Mode eHVD (Nona-Cell)

3: // For decoding the pixel pi(h,v), i={0,1,2,3,4,5,6,7,8}
4: if Dir == 0 // Vertical direction
5: q0(h,v) = p6(h,v-2) //Prediction value q of the preview pixel
8: p0(h,v) = ((q0(h,v) >>shift0 + ByrDiff) << shift0) + (1 << (shift0-1))
9: p1(h,v) = ((q1(h,v) >>shift0 + MltDiff1) << shift1) + (1 << (shift0-1))
11: q3(h,v) = p0(h,v) //Prediction value q of the preview pixel
23: else
24: q0(h,v) = p2(h-2,v) //Prediction value q of the preview pixel
27: p0(h,v) = ((q0(h,v) >>shif01 + ByrDiff) << shift0) + (1 << (shift0-1))

Confidential
23-May-2022

43: pbyr(h,v) = p0(h,v) // Bayer pixel pbyr

Confidential
23-May-2022
I.3.3.3 Extended Mode 2: eHVI (extended Horizontal or Vertical Average-based Intra-

Cell Differential Mode)
5896 Compression Mode eHVI takes the horizontal or vertical difference from intra-cell pixels, not from inter-cell
5897 pixels.
5898 Figure 294 defines the packet structure for Compression Mode eHVI. For this Compression Mode, Header
5900 The Payload shall contain compressed data for the nine pixels of a Nona-Cell, organized as three 3-pixel
5901 triplets (see Figure 278):
5902 • 1-bit field Dir shall the indicate the compression orientation for this MPC Packet:
5903 If Dir contains 0: The orientation shall be vertical, and each decoded pixel triplet shall be 1x3
5904 pixels. The first pixel triplet shall be p0(h, v), p3(h, v), and p6(h, v); the second pixel triplet shall be
5905 p1(h, v), p4(h, v), and p7(h, v); and the third pixel triplet shall be p2(h, v), p5(h, v), and p8(h, v).
5906 If Dir contains 1: The orientation shall be horizontal, and each decoded pixel triplet shall be 3x1
5907 pixels. The first pixel triplet shall be p0(h, v), p1(h, v), and p2(h, v); the second pixel triplet shall be
5908 p3(h, v), p4(h, v), and p5(h, v); and the third pixel triplet shall be p6(h, v), p7(h, v), and p8(h, v).
Vertical Orientation Horizontal Orientation

Field Dir = 0 Field Dir = 1
First
p0 p1 p2 p0 p1 p2 Pixel
Triplet
Second
Triplet
Third
Triplet
First Second Third

Pixel Pixel Pixel
Triplet Triplet Triplet
5909
Figure 293 Pixel Triplet Definitions for eHVI Mode

5911 • Fields ByrDiff, MltDiff1, and MltDiff2 shall contain the fixed quantization result of the center pixel
5912 of the first pixel triplet, the center pixel of the second pixel triplet, and the center pixel of the third
5913 pixel triplet, respectively; no difference operation is involved.
5914 If field Dir indicates vertical orientation (value 0), then:
5915 • Field ByrDiff shall contain the fixed quantization result of p3(h, v)
5916 • Field MltDiff1 shall contain the fixed quantization result of p4(h, v)
5918 If field Dir indicates horizontal orientation (value 1), then:
5919 • Field ByrDiff shall contain the fixed quantization result of p1(h, v)
5922 • Fields MltDiff3 and MltDiff4 shall contain the quantized differences with the predicted value of
5923 ByrDiff in the first pixel triplet. Fields MltDiff5 and MltDiff6 shall contain the quantized differences
5924 with the predicted value of MltDiff1 in the second pixel triplet. Fields MltDiff7 and MltDiff8 shall
5925 contain the quantized differences with the predicted value of MltDiff2 in the third pixel triplet.

Confidential
23-May-2022
5928 Table 96 shows pseudo-code for decoding an MPC Packet for Compression Mode eHVI.
5929
Figure 294 MPC Packet Structure for Compression Mode eHVI
5930 Note:
5933 color.
5936 Table 96 Decoder for Compression Mode eHVI

4: p1(h,v) = (ByrDiff << 3) + (1 << 2)
5: p4(h,v) = (MltDiff1<< 3) + (1 << 2)
6: p7(h,v) = (MltDiff2<< 3) + (1 << 2)
7: p0(h,v) = ((p1(h,v) >> shift0 + MltDiff3) << shift0) + (1 << (shift0 -1))
14: p3(h,v) = (ByrDiff << 3) + (1 << 2)
15: p4(h,v) = (MltDiff1<< 3) + (1 << 2)
16: p5(h,v) = (MltDiff2<< 3) + (1 << 2)
23: end if
25: pbyr(h,v) = (ByrDiff << 3) + (1 << 2) // Bayer pixel pbyr(h,v)

Confidential
23-May-2022
I.3.3.4 Extended Mode 3: eSHV (extended Slanted Horizontal or Vertical Direction-

based Differential Mode)
5937 Compression Mode eSHV references pixels that are located along the slanted horizontal or vertical direction.
5938 Figure 295 defines the packet structure for Compression Mode eSHV (Nona-Cell). For this Compression
5946 Table 97 shows pseudo-code for decoding an MPC Packet for Compression Mode eSHV (Nona-Cell).
5947
Figure 295 MPC Packet Structure for Compression Mode eSHV (Nona-Cell)
5948 Note:
5954 Table 97 Decoder for Compression Mode eSHV (Nona-Cell)

3: // direction for pk(h,v)
12: ldiff = ldiff0 + ldiff1 + ldiff2 + ldiff3
13: rdiff = rdiff0 + rdiff1 + rdiff2 + rdiff3
14: left_en = (ldiff < rdiff) ? 1 : 0
15: // High-low direction
16: cent = left_en ? p8(h-1,v-1) : p6(h+1,v-1)
17: low = left_en ? p7(h-1,v-1) : p7(h+1,v-1)
18: high = left_en ? p5(h-1,v-1) : p3(h+1,v-1)
19: ldiff = abs(cent - low)
20: hdiff = abs(cent - high)

Confidential
23-May-2022
21: if left_en == 1
22: if high_en == 1
25: q2(h,v) = (p2(h-1,v-1) + p6(h,v-2)) >> 1 // color pixel first: q2(h,v) = p2(h-2,v-2)
28: else
34: end if
42: q4(h,v) = p0(h,v)
43: q5(h,v) = p1(h,v)
44: q7(h,v) = p3(h,v)
50: q8(h,v) = p4(h,v)
53: else // right direction
54: if high_en == 1
57: q0(h,v) = (p0(h+1,v-1) + p8(h,v-2)) >> 1 // color pixel first: q0(h,v) = p0(h+2,v-2)
60: else

Confidential
23-May-2022

66: end if
74: q3(h,v) = p1(h,v)
75: q4(h,v) = p2(h,v)
76: q7(h,v) = p5(h,v)
82: q6(h,v) = p4(h,v)
84: end if
86: pbyr(h,v)=left_en ? p0(h,v) : p2(h,v) // Bayer green pixel pbyr(h,v)

Confidential
23-May-2022
I.3.3.5 Extended Mode 4: eMPD (extended Multi-Pixel-based Directional Differential

Mode)
5955 Compared to Standard Compression Mode AD (which uses Basic Prediction Mode), Compression Mode
5956 eMPD mode references more pixels and allocates one more bit to each Multi-Pixel in the MPC Packet.
5957 Figure 296 defines the packet structure for Compression Mode PD. For this Compression Mode, Header
5963 Field ByrPixel can also be regarded as MltPixel0; it is used for generation of the Bayer
5965 Table 98 shows pseudo-code for decoding an MPC Packet for Compression Mode eMPD.
5966
Figure 296 MPC Packet Structure for Compression Mode eMPD (Nona-Cell)
5967 Note:
Table 98 Decoder for Compression Mode eMPD (Nona-Cell)

3: // Preprocessing reference data
4: threshold = green pixel ?10 : 20
5: href = abs(p8(h-2,v-2) – p6(h,v-2))
6: vref = abs(p8(h-2,v-2) – p2(h-2,v))
7: mref = href – vref
8: diag_ref =green pixel ? p8(h-1,v-1) : p8(h-1,v-2)
9: // color pixel first: green pixel ? p8(h,v-1) : p8(h-2,v-2)
12: q0 = p2 (h-2,v)
14: q0 = p6 (h,v-2)
16: if (mref < threshold)
17: q0 = diag_ref
18: else
19: if p8(h-2,v-2) >= max{p6(h,v-2), p2(h-2,v)}

Confidential
23-May-2022
20: q0 = min{p6(h,v-2), p2(h-2,v)}

22: q0 = max{p6(h,v-2), p2(h-2,v)}
23: else
24: q0 = p6(h,v-2) + p2(h-2,v) – p8(h-2,v-2)
25: end if
26: end if
27: end if
29: p0 (h,v)= ((q0 >> shift0 + ByrDiff) << shift0) + (1 << (shift0 -1))
30: // For decoding the pixel p1 (h,v)
32: q1 = p0 (h,v)
34: q1 = p7 (h,v-2)
36: if p6(h,v-2) >= max{p0(h,v), p7(h,v-2)} //Prediction value q of the preview pixel
37: q1(h,v) = min{ p0(h,v), p7(h,v-2)}
38: else if p6(h,v-2) <= min{p0(h,v), p7(h,v-2)}
39: q1(h,v) = max{ p0(h,v), p7(h,v-2)}
40: else
41: q1(h,v) = p 0(h,v) + p7(h,v-2) - p6(h,v-2)
42: end if
43: end if
47: q2 = p1 (h,v)
49: q2 = p8 (h,v-2)
51: if p7(h,v-2) >= max{p1(h,v), p8(h,v-2)} //Prediction value q of the preview pixel
52: q2(h,v) = min{p1(h,v), p8(h,v-2)}
53: else if p7(h,v-2) <= min{p1(h,v), p8(h,v-2)}
54: q2(h,v) = max{p1(h,v), p8(h,v-2)}
55: else
56: q2(h,v) = p1(h,v) + p8(h,v-2) – p7(h,v-2)
57: end if
58: end if

Confidential
23-May-2022

65: q4 = p3 (h,v)
67: q2 = p1 (h,v)
69: if p0(h,v) >= max{p3(h,v), p1(h,v)} //Prediction value q of the preview pixel
70: q4(h,v) = min{p3(h,v), p1(h,v)}
71: else if p 0(h,v) <= min{p3(h,v), p1(h,v)}
72: q4(h,v) = max{p3(h,v), p1(h,v)}
73: else
74: q4(h,v) = p3(h,v) + p1(h,v) – p0(h,v)
75: end if
76: end if
80: q5 = p4 (h,v)
82: q5 = p2 (h,v)
85: q5(h,v) = min{p4(h,v), p2(h,v)}
86: else if p1(h,v) <= min{p4(h,v), p2(h,v)}
87: q5(h,v) = max{p4(h,v), p2(h,v)}
88: else
89: q5(h,v) = p4(h,v) + p2(h,v) – p1(h,v)
90: end if
91: end if
98: q7 = p6 (h,v)
100: q7 = p4 (h,v)
103: q7(h,v) = min{ p6(h,v), p4(h,v)}
105: q7(h,v) = max{ p6(h,v), p4(h,v)}

Confidential
23-May-2022
106: else
107: q7(h,v) = p6(h,v) + p4(h,v) – p3(h,v)
108: end if
109: end if
113: q8 = p7 (h,v)
115: q8 = p5 (h,v)
118: q8(h,v) = min{ p7(h,v), p5(h,v)}
120: q8(h,v) = max{ p7(h,v), p5(h,v)}
121: else
122: q8(h,v) = p7(h,v) + p5(h,v) – p4(h,v)
123: end if
124: end if
127: pbyr(h,v) = p0 (h,v) // Bayer pixel pbyr(h,v)

Confidential
23-May-2022
I.3.4 Low Resolution Image Generation (Nona-Cell)

5973 The MPC architecture for Nona-Cell image sensors supports an additional low-resolution Bayer image. The
5974 Bayer image is reconstructed by pbyr which is described in the Compression Mode Decoder pseudo-code in
5975 Section I.3.2.1 through Section I.3.3.5.
5976 For all Nona-Cell Compression Modes, the Bayer image can be generated using only information that is
5977 present in the first half of the MPC Packet. This is shown in Figure 297.
5978 • For all other Compression Modes, the Bayer image is generated using field ByrDiff or ByrPixel.
5979
Figure 297 Low Resolution Image Generation by Pbyr (Nona-Cell)

Confidential
23-May-2022
I.3.5 Adjustment of Compression Ratio (Nona-Cell)

5980 Figure 298 and Figure 299 define the Packet structures for Compression Ratios 10:6 and 10:7, respectively,
5981 for Nona-Cell. Differences in the bit allocations are highlighted in red.
5982
Figure 298 MPC Packet Structures for Compression Ratio 10:6 (Nona-Cell)
5983
Figure 299 MPC Packet Structures for Compression Ratio 10:7 (Nona-Cell)

Confidential
23-May-2022
5984 Figure 300 defines the values of shift0 and shift1 to use (i.e., in the respective Decoder pseudo-code per
5985 Compression Mode) for each combination of Nona-Cell Compression Mode, value of field Qstep, and
5986 Compression Ratio.
5987
Figure 300 Quantization Bits for Compression Ratios (Nona-Cell)

Confidential
23-May-2022
I.4 MPC for N x N Multi-Pixel Image Sensor [Informative]

5988 MPC provides scalability for N x N multi-pixel image sensors. Regarding N x N, compression for Tetra-Cell
5989 provides scalability for 2N x 2N (N ≥ 2) Multi-Pixel sensor compression. And compression for Nona-Cell
5990 provides scalability for 3N x 3N (N ≥ 2) Multi-Pixel sensor compression.
5991 For example, MPC compresses 4x4 Multi-Pixel images using the Tetra-Cell compression scheme. If the pixel
5992 order of 4x4 Multi-Pixels is changed such as the Tetra-Cell example illustrated in Figure 301, then MPC
5993 compresses 4x4 Multi-Pixel images. After compression, the pixel order is reverted to the original pixel order.
* P : Pixel * P : Pixel
P00 P01 P02 P03 P04 P05 P06 P07 P08 P09 P010 P011 P012 P013 P014 P015 P00 P01 P04 P05 P02 P03 P06 P07 P08 P09 P012 P013 P010 P011 P014 P015
Pixel array of 4 x 4 Multi-Pixel Pixel order of 4 x 4 Multi-Pixel is changed such as Tetra-Cell

5994
Figure 301 Pixel Order Change from 4x4 Multi-Pixel to Tetra-Cell

Confidential
23-May-2022
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.
Andy Baldman, Keysight Technologies Inc. Takashi Miyamoto, Sony Group Corporation
Nadav Banet, Valens Semiconductor Alexander Mokhoria, Robert Bosch GmbH
Craig Bezek, Teledyne LeCroy Makoto Nariya, Sony Group Corporation
Thomas Blon, Silicon Line GmbH Kavitha Naveen, Tektronix, Inc.
Steven Chang, MediaTek Inc. Allan Paul, Cadence Design Systems, Inc.
Geraud Cheenne, STMicroelectronics Joao Pereira, Synopsys, Inc.
Wei Cheng Ku, MediaTek Inc. Radu Pitigoi-Aron, Qualcomm Incorporated
Stephen Creaney, Cadence Design Systems, Inc. Alex Qiu, NVIDIA
Yoshihiko Deoka, Sony Group Corporation Loren Reiss, Cadence Design Systems, Inc.
James Goel, Qualcomm Incorporated Teong Rong Chua, Sony Group Corporation
Jason Gonzalez, Qualcomm Incorporated Matthew Ronning, Sony Group Corporation
Philip Hawkes, Qualcomm Incorporated Hugo Santos, Synopsys, Inc.
Thomas Hogenmueller, Robert Bosch GmbH Frank Seto, Samsung Electronics, Co.
Timo Kaikumaa, Intel Corporation Greg Stewart, Analogix Semiconductor, Inc.
JaeHyuck Kang, Samsung Electronics, Co. Dale Stolitzka, Samsung Electronics, Co.
Soichi Kayamori, Sony Group Corporation Hiroo Takahashi, Sony Group Corporation
Samson Kim, Qualcomm Incorporated Giuseppe Tofanicchio, STMicroelectronics
Tom Kopet, onsemi Guizhen Wang, HiSilicon Technologies Co. Ltd.
Radha Krishna Atukula, NVIDIA Frank Wang, OmniVision Technologies, Inc.
Raj Kumar Nagpal, Synopsys, Inc. Rick Wietfeldt, Qualcomm Incorporated
Daechul Kwon, Samsung Electronics, Co. George Wiley, Qualcomm Incorporated
Ariel Lasry, Qualcomm Incorporated Stephen Wong, Intel Corporation
Ethan Lau, MediaTek Inc. Charles Wu, OmniVision Technologies, Inc.
Wonseok Lee, Samsung Electronics, Co. Kevin Yee, Samsung Electronics, Co.
William Lo, Axonne Inc. Michel Yeh, MediaTek Inc.
Larry Madar, Google LLC Naoki Yokoshima, Sony Group Corporation
Cedric Marta, Synopsys, Inc. Sang Young Youn, Google LLC
Nuno Martins, onsemi Eunseung Yun, Samsung Electronics, Co.

Confidential
23-May-2022
Past Contributors to v4.0:

Sakari Ailus, Intel Corporation Cedric Marta, Synopsys, Inc.
Radha Krishna Atukula, NVIDIA Adi Menachem, Valens Semiconductor
Nadav Banet, Valens Semiconductor Takashi Miyamoto, Sony Corporation
Gyeonghan Cha, Samsung Electronics, Co. Yoshitomo Osawa, Sony Corporation
Geraud Cheenne, STMicroelectronics Josh Pan, MediaTek Inc.
Teong Rong Chua, Sony Corporation Radu Pitigoi-Aron, Qualcomm Incorporated
Edo Cohen, Valens Semiconductor QuanLin Qiu, NVIDIA
Tomer Cohen, Samsung Electronics, Co. Michael Ripley, Intel Corporation
Al Czamara, Test Evolution Sabarish Sridhar, Google, LLC
James Goel, Qualcomm Incorporated Dale Stolitzka, Samsung Electronics, Co.
Takayuki Hirama, Sony Corporation Hiroo Takahashi, Sony Corporation
Natsuko Ibuki, Google, LLC Haran Thanigasalam, Intel Corporation
Jae Hyuck Kang, Samsung Electronics, Co. Giuseppe Tofanicchio, STMicroelectronics
Soichi Kayamori, Sony Corporation Ayshwarya Venkataramanan, Robert Bosch
Tom Kopet, ON Semiconductor GmbH
Daechul Kwon, Samsung Electronics, Co. Rick Wietfeldt, Qualcomm Incorporated
Ariel Lasry, Qualcomm Incorporated George Wiley, Qualcomm Incorporated
Wonseok Lee, Samsung Electronics, Co. Charles Wu, OmniVision Technologies, Inc.
Mark Lewis, Cadence Design Systems, Inc. Eunseung Yun, Samsung Electronics, Co.
Larry Madar, Google, LLC

Confidential
Version 4.0.1 r03 DRAFT Specification for CSI-2
23-May-2022

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.

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
23-May-2022

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 2 Specification v4 0 1

Uploaded by

Document Information

Original Description:

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 2 Specification v4 0 1

Uploaded by

Copyright:

Available Formats

Specification for

Camera Serial Interface 2

MIPI Board Adopted 14 November 2022

Copyright © 2005–2022 MIPI Alliance, Inc.

ii Copyright © 2005–2022 MIPI Alliance, Inc.

Copyright © 2005–2022 MIPI Alliance, Inc. iii

8 Multi-Lane Distribution and Merging ....................................................................63

iv Copyright © 2005–2022 MIPI Alliance, Inc.

9.17 Data Interleaving ......................................................................................................... 164

Copyright © 2005–2022 MIPI Alliance, Inc. v

12.12 RAW6 Data Reception................................................................................................. 223

vi Copyright © 2005–2022 MIPI Alliance, Inc.

Annex C CSI-2 Recommended Receiver Error Behavior (informative) ................265

Copyright © 2005–2022 MIPI Alliance, Inc. vii

Annex I Multi-Pixel Compression (MPC) ................................................................347

viii Copyright © 2005–2022 MIPI Alliance, Inc.

Copyright © 2005–2022 MIPI Alliance, Inc. ix

Figure 34 CCI I/O Timing..................................................................................................................... 58

x Copyright © 2005–2022 MIPI Alliance, Inc.

Copyright © 2005–2022 MIPI Alliance, Inc. xi

xii Copyright © 2005–2022 MIPI Alliance, Inc.

Copyright © 2005–2022 MIPI Alliance, Inc. xiii

xiv Copyright © 2005–2022 MIPI Alliance, Inc.

Figure 218 CSI-2 Data Lane Transmitter ............................................................................................ 261

Copyright © 2005–2022 MIPI Alliance, Inc. xv

xvi Copyright © 2005–2022 MIPI Alliance, Inc.

Copyright © 2005–2022 MIPI Alliance, Inc. xvii

xviii Copyright © 2005–2022 MIPI Alliance, Inc.

Table 35 Transmission of SROI Embedded Data Packet .................................................................... 152

Copyright © 2005–2022 MIPI Alliance, Inc. xix

xx Copyright © 2005–2022 MIPI Alliance, Inc.

29-Nov-2005 v1.00 Initial Board approved release.

09-Nov-2010 v1.01.00 Board approved release.

22-Jan-2013 v1.1 Board approved release.

10-Sep-2014 v1.2 Board approved release.

07-Oct-2014 v1.3 Board approved release.

28-Mar-2017 v2.0 Board approved release.

09-Apr-2018 v2.1 Board approved release.

10-Sep-2019 v3.0 Board approved release.

08-Dec-2021 v4.0 Board approved release.

2022-11-14 v4.0.1 Board approved release.

Copyright © 2005–2022 MIPI Alliance, Inc. xxi

This page intentionally left blank.

xxii Copyright © 2005–2022 MIPI Alliance, Inc.

Copyright © 2005–2022 MIPI Alliance, Inc. 1

2.1 Use of Special Terms

2 Copyright © 2005–2022 MIPI Alliance, Inc.

Copyright © 2005–2022 MIPI Alliance, Inc. 3

4 Copyright © 2005–2022 MIPI Alliance, Inc.

Copyright © 2005–2022 MIPI Alliance, Inc. 5

153 LP-TX Low-Power Transmitter (Large-Swing Single Ended)

6 Copyright © 2005–2022 MIPI Alliance, Inc.

Copyright © 2005–2022 MIPI Alliance, Inc. 7

This page intentionally left blank.

8 Copyright © 2005–2022 MIPI Alliance, Inc.

Device e.g. a Camera containing the Device e.g. an application engine or

Copyright © 2005–2022 MIPI Alliance, Inc. 9

Device e.g. a Camera containing the Device e.g. an application engine or

10 Copyright © 2005–2022 MIPI Alliance, Inc.

5 CSI-2 Layer Definitions

Lane Management Lane Management

High-Speed Unidirectional Clock

High-Speed Unidirectional Lane 1