第一章：Verilog代码规范概述

各位同学好，我是老李。做数字IC设计这行，一晃十几年了。今天咱们聊聊代码规范——这个听起来有点枯燥，但实际特别重要的话题。

你可能觉得，代码能跑通不就行了？写那么规范干嘛？嗯，我当年也这么想。直到有一次，我接手一个离职同事的项目，打开代码一看……好家伙，那叫一个“自由奔放”。变量名用a、b、c，状态机用魔法数字，注释全是“//这里改一下”。我花了整整两周才理清楚逻辑。从那以后，我再也不敢小看代码规范了。

为什么需要代码规范？

说白了，代码规范不是写给机器看的，是写给人看的。机器只在乎你的语法对不对，而人——你的同事、你的继任者、甚至三个月后的你自己——需要快速理解你的设计意图。

我见过太多项目，因为代码混乱导致的问题：

• 调试困难：信号命名乱七八糟，查波形像破案
• 集成出错：模块接口风格不统一，连错信号都不知道
• 维护成本高：改一个功能，要翻遍整个文件找关联代码
• 综合结果差：不规范的可综合风格，导致面积和功耗失控

规范的核心目标

我个人习惯把代码规范的目标总结为四个词：可读、可维护、可综合、可仿真。咱们一个一个说。

1. 可读性

可读性是什么？就是你打开一个文件，扫一眼就能知道它在干什么。不需要逐行分析，不需要猜。

举个例子：

// 不规范的写法
assign d = (a & b) | (c & ~b);

// 规范的写法
assign data_out = (sel_a & enable) | (sel_c & ~enable);

你看，变量名一改，意图就清楚了。我在项目中遇到过有人用单字母变量写了几百行的组合逻辑，那真是……噩梦。

2. 可维护性

可维护性意味着：别人能改你的代码，而且改完不出错。

怎么做到？模块化、参数化、注释到位。比如：

// 好的做法：用parameter定义常量
parameter DATA_WIDTH = 8;
parameter FIFO_DEPTH = 16;

reg [DATA_WIDTH-1:0] fifo_mem [0:FIFO_DEPTH-1];

你想想看，如果这些数字直接写在代码里，哪天要改宽度，你得一个个找。用参数定义，改一处就行。

3. 可综合性

这个坑我踩过。有些写法仿真没问题，但综合工具不认。比如：

// 不可综合的写法
initial begin
  #10 clk = 0;
  forever #5 clk = ~clk;
end

// 可综合的写法
always @(posedge clk or negedge rst_n) begin
  if (!rst_n)
    count <= 0;
  else
    count <= count + 1;
end

记住：可综合的代码，必须用always块、assign语句，不能有#延时、不能有initial（测试bench除外）。

4. 可仿真性

可仿真性常被忽略。你的代码不仅要能跑，还要容易调试。比如：

• 信号命名要有规律，方便在波形里搜索
• 状态机用parameter定义状态名，不要用魔法数字
• 关键信号加assertion，仿真时自动检查

常见规范误区

讲几个我见过的典型误区，你对照一下自己有没有中招。

误区一：规范就是“死规矩”

有人觉得规范是束缚，是形式主义。其实不是。规范是经验的总结，是为了避免踩坑。比如“禁止使用锁存器”这条，不是故意为难你，而是锁存器在综合时容易出问题。

误区二：代码能跑就行

这个想法最危险。我曾经接手一个项目，代码仿真全过，但综合时报了一堆warning。仔细一看，有组合逻辑反馈环、有未初始化的寄存器……这些问题仿真时看不出来，但芯片一跑就出问题。

误区三：注释越多越好

嗯，这个有点反直觉。注释不是越多越好，而是越精准越好。比如：

// 不好的注释
reg [3:0] counter;  // 计数器

// 好的注释
reg [3:0] counter;  // 超时计数器，从0计数到15后产生中断

第一种注释等于没写。第二种才真正帮助理解。

误区四：个人风格无所谓

如果你一个人做项目，确实无所谓。但团队协作时，风格不统一就是灾难。我见过一个项目，有人用下划线命名法，有人用驼峰命名法，还有人用匈牙利命名法。结果呢？集成时连信号都找不对。

所以，团队必须统一规范。这不是扼杀个性，而是提高效率。

本章知识体系

下面这张图，帮你梳理本章的核心内容：

这张图把本章内容串起来了。左边是“为什么需要”，中间是“核心目标”，右边是“常见误区”。你记住这个框架，后面每一章都会围绕这些点展开。

小结

代码规范这件事，说大不大，说小不小。它不会让你的代码功能变强，但会让你的代码更“专业”。

我见过太多工程师，技术能力很强，但代码写得一塌糊涂。结果呢？评审时被反复打回，项目进度被拖累。说白了，规范是一种职业素养。

从下一章开始，我们会深入具体的规范细节。命名、注释、模块结构、状态机……一个一个来。你跟着学，慢慢养成习惯，你会发现——写规范的代码，其实比写“自由”的代码更省心。