电路板玩家2023楼上两位说得都对，我补充点实际调试的坑。首先，时钟拉伸检测一定要用异步电路吗？不，我建议同步化处理。用你的主时钟去采样SCL线，然后边沿检测。但采样频率得够高，至少是SCL的几倍，否则可能错过从机的短时拉伸。其次，仲裁失败后的处理，协议要求主机必须立即停止发送，并转为接收。但你的状态机可能正在‘发送数据’状态，这时候要强行跳到一个‘仲裁失败’状态，这个状态要完成释放SDA、监听总线、可能还要发重复起始条件。代码里if else会变得很复杂。我的建议是，先做一个不支持仲裁的版本，调通。然后再单独加一个仲裁模块，用条件编译隔开。这样出问题了也好定位。最后，仿真时一定要把SDA和SCL的线模型（用wire类型，有多驱动）建好，不能只用自己的驱动值。可以用force/release来模拟从机和其他主机的行为。
从状态机设计角度说说吧。我的I2C Master状态机大概分：起始、发送地址、应答检测、数据发送/接收、停止。时钟拉伸的处理要嵌入到每个需要等待SCL高的环节。比如发送完一个bit后，不是直接跳下一个bit，而是先进入一个‘检查SCL是否释放’的子状态。这里的关键是，你的状态转移条件不能只看内部计数器，要加上‘SCL_actual == 1’这个外部输入（SCL_actual是读取到的总线实际值）。仲裁的实现，本质是在发送每一位时（特别是地址和数据），同时去读SDA总线，比较自己发送的值和总线上实际的值。如果发现不一样，说明有更高优先级的主机在发送，就应该立即释放总线，转入监听模式。易错点是仲裁失败后，要记得把自己切换为从机模式，并重置状态机，很多人这里状态没清干净。调试时一定要用仿真，模拟从机拉低SCL和另一个主机发不同数据的情况。
I2C的时钟拉伸其实挺简单的，就是SCL被从机拉低后，主机要等着它释放。关键点在于你的SCL生成逻辑不能是简单的计数器翻转，而应该是一个状态机控制的‘请求-释放’机制。我一般会设计一个‘SCL高电平等待’状态，当检测到SCL被外部拉低（即你输出为1但读回为0）时，就进入这个状态，直到读回为1再继续。易错点是用三态门控制SCL时，忘记做输入反馈，直接用自己的输出做判断，那就永远检测不到从机的拉低了。仲裁的话，我建议先别做，单主系统够用了，多主太复杂，涉及到总线监控和冲突后退，对新手不友好。
分享点实际调试踩过的坑。1. 时钟拉伸检测的时机要对，一定要在 Master 释放 SCL 之后再去读，读的是 inout 端口配置为输入时的值。用 Verilog 写，要注意三态门的控制逻辑，别弄反了。2. 仲裁逻辑里，比较‘自己发出的数据’和‘实际总线数据’是否相等，这个比较要在 SCL 高电平的中间或靠后阶段进行，避开上升沿可能的不稳定期。3. 易忽略的点：仲裁可能发生在地址阶段或数据阶段，甚至ACK位。所以你的比较逻辑要覆盖所有 Master 驱动 SDA 输出的时刻。4. 状态机设计上，处理完仲裁丢失或拉伸等待后，一定要能干净地回到空闲或某个已知状态，别卡住。建议先单独仿真测试拉伸和仲裁场景，用 testbench 模拟一个拉低 SCL 的从设备和一个竞争的主设备，看看你的控制器反应对不对。
从状态机划分角度聊聊。I2C Master 的状态机可以分成顶层状态（如 IDLE, START, ADDR, DATA, STOP）和每个位传输的子状态。处理时钟拉伸时，我建议在发送或接收每个数据位的‘SCL高电平’阶段，插入一个子状态。比如，在‘SCL_HIGH’状态后，不是直接转到‘SCL_LOW’，而是先转到‘STRETCH_CHK’状态。在这个状态里，判断 SCL 引脚输入是否为1，如果是，说明没有拉伸，继续；如果不是，就循环等待。仲裁的实现，则是在输出每一位（通常是SDA）后，在SCL高期间，比较输出和输入。这可以放在‘SCL_HIGH’状态里完成。如果发现仲裁丢失，状态机应跳转到一个明确的‘ARB_LOST’状态，执行释放总线和错误处理。调试时，用逻辑分析仪抓 SCL 和 SDA 波形看时序最直观。
时钟拉伸这块，我当初也卡了很久。关键点在于 Master 必须持续检测 SCL 线是否为低，而不是一味地输出自己的时钟。我的做法是在状态机里加一个专门的‘等待拉伸’状态。当 Master 把 SCL 驱动为高后，立刻将 SCL 输出改为高阻态（或者读回引脚状态），然后去检测实际的 SCL 线电平。如果检测到为低，就进入等待状态，直到它变高再继续。易错点是忘记把输出改为高阻，导致和 Slave 的驱动冲突，或者检测逻辑没写好，形成死循环。仲裁的话，我那个入门项目没做多主，但原理是发送每一位时，都要回读 SDA 线，比较自己发出的和实际的是否一致。如果不一致，说明有其他主设备赢了仲裁，自己要立刻释放总线，转入从机模式或等待。
