企业官网建设流程全解析

这段时间调DDR3读写，工程综合之后跑到Implementation，眼看着进度条都快拉满了，突然弹出来一个“[opt31-67]”开头的报错。起初以为只是某个时序警告，结果直接卡死在opt_design阶段，整晚都在跟这个错误搏斗。翻了日志、查了XDC、重新生成过MIG核，折腾到最后发现，问题其实出在一个非常容易被忽略的时钟连接细节上。今天把整个排查过程从头到尾梳理一遍，给还在被这个报错折磨的朋友一条完整可复现的修复路径。

这个错误在MIG IP核的调试里出现频率极高，尤其是从旧版Vivado迁移到新版本、或者换板子改DDR颗粒时最容易触发。它不是语法错误，也不是简单的逻辑错误，本质上是在综合后的优化阶段，工具发现DDR控制器内部有某个时钟节点无法被正常解析和连接。懂了这个底层逻辑，后面的排查方向就清晰了：不是去改代码修逻辑，而是把MIG核相关的那条时钟链路一截一截地捋干净。

1. 先搞清楚opt31-67到底在报告什么

1.1 这个错误发生在哪一步

注意看报错出现的时机。Vivado的流程是先Synthesis再Implementation，而opt31-67这个编号，中间的“opt”指的就是Implementation阶段最前面的logic optimization。也就是说，Synthesis阶段能过、能生成网表，但到了opt_design这一步，工具在尝试对设计做时序优化和结构重组时，发现某个寄存器的时钟端没有驱动源，或者某个MMCM/PLL的输入时钟不合法，于是整个流程戛然而止。

我最初犯的错误就是看到是“综合报错”就一头扎进综合设置里改参数，实际完全跑偏了。这类错误在任何版本的Vivado里都有可能出现，表现形式略有差异，但核心都是时钟树链路里存在断点。常见的报错文本会带有类似“cannot be connected to a valid clock source”或“no valid clock input”的描述，用词会因为IP版本不同稍有变化，但指向的是同一个问题。

1.2 为什么MIG核最容易触发这个错误

MIG核是Xilinx官方提供的一个非常庞大的IP核，它内部封装的不仅仅是DDR控制逻辑，还有物理层延时校准、时钟生成、复位同步、用户接口时序逻辑等等。最要命的是，MIG对时钟的要求极其苛刻，它既依赖外部输入的系统时钟，又需要内部MMCM/PLL产生不同频率的时钟域，还要IDELAYCTRL提供精确的延时参考。

这么多时钟域交错在一起，任何一个节点没有被正确驱动，opt阶段就没法给相关寄存器摆出合理的时钟树，自然报连接性错误。MIG核本身是一个黑盒子，用户能控制的只有导出到顶层的那几个端口，而恰恰是这些端口的连接和约束，是最容易出问题的地方。

1.3 先做一个快速判断：你的错误属于哪一类

我根据自己的经验，把opt31-67相关的实际问题分成了四类。先对照一下自己是哪一类，能省掉大量盲目排查时间：

• 第一类：顶层没有正确例化差分时钟的IBUFDS，导致sys_clk_p/n信号悬空；
• 第二类：XDC约束里时钟引脚没有绑到专用时钟引脚上，工具无法把时钟信号引入全局时钟网络；
• 第三类：MIG配置向导里填写的外部输入频率与实际板卡晶振不一致，导致PLL参数直接超出合法范围；
• 第四类：用户逻辑里把MIG的ui_clk、ui_clk_sync_rst等信号误接到了不合理的逻辑上，导致优化时时钟树被拆散。

绝大多数情况下，前三类占了问题的九成以上。我自己这次踩的就是第二类和第三类叠加起来的一个坑，后面细讲。

2. 排查之前的准备工作：别急着动手改

2.1 三分钟定位报错细节的正确姿势

接到这个报错，先不要急着打开代码找bug，也别立刻去重新定制MIG核。第一步永远是看完整的Message窗口记录。在Vivado界面下方Messages窗口里，把视图从“Errors”切到“All Messages”，然后定位到OPT_DESIGN这个阶段的条目，逐条看。很多时候，错误之前还会跟着几条WARNING和CRITICAL WARNING，这几条往往是更早暴露出来的root cause。

另外一个技巧：在Tcl Console里运行report_qor_suggestions，也能在报错密集的时候给出一些结构性建议。不过最直接的还是看log文件，在Run目录下找到runme.log，搜索“opt31-67”这个关键字，往前倒着翻个几百行，基本能把报错时的上下文看得明明白白。

2.2 打开综合后的设计看Schematic

这个被人忽视的步骤，反而是我修复这次问题的关键突破口。在工具栏选择“Open Synthesized Design”，等网表完全加载后，点击Schematic图标，然后在原理图里手动定位到MIG核的顶层实例。具体方法是按Ctrl+F搜索MIG的实例名（默认一般叫u_ddr3或者mig_7series_0），按下回车后，原理图视图会自动跳转到对应的模块上。

这个时候重点看三类信号：

• 外部的系统时钟输入端口有没有连过来；
• 内部MMCM的输入时钟有没有从IBUFG/IBUFDS引出；
• IDELAYCTRL的参考时钟引脚是不是悬空的。

悬空的引脚在Schematic里会显示成没有net连接的小圆点，一眼就能看出来。这个方法其实比用代码检查快得多，也直观得多。如果发现MIG核的sys_clk或ref_clk引脚确实有连接，但连接的却是一个普通逻辑信号而非时钟网络，问题也找到了。

2.3 重新审视MIG IP配置向导里的时钟选项

如果Schematic里看连接没什么明显异常，那就得回到源头，检查一下MIG配置向导里这些选项到底是怎么设置的。很多朋友在定制MIG核的时候，注意力全放在DDR型号、速率等级和地址位宽上，时钟这一页基本都是直接点Next跳过的，这其实埋了大隐患。

MIG配置向导中有几个关键选项会直接影响后续的连接：

• System Clock类型，究竟是差分的还是单端的，这个必须和板卡的硬件设计严格一致；
• System Clock频率，这个频率不是DDR的工作频率，而是输入给MIG的参考时钟频率，通常是100MHz或200MHz；
• 参考时钟选项，有的DDR接口还需要单独的参考时钟源；
• 内部的PLL或MMCM使用方式。

我建议无论当前问题是否出在这，都把最近一次导出的MIG核配置对照板卡原理图重新走一遍。如果硬件上用的是单端100MHz晶振，MIG配置里却选了“Differential”，后面几乎必然会出现连接性错误。

3. 系统性排查链路：从外部晶振到用户接口的每一环

3.1 第一环：外部时钟引脚与IBUFDS/IBUFG的配合

DDR设计里，绝大多数板卡都采用差分晶振给FPGA提供输入时钟。MIG核的sys_clk_p/sys_clk_n端口就是为这个设计的，但问题在于，Vivado里差分时钟输入必须通过原语IBUFDS（或者IP核自带的时钟缓冲处理）连接到内部时钟网络，如果顶层文件里只简单地把sys_clk_p和sys_clk_n接到一个普通寄存器或者干脆没接，那么时钟网络就断在源头，后面再怎么处理都是白搭。

这里有个需要注意的细节：MIG核内部其实已经包含了对应的输入缓冲，但你如果选择让MIG内核自己去处理时钟输入，那么顶层就不该再手动添加IBUFDS，否则会出现双重缓冲，虽然多数情况下能正常工作，但有时会引发PLL输入时钟来源的解析歧义。具体使用哪种方式，取决于你在MIG配置向导的“System Clock”页面里选的是“Different”还是“Single Ended”，以及选用的是“Use System Clock”还是“No Buffer”之类的选项。不同版本向导的文字描述略有差异，原则就是：向导怎么选，顶层就怎么连，不要两边一套方案。

3.2 第二环：MMCM/PLL输入频率范围与DDR速率的匹配

MIG核里面会例化若干个MMCM或PLL，用来把输入时钟倍频/分频成DDR物理层需要的各种频率。比如DDR3-1600，物理层时钟通常需要800MHz，而内部UI时钟是400MHz，控制时钟又是200MHz。这些频率全部是由输入参考时钟经过MMCM/PLL计算出来的。

如果配置向导中填写的输入时钟频率和实际板卡晶振频率不一致，MMCM/PLL计算出来的倍频系数要么超出支持范围，要么在理论上有解但布局布线后无法满足。这种情况下，Synthesis阶段通常不报错，因为综合只是生成代码，不会对MMCM的物理可实现性做深度校验，到了opt_design阶段检查时钟网络时才彻底暴露。

排查这个环节时，可以在Tcl Console里运行：

get_cells -hier -filter {PRIMITIVE_TYPE =~ *.mmcm* || PRIMITIVE_TYPE =~ *.PLL*}

拿到所有MMCM/PLL实例列表后，再运行get_property REF_CLK_FREQ [get_cells ...]查看其参考时钟频率配置，确认是否与板卡输入一致。这个方法比单纯看图形界面准得多。

3.3 第三环：IDELAYCTRL参考时钟和BUFG资源

DDR控制器对输入延时控制极其依赖IDELAYCTRL模块，而IDELAYCTRL必须有一个参考时钟，这个参考时钟通常也是由内部时钟缓冲网络BUFG驱动的。如果IDELAYCTRL的参考时钟没有被正确生成，或者被优化掉了，opt阶段就会报告相关连接性错误。

有一种隐蔽情况是：MIG核可以配置为自动管理IDELAYCTRL，也可以配置为让你从外部提供参考时钟。后者的情况下，如果顶层没有单独例化IDELAYCTRL原语，或没有把参考时钟连接到MIG指定端口，这个断点就会在优化阶段爆炸。我在最早期的调试里就犯过这个错，以为MIG核全都自己搞定了，结果打开Schematic一看，IDELAYCTRL的ref_clk端口挂着个默认值，没拿到真实时钟。

另外，全局时钟缓冲BUFG使用数量也要注意。FPGA的BUFG资源是有限的（7系列一般是32个），MIG核自身就会消耗好几个BUFG。如果你的设计里其他逻辑也大量使用了BUFG，导致MIG内部时钟网络未能分配到BUFG资源，同样可能在opt阶段报连接性错误。这种问题在大型工程中尤其常见，可以通过报告BUFG资源使用量来确认。

3.4 第四环：用户逻辑对MIG接口的悬空与错误连接

Common的问题解决了，别忘了检查自己的用户逻辑。很多人把MIG核例化出来后，只关心app_addr、app_wdf_data这些数据通路，反而把ui_clk、ui_clk_sync_rst、mmcm_locked这种辅助信号当成不重要的东西随便处理。

ui_clk是MIG核输出给用户逻辑的核心时钟，它由内部MMCM产生。如果用户逻辑并没有使用这个时钟，而只用了自己的时钟去采MIG的数据端口，工具在优化时可能会认为部分时钟域之间没有真实的约束关系，从而导致整个时钟网络结构发生异常重构，间接引发opt31-67。

mmcm_locked也是一个容易被忽略的信号。MIG核要求mmcm_locked必须参与复位逻辑的生成，如果这个信号悬空或者接到了无意义的逻辑上，MIG内部复位状态机就永远无法正确释放，优化阶段检查复位网络时也会报异常。我的习惯是：所有MIG相关控制信号全部一一对应连好，不需要的时候宁可把输出信号留着不接，也不要随便接个常量或者悬空出警告。

4. 修复实操：三种典型场景的完整解决步骤

4.1 场景一：sys_clk引脚没绑到专用时钟引脚上

这是一个非常典型的低级错误，但出错率极高。DDR控制器的输入时钟通常要求连接到FPGA的MRCC或SRCC引脚上，也就是所谓的神眼。XDC约束里需要明确指定sys_clk_p/sys_clk_n的位置，并且时钟区域要正确。如果约束里拼错了脚位号，或者干脆把时钟引脚约束到了普通IO口，那么综合是能过的，但opt阶段清理时钟树时必然会因为无法建立合法的时钟输入而报错。

修复这个问题的完整步骤：

第一，在MIG核生成目录中找到系统自动生成的XDC文件。以7系列DDR3为例，文件通常在<project>.srcs/sources_1/ip/mig_7series_0/mig_7series_0/user_design/constraints/mig_7series_0 user.xdc。打开看里面的时钟引脚约束。

第二，核对约束里的PACKAGE_PIN是否与板卡原理图一致。差分时钟的约束写法一般类似：

set_property PACKAGE_PIN K17 [get_ports sys_clk_p] set_property PACKAGE_PIN K18 [get_ports sys_clk_n] set_property IOSTANDARD LVDS [get_ports sys_clk_p] set_property IOSTANDARD LVDS [get_ports sys_clk_n]

第三，确认时钟引脚所在的时钟区域（Clock Region）。如果DDR控制器和引脚所在的时钟区域距离过远，Vivado可能无法在一个时钟区域内完成时钟分配，也会在opt阶段出问题。这种情况通常需要查看器件手册或使用get_clock_regions命令确认。

第四，重新运行综合和实现。这个场景修复后，错误通常会直接消失。

4.2 场景二：MIG配置参数与板卡频率不匹配

再说回我这次真正踩的坑。板卡上实际用的晶振是125MHz的，但工程是从一个老的DDR3例子工程里改过来的，MIG核还是按照100MHz生成的。Synthesis阶段完全正常，到了opt_design，工具的时钟计算器开始纠结怎么从125MHz变出一个理想的DDR频率，最后算出来的相位余量不满足，报出了连接性错误。

修复方法是回到IP Catalog重新定制MIG核。具体操作路径是：

1. 在Sources窗口找到现有的MIG核，右键选“Re-customize IP”；
2. 进入“Memory”页面，确认DDR颗粒型号和速率等级；
3. 进入“Controller Options”页面，把Input Clock Period改成实际的时钟周期。125MHz对应的周期是8ns，100MHz对应10ns；
4. 进入“System Clock”页面，确认时钟类型与板卡一致；
5. 重新Generate Output Products，然后重新综合。

这里特别提醒一下：修改Input Clock Period之后，MIG向导会自动重新计算所有倍频参数。如果你的DDR速率等级超出当前输入频率能支持的组合，向导会直接报红提示，这种情况就需要在DDR速率等级和输入时钟频率之间重新找平衡。改完配置之后不要直接点Run Implementation，最好先重新跑一遍Synthesis，再往下走，因为IP核的底层实现已经变了。

4.3 场景三：多个MIG实例争用全局时钟资源

在部分高端应用中，一个FPGA里可能同时接了多片DDR，建立了多个MIG核实例。这种情况下，每个MIG核都会占用一定的时钟资源和BUFG。如果设计里还有PCIe、Ethernet、高速收发器等模块，BUFG资源很容易捉襟见肘。

碰到这个场景，常见的一种处理方式是让多个MIG核共享输入时钟。那么问题来了：如果你在顶层的例化时给两个MIG核都接上了同一个sys_clk端口，但板卡实际上只有一个差分时钟输入，那你就必须确保这个时钟能同时驱动两个MIG核内部的MMCM/PLL，而且每个MIG核各自的IDELAYCTRL都能拿到参考时钟。一旦资源分配不合适，工具在opt阶段就会报时钟网络冲突。

修复步骤这方面我比较有心得：首先打开Vivado的“Device”视图，查看BUFG的实际布局；然后在约束里手动指定某些时钟网络的BUFG放置区域，例如：

set_property CLOCK_DEDICATED_ROUTE ANY_CMT_COLUMN [get_nets ...]

这种方法能让同一个CMT列内的时钟更有效地共用一个bufg资源。不过提醒一点，CLOCK_DEDICATED_ROUTE ANY_CMT_COLUMN只是一个临时绕行方案，长期来看还是应该通过调整BUFG分配或合并时钟域来彻底解决，否则可能带来可靠性风险。

4.4 修复后的验证清单

以下是我经过多次踩坑后形成的标准化验证清单，每次修改完都按这个顺序过一遍：

• 查看综合日志中MIG相关警告数量是否减少；
• 在Open Synthesized Design状态下打开Schematic，确认sys_clk、ref_clk、ui_clk这条链条上无悬空引脚；
• 运行report_clocks，确认所有时钟都挂了来源，并且频率与设计预期一致；
• 运行report_clock_networks，确认每条时钟网络都有合法的buffer链；
• 执行Implementation，并在Implementation完成后查看时序报告，特别关注DDR接口的setup/hold情况。

这一套流程下来，99%的opt31-67问题都能在半小时内定位并解决。

5. 调优过程中的补充调试技巧

5.1 用报表快速定位时钟域的无效节点

如果在排查时不想一层层去翻Schematic，可以直接利用Vivado内置的时钟报告来秒级定位问题。在综合后或opt失败后的界面，在Tcl Console里运行：

report_clocks -format csv -file clocks.csv report_clock_networks -format csv -file networks.csv

用文本编辑器打开这两个文件，重点关注：

• 名称带mig或ddr的时钟；
• Source列是空的；
• 类型列是unrouteable或者no_driver。

只要看到这种行，基本就是断点位置。相比目测Schematic，这个方法对大型工程更高效。

5.2 使用unconstrained path报告检查悬空信号

还有一种隐蔽情况：时钟确实连上了，但由于某些路径没有被约束，导致opt阶段优化器对整个网络的状态判断出现偏差。在opt报错之前，Vivado其实会先生成一份unconstrained paths报告。在流程设置里勾选生成unconstrained path报告，打开之后看看MIG相关端口有没有出现不合理的unconstrained记录，如果有，顺手把这些路径约束上，往往能把一些奇奇怪怪的连接性错误顺带解决。

5.3 关于重新生成IP的建议

我在网上看到很多人一碰到MIG的问题就建议重新生成IP，这个做法有点粗暴，属于“重装系统式修法”。重新生成IP对于配置错误确实有效，但如果你不清楚具体是哪个配置错了，那么生成的十有八九还是同样的错误配置，等于白做。除非你能明确说出是频率不匹配、引脚约束错误、还是器件型号选错了，否则重生成只是表面功夫。

如果真的决定重新生成，我建议先把旧IP完整删除，包括IP源文件和生成目录，再重新添加MIG核，重新配置。只改参数点OK的做法有时候会残留旧的生成文件，让问题继续存在。

6. 最后的补充经验分享

调试opt31-67这类问题，心态上别慌。它跟时序跑不过不一样，不是那种需要反复调优很久的问题，本质上就是某一个明确的连接断掉了，只是这个断点藏得比较深。按照从外部到内部、从时钟到数据、从IP到用户逻辑的顺序，一层层排查，基本都能找到根因。

我在实际项目里最后还有一个习惯，那就是每次定制MIG核之后，都会顺手把IP生成的XDC和顶层例化模板原封不动保留一份，然后根据板卡原理图逐项核对。看似麻烦，但MIG核这种大型IP，默认模板和实际硬件不总是一一对应的，提前核对能省下后期大量的调试时间。

另外，工程里如果用到了多个频率的时钟来驱动MIG的各个接口，建议在XDC里手动把时钟分组和时钟约束写清楚，不要全部依赖工具自动推导。这个习惯让我在后续处理其他时序问题时也受益很多。

希望这套完整的排查思路和修复流程能让你在下一次遇到opt31-67时，直接少走弯路。如果你在项目里还有其他关于MIG核配置或者DDR接口调试的问题，可以在评论区把具体的报错上下文和MIG配置发出来，大家一起交流排查思路。