综合属性 Synthesis Attributes：指导工具的代码注解
更新时间：2026-09-24。本文是「集成电路大类 · 芯片设计」进阶层（intermediate） 的一篇。写 RTL 时你其实在同时和两类工具对话：仿真器逐周期执行你的代码，综合器则把代码翻译成门级网表（流程见逻辑综合——RTL 到门级网表）。综合属性（synthesis attribute，也叫 pragma） 就是专写给后一类工具看的「代码注解」：它不改变任何逻辑功能，却能告诉综合器这块存储该映射成 BRAM 还是 LUT、这个信号不许优化掉、这两级寄存器是跨时钟域同步器。属性用对了能解决真实的面积、时序和调试问题，用错了则会制造「仿真全过、上板跑飞」的诡异事故。
本文要回答的问题
- 综合属性是什么，写在代码里为什么仿真器「看不见」、综合器却照做？
(* ram_style *)、use_dsp、keep、mark_debug、ASYNC_REG、max_fanout各解决什么问题，怎么写？- 老牌的
full_case/parallel_case为什么被公认为危险，现代 SystemVerilog 用什么替代？ - Xilinx Vivado、Intel Quartus、Synopsys Design Compiler 的属性名互不相同，跨平台代码怎么办？
- 为什么说「先写干净可读的 RTL，属性只在确有必要时才加」？
一、属性的本质：非功能的工具指令
先用一句话划清边界：属性不是逻辑。同一份 RTL，加不加 (* ram_style = "block" *)，仿真波形逐拍完全一致；变化的只是综合器在「资源推断」和「优化」环节做出的选择。它更像编译器的编译选项（-O2、#pragma pack），只不过把开关贴在了具体的信号、数组或模块旁边。
理解这一点，就理解了属性最大的风险来源：它只对综合器生效。仿真器按语言标准直接忽略 (* ... *)，于是你在属性里表达的意图，仿真从不检查。若属性和代码本身的行为打架，仿真一路绿灯，上板后的网表却是另一副样子。
这张图给出了判断一切属性用法对错的总原则：凡是可能改变电路行为语义的属性，都值得警惕；凡是只在行为等价的实现之间做选择的属性，才是安全用法。ram_style 在 BRAM 和分布式 RAM 之间二选一，两者功能等价，属安全；full_case 可能让综合器对未覆盖输入输出任意值，和仿真行为不等价，属危险。
属性可以贴在不同层级的对象上：信号和数组声明前最常见，端口、模块名、例化单元甚至整个架构（architecture）前也可以贴。作用域跟着对象走——贴在模块上的 use_dsp 对模块内所有乘法生效，贴在单个信号上的只管一处。还要记住工具面对非法属性的态度通常是「发一条 warning 然后继续」：属性名拼错、值不合法、对象不适合，综合都不会失败。这意味着属性失效几乎必然是静默的，唯一可靠的核对方式是读综合日志和报告，确认你期待的 BRAM、DSP 真的出现在资源统计里，而不是凭代码里写了属性就默认它生效。
二、两种语法形式
主流综合器接受两种写法。第一种是 SystemVerilog/Verilog-2001 的标准属性语法，形如 (* 名字 = "值" *)，放在声明前面：
(* ram_style = "block" *) logic [31:0] mem [0:1023];
(* keep = "true" *) logic dbg_pulse;
(* ASYNC_REG = "true" *) logic sync_q1, sync_q2;第二种是更古老的 pragma 注释，用特殊关键字嵌在注释里，不同工具关键字不同：
// synthesis attribute ram_style of mem is block // 通用 synthesis 约定
// syn_ramstyle = "block" // Synopsys 风格
(* ramstyle = "M9K" *) reg [7:0] mem [0:511]; // Intel Quartus 风格新代码一律优先用 (* attr *)：它是语言语法的一部分，编译期可解析、拼写错误工具会告警；注释型 pragma 拼错了只是一行普通注释，工具静默忽略，排查起来非常折磨。
三、控制资源推断：ram_style、rom_style 与 use_dsp
综合器面对一个二维数组，要自己猜该用触发器、分布式 RAM（LUT 拼）还是专用 BRAM 硬块，推断规则详见存储推断：RTL 怎么写才会被综合成 BRAM/SRAM。推断通常是对的，但有时你明确知道自己的取舍——比如一块 64 深度的小 FIFO，用 BRAM 浪费，用 LUT 反而省布线——这时就用属性拍板：
// 强制用块 RAM（大容量、时钟同步读、省 LUT）
(* ram_style = "block" *) logic [15:0] buf_hi [0:4095];
// 强制用分布式 RAM（小容量、低延迟、可异步读）
(* ram_style = "distributed" *) logic [15:0] fifo_lo [0:63];
// ROM 同理：block 走硬块，distributed 进 LUT
(* rom_style = "block" *) logic [7:0] sine_tab [0:255];use_dsp 控制算术运算进不进 DSP 硬块。小型乘法铺成 LUT 可能延迟更低、布线更灵活；大位宽乘加进 DSP 则省大量逻辑且时序更好：
logic signed [17:0] a, b;
logic signed [35:0] p;
(* use_dsp = "yes" *) logic signed [35:0] m_dsp; // 强制进 DSP48
(* use_dsp = "logic" *) logic signed [35:0] m_lut; // 强制用 LUT 实现
assign m_dsp = a * b;算一笔资源账就能体会这种选择的分量。一个 1024×32 位的数组，容量是 32768 bit：映射成一块 BRAM 只占一个硬块；映射成触发器则需要 32768 个寄存器，外加地址译码和读写控制，往往吃掉几千个 LUT——两者相差几十倍。反过来，一个深度只有 16 的查找表硬塞进 BRAM，整块 36Kbit 的块 RAM 被占用却只用了几百 bit，同样是浪费。ram_style 的价值就是让你在看清数组深度、位宽和访问模式后替工具做这道算术题，而不是把命运全交给推断规则。
这类属性共同的安全前提是：先让 RTL 写法本身满足推断条件。数组带了复位、读写时钟不一致，再贴 ram_style 也推不出 RAM——工具通常会发一条 warning 然后无视属性。综合后应养成翻日志的习惯：看到 inferred RAMB36 之类的提示才算落地，如果报告里出现的是寄存器阵列，说明属性被忽略了，要回头查代码写法。永远先修代码，不要指望属性补救。
四、保留与调试：keep、syn_keep 与 mark_debug
综合器会积极删掉它认为「没用」的东西：只被观察、不驱动任何输出的中间信号，会在优化阶段消失。这对面积是好事，但调试时是灾难——你想抓的信号在网表里根本不存在。
// keep：保留该信号线，防止被优化合并或删除
(* keep = "true" *) logic dbg_pulse;
// syn_keep：多家工具都认识的通用同义词，可移植性更好
(* syn_keep = 1 *) logic fsm_beat;
// mark_debug：Vivado 综合后把信号接入 ILA 在线逻辑分析仪
(* mark_debug = "true" *) logic [3:0] state;mark_debug 的信号经常同时需要 keep：前者负责把信号引到调试核，后者保证信号在布线优化中存活。模块层级也可以保留，(* keep_hierarchy = "yes" *) 能阻止子模块被打平，方便对某个 IP 单独观察和时序收敛。
dont_touch 更强，作用在网表对象（单元、层级、端口）上，连端口优化和缓冲插入都禁止，一般用于保护手工例化的硬宏或 IP。两者都切忌到处贴——保留信号等于给优化器立路障：本来能合并的逻辑被保留成冗余节点，面积、功耗、时序一起变差。
调试场景下典型的搭配是一条完整链路：先用 keep 保证信号活着，再用 mark_debug 把它引进调试核，然后在工程里设好触发条件和采样深度。采样深度也有成本：ILA 本身要用 BRAM 存波形，抓 32 个信号、深度 4096，背后就是十几万块 RAM 比特被调试核占用，这些资源在调试构建里无关紧要，却绝不能跟进度量版本。签核（signoff）版本必须把 mark_debug、ILA 全部清掉，并在综合报告里确认资源数回落到正常水平，否则量产芯片背着调试电路出货。团队实践中可以把调试属性集中放在专门的 include 文件里，量产时整体不引入，避免在几千行 RTL 里逐个搜删。
五、时序相关：ASYNC_REG 与 max_fanout
跨时钟域（CDC）的两级同步器需要工具特殊对待：两级寄存器要放得尽量近、布局在同一个 SLICE/单元簇里，避免第一级采样到亚稳态后因走线延迟过长而连累第二级。
(* ASYNC_REG = "true" *) logic q1, q2;
always_ff @(posedge dst_clk) begin
q1 <= async_in; // 第一级：可能亚稳
q2 <= q1; // 第二级：完成同步
end下图把常用属性按它们作用在综合流程的哪个环节排开：资源类属性在翻译与推断期生效，keep/max_fanout 在逻辑优化期生效，ASYNC_REG、use_dsp 则一直影响到工艺映射与布局。
为什么「就近」这么重要，要从亚稳态说起。第一级寄存器在时钟沿采到一个正在跳变的异步信号时，输出不会立刻变成干净的 0 或 1，而是先进入一个不确定的中间电平，再用一段随机时间收敛。这段收敛时间必须小于一个时钟周期，第二级才能采到稳定值。两级寄存器之间走线越短、负载越轻，留给收敛的余量就越大，平均无故障时间（MTBF）也就越长。ASYNC_REG 的实际效果就是把 q1、q2 约束进同一个布局单元并限制中间布线——它提高的是 CDC 链路的物理健壮性，而不是逻辑上的同步能力（同步能力只来自「至少两级」这个结构本身）。
读图时注意图右侧的两条注释，它们对应两个高频误解。其一，(* max_fanout = 50 *) 不是电气约束，而是优化指令：某信号驱动的负载超过 50，工具就复制寄存器或缓冲、把负载拆成几组，用来压下高扇出网络的布线延迟。一个使能信号若同时驱动 500 个负载，单条网络的容性延迟可能把整条路径拖成关键路径；拆成 10 组、每组 50 个负载后，每条支线短得多，代价只是多了 9 个复制寄存器。阈值要按工艺和频率试，设得太小会让复制寄存器泛滥，面积和时钟功耗反受其害。其二，ASYNC_REG 不会自动生成时序例外：它只告诉工具这是同步器、请就近摆放，STA 仍会按普通路径分析这条本来就无法满足建立时间的线。真正的豁免要靠 SDC 约束实战：create_clock、false_path 与 multicycle 里的 set_false_path 或异步时钟分组。属性和约束各管一段，缺一不可。
六、full_case 与 parallel_case：经典的危险pragma
这两个老牌注释属性常年出现在教训清单上。// synthesis full_case 告诉综合器「case 已经覆盖全部输入，未列出的项你随便处理」；parallel_case 告诉它「各分支互斥，按并行而非优先级译码」。
危险在于仿真器完全无视这两句话，于是分歧出现了：
always @(*) begin
y = y; // 未列全时仿真保持旧值
case (sel) // synthesis full_case parallel_case
2'b00: y = a;
2'b01: y = b;
// 缺 10、11；若 sel 位重叠，仿真还按先后优先级
endcase
end- 缺了
default时，仿真里未覆盖输入让y保持原值（隐含锁存语义），综合器却被full_case授权输出任意值（dont-care），两边功能直接不同； - 分支条件重叠时，仿真按书写顺序取优先级，
parallel_case却让综合器做成并行译码，结果又不同。
现代的正确做法分两步：RTL 显式写全 default、让分支真正互斥，把意图写进逻辑而不是注释；需要工具帮你查遗漏时，用 SystemVerilog 的 unique case / priority case：
unique case (sel) // 仿真器也会检查：分支须互斥且覆盖
2'b00: y = a;
2'b01: y = b;
default: y = '0;
endcaseunique/priority 是语言关键字，仿真器同样执行、违例时会在运行时报错——检查发生在两侧，而不是只在综合侧，这正是它们比旧 pragma 安全的根本原因。
还有一个组合逻辑特有的陷阱值得点破：always @(*) 里没写全的 case 若也没有 default，仿真中 y 保持旧值，综合器为此推断出的是一个锁存器（latch），而不是你大概率想要的多路选择器。锁存器对时序分析极其不友好，还容易在使能沿附近产生毛刺。正确写法永远是组合块开头先给 y 一个默认赋值，再在各分支覆盖——此时锁存器根本不会产生，full_case 也就毫无存在必要。记住一个简单判据：当你想写 full_case 的那一刻，缺的其实是一个 default。
七、常用属性速查与可移植性
下表汇总本篇出现的属性，决策时重点看「风险」一列：
| 属性 | 作用对象 | 效果 | 风险/注意 |
|---|---|---|---|
ram_style | 二维数组 | 选 BRAM 或分布式 RAM | 写法不满足推断条件时被无视 |
rom_style | 常量数组 | 选块 ROM 或 LUT | 同上 |
use_dsp | 算术信号/模块 | 乘加进 DSP 或铺 LUT | 值名因厂商而异 |
keep / syn_keep | 信号 | 阻止优化删除或合并 | 阻碍优化，面积/时序变差 |
dont_touch | 网表对象 | 完全不动该对象 | 过强，仅用于保护硬宏/IP |
mark_debug | 信号 | 接入 Vivado ILA 调试 | 量产前必须移除 |
ASYNC_REG | 同步器寄存器 | 两级就近布局 | 不产生时序例外，仍需 SDC |
max_fanout | 高扇出信号 | 复制驱动、拆分负载 | 阈值过激会增加面积和功耗 |
full_case/parallel_case | case 语句 | 声明全覆盖/互斥 | 仿真与综合可能不一致，已不推荐 |
跨厂商可移植性是另一个必须正视的现实：属性名大多不是标准，是各家工具的方言。
| 用途 | AMD/Xilinx Vivado | Intel Quartus | Synopsys DC 风格 | 可移植性 |
|---|---|---|---|---|
| RAM 风格 | ram_style | ramstyle | syn_ramstyle 注释 | 差，各家命名不同 |
| 乘法进 DSP | use_dsp | multstyle = "dsp" | 靠综合变量/约束 | 差 |
| 保留信号 | keep | keep / syn_keep | syn_keep | syn_keep 通用性较好 |
| 在线调试 | mark_debug | 无（Signal Tap 另选信号） | 无对应 | 不可移植 |
| 同步器 | ASYNC_REG | 自动识别 + SDC | 自动识别 + SDC | 差，靠约束兜底 |
| case 检查 | 支持旧 pragma | 支持旧 pragma | 支持旧 pragma | 都应改用 unique/priority |
实践中的应对是分层处理：可综合的功能代码只放跨工具通用的属性（如 syn_keep），厂商专属属性收进条件编译段或单独的 include 文件（如 ifdef XILINX 包裹 ram_style，ifdef INTEL 包裹 ramstyle），调试和时序属性尽量用工具约束文件（XDC/SDC/QSF）承载，不污染 RTL。换平台时只改一层，而不是满文件搜属性名。
收尾回到那条贯穿全篇的纪律：先写干净、可读、按推荐范式写就的 RTL，让综合器的默认推断发挥作用；只有当报告、资源利用率或时序数据表明确有必要时，才加最小范围的属性，并在注释里写明为什么加。每一个属性都是留给后来者（包括三个月后的自己）的「此处工具行为被人为干预过」的标记，没有理由的属性和被注释掉的代码一样，都该删掉。
这一篇在知识体系里的位置
本篇处于芯片设计进阶层，回答「RTL 意图和工具实现之间出现分歧时，用什么手段精确干预」。向上承接综合全局，逻辑综合——RTL 到门级网表讲清翻译、优化、映射三阶段，属性正是挂在这三个阶段上的开关；最常用的 ram_style 必须配合存储推断知识使用，见存储推断：RTL 怎么写才会被综合成 BRAM/SRAM；而 ASYNC_REG 之后的 CDC 时序豁免、max_fanout 与综合时序目标，都在 SDC 约束实战：create_clock、false_path 与 multicycle 里完成——属性和 SDC 是同一件事的两半：一个贴在代码旁管实现选择，一个站在工程外管时序签核。
总结
一句话总结：综合属性（synthesis attributes / pragmas）是写在 RTL 里、只对综合器生效、不改变逻辑功能的工具注解——ram_style/rom_style 在 BRAM 与分布式 RAM 间选择、use_dsp 控制乘加是否进 DSP 块、keep/syn_keep/dont_touch 保留信号与层级防优化、mark_debug 引出在线调试信号、ASYNC_REG 让 CDC 同步器就近布局、max_fanout 触发驱动复制；它最大的风险是仿真器忽略、综合器照做，老牌 full_case/parallel_case 正因此可能造成仿真与网表语义不一致，现代写法是 RTL 显式补全 default 并用仿真也会检查的 unique/priority case；属性名是厂商方言、可移植性差，通用属性留 RTL、厂商属性收进条件编译、调试与时序意图交给 XDC/SDC；永远先写干净可读的 RTL，等报告证明确有必要，再加最小范围的一个属性——默认推断优先，人工干预留痕。