企业官网建设流程全解析

1. 时序约束到底在约束什么

1.1 从一个真实翻车案例说起

前两年接手过一个图像采集项目，FPGA 端用 RGMII 接口接千兆 PHY，功能仿真全过，上板之后丢包率随温度升高而飙升。抓了两天波形才发现，问题根本不在逻辑代码，而是时序约束只写了create_clock，RGMII 的 RX 数据相对时钟的建立保持窗口压根没约束，布局布线工具按默认宽松策略走线，常温下勉强能跑，一上温就崩。这个坑让我彻底明白一件事：时序约束不是给工具看的"形式主义"，它是你告诉布局布线器"这条路径必须满足什么物理条件"的唯一手段。你不说，工具就按最省资源的方式走，跑不跑得起来全靠运气。

PDS 是紫光同创（Pango）的 FPGA 开发工具链，整体流程和 Intel Quartus、Xilinx Vivado 是一个思路：综合、布局布线、时序分析、生成码流。但 PDS 的时序约束语法和 SDC 标准高度一致，很多从其他平台转过来的朋友会觉得"差不多"，恰恰是这种"差不多"的心态最容易出问题。本文围绕create_clock到异步时钟处理这条主线，把 PDS 里时序约束的完整链路讲透，包括时钟定义、IO 约束、异步时钟域处理、时序报告解读，以及那些文档里不会写的实操经验。

适合谁看？如果你已经能跑通 PDS 的基本流程，能综合出码流，但对时序约束还停留在"抄模板"的阶段，那这篇内容就是给你准备的。如果你是完全的新手，建议先把 PDS 的工程建立和综合流程走一遍再回来，否则有些概念会比较抽象。

1.2 时序约束的本质：给工具画一张"物理地图"

很多人把时序约束理解成"检查工具"，觉得写完约束跑一下时序报告，通过了就万事大吉。这个理解是反的。时序约束的真正作用是驱动布局布线。FPGA 内部的布线资源是有限的，工具在布局布线时面临无数种选择：这条路径走短线还是长线，那个寄存器放在 CLB 的哪个位置，时钟树怎么分配。约束就是你的"需求说明书"，工具在满足约束的前提下尽量省资源。约束写得松，工具就随便走；约束写得紧，工具就拼命优化。

打个比方，时序约束就像给装修师傅的施工图。你只说"装个厨房"，师傅可能把灶台放在离水管最远的地方，因为那样走线最省事。你得明确告诉他"灶台必须离水管 30 厘米以内"，他才会按你的要求来。create_clock就是告诉工具"这个时钟周期是 10ns"，工具才知道每条路径有多少时间预算。

这里有个关键概念叫时序预算（Timing Budget）。一个时钟周期 10ns，数据从源寄存器出发，经过组合逻辑、布线延迟，到达目的寄存器，必须满足建立时间（Setup）和保持时间（Hold）。工具会把 10ns 拆分成：时钟偏斜（Skew）、组合逻辑延迟、布线延迟、寄存器建立时间、时钟不确定性（Uncertainty）。约束越精确，工具拆分得越合理，最终结果越可靠。

2. Create_clock 的正确打开方式

2.1 主时钟定义：周期、名称与波形参数

create_clock是所有时序约束的起点。PDS 里的基本语法是这样的：

create_clock -name sys_clk -period 10.000 -waveform {0.000 5.000} [get_ports sys_clk]

逐项拆解：-name给时钟起个名字，后续约束都引用这个名字；-period是周期，单位纳秒，10.000 就是 100MHz；-waveform定义上升沿和下降沿的时刻，{0.000 5.000}表示上升沿在 0ns，下降沿在 5ns，占空比 50%；最后的[get_ports sys_clk]指定时钟来源是哪个管脚。

这里有几个新手常踩的坑。第一，-period的精度。有人写-period 10，工具也能认，但建议写成10.000，因为 PDS 内部按皮秒级计算，小数点后位数多一点没坏处。第二，-waveform不是必须的，不写默认就是 50% 占空比从 0 开始，但如果你用的是差分时钟或者有特殊相位要求，就必须显式指定。第三，get_ports和get_pins的区别。如果时钟从外部晶振经过管脚进来，用get_ports；如果是从内部 PLL 输出，用get_pins或者get_nets。

注意：PDS 里时钟名称一旦定义，后续所有约束都必须用这个名字引用。如果你在create_clock里写了-name sys_clk，后面又用clk_100m去引用，工具会报找不到对象。建议命名规范统一，比如clk_前缀加频率，clk_100m、clk_50m，一眼就能看出周期。

2.2 衍生时钟：PLL 输出与时钟分频的约束方法

实际项目里，系统时钟往往不是直接用的，而是经过 PLL 倍频或分频。PDS 里对 PLL 输出的时钟有两种处理方式：自动推导和手动约束。

自动推导是指工具根据 PLL 的配置自动计算输出时钟的周期和相位，你不需要手动写create_clock。但自动推导有个前提：PLL 的输入时钟必须已经约束好了。如果输入时钟没约束，PLL 输出就是"无源之水"，工具推导不出来。

手动约束则是用create_generated_clock：

create_generated_clock -name clk_200m -source [get_pins pll_inst/CLKIN] \ -divide_by 1 -multiply_by 2 [get_pins pll_inst/CLKOUT]

这个约束的意思是：clk_200m来源于pll_inst的CLKIN管脚，倍频系数 2，输出在CLKOUT管脚。-divide_by和-multiply_by可以组合使用，比如输入 50MHz，-multiply_by 4 -divide_by 1就是 200MHz。

什么时候用自动，什么时候用手动？我的经验是：如果 PLL 配置简单、输出时钟关系清晰，用自动推导省事；如果 PLL 有多个输出、相位关系复杂，或者你需要对某个输出做特殊约束，手动写更可控。特别是做源同步接口的时候，PLL 输出的时钟和数据之间的相位关系必须精确控制，手动约束能让你心里有数。

还有一个容易忽略的点：PLL 的反馈时钟。如果 PLL 用了外部反馈（比如从输出管脚绕回来），反馈路径的延迟会影响输出时钟的相位。PDS 里可以用set_clock_latency来补偿，但更推荐的做法是在 PLL 配置时选择内部反馈，避免引入额外的板级延迟。

2.3 时钟不确定性：给抖动和偏斜留余量

set_clock_uncertainty是很多人会跳过的一步，但它直接影响时序分析的乐观程度。这个约束告诉工具："这个时钟有 ±X ns 的不确定性，分析时要把这部分扣掉。"

set_clock_uncertainty -setup 0.200 [get_clocks sys_clk] set_clock_uncertainty -hold 0.100 [get_clocks sys_clk]

-setup和-hold可以分别设置。建立时间的不确定性通常比保持时间大，因为建立时间受时钟抖动（Jitter）影响更明显。对于普通晶振，抖动一般在几十皮秒量级；对于 PLL 输出的时钟，抖动可能到几百皮秒。如果你不确定具体数值，一个保守的做法是取周期的 2%~5%。比如 10ns 周期，建立不确定性取 0.2ns~0.5ns。

提示：不确定性设得太大，工具会拼命优化，可能浪费资源甚至布不通；设得太小，时序报告好看但实际可能不稳定。建议先用保守值跑一版，看时序余量（Slack）有多少，再逐步收紧。

3. IO 约束：RGMII 接口的实战拆解

3.1 输入延迟与输出延迟的计算逻辑

IO 约束是时序约束里最考验功底的部分，因为它涉及板级走线、外部器件特性、PCB 参数。核心的两个命令是set_input_delay和set_output_delay。

先理解这两个命令的物理含义。set_input_delay告诉工具：外部器件发出的数据，相对于时钟沿，到达 FPGA 管脚时已经延迟了多少。这个延迟包括外部器件的 Tco（时钟到输出延迟）和 PCB 走线延迟。set_output_delay则相反：FPGA 发出的数据，需要在时钟沿之前多久到达外部器件管脚，才能被正确采样。

以 RGMII 为例。RGMII 是千兆以太网的常用接口，数据位宽 4bit，时钟 125MHz，在时钟的上下沿都传数据，所以等效数据率是 125MHz × 2 × 4bit = 1000Mbps。RGMII 的时序规范里，RX 方向（PHY 到 FPGA）数据相对时钟有 1~2ns 的延迟，TX 方向（FPGA 到 PHY）通常要求数据与时钟对齐或略有超前。

假设 PHY 芯片的 RX 时钟到数据延迟 Tco 最大 2.0ns，最小 1.0ns，PCB 走线延迟 0.3ns，那么：

set_input_delay -clock rx_clk -max 2.300 [get_ports rgmii_rxd*] set_input_delay -clock rx_clk -min 1.300 [get_ports rgmii_rxd*]

-max对应建立时间分析，-min对应保持时间分析。这里 2.300 = 2.0 + 0.3，1.300 = 1.0 + 0.3。注意-clock参数引用的是已经定义好的时钟名。

TX 方向类似，但方向反过来：

set_output_delay -clock tx_clk -max 1.500 [get_ports rgmii_txd*] set_output_delay -clock tx_clk -min -0.500 [get_ports rgmii_txd*]

-min可以是负数，表示数据可以比时钟晚到。具体数值必须查 PHY 芯片的数据手册，不同厂商的 PHY 差异很大。

3.2 RGMII 的 DDR 约束与虚拟时钟

RGMII 的难点在于它是 DDR（双沿采样）接口。PDS 里处理 DDR 输入需要用-add_delay分别约束上升沿和下降沿：

set_input_delay -clock rx_clk -max 2.300 [get_ports rgmii_rxd*] set_input_delay -clock rx_clk -min 1.300 [get_ports rgmii_rxd*] set_input_delay -clock rx_clk -max 2.300 -clock_fall -add_delay [get_ports rgmii_rxd*] set_input_delay -clock rx_clk -min 1.300 -clock_fall -add_delay [get_ports rgmii_rxd*]

-clock_fall表示这是针对时钟下降沿的约束，-add_delay表示追加而不是覆盖。如果不加-add_delay，后面的约束会覆盖前面的，导致只有一个沿被约束。

另一个关键点是虚拟时钟（Virtual Clock）。有时候外部器件的时钟并不是 FPGA 的输入时钟，而是独立的一个时钟源。这时候需要定义一个虚拟时钟：

create_clock -name virt_clk -period 8.000 set_input_delay -clock virt_clk -max 2.000 [get_ports data_in*]

虚拟时钟没有物理管脚，只用于时序分析。它的好处是让你可以独立描述外部器件的时序特性，不受 FPGA 内部时钟的影响。

3.3 时序例外：False Path 与 Multicycle Path

不是所有路径都需要满足单周期时序。有些路径天然就是多周期的，或者根本不需要时序关系，这时候就要用时序例外。

set_false_path告诉工具"这条路径不用分析"：

set_false_path -from [get_clocks clk_a] -to [get_clocks clk_b]

典型场景是异步时钟域之间的路径。如果两个时钟完全无关，它们之间的路径不需要满足任何时序关系，用false_path可以避免工具做无意义的优化。

set_multicycle_path则用于那些需要多个周期才能稳定的路径：

set_multicycle_path -setup 2 -from [get_clocks clk_a] -to [get_clocks clk_b] set_multicycle_path -hold 1 -from [get_clocks clk_a] -to [get_clocks clk_b]

比如一个乘法器需要 2 个周期才能出结果，就可以用 multicycle 告诉工具"给我 2 个周期的时间"。注意-hold通常要配合-setup一起设，-hold的值一般是-setup减 1。

注意：false_path和multicycle_path是"危险命令"，用错了会导致时序报告虚假通过。建议每加一条例外，都在时序报告里确认对应的路径确实被排除了，而不是被错误地忽略了。

4. 异步时钟域处理：从约束到代码

4.1 异步时钟域的本质问题：亚稳态

异步时钟域的核心问题是亚稳态（Metastability）。当一个信号从一个时钟域传到另一个时钟域，如果两个时钟没有固定的相位关系，采样时刻可能正好落在信号跳变沿附近，导致目的寄存器的输出在一段时间内既不是高也不是低，而是介于两者之间的一个不稳定状态。这个状态可能持续几个周期，也可能被下一级电路解读成不同的值，造成逻辑错误。

时序约束解决不了亚稳态，它只能告诉工具"这两个时钟域之间的路径不用做时序优化"。真正的解决方案在 RTL 代码里：同步器。

最常用的同步器是两级触发器：

reg sync1, sync2; always @(posedge clk_dst) begin sync1 <= signal_src; sync2 <= sync1; end

signal_src是源时钟域的信号，clk_dst是目的时钟域。两级触发器的作用是给亚稳态一个"恢复时间"：第一级可能输出亚稳态，但经过一个周期后，第二级采到的已经是稳定值了。两级同步器的 MTBF（平均无故障时间）通常足够满足绝大多数应用，如果时钟频率很高或者可靠性要求极高，可以用三级。

4.2 多比特信号跨时钟域：握手与异步 FIFO

两级触发器只适用于单比特信号。多比特信号跨时钟域不能简单地对每一位都做两级同步，因为各位的延迟可能不同，导致目的时钟域采到一个"中间态"的数值。比如一个 8bit 计数器从 0x7F 变到 0x80，如果各位延迟不一致，可能采到 0xFF 或者 0x00，完全错误。

多比特跨时钟域有两种主流方案：握手协议和异步 FIFO。

握手协议适用于低速、偶发的数据传输。源时钟域把数据放上总线，然后拉高一个valid信号；目的时钟域用两级同步器采valid，采到之后读取数据，然后回一个ack；源时钟域收到ack后撤销valid。整个过程数据总线保持稳定，直到握手完成。

异步 FIFO 适用于高速、连续的数据流。FIFO 的读写指针分别用各自的时钟域计数，通过格雷码（Gray Code）同步到对方时钟域。格雷码的特点是相邻数值只有一位变化，所以即使采样时刻有偏差，也只会采到相邻的两个值之一，不会出现大幅跳变。PDS 里可以直接调用 FIFO IP 核，配置成异步模式，工具会自动处理格雷码转换和同步逻辑。

提示：用异步 FIFO 的时候，一定要确认 IP 核的同步器级数。有些 IP 默认是两级，如果时钟频率超过 200MHz，建议手动改成三级。另外，FIFO 的深度要算够，深度不够会导致溢出或读空，这个在仿真阶段就要验证。

4.3 异步时钟约束的写法与验证

回到约束层面。对于异步时钟域，标准做法是：

set_clock_groups -asynchronous -group [get_clocks clk_a] -group [get_clocks clk_b]

set_clock_groups比逐条写set_false_path更清晰，也更不容易漏。它告诉工具"这两组时钟完全异步，它们之间的路径不用分析"。

但这里有个陷阱：set_clock_groups会排除所有跨时钟域的路径，包括那些你其实希望有时序关系的路径。比如你有一个时钟域 A 到时钟域 B 的路径，虽然时钟异步，但你通过握手协议保证了数据稳定，这条路径确实不需要时序分析，那没问题。但如果你有一条路径是从 A 到 B 的组合逻辑直连，没有任何同步措施，set_clock_groups会让工具忽略它，时序报告显示通过，实际上板可能出错。

所以我的做法是：先写set_clock_groups，然后在时序报告里专门检查跨时钟域的路径，确认每一条都有对应的同步逻辑。PDS 的时序报告可以按时钟域过滤，把跨时钟域的路径单独列出来，一条条核对。

5. 时序报告解读与常见问题排查

5.1 读懂 Slack：正负值的含义与优化方向

时序报告里最重要的指标是Slack。Slack = 要求时间 - 到达时间。正 Slack 表示满足时序，负 Slack 表示违反时序。Slack 越大，余量越足。

PDS 的时序报告会列出每条路径的详细分解：时钟偏斜、逻辑延迟、布线延迟、建立/保持时间。如果 Slack 是负的，先看是哪一部分占了大头。如果是逻辑延迟大，说明组合逻辑太深，需要插流水线；如果是布线延迟大，说明布局太分散，可以用set_location把相关逻辑约束到相邻区域；如果是时钟偏斜大，说明时钟树没平衡好，需要检查时钟约束是否完整。

一个实用的技巧是看WNS（Worst Negative Slack）和TNS（Total Negative Slack）。WNS 是最差的 Slack，TNS 是所有负 Slack 的总和。如果 WNS 是 -0.5ns，TNS 是 -2ns，说明只有少数几条路径有问题，局部优化即可；如果 WNS 是 -2ns，TNS 是 -200ns，说明整体时序都很紧张，可能需要降低时钟频率或者重构架构。

5.2 常见时序违反的排查速查表

这张表是我自己踩坑总结的，基本上覆盖了 80% 的常见问题。特别说一下复位信号：很多新手直接用异步复位，不经过同步器，结果复位释放时正好落在时钟沿附近，导致部分寄存器复位了、部分没复位，系统行为诡异。正确的做法是异步复位、同步释放：复位信号用两级触发器同步到目标时钟域再使用。

5.3 实操心得：约束文件的组织与版本管理

最后分享几个约束文件管理的经验。第一，约束文件要分模块写。不要把所有约束堆在一个.sdc文件里，按功能拆成clocks.sdc、io.sdc、exceptions.sdc，用source命令包含进来。这样改起来清晰，也不容易误删。

第二，每条约束都要写注释。特别是 IO 约束，把数据手册的页码、计算公式、PCB 走线长度都写进去。过三个月再回来看，没有注释你根本想不起来那个 2.3ns 是怎么来的。

第三，约束文件要纳入版本管理。时序约束和 RTL 代码一样重要，每次修改都要记录原因。我见过太多项目因为约束文件被误改，导致上板失败，排查半天才发现是约束的问题。

第四，时序报告要存档。每次布局布线后的时序报告都保存一份，对比不同版本的 Slack 变化。如果某次修改后 Slack 突然变差，可以快速定位到是哪次改动引入的。

提示：PDS 支持report_timing命令导出时序报告，可以加-max_paths 100导出前 100 条最差路径，方便分析。建议在工程脚本里自动化这一步，每次编译后自动生成报告。

6. 从约束到上板：一个完整的验证闭环

时序约束写完、时序报告通过，不代表上板一定能跑。我习惯做一个上板验证闭环：先用简单测试模式验证时钟和复位，再用伪随机数据验证数据通路，最后跑满速压力测试。

具体来说，第一步用 LED 闪烁或者计数器输出验证时钟频率是否正确。PDS 里可以用create_clock定义的时钟驱动一个计数器，分频后输出到 LED，用示波器或者逻辑分析仪测频率。如果频率不对，说明 PLL 配置或者时钟约束有问题。

第二步用伪随机序列（PRBS）验证数据通路。发送端生成 PRBS 数据，接收端比对，统计误码率。这一步能发现大部分时序相关的间歇性错误。如果误码率随温度变化，基本可以确定是时序余量不足。

第三步跑满速压力测试，同时用温控设备改变环境温度，观察误码率变化。如果常温下没问题但高温下出错，说明建立时间余量不够；如果低温下出错，说明保持时间余量不够。根据测试结果回头调整约束或者优化逻辑。

这个闭环看起来麻烦，但比上板后发现偶发错误再回头排查要省时间得多。特别是 RGMII 这种高速接口，时序问题往往表现为偶发丢包，不跑压力测试根本发现不了。

我个人在实际操作中的体会是：时序约束的功夫，一半在写约束，一半在读报告。写约束靠的是对器件和接口的理解，读报告靠的是对时序模型的理解。两者缺一不可。刚开始可能会觉得约束很繁琐，但当你经历过几次因为约束缺失导致的上板失败之后，就会明白这些看似"形式主义"的约束，其实是项目稳定性的基石。