用set_data_check解决FPGA I2C从机偶发读错问题

1. 问题源头FPGA做I2C从机从设备就是不理你做FPGA开发的人十有八九都被I2C折磨过。尤其当你用FPGA模拟I2C从机或者跟外部EEPROM、传感器、PMIC对接的时候经常会遇到一种特别诡异的现场主机那边说“我发了数据都发出去了”逻辑分析仪抓出来波形也完完整整但设备就是不ACK或者偶尔ACK一下、偶尔又装死。你反复检查波特率、检查地址、检查寄存器配置全都对可问题就是稳定复现不了。我去年做一个电源管理板卡的时候就撞上过这么一出。FPGA做主控外挂一颗I2C接口的PMIC通信速率100kHz按说这速率不算高I2C协议也简单到不能再简单结果PMIC的寄存器读出来时不时就是0xFF。最头疼的是同一个固件在这一块板子上跑得好好的换一块板子就开始出错。后来我把示波器探头焊到SDA和SCL上才终于看到了问题真相——SDA在SCL下降沿之后跳变得太慢了PMIC压根来不及采样。这个问题的本质就是I2C时序里的“数据保持时间data hold time”不满足。而解决它最关键的一招就是FPGA里一个不太起眼的约束命令set_data_check。这篇文章我就用这个真实案例把set_data_check从原理到实战完整拆一遍。你如果是做FPGA逻辑的、或者做嵌入式硬件联调的这篇文章应该能帮你少走很多弯路。2. set_data_check到底是什么它和常规时序约束有什么不同2.1 先搞清楚I2C的时序要求到底是什么I2C协议里数据在SCL高电平期间必须保持稳定只有在SCL低电平期间SDA才能变化。这个“稳定”不是一个模糊的概念协议里写死了两个关键参数建立时间setup time和保持时间hold time。拿标准模式100kHz来说从机对SDA的建立时间要求是最少250ns保持时间要求是0到3.45us之间。快速模式400kHz下建立时间最少100ns保持时间最少0ns、最大0.9us。听起来很简单对不对但在FPGA里实现I2C从机真正让人头疼的不是建立时间而是保持时间。为什么因为FPGA的寄存器输出在时钟沿到来之后数据并不是“瞬间”稳定的从时钟沿到数据真正稳定输出之间有个时钟到输出延时clock-to-output delay简称Tco再加上IOB输入输出块的延迟、PCB走线的延迟SDA实际变化的时间点往往会滞后于SCL下降沿。如果主机是在SCL下降沿之后很快就开始采样下一bit而你这边SDA还没稳定那就直接采错了。换句话说setup时间不够一般可以通过优化逻辑路径、加流水线来解决这是FPGA工程师日常就在做的事但hold时间不满足是数据变化太晚导致的而这恰恰是set_data_check能管的范围。2.2 set_data_check和set_input_delay/set_output_delay的核心区别很多刚接触时序约束的兄弟容易把set_data_check和set_input_delay、set_output_delay搞混。这俩确实长得像但管的根本不是一回事。set_input_delay和set_output_delay管的是时钟沿到数据有效的相对时间关系描述的是“数据相对于时钟边沿提前多少到达”或者“滞后多少到达”。它们约束的是系统级接口的建立时间和保持时间本质上是告诉工具“外部芯片什么时候发数据来”或者“外部芯片什么时候采样数据”。set_data_check则完全不一样。它管的是两个数据信号之间的相对时序关系而不是数据和时钟之间的关系。什么意思就是说set_data_check可以在两个端口、两个寄存器、或者一个端口一个寄存器之间设定一个“数据必须比另一个数据早到多少”或者“必须晚到多少”的约束。在I2C场景下我们关心的就是SDA必须在SCL的某个边沿之前或之后多长时间内保持稳定。SDA和SCL都是数据信号不是时钟所以set_input_delay那套派不上用场必须用set_data_check。2.3 用一个生活化的比喻理解set_data_check你可以把set_data_check想象成两个人交接班A比如SDA必须在B比如SCL下降沿之后的一个采样点到达前把手里的事情做完。set_data_check就是给这个“交接”设定一个最早/最晚时间窗口不能让A太早来、也不能让A太晚走。在Vivado里set_data_check的典型写法长这样set_data_check -from [get_pins {data_path_reg/Q}] \ -to [get_pins {sample_reg/D}] \ -setup 3.0 \ -hold 2.0含义是从data_path_reg/Q到sample_reg/D这条路径上数据到达不能比时钟采样窗口晚超过3nssetup检查数据必须在采样之后继续保持稳定至少2nshold检查。你看到没有这里完全没有提到时钟它约束的是两个数据节点之间的相对到达时间。这就是它区别于普通时序约束的关键。3. 真实案例一块电源板卡上的I2C从机“随机”读错数据3.1 故障现象和初步排查过程说回我那块板卡。硬件架构很简单FPGAArtix-7系列做主控通过I2C总线挂一颗PMICPMIC的I2C地址是0x5E速率100kHz。功能需求是FPGA周期性地读PMIC的电压状态寄存器判断电源是否正常。故障现象是上电自检阶段读回来的寄存器值十次里有七八次是对的但偶尔会出现一次0xFF导致自检误报失败。用串口打印调试信息能明显看到错误是阵发性的毫无规律。我第一反应是I2C总线上拉电阻的问题。查了原理图上拉电阻用的是4.7kΩ对于100kHz的速率、总线电容不大的情况这个阻值是标准的。用示波器量SDA和SCL的波形上升沿、下降沿都挺干净没有明显的振铃说明上拉和总线电容不是元凶。然后我怀疑是FPGA内部逻辑的毛刺。把I2C从机逻辑的RTL代码翻来覆去看了好几遍状态机的跳转、计数器位宽、ACK生成逻辑都检查了没发现问题。用Vivado自带的仿真跑了几千帧数据功能仿真全部正确。这就非常诡异了——仿真没问题说明RTL逻辑功能是对的问题大概率出在物理实现上。这时候我才想到该用set_data_check去检查一下实际布局布线之后的时序报告。3.2 用report_timing_summary定位到真实问题我在Vivado里跑完实现Implementation之后打开时序报告重点看hold timing。因为前面说过setup时间不够在编译阶段大概率就能发现hold问题反而容易藏得很深。果然时序报告里报了一条路径从I2C从机模块的sda_output_regSDA输出寄存器到scl_sync_regSCL同步寄存器的hold violation裕量是-2.1ns。负的裕量意味着这条路径的保持时间确实不够。这个报错信息本身有点反直觉SDA输出寄存器和SCL同步寄存器之间怎么会有一条时序路径原因在于我在RTL里写了这样的逻辑当检测到SCL下降沿时用scl的同步信号作为使能更新SDA输出。综合工具会把scl_sync_reg的输出当作一个数据信号用它去使能sda_output_reg于是就有了这条路径。在100kHz的I2C速率下2.1ns的hold violation听起来不算大但对于PMIC内部那几个纳秒级的采样窗口来说已经足够致命了。3.3 为什么-2.1ns的violation会导致偶发读错这里要解释一下为什么问题是“偶发”的而不是每次必现。FPGA内部的路径延迟并不是一个固定值它受电压、温度的影响会有±10%左右的波动。当芯片工作在低温、高电压的情况下路径延迟会偏小hold裕量可能勉强够用一旦温度升高、电压降低延迟变大hold violation就会显现出来。这就解释了为什么同一份代码在这一块板子上没问题、换一块板子就出问题也解释了为什么同一个板子有时候好有时候坏——你看到的所有随机性底层原因都是物理延迟的波动把hold裕量吃掉了。而且I2C主机在SCL下降沿之后通常经过一小段延时才开始采样SDA。如果主机采样点给得比较晚比如一些MCU的I2C外设会在SCL低电平的中点采样那即便hold时间不太够也可能碰巧能采对。这就让问题更隐蔽因为你不能通过换主机来验证只能在FPGA这边把时序做扎实。4. 用set_data_check一步步修复从约束到验证4.1 确定约束参数怎么算setup和hold的具体数值修复的第一步是明确SDA相对于SCL到底需要满足多大的保持时间。这个数值不是拍拍脑袋定的要从I2C协议和PMIC数据手册两个地方找依据。PMIC数据手册上写得很清楚在标准模式100kHz下从机要求SDA在SCL下降沿之后至少保持0ns、建议保持300ns以上在快速模式400kHz下保持时间最小0ns、最大0.9us。因为我们的设计用了100kHz我决定把保持时间约束设置为500ns——既满足协议要求也留出了充足的裕量。在Vivado里设置这条约束需要先找到SDA输出寄存器和SCL同步寄存器在网表里的实际名字。我打开综合后的原理图定位到I2C模块找到了sda_output_reg的Q引脚和scl_sync_reg的D引脚。然后写下了这条约束set_data_check -from [get_pins {i_i2c_slave/sda_output_reg/Q}] \ -to [get_pins {i_i2c_slave/scl_sync_reg/D}] \ -setup 0.0 \ -hold 500.0这里-setup 0.0表示数据不需要提前到达SDA本来就是在SCL低电平期间变化的-hold 500.0表示SDA在SCL采样沿之后必须保持稳定至少500ns。注意单位是纳秒Vivado默认的时序单位就是ns所以500.0实际上就是500ns。4.2 约束放哪里、怎么写才能被工具正确识别set_data_check这种约束不能随手写在某个不起眼的文件里必须放在正式的XDC约束文件中。我建议单独建一个i2c_timing.xdc然后用source命令在Vivado的约束管理里引入不要把这条约束跟其他管脚约束混在一起方便后期排查。一个常见的坑是XDC文件的执行顺序有讲究。如果你把set_data_check写在create_clock之前工具可能会因为时钟还没定义而报错。稳妥的做法是把set_data_check放在所有create_clock、create_generated_clock之后最好放在文件的后半部分。还有一点在set_data_check之前必须先保证这条路径没有被其他约束伪路径set_false_path覆盖。我之前排查的时候发现工程里有人对scl_sync_reg相关的路径加过set_false_path这就等于告诉工具“这条路径不用检查”set_data_check就白写了。所以加约束之前一定要先确认路径没有被伪路径吞掉。4.3 约束之后的编译结果和时序报告验证加上约束之后重新跑综合和实现再打开时序报告看hold timing结果。这次set_data_check的检查项出现在报告里了而且裕量变成了正数hold slack达到了0.6ns。这个数值说明SDA输出的实际保持时间比要求的500ns多出了0.6ns的余量。虽然余量不算特别大但考虑到100kHz的I2C速率下协议的时序余量本身就很充足这个结果是可以接受的。如果你追求更稳可以把约束的hold值从500ns提到800ns重新编译一次看裕量是否还能保持正数。编译通过之后我把bit文件下载到板卡上连续跑了24小时的压力测试循环读PMIC寄存器上万次没有再出现一次错误。说是“随机”问题最后用一条时序约束就解决了成本几乎为零。4.4 如果约束加完还是报错怎么进一步排查有些情况下set_data_check加完时序报告依然报violation这时候不要急着加大hold值先检查几件事第一确认约束的from和to节点是不是网表里的真实节点。用get_pins拿到的名字必须在综合后的原理图里能对得上如果你写错了引脚名字工具会静默忽略这条约束不出错也不生效。验证方法是在Tcl控制台里输入get_pins -hier *sda_output_reg*看返回列表是否为你期望的节点。第二检查SDA的输出路径上有没有其他组合逻辑。I2C的SDA在FPGA内部通常经过OBUFT三态输出缓冲器再输出到引脚。如果SDA输出寄存器和OBUFT之间还插了其他逻辑实际的路径延迟会比你预期的更大set_data_check的from节点应该选到更靠近输出端的那个寄存器。第三确认你的I2C主机是不是在SCL下降沿之后立刻采样。如果你用的主机采样点特别早即使FPGA这边hold满足500ns主机那边依然会采错。这种场景下set_data_check并不能帮你你需要调整的是FPGA的SDA输出逻辑——比如把SDA变化点提前到SCL下降沿之前一小段时间。5. 从set_data_check出发聊聊I2C时序约束的完整方法论5.1 不只是set_data_checkI2C时序还需要哪些约束写I2C约束的时候新手容易只盯着set_data_check但其实I2C接口在FPGA里需要约束的东西有好几类。我整理了一张清单列一下我实际会做的约束动作约束类型命令示例作用时钟约束create_clock -period 100.0 [get_ports {scl}]定义I2C时钟周期100kHz对应10000nsIO延时输入路径set_input_delay -clock scl_clk -max 100 [get_ports {sda}]约束外部设备向FPGA发送数据的时间窗口IO延时输出路径set_output_delay -clock scl_clk -min 50 [get_ports {sda}]约束FPGA向外部设备输出数据的时间窗口数据检查set_data_check -from [get_pins ...] -to [get_pins ...] -setup 0.0 -hold 500.0约束SDA与SCL节点之间的相对时序说白了set_input_delay和set_output_delay管的是SDA相对于外部时钟的约束而set_data_check管的是SDA与SCL这两个内部节点之间的约束。两者是一个互补的关系不能互相替代。5.2 I2C上拉电阻和逻辑分析仪两个最容易被忽视的变量在做I2C调试的时候set_data_check是软件层面的修复手段但如果硬件本身不配合你写再多约束都白搭。这里分享两个我踩过的硬件坑。第一个坑是上拉电阻的阻值。I2C是开漏输出加外部上拉的结构上拉电阻取值对信号边沿的上升时间影响极大。电阻越大上升沿越缓但功耗越小电阻越小上升沿越陡但总线驱动能力弱的设备可能拉不下去。4.7kΩ是通用值但如果你的总线电容比较大连接设备多、走线长建议用示波器实测一下上升沿时间。经验公式是上升时间约等于0.8473乘以RC如果测出来上升时间超过1us就该考虑把上拉电阻换小比如2.2kΩ或者1kΩ。上升沿太缓会直接影响SDA在SCL高电平期间的稳定采样这是set_data_check救不了的。第二个坑是逻辑分析仪的采样率。很多人在调试I2C时喜欢用逻辑分析仪的I2C协议解码功能但采样率不够的话解码出的波形会“假错”。我曾经用24MHz的逻辑分析仪去抓100kHz的I2C信号解码结果里时不时出现意外的START条件我以为是FPGA逻辑Bug折腾了两天最后发现是逻辑分析仪的采样点刚好落在信号上升沿上导致把毛刺解成了START。换用100MHz采样率之后波形干干净净。所以记住调试I2C时序问题逻辑分析仪的采样率至少要达到信号速率的一百倍以上示波器则要保证带宽足够否则你看到的“问题”不一定是真问题。5.3 常见的I2C时序问题速查表这几年代码评审和现场支持的过程中我积累了不少I2C时序问题的排查经验整理成一个速查表遇到问题可以对着查现象可能原因排查方法解决方向设备完全不ACK地址错误、总线被拉死示波器看SCL/SDA静态电平检查地址位、检查总线是否被设备拉低ACK时好时坏保持时间不够、上拉电阻过大逻辑分析仪抓完整波形比对SDA在SCL高电平期间的稳定性set_data_check加hold约束、减小上拉电阻读回来的数据偶尔跳变建立时间不够、SCL高电平时SDA毛刺放大波形看SCL上升沿附近的SDA状态优化RTL逻辑让SDA只在SCL低电平期间翻转高速模式400kHz下出错总线电容过大、信号边沿过缓测上升沿时间换上拉电阻、减少总线分支、调整PCB走线低温环境下偶发错误路径延迟波动导致hold收敛过紧温度循环测试复现加大hold约束裕量、优化逻辑布局连接多个从机时某个设备异常设备地址冲突、总线驱动能力不足逐一挂载设备排查检查地址配置、添加总线缓冲器5.4 什么时候不要用set_data_check聊完怎么用最后也得说说什么时候别用。set_data_check不是万能的我用它解决了很多问题但也在一些不该用的地方浪费过时间。第一种情况如果你要约束的是SDA和外部时钟SCL之间的关系而不是两个内部数据节点之间的关系那应该用set_input_delay或set_output_delay不要试图用set_data_check去硬套。第二种情况如果你的I2C从机模块里SDA的输出并不是由寄存器直接驱动的而是通过组合逻辑直接输出那么set_data_check能约束的效果会很有限。因为组合逻辑路径没有明确的时序起点和终点工具的优化能力大打折扣。这种情况必须先改RTL把SDA输出改成寄存器输出再谈时序约束。第三种情况如果你的问题根因不在FPGA内部而在外部总线的信号完整性上比如反射、串扰严重set_data_check完全帮不上忙。这类问题要从PCB设计、端接、上拉电阻这些硬件层面去解决别在约束文件里浪费时间。6. 实战心得set_data_check让我少熬夜的几点经验回到这块电源板卡从问题暴露到彻底解决前后花了两天。第一天在反复检查RTL逻辑和硬件电路一无所获第二天想起用set_data_check检查内部路径半小时定位、半小时修复、一晚上验证通过。回头想想如果一开始就按“先检查时序报告、再看硬件”的顺序来第一天就能搞定。这里分享几点我用set_data_check的实际经验算是我熬夜熬出来的教训。第一遇到I2C偶发问题先看时序报告再看代码。很多人的直觉是先怀疑自己的逻辑写错了但FPGA的逻辑错误往往表现为“必现”而时序问题才表现为“偶发”。如果你的问题是十次里错一两次大概率不是逻辑功能问题而是时序裕量问题。先打开Vivado的时序报告搜一下hold timing看有没有负裕量的路径这一步能帮你快速缩小排查范围。第二set_data_check的节点选择优先选寄存器到寄存器不要选端口。选端口做约束当然也可以但端口上的路径延迟受到IOB、PCB走线的影响很大约束值不好把握。寄存器到寄存器的路径是FPGA内部的确定性路径约束值一写一个准。第三约束值不要贴着协议下限去写。I2C标准模式要求hold时间最小为0但如果你按0去写约束工具就认为“只要不是负的就行”这样几乎不提供任何裕量。我习惯把hold约束写到协议要求的三到五倍留出足够的余量这样即使外界环境有波动也不会出问题。第四最好把set_data_check跟普通的IO约束分开管理。I2C的时序约束是个相对独立的部分以后换芯片、换速率的时候只需要改这一个文件。我们现在的做法是把所有I2C的时序约束集中在一个i2c_timing.xdc里每个约束都写清楚注释标明是给哪个I2C实例用的、数值依据来自哪份数据手册的哪一页。半年后再回来看依然能一眼看懂当初为什么这么写。最后再说一个很多人不知道的小技巧Vivado里set_data_check的-from和-to支持使用get_cells或者get_pins的过滤表达式也就是说你可以用通配符同时约束同类的多路信号。如果你的I2C模块被例化了多份每条总线的sda和scl节点命名规则一致可以用一条set_data_check把所有实例的约束一起写了。我一般用get_pins -hier表达式配通配符避免一条条复制粘贴省时省力还不会漏。