企业官网建设流程全解析

开头直接进入场景。

在FPGA工程里，综合（Synthesis）其实是一场“代码意图翻译”的过程，但麻烦的地方在于，综合器很多时候是凭着启发式规则去猜你想要什么。RAM要不要用BRAM？乘法器要不要进DSP48？打拍寄存器会不会被优化合并？这些光靠代码本身，工具往往会给个“它觉得合理”的方案，未必是你真正想要、也未必是性能最优的方案。这个时候就需要在HDL代码里写属性，或者在XDC里下约束，把意图直接递给综合器。

我接上一篇继续聊。上一篇把综合属性最基础的东西过了一遍，包括属性写到哪、怎么生效，这篇专门出一份够日常用的属性清单，结合我实际工程里用过、踩过坑的地方，把HDL和XDC两边各自的“高频干活属性”拆开讲清楚，再给几组可以直接抄作业的组合方案。内容不追求大而全，主打“打开综合报告前，你知道自己到底在为什么而设置”。

1. 先想清楚：这些属性到底是谁在听、什么时候生效

动手设置属性之前，最好先把一件事分清楚：HDL里写的(* ... *)和XDC里的set_property，在时间点上的作用范围不同。

HDL里嵌的属性，是跟着RTL代码走的。综合器读代码的过程中，看到某个属性就会调整对该寄存器的处理方式。这些属性在综合阶段生效，影响的是“代码到网表”的映射结果。比如ram_style决定RAM到底用LUT实现还是BRAM实现，use_dsp决定乘法器是进DSP48还是拿LUT拼，keep决定某根网络会不会被综合器优化掉。

XDC里的属性则分两类。一类是负责把综合阶段已经确定的逻辑“稳住”，在后端布局布线阶段持续生效，比如DONT_TOUCH、MAX_FANOUT、ASYNC_REG。另一类是纯物理层的约束，比如引脚位置、Pblock区域边界、BEL绑定，这类跟综合的关系没那么直接，但对结果影响很大。

一张大致的分工表：

实际工程里最常见的做法是：HDL属性跟着代码封装走，保证换被别人移植、复用的时候，意图不丢；XDC属性跟着工程走，专门处理跟具体芯片资源、时序和物理布局相关的信息。两者不是替代关系，是配合关系。

还有一点必须提前说：属性不是“写了一定生效”的承诺。综合器在特定条件下可能忽略、降级或覆盖某个属性，最后结果要以综合报告中的实际映射为准。我见过不止一个同事盯着ram_style = "block"以为肯定用了BRAM，结果综合报告显示依旧是LUTRAM——原因是存储器容量太小，工具判断BRAM不划算，直接把属性忽略了。

2. HDL里写属性，相当于给综合器递纸条

这一章是HDL属性的大头。我会按“资源映射类、信号保护类、时序意图类”三个维度展开，每个属性都带着代码用法和适用场景。

2.1 存储资源映射：ram_style / rom_style

RAM是FPGA设计里的常客。用一个二维数组声明一块存储器后，综合器会根据写法自动推断成分布式RAM（LUT构成的RAM）或者BRAM（块RAM）。但有些场景下，工具的选择并不理想：

• 存储器容量不大不小，工具觉得用BRAM浪费，用了分布式RAM，结果LUT资源被大量占用；
• 存储访问频率极低，但工具偏偏用了BRAM，导致BRAM紧张；
• 代码在多个模块里混着写RAM，工具风格不统一，调试困难。

此时直接在数组定义上加属性最干脆：

(* ram_style = "block" *) reg [DATA_WIDTH-1:0] mem [0 : DEPTH-1]; (* ram_style = "distributed" *) reg [DATA_WIDTH-1:0] small_mem [0 : 7];

ram_style的常用取值有block、distributed、ultra（UltraScale+系列才支持），还有registers，意思是直接用寄存器搭，不走RAM资源。选择逻辑并不复杂：

与之配套的是rom_style。如果你的数组在初始化后只读，属于ROM场景，同样可以在声明处设置：

(* rom_style = "block" *) reg [31:0] lut_table [0:255]; initial begin $readmemh("table.mem", lut_table); end

这里有一个过来人的提醒：不要在综合前纠结“这个RAM块到底应该block还是distributed”，先把代码仿真跑通过。RAM的映射属性改变，不影响功能模型，只会影响最终实现资源，所以可以在仿真阶段完全无视它，等准备综合时再回头设置。写属性时也别同时写多个互相矛盾的style，综合器通常会按优先级选某一个，并给出WARNING，但有些老版本工具的行为未必可预期。

2.2 运算资源映射：use_dsp与乘法器风格

在FPGA里做乘法、乘加、乘累加，最高效的路径是走芯片内嵌的DSP Slice，而不是用通用逻辑搭建。但综合器并不总是把乘法器识别进DSP，尤其当乘法器位宽不匹配DSP硬核结构，或者周围逻辑太复杂时，工具可能退化成LUT实现。资源还好说，关键是时序：LUT拼乘法器的组合延迟通常远大于DSP48内部的硬乘法器延迟。

这个时候直接给乘法器打上use_dsp属性：

(* use_dsp = "yes" *) reg [15:0] acc; always @(posedge clk) begin acc <= acc + a * b; end

也可以针对某个模块实例在XDC里单独设置：

set_property use_dsp yes [get_cells u_mac_inst]

这里要提醒一点：use_dsp = "yes"是“希望映射到DSP”的请求，不代表一定成功。如果你的乘法位宽是24bit × 24bit以上，DSP48位宽不够，工具依然会拆分或改用LUT。判断依据是综合报告中的“DSP48 usage”条目。如果你看到乘法器数量明显少于逻辑里实际出现的乘法次数，大概率有些乘法逃逸了DSP映射。

use_dsp还有一个取值是no，强制不走DSP。这个用法在低功耗设计里很常见：DSP48的功耗在部分器件上可能高于同规模LUT电路，例如纯LUT乘法器在Leakage功耗上有时更友好，但这需要结合具体器件做功耗评估，不要凭感觉滥用。我的一般原则是：面积有压力时尽量走DSP，功耗敏感时评估后再说，时序紧张时优先DSP。

2.3 信号保持与网络保护：keep / keep_hierarchy / dont_touch

这是HDL属性里最容易踩坑的一组。先说keep：

(* keep = "true" *) wire debug_wire;

keep = "true"的意思是告诉综合器：这根网络你就算觉得多余，也别给我优化掉，后头布局布线阶段还要用。典型场景包括：给调试逻辑观察用的中间信号、在综合后仿真中需要观察的内部节点、跨模块的抽象边界信号。

dont_touch比keep更霸道：

(* dont_touch = "true" *) wire critical_wire;

它同时作用于综合和实现两个阶段，意思是“这个网络所在逻辑块，你不许折叠、不许重定时、不许探测后乱动”。通常用在跨时钟域同步器、需要保证物理完整性的敏感逻辑上。

生产经验里还有一条铁律：keep和dont_touch不要乱加。如果把一个高频翻转、处于优化关键路径中间的网络加上dont_touch，综合器将失去对该网络的优化自由度，时序可能不升反降。正确的姿势是：先不加属性综合一次，看报告里哪部分网表被优化得不符合预期，再有针对性地加，而不是进门就全锁死。

keep_hierarchy作用在模块上，维持模块边界不被展平（flatten）：

(* keep_hierarchy = "yes" *) module foo (...);

模块边界保持住之后，综合、布局布线的分区块调试都方便，Pblock和后续物理约束也更容易落到明确的实例上。代价是全局优化少了跨模块边界合并的机会，时序可能受损。所以我的习惯是：初期调试用keep_hierarchy，代码稳定、需要大力优化时序时，把它拿掉再跑一轮对比。

2.4 同步器与状态机：async_reg和fsm_encoding

跨时钟域这个老话题，在属性层面有一个非常关键的存在：async_reg。

(* async_reg = "true" *) reg [1:0] sync_chain; always @(posedge dclk) begin sync_chain[0] <= async_in; sync_chain[1] <= sync_chain[0]; end

标记成async_reg后，综合器和布局布线器会把这些寄存器视为异步同步器链的一部分，采取特殊处理：尽量保证同一同步器链上的寄存器靠在一起，避免综合的retiming或优化把打拍链折叠、拆分。这一个属性在跨时钟域代码里的价值非常高。

有同学问我：不写async_reg，是不是同步器就一定出问题？也不是一定，但风险明显增加：布局时两级FF可能被拉得很远，或者优化器认为中间信号没有实际作用直接合并掉，导致亚稳态防护失效。在XDC里补设也行：

set_property ASYNC_REG true [get_cells sync_chain_reg[*]]

状态机编码方式用fsm_encoding控制：

(* fsm_encoding = "one_hot" *) reg [3:0] state;

常用取值包括one_hot、gray、sequential、johnson。热独码（one-hot）状态机翻译逻辑简单、速度好，但寄存器多；格雷码（gray）寄存器少、适合连续变化场景；sequential和johnson介于两者之间。Vivado默认会根据状态数量和时序约束自行选择，通常不用手工干预。只有在自动选择明显不合理、或者你有明确的面积优化目标时，才用手工指定。

3. XDC这一半：从综合到布局布线的接力

HDL属性解决的是“综合阶段代码意图”，但很多约束在综合完了之后，还必须继续影响后端实现。XDC才是那个从综合一路传到布局布线的载体。

3.1 用XDC统一设置DONT_TOUCH与MAX_FANOUT

很多时候，你不想为了加一个属性去改动HDL源码，尤其当代码是IP核、第三方交付或已经版本冻结时。XDC可以在不碰源码的情况下，用set_property把这些属性挂到指定单元上。

防止网络被优化掉：

set_property DONT_TOUCH true [get_nets {sync_chain_gen[0].reg_chain}]

限制扇出：

set_property MAX_FANOUT 64 [get_nets rst_vio_n]

MAX_FANOUT非常实用。高扇出信号（时钟使能、复位、低速控制信号）会让后端的布线拥塞恶化。给工具一个扇出上限，它综合阶段就会复制驱动寄存器来分担扇出。但这个值不是越小越好。过小的MAX_FANOUT会生成大量复制寄存器，占用面积、增加时钟负载。以我的经验，普通控制信号按整棵树的实际分布设置，一般从64或128起步；复位、时钟使能这类特别结构化的信号，配合全局时钟资源和复位树结构考虑，不能盲目压小。

3.2 通过综合选项控制大局

属性是“点”上的控制，综合选项是“面”上的控制。

在Vivado综合界面中的Synthesis Settings里，有几个常用选项值得一提：

• -flatten_hierarchy：决定全局展平等级。默认是rebuilt，即展平后再按逻辑重建层级。如果设成full，模块边界完全消失，优化力度最大；设成none，边界保持，调试方便但优化受限。
• -retiming：允许综合器在寄存器之间移动组合逻辑，平衡路径延迟。这个选项对流水线结构收益明显，但对跨时钟域同步器链可能造成破坏——这也是为什么async_reg属性要配合使用。
• -shreg_min_size：寄存器链低于多少长度时，综合成移位寄存器（SRL）而不是普通FF。默认通常是3，也就是说3级以上的移位寄存器链会考虑映射到SRL。
• -fsm_extraction：全局的状态机编码策略。

用命令行跑综合时，示例：

synth_design -top top -part xc7k325tffg900-2 \ -flatten_hierarchy rebuilt -retiming

需要提醒的是，-retiming不是免费的——它可能改变仿真时序，也会拖长综合时间。在项目后期做时序收敛时，跑一版带retiming和跑一版不带retiming的结果对比，往往比单纯调属性更能说明问题。

3.3 SRL与RAM的尺寸阈值控制

移位寄存器和RAM在XDC里也有对应的“家族式”控制属性，这组容易被忽略但在后端很实用。

假设你的设计里有大片深度不等的移位寄存器链，工具默认把超过3~4级的部分综合成SRL。SRL占LUT资源少，但带来的问题是：SRL的输出是异步的，不能像FF那样被“时钟采样到后立即输出”。如果你的移位链是从时钟域A同步到时钟域B的“脉冲展宽链”，SRL可能引发功能问题。

此时可以在XDC里限定：

set_property SHREG_MAX_SIZE 2 [current_design]

值越小，越倾向于用寄存器，代价是LUT消耗增加。反过来，如果LUT资源紧张、寄存器的时序很宽裕，那就把SHREG_MAX_SIZE调大，让更多移位链并进SRL。

RAM尺寸阈值则是RAM_MAX_SIZE：

set_property RAM_MAX_SIZE 1024 [current_design]

含义比较直接：超过该深度的存储器用BRAM，小于等于该深度用分布式RAM。这种全局阈值控制和单个ram_style属性互为补充：属性管局部，阈值管全局默认。

这组XDC属性在工程里应用得不多，但非常值得一试。早期我处理一个LUT溢出报警时，仅仅把全局RAM_MAX_SIZE降下来，就省出了8%的LUT资源，比逐个模块改RAM属性省事得多。

4. 几个我能直接抄作业的组合方案

属性单独用是小打小闹，组合起来才是日常工程实战。下面是我处理过、也帮同事解决过的高频场景组合，代码和约束可以直接参考。

4.1 高扇出复位网络：MAX_FANOUT + 层级保持

复位信号扇出特别大，是综合中最常遇到的问题之一。扇出过大的复位导致布线长、翻转功耗高、时序收敛困难。

一个比较实用的处理流程是：

第一步，查扇出。综合后在报告中看复位树的扇出数目，不满足预期时再动手，否则别给自己加戏。

第二步，在XDC里对复位网络设置扇出上限：

set_property MAX_FANOUT 128 [get_nets sys_reset_n]

第三步，把复位逻辑和普通功能性逻辑尽量分开层次，必要时对复位模块使用keep_hierarchy，保证复位树的形态在后端可预期。

需要注意：对全局复位不要用过小的MAX_FANOUT。FPGA里有一个专用的全局置位/复位网络，Vivado对复位树有完整的处理机制，你强行复制复位寄存器，反而可能破坏工具对复位信号的全局规划。我见过有人把复位扇出上限设成8，结果整版面积爆炸、时序烂得一塌糊涂。复位信号的处理大头应该放在设计层面：能不能异步置位、同步释放，能不能局部复位替代全局复位，这些比一个属性值更关键。

4.2 跨时钟域同步器：ASYNC_REG + DONT_TOUCH

CDC同步器代码写起来只有几行，但保护不好，综合器一个重定时（retiming）操作就可能把两级打拍寄存器合并掉，或者把它们移到负载端。

推荐组合：

(* async_reg = "true", dont_touch = "true" *) reg [1:0] sync_ff;

对应的XDC一侧，如果属性没写进HDL，也可以这样上：

set_property ASYNC_REG true [get_cells sync_ff_reg[*]] set_property DONT_TOUCH true [get_cells sync_ff_reg[*]]

这里再补充一个实战细节：同步器不要用MAX_FANOUT去压扇出。两级同步器的目的就是接收异步信号、产生本地时钟域下干净的信号。如果它的输出扇出极大，正确做法是在第二级输出之后额外加一个本地扇出寄存器，或者给它单独做一个使能路径，而不是把同步器寄存器直接复制成多个驱动源。复制同步器寄存器等于把“异步事件”复制成多份，会造成逻辑上的同步不足。

4.3 乘法器与MAC密集场景：USE_DSP + 全局DSP策略

做滤波、矩阵运算、通信相关设计时，乘法器到处都是。这类设计对DSP48的利用效率直接影响面积和时序。除了一条条给乘法器加use_dsp，更系统性的做法分两步：

第一步，在综合设置里把DSP优化策略打开，或者手动指定：

set_property USE_DSP both [get_cells ...]

第二步，对局部控制不了的场景在RTL里做重构。比如把一个乘法分别放在不同的always块里，没有统一的使能结构，DSP推断条件不一定成立；把这些乘法统一进同一个MAC循环结构，工具就容易整体映射到DSP。

注意，DSP资源的使用往往不是“能映射就一定映射最好”。当DSP48数量不足时，工具会把部分乘法器挪到logic里；当DSP48大量闲置时，也不必为了用而用。在实际项目里我会这样把握：先跑一版不加任何DSP属性，看综合报告里DSP48和LUT占用比例，再针对关键乘法器加属性。直接全加use_dsp = "yes"常常是给自己找额外工作。

4.4 存储阵列的“大改小改”：ram_style + RAM_MAX_SIZE

存储器资源控制的核心思想是：先全局后用局部，先阈值后属性。

比如你希望代码里所有深度小于32的存储尽量用寄存器，深度大于256的用BRAM，中间地带交给工具，可以：

set_property RAM_MAX_SIZE 256 [current_design]

然后跑综合，看报告。如果还有某块特定存储映射得不合适，再回到HDL里给那个数组单独设置ram_style。

这套流程看起来平淡，其实是最稳的。你直接进到HDL里给每个数组写ram_style，一是代码噪点多，二是你未必能精确预期不同深度的最优实现方式。全局阈值设置等于给工具划了一条清晰的分界线，报告里资源比例一目了然，再针对异常点补刀。

5. 属性没生效？我踩过的坑和排查思路

写属性最让人抓狂的不是不会写，而是写了半天综合报告一看，完全没有变化。下面这些坑我基本都踩过，整理出来供你排查时参考。

5.1 属性“失效”的几个原因

第一，属性名或取值拼写错误。Vivado不认识非法属性时会报WARNING，但综合照常跑完。常见的低级错误包括ram_style写成了ram_stye、async_reg写成async_rag。排查方法很直接：综合日志中搜“attribute”或“unknown attribute”。

第二，属性挂在错误的层级上。比如给reg加属性时，作用目标其实是一个内部信号；给module实例加属性时，用get_cells抓错了路径。这种情况下，综合器可能连警告都不给，就是静默忽略。

第三，综合选项覆盖了属性。某些综合策略或选项设置会改变属性的优先级。例如-flatten_hierarchy none加上keep_hierarchy同时出现时，模块边界已经保持住了，再设置dont_touch在网络级别上不一定有额外效果。遇到这种情况，把综合策略和属性放在一起对比，别只看属性本身。

第四，目标资源物理上不支持。比如UltraRAM在器件里根本不存在，你还给RAM打了ram_style = "ultra"，工具只能回退到BRAM并给出警告。

5.2 综合报告怎么看

综合完成后，打开Synthesis Report，重点看几处：

• Resource Utilization区域：确认LUT、FF、BRAM、DSP48的计数符合预期。如果设置了ram_style = "block"但BRAM数量不变，立刻警觉。
• Report Cell Usage：结构层次的单元使用情况，看是否存在异常的小单元（比如被错误优化的逻辑）。
• 日志里的WARNING：搜attribute、constraint、ignored相关条目的关键字，Vivado会明确告诉你哪些属性没有应用到。

我自己的习惯是：任何属性在加入工程后，第一次综合必须刻意扫一眼报告，花了30秒确认“预期生效了”，而不是等到后端、布线完都跑了，才发现问题根源在综合阶段。

5.3 别把DONT_TOUCH当万能锁

这是我在合作项目里见得最多、也最想劝退的用法：为了“保险”起见，到处加DONT_TOUCH，希望这些逻辑不被工具碰、不被优化。

事实是，DONT_TOUCH是抑制优化的利器，同时也是抑制优化的毒药。它一旦加上，工具就无法对该区域内Logic做合理重组、合并、重定时。你用DONT_TOUCH守住了一个小模块，付出的代价可能是整个关键路径上的优化机会全没了。

所以我的原则是：能用KEEP就用KEEP，能只在综合阶段控制就不用DONT_TOUCH，能用keep_hierarchy保模块就别保到网络级别。越靠后的阶段、越向下的层级，加锁代价越大。

5.4 综合前后仿真差异：其实属性也要背锅

有一次综合后仿真功能错误，我最初怀疑是时序建模问题，排查许久才发现是fsm_encoding设置导致状态机的初始化特征变了。属性不只是资源层面的调控，它改变的是网表结构，而网表结构变化必然影响综合后仿真的行为表现。

所以当综合后仿真不过时，除了常规的时序检查，也顺手确认一遍：哪些属性影响了结构？尤其是retiming、dont_touch、keep_hierarchy这几个。如果发现综合前后不一致，优先排查是否是属性“过度约束”导致优化器没按你设想的方式工作，而不是急着修改功能代码。

有一点可以作为通用经验：任何属性方案，都要有一次“加了属性 vs 不加属性”的对比综合结果做背书。对比内容主要是资源、时序和综合后仿真结果。没有对比就没有发言权，很多网上流传的“属性神优化”其实只是那个特定场景下的偶然结果，直接搬到自己工程里未必成立。

我个人在这几年的工程实践里的体会是：属性设置水平，其实反映的是你对综合器运作机制的理解深度。你越是能预判综合器会怎么处理某段代码，你就越知道该在哪个根节点上下约束。属性不是越多越好，而是越精准越好。拿到新工程，先综合一版摸清资源底细和瓶颈路径，再回头决定在哪些关键位置补充属性；在确定方案后，把这一组属性和它的验证结果记录下来，能够大幅减少你和工程迭代的来回成本。希望这份清单里的思路和实战组合，能帮你少走几步弯路。