4. RTL设计与综合优化：GPU核心模块的RTL设计要点、综合策略（面积vs速度）、时序约束入门、综合报告解读
好，咱们进入第四章。这一章，说白了就是真刀真枪干活的章节了。
前面几章我们聊了架构、聊了工具链。但最终，你的GPU能不能跑起来，能不能跑得快，全看RTL写得怎么样，综合做得怎么样。我见过太多人，架构画得天花乱坠，一综合，时序一团糟，面积大得吓人。嗯，咱们今天就把这些坑一个个填上。
4.1 GPU核心模块的RTL设计要点
写GPU的RTL，跟写一般的逻辑不一样。它有几个非常鲜明的特点：
- 数据通路极宽：动不动就是512位、1024位。你想想看，一个SIMT单元，32个线程同时运算，每个线程32位，那就是1024位的数据总线。
- 控制逻辑复杂：Warp调度、寄存器重命名、异常处理，这些交织在一起。
- 频率要求高：GPU核心通常要跑到1GHz以上，在FPGA上虽然会降频，但设计思路得按高频来。
我个人习惯，写RTL之前，先画数据流图。不是那种高大上的架构图，就是一张白纸，把每个时钟周期数据怎么流动画清楚。这一步做好了，后面写代码就是体力活。
4.1.1 流水线设计：别让气泡毁了你的吞吐
GPU核心模块，最核心的就是流水线。以最简单的FMA（融合乘加）单元为例：
// 一个简单的3级流水线FMA
module fma_pipeline (
input clk,
input rst_n,
input [31:0] a, b, c,
input valid_in,
output [31:0] result,
output valid_out
);
// 第一级：乘法
reg [31:0] mult_result;
reg mult_valid;
always @(posedge clk or negedge rst_n) begin
if (!rst_n) begin
mult_result <= 0;
mult_valid <= 0;
end else begin
mult_result <= a * b; // 假设是定点数
mult_valid <= valid_in;
end
end
// 第二级：加法
reg [31:0] add_result;
reg add_valid;
always @(posedge clk or negedge rst_n) begin
if (!rst_n) begin
add_result <= 0;
add_valid <= 0;
end else begin
add_result <= mult_result + c;
add_valid <= mult_valid;
end
end
// 第三级：输出
reg [31:0] final_result;
reg final_valid;
always @(posedge clk or negedge rst_n) begin
if (!rst_n) begin
final_result <= 0;
final_valid <= 0;
end else begin
final_result <= add_result;
final_valid <= add_valid;
end
end
assign result = final_result;
assign valid_out = final_valid;
endmodule
这段代码看起来简单，但我在项目中遇到过一个问题：valid信号的处理。很多人只传递数据，忘了传递valid，结果下游模块拿到的是无效数据。记住，流水线里，数据和valid必须同步移动。
4.1.2 跨时钟域处理：GPU里的异步世界
GPU里时钟域多得很。核心频率、内存接口频率、PCIe频率，都不一样。跨时钟域处理不好，芯片直接废掉。
我曾经在一个项目里，因为一个跨时钟域的握手信号没处理好，导致仿真怎么都过不了。查了三天，最后发现是两级同步器之后，信号被采样到了错误的时钟沿。嗯，从那以后，我对跨时钟域设计就特别小心。
基本原则就两条：
- 单比特信号：用两级同步器（双锁存器）。
- 多比特信号：用异步FIFO，或者握手协议。
千万别想着用组合逻辑直接跨时钟域。你想想看，组合逻辑的毛刺，到了另一个时钟域，那就是灾难。
4.2 综合策略：面积 vs 速度
综合，就是把RTL变成门级网表的过程。但门级网表不是唯一的，同样的RTL，综合工具可以给你变出不同的花样来。这就涉及到综合策略的选择。
说白了，就是面积和速度的博弈。
| 策略 | 目标 | 典型场景 | 代价 |
|---|---|---|---|
| 面积优先 | 资源占用最小化 | 低成本FPGA、原型验证板资源紧张 | 频率可能降低 |
| 速度优先 | 达到最高工作频率 | 性能验证、高频GPU核心 | 面积增大、功耗上升 |
| 平衡策略 | 面积和速度折中 | 大多数原型验证场景 | 两者都不极致 |
我建议，在原型验证的初期，先用面积优先。为什么？因为初期主要是功能验证，跑通就行。等功能稳定了，再切换到速度优先，去压时序。
4.2.1 综合约束怎么写
综合约束，就是告诉工具：你要给我做到什么程度。最核心的就是时钟约束。
# 创建一个时钟，周期10ns，占空比50%
create_clock -name clk_core -period 10 [get_ports clk]
# 设置输入延迟
set_input_delay -clock clk_core -max 5 [get_ports data_in]
set_input_delay -clock clk_core -min 2 [get_ports data_in]
# 设置输出延迟
set_output_delay -clock clk_core -max 6 [get_ports data_out]
set_output_delay -clock clk_core -min 1 [get_ports data_out]
# 设置伪路径（跨时钟域）
set_false_path -from [get_clocks clk_a] -to [get_clocks clk_b]
这里要注意，伪路径一定要设对。我曾经见过有人把异步FIFO的读写指针路径设成了伪路径，结果综合工具直接优化掉了同步逻辑，板子跑起来数据全错。
4.3 时序约束入门
时序约束，是综合和布局布线的灵魂。没有约束，工具就不知道你的目标是什么。
我刚开始做FPGA时，觉得时序约束就是写几个时钟周期。后来发现，远远不止。真正的时序约束，要覆盖所有路径：
- 寄存器到寄存器：最常规的路径，由时钟周期决定。
- 输入到寄存器：由输入延迟决定。
- 寄存器到输出：由输出延迟决定。
- 输入到输出：组合逻辑路径，通常要设最大延迟。
对于GPU原型验证，我建议重点关注寄存器到寄存器路径。因为GPU的核心逻辑，大部分都是流水线，寄存器之间路径最长。
4.4 综合报告解读
综合完了，工具会生成一堆报告。很多人只看有没有错误，然后就过了。其实，报告里藏着很多信息。
4.4.1 时序报告
时序报告，主要看WNS（最差负时序裕量）和TNS（总负时序裕量）。
- WNS：如果为正，说明所有路径都满足时序。如果为负，说明最差的那条路径不满足。
- TNS：所有不满足路径的裕量总和。TNS很大，说明有很多路径不满足，问题比较严重。
我一般先看WNS。如果WNS是负的，但绝对值很小（比如-0.1ns），那可能只是个别路径的问题，手动优化一下就行。如果WNS是-2ns，那就要重新审视设计了。
4.4.2 面积报告
面积报告，看LUT、FF、BRAM、DSP的使用情况。
对于GPU原型验证，我特别关注BRAM和DSP。因为这两个资源是有限的，而且很难用LUT去替代。如果BRAM用超了，那就要考虑把部分数据放到外部DDR里。
我记得有一次，一个项目里DSP用到了120%，但LUT只用了60%。后来我把部分乘法器用LUT实现了，虽然面积大了点，但总算把设计塞进了FPGA。
4.4.3 功耗报告
功耗报告，在原型验证阶段可能不那么重要，但也不能忽视。如果功耗太大，FPGA会发热，甚至烧坏。
我建议，在综合后，看一眼动态功耗的估算值。如果超过FPGA的散热能力，就要考虑降频或者优化设计。
好了，这一章的内容就到这里。RTL设计、综合策略、时序约束、报告解读，这四个环节是环环相扣的。你想想看，RTL写得再好，综合策略不对，也跑不出性能。时序约束设得再准，不看报告，也不知道问题在哪。
下一章，我们会聊到仿真验证。到时候，我会分享一些我在仿真中踩过的坑，以及怎么用仿真来验证GPU的正确性。