2、RTL代码风格与综合：可综合RTL写法、避免Latch、资源共享、流水线插入对时序的影响
好，咱们直接进入正题。RTL代码怎么写，直接决定了综合工具能把你推到多高的频率。我见过太多项目，前端把RTL一丢，说「时序肯定没问题」，结果后端一跑，全是setup violation。说白了，代码风格就是时序的起点。
2.1 可综合RTL写法：别让工具猜你的心思
综合工具不是人，它很笨。你写出来的代码，必须让它一眼就能看懂你要搭什么电路。我个人习惯，写RTL之前先画个简单的数据流图，想清楚哪些是组合逻辑，哪些是寄存器。
核心原则：
- always @(posedge clk) 里只赋值寄存器，别混组合逻辑
- 组合逻辑用 assign 或 always @(*)，别把电平敏感和边沿敏感写在一起
- if-else 要写全，case 要加 default，否则综合出 latch
可综合 vs 不可综合的典型例子：
// 可综合：标准的D触发器
always @(posedge clk or negedge rst_n) begin
if (!rst_n)
q <= 1'b0;
else
q <= d;
end
// 不可综合：用了 initial 和 #delay
initial begin
#10 clk = 0;
forever #5 clk = ~clk;
end嗯，这里要注意：for循环在RTL里是可以综合的，但必须是固定次数的循环。我在项目中遇到过有人用 while(1)，综合工具直接报错——它没法展开无限循环。
2.2 避免Latch：综合出来的隐形炸弹
Latch 这东西，说白了就是电平触发的锁存器。它不像寄存器那样有明确的时钟边沿控制，综合出来之后，时序分析工具很难精确约束它。我曾经在一个项目中，因为一个 if 语句少写了 else，综合出一堆 latch，导致后端的 hold time 怎么修都修不完。
Latch 是怎么产生的？
- 组合逻辑的 if 没有 else
- case 没有 default，且所有分支没覆盖全
- 在 always @(posedge clk) 里对同一个变量既赋值又保持
避坑指南：我曾经在写状态机时，case 的最后一个状态忘了加 default，结果综合出来一个 latch。仿真时功能完全正确，但后端说时序收敛不了。查了两天才发现是 latch 导致的组合环路。所以我现在写 case，必加 default，哪怕只是 default: next_state = IDLE;
你想想看，latch 对时序的影响有多大？它不像寄存器那样有固定的 setup/hold 窗口，综合工具会把它当成组合逻辑处理，但实际行为又像时序单元。这种「四不像」最让后端头疼。
2.3 资源共享：面积和时序的博弈
资源共享，说白了就是让多个运算共用同一个硬件模块。比如两个加法器，如果它们不会同时工作，就可以合并成一个。但这里有个坑：资源共享省了面积，但可能毁了时序。
| 场景 | 不共享 | 共享 |
|---|---|---|
| 面积 | 大（两个加法器） | 小（一个加法器 + MUX） |
| 时序 | 好（路径短） | 差（多了MUX延迟） |
| 功耗 | 高 | 低 |
我个人习惯是：高频模块不共享，低频模块大胆共享。比如在 CPU 的 ALU 里，加法器和乘法器我绝不共享，因为频率太高，MUX 的延迟会吃掉半个周期。但在控制逻辑里，多个配置寄存器共用一个写地址译码器，完全没问题。
小技巧：综合工具一般有资源共享的选项（如 Design Compiler 的 set_resource_sharing）。如果你发现时序紧张，可以关掉它。我一般先关掉跑一次，看看最差路径在哪里，再决定哪些地方手动共享。
2.4 流水线插入：用延迟换频率
流水线，说白了就是把一个长组合逻辑切成几段，中间插寄存器。这样每个小段的延迟变短了，频率就能提上去。代价是多了几个周期的 latency。
举个例子：
// 非流水线：一个周期算完
always @(posedge clk) begin
result <= a * b + c * d + e * f;
end
// 三级流水线：分三步算
always @(posedge clk) begin
stage1_mul1 <= a * b;
stage1_mul2 <= c * d;
stage1_mul3 <= e * f;
stage2_add1 <= stage1_mul1 + stage1_mul2;
stage2_add2 <= stage1_mul3;
result <= stage2_add1 + stage2_add2;
end你看，非流水线版本里，乘法器和加法器串在一起，路径延迟可能是 5ns。切成三级流水后，每级只有 2ns 左右，频率从 200MHz 直接飙到 500MHz。当然，结果要等 3 个周期才出来。
我在项目中遇到过一个问题：流水线插多了，面积暴涨。因为每个流水级都要放寄存器，而且数据位宽越大，面积越夸张。所以我的建议是：只插在关键路径上。先用工具跑一下，看看哪条路径最差，就在那里插一两级，别全插。
流水线插入的黄金法则：
- 每级组合逻辑延迟控制在周期的 70% 以内（留余量给时钟偏斜和 OCV）
- 流水级数不要超过 5 级（除非是特殊模块，比如 FIR 滤波器）
- 注意流水线平衡：别让一级特别长，其他级特别短
2.5 综合工具视角：代码风格如何影响综合结果
综合工具在优化时，会尽量保持你的代码结构。你写 if-else，它就生成 MUX；你写 case，它就生成 decoder。但如果你写得不好，工具会「猜错」你的意图。
举个例子：
// 写法A：工具容易优化
assign sel = (addr == 8'hFF) ? 1'b1 : 1'b0;
// 写法B：工具可能综合出优先级编码器
always @(*) begin
if (addr == 8'hFF)
sel = 1'b1;
else
sel = 1'b0;
end写法A和B功能完全一样，但综合结果可能不同。写法A会生成一个比较器 + MUX，写法B可能被工具理解成优先级逻辑。虽然最终优化后可能一样，但万一工具没优化好呢？所以我个人习惯：能用 assign 的绝不用 always，除非是复杂的状态机。
注意：综合工具对 casex 和 casez 的处理可能和仿真不一致。我曾经在仿真时用 casez 匹配不定态，结果综合出来的电路完全不对。后来查资料才知道，综合工具把 casez 里的 '?' 当成 don't care，但仿真时当成匹配条件。所以我现在一律用 case，不用 casez/casex。
2.6 实战建议：从RTL到综合的检查清单
好，最后总结一下。每次写完RTL，准备交给综合工具之前，我建议你过一遍这个清单：
- 检查所有 if-else 和 case：有没有漏掉的分支？有没有产生 latch？
- 检查所有 always @(posedge clk)：是不是只赋值寄存器？有没有混组合逻辑？
- 检查资源共享：高频路径上有没有不必要的MUX？
- 检查流水线：关键路径有没有插够？流水级数是不是太多？
- 跑一次 lint 检查：工具会告诉你哪些代码风格有问题
嗯，说白了，RTL代码风格就是你和综合工具之间的「沟通语言」。你写得越规范，工具就越懂你，时序收敛就越顺利。我见过太多工程师，花几周调后端，结果发现是RTL里一个 if 没写 else 导致的 latch 问题。所以，从源头抓起，比什么都重要。