FPGA综合优化中信号保留策略：keep与keep_hierarchy属性实战解析

1. 项目概述：FPGA综合优化与信号保留的永恒博弈

在FPGA开发领域，尤其是使用上海安陆这类国产EDA工具链时，一个让工程师们又爱又恨的环节就是“综合”。爱它，是因为它将我们精心设计的RTL代码转化为高效的网表，是设计实现的关键一步；恨它，往往是因为它“过于智能”，有时会自作主张地把我们辛辛苦苦埋下的调试信号、关键路径标志甚至是一些功能逻辑给“优化”掉，导致仿真通过但上板失败，或者调试时抓不到想要的信号。这个问题，业内常称为“信号被综合工具吃掉了”。今天，我们就来深入聊聊，在使用上海安陆FPGA软件（通常指其综合工具）时，如何精准地、有策略地防止模块在综合过程中被过度优化，确保关键信号“存活”下来。这不仅是工具使用技巧，更是对综合工具工作原理和设计意图的深刻理解。

对于初学者来说，可能会觉得综合工具像个黑盒子，输入代码，输出网表，中间发生了什么全靠猜。而对于有经验的工程师，综合过程是一场与工具的默契对话，我们需要用工具能理解的语言（综合属性指令）告诉它：“这里，还有这里，请保持原样。”无论是为了保留用于片上逻辑分析仪（ILA）的调试探针，还是为了确保某些特定电路结构（如异步接口、门控时钟的使能信号）不被简化，掌握防止信号优化的方法都是FPGA开发者的核心技能之一。接下来，我将结合上海安陆工具的特点和通用的FPGA设计理念，拆解这个问题。

2. 综合优化原理与信号“消失”的根源

要解决问题，首先要理解问题是如何产生的。综合工具的根本任务是在满足功能、时序、面积等约束的前提下，将RTL描述转换为由目标FPGA基本单元（如LUT、寄存器、BRAM等）构成的门级网表。在这个过程中，它会进行一系列极其激进的优化：

2.1 常量传播与折叠

这是最常见的优化之一。例如，你写了一个信号assign debug_signal = some_logic & 1‘b0;，综合工具会立刻计算出debug_signal恒为0。如果这个信号没有驱动其他任何负载（即输出未被使用），那么它连同产生它的逻辑some_logic都可能被当作冗余逻辑移除。即使debug_signal被引到了顶层端口，如果顶层端口本身未被使用（例如，你预留的调试引脚未分配物理管脚），综合工具在“全局优化”视角下，仍然可能认为这条路径是死的，从而进行优化。

2.2 死代码消除

这是常量传播的延伸。综合工具会构建整个设计的信号传播图，如果一个寄存器或组合逻辑块的输出，无法通过任何路径传播到顶层输出端口，或者无法影响任何其他被使用的逻辑的状态，那么这块逻辑就被判定为“死代码”，会被无情移除。你的内部状态机标志、计数器值，如果仅用于想象中的“调试观察”而未实际接入输出或用于条件判断，就很容易被判定为死代码。

2.3 逻辑等效性优化

工具会识别并合并功能完全相同的逻辑。比如，两个模块实例化了相同的子模块，或者两段代码产生了完全相同的逻辑功能，工具可能会将它们合并以减少资源占用。这有时会导致你期望的两个独立信号网络被合并成一个，破坏了设计的模块边界或调试的独立性。

2.4 层次结构扁平化

为了进行更全局的优化，综合工具默认倾向于打平（Flatten）设计的层次结构。这意味着模块（module）的边界在优化过程中可能变得模糊。一个模块内部的信号，如果其源头和归宿都在模块内部，工具可能会将其与外部逻辑一起优化，使得“模块内信号”这个概念在综合后的网表中不复清晰，给基于模块的调试和分析带来困难。

上海安陆的综合工具，其内核算法与国际主流工具（如Synopsys Synplify, Xilinx Vivado Synthesis）在基本原理上是相通的，都遵循上述优化策略。因此，解决思路也具备通用性，关键在于如何正确使用工具提供的“指令”来约束这些优化行为。

3. 核心防御策略：使用综合约束属性

这是防止信号被优化的最主要、最直接的方法。我们需要在RTL代码中嵌入综合工具能够识别的特殊注释，这些注释被称为“综合属性”或“编译指示”。在上海安陆的工具中，其语法通常兼容Verilog(* *)或 SystemVerilog/* synthesis ... */的风格。

3.1keep属性：信号保留的“护身符”

keep属性是最常用的指令，它直接告诉综合工具：“这个网线（net）或寄存器（reg）必须保留在网表中，不要优化掉它。”

应用示例与深度解析：

module my_design ( input clk, input rst_n, input [7:0] data_in, output [7:0] data_out ); // 一个内部调试计数器 (* keep = “true” *) reg [31:0] debug_counter; // 一个从复杂组合逻辑中提取的中间调试信号 (* keep = “true” *) wire debug_flag = (data_in > 8‘d100) & (some_condition); always @(posedge clk or negedge rst_n) begin if (!rst_n) begin debug_counter <= 32‘d0; end else begin debug_counter <= debug_counter + 1‘b1; end end // 主逻辑... assign data_out = data_in ^ 8‘hFF; endmodule

为什么有效？(* keep = “true” *)这个属性附着在debug_counter和debug_flag的声明上。它打断了综合工具的优化流程。当工具分析到这些信号时，即使它推导出debug_counter的计数结果没有驱动任何功能逻辑，debug_flag可能是一个常量，它也会因为keep属性的存在而强制保留该信号的网络和驱动逻辑。注意，keep主要作用于“网线”，对于寄存器，它保证寄存器本身不被移除，但其输入逻辑仍可能被优化（例如，如果计数器的输入是常量，计数器可能变成固定值寄存器）。若需保留完整逻辑链，需对相关信号也添加keep。

实操心得：

1. 精准使用：不要滥用keep。给大量信号添加keep会严重阻碍综合工具的优化能力，可能导致面积增大、时序变差。只对确需观察或关键路径上的信号使用。
2. 作用范围：keep属性通常写在信号声明处。对于 wire 型信号，确保属性写在声明语句中。
3. 工具兼容性：上海安陆工具通常支持(* keep *)、(* synthesis keep *)或/* synthesis keep */等多种写法。建议查阅其官方手册，并统一项目中的写法风格。在复杂项目中，可以在一个单独的约束文件或头文件中用 `define 宏来统一定义这些属性，提高代码可维护性。

3.2keep_hierarchy属性：守护模块的“疆界”

当你希望保留某个模块的完整层次结构，防止其内部逻辑被外部逻辑合并或打平时，就需要keep_hierarchy。这对于模块化设计、IP核保护以及基于模块的增量编译和调试至关重要。

应用示例与深度解析：

(* keep_hierarchy = “yes” *) module crypto_core ( input clk, input [127:0] plaintext, input [127:0] key, output [127:0] ciphertext ); // 模块内部复杂的加密逻辑... endmodule module top_level ( input clk, input [127:0] data, input [127:0] key, output [127:0] encrypted_data ); // 实例化时，即使顶层没有其他逻辑与crypto_core交互，其层次也会被保留 crypto_core u_crypto_core ( .clk(clk), .plaintext(data), .key(key), .ciphertext(encrypted_data) ); // 假设这里有一些其他逻辑 (* keep = “true” *) wire some_debug_signal; assign some_debug_signal = |data; // 按位或，产生一个调试信号 endmodule

为什么有效？在top_level中，如果没有keep_hierarchy，综合工具可能会将crypto_core内部的逻辑展开，并与top_level中其他可能的逻辑（虽然本例中简单）进行跨模块优化。添加keep_hierarchy = “yes”后，工具会将crypto_core视为一个黑盒边界（在综合阶段），其内部优化独立进行，输出端口与外部逻辑的连接关系保持不变。这保证了在综合后的网表中，你仍然能看到一个名为u_crypto_core的实例，双击进去能看到完整的子模块网表，这对于定位模块内部问题极其方便。

实操心得：

1. 应用场景：keep_hierarchy特别适用于：
   • IP模块：确保第三方或自研IP的内部实现不被窥探或篡改（与加密IP配合）。
   • 调试模块：如专门的性能计数器、调试信息采集模块，需要独立存在。
   • 增量编译：在大型设计中，固定某些已验证模块的边界，只综合修改的模块，缩短编译时间。
   • 团队协作：明确模块接口，防止因优化导致的接口行为意外改变。
2. 性能权衡：保留层次结构可能会阻止一些跨模块的优化机会，可能对最终的性能（频率、面积）有轻微影响。需要在可调试性/可维护性和性能之间做权衡。

3.3mark_debug属性：为调试工具铺路

虽然上海安陆工具链可能自带调试工具，但概念上与Xilinx的Vivado或Intel的Quartus的“标记调试”功能类似。mark_debug属性是比keep更高级的指令，它明确告诉工具链：“这个信号我计划在后续用片上逻辑分析仪（ILA）来观察，请务必保留它，并为其插入调试核时提供便利。”

应用示例（假设工具支持类似语法）：

module data_path ( input clk, input valid_in, input [63:0] din, output reg valid_out, output reg [63:0] dout ); // 标记为调试信号，通常工具会同时隐含keep行为 (* mark_debug = “true” *) reg [3:0] state; (* mark_debug = “true” *) wire fifo_full; (* mark_debug = “true” *) wire [63:0] processed_data; // ... 状态机、数据处理逻辑 ... assign fifo_full = (fifo_cnt == 8‘hFF); assign processed_data = din * 2; // 示例处理 always @(posedge clk) begin state <= next_state; if (valid_in & !fifo_full) begin dout <= processed_data; valid_out <= 1‘b1; end else begin valid_out <= 1‘b0; end end endmodule

为什么有效？当你在RTL中标记了mark_debug后，综合工具不仅会保留该信号，还会在网表中为其添加特殊的元数据。在后续的实现步骤（翻译、映射、布局布线）中，工具会小心处理这些信号，确保它们不被优化掉，并且其物理连接是可探测的。最后，在生成比特流时，调试工具可以根据这些信息自动生成并插入ILA核的配置。即使工具不支持完全相同的属性名，其原理也是相通的：需要一个明确的指令来区分“功能信号”和“调试信号”。

实操心得：

1. 流程整合：如果上海安陆工具提供图形化调试插入流程，通常在综合后、实现前，有一个“设置调试探头”的步骤。在那里，你可以从网表中选择信号，其效果等同于在RTL中标记mark_debug。在RTL中预标记可以简化后期操作。
2. 信号选择：优先标记控制信号（如使能、有效、状态机状态）、错误标志、关键数据路径的中间结果。避免标记高速变化的宽数据总线，这会消耗大量调试存储资源。

3.4 其他相关属性与技巧

• full_case与parallel_case：用于指导case语句的综合，避免生成锁存器或意外的优先级逻辑，从而间接影响优化结果。不正确的综合推断可能导致信号被意外优化。
• dont_touch：这是一个比keep更强的约束。keep阻止优化移除，但允许工具在保持信号存在的前提下进行逻辑重构（如缓冲器插入、逻辑复制）。dont_touch则要求工具几乎完全保持该网络的原貌。慎用，因为它可能严重干扰布局布线优化。
• 通过端口连接“假负载”：如果某个内部信号非常重要，但又不想用属性，一个“土办法”是将其输出到顶层模块，并连接到一个实际存在的、不会被优化的负载上（例如，连接到一个实际使用的LED输出管脚，或者一个虚拟的、添加了keep属性的寄存器）。这利用了“信号被使用则不会被移除”的基本原理。

4. 设计编码层面的预防措施

除了使用综合属性，良好的编码风格可以从源头上减少信号被意外优化的风险。

4.1 确保信号被“有效使用”

综合工具判断逻辑是否“有效”的标准，是看它能否影响到顶层输出或设备引脚。因此：

• 将关键调试信号引出到顶层端口：这是最根本的方法。即使这个端口在最终板级设计上可能悬空或接测试点，只要它在顶层声明为output，综合工具就必须保留驱动它的所有逻辑。

  module top ( output wire [7:0] o_debug_bus // 专门用于调试的总线 ); // ... 内部逻辑 ... assign o_debug_bus = {state, error_flag, counter[3:0]}; endmodule

  注意：仅仅引出到顶层还不够。如果这个顶层端口在物理约束文件（如UCF、XDC、安陆的约束文件）中没有被分配到具体的芯片引脚上，一些更“激进”的综合工具在“优化掉无负载输出”的选项开启时，仍可能将其优化。此时，需要结合使用keep属性或确保在约束文件中为该输出端口设置set_property CLOCK_DEDICATED_ROUTE FALSE（类似功能）或set_property IOB FALSE等属性，告诉工具即使不绑定引脚也要保留该端口网络。

4.2 避免纯中间变量，赋予其“存在意义”

对于复杂的组合逻辑，尽量将中间结果赋值给寄存器或输出，而不是仅仅用wire连接。寄存器的“状态保持”特性使其更不容易被优化掉。或者，让这个中间信号参与到有实际功能的条件判断中。

• 不佳的写法：

  wire condition_a = (a > b); wire condition_b = (c < d); wire debug_and_result = condition_a & condition_b; // 纯中间wire，极易被优化 assign result = condition_a ? x : y; // debug_and_result 未被使用

• 改进的写法：

  (* keep = “true” *) wire debug_and_result = condition_a & condition_b; // 添加keep // 或者，让其参与功能（即使影响很小） assign result = (condition_a & debug_and_result) ? x : y; // 现在debug_and_result被使用了 // 或者，将其寄存，用于观察 reg r_debug_and_result; always @(posedge clk) r_debug_and_result <= condition_a & condition_b;

4.3 模块化与封装

将需要保留的调试逻辑或特定功能逻辑封装在独立的子模块中，并在该子模块的顶层端口上使用keep_hierarchy。这样，无论外部如何优化，这个模块的内部世界是完整的。这对于插入断言（Assertion）、性能监视器（Performance Monitor）等调试IP非常有用。

5. 工具流程与约束文件配置

上海安陆的软件通常提供图形界面和脚本命令两种操作方式。防止信号优化也需要在工具流程中正确配置。

5.1 综合设置选项解析

在综合的设置界面或脚本中，可能存在以下关键选项：

• 优化努力程度：通常有“High”、“Medium”、“Low”等级别。选择“Low”优化会减少工具进行激进优化的尝试，有利于保留更多原始结构，但性能可能下降。在调试阶段，可以考虑使用“Medium”并配合约束属性，而非直接使用“Low”。
• 保持层次结构：这是一个全局设置，可能叫做“Flatten Hierarchy”或“Keep Hierarchy”。默认可能是“Flatten”以追求最佳优化。你可以将其设置为“Keep”或“Rebuilt”来全局保留层次。但更推荐使用RTL中的keep_hierarchy属性进行局部精细控制。
• 禁用特定优化：高级工具可能允许你禁用“常数传播”、“死代码消除”等特定优化步骤。除非极端情况，否则不建议全局禁用，这会导致设计质量严重下降。应通过属性进行局部约束。

5.2 使用SDC或工具专用约束文件

除了在RTL中嵌入属性，还可以在综合约束文件中添加命令。上海安陆的工具可能支持类似SDC（Synopsys Design Constraints）的命令或自有命令格式。

• 示例（假设语法）：

  # 在约束文件（如 al_constraints.sdc）中 # 为某个模块实例保持层次 set_keep_hierarchy [get_cells u_crypto_core] true # 为某个网络添加keep属性 set_keep [get_nets debug_counter_reg[*]] true # 为某个端口设置不优化（即使无负载） set_property preserve true [get_ports o_debug_bus[*]]

  这种方式将约束与RTL代码分离，管理起来更清晰，尤其适合后期添加调试信号而不用修改RTL代码。你需要查阅上海安陆工具的具体约束文件指南。

5.3 综合后网表查验

综合完成后，不要直接进行实现，务必打开综合后的网表查看器。这是验证你的约束是否生效的关键一步。

1. 在工具中打开综合后的“门级网表”或“技术视图”。
2. 搜索你添加了keep或keep_hierarchy的信号名、模块实例名。
3. 确认它们是否存在，逻辑连接是否符合预期。
4. 如果信号消失了，检查：属性语法是否正确？信号是否真的在某个环节变成了常量？顶层端口是否有物理约束或负载？

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

即使掌握了方法，在实际操作中还是会遇到各种“坑”。下面是一些典型场景和解决思路。

6.1 问题：添加了keep属性，但信号在网表中依然消失了

• 可能原因1：属性语法错误或位置错误。

  • 排查：检查工具日志文件，看是否有关于无法识别综合属性的警告。确认属性是写在信号声明的位置，而不是仅仅在赋值语句后。对于Verilog，确保使用(* *)且括号匹配。对于SystemVerilog，检查/* synthesis ... */的注释格式。
  • 解决：统一项目属性语法标准，参考工具手册示例。可以先用一个最简单的测试设计（例如，一个只包含被keep的计数器的模块）验证属性是否被工具支持。

• 可能原因2：信号在逻辑上确实被化简为常量。

  • 排查：仔细检查驱动该信号的逻辑。例如，debug_signal = a & !a永远为0，即使加了keep，工具可能会保留一个名为debug_signal的网线，但它被直接连接到逻辑‘0’或‘1’上，在网表查看器中可能显示为一个常数源。
  • 解决：确保驱动逻辑不是恒定的。如果需要观察一个可能为常数的信号，可以将其与一个非常数信号进行“或”操作（例如，debug_signal = (a & !a) | glitch_detector），但要注意这改变了原逻辑，仅用于调试。

• 可能原因3：信号所在的模块被整体优化掉了。

  • 排查：如果整个模块的输出都没有被顶层使用，且模块没有keep_hierarchy或其他保留属性，整个模块可能被当作死代码移除，内部的keep信号自然随之消失。
  • 解决：确保模块被顶层实例化并连接，或者对模块本身使用keep_hierarchy。

6.2 问题：keep_hierarchy生效了，但模块内部还是被大幅优化

• 可能原因：keep_hierarchy主要保持模块的边界，防止跨模块优化。但模块内部的逻辑，综合工具仍然会进行充分的优化（常量传播、死代码消除等）。
• 解决：如果需要在模块内部保留特定信号或结构，必须在模块内部的RTL代码中对那些信号使用keep属性。keep_hierarchy和keep是不同层级的约束，经常需要配合使用。

6.3 问题：调试信号保留了，但时序报告变差，甚至出现建立/保持时间违例

• 可能原因：keep属性阻止了工具对某条路径进行逻辑优化（如逻辑复制、寄存器重定时、流水线优化），可能导致该路径成为关键路径或长路径。
• 解决：
  1. 评估必要性：这个调试信号是否必须在最终版本中保留？如果仅用于开发调试，可以考虑使用条件编译指令（如`ifdef DEBUG）在生成最终版本时移除这些信号和属性。
  2. 局部放松约束：如果必须保留，尝试将keep替换为更弱的约束，或者只对信号网络的关键节点使用keep，而不是整条路径。
  3. 添加时序约束：对该路径添加更宽松的时序约束（如set_max_delay），告诉工具优先满足其他路径，此路径可以慢一些。
  4. 物理规划：如果该信号是用于ILA探针，工具在布局布线时可能会将其连接到远离源寄存器的调试逻辑上，引入长线延迟。检查调试核的布局位置是否合理。

6.4 实战技巧：构建可配置的调试系统

对于大型项目，一个良好的实践是构建一个中心化的、可配置的调试系统，而不是到处散落(* keep = “true” *)。

1. 定义调试宏：在一个全局头文件（如debug_defines.vh）中：

   // debug_defines.vh `ifdef ENABLE_DEBUG `define DEBUG_KEEP (* keep = “true” *) `define DEBUG_HIER (* keep_hierarchy = “yes” *) `define DEBUG_MARK (* mark_debug = “true” *) `else `define DEBUG_KEEP `define DEBUG_HIER `define DEBUG_MARK `endif

2. 在RTL中使用宏：

   `include “debug_defines.vh” module my_module ( //... ); `DEBUG_KEEP reg [31:0] dbg_counter; `DEBUG_MARK wire dbg_trigger; // ... endmodule

3. 在综合脚本或Makefile中控制：通过定义ENABLE_DEBUG宏来开关所有调试代码和约束。发布版本时关闭调试，面积和性能最优；调试版本时开启，信号全部保留。

6.5 问题排查速查表

防止信号被优化，本质上是工程师与综合工具之间的一次精确沟通。上海安陆的FPGA软件提供了与国际主流工具类似的约束机制，关键在于理解其优化原理，并熟练运用keep、keep_hierarchy等属性进行外科手术式的干预。良好的编码习惯和项目级的调试策略同样重要。记住，约束不是越多越好，而是越准越好。每次添加一个约束前，都问自己：这个信号是否必须保留？是否有其他方法（如改善编码）可以避免过度优化？通过这种有意识的实践，你不仅能解决信号消失的问题，更能深化对FPGA综合流程的理解，提升整体设计能力。在实际项目中，我通常会建立一个“调试信号清单”，在综合后逐一核对，确保关键观测点万无一失，这比盲目添加约束要高效得多。