企业官网建设流程全解析

有些错误我在Vivado里见一次就记一辈子，Place 30-675算一个。那晚本来只是想把一个简单的FPGA图像处理工程重新跑一遍，综合、布局都没问题，卡在Implementation的Place阶段，红色报错直接停在MRCC引脚上。更气人的是，代码和约束看起来全是对的，时钟引脚也分在了Bank正中央，为什么工具就是不认？后来我把这条错误背后的逻辑彻底挖了一遍，才发现这根本不是“随机故障”，而是对FPGA时钟资源理解不到位时必然踩中的坑。今天把这段排查经历完整写出来，包括MRCC和SRCC的区别、Place 30-675的成因、定位方法，以及可以照着抄的解决方案。

1. MRCC引脚的职责边界：时钟从引脚到缓冲器的“第一公里”

1.1 为什么普通IO不能当时钟用：MRCC/SRCC的物理差异

FPGA引脚不是平等分工的。以Xilinx 7系列为例，每个IO Bank里除了普通用户IO，还专门留出了四根“Clock Capable”（CC）引脚，其中两根叫MRCC，两根叫SRCC。MRCC全称Multi-Region Clock Capable，SRCC全称Single-Region Clock Capable。名字已经说明问题：MRCC天生能驱动跨区域时钟资源，SRCC主要面向单区域时钟。

普通IO之所以不能替代MRCC/SRCC，是因为在硅片内部，只有CC引脚下面才铺设了通往时钟缓冲器的专用走线和专用接口。普通IO到时钟资源的路径是“绕远路”，没有专用金属线，工具就算能布线，也会带来额外的时钟偏斜和抖动，这在高频设计中是不能忍的。更关键的是，Vivado在布局时根本不承认普通IO有合法路径进BUFG，于是会直接报Place类错误。

很多第一次接触FPGA的人会把“引脚分配”当成查表填数字，看到数据手册上某个Bank有一个空闲引脚，就把50MHz有源晶振接上去。这样不是不能用，而是必须配合IBUFG/BUFG的例化，且物理位置必须恰好落在MRCC或SRCC上。如果你不小心把时钟信号约束到了普通IO，工具不会默默帮你兜底，它会给出一整屏你看不懂的错误，Place 30-675往往就在其中。

1.2 从IBUFG到BUFG：时钟信号在FPGA内部的路径

时钟信号从MRCC引脚进入FPGA后，第一站是输入缓冲器IBUFG，然后进入全局时钟缓冲器BUFG，再分发到各个时钟区域。对于差分时钟，还需要IBUFDS把P/N差分信号转换成单端。这条链路看起来简单，但每个环节都有物理约束：MRCC引脚的位置、IBUFG所在IO Bank、BUFG的site位置、BUFG所驱动的时钟区域，这些要素必须两两之间存在合法连接路径，否则Place阶段直接翻车。

举个例子，7系列里的BUFG，整体布局在芯片中央的全局时钟列（Global Clock Column）上。虽然BUFG本身支持被任意时钟输入驱动，但你的MRCC引脚和这个BUFG之间必须满足可布线性要求。工具在做Place时，会检查“该时钟输入 site 是否能够到达该BUFG site”。如果MRCC所在Bank和所选BUFG之间没有直连路径，工具就会放弃，并把这个放弃原因映射成Place报错。

1.3 区域时钟BUFR与全局时钟BUFG的匹配逻辑

除了BUFG，7系列还有BUFR（区域时钟缓冲器）和BUFHCE（水平时钟缓冲器）。BUFR只能驱动所在时钟区域或相邻区域，SRCC引脚由于物理布线短，通常和BUFR绑定得更紧密。MRCC则可以同时作为BUFG和BUFR的输入源，这也是叫“Multi-Region”的原因。

问题往往出在“想当然”上。有的人会在一个跨时钟域设计里偷懒，统一用一个SRCC引脚输入时钟，然后例化BUFG给全局使用。布局时工具发现SRCC根本没有通往那个BUFG的合法路径，于是一边尝试从SRCC搞一条绕行长线，一边尝试重新调整BUFG位置，最终哪个也凑不出来，只能报错。别问我怎么知道的，我踩过。

如果设计里只是驱动单个区域内的逻辑，使用BUFR比BUFG更省功耗、抖动也更小。如果设计里确实需要全局时钟，就老老实实用MRCC。这个选型错误是Place 30-675的高发原因之一。

2. Place 30-675错误的真实信号：工具到底在抱怨什么

2.1 错误文本的常见变体和核心含义

Vivado的Place错误信息形形色色，但标题里的Place 30-675我已经翻来覆去查过很多次。它的完整文本在不同版本里略有差异，大致长这样：

[Place 30-675] The clock buffer BUFGCTRL_X0Y10 cannot be placed because a legal route to the input clock pin ... does not exist. Please check the clock pin and the clock buffer placement.

有些版本还会提示“No legal clock path between the clock capable pin ... and the clock buffer”。这些文字背后只有一个核心意思：工具认为你的时钟源引脚和时钟缓冲器之间不存在合法的物理连接路径。注意，这里的“不存在”不是指布线和约束写得不充分，而是硬件层面的专用连接就不支持。

2.2 三大典型触发场景：错引脚、错缓冲器、错区域

我整理了工作中最容易触发Place 30-675的三类场景，表格如下：

场景A最典型。有些封装中MRCC就那么几根，设计者不愿改板，就把时钟接到普通IO上，试图用“CLOCK_DEDICATED_ROUTE FALSE”蒙混过关。这个属性确实能绕过一部分错误，但代价是让时钟走普通布线，偏斜和抖动都很糟糕，时序收敛时够你喝一壶。

场景B常见于“寄存器用错了”的地方。有人会用BUFGCE例化整个时钟网络，但由于引脚位置特殊，工具在布局时发现该BUFGCE没有任何可访问的site，于是报错。实际上这样的设计更稳妥的策略是先用BUFR做区域时钟，再在必要时转成BUFG。

场景C则更隐蔽。我遇到过两个MRCC引脚位于芯片两端，却要驱动同一个BUFG。这个路径在物理上可能合法，但由于BUFG的site会被自动选择在偏向某一侧的位置，另一侧引脚的路径会变得很长，工具评估后认定不可接受，也会报同样的Place错误。

2.3 一个被我复盘过无数次的例子：单端时钟接到SRCC

某个项目使用了Artix-7 XC7A35T，板卡把一路100MHz参考时钟接到了SRCC引脚上。原理图看起来很好，引脚册上也标着“Clock Capable”，我起初以为没问题。驱动一个UART协议引擎，逻辑只占了一个时钟区域，按说BUFR足够用了，但我在RTL里却写了(* clock_buffer_type = "BUFG" *)，强制综合器用BUFG。

结果就是Place 30-675。当时我不理解，明明引脚是CC引脚，BUFG也是全局的，怎么就不行？后来通过Device View看到，这个SRCC引脚所在的Bank和默认分配的BUFG site之间不存在直连路径，工具连尝试布线都懒得试，直接放弃。

把时钟网络强制改成"BUFR"后，问题立刻消失，时序还更好了。这件事给我一个教训：引脚类型和缓冲器类型必须配对使用，不能只盯着“它能不能当时钟”这一个维度。

3. 定位根因的完整排查链路（照着做即可）

遇到Place 30-675，不要急着改代码或者删约束。严格按照下面的链路去查，绝大多数时候能在十分钟内定位到根因。

3.1 先查XDC：引脚约束和时钟约束有没有打架

第一步打开XDC，重点检查所有物理引脚约束set_property PACKAGE_PIN的位置，以及其对应的IOSTANDARD。确认被工具报错的引脚，是否关联到了MRCC/SRCC。怎么确认？看这个文件名对应的PACKAGE_PIN，再去板卡原理图或封装资料里查它是不是CC引脚。

同时还要检查是否有LOC约束强制指定了BUFG/BUFR的site。有些工程师喜欢在XDC里直接写死：

set_property LOC BUFGCTRL_X0Y10 [get_cells clk_gen/inst/bufg]

这种做法很容易出问题。因为BUFGCTRL_X0Y10这个site可能只能被特定区域的MRCC驱动，一旦你的MRCC引脚不在那个区域内，Place阶段就会炸。除非你是芯片架构专家，否则我不建议手动指定BUFG site，交给工具自动选择更安全。

3.2 再查综合后的时钟网络：用report_clock_utilization说话

打开综合后的设计，在Vivado Tcl Console里运行：

report_clock_utilization -file ./clock_util.txt

打开生成的clock_util.txt，重点看以下几点：

• 每个时钟用的是哪个IBUF/IBUFDS
• 中间串了哪几个BUFG/BUF
• 时钟源引脚是不是和预期一致

如果看到源引脚和你XDC里分配的不一致，或者BUFG数量比预期多，往往就是问题所在。比如一个时钟本来可以直接由MRCC进入BUFG，结果因为RTL里多写了一个BUFG例化，导致两级缓冲器串联，工具在物理布局时找不到合理位置。clock_utilization报告能直观反映这种“多余”的缓冲器。

3.3 最后用Device View查看物理距离：BUFG/BUFR和引脚的相对位置

如果前两步还看不出毛病，就打开Device View。在Vivado中进入Implementation后的Device视图，高亮报错涉及的时钟缓冲器和引脚，查看它们之间的相对位置和连接线。

我习惯再看一下“Clock Regions”图层。把错误涉及的时钟区域高亮出来，然后确认缓冲区所在site是否落在该区域内。这个操作看起来土，但非常有效。工具有时候会为了满足其他约束，把一个时钟缓冲器的候选site收到某个特定区域，而这个区域和你的MRCC引脚根本不在一个可访问的区域内。你在Device View里眼睛一扫就能发现，比瞎猜快得多。

还可以用Tcl命令直接查询候选site：

get_sites -filter { SITE_TYPE == BUFGCTRL } -of_objects [get_clock_regions]

对比候选site列表和当前报错的site，基本就能明白工具为什么放不下去。

4. 解决方案：让Place 30-675消失的几种做法

找到问题后，修复手段通常就是三大类。我按优先级从高到低列出。

4.1 方案A：把时钟输入换到MRCC引脚上

这是最根本的解决方式。对于需要全局时钟的设计，直接从PCB阶段开始，把所有系统时钟都引到MRCC引脚上。如果当前项目还能改板，别犹豫，把连接时钟输入的引脚换掉。

具体换法很简单：修改XDC中的PACKAGE_PIN，同时确认新的引脚属于MRCC。比如原来的时钟引脚是普通IO或SRCC，改成同Bank甚至另一个Bank的MRCC后，再重新跑Place，错误通常会消失。

判断MRCC引脚的方法：在Vivado里打开Package View，按I/O Banks显示，引脚上会有标记；或者在原理图封装库中查看引脚名是否含有MRCC字样。许多板卡数据手册也会在引脚表格里用不同颜色标出CC引脚。

4.2 方案B：更换缓冲器类型——该用BUFR就别硬上BUFG

如果改不了板子，只能改FPGA内部时钟网络。确认这个时钟只需要驱动局部逻辑后，在RTL或综合属性里强制使用区域时钟缓冲器。

例如原本这样例化BUFG：

BUFG clk_buf (.I(clk_in), .O(clk_int));

如果确定只需要区域时钟，可以改用BUFR，并且设置分频模式：

BUFR #( .BUFR_DIVIDE("BYPASS") ) clk_buf ( .I(clk_in), .CE(1'b1), .CLR(1'b0), .O(clk_int) );

或者直接在引脚约束上降低工具预期：在XDC中声明时钟域，然后不手动指定CLOCK_BUFFER_TYPE，让工具根据引脚物理位置自动选。很多时候工具自己选出来的缓冲器类型比你乱写的好一百倍。

4.3 方案C：调整XDC中的LOC约束，避免和相邻引脚冲突

还有一种情况：你用了MRCC引脚，但XDC里残留了某个不相关的LOC约束，导致BUFG的布局范围被限制住。排查方式是搜索所有BUFGCTRL相关的LOC、PACKAGE_PIN附近的CONFIG命令，把那些是历史遗留的注释掉。

如果你有多个时钟源同时输入，还要检查相邻MRCC引脚是否都被占用。有些MRCC引脚对和专用时钟路由有共享关系，如果你把一对差分引脚的其中一端用作单端时钟，另一端悬空，可能会阻断了另一条合法路径。

建议在XDC里对每个时钟源只保留PACKAGE_PIN、IOSTANDARD、create_clock三样核心约束，其他能省则省。

4.4 千万不要迷信CLOCK_DEDICATED_ROUTE FALSE

网上搜Place 30-675，很多人会告诉你加这条属性：

set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets clk_net]

这确实会让错误消失，但只是让时钟信号从专用轨道改走普通布线。结果就是时钟偏斜变大，时序难收敛，极不稳定。尤其在ADC/DAC接口、高速SerDes相关的时钟路径上，用这个属性等于埋雷。

我见过一个做FPGA TDC直方图的同事，为了赶进度加了这条属性，波形一度很漂亮，但在温度变化后就出现偶发丢数，排查了一个星期才定位到是时钟路径问题。后来老老实实换MRCC引脚，同样的逻辑立刻稳定下来。所以除非你知道自己在干什么，否则别碰这个属性。

5. 我在后续项目中养成的几个时钟设计习惯

5.1 设计前先画一张时钟域/引脚分配草图

现在每做一个FPGA项目，我第一件事不是写代码，而是拿一张纸把板上所有时钟源列出来，标注每个时钟源连接到FPGA的哪个Bank哪个引脚，是MRCC还是SRCC，时钟要驱动哪些逻辑区域。这张草图在后续综合、布局阶段就是排查问题的指南针。

特别是在多时钟项目中，输入时钟超过两个时，MRCC的数量往往会不够用。这时候需要提前想清楚哪个时钟用BUFG做全局，哪个时钟用BUFR做局部。不要等到Place报错才后悔。

5.2 用脚本自动化检查MRCC/SRCC占用

Vivado Tcl可以帮助你在跑布局前快速检查全部时钟源引脚属性。我在综合后固定会跑一段脚本：

foreach clk_pin [get_ports {clk*} ] { set pin_site [get_property PACKAGE_PIN $clk_pin] set site_info [get_sites -of_objects [get_ports $clk_pin] ] ... }

脚本会把所有名字带clk的端口，引脚site类型打印出来。如果发现普通IO混进来了，综合后一眼就能看到。这个习惯帮我避开了好几次低级错误。

5.3 遇到类似错误时先抓报告，不急着改代码

每次看到Place错误，我现在的第一反应是保存全部报告，包括place_utilization.txt、clock_util.txt、以及Implementation日志的完整文本。这种错误信息迷惑性很强，仅凭屏幕上前几行很难判断是引脚问题还是缓冲器类型问题。

把报告保存下来还有一个好处：当你换方案后对比前后差异时，可以快速看出工具选择的BUFG site从哪儿变到了哪儿，这是最直接的“因果证据”。

5.4 团队协作时，把硬件引脚表和FPGA约束放在一起评审

很多Place 30-675错误其实在原理图评审阶段就可以避免。硬件工程师和FPGA工程师对引脚的理解经常存在偏差：硬件觉得“这个引脚能接到晶振就行”，FPGA觉得“这个引脚得是全局时钟引脚才能做时钟”。如果两块工作没有对齐，后面必然炸。

我们团队现在要求，所有外部时钟输入必须双重标注：硬件原理图上标出FPGA引脚号的同时，还要标注“MRCC/SRCC”，这两项齐全后才允许发板。这个小小的流程改进，让我们的Place错误率下降了一大半。

最后再分享一条经验：如果你手头正好有之前能正常布局的版本，但新版加了某些引脚约束后突然报Place 30-675，最快的恢复办法不是继续挣扎，而是把新增约束逐条二分禁用，跑一版Place试试。这个错大多时候不是“代码写错”，而是“资源用错”，放下了虚荣心，老老实实回到MRCC和BUFG的物理匹配上，问题往往几分钟就解掉。