3、RTL代码检查：代码风格规范、lint检查、综合指导语句的正确使用
RTL代码检查，说白了就是流片前的「排雷」环节。我见过太多项目，功能仿真跑得欢，一到综合就翻车。为什么？代码写得太「自由」了。芯片设计不是写软件，每一行Verilog最终都会变成实实在在的晶体管。你写了个for循环，软件工程师觉得没啥，但综合工具可能直接给你展开成一大片组合逻辑，面积爆炸。
所以这一节，咱们重点聊聊三件事：代码风格怎么定、lint检查怎么跑、综合指导语句怎么用才不坑。
3.1 代码风格规范：别让队友骂你
我个人习惯，代码风格这件事，必须在项目启动第一天就定下来。不然后面review代码，你会想打人。
这里列几条我踩过坑之后总结的硬性规范：
- 命名要有意义：别用a、b、c这种。我见过一个模块里全是`wire w1, w2, w3...`，三个月后他自己都看不懂。
- 信号名统一风格：比如全局用`lower_case_with_underscore`，别混用驼峰和下划线。
- 寄存器命名加后缀：`_reg`表示寄存器，`_n`表示低有效，`_dly`表示延迟一拍。看一眼名字就知道用途。
- 模块例化要清晰：端口连接用`.port_name(wire_name)`，别用位置映射。位置映射改一个端口顺序，整个模块都得重连。
核心原则：代码是写给人看的，顺便给工具跑。可读性永远优先于「少打几个字」。
举个例子，我比较推荐这种写法：
// 好的风格
wire [7:0] data_in;
wire [7:0] data_out;
reg [7:0] data_reg;
always @(posedge clk or negedge rst_n) begin
if (!rst_n)
data_reg <= 8'h00;
else if (data_valid)
data_reg <= data_in;
end
// 差的风格
wire [7:0] a;
reg [7:0] b;
always @(posedge clk or negedge rst) begin
if (~rst) b <= 0;
else if (vld) b <= a;
end你看，好的风格一眼就能看出逻辑。差的风格，你还得猜`vld`是啥、`rst`是高有效还是低有效。
3.2 Lint检查：工具比你细心
lint检查，说白了就是让工具帮你抓代码里的「坏味道」。我刚开始做设计时，总觉得lint是形式主义。直到有一次，lint报了一个「组合逻辑反馈环路」的警告，我没当回事，结果综合后仿真直接死循环。嗯，从那以后我再也不敢跳过lint了。
常用的lint工具有：
- SpyGlass：Synopsys家的，功能强大，但配置略复杂。
- Design Compiler的lint选项：综合工具自带的，方便但检查项少一些。
- Verilator lint：开源工具，适合小项目快速检查。
lint检查主要抓这几类问题：
| 检查项 | 说明 | 严重程度 |
|---|---|---|
| 未使用信号 | 声明了但没用到，可能是设计遗漏 | 中 |
| 组合反馈环路 | 组合逻辑输出直接或间接反馈到输入 | 高 |
| 锁存器推断 | 条件分支不完整，综合出latch | 高 |
| 位宽不匹配 | 赋值左右位宽不一致 | 中 |
| 时钟门控问题 | 时钟信号被组合逻辑驱动 | 高 |
注意：lint报的warning，不要全部忽略。我建议至少把「高」严重程度的warning全部清零。「中」级别的可以酌情处理，但要有记录。
跑lint的正确姿势是什么？我个人习惯是：
- 每天下班前跑一次lint，当天的问题当天清。
- 不要等到模块全部写完再跑，那时候问题堆成山，改起来想哭。
- lint结果要review，有些false positive可以加注释豁免，但别滥用。
3.3 综合指导语句：用对是神器，用错是炸弹
综合指导语句，就是你在RTL里写给综合工具看的「小纸条」。比如`// synopsys translate_off`、`/* synthesis keep */`这些。用好了能精准控制综合结果，用错了...嗯，我见过有人把整个模块的时序逻辑都综合没了。
常用的综合指导语句：
- translate_off/translate_on：让综合工具跳过某段代码。常用于仿真专用的代码，比如延时语句、文件读写。
- keep/hierarchy：告诉工具不要优化掉某个信号或模块。我遇到过组合逻辑被工具优化掉导致功能错误的案例，加上keep就解决了。
- full_case/parallel_case：用于case语句，告诉工具所有分支都已覆盖（full）或分支互斥（parallel）。但这两个要慎用，用错了会仿真和综合不一致。
小技巧：如果你不确定某个综合指导语句的效果，可以先写个小模块单独综合看看结果。别直接往大项目里塞，翻车了不好查。
举个例子，`full_case`的坑：
// 慎用 full_case
case (sel) // synopsys full_case
2'b00: out = a;
2'b01: out = b;
2'b10: out = c;
// 没有写 2'b11
endcase加上`full_case`后，综合工具认为`2'b11`不会出现，直接优化成优先级逻辑。但仿真时如果`sel`变成`2'b11`，输出是`x`。仿真和综合结果不一致，这就是个大坑。
我曾经在一个项目中，就是因为用了`full_case`，导致后仿出现不定态，查了整整两天才定位到问题。从那以后，我对`full_case`和`parallel_case`的态度就是：能不用就不用，实在要用，必须加注释说明为什么用。
3.4 知识体系总览
下面这张图，帮你理清RTL代码检查的核心逻辑：
你看，这三个方面其实是环环相扣的。代码风格不好，lint检查会报一堆假错；lint检查不跑，综合指导语句用错了也没人发现。所以我的建议是：把这三件事当成一个整体来抓，缺一不可。
最后说一句，RTL代码检查这件事，做得越早、越细，流片后的坑就越少。别等到tapeout前一周才想起来跑lint，那时候改代码，改一个地方可能牵连十个地方，心态直接崩掉。
公众号:蓝海资料掘金营，微信deep3321