1. 信号保留：FPGA工程师的“救命稻草”

刚接触FPGA设计那会儿，我踩过一个大坑。当时为了调试一个复杂的时序模块，我在代码里精心埋了几个观测信号，准备用SignalTap II逻辑分析仪抓来看看波形。结果费了半天劲编译完，打开SignalTap一看，傻眼了——我最想看的那个关键寄存器信号，在列表里根本找不到！它被Quartus的综合器（Analysis & Synthesis）当成冗余逻辑，给无情地“优化”掉了。那种感觉，就像你藏好的工具被家人当垃圾扔了，急需用时只能干瞪眼。后来才知道，这几乎是每个FPGA工程师的必经之路。综合器的本职工作就是化简逻辑、节省资源、提高性能，它可不管你这个信号对你调试有多重要，只要它认为这个信号不影响最终输出，就可能下手“干掉”它。

这就是信号保留（Signal Preservation）问题。在Altera（现在是Intel® FPGA）的Quartus Prime开发环境中，我们写的Verilog或VHDL代码，首先会经过综合工具的处理。这个工具非常智能，它会进行常数传播、寄存器合并、逻辑优化等一系列操作。比如，你写了一个中间寄存器，它的值永远只依赖于某个常量，或者它的输出根本没有被任何其他逻辑使用（也就是所谓的“死代码”），综合器就会认为它是多余的，直接移除。从综合器的角度看，这完美地完成了任务：节省了一个寄存器资源，可能还简化了布线。但从我们工程师的角度看，这简直是灾难，尤其是当这些信号是我们为了调试、验证、或者某些特定架构（比如手动实例化的模块接口）而必须保留的时候。

所以，掌握信号保留技巧，本质上是在和综合器的优化算法“讨价还价”，告诉它：“嘿，这几个信号对我很重要，请手下留情，别动它们。”这就像是给你的关键代码加上了一个“免死金牌”。在Quartus里，我们主要通过与综合工具约定的“综合属性”（Synthesis Attributes）来实现这个目的。这些属性以注释的形式嵌入代码，专门指导综合工具的行为。接下来，我们就深入聊聊Quartus里那些最常用、也最管用的信号保留属性，以及我这些年总结下来的实战心得和避坑指南。

2. 核心三剑客：keep、preserve与noprune

Quartus提供了好几个用于保留信号的属性，但最核心、最常用的就是三个：keep、preserve和noprune。别看它们目标类似，但各自有明确的“管辖范围”和使用场景，用错了可能事倍功半。

2.1 keep属性：给连线（Wire）上把锁

首先来看 /* synthesis keep */。顾名思义，它的主要任务是“保持”一个网络（net）不被优化掉。在Verilog里，这通常指的就是wire型信号。

它解决什么问题？ 想象一下，你有一个复杂的组合逻辑块，输出一个wire信号temp_result。这个信号可能被送到多个地方，或者你只是想在顶层把它引出来观察。综合器在优化时，可能会将这个组合逻辑路径打散、重组，甚至将temp_result这个中间节点完全消解，直接将其逻辑合并到后续的驱动中。结果就是，你想在调试工具里找到temp_result这个信号名，发现它消失了。

怎么用？ 用法很简单。在声明wire的时候，加上综合属性就行。我个人更喜欢使用Verilog-2001标准的属性语法，因为它更清晰，与代码结合更紧密：

(* keep *) wire temp_result; // 推荐这种写法
// 或者传统的注释写法
wire temp_result /* synthesis keep */;

一个实测案例： 我曾设计过一个多级流水线的数据处理器。其中一级流水线输出一个wire [31:0] processed_data，这个数据会同时送入下一级流水线和一個性能计数模块。一开始没加keep，在综合后的网表中，processed_data这个网线不见了，它的逻辑被直接嵌入到了后续两个模块的输入逻辑里。这导致我无法单独监测这一级流水线的输出是否正确。加上(* keep *)后，这个网络被完整地保留下来，在SignalTap里看得一清二楚，调试效率大增。

重要提示： keep主要针对的是组合逻辑路径上的连线。对于寄存器（reg），它虽然也可能有效，但并非最佳选择，因为Quartus对寄存器的优化有另一套更专门的机制。

2.2 preserve属性：守护寄存器（Reg）的卫士

接下来是 /* synthesis preserve */。这位是专门用来保护寄存器的。寄存器在综合过程中面临的“威胁”和wire不太一样。综合器除了会移除无驱动的寄存器，还特别喜欢做一件事：合并冗余寄存器。比如，两个寄存器由完全相同的时钟和复位驱动，且数据来源也相同，综合器就可能把它们合并成一个，以节省资源。

它解决什么问题？ 当你明确需要保留某个特定的寄存器单元，防止它被合并或删除时，就该preserve出场了。这在调试中极其常见，比如你想观察某个状态机内部的某个状态寄存器，或者一个计数器中的某一位。

怎么用？ 同样，用在reg型变量的声明处。

(* preserve *) reg [7:0] debug_counter; // 推荐
// 或
reg [7:0] debug_counter /* synthesis preserve */;

踩过的坑： 这里有个关键点，也是我早期困惑的地方。preserve属性保证了这个寄存器单元本身不被移除或合并，但它不保证这个寄存器的输出网络（fan-out）不会被优化。什么意思？举个例子，你有一个(* preserve *) reg my_reg;，它的输出只连接到一个简单的与门assign out = my_reg & 1‘b1;。综合器保留了my_reg这个触发器，但它可能会优化掉后面那个“与1”的逻辑，直接将my_reg的输出连接到out，甚至如果out后续也被优化掉，my_reg的输出可能看起来“悬空”，但在网表里这个寄存器实体是在的。要保留从寄存器开始的后级逻辑，可能需要结合keep属性一起用。

2.3 noprune属性：防止寄存器被“修剪”

最后是 /* synthesis noprune */。这个名字很形象，“no prune”即“不修剪”。它的功能定义非常具体：防止Quartus移除那些没有直接或间接连接到顶层输出或双向端口的寄存器。

它和preserve有什么区别？ 这是最容易混淆的地方。我们可以这样理解：

• preserve 侧重于对抗“合并”和“常量传播”等优化，目标是保持寄存器个体的存在。
• noprune 侧重于对抗“删除”，目标是阻止综合器仅仅因为寄存器输出没有到达顶层端口就把它扔掉。这是一种更“宽松”的保留。一个寄存器如果加了noprune，即使它的输出看似在模块内部“终结”了，也会被保留下来。

什么情况下用？ 当你有一个内部寄存器，它的输出只用于模块内部的其他逻辑（比如控制一个内部状态机），并且这些后续逻辑也可能被优化，但你仍然希望在最终网表中看到这个寄存器时，用noprune很合适。它有点像是一个兜底条款。

(* noprune *) reg internal_state_reg; // 即使输出未到顶层，也保留

我的经验： 在大型分层设计中，有些调试寄存器可能深埋在子模块里，其输出并未引到最顶层。如果你只用preserve，当它的所有驱动逻辑都被优化后，这个寄存器本身可能还在，但它的作用很难追踪。而noprune则更强调“这个寄存器必须出现在网表中”。对于纯粹的调试信号，我有时会同时使用(* preserve, noprune *)，双保险，确保万无一失。

为了更直观，我总结了一个对比表格：

属性名	主要作用对象	核心目的	典型应用场景
keep	Wire/网络 (Net)	防止组合逻辑优化时移除或简化该网络	保留复杂的中间组合逻辑结果，用于调试或观测。
preserve	寄存器 (Reg)	防止寄存器被合并或移除（针对寄存器单元本身）	保留特定的状态寄存器、计数器，防止被常量传播或冗余合并优化掉。
noprune	寄存器 (Reg)	防止因输出未连接到顶层端口而被删除	保留那些输出仅用于内部逻辑、未引至顶层的寄存器，确保其存在于网表中。

3. 高级用法与实战中的“骚操作”

掌握了基本的三剑客，你已经能解决80%的信号保留问题了。但在实际项目中，情况往往更复杂。下面分享一些进阶技巧和常见陷阱。

3.1 属性组合使用与作用域

综合属性可以组合使用，也可以应用在模块实例上。例如，你想确保一个模块实例内部的所有寄存器都被保留（比如一个第三方IP核，你需要窥探其内部状态），可以在实例化时使用keep或preserve。但要注意，这可能会保留大量不必要的信号，增加资源消耗。

// 保留实例内部所有能保留的信号（谨慎使用！）
my_module u0 (.*) /* synthesis preserve */;

更常见的是对一组信号使用属性。你可以把属性放在一个always块或reg声明块之前，影响紧随其后的多个变量。

(* preserve *) // 这个属性会作用于下面两个reg
reg [3:0] state;
reg valid_flag;

3.2 调试属性与正式版本的平衡

这是非常实际的一个问题。你在代码里加了一堆(* keep *)和(* preserve *)，调试起来是方便了，但它们会阻碍综合器优化，导致你的设计占用更多的逻辑资源（LE/ALM）和寄存器资源，有时甚至会影响时序性能（Fmax）。

我的策略是：

1. 使用条件编译或宏定义：这是最优雅的方式。你可以定义一个调试宏，比如DEBUG_SIGNALS。

   `ifdef DEBUG_SIGNALS
       (* keep *)   wire debug_wire;
       (* preserve *) reg debug_reg;
   `endif
   

   在调试时，在Quartus工程设置或文件头里定义这个宏；发布正式版本时，不定义该宏，这些属性和调试信号就会被当作普通代码，可能被优化掉，从而生成最优化的电路。
2. 分区管理调试信号：将所有的调试信号和相关属性集中放在一个或几个特定的调试模块里，而不是散落在功能代码各处。这样在不需要时，可以轻松地注释或移除整个模块。
3. 定期清理：养成习惯，在调试结束后，评估哪些信号是临时性的，哪些是长期需要观测的。对于临时性信号，及时移除其保留属性。

3.3 当属性“失灵”时怎么办？

有时候，即使你加了属性，信号还是不见了。别慌，我遇到过几次，排查思路如下：

1. 检查语法和位置：确保属性语法正确，且放置在了正确的信号声明位置。对于wire，属性必须放在声明处；对于reg，放在声明处或always块前。
2. 查看综合报告：编译后，打开“Analysis & Synthesis”部分的报告。搜索你的信号名，看看综合器是否给出了警告（比如“忽略某个属性”）。报告里常有线索。
3. 逻辑被彻底优化：这是最常见的原因。比如，你保留了一个寄存器debug_reg，但它的输入是1‘b0，输出驱动了一个& 1’b0的逻辑。综合器可能会进行跨层次的优化，最终推导出这条路径恒为0，从而将整个逻辑链优化掉，连带着你的寄存器也失去了存在价值。此时，可以尝试让这个寄存器的输入源稍微“复杂”一点，比如来自一个输入端口，或者让它的输出驱动一个无法被轻易优化的路径（例如输出到一个添加了keep属性的wire，再连接到顶层端口）。
4. 使用/* synthesis translate_off */ 和 /* synthesis translate_on */：这对指令是“大杀器”。它们之间的代码会被综合器完全忽略，只用于仿真。你可以把一些仅用于仿真测试的代码（比如$display，延迟语句#）放在里面。但绝对不要用它来包裹你想要综合的实际功能逻辑，否则这些逻辑根本不会生成电路。

4. 不止于调试：其他关键综合属性速览

除了信号保留，Quartus的综合属性还能帮我们做很多精细控制。这里快速过几个在信号完整性相关的场景中也非常有用的属性。

4.1 控制存储器实现：ramstyle与ram_init_file

当你用寄存器数组描述RAM时，综合器会自动推断并使用芯片内嵌的Block RAM资源。但有时你需要指定到底用哪种类型的RAM块（比如M9K还是MLAB），或者载入初始值文件。

// 指定使用M9K类型的Block RAM实现这个存储器
(* ramstyle = "M9K" *) reg [31:0] buffer_mem [0:511];

// 为推断的RAM指定初始化文件
(* ram_init_file = "my_boot_loader.mif" *) reg [7:0] boot_rom [0:4095];

指定ramstyle可以确保关键存储器路径使用性能或资源最合适的硬件单元，避免综合器选用不理想的实现方式。

4.2 状态机编码控制：syn_encoding

状态机的编码方式（二进制、格雷码、独热码）直接影响时序、面积和功耗。综合器通常会自己选择，但你可以用syn_encoding属性强制指定。

(* syn_encoding = "one-hot" *) reg [3:0] state;
parameter S_IDLE = 0, S_START = 1, S_RUN = 2, S_DONE = 4; // 注意独热码的parameter值

在高速设计中，强制使用“one-hot”编码可以改善时序；在资源紧张的设计中，“gray”编码可能更省面积。这个属性让你把选择权拿回来。

4.3 小心使用full_case与parallel_case

原始文章提到了这两个用于case语句的属性，但我必须强调：谨慎使用，最好不用。

• full_case：告诉综合器，这个case语句已经列出了所有情况，未列出的视为“不关心”（don‘t care）。如果实际运行时出现了未列出的情况，电路行为将是不可预测的，可能导致锁存器生成或功能错误。
• parallel_case：告诉综合器将case项视为并行优先级，而非生成优先级链。这可以优化速度，但如果case项本身有重叠（比如用了casez），强制并行可能导致逻辑错误。

现代综合工具已经非常智能，绝大多数情况下都能做出最优推断。我个人的经验是，先写好完整的、无歧义的case语句（如使用default分支），让工具去优化。只有在极少数经过严格分析和仿真验证，确认工具推断结果不理想的情况下，才考虑使用这两个属性，并且一定要加上详细的注释说明原因。

5. 工程实践：从代码到网表的完整检查流程

理论说再多，不如一个完整的实操流程。下面是我在项目中确保关键信号被保留的标准检查步骤：

第一步：代码标注。 在编写或修改代码时，立即为确需保留的调试或功能信号添加属性。我习惯用(* preserve *)保寄存器，用(* keep *)保关键中间连线，并用DEBUG_前缀命名它们，方便搜索。

第二步：首次编译与报告检查。 进行一次完整的编译（至少到Analysis & Synthesis阶段）。打开“Compilation Report” -> “Analysis & Synthesis” -> “Advanced HDL Synthesis”。这里会列出“Preserved Registers”和“Preserved Wires/Nets”的数量。核对数量是否符合你的预期。如果数量为0但你明明加了属性，就要回头检查第一步。

第三步：网表查看器验证。 这是最直观的一步。在Quartus菜单栏，选择“Tools” -> “Netlist Viewers” -> “RTL Viewer”。在RTL视图里，找到你的模块，展开层级，肉眼查找你标记的信号。如果信号存在，并且连接关系正确，那就成功了。如果找不到，可以尝试“Technology Map Viewer”（门级视图），但那里更复杂。在RTL Viewer里找不到，通常意味着信号在综合早期就被优化了。

第四步：SignalTap II确认。 如果保留信号是为了调试，那么创建或更新你的SignalTap II文件，添加这些信号。重新编译（包含SignalTap逻辑）。编译成功后，在SignalTap设置界面里，应该能顺利找到并添加这些信号。如果列表里没有，回到第二步检查报告。

第五步：资源与时序影响评估。 在“Compilation Report”的“Flow Summary”和“Fmax Summary”里，观察添加保留属性前后，寄存器（Registers）、逻辑单元（LEs/ALMs）和最大时钟频率（Fmax）的变化。如果影响在可接受范围内，则流程结束。如果资源增加过多或时序违例，你需要回到3.2节的策略，考虑用条件编译宏来管理这些调试属性。

这套流程走下来，基本能确保你的信号在需要时稳稳地待在网表里。信号保留是FPGA开发中一项看似微小却至关重要的技能。它体现了硬件描述语言“描述”与综合工具“实现”之间的边界，掌握它，意味着你不仅能告诉工具“做什么”，还能在一定程度上指导它“怎么做”。希望这些从实际项目中摸爬滚打出来的经验，能让你在下次面对“信号消失术”时，从容地拿出“保留大法”，轻松搞定。