第四章：协议检测与识别：硬件握手检测、协议特征码识别、时序窗口采样法

各位同学，今天我们来聊聊多协议接口里最核心的一环——协议检测与识别。

说白了，就是你的芯片得能“看懂”对方发过来的是什么协议。是I2C？是SPI？还是UART？如果连这个都搞不清楚，后面的切换和复用就无从谈起。

我个人习惯把协议识别分成三个层次：硬件握手检测、协议特征码识别、时序窗口采样法。咱们一个一个来拆解。

4.1 硬件握手检测：最直接的“打招呼”

硬件握手，说白了就是物理层上的信号交互。比如RS232的RTS/CTS，或者I2C的SCL/SDA在空闲时的状态。

我在项目中遇到过一种情况：两个设备对接，一方以为对方是SPI，另一方却按UART的时序在发数据。结果呢？总线直接乱掉。后来我加了一个简单的握手检测模块，先看空闲状态下的电平，再判断起始条件。

举个例子，I2C协议在空闲时，SCL和SDA都是高电平。而SPI的CS在空闲时是高电平，但SCK可能是低也可能是高，取决于CPOL配置。你想想看，如果一上电就检测到SDA被拉低，那大概率是I2C的起始条件来了。

核心思路：利用物理层信号的静态特征，快速排除不可能选项。

硬件握手检测的典型流程是这样的：

  1. 上电后，等待总线空闲超过一定时间（比如100us）
  2. 采样各信号线的静态电平
  3. 与已知协议的空闲状态做匹配
  4. 如果匹配成功，进入该协议的接收状态机

嗯，这里要注意：硬件握手检测不能太敏感。我曾经吃过这个亏——总线上的一个毛刺，让检测模块误判成I2C起始条件，结果整个系统跑飞了。后来我加了一个去抖计数器，连续采样3次都满足条件才确认。

避坑指南：我曾经因为握手检测阈值设得太低，导致在噪声环境下频繁误切换。建议至少做3次连续采样确认，或者用数字滤波器。

4.2 协议特征码识别：看“身份证”

硬件握手只能做初步筛选，真正要确定协议，还得靠特征码。每个协议都有自己独特的“身份证”——比如I2C的7位设备地址、SPI的命令字节、UART的起始位+数据位格式。

我个人习惯把特征码识别分成两类：

  • 固定特征码：比如I2C的起始条件（SCL高时SDA下降沿），这是协议规范里写死的，不会变。
  • 动态特征码：比如某些私有协议在数据包开头加一个0xAA或0x55作为同步头，这个是可以配置的。

来看一个简单的Verilog代码示例，检测I2C起始条件：

// I2C起始条件检测
// 检测SCL为高时，SDA的下降沿
reg sda_d1, sda_d2;
wire sda_falling;
wire start_detected;

always @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
        sda_d1 <= 1'b1;
        sda_d2 <= 1'b1;
    end else begin
        sda_d1 <= sda;
        sda_d2 <= sda_d1;
    end
end

assign sda_falling = sda_d2 & !sda_d1;
assign start_detected = scl & sda_falling;

你想想看，这个检测逻辑其实很简单，但很实用。我在一个项目里用这个模块同时检测了I2C和SMBus的起始条件，两者的区别只在于时序参数不同。

小技巧：特征码识别建议用状态机实现，每个协议一个状态。这样扩展起来很方便，加一个新协议只需要加一个状态和对应的特征码表。

4.3 时序窗口采样法：用时间说话

有些协议，光看特征码还不够。比如同样是UART，波特率可能是9600，也可能是115200。这时候就需要时序窗口采样法了。

说白了，就是在一个时间窗口内，采样信号的变化次数，然后反推出时钟频率或波特率。

我记得有一次调试一个多协议芯片，对方设备说支持I2C和SMBus，但就是不告诉我具体用哪个。我打开示波器一看，SCL的时钟频率是100kHz——嗯，标准I2C模式。如果是SMBus，时钟频率会低一些，而且有超时检测。

时序窗口采样法的实现思路：

  1. 设定一个固定长度的时间窗口（比如1ms）
  2. 在这个窗口内，计数时钟信号的上升沿个数
  3. 根据计数值判断时钟频率范围
  4. 匹配到对应的协议速率模式

来看一个更完整的例子，检测SPI的时钟极性（CPOL）和相位（CPHA）：

// SPI模式检测：通过采样CS和SCK的时序关系
// 在CS下降沿之后，采样第一个SCK边沿
reg [3:0] sample_cnt;
reg [1:0] spi_mode;

always @(posedge clk) begin
    if (cs_falling) begin
        sample_cnt <= 4'd0;
        spi_mode <= 2'b00;
    end else if (sample_cnt < 4'd8) begin
        // 在CS有效后，采样SCK的状态
        if (sck_posedge) begin
            // CPHA=0时，第一个SCK上升沿采样数据
            // CPHA=1时，第一个SCK上升沿是移位
            spi_mode[1] <= 1'b1;  // 检测到CPHA=1
        end
        if (sck_negedge) begin
            spi_mode[0] <= sck;   // 检测CPOL
        end
        sample_cnt <= sample_cnt + 1;
    end
end

这个代码在实际项目中跑过，能准确识别SPI Mode 0~3。不过要注意，时序窗口的长度要留够余量。我曾经因为窗口设得太短，导致低速设备的数据没采全，识别结果总是出错。

经验之谈：时序窗口采样法最适合用在协议速率差异较大的场景。比如I2C的标准模式（100kHz）和高速模式（3.4MHz），用窗口法一测一个准。但如果两个协议的速率很接近，那就得结合特征码一起判断了。

4.4 三种方法的协同工作

在实际的多协议接口芯片里，这三种方法不是孤立的，而是协同工作的。我一般这样安排优先级：

检测阶段 方法 耗时 准确率
第一阶段 硬件握手检测 < 1ms 60%
第二阶段 协议特征码识别 1~10ms 90%
第三阶段 时序窗口采样法 10~100ms 99%

你看这个表格，第一阶段最快但准确率最低，只能排除明显不对的协议。第二阶段看特征码，能锁定大部分协议。第三阶段最慢但最准，用来做最终确认。

为什么会这样设计？说白了就是速度和精度的权衡。你想想看，如果每次上电都花100ms去做时序采样，用户肯定受不了。但如果你只靠握手检测就切换协议，又容易误判。

我的建议：在芯片上电后的前1ms内，只做硬件握手检测。如果匹配成功，立即进入该协议的接收模式。同时，在后台继续做特征码和时序验证。如果发现不匹配，再回退到检测状态。这样既保证了响应速度，又不会误判。

好了，这一章的内容就到这里。协议检测与识别，说白了就是让芯片学会“察言观色”。硬件握手是看脸色，特征码是看身份证，时序窗口是看行为习惯。三者结合，基本能覆盖90%以上的多协议场景。

下一章我们会讲协议切换的仲裁机制——当多个协议同时请求总线时，谁说了算？到时候见。

← 上一章 📖 返回目录 下一章 →