★ FEATURED ARTICLE 在Vivado里跑完综合打开实现后的时序报告一眼望去全是红色的violation心里咯噔一下。但冷静下来仔细看路径源点终点全是uart_rx时钟域到axi总线寄存器、以太网RGMII接收时钟域到用户逻辑这类跨异步时钟域的路径——两个时钟根本没有任何频率和相位关系工具却默认把它们当作同步时钟在查建立时间和保持时间几百条违例里九成是这种假违例。这是FPGA时序约束里最经典的场景异步时钟域没有被正确告知工具导致正常功能被误报为时序失败。set_clock_groups这条约束就是为了解决这个问题的。它能在一行命令里把多个异步时钟域之间的路径全部剪断告诉Vivado这些时钟域之间不需要做静态时序分析。但这条命令用起来简单用对它的人却不多。我见过有人把所有不相干的时钟全部塞进一个异步组结果功能正常但上板就是偶发跑飞也见过把同源时钟误设成异步组导致关键路径失去约束设计在高低温下莫名失效。这篇就围绕set_clock_groups在Vivado里的正确用法展开覆盖语法语义、XDC实际写法、验证方法以及我自己踩过的坑。1. 异步时钟域为什么不约束就会满屏违例1.1 跨时钟域路径的核心矛盾数据到达时间无法预测先打个比方。两个时钟之间的关系要么是有确定相位差和频率比的同步关系要么是互不相关、各自独立的异步关系。同步时钟比如同一个MMCM分频出来的100MHz和50MHz它们的上升沿在时间轴上是有固定规律的工具可以精确算出每条路径上一级寄存器输出的数据什么时候到达下一级寄存器从而判断setup/hold是否满足。异步时钟则完全不是这样——两个晶振分别产生两个频率或者两个来自不同接口的恢复时钟上升沿之间的间隔每一次都可能不同。工具能算出的最大可能偏差范围很大在这个范围下几乎所有跨时钟路径都无法满足下一级寄存器的建立时间。于是问题就出来了。整个设计里只要存在一条从时钟域A的寄存器到时钟域B的寄存器的路径而这个路径没有被约束为不需要检查Vivado就会默认对它做全时序分析。如果A和B是异步关系分析结果必然是violation而且是批量出现。1.2 工具为什么会做全路径检查FPGA工具的设计哲学是保守且通用。它不知道你的两个时钟到底有没有关系所以默认所有时钟之间都要检查时序。这保证了一个原始约束文件在大部分设计里不会漏掉真正的时序问题但也意味着工程中只要有异步时钟域工具就会把大量本不需要分析的路径当成同步路径来查。这是设计工具的固有行为不是bug。我们写时序约束本质上是在告诉工具这些路径要查那些路径不要查。set_clock_groups干的就是不要查这件事。1.3 约束的本质圈定分析范围而不是骗工具这里想强调一个很容易被新手误解的点约束不是把违例压掉而是让工具的分析对象更符合设计实际。异步时钟域之间确实存在数据交互但你已经在功能层面用同步器、FIFO、握手协议处理了亚稳态问题。工具能做的静态时序分析在这种交互面前意义有限——它既无法模拟亚稳态的随机性也无法验证你的同步器在任何随机相位下都满足要求。与其让它生成几百条没法看的违例报告不如直接告诉它这些路径不用查把分析精力集中到真正需要保证时序的单时钟域路径、跨同步时钟域的路径、以及IO接口路径上。set_clock_groups的意义就在这里它让时序报告真正反映设计需要关注的点。2. set_clock_groups用起来很简单但语义很容易踩歪2.1 三种互斥类型异步、逻辑互斥、物理互斥set_clock_groups在Vivado里支持三种互斥关系-asynchronous、-logically_exclusive、-physically_exclusive。很多人只见过第一个另外两个其实也在不同场景下很有用先列个表说明选项含义典型场景-asynchronous时钟之间没有确定的相位/频率关系两个外部晶振时钟、恢复时钟、不同接口的独立时钟-logically_exclusive时钟在逻辑上永远不会同时有效经过MUX选择的两条时钟路径实际只会用其中一条-physically_exclusive时钟在物理上不会同时出现在一个管脚上芯片管脚pin在不同模式下复用不同时钟多数工程里大家接触最多的就是-asynchronous。但如果你设计里有类似BUFGMUX做时钟切换的结构那-logically_exclusive是比-asynchronous更准确的表达。Vivado对后两者的分析优化更积极因为它们之间不仅不检查跨时钟路径工具还能在布线、时钟树优化时做得更激进。2.2 一条命令切断的其实是路径而不是个时钟set_clock_groups的语法看起来是把时钟分组set_clock_groups -asynchronous \ -group {clk_a clk_b} \ -group {clk_c}这里的语义是group和group之间的所有跨时钟路径都被切断。注意是所有。一旦你定义了组组A里任何时钟到组B里任何时钟之间的时序路径全部变为false path。这句话要反复琢磨。因为很多人以为只切了指定的那几条路径但实际上它切的是两个组之间所有可能的路径组合。如果你的设计里这些时钟之间恰好存在应该被检查的同步路径那你等于把这条路径的检查也一并干掉了。这也是-allow_paths参数存在的意义。Vivado允许你在组之间保留一部分路径set_clock_groups -asynchronous \ -group {clk_a} \ -group {clk_b} \ -allow_paths {from [get_cells rx_sync_reg] to [get_cells rx_analysis_reg]}意思是组之间总体不检查时序但单独列出的一些路径仍然保留检查。这种写法适合那种大部分路径确实异步、只有个别路径需要特殊保证的设计。不过-allow_paths的匹配语法比较严格用之前一定要先用get_cells确认匹配到的对象是你想要的否则它可能什么都没匹配到还静默不报错。2.3 与set_false_path的适用边界set_clock_groups和set_false_path都可以让某些路径不检查时序但它们的实现思路完全不同。set_false_path是针对特定起点/终点/时钟逐个设置例外set_clock_groups是在时钟组层面统一声明关系。# 用set_false_path表达异步时钟域 set_false_path -from [get_clocks clk_a] -to [get_clocks clk_b] set_false_path -from [get_clocks clk_b] -to [get_clocks clk_a] # 用set_clock_groups表达同样的关系 set_clock_groups -asynchronous \ -group {clk_a} \ -group {clk_b}两者在不让工具检查跨时钟路径这个目标上是一致的。区别在于set_false_path只影响你明确写出的方向和时钟set_clock_groups则是系统性的组间声明。当一个工程有多个异步时钟域、而且后续还要加新时钟时set_clock_groups的维护成本远低于set_false_path。新时钟只要加入对应组所有相关方向路径自动不检查不用担心漏写反方向。但反过来如果你的设计里只有一条路径需要屏蔽其他跨时钟路径反而要查那set_false_path更精准。用set_clock_groups反而会误伤。2.4 滥用会把真实问题遮蔽掉这是我最想提醒的一点。set_clock_groups很有用但用错了会让真正的时序问题被消失。最典型的错误把两个来自同一个MMCM、但频率不同的时钟设成异步组。比如外部输入100MHzMMCM输出一个50MHz的时钟这两个时钟虽然频率不同但它们每N个周期会精确地对齐一次是确定性的同步关系。如果你用set_clock_groups -asynchronous把它们切成异步那么本来应该被计算的跨时钟同步路径全部不分析了——如果这条路径上确实存在setup违例你可能直到样机在高低温下偶发出错才意识到问题。判断两个时钟是否能设成异步唯一的依据是它们的边沿关系是否能够被确定性地计算。同源MMCM/PLL分频出来的时钟、由同一个外部时钟通过BUFG驱动的时钟、通过时钟管理单元得到的固定相位时钟都属于同步关系。只有来源完全不同、没有任何共同参考点的时钟才是真正异步的。3. Vivado里的完整配置过程从查清时钟树到验证生效3.1 先搞清楚你的时钟从哪里来写set_clock_groups之前第一步不是写约束而是打开工程里的时钟网络弄清楚每个时钟的来源。注意XDC里能引用的时钟名称不是你在代码里定义的信号名而是Vivado实际创建出来、在时钟报告中能看到的名字。工程里时钟通常有几个来源外部差分或单端时钟经过IBUF/BUFG进入FPGA这是primary clock。MMCM/PLL输入的时钟经过分频/倍频后产生generated clock。高速收发器的恢复时钟RXOUTCLK由Serdes IP产生。RGMII接口的RX时钟由PHY提供通常只和PHY内部参考时钟相关。在实际工程里我会先打开综合后的工程在Tcl Console执行report_clocks看看当前设计里Vivado认为有哪些时钟。这个列表才是你后面-group里要填的内容填错名字Vivado会直接报找不到对象。3.2 用report_clock_interaction确认异步关系Vivado里有个非常适合查看时钟域交互情况的命令report_clock_interaction。跑完综合后运行report_clock_interaction -delay_type min_max -significant_digits 4GUI会弹出一个Clock Interaction报告每个时钟对之间会显示几种状态。M标识是master时钟关系R表示存在required pathU表示没有路径用户逻辑条数。如果两个时钟之间显示的是N或者完全没有路径那说明Vivado认为这两个时钟域之间不存在需要分析的路径。要把某对时钟设成异步组时先在这个报告里确认它们之间是否存在路径、路径数量有多少、这些路径是否是你预期要屏蔽的。这个步骤能帮你避免以为没路径结果一大把的尴尬。3.3 XDC示例两种常见写法下面给一个完整的示例覆盖三种典型时钟来源# 1. 创建主时钟 create_clock -period 10.000 -name sys_clk [get_ports clk_100m_p] create_clock -period 8.000 -name eth_rx_clk [get_ports phy_rx_clk] # 2. MMCM生成的用户逻辑时钟 # 由约束向导自动创建名称类似 clk_100m_mmcm_out1、clk_100m_mmcm_out2 # 3. 异步时钟分组系统时钟域与以太网PHY恢复时钟域互不相关 set_clock_groups -asynchronous \ -group {sys_clk clk_100m_mmcm_out1 clk_100m_mmcm_out2} \ -group {eth_rx_clk}如果你的工程里还有DDR、PCIe、GT参考时钟同样按来源归组。比如PCIe参考时钟和系统晶振时钟完全无关那就再加一组set_clock_groups -asynchronous \ -group {sys_clk clk_100m_mmcm_out1 clk_100m_mmcm_out2} \ -group {eth_rx_clk} \ -group {pcie_ref_clk}这种写法读起来很清楚三个时钟域分别是系统侧以太网侧PCIe侧组与组之间全部剪断。注意同组内的时钟之间仍然保持同步检查这是符合预期的因为组内时钟通常是同源或经过MMCM统一管理的。写XDC文件时set_clock_groups最好放在create_clock和create_generated_clock之后。因为命令要引用已经存在的时钟对象否则会报clock not found类似的错误。3.4 综合实现后如何确认约束生效约束写完不是结束必须验证它真的生效了。我常用的验证方法有两个。第一重新运行综合或实现打开Timing Summary看WNS和TNS。如果在时序报告里的violation数量明显减少、剩下的违例集中在你真正需要关注的路径上说明异步约束起了作用。第二更直接的办法还是report_clock_interaction。在实现后的工程里重新跑一遍这个报告找到sys_clk和eth_rx_clk这一对正常情况下它们之间应该显示为broken或者直接没有Required Path这一项。这才是set_clock_groups真正生效的标志。另外可以执行report_timing_summary -setup -max_paths 10在报告里搜索eth_rx_clk到sys_clk的路径如果完全搜不到跨这两个时钟域的路径那就说明约束已经正确切断了。3.5 配套的input/output delay不要被异步组误伤这是容易踩的连带问题。假设你有一个外部输入信号跟eth_rx_clk同步你给它设置了set_input_delay -clock eth_rx_clk。结果你把eth_rx_clk和sys_clk设成异步组后如果这个输入信号最终被送进sys_clk域的寄存器那么从IO引脚到sys_clk域寄存器的路径也会被异步组切断工具不再分析这条输入路径的时序。这种情况下你觉得它是不是应该被分析从接口时序角度看外部信号跟eth_rx_clk同步但它进入sys_clk域后已经在内部做过同步处理那从输入引脚到处理器内部同步器的第一级触发器的路径其实仍然需要保证满足setup/hold。异步组一刀切会让这条路径失去约束。解决方式有两种。一是把输入信号路径专门用set_false_path/set_max_delay单独约束绕开时钟组影响二是确保IO约束的时钟设置在同一个时钟组里。具体工程里我会优先检查每个跨时钟域的IO通路确认它们到底需要不需要时序分析需要的话就用target/through对象细化路径级例外不要让异步组误伤接口时序。4. 我实际踩过的坑和排查方法4.1 约束文件里时钟还没定义就写set_clock_groups刚上手时我犯过一个很低级的错误把set_clock_groups写在了create_clock之前。Vivado报错clock object not found还算轻的更麻烦的是有的版本会直接静默跳过这条约束导致异步关系没生效但因为你没看编译日志以为已经设置了。之后我养成了一个习惯写完约束文件后打开Vivado编译日志搜索set_clock_groups确认命令执行行没有WARNING或ERROR。命令行执行完也可以直接看Tcl Console的输出如果命令成功通常不会有任何输出如果有错Console会报红字。4.2 把MMCM同源时钟误设成异步另一个我见过很多次的错误有人看到MMCM输出两个时钟频率不同就顺手把这两个时钟放进了不同的异步组。举个实际例子DDR控制器时钟和用户逻辑时钟都来自同一个MMCM但频率不同——一个是400MHz一个是100MHz。它们之间明明有确定相位关系是同步时钟。如果误设成异步组DDR控制器和用户逻辑之间的路径不会被分析一旦某条路径在布线后真的出现setup违例你也不会在时序报告里看到它。这种问题往往要到高低温验证或者量产阶段才会暴露。更麻烦的是某些IP核在生成时会自动添加set_clock_groups约束。比如Xilinx的Memory Interface Generator、Ethernet IP都可能在XDC里自动声明时钟关系。你的手动约束如果和IP自带的约束冲突可能会产生set_clock_groups overwriten之类的警告。这时就得仔细核对IP产生文件里的时钟分组避免重复或矛盾设置。4.3 多个XDC约束顺序导致set_clock_groups被覆盖Vivado的约束处理顺序是按XDC文件在工程里的添加顺序执行的。如果你在一个XDC里设了set_clock_groups另一个XDC里又对同样的时钟设了false path或者写了不同的时钟组后来者会覆盖前者。我踩过的一个坑是工程里有两个XDC一个是我自己写的时序约束文件另一个是IP自动生成的约束文件。IP生成文件里的set_clock_groups和我的分组不一致加载顺序上IP文件排在我后面导致我的设置被冲掉。排查时通过在Tcl Console运行report_clock_groups才看到最终生效的时钟组和我想的完全不一样。建议做法是全工程统一在同一个XDC文件里管理set_clock_groups不要分散在多个文件里。如果必须分散就要清楚各XDC在Vivado工程中的加载顺序并定期用report_clock_groups检查最终约束状态。4.4 按下葫芦又起瓢异步约束把IO时序也切了之前提到过IO延时被异步组误伤的问题这里补一个完整案例。某个项目里RGMII接口的RX时钟来自PHYFPGA内部把RX时钟作为异步时钟和系统时钟分开。但RGMII的接收数据信号是从PHY来的、与RX时钟同步经过ILA集成逻辑分析仪时我们还要看它的时序。我把RX时钟和系统时钟设成异步组后发现ILA采集到的RGMII数据居然出现了setup违例但时序报告里看不到这条路径的检查——因为异步组把它切掉了。我最后单独对这条路径做set_max_delay约束强制工具分析同时保留时钟组异步关系。这说明了很重要的一点set_clock_groups是粗粒度工具IO和特殊路径的粒度约束可以叠加使用共同保底。5. 约束之外还需要做的CDC设计工作5.1 先说结论约束永远替代不了同步器我很强调一句话set_clock_groups让时序报告干净但绝不等于你的跨时钟设计是安全的。异步时钟域之间传递信号如果没有任何同步处理信号在目标时钟域里可能会触发亚稳态寄存器输出不确定逻辑会随机跑飞。单比特信号比如使能信号、中断信号、复位信号标准的做法是打两拍同步也就是用两级触发器。第一级寄存器可能进入亚稳态经过一个时钟周期后大概率稳定下来第二级寄存器采样到稳定值。这也就是常说的two flip-flop synchronizer。module sync_2ff #(parameter INIT 1b0) ( input wire clk, input wire rst_n, input wire din, output wire dout ); reg sync_a INIT; reg sync_b INIT; always (posedge clk or negedge rst_n) begin if (!rst_n) begin sync_a INIT; sync_b INIT; end else begin sync_a din; sync_b sync_a; end end assign dout sync_b; endmodule这段代码看起来很简单但有一个细节两级触发器必须放在同一个时钟域里且它们之间最好只隔很短布线距离。有些工具甚至建议在综合时通过属性让两个触发器放得尽量近以减少第一级到第二级之间信号受干扰的概率。5.2 多位数据跨时钟域FIFO和握手是正路多位数据总线直接穿过异步时钟域比如从100MHz域送一个8位计数器到50MHz域如果每个bit都用打两拍同步器那数据将在不同时间到达目标寄存器会采到一个完全错乱的中间值。这种场景必须用更结构化的方式。第一个方案是异步FIFO。把数据在源时钟域写入FIFO在目标时钟域读出读写指针用格雷码跨域同步这样数据本身保持完整控制信号的安全性由格雷码打包保证。Xilinx的FIFO Generator IP以及XPM库里的xpm_fifo_async都能直接生成带正确同步逻辑的异步FIFO。第二个方案是握手协议。源时钟域把数据准备好后拉高request信号目标时钟域经过两级同步采样到request后锁存数据并回ack源域采样到ack后撤销request。这套协议能保证数据在不确定的源/目的相位关系下不丢不重但延迟会明显增大吞吐量也远低于FIFO。选择FIFO还是握手主要看数据通路的吞吐需求。高吞吐、连续数据流用FIFO低频、单次事件型控制数据用握手就够了。5.3 用XPM_CDC简化同步器的管理Vivado提供了一套现成的跨时钟域原语XPM_CDC库里面包含常用的CDC组件。它们的存在感有时不如IP核高但配合时序约束非常好用。比如xpm_cdc_single是单比特同步器xpm_cdc_array_single把多个单比特同步器打包成数组xpm_cdc_handshake实现了完整的握手跨时钟传输xpm_cdc_async_fifo则是异步FIFO的CDC封装。用这些原语的好处是不必手写同步器而且它们经过Xilinx官方验证配合约束工具能清晰地识别出CDC边界。# 在XCI或RTL中实例化xpm_cdc_single后 # 配合set_clock_groups把源时钟和目标时钟设为异步组 # 工具就能自动识别该CDC单元是合法的跨时钟路径 # 其余没有经过CDC单元的跨时钟路径则会被标记为异常。这样set_clock_groups从切断所有跨时钟路径变成了切断除CDC单元之外的所有跨时钟路径设计的安全性和可维护性都会好很多。不过这只在标准时序工具流程里有效如果你用了第三方综合工具对XPM原语的支持程度就要另外评估。5.4 约束和CDC设计一起评审才靠谱最后提供一个项目实践上的建议把set_clock_groups的约束文件当作硬件设计的一部分来做评审而不只是在后端阶段补一补。我通常的做法是每个时钟域先列一张表格记录它的来源、频率、和哪个时钟域有数据交互、交互用的什么同步机制。表里的来源列为真正的异步时钟来源就作为set_clock_groups分组的依据交互机制列里的同步器/异步FIFO就是后续功能审查的重点。这张表同时驱动约束编写和代码Review两边都不容易漏。比如我的RGMII工程里就有一张这样的表系统时钟sys_clk和以太网接收时钟eth_rx_clk之间有一条RX data通路用异步FIFO隔离RX控制信号用xpm_cdc_single做同步两者互不相关在set_clock_groups里分属两组。而sys_clk和MMCM产生的内部时钟属于同步时钟不做异步处理。这样每一条约束背后都有一个设计条目支撑而不是凭空拍脑袋。再说个我自己的心得收尾。set_clock_groups是个一把梭的工具它能一口气让时序报告变干净但也让你对设计的真实时序产生一种虚假的安全感。我现在每写一条时钟组约束都会反问自己三个问题这两个时钟真的没有任何确定性关系吗它们之间存在的每一条路径都有对应的同步机制吗如果哪天工具没做检查全凭设计逻辑保证我敢不敢直接Release版本能把这几个问题都答清楚set_clock_groups对你来说就不是一条语法而是一整套异步时钟域设计的底气。
阅读完成 · 觉得有帮助？
