简介MIPI C-PHY Specification v2.1 是 MIPI 联盟于 2021 年正式发布的物理层规范原文面向从事手机、平板、车载摄像头模组与显示驱动开发的硬件工程师、IC 设计者及驱动软件人员。它解决的是设计者需要权威、完整的协议依据以完成链路设计、时序验证与合规调试的问题涉及三级编码、低功耗设计、电气特性、同步定时与错误检测等核心章节适合具备一定 MIPI 基础、希望深入理解 C-PHY 的中高级读者。资源包共 1 个文件为 3.5MB 的 PDF 文档即规范正文本身内容包含版权声明、免责条款及各技术章节可完整检索与标注。目前已有 4394 人学习下载。读者可借此获得官方定义的数据速率、电压摆幅、上升下降时间等参数用于评估 D-PHY 与 C-PHY 的选型差异也可作为 CSI、DSI 接口调试时核对时序与同步机制的依据避免因理解偏差导致实现错误。需注意该规范受 MIPI 会员协议与知识产权条款约束实施前应确认授权范围。1. 三根线跑出 2.3 bitC-PHY 用状态而不是电平承载信息同样一组引脚换一种物理层吞吐能翻一倍多——真正的原因在于每一拍不再只回答「0 还是 1」它转为回答「六选一的下一步走哪」把时钟跑得更快并不能带来同样的收益。C-PHY 的全部设计都从这个转换出发三根线组成一个 trio每根线取高、中、低三个电平之一一个 UI 里定义 5 种符号折算 2.32 bit落到实际映射上是 2.286 bit。搞懂这条链路你才会明白为什么高速率场景要换物理层、为什么三根线接反了还能救回来、为什么眼图漂亮却照样误码。下面从电平讲到符号再讲到时钟恢复与模式切换。2. 三元信号的本质三个电平、六个线态、五种符号2.1 从差分对到三线一组多出来的那根线买了什么差分传输的直觉很深两根线一根高一根低接收端只关心差值共模噪声被减掉。这套逻辑的代价是每根线只承载半个比特——两根线、一个 UI、一个比特。为了让接收端知道什么时候采样还要额外拉一对差分时钟线这对时钟线不管有没有数据都在全速翻转是纯粹的功耗开销。C-PHY 换了另一个思路不用「两根线的差」表示一个比特改用「三根线各自处在哪个电平」表示一个符号。三根线记作 A、B、C每根线可以被驱动到高、中、低三个电平之一并且约束在任意时刻三根线必须分别占住高、中、低——不允许两根同时为高。满足这个约束的排列共 3! 6 种。这就带来两个直接后果。第一电流在组内闭合。任意时刻总有一根线在灌电流、一根在拉电流、第三根停在中点高阻或经端接泄放三根线的电流代数和恒为零。返回电流被锁在这三根线围成的小回路里回路面积小磁通互相抵消地弹和辐射都比「一去一回」的差分对更可控。这是多花一根线买到的第一件东西。第二每个 UI 携带的信息量超过 1 bit。六个线态如果都能自由跳理论上限是 log2(6) ≈ 2.58 bit/UI规范实际用了 5 种符号2.32 bit/UI落到 16 bit → 7 symbol 的映射上有效值是 16/7 ≈ 2.286 bit/UI。把两边的账摊平方案数据线时钟线每 UI 比特数每根线每 UI 比特数D-PHY 四通道824.000.40C-PHY 三个 trio906.860.76引脚数几乎一样10 对 9有效吞吐差了 1.7 倍把 D-PHY 那对从不休息的时钟线也算进「每根线的产出」差距接近 1.9 倍。提升频率要承担更高的功耗和更难的信号完整性代价而加一根线只需要支付一根线的成本——这是选型时最容易算错的一笔账。2.2 六个线态与五个符号为什么「原地不动」被禁止工程上六个线态通常按「哪根线高、哪根线低」记作 x/−x/y/−y/z/−z含义是电流从哪根线流向哪根线线态ABCx高低中−x低高中y中高低−y中低高z低中高−z高中低关键在于规范没有把六个线态直接当成六个符号用而是把「从一个线态跳到另一个线态」这件事本身定义成符号。给定当前线态下一拍可去的线态有六个其中「留在原地」被排除剩下五个正好对应 symbol 0 到 symbol 4。也就是说符号不是绝对电平的编码而是相对上一拍的跳变方向。接收端必须记住上一拍的状态才能反解出符号这在本质上是一次差分译码。为什么禁止原地不动因为 C-PHY 没有独立时钟线接收端的符号时钟只能从线上的跳变里恢复。一旦允许连续两个 UI 保持同一线态这段数据就是一段没有任何边沿的死区PLL 会漂、采样点会滑而这段死区偏偏可能出现在任何位置。排除掉自跳变就等价于给时钟恢复买了一份强制保险。更巧的是任意两个不同的合法线态之间至少有两根线在变import itertools # 三个电平记作 H2, M1, L0合法线态 三根线恰好取遍 {0, 1, 2} STATES list(itertools.permutations((0, 1, 2), 3)) assert len(STATES) 6 def changed(a, b): 从线态 a 跳到线态 b 时发生电平变化的线数 return sum(1 for x, y in zip(a, b) if x ! y) # 每个线态出发的 5 个合法跳变各有几根线在动 for a in STATES: moves sorted(changed(a, b) for b in STATES if b ! a) print(a, moves) # 恒为 [2, 2, 2, 3, 3]输出对所有六个线态都一样五个跳变里三个动两根线、两个动三根线没有「只动一根」的选项。这意味着每个 UI 至少有两条线在跳时钟恢复永远拿得到边沿代价是动态功耗不会因为数据全 0 而降下来——C-PHY 的功耗模型更接近恒定而不是随数据起伏。做功耗预算时如果用「全 0 图样」估平均功耗实测一定会被打脸这是很多人第一次做 C-PHY 时踩的坑。2.3 16 bit → 7 symbol把 2.32 bit 落成整数log2(5) ≈ 2.3219 是个无理数硬件没法直接用它打包数据。规范的做法是把一个 16 bit 字映射成 7 个符号因为 5^7 78125 ≥ 65536 2^16容量足够。32 bit 字则对应 14 个符号。这个选择把有效速率从理论上的 2.3219 压到 2.2857 bit/UI损失约 1.6%换来的是纯组合逻辑就能实现的定长映射。底层的容量关系可以直接验证BASE 5 SYMBOLS_PER_WORD 7 CAP BASE ** SYMBOLS_PER_WORD assert CAP (1 16) print(f5^7 {CAP}, 2^16 {1 16}, 余量 {CAP / (1 16):.3f}x) def to_base5(value, n): 把 16 bit 值拆成 7 个五进制位高位在前 digits [] for _ in range(n): digits.append(value % BASE) value // BASE return digits[::-1] print(to_base5(0x0000, 7)) # [0, 0, 0, 0, 0, 0, 0] print(to_base5(0xFFFF, 7)) # [4, 0, 4, 4, 1, 2, 0]注意这段代码只说明「容量和进制分解成立」不等于规范里的实际映射。规范给出的是一张直接的映射表而不是先转五进制再输出表的设计目标比「能装下」多得多要让符号在时间上分布得足够散避免长串相同符号造成低频能量堆积、要保证任意单 bit 翻转只影响有限个符号、还要让接收端在 Sync 阶段能快速判定极性。常见的实现思路是先用组合逻辑算出候选符号串再用小表做一次置换面积换时序。自己按进制分解硬写一版去对比规范表格你会发现绝大多数码字对不上——这不是实现有 bug是映射表本来就不是算术变换。还有一点常被忽略7 个符号是一个不可分割的「字」接收端必须先完成字对齐才能开始译码。对齐信息不在 payload 里全靠 SoT 之后的同步序列建立。所以 SoT 少采到一个符号后面整段数据会整体错 7 个符号的整数倍——现象是「数据全错但错误率不随电压噪声变化」看起来很像协议层 bug。3. 时钟藏在跳变里嵌入式时钟怎么被恢复出来3.1 没有时钟线采样点从哪来接收端的结构可以粗分成三层模拟前端把三根线各自的电平切成「高于上门限 / 处于窗口内 / 低于下门限」三档所以每根线需要两个比较器一个 trio 就是 6 个比较器6 个比较器的输出组合里只有 6 种是合法线态其余全是非法码可以直接送进错误检测最后一级把「上一线态 当前线态」查表还原成 5 种符号之一。采样时钟由本地 PLL 产生但 PLL 需要一个参考——这就是前面那条「每个 UI 至少两根线在跳」的规则存在的意义。PLL 锁的是符号率不是比特率所以它看到的边沿密度是恒定的这比 D-PHY 里时钟线全速翻转要省得多但也带来一个麻烦跳变的强度不是恒定的。从高跳到中只走半个摆幅从高跳到低走满摆幅从低跳到中也只有半个摆幅。对于一个动两根线的跳变可能是「一满一半」也可能是「两个半幅」。这意味着相邻边沿的到达时间在过零点附近并不一致——弱跳变过门限更晚。规范对符号的分配方式本质上是在控制这种「强弱跳变」的统计分布而接收端的鉴相器如果只按满摆幅的边沿去建模就会在特定数据图样下出现周期性的采样偏移表现为随图样变化的误码换个测试序列就消失了。我一般会这么理解这件事C-PHY 的时钟恢复不是「从时钟线取时钟」而是「从数据里估一个平均跳变时刻」所以它对图样的敏感度比 D-PHY 高一个量级。调试时如果只跑 PRBS 通过就收工上了真实图像数据很可能翻车。3.2 组内 skew 与组间 skew眼图张不开的真正原因三根线在同一组内被当成一个整体但它们终究是三根独立的走线。组内 skew 会直接吃掉一个 UI 里留给采样判决的窗口如果 B 线比 A 线晚了 UI 的 20%那么从 A 和 B 组合出来的线态就在这 20% 的时间里处于「半个旧状态 半个新状态」的中间态6 个比较器可能输出非法码。这条约束的绝对量级很小。以 2.5 Gsps 的符号率算一个 UI 只有 400 psSYMBOL_RATE 2.5e9 # symbol/sUI 的倒数 UI_PS 1 / SYMBOL_RATE * 1e12 print(fUI {UI_PS:.1f} ps) # 400.0 ps # 经验上组内三线的 skew 要压到 UI 的 10% 以内才留得住判决裕量 for ratio in (0.05, 0.10, 0.15): print(fskew budget {ratio:.0%} UI {UI_PS * ratio:.1f} ps)5% 是 20 ps10% 是 40 ps——这个量级已经接近封装内走线加连接器的失配水平PCB 上的等长绕线几乎不起决定作用真正的失配来自封装打线和连接器针脚。所以 C-PHY 对「组内三根线必须同层、同长度、紧耦合走」的要求不是建议是硬指标。组间 skew 是另一回事。多个 trio 并行时接收端要先把它们对齐才能拼成一个字这属于数字侧的弹性缓冲加去偏斜逻辑规范给了对应的时序预算。真正容易出事的是组间和组内混在一起某个 trio 内部没问题但和另一个 trio 差了半个 UI最后表现为「某些通道误码、某些通道正常」很容易被误判成某一颗芯片坏了。3.3 为什么时序参数用 UI 写规范里的可缩放量与不可缩放量翻规范的时序章节会发现一个现象有些参数用 UI 表达有些用 ns 表达还有些是「UI 和时间混着写」。这不是编排随意而是在区分两类物理事实。用 UI 表达的量是「协议时间」——建立保持窗口、同步序列长度、EoT 之后的静默期它们必须随速率等比缩放否则换个速率就全乱了。用 ns 表达的量是「硅时间」——LP 模式的边沿斜率、上电稳定时间、状态机超时它们由晶体管和 RC 决定跟符号率没关系。混合表达的量最容易被误读比如某个参数写成「X UI Y ns」意思是「协议需要 X 个符号的时间但物理上至少还要再等 Y ns」两个条件同时满足才行。做参数核对时我习惯把整张表按这个维度重排一遍先把所有 UI 项按目标符号率换算成 ps再把所有 ns 项原样填进去最后看有没有哪一项在目标速率下变成了负数或者小于工艺抖动。这一步做完很多「跑得起来但余量很薄」的设计会立刻暴露出来。4. 三种工作模式HS、LP、ALP 各自的电平语义4.1 LP 的六状态环为什么 LP-010 和 LP-101 被排除高速模式之外这三根线还要承担控制信令上电、进 HS、退出、低功耗数据、超低功耗态。这些都在 LP 模式下用单端方式跑每根线只有高和低两个电平三根线组合出 8 种可能。规范只用其中 6 种被排除的是「只有中间那根线与其他两根不同」的两种组合可以理解为三线里恰好一根为高、其余为低且为高的是中间那根以及它的补态。原因很实在把允许的 6 个状态按顺序排成 LP-111 → LP-110 → LP-100 → LP-000 → LP-001 → LP-011 → 回到 LP-111构成一个环环上任意相邻两个状态只差一根线。而被排除的那两个状态无论从环上哪个位置过去都至少要同时翻两根线。单根线翻转意味着什么意味着没有「两根线同时换向」造成的瞬时短路风险也没有因为两根线斜率不同而产生的中间非法组合。LP 模式的速率很低十 Mbps 量级边沿本文还有配套的精品资源点击获取
