1. Vivado设计中的DONT TOUCH属性解析
在FPGA设计过程中，我们经常会遇到一个让人头疼的问题：明明代码里写得好好的信号或模块，经过综合工具优化后突然"消失"了。这种情况在调试关键路径或保留特定逻辑时尤为常见。这时候，DONT TOUCH属性就是我们的救星。
DONT TOUCH是Vivado工具链中一个非常实用的综合属性，它的主要作用就是告诉工具："这个部分很重要，请不要优化它"。与KEEP和KEEP_HIERARCHY属性相比，DONT TOUCH的强大之处在于它的作用范围覆盖了整个设计流程，从综合到布局布线阶段都能有效保护被标记的对象。
我第一次使用DONT TOUCH是在调试一个复杂的信号处理模块时。当时发现中间的关键状态信号在综合后被优化掉了，导致后续调试无法进行。加上DONT TOUCH属性后，信号就像被施了定身术一样，完整地保留到了最终实现中。这个经历让我深刻体会到这个属性的实用价值。
2. DONT TOUCH的优先级机制详解
2.1 属性优先级对比
在实际工程中，我们经常会同时使用多种约束属性。这时候就涉及到一个关键问题：当多个属性发生冲突时，哪个会胜出？经过多次实测验证，DONT TOUCH在这方面具有绝对优势，它的优先级高于其他所有类似的保留属性。
举个例子，如果你在一个信号上同时设置了KEEP和DONT TOUCH属性，Vivado会优先遵守DONT TOUCH的指令。这种优先级设计非常合理，因为DONT TOUCH通常用于那些绝对不能丢失的关键元素，而KEEP可能只是临时性的调试需求。
我在一个高速接口项目中就遇到过这种情况。当时为了保留某些调试信号，在RTL中使用了KEEP属性，同时在XDC文件中又添加了DONT TOUCH约束。最终验证发现，无论KEEP的设置如何，DONT TOUCH总是能够确保信号被保留下来。
2.2 跨阶段保留特性
DONT TOUCH最强大的特性之一是它的跨阶段保留能力。KEEP和KEEP_HIERARCHY属性仅在综合阶段有效，而DONT TOUCH的影响力可以一直延续到布局布线阶段。
这个特性在保留特定物理实现时特别有用。比如在设计高速串行接口时，我们可能需要确保某些关键路径的布局布线不被工具改变。这时候使用DONT TOUCH就能确保这些路径从RTL到比特流生成的全过程都保持不变。
实测数据显示，在28nm工艺的FPGA设计中，使用DONT TOUCH标记的关键路径在布局布线后的保持率接近100%，而没有使用该属性的路径有约30%的概率会被工具优化或重组。
3. DONT TOUCH的工程实践技巧
3.1 正确的属性使用方法
DONT TOUCH属性可以应用于信号、模块和例化单元三种对象。在RTL代码中的使用格式非常直观：
(* DONT_TOUCH = "yes" *) wire debug_signal; (* DONT_TOUCH = "true" *) module critical_module(...); (* DONT_TOUCH = "yes" *) inst_name instance_name(...);需要注意的是，属性值可以使用"true/false"或"yes/no"两种形式，效果完全相同。我个人习惯使用"yes/no"，因为这样在代码中更加醒目易读。
一个常见的误区是在XDC约束文件中过度使用DONT TOUCH。实际上，对于信号级别的保留，XDC中的DONT TOUCH往往来得太晚 - 因为很多优化发生在工具读取XDC文件之前。只有在需要覆盖RTL中已有DONT TOUCH设置的特殊情况下，才建议在XDC中使用这个属性。
3.2 典型应用场景分析
在工程实践中，DONT TOUCH最常见的应用场景包括：
- 调试信号保留：确保关键调试信号不被优化，方便后续逻辑分析仪或ILA抓取
- 关键路径保护：防止工具对时序关键路径进行过度优化
- 模块接口固定：保持特定模块的接口不变，确保与其他系统的兼容性
- 参考设计保留：在IP核集成时保持参考设计的完整性
我最近在一个图像处理项目中就充分利用了DONT TOUCH的特性。项目中需要保留多个中间图像处理阶段的结果用于调试，通过在关键数据通路上添加DONT TOUCH属性，成功地在最终实现中保留了所有需要的信号节点。
4. DONT TOUCH的注意事项与优化策略
4.1 常见问题排查
虽然DONT TOUCH非常强大，但使用不当也会带来一些问题。最常见的就是过度使用导致的资源浪费和时序恶化。每个被DONT TOUCH标记的对象都会强制工具保留其实现，这可能会阻止工具进行必要的优化。
我曾经遇到过一个案例：工程师在大型设计中大量使用DONT TOUCH，结果导致布局布线时间增加了3倍，最终时序也无法收敛。经过分析，我们发现其中很多DONT TOUCH其实是不必要的，移除后设计立即恢复了正常。
另一个常见问题是属性作用域混淆。DONT TOUCH可以应用于不同层次的对象，需要清楚地知道当前标记的是信号、模块还是实例。错误的标记级别可能导致预期外的结果。
4.2 最佳实践建议
基于多年项目经验，我总结出以下DONT TOUCH使用建议：
- 最小化原则：只对真正关键的信号或模块使用DONT TOUCH
- 层次化标记：尽量在适当的抽象层次上应用属性
- 文档记录：在代码中添加注释说明使用DONT TOUCH的原因
- 定期审查：在项目后期重新评估DONT TOUCH的必要性
- 替代方案考虑：对于调试需求，可以考虑使用MARK_DEBUG属性
在资源受限的设计中，可以采用阶段性使用策略：在开发调试阶段启用DONT TOUCH，在最终量产版本中移除不必要的保留属性。这种方法既能满足调试需求，又能保证最终设计的优化程度。
