4、RTL设计与综合：Verilog/VHDL代码编写、综合选项设置、综合报告解读

好，咱们进入正题。RTL设计，说白了就是把你脑子里的电路逻辑，用硬件描述语言写出来。这一步做不好，后面时序收敛、功耗优化全是空谈。我见过太多新手，上来就写代码，结果综合出来一堆Latch，或者面积大得吓人。嗯，今天咱们就把这块掰开揉碎了讲清楚。

4.1 可综合的Verilog/VHDL代码风格

先问个问题：你写的代码，综合器真的能看懂吗？

很多人以为写Verilog就像写C语言，其实差远了。硬件描述语言的核心是描述「电路结构」，而不是描述「执行流程」。我个人的习惯是，写代码之前先在脑子里把寄存器传输级（RTL）的框图画出来，再动手写。

4.1.1 组合逻辑与时序逻辑的区分

这是最基础，也是新手最容易翻车的地方。记住一个原则：

• 组合逻辑：用 assign 或 always @(*) 实现。输出只取决于当前输入。
• 时序逻辑：用 always @(posedge clk) 实现。输出取决于时钟边沿和之前的状态。

举个例子，一个简单的D触发器：

// Verilog 风格
always @(posedge clk or negedge rst_n) begin
  if (!rst_n)
    q <= 1'b0;
  else
    q <= d;
end

注意这里用了非阻塞赋值 <=。为什么？因为时序逻辑里，非阻塞赋值能保证多个寄存器在同一个时钟沿同时更新，模拟出硬件并行工作的特性。你想想看，如果用阻塞赋值 =，那综合出来的电路行为就完全不对了。

4.1.2 避免生成Latch

Latch是组合逻辑中的锁存器，大部分情况下不是我们想要的。它会让时序分析变得复杂，而且对毛刺敏感。我见过最夸张的一个案例，有人写了一个case语句，忘了写default，结果综合出来一堆Latch，面积直接翻倍。

避坑指南：

• 组合逻辑的 always @(*) 块里，所有分支都必须赋值。
• if语句必须有else。
• case语句必须有default。

4.2 综合选项设置

代码写好了，接下来就是综合。Vivado的综合选项很多，但真正关键的其实就几个。我一般会按项目阶段来调整：

选项	推荐设置	说明
flatten_hierarchy	rebuilt	保持层次结构，方便调试。如果追求性能可以选full
fsm_extraction	one_hot / auto	状态机编码方式，one_hot适合高速，binary适合面积
keep_equivalent_registers	false	合并等效寄存器，减少面积
resource_sharing	auto	自动共享算术资源，比如加法器、乘法器
max_bram	-1 (unlimited)	限制BRAM使用数量，防止过度推断

我个人习惯在综合前先跑一次 report_compile_order，看看Vivado是怎么理解你的代码结构的。有时候你会发现，你写的代码和综合器理解的根本不是一回事。

4.3 综合报告解读

综合完成后，Vivado会生成一堆报告。很多人只看一眼时序结果就跑了，其实这里面藏着大量信息。我一般会按以下顺序看：

4.3.1 综合报告概览

打开 synth_1/synth_1.rpt，先看最上面的Summary：

• Cell Count：用了多少LUT、FF、BRAM、DSP。如果某个资源用量异常高，说明代码风格有问题。
• Estimated Frequency：综合器估算的最高频率。注意这只是估算，实际布局布线后会有变化。
• Warnings：重点关注Latch inferred、Multi-driven nets这类警告。

4.3.2 时序报告解读

综合后的时序报告虽然不如布局布线后准确，但能帮你提前发现潜在问题。重点看：

• Worst Negative Slack (WNS)：最差路径的时序裕量。如果是负数，说明这条路径可能无法满足时序要求。
• Total Negative Slack (TNS)：所有违规路径的裕量总和。这个值越大，说明问题越严重。
• Number of Failing Endpoints：有多少个寄存器违反了时序。

我记得有一次，综合报告显示WNS是-0.3ns，我当时没在意，觉得布局布线后能收敛。结果布局布线后WNS变成了-1.2ns，最后不得不重新优化代码。所以，别小看综合阶段的时序报告。

4.3.3 资源利用率报告

打开 utilization_synth.rpt，看看各个模块的资源占用情况。我一般会关注：

• LUT利用率：如果超过80%，布局布线时可能会遇到拥塞问题。
• BRAM利用率：注意BRAM的分布，尽量分散使用，避免局部拥塞。
• DSP利用率：如果用了大量DSP，检查是否真的需要，有时候用LUT实现更划算。

4.4 知识体系结构图

下面这张图，是我自己总结的RTL设计与综合的核心流程。你可以把它当作一个检查清单：

4.5 实战经验总结

最后，分享几个我这些年积累的小技巧：

• 代码风格统一：团队协作时，建议用统一的命名规范。比如寄存器用 _reg 后缀，线网用 _wire 后缀。这样综合报告里一眼就能看出哪些是寄存器。
• 善用综合属性：Vivado支持很多综合属性，比如 (* keep = "true" *) 可以防止综合器优化掉你不想优化的信号。我在调试时经常用这个。
• 不要过度优化：综合器很聪明，但也很笨。你强行用代码去「指导」综合器，有时候反而会适得其反。先写清晰的代码，再根据综合报告做针对性优化。

好了，这一章的内容就到这里。记住，综合报告是你的好朋友，别怕看它，多看看自然就懂了。