1. Verilog代码规范概述：为什么需要代码规范？

说实话，我刚入行那会儿，也觉得代码规范是个麻烦事。

那时候我心想：代码能跑不就行了？写那么规整干嘛？直到有一次，我接手了一个前辈留下的项目——整整两万行的Verilog，没有注释，信号命名乱七八糟，一个always块里塞了三百行逻辑。我盯着屏幕看了三天，愣是没看懂那个状态机到底想干嘛。

嗯，从那以后，我再也不敢小看代码规范了。

1.1 代码规范到底是什么？

说白了，代码规范就是一套约定。它告诉你：信号怎么命名、代码怎么排版、模块怎么划分、注释怎么写。

它不是强制性的语法规则，而是团队协作的「通用语言」。你想想看，如果每个人写代码都按自己的习惯来，那项目交接的时候，简直就是灾难。

1.2 为什么需要代码规范？

我总结了四个最直接的原因：

• 可读性——别人（包括三个月后的你）能一眼看懂你的代码
• 可维护性——改bug、加功能的时候，不会牵一发动全身
• 可复用性——写好的模块能直接拿到下一个项目用
• 可验证性——仿真和综合的时候，少出莫名其妙的错误

我记得有一次，一个同事写的代码里，所有信号都用a1、b2、temp这种名字。结果综合的时候报了一个时序违例，我们三个人花了整整两天才找到那个信号——它藏在了一个嵌套了五层的if-else里。你说这时间花得冤不冤？

1.3 代码规范与可读性的关系

可读性这个东西，很多人觉得是「锦上添花」。其实不是，它是「雪中送炭」。

你想想看，一个模块几百行代码，如果没有规范：

• 信号命名随意，你根本猜不到它是干什么的
• 缩进混乱，逻辑层次看不清
• 没有注释，你只能一行一行去猜设计意图

我个人的习惯是：写代码的时候，假设半年后会有另一个人来接手。他能不能在半小时内看懂我的设计？如果能，那规范就到位了。

1.4 代码规范与可维护性的关系

可维护性，说白了就是改代码的时候不痛苦。

我在项目中遇到过这样一个场景：一个模块需要增加一个新的功能模式。结果因为原来的代码没有规范，信号命名混乱，状态机写成了一个大一统的always块。我改了一个信号，结果影响了三个功能模块。最后不得不把整个模块重写了一遍。

如果当初有规范：

• 模块接口清晰，功能划分明确
• 状态机独立编写，状态编码规范
• 组合逻辑和时序逻辑分开

那加一个新功能，可能只需要改一个状态和几行组合逻辑就够了。

1.5 代码规范的核心要素

我整理了一份清单，算是这些年踩坑踩出来的经验：

要素	说明	我的建议
命名规范	信号、模块、参数命名统一	用有意义的英文，别用拼音
缩进与排版	代码层次清晰可见	统一用4空格，别混用Tab
注释规范	解释设计意图，而非代码本身	每个模块头部写清楚功能
模块划分	功能独立，接口清晰	一个模块只做一件事
代码风格	always块、assign语句统一写法	组合逻辑用assign，时序逻辑用always

1.6 一个反面例子

给你看一段我早期写的代码，说实话，现在回头看我自己都脸红：

module test (a, b, c, d, e, f, g, h, i, j);
input a, b, c, d, e, f, g, h, i, j;
output reg [7:0] out;
reg [7:0] temp1, temp2, temp3;
always @(posedge a or negedge b) begin
  if (!b) begin
    temp1 <= 0;
    temp2 <= 0;
    temp3 <= 0;
  end else begin
    if (c) begin
      temp1 <= d + e;
      if (f) begin
        temp2 <= g - h;
      end else begin
        temp2 <= i + j;
      end
    end else begin
      temp1 <= 0;
      temp2 <= 0;
    end
    temp3 <= temp1 + temp2;
  end
end
assign out = temp3;
endmodule

你看，信号名全是a、b、c，根本不知道干嘛的。一个always块里混了复位、组合逻辑、时序逻辑。而且没有注释。这种代码，别说别人了，我自己过一个月都看不懂。

1.7 知识体系总览

下面这张图，是我对本章内容的一个梳理。你可以把它当作一个「导航图」：

1.8 避坑指南

最后，分享几个我亲身踩过的坑：

• 我曾经因为信号命名不规范，在仿真的时候把data_in和data_in_valid搞混了，结果整整浪费了一天去追bug。
• 我曾经接手一个项目，代码里没有模块注释，我花了三天才搞清楚每个模块的功能。从那以后，我要求团队每个模块头部必须写清楚：功能、输入输出、使用说明。
• 我曾经见过一个always块里写了200行逻辑，复位、组合、时序全混在一起。后来那个模块出了bug，没人敢改，最后只能重写。

嗯，这些教训都是用时间和加班换来的。希望你能少走这些弯路。

---