企业官网建设流程全解析

做FPGA调试最憋屈的时刻，不是波形抓错了，不是触发条件设错了，而是你明明在代码里写了一个信号，等综合完打开网表一看，它没了。尤其是刚接触紫光同创Pango Design Suite的朋友，从Vivado或Quartus切过来，习惯了那边“右键Mark Debug”一套流程，到了这边突然找不到信号，第一反应往往是怀疑工具是不是有bug。其实真不是工具的问题，大部分时候是综合器觉得这个信号“没有用”，顺手就帮你优化掉了。

这篇文章专门聊这个事。我会从信号为什么会被优化讲起，然后给出Pango Design Suite里最实用的保留信号方法，包括代码加属性、约束文件固定、Debug工具里挂探针的完整流程，最后再把我这些年踩过的坑和排查思路一并整理出来。无论你是刚入门的学生，还是从其他FPGA平台转过来的工程师，照着这套方法做，基本能解决“Debug时信号被优化”这个让人头大的问题。

1. 信号为什么会被“优化”掉：先搞懂综合器在想什么

1.1 一个典型的抓狂场景

先描述一个我猜很多人都经历过的场景。你写了一个测速模块，内部有一个计数器用来记录某个事件的脉冲个数，这个计数器既没有连接到输出端口，也没有参与任何外设控制，它纯粹是给你自己观察用的。仿真阶段一切正常，波形里计数器老老实实从0加到N。于是你高高兴兴地上板调试，在Pango Design Suite里创建Debug工程，想把计数器拉进采样窗口，结果搜索信号名，搜不到。

这时候你可能会把综合报告翻个底朝天，或者重新综合一遍，甚至怀疑软件破解不完整。我当初也这么干过。后来才明白，问题出在综合器的工作逻辑上：对于没有扇出到输出端口、没有驱动任何实际负载的寄存器，综合器会判定为“冗余逻辑”，直接删掉。这在FPGA综合里叫死代码消除（Dead Code Elimination），属于非常常规的优化手段。

换句话说，在你的仿真世界里，这个计数器有存在感；但在综合器眼里，它就是一个既不影响引脚输出、也不影响其他寄存器状态的“孤儿信号”，留着它只会浪费寄存器资源。于是优化器毫不犹豫地把它丢了。

1.2 综合工具到底做了哪些“手脚”

理解信号被优化，不能只看表面，你得知道综合工具在背后做了哪几类操作。简单归纳一下，常见的优化动作有这么几种：

• 常量传播与常量折叠：如果信号的值在综合阶段就能确定，比如某个寄存器永远只被赋值为0，那么所有用到它的地方都会直接替换成常量，寄存器本身自然就不需要了。
• 无扇出逻辑消除：一个寄存器或线网，如果它的输出没有连接到任何有效负载，综合器就会把整条逻辑链删掉。这是最常见的一种“信号消失”原因。
• 寄存器合并与等价逻辑吸收：两个寄存器如果赋值条件相同、初始值相同、位宽一样，综合器有可能会把它们合并成一个；或者某些逻辑被吸收到LUT内部，原本的中间线网就不存在了。
• RAM/移位寄存器推断：当你写了大块存储逻辑时，工具会把它推断成Block RAM或分布式RAM。RAM内部的地址线、数据线地址寄存器往往是不可见的，因为它们的物理实现已经变成了RAM原语的内部配置。
• 层次化展平（Flatten）：综合时工具默认会把模块层次打平，再重新聚合。在这个过程中，信号名字会被重新生成，你要是按原代码层次里的信号名去网表里找，找不著。

你注意一下最后一条，它其实是很多人在Pango Design Suite里“找不到信号”的真正原因：信号还在，只是被改了名、换了层次，看起来像是被优化掉了。但也确实有相当一部分信号是真的被删了，两者要区分对待。

1.3 为什么Debug工具总是“慢半拍”

很多人不理解一个问题：为什么仿真能看到，上板Debug就看不到？仿真和综合是两套完全不同的执行路径。

仿真器（比如ModelSim、Vivado Simulator）处理的是你的RTL代码，它按照语法逐行执行，所有信号天然存在，不需要做任何优化。综合器则不同，它的目标是把RTL映射成目标FPGA器件的底层资源（LUT、FF、BRAM、DSP等），映射过程中必须做优化，否则最终电路的资源占用会大得离谱。

Debug工具（在线逻辑分析仪）的原理是，在布局布线阶段把调试探针挂载到综合后的网表上，然后通过JTAG接口把采样数据回传到上位机。如果信号在综合阶段就被删了，那么网表里没有这个节点，后续所有环节都无从谈起。如果信号只是被改了名字，那Debug工具里搜索名字也会落空，你需要按新的自动生成名去找。

所以记住这个链条：信号必须在综合后的网表中存在，并且名字可识别，Debug工具才可能抓到它。后面所有解决方案，本质上都在围绕“保留信号”和“让信号名字稳定”这两件事做文章。

2. 最直接的解法：用综合属性把信号“钉”住

2.1 Keep、Syn_Keep、Dont_Touch怎么选

如果信号确实需要保留，最推荐的方式不是去调工具选项，而是在RTL代码里直接加综合属性。为什么？因为工具选项是全局性的，一开就影响整个工程；而代码属性是定点打击，只对目标信号生效，逻辑清楚，也方便后期维护。

Pango Design Suite作为国产FPGA工具，对Verilog-2001标准属性和Synopsys属性有较好的兼容性。实际开发中，我常用的属性有三个：

简单说，keep是“别删我”，dont_touch是“别动我”。调试场景下，需要上板观察的信号，我一般直接上dont_touch，省得保留之后名字变了又找不到。如果你只是担心被删除，用keep就够了。

2.2 代码里到底怎么写

以Verilog为例，写属性的位置非常关键，我见过不少朋友把属性写在声明语句末尾，结果工具根本不认。正确写法是在信号声明语句前一行加属性，或者直接内联在信号名前面。

// 方式一：属性单独一行 (* keep = "true" *) wire [7:0] dbg_cnt; // 方式二：属性内联 (* dont_touch = "true" *) reg dbg_flag; // 总线信号也支持 (* syn_keep = "true" *) wire [15:0] dbg_addr; // 例化实例也可以保留 (* dont_touch = "true" *) my_module u_my_module ( .clk(clk), .rst_n(rst_n) );

写完之后重新综合，然后在综合后的网表窗口里搜一下信号名，如果能搜到，说明属性生效了。这里有一个很容易踩的坑：如果你修改了属性，但工程开了增量综合或者增量布局布线，工具可能没有重新综合这部分逻辑，结果你发现属性“加了没用”。处理办法是，改完属性后先Clean掉之前的综合结果，再重新跑综合，不要只点Incremental Run。

另外，如果你习惯写VHDL也没关系，方法类似：

attribute keep : string; attribute keep of dbg_cnt : signal is "true";

2.3 属性写了还是被优化，怎么办

这种情况我也遇到过，具体原因有很多，但最常见的是这么几个：

• 属性写错对象：keep属性要加在信号声明处，不是加在赋值语句里。如果你写在always块内部，工具不会理你。
• 信号被吸收进了原语内部：比如你声明了一个reg [7:0] cnt，但工具推断成了DSP的流水线寄存器，或者RAM的输出寄存器。此时reg已经变成DSP/RAM原语的内部结构，外部属性管不到它。对策是不要直接保留这个寄存器，而是保留它前后的一级wire，或者对例化后的DSP/RAM原语加dont_touch。
• 综合缓存没清干净：这是最容易忽略的。Pango Design Suite的综合缓存有时候不会因为代码改动而自动失效，建议遇到“属性加了没反应”时，先Clean Project再重新综合。
• 属性大小写写错：keep不能写成KEEP，有些属性名是大小写敏感的，写错了工具会静默忽略。

还有一个“野路子”方法，就是在信号上挂一个不会影响功能的虚拟负载，比如把这些信号全部异或后接到一个未使用的输出引脚上。这样综合器看到信号有扇出了，就不会删。但我不推荐这么干，一方面占用引脚，另一方面代码里混入为了调试而存在的逻辑，很容易污染设计意图。正规做法还是用属性，或者用后面要讲的Debug工具流程。

3. Pango Design Suite里推荐的Debug信号保留流程

3.1 第一步：合理设置综合选项

有人问我，能不能在综合设置里把优化关掉，这样所有信号都保住了。理论上可以，但实际千万别这么干。全局关闭优化大概率会让你的设计时序跑不过，或者资源占用翻好几倍。综合工具把优化等级调低是给特殊场景用的，比如排查综合bug，或者做形式验证对照，不是给常规调试用的。

正确的思路是，在综合设置里保留那些“定向保留信号”的选项，但不要全局关闭优化。以Pango Design Suite常见的工程设置路径为例：

1. 在工程管理器中右键Synthesis Process，选择Settings；
2. 在Synthesis Options里找到Preserve Hierarchy或类似的层次保留选项，建议设为Yes或All；
3. 找到Optimization Goal，一般有Area和Speed两种，不管是哪种，都不会单独摧毁你的调试信号，不用因为这个纠结；
4. 找到与Remove Duplicate Registers、Resource Sharing相关的选项，如果确认某些信号因为这些选项被优化，可以考虑关闭，但要做好资源上升的准备；
5. 如果工具提供了一个Keep All Signals或Preserve All Nets之类的选项，建议保持默认关闭。

这里有一个经验：不要为了Debug信号去全局改综合策略，Project级设置影响面太大，出了问题你反而分不清是逻辑问题还是优化策略问题。用属性定点保留，永远是最可控的方案。

3.2 第二步：在网表里确认信号并挂到Debug工具上

综合完成后，打开综合后的网表或者原理图查看器，先搜索一下你要的信号名。如果搜到了，表明信号在网表层面还存在；如果搜不到，回到第2节用属性保留。

在Pango Design Suite里，类似Vivado的“Mark Debug”操作，大致步骤是这样的（以常见版本界面为例，不同版本菜单位置可能略有差异）：

1. 打开综合后的Netlist窗口，展开设计层次；
2. 在搜索框里输入信号名，支持通配符；
3. 右键目标信号，选择Add to Debug或Mark Debug（不同版本叫法可能不同）；
4. 打开Debug工具（有些版本叫Chip Debugger或者Logic Analyzer配置器），你会看到刚才标记的信号已经出现在调试探针列表里；
5. 为调试探针选择采样时钟。注意，采样时钟的频率必须能覆盖你信号的最高有效变化率，否则抓到的波形是欠采样的；
6. 设置采样深度和触发条件，保存Debug工程；
7. 执行布局布线，生成bitstream；
8. 上板后通过调试接口连接，运行触发采样，观察波形。

这里我要特别强调采样时钟的选择。很多人抓不到信号，不是因为信号被优化了，而是采样时钟选错了。如果被测信号和采样时钟不在同一个时钟域，采样结果会出现大量亚稳态或者错位。最稳妥的做法是选择被测信号所在时钟域的时钟作为采样时钟，并且保证这个时钟在调试期间一直是活动的。

3.3 第三步：用约束文件固定信号名字

代码里加了dont_touch，网表里也能搜到信号了，但还有一个隐患：布局布线阶段工具可能还会对信号做重命名。如果你靠名字去识别信号，这时候又会被坑一把。

解决办法是在约束文件里对关键调试信号添加命名约束或保留约束。以Pango Design Suite常见的约束语法为例，大致写法如下：

# 保留一个线网，防止布局布线阶段被改名 set_property KEEP true [get_nets dbg_cnt] # 使用通配符批量保留一类信号 set_property KEEP true [get_nets *dbg_*] # 对某个寄存器实例加DONT_TOUCH set_property DONT_TOUCH true [get_cells u_my_module/dbg_cnt_reg*]

如果你不确定Pango Design Suite当前版本支持的约束写法，最直接的办法是打开工具自带的约束模板，或者看综合报告里自动生成的约束文件。在这个基础上改，比自己凭记忆写要可靠得多。

3.4 第四步：什么时候用IP例化方式替代Mark Debug

Mark Debug这种方式适合你已经完成设计、临时想加调试信号的场景。但如果你在设计阶段就明确知道某些信号需要长期观察，还有一个更稳妥的选择：直接例化调试IP。

在Pango Design Suite里也提供了类似ILA（集成逻辑分析仪）的IP核，你可以像例化普通模块一样，在RTL代码里把调试IP例化进去。这样做的好处是，调试逻辑和功能逻辑明确区分，综合和布局布线都不会轻易动它；坏处是，改一次采样信号就要改代码、重新综合，不像Mark Debug那样可以临时改。

举个例子：

ila_debug u_ila_debug ( .clk(clk), .probe0(dbg_cnt), .probe1(dbg_flag), .probe2(event_pulse) );

但要注意，IP例化方式会额外占用Block RAM资源，采样深度越大，BRAM占用越多。对于只有少量信号的情况，直接Mark Debug更省事；对于需要长期保留固定调试接口的模块，用IP例化方式更合适。

4. 常见问题排查与自查清单

4.1 问题速查表

我把平时在群里、论坛上看到的高频问题整理成一张表，你可以直接对照排查：

4.2 为什么加了属性还是找不到信号

这个情况需要重点说一说，因为很多人会卡在这一步。先说一个常见误操作：把keep属性加在reg上，但reg实际上是综合器的一部分时序逻辑，只加keep在一些版本里并不完全管用。我推荐的组合是：

• 对wire类型信号，加keep或syn_keep；
• 对reg类型信号，加dont_touch；
• 对信号链中间节点，最好对前后两个信号都加保留属性。

另外一个原因就是信号所在模块被优化了。比如你的模块输入端固定为常量，综合器完全可以通过常量传播计算出模块内部所有寄存器的值，然后把整块逻辑全删掉。这时候你只保留一个内部信号是没用的，得把整个模块实例用dont_touch保住，或者把模块顶层的输入信号保住。

还有一点是工程缓存的老问题。Pango Design Suite在快速迭代时，有些版本的综合缓存策略比较激进，代码变了但综合结果没有完全刷新。遇到这类情况，先Clean Project，再重新综合。如果还是不行，可以试试重启软件，这个办法土，但有时候就是管用。

4.3 抓到的波形不对：从采样时钟和触发条件找原因

信号保住了，也挂到Debug工具上了，上板一跑，发现抓到的波形全是0，或者和你预期的时序差得十万八千里。这时候不要怀疑信号被优化工具搞了，问题大概率出在采样配置上。

采样时钟方面，优先选被测信号所在时钟域的时钟。比如你测的是PLL输出时钟驱动的逻辑，那采样时钟最好就是PLL的输出，而不是外部晶振输入时钟。如果被测信号跨了两个时钟域，更稳妥的办法是把信号先打两拍同步到采样时钟域，再送进调试IP，否则采到的波形会有毛刺和亚稳态。

触发条件方面，Debug工具本质上是“等触发条件成立，然后记录一段波形”。你要先想清楚自己想抓什么事件。比如你想抓计数器从0跳变的瞬间，触发条件可以设为“不等于0”或者“上升沿”；如果你想抓某个状态机的特定状态，触发条件就设为对应的状态值。很多人触发条件设错，导致采样窗口里永远没有目标数据。

采样深度方面，深度越大，能记录的波形越长，但BRAM占用也越高。以常见调试IP为例，深度从1K到64K可选，深度每翻一倍，BRAM消耗基本也翻一倍。如果你只是看某个信号跳变，1K或4K足够了，不用贪大。

4.4 保留信号太多导致布线失败怎么办

这是另一个极端：你为了调试，给几十个信号都加了保留属性，结果布局布线跑不过去了。原因很直接，保留信号意味着这些信号不能被工具自由优化和重布局，相当于给布线器上了紧箍咒，本来就拥挤的区域瞬间堵死。

我个人的经验是，单次调试会话建议保留的信号在16个以内。优先保留你最关心的、能反应问题本质的信号，不要抱着“全都抓下来，回去慢慢看”的想法。一口气抓几十个信号，不仅布线容易失败，抓回来的波形你也看不过来。

如果确实需要抓大量信号，一个变通方式是分批次调试。先抓A组信号，跑完看结果，再改挂B组信号，重新布局布线。虽然多花点时间，但至少都能抓出来。

5. 最后分享几条我踩坑之后养成的习惯

Debug信号被优化这个事，遇到一次坑可能还好，反复栽跟头就说明方法有问题。我在折腾Pango Design Suite一段时间后，慢慢养成了一些工作习惯，分享出来供你参考。

第一，在写RTL代码时就把调试信号规划好。我习惯在模块里单独划出一段区域，统一命名带dbg_前缀的信号，并把它们集中声明。这样后续加保留属性、加约束、搜信号名都方便。如果实现的是正式版本，直接用一个宏把这些调试逻辑包起来，综合时关掉宏即可。

`ifdef DEBUG_EN (* dont_touch = "true" *) wire [7:0] dbg_cnt; `endif

第二，修改调试属性后，强制重新综合一次。不要省那几分钟的增量编译，因为增量编译有时会沿用旧的综合网表，导致你加的属性没有实际生效，白忙活一场。

第三，遇到“信号被优化”，先看综合报告和综合后的网表，再决定怎么处理。不太建议在综合设置里全局把优化关掉，这个开关是最后的排查手段，不是日常调试配置。我见过有人为了省事，把所有优化选项全关了，结果时序收敛非常困难，问题反而更难查。

第四，善用约束文件里的通配符。当你需要保留一批调试信号时，不要一个个手写，直接用*dbg_*之类的通配符批量匹配。前提是你的调试信号命名足够有规律，所以第一条习惯很重要。

Pango Design Suite的工具链还在持续完善中，界面和选项在不同版本之间会有差异，但底层的综合优化原理是相通的。只要掌握了“属性保留信号、网表确认存在、约束固定名字、Debug工具挂探针”这条主线，不管工具怎么升级，你都能快速找到对应的操作方法。希望这篇避坑指南能帮你少走一些弯路。