3. Sensor接口协议与RTL实现：MIPI CSI-2协议解析

好，咱们进入第三章。Sensor接口这块，说白了就是摄像头和AI ISP芯片之间的“高速公路”。MIPI CSI-2是目前最主流的协议，没有之一。我这些年经手的项目，从手机摄像头到车载环视，几乎全是它。今天咱们就把它的RTL实现要点掰开揉碎了讲清楚。

3.1 D-PHY与C-PHY：物理层的两种选择

MIPI物理层主要有两种：D-PHY和C-PHY。很多刚入行的同学容易混淆，其实它们解决的是同一个问题——高速传输，但方式完全不同。

D-PHY 是我用得最多的。它的结构很清晰：每个lane是一对差分线，外加一个独立的时钟lane。RTL实现时，你只需要关注DDR（双沿采样）和LP（低功耗）/HS（高速）模式切换。

C-PHY 呢？它没有时钟lane，时钟信息通过三线之间的电平跳变来编码。好处是节省了引脚，坏处是RTL解串逻辑复杂不少。我记得有个项目为了省PCB走线空间选了C-PHY，结果RTL调试花了两周——每次状态跳变都要精确对齐三个信号的边沿。

3.2 Lane管理：从1到4的伸缩艺术

CSI-2支持1、2、3、4条数据Lane。Lane管理模块的核心任务就是：把Sensor发来的数据均匀分配到各条Lane上，再在接收端重新拼回去。

这里有个关键概念——Lane Distribution。发送端会把数据按字节拆开，轮流分配给各条Lane。比如4-Lane模式下，Byte0走Lane0，Byte1走Lane1，Byte2走Lane2，Byte3走Lane3，然后Byte4又走Lane0，以此类推。

RTL实现时，我习惯用一个简单的状态机来控制Lane对齐：

// Lane对齐状态机（简化版）
typedef enum logic [1:0] {
    IDLE,       // 等待SoT（Start of Transmission）
    SYNC,       // 同步各Lane的字节边界
    DATA        // 正常接收数据
} lane_state_t;

always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
        lane_state <= IDLE;
    end else begin
        case (lane_state)
            IDLE: begin
                if (sot_detected) lane_state <= SYNC;
            end
            SYNC: begin
                // 等待所有Lane的同步头对齐
                if (all_lanes_synced) lane_state <= DATA;
            end
            DATA: begin
                if (eot_detected) lane_state <= IDLE;
            end
        endcase
    end
end

3.3 PPI接口设计：PHY与Controller的桥梁

PPI（PHY-Protocol Interface）是MIPI定义的标准接口，连接物理层（PHY）和协议层（Controller）。说白了，PHY负责把模拟信号转成数字比特流，Controller负责解析这些比特流里的协议内容。

PPI接口的信号不多，但时序要求严格。核心信号包括：

• clk_p / clk_n：DDR时钟，频率是数据速率的一半
• data_en：数据有效标志
• data[7:0]：每个时钟周期采到的8位数据
• hs_sync：高速传输同步信号

RTL设计时，我建议把PPI接口单独封装成一个模块。这样做的好处是：换PHY厂商时，只需要改这个模块的适配逻辑，Controller核心不用动。

3.4 数据打包与解包：从比特流到图像帧

CSI-2的数据格式是分层的。从外到内依次是：帧（Frame）→ 行（Line）→ 包（Packet）。每个包又分为包头（Header）、数据负载（Payload）和包尾（Footer）。

打包过程（发送端）：

1. Sensor采集一行像素数据
2. 加上包头（包含数据类型、虚拟通道号、数据长度）
3. 按Lane数拆分字节，发送到各条Lane
4. 包尾加上CRC校验（可选）

解包过程（接收端）：

1. 从各Lane收集字节，重新组合成包
2. 解析包头，提取数据类型和长度
3. 根据数据类型，把负载数据送到对应的处理模块（RAW、YUV、JPEG等）
4. 校验CRC，如果出错则标记坏帧

RTL实现时，解包模块的状态机大概是这样的：

// 解包状态机
typedef enum logic [2:0] {
    WAIT_SOT,       // 等待Start of Transmission
    HEADER,         // 接收4字节包头
    PAYLOAD,        // 接收数据负载
    CRC,            // 接收2字节CRC
    WAIT_EOT        // 等待End of Transmission
} unpack_state_t;

always_ff @(posedge clk) begin
    case (unpack_state)
        WAIT_SOT: begin
            if (sot_valid) unpack_state <= HEADER;
        end
        HEADER: begin
            if (byte_count == 4) begin
                // 解析出payload_length
                unpack_state <= PAYLOAD;
            end
        end
        PAYLOAD: begin
            if (byte_count == payload_length) begin
                unpack_state <= CRC;
            end
        end
        CRC: begin
            // 校验，2字节
            unpack_state <= WAIT_EOT;
        end
        WAIT_EOT: begin
            if (eot_valid) unpack_state <= WAIT_SOT;
        end
    endcase
end

3.5 核心知识体系：一张图看懂

下面这张SVG图总结了本章的核心逻辑。从Sensor到AI ISP芯片，数据是怎么一路流过来的。

3.6 常见问题与调试技巧

最后，分享几个我在项目中踩过的坑，希望能帮你少走弯路。

• 问题1：图像有竖条纹——通常是Lane分配顺序错了。检查Sensor的Lane映射配置和RTL里的分配逻辑是否一致。
• 问题2：图像颜色不对——可能是数据类型解析错了。比如Sensor输出的是RAW10，但RTL按RAW8解析，每个像素少2bit，颜色自然不对。
• 问题3：偶尔丢帧——大概率是FIFO深度不够。Sensor的帧率波动时，FIFO溢出导致丢帧。我一般把FIFO深度设为最大行长度的1.5倍。

嗯，MIPI CSI-2这部分就讲到这里。内容不少，但核心就三件事：物理层选型、Lane对齐、协议解析。把这三点吃透了，Sensor接口这块基本就稳了。