企业官网建设流程全解析

做FPGA做了这么多年，有一个体会越来越深：真正让项目难产的，往往不是顶层架构不是算法优化，而是那些“看不见、摸不着”的底层约束问题。尤其是当你从单DIE器件切到多DIE器件，比如Intel的Agilex、Stratix V，或者Xilinx的VU9P这种大逻辑容量芯片时，过去那套单DIE时代的约束思路，很多时候不仅帮不上忙，反而会把时序报告带偏，甚至在布局布线阶段暴雷。

这篇文章想聊的就是两件大多数人容易踩坑的事：多DIE器件的约束策略，以及Laguna寄存器在跨DIE传输中的角色。先说明白，我主要基于Intel FPGA体系来讲，但Xilinx的多SLR架构处理思路也差不多，文末我会穿插对照。全文不会只讲“怎么敲命令”，我更想带着你一起看：为什么多DIE架构会让传统约束失效，为什么Laguna寄存器不能乱动，以及一套可复用的实战排查路径。

1. 多DIE FPGA究竟改变了什么：从单DIE到多DIE的设计思维转变

1.1 为什么大芯片要做成多DIE

很多刚接触FPGA的同事会问：既然一片芯片想做大，为什么不做成一颗完整的大DIE，非要拆成好几个DIE拼在一起？答案很简单，制造难度和良率。

半导体制造面积越大，单颗芯片上的缺陷概率就越大，良率直线下降。像VU9P这种超过250万个逻辑单元、需要大量高速收发器和DSP的巨型芯片，如果强行做成单DIE，光刻掩膜的成本、晶圆面积、散热功耗都是灾难级问题。所以主流做法是：把一颗物理芯片内部拆成2个、3个甚至4个独立的DIE，再通过片内的高速互连（Intel体系叫EMIB或interposer，Xilinx体系叫Super Logic Region边界）把它们封装在一起。对外看是一颗芯片，对内看是多个DIE协同工作。

这个“对外统一、对内分裂”的特性，就是多DIE设计所有麻烦的根源。你在RTL里写的module边界、你在SDC里定义的时钟、你在布局时放置的逻辑，最终会被工具映射到不同的DIE上。而DIE之间的信号传输，不像同一颗DIE内部那样走普通互补金属氧化物半导体连线，需要经过专用硬核逻辑和高速连线，延时模型完全不同。

1.2 多DIE架构与单DIE的根本差异

单DIE设计里，你可以把芯片当作一个均质的逻辑池。时序报告基本符合直觉：路径越长，延时越大；约束越紧，工具越努力。你写一条set_false_path，工具知道这条路径可以完全不管时序，布局布线时就可以任意摆放。

多DIE设计里，芯片被物理分割成了多个区域。跨DIE路径的信号必须从DIE A的边界跑到DIE B的边界，再进入DIE B内部。这个过程中的路径延时，由三部分组成：

• 源DIE内部布线延时；
• DIE间互连桥接延时（Intel叫Laguna接口，Xilinx的SLR边界也类似）；
• 目的DIE内部布线延时。

其中中间那部分，也就是跨DIE桥接延时，是固定且不可优化的。它不像普通逻辑路径那样能通过换Pblock、改布局策略来缩短。你唯一能做的是：要么接受它，把它在约束里考虑清楚；要么想办法减少跨DIE路径的数量，让关键路径尽量留在一个DIE内部。

1.3 多DIE设计最容易犯的三个“惯性错误”

我在看过好几个团队从单DIE迁移到多DIE，包括我自己早期做VU9P项目时，踩过的坑基本集中在三种惯性思维上。

第一个错误，是拿单DIE的约束思路直接套。比如习惯性地给所有跨时钟域路径加set_false_path，或者简单地把慢速接口约束成set_max_delay。跨DIE路径确实慢，但它不是异步路径，它有真实时钟驱动，你盲目设false_path，工具就会彻底不管它，等到布线完一看，Fmax挂在30MHz，你却不知道为什么。

第二个错误，是提前不规划跨DIE区域。很多流程是综合完成后直接跑布局布线，任由工具把逻辑分布在各个DIE上。但跨DIE路径的性能损失是固定的，工具在布局时虽然会根据时序压力自动调整，但如果整个设计的关键路径恰好分布在两个DIE之间，工具再怎么调整也有物理上限。这就是为什么有些人会发现，压时序约束反而越来越差——因为关键路径已经被逼到跨DIE链路上，根本没有优化空间。

第三个错误，是不了解Laguna寄存器的作用，在RTL里擅自插入寄存器，或者反过来用综合属性误删了工具自动插入的Laguna寄存器。这个我后面专门展开。

2. 约束才是多DIE设计的隐形杀手

2.1 为什么普通SDC约束在多DIE下会失效

SDC约束本身没有错，错的是我们给它的“上下文”。在单DIE设计里，create_clock定义好了时钟，工具在时序引擎里计算路径延时，时钟不确定性（uncertainty）、抖动（jitter）这些参数基本是全局性的。但在多DIE设计里，时钟树也分DIE，DIE内部的时钟树可以做到很好的偏斜控制，跨DIE的时钟树偏斜则完全不一样。

举个实际场景。比如你有一个clk_a在DIE 0，clk_b在DIE 1，两个时钟同源但从不同DIE的时钟树驱动。时序工具计算跨DIE路径时，需要额外考虑DIE间时钟偏斜，手动加set_clock_uncertainty也不一定准。

更重要的是，多DIE器件的内部有大量专用高速互连线（EMIB、interposer通道），这些通道的延时模型和普通布线不同。如果约束文件里没有把这些路径单独对待，工具可能自动绕路，走普通的跨DIE逻辑阵列资源，导致时序严重恶化。

所以我的原则是：多DIE器件的约束，至少要分成三个层次来写。

第一层是全局约束，包括主时钟、生成时钟、时钟组互斥关系。这一层和单DIE区别不大，但要注意时钟MUX约束：多DIE器件的时钟MUX资源往往靠近DIE边界，切换时钟时的瞬时行为更容易引起亚稳态，需要在SDC里准确描述MUX的切换关系，不能简单把所有时钟设成set_false_path。

第二层是跨DIE路径约束，这是我建议每个项目单独拉出来的一个SDC文件，专门处理所有跨DIE路径。具体做法是使用set_clock_groups -asynchronous去掉不相干的时钟路径，但保留同源跨DIE路径的时序关系，然后对慢速跨DIE路径使用set_max_delay设定明确上限。

第三层是物理约束，包括Pblock、LogicLock区域、DIE分配等。约束文件不只是时序，还要告诉工具“哪些逻辑必须待在哪颗DIE上”。

2.2 跨DIE路径的时序约束正确写法

很多工程师喜欢把所有跨DIE路径直接设成set_false_path，一劳永逸。如果跨DIE路径连接的是真正异步的两个时钟域，这么做没问题。但如果是同源时钟、只是分布在不同的DIE上呢？那就不该用set_false_path，而应该用set_multicycle_path或set_max_delay来放宽时序。

为什么？因为同源时钟意味着数据发起和捕获的基准时钟是同一个，只不过经过不同DIE的时钟树后达到的相位可能有偏移。如果设false_path，工具认为完全不关心，路径上的寄存器就可能被综合/布局优化到极其糟糕的位置，导致实际工作中采样错乱。设置set_multicycle_path就不一样，它告诉工具：这条路径虽然达标困难，但可以在几个周期内完成，工具会为它保留合理的布线空间。

举个例子。假设跨DIE路径的数据发起时钟是clk_a（150MHz），捕获时钟是clk_b（也是150MHz，同源）。正常情况下一个周期6.67ns内要求路径从发射沿到捕获沿完成。但跨DIE路径的典型延时可能是8~10ns。这时如果你写：

set_multicycle_path -setup 2 -from [get_registers {dut_0/cross_die_*}] -to [get_registers {dut_1/cross_die_*}] -clock clk_b set_multicycle_path -hold 1 -from [get_registers {dut_0/cross_die_*}] -to [get_registers {dut_1/cross_die_*}] -clock clk_b

工具会认为数据可以在两个周期内到达，但控制信号回归、保持时机都由工具自动处理。这是多DIE跨DIE路径上最实用的一条命令。

还要注意，set_multicycle_path虽然常见，但很多人写错hold的值。记住一个口诀：给了h到setup的卡口，一定得匹配hold的偏移，否则hold分析会基于错误的捕获沿进行计算，大概率出现大量假性hold违例。上面例子中setup改成2，hold必须改成1，不能漏。

对于真正异步、不需要时序分析的跨DIE路径，可以用set_clock_groups处理时钟关系，而不是直接对路径设false_path。这样做的好处是仍然保留了路径的物理存在感，工具在布局时不会把它当成完全无关的信号而随意跨越DIE。

2.3 IO约束与接口时序约束的坑

多DIE器件的IO引脚分布也有讲究。我曾经在一个Artix-7升到更大规模Intel器件的项目里，只改了引脚位置，没重新看IO标准的时钟偏移，结果RGMII接口的DDR采样就是不对。RGMII接口时序约束是FPGA工程师绕不开的坎，多DIE器件上更是如此。

RGMII的源同步接口要求数据在时钟的双沿都有效，PCB上的走线延迟和FPGA内部IO逻辑的延迟必须匹配。在SDC里一般通过set_output_delay来约束，但多DIE器件里，IO逻辑可以分布在不同的DIE上，靠近引脚的那颗DIE和远离引脚的那颗DIE，到达IOB的延迟差可能很大。

解决思路有两个：一是用IO寄存器位置约束，保证RGMII的时钟和数据寄存器在同一个IO Tile或相邻IO Tile；二是显式约束内部延迟关系，用set_output_delay -max和-min分别匹配DDR采样的建立保持窗口。

还有LVDS接收、MIPI这类高速接口，多DIE跨DIE延迟会导致字节对齐逻辑状态机出错。我的习惯是高速接口的所有逻辑都锁定在靠近引脚的那颗DIE上，用物理约束强制实现：

set_property PBLOCK pblock_mipi [get_cells {mipi_phy_*}]

Xilinx体系就用Pblock，Intel体系对应的是LogicLock。反正原则是：高速接口逻辑和引脚所在DIE绑定，不要让它“漂流”到另一颗DIE上。

3. Laguna寄存器：跨DIE传输的幕后英雄

3.1 Laguna寄存器从哪来，为什么要有它

在Intel FPGA体系里，跨DIE路径上的信号传输，并不是直接把DIE A的输出连线拉到DIE B的输入。DIE之间的互连通道（EMIB之类的桥接结构）要求信号在进入桥接之前必须经过专门的寄存器级同步。这个专用寄存器就是Laguna寄存器。

你可以把它理解为一座“海关”：所有跨DIE的货物都必须在这里清关、登记、盖章，然后才能进入另一边的海关。Laguna寄存器就是DIE边界上的海关柜台。它和普通逻辑寄存器不一样，位置固定，逻辑容量固定，你不能把它挪走，也不能随便把它优化掉。它存在的意义是：把跨DIE路径的时序分割成两段，每段都可以被时序工具单独分析和优化，从而保证跨DIE传输的确定性。

所以在一份Intel FPGA的时序报告里，跨DIE路径通常长这样：

Source FF: DIE0中的普通寄存器 Laguna Register: DIE0边界专用寄存器 Destination FF: DIE1中的普通寄存器

如果这条路径上没有出现Laguna寄存器，反而要警惕：要么路径被工具优化成了组合逻辑直连（不建议），要么你的约束把这条路径给禁止了，工具直接忽略了。

3.2 综合器什么时候会自动插入Laguna寄存器

正常情况下，你在RTL里写了一个跨DIE的信号，比如：

reg [31:0] data_cross; always @(posedge clk) begin data_cross <= data_q; end

经过综合、布局布线后，工具检查到data_cross这个寄存器相关的路径跨越了DIE边界，就会自动用一个Laguna寄存器替换或拆分该寄存器。这个过程中，工具会保证逻辑功能不变，但物理实现上，数据会被暂存在DIE边界。

实际使用中，工具不是所有信号都会自动插入Laguna寄存器。它主要参考两个因素：信号跨越的DIE边界数量、信号所在路径的时序要求。如果信号在一个DIE内就能完成所有逻辑，就不会动用Laguna。如果信号必须跨DIE且要求高频采样，工具会倾向于在源DIE末尾、目的DIE开头各打一拍，也就是让Laguna寄存器承担同步角色。

这就引出一个坑：有些工程师不知道这回事，在RTL里手动为跨DIE信号多打了几拍寄存器，还特意加了大段注释，结果综合后工具发现这些寄存器可以合并到Laguna寄存器里，于是大量冗余逻辑出现，Fmax反而下降。后面我会详细讲怎么用综合属性控制这个行为。

3.3 为什么Laguna寄存器不能乱碰

Laguna寄存器不是普通逻辑，它是硬核逻辑资源，分布在DIE边界固定位置。它连接着DIE间的高速互连通道，专用性极强。如果你通过综合属性把它强制拆掉，或者通过位置约束把它锁到远离DIE边界的位置，工具会在布局布线阶段报错或经历极其漫长的编译流程，甚至完全无法布线。

我见过一个项目，工程师发现某条跨DIE路径时序违例严重，一时心急，把路径上的寄存器全部用(* dont_touch = "true" *)强制保留，又在Vivado里用set_property LOC把寄存器挪到某个区域。结果编译直接跑了12小时，最终全是布线拥塞错误。原因很简单：他把跨DIE路径原本应该使用的Laguna寄存器通道破坏了，工具被迫绕额外的互连资源，反而把路径拉得更长。

正确做法是：跨DIE路径上的寄存器，尽量减少手动干预，交给工具自动插入Laguna寄存器。如果一定需要指定位置，用set_instance_assignment（Quartus）或Pblock（Vivado）约束到DIE边界区域，而不是精确锁引脚。

另外提醒一下，有些综合工具版本对Laguna寄存器的识别有差异。Intel Quartus一般在顶层综合阶段就能看到Laguna寄存器的插入，Xilinx的Vivado则需要布局后查看。排查时注意选择正确的阶段查看报告，否则你会白找半天。

4. 实战案例：一次跨DIE时序违例的完整排查

为了把上面这些原理串起来，我分享一个真实项目经历。为了不涉及具体产品，我稍微改了点细节，但排查过程完全真实。

4.1 项目背景与约束目标

一个图像采集处理项目，用的是Intel某款多DIE FPGA，项目里同时跑了图像传感器MIPI采集（800Mbps）、DDR4读写（2400MT/s）、以及图像处理流水线（150MHz）。整体逻辑量比较大，综合后工具自动把业务逻辑分布在两颗DIE上。

项目时序目标是时钟150MHz，也就是周期6.67ns。

第一版编译完成后，时序报告惨不忍睹：总共有40多条路径违例，其中大半集中在DIE1到DIE2的跨DIE路径上，最差路径余量（WNS）是-1.8ns。当时团队的第一反应是：跨DIE路径慢，那就全部设false path。结果时序报告确实“好看”了，但板子上电后图像数据偶尔出现一行花屏。

现在回头看，这个做法错得很典型：把跨DIE路径当成无关紧要的路径直接忽略，但实际数据是实时的，错了就是错了。

4.2 第一轮修改：把所有跨DIE路径设false path的错误做法

错误做法是：

set_false_path -from [get_cells -hier *DIE1*] -to [get_cells -hier *DIE2*]

看起来简单干净，实际上造成了三个问题：

• 工具认为路径不关心时序，把源寄存器、目的寄存器分别放在两DIE内任意位置，不考虑布线长度；
• 路径上的跨DIE同步机制被完全绕过，综合器不再考虑插入Laguna寄存器；
• 实电路中有真实数据传输，数据到达时间完全不可控，板级偶发错误无法复现和排查。

4.3 第二轮修改：使用set_max_delay与set_min_delay

正确的思路是保留跨DIE路径的时序分析，但放宽要求，并施加明确的上下界。于是我在SDC里做了两类事情。

第一步，先把跨DIE路径从全局false path中排除，改为设置最大延时约束：

set_max_delay -from [get_cells -hier {pipe_die1_*}] -to [get_cells -hier {pipe_die2_*}] 8.0 set_min_delay -from [get_cells -hier {pipe_die1_*}] -to [get_cells -hier {pipe_die2_*}] 1.0

为什么设max_delay而不设multicycle_path？因为图像处理流水线里，数据是逐级流水传递的，多周期关系并不明显，我只需要告诉工具“这条路径的极限是8ns，你看着办”。set_min_delay 1.0是为了防止工具为了绕开拥塞，把路径拉得太短导致hold违例。

第二步，针对真正跨时钟域的路径，用set_clock_groups管理时钟关系，而不是直接对路径设false_path。比如MIPI字节时钟域和图像处理时钟域之间：

set_clock_groups -asynchronous -group {clk_mipi_byte} -group {clk_pixel}

这样工具会自动为跨时钟域路径做同步处理，而不会因为路径时序分析失败而乱插或乱删Laguna寄存器。

4.4 最终方案：物理约束与时序例外结合

时序例外改完之后，WNS从-1.8ns改善到-0.6ns，但还没过。这时候我才意识到，单靠约束不足以解决问题，必须干预布局。

我用LogicLock分别给两套逻辑划分了区域：MIPI采集逻辑锁在DIE0的某个IO附近，图像处理流水线锁在DIE0和DIE1的相邻区域，让跨DIE路径的距离尽量短。同时给跨DIE路径上的关键寄存器加了集合约束，让工具自动插入Laguna寄存器。

具体做法是，在Quartus中给跨DIE路径所在的模块加上logiclock约束：

set_instance_assignment -name LOGICLOCK_REGION pblock_die0_phy -to [get_cells {phy_inst_*}] set_instance_assignment -name LOGICLOCK_REGION pblock_die1_pipe -to [get_cells {pipe_inst_*}]

然后重新综合、布局布线。这次报告里能看到关键跨DIE路径上出现了Laguna寄存器，延时分布变得清晰：源到Laguna 2.1ns，Laguna到目的2.4ns，符合预期范围。

最终Fmax顺利达到150MHz，WNS归正，MIPI图像数据连续跑了48小时没有出现花屏。这个案例的教训总结成一句话就是：跨DIE路径不能靠一味放宽约束蒙混过关，物理布局上的安排才是根本。

为方便你上手，这里列一个排查清单：

5. 常见问题与排查技巧实录

5.1 布局布线阶段发现跨DIE路径完全无法满足时序

我见过不止一次：时序约束看起来没问题，逻辑量也不大，但布局布线后某些路径的Fmax就是上不去，甚至越约束越低频。这里面有一个很隐蔽的细节：综合阶段工具并不会给你真实的跨DIE路径延时预测，只有布局布线后才会反映出来。如果你在综合阶段看到的WNS是正数就觉得万事大吉，那后面大概率要打脸。

这时候我建议先查三个东西：综合报告里的跨DIE信号数量、是否有大量信号跨DIE、这些信号是否集中在某个关键路径上。如果跨DIE信号很多，优先做逻辑分区调整，把有关联的逻辑尽量放在同一个DIE。如果没法调整，再考虑提高流水线深度或者使用set_multicycle_path。

还有一个经验：FPGA布局和布线是两个不同步骤，很多人混在一起看。布局阶段工具决定逻辑放在哪里，布线阶段工具决定怎么连起来。跨DIE路径问题的根因常常在布局阶段就定了，布线阶段只能补救。所以遇到跨DIE时序问题，不要在布线约束上死磕，一定要回头看布局和物理约束。

5.2 set_false_path的“正确”和“错误”场合

很多新手一上来就问：set_false_path到底能不能用？我的回答是能用，但必须知道用在哪。

正确的场合包括：静态配置信号、测试模式信号、跨异步时钟域且已经做了双触发器同步的信号。这些路径本身不需要时序收敛，false_path能让工具腾出资源给真正重要的路径，是很高效的约束。

错误的场合包括：同源时钟跨DIE路径、数据流水线路径、实时接口信号。这些路径设了false_path，工具就会彻底忽略，布局时不考虑路径长度，布线时不优化延时，最后物理实现的结果就是你看到的各种偶发错误。

判断要不要设false_path，我有个简单标准：想象如果这条路径延时变成10倍，系统还能不能正常工作？如果答案是不能，它就不该设false_path；如果答案是能（比如调试寄存器、版本寄存器），那才考虑。

5.3 时钟MUX约束与复位信号亚稳态

多DIE项目里，时钟MUX约束和复位信号亚稳态是另外两个常见坑。我把它们放在一起讲，因为它们都是“看起来小、炸起来毁所有”的典型。

时钟MUX在FPGA内部用于时钟切换，多DIE器件的时钟MUX通常靠近DIE边界，切换瞬间更容易产生毛刺。如果约束里没有把这些时钟关系处理干净，时钟切换后所有跨DIE寄存器都可能进入亚稳态。

解决办法是尽量使用BUFGMUX / CLOCK_MUX原语，而不是用普通的逻辑组合去产生时钟。同时SDC里对MUX的两个输入时钟定义好set_clock_groups -physically_exclusive，告诉工具这两个时钟永远不同时有效，避免时序引擎做无谓的分析。

复位信号亚稳态则是另一个高频问题。异步复位在多DIE设计里尤其危险，因为复位信号可能通过普通的全局网络传到所有DIE，跨DIE路径上的复位同步如果不一致，可能导致寄存器一边复位了一边没复位。

推荐做法是用XPM_CDC_SYNC_RST原语（Xilinx）或标准复位同步模块（Intel）来统一跨DIE复位释放。不要自己手写两级DFF就当同步完事，必须确认复位释放沿与目标时钟沿的关系。

5.4 查看跨DIE路径的实用工具与报告

每个厂商的EDA工具都有查看跨DIE路径的报告功能，关键是你要知道去哪里找。

Intel Quartus里，可以用Report Cross Die Paths报告查看所有跨DIE路径的分布情况，也可以在编译后查看Report Timing时勾选“Show Cross-DIE paths only”。Quartus还有一份Fitter Resource Utilization报告，能直接看到LogiLock区域的资源使用、Laguna寄存器的插入数量。

Xilinx Vivado里，时序报告里每条路径都会标注是否跨越SLR，用report_clock_interaction可以看跨时钟域路径。更直接的是打开Device视图，布局后按SLR着色，一眼就能看出来哪些逻辑跨了SLR。

我说一个我自己常用的组合拳流程：

1. 综合后，先查跨DIE信号数量，做到心里有数；
2. 布局后，打开Device视图，按DIE/SLR查看关键模块分布；
3. 时序收敛失败后，优先查WNS最差的前20条路径，看是否集中在某个DIE边界；
4. 如果是，回SDC检查跨DIE路径约束，再看LogicLock/Pblock是否需要调整；
5. 重新布局布线，对比WNS变化。

这套流程我走了两年，项目基本都能快速定位问题。

6. 关于多DIE设计，我最后想分享的几点体会

写到这里，核心内容基本都覆盖了。最后说几句个人体会。

多DIE设计不是什么玄学，它的本质是一个“物理世界”问题。你在RTL里写得干干净净，但逻辑一旦落到不同DIE上，信号传输的物理距离就是绕不过去的坎。早一点在项目早期做DIE分区规划、早一点考虑跨DIE路径用什么约束、早一点查看Laguna寄存器的插入情况，后面就能少掉很多头发。

我见过太多团队倒在了约束这一步：要么全false path一堆、时序报告绿得发亮、板子上电就挂；要么死磕单条跨DIE路径，把编译时间拖到天荒地老。其实多DIE设计有一条朴素的准则：跨DIE路径要有意识地去管理，不能靠工具自动摆烂。

如果你是刚开始接触多DIE器件，建议从一个小模块开始，专门去读一读工具生成的跨DIE路径报告，去查一查Laguna寄存器在时序报告里的位置，亲手改一次约束并观察时序变化。踩过几个坑之后，你会发现多DIE约束并没有想象中那么难。

如果你已经在多DIE项目上踩了坑，希望这篇文章能帮你定位到问题方向。跨DIE路径、Laguna寄存器、时钟MUX、复位亚稳态这几个关键词，值得你在每个项目的约束文件里反复审视。